Open Stack

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
>