Hi Muriel,
On Tue, Feb 15, 2011 at 10:04:20AM +0100, Muriel wrote:
i'm completely new to openstack but i started working on something
similar to eucalyptus. In the coming months we will begin a project
to bring our work on openstack and share it with you.
Cool, looking forward to it!
The
On Feb 15, 2011, at 12:55 PM, Eric Day wrote:
I think there is plenty of material on the mailing list/blogs/... to
create a great talk from if you want to keep it focused on twisted
vs eventlet vs other options for highly scalable systems (both in
a technical and social way).
What
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
On Feb 15, 2011, at 1:06 PM, Justin Santa Barbara wrote:
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
On Mon, 2011-02-14 at 09:51 -0800, Eric Day wrote:
There are possible solutions to build an AMQP based service,
but AMQP brings complexity and a protocol not optimized for high
latency and intermittent connectivity.
Regardless of whether the system uses AMQP, I am a fan of AMQP's
flexible
On Feb 15, 2011, at 1:06 PM, Justin Santa Barbara wrote:
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
Hi Erik,
Thanks for your comments.
There doesn't seem to be a consensus to use core API + extensions vs.
multiple APIs?
Anyway, I don't see any issues with specifying a core API for network
services, and a core API for network agents, corresponding exactly to
NTT's Ishii-san's generic APIs, and
Ishii-san,
Re-reading the proposal you sent on Feb. 2nd, I realized that you didn't
separate between generic operations and plugin-specific operations. I
thought you did, sorry. I propose to rewrite your spec into one API and two
(optional) extensions:
- network service API (plugin-agnostic):
Hisaharu-san, Romain and Eric
Thank you for your reply. I try to refer the doc Eric has given us.
Initially, there would be some ways to define a set of generic APIs.
My idea is to make categories to have an overviews. Each category,
for example, would be linked a use case in the blue print.
9 matches
Mail list logo
