openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

> How would this work if someone didn't run  a volume service or glance?
> Should the api listen for that?
>
>
My expectation is that if someone didn't run a volume service, we should
expose that just as if there were insufficient resources (because that's not
far from the case.)  We'd return an error like "no resources to satisfy your
request".  That way there's only one code path for quota exhausted / zero
quota / no volume service / all disks full / no 'HIPAA compliant' or
'earthquake proof' volumes available when a user requests that.

For glance, I don't know - how is it even possible to boot an instance
without an image?

  We shouldn't be relying on extensions for Cactus.  In fact, I'd rather
> leave out extensions until we have a solid use case.  You may be saying that
> volumes will be our test-use case, but I think that will yield a sub-optimal
> API.
>
>
>  I see extensions doing a few things. First, it gives a way for other
> developers to work on and promote additions to the api without fighting to
> get them into core at first.
>
>
While I agree that's a good goal, I don't think we should rely on it for our
core services, because it will give a sub-optimal experience.  I also think
that this extension element may well be worse than simply having separate
APIs.  Right now I think we're designing in a vacuum, as you say.

Can you explain how it would yield a sub-optimal api?
>
> It would yield a sub-optimal API precisely because the process of fighting
to get things into core makes them better.  If you don't believe that, then
we should shut down the mailing list and develop closed-source.

A less meta reasoning would be that when we design two things together,
we're able to ensure they work together.  The screw and the screwdriver
didn't evolve independently.  If we're designing them together, we shouldn't
complicate things by use of extensions.


>  I don't think that anyone is proposing that a volume API be entirely
> defined as an extension to OpenStack compute. The volume extension servers
> simply as an example and it  covers the case for mounting and un-mounting  a
> volume.  If we can figure out a way of doing this in a general way we can
> always promote the functionality to the core.
>


> I don't disagree that there should be core apis for each service, but that
> in the long run, there may not be a single api. Glance already doesn't have
> an api in the openstack 1.1 spec. What about Swift?
>

OK - so it sounds like volumes are going to be in the core API (?) - good.
 Let's get that into the API spec.  It also sounds like extensions (swift /
glance?) are not going to be in the same API long-term.  So why do we have
the extensions mechanism?

Until we have an implemented use case (i.e. a patch) that uses the
extensions element, I don't see how we can spec it out or approve it.  So if
you want it in v1.1, we better find a team that wants to use it and write
code.  If there is such a patch, I stand corrected and let's get it reviewed
and merged.

I would actually expect that the majority of the use cases that we want in
the API but don't _want_ to go through core would be more simply addressed
by well-known metadata (e.g. RAID-5, multi-continent replication, HPC,
HIPAA).



In general, I like the organic model with promotion of useful extensions
into core.  I'm 100% opposed to extensions being used for our initial
functionality.  I'm also very concerned by the idea that we think we can
radically change these APIs.  If we're talking about spinning images out
into a separate API in future, or moving volumes into the core, that would
be a major revision, because we'd break clients beyond simply requiring them
to tolerate additional elements.  Versioning helps here, but note that AWS
has _never_ deprecated a call afaik.  Versioning is a purely linear
evolution, and so if I want a new feature, that means I have to use the
refactored APIs?  It sounds like we're designing the OpenStack API v0.1,
otherwise we're going to have some very angry developers here.

One way to mitigate this is to create C, PHP, Python, Ruby and Java wrappers
as part of OpenStack, and make _that_ the stable API for now.  The wrappers
would have to hide any API changes, and thus we're not externalizing the
pain of API changes.  I think we desperately need this anyway (well, at
least one language binding) to support simple integration testing.

Justin