One item that will impact this separation is that fuel_upgrade implicitly depends on the openstack.yaml release file from fuel-nailgun. Without it, the upgrade process won't work. We should refactor fuel-nailgun to implement this functionality on its own, but then have fuel_upgrade call this piece. Right now, we're copying the openstack.yaml for the target version of Fuel and embedding it in the tarball[1]. Instead, the version should be taken from the new version of fuel-nailgun that is installed inside the nailgun container.
The other file which gets embedded in the upgrade tarball is the version.yaml file, but I think that's okay to embed during RPM build. [1]https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/openstack.py#L211-L213 On Thu, Jul 16, 2015 at 3:55 PM, Oleg Gelbukh <ogelb...@mirantis.com> wrote: > Vladimir, > > Good, thank you for extended answer. > > -- > Best regards, > Oleg Gelbukh > > On Thu, Jul 16, 2015 at 3:30 PM, Vladimir Kozhukalov > <vkozhuka...@mirantis.com> wrote: >> >> Oleg, >> >> Yes, you are right. At the moment all docker containers are packaged into >> a single rpm package. Yes, it would be great to split them into several >> one-by-one rpms, but it is not my current priority. I'll definitely think of >> this when I'll be moving so called "late" packages (which depend on other >> packages) into "perestroika". Yet another thing is that eventually all those >> packages and containers will be "artifacts" and will be treated differently >> according to their nature. That will be the time when we'll be thinking of a >> docker registry and other stuff like this. >> >> >> >> >> >> >> Vladimir Kozhukalov >> >> On Thu, Jul 16, 2015 at 2:58 PM, Oleg Gelbukh <ogelb...@mirantis.com> >> wrote: >>> >>> Vladimir, >>> >>> Thank you, now it sounds concieving. >>> >>> My understanding that at the moment all Docker images used by Fuel are >>> packaged in single RPM? Do you plan to split individual images into separate >>> RPMs? >>> >>> Did you think about publishing those images to Dockerhub? >>> >>> -- >>> Best regards, >>> Oleg Gelbukh >>> >>> On Thu, Jul 16, 2015 at 1:50 PM, Vladimir Kozhukalov >>> <vkozhuka...@mirantis.com> wrote: >>>> >>>> Oleg, >>>> >>>> All docker containers currently are distributed as rpm packages. A >>>> little bit surprising, isn't it? But it works and we can easily deliver >>>> updates using this old plain rpm based mechanism. The package in 6.1GA is >>>> called fuel-docker-images-6.1.0-1.x86_64.rpm So, upgrade flow would be like >>>> this >>>> 0) add new (say 7.0) repository into /etc/yum.repos.d/some.repo >>>> 1) install fuel-upgrade package (yum install fuel-upgrade-7.0) >>>> 2) fuel-upgrade package has all other packages (docker, bootstrap image, >>>> target images, puppet modules) as its dependencies >>>> 3) run fuel-upgrade script (say /usr/bin/fuel-upgrade) and it performs >>>> all necessary actions like moving files, run new containers, upload >>>> fixtures >>>> into nailgun via REST API. >>>> >>>> It is necessary to note that we are talking here about Fuel master node >>>> upgrades, not about Openstack cluster upgrades (which is the feature you >>>> are >>>> working on). >>>> >>>> Vladimir Kozhukalov >>>> >>>> On Thu, Jul 16, 2015 at 1:22 PM, Oleg Gelbukh <ogelb...@mirantis.com> >>>> wrote: >>>>> >>>>> Vladimir, >>>>> >>>>> I am fully support moving fuel-upgrade-system into repository of its >>>>> own. However, I'm not 100% sure how docker containers are going to appear >>>>> on >>>>> the upgraded master node. Do we have public repository of Docker images >>>>> already? Or we are going to build them from scratch during the upgrade? >>>>> >>>>> -- >>>>> Best regards, >>>>> Oleg Gelbukh >>>>> >>>>> On Thu, Jul 16, 2015 at 11:46 AM, Vladimir Kozhukalov >>>>> <vkozhuka...@mirantis.com> wrote: >>>>>> >>>>>> By the way, first step for this to happen is to move >>>>>> stackforge/fuel-web/fuel_upgrade_system into a separate repository. >>>>>> Fortunately, this directory is not the place where the code is >>>>>> continuously >>>>>> changing (changes are rather seldom) and moving this project is going to >>>>>> barely affect the whole development flow. So, action flow is as follows >>>>>> >>>>>> 0) patch to openstack-infra for creating new repository (workflow -1) >>>>>> 1) patch to Fuel CI to create verify jobs >>>>>> 2) freeze stackforge/fuel-web/fuel_upgrade_system directory >>>>>> 3) create upstream repository which is to be sucked in by openstack >>>>>> infra >>>>>> 4) patch to openstack-infra for creating new repository (workflow +1) >>>>>> 5) patch with rpm spec for fuel-upgrade package and other >>>>>> infrastructure files like run_tests.sh >>>>>> 6) patch to perestroika to build fuel-upgrade package from new repo >>>>>> 7) patch to fuel-main to remove upgrade tarball >>>>>> 8) patch to Fuel CI to remove upgrade tarball >>>>>> 9) patch to fuel-web to remove fuel_upgrade_system directory >>>>>> >>>>>> >>>>>> >>>>>> Vladimir Kozhukalov >>>>>> >>>>>> On Thu, Jul 16, 2015 at 11:13 AM, Vladimir Kozhukalov >>>>>> <vkozhuka...@mirantis.com> wrote: >>>>>>> >>>>>>> Dear colleagues, >>>>>>> >>>>>>> I'd like to suggest to get rid of Fuel upgrade tarball and convert >>>>>>> this thing into fuel-upgrade rpm package. Since we've switched to online >>>>>>> rpm/deb based upgrades, it seems we can stop packaging rpm/deb >>>>>>> repositories >>>>>>> and docker containers into tarball and instead package upgrade python >>>>>>> script >>>>>>> into rpm. It's gonna decrease the complexity of build process as well as >>>>>>> make it a little bit faster. >>>>>>> >>>>>>> What do you think of this? >>>>>>> >>>>>>> >>>>>>> Vladimir Kozhukalov >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> __________________________________________________________________________ >>>>>> 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 >>>> >>> >>> >>> >>> __________________________________________________________________________ >>> 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 > __________________________________________________________________________ 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
