So if what u are talking about is anything RPC/MQ based, then I would say those
are not internal API's.
Once a RPC/MQ mechanism is introduced they don't really become internal API's
anymore (if we are talking about the same API's, haha).
Since other stuff can be reading those messages on the
, Joshua Harlow wrote:
Re: [Openstack] Canonical AWSOME So if what u are talking about is anything
RPC/MQ based, then I would say those are not internal API’s.
Once a RPC/MQ mechanism is introduced they don’t really become internal API’s
anymore (if we are talking about the same API’s, haha
23. apr. 2012 17.15 skrev Justin Santa Barbara jus...@fathomdb.com:
What's the advantage of replacing the native EC2 compatibility layer with
AWSOME from a user / operator point of view?
Although I wasn't able to attend the design summit session, right now we
have two native APIs, which means
On Tue, 2012-04-24 at 13:26 +0200, Soren Hansen wrote:
23. apr. 2012 17.15 skrev Justin Santa Barbara jus...@fathomdb.com:
With one native API, we can focus all our energies on making sure that API
works. Then, knowing that the native API works, we can build other APIs on
top through
If EC2 API is limiting what we can do, that's not going to change just
because you move the EC2 API implementation into a proxy in front of the
OpenStack API. The only difference is that it's suddenly the AWSOME
development team's problem.
I think it's actually the EC2 API caller's problem.
Actually, I think JSON schema for our message-bus messages might be a really
good idea (tm). Violations could just be warnings until we get things locked
down... maybe I should propose a blueprint? (Although I have enough of a
blueprint backlog as it is...)
Actually, I think JSON schema for our message-bus messages might be a really
good idea (tm). Violations could just be warnings until we get things locked
down... maybe I should propose a blueprint? (Although I have enough of a
blueprint backlog as it is...)
This was discussed at the
On 04/24/2012 11:39 AM, Eric Windisch wrote:
Actually, I think JSON schema for our message-bus messages might be a
really good idea (tm). Violations could just be warnings until we get
things locked down... maybe I should propose a blueprint? (Although I
have enough of a blueprint backlog as
Thanks for the pointer. I found the etherpad:
http://etherpad.openstack.org/VersioningNovaRPCAPIs
Is there a blueprint that came / is coming out of that?
I think the data representation is orthogonal e.g. in theory, we could even
use XML schemas:
PyDict -- XML -- XML Schema Validation -- Warn /
I'm more in favor of just having a schema, I don't care if that compiles to
protocol buffers, json, NEWAWESOMEhipsterMSGFORMAT.
That schema will force people to think a little more when they add messages,
and it will automatically document the messages that are being sent around.
That's a big
The change was just to the fake rpc backend to help catch more errors in
unit tests where non-primitive types are getting passed into rpc.
My current code should still work, but the tests seem to have eliminated the
more generic exception handling case with the assumption that testing
On 04/24/2012 01:25 PM, Joshua Harlow wrote:
I’m more in favor of just having a schema, I don’t care if that compiles
to protocol buffers, json, NEWAWESOMEhipsterMSGFORMAT.
That schema will force people to think a little more when they add
messages, and it will automatically document the
Philipp Wollermann wrote:
What's the advantage of replacing the native EC2 compatibility layer with
AWSOME from a user / operator point of view?
One thing that was mentioned is that the proxy could be run on top of a
public cloud that chose to only deploy OpenStack API support.
--
Thierry
On Mon, Apr 23, 2012 at 8:39 AM, Thierry Carrez thie...@openstack.orgwrote:
Philipp Wollermann wrote:
What's the advantage of replacing the native EC2 compatibility layer
with AWSOME from a user / operator point of view?
One thing that was mentioned is that the proxy could be run on top of
On 04/23/2012 02:39 PM, Thierry Carrez wrote:
Philipp Wollermann wrote:
What's the advantage of replacing the native EC2 compatibility layer with
AWSOME from a user / operator point of view?
One thing that was mentioned is that the proxy could be run on top of a
public cloud that chose to
What's the advantage of replacing the native EC2 compatibility layer with
AWSOME from a user / operator point of view?
Although I wasn't able to attend the design summit session, right now we
have two native APIs, which means we have two paths into the system.
That is poor software
We just have to be careful here to make sure that lots and lots of tests are
done to ensure that the EC2 response is valid as well as to ensure the
performance is not de-graded by having this proxy layer. If it does get
de-graded then there needs to be some work done to ensure that this does
Creating a contract on the private API will allow the external APIs to be
created and tested without needing a translation layer, even if contributory
APIs were developed outside of the project (such as in AWSOME).
It is clearly better, architecturally, if the EC2/OCCI apis can access the
On 04/23/2012 10:42 AM, Doug Hellmann wrote:
On Mon, Apr 23, 2012 at 8:39 AM, Thierry Carrez thie...@openstack.org
mailto:thie...@openstack.org wrote:
Philipp Wollermann wrote:
What's the advantage of replacing the native EC2 compatibility
layer with AWSOME from a user /
Martin Packman mentioned that there are some other groups interested in
creating a separate AWS validation test suite, and that AWSOME would
probably be using that. I think Joshua Harlow from Yahoo! was working in
that area, too.
On Mon, Apr 23, 2012 at 1:38 PM, Joshua Harlow
Ya, we should figure out how to organize to make this happen.
It seems to provide many benefits (not just for openstack).
Maybe setup a little working group around this...
On 4/23/12 12:01 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote:
Martin Packman mentioned that there are some other
On Monday, April 23, 2012 at 3:42 PM, Justin Santa Barbara wrote:
I didn't realize people were willing to do so.
Ah yes, well, that problem might still remain. There are certainly seem to be
volunteers to work on the versioning code, but defining, tagging, and adhering
to API contracts
How are REST endpoints not reliable or scalable ;-)
I'd like to know, seeing as the web is built on them :-)
It is clearly better to access the internal API's if performance is an issue,
from an abstraction point of view if the EC2 apis are a view on top of the OS
apis then that seems to make
...@us.ibm.com
The more I'm around some people, the more I like my dog.
Russell Bryant rbry...@redhat.com
Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net
04/23/2012 02:16 PM
To
openstack@lists.launchpad.net
cc
Subject
Re: [Openstack] Canonical AWSOME
On 04/23/2012 10:42 AM, Doug
On Monday, April 23, 2012 at 4:00 PM, Joshua Harlow wrote:
Re: [Openstack] Canonical AWSOME How are REST endpoints not reliable or
scalable ;-)
I’d like to know, seeing as the web is built on them :-)
The resiliency of the internet is actually built on BGP. REST endpoints fall
over
+1 on this. Implementing adapter style code may also introduce additional
state maintenance within the proxy/adapter to the eventual target API and
if not at a minimum more complexity. Also care would be needed to avoid
leaky abstractions [1]. However, I don't necessarily agree that a REST
Windisch e...@cloudscaling.com,
Cc: openstack openstack@lists.launchpad.net
Date: 04/23/2012 05:43 PM
Subject:Re: [Openstack] Canonical AWSOME
Sent by:openstack-bounces+mjfork=us.ibm@lists.launchpad.net
On Mon, Apr 23, 2012 at 12:31 PM, Eric Windisch e...@cloudscaling.com
I have the same doubt as you Philipp.
By the way, some days ago I read Citrix takes cloudstack to apache,
abandons openstack [
http://www.pcworld.com/businesscenter/article/253084/citrix_takes_cloudstack_to_apache_abandons_openstack.html
]
They said that one of the reasons was that they believe
Please see:
http://etherpad.openstack.org/FolsomEC2Compatibility
Euca2ools is a a start, but there is more than meets the eye that is
missing/lacking/incorrect in the EC2 layer.
And there are many ways of solving it, but I think one of the key take-aways
from that session is that we need a
Hi,
I just saw the announcement of Canonical's AWSOME
(https://launchpad.net/awsome), providing a translation proxy from the EC2 API
to the OpenStack API.
I'm definitely not an expert regarding OpenStack, but… doesn't OpenStack
already support an EC2 compatibility API?
At least, I can use the
30 matches
Mail list logo
