<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi,<br>
</p>
<br>
<div class="moz-cite-prefix">On 03/17/2017 07:27 AM, Fabien Boucher
wrote:<br>
</div>
<blockquote
cite="mid:CACzCTjOJ5Cb=k0h7pZB9YDhoh2p967Fsfv0=msaPTw-0F=-RBQ@mail.gmail.com"
type="cite">
<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>
</div>
</div>
</blockquote>
<br>
If we can avoid to rsync 90G of data, it's better.<br>
<br>
The copy/transfer part is not really complex, only 3 commands. I
will try to test the patch proposed to fix the transfer accept
command. If it's functionnal the workflow could be:<br>
<br>
* create a copy of the production volume<br>
* (transfer in another tenant if possible, optional)<br>
* Fix sec groups<br>
* create instance<br>
* stop all services<br>
* get the db backup from production<br>
* restore db<br>
* start the upgrade and validate<br>
<br>
With this workflow, we don't have to stop the production environment
(especially for db). I will try to validate this setup.<br>
<br>
Thanks for your comments<br>
<br>
Nico<br>
<blockquote
cite="mid:CACzCTjOJ5Cb=k0h7pZB9YDhoh2p967Fsfv0=msaPTw-0F=-RBQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Softwarefactory-dev@redhat.com"
target="_blank">Softwarefactory-dev@redhat.com</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Softwarefactory-dev@redhat.com">Softwarefactory-dev@redhat.com</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>