I see, the latency of setting up bridges and vlans could be a problem.
How about the second problem, that of not having enough information to
assign the IP. Is it really necessary to know what physical node the
VM will run on before assigning the IP? Shouldn't that be decoupled?
For example, if
If we can dynamically plug (and presumably unplug) a vNIC into a
vPort, and assign the IP at that time, does that imply that we cannot
use the IP injection into the VM image? Is it fine to use DHCP or RA
in all cases?
On Wed, Feb 23, 2011 at 22:29, Ishimoto, Ryu r...@midokura.jp wrote:
Hi
I think we had this conversation before some weeks ago. From my perspective
I think networking services are normally not considered as first class
citizens of the 'Virtual Datacenter'. What Ishimoto-san describes is a
Virtual Switch. But networking services in the day-in day-out operations
include
On Feb 23, 2011, at 12:26 PM, Vishvananda Ishaya wrote:
We need some sort of supervisor to tell the network to allocate the network
before dispatching a message to compute. I see three possibilities (from
easiest to hardest):
1. Make the call in /nova/compute/api.py (this code runs on
George,
What hypervisor are you using? I'm guessing kvm, but not totally sure. I
know the behavior for XenServer is to keep the the instances available
after a reboot. Can you show some examples of what you're talking about
with versions?
Thanks,
Pvo
On 2/24/11 1:49 AM, Thierry Carrez
Hi Jay,
I couldn't agree more. I had another bug come up yesterday on another of my
patches (I know - not a good day for me!) where I again broke the OpenStack
API by requiring the metadata attribute.
In this case, it was missed by the unit tests. I believe I was always
passing metadata, so
Thanks John,
While it's nice to have a vision, we also have tactic issues that we need some
quick movement on.
Can we do something short term to keep all parties happy while continuing this
larger discussion?
-S
From: John Purrier
Sent: Thursday, February 24,
Perfect.
Objections? (naming bun-fights discouraged ;)
-S
From: John Purrier
Sent: Thursday, February 24, 2011 1:39 PM
To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark
Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net
Subject:
For copyright headers, just add a new Copyright 2011 OpenStack,
LLC. line for existing files under the old copyright line. You can add
a new license for new code for existing files, but that gets messy. For
new files, just do as we usually do for new files (copyright + license
brief). You can also
In regards to openstack tools, we certainly have some options. We
could do everything from one big package with all tools for all
languages/services to one project for each language/service (and all
permutations in between). IMHO, I think it makes the most sense to
keep the client tools for all
I would encourage using all lowercase for command line tools
(oscompute), I don't really care what the name is though. :)
-Eric
On Thu, Feb 24, 2011 at 05:42:56PM +, Sandy Walsh wrote:
Perfect.
Objections? (naming bun-fights discouraged ;)
-S
congratulations!
On Wed, Feb 23, 2011 at 2:55 AM, Soren Hansen so...@linux2go.dk wrote:
This is now done.
Den 21/02/2011 08.46 skrev Soren Hansen so...@ubuntu.com:
2011/2/19 Rick Harris rick.har...@rackspace.com:
Throwing my hat into the ring for nova-core membership. Eager to help
knock
Thanks Eric,
I agree. It would be great to do 'bzr branch lp:nova' and have all the client
tools we need. Especially given the fact that the client tools are now required
by the system itself. I suspect it will also be needed for integration testing.
This also prevents more PPA administration.
+1 to improving reviews since I agree with sandy on it being our greatest
strength. I also I prefer sandy's approach (unless I'm mistaken), jump in
and see how it goes, we can update a wiki as things proceed. I don't
understand the need for a more formal documentation of process. I'd just
hate for
+2 from me
On Wed, Feb 23, 2011 at 10:45 AM, Matt Dietz matt.di...@rackspace.comwrote:
+1 to this!
On 2/17/11 3:28 PM, Soren Hansen so...@ubuntu.com wrote:
+1! (Yup, that was +factorial(1), for those keeping score at home)
2011/2/17 Sandy Walsh sandy.wa...@rackspace.com:
I'd like to
+10 for lowercase.
On Thu, Feb 24, 2011 at 12:00 PM, Eric Day e...@oddments.org wrote:
I would encourage using all lowercase for command line tools
(oscompute), I don't really care what the name is though. :)
-Eric
On Thu, Feb 24, 2011 at 05:42:56PM +, Sandy Walsh wrote:
Perfect.
Instead of an unstable trunk, i think code should just be better vetted
before it lands in the trunk. If the difference between trunk and your
proposed unstable trunk is a set of automated tests, then those tests can
just as easily be run on a LP branch before it gets into current trunk. We
just
+1 (since it looks like i missed the list last time)
On Feb 17, 2011, at 8:25 AM, Sandy Walsh wrote:
I'd like to help out on the review process as per
http://wiki.openstack.org/Governance/Approved/CoreDevProcess
I like quiet walks in the park and black and white movies.
-Sandy
On Thu, Feb 24, 2011 at 1:49 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
Jay, I totally see your argument.
Are you proposing a more plug-in type mechanism like nova-manage/django-admin
(but uses the public API)? Or, perhaps, similar to the Citrix 'xe' umbrella?
Like the nova-manage
I see the value in having a separate CLI tool per service as:
a. Scales easily, no cross-service dependencies.
b. Expectations are clear that each service must provide an API and CLI to
drive it.
c. Interactions can be clearly targeted to a specified service (no
ambiguity).
d. These tools are
Eric Day wrote:
For copyright headers, just add a new Copyright 2011 OpenStack,
LLC. line for existing files under the old copyright line. You can add
a new license for new code for existing files, but that gets messy. For
new files, just do as we usually do for new files (copyright + license
I agree. I propose we always keep lp:nova (or lp:project) stable,
and instead create trunks like lp:nova/testing that all the
test/regression systems can be run against. This is pretty similar to
how we did things with Drizzle, a commit would bounce down the line,
finlly landing in lp:project when
On Thu, Feb 24, 2011 at 2:19 PM, John Purrier j...@openstack.org wrote:
I see the value in having a separate CLI tool per service as:
a. Scales easily, no cross-service dependencies.
I'm talking about CLI tools that access the API, not the individual services...
b. Expectations are clear
Ahh, well I would probably just add our copyright line below Jacob's
in the LICENSE file for now, and maybe ping him to add the brief
header to the old files. For new files, we can still add our standard
copyright/license header. If add files under Apache, be sure to add
LICENSE.Apache too for the
Let me know if there are any questions I didn't answer thoroughly enough.
Looks like a fun project Eric. I only got caught up on the ML this weekend and
I'm behind again already.
Some questions that I jotted down from the previous discussions were:
1. Will broadcast queues be supported?
2.
Well, my previous reply somehow isn't going through to the list... so...
here it is again:
I've got some objections so far:
1. relying on python-cloudservers is a good metric by which to judge your
compatibility with the rackspace cloud, once jacob has accepted the changes
to support changing
Perhaps I'm missing something, but I'm not sure what you mean by
one API. Each project/service will be driving their own API,
no? For example do you expect one CLI tool for swift, nova, and a
queue service?
I see John's points with allowing each service to drive their own
API/tools (hopefully
We need an unstable trunk:
I could not possibly disagree more. Trunk is about releasability and stability.
As developers we need a stable well-protected trunk so that we can actually
work successfully in parallel on our own branches. My ideal for trunk is that
when it comes time for tagging a
On Thu, Feb 24, 2011 at 3:17 PM, Mark Washenberger
mark.washenber...@rackspace.com wrote:
We need an unstable trunk:
I could not possibly disagree more. Trunk is about releasability and
stability. As developers we need a stable well-protected trunk so that we can
actually work successfully
On Thu, Feb 24, 2011 at 2:48 PM, Eric Day e...@oddments.org wrote:
Perhaps I'm missing something, but I'm not sure what you mean by
one API. Each project/service will be driving their own API,
no? For example do you expect one CLI tool for swift, nova, and a
queue service?
I see John's
Hi Sandy,
On Thu, Feb 24, 2011 at 07:42:34PM +, Sandy Walsh wrote:
Looks like a fun project Eric. I only got caught up on the ML this weekend
and I'm behind again already.
It's a never-ending battle. I find routing all messages from jaypipes
into /dev/null helps. :)
1. Will broadcast
On Thu, Feb 24, 2011 at 3:56 PM, Eric Day e...@oddments.org wrote:
Hi Sandy,
On Thu, Feb 24, 2011 at 07:42:34PM +, Sandy Walsh wrote:
Looks like a fun project Eric. I only got caught up on the ML this weekend
and I'm behind again already.
It's a never-ending battle. I find routing all
I'd definitely approve of something xe-like.
$ os vm-create
$ os user-list
$ os network-attach
That looks pretty neat to me.
Ewan.
-Original Message-
From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
This is what we're working on, and what Justin is proposing, Mark.
Basically, in Drizzle-land, people propose a merge into trunk, Hudson
picks up that proposal, pulls the brnach into lp:drizzle/staging,
builds Drizzle on all supported platforms (12 OS/distro combos), then
runs all automated
On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote:
I just don't want to end up with:
os-describe-images
os-describe-image-attribute
os-describe-instances
os-describe-groups
os-describe-zones
os-describe-keypairs
os-describe-volumes
os-describe-snapshots
The above is asinine,
Yup, this looks like the super tool that jay was talking of earlier (odd too,
since that's something I'm using accused of being)
I kind of like it as well, since it permits swift, nova and glance to have
their own client tools, but fit within the larger umbrella (and
tab-completion/hints work
Andy has listed a few things on the wiki. I'll summarize the known efforts here:
* Anso has created some Vagrant scripts that test multi-node
functionality of the EC2 API, libvirt + KVM, and nova-objectstore
* Vishy/Devin have been refactored Nova's existing smoketests/ and
updated to include
On Thu, Feb 24, 2011 at 4:10 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
Yup, this looks like the super tool that jay was talking of earlier (odd
too, since that's something I'm using accused of being)
I kind of like it as well, since it permits swift, nova and glance to have
their own
Hmm, that's a little tricky since oscompute will be contain the cmdline tool
and the client tool to the REST API (cmdline is just a shell interface over the
client). It would mean splitting things up and the setup.py would get
complicated.
To Eric's point
.../clients/python/*
On Thu, Feb 24, 2011 at 4:05 PM, Mark Washenberger
mark.washenber...@rackspace.com wrote:
This is what we're working on, and what Justin is proposing, Mark.
Basically, in Drizzle-land, people propose a merge into trunk, Hudson
picks up that proposal, pulls the brnach into lp:drizzle/staging,
I'm curious what the point of having a line of trunks for a commit to bounce
down on its way to trunk would gain us other than having to manage a line of
trunks. What's wrong with status quo branch management (other than tests)?
What's wrong with having the commit sit in its LP topic branch, which
On Thu, Feb 24, 2011 at 4:45 PM, John Purrier
john.purr...@rackspace.com wrote:
We all knew you would come around, Jay! No-one wants you to lose your mind...
Easy to do around here ;)
-jay
___
Mailing list: https://launchpad.net/~openstack
Post to
The extra branches are just an implementation detail, we can have
them or not. It's really a matter of if it's possible and/or easier
to have jenkins fire off new jobs with arbitrary branches that need
to be merged with trunk for each job vs merging and pushing to a
staging branch and have the
I see. So their use would in general be for the use of automated systems?
On Thu, Feb 24, 2011 at 4:33 PM, Eric Day e...@oddments.org wrote:
The extra branches are just an implementation detail, we can have
them or not. It's really a matter of if it's possible and/or easier
to have jenkins
++
On Thu, Feb 24, 2011 at 02:33:42PM -0800, Devin Carlen wrote:
This is a bit nitpicky but I'd rather see it called just nova, as in:
nova describe images
Who has strong opinions?
On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote:
On Thu, Feb 24, 2011 at 4:06 PM, Eric Day
Correct, no human would use them.
On Thu, Feb 24, 2011 at 5:36 PM, Trey Morris trey.mor...@rackspace.com wrote:
I see. So their use would in general be for the use of automated systems?
On Thu, Feb 24, 2011 at 4:33 PM, Eric Day e...@oddments.org wrote:
The extra branches are just an
I agree the 'os' designation is ambiguous and likely to cause some
confusion.
On 02/24/2011 04:36 PM, Eric Day wrote:
++
On Thu, Feb 24, 2011 at 02:33:42PM -0800, Devin Carlen wrote:
This is a bit nitpicky but I'd rather see it called just nova, as in:
nova describe images
Who has strong
Yup. Right now when a project-core member clicks 'Approve'
after code review, tarmac picks it up and pushes to trunk assuming
unittests pass. Instead it could push to staging and trigger a hook
in jenkins which would fire off a bunch of other jobs that run the
staging branch through a battery of
I'd also like to see it called 'nova'.
On Thu, Feb 24, 2011 at 4:41 PM, Rick Clark rick.cl...@rackspace.comwrote:
I agree the 'os' designation is ambiguous and likely to cause some
confusion.
On 02/24/2011 04:36 PM, Eric Day wrote:
++
On Thu, Feb 24, 2011 at 02:33:42PM -0800, Devin
What about an interactive shell like IOS, vyatta, python shell, irb, etc
$ novashell
novashell show instances
novashell stop instance foo
novashell set instance foo memory 2048
novashell start instance foo
Then wrap it in SSHD and you can embed nova into hardware, manage it like a
switch,
That is how it works now, but if we need to run tests that are not
on the tarmac machine, we need to push that local branch somewhere
so other things can test the same thing.
Monty Taylor will have a much better idea of how to orchestrate all
of this, I'm going off what we did in the past, and I
On 02/24/2011 04:53 PM, JC Smith wrote:
What about an interactive shell like IOS, vyatta, python shell, irb, etc
$ novashell
novashell show instances
novashell stop instance foo
novashell set instance foo memory 2048
novashell start instance foo
Then wrap it in SSHD and you can embed
This thread seems to be radically messed up, but from where I am sitting it
certainly doesn't seem like everybody is agreeing, so far it appears that
most people disagree about most things.
On Thu, Feb 24, 2011 at 2:33 PM, Trey Morris trey.mor...@rackspace.comwrote:
sounds like we agree then.
(by radically messed up i mean i am getting up to 4 copies of each message
and the ordering has been non-chronological)
On Thu, Feb 24, 2011 at 3:36 PM, Andy Smith andys...@gmail.com wrote:
This thread seems to be radically messed up, but from where I am sitting it
certainly doesn't seem like
I guess I will be the odd man out, but using the project name for compute as
the command line tool name makes no sense. As we add more projects and
services it makes less sense to drive them from a tool called 'nova'. For
example, today swift has a tool called st to manipulate its rest api. Are we
Unless the mailing lists are being even crazier than I think, I don't
believe anybody has addressed any of the concerns I brought up in the
novatools thread.
Am I missing a set of emails or have you?
--andy
On Thu, Feb 24, 2011 at 2:16 PM, Jay Pipes jaypi...@gmail.com wrote:
On Thu, Feb 24,
can't the other tests/systems also pull the LP topic branch straight from LP
for testing?
This would allow:
test system 1 to pull trunk, merge topic branch A and test. if success it
passes it off to
test system 2 to pull trunk, merge topic branch A and test, while
test system 1 moves on, pulls
Please summarize these on the wiki and add your information the wiki, that
is what the wiki page was made to do and what I asked you to do.
--andy
On Thu, Feb 24, 2011 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote:
Andy has listed a few things on the wiki. I'll summarize the known efforts
That url is http://wiki.openstack.org/TestingBrainstorm btw
On Thu, Feb 24, 2011 at 4:06 PM, Andy Smith andys...@gmail.com wrote:
Please summarize these on the wiki and add your information the wiki, that
is what the wiki page was made to do and what I asked you to do.
--andy
On Thu, Feb
Sure, that's possible too. I'll leave it to the folks setting up the
tests and working with tarmac/bzr/jenkins/... to decide what is the
easiest way to implement it. Lots of ways to do it. :)
-Eric
On Thu, Feb 24, 2011 at 06:05:48PM -0600, Trey Morris wrote:
can't the other tests/systems
Hi John,
I think the super tool should be named openstack, I don't think
anyone was proposing we call that nova. Each individual project can
use whatever name it likes, for example:
nova create instance
glance describe images
openstack create cluster netowork imaage count
The last one would use
This stuff was discussed and decided upon in the release meeting a couple
days ago, unless somebody more official wants to make a statement the
results of the decision were:
(1) Developer review days are a go, Soren will set up a wiki page assigning
devs to days (i don't think this is done yet).
So in cases where static injection into the image is used, it seems there
can be no dynamic reconfiguration of the network, ie cannot plug a vNic into
a network after the VM is started.
Just so we're all on the same page, in what cases is dhcp/ra not
appropriate?
Cheers,
Dan
On Feb 25, 2011
I'd like to go on record as saying that anything related to nova or
openstack that doesn't allow you to configure which public API you're
consuming shouldn't bear the name nova or openstack. If you look at
http://nova.openstack.org/ you see API Compatibility in bold as one
of our design
Looking at https://lists.launchpad.net/openstack/threads.html I see a
few posts from you, but they all complain about the list missing
messages from you. Not sure what the issue is. Seems replies from
everyone but you are working just fine.
-jay
On Thu, Feb 24, 2011 at 7:03 PM, Andy Smith
On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes jaypi...@gmail.com wrote:
On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith andys...@gmail.com wrote:
Well, my previous reply somehow isn't going through to the list... so...
here it is again:
I've got some objections so far:
1. relying on
Please ignore the first clause of that email as it appears the message was
indeed received.
I still feel there is discussion about this (novatools) going on in the
novatools thread.
--andy
On Thu, Feb 24, 2011 at 5:41 PM, Jay Pipes jaypi...@gmail.com wrote:
Looking at
Some great discussion going on here folks but, in an attempt to prevent this
turning into a full-on Painting the Bike Shed debate, here are the assumptions
I'm proceeding with:
1. Eventually there will be a super tool to aggregate the various services.
It will be built/named later by someone.
On Thu, Feb 24, 2011 at 9:05 PM, Andy Smith andys...@gmail.com wrote:
On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes jaypi...@gmail.com wrote:
On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith andys...@gmail.com wrote:
Well, my previous reply somehow isn't going through to the list... so...
here it is
On Thu, Feb 24, 2011 at 9:19 PM, Andy Smith andys...@gmail.com wrote:
Please ignore the first clause of that email as it appears the message was
indeed received.
I still feel there is discussion about this (novatools) going on in the
novatools thread.
Yes, no doubt. Both of these threads are
I, mistakingly, changed the subject so I could focus on the install directory.
Sorry for creating a rift.
Hopefully, I'm going to move it in such a way that we don't need to mess with
the python path for nova and a user can still install it if desired.
-S
Thanks Jay. Yes, to the best of my knowledge nothing should have changed to
keep novatools from working with cloudservers/RS API. This was the situation
right up to the rebranding. Now, a merge would be much harder.
-S
*If* Sandy's minimal changes were merged, then python-cloudservers
would
On Thu, Feb 24, 2011 at 6:25 PM, Jay Pipes jaypi...@gmail.com wrote:
On Thu, Feb 24, 2011 at 9:05 PM, Andy Smith andys...@gmail.com wrote:
On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes jaypi...@gmail.com wrote:
On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith andys...@gmail.com wrote:
Well, my
But will he continue to pull merges on a rapidly changing series of patches up
to RC on April 14th and beyond?
-S
So we have perhaps a decent chance of getting things rolling there?
I think it is worth pursuing.
--andy
Confidentiality Notice: This e-mail message (including any attached or
Sandy Walsh wrote:
I'd like to help out on the review process as
per http://wiki.openstack.org/Governance/Approved/CoreDevProcess
I like quiet walks in the park and black and white movies.
+1s from: jaypipes, devcamcar, soren, cerberus, tr3buchet and vishy
Some +1s were added a bit late,
I'm afraid I'm unable to attend today's meeting. Sorry about the late
notice.
___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help :
76 matches
Mail list logo
