On Wed, Feb 9, 2011 at 11:19 PM, Aimon Bustardo abusta...@g2ix.com wrote:
I have seen another thread on this also Multi Clusters in a Region .
the URI based naming makes the most sense here and the actual name is
each child is free-form but must conform to acceptable URI characters
for
Jay,
It sounds like you understand it. :) The guest agent will be required to
configure the VM's network settings and root password, etc. I share your
thoughts. It feels like it should be a part of nova to me as well.
- Chris
On Feb 10, 2011, at 7:53 AM, Jay Pipes wrote:
If this guest
Hi Hisaharu,
Thanks for sharing this design proposal and the POC code.
I will have a look at the code as soon as possible.
At a first glance, I think the design that you are proposing is in line with
the goals of the network service blueprint
(http://wiki.openstack.org/NetworkService)
If I got
Hi George,
Would love to hear your ideas. I appreciate any conversations that involve
security and extensibility. :) I have short term goals I need to hit, but I'm
all for combining any duplicated efforts for the long run.
- Chris
On Feb 10, 2011, at 8:40 AM, George Reese wrote:
I have
OK, now I understand you a bit better about the URI naming scheme.
Thanks for your explanation/clearing it up.
Cheers!
jay
On Thu, Feb 10, 2011 at 12:05 PM, Eric Day e...@oddments.org wrote:
On Wed, Feb 09, 2011 at 08:00:02PM -0500, Jay Pipes wrote:
There is other common functionality we
On Thu, Feb 10, 2011 at 12:08 PM, Chris Behrens
chris.behr...@rackspace.com wrote:
Hi George,
Would love to hear your ideas. I appreciate any conversations that involve
security and extensibility. :) I have short term goals I need to hit, but
I'm all for combining any duplicated efforts
All,
I'm not sure if this has been discussed before at any length, but I would
like to discuss if it makes sense to have source code in the stable trunk
and installable packages built and provided from the rapidly changing
development trunk.
For some background we've been working through some
On Thu, 10 Feb 2011, Thierry Carrez wrote:
Paul Voccio wrote:
So the question I want to pose to the community is if they are
interested in the code, where should it go and how should we move
forward on extending it?
I think it's always interesting to publish the code. I'm not convinced
Hi Jason,
I think you might wanna check this:
http://www.mail-archive.com/nova@lists.launchpad.net/msg00321.html
Worth mentioning that the release PPA is actually called release not
stable as mentioned in the above mail.
I hope this helps.
On Thu, Feb 10, 2011 at 7:26 PM, Jason Cannavale
Hi Sandy,
I think there is some consensus forming around URI names for zones
and objects, so for now I might make sure the zone API rejects names
that are not compliant (ie, no spaces, ...). This is obviously easy
to change later on too as plans firm up.
-Eric
On Thu, Feb 10, 2011 at 01:19:57PM
I think this may have to do with confusion over what the release
series on Launchpad are...
The Bexar series is frozen at this point, and does not get any
non-critical bug fixes or feature patches that have been going into
the Cactus (trunk) series, unless a post-bexar-release exception is
made
Justin,
Our USC-ISI team is very interested in this. We are implementing different
architecture types beyond x86_64. We are also interested in suggesting switch
topology for MPI cluster jobs, passing in requests for GPU accelerators, etc.
Currently, our approach has been to specify these
Thanks Brian - that's a great suggestion for how to get round the
limitations of the EC2 API. I've added it to the wiki page for the
blueprint:
*We could also stuff this information into another supported field; for
example instance-type (e.g. euca-run-instance --instance-type
13 matches
Mail list logo
