search

ansible-community / ara-collection

Collection of Ansible roles for ARA Records Ansible.
https://ara.recordsansible.org
GNU General Public License v3.0
28 stars 16 forks source link

Release schedule #17

Closed Thulium-Drake closed 3 years ago

Thulium-Drake commented 3 years ago

Hi @dmsimard,

Apart from 'where we want to go', do you already have plans/ideas on releasing the collection. For example:

dmsimard commented 3 years ago

Hey @Thulium-Drake and thanks for the issue!

Releases for ara and the collection have historically been on a need basis rather than on a schedule because the (relativelly small) volume of changes did not previously justify doing otherwise.

In other words, if there's no commits for a month, there's no release to cut but if there is a steady stream of contributions, then we could end up releasing twice in a month! I'm happy to revisit this in the future but I don't yet see the need to commit to a strict release schedule for now.

More specifically:

Are all the desired features in here?

Not quite -- off the top of my head (and we can create issues for these), there would be at least:

I don't see myself using all of these but I'd like to have support for them in the roles even if just for integration testing purposes since we use the collection in CI jobs.

selinux support would warrant a look at too -- it's not really good and I can't pretend I'm a selinux expert.

How are bugfixes handled (one release for each? One for every 10? Or once a month?)?

On a need basis -- maybe because there hasn't been a release in a while (like now!) or if we (as in maintainers) or users need a release.

Thulium-Drake commented 3 years ago

Hey @Thulium-Drake and thanks for the issue!

Releases for ara and the collection have historically been on a need basis rather than on a schedule because the (relativelly small) volume of changes did not previously justify doing otherwise.

In other words, if there's no commits for a month, there's no release to cut but if there is a steady stream of contributions, then we could end up releasing twice in a month! I'm happy to revisit this in the future but I don't yet see the need to commit to a strict release schedule for now.

More specifically:

Are all the desired features in here?

Not quite -- off the top of my head (and we can create issues for these), there would be at least:

* managing user authentication (i.e, creating users in django, `EXTERNAL_AUTH` is out of scope)

I might have a usecase for my current customer in which I could warrent spending some time on this, but either way, I'll have a look at it :-)

WRT external authentication, maybe 'just' configuring ARA to do it, nothing else. The user should still configure his/her webserver to actually authenticate.

* running the server with mod_wsgi (WIP PR already opened)

* running the server with uwsgi (shouldn't be terribly different than gunicorn)

* running the server with podman (and perhaps docker, but it's getting increasingly difficult to support both especially across distros)

I'd say pick one and stick with it. I'm no expert and I only run docker (podman is not ready for Debian just yet ;-) ). But my gut feeling is that ARA isn't all to complicated to get running on either. So maybe just create a OCI-compliant image which is tested on both and then CI-ed for just docker or podman.

I don't see myself using all of these but I'd like to have support for them in the roles even if just for integration testing purposes since we use the collection in CI jobs.

selinux support would warrant a look at too -- it's not really good and I can't pretend I'm a selinux expert.

How are bugfixes handled (one release for each? One for every 10? Or once a month?)?

On a need basis -- maybe because there hasn't been a release in a while (like now!) or if we (as in maintainers) or users need a release.

Sounds great! Is there already a workflow to release it to Galaxy? There's some fixes in now I'd really love to have packaged (I have multiple versions of the collection laying around now and none of them are the same... :-) )

Maybe just stick to 0.0.x for now, while we still work on this list. I'll consider this answered for now!

Can you add the list of features to your issue about brainstorming, or create a new issue with it along the lines of 'We need this for 1.0.0'?

Cheers!

dmsimard commented 3 years ago
  • managing user authentication (i.e, creating users in django, EXTERNAL_AUTH is out of scope)

    I might have a usecase for my current customer in which I could warrent spending some time on this, but either way, I'll have a look at it :-)

I know there is some "prior art" in this area like on stack overflow and this gist but I can't help but think there must be a better way. Once upon a time @apollo13 pointed me to https://github.com/ansible/ansible/pull/46544 but I haven't followed up on it.

WRT external authentication, maybe 'just' configuring ARA to do it, nothing else. The user should still configure his/her webserver to actually authenticate.

