Re: [openstack-dev] [Nova] Proposal to revert per-user-quotas
From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] Sent: Tuesday, August 20, 2013 9:41 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] Proposal to revert per-user-quotas On Aug 20, 2013, at 9:02 AM, Yingjun Li liyingjun1...@gmail.commailto:liyingjun1...@gmail.com wrote: Thanks for address the issues. About the bad state for fixed_ips, floating_ips, i think we could make the user_id column=NULL when creating the quota usage and reservation, so the usages for fixed_ips and floating_ips will be synced within the project. Does this make sense? If this is a viable approach, I prefer that we attempt to fix the code in tree. We attempted to get this code in grizzly and had to revert. I'd hate to go through the cycle again in I if we can fix it now. [Gary Kotton] I too prefer this approach. Vish 2013/8/20 Andrew Laski andrew.la...@rackspace.commailto:andrew.la...@rackspace.com The patch in question (https://review.openstack.org/#/c/28232/24) adds the ability to track quota usage on a per user basis within a project. I have run into two issues with it so far: the db migration is incomplete and leaves the data in a bad state, and the sync methods used during quota reservations no longer work for fixed_ips, floating_ips, and networks since they are not tied to a user. The db migration issue is documented at https://bugs.launchpad.net/nova/+bug/1212798 but the tl;dr is that the quota usages that were in place before the migration is run can not be decremented and aren't fixed by the healing sync that occurs. I sought to address this by introducing a new migration which performs a full sync of quota usages and removes the bad rows but that led me to the next issue. Some resources can't be synced properly because they're tracked per user in the quota table but they're not tied to a user so it's not feasible to grab a count of how many are being used by any particular user. So right now the quota_usages table can get into a bad state with no good way to address it. Right now I think it will be better to revert this change and re-introduce it once these issues are worked out. Thoughts? As an addendum, the patch merged about a month ago on Jul 25th and looks to have some minor conflicts for a revert but should be minimally disruptive. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] oauth and keystone
Hello, You have to add the oAuth filter (oauth_extension) in your pipeline, in /etc/keystone/keystone.conf or /etc/keystone/keystone-paste.ini: [pipeline:api_v3] pipeline = access_log sizelimit url_normalize token_auth admin_token_auth xml_body json_body oauth_extension ec2_extension s3_extension service_v3 and restart keystone. Matthieu Huin m...@enovance.com - Original Message - | From: Yongsheng Gong gong...@unitedstack.com | To: OpenStack Development Mailing List openstack-dev@lists.openstack.org | Sent: Wednesday, August 21, 2013 6:22:09 AM | Subject: [openstack-dev] oauth and keystone | | Hi, | | I have seen the code about oauth in the keystone but I cannot find the | document about how to setup keystone and other openstack services to enable | oauth. | | Can anyone tell me how to setup an env like this? | | Thanks | Yong Sheng Gong | | ___ | 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
[openstack-dev] [Heat] Meeting agenda for Wed August 21st at 2000 UTC
The Heat team holds a weekly meeting in #openstack-meeting, see https://wiki.openstack.org/wiki/Meetings/HeatAgenda for more details The next meeting is on Wed August 21st at 2000 UTC Current topics for discussion: - Review last weeks actions - Reminder re FeatureProposalFreeze - h3 blueprint status - Open discussion If anyone has any other topic to discuss, please add to the wiki. Thanks! Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Concerning get_resources/get_meters and the Ceilometer API
On Tue, Aug 20 2013, Thomas Maddox wrote: […] I hope I'm not seeing a problem that doesn't exist, but either way I'll learn something so, thoughts? =] That sounds like a good idea. -- Julien Danjou // Free Software hacker / independent consultant // http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][keystone][LDAP] Error about enable and desc attribute type undefine.
I got the solution, There is not 'enable' attribute in objectClass inetOrgPerson of openldap inetOrgPerson schema. Now everything is OK. 2013/8/21 XINYU ZHAO xyzje...@gmail.com Which release are you using? According to my experience last year when ldap backend was much more premature, i had to add those attributes in my ldap server's manually, because there is no such attribute in its schema. I don't know the status now. On Mon, Aug 19, 2013 at 11:42 PM, Qinglong.Meng mengql112...@gmail.comwrote: Hi all, I configure keystone with ldap backend followed LDAP section of http://docs.openstack.org/developer/keystone/configuration.html, and when I create tenant in ldap, I got the error about enable and desc attribute type undefined in keystone.log. Here is keystone.conf: http://paste.openstack.org/show/44574/ keystone.log http://paste.openstack.org/show/44575/ the ldif of ldap server http://paste.openstack.org/show/44578/ sample slapd.conf http://paste.openstack.org/show/44579/ -- Lawrency Meng mail: mengql112...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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 -- Lawrency Meng mail: mengql112...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstack][keystone][ssl] Help for configure keystone with ssl.
Hi All, Os: ubuntu 12.04 LTS keystone version: stable/grizzly Ｉ hava seen keystone-manage ssl_setup in keystone tag 2013.2.b1. but I can't use it in my version. So I want to know: * how to configure ssl with keystone manual? * how to test configure is ok? Tks for you help. Best Regards, -- Lawrency Meng mail: mengql112...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [keystone][ssl] Help for configure keystone with ssl.
Qing Long, Here's a document in keystone FYI. https://github.com/openstack/keystone/blob/master/doc/source/apache-httpd.rst Meanwhile, I'm submitting a patch into devstack to enable apache and ssl for keystone service: https://review.openstack.org/#/c/36474/ Please help me to test it if you want. :-) Best Regards, Edward Zhang(张华) Qinglong.Meng mengql112233@gma il.comTo openst...@lists.openstack.org, 08/21/2013 06:13 openstack-dev@lists.openstack.org PMopenstack-dev@lists.openstack.org , cc Subject [Openstack] [keystone][ssl] Help for configure keystone with ssl. Hi All, Os: ubuntu 12.04 LTS keystone version: stable/grizzly Ｉ hava seen keystone-manage ssl_setup in keystone tag 2013.2.b1. but I can't use it in my version. So I want to know: * how to configure ssl with keystone manual? * how to test configure is ok? Tks for you help. Best Regards, -- Lawrency Meng mail: mengql112...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack inline: ecblank.gifinline: A5985312.gifinline: graycol.gifinline: pic17986.gif___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Announcing Tuskar project and PTL nominations
Hi everyone, We would like to announce Tuskar, an OpenStack management service. Our goal is to provide an API and UI to install and manage OpenStack at larger scale: where you deal with racks, different hardware classes for different purposes (storage, memory vs. cpu-intensive compute), the burn-in process, monitoring the HW utilisation, etc. Some of this will overlap with TripleO, Ceilometer and possibly other projects. In that case, we will work with the projects to figure out the best place to fix rather than duplicating effort and playing in our own sandbox. Current status: There's a saying that if you're not embarrassed by your first release, you've shipped too late. I'm happy to say, we are quite embarrassed :-) We've got a prototype that allows us to define different hardware classes and provision the racks with the appropriate images, then add new racks and have them provisioned. We've got a Horizon dashboard plugin that shows the general direction we want to follow and we're looking into integrating Ceilometer metrics and alarms. However, we're still tossing around different ideas and things are very likely to change. Our repositories are on Stackforge: https://github.com/stackforge/tuskar https://github.com/stackforge/python-tuskarclient https://github.com/stackforge/tuskar-ui And we're using Launchpad to manage our bugs and blueprints: https://launchpad.net/tuskar https://launchpad.net/tuskar-ui If you want to talk to us, pop in the #tuskar IRC channel on Freenode or send an email to openstack-...@lists.launchpad.net with [Tuskar] in the subject. PTL: Talking to OpenStack developers, we were advised to elect the PTL early. Since we're nearing the end of the Havana cycle, we'll elect the PTL for a slightly longer term -- the rest of Havana and throughout Icehouse. The next election will coincide with those of the official OpenStack projects. If you are a Tuskar developer and want to nominate yourself, please send an email to openstack-...@lists.launchpad.net with subject Tuskar PTL candidacy. The self-nomination period will end on Monday, 26th August 2013, 23:59 UTC. -- Tomas Sedovic ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Concerning get_resources/get_meters and the Ceilometer API
On 8/20/13 1:48 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: On 08/20/2013 10:42 AM, Thomas Maddox wrote: On 8/19/13 8:21 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: On 08/18/2013 04:04 PM, Jay Pipes wrote: On 08/17/2013 03:10 AM, Julien Danjou wrote: On Fri, Aug 16 2013, Jay Pipes wrote: Actually, that's the opposite of what I'm suggesting :) I'm suggesting getting rid of the resource_metadata column in the meter table and using the resource table in joins... I think there's a lot of scenario where this would fail, like for example instances being resized; the flavor is a metadata. I'm proposing that in these cases, a *new* resource would be added to the resource table (and its ID inserted in meter) table with the new flavor/instance's metadata. Though, changing the schema to improve performance is a good one, this needs to be thought from the sample sending to the storage, through the whole chain. This is something that will break a lot of current assumption; that doesn't mean it's bad or we can't do it, just that we need to think it through. :) Yup, understood completely. The change I am proposing would not affect any assumptions made from the point of view of a sample sent to storage. The current assumption is that a sample's *exact* state at time of sampling would be stored so that the exact sample state could be reflected even if the underlying resource that triggered the sample changed over time. All I am proposing is a change to the existing implementation of that assumption: instead of storing the original resource metadata in the meter table, we instead ensure that we store the resource in the resource table, and upon new sample records being inserted into the meter table, we check to see if the resource for the sample is the same as it was last time. If it is, we simply insert the resource ID from last time. If it isn't, we add a new record to the resource table that describes the new resource attributes, and we insert that new resource ID into the meter table for that sample... I'm assuming we wouldn't need a backlink to the older resource? I'm thinking about how this would work work Events and Request ID's. The two most common reports we run from StackTach are based on Request ID and some resource ID. Show me all the events related to this Request UUID Show me all the events related to this Instance/Image/Network/etc UUID A new Resource entry would be fine so long as it was still associated with the underlying Resource UUID (instance, image, etc). We could get back a list of all the Resources with the same UUID and, if needed, lookup the metadata for it. This would allow us to see how to the resource changed over time. I think that's what you're suggesting ... if so, yep. As for the first query ... for this Request ID, we'd have to map Event many related Resources since one event could have a related instance/image/network/volume/host/scheduler, etc. These relationships would have to get mapped when the Event is turned into Meters. Changing the Resource ID might not be a problem if we keep a common Resource UUID. I have to think about that some more. Would we use timestamps to determine which Resource is the most recent? -S Are we going to be incurring significant performance cost from this? There's certainly a storage cost and potentially a race condition (read the current metadata, change something and, at the same time, someone else did the another metadata change). But the performance overhead should be slight. H, okay. Yeah, it's not currently checking before merging metadata right now. It's just merging whichever notifications happens to show up last. Let me see if I understand how a query will work for this based on the current way CM gets billing: Scenario: Monthly billing for Winston who built 12 machines this month; we don't want to bill for failed/stalled builds that weren't cleaned up yet either. 1. Filter Meter table for the time range in the samples to get the Resources that were updated I would do like we do in StackTach, query for the unique set of Request ID's over that time range by Tenant. From there determine which of those operations were billable actions (CUD). I think Dragon's Trigger work will make this far less expensive than it is in StackTach currently since we'll be able to create a Request Resource (each Request will have a related Resource) with metadata saying this was a billable event and the tenant ID. The corresponding events to the request ID can link to this Request resource. The query should be pretty tight. That's an interesting point about triggers; I'm not sure I fully understand - the criteria would be like a 'completed billable request' and can be stored as satisfied after the notifications come through for a specific tenant? So, we would just aggregate for each tenant's billable (triggered 'bill this') events for the period? 2. Because
Re: [openstack-dev] Tempest test failing for neutron
The full suite of neutron tests is non voting; your jenkins job is failing
because of unit tests.
The reason for this failure, I believe, is the inability of querying
neutron ports by IP using a regex.
There is a blueprint for that already registered: allow filters to use
'like' operation of
sqlalchemyhttps://blueprints.launchpad.net/neutron/+spec/like-op-list
Salvatore
On 19 August 2013 13:34, Rajdeep Dua dua_rajd...@yahoo.com wrote:
On submitted a Patch for neutron test case
https://review.openstack.org/#/c/42598/
unrelated tests from tempest seem to be failing.
http://logs.openstack.org/98/42598/2/check/gate-tempest-devstack-vm-neutron-full/4388bc6/console.htmlopenstack-dev@lists.openstack.org
One of the test failure is listed below.
Any idea why this is happening and how to fix this?
==
2013-08-19 11:11:47.424 | FAIL:
tempest.api.compute.admin.test_fixed_ips.FixedIPsTestJson.test_set_reserve[gate]
2013-08-19 11:11:47.425 |
tempest.api.compute.admin.test_fixed_ips.FixedIPsTestJson.test_set_reserve[gate]
2013-08-19 11:11:47.425 |
--
2013-08-19 11:11:47.425 | _StringException: Empty attachments:
2013-08-19 11:11:47.425 | stderr
2013-08-19 11:11:47.426 | stdout
2013-08-19 11:11:47.426 |
2013-08-19 11:11:47.426 | Traceback (most recent call last):
2013-08-19 11:11:47.427 | File
tempest/api/compute/admin/test_fixed_ips.py, line 74, in test_set_reserve
2013-08-19 11:11:47.427 | resp, body =
self.client.reserve_fixed_ip(self.ip, body)
2013-08-19 11:11:47.427 | File
tempest/services/compute/json/fixed_ips_client.py, line 39, in
reserve_fixed_ip
2013-08-19 11:11:47.428 | resp, body = self.post(url, json.dumps(body),
self.headers)
2013-08-19 11:11:47.428 | File tempest/common/rest_client.py, line 259,
in post
2013-08-19 11:11:47.428 | return self.request('POST', url, headers, body)
2013-08-19 11:11:47.428 | File tempest/common/rest_client.py, line 387,
in request
2013-08-19 11:11:47.429 | resp, resp_body)
2013-08-19 11:11:47.429 | File tempest/common/rest_client.py, line 432,
in _error_checker
2013-08-19 11:11:47.429 | raise exceptions.NotFound(resp_body)
2013-08-19 11:11:47.430 | NotFound: Object not found
2013-08-19 11:11:47.430 | Details: {itemNotFound: {message: Fixed IP
10.1.0.4 not found, code: 404}}
2013-08-19 11:11:47.430 |
2013-08-19 11:11:47.431 |
___
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
[openstack-dev] Host capabilities are not getting updated
Hi, I have been trying to use some additional capabilities in host. As shown in the following link: http://russellbryantnet.wordpress.com/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/ I created a flavor and an aggregate. But when I try to boot the instance using the flavor, it results in error because ComputeCapabilitiesFilter returns 0 hosts. I investigated further and found that the host's capabilities werent being updated. How can I rectify this? ~Peeyush Gupta___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Concerning get_resources/get_meters and the Ceilometer API
On 8/20/13 6:47 PM, Jay Pipes jaypi...@gmail.com wrote: On 08/19/2013 08:27 AM, Sandy Walsh wrote: On 08/19/2013 05:08 AM, Julien Danjou wrote: On Sun, Aug 18 2013, Jay Pipes wrote: I'm proposing that in these cases, a *new* resource would be added to the resource table (and its ID inserted in meter) table with the new flavor/instance's metadata. Ah I see. Considering we're storing metadata as a serialized string (whereas it's a dict), isn't there a chance we fail? I'm not sure about the idempotence of the JSON serialization on dicts. Yeah, using a json blob should only be for immutable data. Well, to be perfectly frank, fields that store JSON blobs in a RDBMS should be reserved for: a) Data that never needs to be used in a search filter b) Data that never needs to aggregated in a group by If any part of a JSON blob doesn't meet the above, it should be removed from the JSON blob and put into its own fields in a table (or alternately, put into something like the Trait model) I'm assuming metadata can change so we'd need idempotence. I could easily see two pipelines altering metadata fields. Last write wins. :( I actually don't think metadata about resources does change, or at least, if it does change, then it describes a new resource. As an example, if an instance resource is resized from an m1.tiny to an m2.xlarge, is it still really the same resource? I would say no, it isn't...at least as far as CM should be concerned, since it consumes an entirely different pattern of metered usages now. I think it's an awesome idea to extract resource_metadata to the Trait model (since we can't very well predict the needed columns with the nature of notification payloads right now). It will allow us to search the metadata without having to get a bunch of rows, pull the JSON for each, search it, and so on. I'm trying to get a better handle on the suggestion for immutable resource metadata; some questions: 1. I build a server and it goes from a scheduling state to an active state with ~8 or 9 steps in between each with different old/new tasks and old/new states (assuming notify_on_task_state_change configured). According to this definition of a resource, a server build should create ~10 different resources because the metadata changes from step to step, correct? 2. The audit period in the metadata changes, does that warrant a resource change (maybe that doesn't belong in resource_metadata from CM's perspective)? 3. What are you thinking would be the best way to tie them all together logically as states of a server, image, etc? I'm thinking we'd have to do something like Sandy had mentioned, instance UUID, image UUID, etc. 4. I suppose the alternate question is: do we want to relate them? =] 5. If not, why? -Thomas Best, -jay ___ 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
Re: [openstack-dev] Announcing Tuskar project and PTL nominations
On 08/21/2013 02:32 PM, Tomas Sedovic wrote: Hi everyone, We would like to announce Tuskar, an OpenStack management service. Our goal is to provide an API and UI to install and manage OpenStack at larger scale: where you deal with racks, different hardware classes for different purposes (storage, memory vs. cpu-intensive compute), the burn-in process, monitoring the HW utilisation, etc. Some of this will overlap with TripleO, Ceilometer and possibly other projects. In that case, we will work with the projects to figure out the best place to fix rather than duplicating effort and playing in our own sandbox. Current status: There's a saying that if you're not embarrassed by your first release, you've shipped too late. I'm happy to say, we are quite embarrassed :-) We've got a prototype that allows us to define different hardware classes and provision the racks with the appropriate images, then add new racks and have them provisioned. We've got a Horizon dashboard plugin that shows the general direction we want to follow and we're looking into integrating Ceilometer metrics and alarms. However, we're still tossing around different ideas and things are very likely to change. Our repositories are on Stackforge: https://github.com/stackforge/tuskar https://github.com/stackforge/python-tuskarclient https://github.com/stackforge/tuskar-ui And we're using Launchpad to manage our bugs and blueprints: https://launchpad.net/tuskar https://launchpad.net/tuskar-ui If you want to talk to us, pop in the #tuskar IRC channel on Freenode or send an email to openstack-...@lists.launchpad.net with [Tuskar] in the subject. A typo in the mailing list name, sorry. I meant: openstack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev PTL: Talking to OpenStack developers, we were advised to elect the PTL early. Since we're nearing the end of the Havana cycle, we'll elect the PTL for a slightly longer term -- the rest of Havana and throughout Icehouse. The next election will coincide with those of the official OpenStack projects. If you are a Tuskar developer and want to nominate yourself, please send an email to openstack-...@lists.launchpad.net with subject Tuskar PTL candidacy. The self-nomination period will end on Monday, 26th August 2013, 23:59 UTC. -- Tomas Sedovic ___ 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
Re: [openstack-dev] [Openstack][keystone][LDAP] Error about enable and desc attribute type undefine.
If you miss only the 'enabled' attribute you can just turn on 'user_enabled_emulation' in [ldap] section of your config. This way you won't need to modify LDAP schema in your server. On Wed, Aug 21, 2013 at 2:06 PM, Qinglong.Meng mengql112...@gmail.comwrote: I got the solution, There is not 'enable' attribute in objectClass inetOrgPerson of openldap inetOrgPerson schema. Now everything is OK. 2013/8/21 XINYU ZHAO xyzje...@gmail.com Which release are you using? According to my experience last year when ldap backend was much more premature, i had to add those attributes in my ldap server's manually, because there is no such attribute in its schema. I don't know the status now. On Mon, Aug 19, 2013 at 11:42 PM, Qinglong.Meng mengql112...@gmail.comwrote: Hi all, I configure keystone with ldap backend followed LDAP section of http://docs.openstack.org/developer/keystone/configuration.html, and when I create tenant in ldap, I got the error about enable and desc attribute type undefined in keystone.log. Here is keystone.conf: http://paste.openstack.org/show/44574/ keystone.log http://paste.openstack.org/show/44575/ the ldif of ldap server http://paste.openstack.org/show/44578/ sample slapd.conf http://paste.openstack.org/show/44579/ -- Lawrency Meng mail: mengql112...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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 -- Lawrency Meng mail: mengql112...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] [ceilometer] Periodic Auditing In Glance
On Mon, Aug 19, 2013 at 3:06 PM, Sandy Walsh sandy.wa...@rackspace.comwrote:
On 08/16/2013 04:58 PM, Doug Hellmann wrote:
The notification messages don't translate 1:1 to database records. Even
if the notification payload includes multiple resources, we will store
those as multiple individual records so we can query against them. So it
seems like sending individual notifications would let us distribute the
load of processing the notifications across several collector instances,
and won't have any effect on the data storage requirements.
Well, they would. Each .exists would result in a Event record being
stored with the underlying raw json (pretty big) at the very least.
Ah, you're right, I forgot about the new event table. I was just thinking
of the samples.
Doug
Like Alex said, if each customer has a daily week-long rolling backup
over 100k instances that's 700k .exists records.
We have some ideas we're kicking around internally about alternative
approaches, but right now I think we have to design for 1 glance .exists
per image (worst case) or 1 glance event per tenant (better case) and
hope that deploying per-cell will help spread the load ... but it'll
suck for making aggregated reports per region.
Phil, like Doug said, I don't think switching from per-instance to
per-tenant or anything else will really affect the end result. The
event-meter mapping will have to break it down anyway.
-S
Doug
On Thu, Aug 15, 2013 at 11:58 AM, Alex Meade alex.me...@rackspace.com
mailto:alex.me...@rackspace.com wrote:
I don't know any actual numbers but I would have the concern that
images tend to stick around longer than instances. For example, if
someone takes daily snapshots of their server and keeps them around
for a long time, the number of exists events would go up and up.
Just a thought, could be a valid avenue of concern.
-Alex
-Original Message-
From: Doug Hellmann doug.hellm...@dreamhost.com
mailto:doug.hellm...@dreamhost.com
Sent: Thursday, August 15, 2013 11:17am
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] [ceilometer] Periodic Auditing
In Glance
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Nova generates a single exists event for each instance, and that
doesn't
cause a lot of trouble as far as I've been able to see.
What is the relative number of images compared to instances in a
typical
cloud?
Doug
On Tue, Aug 13, 2013 at 7:20 PM, Neal, Phil phil.n...@hp.com
mailto:phil.n...@hp.com wrote:
I'm a little concerned that a batch payload won't align with
exists
events generated from other services. To my recollection, Cinder,
Trove and
Neutron all emit exists events on a per-instance basisa
consumer would
have to figure out a way to handle/unpack these separately if they
needed a
granular feed. Not the end of the world, I suppose, but a bit
inconsistent.
And a minor quibble: batching would also make it a much bigger
issue if a
consumer missed a notificationthough I guess you could
counteract that
by increasing the frequency (but wouldn't that defeat the purpose?)
On 08/13/2013 04:35 PM, Andrew Melton wrote:
I'm just concerned with the type of notification you'd send.
It has to
be enough fine grained so we don't lose too much information.
It's a tough situation, sending out an image.exists for each
image with
the same payload as say image.upload would likely create TONS
of
traffic.
Personally, I'm thinking about a batch payload, with a bare
minimum of
the
following values:
'payload': [{'id': 'uuid1', 'owner': 'tenant1', 'created_at':
'some_date', 'size': 1},
{'id': 'uuid2', 'owner': 'tenant2',
'created_at':
'some_date', 'deleted_at': 'some_other_date', 'size':
2}]
That way the audit job/task could be configured to emit in
batches
which
a deployer could tweak the settings so as to not emit too many
messages.
I definitely welcome other ideas as well.
Would it be better to group by tenant vs. image?
One .exists per tenant that contains all the images owned by
that tenant?
-S
Thanks,
Andrew Melton
On Tue, Aug 13, 2013 at
Re: [openstack-dev] Osl and dangerous code merging
IIUC, git sub-modules point to a specific revision of the external repository, right? So would projects still have to explicitly update to newer versions of the incubator code by changing that sub-module reference? With the copy process we have now it is possible to update only part of the incubator code in a project. Is that a feature we would want to retain if using sub-modules? Doug On Tue, Aug 20, 2013 at 7:27 AM, Roman Bogorodskiy rbogorods...@mirantis.com wrote: FWIW, I've created a sample project using olso as a submodule: https://github.com/novel/oslo-helloworld I spotted some minor difficulties: 1. As olso directory layout is not designed to be used as a submodule, a symlink has to be created to place code to the proper location 2. sys.path hack has to be applied for proper imports On Thu, Aug 8, 2013 at 2:39 PM, Mark McLoughlin mar...@redhat.com wrote: What do you mean by dangerous code merging in the subject? The body of your mail doesn't make any reference to whatever danger you're seeing. On Thu, 2013-08-08 at 14:16 +0400, Boris Pavlovic wrote: Hi All, Could somebody answer me, why we are merging oslo code in other projects and don't use git submodules (http://git-scm.com/book/en/Git-Tools-Submodules) The idea of using submodules has come a few times. I don't have a fundamental objection to it, except any time I've seen submodules used in a project they've been extremely painful for everyone involved. I'd be happy to look at a demo of a submodule based system for projects to use code from oslo-incubator. Mark. ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Stats on blueprint design info / creation times
On Mon, Aug 19, 2013 at 11:47 AM, Daniel P. Berrange berra...@redhat.comwrote: In this thread about code review: http://lists.openstack.org/pipermail/openstack-dev/2013-August/013701.html I mentioned that I thought there were too many blueprints created without sufficient supporting design information and were being used for tickbox process compliance only. I based this assertion on a gut feeling I have from experiance in reviewing. To try and get a handle on whether there is truely a problem, I used the launchpadlib API to extract some data on blueprints [1]. In particular I was interested in seeing: - What portion of blueprints have an URL containing an associated design doc, - How long the descriptive text was in typical blueprints - Whether a blueprint was created before or after the dev period started for that major release. The first two items are easy to get data on. On the second point, I redid line wrapping on description text to normalize the line count across all blueprints. This is because many blueprints had all their text on one giant long line, which would skew results. I thus wrapped all blueprints at 70 characters. The blueprint creation date vs release cycle dev start date is a little harder. I inferred the start date of each release, by using the end date of the previous release. This is probably a little out but hopefully not by enough to totally invalidate the usefulness of the stats below. Below, Early means created before start of devel, Late means created after the start of devel period. The data for the last 3 releases is: Series: folsom Specs: 178 Specs (no URL): 144 Specs (w/ URL): 34 Specs (Early): 38 Specs (Late): 140 Average lines: 5 Average words: 55 Series: grizzly Specs: 227 Specs (no URL): 175 Specs (w/ URL): 52 Specs (Early): 42 Specs (Late): 185 Average lines: 5 Average words: 56 Series: havana Specs: 415 Specs (no URL): 336 Specs (w/ URL): 79 Specs (Early): 117 Specs (Late): 298 Average lines: 6 Average words: 68 Looking at this data there are 4 key take away points - We're creating more blueprints in every release. - Less than 1 in 4 blueprints has a link to a design document. - The description text for blueprints is consistently short (6 lines) across releases. - Less than 1 in 4 blueprints is created before the devel period starts for a release. You can view the full data set + the script to generate the data which you can look at to see if I made any logic mistakes: http://berrange.fedorapeople.org/openstack-blueprints/ There's only so much you can infer from stats like this, but IMHO think the stats show that we ought to think about how well we are using blueprints as design / feature approval / planning tools. That 3 in 4 blueprint lack any link to a design doc and have only 6 lines of text description, is a cause for concern IMHO. The blueprints should be giving code reviewers useful background on the motivation of the dev work any design planning that took place. While there are no doubt some simple features where 6 lines of text is sufficient info in the blueprint, I don't think that holds true for the majority. How many of those blueprints without links or expansive documentation are related to some other blueprint that does have documentation? In ceilometer, we have several blueprint clusters where one main blueprint has some documentation and the others are present for assigning and scheduling the work of a multi-part feature, or vice versa. For example, https://blueprints.launchpad.net/ceilometer/+spec/alarming has no real doc because it's an umbrella blueprint for a lot of other pieces, many of which *do* have documentation. Doug In addition to helping code reviewers, the blueprints are also arguably a source of info for QA people testing OpenStack and for the docs teams documenting new features in each release. I'm not convinced that there is enough info in many of the blueprints to be of use to QA / docs people. The creation dates of the blueprints are also an interesting data point. If the design summit is our place for reviewing blueprints and 3 in 4 blueprints in a release are created after the summit, that's alot of blueprints potentially missing summit discussions. On the other hand many blueprints will have corresponding discussions on mailing lists too, which is arguably just as good, or even better than, summit discussions. Based on the creation dates though terseness of design info, I think there is a valid concern here that blueprints are being created just for reason of tickbox process compliance. In theory we have an approval process for blueprints, but are we ever rejecting code submissions for blueprints which are not yet approved ? I've only noticed that happen a couple of times in Nova
Re: [openstack-dev] [keystone] [oslo] postpone key distribution bp until icehouse?
Dolph Mathews wrote: With regard to: https://blueprints.launchpad.net/keystone/+spec/key-distribution-server [...] Dolph: you don't mention Barbican at all, does that mean that the issue is settled and the KDS should live in keystone ? Dolph and I talked about having a design session to talk about how Barbican and Keystone will work together going forward. In this particular case, as I understand it, Simo is right. There isn't much need for Barbican to be involved in the PKI key signing (except maybe for key storage at some point, but that wouldn't' require a lot of changes if we did that). Once the sessions are opened for Hong Kong, we'll put in for the design session. Jarret ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Osl and dangerous code merging
On 2013-08-21 10:03, Julien Danjou wrote: On Wed, Aug 21 2013, Doug Hellmann wrote: IIUC, git sub-modules point to a specific revision of the external repository, right? Yes. So would projects still have to explicitly update to newer versions of the incubator code by changing that sub-module reference? Yes. With the copy process we have now it is possible to update only part of the incubator code in a project. Is that a feature we would want to retain if using sub-modules? We'd lose it indeed. OTOH, it seems _relatively_ dangerous to me to update part of Oslo-incubator like we do, considering the possible dependencies between files. That can be an issue, but on the other hand when a mass sync is done there's almost no way to keep track of all the changes involved, so I think in some circumstances it can be better to do individual modules. At least that way the person doing the sync is presumably familiar with the code they're syncing and has a handle on the dependencies (and potential changes needed in the target project). Just a counterpoint. Not sure it's a sufficient argument to stop this if we want to move forward with it. -Ben ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [oslo] postpone key distribution bp until icehouse?
On Wed, Aug 21, 2013 at 10:44 AM, Jarret Raim jarret.r...@rackspace.comwrote: Dolph Mathews wrote: With regard to: https://blueprints.launchpad.net/keystone/+spec/key-distribution-server [...] Dolph: you don't mention Barbican at all, does that mean that the issue is settled and the KDS should live in keystone ? Dolph and I talked about having a design session to talk about how Barbican and Keystone will work together going forward. In this particular case, as I understand it, Simo is right. There isn't much need for Barbican to be involved in the PKI key signing (except maybe for key storage at some point, but that wouldn't' require a lot of changes if we did that). +1 Once the sessions are opened for Hong Kong, we'll put in for the design session. Jarret ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Osl and dangerous code merging
On Aug 21, 2013, at 8:03 AM, Julien Danjou jul...@danjou.info wrote: On Wed, Aug 21 2013, Doug Hellmann wrote: IIUC, git sub-modules point to a specific revision of the external repository, right? Yes. So would projects still have to explicitly update to newer versions of the incubator code by changing that sub-module reference? Yes. With the copy process we have now it is possible to update only part of the incubator code in a project. Is that a feature we would want to retain if using sub-modules? We'd lose it indeed. OTOH, it seems _relatively_ dangerous to me to update part of Oslo-incubator like we do, considering the possible dependencies between files. My 2c, Keeping the same functionality would mean that each of the oslo-incubator directories would be its own submodule. Vish -- Julien Danjou -- Free Software hacker - independent consultant -- http://julien.danjou.info ___ 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
Re: [openstack-dev] Stats on blueprint design info / creation times
For the case of an item that has no significant doc of its own but is related to an extensive blueprint, how about linking to that extensive blueprint? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [oslo] postpone key distribution bp until icehouse?
On 08/21/2013 11:44 AM, Jarret Raim wrote: Dolph Mathews wrote: With regard to: https://blueprints.launchpad.net/keystone/+spec/key-distribution-server [...] Dolph: you don't mention Barbican at all, does that mean that the issue is settled and the KDS should live in keystone ? Dolph and I talked about having a design session to talk about how Barbican and Keystone will work together going forward. In this particular case, as I understand it, Simo is right. There isn't much need for Barbican to be involved in the PKI key signing (except maybe for key storage at some point, but that wouldn't' require a lot of changes if we did that). KDS keys are not signed. They are symmetric. We are writing the KDS code sa a stand alone extension, such that if we change our mind about where it lives, we can migrate it without too much disruption. However, I am pretty certain that it belongs in Keystone. THis is confirmation of identity for services, and it probably will interoperate with the service catalog over time. Keystone doesn't have a concept of a Service Principal the way that Kerberos does, but the KDS code really introduces that concept, and I think it will be important for more complex authorization rules in the future. Once the sessions are opened for Hong Kong, we'll put in for the design session. Jarret ___ 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
[openstack-dev] [OSSG] ASK - What is the regular OSSG IRC meetup schedule? #TIA
-- Thanks, -Sriram ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Osl and dangerous code merging
On 21/08/13 16:07, Doug Hellmann wrote: IIUC, git sub-modules point to a specific revision of the external repository, right? So would projects still have to explicitly update to newer versions of the incubator code by changing that sub-module reference? Normally - Yes. With Gerrit - Maybe. Gerrit supports auto-updating submodule pointers in other gerrit hosted repos. But.. There are gottchas. The big one being, I don't think it's something that can be gated on.. Even if Gerrit was to make it *really easy* and testable .. I'd vote against any attempt to bring submodules into our repositories. I can use them, and have used them successfully with teams in the past. But it wasn't worth it. Training every new person in, and dealing with the inevitable mistakes was just too much effort. With a team the size of OpenStack's, this will be totally unmanageable IMO. Thanks, Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OSSG] ASK - What is the regular OSSG IRC meetup schedule? #TIA
Thanks Bryan, would like to get involved more. Meet you tomorrow at 10 am PST/ 1800 UTC. On Wed, Aug 21, 2013 at 11:07 AM, Bryan D. Payne bdpa...@acm.org wrote: Thursdays at 1800 UTC. https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity -bryan On Wed, Aug 21, 2013 at 10:57 AM, Sriram Subramanian sri...@sriramhere.com wrote: -- Thanks, -Sriram ___ 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 -- Thanks, -Sriram ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Osl and dangerous code merging
Mac Innes, Kiall wrote: Even if Gerrit was to make it *really easy* and testable .. I'd vote against any attempt to bring submodules into our repositories. I can use them, and have used them successfully with teams in the past. But it wasn't worth it. Training every new person in, and dealing with the inevitable mistakes was just too much effort. With a team the size of OpenStack's, this will be totally unmanageable IMO. +1 -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Osl and dangerous code merging
Hi, Really sorry, but I don't understand why using some specific oslo sync util is simpler then git submodules?) I mean this two things are almost the same but: In case of oslo we are copy-pasting code In case of submodules we are bumping commit hashs So why submodules are terrible and oslo-sync is good?=) Where is so big difference, and could somebody explain me? (I mean real use cases from life where oslo sync is good and submodules are bad) Thanks. Best regards, Boris Pavlovic --- Mirantis Inc. On Wed, Aug 21, 2013 at 10:26 PM, Thierry Carrez thie...@openstack.orgwrote: Mac Innes, Kiall wrote: Even if Gerrit was to make it *really easy* and testable .. I'd vote against any attempt to bring submodules into our repositories. I can use them, and have used them successfully with teams in the past. But it wasn't worth it. Training every new person in, and dealing with the inevitable mistakes was just too much effort. With a team the size of OpenStack's, this will be totally unmanageable IMO. +1 -- Thierry Carrez (ttx) ___ 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
Re: [openstack-dev] Stats on blueprint design info / creation times
+100 If one blueprint points to another, then the pointers should be present and available in both blueprints. Dependency linking, folks. --Rocky From: Mike Spreitzer [mailto:mspre...@us.ibm.com] Sent: Wednesday, August 21, 2013 9:04 AM To: Daniel P. Berrange Cc: OpenStack Development Mailing List Subject: Re: [openstack-dev] Stats on blueprint design info / creation times For the case of an item that has no significant doc of its own but is related to an extensive blueprint, how about linking to that extensive blueprint? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] tarballs of savanna-extra
IMHO, the jars should be served from the Apache Hadoop community. I don't know what hoops have to jumped through for that though. It may be far simpler to put them in the mirantis CDN. Best, matt On 08/21/2013 02:21 PM, Sergey Lukjanov wrote: Agreed that storing Hadoop-Swift integration jars in the git repo is a good practice, any thoughts about where to store them? Currently I have only one option - we can store them at the public CDN (savanna-files.mirantis.com) near the images for vanilla plugin. As for publishing tarballs with the content of savanna-extra - looks like there are more pros than cons, so, we can do it. Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. On Aug 20, 2013, at 16:31, Matthew Farrellee m...@redhat.com wrote: Is there a downside to having it? A positive is it gives a snapshot of everything for each release. I'm not at fan of having a snapshot of the Hadoop swift patches compiled into a jar and stored in the repository. I'd prefer that it is hosted elsewhere. Best, matt On 08/19/2013 04:37 PM, Sergey Lukjanov wrote: Hi Matt, it is not an accident that savanna-extra has no tarballs at tarballs.o.o, because this repo is used for storing some date that is only needed for some stuff like building images for vanilla plugin, storing Swift support patch for Hadoop and etc. So, it looks like that we should not package all of them to one heterogeneous tarball. Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. On Aug 20, 2013, at 0:25, Matthew Farrellee m...@redhat.com wrote: Will someone setup a tarballs.os.o release of savanna-extra's master (https://github.com/stackforge/savanna-extra), and make sure it gets an official release for 0.3? Best, matt ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Osl and dangerous code merging
On 21/08/13 19:48, Boris Pavlovic wrote: So why submodules are terrible and oslo-sync is good?=) I think the biggest mistake people make with submodules, which oslo's sync avoids, is dropping commits / Going backwards / Switching branches on submodule - or worse - pointing at a detached commit. Olso's sync results in a diff.. Here's what happens when you switch a submodule: $ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: cookbooks (new commits) $ git diff diff --git a/cookbooks b/cookbooks index e9e667f..3c3156a 16 --- a/cookbooks +++ b/cookbooks @@ -1 +1 @@ -Subproject commit e9e667f51283abb2e2f174c68adaec683098bcd1 +Subproject commit 3c3156ac0c67ee2334b52fd8e2d298d3433b4281 And WORSE! That submodule is now pointing to a detached commit. Getting developers - the hundreds of developers involved in OpenStack - to understand and appreciate this issue, and about 50 other issues, is not time spent well. Time that will need to be spent over and over again as OpenStack gains more and more developers. Thanks, Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Stackalytics] 0.2 release
Hello everyone! We are excited to present the new release of Stackalyticshttp://www.stackalytics.com/- 0.2. One of major features of this release is review processing. It gives data on who reviews most, distribution of reviews by engineers or by modules, what is the ratio of positive to negative marks. Also the service now shows all projects from OpenStack world - nearly 150 active projects! And the last but not the least - filtering options are made more intuitive, user may slice the stats by release, project type, module, company, engineer and, of course, by metric. Full release notes are below: - Changed internal architecture. Got rid of persistent storage in Mongo. Configuration file default_data.jsonhttps://github.com/Mirantis/stackalytics/blob/master/etc/default_data.jsonnow serves as persistent storage. - Added polling of Gerrit for retrieval of review related source data. - Implemented basic statistics for reviews: number of reviews over time, number of negative/positive review, ratio of positive and negative reviews. - Redesigned navigation and layout of statistics pages. - Implemented auto-assignment of commits to release cycles based on dates. - Implemented automated retrieval of projects list from GitHub API. - Cleanup of default_data.json (reduced from 14k LOC to 4k) - Added to corrections.json all commits which are over 3k LOC and looks like auto-generated. - Implemented feature request Sort bugs ID as numbers, not as stringshttps://bugs.launchpad.net/stackalytics/+bug/1204926 - Fixed bunch deletion from memcachedhttps://bugs.launchpad.net/stackalytics/+bug/1209211 More details on the architecture are on project's wiki: https://wiki.openstack.org/wiki/Stackalytics And certainly welcome everyone who wants to run the service on their own: https://wiki.openstack.org/wiki/Stackalytics/HowToRun We currently gather feature requests for version 0.3 - feel free to post blueprint to project's space at launchpad: https://launchpad.net/stackalytics/ Thanks, Ilya ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Swift] team meeting notes
Notes from today's meeting are at http://eavesdrop.openstack.org/meetings/swift/2013/swift.2013-08-21-19.01.html --John signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] can openstack compute manage both physical and machine machines?
Qing, you can take a look at this link: https://wiki.openstack.org/wiki/Baremetal Yapeng From: Qing He [mailto:qing...@radisys.com] Sent: Wednesday, August 21, 2013 2:23 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] can openstack compute manage both physical and machine machines? All, From the documents, It seems to me Nova can only manage virtual machines, but not mixed with physical machines. Am I wrong? Thanks, Qing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Nova master appears to fail PEP8 compliance
Attempting to submit code to Nova, I got the following error from Jenkins: 2013-08-21 17:23:55.604 | pep8 runtests: commands[0] | flake8 2013-08-21 17:23:55.615 | /home/jenkins/workspace/gate-nova-pep8$ /home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8 2013-08-21 17:25:44.400 | ./nova/tests/compute/test_compute_api.py:535:10: H202 assertRaises Exception too broad 2013-08-21 17:25:44.879 | ERROR: InvocationError: '/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8' 2013-08-21 17:25:44.880 | pep8 runtests: commands[1] | /home/jenkins/workspace/gate-nova-pep8/tools/config/check_uptodate.sh 2013-08-21 17:25:44.884 | /home/jenkins/workspace/gate-nova-pep8$ /home/jenkins/workspace/gate-nova-pep8/tools/config/check_uptodate.sh 2013-08-21 17:25:48.466 | ___ summary 2013-08-21 17:25:48.466 | ERROR: pep8: commands failed Since I did not modify test_compute_api.py it seems that the problem is with the Nova master branch. My code was branched from commit 8f47cb6399. Dan smime.p7s Description: S/MIME Cryptographic Signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] Team meeting reminder August 22 18:00 UTC
Hi folks, We'll be have the Savanna team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_August.2C_22 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meetingiso=20130822T18 Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]can you create network between a VM and a physical machine in neutron?
Thanks Aaron! From: Aaron Rosen [mailto:aro...@nicira.com] Sent: Wednesday, August 21, 2013 12:24 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron]can you create network between a VM and a physical machine in neutron? Hi, Yes, if you use the providernetwork extension you can create a network on a vlan and have physical hosts accessible on that vlan. If using the NVP plugin another option is to use its networkgw extension to do this in conjunction with overlay networks. Aaron On Wed, Aug 21, 2013 at 11:25 AM, Qing He qing...@radisys.commailto:qing...@radisys.com wrote: All, I'm trying to find way to create a network with a mixture of VM and physical machines. Is this possible? Thanks, Qing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [Nova] can openstack compute manage both physical and machine machines?
Thanks, Yapeng! From: Yapeng Wu [mailto:yapeng...@huawei.com] Sent: Wednesday, August 21, 2013 1:20 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] can openstack compute manage both physical and machine machines? Qing, you can take a look at this link: https://wiki.openstack.org/wiki/Baremetal Yapeng From: Qing He [mailto:qing...@radisys.com]mailto:[mailto:qing...@radisys.com] Sent: Wednesday, August 21, 2013 2:23 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] can openstack compute manage both physical and machine machines? All, From the documents, It seems to me Nova can only manage virtual machines, but not mixed with physical machines. Am I wrong? Thanks, Qing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] LXC host device passthrough
Hi, We are considering the LXC host device passthrough for GPU. Is anybody already working on this LXC host device passthrough? If it is not already done, we are interested in implementing this LXC host device passthrough. We want to get some opinions/comments about LXC host device passthrough. We think LXC host device passthrough is similar to KVM pci-passthrough, and can share much code for KVM PCI Passthrough: https://review.openstack.org/#/q/topic:pci-passthrough-enhancement,n,z We think it can be done by adding some code for LXC passthrough to the KVM pci-passthrough code by updating codes under nova/pci/ and creates a few more files. Maybe DB, scheduler, and object support wise, they can be adapted for LXC host device by adding one more table. Any better idea? Thanks, Mikyung ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Oslo.db] Configuration options
Another question related to making oslo.db a pypi library and relevant to how
taskflow is used.
Currently taskflow has a persistence layer, its using a copy of oslo-incubator
db module to do this.
That copied code (soon to be library I hope) has the following:
db_opts = [
cfg.StrOpt('backend',
default='sqlalchemy',
deprecated_name='db_backend',
deprecated_group='DEFAULT',
help='The backend to use for db'),
cfg.BoolOpt('use_tpool',
default=False,
deprecated_name='dbapi_use_tpool',
deprecated_group='DEFAULT',
help='Enable the experimental use of thread pooling for '
'all DB API calls')
]
Now if oslo.db is a library, and taskflow and the integrated project want to
use a database backend (potentially a different one) how would that be possible
with a single library configuration?
It would seem like the configuration done like this would not allow for that,
and I could see taskflow having local sqlite as its backend (different DB
config in this case, same backend), while the integrated project using mysql
(for whatever its storing).
Would something like that be possible?
Thoughts??
-josh
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Incubation Request: Marconi
Technical Committee Members and OpenStack Contributors, As you may already know, over the last seven months, contributors from a variety of companies and backgrounds have been designing and developing the Marconi project, a highly-scalable and redundant messaging service. Marconi was proposed and discussed at the Grizzly design summit to address a critical gap in the OpenStack portfolio. Since 2010, we've seen increasingly-large companies adopting OpenStack for their increasingly-complex, distributed applications. Such applications often rely on message queueing to decouple components, but OpenStack currently provides no solution for doing so as part of its integrated release. Consequently, OpenStack end-users and operators have been forced to either piece together queuing systems on their own, or look outside the open community to proprietary options like Amazon's SQS. This not only duplicates effort, but also reduces application portability between OpenStack deployments. Therefore, we would like to request that the Marconi project be considered for incubation to become an official OpenStack project. Our application is now available on the OpenStack wiki for review: https://wiki.openstack.org/wiki/Marconi/Incubation We really appreciate your time and consideration, and look forward to your feedback on the project! -- Kurt G. (on behalf of the Marconi team) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OSSG] ASK - What is the regular OSSG IRC meetup schedule? #TIA
FYI, currently 1800 UTC is 11a Pacific. Hopefully you can still make it. Cheers, -bryan On Wed, Aug 21, 2013 at 11:20 AM, Sriram Subramanian sri...@sriramhere.comwrote: Thanks Bryan, would like to get involved more. Meet you tomorrow at 10 am PST/ 1800 UTC. On Wed, Aug 21, 2013 at 11:07 AM, Bryan D. Payne bdpa...@acm.org wrote: Thursdays at 1800 UTC. https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity -bryan On Wed, Aug 21, 2013 at 10:57 AM, Sriram Subramanian sri...@sriramhere.com wrote: -- Thanks, -Sriram ___ 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 -- Thanks, -Sriram ___ 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
[openstack-dev] [State-Management] Agenda for tomorrows meeting at 2000 UTC
Hi all, The [state-management] project team holds a weekly meeting in #openstack-meeting on thursdays, 2000 UTC. The next meeting is tomorrow, Aug 22!!! As usual, everyone is welcome :-) Link: https://wiki.openstack.org/wiki/Meetings/StateManagement Taskflow: https://wiki.openstack.org/TaskFlow ## Agenda (30-60 mins): ## - Discuss any action items from last meeting. - Discuss ongoing status of the overall effort and any needed coordination. - Talk about progress with regards to cinder/nova/ironic/heat/trove integration. - Discuss about any other potential new use-cases for said library. - Discuss about any other ideas, problems, issues, solutions, reviews, questions (and more). Any other topics are welcome :-) See you all soon! -Josh ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo.db] Configuration options
Josh thanks for highlighting this. This example is a good reason why oslo
libraries should decouple their useful bits from any configuration
assumptions. Much of the code already allows use without requiring you to
adopt configuration code. But we should make all of it like that.
On Wed, Aug 21, 2013 at 3:42 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:
Another question related to making oslo.db a pypi library and relevant
to how taskflow is used.
Currently taskflow has a persistence layer, its using a copy of
oslo-incubator db module to do this.
That copied code (soon to be library I hope) has the following:
db_opts = [
cfg.StrOpt('backend',
default='sqlalchemy',
deprecated_name='db_backend',
deprecated_group='DEFAULT',
help='The backend to use for db'),
cfg.BoolOpt('use_tpool',
default=False,
deprecated_name='dbapi_use_tpool',
deprecated_group='DEFAULT',
help='Enable the experimental use of thread pooling for '
'all DB API calls')
]
Now if oslo.db is a library, and taskflow and the integrated project
want to use a database backend (potentially a different one) how would that
be possible with a single library configuration?
It would seem like the configuration done like this would not allow for
that, and I could see taskflow having local sqlite as its backend
(different DB config in this case, same backend), while the integrated
project using mysql (for whatever its storing).
Would something like that be possible?
Thoughts??
-josh
___
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
Re: [openstack-dev] [Openstack][keystone][ssl] Help for configure keystone with ssl.
Yes, I only get 2013.2.b1 from git tags. 2013/8/21 ZhiQiang Fan aji.zq...@gmail.com 2013.2 should be in havana? On Wed, Aug 21, 2013 at 6:13 PM, Qinglong.Meng mengql112...@gmail.comwrote: Hi All, Os: ubuntu 12.04 LTS keystone version: stable/grizzly Ｉ hava seen keystone-manage ssl_setup in keystone tag 2013.2.b1. but I can't use it in my version. So I want to know: * how to configure ssl with keystone manual? * how to test configure is ok? Tks for you help. Best Regards, -- Lawrency Meng mail: mengql112...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- blog: zqfan.github.com git: github.com/zqfan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Lawrency Meng mail: mengql112...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][keystone][LDAP] Error about enable and desc attribute type undefine.
Tks for you reply, Can you tall me more about user_enable_emulation in keystone.conf? Best Regards, 2013/8/21 Yuriy Taraday yorik@gmail.com If you miss only the 'enabled' attribute you can just turn on 'user_enabled_emulation' in [ldap] section of your config. This way you won't need to modify LDAP schema in your server. On Wed, Aug 21, 2013 at 2:06 PM, Qinglong.Meng mengql112...@gmail.comwrote: I got the solution, There is not 'enable' attribute in objectClass inetOrgPerson of openldap inetOrgPerson schema. Now everything is OK. 2013/8/21 XINYU ZHAO xyzje...@gmail.com Which release are you using? According to my experience last year when ldap backend was much more premature, i had to add those attributes in my ldap server's manually, because there is no such attribute in its schema. I don't know the status now. On Mon, Aug 19, 2013 at 11:42 PM, Qinglong.Meng mengql112...@gmail.comwrote: Hi all, I configure keystone with ldap backend followed LDAP section of http://docs.openstack.org/developer/keystone/configuration.html, and when I create tenant in ldap, I got the error about enable and desc attribute type undefined in keystone.log. Here is keystone.conf: http://paste.openstack.org/show/44574/ keystone.log http://paste.openstack.org/show/44575/ the ldif of ldap server http://paste.openstack.org/show/44578/ sample slapd.conf http://paste.openstack.org/show/44579/ -- Lawrency Meng mail: mengql112...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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 -- Lawrency Meng mail: mengql112...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Lawrency Meng mail: mengql112...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [swift] temp auth tokens expire immediately
Ok - in /etc/memcache.conf IP to listen on needs to be 0.0.0.0 not the actual node IP address. # IP to listen on -l 0.0.0.0 Thx. From: Snider, Tim Sent: Wednesday, August 21, 2013 5:08 PM To: openstack-dev@lists.openstack.org Subject: [swift] temp auth tokens expire immediately I've reconfigured my swift cluster and restarted memcache service on all the swift nodes. Now I have temp auth tokens expiring immeadiately. I've checked memcache server lines in /etc/swift/proxy-service.conf - those seem to be sane. What am I missing? root@controller11:~/ssbench-0.2.16#mailto:root@controller11:~/ssbench-0.2.16# curl -v -H 'X-Storage-User: test:tester' -H 'X-Storage-Pass: testing' http://192.168.10.68:8080/auth/v1.0 * About to connect() to 192.168.10.68 port 8080 (#0) * Trying 192.168.10.68... connected GET /auth/v1.0 HTTP/1.1 User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: 192.168.10.68:8080 Accept: */* X-Storage-User: test:tester X-Storage-Pass: testing HTTP/1.1 200 OK X-Storage-Url: http://192.168.10.88:8080/v1/AUTH_test X-Storage-Token: AUTH_tk768c95e7330f46efa88d82787a34e9e4 X-Auth-Token: AUTH_tk768c95e7330f46efa88d82787a34e9e4 X-Trans-Id: tx450df531523b450eaa966b3365250f80 Content-Length: 0 Date: Wed, 21 Aug 2013 22:00:38 GMT * Connection #0 to host 192.168.10.68 left intact * Closing connection #0 root@controller11:~/ssbench-0.2.16#mailto:root@controller11:~/ssbench-0.2.16# curl -v -H 'X-Storage-User: test:tester' -H 'X-Storage-Pass: testing' http://192.168.10.68:8080/auth/v1.0 * About to connect() to 192.168.10.68 port 8080 (#0) * Trying 192.168.10.68... connected GET /auth/v1.0 HTTP/1.1 User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: 192.168.10.68:8080 Accept: */* X-Storage-User: test:tester X-Storage-Pass: testing HTTP/1.1 200 OK X-Storage-Url: http://192.168.10.87:8080/v1/AUTH_test X-Storage-Token: AUTH_tk21ef1ade731e462e91d8d6d3a1d8cbbe X-Auth-Token: AUTH_tk21ef1ade731e462e91d8d6d3a1d8cbbe X-Trans-Id: txe513acba005f42d298eb7c563bb1e6a3 Content-Length: 0 Date: Wed, 21 Aug 2013 22:00:39 GMT * Connection #0 to host 192.168.10.68 left intact * Closing connection #0 root@controller11:~/ssbench-0.2.16#mailto:root@controller11:~/ssbench-0.2.16# curl -v -H 'X-Storage-User: test:tester' -H 'X-Storage-Pass: testing' http://192.168.10.68:8080/auth/v1.0 * About to connect() to 192.168.10.68 port 8080 (#0) * Trying 192.168.10.68... connected GET /auth/v1.0 HTTP/1.1 User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: 192.168.10.68:8080 Accept: */* X-Storage-User: test:tester X-Storage-Pass: testing HTTP/1.1 200 OK X-Storage-Url: http://192.168.10.88:8080/v1/AUTH_test X-Storage-Token: AUTH_tkf433982fff3d484591826d1a02e54f7c X-Auth-Token: AUTH_tkf433982fff3d484591826d1a02e54f7c X-Trans-Id: txc009e567a213466a9de01ab14004c053 Content-Length: 0 Date: Wed, 21 Aug 2013 22:00:41 GMT * Connection #0 to host 192.168.10.68 left intact * Closing connection #0 root@controller11:~/ssbench-0.2.16#mailto:root@controller11:~/ssbench-0.2.16# Thanks, Tim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] object-oriented design in nova--room for improvement?
There is always room for improvement I hope ;) +openstack-dev (I think where u wanted this to go). A question, are u thinking about organizing the 'metadata' associated with resources? If so it might be interesting to see if there could be a grand unification around something like 'ResourceTracker' 'Stats' that exposes 'metadata' (different types) via an API that all the other classes could use? Is that inline of what u are thinking?? Sort of like a resource + metadata 'database' that everyone uses (and accesses and updates via a single set of APIs). I might have misread your idea though. On 8/21/13 7:55 PM, Chris Friesen chris.frie...@windriver.com wrote: Hi, I'm pretty new to OpenStack, so maybe I'm still not grokking the overall design. Feel free to tell me I'm totally full of it. :) Anyways, I've been poking around in the code with an eye towards maybe extending the set of information exported by the compute nodes for use in scheduler filters. I started putting together a list of areas that would need to be updated, and it seems like there are quite a few separate chunks of code all over the codebase that are aware of the details of what is exported: LibvirtDriver class Claim² class ComputeNode class compute_node_statistics() in sqlalchemy/api.py ServiceCommands class (to show host resources) ResourceTracker class (to track used/free resources) Stats class FakeDriver class HostState class in libvirt/driver.py json/xml stuff in nova/doc/api_samples HostController class make_hypervisor() in compute/plugins/v3/hypervisors.py HypervisorStatisticsTemplate API class HypervisorsController API class HostController API class SchedulerManager class I've probably missed some, the above was generated looking for cases of vcpus_used. Maybe I'm dreaming, but it seems like there should be a way to do this more efficiently rather than manually copying knowledge into different parts of the code. Thoughts? Chris ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][Climate] bp:configurable-ip-allocation
Hi, everyone! We are working on Climate, and we are interested in https://blueprints.launchpad.net/neutron/+spec/configurable-ip-allocation I see two changes connected with this bp, but they both were abandoned in the beginning of the year. Can anyone give me an answer about implementation progress? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo.db] Configuration options
On Thu, 2013-08-22 at 01:14 +, Joshua Harlow wrote: Agreed, any thoughts from the oslo folks on how this could be done (without a major refactoring??). Can it even be done? It will be a continuous problem for libraries which want to be integrated with the various openstack projects, especially if those libraries use oslo code, since there is now a weird 'action at a distance' on config shared between the project and the library. To me this is one of the pain points in a global CFG object, maybe for things that oslo will 'librarize' those libraries should not have a strong coupling to said global CFG but should prefer a local config 'object' to be passed in (of which the project using the oslo library can by default pass in the global CFG object to it, if the project desires to use it this way). Take a look at the oslo.messaging API: http://docs.openstack.org/developer/oslo.messaging/transport.html See? No dependence on a global config object. And the ability to connect to alternate brokers via a transport_url. So, yes - moving any API out of oslo-incubator into a standalone library is all about cleaning up issues like this. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone] driver/pluggable base classes and ABCMeta
I've been doing some pondering on how Keystone handles the various pluggable systems with it's Manager / Driver architecture. Currently we implement the base driver class as follows: There is a driver object that has a number of reference functions defined on it, each of these functions typically raises NotImplemented() and has a docstring describing the expected behavior. A simple example of this would be the Token Driver base class. A complex example would be the Identity Driver base class. Example: class AbstractBaseClassTest(object): def abstract_method1(args, kwargs): raise NotImplemented() def abstract_method2(args, kwargs): ... This type of system is not inherently bad, nor flawed, but there are some cases when I've run into situations that raise a NotImplemented() error unexpectedly (usually in custom code I've had to write around a driver or replace a driver with and internal to my company implementation). For those not familiar with ABCMeta, abstract base classes, and the abc module: In a model that uses an abstract metaclass, the base class methods that need to be overridden are decorated with the abstractmethod decorator from the abc module. This decorator when coupled with the ABCMeta metaclass, requires all abstract methods to be overridden by the class that inherits from the base class before the class can be instantiated. Similarly there is an abstractproperty decorator for @property methods. The exception raised looks like: TypeError: Can't instantiate abstract class TestClass with abstract methods AbsTest1, AbsTest2 The benefits are two fold. First, this means that a new driver could not be implemented without overriding the expected methods (no raising NotImplemented() unintentionally) and it guarantees that even seldom-used expected functions would be defined on the driver implementations. Second benefit is that these abstract methods can be called via the standard super() call, therefore if there is some base functionality that should be used (or legitimately you want to raise NotImplemented()), it is possible to have that defined on the parent class. Example abstract base class (with using six module instead of directly setting __metaclass__): class AbstractBaseClassTest(six.with_metaclass(abc.ABCMeta)): @abc.abstractmethod def abstract_method1(int_arg): # we can do something here instead of raising # NotImplemented() return (int_arg + 1) On to the downsides, the compatibility between python2.7 and python3k (using the six library) is not the most pleasing thing to look at. It requires defining the object that inherits from a method call six.with_metaclass. I also have not looked at the performance implications of this, however, at first blush, it doesn't look like should be significant. There are possibly other pitfalls that haven't come to mind as of yet. In short, the drivers should probably be actual abstract classes, since that is what they effectively are. I've seen this functionality used in both Neutron and Ironic. I could see it providing some benefits from it in Keystone. I wanted to get the general feeling from the Mailing List on using abstracted base classes in lieu of our current implementation prior to proposing a Blueprint, etc. I don't see this as a Havana implementation but possibly something to consider for Icehouse. I don't know if the benefits really would bring us a huge win in Keystone, but I think it would make understanding what should be implemented when subclassing for driver development (and similar pluggable systems) a bit more clear. Cheers! -- Morgan Fainberg Sr. Software Architect | Metacloud, Inc Email: m...@metacloud.com IRC: morganfainberg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
