On Wed, Jan 25, 2012 at 7:01 PM, Edgar Magana (eperdomo) eperd...@cisco.com
wrote:
Dan,
** **
I was trying the os-create-server extension that your mention in this
thread but I am not sure if it will also limit the number of interfaces per
VM.
In my testbed, I have two (and
Could you give me some references on how i could implement the diagnostics
call for kvm/libvirt?
Regards,
Leander
On Wed, Jan 25, 2012 at 7:39 PM, Vishvananda Ishaya
vishvana...@gmail.comwrote:
There are currently no plans for such of thing. It seems easier to rely on
existing plugins for
Hi everyone,
The third milestone of the Essex cycle is available for Keystone,
Glance, Nova and Horizon. Note that Keystone now provides
python-keystoneclient as an additional release deliverable.
You can see the full list of new features and fixed bugs, as well as
tarball downloads, at:
could anyone please explain to me what is the relation between zones
in nova-manage and region in keystone-manage? And help me to get the
auth back working.
I got my fedora host test system messed up after installing keystone.
Now I suspect region/zone could be the reason for authentication
Zones is going through some radical changes currently.
Specifically, we're planning to use direct Rabbit-to-Rabbit communication
between trusted Zones to avoid the complication of changes to OS API, Keystone
and novaclient.
To the user deploying Nova not much will change, there may be a new
John Griffith wrote:
All,
I rant into some problems with my LaunchPad accounts that prevented me
from getting everything submitted/approved before the deadline.
This change is simply the addition of a SAN-ISCSI driver for SolidFire
block storage devices. It was on it's way to approval
Sandy,
I am excited to hear about the work that is going on around communication
between trusted zones and look forward to seeing what you have created.
In general, the scalability of Nova is an area where I think we need to put
additional emphasis. Rackspace has done a lot of work on zones,
Hey,
On Tue, 2012-01-03 at 16:57 +, Mark McLoughlin wrote:
The openstack-common project intends to produce a python library containing
infrastructure code shared by OpenStack projects. The APIs provided by the
project should be high quality, stable, consistent and generally useful.
Jason
Thanks Blake ... all very valid points.
Based on our discussions yesterday (the ink is still wet on the whiteboard)
we've been kicking around numbers in the following ranges:
500-1000 hosts per zone (zone = single nova deployment. 1 db, 1 rabbit)
25-100 instances per host (minimum flavor)
3s
On Thu, 2012-01-26 at 10:13 -0600, Blake Yeager wrote:
Does anyone have other thoughts about how we ensure we are all working
toward building a massively scalable system?
I recently discussed with both Sandy and Ziad a multi-realm extension
to Keystone. I've documented my thoughts on it as the
I see it implemented in the code as
DELETE /v2.0/tokens/{tokenId}
But it doesn't appear to be documented in any of the WADLs.
Thanks!
Guang
smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list:
It is definitely not a documented call (hence the should this be removed?
comment in the implementation); if it were to be promoted from
undocumented to an extension, I imagine it would belong in OS-KSADM.
- Dolph
On Thu, Jan 26, 2012 at 10:51 AM, Yee, Guang guang@hp.com wrote:
I see it
This is getting really interesting !!
I really hope to see the new Zones code merged into Essex, since we are
really planning a production implementation on Essex, as soon as it is
marked as a release ( nova, keystone, glance swift, wich also we got
it working on a big lab environment with
Happy tag day, everyone!
The next thing I'm going to work on (for Nova/Folsom) is adding an
API to assist with Puppet configuration on nova instances. The
blueprint for that is here:
http://wiki.openstack.org/PuppetConfigForNova
I welcome comments on that proposal.
There's a
Yippe common code that people can share! Win!
On 1/26/12 8:32 AM, Mark McLoughlin mar...@redhat.com wrote:
Hey,
On Tue, 2012-01-03 at 16:57 +, Mark McLoughlin wrote:
The openstack-common project intends to produce a python library containing
infrastructure code shared by OpenStack
Hi All,
The devstack document doesn't explain how to start/stop services,
maybe it's obvious for the devstack developers but not for a new user
like me! I can't use commands like restart nova-api because they
are not installed.
I installed OpenStack using devsatck stack.sh script
Hi,
I installed OpenStack using devsatck script (http://devstack.org/) on
Ubuntu 11.10. Installation was successful but there is no /etc/nova/
directory and It looks like that devstack script doesn't install all
the nova services.
I tried the flowing commands; please see the error messages
Can't wait for openstack-common to be usable for Quantum as well. Here is
our write-up of code in Quantum that seems generic (and is likely
borrowed from other openstack project):
http://wiki.openstack.org/QuantumOpenstackCommon
Would love to get much of this into openstack-common.
Dan
On
localadmin@k:~$ sudo screen -x
There is no screen to be attached.
localadmin@k:~$ killall screen
screen: no process found
Should I re-run stack.sh?
On Thu, Jan 26, 2012 at 2:24 PM, Dean Troyer dtro...@gmail.com wrote:
On Thu, Jan 26, 2012 at 1:02 PM, Joe Smithian joe.smith...@gmail.com
Looks interesting.
I wonder if it can be made more generic so that it would satisfy a similar
set of requirements for Chef (or whatever else comes along). I would
suspect that the general requirements for tables etc. are not puppet
specific, although the implementations may vary.
I would hope
I've created a script. Test if it helps you. You have to create the
/var/log/nova dir.
mkdir -p /var/log/nova
__
startnova.sh:
#!/bin/bash
service rabbitmq-server start
cd /opt/stack/glance/bin
./glance-registry --config-file=../etc/glance-registry.conf
Moving it to an extension makes sense to me. Ziad, does it make sense to add
it to OS-KSADM...or is this a different extension all together...revoke token
extension?
-jOrGe W.
On Jan 26, 2012, at 11:43 AM, Dolph Mathews wrote:
It is definitely not a documented call (hence the should this be
root@shrek:~# ps -ef | grep screen | grep -v grep
On Thu, Jan 26, 2012 at 2:32 PM, Dean Troyer dtro...@gmail.com wrote:
On Thu, Jan 26, 2012 at 1:30 PM, Joe Smithian joe.smith...@gmail.com wrote:
localadmin@k:~$ sudo screen -x
There is no screen to be attached.
You need to run this as
stack.sh doesn't run as root so sudo is incorrect.
it runs as local user or if you ran it as root originally, it will create a
user called stack change to that user and rerun itself.
(which means you will need to do sudo su stack; screen -x)
If it isn't running as the stack user, you probably
Yea, re-running stack.sh should bring everything back up.
Bear in mind this will wipe all users, images, instances etc (devstack is
for development, rather than production openstack environments after all)
Thanks,
Kiall
Sent from my mobile - Sorry for being short.
On Jan 26, 2012 7:45 p.m., Joe
Hi Joe,
I'm sure there are more elaborate approaches, but I have a simple kill.sh
script that looks something like:
sudo killall dnsmasq
sudo killall qemu
sudo rm -f /etc/libvirt/qemu/instance-*.xml
sudo killall screen
screen -wipe
This is of course specific to my use of qemu.
After running
if you need to restart your service frequently without destroying your
existing data, you might want to take a look at the upstart patch for
devstack.
https://blueprints.launchpad.net/devstack/+spec/upstart
Yun
On Thu, Jan 26, 2012 at 2:30 PM, Joe Smithian joe.smith...@gmail.com wrote:
Nicely done, guys!
Very, very cool.
d
On 26 Jan 2012 - 13:22, Robbie Williamson wrote:
http://jenkins.qa.ubuntu.com/view/Precise%20OpenStack%20Testing/
James Page[1] has setup the jobs in the Ubuntu OpenStack QA Lab to start
publishing to our public Jenkins QA instance this morning. We now
Ya, I would agree strongly with this.
Making openstack puppet specific seems bad in the long run (not everyone
wants/needs puppet).
This especially is apparent with having puppet tables in the nova database.
Something more generic maybe can be thought about?
On 1/26/12 11:30 AM, Tim Bell
HI Robbie
Awesome!
Can I ask some questions?
1. Is there any document or opensource of your juju-based ci-deployment?
2. Which kind of test are you running after deploy test?
Cheers
Nati
2012/1/26 Robbie Williamson rob...@ubuntu.com:
This actually is something I wanted to verify.
What are the reasons sudo won't work?
Apache running seems to be the only reason for that? Also the fact that config
files are written to privileged locations (/etc/apache2...), volume group
commands and such.
In the newer devstack I am working on
On 01/26/2012 02:49 PM, Nachi Ueno wrote:
HI Robbie
Awesome!
Can I ask some questions?
1. Is there any document or opensource of your juju-based ci-deployment?
This is coming *real* soon, we just recently got it all working and
wanted to clean it up first.
2. Which kind of test are you
I would like to know the proper way to blow away a stack and create a
fresh stack with devstack. Currently, I hit ctrl-c and ctrl-d a bunch
of times to close all the windows in the screen session. Then I run
./stack.sh again. Is this the best way? Is this documented somewhere?
Thanks,
Naveed
Hi Robbie
Thank you for your quick reply.
2012/1/26 Robbie Williamson rob...@ubuntu.com:
On 01/26/2012 02:49 PM, Nachi Ueno wrote:
HI Robbie
Awesome!
Can I ask some questions?
1. Is there any document or opensource of your juju-based ci-deployment?
This is coming *real* soon, we just
Hi Yun,
That's was exactly what I was looking for and was missing in devstack.
Thanks for providing it!
Joe.
On Thu, Jan 26, 2012 at 3:13 PM, Yun Mao yun...@gmail.com wrote:
if you need to restart your service frequently without destroying your
existing data, you might want to take a look at
Hi Jorge,
Those were exactly what I was looking for and were missing in
devstack. Thanks for providing it!
mkdir -p /var/log/keystone/ should be added to startnova.sh
I tried startnova.sh but it has either crashed the machine or
disconnected the network access- it doesn't reply to ping and
On 1/26/12 11:30 AM, Tim Bell wrote:
Looks interesting.
I wonder if it can be made more generic so that it would satisfy a similar
set of requirements for Chef (or whatever else comes along). I would
suspect that the general requirements for tables etc. are not puppet
specific, although the
Hey Nati--
1. Is there any document or opensource of your juju-based ci-deployment?
You can find a whole pile of bzr branches that hosts everything this is
built on at
https://code.launchpad.net/~openstack-ubuntu-testing
Beware this contains a lot of stuff! Packaging branches, forked
Oh, and regarding this:
On 1/26/12 11:30 AM, Tim Bell wrote:
I would hope for, at minimum, an implementation for Xen and KVM with, if
appropriate, something for lxc too.
That relates directly to the second question in my email: what
communication method should I use to pass information
On Thu, Jan 26, 2012 at 2:58 PM, Naveed Massjouni navee...@gmail.com wrote:
I would like to know the proper way to blow away a stack and create a
fresh stack with devstack. Currently, I hit ctrl-c and ctrl-d a bunch
of times to close all the windows in the screen session. Then I run
./stack.sh
If a client has bound to the contract XSD, they will break if we add this,
won't they?
But… I don't know how many clients would have bound to the OS-KSADM contracts.
We've been diligent and strict about not changing the core contract, but this
is the first time we've been presented with a
I think its just use a new virtual machine for now is the suggested way.
On 1/26/12 12:58 PM, Naveed Massjouni navee...@gmail.com wrote:
I would like to know the proper way to blow away a stack and create a
fresh stack with devstack. Currently, I hit ctrl-c and ctrl-d a bunch
of times to close
There is another thread on this, but the quick answer is;
killall screen
./stack.sh
You should generally make sure that you have terminated all instances and
deleted all volumes in advance or you could run into issues. It is always
safer to start from a clean vm, but the above should work in
Fantastic Work!
If you guys are still aways off with integrating Tempest, it would probably be
fairly easy use the exercise scripts in devstack to get a little more coverage
in the interim. You just would have to set up a bunch of env variables via
something like devstack/openrc and
That's easy enough, thanks. Sometimes I forget to delete all my
instances before blowing away screen and running ./stack.sh. Just
curious, what happens to all those vm's? Am I building up an army of
zombie vm's that are taking up resources? Or do they disappear into
the ether?
-Naveed
On Thu, Jan
A) This wasn't documented at all (AFAIK), so there's no concern of breaking
contracts.
B) Even if it's moved to an extension, would the call change from it's current
form?:
DELETE /tokens/{token_id}
I'm not sure what the extension convention is here.
-Dolph Mathews
On Jan 26, 2012, at
On Jan 26, 2012, at 4:39 PM, Ziad Sawalha wrote:
If a client has bound to the contract XSD, they will break if we add this,
won't they?
No. XSD only concerns itself with the attributes and elements of the message.
This is just adding a delete. That's a separate method, it shouldn't break
On Jan 26, 2012, at 5:17 PM, Dolph Mathews wrote:
A) This wasn't documented at all (AFAIK), so there's no concern of breaking
contracts.
I agree, it shouldn't break anything.
B) Even if it's moved to an extension, would the call change from it's current
form?:
DELETE /tokens/{token_id}
A) It sounds like yore making an assumption about what the type of client is.
Some clients use WADL to generate stubs or validate contracts. Consider clients
like JAX-RS/CXF clients? If you change the WADL, you've changed the contract.
Like I said, I think this would be an edge case, but a key
looks like the awesome authors of devstack are now handling this for you:
https://github.com/openstack-dev/devstack/blob/master/stack.sh#L931
So the instances are destroyed on the second run.
Vish
On Jan 26, 2012, at 3:14 PM, Naveed Massjouni wrote:
That's easy enough, thanks. Sometimes I
Congrats to the Quantum team!
The latest + greatest version of Quantum was release this morning, see:
https://launchpad.net/quantum/essex/essex-3
I delayed the announce in order to complete updating the documentation, due
to the fact that install procedures changed significantly with this
The approach here looks solid, but I'm not sure if it goes far enough.
One issue that Keystone has to resolve eventually is how to authenticate
request for tenant-specific file system users.
Basically the core authentication system allows satellite authentication
systems to authenticate users
Awesome authors indeed! Thanks.
-Naveed
On Thu, Jan 26, 2012 at 6:31 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
looks like the awesome authors of devstack are now handling this for you:
https://github.com/openstack-dev/devstack/blob/master/stack.sh#L931
So the instances are
Okay just to make things clear...
Totally agree with everything you said. I don't think we should just put the
functionality in core. The safest thing to do is to put it in a separate
extension rather than modifying the existing management extension. The safest
thing to do is also to move
Well the code to generate diagnostics under xen is in
nova/virt/xenapi/vm_utils.py:
887 def compile_diagnostics(cls, session, record):
888 Compile VM diagnostics data
889 try:
890 host = session.get_xenapi_host()
891 host_ip =
I would love to see a first class puppet integration with nova instances.
I'd also like to see more of a service oriented approach and avoid adding
tables to nova if possible.
I'm not sure the best solution is to come up with a generic service for
$configuration_manager for nova core. I'd rather
The Melange Essex-3 milestone was released this morning. You can find details
at:
https://launchpad.net/melange/essex/essex-3
This release focused on bug fixing, splitting out the python-melangeclient and
tidying up integration with the Nova Quantum Manager. This was also the first
release
Hi,
I have similar query. I had installed open stack using devstack on a
freshly installed stand-alone machine(not vm). For the first time once the
stack.sh is completed I was able to connect to the dashboard and all the
services are up and running. Once I rebooted the box, all my settings are
That is correct. Devstack is primarily for development. It isn't really
designed to be a production ready system.
Vish
On Jan 26, 2012, at 10:18 PM, nandakumar raghavan wrote:
Hi,
I have similar query. I had installed open stack using devstack on a freshly
installed stand-alone
59 matches
Mail list logo
