Re: [openstack-dev] nova-api fails to start
screen -x stack should give you the clue as to why it's failing. In my
case it printed
2013-11-07 23:24:14.758 TRACE nova IOError: [Errno 13] Permission denied:
'/etc/nova/api-paste.ini'
2013-11-07 23:24:14.758 TRACE nova
n-api failed to start
all i had to do was change the ownership of the files to the user executing
stack.sh and restart the process.
On Fri, Nov 8, 2013 at 4:49 PM, Telles Nobrega tellesnobr...@gmail.comwrote:
I thought it worked but it actually didn't. I'm trying again
On Thu, Nov 7, 2013 at 10:19 PM, Telles Nobrega
tellesnobr...@gmail.comwrote:
It was a new installation, but i tried a couple more times, removed all
the component folders and it worked
--
___
Telles Mota Vidal Nóbrega
Undergraduated in Computer Science at Federal University of Campina
Grande (UFCG)
Developer at PulsarOpenStack Project - HP
On 07 Nov 2013, at 17:54, Krishanu Dhar rony.k...@gmail.com wrote:
Hey Telies - Were you trying to recreate the failure? or is it a new
installation?
On Fri, Nov 8, 2013 at 2:13 AM, Telles Nobrega
tellesnobr...@gmail.comwrote:
Now i have something like your problem, im getting
die 609 'nova-api did not start'
On Thu, Nov 7, 2013 at 4:11 PM, Krishanu Dhar rony.k...@gmail.comwrote:
thanks man, incidentally i ran into your post too and it got me going.
However, I was wondering if the fix should go in stack.sh.stack.sh
On Fri, Nov 8, 2013 at 12:32 AM, Cazzolato, Sergio J
sergio.j.cazzol...@intel.com wrote:
Hi, I had the same issue and fixed that doing a chwon and changing
the ownership to my user of the files in /etc/nova where the owner was the
user nova.
In my case the files were: api-paste.ini and policy.json
I posted the solution there too:
http://stackoverflow.com/questions/19843239/getting-nova628die-trying-to-start-openstack-nova-module
Thanks
*From:* Krishanu Dhar [mailto:rony.k...@gmail.com]
*Sent:* Thursday, November 07, 2013 3:40 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] nova-api fails to start
Any other recommendations on how to have a successful devstack
installation?
On Thu, Nov 7, 2013 at 11:37 PM, Krishanu Dhar rony.k...@gmail.com
wrote:
below is an error that's probably the cause...
2013-11-07 23:24:14.758 TRACE nova IOError: [Errno 13] Permission
denied: '/etc/nova/api-paste.ini'
2013-11-07 23:24:14.758 TRACE nova
n-api failed to start
krish@krish-VirtualBox:/opt/stack/nova$ ls -l /etc/nova/api-paste.ini
-rw--- 1 nova nova 4260 Apr 23 2013 /etc/nova/api-paste.ini
isn't it expected to fail if the file is owned by nova... weird.
On Thu, Nov 7, 2013 at 11:18 PM, Krishanu Dhar rony.k...@gmail.com
wrote:
it did not even start the process in my case.
I tried looking up email threads in google and looks like quite a few
have run into this before, but couldn't find a working fix.
On Thu, Nov 7, 2013 at 11:15 PM, Telles Nobrega
tellesnobr...@gmail.com wrote:
Weird, i had the same problem, but when i kill the processes it works
On Thu, Nov 7, 2013 at 2:34 PM, Krishanu Dhar rony.k...@gmail.com
wrote:
Nothing was left behind.
#ps aux|grep -ie nova did not return anything.
On Thu, Nov 7, 2013 at 11:01 PM, Telles Nobrega
tellesnobr...@gmail.com wrote:
Did you check if there are any nova process left running?
On Thu, Nov 7, 2013 at 2:28 PM, Krishanu Dhar rony.k...@gmail.com
wrote:
Appreciate the responses. But there is something wrong with this. I
ran unstack.sh again and retried the installation. it failed with the same
message.
So, what are my options right now?
On Thu, Nov 7, 2013 at 7:31 PM, Telles Nobrega
tellesnobr...@gmail.com wrote:
Sometimes after ./unstack is ran, some process are still runnning for
nova.
Try running this to kill them all (ps aux | grep -ie nova | awk
'{print $2}' | xargs kill -9) and try ./stack again
On Thu, Nov 7, 2013 at 9:14 AM, Noorul Islam K M noo...@noorul.com
wrote:
Krishanu Dhar rony.k...@gmail.com writes:
Hi,
I was trying to install the devstack and it failed while starting
the nova
api. below is a snippet from the console. Is it a bug?
+ screen -S stack -p n-api -X stuff 'cd /opt/stack/nova
/usr/local/bin/nova-a'i || echo n-api failed to start | tee
/opt/stack/status/stack/n-api.failure
+ echo 'Waiting for nova-api to start...'
Waiting for nova-api to start...
+ wait_for_service 60 http://10.0.2.15:8774
+ local timeout=60
+ local url=http://10.0.2.15:8774
+ timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -s
http://10.0.2.15:8774 /dev/null; do sleep 1; done'
+ die 628 'nova-api did not start'
+ local exitcode=0
+ set +o xtrace
[Call Trace]
./stack.sh:1084:start_nova_api
/home/krish/devstack/lib/nova:628:die
[ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start
krish@krish-VirtualBox:~/devstack$
Did you try screen -x stack ?
Re: [openstack-dev] RFC: reverse the default Gerrit sort order
On Friday, November 8, 2013, Joe Gordon wrote:
On Thu, Nov 7, 2013 at 7:36 AM, Robert Collins
robe...@robertcollins.netjavascript:_e({}, 'cvml',
'robe...@robertcollins.net');
wrote:
I've been thinking about review queues recently (since here at the
summit everyone is talking about reviews! :)).
One thing that struck me today was that Gerrit makes it easier to
review the newest changes first, rather than the changes that have
been in the queue longest, or the changes that started going through
the review process first.
So... is it possible to change the default sort order for Gerrit? How
hard is it to do - could we do an experiment on that and see if it
nudges the dial for reviewstats (just make the change, not ask anyone
to change their behaviour)?
As for what sort order to choose, I'd be happy just getting data on a
different default sort order - it seems like the easiest thing would
be to reverse the current order, vs doing something more
sophisticated.
++, This sounds like an interesting idea. and we could try it out for a
few weeks to see what happen.
I agree this would be interesting but if it isn't configurable (e.g. A
mechanism to support current behavior) I think this would very much disrupt
the workflow I use. If configurable, I'd be open to it, if not
configurable I have to say -1 to this idea.
Cheers,
Morgan Fainberg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [rally] NovaServers.snapshot_server test works incorrectly.
Alex,
I experimented with rally yesterday and faced with some troubles. My test
suite was simple enough and while running it I saw few backtraces on the
screen. I captured backtraces and attached it as well as my test suit file.
Also I tried to investigate this error and found that the test was doing
sequence of GET requests, then doing DELETE request and then GET request
again. I can conclude that it is some other result than we expect
It is okay, because there is only one way to check that:
1) VM is created/deleted/...
2) Image is uploaded/deleted/...
3)
It is to pull status of object, and wait until it becomes ready.
openstack-rally command raised such exception because all calls of
snapshot_server method failed.
So we try to aggregate empty list of results. Could you file a bug in
launchpad?
Best regards,
Boris Pavlovic
--
Mirantis Inc.
On Thu, Nov 7, 2013 at 5:44 PM, Alexander Gorodnev
agorod...@mirantis.comwrote:
Hi team,
I experimented with rally yesterday and faced with some troubles. My test
suite was simple enough and while running it I saw few backtraces on the
screen. I captured backtraces and attached it as well as my test suit file.
Also I tried to investigate this error and found that the test was doing
sequence of GET requests, then doing DELETE request and then GET request
again. I can conclude that it is some other result than we expect.
Also when I'm trying to get details on my task I see the following error
message:
:~/rally$ openstack-rally task detailed
648a583e-ba0a-426d-8d9f-ffeaac0a9a03
Task 648a583e-ba0a-426d-8d9f-ffeaac0a9a03 is finished.
test scenario NovaServers.snapshot_server
args position 0
args values:
{u'args': {u'flavor_id': 42,
u'image_id': u'cfd22ffe-3c75-4c83-be58-9e9b316a7b64'},
u'concurrent': 1,
u'times': 1}
Command failed, please check log for more info
2013-11-07 17:36:10.140 30348 CRITICAL rally [-] max() arg is an empty
sequence
Any help would be appreciated.
Thanks,
Alexander
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] cinder metrics with nova-scheduler
On Thu, Nov 7, 2013 at 10:51 PM, Abbass MAROUNI abbass.maro...@virtualscale.fr wrote: Hello, We want to be able to launch a VM with a number of cinder volumes on the same host (the host is a compute and a storage node). We're looking for a way to tell nova-scheduler to work with cinder-scheduler so that we can filter and weight hosts according to our needs. According to the documentation on nova-scheduler filters : DiskFilter : Only schedule instances on hosts if there are sufficient Disk available for ephemeral storage. Is there any implementation of a filter to check the persistence storage on a host ? Do you think that this feature is doable ? Best Regards, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hello Abbass, Currently there is not a way to do this, however your request is very timely as we just discussed this very use case at the summit today and do have plans to work on it for the Icehouse release. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] cinder metrics with nova-scheduler
hi John: is there a etherpad or something like wiki about that? I'm intereted in it also. But my original thought is, vm is vm, volume is volume, they need be handled separately using some unified mechanism, the result is, they are on the same host. 2013/11/8 John Griffith john.griff...@solidfire.com On Thu, Nov 7, 2013 at 10:51 PM, Abbass MAROUNI abbass.maro...@virtualscale.fr wrote: Hello, We want to be able to launch a VM with a number of cinder volumes on the same host (the host is a compute and a storage node). We're looking for a way to tell nova-scheduler to work with cinder-scheduler so that we can filter and weight hosts according to our needs. According to the documentation on nova-scheduler filters : DiskFilter : Only schedule instances on hosts if there are sufficient Disk available for ephemeral storage. Is there any implementation of a filter to check the persistence storage on a host ? Do you think that this feature is doable ? Best Regards, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hello Abbass, Currently there is not a way to do this, however your request is very timely as we just discussed this very use case at the summit today and do have plans to work on it for the Icehouse release. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *---* *Lingxian Kong* Huawei Technologies Co.,LTD. IT Product Line CloudOS PDU China, Xi'an Mobile: +86-18602962792 Email: konglingx...@huawei.com; anlin.k...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Swift] cluster federation: Austin hackathon follow-up
Hi, Just before the Austin hackathon, we uploaded 5 patches related to the cluster federation blueprint https://blueprints.launchpad.net/swift/+spec/cluster-federation one of those patches, https://review.openstack.org/51242 dealt with the mechanics of forwarding data from a middleware component to/from a different cluster. This patch had two goals: 1. Maximize code reuse while minimizing core code change: any new code is simple and doesn't impact connection management, or the way the core handles data proxying between connections. 2. Refactor at the level of the ring and introduce the concept of a TargetRing to show that container-forwarding can be seen as a kind of storage policy while, again, minimizing core code change. I have just pushed a new patch, https://review.openstack.org/55674 which presents an alternative way to achieve the code reuse objective by creating a swift/common/http_utils module that can be used by both middleware and core proxy-server code (and possibly other code as well such as backend daemons, container-sync being a possible candidate). Like the first patch, it also includes a very basic piece of middleware that forwards all requests to a configured target cluster. I am including more details about the patch further down so if you're interested, please keep reading. I am interested in finding out which approach people prefer and get feedback on the patch itself. Eric More details -- Most of the code complexity in http_utils comes from the fact that for object PUT data must be transferred between the client connection and the backends/target connection and, at the moment, this uses decoupling queues and extra threads to produce to / consume from the queues. It is basically very close to the code from helper methods already in base.py and obj.py so reusing the code from http_utils in proxy-server means that the following code can be removed (only commented out for now): base.py: _make_app_iter obj.py: _send_file plus a chunk of code embedded in PUT Unlike the previous patch, this alternative patch has basic support for ssl based on the httplib.HTTPSConnection class used by bufferedhttp.py. It may form a good basis for more generic use, in particular by the container-sync daemon which must interact with proxies from other clusters. I understand there is a wish to remove the dependency on swiftclient in this daemon and the code in http_utils could be a good step forward towards that objective. Both patches rely on a callback from proxy/server.py (just like already exists for calling back the authorization middleware) to give a handle on the controller object that is created anew for each request. The app given to a middleware at instantiation time is the next filter in the pipeline and only maps to the proxy-server application if the middleware is placed just before proxy-server in the paste-deploy config pipeline. As far as I know, a callback from server.py is the only way a middleware can have a handle on proxy-server or a controller while being flexible about its placement in the pipeline. In the case of the original patch, the handle on the controller is needed to be able to call reused controller methods such as make_requests, etc. In the case of the alternative patch, only a handle on the proxy-server application is needed for http purposes so that configuration values (timeouts, queue depth, etc.) can be reused. However, in both cases, a fully functional container-forwarding will require a handle on the controller to implement complex multi-container use cases (COPY, SLO, DLO, versioning) where forwarded containers could reside in different clusters. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] ERROR : Unable to locate Volume Group stack-volumes
Hi all, I am using devstack and sometimes when i do a ./unstack.sh and then ./stack.sh, there is a Unable to locate Volume Group stack-volumes ERROR as followed. Does anyone know what causes the error and how to solve the issue? Before i do the ./unstack.sh and redo ./stack.sh. Everything looks good. thanks xin 2013-11-08 09:57:54.869 ERROR cinder.brick.local_dev.lvm [req-3ccb7cde-b7bf-472a-afb6-c1e15b1cf589 None None] Unable to locate Volume Group stack-volumes 2013-11-08 09:57:54.869 ERROR cinder.volume.manager [req-3ccb7cde-b7bf-472a-afb6-c1e15b1cf589 None None] Error encountered during initialization of driver: LVMISCSIDriver 2013-11-08 09:57:54.870 ERROR cinder.volume.manager [req-3ccb7cde-b7bf-472a-afb6-c1e15b1cf589 None None] Bad or unexpected response from the storage volume backend API: Volume Group stack-volumes does not exist 2013-11-08 09:57:54.870 TRACE cinder.volume.manager Traceback (most recent call last): 2013-11-08 09:57:54.870 TRACE cinder.volume.manager File /opt/stack/cinder/cinder/volume/manager.py, line 191, in init_host 2013-11-08 09:57:54.870 TRACE cinder.volume.manager self.driver.check_for_setup_error() 2013-11-08 09:57:54.870 TRACE cinder.volume.manager File /opt/stack/cinder/cinder/volume/drivers/lvm.py, line 89, in check_for_setup_error 2013-11-08 09:57:54.870 TRACE cinder.volume.manager raise exception.VolumeBackendAPIException(data=message) 2013-11-08 09:57:54.870 TRACE cinder.volume.manager VolumeBackendAPIException: Bad or unexpected response from the storage volume backend API: Volume Group stack-volumes does not exist 2013-11-08 09:57:54.870 TRACE cinder.volume.manager ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Some initial code copying for db/migration
There are several different points being raised here, all very interesting. Trying to separate them below. 1) Using objects as an abstraction for versioned data: This seems like a good direction overall, especially from the point-of-view of backwards compatibility of consumers of the object. However, after looking through some of the objects defined in nova/objects/, I am not sure if I understand how this works. Specifically, it is not clear to me how might the consumer of the object be able to query different versions of it at runtime. 2) Using objects as an abstraction to support different kinds of backends (SQL and non-SQL backends): - Again, a good direction overall. From implementation point-of-view though this may become tricky, in the sense that the object layer would need to be designed with just the right amount of logic so as to be able to work with either a SQL or a non-SQL backend. It will be good to see some examples of how this might be done if there are any existing examples somewhere. 3) From Solum's point-of-view, the concern around the potential downtime that may be incurred in the API-layer because of breaking object model changes, and so, investigating how to design this correctly right from the start. - This is a valid concern. We will have to design for this at sometime or other anyways. Doing this first up might be good with regards to understanding how the decision of using versioned objects would tie with the API layer implemented in Pecan+WSME. I don't have much experience with either, so would love to hear about it from those who do. Best Regards, Devdatta -Original Message- From: Clayton Coleman ccole...@redhat.com Sent: Thursday, November 7, 2013 8:26pm To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Cc: Dan Smith d...@danplanet.com Subject: Re: [openstack-dev] [Solum] Some initial code copying for db/migration - Original Message - https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L420 https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L43 This API and these models are what we are trying to avoid exposing to the rest of nova. By wrapping these in our NovaObject-based structures, we can bundle versioned data and methods together which is what we need for cross-version compatibility and parity for the parts of nova that are not allowed to talk to the database directly. See the code in nova/objects/* for the implementations. Right now, these just call into the db_api.py, but eventually we want to move the actual database implementation into the objects themselves and hopefully dispense with most or all of the sqlalchemy/* stuff. This also provides us the ability to use other persistence backends that aren't supported by sqlalchemy, or that don't behave like it does. If you're going to be at the summit, come to the objects session on Thursday where we'll talk about this in more detail. Other projects have expressed interest in moving the core framework into Oslo so that we're all doing things in roughly the same way. It would be good to get you started on the right way early on before you have the migration hassle we're currently enjoying in Nova :) --Dan The summit session was excellent - next step for me is to look through what the right abstraction is going to be for objects that keeps the db details properly isolated and the API surface on /objects suitably coarse (in line with the long discussion in Nova about non-SQL backends, the consensus of which is that the domain object model needs to abstract whole interaction flows, vs granular steps). I'll try to have some example code to debate after I get back from summit. Even assuming Solum has a fairly small persistence model, in the long run I believe it's fair to say that the ability to perform live upgrades will become critical for all operators. One of the side effects of supporting potentially millions of applications (at the high end, and not an unreasonable estimate for hosted environments) is that any period of downtime at the API level will prevent users from making deployments, which is a direct line-of-business concern. Designing around live upgrades - specifically, the requirement that code must be aware of two versions of a schema at the same time - implies that the domain model must be able to be aware of those versions on an object basis. For reference, [1] and [2] contain some of the Nova discussion, and Nova in icehouse is going to be moving this way. I'd prefer (it's important to Red Hat) to design for that from the beginning and be working towards that end. Do folks have additional questions or concerns about my exploration of a versioned domain object model from day one? Are there others who would like to embrace quick and dirty and explicitly ignore this
Re: [openstack-dev] [Off Topic] Sunday/Monday in Hong Kong
On 11/08/2013 06:09 PM, Chris Jones wrote: Hey I'm going to be staying in the Tsim Sha Tsui area of Hong Kong until late Monday - just wondering if any other folks are staying on and want to do interesting things? -- Cheers, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev same here -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Some initial code copying for db/migration
1) Using objects as an abstraction for versioned data: This seems like a good direction overall, especially from the point-of-view of backwards compatibility of consumers of the object. However, after looking through some of the objects defined in nova/objects/, I am not sure if I understand how this works. Specifically, it is not clear to me how might the consumer of the object be able to query different versions of it at runtime. The object registry is handled by the metaclass in objects/base.py. It automatically collects objects that inherit from NovaObject, and allows multiple versions of the same object to exist. We don't have anything that needs to specifically ask the registry directly for foo object version X, so there's no interface for doing that right now. We do, however, have incoming objects over RPC that need to be re-hydrated, with an is this compatible version check. We also have the ability to downlevel an object using the obj_make_compatible() method. We are planning to always roll the conductor code first, which means it can take the newest version of an object from the schema (in whatever state it's in) and backlevel it to the version being asked for by a remote RPC client. 2) Using objects as an abstraction to support different kinds of backends (SQL and non-SQL backends): - Again, a good direction overall. From implementation point-of-view though this may become tricky, in the sense that the object layer would need to be designed with just the right amount of logic so as to be able to work with either a SQL or a non-SQL backend. It will be good to see some examples of how this might be done if there are any existing examples somewhere. We don't have any examples of using a non-SQL backend for general persistence in Nova, which means we don't have an example of using objects to hide it. If what NovaObject currently provides is not sufficient to hide the intricacies of a non-SQL persistence layer, I think it's probably best to build that on top of what we've got in the object model. 3) From Solum's point-of-view, the concern around the potential downtime that may be incurred in the API-layer because of breaking object model changes, and so, investigating how to design this correctly right from the start. - This is a valid concern. We will have to design for this at sometime or other anyways. Doing this first up might be good with regards to understanding how the decision of using versioned objects would tie with the API layer implemented in Pecan+WSME. I don't have much experience with either, so would love to hear about it from those who do. The ironic guys were mentioning that they'd like to have something a little more native for WSME integration. I too am ignorant here, but I think it sounded like they wanted some general way to take an object and transform it into what gets exposed to the API client. Perhaps just a pattern of standard methods on such objects would be sufficient. For nova, maybe: class NovaAPIViewableThingy(NovaObject): def obj_api_view(self, context): if context.is_admin(): return show_admin_stuff() else: return show_usery_stuff() ? --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Shall backward compatibility env. vars be removed from python-clients?
I think you need to do option 2 and print deprecation warnings, then the question becomes for how long. I think there is a policy for this and that it is deprecate in N remove in N+1 Clients are a bit different so maybe keep it for ~6 months? Sam On 8 Nov 2013, at 10:49 am, Leandro Costantino leandro.i.costant...@intel.com wrote: Hi all, Clients like python-novaclient/cinderclient/trove still support NOVA_*, CINDER_*, TROVE_* variables for backward compatibility support,while clients like python-neutronclient/keystoneclient only supports OS_* env vars. The following bug (#1061491, see review), mentions that it may be confusing if novaclient for instance, silently accept those variables without even being mentioned on the current help/documentation neither warning the user at all. (User has exported NOVA_USERNAME/CINDER_USERNAME/etc instead of OS_USERNAME etc.) As Kevin suggested on the review, (https://review.openstack.org/#/c/55588/) “we need to make sure that we have consensus that enough time has passed to drop the old variables”. I would like to hear opinions about this. Some options that i can think of are: 1) Remove NOVA_USERNAME, NOVA_PASSWORD and NOVA_PROJECT_ID support from novaclient. Same for other clients allowing vars other than OS_USERNAME, OS_PASSWORD, OS_TENANT_ID for this specific options. 2) Warn about deprecation if they are being used. 3) Ignore this topic, keep everything as today and just close the 'bug/suggestion'. 4) Other? Best Regards -Leandro PS: shall this message belong to another ML, please, let me know. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