Yeah, that's what I had in mind. The vhost configuration file is meant to be replaceable by one provided by the user if need be like we do for the live demo: https://github.com/ansible-community/ara-infra/blob/master/playbooks/templates/api.demo.recordsansible.org.conf.j2

  • running the server with podman (and perhaps docker, but it's getting increasingly difficult to support both especially across distros)

    I'd say pick one and stick with it. I'm no expert and I only run docker (podman is not ready for Debian just yet ;-) ). But my gut feeling is that ARA isn't all to complicated to get running on either. So maybe just create a OCI-compliant image which is tested on both and then CI-ed for just docker or podman.

The image published to docker hub and quay.io are already OCI compliant (built with buildah) and it already works with both docker and podman. We test that we can build and run the images before publishing them but it's not with the role, it's with an integration test playbook.

Sounds great! Is there already a workflow to release it to Galaxy? There's some fixes in now I'd really love to have packaged (I have multiple versions of the collection laying around now and none of them are the same... :-) )

Yeah, there is automation with Zuul to publish a new version of the collection to galaxy automatically whenever we push a new tag to the git repo. It's not enabled yet but it's not complicated to add when we're ready.

Maybe just stick to 0.0.x for now, while we still work on this list. I'll consider this answered for now! Can you add the list of features to your issue about brainstorming, or create a new issue with it along the lines of 'We need this for 1.0.0'?

We can release new versions easily and the collection is stable enough that tagging a 1.0.0 even before landing the above doesn't come across as shocking to me. Maybe we could land https://github.com/ansible-community/ara-collection/pull/15 first but otherwise the rest are good additions that aren't blockers and can ship later.

dmsimard commented 3 years ago

@Thulium-Drake we are long overdue for a release and I think with the last few bugfixes that we merged it should be good to go. What do you think ?

I wouldn't use 1.0.0 yet because I am not sure if ara-web will make the cut. It's been long broken/neglected and it tends to confuse users more than anything else.

Thulium-Drake commented 3 years ago

I agree, a 0.x release is enough for now :-)

What is the future within the ARA project for ara-web? Does it have a bright future ahead? If so, we could also opt to remove it from the collection.

I'll have a look on Friday to make issues for all the features you listed in one of your earlier posts. If you can then also add the issues you feel we need (that aren't listed in this thread ;-) ), we can close this issue as the release schedule is clear. And we could use Github's milestone thingey to determine when 1.0.0 is ready :-)

dmsimard commented 3 years ago

I agree, a 0.x release is enough for now :-)

:+1:

What is the future within the ARA project for ara-web? Does it have a bright future ahead? If so, we could also opt to remove it from the collection.

I've always believed that ara-web had potential but I am most definitely not a javascript person. As time went on, it eventually broke due to API changes and the feature gap with the built-in UI has grown increasingly significant.

With that in mind, it's future mostly relies on someone knowledgeable and willing to pick it up but in spite of various attempts here and there, this has not happened. I have not fully retired the project and removed the role in hope that it would make an eventual return easier but it has not happened either.

In other words: my time is limited and is better spent not doing javascript where I can be productive and bring more value to the project. I would love to be pleasantly surprised but I don't expect it will happen.

I'll have a look on Friday to make issues for all the features you listed in one of your earlier posts. If you can then also add the issues you feel we need (that aren't listed in this thread ;-) ), we can close this issue as the release schedule is clear. And we could use Github's milestone thingey to determine when 1.0.0 is ready :-)

Sure thing -- one of the things I had mentioned was support for authentication. I must point out that I have a different opinion about authentication now and I've updated the issue we have about it: https://github.com/ansible-community/ara-collection/issues/4

Thulium-Drake commented 3 years ago 
* managing user authentication (i.e, creating users in django, `EXTERNAL_AUTH` is out of scope)

4

* running the server with mod_wsgi (WIP PR already opened)

38

* running the server with uwsgi (shouldn't be terribly different than gunicorn)

41

* running the server with podman (and perhaps docker, but it's getting increasingly difficult to support both especially across distros)

40

An additional nice-to-have would to to have something of a (semi)-automatic workflow to publish to Galaxy. I have set this up for almost all of my roles. Galaxy's current behavior is to automatically import the latest tag. So every time I make a tag, it magically appears on Galaxy.

42

dmsimard commented 3 years ago

Thanks for creating the issues !

I've released 0.1.0: https://twitter.com/RecordsAnsible/status/1427714595033133062

We can close this now I think.