Hi,
On 03/17/2017 07:27 AM, Fabien Boucher wrote:
Hi, yes good idea to try that in the preprod tenant first.
Could also be a valid workflow to:
- deploy a SF (current deploy version)
- Fix sec groups
- Stop most of new deployed VM services
- rsync the / of the new deployed sf from the prod
- Start the upgrade and validate
This can avoid the complex part with the volume snapshot, transfert, ...
If we can avoid to rsync 90G of data, it's better.
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:
* create a copy of the production volume
* (transfer in another tenant if possible, optional)
* Fix sec groups
* create instance
* stop all services
* get the db backup from production
* restore db
* start the upgrade and validate
With this workflow, we don't have to stop the production environment
(especially for db). I will try to validate this setup.
Thanks for your comments
Nico
Fabien
On Fri, Mar 17, 2017 at 10:27 AM, Matthieu Huin <[email protected]
<mailto:[email protected]>> wrote:
o/
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.
On Thu, Mar 16, 2017 at 9:32 PM, Nicolas Hicher
<[email protected] <mailto:[email protected]>> wrote:
Hello,
Just to give you a quick status about this story and propose a
new workflow.
My first idea was to do the following actions to spawn a clone
sf-project.io <http://sf-project.io> on a different tenant
(pre_upgrade).
* create the tenant with a security group rules with all
egress rules deleted
* add few security rules (dns, ssh, http and https)
* create a snapshot from production instance
* create a volume using the snapshot
* create an image from the volume
* upload the image in the pre_upgrade tenant
* start the instance.
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.
I found another solution, you can use the openstack transfer
command to transfer a volume to another tenant, The workflow
is simple
* in prod tenant:
$ openstack volume create --source $volume_prod_id --size 160
sf-project.io <http://sf-project.io>
$ openstack volume transfer request create $volume_prod_id
+------------+--------------------------------------+
| Field | Value |
+------------+--------------------------------------+
| auth_key | a8efe8019ecea159 |
| created_at | 2017-03-16T18:20:03.559539 |
| id | 9bb7b5a0-4456-4c34-834b-c598f8f3b89c |
| name | None |
| volume_id | 81d4a362-6f55-4aa9-a78b-8996507fe7d5 |
+------------+--------------------------------------+
* in pre_upgrade tenant
$ openstack volume transfer accept $id $auth_key
But there is a bug in accept transfer client command. A
bugzilla was open in October
(https://bugs.launchpad.net/python-openstackclient/+bug/1633582
<https://bugs.launchpad.net/python-openstackclient/+bug/1633582>),
a review proposed few days ago
(https://review.openstack.org/#/c/386770/
<https://review.openstack.org/#/c/386770/>).
So, for me the easier solution will be:
In SF_Prod tenant:
* create a new network (sf_pre_upgrade_net) with a subnet.
* create a new router (sf_pre_upgrade_router)
* create a new security group (sf_pre_upgrade_rules: remove
egress rules and add dns, ssh, http and https rules)
* create a new volume from production
* boot an instance within sf_pre_upgrade_net with
sf_pre_upgrade_rules
The instance will be isolated but on the same tenant than
production, it's simple and should do the job.
Are you ok with this workflow ? Do you think there are any
issues ?
Thanks.
Nico
_______________________________________________
Softwarefactory-dev mailing list
[email protected]
<mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/softwarefactory-dev
<https://www.redhat.com/mailman/listinfo/softwarefactory-dev>
_______________________________________________
Softwarefactory-dev mailing list
[email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/softwarefactory-dev
<https://www.redhat.com/mailman/listinfo/softwarefactory-dev>
_______________________________________________
Softwarefactory-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/softwarefactory-dev
