Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball
Matt, Thanks for noting this. My understanding of the problem is that we should put openstack.yaml into a separate package build from fuel-web repository. When a user installs fuel-upgrade package it requires openstack.yaml package of necessary version to be also installed. Another idea here is that we don't need this upgrade script at all. Our docker containers are stateless, so the upgrade flow is going to be significantly simpler in 7.0. But still we have quite a few things like create links, move files, backup database, etc. which makes this idea a little bit premature. Maybe a little bit later. Ok, let's stop merging any code into fuel-web/fuel_upgrade_system/fuel_upgrade since now. All patches, which are not merged yet (I doubt we have any) should be ported to the new repository which is going to be created once this patch [1] is merged. [1] https://review.openstack.org/#/c/202541/ Vladimir Kozhukalov On Fri, Jul 17, 2015 at 12:03 AM, Sergii Golovatiuk < sgolovat...@mirantis.com> wrote: > 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 > 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 >> wrote: >> > Vladimir, >> > >> > Good, thank you for extended answer. >> > >> > -- >> > Best regards, >> > Oleg Gelbukh >> > >> > On Thu, Jul 16, 2015 at 3:30 PM, Vladimir Kozhukalov >> > 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 >> >> 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 >> >>> 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 > > >> wrote: >> > >> > Vladimir, >> > >> > I am fully support moving fuel-upgrade-system into repository of its >> > own.
Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball
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 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 > wrote: > > Vladimir, > > > > Good, thank you for extended answer. > > > > -- > > Best regards, > > Oleg Gelbukh > > > > On Thu, Jul 16, 2015 at 3:30 PM, Vladimir Kozhukalov > > 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 > >> 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 > >>> 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 > 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 > > 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 (
Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball
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 wrote: > Vladimir, > > Good, thank you for extended answer. > > -- > Best regards, > Oleg Gelbukh > > On Thu, Jul 16, 2015 at 3:30 PM, Vladimir Kozhukalov > 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 >> 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 >>> 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 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 > 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 >> wrote: >>> >>> Dear collea
Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball
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 > 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 >>> 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 > >
Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball
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 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 >> 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 >>> >>> >> >> _
Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball
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 > 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
Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball
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 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
Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball
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
Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball
Hi, Vladimir, I like the initiative, just to add some steps: 10) patch to fuel-qa/ and jenkins jobs to change the workflow of upgrades tests, 11) clarification on how upgrade should be tested (against which repositories and ISO images), how update of upgrade rpm should be tested 12) documentation fixes on how upgrade should be performed, 13) patch to HCF and release checklists to change publishing process. I see the 11) as the most unclear here, so please include it in your considerations with high priority. Let's involve QA team from the very beginning. On Thu, Jul 16, 2015 at 11:46 AM, Vladimir Kozhukalov 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 > 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 > -- Aleksandra Fedorova Fuel CI Engineer bookwar __ 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
Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball
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-dev] [Fuel] Getting rid of upgrade tarball
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
