<div dir="ltr"><div>Hi, yes good idea to try that in the preprod tenant first.<br></div><div><br>Could also be a valid workflow to:<br></div><div>- deploy a SF (current deploy version)<br></div><div>- Fix sec groups<br></div><div>- Stop most of new deployed VM services<br></div><div>- rsync the / of the new deployed sf from the prod<br></div><div>- Start the upgrade and validate<br></div><div><br></div><div class="gmail_extra">This can avoid the complex part with the volume snapshot, transfert, ...<br><br></div><div class="gmail_extra">Fabien<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 17, 2017 at 10:27 AM, Matthieu Huin <span dir="ltr"><<a href="mailto:mhuin@redhat.com" target="_blank">mhuin@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>o/<br><br></div>If it is isolated I don't see a pb with that. You could probably test it out first on the sf-preprod tenant by applying the workflow to the preprod. This way you can observe any unforeseen consequences.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 9:32 PM, Nicolas Hicher <span dir="ltr"><<a href="mailto:nhicher@redhat.com" target="_blank">nhicher@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Just to give you a quick status about this story and propose a new workflow.<br>
<br>
<br>
My first idea was to do the following actions to spawn a clone <a href="http://sf-project.io" rel="noreferrer" target="_blank">sf-project.io</a> on a different tenant (pre_upgrade).<br>
<br>
* create the tenant with a security group rules with all egress rules deleted<br>
<br>
* add few security rules (dns, ssh, http and https)<br>
<br>
* create a snapshot from production instance<br>
<br>
* create a volume using the snapshot<br>
<br>
* create an image from the volume<br>
<br>
* upload the image in the pre_upgrade tenant<br>
<br>
* start the instance.<br>
<br>
<br>
But there is an issue with this workflow, you can't create an image from a volume where you have a description key in the volume_image_metadata and the most important, it will be very long to create a 160G image.<br>
<br>
<br>
I found another solution, you can use the openstack transfer command to transfer a volume to another tenant, The workflow is simple<br>
<br>
* in prod tenant:<br>
<br>
$ openstack volume create --source $volume_prod_id --size 160 <a href="http://sf-project.io" rel="noreferrer" target="_blank">sf-project.io</a><br>
<br>
$ openstack volume transfer request create $volume_prod_id<br>
<br>
+------------+----------------<wbr>----------------------+<br>
| Field      | Value                                |<br>
+------------+----------------<wbr>----------------------+<br>
| auth_key   | a8efe8019ecea159                     |<br>
| created_at | 2017-03-16T18:20:03.559539           |<br>
| id         | 9bb7b5a0-4456-4c34-834b-c598f8<wbr>f3b89c |<br>
| name       | None                                 |<br>
| volume_id  | 81d4a362-6f55-4aa9-a78b-899650<wbr>7fe7d5 |<br>
+------------+----------------<wbr>----------------------+<br>
<br>
* in pre_upgrade tenant<br>
<br>
$ openstack volume transfer accept $id $auth_key<br>
<br>
But there is a bug in accept transfer client command. A bugzilla was open in October (<a href="https://bugs.launchpad.net/python-openstackclient/+bug/1633582" rel="noreferrer" target="_blank">https://bugs.launchpad.net/py<wbr>thon-openstackclient/+bug/1633<wbr>582</a>), a review proposed few days ago (<a href="https://review.openstack.org/#/c/386770/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/386770/</a>).<br>
<br>
<br>
So, for me the easier solution will be:<br>
<br>
In SF_Prod tenant:<br>
<br>
* create a new network (sf_pre_upgrade_net) with a subnet.<br>
<br>
* create a new router (sf_pre_upgrade_router)<br>
<br>
* create a new security group (sf_pre_upgrade_rules: remove egress rules and add dns, ssh, http and https rules)<br>
<br>
* create a new volume from production<br>
<br>
* boot an instance within sf_pre_upgrade_net with sf_pre_upgrade_rules<br>
<br>
<br>
The instance will be isolated but on the same tenant than production, it's simple and should do the job.<br>
<br>
Are you ok with this workflow ? Do you think there are any issues ?<br>
<br>
Thanks.<br>
<br>
Nico<br>
<br>
______________________________<wbr>_________________<br>
Softwarefactory-dev mailing list<br>
<a href="mailto:Softwarefactory-dev@redhat.com" target="_blank">Softwarefactory-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/softwarefactory-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/softwarefactory-dev</a><br>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Softwarefactory-dev mailing list<br>
<a href="mailto:Softwarefactory-dev@redhat.com">Softwarefactory-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/softwarefactory-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/<wbr>softwarefactory-dev</a><br>
<br></blockquote></div><br></div></div>