Re: [Openstack] Keystone: LDAP identity driver 'list resource' support
Hey Boden, It's not scheduled to be fixed in the Folsom release, the linkages to milestones and such indicate that. The original developer that proposed a patch disappeared in that flow, so it stagnated. Adam just picked it up and assigned it to himself though to dig around on it - so perhaps he can provide more detail there. -joe On Sep 10, 2012, at 10:31 AM, boden bo...@linux.vnet.ibm.com wrote: Thanks... Is this defect going to get resolved in the folsom time-frame? Looks like the target milestone was set to none and the defect has been inactive for 2.5 months. On 9/10/2012 12:43 PM, Dolph Mathews wrote: You thought correct: https://bugs.launchpad.net/keystone/+bug/983304 -Dolph On Mon, Sep 10, 2012 at 11:32 AM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 09/10/2012 11:29 AM, boden wrote: I've been munking with the latest Keystone LDAP identity driver and based on what I'm seeing the driver does not support the 'list' resource based methods. For example 'list users', 'list tenants'... For example, config your keystone.conf up to use an LDAP backend which contains the supported DIT structure for the driver and then fire up keystone. Hit keystone with a GET /users or GET /tenants request and 500/501 errors. Switch your identity driver back to the SQL identity driver and retry -- all is well and you can list users and tenants. Looking at the code it appears the ldap identity driver does not implement the list_*() methods (list_users(), list_roles()...) _ Mailing list: https://launchpad.net/~__openstack https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~__openstack https://launchpad.net/~openstack More help : https://help.launchpad.net/__ListHelp https://help.launchpad.net/ListHelp That is correct. I thought we already had a ticket for this one, but it does not appear to be so. Please go ahead and open one. _ Mailing list: https://launchpad.net/~__openstack https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~__openstack https://launchpad.net/~openstack More help : https://help.launchpad.net/__ListHelp 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] keystone questions
On Aug 28, 2012, at 12:41 AM, pat p...@xvalheru.org wrote: Thanks for Q1. About Q2, I more think about keystone instances and each has its own storage and the keystones are interconnected and their data are replicated. The DB, in your suggestion, looks like single point of failure to me. Hi Pat, Yes - it definitely could be. If you're setting up keystone in an HA configuration, then I'd expect that you actually have a mysql cluster backing the database that could allow a single instance of mysql to fail and maintain services. Keystone, like Nova, Glance, etc is stashing it's state somewhere - the WSGI processes that run keystone have moved that to MySQL, so MySQL is the place where you need to watch and care for. Many implementations of OpenStack that I've seen have shared the MySQL instance between keystone, nova, and glance, and quite successfully. If you were using LDAP entirely for the backend instead of the SQL backed mechanisms, then you'd need a replicated/failover cluster for LDAP as well. -joe On Mon, 27 Aug 2012 09:46:41 -0700, Joseph Heck wrote Hi Pat, On Aug 27, 2012, at 8:09 AM, pat p...@xvalheru.org wrote: I have two questions regarding OpenStack Keystone: Q1) The Folsom release supports domains. The domain can contain more tenants and tenant cannot be shared between domains. Is this right? I think so, but want to be sure. I'm afraid it doesn't. We didn't make sufficient progress with the V3 API (which is what incorporates domains) to include that with the Folsom release. We expect this to be available with the grizzly release. Q2) Is it posible to have a “cluster” of the Keystones to avoid Keystone to be a bottleneck? If so, could you point me to a “tutorial”? Or did I missed something important? If by cluster you mean multiple instances to handle requests, then absolutely - yes. For this particular response, I'll assume you're using a SQL backend for Keystone. Generally you maintain a single database - wether that's an HA cluster or a single instance, and any number of Keystone service instances can point to and use that. Freehosting PIPNI - http://www.pipni.cz/ ___ 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] keystone questions
Hi Pat, On Aug 27, 2012, at 8:09 AM, pat p...@xvalheru.org wrote: I have two questions regarding OpenStack Keystone: Q1) The Folsom release supports domains. The domain can contain more tenants and tenant cannot be shared between domains. Is this right? I think so, but want to be sure. I'm afraid it doesn't. We didn't make sufficient progress with the V3 API (which is what incorporates domains) to include that with the Folsom release. We expect this to be available with the grizzly release. Q2) Is it posible to have a “cluster” of the Keystones to avoid Keystone to be a bottleneck? If so, could you point me to a “tutorial”? Or did I missed something important? If by cluster you mean multiple instances to handle requests, then absolutely - yes. For this particular response, I'll assume you're using a SQL backend for Keystone. Generally you maintain a single database - wether that's an HA cluster or a single instance, and any number of Keystone service instances can point to and use that. -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] KeyStone service is not responding while installing thorough DevStack !!
Trinath - it sounds like PyPi was slow and/or hung. That happens upon occasion (and has caused much grief). I'm guessing by the time I'm responding to this, it's cleared up for you. Are you able to run through devstack now without issue? - joe On Aug 23, 2012, at 1:39 AM, Trinath Somanchi trinath.soman...@gmail.com wrote: Hi- Me too experiencing the same. I was struck at this point. Downloading/unpacking prettytable (from -r python_keystoneclient.egg.info/requires.txt (line 2)) It was just struck here... and not moving forward. Can any one guide me troubleshooting the issue. - Trinath ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] KeyStone service is not responding while installing thorough DevStack !!
One of two things - either the file doesn't exist in that location, or the process running it doesn't have permissions to see the file. Does the file exist at /etc/keystone/logging.conf? Devstack tries to set that up in the right location in stack.sh at line 2038 - did that fail when you ran it? -joe On Aug 23, 2012, at 8:28 AM, hitesh wadekar hitesh.wade...@gmail.com wrote: Thanks Dolph and Joseph for a quick answers. I tried through command though,.. cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/kestone/logging.conf -d --debug The output of this - Traceback (most recent call last): File /opt/stack/keystone/bin/keystone-all, line 83, in module config.setup_logging(CONF) File /opt/stack/keystone/keystone/config.py, line 45, in setup_logging 'config file: %s' % conf.log_config) RuntimeError: Unable to locate specified logging config file: /etc/kestone/logging.conf It seems some problem with logging.conf file.. any idea? location issue?. Thanks, Hitesh On Thu, Aug 23, 2012 at 5:21 PM, Dolph Mathews dolph.math...@gmail.com wrote: What exactly happens when you try to start it directly? cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/ke'stone/logging.conf -d --debug What happens when you curl http://localhost:5000/v2.0/ on that machine? And with port 35357? -Dolph On Thu, Aug 23, 2012 at 3:15 AM, hitesh wadekar hitesh.wade...@gmail.com wrote: Guys, I am installing DevStack script. I stucked here. + screen -S stack -p key -X stuff 'cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/ke'stone/logging.conf -d --debug echo 'Waiting for keystone to start...' Waiting for keystone to start... + timeout 60 sh -c 'while ! http_proxy= curl -s http://192.168.1.100:5000/v2.0/ /dev/null; do sleep 1; done' + echo 'keystone did not start' keystone did not start By looking at message, it is sure that KeyStone service has not been responding. I installed it manually but no luck still seen the same issue. Any suggestion or pointers for this? Thanks, Hitesh Wadekar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- -Dolph ___ 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] sort_key and sort_dir for collections based REST APIs
In the V3 Keystone API, we asserted that we wanted filter functions, but didn't go to the length of defining a sort_key and sort_direction in the API spec. ref: https://docs.google.com/document/d/1VP-bTBbwsn6q-rDzuS9CEKb2ubE1VjbWRFd4BkkjoOY/edit?pli=1 -joe On Aug 20, 2012, at 10:05 AM, Brian Waldon bcwal...@gmail.com wrote: As we can't just add things to our APIs, it's not straight-forward to support them across the board. I think it would make sense to bake these parameters into the next versions of our APIs for collection sorting, but my opinion is definitely biased. Maybe Joe Heck can comment, as he's working on the v2 Identity API. Brian On Aug 20, 2012, at 11:43 AM, boden wrote: All, Is anybody here familiar with the 'sort_key' and 'sort_dir' parameters for collection based APIs? Specifically I'm wondering if there are any plans to add support for these 2 params across the board (all collections based REST APIs including the 'primary compute extensions')? Based on my google-ability it appears they are only on the glance image APIs (http://docs.openstack.org/developer/glance/glanceapi.html ) at the present moment, so looking for more clarity on this topic intermediate to longer term. Thanks much ___ 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] keystone and ssl ?
The basic support for SSL has been readded to Keystone earlier this release cycle, alough theres still a few pieces trickling through the pipeline (recent updates to keystone client to allow for self-signed certs). It needs testing, and I dont know that we yet have good deployment option docs (there are several options there) on how to deploy keystone with SSL. The option to use a signed SSL cert as an authenticated administrative request itself has not been re-added, instead there was more interest from developers doing the code to focus on getting a base PKI implementation to allow for generically signed tokens in this release. - joe On Aug 3, 2012, at 9:13 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/03/2012 05:18 AM, Pierre Amadio wrote: snip https://blueprints.launchpad.net/keystone/+spec/2-way-ssl At the bottom of the blueprint, there are 2 addressed by links with a set of patches: https://review.openstack.org/1038 https://review.openstack.org/7706 But i do not find trace of those patches in the ubuntu package snip I also fail to find trace of those in a git checkout of the refs/heads/stable/essex branch of keystone's git repository. I am confused. The reason is because that code and a bunch of other stuff was ripped out of Keystone late in the Essex release series with the move to Keystone Light, which was essentially a rewrite of Keystone that replaced the Keystone project that had the code in it that you refer to above. I've cc'd Joe Heck to give you some information on when SSL support might be re-added to Keystone. Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone: 'PKI Signed Tokens' lack support for revocation
Hey Maru, I think you're putting too many words in Adam's mouth here. First, Adam didnt assert is wasnt valuable, useful, or nessecary - simply that it wasnt in the first cut and not in the list that we agreed was critically essential to an initial implementation. As you noted, its a complex and somewhat tricky issue to get right. There's always room for more participation to correct the flaws you see in the existing system - the beauty of open source. I would love to see continued work on the signing and revocation work to drive in these features that mean so much to you. I'd be happy to open a blueprint if you can stand behind it, define what you think it required, and commit to the work to implement that revocation mechanism. Implying negative emotions on Adam's part when he's been one driving the implementation and doing the work is simply inappropriate. Please consider the blueprint route, definition of a viable solution, and work to make it happen instead of name calling and asserting how the developers doing the work are screwing up. - joe On Aug 1, 2012, at 8:05 PM, Maru Newby mne...@internap.com wrote: Hi Adam, I apologize if my questions were answered before. I wasn't aware that what I perceive as a very serious security concern was openly discussed. The arguments against revocation support, as you've described them, seem to be: - it's complicated/messy/expensive to implement and/or execute - Kerberos doesn't need it, so why would we? I'm not sure why either of these arguments would justify the potential security hole that a lack of revocation represents, but I suppose a 'short enough' token lifespan could minimize that hole. But how short a span are you suggesting as being acceptable? The delay between when a user's access permissions change (whether roles, password or even account deactivation) and when the ticket reflects that change is my concern. The default in Keystone has been 24h, which is clearly too long. Something on the order of 5 minutes would be ideal, but then ticket issuance could become the bottleneck. Validity that's much longer could be a real problem, though. Maybe not at the cloud administration level, but for a given project I can imagine someone being fired and their access being revoked. How long is an acceptable period for that ticket to still be valid? How much damage could be done by someone who should no longer have access to an account if their access cannot be revoked, by anyone, at all? I'm hearing that you, as the implementer of this feature, don't consider the lack of revocation to be an issue. What am I missing? Is support for revocation so repugnant that the potential security hole is preferable? I can see that from a developer's perspective, but I don't understand why someone deploying Keystone wouldn't avoid PKI tokens until revocation support became available. Thanks, Maru On 2012-08-01, at 9:47 PM, Adam Young wrote: On 08/01/2012 09:19 PM, Maru Newby wrote: I see that support for PKI Signed Tokens has been added to Keystone without support for token revocation. I tried to raise this issue on the bug report: https://bugs.launchpad.net/keystone/+bug/1003962/comments/4 And the review: https://review.openstack.org/#/c/7754/ I'm curious as to whether anybody shares my concern and if there is a specific reason why nobody responded to my question as to why revocation is not required for this new token scheme. Anybody? It was discussed back when I wrote the Blueprint. While it is possible to do revocations with PKI, it is expensive and requires a lot of extra checking. Revocation is a policy decision, and the assumption is that people that are going to use PKI tokens are comfortable with out revocation. Kerberos service tickets have the same limitation, and Kerberos has been in deployment that way for close to 25 years. Assuming that PKI ticket lifespan is short enough, revocation should not be required. What will be tricky is to balance the needs of long lived tokens (delayed operations, long running operations) against the needs for reasonable token timeout. PKI Token revocation would look like CRLs in the Certificate world. While they are used, they are clunky. Each time a token gets revoked, a blast message would have to go out to all registered parties informing them of the revocation. Keystone does not yet have a message queue interface, so doing that is prohibitive in the first implementation. Note that users can get disabled, and token chaining will no longer work: you won't be able to use a token to get a new token from Keystone. Thanks, Maru ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help :
Re: [Openstack] [KeyStone] Requestid, context, notification in Keystone
Thanks Jay! On Jul 23, 2012, at 9:49 AM, Jay Pipes wrote: On 07/21/2012 02:57 AM, Joseph Heck wrote: Hey Nachi If by this you mean the idea that a request ID is created at a user request action, and then propagated through all relevant systems and API calls to make tracing the distributed calls easier, I'm totally in favor of the idea. Distributed tracing through the calls has been a real pain in the a... I'm afraid I haven't been watching the other projects closely enough to realize that this was getting implemented - any chance you could point out the relevant change reviews so I could see where/how the other projects have been doing this? Hey Joe, Here is a relevant patch for Glance: https://review.openstack.org/#/c/9545/ Best, -jay ___ 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] Identity API v3 - Why allow multi-tenant users?
Perhaps a poor analogy with email - The domain is an arbitrary string that's intended for tenant isolation in large openstack environments. It's a place to hang policy so that you can delegate things like password changing (where the keystone backend supports it) to someone other than the keystone-uber-administrator. I expect almost any smaller/smallish deployment of OpenStack to likely use just a single domain, which is mostly ignored. It's really a mechanism in place for service-provider sized clouds, or where you want to be able to enforce hard boundaries in permissions between groups of tenants by customizing the policy.json files to respect domain_id information. I would expect that in any implementation, it would be independent of email domain names or such - At least that wouldn't be a way that I'd slice up permissions across projects. -joe On Jul 18, 2012, at 9:25 AM, Tim Bell wrote: Thanks…. My worry is the username. Currently, I have OS_USERNAME=timbell Not OS_USERNAME=timb...@cern.ch Does that mean in the future that my OS_USERNAME=timbell OS_DOMAINNAME=cern.ch I would like that I could still register as timbell in my domain even if someone else on the same OpenStack instance has a user id of timbell. Cross domain, federated identity as part of an authorization layer would be an interesting development (as we look to federated clouds and bursting) but I didn’t see something like that in v3. Tim From: openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of Adam Young Sent: 18 July 2012 17:46 To: openstack@lists.launchpad.net Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users? The idea of a Domain is that it is a single administrative entity, such as a company. When a person joins a company, they get an email adddress. THat address does not change regardless of the position they hold. Tenants are administrative groupings below that. It is unfortunate that we used the name tenants for this, as it actually contradicts the usual meaning of the term. We will be shortly switching back to using the term projects, and I think that is clearer. It certainly makes sense for a user to belong to one domain, but have access to a project controlled in another domain. Here is a scenario. Joe's Sporting Goods and Local Bank are both companies that have a presense in a coud provider. Each has their own domain. t...@localbank.com is going to set up a Point of Sale system for Joe. So Joe creates a project called joes-point-of-sale and provides access to user t...@localbank.com. On 07/18/2012 02:46 AM, Matt Joyce wrote: I could see service users and security / operations teams having a need to span many domains. -Matt On Tue, Jul 17, 2012 at 11:24 PM, Tim Bell tim.b...@cern.ch wrote: I thought that the v3 API supports domains as a group of tenants which would make the question rather different. Thus, I guess the question is A. Should there be users in multiple tenants in a single domain ? B. Should there be users in multiple domains ? There are clear use cases for A (such as researchers working on multiple projects sharing project quotas) For B, it is less clear as if I am a domain administrator, I do not want to be told that I cannot allocate user X since another domain has already taken it. On the other hand, there is a clear architectural benefit from having the concept of identity (and authentication) split off from roles and projects. Tim From: openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of John Postlethwait Sent: 18 July 2012 07:42 To: Rouault, Jason (Cloud Services) Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users? Forcing a user to remember different usernames and/or passwords for each project they are a part of, when it is possible they are part of N projects, really isn't an acceptable option in my opinion. I believe that regardless of the engineering complexities, the end users shouldn't have to feel pain in order to make engineering the solutions and features they interact with easier. Software is for end users (in their various forms) and as such we need to take that into account when we make decisions. While no functionality is lost per se, there is a major end-user impact, and that should be reason enough to implement it… John Postlethwait Nebula, Inc. 206-999-4492 On Tuesday, July 17, 2012 at 4:15 PM, Rouault, Jason (Cloud Services) wrote: One benefit is the user does not need to have multiple sets of credentials to interact with multiple projects. Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net
Re: [Openstack] [Keystone] Quotas: LDAP Help
That's the general area I was going to head with the Active Directory backend I'm hacking on. Chris Hoge of UOregon presented today (@ OSCON) on a local keystone hack that they did to enable LDAP AuthN + a fail back to SQL based system for their scientific computing cluster - follows a very similar model. -joe On Jul 17, 2012, at 2:16 PM, Tim Bell tim.b...@cern.ch wrote: +1 The corporate LDAP should be read-only for a source of user, roles and attributes. Updating the corporate LDAP is not an option in many environments which can significantly benefit from the structured directory information available. Thus, at minimum, allow a r/o LDAP and local DB store for any openstack specific information that needs updating. Tim -Original Message- From: openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of Ryan Lane Sent: 17 July 2012 20:43 To: Adam Young Cc: Joseph Heck; openstack Subject: Re: [Openstack] [Keystone] Quotas: LDAP Help I haven't been thinking about quotas, so bear with me here. A few thoughts: Certain deployments might not be able to touch the LDAP backend. I am thinking specifically where there is a corporate AD/LDAP server. I tried to keep the scheme dependency simple enough that it could be layered onto a read-only scenario. If we put quotas into LDAP, it might break on those deployments. Many, many deployments won't be able to. Applications should generally assume they are read-only in regards to LDAP. I can see that we don't want to define them in the Nova database, as Swift might not have access to that, and swift is going to be one of the primary consumers of Quotas. I am Assuming Quantum will have them as well. As you are aware, there is no metadata storage in the LDAP driver, instead it is generated from the tenant and role information on the fly. There is no place to store metadata in groupOfNames which is the lowest( common denominator) grouping used for Tenants. Probably the most correct thing to do would be to use a seeAlso that points to where the quota data is stored. Let's try not to force things into attributes if possible. When LDAP is used, is the SQL backend not used at all? Why not store quota info in Keystone's SQL backend, but pull user info from LDAP, when enabled? We should only consider storing something in LDAP if it's going to be reused by other applications. LDAP has a strict schema for exactly this purpose. If the quota information isn't directly usable by other applications we shouldn't store it in LDAP. Many applications with an LDAP backend also have an SQL backend, and use the SQL as primary storage for most things, and as a cache for LDAP, if it's used. I think this is likely a sane approach here, as well. - Ryan ___ 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] [Keystone] Services API
In the V2 API, there's no update available - it's just create/delete. -joe On Jul 13, 2012, at 5:19 AM, Antonio Manuel Muñiz Martín wrote: There are no method update_service here [1], so I think update is not possible, am I right? Thanks, Antonio. [1] https://github.com/openstack/keystone/blob/0425fba560e7d68e52f922667972765e64ad17dc/keystone/controllers/services.py 2012/7/13 Antonio Manuel Muñiz Martín amu...@klicap.es: Hi, I'm trying to make an update request (PUT /v2.0/OS-KSADM/services/53ccd2984389495cab439640dc5596d3) and it's returning HTTP 404. The docs also miss the PUT method [1], so I guess if there is a way to update a service through the WS API? Thanks, Antonio. [1] http://docs.rackspace.com/openstack-extensions/auth/OS-KSADM-admin-devguide/content/Service_Operations_OS-KSADM.html -- Antonio Manuel Muñiz Martín Software Developer at klicap - ingeniería del puzle work phone + 34 954 894 322 www.klicap.es | blog.klicap.es -- Antonio Manuel Muñiz Martín Software Developer at klicap - ingeniería del puzle work phone + 34 954 894 322 www.klicap.es | blog.klicap.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [keystone] - V3 API implementation folsom goals
During Tuesday's keystone meeting (http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-07-10-18.01.html if you're curious), we reviewed the work that we'd originally lined up against Folsom and did a check against the time remaining in the development cycle (through August 16th - http://wiki.openstack.org/FolsomReleaseSchedule). It was pretty clear that while we had high hopes, there's a lot remaining that isn't going to get done. Related to that, I've unlinked a significant number of blueprints from the folsom-3 milestone. Based on the current trajectory, I suspect they won't make it for those blueprints. If we start making significant traction on the development to get those features and components done, then we'll relink them. The V3 API has been nailed down sufficient to start implementation, and that's my view of our highest focus outside of the PKI work that Adam Young has been pushing into place. I am hopeful that we can have a V3 API fully implemented and operational by the end of the Folsom-3 milestone (in a few weeks), but I feel it's far too late in the development cycle to ask any other OpenStack core projects to rely on that effort for a Folsom release. Regardless of hope, I've unlinked the V3 API blueprint and the pieces dependent on it from the folsom series until it's clear that we're going to be in a position to actually deliver those items. Related to the V3 API work, I've done a quick breakdown, and we're abusing the bug mechanism in launchpad to help coordinate and track. The bugs related to the work breakdown have all been tagged with v3api, and have been prioritized. The general breakdown is set to implement tests that represent the V3 API, and then fill in the implementation to make those tests work. -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [keystone] Keystone V3 API - draft 3 - implementation draft available
Thanks again to everyone that read, commented, and suggested improvements into the Keystone V3 API. This process has been immensely valuable, although far more time consuming than I expected. I've created a 3rd draft, now available at https://docs.google.com/document/d/1VP-bTBbwsn6q-rDzuS9CEKb2ubE1VjbWRFd4BkkjoOY/edit The third draft is *mostly* a refinement of the 2nd, with the notable difference being that (as threatened at the design summit), I've renamed tenant to project to revert back to the original naming structure. (sorry Jay, changing it to account - while semantically pretty good - lost out to existing terms in our documentation and history) We don't have all the questions answered, and the largest the consistently came up in this last draft was how to deal with requesting related items - potentially through query-able arguments to GET verbs on the resources. While I may regret not nailing that down right now, I'm going to run with Brian's learning from the Glance API implementation and leave this draft open, but begin implementation so we can see what in there (while nice) is made up of unimplementium. ___ 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]Is the cloudfiles compatible with keystone v2.0?
Pete- not quite accurate on the ports. Both ports are used in Keystone in the Essex release. 35357 is the one registered with IANA, and is the administrative port in that only administrative accounts can call in REST API's there. Port 5000 is the public port when you've got it configured in an all-in-one configuration, and just commonly used since then. -joe (a keystone person) On Jul 5, 2012, at 7:34 PM, Pete Zaitcev wrote: On Thu, 5 Jul 2012 18:21:48 +0800 Alex Yang alex890...@gmail.com wrote: If i want use the cloudfiles with the keystone(the newest version), I need change the code of cloudfiles by myself? Indeed, clients have to be adapted in cases like yours. However, please look at python-swiftclient. It may be sufficiently similar so you don't need to change much in your application that uses python-cloudfiles. By the way, it was my understanding that Keystone people encourage everyone to migrate from port 5000 to port 35357. The latter is assigned with IANA. -- 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
[Openstack] [keystone] Congrats to Adam Young - now in Keystone Core
Congrats to Adam Young - now a member of Keystone Core. For those of you who don't know, Adam drove the initial LDAP backend implementation for the new keystone architecture, and has been the driving force (technically and code) behind getting PKI enabled within Keystone for signed tokens as we step things forward. Thanks Adam, and as a sincere congratulations, we'll be giving you more work :-) Seriously, though - great work! We all appreciate it! -joe ___ 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] Adding docs gating jobs?
I'm for it. On Jun 26, 2012, at 9:17 AM, Jay Pipes wrote: ++ -jay On 06/26/2012 10:02 AM, Monty Taylor wrote: Hey guys! We have all of the projects properly and consistently building and uploading sphinx docs from in tree. This is pretty exciting, because it means one more resource we can expect to work. So related to that, we were talking about putting in a gating job for each project to prevent changes from breaking the docs. I don't really expect these jobs to fail builds very often, as the jobs themselves are pretty stable - but obviously it's the kind of thing people might have an opinion on. Thoughts? Monty ___ 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] [keystone] Keystone on port 5000 - proposing change default port to 8770
Honestly the only reason is that I've heard some fairly direct feedback that port 5000 is that MS uPnP port and hence blocked by many corporate entities, so it's just a matter of a PITA and a slight bump in setup for those groups. Thought to honestly register another port with IANA like 35357 and put it in place - wanted to see if anyone screamed first. -joe On Jun 20, 2012, at 8:49 PM, Vaze, Mandar wrote: public_port is configurable via keystone.conf - so if port 5000 is blocked in specific setup, it is trivial to change it to some other port. why make so many changes (REST docs, XML docs, devstack, and the code) for a parameter that can be easily tweaked ? -Mandar -Original Message- From: openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net [mailto:openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Thursday, June 21, 2012 4:46 AM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: [Openstack] [keystone] Keystone on port 5000 - proposing change default port to 8770 At the risk of a terrible public tar and feathering... I've learned that port 5000 (which Keystone is using for it's default public-token-auth stuff) is commonly blocked by many firewalls, as it's been registered as a Microsoft uPnP port. I thought I'd go ahead and propose changing the default to 8770. I picked this number because it's close to the Nova ports in common use (8773, 8774, 8775, and 8776). And yes, I'll submit updates to all REST docs, XML docs, devstack, and the code. So... how many people do I need to worry about murdering me for this next design summit? -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] Keystone on port 5000 - proposing change default port to 8770
While I think we could merge the two together and control access with RBAC now, I expect we'll keep separate ports for the use case that Matt Joyce specifically mentions. I've made a blueprint to implement RBAC into keystone, using Keystone (https://blueprints.launchpad.net/keystone/+spec/rbac-keystone-api), but there will still be a need to bootstrap into the system, which may reside only on the admin port. The V3 draft API doesn't distinguish between public and private, somewhat intentionally, as that's something I expect to wrap behind RBAC for most access. That said, having an admin-functions-only running on a private port and potentially disabled is clearly something that Matt (and others?) want to keep available, so I expect we will. -joe On Jun 21, 2012, at 12:36 PM, Gabriel Hurley wrote: The port change is fine with me since we're trampling on an already-registered port number. However, I'd like to ask again about the admin vs. standard ports in the Keystone v3 API. There was no mention of the differentiation between the two or how they would be used. Especially in a post-RBAC/policy.json world, what is an admin API call? Does Keystone really need two ports (Matt Joyce suggests it does) or could they be one? - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Nguyen, Liem Manh Sent: Thursday, June 21, 2012 10:40 AM To: Joseph Heck; Vaze, Mandar Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [keystone] Keystone on port 5000 - proposing change default port to 8770 +1 for an IANA-registered public port. I wonder why we registered the admin port, but not the public port in the first place. Liem -Original Message- From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Thursday, June 21, 2012 1:28 AM To: Vaze, Mandar Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [keystone] Keystone on port 5000 - proposing change default port to 8770 Honestly the only reason is that I've heard some fairly direct feedback that port 5000 is that MS uPnP port and hence blocked by many corporate entities, so it's just a matter of a PITA and a slight bump in setup for those groups. Thought to honestly register another port with IANA like 35357 and put it in place - wanted to see if anyone screamed first. -joe On Jun 20, 2012, at 8:49 PM, Vaze, Mandar wrote: public_port is configurable via keystone.conf - so if port 5000 is blocked in specific setup, it is trivial to change it to some other port. why make so many changes (REST docs, XML docs, devstack, and the code) for a parameter that can be easily tweaked ? -Mandar -Original Message- From: openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net [mailto:openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Thursday, June 21, 2012 4:46 AM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: [Openstack] [keystone] Keystone on port 5000 - proposing change default port to 8770 At the risk of a terrible public tar and feathering... I've learned that port 5000 (which Keystone is using for it's default public- token-auth stuff) is commonly blocked by many firewalls, as it's been registered as a Microsoft uPnP port. I thought I'd go ahead and propose changing the default to 8770. I picked this number because it's close to the Nova ports in common use (8773, 8774, 8775, and 8776). And yes, I'll submit updates to all REST docs, XML docs, devstack, and the code. So... how many people do I need to worry about murdering me for this next design summit? -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding ___ 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
Re: [Openstack] Common openstack client library
Alexey -
where's the library of common that you've put together? Is it committed to
openstack-common? somewhere else?
-joe
On Jun 19, 2012, at 9:43 AM, Alexey Ababilov wrote:
Unfortunately, nova, keystone, and glance clients are very inconsistent. A
lot of code is copied between all these clients instead of moving it to a
common library. The code was edited without synchronization between clients,
so, they have different behaviour:
all client constructors use different parameters (api_key in nova or password
in keystone and so on);
keystoneclient authenticates immediately in __init__, while novaclient does
in lazily during first method call;
{keystone,nova}client can manage service catalogs and accept keystone's auth
URI while glanceclient allows endpoints only;
keystoneclient can support authorization with an unscoped token but
novaclient doesn't;
novaclient uses class composition while keystoneclient uses inheritance.
I have developed a library to unify current clients. The library can be used
as-is, but it would be better if openstack clients dropped their common code
(base.py, exceptions.py and so on) and just began to import common code.
Here is an example of using unified clients.
from openstackclient_base import patch_clients
from openstackclient_base.client import HttpClient
http_client = HttpClient(username=..., password=..., tenant_name=...,
auth_uri=...)
from openstackclient_base.nova.client import ComputeClient
print ComputeClient(http_client).servers.list()
from openstackclient_base.keystone.client import IdentityPublicClient
print IdentityPublicClient(http_client).tenants.list()
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone API V3 - draft 2 now available
Draft 2 of the V3 Core Keystone API is now available for comment: https://docs.google.com/document/d/1_TkawQIa52eSBfS4pv_nx1SJeoBghIlGVZsRJJynKAM/edit In this revision, I've * updated the token structure a bit - to match the new resources * changed how the associations or user-tenant through a role are enabled (POST instead of PUT) * put in detailed examples of responses to every call The general format of this documentation roughly follows the developer documentation at developer.github.com, which I thought had a pretty good model of showing how to use the APIs and describing the relevant pieces. There's a lot of cut and paste in there, so if something seems obviously wrong, it probably is ... please make a comment on the google doc and let me know. This document is far more structured and complete, and contains sufficient detail for those excited about WADLs and XSDs and such to create relevant mappings. Feedback needed please, comment away! -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] v3 API draft (update and questions to the community)
P.S. the X-Subject-Token stuff is breaking HTTP; you need to either put the token (or a facsimile for it) in the URL, or put Vary: Subject-Token in EVERY response those resources generate. The former is preferred; this is over TLS, right? Sorry I didn't see that earlier. P.P.S If it's not too late, drop the X- from that header! http://tools.ietf.org/html/draft-ietf-appsawg-xdash-05 Mark - could you open a bug against Keystone for the X-Subject-Token breaking HTTP with the relevant details? ___ 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] [openstack][keystone] v3 API question
On Jun 8, 2012, at 8:38 PM, Dolph Mathews wrote:
On Jun 8, 2012, at 6:47 PM, Nguyen, Liem Manh liem_m_ngu...@hp.com wrote:
Hi Joe/Dolph,
I have a few questions on the v3 API’s create_user (sorry the comments
section in the Google docs is getting pretty cluttered now):
(POST) /users == create_user
{
tenant_id: ...
name: ...
password: ...
enabled: ...
email: ...
description: ...
}
1. Does this tenant_id option establish the default tenancy of the
created user?
Yes.
2. If it does, is this default tenancy immutable or mutable? If it is
mutable, who (what role) can change it and via what API?
Should be mutable by admins, via the admin API, as it's just a regular
attribute of the user and the keystone admin concept currently applies to
the entire deployment.
3. What is the intended purpose of a user’s default tenancy? Is the
default tenancy association intended to link a user to a given domain
(rather than the normal user-tenant role association)?
To be a little more explicit about the default tenant thing - it's used so
that the user can give a username/password pair to the POST to /token and get
a token scoped to a tenant without the user asserting which tenant it wishes to
use.
Auto-scoping the user's context, when a tenant is not explicitly specified
during auth.
I can't fairly answer the second question because the idea of domains wasn't
around at the time. However, if you replace the term domain with tenant,
I'd say yes.
The reason I am asking this is that I would like to know what level of
isolation (if any) we can establish for users that are homed to different
domains… So, for example, an isolation would be that a user A with a
default tenancy in domain X may not be modified or deleted by a domain-admin
in domain Y, even when user A has tenant membership in domain Y.
I think that's an issue best solved per-deployment by robust RBAC, rather
than being hardcoded either way.
I agree with Dolph - since domains don't segment users, only tenants - then the
choice is really driven by RBAC, which can be encapsulated in rules. None of
the API defined in the v1 draft currently even hints at what RBAC might be
wrapped around each of the calls, but all of those calls can and should be
wrapped as actions and defined in the policy.json file.
We do need to come up with a suggested default implementation - given that
users are not segmented into domains, what would you suggest?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] [keystone] v3 API draft (update and questions to the community)
First a thank you to everyone who's swung by to read (and some comment) on the
V3 draft at
https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit?pli=1.
It's been immensely useful.
To clear up a bit of confusion I caused (sorry Jay!) - there were *no* example
responses included in the document, although some of the pieces certainly
looked like they might be. I put in placeholders for example responses to be
added to make it more explicit, and cleaned up my formatting so that I was
consistent (and hopefully through that, more clear)
This morning/afternoon I went through and tried to provide answers and feedback
to most of the outstanding comments - the folks who commented will see the
results through the Google doc responses as they have notifications defined. I
made a few changes to the draft - in particular, identifing what the primary
key in the resource attributes would/should be from a REST perspective, and
crossing out or adding a few attributes here and there based on feedback. I
also tried to make some spelling fixes where I missed earlier.
I've also added an open points discussion near the top of the document, and I'd
like to raise a few of those issues here on the mailing list.
First - what's the current thought of support for PATCH vs PUT in updating REST
resources? Are there any issues with clients being able to use a PATCH verb?
It's not something I'm super familiar with, so I'm looking for feedback from
the community here. Ideally, I'd like to support the semantics of the PATCH
HTTP verb, and possibly just assert no support for the PUT verb to be clear
about intended functionality. Is that going to throw anyone for a loop?
Second - filtering/searching for resources. The draft includes a section
labelled Query By Name, which is probably mis-labelled, as it's intended to
cover the general idea of passing in query parameters to general listing
resource endpoints to filter the result set. The API endpoints across all the
resources are defined as plurals, with the idea that specificity comes later in
the URI (for referencing a single resource), or that we could add on these
query parameters to restrict/filter by resource type.
Would it be better to make each of the query parameters explicit in the API
beyond the pagination?
Third - there's a general workflow question about how to go from username +
password to a token scoped to a specific tenant. There are a few suggestions
outstanding:
1) make a default tenant concept on a user, and when the user authenticates and
gets a token, it's initially scoped to that specific tenant *unless* the
authentication request also explicitly passed in an alternative tenant_id.
1a) The user could then look up any additional tenant_id from the
/users/{userid}/tenants resource path.
1b) a variation of this could be to include a list of all tenants the
user is associated with in the token resource when it's returned, with the
token scoped by default to whatever is set in the user's default tenant
attribute.
2) when any authentication that is just handed in a username+password and no
tenent_id, hand back a list of tokens, all authenticated for the user.
Fourth - there's an outstanding suggestion that the token resource, in
particular, may be much better suited to including whole resources back,
instead of resource IDs or atom link references to those resources. That's
generally how /token is behaving in the v2 API, and I'm leaning towards making
that explicit in the V3 API as well. Right now the APi defines only that the
ID's will be returned, not representations of the whole resource.
Thoughts? Feedback?
-joe
___
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] Identity API v3 - Why allow multi-tenant users?
Hi Caitlin, A user is able to be associated with multiple tenants in the current API as well - this API just attempt to make is significantly more clear what you're asking for and what you're getting back. It was one of the earliest requests and requirements of the auth system. For the back-ends of Keystone that allow resetting of passwords, it would generally be an administrator of Keystone (as it is today) that would be required to reset a user's password, but with the additional domain model, it's possible to expand that a bit if a local implementation wanted to allow a domain admin to reset a user's password as well. -joe On May 29, 2012, at 10:18 AM, Caitlin Bestler wrote: One of the major complication I see in the API is that users can be associated with multiple tenants. What is the benefit of this? What functionality would be lost if a human user merely had to use a different account with each tenant? There are numerous issues with multi-tenant users. For example, if a user is associated with multiple tenants, who resets the user’s password? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [openstack][keystone] V3 API draft
Good morning, I wanted to announce that we have the first strawman/draft of a V3 API for Keystone available for comment and feedback. This is an early draft, and I expect there to be more than one. https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit The general theme of this proposal is a broad CRUD based API supporting authentication and authorization needs in OpenStack. Back-end implementations of Keystone may not support all components of the API, hence an API return may be NotImplemented. This is to support Keystone as a programmatic facade to an deployment’s existing authentication and authorization system(s). Themes for changes: • different style of pagination that I hope will be more effective for UI work • consolidate CRUD operations currently in contrib into CORE • adding a url resource attribute that's the fully qualified resource location for the keystone service • flatten the service catalog structure • added in a domains (collection of tenants) • restructure role API calls to be specific to user-tenant or user-domain • tokens are now very explicit to user+tenant combinations • new API mechanisms to get tenants associated with a user • generalized credentials associated with a user/tenant combo (ec2, pki, ssh keys, etc) • propose an extended policy-implementation-specific API If you're interested, please review and provide feedback through the above Google Doc, or feel free to open broader discussion questions here on the list. -joe ___ 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] Any seattle area openstackers on the list? ...
Next OpenStack Seattle meetup is Thursday evening, BTW - at HP's offices: http://www.meetup.com/OpenStack-Seattle/events/58239262/ On May 21, 2012, at 12:23 PM, Sriram Subramanian wrote: There is a lot of openstackers around including me. What are you upto with openstack? Some of the local groups around openstack are: http://www.meetup.com/OpenStack-Seattle/ http://www.meetup.com/OpenStack-Seattle/ http://www.meetup.com/Seattle-Opscode-Chef-Meetup-Group/ (not openstack per se) Please let me know if you need more details. Thanks, -Sriram From: openstack-bounces+sriram=computenext@lists.launchpad.net [mailto:openstack-bounces+sriram=computenext@lists.launchpad.net] On Behalf Of Arvind Srinivasan Sent: Monday, May 21, 2012 11:26 AM To: openstack@lists.launchpad.net Subject: [Openstack] Any seattle area openstackers on the list? ... Would be nice to meet up and hack away. --- Arvind Srinivasan - IBM Cloud Strategy Technology Standards Email: arvin...@us.ibm.com Phone: +1 919 673 1082 - ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Keystone] PKI
Coming out of the Keystone meeting from today (http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-18.02.html), I thought it worth mentioning that adam young has been doing some tremendous lifting in terms of looking at adding in PKI support to Keystone. The writeup and details are on the OpenStack wiki at http://wiki.openstack.org/PKI I rather suspect there's a lot of interest in this topic, so I wanted to make sure the broader community knew about the effort, what we were thinking, and were we are. If you're interested in discussing, the keystone meeting is on Tuesday mornings at 18:00 UTC -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone client, user belongs to many tenants?
Guang, I think you need to re-read the code. The association between a user and tenant is what the role represents, and its inaccurate to assert that a user is aligned only with a single tenant ever, that is not the case. A role is no longer global, specifically to avoid the tremendous confusion and inaccuracy of implementation about how to apply a role that relates a tenant and user along with a potential global role concept that was in the earliest implementations of Keystone. The current implementation is simpler and far more specific and clear in it's implementation. -joe On May 9, 2012, at 10:22 PM, Yee, Guang wrote: I think this use case underscores one of the key differences between the fat Keystone (Diablo - E3) and KSL (Essex final). In fat Keystone, users and tenants are loosely coupled. They are bind together by role assignments. In KSL, users and tenants are tightly coupled, and IMHO very inflexible. Maybe the following example would further clarify this … Suppose you have tenants Dodgers, Giants, and Brewers, user Bud Selid, roles Commissioner and Minority Owner, and service MLB. And you want Bud Selid to have the Commissioner role for Dodgers, Giants, and Brewers, but Minority Owner role for Brewers only. In fat Keystone, there a couple of ways you can accomplish this. 1) Make Commissioner a “global role” (unscoped) and assign it to user Bud Selid. Assign the Minority Owner role to Bud Selid for tenant Brewers by creating a role reference. When Bud Selid tries to access MLB with his unscoped token, MLB will get his Commissioner role back from Keystone. When Bud Selid tries to access MLB with his token scoped to Brewers, MLB will get both his Commissioner and Minority Owner roles back from Keystone. When Bud Selid tries to acess MLB with his token scoped to Giants or Dodgers, MLB will only get his Commissioner role back from Keystone. 2) Assign the Commissioner role to Bud Selid to tenants Giants, Dodgers, and Brewers individually by creating the respective role references. Assign the Minority Owner role to Bud Selid for tenant Brewers by creating another role reference. In this scenario, Bud Selid will always need a scoped token to access MLB. In KSL, there really aren’t any effective ways to accomplish the same thing. Global roles are no longer supported. A given user must assign to exactly one tenant. I suppose you can have Bud Selid under the “Default Tenant”, and assign both Commissioner and Minority Owner roles to him. But there are two major side effects. 1) Bud Selid must access MLB with the token scoped to the “Default Tenant” in order for MLB to recognize him as Commissioner. Which means he IS ALSO the Minority Owner for Dodgers, Giants, and Brewers. J 2) If Bud Selid tries to access MLB with the token scoped to either Giants, Dodgers, or Brewers, his a NOBODY. J The upcoming Domains blueprint (to be implemented for Folsom), which offers true multitenancy, should support these types of use cases. https://blueprints.launchpad.net/keystone/+spec/keystone-domains With Domains, you can create a MLB domain with tenants Dodgers, Giants, and Brewers. And have Bud Selid under the MLB domain. Notice that users will no longer be assigned to tenants. They will be under a domain. Create roles Commissioner and Minority Owner in the MLB domain. Assign the Commissioner role to Bud Selid, and the Minority Owner role scoped to Brewers. Suppose you have another domain NFL, Bud Selid will not be able to access any tenants in the NFL domain, unless the NFL domain administrator explicitly assign NFL roles to Bud Selid. Guang From: openstack-bounces+guang.yee=hp@lists.launchpad.net [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of Dolph Mathews Sent: Wednesday, May 09, 2012 4:34 PM To: Joshua Harlow Cc: openstack Subject: Re: [Openstack] Keystone client, user belongs to many tenants? The user create command is actually creating discrete users, each with a default tenant reference. While that's fine for a lot of simple use cases, it doesn't directly support a user accessing multiple tenants at all. Instead, create a role, and grant that role to a user-tenant pair, creating an explicit relationship between the two. Using default tenants is optional with this method, but will affect how users must auth. -Dolph Mathews On May 9, 2012, at 3:46 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: A question, I am using anvil to setup the keystone roles/users/tenants. It seems like the python keystone client has the following command: client.users.create Which seems to take in the following: create(self, name, password, email, tenant_id=None, enabled=True): I would assume a user name can be used in multiple tenants but when I am trying to create a user that spans tenants and it
Re: [Openstack] Keystone client, user belongs to many tenants?
users are defined as globally unique in keystone
what's anvil?
-joe
On May 9, 2012, at 1:46 PM, Joshua Harlow wrote:
A question,
I am using anvil to setup the keystone roles/users/tenants.
It seems like the python keystone client has the following command:
client.users.create
Which seems to take in the following:
create(self, name, password, email, tenant_id=None, enabled=True):
I would assume a user name can be used in multiple tenants but when I am
trying to create a user that spans tenants and it seems like it borks.
ClientException: Conflict occurred attempting to store user. (IntegrityError)
(1062, Duplicate entry 'admin' for key 'name') 'INSERT INTO user (id, name,
extra) VALUES (%s, %s, %s)' ('3e14a9c1fd404c7e81c0dba8bd640575', 'admin',
'{password:
$6$rounds=4$yX5fL51OyGKjuPjr$8yv.S3GpqsKeaHv4GjNY4YW2vvykWzrEV7RX.qJpyy3CjmyXrZMRRJifEzfa7xv1l.NzoggQBXUAESn3Oqm0x/,
enabled: true, email: ad...@example.com, tenantId:
d1506184877a449a91fc6adcb553ad97}') (HTTP 409)
Is this supposed to happen? Is the client supposed to send back this much
info also (hashed password??) :-P
Any ideas?
___
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] Missing(?) keystone service catalog
The service-list should give you a list of the services in the catalog, driven
by the template. What's in your catalog file at
/etc/keystone/default_catalog.templates? It sounds like it's empty - that's
what it's reading to report on services. You won't be able to use any of the
add/remove CRUD operations unless you switch to the SQL based back-end, but
service-list should do what you want.
When you did the curl, I assume you used the token retrieved from the admin
user with the /tokens/{token_id}/endpoints call?
-joe
On May 3, 2012, at 2:54 AM, Nick Lothian wrote:
My /etc/keystone/keystone.conf says:
[catalog]
template_file = /etc/keystone/default_catalog.templates
# dynamic, sql-based backend (supports API/CLI-based management commands)
driver = keystone.catalog.backends.templated.TemplatedCatalog
(This is the default from devstack).
I did look at that, but made the mistake of assuming the comment was correct
and referred to the next line, especially since the next, commented out entry
said it was the file-based one. My mistake I guess - I'll try the SQL one.
Shouldn't the API give a read-only view of the service catalog if CRUD
operations are unavailable?
On Thu, May 3, 2012 at 4:32 PM, Rafael Durán Castañeda
rafadurancastan...@gmail.com wrote:
On 05/03/2012 06:38 AM, Nick Lothian wrote:
I'm having some trouble using the Keystone API.
When I run
keystone --os_username=admin --os_password=password
--os_auth_url=http://192.168.1.50:5000/v2.0/ service-list
I get the following:
No handlers could be found for logger keystoneclient.v2_0.client
Unable to communicate with identity service: 404 Not Found
The resource could not be found.
. (HTTP 404)
The keystone log shows the following:
(eventlet.wsgi.server): 2012-05-03 14:03:12,840 DEBUG wsgi write
192.168.1.50 - - [03/May/2012 14:03:12] GET /v2.0/OS-KSADM/services
HTTP/1.1 404 176 0.008028
Additionally, if I use curl to call the keystone API directly (as documented
at http://keystone.openstack.org/api_curl_examples.html#id4) my whole
serviceCatalog section is empty (serviceCatalog: {})
I am using a default devstack installation.
What am I missing?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
I think DevStack is using TemplatedCatalog as catalog backend and it doesn't
support CRUD. If you need CRUD operations you can use SQL backend.
___
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] [nova-api] No module named nova_keystone_context
Morning Leander, The key file is what's in your nova api-paste.ini file - it's what is defining the WSGI pipeline that loads up the various bits that set context. What version of Nova and Keystone are you running? I rather suspect you might have updated your code without also getting the updates into your api-paste.ini file. -joe On May 3, 2012, at 3:28 AM, Leander Bessa wrote: Hello, Every time i start nova-api i get the following output: nova-api --config-file=/etc/nova/nova.conf 2012-04-30 15:23:51 CRITICAL nova [-] No module named nova_keystone_context 2012-04-30 15:23:51 TRACE nova Traceback (most recent call last): 2012-04-30 15:23:51 TRACE nova File /usr/bin/nova-api, line 51, in module 2012-04-30 15:23:51 TRACE nova servers.append(service.WSGIService(api)) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/nova/service.py, line 326, in __init__ 2012-04-30 15:23:51 TRACE nova self.app = self.loader.load_app(name) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/nova/wsgi.py, line 388, in load_app 2012-04-30 15:23:51 TRACE nova return deploy.loadapp(config:%s % self.config_path, name=name) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in loadapp 2012-04-30 15:23:51 TRACE nova return loadobj(APP, uri, name=name, **kw) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in loadobj 2012-04-30 15:23:51 TRACE nova return context.create() 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2012-04-30 15:23:51 TRACE nova return self.object_type.invoke(self) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2012-04-30 15:23:51 TRACE nova **context.local_conf) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2012-04-30 15:23:51 TRACE nova val = callable(*args, **kw) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/nova/api/openstack/urlmap.py, line 163, in urlmap_factory 2012-04-30 15:23:51 TRACE nova app = loader.get_app(app_name, global_conf=global_conf) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2012-04-30 15:23:51 TRACE nova name=name, global_conf=global_conf).create() 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2012-04-30 15:23:51 TRACE nova return self.object_type.invoke(self) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2012-04-30 15:23:51 TRACE nova **context.local_conf) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2012-04-30 15:23:51 TRACE nova val = callable(*args, **kw) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/nova/api/auth.py, line 48, in pipeline_factory 2012-04-30 15:23:51 TRACE nova filters = [loader.get_filter(n) for n in pipeline[:-1]] 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 354, in get_filter 2012-04-30 15:23:51 TRACE nova name=name, global_conf=global_conf).create() 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 366, in filter_context 2012-04-30 15:23:51 TRACE nova FILTER, name=name, global_conf=global_conf) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 458, in get_context 2012-04-30 15:23:51 TRACE nova section) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 517, in _context_from_explicit 2012-04-30 15:23:51 TRACE nova value = import_string(found_expr) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 22, in import_string 2012-04-30 15:23:51 TRACE nova return pkg_resources.EntryPoint.parse(x= + s).load(False) 2012-04-30 15:23:51 TRACE nova File /usr/lib/python2.7/dist-packages/pkg_resources.py, line 1989, in load 2012-04-30 15:23:51 TRACE nova entry = __import__(self.module_name, globals(),globals(), ['__name__']) 2012-04-30 15:23:51 TRACE nova ImportError: No module named nova_keystone_context 2012-04-30 15:23:51 TRACE nova Exception KeyError: KeyError(140300442122736,) in module 'threading' from '/usr/lib/python2.7/threading.pyc' ignored Am i missing something from my config file, or is it something else? Here's my nova.conf file: [DEFAULT] # LOG/State verbose=True # Authentication
Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?
This isn't about parsing the data structure - it's about what a service represents so that we can model it appropriately. So what does the service here represent? the collection of all possible services of that type? That's what your example would seem to indicate. In your example, the service is a pretty simple structure - just having a type (driven by convention and API spec) and human readable name, and each service is expected to have 1 to N endpoints. Is it reasonable to have a service without any endpoints? Regardless of reasonable, is it allowable? What does an endpoint represent? The API's URI point, clearly. Is there a uniqueness constraint of any kind on endpoints? Is it allowable (if strange) to list 3 duplicate endpoints with exactly the same metadata on it? -joe On Apr 25, 2012, at 9:37 AM, Nguyen, Liem Manh wrote: I would like to keep the service type and name under the service and not the endpoint, too. Make it easier to parse for a given service. One thing is that I am not sure if we need the metadata tag… In the Keystone XSD, we have the construct anyAttribute namespace=##other processContents=lax/, which allows any additional, implementation-specific attribute to be added. Those that do not support the specific attribute can simply ignore it. A couple of benefits I can see with not using the metadata tag, and just use the custom element directly like this: http://paste.openstack.org/show/13832/, which the anyAttribute supports, are: · Simplier parsing, one level less. · If that attribute becomes a core attribute later, no need to change the parser. Liem From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf Of Joe Savak Sent: Tuesday, April 24, 2012 1:04 PM To: Joseph Heck; openstack@lists.launchpad.net (openstack@lists.launchpad.net) Cc: Adam Gandelman Subject: Re: [Openstack] [Keystone] What exactly are we modeling with endpoints? Having endpoints under the service construct is supposed to make it easier to programmatically find the endpoint(s) you are interested in. For example – as nova client I can parse the service catalog and identity nova by service-type “compute” in order to get the public, internal, and admin endpoints for nova. By having service type name as attributes under the endpoint, I’ll have a harder time doing that (having to dive into each endpoint construct to identify the ones with service-type “compute”). Maybe it would be better to have each endpoint have its own construct inside of a service. So instead of http://paste.openstack.org/show/13678/ Maybe http://paste.openstack.org/show/13682/ From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Friday, April 20, 2012 4:16 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Cc: Adam Gandelman Subject: [Openstack] [Keystone] What exactly are we modeling with endpoints? While I've been roaming about the summit and conference, I've been trying to figure out exactly what we're modeling with the current service and endpoints that are in the API today. After talking with a number of folks, it's getting clearer that how it's being used is very installation specific. I'd like to simplify this aspect of the API if at all possible, especially with a lot of the good ideas around describing the relationships between endpoints and and their installation. The use cases I'm hearing actively in use are: * (Horizon/UI/client) To indicate to a user where they can go to access their data * (Glance, Nova, Keystone client) to find the endpoint relevant to uploading images (current client implementations appear to assume there is only one image endpoint) The use case to indicate a geographic location for a datacenter or cloud is not consistent - some implementations I've learned of have that feature (and use Region for that sort of information), and others are load balancing a single endpoint to deploy to multiple datacenters and geographic regions from a single endpoint. At the summit and conference, I heard a desire to expose geographic information with the endpoints, but that is clearly an operator specific implementation/deployment detail. Likewise I heard a lot of We could really... if additional metadata was easily available on endpoints, again in fairly implementation/deployment specific detail. So looking forward towards a v.next API, what do you all think about having just endpoints, with everything else being attributes on those endpoints (including what service and type it is), with some expected conventions (that there are a few well defined types - such as PublicURL and InternalURL, and relevant names for the rest API
[Openstack] [Keystone] What exactly are we modeling with endpoints?
While I've been roaming about the summit and conference, I've been trying to figure out exactly what we're modeling with the current service and endpoints that are in the API today. After talking with a number of folks, it's getting clearer that how it's being used is very installation specific. I'd like to simplify this aspect of the API if at all possible, especially with a lot of the good ideas around describing the relationships between endpoints and and their installation. The use cases I'm hearing actively in use are: * (Horizon/UI/client) To indicate to a user where they can go to access their data * (Glance, Nova, Keystone client) to find the endpoint relevant to uploading images (current client implementations appear to assume there is only one image endpoint) The use case to indicate a geographic location for a datacenter or cloud is not consistent - some implementations I've learned of have that feature (and use Region for that sort of information), and others are load balancing a single endpoint to deploy to multiple datacenters and geographic regions from a single endpoint. At the summit and conference, I heard a desire to expose geographic information with the endpoints, but that is clearly an operator specific implementation/deployment detail. Likewise I heard a lot of We could really... if additional metadata was easily available on endpoints, again in fairly implementation/deployment specific detail. So looking forward towards a v.next API, what do you all think about having just endpoints, with everything else being attributes on those endpoints (including what service and type it is), with some expected conventions (that there are a few well defined types - such as PublicURL and InternalURL, and relevant names for the rest API endpoints (ec2, compute, volume, image, identity...) Additional metadata can then float on the endpoints in deployment/implementation specific ways that don't lock in other systems to be deployed and implemented in the same fashion. -joe On Apr 20, 2012, at 1:47 PM, Lorin Hochstein wrote: On Apr 13, 2012, at 12:34 PM, Adam Gandelman wrote: On 04/13/2012 10:50 AM, Dolph Mathews wrote: While $(tenant_id)s is certainly the documented syntax, it appears that the SQL catalog backend (and *only* the SQL catalog backend, as far as I can tell) explicitly supports both $(tenant_id)s and %(tenant_id)s: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/sql.py#L163 Perhaps Adam Gandelman has some insight? -Dolph Dolph- No, the same is supported in the case of templated catalog as well, which is what the SQL catalog was largely based off: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L115 Just tested that sed -i 's/\$/%/g' /etc/keystone/default_catalog.templates still produces a functional service catalog when configured to use the templated backend. Seeing as both are supported, perhaps it would be better for docs to be updated to refer to the use of % instead of $ to avoid people running into problems with the $() sub-shell? The OpenStack Install and Deploy manual has some language about this (see last paragraph): http://docs.openstack.org/trunk/openstack-compute/install/content/elements-of-keystone-service-catalog-entry.html This hasn't made its way into the admin docs yet, though. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.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
[Openstack] mock, mox, stubs, fakes, etc
Poking around through all various mechanisms we have to test and verify OpenStack - does anyone have a concise writeup on the various tools and techniques that we're using? I'm not familiar with the stubs or mock libraries, and a little familiar with mox. Is anyone who is familiar with them all willing to take a stab at outlining where they're individually most effective and useful? -joe ___ 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] mock, mox, stubs, fakes, etc
Thanks Lorin! That helps me quite a bit. -joe On Apr 8, 2012, at 3:20 PM, Lorin Hochstein wrote: mox and mock are two competing Python libraries for defining mock objects for unit tests. I think they're basically equivalent in terms of what you can do with them, but they use different styles: In mox the assertions are written before the code under test, and in mock the assertions are written after the code under test. I personally think mock is more Pythonic, and it's what I use on other projects. Mox is a port of a Java library, and mock was (AFAIK) written specifically for Python. Also, Mock has been accepted into the Python 3.3(?) standard library as a submodule of unit tests. However, mox has been the main mocking library used in Nova unit test for as long as I have been familiar with the code. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com On Apr 8, 2012, at 4:06 PM, Joseph Heck wrote: Poking around through all various mechanisms we have to test and verify OpenStack - does anyone have a concise writeup on the various tools and techniques that we're using? I'm not familiar with the stubs or mock libraries, and a little familiar with mox. Is anyone who is familiar with them all willing to take a stab at outlining where they're individually most effective and useful? -joe ___ 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] python-glanceclient
I think Dean Troyer was going to take an even farther stance at the Summit. A unified client for all the core projects (and OpenStack client) instead of the proliferation of separate clients that we have. As we got into really testing the Essex release these past weeks, it because pretty clear to me that the user experience of working with nova, glance, and keystone (sorry Dan, I wasn't trying to through Quantum in the mix too at the time) - was definitely working with totally separate projects. On top of which is required some pretty deep knowledge of how and where things tied in to use those clients effectively (i..e don't use nova project list, use keystone tenant-list. These all made sense while focused on the individual projects, but make for a confusing proliferation of tools needed to deploy, run and use OpenStack. OpenStack would be well served to consolidate the clients, or at the very least drive further against the ideas started in http://wiki.openstack.org/UnifiedCLI to make the command structure, responses, and options available in clients consistent. For horizon, just having python libraries that don't require the entire back-end of a system to be installed was necessary, so the proliferation didn't matter that much. We are evolving beyond that now. -joe On Apr 5, 2012, at 9:04 AM, Brian Waldon wrote: We should definitely push to consolidate common code for clients! We can use either glanceclient or quantumclient as a prototype. As for the auth code specifically, it can be replaced with something as simple as this: https://github.com/openstack/python-glanceclient/blob/master/glanceclient/shell.py#L119 On Apr 4, 2012, at 9:11 AM, Dan Wendlandt wrote: Very cool guys! We'll be reworking the Quantum client in a similar alignment effort during Folsom. One question to that end: is there any effort to get much of the code that will be common across all OpenStack python-*client projects into something like openstack-common (or an openstack-client-common)? It seems like much of what is in https://github.com/openstack/python-glanceclient/tree/master/glanceclient/common would be useful across all projects. The same could likely be said for the basic keystone code required by a client (e.g., https://github.com/openstack/python-novaclient/blob/master/novaclient/service_catalog.py). Thanks, Dan On Tue, Apr 3, 2012 at 8:39 PM, Brian Waldon brian.wal...@rackspace.com wrote: In an effort to further align OpenStack API clients, Jay Pipes, Monty Taylor and myself have set up the python-glanceclient project. It is not intended to be a drop-in replacement for the existing client that lives in Glance, but a complete rewrite with a shiny new interface that maintains feature-parity. As for integrating this new client with the necessary OpenStack projects, here's a little roadmap I came up with: X 1) Basic functionality X 2) Integrate with Gerrit 3) Verify feature parity 4) Integrate with DevStack 5) Integrate with Nova 6) Drop old client from Glance If anybody is interested in playing with the new client, here it is: https://github.com/openstack/python-glanceclient. You can either yell at me or use Gerrit to fix anything I may have overlooked. Thanks! Brian Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack 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 ___ 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] Dashboard VNC Console failed to connect to server
Hey Tony, Slightly related - I'm getting a valid link form the dashboard that gets to VNCProxy and such, but the page that comes active reports a Server timeout. Any idea how to diagnose this and what's happened/not responded? http://172.17.1.50:6080/vnc_auto.html?token=f96cf65b-1a2f-415c-97f7-90da7cdc102atitle=zerglet(b13812ac-8310-49ea-97e6-50ff062754af) In the javascript console, here's what I'm seeing: New state 'loaded', was 'disconnected'. Msg: noVNC ready: native WebSockets, createImageData rendering util.js:71New state 'connect', was 'loaded'. util.js:71New state 'ProtocolVersion', was 'connect'. Msg: Starting VNC handshake util.js:72New state 'failed', was 'ProtocolVersion'. Msg: Failed to connect to server util.js:71New state 'failed', was 'failed'. Any ideas? -joe On Mar 29, 2012, at 1:06 PM, Anthony Young wrote: How are you generating this link: http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None ? It looks like if horizon is behaving nicely the link would look like http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/vnc Also, could you pastie your nova-api.log somewhere? A On Thu, Mar 29, 2012 at 11:52 AM, Guilherme Birk guib...@hotmail.com wrote: I'm having problems with it too. I'm trying to connect on my instances in the VNC tab at the dashboard, but I'm getting a 404 not found in the URL http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None Here is my nova-api.log. Looks like nova is having problems with the POST at http://localhost:8774/v1.1/db742491018d467690ba7d3a7bb383a5/servers/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/action. Any suggestions ? From: luciantho...@hotmail.com To: openstack@lists.launchpad.net Date: Thu, 29 Mar 2012 18:07:59 + Subject: [Openstack] Dashboard VNC Console failed to connect to server Hey guys, I'm using Dashboard with a nova-compute installed in another machine, but when I try access VNC Console I get the error failed to connect to server. Here is the log - http://pastebin.com/5DZMfiNE Anyone already saw this trouble? Lucian Thomaz ___ 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 ___ 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] Dashboard VNC Console failed to connect to server
http://pastie.org/3694439 The compute host is 172.18.1.1 with my instance (TTY, named zerglet) The nova vncproxy code is running at 172.17.1.50 - both have direct access to each other - pingable, etc. 172.17.1.50 is the nova-api host for this setup as well -joe On Mar 29, 2012, at 2:35 PM, Anthony Young wrote: Joe - can you pastie your nova.conf from your compute host? The most relevant flags are vncserver_proxyclient_address and vncserver_listen On Thu, Mar 29, 2012 at 2:21 PM, Joseph Heck he...@me.com wrote: Hey Tony, Slightly related - I'm getting a valid link form the dashboard that gets to VNCProxy and such, but the page that comes active reports a Server timeout. Any idea how to diagnose this and what's happened/not responded? http://172.17.1.50:6080/vnc_auto.html?token=f96cf65b-1a2f-415c-97f7-90da7cdc102atitle=zerglet(b13812ac-8310-49ea-97e6-50ff062754af) In the javascript console, here's what I'm seeing: New state 'loaded', was 'disconnected'. Msg: noVNC ready: native WebSockets, createImageData rendering util.js:71New state 'connect', was 'loaded'. util.js:71New state 'ProtocolVersion', was 'connect'. Msg: Starting VNC handshake util.js:72New state 'failed', was 'ProtocolVersion'. Msg: Failed to connect to server util.js:71New state 'failed', was 'failed'. Any ideas? -joe On Mar 29, 2012, at 1:06 PM, Anthony Young wrote: How are you generating this link: http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None ? It looks like if horizon is behaving nicely the link would look like http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/vnc Also, could you pastie your nova-api.log somewhere? A On Thu, Mar 29, 2012 at 11:52 AM, Guilherme Birk guib...@hotmail.com wrote: I'm having problems with it too. I'm trying to connect on my instances in the VNC tab at the dashboard, but I'm getting a 404 not found in the URL http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None Here is my nova-api.log. Looks like nova is having problems with the POST at http://localhost:8774/v1.1/db742491018d467690ba7d3a7bb383a5/servers/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/action. Any suggestions ? From: luciantho...@hotmail.com To: openstack@lists.launchpad.net Date: Thu, 29 Mar 2012 18:07:59 + Subject: [Openstack] Dashboard VNC Console failed to connect to server Hey guys, I'm using Dashboard with a nova-compute installed in another machine, but when I try access VNC Console I get the error failed to connect to server. Here is the log - http://pastebin.com/5DZMfiNE Anyone already saw this trouble? Lucian Thomaz ___ 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 ___ 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] Dashboard VNC Console failed to connect to server
thank you - morons-r-us is trying that suggestion right now... -joe On Mar 29, 2012, at 3:01 PM, Anthony Young wrote: Joe - looks like it could just be a typo: 1 2 3 --vncserver_list=172.18.1.1 --vncserver_proxyclient_address=172.18.1.1 --novncproxy_base_url=http://172.17.1.50:6080/vnc_auto.html that should be vncserver_listen A On Thu, Mar 29, 2012 at 2:42 PM, Joseph Heck he...@me.com wrote: http://pastie.org/3694439 The compute host is 172.18.1.1 with my instance (TTY, named zerglet) The nova vncproxy code is running at 172.17.1.50 - both have direct access to each other - pingable, etc. 172.17.1.50 is the nova-api host for this setup as well -joe On Mar 29, 2012, at 2:35 PM, Anthony Young wrote: Joe - can you pastie your nova.conf from your compute host? The most relevant flags are vncserver_proxyclient_address and vncserver_listen On Thu, Mar 29, 2012 at 2:21 PM, Joseph Heck he...@me.com wrote: Hey Tony, Slightly related - I'm getting a valid link form the dashboard that gets to VNCProxy and such, but the page that comes active reports a Server timeout. Any idea how to diagnose this and what's happened/not responded? http://172.17.1.50:6080/vnc_auto.html?token=f96cf65b-1a2f-415c-97f7-90da7cdc102atitle=zerglet(b13812ac-8310-49ea-97e6-50ff062754af) In the javascript console, here's what I'm seeing: New state 'loaded', was 'disconnected'. Msg: noVNC ready: native WebSockets, createImageData rendering util.js:71New state 'connect', was 'loaded'. util.js:71New state 'ProtocolVersion', was 'connect'. Msg: Starting VNC handshake util.js:72New state 'failed', was 'ProtocolVersion'. Msg: Failed to connect to server util.js:71New state 'failed', was 'failed'. Any ideas? -joe On Mar 29, 2012, at 1:06 PM, Anthony Young wrote: How are you generating this link: http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None ? It looks like if horizon is behaving nicely the link would look like http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/vnc Also, could you pastie your nova-api.log somewhere? A On Thu, Mar 29, 2012 at 11:52 AM, Guilherme Birk guib...@hotmail.com wrote: I'm having problems with it too. I'm trying to connect on my instances in the VNC tab at the dashboard, but I'm getting a 404 not found in the URL http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None Here is my nova-api.log. Looks like nova is having problems with the POST at http://localhost:8774/v1.1/db742491018d467690ba7d3a7bb383a5/servers/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/action. Any suggestions ? From: luciantho...@hotmail.com To: openstack@lists.launchpad.net Date: Thu, 29 Mar 2012 18:07:59 + Subject: [Openstack] Dashboard VNC Console failed to connect to server Hey guys, I'm using Dashboard with a nova-compute installed in another machine, but when I try access VNC Console I get the error failed to connect to server. Here is the log - http://pastebin.com/5DZMfiNE Anyone already saw this trouble? Lucian Thomaz ___ 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 ___ 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] Dashboard VNC Console failed to connect to server
Well, even with the change, I'm not getting the live VNCconsole. Javascript all comes up happy, but fails to connect - same errors. Anything that I should query in the javascript console that will tell me what's happening? Or logs form the novnc process? -joe On Mar 29, 2012, at 3:02 PM, Joseph Heck wrote: thank you - morons-r-us is trying that suggestion right now... -joe On Mar 29, 2012, at 3:01 PM, Anthony Young wrote: Joe - looks like it could just be a typo: 1 2 3 --vncserver_list=172.18.1.1 --vncserver_proxyclient_address=172.18.1.1 --novncproxy_base_url=http://172.17.1.50:6080/vnc_auto.html that should be vncserver_listen A On Thu, Mar 29, 2012 at 2:42 PM, Joseph Heck he...@me.com wrote: http://pastie.org/3694439 The compute host is 172.18.1.1 with my instance (TTY, named zerglet) The nova vncproxy code is running at 172.17.1.50 - both have direct access to each other - pingable, etc. 172.17.1.50 is the nova-api host for this setup as well -joe On Mar 29, 2012, at 2:35 PM, Anthony Young wrote: Joe - can you pastie your nova.conf from your compute host? The most relevant flags are vncserver_proxyclient_address and vncserver_listen On Thu, Mar 29, 2012 at 2:21 PM, Joseph Heck he...@me.com wrote: Hey Tony, Slightly related - I'm getting a valid link form the dashboard that gets to VNCProxy and such, but the page that comes active reports a Server timeout. Any idea how to diagnose this and what's happened/not responded? http://172.17.1.50:6080/vnc_auto.html?token=f96cf65b-1a2f-415c-97f7-90da7cdc102atitle=zerglet(b13812ac-8310-49ea-97e6-50ff062754af) In the javascript console, here's what I'm seeing: New state 'loaded', was 'disconnected'. Msg: noVNC ready: native WebSockets, createImageData rendering util.js:71New state 'connect', was 'loaded'. util.js:71New state 'ProtocolVersion', was 'connect'. Msg: Starting VNC handshake util.js:72New state 'failed', was 'ProtocolVersion'. Msg: Failed to connect to server util.js:71New state 'failed', was 'failed'. Any ideas? -joe On Mar 29, 2012, at 1:06 PM, Anthony Young wrote: How are you generating this link: http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None ? It looks like if horizon is behaving nicely the link would look like http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/vnc Also, could you pastie your nova-api.log somewhere? A On Thu, Mar 29, 2012 at 11:52 AM, Guilherme Birk guib...@hotmail.com wrote: I'm having problems with it too. I'm trying to connect on my instances in the VNC tab at the dashboard, but I'm getting a 404 not found in the URL http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None Here is my nova-api.log. Looks like nova is having problems with the POST at http://localhost:8774/v1.1/db742491018d467690ba7d3a7bb383a5/servers/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/action. Any suggestions ? From: luciantho...@hotmail.com To: openstack@lists.launchpad.net Date: Thu, 29 Mar 2012 18:07:59 + Subject: [Openstack] Dashboard VNC Console failed to connect to server Hey guys, I'm using Dashboard with a nova-compute installed in another machine, but when I try access VNC Console I get the error failed to connect to server. Here is the log - http://pastebin.com/5DZMfiNE Anyone already saw this trouble? Lucian Thomaz ___ 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone auth_token confusion in Swift vs Glance; Persistent tokens or not ?
Florian -
Would love to have some docs patches!
-joe
On Mar 23, 2012, at 6:04 AM, Florian Daniel Otel wrote:
Thanks Jay for the in-depth explanation, it actually does make sense :)
Sorry for the late reply -- I had to to change my Keystone, Swift and Glance
setup and digest the changes. Still not completely out of the woods yet
Thanks Chmouel for the the patch [1] for the Glance and Swift config files.
It's pretty much what I had in mind as well. However, shouldn't
keystone.conf itself be changed accordingly ? I can take a stab at it and
submit a proposal if it helps...
Also, wrt to the docs [2]. AFAICT the patch covers only
doc/sources/configuringservices.rst , but it needs fixing in other places
too (e.g. doc/sources/middleware_architecture.rst). Same thing there -- I
can try to make a patch and submit it (I need to get the hang of it first...)
Regards,
Florian
[1]
https://github.com/openstack-dev/devstack/commit/bd07d61c4545c52d39b9c957ff9e4423525ca452
[2] https://review.openstack.org/#change,5190
On Tue, Mar 20, 2012 at 10:09 PM, Jay Pipes jaypi...@gmail.com wrote:
Hi Florian, I appreciate your post and sympathize with your
frustration/confusion. I'll do my best below to help un-confuse :)
On 03/20/2012 12:15 PM, Florian Daniel Otel wrote:
Hello all,
I need some help with inconsistencies and -- in my mind -- confusing
instructions wrt auth_token Keytone middleware.
So far I have Keystone and Swift w/ Keystone auth working well together
(ussing Essex-4 milestone release of Keystone resp v1.4.6 of Swift).
What I am now trying is to get Glance on Swift with Keystone Auth but
I'm faced with conflicting info that I cannot make sense of
1) Naming inconsistencies -- token_auth , tokenauth (Keystone resp
Swift) vs authtoken (Glance)
The existing Keystone and Swift docs (e.g. this one:
http://keystone.openstack.org/configuringservices.html#configuring-swift-to-use-keystone*)
*use as names token_auth (Keystone) resp tokenauth (Swift) wheareas
in Glance docs the same midldleware (i.e.
keystone/middleware/auh_token.py) is referred to as authtoken (see
e.g. here http://glance.openstack.org/authentication.html )
While this may be only pedantic IMHO it would help if things would be
called the same way in different places. Or, if I'm confusing things,
someone point me out the differences to which is what and why.
Completely agreed, and Chmouel has submitted two patches to address these
inconsistencies.
2) auth_token: Persistent tokens or user/pass ?
As per Jay Pipes comment here:
https://bugs.launchpad.net/glance/+bug/953989/comments/2 (from
2012-03-13) the concept of long-lived (i.e. persistent) tokens are no
longer supported by the Keystone auth_token middleware -- and that is
listed as why that bug was invalid.
Actually, no not quite. The bug was marked Invalid because the source of the
issue was three things that Kevin (the bug reporter) had failed to do in his
setup -- two of which had to do with the authentication and one having to do
with an incorrect endpoint template placeholder.
Anyway, let me try and explain what the deal is with the long-lived token
deprecation that is mentioned in the bug report.
Previously in Keystone there was the concept of a service token --
otherwise known as a long-lived token. These special tokens would be read
from a configuration file or paste-ini file by the auth_token middleware that
sat, for instance, in the Glance API server pipeline. Importantly, these
special tokens were **not required to be attached to any user or tenant**.
The auth_token middleware is responsible for authenticating -- via Keystone
-- incoming regular user requests on an API endpoint. For example, if I call
GET http://example.com:9292/v1/images to get a list of images from a Glance
API server, and that server was configured with the auth_token middleware,
then the middleware looks for certain HTTP headers in the incoming request.
If the HTTP_X_AUTH_TOKEN header is present in the incoming request,
then the middleware would need to *validate* this authentication token with
Keystone. This validation call (POST /v2.0/tokens/{$token_id} [1]) is a
*privileged* call in the Keystone Service Admin API, and as such, in order to
make the validation request, the HTTP request to Keystone itself needs,
itself, to supply an HTTP_X_AUTH_TOKEN that is scoped to some entity that
can make this privileged validation call. However, as mentioned before, the
long-lived service token was not scoped to any user/tenant, and these
unscoped tokens were accepted by the validate token API call as privileged
tokens...
OK, so recent changes removed this inconsistency in the scoping of tokens.
There are no longer any tokens that are unscoped, and because of this, it was
found to be more logical to have a user and password combination in
middleware
Re: [Openstack] OpenStack Installation Woes - Need re-assurance and help.
Those were great bugs too - sorry you hit them, but thanks to you and Jay for reporting them in! We're working on them now! -joe On Mar 14, 2012, at 1:45 AM, Kevin Jackson wrote: Shep, Those steps are great. I'll be running through them, the devstack and any other info I've collated and update the bug I originally raised that caused me the pain that tipped me over the edge (https://bugs.launchpad.net/glance/+bug/953989) Adam, the other bugs raised in the last day regarding my issues where raised by jaypipes when helping me troubleshoot my install : https://bugs.launchpad.net/keystone/+bug/954089 and https://bugs.launchpad.net/keystone/+bug/954087 Regards, Kev On 14 March 2012 01:59, Justin Shepherd jshep...@rackspace.com wrote: Sent this to kevin earlier, thought i would throw it out to the list.. here are the steps i take to get a working keystone and glance on Ubuntu-12.04 using the ubuntu packages. http://paste.openstack.org/show/9101/ These steps produce a working keystone and glance.. not 100% sure they are the most efficient steps, would be curious to hear from others if there is a better way. --shep On Mar 13, 2012, at 5:41 PM, Adam Gandelman wrote: On 03/13/2012 01:53 PM, Kevin Jackson wrote: Whilst OpenStack is being developed, a lot of people's entry into OpenStack is through deb packages (or insert your fave package management in here) - therefore Ubuntu becomes unofficial (but vocal) PR to OpenStack. If the Ubuntu debs don't install, it becomes Plan B to install from somewhere else - even if that somewhere else is openstack.org. When we view the pages of http://www.ubuntu.com/cloud there is little doubt that OpenStack is a 1st class citizen (Best-of-breed cloud infrastructure is built into every copy of Ubuntu). Kevin- As someone who helps maintain the Ubuntu packages, I'm curious to know when/what/where the problems you've hit installing packages. Do/did bug #s exist? Can you please file bugs when you hit them? We've been making an extra effort to ensure that the Openstack packages on archive.ubuntu.com are *at least* installable without error at any given time. Packaging bugs have slipped through into our weekly uploads, but we've been either catching them early or responding to any new relevant bug reports, and doing point uploads with fixes ASAP so things are installable until the next weekly upload. I ask anyone that is running into packaging problems: Please file bugs against the Ubuntu packages if you find they are failing to install. They *will* get fixed! Adam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Kevin Jackson @itarchitectkev ___ 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] OpenStack Installation Woes - Need re-assurance and help.
Yeah, one service tenant, and then service accounts for each of nova, glance, quantum, swift. I've got a review that's updating this detail in the keystone docs right now (https://review.openstack.org/#change,5348) The catalog can be either the template (in which case, you don't use commands, you just edit the template) or the SQL based catalog (where you do use the commands) -joe On Mar 14, 2012, at 9:57 AM, Anne Gentle wrote: Hi Shep and others - A couple of questions to enhance my understanding while I walk through this for the install doc. Service Tenant - do you create just one service tenant to enclose all the service users? Glance Service User - do you create a Nova Service User and a Swift Service User also? files/default_catalog.templates - are your commands updating the template or a database? It this is a point of confusion. I guess I have to also add: [catalog] driver = keystone.catalog.backends.sql.Catalog to keystone.conf in order to use a database backend for my service catalog? Thanks for improving my mind map. Anne On Tue, Mar 13, 2012 at 8:59 PM, Justin Shepherd jshep...@rackspace.com wrote: Sent this to kevin earlier, thought i would throw it out to the list.. here are the steps i take to get a working keystone and glance on Ubuntu-12.04 using the ubuntu packages. http://paste.openstack.org/show/9101/ These steps produce a working keystone and glance.. not 100% sure they are the most efficient steps, would be curious to hear from others if there is a better way. --shep On Mar 13, 2012, at 5:41 PM, Adam Gandelman wrote: On 03/13/2012 01:53 PM, Kevin Jackson wrote: Whilst OpenStack is being developed, a lot of people's entry into OpenStack is through deb packages (or insert your fave package management in here) - therefore Ubuntu becomes unofficial (but vocal) PR to OpenStack. If the Ubuntu debs don't install, it becomes Plan B to install from somewhere else - even if that somewhere else is openstack.org. When we view the pages of http://www.ubuntu.com/cloud there is little doubt that OpenStack is a 1st class citizen (Best-of-breed cloud infrastructure is built into every copy of Ubuntu). Kevin- As someone who helps maintain the Ubuntu packages, I'm curious to know when/what/where the problems you've hit installing packages. Do/did bug #s exist? Can you please file bugs when you hit them? We've been making an extra effort to ensure that the Openstack packages on archive.ubuntu.com are *at least* installable without error at any given time. Packaging bugs have slipped through into our weekly uploads, but we've been either catching them early or responding to any new relevant bug reports, and doing point uploads with fixes ASAP so things are installable until the next weekly upload. I ask anyone that is running into packaging problems: Please file bugs against the Ubuntu packages if you find they are failing to install. They *will* get fixed! Adam ___ 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 ___ 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-4 milestone proposed candidates
For keystone, we are writing migration docs from Diablo - both with and without keystone configurations. We've implemented export and import mechanisms to bring in data to the new keystone instance, so it's mostly a matter of just explaining how to use it. -joe On Mar 1, 2012, at 7:34 AM, David Kranz wrote: This is a great milestone and I was wondering about upgrade. At the last design summit there was a discussion about how hard/easy it would be to upgrade to Essex. What is the final answer? Are their (going to be) instructions on how to upgrade an operating diablo cluster to essex? And is the answer different if the diablo cluster is not using keystone? -David On 2/29/2012 6:15 AM, Thierry Carrez wrote: Hi everyone, Milestone-proposed branches were just created for Keystone, Glance, Nova and Horizon in preparation for the essex-4 milestone delivery on Thursday. Please test proposed deliveries to ensure no critical regression found its way in. Milestone-critical fixes will be backported to the milestone-proposed branch until final delivery of the milestone, and will be tracked using the essex-4 milestone targeting. Links: for PROJ in ['keystone', 'nova', 'glance', 'horizon']: Milestone-critical bugs: https://launchpad.net/PROJ/+milestone/essex-4 Branch at: https://github.com/openstack/PROJ/tree/milestone-proposed Proposed tarballs at: http://PROJ.openstack.org/tarballs/ (Look for the most recent PROJ-2012.1~e4*.tar.gz build) You can also test the glance, nova and python-novaclient candidates on Ubuntu by enabling the new common ppa:~openstack-ppa/milestone-proposed The current plan is to deliver Essex-4 Thursday morning, US time. The development focus now switched completely from feature development to preparation of final release candidates. Release-blocking bugs will be listed on https://launchpad.net/PROJ/+milestone/essex-rc1. Once we get a valid release candidate, Folsom development will be open. Cheers, ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone update
Good morning! For those that don't know me, I'm Joe Heck - and I'm running (along with Andy (termie)) for Keystone PTL. Regardless of what you vote there, I want to get your attention for the state of Keystone today. In the keystone meeting today (http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-02-28-18.02.html), we agreed that Essex4 is locked down in terms of features, and we are now focusing on stabilization, bug fixing, and documentation for the full-on Essex release. There are still fairly large code elements outstanding, but the API should be considered locked down at this point and we're are focusing hard on consistent integration and beefing up the backends to the existing services. Going Forward... We are also starting to get set up for discussions about what to do in Folsom - to that end, we're going to reset all the blueprints here pretty shortly. Since the baseline of keystone, we've entered everything as bugs (it was easier to tag and discuss in bugs) - but many of those items really need to be blueprints. I'm sure there's a lot of good ideas out there related to what we should be doing with keystone, so here's the plan to sort it out: As of today, I erased assigned from all of the blueprints in keystone. If you want to advocate for one of the blueprints that is listed in the current set, assign the blueprint to yourself. Or, register a new blueprint and assign it to yourself. Guang Yee and Jesse Andrews have a couple blueprints assigned to them right now, since I did the clearing work. READ THIS IF NOTHING ELSE: At the end of the day (in US/Pacific) wednesday (Feb 29th), I'm going delete/negate/remove/flamethrower any blueprints that don't have a person assigned to it. https://blueprints.launchpad.net/keystone By assigning a blueprint to yourself, you are asserting that you will advocate for, defend, and explain the use cases behind the blueprint as well as help talk through potential technical solutions. you *do not* need to know how to solve the issues to suggest a blueprint. If you are unable to work the launchpad interface and want to keep a blueprint around, contact me directly and I can assign the blueprint to you. Along with the blueprints, we are also tacking in use cases for Keystone that we're aware of at http://wiki.openstack.org/KeystoneUseCases. Anyone can edit this page when you log in with Launchpad credentials. We're looking for the real-world issues and problems that folks are seeing or want to address with Keystone. Please edit and add to this page. We will start discussing blueprints in upcoming keystone meetings - schedule for which will be updated at http://wiki.openstack.org/Meetings/KeystoneMeeting. If you have any questions, send me a note or ping me on IRC, and I'll do my best to answer it or get you to where we can answer it. -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone Use Cases and User Stores
Happy Friday (hopefully it's friday when you get this...) As keystone is getting into a new baseline, we're actively going through the bug list and blueprints and re-assessing based on the updated codebase. As we're getting into the details, we want to try and stay as close to the road as possible with implementing features and making sure the features we implement are rock solid going forward. To support that, we are starting to gather use cases of the folks actively deploying and trying to use Keystone. If you're using Keystone, I'd like to encourage you to take a look at the wiki page: http://wiki.openstack.org/KeystoneUseCases and see if there are other use cases that you require for your deployment. With these use cases, and the topics that we are collecting for broader discussion at the Folsom summit (http://wiki.openstack.org/KeystoneFolsomSummitTopics), we are looking to build out blueprints and prioritize work for the upcoming Folsom release. Thanks! -joe (heckj) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone Use Cases and User Stores
Thanks Jason - Thats already on our list of topics to discuss more broadly at the Folsom design summit (http://wiki.openstack.org/KeystoneFolsomSummitTopics). The etherpad has a great deal of detail, but I think it needs some conversation needs happen as to how it related to the RBAC discussions that we had the Essex design summit (etherpad at http://etherpad.openstack.org/canhaz). From your user stories, it's not entirely clear what a group concept is getting us that isn't already in tenant when you apply RBAC. I'd like to understand that better. Are you available on IRC to chat sometime? If it would be easier, I'd be happy to schedule it up as a topic of conversation in a future keystone IRC meeting. The next meeting (the 21st - http://wiki.openstack.org/Meetings/KeystoneMeeting), but I've added it to a talk list. Would you be available to chat on IRC on the 28th? -joe On Feb 17, 2012, at 12:28 PM, Rouault, Jason (Cloud Services) wrote: http://etherpad.openstack.org/keystone-domains -Original Message- From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Friday, February 17, 2012 12:59 PM To: OpenStack Mailing List Subject: [Openstack] Keystone Use Cases and User Stores Happy Friday (hopefully it's friday when you get this...) As keystone is getting into a new baseline, we're actively going through the bug list and blueprints and re-assessing based on the updated codebase. As we're getting into the details, we want to try and stay as close to the road as possible with implementing features and making sure the features we implement are rock solid going forward. To support that, we are starting to gather use cases of the folks actively deploying and trying to use Keystone. If you're using Keystone, I'd like to encourage you to take a look at the wiki page: http://wiki.openstack.org/KeystoneUseCases and see if there are other use cases that you require for your deployment. With these use cases, and the topics that we are collecting for broader discussion at the Folsom summit (http://wiki.openstack.org/KeystoneFolsomSummitTopics), we are looking to build out blueprints and prioritize work for the upcoming Folsom release. Thanks! -joe (heckj) ___ 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] Integration test gating on trunk
+100 - I know there was a huge amount of effort that went into making this happen from a lot of people. I'm Looking forward to seeing it come live! -joe On Dec 29, 2011, at 2:51 PM, James E. Blair wrote: Having said that, the Jenkins job has been running in silent mode on master for several days with few false errors. My feeling from the design summit was that it was generally understood there would be a shakedown period, and people are willing to accept some risk and some extra work for the benefits an integration test gating job will brink. I think we're at that point, so I'd like to turn this job on Tuesday, January 3rd. -Jim ___ 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] Extension Documentation
I totally agree with Anne that the documentation in this split up format is very hard to both find and parse. It's not inaccurate, so much as it leaves a gaping hole in understanding what is and isn't available when you have 9+ documents to read and they're not really interlinked. The effort I kicked off, but haven't had a lot of time to put into lately, to create a single unified portal/page for the API was an idea to address this weakness with the current structure. I've created a github pages site to stub out how this might work - https://github.com/heckj/api-site-mock, with the generated site at http://heckj.github.com/api-site-mock/. It's very much a work in progress, which I hope to resume work on in a few weeks when I should be able to free up some additional time. I have documented my intention for the site's goals (https://github.com/heckj/api-site-mock/blob/master/GOALS.md) and design (https://github.com/heckj/api-site-mock/blob/master/DESIGN.md) - tl;dr, making a unified API directory for immediate web-based consumption (i.e. browser) along the lines of: * https://www.parse.com/docs/rest * https://dev.twitter.com/docs/api If anyone else would be interested in collaborating on this site live to move it forward, I would be happy to add your accounts to directly push into the repository. And of course I'm happy to take pull requests. -joe On Dec 9, 2011, at 6:29 AM, Brian Waldon wrote: Hey Anne, Great feedback! As for number 8, I think the nova-api team might be the best group to be tasked with reviewing code and documentation for any extensions proposed to Nova's codebase. And we can absolutely discuss this at the meeting today! Brian On Dec 9, 2011, at 9:17 AM, Anne Gentle wrote: Hi everyone - Overall I support this effort and have discussed it at length with the Rackers working on it. I'd really like to get feedback from everyone who thinks they'll consume this type of information. I don't find it easy to use from an API consumer's perspective, but it is an absolute must for the projects to have a way to describe what parts of their API is an extension. Here are my suggestions on this first iteration, which I've talked to Jorge about but also want to share with the list to get input. 1. The header - at first it may confuse people since it's an OpenStack header on a Rackspace domain name. I understand this convention was chosen since you intend to give it over to OpenStack. 2. In the header, I don't believe Extensions Documentation is the correct label, probably just highlight Documentation. 3. I don't have a good sense of how readers will get to API documentation from this page. With the API site also being worked on, we'll need to find a good secondary nav for these types of sites. 4. All of the links need to add an additional /content/ to the link to avoid redirects. 5. All of these mini-docs need to use a processing instruction or pom directive to avoid the tiny chunking and only chunk at the chapter level. 6. I made some minor changes to the DocBook template so that people can find the WADL normalizer tool. 7. For the API site we're constructing, we're not yet sure how to handle extensions for the API reference. Right now we need to fill in a lot of reference information. Suggestions for integration are welcomed. 8. We need a discussion about who will review these extension submissions and ensure they get built. Based on the struggle to get these docs written, I also want to know if you all find the templates useful and think you'll author these. Any suggestions for the authoring side? Brian, can we discuss at the nova-api meeting tomorrow at 3:00 CST in #openstack-manuals as well? I'll also discuss at the Doc Team meeting Monday 12/12 at 2:00 CST (20:00 UTC). Thanks for all the work here. Let's iterate on this site. Thanks, Anne On Thu, Dec 8, 2011 at 10:58 AM, Jorge Williams jorge.willi...@rackspace.com wrote: Hi All, I've started putting together a site to hold extension documentation. You can see it here: http://docs.rackspace.com/openstack-extensions/ The idea is to have a repository for all extensions, whether the extension is an OpenStack extension or a vendor specific extension. It makes sense to me that users can go to a central place to get extension docs regardless of where the extension came from or who wrote it, etc. I'm putting this out as somewhat of a proposal with the hopes that we can roll this page into our own docs site. The site is *somewhat* automated. If you put the webhelp output that comes out of our docs tool chain, it will reach into the extension description sample for info about the extension and just roll it into the index page. The idea is that we can have something like Jenkins spit out some webhelp to a directory and things will just work. The script that does this is written in perl though If anyone wants to take a stab at
Re: [Openstack] dashboard running error since of NameError: name '_' is not defined in glance code
That's almost always a reference to gettext - the module used for internationalization. In this case, it's a bug where accessing that method isn't also getting a few lines that import gettext lined up into it. import gettext gettext.install(glance, unicode=1) I've filed it for you as bug 887672 (https://bugs.launchpad.net/glance/+bug/887672), but at a quick glance I'm not sure where the appropriate fix should be placed -joe On Nov 7, 2011, at 8:12 PM, DeadSun wrote: I installed openstack-dashboard and input ip in web browse. Then it show NameError at / name '_' is not definedRequest Method:GET Request URL: http://192.168.1.85/ Django Version: 1.3 Exception Type: NameError Exception Value: name '_' is not defined Exception Location: /usr/local/lib/python2.7/dist-packages/glance-2012.1-py2.7.egg/glance/common/exception.py in GlanceException, line 37 Python Executable:/usr/bin/python Python Version: 2.7.2 I found line 37 in /usr/local/lib/python2.7/dist-packages/glance-2012.1-py2.7.egg/glance/common/exception.py message = _(x) It seems '_' is not imported, but I don't know which module I need to install. -- 非淡薄无以明志，非宁静无以致远 ___ 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-poc] [Openstack] proposal for policy around and management of client libraries
The dashboard (project Horizon) depends on these today to interact with the REST API's to provide a user interface today. -joe On Nov 7, 2011, at 1:25 PM, Caitlin Bestler wrote: Monty Taylor wrote: OpenStack projects that need to depend on these will reference the git repo of the project in their tools/pip-requires file. This should take care of depends for developers. Normal installation depends can be taken care of by distro packagers as usual. Why would an openstack project *need* to reference a client library of another openstack project? Wouldn't requiring openstack projects to rely on the REST API of other projects eliminate a whole mess of release dependencies? ___ 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
Re: [Openstack] proposal for policy around and management of client libraries
The dashboard (project Horizon) depends on these today to interact with the REST API's to provide a user interface today. -joe On Nov 7, 2011, at 1:25 PM, Caitlin Bestler wrote: Monty Taylor wrote: OpenStack projects that need to depend on these will reference the git repo of the project in their tools/pip-requires file. This should take care of depends for developers. Normal installation depends can be taken care of by distro packagers as usual. Why would an openstack project *need* to reference a client library of another openstack project? Wouldn't requiring openstack projects to rely on the REST API of other projects eliminate a whole mess of release dependencies? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] keystone Endpoint schema
That's just what it sees today - the only one of the service endpoints that uses all three (right now anyway) is Keystone itself. Can you share a different pattern that you're interested in seeing supported? -joe On Oct 31, 2011, at 9:46 AM, Marcelo Martins wrote: What makes keystone assume that all types of services will have [public_url] [admin_url] [internal_url] ? Marcelo Martins Openstack-swift btorch...@zeroaccess.org ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] keystone Endpoint schema
Can you provide an example? I think you're asserting that you'd like the keystone-manage command to not require 3 different URLs when they don't exist separately, is that correct? -joe On Oct 31, 2011, at 11:45 AM, Marcelo Martins wrote: Well, If you need to specify a type when adding an endpointTemplate, then keystone should be smart enough to identify the type given and only accept the number of URLs needed for such type of service. Marcelo Martins Openstack-swift btorch...@zeroaccess.org On Oct 31, 2011, at 1:40 PM, Joseph Heck wrote: That's just what it sees today - the only one of the service endpoints that uses all three (right now anyway) is Keystone itself. Can you share a different pattern that you're interested in seeing supported? -joe On Oct 31, 2011, at 9:46 AM, Marcelo Martins wrote: What makes keystone assume that all types of services will have [public_url] [admin_url] [internal_url] ? Marcelo Martins Openstack-swift btorch...@zeroaccess.org ___ 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] OpenStack and OpenFlow
There is an openVswitch driver for quantum right now, and i believe Nicira has a proprietary driver available as well, based on OpenFlow. there is a netstack group taht would be a good place to get more involved if you wanted to be involved with developing a quantum driver: https://launchpad.net/~netstack - joe On Oct 29, 2011, at 9:07 AM, Michael J Fork mjf...@us.ibm.com wrote: At the OpenStack conference in Boston, Su-hun Yun of NEC participated in the Networking Panel and talked about their OpenFlow implementation for OpenStack. Su-hun showed a recorded demo of the plugin they developed for Quantum that talked to an NEC OpenFlow controller. Unfortunately, I have searched around looking for the demo or additional details and have not been successful. For example, it was not clear if the plugin was going to be contributed to the Quantum project, open-sourced, or kept commercial. Michael - Michael Fork Cloud Architect, Emerging Solutions IBM Systems Technology Group From:Yoshisato Ushio yoshisato.us...@gmail.com To:openstack@lists.launchpad.net Date:10/29/2011 02:08 AM Subject:[Openstack] OpenStack and OpenFlow Sent by:openstack-bounces+mjfork=us.ibm@lists.launchpad.net Hello Folks, I am interested in the use of OpenFlow technology with OpenStack. But honestly speaking, I have no deep expertise in OpenStack.Then let me ask questions. Q1) In order to use openflow features with OpenStack, such as, Open vSwitch or OpenFlow capable HW switches, can I assume that all I should do for this is to develop a quantum plugin module for openflow under nova manager ? Q2) Are there any open-source codes of quantum plugin for openflow ? Any advice would be greatly appreciated, Yoshisato Ushio___ 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] Available Mailing Lists
the ones like netstack are related to specific development teams within OpenStack, and I don't think there's a consolidated list anywhere (although you could update that Wiki page). Not all the projects have sub-lists, in fact it's relatively rare, as there's been a concerted effort to keep things flowing through the single main mailing list. -joe On Oct 29, 2011, at 11:03 AM, Michael J Fork wrote: All, I am looking for a list of of the available OpenStack-related mailing lists. I am aware of the Mailing List wiki page (http://wiki.openstack.org/MailingLists) but, for example, it does not contain the NetStack mailing list (https://launchpad.net/~netstack). What others are available? Thanks. Michael - Michael Fork Cloud Architect, Emerging Solutions IBM Systems Technology Group___ 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] +1, All services should have WADLs
Well said John. -joe On Oct 28, 2011, at 8:26 AM, John Dickinson wrote: On Oct 28, 2011, at 10:04 AM, Ed Leafe wrote: Swift had the advantage of starting out as a closed source project that only had to serve a single master, and thus didn't need external orchestration to keep it on track. Nova, OTOH, as a community development effort, essentially had to be all things to all people, which is unworkable; hence the need for some up-front design to keep some sort of focus to the development. The problem is that this inevitably descends into bikeshedding, which has been prominently on display in this thread. I absolutely do not want to compare different openstack projects. That all too often is perceived as an us vs them, and I want to avoid that altogether. Yes, nova and swift and glance and keystone and horizon are different. My point from earlier is that because the projects are different (in scope, users, and dev lifecycle), statements like all openstack projects need to do X are either meaningless or unmanageable. Openstack is a collection if different parts that should work together, but that doesn't mean that there are one size fits all solutions to issues that come up. These discussions around the One True Way to do things are a distraction at best. If you have 2 people arguing about the best way for an aspect of a particular project should work, have them both code it up (or write the docs or design the UI or whatever) and then compare and choose the best implementation. Bikeshedding (along with complaining about bikeshedding [meta!]) feels satisfying, but it's a hollow pursuit that distracts from getting things done. --John___ 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] [Keystone] Nova projects (Diablo)
Liem, There's some newer documentation that we just created at keystone.openstack.org related to setting up and configuring Keystone. Look into the page at http://keystone.openstack.org/configuring.html, which also has detail on how to configure Nova to work with Keystone. -joe On Oct 28, 2011, at 10:50 AM, Nguyen, Liem Manh wrote: Hi Stackers, For the Diablo release, I would like to use Keystone as the auth component… Do I still need to use lazy provisioning (nova_auth_token.py) in my pipeline to provision Nova projects (i.e., is Nova project creating still required)? Also, is there an example of how the novarc should be configured for Keystone? Thanks, Liem ___ 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] OpenStack Dashboard Gerrit/Github Transition
I'm working on that with the transition right now - we hope to get it back in place shortly, and are working through some of the issues of getting this backed with Gerrit now. -joe On Oct 28, 2011, at 1:53 PM, Kiall Mac Innes wrote: Hi Devin, Should we expect a diablo/stable branch? I'm only asking because the old branches are now gone. Thanks, Kiall On Oct 28, 2011 9:48 p.m., Devin Carlen devin.car...@gmail.com wrote: Hello all, We have officially completed the Gerrit/Github transition for Horizon. This is the last time we'll have to move things for a while. I promise. :) The official Horizon repo is now at: https://github.com/openstack/horizon Gerrit workflow instructions are here: http://wiki.openstack.org/GerritWorkflow Thanks to James Blair, Thierry Carrez, and Monty Taylor for all their help lately. Best, Devin ___ 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] proliferation of websites (was Re: [Nova] [Keystone] Nova projects (Diablo))
I like the idea - but I don't know what it would take to create it. I don't think openstack.org or docs.openstack.org content sites are managed in a repo. I believe I heard that Todd Morey was managing those sites, but I might be wrong. -joe On Oct 28, 2011, at 4:38 PM, Stefano Maffulli wrote: On Fri, 2011-10-28 at 19:26 -0400, Jay Pipes wrote: All the core projects have developer-specific docs at http://$PROJECT.openstack.org. got it. I still wonder whether we should find a better home for these docs and include them in a more visible path. For example, if it was under docs.openstack.org/developer/$PROJECT and formatted to include the top navigation bar (Home | Project | Community...) I think it would help. How hard would it be to achieve? /stef ___ 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] proliferation of websites (was Re: [Nova] [Keystone] Nova projects (Diablo))
Stef - As Jay mentioned, I was following the pattern that the core projects already had in place. The documentation embedded in the project (which is specifically aimed at contributors) is in this setup. I haven't yet updated the docbook pieces (which become docs.openstack.org HTML PDF) because I'm waiting for feedback from the Keystone team on some questions based on what I wrote for internal consumption. -joe On Oct 28, 2011, at 4:26 PM, Jay Pipes wrote: On Fri, Oct 28, 2011 at 7:18 PM, Stefano Maffulli stef...@openstack.org wrote: On Fri, 2011-10-28 at 13:17 -0700, Joseph Heck wrote: There's some newer documentation that we just created at keystone.openstack.org related to setting up and configuring Keystone. Look into the page at http://keystone.openstack.org/configuring.html, which also has detail on how to configure Nova to work with Keystone. Creating more websites can lead to lots of confusion for OpenStack as a project down the road. I have received lots of comments from users and new partners that the first approach to the project in general is frightening. We should try to keep documents, recipes, etc in few places where google can find them. what's the rationale for putting this documentation on keystone.openstack.org instead of reusing one of the other sites we already have, like openstack.org/wiki? Hey Stef, All the core projects have developer-specific docs at http://$PROJECT.openstack.org. Cheers! -jay ___ 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] +1, All services should have WADLs
Yeah, that's what I've been poking at and the original start of this rather lengthy thread. Unfortunately, WADL, while it appears complete, is rather obnoxious for pulling out data. Or more accurately, I haven't fully understood the WADL specification in order to write a WADL parser to allow me to do just that. I'm poking at it now, but my original goal wasn't to write an XML parser but to just create a unified API documentation set on a web site to make it easier to consume OpenStack services. -joe On Oct 27, 2011, at 8:04 AM, Lorin Hochstein wrote: It would be great if we could do some kind of transform of the IDL to generate (some of) the human-consumable REST API documentation that lives at docs.openstack.org. That would simplify the task of keeping those docs up to date. Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin On Oct 27, 2011, at 9:54 AM, Sandy Walsh wrote: Sounds awesome! I've done an application like this in the past where an entire web UI was data driven using a custom IDL. It had to have presentation hints associated with it (acceptable values, display widget, etc). Not something WADL supports inherently I'm sure. But, I know from experience this can work. I don't really care what the IDL is, so long as we don't have to write a parser for it in 10 different languages ... which is why XML/JSON hold such appeal (although JSON in C keeps me awake at night). -S From: Mark Nottingham [m...@mnot.net] Sent: Thursday, October 27, 2011 10:38 AM To: Sandy Walsh Cc: Mellquist, Peter; Joseph Heck; openstack@lists.launchpad.net Subject: Re: [Openstack] +1, All services should have WADLs I'm totally on board with having the interface being machine-consumable at runtime -- see the previous discussion on versioning and extensibility -- but WADL isn't really designed for this. I'm sketching up something more appropriate, and will be able to talk about it soon (hopefully). ___ 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] Keystone Why does it? What does? questions
On Oct 27, 2011, at 9:19 AM, Vishvananda Ishaya wrote: On Oct 25, 2011, at 12:05 PM, Joseph Heck wrote: Q: What's the keystone-manage command for credential add do? There's also no corresponding delete or disable - is this password update for the passwords that are set on keystone-manage user add? If not, how are those passwords updated? Q: What are type and key as related to credential add command, and what are they intended to do? We use the credential add command to store ec2 credentials. The idea behind credentials could be that a user would have a number of different credentials of different types. Oauth keys, ec2 secret and access, etc. I hacked the ability to add the ec2 credentials in because we needed it to make the ec2 api work in nova. The idea was that more robust support would be added through admin api extensions later. Thanks Vish! Any quick pointers to nova code (or where to find them) so I can see how you're using it today? I want to slap this into the docs (which are anemic in this area at the moment, since I didn't grok it) -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone Why does it? What does? questions
Perfect, thanks! -joe On Oct 27, 2011, at 9:38 AM, Vishvananda Ishaya wrote: See the current trunk of devstack which creates the creds and has an 'openrc' file that is sourceable and allows euca2ools to work again. There is also a bit of code in nova-manage to export users projects and keys to keystone which uses it. We don't really do anything with them in the nova code per se. Vish On Oct 27, 2011, at 9:22 AM, Joseph Heck wrote: On Oct 27, 2011, at 9:19 AM, Vishvananda Ishaya wrote: On Oct 25, 2011, at 12:05 PM, Joseph Heck wrote: Q: What's the keystone-manage command for credential add do? There's also no corresponding delete or disable - is this password update for the passwords that are set on keystone-manage user add? If not, how are those passwords updated? Q: What are type and key as related to credential add command, and what are they intended to do? We use the credential add command to store ec2 credentials. The idea behind credentials could be that a user would have a number of different credentials of different types. Oauth keys, ec2 secret and access, etc. I hacked the ability to add the ec2 credentials in because we needed it to make the ec2 api work in nova. The idea was that more robust support would be added through admin api extensions later. Thanks Vish! Any quick pointers to nova code (or where to find them) so I can see how you're using it today? I want to slap this into the docs (which are anemic in this area at the moment, since I didn't grok it) -joe ___ 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] +1, All services should have WADLs
Jorge - It's way back the beginning of this thread - A consolidated single website with API docs as HTML pages that is easy for developers to consume. I'm looking forward to seeing the WADL parser, already on that thread with David Cramer directly. I can wait until he's got it in github, which he said would likely be next week. The docs generated on doc.openstack.org are all in docbook format - neat, but not what I'm after. As I mentioned some 40 msgs back (now quite lost, I'm sure), what I'm looking to create is something like these sites provide: https://dev.twitter.com/docs/api http://developer.netflix.com/docs/REST_API_Reference http://code.google.com/p/bitly-api/wiki/ApiDocumentation#REST_API http://upcoming.yahoo.com/services/api/ That we can generate (ideally dynamically, but I'm not wedded to that) from the API's of all of Nova, Glance, Keystone and Quantum - both what we've labelled as core and extensions. My goal isn't to make, parse, or manually read WADL's - it's to make this set of web pages. If WADL helps me get there expediently, I'm all over it. -joe On Oct 27, 2011, at 11:03 AM, Jorge Williams wrote: As I stated in previous emails, we are pulling data from the WADL to grab human-consumable REST API docs that live at docs.openstack.org today. We can certainly expand that capability to create a unified API documentation set rather than individual guides. A lot of the hard work for parsing is already done, and we'll be releasing a WADL normalizer that puts the WADL in an easer to process form. Joe, I'd love to hear more about what you're trying to accomplish. Maybe we can help you leverage the tools we have to accomplish them. -jOrGe W. On Oct 27, 2011, at 10:51 AM, Joseph Heck wrote: Yeah, that's what I've been poking at and the original start of this rather lengthy thread. Unfortunately, WADL, while it appears complete, is rather obnoxious for pulling out data. Or more accurately, I haven't fully understood the WADL specification in order to write a WADL parser to allow me to do just that. I'm poking at it now, but my original goal wasn't to write an XML parser but to just create a unified API documentation set on a web site to make it easier to consume OpenStack services. -joe On Oct 27, 2011, at 8:04 AM, Lorin Hochstein wrote: It would be great if we could do some kind of transform of the IDL to generate (some of) the human-consumable REST API documentation that lives at docs.openstack.org. That would simplify the task of keeping those docs up to date. Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin On Oct 27, 2011, at 9:54 AM, Sandy Walsh wrote: Sounds awesome! I've done an application like this in the past where an entire web UI was data driven using a custom IDL. It had to have presentation hints associated with it (acceptable values, display widget, etc). Not something WADL supports inherently I'm sure. But, I know from experience this can work. I don't really care what the IDL is, so long as we don't have to write a parser for it in 10 different languages ... which is why XML/JSON hold such appeal (although JSON in C keeps me awake at night). -S From: Mark Nottingham [m...@mnot.net] Sent: Thursday, October 27, 2011 10:38 AM To: Sandy Walsh Cc: Mellquist, Peter; Joseph Heck; openstack@lists.launchpad.net Subject: Re: [Openstack] +1, All services should have WADLs I'm totally on board with having the interface being machine-consumable at runtime -- see the previous discussion on versioning and extensibility -- but WADL isn't really designed for this. I'm sketching up something more appropriate, and will be able to talk about it soon (hopefully). ___ 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 ___ 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] SystemUsageData in Diablo via notification system?
Have you been testing and/or working with a specific hub from the list on that wiki page (http://code.google.com/p/pubsubhubbub/wiki/Hubs)? What I'm wondering is how we could set up a notification system that would be highly available (i.e. two nodes or a failover mechanism) that wouldn't loose data. I don't have any background with pubsubhubbub as yet, so looking for some insight from someone who has messed with it previously. -joe On Oct 26, 2011, at 10:25 AM, Monsyne Dragon wrote: I answered Roe Lee's question via email, but I figured some other folks on the list might want to know as well... Begin forwarded message: Date: October 26, 2011 12:21:34 AM CDT To: Roe Lee hrlee...@gmail.com Subject: Re: SystemUsageData in Diablo via notification system? Hello! Yes, notifications were mostly added in Diablo, and the usage data has also been expanded in the current trunk (for the Essex release). I have updated some of the information on the implementation on notifications on the openstack wiki here: http://wiki.openstack.org/NotificationSystem#Implementation On Oct 25, 2011, at 10:20 PM, Roe Lee wrote: Hi- I am looking for the way to get system usage data for a billing purpose in Diablo release. Is there anyone know as to how to get event messages such as compute.instance.create, compute.instance.delete, etc? I believe this information cat be retrieved via log files or AMQP. P.S: I guess system usage data is not available in cactus. Hope to hearing any tips. Thanks, Roe -- This message was sent from Launchpad by Roe Lee (https://launchpad.net/~roe-lee) to each member of the OpenStack Team team using the Contact this team link on the OpenStack Team team page (https://launchpad.net/~openstack). For more information see https://help.launchpad.net/YourAccount/ContactingPeople -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] describing APIs for OpenStack consumers
I expect this is going to open a nasty can of worms... today we don't have a consistent way of describing the APIs for the various services. I saw Nati's bug (https://launchpad.net/bugs/881621), which implies that all the services should have a WADL somewhere describing the API. I'm not a huge fan of WADL, but the only other thing I've found is swagger (http://swagger.wordnik.com/spec). I have been working towards trying to create an comprehensive OpenStack API documentation set that can be published as HTML, not unlike some of these: https://dev.twitter.com/docs/api http://developer.netflix.com/docs/REST_API_Reference http://code.google.com/p/bitly-api/wiki/ApiDocumentation#REST_API http://upcoming.yahoo.com/services/api/ To make this sort of web-page documentation effective, I think it's best to drive it from descriptions on each of the projects (if we can). I've checked with some friends who've done similar, and learned that most of the those API doc sets are maintained by hand - not generated from description files. What do you all think about standardizing on WADL (or swagger) as a description of the API and generating comprehensive web-site-based API documentation from those description files? Does anyone have any other description formats that would work for this as an alternative? (I admit I don't want to get into XML parsing hell, which is what it appears that WADL might lead too) -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone Why does it? What does? questions
On Oct 25, 2011, at 12:54 PM, Jesse Andrews wrote: I'm not an expert ... adding some comments On Tue, Oct 25, 2011 at 12:05 PM, Joseph Heck he...@me.com wrote: I've just dropped in place a bunch of developer documentation (RST) for Keystone - one in, one pending (https://review.openstack.org/#change,1089). Making these docs brought up a number of questions that I wasn't able to answer. I want to put more context around the commands and concepts for the reader prior to updating the docbook documentaiton. Joe Savak suggested on IRC that I just drop them out here to the list, so here goes: If any of these are just bugs, let me know and I'll file them. Q: Why is an administrative service token bound to a tenant? Right now, keystone-manage to create an administrative service token, the token which in turn is configured into nova, swift, glance, and dashboard, requires a tenant - but as I understand tenant that doesn't make sense - as the various services all serve more than one tenant. we create a tenant for services and then create the long lived validation for missed some of this create long lived validation for what? Q: How do you remove a service? You can invalidate the token - which means the service can no longer validate user tokens You can remove the service from the catalog Is there an API for removing the service from the catalog? There isn't a keystone-manage command for it (that I found) Q: How do you remove an EndpointTemplate? not sure through the api, but can you via keystone-manage? If not you can remove via the database. I think that's direct database manipulation then. Ziad/Dolph/Yogi - can you confirm? Should be a bug? Q: What's the purpose of a role prior to RBAC Is it really just relevant for the Keystone administrative API, but more coming online later with the RBAC work? Does any role based link between a user and a tenant allow that user to get a scoped token for that tenant? Currently as specified a token validation can return roles, which then can allow services to implement rbac. The session on can haz was talking about how nova can do that without any changes in keystone. Ziad/Yogi/Dolph - is there anything that role does *today* (i.e. Diablo release) other than authorizing access to the Keystone Admin API? Q: How do you remove a role? Not sure how to - I think this should be another extension since in an enterprise deployment the roles would be set by mapping ldap/ad groups into roles Missing? Should be a bug? Q: What's the keystone-manage command for credential add do? There's also no corresponding delete or disable - is this password update for the passwords that are set on keystone-manage user add? If not, how are those passwords updated? Q: What are type and key as related to credential add command, and what are they intended to do? Q: Why isn't there a user delete and a tenant delete? Is this a just haven't gotten to it yet bug? Those should probably be in the user/tenant extension. Not sure if they are there or not. ___ 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] describing APIs for OpenStack consumers
Which dev docs and how? I haven't spotted those scripts or systems... -joe On Oct 25, 2011, at 2:58 PM, Jorge Williams wrote: Some of that dev guide documentation is generated from a WADL :-) The purpose of a WADL is that it is machine readable so it opens up a lot of possibilities, for creating docs, testing, validation, etc. -jOrGe W. On Oct 25, 2011, at 4:14 PM, Daryl Walleck wrote: Hi everyone, This is just my opinion, but I've only found WADLs very useful when use tool based automation. To me they're a huge headache to read. To me, the current dev guide style of documentation has been far more helpful in developing automation. Daryl On Oct 25, 2011, at 3:24 PM, Anne Gentle wrote: Hi all - Would also love Swagger. Nati looked into it and he thought it would require a Python client generator, based on reading that Client generators are currently available for Scala, Java, Javascript, Ruby, PHP, and Actionscript 3. So in the meantime the QA list and Nati suggested WADL as a starting point for auto-generating simple API documentation while also looking towards Swagger for a way to document a public cloud like the Free Cloud. At the last OpenStack hackathon in the Bay Area (California), Nati worked through a simple WADL reader, he may be able to describe it better. Hope that helps - sorry it's not more detailed than that but wanted to give some background, sounds like we all want similar outcomes and the resources for tasks to get us to outcomes is all we're lacking. QA Team, let me know how the Docs Team can work with you here. Anne Anne Gentle a...@openstack.org my blog | my book | LinkedIn | Delicious | Twitter On Tue, Oct 25, 2011 at 2:41 PM, Joseph Heck he...@mac.com wrote: I expect this is going to open a nasty can of worms... today we don't have a consistent way of describing the APIs for the various services. I saw Nati's bug (https://launchpad.net/bugs/881621), which implies that all the services should have a WADL somewhere describing the API. I'm not a huge fan of WADL, but the only other thing I've found is swagger (http://swagger.wordnik.com/spec). I have been working towards trying to create an comprehensive OpenStack API documentation set that can be published as HTML, not unlike some of these: https://dev.twitter.com/docs/api http://developer.netflix.com/docs/REST_API_Reference http://code.google.com/p/bitly-api/wiki/ApiDocumentation#REST_API http://upcoming.yahoo.com/services/api/ To make this sort of web-page documentation effective, I think it's best to drive it from descriptions on each of the projects (if we can). I've checked with some friends who've done similar, and learned that most of the those API doc sets are maintained by hand - not generated from description files. What do you all think about standardizing on WADL (or swagger) as a description of the API and generating comprehensive web-site-based API documentation from those description files? Does anyone have any other description formats that would work for this as an alternative? (I admit I don't want to get into XML parsing hell, which is what it appears that WADL might lead too) -joe ___ 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 ___ 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] describing APIs for OpenStack consumers
It sounds like even though most of us hate WADL, it's what we're expending effort after to make a consolidated API set. So unless Nati and Ravi want to switch to using Swagger (or something else), WADL is the direction we're heading. I totally agree with Daryl that reading it is a PITA, and am finding (from my part) that the only definitive way to know about writing the docs and documenting the authoritative API is to read the underlying code. (which is what I suspect Nati likely did with the pull request that adds in WADL for the Nova/OpenCompute extension API) Nati - do you have your WADL parsing/reading code stashed in a public git repo somewhere that I could work with and help expand upon? I'd like to see what I can do to modify it to generate some of the interactive docs. On Oct 25, 2011, at 2:56 PM, Jorge Williams wrote: We've done quite a bit of work to get high quality documentation from a WADL, in fact we are using some of this today. We've taken most of the hard work re: parsing the WADL, at least for the purpose of generating docs from it and of writing code that can read it (though that later part can use a bit more work). We are also working to add WADL support in Repose, which we presented at the summit, you can find the presentation here: https://github.com/rackspace/repose/tree/master/documentation/presentations. The plan there is to have an HTTP proxy that can do validation of a service on the fly. When it's done, you could, for example, turn this on when you run functional tests and get a gauge as to what your API coverage is and track both client and service API errors. Other API tools like Apigee and Mashery already have support for WADL. In fact apigee maintains an extensive wadl library for common APIs: https://github.com/apigee/wadl-library. There is some WADL support in python as well, though I haven't tested it first hand. So obviously, I'd vote for WADL. I haven't looked at Swagger too deeply, at first glance it *seems* to be missing some stuff -- but I'll have to study it in detail to be sure. (How do you define acceptable media types, matrix parameters, that a particular HTTP header is required?) I don't like the fact that it tries to describe the format of the message as well as the HTTP operations. I'd rather take the approach that WADL takes which is to rely on existing schema languages like XML Schema and JSON Schema. What I do like about Swagger is that you seem to be able to generate some really cool interactive documentation from it. I really like their API explorer feature for example: You can see it here: http://developer.wordnik.com/docs#!/account/get_word_lists_for_current_user. That's pretty cool. The thing is though, I could easily generate Swagger from my WADL :-) So choosing WADL doesn't necessarily mean that we can't get access to those tools. Just my 2 cents, -jOrGe W. On Oct 25, 2011, at 3:24 PM, Anne Gentle wrote: Hi all - Would also love Swagger. Nati looked into it and he thought it would require a Python client generator, based on reading that Client generators are currently available for Scala, Java, Javascript, Ruby, PHP, and Actionscript 3. So in the meantime the QA list and Nati suggested WADL as a starting point for auto-generating simple API documentation while also looking towards Swagger for a way to document a public cloud like the Free Cloud. At the last OpenStack hackathon in the Bay Area (California), Nati worked through a simple WADL reader, he may be able to describe it better. Hope that helps - sorry it's not more detailed than that but wanted to give some background, sounds like we all want similar outcomes and the resources for tasks to get us to outcomes is all we're lacking. QA Team, let me know how the Docs Team can work with you here. Anne Anne Gentle a...@openstack.org my blog | my book | LinkedIn | Delicious | Twitter On Tue, Oct 25, 2011 at 2:41 PM, Joseph Heck he...@mac.com wrote: I expect this is going to open a nasty can of worms... today we don't have a consistent way of describing the APIs for the various services. I saw Nati's bug (https://launchpad.net/bugs/881621), which implies that all the services should have a WADL somewhere describing the API. I'm not a huge fan of WADL, but the only other thing I've found is swagger (http://swagger.wordnik.com/spec). I have been working towards trying to create an comprehensive OpenStack API documentation set that can be published as HTML, not unlike some of these: https://dev.twitter.com/docs/api http://developer.netflix.com/docs/REST_API_Reference http://code.google.com/p/bitly-api/wiki/ApiDocumentation#REST_API http://upcoming.yahoo.com/services/api/ To make this sort of web-page documentation effective, I think it's best to drive it from descriptions on each of the projects (if we can
Re: [Openstack] describing APIs for OpenStack consumers
That's exactly what I'm poking at (and what Nati has started doing as well). I was trying to see if there was a consistent way to describe all the API endpoints that could be used to document the combined set. The raw description is clearly insufficient, so how best to create a final product that has that information. My original question was towards can we embed that additional information in the API description and render it into final form, or do we just bag it and manage all of that detail by hand (in restructuredtext, docbook, etc) -joe On Oct 25, 2011, at 3:34 PM, Caitlin Bestler caitlin.best...@nexenta.com wrote: WADL sounds like a wonderful validation tool. But shouldn’t our primary goal be finding a consistent way to describe the APIs for *application developers*. Syntax tools, whether ancient notations like BNF or the latest XML concoction only tell you the syntax of the operation. There also has to be consistent information that provides information to the reader as to when and why they would use this specific operation, not just how to format it. There is also a tendency of syntax oriented tools to omit vital state information, particularly the expected sequence of operations. ___ 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] Keystone versioning and tarballs
.3 means 3rd quarter I noticed that the developer docs aren't grabbing the version correctly to place them in when rendering... is keystone.version() the right place to get that information? If so, I'll make that edit to get it into the developer docs generation. -joe On Oct 24, 2011, at 9:09 AM, Dolph Mathews wrote: As long as the versioning scheme is self-consistent, I don't have any opinion on what we use. How do Openstack's named releases (cactus, diablo, essex) not work, though? (they're still sortable, right?) (and what was the .3 in 2011.3 supposed to mean? I assume it's not March, considering the October release...) -Dolph From: Mark McLoughlin [mar...@redhat.com] Sent: Monday, October 24, 2011 10:36 AM To: Dolph Mathews Cc: Ziad Sawalha; Thierry Carrez; openstack@lists.launchpad.net Subject: RE: Keystone versioning and tarballs Hi Dolph, On Mon, 2011-10-24 at 14:35 +, Dolph Mathews wrote: We definitely need to publish a tarball for diablo. Cool. Will the version be 1.0 or 2011.3, though? :) I recently refactored/centralized our versioning (we were reporting different versions in different places in the codebase). At the same time, I also set the `keystone.version()` response to 'essex-dev', since we haven't discussed codebase versioning very thoroughly, and it needed to be updated to *something* post-diablo. So, this is certainly open to feedback/suggestions/discussion! Well, a completely non-numeric version doesn't work IMHO. The easiest path is to copy nova and glance, no? i.e diablo was 2011.3 and essex is 2012.1 Cheers, Mark. This email may include confidential information. If you received it in error, please delete it. ___ 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] [QA] openstack-integration-tests
What you've described is a great unit testing framework, but with integration testing you need recognition that some tests are dependent of specific system state - and therefore can not be run blindly in parallel. Some can, just not all - and often the most expedient way to get a system in a known state is to walk it there through sequences of tests. I believe we essentially already have this framework in place with the openstack-integration-tests repo and the proposed (but not yet implemented) set of tests using proboscis to enable dependencies and grouping in those tests. -joe On Oct 19, 2011, at 5:00 PM, Ngo, Donald (HP Cloud Services : QA) donald@hp.com wrote: My wish list for our proposed framework: -Create XML JUnit style run reports -Run tests in parallel -Should be able to run out of the box with little configuration (a single configuration file, everything in one place) -Run through standard runner like Nosetest (i.e. nosetests /Kong or nosetests /YourSuite). This will allow the suites to easily integrate in each company’s framework. -Tests framework should support drop and run using reflection as a way to identify tests to run Thanks, Donald From: openstack-bounces+donald.ngo=hp@lists.launchpad.net [mailto:openstack-bounces+donald.ngo=hp@lists.launchpad.net] On Behalf Of Brebner, Gavin Sent: Wednesday, October 19, 2011 10:39 AM To: Daryl Walleck; Rohit Karajgi Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [QA] openstack-integration-tests My 2c To me, the end-customer facing part of the Openstack solution is in many ways the set of libraries and tools customers are likely to use – as such testing with them is essential. If there’s a bug that can be only exposed through some obscure API call that isn’t readily available through one of the usual libraries, it mostly will be of only minor importance as it will be rarely if ever get used, whereas e.g. a bug in a library that causes data corruption will not be good for Openstack no matter how correct things are from the endpoint in. The whole solution needs to work; this is complex as we don’t necessarily control all the libraries, and can’t test everything with every possible library, so we have to do the best we can to ensure we catch errors as early as possible e.g. via direct API testing for unit tests / low level functional tests. Testing at multiple levels is required, and the art is in selecting how much effort to put at each level. Re. framework we need a wide range of capabilities, hence keep it simple and flexible. One thing I’d really like to see would be a means to express parallelism – e.g. for chaos monkey type tests, race conditions, realistic stress runs and so on. Support for tests written in any arbitrary language is also required. I can write all this myself, but would love a framework to handle it for me, and leave me to concentrate on mimicking what I think our end customers are likely to do. Gavin From: openstack-bounces+gavin.brebner=hp@lists.launchpad.net [mailto:openstack-bounces+gavin.brebner=hp@lists.launchpad.net] On Behalf Of Daryl Walleck Sent: Wednesday, October 19, 2011 6:27 PM To: Rohit Karajgi Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [QA] openstack-integration-tests Hi Rohit, I'm glad to see so much interest in getting testing done right. So here's my thoughts. As far as the nova client/euca-tools portion, I think we absolutely need a series of tests that validate that these bindings work correctly. As a nice side effect they do test their respective APIs, which is good. I think duplication of testing between these two bindings and even what I'm envisioning as the main test suite is necessary, as we have to verify at least at a high level that they work correctly. My thoughts for our core testing is that those would the ones that do not use language bindings. I think this is where the interesting architectural work can be done. Test framework is a very loose term that gets used a lot, but to me a framework includes: The test runner and it's capabilities How the test code is structured to assure maintainability/flexibility/ease of code re-use Any utilities provided to extend or ease the ability to test I think we all have a lot of good ideas about this, it's just a matter of consolidating that and choosing one direction to go forward with. Daryl On Oct 19, 2011, at 9:58 AM, Rohit Karajgi wrote: Hello Stackers, I was at the design summit and the sessions that were ‘all about QA’ and had shown my interest in supporting this effort. Sorry I could not be present at the first QA IRC meeting due to a vacation. I had a chance to eavesdrop at the meeting log and Nachi-san also shared his account of the outcome with me. Thanks Nachi! Just a heads
Re: [Openstack] [QA] openstack-integration-tests
, if not into the thousands of tests, which in my mind significantly changes how I would design the suite. Daryl On Oct 19, 2011, at 7:26 PM, Joseph Heck wrote: What you've described is a great unit testing framework, but with integration testing you need recognition that some tests are dependent of specific system state - and therefore can not be run blindly in parallel. Some can, just not all - and often the most expedient way to get a system in a known state is to walk it there through sequences of tests. I believe we essentially already have this framework in place with the openstack-integration-tests repo and the proposed (but not yet implemented) set of tests using proboscis to enable dependencies and grouping in those tests. -joe On Oct 19, 2011, at 5:00 PM, Ngo, Donald (HP Cloud Services : QA) donald@hp.com wrote: My wish list for our proposed framework: -Create XML JUnit style run reports -Run tests in parallel -Should be able to run out of the box with little configuration (a single configuration file, everything in one place) -Run through standard runner like Nosetest (i.e. nosetests /Kong or nosetests /YourSuite). This will allow the suites to easily integrate in each company’s framework. -Tests framework should support drop and run using reflection as a way to identify tests to run Thanks, Donald From: openstack-bounces+donald.ngo=hp@lists.launchpad.net [mailto:openstack-bounces+donald.ngo=hp@lists.launchpad.net] On Behalf Of Brebner, Gavin Sent: Wednesday, October 19, 2011 10:39 AM To: Daryl Walleck; Rohit Karajgi Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [QA] openstack-integration-tests My 2c To me, the end-customer facing part of the Openstack solution is in many ways the set of libraries and tools customers are likely to use – as such testing with them is essential. If there’s a bug that can be only exposed through some obscure API call that isn’t readily available through one of the usual libraries, it mostly will be of only minor importance as it will be rarely if ever get used, whereas e.g. a bug in a library that causes data corruption will not be good for Openstack no matter how correct things are from the endpoint in. The whole solution needs to work; this is complex as we don’t necessarily control all the libraries, and can’t test everything with every possible library, so we have to do the best we can to ensure we catch errors as early as possible e.g. via direct API testing for unit tests / low level functional tests. Testing at multiple levels is required, and the art is in selecting how much effort to put at each level. Re. framework we need a wide range of capabilities, hence keep it simple and flexible. One thing I’d really like to see would be a means to express parallelism – e.g. for chaos monkey type tests, race conditions, realistic stress runs and so on. Support for tests written in any arbitrary language is also required. I can write all this myself, but would love a framework to handle it for me, and leave me to concentrate on mimicking what I think our end customers are likely to do. Gavin From: openstack-bounces+gavin.brebner=hp@lists.launchpad.net [mailto:openstack-bounces+gavin.brebner=hp@lists.launchpad.net] On Behalf Of Daryl Walleck Sent: Wednesday, October 19, 2011 6:27 PM To: Rohit Karajgi Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [QA] openstack-integration-tests Hi Rohit, I'm glad to see so much interest in getting testing done right. So here's my thoughts. As far as the nova client/euca-tools portion, I think we absolutely need a series of tests that validate that these bindings work correctly. As a nice side effect they do test their respective APIs, which is good. I think duplication of testing between these two bindings and even what I'm envisioning as the main test suite is necessary, as we have to verify at least at a high level that they work correctly. My thoughts for our core testing is that those would the ones that do not use language bindings. I think this is where the interesting architectural work can be done. Test framework is a very loose term that gets used a lot, but to me a framework includes: The test runner and it's capabilities How the test code is structured to assure maintainability/flexibility/ease of code re-use Any utilities provided to extend or ease the ability to test I think we all have a lot of good ideas about this, it's just a matter of consolidating that and choosing one direction to go forward with. Daryl On Oct 19, 2011, at 9:58 AM, Rohit Karajgi wrote: Hello Stackers, I was at the design summit and the sessions that were ‘all about QA’ and had shown my interest in supporting this effort. Sorry I could not be present at the first QA IRC meeting
Re: [Openstack] openstack storage comparison with extreemfs
Hi Sudhakar - I'm not terribly familiar with xtreemFS, but glancing at their website, it looks like it's replicated block-volume mechanism not unlink gluster or ceph. There is no plugin or back-end that takes the Nova block volume components and uses this - if it supports an iSCSI interface to the VMs, then I suppose you could create a back-end that did that work for you, but right now there's no support or even really explicit knowledge of it from within Nova. That's not to say you couldn't use it - just that it isn't used or supported in OpenStack today. -joe On Oct 12, 2011, at 2:43 AM, Sudhakar Maiya wrote: Hi, can anyone tell me that if we can implment openstack stroage as extreemfs. Regards Sudhakar ___ 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] openstack dashboard
Swift support is in the dashboard, and is configured entirely by Keystone, upon which Dashboard depends for the API endpoints from its service catalog. You will need swift and dashboard both configured in Keystone to get the operability. - joe On Oct 7, 2011, at 11:20 AM, Khaled Ben Bahri khaled-...@hotmail.com wrote: Hi, for windows OS there are cyberduck software http://cyberduck.ch/ On linux System, there are dashboard for Nova but I wonder if we can configure it for swift Regards Khaled Date: Fri, 7 Oct 2011 08:14:16 -0300 From: corre...@gmail.com To: openstack@lists.launchpad.net Subject: Re: [Openstack] openstack dashboard I appreciate too! Is it possible to use Dashboard as interface to Swift to do users activities, for example, a web interface like Dropbox where users can upload and download files? I've seen tutorials with Cyberduck, but just one client isn't cool. Thanks! On Fri, Oct 7, 2011 at 6:19 AM, Khaled Ben Bahri khaled-...@hotmail.com wrote: Hi, can any one help me please to configure dashboard for openstack swift, or if there are any other web interface for swift what I found is for nova. thanks in advance for any help Best regards Khaled ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- - MSc. Correa, J.L. ___ 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] openstack-nova
That code update has already landed - its actually in the Diablo release, just not the default mechanism as yet. Carrot should be fully deprecated by the Essex release in favor of the Kombu AMQP library -joe On Oct 6, 2011, at 4:18 AM, Armaan wrote: i am asking this question out curiosity, Nova uses Carrot to connect with RabbitMQ environment. But Carrot has already been discontinued in favor of Kombu framework. So in near future, is there any possibility that nova will use Kombu instead of carrot. Regards Syed Armani ___ 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] keystone + dash + diablo user flows
Can we clone this into the Openstack repo so that it's clear: a) there is a central set of openstack integration and functional tests b) that it is THE place to add in common, cross-cutting tests I don't really care which setup we use as the OpenStack project - Soren's is fine, just needs to be central and open, and ideally have a set of approvers for adding tests through Gerrit (I suggest we just start with Soren and grow it from there) -joe On Sep 21, 2011, at 11:31 AM, Jay Pipes wrote: All good, Jesse. I think it would be appropriate to either create a new smoketest that stresses the flow you outline below, or add a new integration test to here: https://github.com/sorenh/openstack-integration-tests Otherwise, testing will by nature be a manual process Cheers! -jay On Wed, Sep 21, 2011 at 4:16 AM, Jesse Andrews anotherje...@gmail.com wrote: As part of the release meeting today we talked about getting a preview release of keystone + dash + diablo working asap. This is an attempt to summarize the major interfaces. Ziad and team have an identity guide (they are updating and can share asap) to help flush this out. Here is what I see needs implemented to make Dash + Nova + Keystone work together. This is a subset of the auth spec (what Ziad team are working to support Diablo as these are the contracts between those services) 1. CREATE TOKEN: (enduser api)POST /v2.0/tokens post data: https://github.com/openstack/keystone/blob/master/keystone/content/common/samples/auth_credentials.json response: https://github.com/openstack/keystone/blob/master/keystone/content/common/samples/auth.json 2. VALIDATE TOKEN: (admin api) GET /v2.0/tokens/(token)?[belongs_to=(tenant_id)] response: https://github.com/openstack/keystone/blob/master/keystone/content/common/samples/validatetoken.json 3. TENANTS FOR TOKEN: (user api)GET /v2.0/tenants returns: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/docbkx/samples/tenants.json These 3 APIs are the meat of the keystone auth api (disregarding CRUD operations for users/tenants) Flow: * user visits a web console to login to openstack * dashboard uses keystone to authenticate (dashboard has no internal user system, and shouldn't store username/password in session/shared state) * since there can be a many to many relationship between users and tenants, the user might need to specify the tenant they want to operate on before talking with services like nova/glance/... * A service like NOVA need to validate (via http proxy or middleware) the token and return a USER, TENANT (previously known as a project in nova), and a list of roles. Notes: * a tenant is a project in nova and an account in swift. Think of it as the entity that owns the resources. * a user is the acting entity. * while keystone implements many-to-many tenant/user support, services should support many-to-many, one-to-many, one-to-one - as the API makes no assumptions about the hierarchical nature of the users/tenants * when getting the response to the create unscoped token, I write that it returns stuff. While it technically returns the roles, serviceCatalog, userinfo (same structure as for the scoped token), it isn't guaranteed to be the complete list of roles/endpoints for every tenant the user is a member of. * since the goal of the dashboard is to toggle visibility/functionality based on capabilities presented in the service catalog, we ask for a scoped token that has the capabilities for the tenant / user pair. * I use nova as my example but the approach is generalized. * crud operations for users/tenants exists both in keystone-manage and api calls. While dashboard has had user management capabilities in the past, we might rely on command line user management for the first release of the preview. * mistakes in this summary are mine (please correct me)… up until a few hours ago I had assumed the relationship betweens tenants/users and tokens was subtly different. ps. The swimlane (sequence diagram) was generated with sdedit (sourceforge) and is attached for patches :) ___ 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] Diablo 4 dashboard install errror (bzr: ERROR: Not a branch: https://launchpad.net/glance/.)
It will be tomorrow - I'll be making changes to track the shifting repos this weekend. -joe On Sep 15, 2011, at 10:40 PM, 董志斌 atk...@gmail.com wrote: Hi, but quantum project no git , 2011/9/16 Jae Sang Lee hyan...@gmail.com Hi. launchpad glance repo is not running, change address at github. -e git+https://github.com/openstack/glance.git#egg=glance -Jaesang 2011/9/16 董志斌 atk...@gmail.com Hi,jay the current pip-requires file content: nose==1.0.0 Django==1.3 django-nose==0.1.2 django-mailer django-registration==0.7 kombu python-cloudfiles python-dateutil routes webob sqlalchemy paste PasteDeploy sqlalchemy-migrate eventlet xattr pep8 pylint coverage -e bzr+https://launchpad.net/glance#egg=glance -e bzr+https://launchpad.net/quantum#egg=quantum -e git+https://github.com/jacobian/openstack.compute.git#egg=openstack -e git+https://github.com/cloudbuilders/openstackx.git#egg=openstackx -e git://github.com/rackspace/python-novaclient.git#egg=python-novaclient 2011/9/16 Jay Pipes jaypi...@gmail.com Hi! Replace this line in tools/pip-requires: bzr+https://launchpad.net/glance#egg=glance With this: glance Cheers! -jay 2011/9/15 董志斌 atk...@gmail.com: Hi i thouth to git get dashboard(https://github.com/4P/openstack-dashboard.git), when i execution python install_env.py，error： Downloading/unpacking bzr+https://launchpad.net/glance#egg=glance (from -r pip-requires (line 21)) Checking out https://launchpad.net/glance to /tmp/pip-e_1gWw-build bzr: ERROR: Not a branch: https://launchpad.net/glance/;. Complete output from command /usr/bin/bzr branch -q https://launchpad.net/glance /tmp/pip-e_1gWw-build: Command /usr/bin/bzr branch -q https://launchpad.net/glance /tmp/pip-e_1gWw-build failed with error code 3 Storing complete log in /root/.pip/pip.log are you help me ? from china ___ 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 ___ 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] multinode diablo - debugging why a VM won't start up
Good morning, I've installed Diablo from packages (from trunk) yesterday on Ubuntu 11.04 - and have a single instance setup working just fine for firing up instances, shutting them down, etc. I then attempted to add a computing node to that setup, but have been unable to get instances to fire up on that remote node. euca-describe-instances shows it going past scheduling to networking, but it doesn't get beyond that point. In the logs, I see the nova-compute attempt to create the node: It talks with Glance, gets the instance details, and then makes a call to nova-network, where it seems to stall out. 2011-08-19 08:37:13,456 DEBUG nova.rpc [-] Making asynchronous call on network ... from (pid=1047) multicall /usr/lib/pymodules/python2.7/nova/rpc/amqp.py:462 2011-08-19 08:37:13,457 DEBUG nova.rpc [-] MSG_ID is c35f4791df754059b70f7351706db17f from (pid=1047) multicall /usr/lib/pymodules/python2.7/nova/rpc/amqp.py:465 After a little while (few seconds), I start to see this in the logs: 2011-08-19 08:37:57,136 INFO nova.compute.manager [-] Found instance 'instance-0015' in DB but no VM. State=0, so setting state to shutoff. 2011-08-19 08:37:57,137 INFO nova.compute.manager [-] DB/VM state mismatch. Changing state from '0' to '5' I'm using KVM, and the /etc/nova/nova.conf file is a replica of the one on the controller node. Other quirks of this setup include running it on a single NIC (eth0) and FlatDHCPNetworking. (relevant pieces from nova.conf) --network_manager=nova.network.manager.FlatDHCPManager --flat_network_bridge=br100 --flat_injected=False --flat_interface=eth0 --public_interface=eth0 While I see a br100 network interface (gets created for me) on the controller, I don't see one on the compute-only node (I've installed the packages nova-compute and nova-network). Do I need to create a br100 manually in /etc/network/interfaces? Any suggestions on where I would look for additional logging/debugging information? It seems like something in failing in nova-network, but i'm not sure where to look for and see more detail. -joe ___ 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] web interface
It was for the bexar release. In Cactus and in the current trunk, the dashboard has continued to evolve, most recently (trunk only) adding swift support. Dashboard is an incubating project within Openstack. The trunk development is on Github at https://github.com/4P/openstack-dashboard/, documentation is lagging just a touch, but the most recent updates by Mike should have installation instructions in the docs to match installing dashboard with Nova, Glance, Swift, and Keystone. - joe On Jul 22, 2011, at 2:37 AM, Zeeshan Ali Shah zas...@pdc.kth.se wrote: Hi, Is this the dashboard for managing Openstack ? http://docs.openstack.org/bexar/openstack-compute/admin/content/ch06.html -- -- Regards Zeeshan Ali Shah System Administrator PDC-Center for High Performance Computing CSC School of Computer Science and Communication KTH-Royal Institute of Technology , Sweden +46 8 790 9115 ___ 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] FW: [Netstack] Official Python version for Quantum
Openstack currently supports back through Python 2.6 and includes Python 2.7 - as far as I know, we're not aiming to support any Python 3.x versions as yet. -joe On Jul 20, 2011, at 1:04 PM, Debo Dutta (dedutta) wrote: Some of us were discussing about the official stand on what version of python one should use for Diablo. The web page says 2.6.x. If folks are going to test on ubuntu 11.04 etc, then I guess things need to run on 2.7.x …..Clarification would be very useful. Debo From: Dan Wendlandt [mailto:d...@nicira.com] Sent: Wednesday, July 20, 2011 1:02 PM To: Debo Dutta (dedutta) Cc: Edgar Magana (eperdomo); netst...@lists.launchpad.net Subject: Re: [Netstack] Official Python version for Quantum On Wed, Jul 20, 2011 at 11:51 AM, Debo Dutta (dedutta) dedu...@cisco.com wrote: Hi Dan Maybe we should talk to the Openstack list too …. We know OS works fine on Ubuntu 11.04 with 2.7.2 and that dev env page was written in Jan 2011 before 11.04 came out. Maybe that will get updated soon! Definitely, I'd encourage you to contact the main list. A clarification on this point would be useful. I use 11.04 fairly frequently as well and agree that I haven't seen any problems. dan Debo From: netstack-bounces+dedutta=cisco@lists.launchpad.net [mailto:netstack-bounces+dedutta=cisco@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: Wednesday, July 20, 2011 10:56 AM To: Edgar Magana (eperdomo) Cc: netst...@lists.launchpad.net Subject: Re: [Netstack] Official Python version for Quantum Hi Edgar, That's a good question. I think this is a case where we would invoke the what is the larger openstack policy? principle. My understanding is that Nova assumes python 2.6.x (http://wiki.openstack.org/PythonDevelopmentEnvironment), though in practice I suspect a general rule would be to avoid using anything that will break in python 2.7 or python 3.x if there is a reasonable alternative (hence, it often works on newer versions). RHEL can generally be a pain with OpenStack, though I know there are people working on improving the experience. I'd probably direct this conversation to the OpenStack community as a whole if you have further question or specific points you'd like to bring up. Thanks, Dan On Wed, Jul 20, 2011 at 10:46 AM, Edgar Magana (eperdomo) eperd...@cisco.com wrote: Hello Folks, I would like to know if we have defined an official version of Python to be used on all Quantum development. Is it 2.6 or 2.7? Is there any place on the Quantum blueprints where we have defined the supported versions of all the libraries that we are using for our development? Thanks, Edgar -- 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, Inc. www.nicira.com | www.openvswitch.org Sr. Product Manager cell: 650-906-2650 ~~~ -- ~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org Sr. Product Manager cell: 650-906-2650 ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Multi-nic support question
Afternoon! I ran into an issue with the multi-nic addition that just hit trunk - wanted to see how best to resolve or if this is a bug. The signature for the create() method in NetworkCommands (in nova/bin/nova-manage) changed - which means that the existing docs to create a network: nova-manage network create 10.0.0.0/24 1 32 Fails with an index out of range error. The reason is that the arguments ['10.0.0.0/24', '1', '32'] no longer match up as expected with the arguments in create(). Label=None was added at the front of that method signature. So with multi-nic added in, does the command need to be updated, or should that Label component be pushed back in the positional list of arguments? -joe ___ 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] Multi-nic support question
To answer my own question on the list (Thanks Vish Trey): The command to create a network should be updated - aka: nova-manage network create private 10.0.0.0/24 1 32 additionally, the nova-manage floating create also changed, and no longer requires a hostname in there. Vish has updated his novascript (https://github.com/vishvananda/novascript/commit/d36f5775b2d8d6d736294cb866937bd9ccfd0d33) with the relevant changes. (as I write this, the cloudbuilders nova.sh script hasn't been updated - so it needs those little tweaks if you're using it with trunk) -joe On Jul 6, 2011, at 12:06 PM, Joseph Heck wrote: Afternoon! I ran into an issue with the multi-nic addition that just hit trunk - wanted to see how best to resolve or if this is a bug. The signature for the create() method in NetworkCommands (in nova/bin/nova-manage) changed - which means that the existing docs to create a network: nova-manage network create 10.0.0.0/24 1 32 Fails with an index out of range error. The reason is that the arguments ['10.0.0.0/24', '1', '32'] no longer match up as expected with the arguments in create(). Label=None was added at the front of that method signature. So with multi-nic added in, does the command need to be updated, or should that Label component be pushed back in the positional list of arguments? -joe ___ 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] XML and JSON for API's
I beg to differ on the value of XML to enterprise customers - My perception is that validation of the data structure and valid values is important, but that doesn't mean it needs to be XML. The same can be done with JSON (although there's not the fancy validators set up for that), and JSON is establishing itself as a very common mechanism that's quick and easy to use. The complaint with API's - XML or JSON - from people working in enterprises and using them (speaking as one) is that the data structures aren't well known/documented and available to be understood. JSON data structures tend to be simpler (I know - I'm making a hasty generalization) and *simpler* wins the day for me. If you argued XML output to match with pre-existing tools, I'd buy that. Not for enterprise customers will be happier with it. -joe On Jun 2, 2011, at 11:20 AM, Jorge Williams wrote: I think we would lose some of the benefits of REST if we were to support a single format. My experience is that we have two communities of customers some of which prefer XML and others prefer JSON and we should be able to serve both communities. Amazon handles the same problem by supporting two kinds of APIs SOAP and Query -- REST allows us the capability to serve customers with a single API. XML offers a lot of benefits in terms of validation, transformation, and tooling that's important for enterprise customers -- JSON makes sense in other contexts particularly web development. I feel all core apis should support both. -jOrGe W. On Jun 2, 2011, at 12:54 PM, Rick Clark wrote: Hi All, Is it required for new openstack API's to support both JSON and XML, or would it be acceptable to only support JSON? Cheers, Rick ___ 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
