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, ... Fabien On Fri, Mar 17, 2017 at 10:27 AM, Matthieu Huin <[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]> > 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/1633 >> 582), 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 > >
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
