On 07/12/2012 10:45 AM, Lorin Hochstein wrote:
(crossposting to doc-core in case not everyone there has moved over to
openstack-docs yet).
A question came up on this merge proposal: https://review.openstack.org/9494
In that proposal, I had created a troubleshooting section in the
Self Resolved
since no memory resources are available, this error is shown.
On Thu, Jul 12, 2012 at 11:06 AM, Trinath Somanchi
trinath.soman...@gmail.com wrote:
Hi-
I have set up two machine a Controller (All Openstack Modules) and Node
(Only Nova-Compute).
In the first instance,
You can just stop nova-compute on the essex-1 node.
2012/7/12 Trinath Somanchi trinath.soman...@gmail.com
Hi-
I have installed Openstack on a Machine ESSEX-1 which is the controller
and Nova-Compute on another machine ESSEX-2 which acts as an agent/node.
When ever I start an new instance,
$ sudo nova-manage service disable --host=ESSEX-1 --service nova-compute
It's also good to read the documentation before asking questions.
http://docs.openstack.org/essex/openstack-compute/admin/content/managing-the-cloud.html#d6e6254
Cheers.
On Thu, Jul 12, 2012 at 9:14 AM, Christian Wittwer
Adam Gandelman wrote:
I'd like to announce the availability of Folsom trunk testing PPAs for
Ubuntu 12.04 and and 12.10. We've spent a considerable amount of time
this cycle expanding our test infrastructure + coverage and packaging
efforts in order to support a single Openstack release
Hi Neo-
I have configured Nova network to use FLATDHCPMANAGER driver.
I'm able to start the instances at NODES.
But some times these instances run at Controller it self. I'm investigating
the terms on how to restrict this.
Hence posted the issue in the list.
On Thu, Jul 12, 2012 at 12:28 PM,
Thanks for the reply.
If I stop the Nova-Compute in Essex-1 machine. then How will Controller and
Nodes communicate via libvirt where in turn Nova-compute handles it.?
On Thu, Jul 12, 2012 at 1:00 PM, Sébastien Han han.sebast...@gmail.comwrote:
$ sudo nova-manage service disable
Hi,
1. Is this also applicable to the agents? Say for example a user wants
to ensure that a public network is attached to network interface em1 and
the private network attached to em2. Is this something that will be
addressed by the blueprint?
2. I prefer option #3. This seems to be a cleaner
Thanks a lot for the help in replies...
have disabled Nova-compute in Controller. It worked fine..
On Thu, Jul 12, 2012 at 3:48 PM, Kiall Mac Innes ki...@managedit.ie wrote:
Are you saying you don't want instances to run on the controller?
If so, remove nova-compute from the controller and
Why not just --public or not ? Why do you need --public True ? That just
adds confusion...
Endre.
2012/7/12 Gary Kotton gkot...@redhat.com
**
Hi,
1. Is this also applicable to the agents? Say for example a user wants to
ensure that a public network is attached to network interface em1 and
Fowarding to the list
Original Message
Subject:Re: [Openstack] [Quantum] Public Network spec proposal
Date: Thu, 12 Jul 2012 13:47:13 +0200
From: Endre Karlson endre.karl...@gmail.com
To: gkot...@redhat.com
Why not just --public or not ? Why do you need
I've only deployed openstack for the first time a couple weeks ago,
but FWIW...
I had similar symptoms on my Essex test deployment (on Ubuntu 12.04)
turned out my problem was taht while the br100 bridge was up and
configured the underlying eth1 physical interface was down so the bits
went
Oh don't worry.
The nova-scheduler and other nova components will take care all of it.
Just run the disable nova-compute command and run another instance. You'll see.
On Thu, Jul 12, 2012 at 4:16 PM, Trinath Somanchi
trinath.soman...@gmail.com wrote:
Thanks for the reply.
If I stop the
If we just use one flag, it can represent just two values True or False. If we want to represent three values True, False or not specified, we have to use --public True or --public False or nothing at all.So it is a three-values logic.-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
Hi all
I found that the arp_cache in slabinfo on objec-server is growing up
followed with uploaded object numbers.
Does any code using it ?
2352000 1329606 56%0.06K 36750 64147000K kmalloc-64
1566617 1257226 80%0.21K 42341 37338728K xfs_ili
1539808 1257748 81%
We've got volumes in production, and while I'd be more comfortable with option
2 for the reasons you list below, plus the fact that cinder is fundamentally
new code with totally new HA and reliability work needing to be done
(particularly for the API endpoint), it sounds like the majority is
On 07/11/2012 07:28 PM, Rafael Durán Castañeda wrote:
Thank you guys for the info, I didn't know about some of the projects.
However writing my on-house own stuff is not what I was considering
but adding a middleware into Keystone, nothing fancy but extensible so
it covers at least most basic
On 07/05/2012 07:02 PM, Nick Barcet wrote:
On 07/04/2012 05:38 PM, Day, Phil wrote:
Hi All,
I’m thinking it’s about time we had an OpenStack User Group meeting in
the UK , and would be interested in hearing from anyone interested in
attending, presenting, helping to organise, etc.
London
Hi,Who can tell me where glance API v2.0 spec is?ThanksYong Sheng Gong
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help :
On 07/12/2012 10:36 AM, Thomas, Duncan wrote:
We’ve got volumes in production, and while I’d be more comfortable with
option 2 for the reasons you list below, plus the fact that cinder is
fundamentally new code with totally new HA and reliability work needing
to be done (particularly for the
Here's the latest draft:
https://docs.google.com/document/d/1jPdgmQUzTuSt9iqcgPy74fbkzafCvqfQpvzRhwf2Kic/edit
It is still a work in progress as we have found several tweaks we want to make
as we actually implement it. I will spend some time updating the google doc
sometime soon.
On Jul 12,
During Tuesday's keystone meeting
(http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-07-10-18.01.html
if you're curious), we reviewed the work that we'd originally lined up against
Folsom and did a check against the time remaining in the development cycle
Thank you again for your feedback.
On the discussion about two or three-way logic, I understand Yong's point
of being able to fetch public and private networks in one call, but I also
I agree with Endre that using a boolean flag for something which is
actually Yes/No/Whatever sounds confusing and
On Thu, Jul 12, 2012 at 9:28 AM, Jay Pipes jaypi...@gmail.com wrote:
On 07/12/2012 10:36 AM, Thomas, Duncan wrote:
We’ve got volumes in production, and while I’d be more comfortable with
option 2 for the reasons you list below, plus the fact that cinder is
fundamentally new code with totally
On 07/12/2012 04:48 PM, Jay Pipes wrote:
On 07/11/2012 07:28 PM, Rafael Durán Castañeda wrote:
Thank you guys for the info, I didn't know about some of the projects.
However writing my on-house own stuff is not what I was considering
but adding a middleware into Keystone, nothing fancy but
We currently have a large deployment that is based on nova-volume as it is
in trunk today, and just ripping it out will be quite painful. For us,
option #2 is the only suitable option.
We need a smooth migration path, and time to successfuly migrate to Cinder.
Since there is no clear migration
for posterity yes the info isn't hard to find in the database:
mysql select id,vcpus,vcpus_used,memory_mb,memory_mb_used from compute_nodes;
I'm not terribly keen on SQL as an interface, guess if it bothers me
enough I'll implement a different interface...
On Wed, Jul 11, 2012 at 10:34 PM,
This community just doesn't give a rat's ass about compatibility, does it?
-George
On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote:
Hello Everyone,
Now that the PPB has decided to promote Cinder to core for the Folsom
release, we need to decide what happens to the existing Nova
On Thu, 2012-07-12 at 18:26 +0200, Rafael Durán Castañeda wrote:
Unless I'm missing something, nova_limits is not applicable to Keystone
since it takes the tenant_id from 'nova.context', which obiously is not
available for Keystone; thought adapt/extend it to keystone should be
trivial and
On 07/11/2012 02:34 PM, Nick Barcet wrote:
Hi,
The metering project team holds a meeting in #openstack-meeting,
Thursdays at 1600 UTC
http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0.
Everyone is welcome.
Agenda:
http://wiki.openstack.org/Meetings/MeteringAgenda
On Thu, 2012-07-12 at 12:31 -0400, Jonathan Proulx wrote:
for posterity yes the info isn't hard to find in the database:
mysql select id,vcpus,vcpus_used,memory_mb,memory_mb_used from
compute_nodes;
I'm not terribly keen on SQL as an interface, guess if it bothers me
enough I'll
On 07/12/2012 12:26 PM, Rafael Durán Castañeda wrote:
Unless I'm missing something, nova_limits is not applicable to Keystone
since it takes the tenant_id from 'nova.context', which obiously is not
available for Keystone; thought adapt/extend it to keystone should be
trivial and probably is
Hello list,
I've just installed Openstack Essex on Ubuntu 12.04. Everything works well
except one problem I just faced:
When I try terminate VM in dashboard. It stuck in deleting ask for few
hours until now. I can not connect VM. I try reboot using nova command and
error :
We actually care a hell of a lot about compatibility. We also recognize there
are times when we have to sacrifice compatibility so we can move forward at a
reasonable pace.
If you think we are handling anything the wrong way, we would love to hear your
suggestions. If you just want to make
Well, I think overall OpenStack has done an absolute shit job of compatibility
and I had hoped (and made a huge point of this at the OpenStack conference)
Diablo - Essex would be the end of this compatibility bullshit.
But the attitudes in this thread and with respect to the whole Cinder
On 07/12/2012 12:32 PM, George Reese wrote:
This community just doesn't give a rat's ass about compatibility, does it?
a) Please don't be inappropriate on the mailing list
b) Vish sent the email below to the mailing list *precisely because* he
cares about compatibility. He wants to discuss the
Hi Everyone,
Throughout the email thread regarding how to proceed with
cinder/nova-volumes and a number of IRC conversations I thought I
should try and clarify a few things about Cinder.
First, it should be clear that Cinder is literally a direct copy of
the existing nova-volume code. This was
Outside of the Etherpad (http://etherpad.openstack.org/FolsomComputeCells)
and presentation referenced there (http://comstud.com/FolsomCells.pdf), are
there additional details available on the architecture / implementation of
Cells?
Thanks.
Michael
This level of response is unnecessary.
That said, the perspectives which influenced the decision seemed somewhat
weighted to the development community. I could be wrong, but I did not see much
input from the operations community as to the impact.
Clearly, going forward, we want to be more
I certainly wasn't picking on Vish, but instead the entire community so eagerly
interested in option #1. You see, the OpenStack community has a perfect record
of making sure stuff like that ends up breaking everyone between upgrades.
So, if you take offense by my comments… err, well, I'm not at
On 07/12/2012 06:36 AM, Kuo Hugo wrote:
Hi all
I found that the arp_cache in slabinfo on objec-server is growing up
followed with uploaded object numbers.
Does any code using it ?
The code which maps from IP to Ethernet addresses does. That mapping is
what enables sending IP datagrams
You evidently have not had to live with the interoperability nightmare known as
OpenStack in the same way I have. Otherwise, you would find responses like
Brian's much more offensive.
-George
On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote:
This level of response is unnecessary.
What exactly was so offensive about what I said? Communities like OpenStack are
built on top of people *doing* things, not *talking* about things. I'm just
asking you to contribute code or design help rather than slanderous commentary.
Brian Offensive Waldon
On Jul 12, 2012, at 11:59 AM,
Partially developed. This probably isn't much use, but I'll throw it out
there: http://comstud.com/cells.pdf
ATM the messy code speaks for itself here:
https://github.com/comstud/nova/tree/cells_service
The basic architecture is:
Top level cell with API service has DB, rabbit, and the
So if Im not coding, I should shut up?
I think you answered your own question.
Sent from my iPhone
On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote:
What exactly was so offensive about what I said? Communities like OpenStack
are built on top of people *doing* things,
Planning the development of the projects is valuable as well as contributing
code. If you review my last message, you'll see the words '... or design help',
which I intended to represent non-code contribution. You seem to have strong
opinions on how things should be done, but I don't see your
This ain't the first time I've had a run in with you where your response was
essentially if you don't like it, go code it.
And obviously you missed the entire constructive point in my response. It's
this:
The proposed options suck. It's too late to do anything about that as this ship
has
On Jul 12, 2012, at 11:48 AM, Christopher B Ferris wrote:
This level of response is unnecessary.
That said, the perspectives which influenced the decision seemed somewhat
weighted to the development community. I could be wrong, but I did not see
much input from the operations community
George,
I am relatively new to this mailing list so I assume that there is some history
that is prompting the vehemence but I do not understand what you are trying to
accomplish.
Vish sent out two proposed ways for dealing with the migration. Most of the
early voting (including mine) has
To certain extent I agree with george's sentiment.
Recent example... we're changing tenants to projects in the keystone api.
Yes we maintain v2 api compatibility but there will be a cost to users in
the confusion of decisions like this. George is right to be calling for
openstack to grow up.
That's a good question. I'm also interested in an update on cells. How
is progress on cells going? Is there a blueprint for it? Is it
targeted to a folsom milestone?
Thanks,
Nate
On Thu, Jul 12, 2012 at 1:39 PM, Michael J Fork mjf...@us.ibm.com wrote:
Outside of the Etherpad
You are mistaking me for caring about the answer to this question.
This ship has sailed. We are faced with two shitty choices as a result of
continued lack of concern by this community for compatibility.
History? I've been pounding my head against the OpenStack all for years on
compatibility
http://www.sebastien-han.fr/blog/2012/07/10/delete-a-vm-in-an-error-state/
On Thu, Jul 12, 2012 at 8:34 PM, Tong Li liton...@us.ibm.com wrote:
Hi, Hien,
I had same problem. The only way that I can get rid of it is to remove
the record for that instance from the following 3 mysql db tables
How can I disregard a position that you don't have? (or at least I don't
understand yet) You have failed to provide a position.
Like I said, I'm fairly new to OpenStack….but I am *very* experienced in open
source and operating very large and complex production systems… so I am trying
to come
I don't think Cinder should exist.
Sometimes you have to live with the technical debt because that's the best way
to preserve the investment your customers have made in your product.
Or if you're very smart, you find a way to refactor that technical debt
invisibly to customers.
But you don't
On Thu, Jul 12, 2012 at 1:14 PM, George Reese
george.re...@enstratus.com wrote:
So if Im not coding, I should shut up?
I think you answered your own question.
Sent from my iPhone
On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote:
What exactly was so offensive about
On Thursday, July 12, 2012 at 15:13 PM, Chris Behrens wrote:
Partially developed. This probably isn't much use, but I'll throw it out
there: http://comstud.com/cells.pdf
We're going to have to sync once more on removing _to_server calls from the RPC
layer.
With the matchmaker upstream
The stated and agreed-upon goal from Essex forward is to make the core
OpenStack projects N+1 compatible (e.g. Essex-Folsom, Folsom-Grizzly), and to
make the clients capable of talking to every API version forever.
Anything standing in the way of that should be considered a release-blocking
George,
your opinion is best conveyed if it comes with a polite choice of words.
Please refrain from adding more of your references to excrements and
help the community make a decision.
/stef
On 07/12/2012 12:14 PM, George Reese wrote:
So if Im not coding, I should shut up?
I think you
On Thu, Jul 12, 2012 at 2:37 PM, George Reese george.re...@enstratus.comwrote:
This ain't the first time I've had a run in with you where your response
was essentially if you don't like it, go code it.
And obviously you missed the entire constructive point in my response.
It's this:
The
On 07/12/2012 12:37 PM, George Reese wrote:
It's too late to do anything about that as
this ship has sailed.
This is wrong. You and anybody that believes options #1 and #2 proposed
by Vish and John are sub-optimal still have time to make a proposal.
Please, take time to write it down.
Cheers,
Hi all,
I have faced a situation where, if an LXC instance is rebooted by logging
into it as root user, I no longer was able to remotely logged into it (SSH).
But I can ping to that instance.
Is it a known issue ? if so, would like to know if there is any workaround.
--
Best Regards
Sajith
On Thu, Jul 12, 2012 at 2:38 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
Agreed, I'm a developer, so I'm clearly biased towards what is easier for
developers. It will be a significant effort to have to maintain the
nova-volume code, so I want to be sure it is necessary. End users
On Jul 12, 2012, at 2:22 PM, Narayan Desai wrote:
I think that the long term maintenance or removal of nova-volume in
its existing form is orthogonal to the actual issue of continuity from
one release to the next.
Agreed. Discussion the volume/cinder strategy is a separate topic. I've
taken
On Jul 12, 2012, at 2:36 PM, David Mortman wrote:
On Thu, Jul 12, 2012 at 3:38 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
Two thoughts:
1) I think this is the wrong forum to poll operators on their
preferences in general
2) We don't yet even have a fully laid out set of
tl;dr: I vote for option 2 as it's the only reasonable path from a deployer's
point of view
With my deployer hat on, I think option 1 isn't really valid. It's completely
unfair to force deployers to use Cinder before they can upgrade to Folsom.
There are real deployments using nova-volumes,
So, in short, your entire purpose here is to troll everyone? Nice… : /
You obviously care. You keep responding… You have been asked numerous times
what we can do to NOT stick us yet against in this situation in the future.
Why is that such a difficult question to answer? Do you have an answer?
El 12/07/12 18:59, Jay Pipes escribió:
On 07/12/2012 12:26 PM, Rafael Durán Castañeda wrote:
Unless I'm missing something, nova_limits is not applicable to Keystone
since it takes the tenant_id from 'nova.context', which obiously is not
available for Keystone; thought adapt/extend it to
On Thu, Jul 12, 2012 at 2:38 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
On Jul 12, 2012, at 11:48 AM, Christopher B Ferris wrote:
This level of response is unnecessary.
That said, the perspectives which influenced the decision seemed somewhat
weighted to the development community.
On Thu, Jul 12, 2012 at 2:56 PM, George Reese
george.re...@enstratus.com wrote:
I don't think Cinder should exist.
Sometimes you have to live with the technical debt because that's the best
way to preserve the investment your customers have made in your product.
Or if you're very smart, you
[launchpad is slow at delivering messages to the list. Please everybody
keep it in mind and slow down your replies too to give people the chance
to comment, too.]
On 07/12/2012 12:47 PM, Matt Joyce wrote:
Yes we maintain v2 api compatibility but there will be a cost to users
in the confusion of
On Jul 12, 2012, at 5:08 PM, John Postlethwait wrote:
So, in short, your entire purpose here is to troll everyone? Nice… : /
If you think that, you're likely part of the problem.
You obviously care. You keep responding… You have been asked numerous times
what we can do to NOT stick us
On 07/12/2012 04:36 PM, Vishvananda Ishaya wrote:
On Jul 12, 2012, at 2:22 PM, Narayan Desai wrote:
I think that the long term maintenance or removal of nova-volume in
its existing form is orthogonal to the actual issue of continuity from
one release to the next.
Agreed. Discussion
Excellent points. Let me make the following proposal:
1) Leave the code in nova-volume for now.
2) Document and test a clear migration path to cinder.
3) Take the working example upgrade to the operators list and ask them for
opinions.
4) Decide based on their feedback whether it is
On Jul 12, 2012, Christopher B Ferris wrote:
Clearly, going forward, we want to be more deliberate about changes
Funny how compatibility is always a popular going forward item.
Best -Federico
_
-- 'Problem' is a bleak word for challenge - Richard Fish
Hello,
I'm not an OpenStack developer nor any type of developer. I am, however,
heavily involved with operations for a few production OpenStack
environments. I understand the debate going on and wanted to add an
administrator's point of view.
For admins, OpenStack is not our job, but a tool we
On the flip side - to refresh people's memory it might be useful to send
out a link to some of the email threads (or wikis) that explained why this
move is critical to OS's success. Perhaps some of those reasons aren't as
valid any more given the impact people are now seeing it will have.
Dear all,
As the project named ceilometer appeared,I paid close attention to it.
According to the docs of ceilometer,I deploied it in openstack exsse
environment.
While,I cannot start the ceilometer collector and agent.
The follows are my operations.
1.Install
Sorry about this. I've had other priorities at Rackspace lately, but I have a
functioning implementation that I can hope to start to merge ASAP.
I'm on vacation for a couple days, so I can provide a better update on Monday.
On Jul 12, 2012, at 4:29 PM, Jaesuk Ahn bluejay@gmail.com wrote:
On Thu, Jul 12, 2012 at 4:36 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
Upgrading has been painful and we are striving to improve this process
as much as possible.
I think that this needs to be a core value of the developer community,
if Openstack is going to become pervasive.
I
Hi-
With respect to your document, on Openstack - OVS and Quantum,
I'm unable to understand the setup of OVS and Quantum in
ESSEX-2/Compute-node machine.
In the Document, https://lists.launchpad.net/openstack/pdfuNjHGvU5UA.pdf,
Page.No: 17/19,
In the section Open-vSwitch Quantum-agent, Do we
Thanks for the tip, unfortunately the interfaces are already up.
- Michael
On Thu, Jul 12, 2012 at 10:15 PM, Jonathan Proulx j...@csail.mit.edu wrote:
I've only deployed openstack for the first time a couple weeks ago,
but FWIW...
I had similar symptoms on my Essex test deployment (on
Title: quantal_folsom_horizon_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_horizon_trunk/44/Project:quantal_folsom_horizon_trunkDate of build:Thu, 12 Jul 2012 19:01:53 -0400Build duration:2 min 35 secBuild cause:Started by an SCM changeBuilt
83 matches
Mail list logo
