Re: [Openstack] OpenStack Identity: Keystone API Proposal

[andi abes]

Ziad, thanks the quick edits.

One more quick question, mostly because I haven't followed the full keystone
discussions. How does this API relate (if at all) to:
http://wiki.openstack.org/FederatedAuthZwithZones

Specifically, around resource groups and federated authentication.

tia,
a.

On Sat, Jun 11, 2011 at 11:40 AM, Ziad Sawalha
wrote:

>  I've updated the dev guide with your suggestions:
> - Section 4.4 explains the GET /tenants call needs to be authenticated and
> the examples now show passing in the authentication header.
> - Section 5.2.1 is new and talks about authenticating for the Admin API and
> puts in a reference for bootstrapping the system (creating a first
> administrator). Here, I've left it as a reference to the admin guide which
> is yet to be developed (jaypipes volunteered to help us create that in RST),
> but I also refer to the readme which today has instructions for setting up
> your Keystone instance.
>
>  Let me know if that gets you going, Andi.
>
>  Regards,
> Ziad
>
>
>   From: Ziad Sawalha 
> Date: Sat, 11 Jun 2011 14:44:12 +
> To: Andiabes 
>
> Cc: "openstack@lists.launchpad.net" 
> Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
>
>   Your guess is correct. The only calls you should be able to make without
> having a token are the calls to discover the service (getting version info,
> WADL contract, dev guide, help, etc…) and to get a token. After that, all
> other calls require passing in a token.
>
>  On the Admin APIs, the token passed in must have the necessary
> administrative privileges.
>
>  To bootstrap Keystone with a blank identity store, you can execute
> bin/keystone-manage to create your initial administrative identity(ies).
>
>  If you use the sample data creation script provided, it will create an
> admin user (and create a token for that user) which you can use.
>
>  We'll clarify that in the dev guide.
>
>  Thanks Andi
>
>  Ziad
>
>   From: Andiabes 
> Date: Fri, 10 Jun 2011 21:08:18 -0400
> To: Ziad Sawalha 
> Cc: "openstack@lists.launchpad.net" 
> Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
>
>   It might be useful to include in the API guide some information about
> authentication to keystone itself. I.e when requesting a list of
> users,tenants etc the requestor should somehow authenticate itself
> I'm guessing that the flow involve acquiring a token that authenticates the
> user to keystone as a user who has privileges to manage the relevant
> entities.?
>
>  Sent from my iPad
>
> On Jun 10, 2011, at 7:24 PM, Ziad Sawalha 
> wrote:
>
>   Time flies! It's June 10th already. In my last email to this community I
> had proposed today as the day to lock down the Keystone API so we can
> finalize implementation by Diablo-D2 (June 30th).
>
>  We've been working on this feverishly over the past couple of weeks and
> have just pushed out a proposed API 
> here:
> https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf
>
>  For any and all interested, the original source and code is on Github 
> (
> https://github.com/rackspace/keystone), along with the current
> implementation of Keystone, examples, sample data, tests, instructions, and
> all the goodies we could muster to put together. The project also lives on
> Launchpad at http://launchpad.net/keystone.
>
>  The API we just put out there is still a proposal. We're going to be
> focusing on the implementation, but would still love to get community input,
> feedback, and participation.
>
>  Have a great weekend and regards to all,
>
>  Ziad
>
>
>
>
>  Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited.
> If you receive this transmission in error, please notify us immediately by 
> e-mail
> at ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>
>   ___
> Mailing list: 
> https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : 
> https://launchpad.net/~openstack
> More help   : 
> https://help.launchpad.net/ListHelp
>
>Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indica

Re: [Openstack] XML and JSON for API's

[Bryan Taylor]

On 6/12/11 12:08 AM, "Mark Nottingham"  wrote:

>> 
>> 
>> I understand where you're coming from Mark.  I'm still suffering PTSD
>>from the SOAP days.  One of the lessons leaned there was that auto
>>generated language bindings are a bad idea.  Unless you strictly control
>>the client and server implementations -- it all falls apart really
>>quickly.   That's not an XML thing, honestly, I think an auto-generated
>>JSON client would suffer from similar interoperability problems -- there
>>really needs to be a human in the loop.
>> 
>> Given that, we should be building and distributing language bindings
>>for common languages with all our APIs -- it's well worth the investment
>>in my opinion.
>
>+1, especially for the complex ones. It's not a small engineering effort,
>though (especially if some users want synchronous implementations while
>others need async, for example). I suppose that's a real driver for
>keeping the APIs as simple as possible...

This actually has some nice qualities in terms of RESTfulness, because
HATEOAS is a somewhat hard concept and clients that don't get it will
waste their time trying to figure out how to construct URIs to abuse the
RESTful API with RPC style programming. If we write the clients, this
isn't as much of a concern, assuming we get it right :-) . But if we are
struggling to encourage both XML and JSON, uniformly supporting the
language bindings the market wants (java, C#, ruby, python, php for
starters) will be much harder. I'd take a wild guess language binding
writers often prefer XML if they code static languages and JSON for
dynamic ones.

>
>> Also, I really don't see people generating language bindings for REST
>>services the way they did for SOAP.  Note that XML Schema isn't going to
>>give you a language binding in the first place because it describes data
>>types not operations -- and I don't see people using WADL in that way.
>>We use this sort of stuff, internally, for machine processable
>>documentation and validation -- and there are many benefits in both of
>>those cases.
>
>Absolutely; I think those are the sweet spots for WADL. It's also helpful
>in the API design phase, to make sure you've covered all of your bases.

I find that hand written XSDs end up being way more humane than the
generated ones. REST's resource / media type orientation helps XSD sanity
too. SOAP forced a different XSD type for every input and output message,
which would be soul crushing to write by hand. This is what pressured
everybody to auto generate as much as possible when they used SOAP, and
the bloated spew that follows is what caused XSDs to get a bad name. I
think SOAP and WSDL were the real culprits and XSD was collateral damage.
I do agree with Jorge that XSD 1.1's XPath based assertions are a big step
forward. 

As for WADL, its initial cold reception was, in my view, due to
(overblown) fears that the WSDL mindset would infect the REST world. A
server has to describe its entry points sufficiently for a client to know
what it can rely on and whatever artifact solves this is a "contract".
Handwriting it in HTML is fine, but enforcing structure standards is
really hard that way. Unlike WSDL, we can use a mixed approach and
leverage the HTTP uniform interface, standardized media types, and
standard link relations. Atom service documents and OpenSearch description
documents and WADL all do the same thing: they provide hypermedia that's
adept at reducing the number of entry points your server has to advertise.
The difference is that WADL is more generic - it describes resources of
any media type, whereas Atom's service documents are only describing end
points within Atom.

With WADL, once you get to an entry point that is already described by a
well documented media type, your contract is complete and the WADL can
omit its linked sub-resources. For example, I if I show an atom feed's
entry page, I don't need to make a URI template for its pages. So the more
I rely on media types that uses standard link relations, the simpler my
WADL will be. 

Jorge made a mini-schema for Rackspace that includes a type for Atom links
for use within XSD based media types so they can leverage semantic
linking. The rel attribute uses a restriction enumeration. We started with
the IANA link relation registry and this becomes the Rackspace link
relation registry and we could add or remove our own relations if we want.
I've started adding annotation and documentation to some of the relations
to provide richer descriptions than what IANA provides.  Their one-liners
are rather terse for real world work with such a pivotal concept.
Individual services can extend as they please too, and it's clear which is
extension and which is Rackspace standard. Just having it as documentation
is valuable, and JSON representations, by osmosis, benefit from it.





___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscrib

[Openstack] EMEA OpenStack Day

[Lauren Sell]

We're planning an OpenStack Day in London, Wednesday, July 13, and I hope you 
can attend.  

Registration and the proposed agenda can be found at 
emeaopenstackday.eventbrite.com. 

If you are interested in volunteering with the event or want to get involved in 
any way, please let me know.

Thanks,
Lauren___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp