Open Stack

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
<justin at 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 <josh at 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 <
>> justin at 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 <
>>> vishvananda at 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 at lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110223/2852529d/attachment.html>