> 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
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
