On 11/1/12 9:36 AM, Lars Kellogg-Stedman l...@seas.harvard.edu wrote:
Honestly I think the entire idea of passing a password in to the
instance at boot
time is insecure and flawed.
I think that the use of a configuration drive is a reasonably way to
provide configuration information to an
Its in the instance_metadata table in the nova db.
From: Trinath Somanchi [mailto:trinath.soman...@gmail.com]
Sent: Friday, August 31, 2012 9:15 PM
To: Anne Gentle
Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net
Subject: Re: [openstack-dev] [Openstack] Openstack NOVA and
Hey Sam,
Is it possible your hypervisors restarted? I see this entry in the logs:
2012-08-23 06:35:02 INFO nova.compute.manager
[req-f1598257-3f35-40e6-b5aa-d47a0e93bfba None None] [instance:
ce00ff1d-cf46-44de-9557-c5a0f91c8d67] Rebooting instance after nova-compute
restart.
Gabe
From:
It would definitely be great to see these as generally accepted properties. In
general, I would hope that anything that is accepted by the community
eventually makes it into core API, and shipping with them on by default is a
great first step. Mostly, I'd like to see us able to turn off the
-Original Message-
From: openstack-
bounces+gabe.westmaas=rackspace@lists.launchpad.net
[mailto:openstack-
bounces+gabe.westmaas=rackspace@lists.launchpad.net] On Behalf Of
Daniel P. Berrange
Sent: Friday, August 10, 2012 8:48 AM
To: Vishvananda Ishaya
Cc: OpenStack
-Original Message-
From: openstack-
bounces+gabe.westmaas=rackspace@lists.launchpad.net
[mailto:openstack-
bounces+gabe.westmaas=rackspace@lists.launchpad.net] On Behalf Of
Gabe Westmaas
Sent: Friday, August 10, 2012 9:15 AM
To: Daniel P. Berrange; Vishvananda Ishaya
Cc
Hey Lars,
Sadly I don't have much in the way of a solution for you, but I do have
some suggestions. Comments inline.
On 6/15/12 4:17 PM, Lars Kellogg-Stedman l...@seas.harvard.edu wrote:
Howdy all,
I've spent the past few days slogging through the initial steps of
getting OpenStack and
[mailto:salv.orla...@gmail.com]
Sent: Thursday, June 14, 2012 7:15 PM
To: Jay Pipes
Cc: Gabe Westmaas; openstack@lists.launchpad.net
Subject: Re: [Openstack] request and transaction IDs across all projects
+111 from me.
This would make a lot easier extracting info from logs and correlating events
On 6/12/12 12:32 PM, Jay Pipes jaypi...@gmail.com wrote:
On 06/12/2012 01:27 AM, Gabe Westmaas wrote:
In nova we use a request ID to to help in finding all logs associated
with
a particular request, and this has proven to be extremely useful when
debugging issues. This should be taken a bit
In nova we use a request ID to to help in finding all logs associated with
a particular request, and this has proven to be extremely useful when
debugging issues. This should be taken a bit further, in two different
directions.
First, I'd like to see the request ID stored along with the any
Services, Galway
-Original Message-
From: openstack-bounces+duncan.thomas=hp@lists.launchpad.net
[mailto:openstack-bounces+duncan.thomas=hp@lists.launchpad.net] On
Behalf Of Gabe Westmaas
Sent: 08 June 2012 06:01
To: openstack@lists.launchpad.net
Subject: [Openstack] [nova
Hey all,
I was looking through some of the api calls, in particular creating a
server on the openstack api. I'm not too excited by how long it takes,
and was wondering what people think about making it more asynchronous.
Basically, wondering if making it so that the POST to the nova API doesn't
And I opened one 3 weeks ago! :) Just marked the one you did as a duplicate –
happy to have it go either way though, no worries.
https://bugs.launchpad.net/nova/+bug/998199
The error message is confusing, largely because the variable names are
confusing, I suspect. Anyway, there should be
Should we revert this change till we get it cleared up?
On 6/4/12 8:29 PM, James E. Blair cor...@inaugust.com wrote:
On 06/04/2012 04:00 PM, Kevin L. Mitchell wrote:
Today I've noticed some significant problems with nova's test suite
leaving literally hundreds of python processes out. I'm
I agree, this looks much more clear compared to where we are now.
I'd like to understand the difference between a soft and hard delete.
Does an API user have to specify that in some way? I definitely agree
that you should be able to delete in any state, I would rather it not be a
requirement
Also, with this proposal I'd be a lot more interested in exposing task
state as a part of the API eventually. This is helpful to communicate
whether or not other actions would be allowed in certain states. For
example, right now we don't allow other actions when a server is
snapshotting, but
This actually sounds like it covers most of the first run needs in this
etherpad:
http://etherpad.openstack.org/FolsomGlanceImageReplication
Definitely excited to see the tool, and then I wonder if we can just add a
few things to it to get metadata and filtering support. Sounds like ec2
stuff
I'd prefer to just set a different expectation for the user. Rather than
worrying about state change and invalidation, lets just set the expectation
that the system as a whole is eventually consistent. I would love to prevent
any cache busting strategies or expectations as well as anything
On 3/23/12 8:56 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
On 03/23/2012 09:44 AM, Gabe Westmaas wrote:
I'd prefer to just set a different expectation for the user. Rather
than worrying about state change and invalidation, lets just set the
expectation that the system as a whole
Instances in deleted status can normally be deleted, but there is definitely a
bug to file here somewhere – possibly more than one. A common reason I have
seen is that the node the instance lives on is no longer operating correctly,
so the compute manager never gets the delete request, so it
...@gmail.com]
Sent: Thursday, March 22, 2012 2:20 AM
To: Gabe Westmaas
Cc: Yong Sheng Gong; Openstack Mail List
Subject: Re: [Openstack] Can't delete instances with error status.
My understanding is that you would not always want a user to delete an instance
in an error state. So an operations person can
there have been occasions where it's frustrated me that something I
objected to got merged without my seeing it or while I was trying to
comment.
I've heard of this several times in the past as well - some merge prop is
mid-review, and then it merges. Is there an easy mechanism to flag a
Beyond refactoring the way we add in data for response extensions, I think
the right way to get this database performance is make the compute-cells
approach the normal. In this approach, there are at least two nova
databases, one which lives along with the nova-api nodes, and one that lives
I think this thing we call zones is fundamentally different from an
Availability Zone or a Host Aggregate. An Availability Zone is about
redundancy, a Host Aggregate is about capabilities, and a Zone is about
infrastructure performance. I could easily imagine an Availability Zone larger
than
On 2/15/12 9:48 AM, Armando Migliaccio
armando.migliac...@eu.citrix.com wrote:
I am a bit lost...what has size got to do with relationship?
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: 15 February 2012 14:36
To: Gabe Westmaas
Cc: Armando Migliaccio; Martin
This really is more of about sharding than grouping though. The specific
goal of this implementation is to shard your nova database (on a capacity
basis, not on a special key) and allow you to split (or shard :)
connections to your rabbit server. This implementation should be used for
performance
Partitions maybe?
On 2/14/12 4:01 PM, Gabe Westmaas gabe.westm...@rackspace.com wrote:
This really is more of about sharding than grouping though. The specific
goal of this implementation is to shard your nova database (on a capacity
basis, not on a special key) and allow you to split (or shard
Maybe a good topic for next design summit is to define our next set of goals
with migrations as the projects get larger and the usage of the projects
increases in scale.
Are migrations intended for all environments? Dev, initial rollouts, small
clouds, enterprise clouds?
Should data and
Sure! Sorry about that :)
Torpedo is just the set of ruby tests that we have been using for a while
to smoketest the API, separated into a project outside of VPC - the
project that was running for a while on the jenkins server. Source is
here: https://github.com/dprince/torpedo When one is hit
Hey all,
Just thought I'd let you know of a tool many of the guys here on ozone have
found useful:
http://reviewday.ohthree.com/
Basically it takes the review ordering work that Thierry did and makes it work
with gerrit and then adds test results from smokestack to let you know whether
unit
I definitely get why developers working on the code base are in favor of
this, especially for reasons 3 and 4 below. However, there are a couple
of reasons that it might make sense to keep it, and I'd really like to
hear from a different demographic, if at all possible.
First, I'd like to hear
On 10/12/11 9:22 AM, Jay Pipes jaypi...@gmail.com wrote:
On Wed, Oct 12, 2011 at 8:13 AM, Gabe Westmaas
gabe.westm...@rackspace.com wrote:
I definitely get why developers working on the code base are in favor of
this, especially for reasons 3 and 4 below. However, there are a couple
I'd like to try to summarize and propose at least one next step for the content
of the openstack-integration-tests git repository. Note that this is only
about the actual tests themselves, and says absolutely nothing about any gating
decisions made in other sessions.
First, there was
On 9/12/11 2:54 PM, Tim Simpson tim.simp...@rackspace.com wrote:
It would be advantageous for the tests to only use one client, whatever
it turns out to be. I think it would be most practical to use a bleeding
edge version of Nova client and add any features necessary to it in its
own repo
Hey Thierry,
Here is a list the team compiled on the known gaps in the 1.1
implementation. I haven't had a chance to file any bugs on these yet, but
wanted to at least answer this email with the list. I split them roughly
based on complexity.
Most complex:
resource uuids - there is a mixture
Most of these issues (and a few more) are now tagged osapi-v1.1 (thanks
waldon). If you do work on them please claim them first!
Thanks for the help.
Gabe
On 9/8/11 9:32 AM, Gabe Westmaas gabe.westm...@rackspace.com wrote:
Hey Thierry,
Here is a list the team compiled on the known gaps
Hey Sandy,
We hadn't shifted our focus over to the client yet - our assumption had been
that the best course would be to version the existing library and move forward.
However, that was definitely an assumption and if people have experience that
says maybe we should explore a new client tied
On Wednesday, March 30, 2011 6:16pm, Rick Clark r...@openstack.org said:
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help :
Thanks Justin, appreciate the input! Answers inline.
On Thursday, March 31, 2011 5:31pm, Justin Santa Barbara
jus...@fathomdb.com said:
I think there are a few distinct issues:
1) XML support. I was thinking that most XML issues would also be issues in
the JSON, so validating the XML
Hey All,
For various reasons, Rackspace has a need to allow customers to request
placement in the same zone as another server. I am trying to figure out if
this is generically useful, or something that should be outside of core. The
idea is that if you don't specify an affinity ID one will
40 matches
Mail list logo
