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
