Hi, Let's put openstack.yaml to package if it requires for master node upgrade. Environment update part should be removed as it never reached production state.
-- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jul 16, 2015 at 8:07 AM, Matthew Mosesohn <mmoses...@mirantis.com> wrote: > 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 >
__________________________________________________________________________ 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
