On Thu, Feb 18, 2016 at 4:00 AM, Aleksandr Didenko <adide...@mirantis.com> wrote:
> > Given the requirements to be able to use new features in fuel, with an > older version of OpenStack, what alternative would you propose? > > For example, it's possible to use existing "release" functionality in Fuel > (release contains granular tasks configuration, puppet modules and > manifests, configuration data). So after upgrade from 8.0 to 9.0 it will > look like this [0] - with separate composition layer for every supported > "release". > > > We should allow a user to specify that they want a build a cloud using X > fuel release to deploy Y os with Z OpenStack release. > > [0] should work for this as well. But the number of X-Y-Z combinations > will be limited. Well, it will be limited in any case, I don't think that > it's possible to support unlimited number of OpenStack versions in a single > Fuel release. > > I agree it should not be unlimited but it should be created than the 1-1-1 we currently support. Since we push for upstream openstack puppet to support current and best effort on current-1, I think being able to support at least that should be doable. > In case we want to use single composition layer for more than one > openstack version, we need to resolve the following blockers: > - Move everything except composition layer (top-scope manifests and other > granular tasks) from fuel-library to their own repos. Otherwise we'll have > OpenStack version conditionals in modules manifets, providers and functions > which would be a mess. > - Refactor tasks upload/serialization in Nailgun > - (?) Refactor configuration data serialization in Nailgun > > And still we'll have to add conditionals to puppet functions that relay on > configuration data directly (like generate_network_config.rb). Or write > some sort of data serialization in front of them in manifests. Or leave > nailgun serialization based on installed version (which is almost the same > as using separate composition layers [0]). > > In either case (separate releases or single composition layer) it will > double CI load and testing efforts, because we need to CI/test new features > and patches for 9.0+mitaka and 9.0+liberty. > > Regards, > Alex > > [0] http://paste.openstack.org/show/487383/ > > > On Thu, Feb 18, 2016 at 9:31 AM, Bogdan Dobrelya <bdobre...@mirantis.com> > wrote: > >> On 17.02.2016 18:23, Bogdan Dobrelya wrote: >> >> So we'll have tons of conditionals in composition layer, right? Even if >> >> some puppet-openstack class have just one new parameter in new release, >> >> then we'll have to write a conditional and duplicate class >> declaration. Or >> >> write complex parameters hash definitions/merges and use >> >> create_resources(). The more releases we want to support the more >> >> complicated composition layer will become. That won't make >> contribution to >> >> fuel-library easier and even can greatly reduce development speed. >> Also are >> >> we going to add new features to stable releases using this workflow >> with >> >> single composition layer? >> > >> > As I can see from an example composition [0], such code would be an >> > unmaintainable burden for development and QA process. Next imagine a >> > case for incompatible *providers* like network transformations - shall >> > we put multiple if/case to the ruby providers as well?.. >> > >> > That is not a way to go for a composition, sorry. While the idea may be >> > doable, I agree, but perhaps another way. >> > >> > (tl;dr) >> > By the way, this reminded me "The wrong abstraction" [1] article and >> > discussion. I agree with the author and believe one should not group >> > code (here it is versioned puppet modules & compositions) in a way which >> > introduces abstractions (here a super-composition) with multiple >> > if/else/case and hardcoded things to switch the execution flow based on >> > version of things. Just keep code as is - partially duplicated by >> > different releases in separate directories with separate modules and >> > composition layers and think of better solutions please. >> > >> > There is also a nice comment: "...try to optimize my code around >> > reducing state, coupling, complexity and code, in that order". I >> > understood that like a set of "golden rules": >> > - Make it coupled more tight to decrease (shared) state >> > - Make it more complex to decrease coupling >> > - Make it duplicated to decrease complexity (e.g. abstractions) >> > >> > (tl;dr, I mean it) >> > So, bringing those here. >> > - The shared state is perhaps the Nailgun's world view of all data and >> > versioned serializers for supported releases, which know how to convert >> > the only latest existing data to any of its supported previous versions. >> > - Decoupling we do by putting modules with its compositions to different >> > versioned /etc/puppet subdirectories. I'm not sure how do we decouple >> > Nailgun serializers though. >> > - Complexity is how we compose those modules / write logic of >> serializers. >> > - Duplication is puppet classes (and providers) with slightly different >> > call parameters from a version to version. Sometimes even not backwards >> > compatible. Probably same to the serializers? >> > >> > So, we're going to *increase complexity* by introducing >> > super-compositions for multi OpenStack releases. Not sure about what to >> > happen to the serializers, any volunteers to clarify an impact?. And the >> > Rules "allow" us to do so only in order to decrease either coupling or >> > shared state, which is not the case, AFAICT. Modules with compositions >> > are separated well by OpenStack versions, nothing to decrease. Might >> > that change to decrease a shared state? I'm not sure if it even applies >> > here. Puppet versioning shares nothing. Only Nailgun folks may know the >> > answer. >> >> AFAIK, Nailgun serializers have no shared state and state at all, as >> they always produce the same "data view" for a given version and there >> is no internal state impacting results. Although, they might end up with >> decreased complexity while the orchestration logic - with a drastically >> increased one. It would be hard to determine which deployment graph to >> build from the super-composed multi-release modular tasks, AFAICT. So it >> seems no gain here as well. That means the Golden Rules recommend us to >> not do so :) >> >> > >> > [0] >> > >> https://review.openstack.org/#/c/281084/1/deployment/puppet/ceph/manifests/nova_compute.pp >> > [1] https://news.ycombinator.com/item?id=11032296 >> > >> >> >> -- >> Best regards, >> Bogdan Dobrelya, >> Irc #bogdando >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev