Andrew Woodward
2015-07-09 23:06:35 UTC
It has come to my attention that we spend an enormous amount of time in
Fuel when switching between OpenStack releases. A good amount of this seems
to be due to a chicken and the egg problem. We cant deploy updated packages
with out updated manifests, and we we cant update (in that CI won't pass)
the manifests without updated packages. In order to accommodate this we
either have to set up a new separate set of CI pipelines for both or freeze
various parts of CI, merging patch sets that can't pass until everything is
in and working, or some monstrous combination of both. This has become
quite the time sink for everyone involved and there must be a better way to
accommodate switching between releases.
Thinking about this I wonder how much easier this process could be if the
manifests supported two releases at once.
I propose that we consider supporting both the dev release, and the prior
release (as stable and default for option precedence). We would need to
come up with some option versioning scheme in which we can identify options
which are only relevant to the specific release (I'm not yet sure what sure
what this would look line) This seems like it would be most of the need to
support multiple versions at once.
But why should we go through this effort? Yes this would become complicated
to set up, however I cant imagine that other folks are not having a similar
issues.
* Moving to a two version system should nearly reduce the impact of
switching to nearly none (given you have packages)
* It should also help accelerate our releases of puppet-openstack, since
devs can switch between versions more easily
* It should help our release support story since non-option changes will
automatically hit dev and (current) stable manifests at the same time
* This can also help the current stable release process, instead of
branching, we can simply tag the first stable release and maintain it in
the master branch, only pushing it out when we drop it to shift the
dev/stable versions
* While not a direct benefit to puppet-openstack, this would help simplify
fuel running CI on master openstack and master puppet-openstack which will
help with our efforts in puppet-openstack
So next steps
Lets discuss the proposal in general (good idea / bad idea). I'd like to
hash out what this versioned interface may need to look like, that way I
can take up attempting to make this work in a single module so we can
vet/discuss any issues more thoroughly.
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
Fuel when switching between OpenStack releases. A good amount of this seems
to be due to a chicken and the egg problem. We cant deploy updated packages
with out updated manifests, and we we cant update (in that CI won't pass)
the manifests without updated packages. In order to accommodate this we
either have to set up a new separate set of CI pipelines for both or freeze
various parts of CI, merging patch sets that can't pass until everything is
in and working, or some monstrous combination of both. This has become
quite the time sink for everyone involved and there must be a better way to
accommodate switching between releases.
Thinking about this I wonder how much easier this process could be if the
manifests supported two releases at once.
I propose that we consider supporting both the dev release, and the prior
release (as stable and default for option precedence). We would need to
come up with some option versioning scheme in which we can identify options
which are only relevant to the specific release (I'm not yet sure what sure
what this would look line) This seems like it would be most of the need to
support multiple versions at once.
But why should we go through this effort? Yes this would become complicated
to set up, however I cant imagine that other folks are not having a similar
issues.
* Moving to a two version system should nearly reduce the impact of
switching to nearly none (given you have packages)
* It should also help accelerate our releases of puppet-openstack, since
devs can switch between versions more easily
* It should help our release support story since non-option changes will
automatically hit dev and (current) stable manifests at the same time
* This can also help the current stable release process, instead of
branching, we can simply tag the first stable release and maintain it in
the master branch, only pushing it out when we drop it to shift the
dev/stable versions
* While not a direct benefit to puppet-openstack, this would help simplify
fuel running CI on master openstack and master puppet-openstack which will
help with our efforts in puppet-openstack
So next steps
Lets discuss the proposal in general (good idea / bad idea). I'd like to
hash out what this versioned interface may need to look like, that way I
can take up attempting to make this work in a single module so we can
vet/discuss any issues more thoroughly.
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community