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 sy
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: https://launchp
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 acc
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 an
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 hypervisor
or cloud platform to inject a password cre
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
> hype
Brian Waldon wrote:
> Currently, the Openstack API includes a Versions WSGI application. The
> intended purpose is to detail all versions of the API that are reachable
> by a client. Currently, it only supports "v1.0." As we move towards the
> Cactus release, we need to add support for the new "v1.
On Mar 3, 2011, at 8:40 AM, George Reese wrote:
> Any mechanism that requires an agent or requires any ability of the
> hypervisor or cloud platform to inject a password creates trust issues. In
> particular, the hypervisor and platform should avoid operations that reach
> into the guest. The g
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
administrato
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
Part of the API specification says that the OpenStack API supports gzip
compression in requests and responses. I have an extremely simple WSGI
middleware implementation of this finished, but it does not support streaming
which could potentially be non-performant for large responses.
Keep in min
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 li
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
wa
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
Just for reference, our current Rackspace commitment is to support current API
and one version back. Anything older will be marked as depricated and we do not
commit that it will work. By the way, this is merely a goal at this point since
there is only one version. However, we are trying to live
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
Brian Waldon wrote:
> 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?
I have no idea what would
I agree with Greg here. Signatures complicate life for our clients, they are
not browser friendly, and I'm not really convinced that we need them. If we are
going to have a default (and I think that we should) it should be dead simple
to integrate with. I would vote for basic auth with http
> 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
Yum repo for RHEL6 was updated. http://yum.griddynamics.net/
Grid Dynamics team also decided to create an OpenStack-cent
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 serial
The hypervisor can set your VM's memory or disk contents to anything it likes,
set your registers to anything it likes, read all of memory, disk, and network,
or even redirect you to a malicious TPM. If you are going to execute code on a
VM in the cloud, then you _have_ to trust the service pro
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 w
On 03/03/2011 12:40 PM, George Reese wrote:
> So why don't we give the provider root access to our machines?
>
to be fair, a provider owns the hypervisor and storage, I would always
assume providers have root equivalent access if they want it.
> Because there's a line between what is our respons
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
Agents aren't compulsory. If you don't like them, turn them off. It's totally
within your power to do so. Just don't go complaining to your service provider
when they can't reset your root password for you.
You could even replace the agent with one of your own that performed some
functions b
> -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 giv
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 ser
On Tue, Mar 1, 2011 at 7:46 PM, Monsyne Dragon 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. You
> would be '
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 ot
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
hop
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
Hi Mike,
On Thu, Mar 03, 2011 at 12:33:11PM -0800, Michael Mayo wrote:
>Here are my thoughts, as a client developer:
>1. Hit auth server first for token, then hit compute and storage endpoints
>2. Signed requests
>This is a little more painful from a development standpoint, but it'
I think you're overestimating the security risk in issue 3. You're bank's
website uses HTTPS. In order to launch a successful man-in-the middle attack
against it you would have to compromise the certificate authority. Basic Auth
with HTTPS against a single endpoint is pretty darn secure and
I was thinking more of a "sniff someone's traffic and perform those same
requests again" sort of attack. But then again, I'm an iPhone guy and not a
security expert :)
In the end, I'm simply advocating that we reduce the number of HTTP requests
needed to get information or get things done. Ge
On Mar 3, 2011, at 3:13 PM, Scott Moser wrote:
> The reason I piped up, and the reason I think there is some
> misunderstanding is (from Ed):
>
>> Again, you seem to have missed my point. OpenStack is *not* working on
>> this.
>
> This is an OpenStack mailing list. The original mail says:
> I agree the token round-trip may not be the best for mobile apps,
> but they can at least be cached.
This is exactly what I'm doing for our iOS app :) It still would be better if
I didn't have to do it at all, though. Even
> We're also getting something else
> with a token server though: ser
Speaking of the auth related stuff... For the multitenant bp we need to
add support for 'accounts', etc. I have a branch proposed for merge
that has that in it, plus basic admin api's for users/accounts
(projects) in nova. It also adds to the builtin auth so you can use an
account:username l
That's fine by me. If you've got reasons to keep it, and upgrade from
CloudServers 1.0 is a great one, then let's keep it.
Ewan.
> -Original Message-
> From: Eric Day [mailto:e...@oddments.org]
> Sent: 03 March 2011 19:35
> To: Ewan Mellor
> Cc: Brian Waldon; openstack@lists.launchpad.n
Updates to the OpenStack Governance Model have been made and are published
here: http://wiki.openstack.org/Governance/Model.
A blog post with additional details is here:
http://www.openstack.org/blog/2011/03/openstack-governance-update/
Comments:
John
John Purrier
(206) 930-0788 |
So I also think it is great to support multiple apis (and major versions).
Right now I am more concerned with how we should accomplish this in the code.
Does anyone have any objection to creating a different directory under nova/api
per api and major version with a common set of code shared bet
On Thu, Mar 03, 2011 at 12:03:28PM -0800, Vishvananda Ishaya wrote:
> 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 c
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
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).
>Righ
> 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 th
On Thu, Mar 03, 2011 at 02:46:13PM -0800, Michael Mayo wrote:
> >> This is true. An endpoint list is certainly necessary, but it would be
> >> great if I only needed to call that one time instead of every time an auth
> >> token expires.
> >
> > You would probably want to refresh the service li
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 simply
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 prototyp
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
ha
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,
On Thu, Mar 3, 2011 at 3:42 PM, Zed A. Shaw wrote:
> On Thu, Mar 03, 2011 at 12:03:28PM -0800, Vishvananda Ishaya wrote:
> > 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
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 wrote:
> On Thu, Mar 3, 2011 at 3:42 PM, Zed A. Shaw wrote:
>
>> On Thu, Mar 03, 2011 at 12:03:28PM -0800, Vishvananda Ishaya wrote:
>> > There have been nu
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"
docum
> 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 tha
On Mar 3, 2011, at 7:02 PM, Michael Mayo 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
>> 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 c
61 matches
Mail list logo
