Glen Campbell wrote:
There's been some discussion of an admin/management API and what
functions would be provided there. I've been tasked with handling the
technical coordination of implementing Nova at Rackspace, and have thus
been identifying gaps between functionality that our current
Devin Carlen wrote:
added a few inline
Sounds like we need... a wikipage !
Please see, edit, augment, comment on:
http://wiki.openstack.org/OpenStackAPIGapAnalysis
--
Thierry Carrez (ttx)
Release Manager, OpenStack
___
Mailing list:
On Mar 2, 2011, at 11:41 PM, Mark Washenberger wrote:
To your main point, I share your desire to be able to turn off password
injection during instance creation. (For clarity, I'm assuming that your
preference is to create the vm with no root password and only ssh keys as a
means of
Hello everyone,
A new release of OpenStack Compute (Nova) Bexar is now available. It
consists of the following deliverables:
Nova 2011.1.1: https://launchpad.net/nova/bexar/2011.1.1
This point release was needed to fix an issue with the original 2011.1
tarball, where some files were missing and
On Thu, 3 Mar 2011, George Reese wrote:
Of all the boostrapping mechanisms I have encountered, the AWS model
still remains the best. Specifically, with the guest OS pulling the keys
from a trusted platform source.
Any mechanism that requires an agent or requires any ability of the
I don't agree with this approach.
The current Cloud Servers approach is flawed. I wrote about this a year ago:
http://broadcast.oreilly.com/2010/02/the-sacred-barrier.html
It's a mistake to send OpenStack pursuing a flaw in Cloud Servers.
-George
On Mar 3, 2011, at 9:32 AM, Ed Leafe wrote:
I believe they are complementary; Sandy's is an architectural change that
lets OpenStack users choose which API functions are restricted to admins
only; my proposal is for a set of administrative functions (really just
API extensions, since they could be deployed as a public API if the
On Mar 2, 2011, at 8:30 PM, Jesse Andrews wrote:
I would prefer a signature based approach as the default (as signatures
limits replay attacks; tokens allow an eavesdropper to make arbitrary
requests if they obtain a token).
On the other hand, signatures make simple things difficult, such
George Reese wrote:
It's a mistake to send OpenStack pursuing a flaw in Cloud Servers.
As much as I agree with Scott and you, I fail to see why OpenStack
cannot support both ways and let the deployer choose ?
--
Thierry Carrez (ttx)
Release Manager, OpenStack
On Mar 3, 2011, at 10:36 AM, George Reese wrote:
I don't agree with this approach.
The current Cloud Servers approach is flawed. I wrote about this a year ago:
http://broadcast.oreilly.com/2010/02/the-sacred-barrier.html
FWIW, I agree with what you're saying. Please understand,
Raphael,
Could you tell us more about StormMQ? What do you do, how much of your
software is open-source, how might it fit into the OpenStack ecosystem (both
from open-source and proprietary points-of-view)?
I admit to my shame that I know nothing about your company, but it certainly
sounds
maybe I'm missing something, but if you don't want to run a recent API why
should you expect to be able to run it with a recent release of nova? I
think trying to support older and new versions at the same time would clip
our wings, or at the very least add some nastiness to the code. If someone
I could use some more clarification on what you would like to see. What do you
mean by recent versions? How long should a minor version of the OS API be
supported in future releases? Should we even expose minor versions as separate
endpoints?
Personally, I do not feel it necessary to expose
Trey Morris wrote:
maybe I'm missing something, but if you don't want to run a recent API
why should you expect to be able to run it with a recent release of
nova? I think trying to support older and new versions at the same time
would clip our wings, or at the very least add some nastiness to
We should support old versions. The API layers should be a very thin
layer over what the Nova internal API provides, so even if we have
v1.0, v1.1, etc. subdirectories in the API and do full code copying,
it should be a fairly minimal mapping. We can of course share as
much common code (like
So why don't we give the provider root access to our machines?
Because there's a line between what is our responsibility and what is that of
the provider. Agents need to be invited elements, not required elements.
-George
On Mar 3, 2011, at 12:36 PM, Ewan Mellor wrote:
The hypervisor can set
I agree with you in general, Eric.
For this particular transition (API 1.0 to 1.1) are there any important client
tools that would break? I don't imagine that there are many people who've
written against Bexar and wouldn't be able to redo their stuff against Cactus,
so the question is really
Let me put this another way.
You have an option of two methods: one more intrusive and one less intrusive.
The more intrusive approach gives the owner of the guest less control and is
less transparent. The less intrusive approach gives the guest owner more
control and is more transparent.
Why
-Original Message-
From: George Reese [mailto:george.re...@enstratus.com]
You have an option of two methods: one more intrusive and one less
intrusive. The more intrusive approach gives the owner of the guest
less control and is less transparent. The less intrusive approach gives
If we are supporting ec2, we should support CloudServers 1.0 since
there are tools for that. Rackspace needs to do it for their upgrade
path, why not keep in in Nova trunk so others can use? It will be
legacy just like the ec2 interface, but I see no harm in keeping
it there.
If the underlying
On Tue, Mar 1, 2011 at 7:46 PM, Monsyne Dragon mdra...@rackspace.com wrote:
On 3/1/11 6:32 PM, Justin Santa Barbara wrote:
2) Preclude us from having e.g. multi-project queries (show me all my
servers in projects A and B)?
It doesn't really preclude multi-account queries, if they are needed.
There have been numerous mailing list discussions about common auth methods. I
feel like we end up devolving into theoretical discussions at some point, and I
find it hard to evaluate different approaches without example code. Termie,
Jesse, Paul Voccio, and I had a discussion in person the
On Thu, 3 Mar 2011, Ed Leafe wrote:
On Mar 3, 2011, at 10:36 AM, George Reese wrote:
It's a mistake to send OpenStack pursuing a flaw in Cloud Servers.
Boy...
Isn't this a rat hole that I've helped us go down.
I am completely pro-agent (well, more agnostic). I would certainly
hope
Here are my thoughts, as a client developer:
1. Hit auth server first for token, then hit compute and storage endpoints
This is fairly simple, but there are a couple of problems with it:
a. It's not very curl or browser friendly (you have to curl the auth server
first and copy the token, which
Sounds good to me. Share as much as we can, but also keep the code
readable. We'll deal with specifics once the code is proposed for
merge.
-Eric
On Thu, Mar 03, 2011 at 04:33:22PM -0500, Brian Waldon wrote:
So I also think it is great to support multiple apis (and major versions).
Right
On Thu, Mar 03, 2011 at 01:23:07PM -0800, Michael Mayo wrote:
We're also getting something else
with a token server though: service discovery (via service URL headers
returned with token). This can be important for auto-configuring apps
since you can simply enter a auth URL and the app will
On 3/3/11 4:46 PM, Michael Mayo wrote:
On Thu, Mar 03, 2011 at 01:23:07PM -0800, Michael Mayo wrote:
We're also getting something else
with a token server though: service discovery (via service URL headers
returned with token). This can be important for auto-configuring apps
since you can
On Thu, Mar 03, 2011 at 12:03:28PM -0800, Vishvananda Ishaya wrote:
Rationale: Openstack components need a common solution for Authentication
(authn) and Authorization (authz). Mailing list discussions tend to devolve
into hypotheticals, so we decided to put together a proposal and prototype,
The problem with this logic is that you are optimizing wrong. In a token
based auth system, the tokens are valid generally for a period of time (24
hours normally with Rackspace auth), and it is a best practice to cache
this. Saying that you are reducing HTTP requests for 1 request that has to
Taking this from the MP to ML for wider audience.
On Thu, Mar 03, 2011 at 11:29:43PM -, Monsyne Dragon wrote:
Actually, the OpenStack API only defines compute methods, it punts on
auth currently (as it should). There is no definitive OpenStack Auth
document or service right now, which
Oh, the merge proposal is at
https://code.launchpad.net/~anso/nova/authn_and_authz/+merge/52119
On Thu, Mar 3, 2011 at 6:04 PM, Andy Smith andys...@gmail.com wrote:
On Thu, Mar 3, 2011 at 3:42 PM, Zed A. Shaw zeds...@zedshaw.com wrote:
On Thu, Mar 03, 2011 at 12:03:28PM -0800, Vishvananda
On Mar 3, 2011, at 5:45 PM, Chuck Thier wrote:
The problem with this logic is that you are optimizing wrong. In a token
based auth system, the tokens are valid generally for a period of time (24
hours normally with Rackspace auth), and it is a best practice to cache this.
Saying that
This is assuming that the endpoint url does not change, and is going to be
the same for all users. It could be that the, say swift url, that you get is
not the same as what someone else gets, based on their account, service
level, or even current IP (for directing folks to the 'nearest'
On 3/3/11 5:51 PM, Eric Day wrote:
Taking this from the MP to ML for wider audience.
On Thu, Mar 03, 2011 at 11:29:43PM -, Monsyne Dragon wrote:
Actually, the OpenStack API only defines compute methods, it punts on
auth currently (as it should). There is no definitive OpenStack Auth
The problem with this logic is that you are optimizing wrong. In a token
based auth system, the tokens are valid generally for a period of time (24
hours normally with Rackspace auth), and it is a best practice to cache this.
Saying that you are reducing HTTP requests for 1 request that
It depends. If you're in a busy area of a big city with 1 bar of EDGE
coverage on your phone, latency becomes your biggest connectivity issue. So
if you're only doing something with the API every 24 hours, auth could
reasonably be close to 50% of the time you stare in frustration cursing
36 matches
Mail list logo
