Good morning, I created a debian (12) instance on openstack. But I don't know what the username and password are. Please help m Le ven. 4 oct. 2024 à 19:48, <openstack-discuss-request@lists.openstack.org> a écrit :
Send openstack-discuss mailing list submissions to openstack-discuss@lists.openstack.org
To subscribe or unsubscribe via email, send a message with subject or body 'help' to openstack-discuss-request@lists.openstack.org
You can reach the person managing the list at openstack-discuss-owner@lists.openstack.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..."
Today's Topics:
1. Re: [all][qa][infra] Restore unit tests for intermediate python versions (Takashi Kajinami) 2. Re: [all][qa][infra] Restore unit tests for intermediate python versions (Takashi Kajinami) 3. Re: [cinder] What is the "official" name for Cinder in the service catalog? (Ghanshyam Mann) 4. Re: [cinder] What is the "official" name for Cinder in the service catalog? (Takashi Kajinami)
----------------------------------------------------------------------
Message: 1 Date: Sat, 5 Oct 2024 02:26:59 +0900 From: Takashi Kajinami <kajinamit@oss.nttdata.com> Subject: Re: [all][qa][infra] Restore unit tests for intermediate python versions To: Clark Boylan <cboylan@sapwetik.org>, openstack-discuss@lists.openstack.org Message-ID: <9aec1a2b-0f30-4a47-879f-76ada4412057@oss.nttdata.com> Content-Type: text/plain; charset=UTF-8; format=flowed
On Fri, Oct 4, 2024, at 9:30 AM, Takashi Kajinami wrote:
Hello,
As you may know, current master runs unit tests with only Python 3.9 and Python 3.12. My understanding about this set up is that we test the minimum boundary and the maximum boundary and assume the change may work with all the versions between these two.
However in some of my recent work I had to introduce the switch in the middle of these two versions. For example https://review.opendev.org/c/openstack/neutron/+/931271 introduces the logic to distinguish Python < 3.10 from Python >= 3.10 , and we don't specifically test that boundary. I'm afraid that this may potentially cause uncaught problems.
One approach that wasn't discussed in the change is to continue to use
On 10/5/24 01:47, Clark Boylan wrote: the existing code (pkg_resources) until python3.12 then only change the behavior for 3.12. That approach would generally work if we are only testing the boundaries since we're flipping the behavior on the boundary.
For this case we need python 3.11 job to test the boundary. Also this leaves noisy deprecation warnings in < Python 3.11 .
So my question here is ... Can we test all supported python versions, not only min/max, at least in check jobs ? This would helps us catch any regressions caused by such implementation.
We can. The main limitation is that we may not have a test platform for
every version of python depending on how the distro releases align with python releases. Currently I think we have a platform for every release though (centos/rocky 3.9, jammy 3.10, bookworm 3.11, noble 3.12). If we end up without a platform for a version of python jobs may need to be updated to install python from source or some other method.
acknowledged
I know there could be tradeoffs between test coverage and infra resources, but IMO this is the test coverage we should fill.
Yes, the main concern was simply to avoid unnecessary effort. In the
case of unittest jobs the vast majority of those are much cheaper in terms of resources than tempest jobs. I think if we stuck to this primarily for unittests the impact would be minimal. If we tried to expand the tempest matrix that would become unwieldy.
Yes. I don't intend to run all tests in all versions but at least having unit test jobs, which are supposed to be cheap, may avoid 0 test coverage and would be enough now.
In case we find any real problems then we can expand the scope to other jobs.
Thank you,
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
------------------------------
Message: 2 Date: Sat, 5 Oct 2024 02:29:31 +0900 From: Takashi Kajinami <kajinamit@oss.nttdata.com> Subject: Re: [all][qa][infra] Restore unit tests for intermediate python versions To: Jeremy Stanley <fungi@yuggoth.org>, openstack-discuss@lists.openstack.org Message-ID: <6b5f06e2-1c2f-4e62-be6f-fb289922bb4d@oss.nttdata.com> Content-Type: text/plain; charset=UTF-8; format=flowed
On 10/5/24 02:16, Jeremy Stanley wrote:
On 2024-10-05 01:30:30 +0900 (+0900), Takashi Kajinami wrote: [...]
to distinguish Python < 3.10 from Python >= 3.10 [...]
This is a questionable choice of implementation, given some distros in the past have backported features to older releases or reverted removals they saw as regressions. When possible, it makes more sense to test for the existence/absence of the feature you want to use rather than blindly assuming the (C)Python version will serve as a faithful proxy. An up-side to this approach is that you don't need to worry as much about version boundaries, as long as you test versions both with and without the feature/behavior in question.
The super annoying thing with that change is that importlib.metadata.entry_point has been existing since python 3.8 but it changed the behavior in python 3.10 . So checking existance of modules/attributes didn't work and I avoided implementing hanky inspect check to analyze accepted arguments.
An alternative solution may be relying on importlib_metadata for all versions because it works for Python 3.12, but I was unsure if requiring unnecessary 3rd party dependency to make the code older version would be a good choice.
------------------------------
Message: 3 Date: Fri, 04 Oct 2024 10:38:36 -0700 From: Ghanshyam Mann <gmann@ghanshyammann.com> Subject: Re: [cinder] What is the "official" name for Cinder in the service catalog? To: "Artem Goncharov" <artem.goncharov@gmail.com> Cc: openstack-discuss <openstack-discuss@lists.openstack.org> Message-ID: <192589cb074.be2d62a51024073.7540045177503817038@ghanshyammann.com
Content-Type: text/plain; charset="UTF-8"
This procedure is followed in keystoneauth, openstacksdk, rust SDK/cli so no users should be affected unless they explicitly ignored official rules. ---- typed from mobile, auto-correct typos assumed ---- On Fri, Oct 4, 2024, 19:23 Artem Goncharov artem.goncharov@gmail.com> wrote: Official procedure is described at https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.h... You know the service that you want to talk to and there is a list of service types that the service supports. You follow the procedure to find
---- On Fri, 04 Oct 2024 10:26:33 -0700 Artem Goncharov wrote --- the one set by your cloud.
We have been trying to standardize the use of service catalog type for many years (I think ~7-8 years :) or maybe more), and if we still expect/support users to use them the wrong way, then there is no point in the whole effort on these guidelines. In the first step, we should fix our implementation in all the services/tools you mentioned. This is what devstack change is trying to impose.
-gmann
---- typed from mobile, auto-correct typos assumed ---- On Fri, Oct 4, 2024, 19:19 Takashi Kajinami kajinamit@oss.nttdata.com> wrote:
On 10/5/24 02:03, Artem Goncharov wrote:
On Fri, Oct 4, 2024, 18:56 Takashi Kajinami kajinamit@oss.nttdata.com
kajinamit@oss.nttdata.com>> wrote:
IMHO changing the default value now is not a good option here. If
we change the default value
in tempest, nova, glance (and so on, if exists) it means that
deployment would break during upgrade
unless users explicitly set these options to the legacy value or
update keystone endpoints to use
the new type. This sounds like a quite breaking change which makes upgrade of
real deployments difficult.
May I know if there is any clear downside of using 'volumev3' ?
To be honest based on the fact that
"volumev3" has been used as default and mentioned in docs for
very long time, I find it little valuable
while it has big use impact.
There should be no impact at all as long as keystoneauth lib is used
which implements service/version discovery.
If services hard coded service type of cinder without implementing discovery it is clearly a bug and must be fixed instead of sticking to keeping bugs forever what we do so often.
I'm not following this. Even if we use keystoneauth, we should know the service type to look up the correct endpoint from the list. Or are you saying that we can determine the endpoint for cinder without service_type field ?
There are number of implementations which hard-code volumev3 or use the volumev3 as default.
https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&excludeFiles=&repos=
examples:
https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard/...
https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/...
https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volume...
We may be need to make these at least configurable.
In addition to that a split between upgrade vs. new install should be
implemented (install docs should explicitly recommend proper usage while existing installations may stick to their current configuration). Moreover nothing prevents adding multiple values to the catalog and drop older ones once all consumers are updated to follow the discovery procedure.
I agree we can add multiple service types and endpoints for the same
concern is that not all users may be aware of the required steps to avoid inconsistency caused by such change of default behavior.
I can easily imagine that users upgrade their deployment and now their services require block-storage service type without noticing they should create that "new" service type.
On 10/5/24 01:50, Ghanshyam Mann wrote: > ---- On Fri, 04 Oct 2024 09:48:25 -0700 Ghanshyam Mann
wrote ---
> > ---- On Fri, 04 Oct 2024 09:12:13 -0700 Artem Goncharov
wrote ---
> > > Hey Stephen > > > > > > On Friday, 4 October 2024 15:15:08 GMT+2 Stephen
Finucane wrote:
> > > > o/ > > > > > > > > I've proposed a series of patches to "clean up" the
service catalog that
> > > > DevStack creates in a deployment. Currently, DevStack
creates two endpoints
> > > > for Cinder: one called 'cinderv3' of type 'volumev3'
and another called
> > > > 'cinder' of type 'block-storage'. For example: > > > > > > > > { > > > > "services": > > > > [ > > > > { > > > > "name": "cinderv3", > > > > "description": "Cinder Volume Service
V3",
> > > > "id":
"65460706a9864e71926f13042f526aeb",
> > > > "type": "volumev3", > > > > "enabled": true, > > > > "links": > > > > { > > > > "self": > > > > "
http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb>"
> > > > } > > > > }, > > > > { > > > > "name": "cinder", > > > > "description": "Cinder Volume
Service",
> > > > "id":
"cd406a0e296d47dca1e481e992851bb2",
> > > > "type": "block-storage", > > > > "enabled": true, > > > > "links": > > > > { > > > > "self": > > > > "
http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2>"
> > > > } > > > > }, > > > > // ... > > > > ], > > > > "links": > > > > { > > > > "next": null, > > > > "self": "
http://10.0.108.50/identity/v3/services http://10.0.108.50/identity/v3/services>",
> > > > "previous": null > > > > } > > > > } > > > > > > > > They both ultimately point to the same API, the
Cinder v3 API, meaning one
> > > > of these endpoints is redundant. My assumption was
'block-storage' was the
> > > > correct one, since that's the official service type
[1], and that 'cinder'
> > > > was the appropriate name since it mirrors what we use
for other services
> > > > (nova, neutron, keystone, glance, ...). However,
tkajinam raised the point
> > > > [2] that the Install Guide currently recommends use
of the 'volumev3' type
> > > > and that projects like Nova and Glance have an
'[cinder] catalog_info' that
> > > > defaults to 'volumev3'. If so, is 'block-storage'
really the official
> > > > service type, or is it 'volumev3'. If it is, should
we be changing the
> > > > Install Guide and the various config option defaults? > > > > > > > > > > Previously we had volumev2 and volumev3. Those are both
versioned aliases to
> > > the block-storage as the official service type name
(that is what structure of
> > > the service-types-authority claims). Now there is no
volumev2 and thus the
> > > confusion grows. > > > I suggest looking at the rendered json at [2] which
states:
> > > ``` > > > "cinder": { > > > "aliases": [ > > > "volumev3", > > > "volumev2", > > > "volume", > > > "block-store" > > > ], > > > "api_reference": "
https://docs.openstack.org/api-ref/block-storage/ https://docs.openstack.org/api-ref/block-storage/>",
> > > "project": "cinder", > > > "service_type": "block-storage" > > > }, > > > ``` > > > > > > Catalog consumption process is in detail described at
[3]. It is insanely
> > > complex and confusing but that is what all tools that
look at the service
> > > catalog do. > > > > > > Overall: > > > - official and unique service_type of the cinder is
block-storage
> > > - volumev3 is an alias pointing to explicit v3 api of
block-storage
> > > - there was an "idea" that once a service exposing
multiple API versions (and
> > > those are exposed independently with version-suffixed
service types) there is an
> > > unversioned one pointing to the "latest" version
(therefore typically you also
> > > find `volume` service pointing to the v3 > > > - technically install docs should stop suggesting
registering volumev3
> > > including project_id suffix. This is in detail
addressed by the service catalog
> > > consumption procedure and in addition blosk-storage v3
api has a series of
> > > APIs without project_id. Continuing appending
service. However my main project_id in the service
> > > catalog is heavily harmful. > > > - install docs may switch to registering
`block-storage` or `volume` instead
> > > of volumev3 and even stop pointing it to the v3 api
explicitly since version
> > > discovery is there to figure out all the aspects. > > > > With the API version changing and just to keep backward
compatibility of devstack
> > among tooling, we kept modifying the catalog name in this
way and ended up with more
> > confusion. > > > > I agree to make the cinder catalogue also consistent with
others and name them only
> > 'blosk-storage'. > > > > Tempest still uses 'volumev3' as the default cinder
service catalog, but that is something we
> > should change as first: > > > > -
https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8... https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8...
> > Just saw that you already proposed that. thanks ++ > > https://review.opendev.org/c/openstack/tempest/+/930296
https://review.opendev.org/c/openstack/tempest/+/930296>
> > -gmann > > > > > -gmann > > > > > > > > > > > [1]
------------------------------
Message: 4 Date: Sat, 5 Oct 2024 02:48:13 +0900 From: Takashi Kajinami <kajinamit@oss.nttdata.com> Subject: Re: [cinder] What is the "official" name for Cinder in the service catalog? To: Artem Goncharov <artem.goncharov@gmail.com> Cc: openstack-discuss <openstack-discuss@lists.openstack.org> Message-ID: <e3731ee2-6ffb-4827-b03e-a0008625a8b5@oss.nttdata.com> Content-Type: text/plain; charset=UTF-8; format=flowed
OK. Thanks for the explanation. I then probably misunderstood the impact of the change. It sounds like as long as we use appropriate SDK in a proper manner, we can look up the endpoint with official service type by legacy service type and vise versa, because of internal translation which I was not aware of.
If that is true, I agree the change has no impact unless something too hacky is made in services.
This procedure is followed in keystoneauth, openstacksdk, rust SDK/cli so no users should be affected unless they explicitly ignored official rules.
---- typed from mobile, auto-correct typos assumed ----
On Fri, Oct 4, 2024, 19:23 Artem Goncharov <artem.goncharov@gmail.com <mailto:artem.goncharov@gmail.com>> wrote:
Official procedure is described at https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.h... < https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.h...
You know the service that you want to talk to and there is a list of service types that the service supports. You follow the procedure to find
On 10/5/24 02:26, Artem Goncharov wrote: the one set by your cloud.
---- typed from mobile, auto-correct typos assumed ----
On Fri, Oct 4, 2024, 19:19 Takashi Kajinami <
kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>> wrote:
On 10/5/24 02:03, Artem Goncharov wrote: > > > > On Fri, Oct 4, 2024, 18:56 Takashi Kajinami <
kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com> <mailto: kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>>> wrote:
> > IMHO changing the default value now is not a good option
here. If we change the default value
> in tempest, nova, glance (and so on, if exists) it means
that deployment would break during upgrade
> unless users explicitly set these options to the legacy
value or update keystone endpoints to use
> the new type. > This sounds like a quite breaking change which makes
upgrade of real deployments difficult.
> > May I know if there is any clear downside of using
'volumev3' ? To be honest based on the fact that
> "volumev3" has been used as default and mentioned in docs
for very long time, I find it little valuable
> while it has big use impact. > > > > There should be no impact at all as long as keystoneauth lib
is used which implements service/version discovery.
> If services hard coded service type of cinder without
implementing discovery it is clearly a bug and must be fixed instead of sticking to keeping bugs forever what we do so often.
I'm not following this. Even if we use keystoneauth, we should
know the service type
to look up the correct endpoint from the list. Or are you saying
that we can determine
the endpoint for cinder without service_type field ?
There are number of implementations which hard-code volumev3 or
use the volumev3 as default.
https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&excludeFiles=&repos= < https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&excludeFiles=&repos=
examples:
https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard/... < https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard/...
https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/... < https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/...
https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volume... < https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volume...
We may be need to make these at least configurable.
> In addition to that a split between upgrade vs. new install
should be implemented (install docs should explicitly recommend proper usage while existing installations may stick to their current configuration). Moreover nothing prevents adding multiple values to the catalog and drop older ones once all consumers are updated to follow the discovery procedure.
I agree we can add multiple service types and endpoints for the
same service. However my main
concern is that not all users may be aware of the required steps
to avoid inconsistency caused by
such change of default behavior.
I can easily imagine that users upgrade their deployment and now
their services require block-storage
service type without noticing they should create that "new"
service type.
> > > > On 10/5/24 01:50, Ghanshyam Mann wrote: > > ---- On Fri, 04 Oct 2024 09:48:25 -0700 Ghanshyam
Mann wrote ---
> > > ---- On Fri, 04 Oct 2024 09:12:13 -0700 Artem
Goncharov wrote ---
> > > > Hey Stephen > > > > > > > > On Friday, 4 October 2024 15:15:08 GMT+2
Stephen Finucane wrote:
> > > > > o/ > > > > > > > > > > I've proposed a series of patches to "clean
up" the service catalog that
> > > > > DevStack creates in a deployment. Currently,
DevStack creates two endpoints
> > > > > for Cinder: one called 'cinderv3' of type
'volumev3' and another called
> > > > > 'cinder' of type 'block-storage'. For example: > > > > > > > > > > { > > > > > "services": > > > > > [ > > > > > { > > > > > "name": "cinderv3", > > > > > "description": "Cinder Volume
Service V3",
> > > > > "id":
"65460706a9864e71926f13042f526aeb",
> > > > > "type": "volumev3", > > > > > "enabled": true, > > > > > "links": > > > > > { > > > > > "self": > > > > > "
" > > > > > } > > > > > }, > > > > > { > > > > > "name": "cinder", > > > > > "description": "Cinder Volume Service", > > > > > "id": "cd406a0e296d47dca1e481e992851bb2", > > > > > "type": "block-storage", > > > > > "enabled": true, > > > > > "links": > > > > > { > > > > > "self": > > > > > " http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 < http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2> <http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 <http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 " > > > > > } > > > > > }, > > > > > // ... > > > > > ], > > > > > "links": > > > > > { > > > > > "next": null, > > > > > "self": " http://10.0.108.50/identity/v3/services < http://10.0.108.50/identity/v3/services> < http://10.0.108.50/identity/v3/services < http://10.0.108.50/identity/v3/services>>", > > > > > "previous": null > > > > > } > > > > > } > > > > > > > > > > They both ultimately point to the same API,
http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb < http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb> <http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb <http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb the Cinder v3 API, meaning one
> > > > > of these endpoints is redundant. My
assumption was 'block-storage' was the
> > > > > correct one, since that's the official
service type [1], and that 'cinder'
> > > > > was the appropriate name since it mirrors
what we use for other services
> > > > > (nova, neutron, keystone, glance, ...).
However, tkajinam raised the point
> > > > > [2] that the Install Guide currently
recommends use of the 'volumev3' type
> > > > > and that projects like Nova and Glance have
an '[cinder] catalog_info' that
> > > > > defaults to 'volumev3'. If so, is
'block-storage' really the official
> > > > > service type, or is it 'volumev3'. If it is,
should we be changing the
> > > > > Install Guide and the various config option
defaults?
> > > > > > > > > > > > > Previously we had volumev2 and volumev3. Those
are both versioned aliases to
> > > > the block-storage as the official service type
name (that is what structure of
> > > > the service-types-authority claims). Now there
is no volumev2 and thus the
> > > > confusion grows. > > > > I suggest looking at the rendered json at [2]
which states:
> > > > ``` > > > > "cinder": { > > > > "aliases": [ > > > > "volumev3", > > > > "volumev2", > > > > "volume", > > > > "block-store" > > > > ], > > > > "api_reference": "
https://docs.openstack.org/api-ref/block-storage/ < https://docs.openstack.org/api-ref/block-storage/> < https://docs.openstack.org/api-ref/block-storage/ < https://docs.openstack.org/api-ref/block-storage/>>",
> > > > "project": "cinder", > > > > "service_type": "block-storage" > > > > }, > > > > ``` > > > > > > > > Catalog consumption process is in detail
described at [3]. It is insanely
> > > > complex and confusing but that is what all
tools that look at the service
> > > > catalog do. > > > > > > > > Overall: > > > > - official and unique service_type of the
cinder is block-storage
> > > > - volumev3 is an alias pointing to explicit v3
api of block-storage
> > > > - there was an "idea" that once a service
exposing multiple API versions (and
> > > > those are exposed independently with
version-suffixed service types) there is an
> > > > unversioned one pointing to the "latest"
version (therefore typically you also
> > > > find `volume` service pointing to the v3 > > > > - technically install docs should stop
suggesting registering volumev3
> > > > including project_id suffix. This is in detail
addressed by the service catalog
> > > > consumption procedure and in addition
blosk-storage v3 api has a series of
> > > > APIs without project_id. Continuing appending
project_id in the service
> > > > catalog is heavily harmful. > > > > - install docs may switch to registering
`block-storage` or `volume` instead
> > > > of volumev3 and even stop pointing it to the v3
api explicitly since version
> > > > discovery is there to figure out all the
aspects.
> > > > > > With the API version changing and just to keep
backward compatibility of devstack
> > > among tooling, we kept modifying the catalog name
in this way and ended up with more
> > > confusion. > > > > > > I agree to make the cinder catalogue also
consistent with others and name them only
> > > 'blosk-storage'. > > > > > > Tempest still uses 'volumev3' as the default
cinder service catalog, but that is something we
> > > should change as first: > > > > > > -
https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8... < https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8cffe39/tempest/config.py#L981> < https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8... < https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8...
> > > > Just saw that you already proposed that. thanks ++ > > > > https://review.opendev.org/c/openstack/tempest/+/930296 < https://review.opendev.org/c/openstack/tempest/+/930296> < https://review.opendev.org/c/openstack/tempest/+/930296 < https://review.opendev.org/c/openstack/tempest/+/930296>> > > > > -gmann > > > > > > > > -gmann > > > > > > > > > > > > > > [1] >
------------------------------
Subject: Digest Footer
_______________________________________________ openstack-discuss mailing list -- openstack-discuss@lists.openstack.org To unsubscribe send an email to openstack-discuss-leave@lists.openstack.org
------------------------------
End of openstack-discuss Digest, Vol 72, Issue 23 *************************************************