Re: [Openstack] Swift S3 with Keystone anyone?
We have a developer (Chmouel Boudjnah) working on getting S3 Auth/Keystone(light)/ACLs all working together. The hope is that we can have a viable production-ready alternative to nova-objectstore to support euca-upload-bundle. He is very close to having it all working and he was hoping to have it ready by the bugfix day, so hopefully he can respond with more info. When we have it all working, we will prepare some documentation to help out in getting things configured and perhaps add it as an option to devstack. Vish On Feb 1, 2012, at 10:15 PM, Kuo Hugo wrote: I would love to know more about this topic too. push Hugo Kuo 2012/2/2 Pete Zaitcev zait...@redhat.com Hello: Does anyone happen to have Swift running with S3 and Keystone? If yes, send me the proxy-server.conf, please. Also, I'd like to ask a few questions, if I may. I tried to piece it together from the code, but failed. The authentication is done with a special hook into Keystone. It supplies middleware, keystone/keystone/middleware/s3_token.py, which invokes a POST to v2 Keysone with OS-KSS3:s3Credentials, then sets a req. header X-Auth-Token. So far so good. However, how does it fit in with Swift? The actual S3 operations are implemented by swift/common/middleware/swift3.py, which rolls up the canonical string, then stuffs it into env['HTTP_X_AUTH_TOKEN']. The intent is, as I understand, to invoke the special purpose code in tempauth and thus is useless for Keystone. So, how is this supposed to work? I imagine the pipeline should look something like this: [pipeline:main] pipeline = healthcheck cache s3auth swift3 proxy-server [filter:s3auth] use = egg:keystone#swiftauth service_protocol = http service_host = 192.168.129.18 service_port = 5000 [filter:swift3] use = egg:swift#swift3 Except... There is no entry point for s3_auth in keystone egg. Documentation seems to be absent. I suppose I could put it together, if I got it all working at least once. Confused, -- Pete ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- +Hugo Kuo+ tonyt...@gmail.com hugo@cloudena.com +886-935-004-793 www.cloudena.com ___ 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
Re: [Openstack] Remove Zones code - FFE
Well, I can actually say with confidence that the replacement would be stable by essex release. In fact, I expect the first commit to be a completely working solution that solves a number of problems with the original implementation. I don't think there's any issue getting something committed by the 15th if there's not much bickering on the review. The code is dead simple (currently a 500 line diff) and requires almost no modification of nova core. The only modifications to nova core are: Specify a different compute API class to use Modify rpc code to allow some kwargs to Connection __init__ so you can specify a specific rabbit server to use to send a message to a zone Add 2 new rpc methods: cast_to_zone and call_to_zone (which use the above change) Add a few zone_api.update_instance() calls in some places in compute so that we can push instance updates to top level zone. Migration for zones DB table to add rpc credential information. Besides that, the rest of the code is standalone. There's absolutely no concern that it'll make non-zones less stable. The few zone_api.update_instance() type calls would be no-ops when zones is turned off. As far as meeting a 2/15 date, here's what I have left: 1) clean up some things in my compute API subclass 2) finish writing tests (Vish: I was joking when I asked if you meant 15th of March ;) After what I would plan to push for the first commit, there's some refactoring desired to better share functionality between the zone scheduler and the host scheduler, but it'd be nothing required for Essex if we want to wait on that. And there's a desire to fold this new 'zones' nova service I'm creating into the current scheduler as potentially just a different scheduler driver. There's 1 thing that would be lost in what I'd propose: zone scheduling would initially be random zone selection. Either way, I think I'll throw something up for review by mid next week to see what thoughts are. I'd like to at least share what this looks like at the moment. If we still decide to wait for F1, cool. - Chris On Feb 2, 2012, at 1:27 AM, Vishvananda Ishaya wrote: I talked with chris a bit offline, and I'm a little concerned that we will be pushing too hard to try and get this into a working state by Essex. I think even if we to slam it in we will be faced with bugs that will make the essex version potentially as broken as the current zones code is. It is probably much more reasonable to target F1 as a delivery date for this feature. Alejandro, is your team ok with deploying milestone releases? I know it would take a lot of pressure off of Chris, Sandy, et. al. since they are trying to meet some pretty hard delivery dates as it is. Vish On Feb 1, 2012, at 3:44 PM, Alejandro Comisario wrote: Sounds pretty good Vish. Since we are mostly deployers, and the ones who are gonna try the new code from day zero, whats good for Sandy, its good for us. Alejandro. On 02/01/2012 06:57 PM, Vishvananda Ishaya wrote: Thanks for the feedback. It is good to get input from one of the largest openstack installs! So it sounds like the existing code is pretty broken. Based on this feedback I would like to propose the following: 1) cut out zones code (meaning merge the existing branch) 2) grant an FFe for the new rpc based zone code as long is it can be merged without heavily modifying core. This means: a) it should be deployable with the feature disabled b) it should only include minor modifications to core components c) if a major change is needed to distributed_scheduler (for example), consider leaving the existing version in, and copying the code to a new file (distributed_scheduler_v2) and doing the modifications there. That way we can minimize chances of breakage d) it needs to be merged by the 15th Does that seem reasonable? Vish On Feb 1, 2012, at 1:42 PM, Alejandro Comisario wrote: Hi guys. Its true that we are trying to make multizones work, actually we did, but we get into an instance were listing all vms from the parent zone ( where is has to go thru all the child zones ) is buggy ( if not impossible by now ). So, if there is a new zone architecture that actually works ( we want to stop using our own deployer to do that ) or has a chance to be fully working when 2012-1 is out, (we would prefer not to wait till Folsom) we are totally into it ! since by now, we were actually waiting for this new Zones code to come out to try again. Alejandro. On 02/01/2012 06:17 PM, Nathanael Burton wrote: +1 On Feb 1, 2012 4:13 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: I would prefer that if it can be done super-super fast. :) Vish On Feb 1, 2012, at 1:04 PM, Chris Behrens wrote: I wonder if we can use some of the architecture of the new code and move the current implementation to that model. It'd preserve the existing functionality, set us up for
Re: [Openstack] [Nova] Essex dead wood cutting
Vishvananda Ishaya wrote: We don't need support from microsoft specifically. What we need is one or more companies committed to: a) actually using the Hyper-V driver b) writing tests and fakes so that the existing functionality doesn't break c) providing test hardware and jenkins integration for functional testing d) adding new features to get the feature set closer to the level of the other drivers I would add (e): maintaining the code in good shape over time. It's not really something that can be fixed once per year, it's more a continuous thing. The existing hyper-v code has been removed for Essex, but I would be more than happy to see it come back in Folsom if we can get some commitment around the above list. In the mean time, it can certainly live as separate code until it catches up with the above-stated requirements, given the way hypervisors can be plugged into OpenStack. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] Remove Zones code - FFE
Chris Behrens wrote: Well, I can actually say with confidence that the replacement would be stable by essex release. In fact, I expect the first commit to be a completely working solution that solves a number of problems with the original implementation. I don't think there's any issue getting something committed by the 15th if there's not much bickering on the review. The code is dead simple (currently a 500 line diff) and requires almost no modification of nova core. The only modifications to nova core are: Specify a different compute API class to use Modify rpc code to allow some kwargs to Connection __init__ so you can specify a specific rabbit server to use to send a message to a zone Add 2 new rpc methods: cast_to_zone and call_to_zone (which use the above change) Add a few zone_api.update_instance() calls in some places in compute so that we can push instance updates to top level zone. Migration for zones DB table to add rpc credential information. Besides that, the rest of the code is standalone. There's absolutely no concern that it'll make non-zones less stable. The few zone_api.update_instance() type calls would be no-ops when zones is turned off. It still introduces a bit of disturbance in the Force, if only by loss of focus on bugfixing. From where I'm standing it boils down to how broken the current zone code is... and how much better the replacement code would be. I'll admit I have trouble properly evaluating how functional zone code is with my couple laptops, so I'll trust you guys (Chris, Vish, Alejandro) on that: if the new code is significantly more functional than the old one, and the whole thing does not really touch non-zone code, I'd say go for it... by the 15th at the latest ! -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] Swift S3 with Keystone anyone?
Hi, Please check the review: https://review.openstack.org/#q,3076,n,z Use swiftauth and s3token middleware and you may be able to do what you want. I'm sorry that I haven't try it. Or, you can use authtoken and _patched_ swift3 middleware. You'll find the patch in the view above. Regards, Akira Yoshiyama 2012/02/02 14:47 Pete Zaitcev zait...@redhat.com: Hello: Does anyone happen to have Swift running with S3 and Keystone? If yes, send me the proxy-server.conf, please. Also, I'd like to ask a few questions, if I may. I tried to piece it together from the code, but failed. The authentication is done with a special hook into Keystone. It supplies middleware, keystone/keystone/middleware/s3_token.py, which invokes a POST to v2 Keysone with OS-KSS3:s3Credentials, then sets a req. header X-Auth-Token. So far so good. However, how does it fit in with Swift? The actual S3 operations are implemented by swift/common/middleware/swift3.py, which rolls up the canonical string, then stuffs it into env['HTTP_X_AUTH_TOKEN']. The intent is, as I understand, to invoke the special purpose code in tempauth and thus is useless for Keystone. So, how is this supposed to work? I imagine the pipeline should look something like this: [pipeline:main] pipeline = healthcheck cache s3auth swift3 proxy-server [filter:s3auth] use = egg:keystone#swiftauth service_protocol = http service_host = 192.168.129.18 service_port = 5000 [filter:swift3] use = egg:swift#swift3 Except... There is no entry point for s3_auth in keystone egg. Documentation seems to be absent. I suppose I could put it together, if I got it all working at least once. Confused, -- Pete ___ 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
Re: [Openstack] [Nova] Essex dead wood cutting
To the best of my knowledge, the ESXi support is up to date. There may be bugs, but which virt driver is perfect ;)? Sateesh may know more, because he is the main contributor/maintainer from Citrix. However, as Vish pointed out in a previous email, any driver is doomed to rot if: a) no one is deploying OpenStack using the specific driver, thus unveiling potential problems; b) a pool of developers (not necessarily the first committer) keep the code up to date, increase functionality and test coverage (both unit and functional); Clearly both xenapi and libvirt are actively developed and deployed. How about vmwareapi? Anyone? Let's make sure that vmwareapi is not going to be the next one to bite the dust. A. -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: 02 February 2012 08:53 To: openstack@lists.launchpad.net Subject: Re: [Openstack] [Nova] Essex dead wood cutting Thierry Carrez wrote: Just as Nova enters feature freeze, it sounds like a good moment to consider removing deprecated, known-buggy-and-unmaintained or useless feature code from the Essex tree. Here are my suggestions for removal: - Ajaxterm (unmaintained, security issues, replaced by VNC console) - Hyper-V support (known broken and unmaintained) While we are at it (and since I'm getting used to press coverage), what's the state of the VMWareAPI support ? I knew Hyper-V was not working because bugs were reported against it... but I don't really know how functional vmwareapi actually is. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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
Re: [Openstack] [Nova] Essex dead wood cutting
Errata corrige for point b) a pool of developers (not necessarily the first committer) DOES NOT keep the code up to date, AND DOES NOT increase functionality and test coverage (both unit and functional); :) -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Armando Migliaccio Sent: 02 February 2012 11:52 To: Thierry Carrez; openstack@lists.launchpad.net Subject: Re: [Openstack] [Nova] Essex dead wood cutting To the best of my knowledge, the ESXi support is up to date. There may be bugs, but which virt driver is perfect ;)? Sateesh may know more, because he is the main contributor/maintainer from Citrix. However, as Vish pointed out in a previous email, any driver is doomed to rot if: a) no one is deploying OpenStack using the specific driver, thus unveiling potential problems; b) a pool of developers (not necessarily the first committer) keep the code up to date, increase functionality and test coverage (both unit and functional); Clearly both xenapi and libvirt are actively developed and deployed. How about vmwareapi? Anyone? Let's make sure that vmwareapi is not going to be the next one to bite the dust. A. -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: 02 February 2012 08:53 To: openstack@lists.launchpad.net Subject: Re: [Openstack] [Nova] Essex dead wood cutting Thierry Carrez wrote: Just as Nova enters feature freeze, it sounds like a good moment to consider removing deprecated, known-buggy-and-unmaintained or useless feature code from the Essex tree. Here are my suggestions for removal: - Ajaxterm (unmaintained, security issues, replaced by VNC console) - Hyper-V support (known broken and unmaintained) While we are at it (and since I'm getting used to press coverage), what's the state of the VMWareAPI support ? I knew Hyper-V was not working because bugs were reported against it... but I don't really know how functional vmwareapi actually is. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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 ___ 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] Essex-3 Milestone of Quantum Available
Nice job netstackers. I've got a remark. I downloaded the Quantum archive from Quantum project Launchpad page and I untared it but I cannot find any OVS agent in the plugin directory. Does it mean it's packaged alone ? If yes, where I can find it ? Regards, Doude. On Fri, Jan 27, 2012 at 1:59 PM, Shake Chen shake.c...@gmail.com wrote: Hi Now the Qautum E3 whether work with Horizon E3? whether I can manage the Qauntum in Horizon Dashboard? On Fri, Jan 27, 2012 at 7:57 PM, Leandro Reox leandro.r...@gmail.comwrote: Excellent job guys ! Well definitely try it next week, the last release worked out pretty good so far for us. Keep up the good work! Cheers Lean On Thu, Jan 26, 2012 at 8:36 PM, Dan Wendlandt d...@nicira.com wrote: Congrats to the Quantum team! The latest + greatest version of Quantum was release this morning, see: https://launchpad.net/quantum/essex/essex-3 I delayed the announce in order to complete updating the documentation, due to the fact that install procedures changed significantly with this release. See PDF on downloads page. Changes since Essex-2 include: - client code in separate repo to simplify development dependencies on other projects. - integration with Nova Floating IPs. - API filters for efficient queries and improved API error codes (API v1.1 only) - fixes to python setup tools scripts to make life easier for distros packagers. - port packet statistics extension If you have an OpenStack distro and are looking to package Quantum for Essex, the packaging should now be in its final form. Let us know how we can help. E-3 was also the first release for which Quantum was part of the standard OpenStack build process, thanks to the CI team for all the help! Since Quantum is still in incubation, E-4 is not a feature frozen milestone, though we will shutting the door to major merges at least a week before the official milestone branch point to avoid last-minute churn. Thanks to all who contributed to E-3. Looking forward to a great E-4 milestone with lots of early merge proposals :) Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ 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 -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com ___ 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
Re: [Openstack] Remove Zones code - FFE
Thierry et. al. Responses inline. On 02/02/2012 06:03 AM, Thierry Carrez wrote: Chris Behrens wrote: Well, I can actually say with confidence that the replacement would be stable by essex release. In fact, I expect the first commit to be a completely working solution that solves a number of problems with the original implementation. I don't think there's any issue getting something committed by the 15th if there's not much bickering on the review. The code is dead simple (currently a 500 line diff) and requires almost no modification of nova core. The only modifications to nova core are: Specify a different compute API class to use Modify rpc code to allow some kwargs to Connection __init__ so you can specify a specific rabbit server to use to send a message to a zone Add 2 new rpc methods: cast_to_zone and call_to_zone (which use the above change) Add a few zone_api.update_instance() calls in some places in compute so that we can push instance updates to top level zone. Migration for zones DB table to add rpc credential information. There's 1 thing that would be lost in what I'd propose: zone scheduling would initially be random zone selection. There's actually no concern for us in the scheduler for being random actually, we prefer this since our strategy is more aligned with the spread first scheduling method. Besides that, the rest of the code is standalone. There's absolutely no concern that it'll make non-zones less stable. The few zone_api.update_instance() type calls would be no-ops when zones is turned off. It still introduces a bit of disturbance in the Force, if only by loss of focus on bugfixing. From where I'm standing it boils down to how broken the current zone code is... and how much better the replacement code would be. I'll admit I have trouble properly evaluating how functional zone code is with my couple laptops, so I'll trust you guys (Chris, Vish, Alejandro) on that: if the new code is significantly more functional than the old one, and the whole thing does not really touch non-zone code, I'd say go for it... by the 15th at the latest ! So, if Chris is confident to merge the new zone code to 2/15 we'll be pleased to test it, to continue to our new features early adoption philosophy :D As we said before, today we are covering our need of multizone across our datacenters with our in-house custom scheduling api, one that we want to deprecate asap as we move to Essex making direct calls to the parent zone ( nova api ) doing this in a native way. For us, multizone is a MUST for taking Essex into production, so if you Chris can make it to 2/15 we will be testing all this new code on 2/15 one minute later after commit :D so we can give you as much feedback as you need almost immediately. Vish, if multizone actually worked since E-2 we were thinking about going with E-3 into prod and putting all our efforts till we wait for 2012-1, this is not what we prefer, but since we didnt find a feature more attractive in diablo than cactus and multizone code in diablo was pretty much broken than Essex. We have to make a balance between what we need and what openstack actually gives us ( in that case, we have to develop ourselves without digging into nova-core source code) So definitely its a +1 for merging the code to 2/15. Best. Alejandro. ___ 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] Wishlist bugs
Hey, Wishlist (I want a pony) bugs that have sat in launchpad for an extended period with no progress contribute to the general noise in launchpad - for developers trying to fix stuff that matter to people, they're not a very good source of information. So, how about we do this: http://wiki.openstack.org/BugTriage Priority 8: Review wishlist bugs We should review all Wishlist bugs to make sure they are still relevant and properly prioritized. If a low priority Wishlist bug has seen no visible progress in several months, set its status to Opinion with a friendly comment e.g. Thanks for the suggestion, but it looks like no-one is actively working on this Wishlist item and it is marked as Low priority. I am moving the bug to Opinion status so that it doesn't clutter up the default queries. If any one decides to work on the bug, please feel free to move it to In Progress. Thoughts? Thanks, Mark. ___ 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] Configure Rate limits on OS API
On Fri, Dec 30, 2011 at 11:34 AM, Jay Pipes jaypi...@gmail.com wrote: I struggled to figure out how to change this ratelimiting stuff for ages while working on Tempest. Eventually, I just removed the ratelimit middleware entirely from the pipeline since I could find no documentation whatsoever on how to change the limits. It would be awesome if this was documented in the Nova docs. I've added a bug to remind about it: https://bugs.launchpad.net/nova/+bug/910193 Cheers, There's a merge prop for the compute admin documentation at https://review.openstack.org/#change,3653 Comments appreciated. mike ___ 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] Essex-3 Milestone of Quantum Available
Hi Quantum team! Now the Quantum E3, still can not manage in Horizion E3. I test in Devstack. The Horizion team said the Quantum API not stable。 Any plan fix the problem and let Horizon can manage the Quantum. On Fri, Jan 27, 2012 at 7:36 AM, Dan Wendlandt d...@nicira.com wrote: Congrats to the Quantum team! The latest + greatest version of Quantum was release this morning, see: https://launchpad.net/quantum/essex/essex-3 I delayed the announce in order to complete updating the documentation, due to the fact that install procedures changed significantly with this release. See PDF on downloads page. Changes since Essex-2 include: - client code in separate repo to simplify development dependencies on other projects. - integration with Nova Floating IPs. - API filters for efficient queries and improved API error codes (API v1.1 only) - fixes to python setup tools scripts to make life easier for distros packagers. - port packet statistics extension If you have an OpenStack distro and are looking to package Quantum for Essex, the packaging should now be in its final form. Let us know how we can help. E-3 was also the first release for which Quantum was part of the standard OpenStack build process, thanks to the CI team for all the help! Since Quantum is still in incubation, E-4 is not a feature frozen milestone, though we will shutting the door to major merges at least a week before the official milestone branch point to avoid last-minute churn. Thanks to all who contributed to E-3. Looking forward to a great E-4 milestone with lots of early merge proposals :) Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com ___ 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] Capture of the Keystone/LDAP Role discussion
On 02/02/2012 02:38 AM, Vishvananda Ishaya wrote: Nice summary. As you said ldap structures are going to vary by company. I am curious if AD has a standard way of dealing with this that we could use. FWIW, the nova deprecated ldap auth code uses subtrees for roles, and yes it is painful, but it might be the way to go if we want something quick and we assume organizations are going to have to write their own version anyway. Based on discussions with numerous people, It seems that the subtree approach (as done by nova deprecated) is the norm. What seems to vary the most amongst LDAP servers is not the schema, but the method used to query for membership in nested groups. In OpenLDAP, the syntax involves sets http://www.openldap.org/faq/data/cache/1133.html http://www.openldap.org/faq/data/cache/1134.html Whereas in Active directory, it involves using LDAP_MATCHING_RULE_IN_CHAIN rule OID. In the 389 (Fedora) Directory Server as well as OpenLDAP it is also possible to use the deference control in conjunction with the memberof plugin. However, we might not need to query for nested group membership. For example, lets assume a tenant has 3 administrative roles: user management, network management, VM management. In addition, users that do not have an explicit admin role get read only access to the resources of that tenant. So a user that has the right to manage networks for that tenant would have to appear in both the members list of that tenant as well as in the networkMgmt role. The first is provided for read only access, and the second for the ability to modify the network. It is a little redundant. We could perhaps put a constraint on the roles that they will only allow users that are listed in the general membership for that tenancy. There was some talk about nesting tenancies for resellers. This is somewhat different from nested group member ship, as entry in the lower level tenant should *not* provide access to all resources of the containing tenancy. Permissions go the other way around: if I am an admin of the container, I can manage elements of the contained. It does mean that the Keystone server needs to be smart enough to check all of the levels of nesting from lowest to highest to see if a user has the appropriate role for the requested operation. So, to summarize: Roles will be entites under tenants, with a member field that indicates the users that have that role. Vish On Feb 1, 2012, at 7:56 PM, Adam Young wrote: As part of the effort to get LDAP support into Keystone Light, we had a bit of a design discussion on IRC. The discussion focused on Roles, and I would like to sum up what was said in that discussion. When we talk about Roles, we mean the permissions a given user has in a given tenant. As such, it is a three way relationship, and LDAP does not handle those well. Group member ship is done using a multivalued attribute, such that a Group has a list of users in an attribute named members.This cannot be extended to roles directly, as the attribute would have to hold two values: the user, and the role. One proposal was to do just that: to append the role name on to the user name, and them as a single string inside a single attribute. A drawback to this approach is that the LDAP rules have no way of enforcing that the values placed into the concatenated string are valid values. Another drawback is that the parsing of the string is then placed on the system that consumes the roles. Groups can be containers of other objects. As such, another alternative is to put a collection of roles under the tenant group, and then to add the user names to each of the roles.The drawback to this approach is that the tenant then becomes a subtree, and the management of subtrees is more involved in LDAP than the management of single objects. / /Roles tend to map to permissions on external objects. For example, a role might indicate that a given user can create a new network inside of quantum, or deploy a new template image into glance. If the set of roles is known a-priori, they could be done as a set of attributes on the tenant group. The drawback with this approach is that making changes to the LDAP schema after deployment is generally not allowed in large organizations, so adding a new role would be impossible/. If the objects being managed were entirely within the Directory Server, one possible solution would be to use the Directory servers access controls to manage who could do what. For example, in order for a user to be able to create a new network, they wound need write access to the networks collection for their tenancy. The reason we cannot do that is that many of the objects are maintained in external databases, and not in the directory server. Plus, the access controls for LDAP are not guaranteed to be consistent across different LDAP
Re: [Openstack] [Netstack] Essex-3 Milestone of Quantum Available
2012/2/2 Doude doudou...@gmail.com: Nice job netstackers. I've got a remark. I downloaded the Quantum archive from Quantum project Launchpad page and I untared it but I cannot find any OVS agent in the plugin directory. Does it mean it's packaged alone ? If yes, where I can find it ? Hi Doude, thanks for mentioning this. We switched over to using the standard openstack project tarball generation mechanism for E-3, but our team still ran tests still from git, and missed several issues like you one you mention. If possible, its probably best to just use the E-3 tarball from github itself: https://github.com/openstack/quantum/zipball/essex-3, which contains all of the correct files (I believe). Does that work for you? It should have all of the files you need. If needed, we could issue a Essex-3.1 drop with a fixed tarball. Dan Regards, Doude. On Fri, Jan 27, 2012 at 1:59 PM, Shake Chen shake.c...@gmail.com wrote: Hi Now the Qautum E3 whether work with Horizon E3? whether I can manage the Qauntum in Horizon Dashboard? On Fri, Jan 27, 2012 at 7:57 PM, Leandro Reox leandro.r...@gmail.com wrote: Excellent job guys ! Well definitely try it next week, the last release worked out pretty good so far for us. Keep up the good work! Cheers Lean On Thu, Jan 26, 2012 at 8:36 PM, Dan Wendlandt d...@nicira.com wrote: Congrats to the Quantum team! The latest + greatest version of Quantum was release this morning, see: https://launchpad.net/quantum/essex/essex-3 I delayed the announce in order to complete updating the documentation, due to the fact that install procedures changed significantly with this release. See PDF on downloads page. Changes since Essex-2 include: - client code in separate repo to simplify development dependencies on other projects. - integration with Nova Floating IPs. - API filters for efficient queries and improved API error codes (API v1.1 only) - fixes to python setup tools scripts to make life easier for distros packagers. - port packet statistics extension If you have an OpenStack distro and are looking to package Quantum for Essex, the packaging should now be in its final form. Let us know how we can help. E-3 was also the first release for which Quantum was part of the standard OpenStack build process, thanks to the CI team for all the help! Since Quantum is still in incubation, E-4 is not a feature frozen milestone, though we will shutting the door to major merges at least a week before the official milestone branch point to avoid last-minute churn. Thanks to all who contributed to E-3. Looking forward to a great E-4 milestone with lots of early merge proposals :) Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ 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 -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com ___ 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/~netstack Post to : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ 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] [Netstack] updating quantum in horizon
Hi Shake, You can read more details about quantum + horizon in the thread below. If you are able to do any work to fix things, please let us know. Dan On Tue, Jan 31, 2012 at 4:47 PM, Tres Henry t...@treshenry.net wrote: Yeah, the Quantum UI hasn't been getting a lot of use because of it's broken status. My vote would be to update the UI to support the new Quantum Manager way of doing things instead of trying to support two UI paradigms. As a good parallel to this discussion the Horizon community has been working on formalizing the design process which spawned a first pass at a Human Interface Guideline (https://github.com/4P/Horizon-HIG/blob/master/OpenStack_HIG.rst). The HIG is a good tool to measure the implementation against. In an ideal world your change suggestions below would be translated into requirements which would then drive a design pass resulting in wireframes that would guide the implementation. Unfortunately the world is often less than ideal so we'll just have to do our best given the tight timeline. We can finish off https://review.openstack.org/3336, which I believe just needs some testing, then we can create bugs for all of your suggestions below and see what we can get nailed down before Folsom. On Jan 31, 2012, at 10:39 AM, Dan Wendlandt wrote: Hi Tres, Thanks for sending this out. I'm excited that we have a couple people interested in fixing things up here! CC'd is Michael Fork, who also mentioned that he is interested in working on this. I will start out with a caveat that all of these comments are targeted at making Horizon work well with Quantum + the Quantum Manager code in Nova. The original Quantum + Horizon code was written back in diablo, prior to much of the work on Quantum Manager, and thus targeted a more manual model where the user explicitly created + attached ports, rather than having QuantumManager do that automatically. It also was a model that was not integrated with IP Address management at all. Given that things seem to have been broken with Quantum + Horizon for a while, I am assuming that no one has been seriously using the code in this form, and thus we can move to a model that uses QuantumManager without worrying about the old model. If anyone wants to step forward and support the old model, we'll have to figure out how the two approaches should co-exist. Otherwise, I would just push for a model where QuantumManager is the primary mode of use for Quantum + Horizon. One error prevents a lot of the code from even working in the first place, so we should probably tackle that first. Oddly, it seems to be an issue with the vif-extension in Nova. When trying to view the detail page of an individual network does not work. I get this error: Error: Unable to get network details: The server has either erred or is incapable of performing the requested operation. Underneath the covers, I see the exception: [Tue Jan 31 09:53:29 2012] [error] ERROR:horizon.dashboards.nova.networks.views:Unable to get network details. [Tue Jan 31 09:53:29 2012] [error] Traceback (most recent call last): [Tue Jan 31 09:53:29 2012] [error] File /opt/stack/horizon/horizon/horizon/dashboards/nova/networks/views.py, line 102, in detail [Tue Jan 31 09:53:29 2012] [error] network['ports'] = _get_port_states(request, network_id) [Tue Jan 31 09:53:29 2012] [error] File /opt/stack/horizon/horizon/horizon/dashboards/nova/networks/views.py, line 143, in _get_port_states [Tue Jan 31 09:53:29 2012] [error] vifs = api.get_vif_ids(request) [Tue Jan 31 09:53:29 2012] [error] File /opt/stack/horizon/horizon/horizon/api/quantum.py, line 118, in get_vif_ids [Tue Jan 31 09:53:29 2012] [error] instance_vifs = nova.virtual_interfaces_list(request, id) [Tue Jan 31 09:53:29 2012] [error] File /opt/stack/horizon/horizon/horizon/api/nova.py, line 398, in virtual_interfaces_list [Tue Jan 31 09:53:29 2012] [error] return novaclient(request).virtual_interfaces.list(instance_id) [Tue Jan 31 09:53:29 2012] [error] File /opt/stack/python-novaclient/novaclient/v1_1/virtual_interfaces.py, line 33, in list [Tue Jan 31 09:53:29 2012] [error] 'virtual_interfaces') [Tue Jan 31 09:53:29 2012] [error] File /opt/stack/python-novaclient/novaclient/base.py, line 69, in _list [Tue Jan 31 09:53:29 2012] [error] resp, body = self.api.client.get(url) [Tue Jan 31 09:53:29 2012] [error] File /opt/stack/python-novaclient/novaclient/client.py, line 130, in get [Tue Jan 31 09:53:29 2012] [error] return self._cs_request(url, 'GET', **kwargs) [Tue Jan 31 09:53:29 2012] [error] File /opt/stack/python-novaclient/novaclient/client.py, line 118, in _cs_request [Tue Jan 31 09:53:29 2012] [error] **kwargs) [Tue Jan 31 09:53:29 2012] [error] File /opt/stack/python-novaclient/novaclient/client.py, line 101, in request [Tue Jan 31 09:53:29 2012] [error] raise exceptions.from_response(resp,
Re: [Openstack] [Netstack] Essex-3 Milestone of Quantum Available
2012/2/2 Doude doudou...@gmail.com: No, it's not necessary. Like you said, I can use github archive or download manually the missing files. Do you want I create a bug for that ? I was about to, but go ahead :) Regards, Doude. 2012/2/2 Dan Wendlandt d...@nicira.com 2012/2/2 Doude doudou...@gmail.com: Nice job netstackers. I've got a remark. I downloaded the Quantum archive from Quantum project Launchpad page and I untared it but I cannot find any OVS agent in the plugin directory. Does it mean it's packaged alone ? If yes, where I can find it ? Hi Doude, thanks for mentioning this. We switched over to using the standard openstack project tarball generation mechanism for E-3, but our team still ran tests still from git, and missed several issues like you one you mention. If possible, its probably best to just use the E-3 tarball from github itself: https://github.com/openstack/quantum/zipball/essex-3, which contains all of the correct files (I believe). Does that work for you? It should have all of the files you need. If needed, we could issue a Essex-3.1 drop with a fixed tarball. Dan Regards, Doude. On Fri, Jan 27, 2012 at 1:59 PM, Shake Chen shake.c...@gmail.com wrote: Hi Now the Qautum E3 whether work with Horizon E3? whether I can manage the Qauntum in Horizon Dashboard? On Fri, Jan 27, 2012 at 7:57 PM, Leandro Reox leandro.r...@gmail.com wrote: Excellent job guys ! Well definitely try it next week, the last release worked out pretty good so far for us. Keep up the good work! Cheers Lean On Thu, Jan 26, 2012 at 8:36 PM, Dan Wendlandt d...@nicira.com wrote: Congrats to the Quantum team! The latest + greatest version of Quantum was release this morning, see: https://launchpad.net/quantum/essex/essex-3 I delayed the announce in order to complete updating the documentation, due to the fact that install procedures changed significantly with this release. See PDF on downloads page. Changes since Essex-2 include: - client code in separate repo to simplify development dependencies on other projects. - integration with Nova Floating IPs. - API filters for efficient queries and improved API error codes (API v1.1 only) - fixes to python setup tools scripts to make life easier for distros packagers. - port packet statistics extension If you have an OpenStack distro and are looking to package Quantum for Essex, the packaging should now be in its final form. Let us know how we can help. E-3 was also the first release for which Quantum was part of the standard OpenStack build process, thanks to the CI team for all the help! Since Quantum is still in incubation, E-4 is not a feature frozen milestone, though we will shutting the door to major merges at least a week before the official milestone branch point to avoid last-minute churn. Thanks to all who contributed to E-3. Looking forward to a great E-4 milestone with lots of early merge proposals :) Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ 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 -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com ___ 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/~netstack Post to : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ 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] [Netstack] Essex-3 Milestone of Quantum Available
On 02/02/2012 11:45 AM, Dan Wendlandt wrote: 2012/2/2 Doudedoudou...@gmail.com: Nice job netstackers. I've got a remark. I downloaded the Quantum archive from Quantum project Launchpad page and I untared it but I cannot find any OVS agent in the plugin directory. Does it mean it's packaged alone ? If yes, where I can find it ? Hi Doude, thanks for mentioning this. We switched over to using the standard openstack project tarball generation mechanism for E-3, but our team still ran tests still from git, and missed several issues like you one you mention. If possible, its probably best to just use the E-3 tarball from github itself: https://github.com/openstack/quantum/zipball/essex-3, which contains all of the correct files (I believe). Does that work for you? It should have all of the files you need. If needed, we could issue a Essex-3.1 drop with a fixed tarball. Dan and Doude, Bug https://bugs.launchpad.net/quantum/+bug/925074 covers the missing agent as well as missing LICENSE and plugin README files. From my point of view, issuing an E3.1 just for these is not warranted but I'd like to see them included in an E3.1 issued for other purposes, or else in E4. -Bob Dan Regards, Doude. On Fri, Jan 27, 2012 at 1:59 PM, Shake Chenshake.c...@gmail.com wrote: Hi Now the Qautum E3 whether work with Horizon E3? whether I can manage the Qauntum in Horizon Dashboard? On Fri, Jan 27, 2012 at 7:57 PM, Leandro Reoxleandro.r...@gmail.com wrote: Excellent job guys ! Well definitely try it next week, the last release worked out pretty good so far for us. Keep up the good work! Cheers Lean On Thu, Jan 26, 2012 at 8:36 PM, Dan Wendlandtd...@nicira.com wrote: Congrats to the Quantum team! The latest + greatest version of Quantum was release this morning, see: https://launchpad.net/quantum/essex/essex-3 I delayed the announce in order to complete updating the documentation, due to the fact that install procedures changed significantly with this release. See PDF on downloads page. Changes since Essex-2 include: - client code in separate repo to simplify development dependencies on other projects. - integration with Nova Floating IPs. - API filters for efficient queries and improved API error codes (API v1.1 only) - fixes to python setup tools scripts to make life easier for distros packagers. - port packet statistics extension If you have an OpenStack distro and are looking to package Quantum for Essex, the packaging should now be in its final form. Let us know how we can help. E-3 was also the first release for which Quantum was part of the standard OpenStack build process, thanks to the CI team for all the help! Since Quantum is still in incubation, E-4 is not a feature frozen milestone, though we will shutting the door to major merges at least a week before the official milestone branch point to avoid last-minute churn. Thanks to all who contributed to E-3. Looking forward to a great E-4 milestone with lots of early merge proposals :) Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ 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 -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com ___ 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/~netstack Post to : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack 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
Re: [Openstack] nova scaling-zone and trusted computing
Chris, The scaling-zone enforces designs on capabilities - capability must be periodically updated, within 3 keep-alive ticks, from components, otherwise the capability is viewed as stale and removed. Is any intention to create sticky, i.e., good until update/cancel, capabilities from entity outside of compute-nodes? On trusted computing, a node's trusted state can't be trusted if reported directly by node itself, rather it should come from a 3rd trusted entity to verify and report nodes' state. Secondly, we would need sticky capability since it won't be useful or feasible to continue updating all nodes' trusted states into nova in 3 ticks if we are running state verification logic external to Nova. -Fred Have you taken a look at: https://review.openstack.org/#change,2552 to see if it makes your life any easier? There's more changes coming. One of the goals is to make things a bit more pluggable and eventually even combine all of the current schedulers. - Chris ___ 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] Quantum Bug-Squashing Next Thurs (2/2)
Adding main openstack list to thread with webex link for Quantum bus-squashing event. Remember to have you devstack environment setup ahead of time. Event starts @ 2pm Pacific. Anyone is welcome to participate, though the content is geared toward folks already familiar with Quantum basics. Webex will be recorded and posted. Dan On Tue, Jan 31, 2012 at 10:11 PM, Dan Wendlandt d...@nicira.com wrote: Thanks to those who RSVPed. Sounds like a good number of people will be remote. Below is a webex that anyone can join for the presentations on using Quantum + devstack, which is how we will start. For the post presentation period, we will try a google plus hangout, but may just fall back to IRC or keep the webex going :) Dan --- Meeting information --- Topic: quantum bug-squashing Date: Thursday, February 2, 2012 Time: 2:00 pm, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Number: 628 703 774 Meeting Password: (This meeting does not require a password.) --- To start or join the online meeting --- Go to https://nicira.webex.com/nicira/j.php?ED=191705502UID=485602003RT=MiM0 --- Audio conference information --- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll number (US/Canada): +1-408-600-3600 Global call-in numbers: https://nicira.webex.com/nicira/globalcallin.php?serviceType=MCED=191705502tollFree=0 Access code:628 703 774 On Thu, Jan 26, 2012 at 4:29 PM, Dan Wendlandt d...@nicira.com wrote: Hi Netstack team, A week from today (Thurs. 2/2) is the OpenStack-wide bug-squashing day. For Quantum, we are going to focus on improving code quality metrics, most particularly, code coverage in Quantum + Quantum Manager. For those of you in the bay area, we will be hosting an on-site event 2pm - 7pm at Nicira's main office (3460 W. Bayshore Rd., Palo Alto, CA.. located right near Hwy 101 San Antonio Ave). We will start off with a few presentations covering Quantum basics, and walking through how to get devstack + Quantum up and running, hopefully along with Tempest (please arrive with access to a clean Ubuntu Oneiric host that you can use). Next, we can identify key gaps in code coverage and start hacking on unit tests or integration tests that will address these gaps. Hopefully we can get the code reviewed and committed right then and there. Around dinner we will have pizza and beverages to help fuel the coding, with things hopefully wrapping up around 7pm. Feel free to join for whatever part works for your schedule. If you plan on attending, please drop me a note so we have adequate preparations. Anyone currently or interested in contributing to Quantum is welcome to attend, but the focus will be on writing + committing code, not a general training session on how to use Quantum. For those we are remote, we will try to do the presentations using webex, so you can see slides and ask questions. We will also setup a google hangout for the coding portion (sorry, google hangout has not yet figured out how to transmit pizza or beer via the web). See you there! Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ 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] Capture of the Keystone/LDAP Role discussion
On 02/02/2012 11:50 AM, Ryan Lane wrote: Based on discussions with numerous people, It seems that the subtree approach (as done by nova deprecated) is the norm. It's a normal approach taken by a number of applications, yes. It's not a bad way to handle this, and we are already doing it in nova. The plus of doing it this way, rather than key-value pairs on users, is that when a tenant is deleted, all of the roles are deleted with it. Also, referential integrity plugins can remove userdns from tenants and roles when a user is deleted. It'll still be necessary for admins to remove users from roles when removed from tenants, and we can't depend on that, so we should handle that case. I'll make sure that gets in. What seems to vary the most amongst LDAP servers is not the schema, but the method used to query for membership in nested groups. In OpenLDAP, the syntax involves sets http://www.openldap.org/faq/data/cache/1133.html http://www.openldap.org/faq/data/cache/1134.html Whereas in Active directory, it involves using LDAP_MATCHING_RULE_IN_CHAIN rule OID. In the 389 (Fedora) Directory Server as well as OpenLDAP it is also possible to use the deference control in conjunction with the memberof plugin. However, we might not need to query for nested group membership. For example, lets assume a tenant has 3 administrative roles: user management, network management, VM management. In addition, users that do not have an explicit admin role get read only access to the resources of that tenant. So a user that has the right to manage networks for that tenant would have to appear in both the members list of that tenant as well as in the networkMgmt role. The first is provided for read only access, and the second for the ability to modify the network. It is a little redundant. We could perhaps put a constraint on the roles that they will only allow users that are listed in the general membership for that tenancy. It shouldn't be necessary to do nested searching. When searching for tenant roles for a user, it should be enough to search for the user as a member of roles using the tenant as a base. Even if nested group searching is necessary, it's possible to do nested searching without support for it on the LDAP server side. A recursive search works here. memberOf is also a possibility, but it needs to be supported on the server side; also, some servers use memberOf, and some use isMemberOf, so we'd have to make that configurable. It's likely best to assume some server in use won't support plugins or extensions. We can discover capabilities from the server and use a more efficient method if it's available, while falling back to the less efficient method. Short-lived caches of the results can also alleviate performance problems due to inefficient queries. Right. First step is getting something to function, and then we can performance tune. There was some talk about nesting tenancies for resellers. This is somewhat different from nested group member ship, as entry in the lower level tenant should *not* provide access to all resources of the containing tenancy. Permissions go the other way around: if I am an admin of the container, I can manage elements of the contained. It does mean that the Keystone server needs to be smart enough to check all of the levels of nesting from lowest to highest to see if a user has the appropriate role for the requested operation. So, to summarize: Roles will be entites under tenants, with a member field that indicates the users that have that role. We still need some way to differentiate between roles and tenants, otherwise subtree searches will cause problems. In nova we handled this by assigning the owner attribute on tenants, but no owner on roles. This allowed tenants to be found via a search like this: ((objectclass=groupofnames)(owner=*)) Roles are then discovered by a search like this, using the tenant as a base: (objectclass=groupofnames) Alternatively, we could add schema for roles and projects. It seems a little overkill to add schema just to differentiate these for subtree searches, though. I don't love this solution, as it is not really very self documenting, and it would be easy enough for someone to mess it up. objectClasses: ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( cn ) MAY ( member $ businessCategory $ seeAlso $ owner $ ou $ o $ description ) Seems like what we really want is organizationalRole from http://www.ietf.org/rfc/rfc4519.txt 3.10. 'organizationalRole' The 'organizationalRole' object class is the basis of an entry that represents a job, function, or position in an organization. (Source: X.521 [X.521]) ( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod
[Openstack] Keystone installation with ManagedIT packages...
Still having issues.
I found a config bug in my Keystone.conf file in the filter pipeline for the
d5_compat modules. However, when I fix the config to match the installation
guide and restart keystone, I get an error message that the d5_compat module
can't be found. My keystone installation is from the ManagedIT PPA. Is this a
bug in the documentation? In the ManagedIT packages? The pipeline for the
ManageIT package is configured as follows:
[pipeline:admin]
pipeline =
urlrewritefilter
admin_api
[pipeline:keystone-legacy-auth]
pipeline =
urlrewritefilter
legacy_auth
RAX-KEY-extension
service_api
versus what is specified in the installation guide. Does this difference
matter? What are the differences?
Regards,
Ross
On Feb 1, 2012, at 10:31 AM, Lillie Ross-CDSR11 wrote:
Hi Jay,
Yes, this confused me, however I get the same error using the token I
generated and added (via the keystone-manage command). To wit:
root@nova:~# keystone-manage token list
token userexpiration tenant
---
10111213141516171819 1 2022-01-01 00:00:00 2
fa89fb9a-60d2-4921-b12d-6aee1c177823 1 2012-02-01 15:24:33 1
b06c5e4e-5e59-4293-aa54-ce6879f11371 2 2012-02-01 15:26:41 1
where the first token is the long-lived one I supplied during installation.
Running the glance command yields identical results:
root@nova:~# glance -v -A 10111213141516171819 details
Failed to show details. Got error:
Internal Server error: Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/eventlet/wsgi.py, line 336, in
handle_one_response
result = self.application(self.environ, start_response)
File /usr/lib/python2.7/dist-packages/webob/dec.py, line 147, in __call__
resp = self.call_func(req, *args, **self.kwargs)
File /usr/lib/python2.7/dist-packages/webob/dec.py, line 208, in call_func
return self.func(req, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/glance/common/wsgi.py, line 113, in
__call__
response = req.get_response(self.application)
File /usr/lib/python2.7/dist-packages/webob/request.py, line 1053, in
get_response
application, catch_exc_info=False)
File /usr/lib/python2.7/dist-packages/webob/request.py, line 1022, in
call_application
app_iter = application(self.environ, start_response)
File /usr/lib/python2.7/dist-packages/webob/dec.py, line 147, in __call__
resp = self.call_func(req, *args, **self.kwargs)
File /usr/lib/python2.7/dist-packages/webob/dec.py, line 208, in call_func
return self.func(req, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/glance/common/wsgi.py, line 110, in
__call__
response = self.process_request(req)
File /usr/lib/python2.7/dist-packages/glance/common/context.py, line 104,
in process_request
raise exception.NotAuthorized()
NotAuthorized: None
Completed in 0.0031 sec.
Interestingly (perhaps) I see nothing in the keystone.log file. In fact, I
don't even see the keystone log file. Keystone opens to log files named
'admin.log' and 'keystone_legacy_auth.log'. Is this right? Also, if I run
keystone interactively (keystone -v -d) then issue the glance command, I see
nothing in the keystone window. This doesn't seem right to me, but I'm just
getting started with keystone integration.
Thanks in advance for any insight...
Regards,
Ross
On Jan 31, 2012, at 6:48 PM, Jay Pipes wrote:
On 01/31/2012 06:28 PM, Lillie Ross-CDSR11 wrote:
I'm reinstalling the various Openstack services from packages in the
ManagedIT PPA to pull in the latest Diablo bug fixes. I'm following the
latest directions in the newly release installation guide as I perform
these upgrades
(http://docs.openstack.org/diablo/openstack-compute/install/content/index.html).
However, I'm having trouble getting Glance to authenticate with
Keystone. All config files have been copied from the examples posted in
the installation guide (and modified accordingly for my admin token, IP
addresses, etc.). Regardless, I continually get the following error
message and stack dump when trying to verify the Glance/Keystone
integration:
Step 1: Grab a token
# curl -d '{auth: {tenantName: default,
passwordCredentials:{username: admin, password: admin}}}' -H
Content-type: application/json http://173.23.181.1:35357/v2.0/tokens |
python -mjson.tool
...
token: {
expires: 2012-02-01T15:24:33,
id: fa89fb9a-60d2-4921-b12d-6aee1c177823,
tenant: {
id: 1,
name: default
}
}
You're going to want to grab a long-lived token (sometimes called a service
token) to use for the Glance API - Glance Registry connection. This
service token should be used in the glance-registry.conf file.
In glance-registry.conf, you'll see a section looking like this:
[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
Re: [Openstack] Keystone installation with ManagedIT packages...
I got the same error and now resolved. You can check if you have
pipeline = versionnegotiation authtoken keystone_shim apiv1app
in glance-api and
pipeline = authtoken keystone_shim registryapp
in glance-registry.
Paras.
On Thu, Feb 2, 2012 at 4:12 PM, Lillie Ross-CDSR11
ross.lil...@motorolasolutions.com wrote:
Still having issues.
I found a config bug in my Keystone.conf file in the filter pipeline for the
d5_compat modules. However, when I fix the config to match the installation
guide and restart keystone, I get an error message that the d5_compat module
can't be found. My keystone installation is from the ManagedIT PPA. Is this
a bug in the documentation? In the ManagedIT packages? The pipeline for the
ManageIT package is configured as follows:
[pipeline:admin]
pipeline =
urlrewritefilter
admin_api
[pipeline:keystone-legacy-auth]
pipeline =
urlrewritefilter
legacy_auth
RAX-KEY-extension
service_api
versus what is specified in the installation guide. Does this difference
matter? What are the differences?
Regards,
Ross
On Feb 1, 2012, at 10:31 AM, Lillie Ross-CDSR11 wrote:
Hi Jay,
Yes, this confused me, however I get the same error using the token I
generated and added (via the keystone-manage command). To wit:
root@nova:~# keystone-manage token list
token user expiration tenant
---
10111213141516171819 1 2022-01-01 00:00:00 2
fa89fb9a-60d2-4921-b12d-6aee1c177823 1 2012-02-01 15:24:33 1
b06c5e4e-5e59-4293-aa54-ce6879f11371 2 2012-02-01 15:26:41 1
where the first token is the long-lived one I supplied during installation.
Running the glance command yields identical results:
root@nova:~# glance -v -A 10111213141516171819 details
Failed to show details. Got error:
Internal Server error: Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/eventlet/wsgi.py, line 336, in
handle_one_response
result = self.application(self.environ, start_response)
File /usr/lib/python2.7/dist-packages/webob/dec.py, line 147, in __call__
resp = self.call_func(req, *args, **self.kwargs)
File /usr/lib/python2.7/dist-packages/webob/dec.py, line 208, in call_func
return self.func(req, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/glance/common/wsgi.py, line 113, in
__call__
response = req.get_response(self.application)
File /usr/lib/python2.7/dist-packages/webob/request.py, line 1053, in
get_response
application, catch_exc_info=False)
File /usr/lib/python2.7/dist-packages/webob/request.py, line 1022, in
call_application
app_iter = application(self.environ, start_response)
File /usr/lib/python2.7/dist-packages/webob/dec.py, line 147, in __call__
resp = self.call_func(req, *args, **self.kwargs)
File /usr/lib/python2.7/dist-packages/webob/dec.py, line 208, in call_func
return self.func(req, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/glance/common/wsgi.py, line 110, in
__call__
response = self.process_request(req)
File /usr/lib/python2.7/dist-packages/glance/common/context.py, line 104,
in process_request
raise exception.NotAuthorized()
NotAuthorized: None
Completed in 0.0031 sec.
Interestingly (perhaps) I see nothing in the keystone.log file. In fact, I
don't even see the keystone log file. Keystone opens to log files named
'admin.log' and 'keystone_legacy_auth.log'. Is this right? Also, if I run
keystone interactively (keystone -v -d) then issue the glance command, I see
nothing in the keystone window. This doesn't seem right to me, but I'm just
getting started with keystone integration.
Thanks in advance for any insight...
Regards,
Ross
On Jan 31, 2012, at 6:48 PM, Jay Pipes wrote:
On 01/31/2012 06:28 PM, Lillie Ross-CDSR11 wrote:
I'm reinstalling the various Openstack services from packages in the
ManagedIT PPA to pull in the latest Diablo bug fixes. I'm following the
latest directions in the newly release installation guide as I perform
these upgrades
(http://docs.openstack.org/diablo/openstack-compute/install/content/index.html).
However, I'm having trouble getting Glance to authenticate with
Keystone. All config files have been copied from the examples posted in
the installation guide (and modified accordingly for my admin token, IP
addresses, etc.). Regardless, I continually get the following error
message and stack dump when trying to verify the Glance/Keystone
integration:
Step 1: Grab a token
# curl -d '{auth: {tenantName: default,
passwordCredentials:{username: admin, password: admin}}}' -H
Content-type: application/json http://173.23.181.1:35357/v2.0/tokens |
python -mjson.tool
...
token: {
expires: 2012-02-01T15:24:33,
id: fa89fb9a-60d2-4921-b12d-6aee1c177823,
tenant: {
id: 1,
name: default
}
}
You're going to want to grab a long-lived token
Re: [Openstack] [Nova] Essex dead wood cutting
-Original Message- From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: Thursday, February 02, 2012 12:53 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] [Nova] Essex dead wood cutting Thierry Carrez wrote: Just as Nova enters feature freeze, it sounds like a good moment to consider removing deprecated, known-buggy-and-unmaintained or useless feature code from the Essex tree. Here are my suggestions for removal: - Ajaxterm (unmaintained, security issues, replaced by VNC console) - Hyper-V support (known broken and unmaintained) While we are at it (and since I'm getting used to press coverage), what's the state of the VMWareAPI support ? I knew Hyper-V was not working because bugs were reported against it... but I don't really know how functional vmwareapi actually is. The VMware support is in _much_ better shape than the Hyper-V support. We haven't done much to it in the last few weeks (focusing on XenServer support right now) but we've been actively using it from stable/diablo and early essex. Sateesh did some fixups to it when the multinic support went in, and it was in good shape then. There's certainly no need to remove it. It's clearly not tier 1 like XenServer and KVM, but it's in decent enough shape. Cheers, Ewan. ___ 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] Capture of the Keystone/LDAP Role discussion
Sorry I am a little late to this thread. When we talk about Roles, we mean the permissions a given user has in a given tenant. As such, it is a three way relationship, and LDAP does not handle those well. Have we also consider services and global roles? There was security bug regarding tenant role conflicts/overlaps. https://bugs.launchpad.net/keystone/+bug/890411 How are they being handled in your LDAP design? Guang -Original Message- From: openstack-bounces+guang.yee=hp@lists.launchpad.net [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of Adam Young Sent: Thursday, February 02, 2012 12:55 PM To: Ryan Lane; openstack@lists.launchpad.net Subject: Re: [Openstack] Capture of the Keystone/LDAP Role discussion On 02/02/2012 11:50 AM, Ryan Lane wrote: Based on discussions with numerous people, It seems that the subtree approach (as done by nova deprecated) is the norm. It's a normal approach taken by a number of applications, yes. It's not a bad way to handle this, and we are already doing it in nova. The plus of doing it this way, rather than key-value pairs on users, is that when a tenant is deleted, all of the roles are deleted with it. Also, referential integrity plugins can remove userdns from tenants and roles when a user is deleted. It'll still be necessary for admins to remove users from roles when removed from tenants, and we can't depend on that, so we should handle that case. I'll make sure that gets in. What seems to vary the most amongst LDAP servers is not the schema, but the method used to query for membership in nested groups. In OpenLDAP, the syntax involves sets http://www.openldap.org/faq/data/cache/1133.html http://www.openldap.org/faq/data/cache/1134.html Whereas in Active directory, it involves using LDAP_MATCHING_RULE_IN_CHAIN rule OID. In the 389 (Fedora) Directory Server as well as OpenLDAP it is also possible to use the deference control in conjunction with the memberof plugin. However, we might not need to query for nested group membership. For example, lets assume a tenant has 3 administrative roles: user management, network management, VM management. In addition, users that do not have an explicit admin role get read only access to the resources of that tenant. So a user that has the right to manage networks for that tenant would have to appear in both the members list of that tenant as well as in the networkMgmt role. The first is provided for read only access, and the second for the ability to modify the network. It is a little redundant. We could perhaps put a constraint on the roles that they will only allow users that are listed in the general membership for that tenancy. It shouldn't be necessary to do nested searching. When searching for tenant roles for a user, it should be enough to search for the user as a member of roles using the tenant as a base. Even if nested group searching is necessary, it's possible to do nested searching without support for it on the LDAP server side. A recursive search works here. memberOf is also a possibility, but it needs to be supported on the server side; also, some servers use memberOf, and some use isMemberOf, so we'd have to make that configurable. It's likely best to assume some server in use won't support plugins or extensions. We can discover capabilities from the server and use a more efficient method if it's available, while falling back to the less efficient method. Short-lived caches of the results can also alleviate performance problems due to inefficient queries. Right. First step is getting something to function, and then we can performance tune. There was some talk about nesting tenancies for resellers. This is somewhat different from nested group member ship, as entry in the lower level tenant should *not* provide access to all resources of the containing tenancy. Permissions go the other way around: if I am an admin of the container, I can manage elements of the contained. It does mean that the Keystone server needs to be smart enough to check all of the levels of nesting from lowest to highest to see if a user has the appropriate role for the requested operation. So, to summarize: Roles will be entites under tenants, with a member field that indicates the users that have that role. We still need some way to differentiate between roles and tenants, otherwise subtree searches will cause problems. In nova we handled this by assigning the owner attribute on tenants, but no owner on roles. This allowed tenants to be found via a search like this: ((objectclass=groupofnames)(owner=*)) Roles are then discovered by a search like this, using the tenant as a base: (objectclass=groupofnames) Alternatively, we could add schema for roles and projects. It seems a little overkill to add schema just to differentiate these for subtree searches, though. I don't love
Re: [Openstack] Keystone installation with ManagedIT packages...
That should have read... ... Also - Can you run SELECT * from `endpoint_templates`; against the keystone DB ... Thanks, Kiall On Fri, Feb 3, 2012 at 12:15 AM, Kiall Mac Innes ki...@managedit.ie wrote: Hi Lille, My packages (the Managed I.T ones) certainly do work, the config files shipped with them are fairly stock config files from the git stable/diablo branch, these generally are not setup for use with keystone of of the box. I've got a bunch of scripts and sample config files on our GitHub account[1], Maybe you can compare your config files to these? If that doesn't work, can you place your config's (all of them!) up on http://paste.openstack.org and send us the links? Also - Can you run SELECT * from `endpoint_templates`; against Here is: A sample of what I get back from keystone: http://paste.openstack.org/show/4665/ A sample of the glance index output http://paste.openstack.org/show/4666/ A sample result for the SQL query http://paste.openstack.org/show/4667/ (Note: I have a webserver on port 80 that proxies traffic to the correct service i.e. your ports will likely be different, but the path (the part AFTER the port) should match) Thanks, Kiall [1] https://github.com/managedit/openstack-setup On Thu, Feb 2, 2012 at 10:12 PM, Lillie Ross-CDSR11 ross.lil...@motorolasolutions.com wrote: Still having issues. I found a config bug in my Keystone.conf file in the filter pipeline for the d5_compat modules. However, when I fix the config to match the installation guide and restart keystone, I get an error message that the d5_compat module can't be found. My keystone installation is from the ManagedIT PPA. Is this a bug in the documentation? In the ManagedIT packages? The pipeline for the ManageIT package is configured as follows: [pipeline:admin] pipeline = urlrewritefilter admin_api [pipeline:keystone-legacy-auth] pipeline = urlrewritefilter legacy_auth RAX-KEY-extension service_api versus what is specified in the installation guide. Does this difference matter? What are the differences? Regards, Ross On Feb 1, 2012, at 10:31 AM, Lillie Ross-CDSR11 wrote: Hi Jay, Yes, this confused me, however I get the same error using the token I generated and added (via the keystone-manage command). To wit: root@nova:~# keystone-manage token list token userexpiration tenant --- 10111213141516171819 1 2022-01-01 00:00:00 2 fa89fb9a-60d2-4921-b12d-6aee1c177823 1 2012-02-01 15:24:33 1 b06c5e4e-5e59-4293-aa54-ce6879f11371 2 2012-02-01 15:26:41 1 where the first token is the long-lived one I supplied during installation. Running the glance command yields identical results: root@nova:~# glance -v -A 10111213141516171819 details Failed to show details. Got error: Internal Server error: Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/eventlet/wsgi.py, line 336, in handle_one_response result = self.application(self.environ, start_response) File /usr/lib/python2.7/dist-packages/webob/dec.py, line 147, in __call__ resp = self.call_func(req, *args, **self.kwargs) File /usr/lib/python2.7/dist-packages/webob/dec.py, line 208, in call_func return self.func(req, *args, **kwargs) File /usr/lib/python2.7/dist-packages/glance/common/wsgi.py, line 113, in __call__ response = req.get_response(self.application) File /usr/lib/python2.7/dist-packages/webob/request.py, line 1053, in get_response application, catch_exc_info=False) File /usr/lib/python2.7/dist-packages/webob/request.py, line 1022, in call_application app_iter = application(self.environ, start_response) File /usr/lib/python2.7/dist-packages/webob/dec.py, line 147, in __call__ resp = self.call_func(req, *args, **self.kwargs) File /usr/lib/python2.7/dist-packages/webob/dec.py, line 208, in call_func return self.func(req, *args, **kwargs) File /usr/lib/python2.7/dist-packages/glance/common/wsgi.py, line 110, in __call__ response = self.process_request(req) File /usr/lib/python2.7/dist-packages/glance/common/context.py, line 104, in process_request raise exception.NotAuthorized() NotAuthorized: None Completed in 0.0031 sec. Interestingly (perhaps) I see nothing in the keystone.log file. In fact, I don't even see the keystone log file. Keystone opens to log files named 'admin.log' and 'keystone_legacy_auth.log'. Is this right? Also, if I run keystone interactively (keystone -v -d) then issue the glance command, I see nothing in the keystone window. This doesn't seem right to me, but I'm just getting started with keystone integration. Thanks in advance for any insight... Regards, Ross On Jan 31, 2012, at 6:48 PM, Jay Pipes wrote: On 01/31/2012 06:28 PM, Lillie Ross-CDSR11 wrote: I'm reinstalling the
Re: [Openstack] Capture of the Keystone/LDAP Role discussion
Had a chat with some long time Identity Management developers. They cautioned me against using organizationalRole as it is often abused in organizations and we might have conflicts.. However, it seems like using organizationalUnit for tenants is corrent, and very much in keeping with what happens is many hosting providers. So I now suggest that tenants become objectType organizationalUnit and roles are done as groupOfNames within the tenants. On 02/02/2012 03:54 PM, Adam Young wrote: We still need some way to differentiate between roles and tenants, otherwise subtree searches will cause problems. In nova we handled this by assigning the owner attribute on tenants, but no owner on roles. This allowed tenants to be found via a search like this: ((objectclass=groupofnames)(owner=*)) Roles are then discovered by a search like this, using the tenant as a base: (objectclass=groupofnames) Alternatively, we could add schema for roles and projects. It seems a little overkill to add schema just to differentiate these for subtree searches, though. I don't love this solution, as it is not really very self documenting, and it would be easy enough for someone to mess it up. objectClasses: ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( cn ) MAY ( member $ businessCategory $ seeAlso $ owner $ ou $ o $ description ) Seems like what we really want is organizationalRole from http://www.ietf.org/rfc/rfc4519.txt 3.10. 'organizationalRole' The 'organizationalRole' object class is the basis of an entry that represents a job, function, or position in an organization. (Source: X.521 [X.521]) ( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l $ description ) ) With the users going in the roleOccupant field. This is in core.ldif in the schema ___ 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] [Nova] Essex dead wood cutting
Having deployed an early OpenStack HyperV cloud, I'd say the following are some good places for MS to start: A MS driven development effort to bring feature parity with other supported hypervisors. A commitment to maintain the HyperV components on an ongoing basis. Contribution of resources to foster and help grow community participation and infrastructure. Active participation within the OpenStack community and other OpenStack projects to support and promote interoperability. An open mind. pp On Thu, Feb 02, 2012 at 01:49:59AM +, Sriram Subramanian wrote: What kind of support from MS is needed to support Hyper-V in Openstack? From: openstack-bounces+sriram=computenext@lists.launchpad.net [mailto:openstack-bounces+sriram=computenext@lists.launchpad.net] On Behalf Of Rangababu Chakravarthula Sent: Wednesday, February 01, 2012 6:17 AM To: Wayne Walls Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Nova] Essex dead wood cutting We use Ubuntu KVM + Libivrt and have helped several clients build private clouds and all of them are using Windows guests (Win 2003, Win 2008, Win 7). For all the issues that we had with windows guests on KVM, we had to figure out ourselves or get help from kvm community forums. MS would only support if you use Windows 2008 Datacenter or other commercial certified hypervisors Ranga On Sat, Jan 28, 2012 at 3:32 PM, Wayne Walls [1]wa...@openstack.org wrote: Greetings, Tim! Took a quick stab, answers/comments in-line. Cheers, Wayne On 1/28/12 2:34 PM, Tim Bell [2]tim.b...@cern.ch wrote: With the Hyper-V support being phased out, I would be interested to understand: - What hypervisors are being used for running Windows guests (both Windows 7 and Windows Server) on top of OpenStack ? The quick and dirty answer is KVM, and somewhere along the lines we'll see Citrix XenServer join the race (hopefully sooner rather than later :)). Plug for XenServer: [3]http://wiki.openstack.org/XenServerDevelopment -- maybe Ewan/Anne has an update for when we'll see full blown XenServer+OpenStack install guides? - To what extent will Microsoft support problems reported with a Windows guest running on a non-Microsoft hypervisor ? I think this is a much harder question to answer, as in the past ([4]http://www.redhat.com/promo/svvp) there has been a reciprocal agreement between RedHat and MS to support each others efforts on their own respective virtualization platforms. Seeing that a) Ubuntu+KVM/libvirt is the current standard, and b) RedHat is not actively participating in the OpenStack community it leaves us with a big question mark. Any companies out there that are running KVM clouds w/ Windows care to address this? Do you have customers that want to know how upstream KVM issues are handled? Citrix and Microsoft on the other hand have a fairly long standing partnership, so anything MS products running on XenServer should see a clear escalation path I'd think. - Are there other sites who are affected by this proposal who would be willing to invest effort to maintain the Hyper-V support ? Is there a group that has taken ownership of this? I know that Jordan Rinke (Rackspace), Alex Landman and Peter Pouliot (Novell MS Interop Lab @ SUSE) spent a lot of time on Hyper-V in the Bexar/Cactus releases. They made pretty significant strides in that period, but the progress has since subsided. With the latest movement in the Hyper-V arena, especially around them trying to get full Ubuntu and Debian support in there, does that mean it's less and less likely MS will support their products or competing HV's? Tim Bell CERN -Original Message- From: openstack-bounces+tim.bell=[5]cern...@lists.launchpad.net [mailto:[6]openstack-bounces+tim.bell=[7]cern...@lists.launchpad.net] On Behalf Of Sandy Walsh Sent: 27 January 2012 16:45 To: Thierry Carrez; [8]openstack@lists.launchpad.net Subject: Re: [Openstack] [Nova] Essex dead wood cutting I'll be taking the existing Zones code out of API and Distributed Scheduler. The new Zones infrastructure is an optional component. -S From: openstack-bounces+sandy.walsh=[9]rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=[10]rackspace@lists.launchpad.net] on behalf of Thierry Carrez [[11]thie...@openstack.org] Sent: Friday, January 27, 2012 11:23 AM To: [12]openstack@lists.launchpad.net Subject: [Openstack] [Nova] Essex dead wood cutting Just as Nova enters feature freeze, it sounds like a good moment to consider removing deprecated, known-buggy-and-unmaintained or useless
[Openstack-poc] [Bug 925775] [NEW] utils.import_object sometimes masks the failed import
Public bug reported:
146 def import_class(import_str):
147 Returns a class from a string including module and class
148 mod_str, _sep, class_str = import_str.rpartition('.')
149 try:
150 __import__(mod_str)
151 return getattr(sys.modules[mod_str], class_str)
152 except (ImportError, ValueError, AttributeError):
153 raise exception.NotFound('Class %s cannot be found' % class_str)
From time to time we are seeing the exception raised without the
class_str being filled in making it fun to track down what is not
installed.
** Affects: openstack-common
Importance: Undecided
Status: Confirmed
--
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/925775
Title:
utils.import_object sometimes masks the failed import
Status in openstack-common:
Confirmed
Bug description:
146 def import_class(import_str):
147 Returns a class from a string including module and class
148 mod_str, _sep, class_str = import_str.rpartition('.')
149 try:
150 __import__(mod_str)
151 return getattr(sys.modules[mod_str], class_str)
152 except (ImportError, ValueError, AttributeError):
153 raise exception.NotFound('Class %s cannot be found' % class_str)
From time to time we are seeing the exception raised without the
class_str being filled in making it fun to track down what is not
installed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/925775/+subscriptions
___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help : https://help.launchpad.net/ListHelp
[Openstack-poc] [Bug 925775] Re: utils.import_object sometimes masks the failed import
** Changed in: openstack-common
Status: New = Confirmed
--
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/925775
Title:
utils.import_object sometimes masks the failed import
Status in openstack-common:
Confirmed
Bug description:
146 def import_class(import_str):
147 Returns a class from a string including module and class
148 mod_str, _sep, class_str = import_str.rpartition('.')
149 try:
150 __import__(mod_str)
151 return getattr(sys.modules[mod_str], class_str)
152 except (ImportError, ValueError, AttributeError):
153 raise exception.NotFound('Class %s cannot be found' % class_str)
From time to time we are seeing the exception raised without the
class_str being filled in making it fun to track down what is not
installed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/925775/+subscriptions
___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help : https://help.launchpad.net/ListHelp
