Hi, The Octane team has some issues with lacking definition of what the 'release' is in Fuel (in terms of managed environments). I started an etherpad [1] to summarize the entities/artifacts that consistute a 'release' at the moment. Based on this definition, we can localize and define entry points where the actual 'release'-specific code could be separated from universal frameworks in Nailgun and other component of Fuel. Thus, we could better manage different releases with a single version of Nailgun code, which is essential for the upgrade workflow.
I agree with Alex on that at least a part of the composition layer is bound to be 'release'-specific, especially the puppet modules that deploy OpenStack and other managed components. On the other hand, certain parts of the fuel-library have nothing to do with the managed 'release', and concern the Fuel Admin node itself. It would be useful to make separation along those lines as well. [1] https://etherpad.openstack.org/p/fuel-release-definition -- Best regards, Oleg Gelbukh On Thu, Feb 11, 2016 at 12:02 PM, Aleksandr Didenko <adide...@mirantis.com> wrote: > Hi, > > > So what is open? The composition layer. > > We can have different composition layers for every release and it's > already implemented in releases - separate puppet modules/manifests dir for > every release. > > > Currently, we just abandon support for previous versions in the > composition layer and leave them to only be monuments in the > stable/<release> series branches for maintenance. If we instead started > making changes (forwards or backwards that) change the calls based on the > openstack version [5] then we would be able to change the calls based on > then needs of that release, and the puppet-openstack modules we are working > with. > > 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? > > > Testing master while keeping stable. Given the ability to conditional > what source of openstack bits, which versions of manifests we can start > testing both master and keep health on stable. This would help accelerate > both fuel development and deploying and testing development versions of > openstack > > I'm sorry, but I don't see how we can accelerate things by making > composition layer more and more complicated. If we're going to run CI and > swarm for all of the supported releases on the ISO, that would rather > decrease speed of development and testing drastically. Also aren't we > "testing both master and keep health on stable" right now by running tests > for master and stable versions of Fuel? > > > Deploying stable and upgrading later. Again given the ability to deploy > multiple OpenStack versions within the same Fuel version, teams focused on > upgrades can take advantage of the latest enhancements in fuel to work the > upgrade process more easily, as an added benefit this would eventually lead > to better support for end user upgrades too. > > Using the same composition layers is not required for this. Also how it > differs from using the current upgrade procedure? When you have, for > instance, 7.0 release and then upgrade to 8.0, so basically result is the > same - you have two releases in Fuel, 2 directories with manifests, 2 repos > with packages. > > > Deploying older versions, in the odd case that we need to take advantage > of older OpenStack releases like in the case of Kilo with a newer version > of Fuel we can easily maintain that version too as we can keep the older > cases around in the composition layer with out adding much burden on the > other components. > > Using the same composition layers is not required for this, "we can keep > the older cases around" in the composition layer of previous version. > > Also, how many releases we're going to support? All of them starting from > Kilo? What about ISO size? What about CI, infra (required HW), acceptance > testing, etc impact? > > Regards, > Alex > > > > On Thu, Feb 11, 2016 at 6:57 AM, Andrew Woodward <xar...@gmail.com> wrote: > >> Right now master (targeting 9.0) is still deploying liberty and there is >> active work going on to support both Kilo and Mitaka. On the review queue >> are changes that would make fuel-library in-compatible with the prior >> (liberty) openstack release. However I think if we extend a little bit of >> effort we can keep some semblance of "support" while creating a pattern for >> the Kilo support to continue to use. At the same time this pattern can help >> us test parallel versions as we move through openstack releases and should >> reduce occurrences of our CI freeze/merge parties >> >> What is this magic pattern? Well its already present, and all be it not >> designed for this I think we could quickly make it work. We use the release >> fixture already present in fuel. Originally designed to work for upgrades, >> we could reuse this within the same fuel release to control various aspects >> needed to deploy a separate openstack version. >> >> What we need to support multiple OpenStack versions: >> 1) Packge repo's that contain the relevant bits. CHECK, this can be >> toggled with a new release [1][2] >> 2) can point to different Puppet modules CHECK, also in toggled release >> [3] >> 3) Composition layer that supports calls to different puppet-openstack >> modules, WIP, it still needs work, but can be done [4] >> >> So what is open? The composition layer. >> >> Currently, we just abandon support for previous versions in the >> composition layer and leave them to only be monuments in the >> stable/<release> series branches for maintenance. If we instead started >> making changes (forwards or backwards that) change the calls based on the >> openstack version [5] then we would be able to change the calls based on >> then needs of that release, and the puppet-openstack modules we are working >> with. >> >> Given that we most of the time we would be supporting the previous >> release (liberty) (which we should avoid dropping until after dev releases) >> and the currently under development release (Mitaka), this will give us >> some magical powers. >> >> Testing master while keeping stable. Given the ability to conditional >> what source of openstack bits, which versions of manifests we can start >> testing both master and keep health on stable. This would help accelerate >> both fuel development and deploying and testing development versions of >> openstack >> >> Deploying stable and upgrading later. Again given the ability to deploy >> multiple OpenStack versions within the same Fuel version, teams focused on >> upgrades can take advantage of the latest enhancements in fuel to work the >> upgrade process more easily, as an added benefit this would eventually lead >> to better support for end user upgrades too. >> >> Deploying older versions, in the odd case that we need to take advantage >> of older OpenStack releases like in the case of Kilo with a newer version >> of Fuel we can easily maintain that version too as we can keep the older >> cases around in the composition layer with out adding much burden on the >> other components. >> >> [1] >> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1957 >> [2] >> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1906 >> >> [3] >> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1371 >> >> [4] https://github.com/xarses/fuel-library/tree/9-Kilo >> >> [5] >> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1948 >> >> -- >> >> -- >> >> Andrew Woodward >> >> Mirantis >> >> Fuel Community Ambassador >> >> Ceph Community >> >> __________________________________________________________________________ >> 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
