Re: [openstack-dev] [QA] [openstack-qa] [tempest] UUIDs and names in tempest.conf file
-Original Message- From: ext Matthew Treinish [mailto:mtrein...@kortar.org] Sent: Tuesday, June 16, 2015 4:49 PM To: openstack-dev@lists.openstack.org; All Things QA. Subject: Re: [openstack-qa] [QA] [tempest] UUIDs and names in tempest.conf file So I need to point out that the openstack-qa list isn't used anymore. We only keep it around so we have a place to send for periodic test results. In the future you should just send things to the openstack-dev ML with a [QA] tag in the subject. On Tue, Jun 16, 2015 at 05:25:30AM +, Tikkanen, Viktor (Nokia - FI/Espoo) wrote: Hi! I have a question regarding usage of UUIDs and names in the tempest.conf file. Are there some common ideas/reasons (except unambiguousness and making test cases simpler) why some parameters (e.g. public_network_id, flavor_ref, image_ref, ...) are designed so that they require entity UUIDs but others (e.g. fixed_network_name, floating_network_name, ...) require entity names? So this is mostly a historical artifact from before I even started working on the project, my guess is this was done because not all resources require unique names, but that's just my guess. Config options to tell tempest resources to use which were added more recently use a name because it's hard for people to deal with uuids. That being said there is a spec still under review to rationalize how we specify resources in tempest to make things a bit simpler and more consistent: https://review.openstack.org/173334 Once the details are ironed out in the spec review and implementation begins we'll deprecate most of the existing options in favor of the new format for specifying resources. There were no activities with this spec since middle of April but anyway thank you for the clarification. Currently there seems to be a number of functions like get_network_from_name (/opt/tempest/tempest/common/fixed_network.py) for UUID/name conversion available but as you said there is a need for more consistent test resource management... -VT __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA] [openstack-qa] [tempest] UUIDs and names in tempest.conf file
So I need to point out that the openstack-qa list isn't used anymore. We only keep it around so we have a place to send for periodic test results. In the future you should just send things to the openstack-dev ML with a [QA] tag in the subject. On Tue, Jun 16, 2015 at 05:25:30AM +, Tikkanen, Viktor (Nokia - FI/Espoo) wrote: Hi! I have a question regarding usage of UUIDs and names in the tempest.conf file. Are there some common ideas/reasons (except unambiguousness and making test cases simpler) why some parameters (e.g. public_network_id, flavor_ref, image_ref, ...) are designed so that they require entity UUIDs but others (e.g. fixed_network_name, floating_network_name, ...) require entity names? So this is mostly a historical artifact from before I even started working on the project, my guess is this was done because not all resources require unique names, but that's just my guess. Config options to tell tempest resources to use which were added more recently use a name because it's hard for people to deal with uuids. That being said there is a spec still under review to rationalize how we specify resources in tempest to make things a bit simpler and more consistent: https://review.openstack.org/173334 Once the details are ironed out in the spec review and implementation begins we'll deprecate most of the existing options in favor of the new format for specifying resources. Currently I use shell scripts for creating images and flavors with some predefined ID (like 01010101-0101-0101-0101-010101010101) just to avoid updating of the related parameters into configuration file every time when some new environment is taken into use. The problem here is that e.g. image ID cannot be reused after deleting the image (unless the data is removed directly from database) and flavors cannot be updated without changing their ID. So there are several scripts out there to do something similar (make a couple images and flavors to use for testing) to do some of those common setup steps. There used to be an in-tree bash script in tempest to do the same thing too. It was removed because it was basically unmaintained and had bit-rotted to the point it didn't really work. There is a patch up for review right now to provide a new in-tree tool for automating some of these initial configuration steps here: https://review.openstack.org/#/c/133245/ -Matt Treinish signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
