<div dir="ltr"><div>Hi,<br><br></div><div class="gmail_extra">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.<br><br clear="all"><div><div class="gmail_signature"><div dir="ltr">--<br>
Best regards,<br>
Sergii Golovatiuk,<br>
Skype #golserge<br>
IRC #holser<br></div></div></div>
<br><div class="gmail_quote">On Thu, Jul 16, 2015 at 8:07 AM, Matthew Mosesohn <span dir="ltr"><<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One item that will impact this separation is that fuel_upgrade<br>
implicitly depends on the openstack.yaml release file from<br>
fuel-nailgun. Without it, the upgrade process won't work. We should<br>
refactor fuel-nailgun to implement this functionality on its own, but<br>
then have fuel_upgrade call this piece. Right now, we're copying the<br>
openstack.yaml for the target version of Fuel and embedding it in the<br>
tarball[1].<br>
Instead, the version should be taken from the new version of<br>
fuel-nailgun that is installed inside the nailgun container.<br>
<br>
The other file which gets embedded in the upgrade tarball is the<br>
version.yaml file, but I think that's okay to embed during RPM build.<br>
<br>
[1]<a href="https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/openstack.py#L211-L213" rel="noreferrer" target="_blank">https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/openstack.py#L211-L213</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Jul 16, 2015 at 3:55 PM, Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com">ogelbukh@mirantis.com</a>> wrote:<br>
> Vladimir,<br>
><br>
> Good, thank you for extended answer.<br>
><br>
> --<br>
> Best regards,<br>
> Oleg Gelbukh<br>
><br>
> On Thu, Jul 16, 2015 at 3:30 PM, Vladimir Kozhukalov<br>
> <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
>><br>
>> Oleg,<br>
>><br>
>> Yes, you are right. At the moment all docker containers are packaged into<br>
>> a single rpm package. Yes, it would be great to split them into several<br>
>> one-by-one rpms, but it is not my current priority. I'll definitely think of<br>
>> this when I'll be moving so called "late" packages (which depend on other<br>
>> packages) into "perestroika". Yet another thing is that eventually all those<br>
>> packages and containers will be "artifacts" and will be treated differently<br>
>> according to their nature. That will be the time when we'll be thinking of a<br>
>> docker registry and other stuff like this.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Vladimir Kozhukalov<br>
>><br>
>> On Thu, Jul 16, 2015 at 2:58 PM, Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com">ogelbukh@mirantis.com</a>><br>
>> wrote:<br>
>>><br>
>>> Vladimir,<br>
>>><br>
>>> Thank you, now it sounds concieving.<br>
>>><br>
>>> My understanding that at the moment all Docker images used by Fuel are<br>
>>> packaged in single RPM? Do you plan to split individual images into separate<br>
>>> RPMs?<br>
>>><br>
>>> Did you think about publishing those images to Dockerhub?<br>
>>><br>
>>> --<br>
>>> Best regards,<br>
>>> Oleg Gelbukh<br>
>>><br>
>>> On Thu, Jul 16, 2015 at 1:50 PM, Vladimir Kozhukalov<br>
>>> <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
>>>><br>
>>>> Oleg,<br>
>>>><br>
>>>> All docker containers currently are distributed as rpm packages. A<br>
>>>> little bit surprising, isn't it? But it works and we can easily deliver<br>
>>>> updates using this old plain rpm based mechanism. The package in 6.1GA is<br>
>>>> called fuel-docker-images-6.1.0-1.x86_64.rpm So, upgrade flow would be like<br>
>>>> this<br>
>>>> 0) add new (say 7.0) repository into /etc/yum.repos.d/some.repo<br>
>>>> 1) install fuel-upgrade package (yum install fuel-upgrade-7.0)<br>
>>>> 2) fuel-upgrade package has all other packages (docker, bootstrap image,<br>
>>>> target images, puppet modules) as its dependencies<br>
>>>> 3) run fuel-upgrade script (say /usr/bin/fuel-upgrade) and it performs<br>
>>>> all necessary actions like moving files, run new containers, upload fixtures<br>
>>>> into nailgun via REST API.<br>
>>>><br>
>>>> It is necessary to note that we are talking here about Fuel master node<br>
>>>> upgrades, not about Openstack cluster upgrades (which is the feature you are<br>
>>>> working on).<br>
>>>><br>
>>>> Vladimir Kozhukalov<br>
>>>><br>
>>>> On Thu, Jul 16, 2015 at 1:22 PM, Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com">ogelbukh@mirantis.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Vladimir,<br>
>>>>><br>
>>>>> I am fully support moving fuel-upgrade-system into repository of its<br>
>>>>> own. However, I'm not 100% sure how docker containers are going to appear on<br>
>>>>> the upgraded master node. Do we have public repository of Docker images<br>
>>>>> already? Or we are going to build them from scratch during the upgrade?<br>
>>>>><br>
>>>>> --<br>
>>>>> Best regards,<br>
>>>>> Oleg Gelbukh<br>
>>>>><br>
>>>>> On Thu, Jul 16, 2015 at 11:46 AM, Vladimir Kozhukalov<br>
>>>>> <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
>>>>>><br>
>>>>>> By the way, first step for this to happen is to move<br>
>>>>>> stackforge/fuel-web/fuel_upgrade_system into a separate repository.<br>
>>>>>> Fortunately, this directory is not the place where the code is continuously<br>
>>>>>> changing (changes are rather seldom) and moving this project is going to<br>
>>>>>> barely affect the whole development flow. So, action flow is as follows<br>
>>>>>><br>
>>>>>> 0) patch to openstack-infra for creating new repository (workflow -1)<br>
>>>>>> 1) patch to Fuel CI to create verify jobs<br>
>>>>>> 2) freeze stackforge/fuel-web/fuel_upgrade_system directory<br>
>>>>>> 3) create upstream repository which is to be sucked in by openstack<br>
>>>>>> infra<br>
>>>>>> 4) patch to openstack-infra for creating new repository (workflow +1)<br>
>>>>>> 5) patch with rpm spec for fuel-upgrade package and other<br>
>>>>>> infrastructure files like run_tests.sh<br>
>>>>>> 6) patch to perestroika to build fuel-upgrade package from new repo<br>
>>>>>> 7) patch to fuel-main to remove upgrade tarball<br>
>>>>>> 8) patch to Fuel CI to remove upgrade tarball<br>
>>>>>> 9) patch to fuel-web to remove fuel_upgrade_system directory<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Vladimir Kozhukalov<br>
>>>>>><br>
>>>>>> On Thu, Jul 16, 2015 at 11:13 AM, Vladimir Kozhukalov<br>
>>>>>> <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>> Dear colleagues,<br>
>>>>>>><br>
>>>>>>> I'd like to suggest to get rid of Fuel upgrade tarball and convert<br>
>>>>>>> this thing into fuel-upgrade rpm package. Since we've switched to online<br>
>>>>>>> rpm/deb based upgrades, it seems we can stop packaging rpm/deb repositories<br>
>>>>>>> and docker containers into tarball and instead package upgrade python script<br>
>>>>>>> into rpm. It's gonna decrease the complexity of build process as well as<br>
>>>>>>> make it a little bit faster.<br>
>>>>>>><br>
>>>>>>> What do you think of this?<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Vladimir Kozhukalov<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> __________________________________________________________________________<br>
>>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>> Unsubscribe:<br>
>>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>