[Openstack] Project quotas on multi-region
Hi, In a deployment scenario where one keystone has several regions registered, how the project quota are managed by, as an example, two nova services in two different regions? I am wondering if is it possible to set quota on the project for all regions or this must to be done on a region by region basis which really means a quota for a project in a region. Thanks in advance, Glaucimar Aguiar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone - Domain admin role policies?
Great! It will be nice to better understand user roles and permission story for Grizzly. Please share if you have more information on this. Thanks, Glaucimar Aguiar From: Dolph Mathews [mailto:dolph.math...@gmail.com] Sent: quarta-feira, 13 de março de 2013 13:08 To: Aguiar, Glaucimar (Brazil RD-ECL) Cc: openstack@lists.launchpad.net; Brant L Knudson Subject: Re: [Openstack] Keystone - Domain admin role policies? That's exactly our goal, but I'm not sure that corresponding well-tested policy.json changes will land in time for Grizzly (also not sure if there would be any other supporting changes required). Adding Brant as he specifically was investigating the same possibility in Grizzly. -Dolph On Tue, Mar 12, 2013 at 8:57 AM, Aguiar, Glaucimar (Brazil RD-ECL) glaucimar.agu...@hp.commailto:glaucimar.agu...@hp.com wrote: Please note that I know one can edit policy.json to define domain-admin role permissions but with the implementation of domains, it seems that domain-admin role permissions should be defined as admin role permissions are. Thanks in advance, Glaucimar Aguiar -Original Message- From: openstack-bounces+glaucimar.aguiar=hp@lists.launchpad.netmailto:hp@lists.launchpad.net [mailto:openstack-bounces+glaucimar.aguiarmailto:openstack-bounces%2Bglaucimar.aguiar=hp@lists.launchpad.netmailto:hp@lists.launchpad.net] On Behalf Of Aguiar, Glaucimar (Brazil RD-ECL) Sent: terça-feira, 12 de março de 2013 10:34 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Keystone - Domain admin role policies? Hi, While studying keystone v3 and domains feature, I realized that current policy.json file has no domain_admin role as I was expecting. I wonder if this role will be defined in Grizzly timeframe or how do you envision domain_admin role enforcement. Thanks in advance! Glaucimar Aguiar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone - Domain admin role policies?
Hi, While studying keystone v3 and domains feature, I realized that current policy.json file has no domain_admin role as I was expecting. I wonder if this role will be defined in Grizzly timeframe or how do you envision domain_admin role enforcement. Thanks in advance! Glaucimar Aguiar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone - Domain admin role policies?
Please note that I know one can edit policy.json to define domain-admin role permissions but with the implementation of domains, it seems that domain-admin role permissions should be defined as admin role permissions are. Thanks in advance, Glaucimar Aguiar -Original Message- From: openstack-bounces+glaucimar.aguiar=hp@lists.launchpad.net [mailto:openstack-bounces+glaucimar.aguiar=hp@lists.launchpad.net] On Behalf Of Aguiar, Glaucimar (Brazil RD-ECL) Sent: terça-feira, 12 de março de 2013 10:34 To: openstack@lists.launchpad.net Subject: [Openstack] Keystone - Domain admin role policies? Hi, While studying keystone v3 and domains feature, I realized that current policy.json file has no domain_admin role as I was expecting. I wonder if this role will be defined in Grizzly timeframe or how do you envision domain_admin role enforcement. Thanks in advance! Glaucimar Aguiar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone v3 adoption
Hello, I would like to know the plans for nova, glance, etc to adopt keystone v3 API. Is there an expectation that this happens in Havana timeframe? I am asking as the it seems the Domains feature is not useful until services are capable of validating a v3 token and move to keystone v3 API. Thanks in advance, Glaucimar Aguiar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone v3 adoption
Perfect, thanks! From: Dolph Mathews [mailto:dolph.math...@gmail.com] Sent: quinta-feira, 7 de março de 2013 14:56 To: Aguiar, Glaucimar (Brazil RD-ECL); openstack Subject: Re: [Openstack] Keystone v3 adoption Yes, exactly. Until keystoneclient.middleware.auth_token is revised, v3 tokens will basically only be useful against keystone. -Dolph On Thu, Mar 7, 2013 at 11:52 AM, Aguiar, Glaucimar (Brazil RD-ECL) glaucimar.agu...@hp.commailto:glaucimar.agu...@hp.com wrote: Hi Dolph, Thank you very much for your answer. I really appreciate it. Are you saying then, that I configure nova (for example) to use v3 middleware, I should be able to call nova with a v3 token and this token will get validated? Glaucimar Aguiar From: Dolph Mathews [mailto:dolph.math...@gmail.commailto:dolph.math...@gmail.com] Sent: quinta-feira, 7 de março de 2013 11:04 To: Aguiar, Glaucimar (Brazil RD-ECL) Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone v3 adoption The v3 API is largely abstracted from other services (horizon being a major exception) using keystoneclient.middleware.auth_token, which is being revised here [1] and here [2]. Because the clients do not necessarily follow the same release schedule as the services, we've obviously been focused on the API and it's server-side implementation. I expect we'll do a v3-compliant release of keystoneclient around the time of grizzly's release. openstackclient (providing CLI exposure) is in the works as well [3]. [1]: https://review.openstack.org/#/c/23401/ [2]: https://review.openstack.org/#/c/21942/ [3]: https://review.openstack.org/#/q/project:openstack/python-openstackclient+status:open,n,z -Dolph On Thu, Mar 7, 2013 at 5:30 AM, Aguiar, Glaucimar (Brazil RD-ECL) glaucimar.agu...@hp.commailto:glaucimar.agu...@hp.com wrote: Hello, I would like to know the plans for nova, glance, etc to adopt keystone v3 API. Is there an expectation that this happens in Havana timeframe? I am asking as the it seems the Domains feature is not useful until services are capable of validating a v3 token and move to keystone v3 API. Thanks in advance, Glaucimar Aguiar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Quota classes, Store quota data relation
Hi, I am trying to understand the relation of quota classes' implementation (which I understand as unfinished) with the https://blueprints.launchpad.net/keystone/+spec/store-quota-data blueprint, if any. Per my understanding the implementation of StoreQuotaData and the movement of services to use this central repository require the implementation of quota classes in nova to be also moved to this centralized location. Are there plans on this area? Thanks for clarifications or help in better understand this relationship. Glaucimar Aguiar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quota classes, Store quota data relation
Thanks Everett! So, does this mean that nova continue to store quotas assigned to projects as well as keystone? Meaning they will be duplicated? Thanks again! Glaucimar Aguiar From: Everett Toews [mailto:everett.to...@rackspace.com] Sent: quarta-feira, 28 de novembro de 2012 18:55 To: Aguiar, Glaucimar (Brazil RD-ECL); openstack@lists.launchpad.net Subject: Re: [Openstack] Quota classes, Store quota data relation Store Quota Data (in Keystone) is only intended to be a very simple way to store quotas centrally. It is not related to quota classes and there are no plans to do so. That blueprint came out of a use case to have quotas in Swift. However, Swift doesn't store any user/tenant/project data so it was moved to Keystone. The idea being that you could write Swift middleware to check the quotas in Keystone before performing some operation. Regards, Everett From: Aguiar, Glaucimar (Brazil RD-ECL) glaucimar.agu...@hp.commailto:glaucimar.agu...@hp.com Date: Wednesday, November 28, 2012 2:36 PM To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Quota classes, Store quota data relation Hi, I am trying to understand the relation of quota classes' implementation (which I understand as unfinished) with the https://blueprints.launchpad.net/keystone/+spec/store-quota-data blueprint, if any. Per my understanding the implementation of StoreQuotaData and the movement of services to use this central repository require the implementation of quota classes in nova to be also moved to this centralized location. Are there plans on this area? Thanks for clarifications or help in better understand this relationship. Glaucimar Aguiar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quota classes, Store quota data relation
Got it! Thank you much. Glaucimar Aguiar From: Everett Toews [mailto:everett.to...@rackspace.com] Sent: quarta-feira, 28 de novembro de 2012 19:46 To: Aguiar, Glaucimar (Brazil RD-ECL); openstack@lists.launchpad.net Subject: Re: [Openstack] Quota classes, Store quota data relation From: Aguiar, Glaucimar (Brazil RD-ECL) glaucimar.agu...@hp.commailto:glaucimar.agu...@hp.com Date: Wednesday, November 28, 2012 3:08 PM To: Everett Toews everett.to...@rackspace.commailto:everett.to...@rackspace.com, openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: RE: [Openstack] Quota classes, Store quota data relation Thanks Everett! So, does this mean that nova continue to store quotas assigned to projects as well as keystone? Meaning they will be duplicated? --- They will not be duplicated. Nova will continue to use its own mechanism for quotas. As it stands right now, the only use case for Quotas in Keystone will be for Swift. And even that's optional, depending on whether or not the deployer chooses to write Swift middleware to use it. Cheers, Everett ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [metering][ceilometer] Ceilometer and Keystone regions
Hello, Can Ceilometer collect data about instances in different keystone regions? Is this a valid/possible configuration? Scenario 1: I have two regions defined in my keystone service, each one has a nova service in it. Can Ceilometer collect metering information from both regions? In a single database? Scenario 2: I have two nova services in my keystone service region. Can Ceilometer support this configuration? I appreciate any information on this, documentation pointers on this subject are helpful as well. Thanks! Glaucimar Aguiar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [metering][ceilometer] Ceilometer and Keystone regions
Great! Thanks! On Nov 8, 2012, at 8:33 PM, Julien Danjou jul...@danjou.info wrote: On Thu, Nov 08 2012, Aguiar, Glaucimar (Brazil RD-ECL) wrote: Can Ceilometer collect data about instances in different keystone regions? Is this a valid/possible configuration? Scenario 1: I have two regions defined in my keystone service, each one has a nova service in it. Can Ceilometer collect metering information from both regions? In a single database? Yes, you'll just have to deploy at least one ceilometer-collector in each region on Nova and connect them to the same database. Plus ceilometer-agent-compute on each nova-compute. Scenario 2: I have two nova services in my keystone service region. Can Ceilometer support this configuration? Yes, same answer as scenario 1, deploy at least a ceilometer-collector for each Nova, plus ceilometer-agent-compute. If you want to easily identify the region your meter stored in Ceilometer come from, you can use the 'source' field of the meters to a string that helps you recognize which region the meter come from (see counter_source option in Ceilometer). -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [ceilometer] requesting feedback on priorities for metering data collection
Thank you very much for the answers, they are of great help. I will plan on attending Thursday meeting so I can see the Essex discussion. Glaucimar Aguiar From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com] Sent: quarta-feira, 25 de julho de 2012 14:29 To: Aguiar, Glaucimar (Brazil RD-ECL); openstack@lists.launchpad.net Subject: Re: [Openstack] [ceilometer] requesting feedback on priorities for metering data collection On Wed, Jul 25, 2012 at 10:45 AM, Aguiar, Glaucimar (Brazil RD-ECL) glaucimar.agu...@hp.commailto:glaucimar.agu...@hp.com wrote: Doug, Thanks for sending this out. I am interested in this project and as I could not have it working yet with my Essex release of OpenStack Some of the pieces work with Essex, but the actual daemons don't, yet. We are planning to discuss this at our meeting this Thursday (http://wiki.openstack.org/Meetings/MeteringAgenda). I would like to better understand the metrics collected you mention below. I have being reading the documentation and code extensively and would like to count on your help to better understand some aspects of the ceilometer. Some questions below, sorry if they sound so easy for you but if you could help me with these, this would be of a great help for me. These are good questions, thanks for bringing them up! When you say CPU usage meters, does it mean ceilometer is already capable of reporting the cpu consumption over an hour? We are currently polling libvirt periodically to get the total CPU time for an instance. The frequency of polling is adjustable, but I think the default is 10 minutes. The value returned by libvirt represents the total time for the instance, but a client could pull the data and perform the calculation over a period of time. The API we have defined allows for querying within a time range, for example. Does this take into account the number of CPUs of the instance or this should be derived from the instance data? The number of CPUs in an instance is part of the metadata associated with the counter, but does not enter into the calculation of CPU-time as far as I know. We ask libvirt for that info, and just use what we're given. Thank you very much for any help in increasing my understanding of the behavior of this component. I can also contact you in IRC if you prefer. I hope my answers help, Doug Regards, Glaucimar Aguiar From: openstack-bounces+glaucimar.aguiar=hp@lists.launchpad.netmailto:hp@lists.launchpad.net [mailto:openstack-bounces+glaucimar.aguiarmailto:openstack-bounces%2Bglaucimar.aguiar=hp@lists.launchpad.netmailto:hp@lists.launchpad.net] On Behalf Of Doug Hellmann Sent: quarta-feira, 25 de julho de 2012 11:24 To: openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org; openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] [ceilometer] requesting feedback on priorities for metering data collection When the ceilometer project started after the Folsom summit, we compiled a list of metrics to be collected [1]. We have reached a stage in the project where we are ready to start implementing more of these meters, and would like some input from the rest of the community about priorities. We have implemented the instance counter, disk I/O, and CPU usage meters, and have begun working on collecting some of the network statistics. If you are interested in using ceilometer for tracking usage in your cloud deployment, please let us know which other metrics you will find especially useful. Thanks, Doug 1 - http://wiki.openstack.org/EfficientMetering#Meters ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Questions about ceilometer
Doug,
I will start ceilometer installation now. Would you recommend installing Folsom
then instead of essex? (I already have essex installed so, this is the reason
for asking).
Thanks,
Glaucimar Aguiar
From: openstack-bounces+glaucimar.aguiar=hp@lists.launchpad.net
[mailto:openstack-bounces+glaucimar.aguiar=hp@lists.launchpad.net] On
Behalf Of Doug Hellmann
Sent: segunda-feira, 16 de julho de 2012 09:55
To: 张家龙
Cc: openstack
Subject: Re: [Openstack] Questions about ceilometer
On Sat, Jul 14, 2012 at 10:02 PM, 张家龙
zhan...@awcloud.commailto:zhan...@awcloud.com wrote:
Hi,all.
Sorry for late reply.
Until now, I not test folsom. So, I`am not sure how it work in folsom .
The follow is my qpid config file:
http://pastebin.com/sBXm6k7z
And Doug writed set driver to
nova.openstack.common.notifier.rabbit_notifier,
while , I cannot found this class or modules in exsse.
The notifier classes moved in Folsom, so that's the setting you would need if
you were working with Folsom.
I'm traveling this week, so I won't be able to set up a test environment with
Essex or qpid until next week some time.
Based on rereading the configuration files you posted, I do suspect that this
is a problem with the code, rather than your configuration. You might want to
try the patch John posted above. I don't think that's the right long-term
solution, but if it gets you past this situation we can find a better solution
later.
Doug
--
Best Regards
ZhangJialong
-- Original --
From: Doug
Hellmanndoug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com;
Date: Sat, Jul 14, 2012 00:17 AM
To: 张家龙zhan...@awcloud.commailto:zhan...@awcloud.com;
Cc: Julien Danjoujul...@danjou.infomailto:jul...@danjou.info;
openstackopenstack@lists.launchpad.netmailto:openstack@lists.launchpad.net;
Subject: Re: [Openstack] Questions about ceilometer
On Fri, Jul 13, 2012 at 11:36 AM, 张家龙
zhan...@awcloud.commailto:zhan...@awcloud.com wrote:
Dear Doug,
I`m use Qpid instead of Rabbit .
Did it cause the error ?
Qpid should work, but I haven't been testing with that so you might have found
a bug.
There are (at least) two differences between your setup and what I normally
use: Essex and qpid. Have you tried running against a folsom install? That
would at least tell us if the qpid configuration is correct or if the problem
is related to Essex.
Doug
In addition,my nova.conf,mongodb.conf and ceilometer-collector.conf are
here:
http://pastebin.com/sW5d8eRv
http://pastebin.com/D5GMkLsb
http://pastebin.com/u5vH22Lh
Were there some errors in my config files?
Waiting your reply. Thanks.
--
Best Regards
ZhangJialong
-- Original --
From: Doug
Hellmanndoug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com;
Date: Fri, Jul 13, 2012 11:28 PM
To: 张家龙zhan...@awcloud.commailto:zhan...@awcloud.com; Julien
Danjoujul...@danjou.infomailto:jul...@danjou.info;
Cc:
openstackopenstack@lists.launchpad.netmailto:openstack@lists.launchpad.net;
Subject: Re: [Openstack] Questions about ceilometer
On Fri, Jul 13, 2012 at 10:04 AM, Doug Hellmann
doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote:
On Thu, Jul 12, 2012 at 9:42 PM, 张家龙
zhan...@awcloud.commailto:zhan...@awcloud.com wrote:
Dear all,
As the project named ceilometer appeared,I paid close attention to it.
According to the docs of ceilometer,I deploied it in openstack exsse
environment.
While,I cannot start the ceilometer collector and agent.
The follows are my operations.
1.Install openstack nova ,mongodb and ceilometer.
2.configurate nova ,mongodb and ceilometer
The /etc/nova/nova.conf file is here:
http://pastebin.com/sW5d8eRv
Here is the /etc/ceilometer-collector.conf file is here:
http://pastebin.com/u5vH22Lh
And the /etc/mongodb.conf is here:
http://pastebin.com/D5GMkLsb
3.Start openstack nova ,mongodb
4.Then I start the ceilometer-collector
/usr/bin/ceilometer-collector start
While,some errors occurred:
2012-07-11 05:25:35 INFO ceilometer.storage [-] Loaded mongodb storage
engine EntryPoint.parse('mongodb =
ceilometer.storage.impl_mongodb:MongoDBStorage')
2012-07-11 05:25:35 INFO ceilometer.storage [-] Loaded mongodb storage
engine EntryPoint.parse('mongodb =
ceilometer.storage.impl_mongodb:MongoDBStorage')
2012-07-11 05:25:35 INFO ceilometer.storage.impl_mongodb [-] connecting to
MongoDB on localhost:27017
2012-07-11 05:25:35 INFO ceilometer.collector.dispatcher [-] attempting to
load notification handler for ceilometer.collector.compute:instance
2012-07-11 05:25:35 INFO ceilometer.collector.dispatcher [-] subscribing
instance handler to compute.instance.create.end events
2012-07-11 05:25:35 INFO ceilometer.collector.dispatcher [-] subscribing
instance handler to compute.instance.exists
