No hard feelings or anything like that. :) We actually did just have a talk about the possibility of merging it in with Nova (or perhaps combining them with other toolsets). I imagine it will hit the ML soon for further discussion once we get the kinks worked out.
On Wed, Feb 23, 2011 at 9:11 PM, Justin Santa Barbara <jus...@fathomdb.com>wrote: > Hi Josh - I didn't think your Python API bindings were in particularly > widespread use yet because they were so new. But I'm a big fan and love how > they are moving so quickly. I think I hit some bugs in them one day and > then when I pulled the next day you'd fixed them all. Perhaps there was > some meiosis in my estimate of the auth-change impact ;-) ... no offence > intended towards your work on the bindings. > > I'd love to see your project as part of nova, so that we can use it as our > reference implementation of the OpenStack API and keep an official binding > in lock-step with developments to the API. Any chance of that happening? > > Justin > > > > On Wed, Feb 23, 2011 at 6:54 PM, Josh Kearney <j...@jk0.org> wrote: > >> Two people may have come into the channel and brought it to our attention >> today, but this was a very recent change. I can assure you there are many >> more OS API consumers out there already. It's likely that most just haven't >> pulled trunk since it landed. >> >> I think we all agree that a decision on a standard needs to be made to >> avoid further pain down the road, even if it's just between us devs. >> >> >> On Wed, Feb 23, 2011 at 8:38 PM, Justin Santa Barbara < >> jus...@fathomdb.com> wrote: >> >>> When the authentication protocol changes, then OpenStack wrapper >>> libraries will need to change - good point. So there's even less reason to >>> treat OpenStack as if it were a stable API. >>> >>> However, we can't expect people using those libraries to change their >>> credentials - there was enough kicking and screaming when two people had to >>> do that today; when it's 200 including automated systems on big server >>> farms, it'll be really painful. So I think we should standardize on one set >>> of credentials across EC2 and OpenStack asap (or decide that having >>> differing sets of credentials based on the API is in fact what we want to >>> do) >>> >>> Justin >>> >>> >>> >>> >>> >>> On Wed, Feb 23, 2011 at 6:19 PM, Vishvananda Ishaya < >>> vishvana...@gmail.com> wrote: >>> >>>> Hey Justin, >>>> >>>> Does it make any difference that the way the auth is (theoretically) >>>> supposed to work with the os api is that the user gets an auth token from >>>> an >>>> external auth server and then uses username / authtoken to actually contact >>>> the api? I think it is just faked out right now to use the access_key >>>> instead of doing external auth, but I think the reason it works like it >>>> does >>>> is because the plan was to switch to external auth eventually. >>>> >>>> Vish >>>> >>>> On Feb 23, 2011, at 5:56 PM, Justin Santa Barbara wrote: >>>> >>>> I previously fixed OpenStack authentication so it would use the same >>>> credentials as EC2. This bugfix was just reverted, because it caused >>>> OpenStack API users to have to enter in different credentials (sorry!), but >>>> primarily because it hadn't been discussed on the mailing list. So here >>>> goes! >>>> >>>> Here's a blueprint: >>>> https://blueprints.launchpad.net/nova/+spec/authentication-consistency >>>> >>>> Here's an overview of the problem: >>>> >>>> EC2 uses an (api_key, api_secret) pair. Post-revert, OpenStack uses the >>>> api_key(!) as the password, but a different value entirely as the username: >>>> (username, api_key). The bugfix made it so that both APIs used the EC2 >>>> credentials (api_key, api_secret) . This did mean that anyone that had >>>> saved the 'bad' OpenStack credentials was unable to continue to use those >>>> credentials. I also overlooked exporting the updated credentials in novarc >>>> (though a merge request was pending). >>>> >>>> I actually thought originally that this was a straight-up bug, rather >>>> than a design 'decision', so I should definitely have flagged it better. >>>> Again, sorry to those I impacted. >>>> >>>> As things stand now, post-revert, this is probably a security flaw, >>>> because the EC2 API does not treat the api_key as a secret. The EC2 API >>>> can >>>> (relatively) safely be run over non-SSL, because it uses signatures instead >>>> of passing the shared secret directly. >>>> >>>> This is also not very user-friendly. Post-revert, an end-user must know >>>> whether any particular cloud tool uses the EC2 API or the OpenStack API, so >>>> that they can enter in the correct pair of credentials. That doesn't seem >>>> like a good idea; I think there should be one set of credentials. >>>> >>>> There is some discussion about the idea of having the api_key be >>>> user-friendly. I don't think it buys us anything, because the api_secret >>>> is >>>> still going to be un-friendly, but I have no objection as long as it is >>>> does >>>> in a way that does not break existing users of the EC2 API. >>>> >>>> I propose that: >>>> (1) the OpenStack API and EC2 credentials should be the same as each >>>> other (whatever they are) for the sake of our collective sanity and >>>> (2) we have to change the current configuration anyway for security >>>> reasons. >>>> (3) We should not change the EC2 credentials, because we've shipped the >>>> EC2 API and our users have an expectation that we won't break them without >>>> good reason, so >>>> (4) we must change the credentials for users of the (non-shipped) >>>> OpenStack API. >>>> >>>> Estimated user impact: I believe there are two people that will be >>>> affected, and it will take them ~1 minute each, so total impact ~2 minutes. >>>> >>>> The longer we delay fixing this, the more people we break and the bigger >>>> the impact. It seems that we have no choice but to do a >>>> non-backwards-compatible authentication change, but I believe this is OK at >>>> the moment because the OpenStack API is not yet stable/released - i.e. we >>>> can still make fixes without worrying about backwards compatibility shims. >>>> We're not in "The Old New Thing" land yet :-) >>>> >>>> >>>> >>>> As an aside, I am very unhappy about the way this revert was pushed >>>> through by Rackspace team-members, seemingly without much consideration of >>>> alternatives. Perhaps we should consider changing from needing two >>>> core-approves, to needing one Rackspace core-approve and one non-Rackspace >>>> core-approve. >>>> >>>> >>>> Justin >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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
