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]> 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 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 > > $ 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), > a review proposed few days ago (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] > https://www.redhat.com/mailman/listinfo/softwarefactory-dev >
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
