[openstack-dev] [Fuel] Getting rid of upgrade tarball
Sergii Golovatiuk
sgolovatiuk at mirantis.com
Thu Jul 16 21:03:19 UTC 2015
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 <mmosesohn at 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 <ogelbukh at 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
> > <vkozhukalov at 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 <ogelbukh at 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
> >>> <vkozhukalov at 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 <ogelbukh at 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
> >>>>> <vkozhukalov at 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
> >>>>>> <vkozhukalov at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150716/f04850dd/attachment.html>
More information about the OpenStack-dev
mailing list