Hi All,
I was looking at the multi-nic blueprint(
https://blueprints.launchpad.net/nova/+spec/nova-multi-nic), and in
particular:
1) removing mac_address column from the instances table and creating a
mac_addresses table. This is for storing which instances own which mac
addresses as well as
Hi everyone,
We have had quite a few branches that filed for feature freeze
exceptions, and the following have been granted an exception for late
merging until Tuesday EOD, so they need your attention:
https://code.launchpad.net/~blamar/nova/openstack-api-1-1-images/+merge/53942
I personally think that having an external Identity Management solution is
the best option. In my mind there are vare valuable benefits for having a
highly scalable, enterprise class, identity management solution on OpenStack
such as (1) Separation of concerns of Authentication and Authorization
Agree that this is a tricky technical issue, and I agree that the issue of
management of Authn and Authz should be external to Nova and all other
OpenStack components.
I believe there are two fundamental problems to be solved and that we will
confuse ourselves if we try to mix them together:
Hi Thierry, in addition to the technical sessions for Nova, Swift, and
Glance at the design summit, I have asked Stephen to add Project and
Release management. You will own the time slots, once the PTL's are on
board we will discuss how best to schedule the sessions.
Thanks,
John
-Original
On Mon, Mar 28, 2011 at 5:48 AM, Thierry Carrez thie...@openstack.org wrote:
I'd like to say that I dislike this type of behind closed doors
development, where things are developed without a blueprint, bug or
linked branch and then thrown very late into the review queue.
We do an open source
Agreed, Pluggable option 2 with a default OAuth implementation seems like the
best strategy.
Vish
On Mar 28, 2011, at 9:42 AM, Khaled Hussein wrote:
I was thinking of having OAuth implementation for authorization/delegation in
an external identity management solution, option 2 :). The IdM
No objection to a discussion during the summit, but I've been able to watch
all of these branches and others evolve here:
https://code.launchpad.net/nova
For example, when I wanted to add VNC support because my system wouldn't
boot, it was easy for me to look at the vnc_console branch and get the
On Mon, Mar 28, 2011 at 1:38 PM, Justin Santa Barbara
jus...@fathomdb.com wrote:
No objection to a discussion during the summit, but I've been able to watch
all of these branches and others evolve here:
https://code.launchpad.net/nova
For example, when I wanted to add VNC support because my
The problem we've been having revolves around the fact that we have
dozens of developers working on Nova, with no real guidance as to the
long-term direction of the project, and teams just doing whatever the
heck they want to, without ML discussion and blueprints, and then
expecting people to
Rubbish. Open development means knowing the general directions and
specifications that people are working on by open discussions, open
blueprints/specs, and active communication between teams. I can go to
github and see how many people forked this (ugh.). That doesn't give
me any clue as to
Open == Accessible. Open != Verbose. I'm willing to discuss more at
the design summit, but my biggest concern is that we let the most
people possible can contribute. This includes those who work behind
closed doors on their own pet projects.
This thread started specifically in response to a
On Mon, Mar 28, 2011 at 2:32 PM, Todd Willey t...@ansolabs.com wrote:
Open == Accessible. Open != Verbose. I'm willing to discuss more at
the design summit, but my biggest concern is that we let the most
people possible can contribute. This includes those who work behind
closed doors on
2011/3/28 Thierry Carrez thie...@openstack.org:
I'd like to say that I dislike this type of behind closed doors
development, where things are developed without a blueprint, bug or
linked branch and then thrown very late into the review queue.
I'd appreciate a discussion about this at the
one last note for completeness:
http://etherpad.openstack.org/r7eSWs0b8k
http://etherpad.openstack.org/r7eSWs0b8k
Thanks Vish ... that's what I was looking for.
For others:
https://code.launchpad.net/~anso/nova/authn_and_authz/+merge/52119
Blueprints serve three purposes. I don't claim they do them well, or
that we are using them well
1) they help us schedule technical discussions at the summit. We could
obviously do it some other way, but that is on of the current uses.
2) They let the various dev groups know what is being
There's prior art to OAuth from the cmdline. Anything that interacts with
Launchpad's API does it. See e.g. bzr lp-propose-merge.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe :
-Original Message-
From: Todd Willey
Sent: 28 March 2011 21:11
To: Jay Pipes
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Feature Freeze status
[Snip]
Clearly blueprints are about process and not about code. Merge
proposals are a hybrid of code and process.
+1
From: Ewan Mellor [ewan.mel...@eu.citrix.com]
Blueprints should be regarded in the same way as docstrings. Sure, you can
write the code faster without docstrings, and the code will work just as
well, but it will take everyone else twice as long
On Mon, Mar 28, 2011 at 7:42 PM, Ewan Mellor ewan.mel...@eu.citrix.com wrote:
-Original Message-
From: Todd Willey
Sent: 28 March 2011 21:11
To: Jay Pipes
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Feature Freeze status
[Snip]
Clearly blueprints are about process
20 matches
Mail list logo
