Re: [Openstack] swift and disk usage
Hi Paras, Am 08.05.13 22:02, schrieb Paras pradhan: Thanks Christian. How do we keep track of the usage? For example with 5 nodes i.e 40TB. How do we know how much space has been consumed out of this 40TB? well, that depends on the used authentication scheme. If you are using swauth and don't have thousands of users, this gist might help you: https://gist.github.com/cschwede/5559268 It reports the used bytes for every account and the total size. Please note that the returned account list is not sorted. On the other side you can simply monitor all of your disks, sum up all used byte values and divide by the number of replicas (3). You might also use account_quotas, which blocks further write requests if the quota on an account is exceeded. It is especially useful for smaller private storage clusters. http://docs.openstack.org/developer/swift/misc.html#module-swift.common.middleware.account_quotas Christian Paras. On Wed, May 8, 2013 at 2:44 PM, Christian Schwede i...@cschwede.de mailto:i...@cschwede.de wrote: Am 08.05.13 21:18, schrieb Paras pradhan: I have a three nodes swift cluster. I can see the objects being replicated to all three nodes. Each node has 12 2TB disks. Since I have 3 replicas the usable space is only 24TB ? Yes, that's correct. How this will scale up if we add two more storage nodes of the same capacity? 5 * 12 * 2 / 3: ~ 40TB usable capacity. Also, is there any tool to monitor the usage, health of the whole cluster? To detect failed drives you might have a look at http://docs.openstack.org/developer/swift/admin_guide.html#detecting-failed-drives For Swift-related monitoring please refer to http://docs.openstack.org/trunk/openstack-object-storage/admin/content/ch_introduction-to-openstack-object-storage-monitoring.html For general node monitoring you can use your preferred tool (Nagios, Icinga, Shinken, RHQ, Hyperic...). ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Devstack usage in Install Openstack
Hi Dear All I had installed openstack using Devstack so dashboard (horizon) was shown. But how to add my ESXi servers and so on to it ? what is usage of dashboard? is it just a demo?? Or we must configure it to utilize?? Plz help me .if using Devstack is just a demo i should go to install real openstack. Thanks ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Allocating dynamic IP to the VMs
Hello Sylvain, I am sorry I got caught up with another project in the past few weeks, hence my late reply. Please bare with me. The floating ip is bound to the qg-550803ee-ce bridge. root@controller:~# ip a 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP qlen 1000 link/ether d4:ae:52:bb:aa:20 brd ff:ff:ff:ff:ff:ff inet 192.168.2.225/24 brd 192.168.2.255 scope global eth0 inet6 fe80::d6ae:52ff:febb:aa20/64 scope link valid_lft forever preferred_lft forever 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP qlen 1000 link/ether d4:ae:52:bb:aa:21 brd ff:ff:ff:ff:ff:ff inet 10.10.10.1/24 brd 10.10.10.255 scope global eth1 inet6 fe80::d6ae:52ff:febb:aa21/64 scope link valid_lft forever preferred_lft forever 31: br-int: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN link/ether e6:fe:c6:5e:73:47 brd ff:ff:ff:ff:ff:ff 32: br-ex: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN link/ether f6:26:0f:0d:32:45 brd ff:ff:ff:ff:ff:ff inet6 fe80::f426:fff:fe0d:3245/64 scope link valid_lft forever preferred_lft forever 33: tapd648cfe0-f6: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN link/ether fa:16:3e:9a:2c:29 brd ff:ff:ff:ff:ff:ff inet 10.5.5.2/24 brd 10.5.5.255 scope global tapd648cfe0-f6 inet6 fe80::f816:3eff:fe9a:2c29/64 scope link valid_lft forever preferred_lft forever 34: br-tun: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN link/ether 5e:2b:f9:ca:c6:40 brd ff:ff:ff:ff:ff:ff 35: qr-9e818b07-92: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN link/ether fa:16:3e:01:48:1d brd ff:ff:ff:ff:ff:ff inet 10.5.5.1/24 brd 10.5.5.255 scope global qr-9e818b07-92 inet6 fe80::f816:3eff:fe01:481d/64 scope link valid_lft forever preferred_lft forever 36: qg-550803ee-ce: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN link/ether fa:16:3e:fc:87:1c brd ff:ff:ff:ff:ff:ff inet 192.168.2.151/24 brd 192.168.2.255 scope global qg-550803ee-ce inet 192.168.2.152/32 brd 192.168.2.152 scope global qg-550803ee-ce inet6 fe80::f816:3eff:fefc:871c/64 scope link valid_lft forever preferred_lft forever But I can not ping the floating ip. root@controller:~# quantum net-list -- --router:external True +-+--+---+ | id | name | subnets | ++---+---+ | a83c3409-6c79-4bb7-9557-010f3b56024f | ext_net | fb3439f4-2afa-4cdc-86a6-aaee2ce1a3a3 | ++---+---+ root@controller:~# quantum floatingip-list +---+--+++ | id | fixed_ip_address | floating_ip_address | port_id | ++-+++ | 46311a66-5793-43af-be74-612580e505ca | 10.5.5.3 | 192.168.2.152 | 529f6c56-8037-489a-a120-b97675d1745f | +-- -+-+++ Any idea? On 25 March 2013 16:09, Sylvain Bauza sylvain.ba...@digimind.com wrote: Le 25/03/2013 16:00, Chathura M. Sarathchandra Magurawalage a écrit : I can not see anything going through qg- interface. Your iptables seem correct. Could you please ip a and make sure floating ip is bound to qg- ? Are you sure that floating IPs are working properly on your setup ? -Sylvain ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [openstack-community] [Ask] Guidelines for answering question on Ask
Can we have a template? I think it would be really helpful if by default there is a template / form to fill out. Not sure if the underlying software has that mechanism. Basically to do support, it'd really important to know the version used, system. Thoughts? John On Fri, May 10, 2013 at 2:25 AM, Adam Nelson a...@varud.com wrote: This is great work. It might be better though to put the moderator rules on the ask.openstack.org site itself rather than the wiki so that you can link to it in the header without leaving the 'ask' site. Stackoverflow uses the 'faq' as the link in the header for this type of information: http://stackoverflow.com/faq Just my two cents. Cheers, Adam https://twitter.com/varud https://www.linkedin.com/in/adamcnelson On Fri, May 10, 2013 at 6:58 AM, Stefano Maffulli stef...@openstack.orgwrote: Hello folks, now that the traffic on https://ask.openstack.org has increased, I think it's time we start collecting guidelines for the moderators so we keep having a very informative tool, with consistently good questions and answers. I think it helps for example to pay attention to the titles of the questions and make them as explicit and clear as possible. The titles need to look like questions. Good examples are: * Where can I find instructions on how to setup OpenStack Grizzly on VMware Workstation? * How to set up metadata service on a flat network? * Why do I get No portal found error while attaching cinder volume to VM? I have started collecting best practices from Ask Ubuntu, Mozilla and Stackoverflow to be published on this page: https://wiki.openstack.org/**wiki/Community/AskModeratorshttps://wiki.openstack.org/wiki/Community/AskModerators Do you have other examples, guidelines that we can imitate? thanks stef -- Ask and answer questions on https://ask.openstack.org __**_ Community mailing list commun...@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**communityhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Devstack usage in Install Openstack
On Sat, May 11, 2013 at 3:30 AM, Mahzad Zahedi ict.mywork2...@gmail.com wrote: But how to add my ESXi servers and so on to it ? what is usage of dashboard? is it just a demo?? ... Plz help me .if using Devstack is just a demo i should go to install real openstack. DevStack is designed to be a development environment and is also used in the OpenStack integration tests. It should never be used for production. You may be able to configure it to include your ESXi servers but will likely have to do some of that configuration by hand. You should probably consider installing from one of the vendor package sets if you want to operate your setup for any length of time or have plans to eventually open it up to other users, even just for testing. DevStack re-initializes everything from scratch every time you run stack.sh. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A Grizzly GRE failure
So to be clear:
* I have a three nics on my network node. The VM traffic goes out the
1st nic on 192.168.239.99/24 to the other compute nodes, while
management traffic goes out the 2nd nic on 192.168.241.99. The 3rd nic
is external and has no IP.
* I have four GRE endpoints on the VM network, one at the network node
(192.168.239.99) and three on compute nodes
(192.168.239.{110,114,115}), all with IDs 2-5.
* I have a fifth GRE endpoint with id 1 to 192.168.241.99, the network
node's management interface. This was the first tunnel created when I
deployed the network node because that is how I set the remote_ip in
the ovs plugin ini. I corrected the setting later, but the
192.168.241.99 endpoint persists and, as your response implies, *this
extraneous endpoint is the cause of my troubles*.
My next question then is what is happening? My guess:
* I ping a guest from the external network using its floater (10.21.166.4).
* It gets NAT'd at the tenant router on the network node to
192.168.252.3, at which point an arp request is sent over the unified
GRE broadcast domain.
* On a compute node, the arp request is received by the VM, which then
sends a reply to the tenant router's MAC (which I verified with
tcpdumps).
* There are four endpoints for the packet to go down:
Bridge br-tun
Port br-tun
Interface br-tun
type: internal
Port gre-1
Interface gre-1
type: gre
options: {in_key=flow, out_key=flow, remote_ip=192.168.241.99}
Port gre-4
Interface gre-4
type: gre
options: {in_key=flow, out_key=flow,
remote_ip=192.168.239.114}
Port gre-3
Interface gre-3
type: gre
options: {in_key=flow, out_key=flow,
remote_ip=192.168.239.110}
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port gre-2
Interface gre-2
type: gre
options: {in_key=flow, out_key=flow, remote_ip=192.168.239.99}
Here's where I get confused. Does it know that gre-1 is a different
broadcast domain than the others, or does is see all endpoints as the
same domain?
What happens here? Is this the cause of my network timeouts on
external connections to the VMs? Does this also explain the sporadic
nature of the timeouts, why they aren't consistent in frequency or
duration?
Finally, what happens when I remove the oddball endpoint from the DB?
Sounds risky!
Thanks for your help
--Greg Chavez
On Fri, May 10, 2013 at 7:17 PM, Darragh O'Reilly
dara2002-openst...@yahoo.com wrote:
I'm not sure how to rectify that. You may have to delete the bad row from the
DB and restart the agents:
mysql use quantum;
mysql select * from ovs_tunnel_endpoints;
...
On Fri, May 10, 2013 at 6:43 PM, Greg Chavez greg.cha...@gmail.com wrote:
I'm refactoring my question once again (see A Grizzly arping
failure and Failure to arp by quantum router).
Quickly, the problem is in a multi-node Grizzly+Raring setup with a
separate network node and a dedicated VLAN for VM traffic. External
connections time out within a minute and dont' resume until traffic is
initiated from the VM.
I got some rather annoying and hostile assistance just now on IRC and
while it didn't result in a fix, it got me to realize that the problem
is possibly with my GRE setup.
I made a mistake when I originally set this up, assigning the mgmt
interface of the network node (192.168.241.99) as its GRE remote_ip
instead if the vm_config network interface (192.168.239.99). I
realized my mistake and reconfigured the OVS plugin on the network
node and moved one. But now, taking a look at my OVS bridges on the
network node, I see that the old remote IP is still there!
Bridge br-tun
snip
Port gre-1
Interface gre-1
type: gre
options: {in_key=flow, out_key=flow,
remote_ip=192.168.241.99}
snip
This is also on all the compute nodes.
( Full ovs-vsctl show output here: http://pastebin.com/xbre1fNV)
What's more, I have this error every time I restart OVS:
2013-05-10 18:21:24ERROR [quantum.agent.linux.ovs_lib] Unable to
execute ['ovs-vsctl', '--timeout=2', 'add-port', 'br-tun', 'gre-5'].
Exception:
Command: ['sudo', 'quantum-rootwrap', '/etc/quantum/rootwrap.conf',
'ovs-vsctl', '--timeout=2', 'add-port', 'br-tun', 'gre-5']
Exit code: 1
Stdout: ''
Stderr: 'ovs-vsctl: cannot create a port named gre-5 because a port
named gre-5 already exists on bridge br-tun\n'
Could that be because grep-1 is vestigial and possibly fouling up the
works by creating two possible paths for VM traffic?
Is it as simple as removing it with ovs-vsctl or is something else required?
Or is this actually needed for some reason? Argh... help!
Re: [Openstack] API version in Grizzly
Thanks! Gabriel. I understood. Devendra On 10-May-13 11:46 PM, Gabriel Hurley wrote: When you say Identity v3.0 development is going on side-by-side so I think if I have Grizzly setup with Identity v2.0 then it'll be upgraded to Identity v3.0 with Grizzly when new version is available in updates. Though I might have option to upgrade it or not? OR Identity v3.0 will be released with Havana ? I believe you're still a little confused by what it means to upgrade to an API. The API version(s) are an inherent part of a particular release. Grizzly features both v2.0 and v3 Keystone APIs. They're both there. It's up to you when you want to upgrade to it by changing your endpoints, scripts, clients, etc. to take advantage of the new API. There will be further refinements in Havana, but v3 is here now. Another thing looks confusing to me in API Specification page http://docs.openstack.org/api/api-specs.html, we have version number mentioned with v1.0/v2.0 for some components (e.g. Object, Identity, Networking) but v1/v2 for few others (e.g. Image, Compute). Is there any special reason to not put .0 in version for some components ? The inconsistency is legitimate, not merely an oversight. Keystone dropped the .0 for the major versions in its URL structure. As such you would use http://host:5000/v2.0/ for v2.0 and http://host:5000/v3/ for the v3 API. Other services have chosen to include or exclude the .0 as they see fit. Unfortunately right now you just have to look up what the proper numbering format is for a particular API. All the best, - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] New code name for networks
Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net wrote: Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Davanum Srinivas :: http://davanum.wordpress.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
Tyronosaurus Rex Optimus Prime Super Happy Fun Network Times A.N.A.L. - Automated Networking and Logistics And with that I am out of ideas. On Sat, May 11, 2013 at 12:58 PM, Davanum Srinivas dava...@gmail.comwrote: Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net wrote: Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Davanum Srinivas :: http://davanum.wordpress.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
I have been arguing for: mutnuaq Granted, it takes a minute to learn how to type, but it's just a little snarky, and it takes up the exact same number of letter. However, it does screw with sorting. SO - what about: qumutna It's a little bit easier to wrap your head around, it's still clearly an homage, and it should be super easy to bulk cut/replace. On 05/11/2013 03:58 PM, Davanum Srinivas wrote: Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net wrote: Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
Or even better, just continue to call it openstack networking. The code names only serve to confuse the uninitiated. They needlessly steepen the learning curve and slow uptake. On May 11, 2013 3:59 PM, Davanum Srinivas dava...@gmail.com wrote: Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net wrote: Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Davanum Srinivas :: http://davanum.wordpress.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
On 05/11/2013 04:07 PM, Asher Newcomer wrote: Or even better, just continue to call it openstack networking. The code names only serve to confuse the uninitiated. They needlessly steepen the learning curve and slow uptake. The problem with OpenStack Networking (or getting rid of codenames) is seen with pre-incubation-incubation-integrated cycle. A project cannot call itself OpenStack Foo until it actually _is_ openstack foo. So any new project by necessity has to start off as something else. But - if we then require them to drop that name and become openstack foo when they become incubated or integrated, then we've got what's become a stable project with a decent amount of contributors renaming itself. Every. Time. The code names aren't just cute. I kind of wish they were, because it would make several things much easier if we could just ditch them and do a pure openstack. code namespace. But the reality is that it gets really really tricky to deal with a bunch of things if they go away. On May 11, 2013 3:59 PM, Davanum Srinivas dava...@gmail.com mailto:dava...@gmail.com wrote: Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net mailto:m...@amerine.net wrote: Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com mailto:jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Davanum Srinivas :: http://davanum.wordpress.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
Jeremy Stanly on IRC just suggested kumquat... but to that I respond: qumkuat Same benefits as qumutna - except it's more pronouncable. On 05/11/2013 04:07 PM, Monty Taylor wrote: I have been arguing for: mutnuaq Granted, it takes a minute to learn how to type, but it's just a little snarky, and it takes up the exact same number of letter. However, it does screw with sorting. SO - what about: qumutna It's a little bit easier to wrap your head around, it's still clearly an homage, and it should be super easy to bulk cut/replace. On 05/11/2013 03:58 PM, Davanum Srinivas wrote: Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net wrote: Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
Réseaux or a translation for networks in some other language (maybe networks in Chinese as Havana will be released in HKG) -- just thinking international ;-) Best Regards MoE/// On May 11, 2013, at 4:07 PM, Monty Taylor mord...@inaugust.com wrote: I have been arguing for: mutnuaq Granted, it takes a minute to learn how to type, but it's just a little snarky, and it takes up the exact same number of letter. However, it does screw with sorting. SO - what about: qumutna It's a little bit easier to wrap your head around, it's still clearly an homage, and it should be super easy to bulk cut/replace. On 05/11/2013 03:58 PM, Davanum Srinivas wrote: Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net wrote: Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Guest PXE Boot
Neat!
Have you seen any of the work around nova baremetal (which is
transitioning to be called ironic?) Related to that is a set of virtual
power drivers which allow for treating virtual machines like real
machines - so that you can use nova to pxe boot a kvm or a virtualbox or
a vmware instance.
I know it's not exactly the same thing, but I don't know what you're
trying to accomplish. Perhaps what you want is similar enough to work
together?
Monty
On 05/10/2013 12:55 PM, David Hill wrote:
Hi guys,
I was trying to PXE boot a guest for quite some time now and I think
I’ve found a solution that is kind of hackish but pretty simple. I’m
not quite sure it’s good to go in trunk but felt like I’d share it since
I’ve been messing a while on this.
If anybody have a better solution, I would really like to hear/see/try it …
Here is how I did it:
First, patch the libvirt/driver.py file:
--- /usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py.orig
2013-05-10 16:25:17.787862177 +
+++ /usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py
2013-05-10 16:26:39.442022870 +
@@ -87,6 +87,9 @@
LOG = logging.getLogger(__name__)
libvirt_opts = [
+cfg.StrOpt('default_guest_boot_dev',
+ default='hd',
+ help='Sets the default guest boot device'),
cfg.StrOpt('rescue_image_id',
default=None,
help='Rescue ami image'),
@@ -1792,7 +1795,7 @@
instance['name'],
ramdisk)
else:
-guest.os_boot_dev = hd
+guest.os_boot_dev = FLAGS.default_guest_boot_dev
if FLAGS.libvirt_type != lxc and FLAGS.libvirt_type != uml:
guest.acpi = True
And add to nova.conf:
default_guest_boot_dev=network
And finally add to /etc/dnsmasq.conf
dhcp-boot=boot\x86\pxelinux.com,host_name,host_ip
dhcp-no-override
And restart dnsmasq.conf
In my actual setup, the guest will PXE boot, show the menu 60 seconds
and then boot from hard disk after the 60 seconds timeout.
Thank you very much,
Dave
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack Marketing] New code name for networks
Octopus ~sean On May 11, 2013, at 12:57 PM, Jason Smith jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Marketing mailing list market...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/marketing ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
On Sat, May 11, 2013 at 3:12 PM, Monty Taylor mord...@inaugust.com wrote: On 05/11/2013 04:07 PM, Asher Newcomer wrote: Or even better, just continue to call it openstack networking. The code names only serve to confuse the uninitiated. They needlessly steepen the learning curve and slow uptake. The problem with OpenStack Networking (or getting rid of codenames) is seen with pre-incubation-incubation-integrated cycle. A project cannot call itself OpenStack Foo until it actually _is_ openstack foo. So any new project by necessity has to start off as something else. But - if we then require them to drop that name and become openstack foo when they become incubated or integrated, then we've got what's become a stable project with a decent amount of contributors renaming itself. Every. Time. The code names aren't just cute. I kind of wish they were, because it would make several things much easier if we could just ditch them and do a pure openstack. code namespace. But the reality is that it gets really really tricky to deal with a bunch of things if they go away. I told Monty and the TC this at the Summit (sorry I couldn't attend the session about code names). I find this trickiness a weak argument in the face of the invented names that are getting to be as bad as U.S. pharmaceuticals. Plus it forces us to put a lookup table in the docs forever. [1] Let's find a process for naming that meets a few reqs: - describes the service - goes through a legal review - enables new eyes to understanding it by reading the English word that the service represents (that can be translated into a meaningful word in other languages) If we have to preface with Stackforge to indicate pre-incubation, that's fine. Use Incubating or some such to indicate incubation. Meaningful words have meaning. I acknowledge we still have to indicate what commands, daemon names, and so on are related to a particular service. That issue is also fixable with some resources and effort and pays off in easier adoption and understanding. Anne 1. http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/terminology-codenames.html On May 11, 2013 3:59 PM, Davanum Srinivas dava...@gmail.com mailto:dava...@gmail.com wrote: Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net mailto:m...@amerine.net wrote: Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com mailto:jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Davanum Srinivas :: http://davanum.wordpress.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
On 2013-05-11 16:13:39 -0400 (-0400), Monty Taylor wrote: Jeremy Stanly on IRC just suggested kumquat... [...] Only because I find them extremely tasty and fun to pronounce. -- Jeremy Stanley ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
Anne, Here's the guidance provided by ASF for their Incubator Podlings which can be used to come up with a process of our own. http://incubator.apache.org/guides/names.html -- dims On Sat, May 11, 2013 at 5:48 PM, Anne Gentle a...@openstack.org wrote: On Sat, May 11, 2013 at 3:12 PM, Monty Taylor mord...@inaugust.com wrote: On 05/11/2013 04:07 PM, Asher Newcomer wrote: Or even better, just continue to call it openstack networking. The code names only serve to confuse the uninitiated. They needlessly steepen the learning curve and slow uptake. The problem with OpenStack Networking (or getting rid of codenames) is seen with pre-incubation-incubation-integrated cycle. A project cannot call itself OpenStack Foo until it actually _is_ openstack foo. So any new project by necessity has to start off as something else. But - if we then require them to drop that name and become openstack foo when they become incubated or integrated, then we've got what's become a stable project with a decent amount of contributors renaming itself. Every. Time. The code names aren't just cute. I kind of wish they were, because it would make several things much easier if we could just ditch them and do a pure openstack. code namespace. But the reality is that it gets really really tricky to deal with a bunch of things if they go away. I told Monty and the TC this at the Summit (sorry I couldn't attend the session about code names). I find this trickiness a weak argument in the face of the invented names that are getting to be as bad as U.S. pharmaceuticals. Plus it forces us to put a lookup table in the docs forever. [1] Let's find a process for naming that meets a few reqs: - describes the service - goes through a legal review - enables new eyes to understanding it by reading the English word that the service represents (that can be translated into a meaningful word in other languages) If we have to preface with Stackforge to indicate pre-incubation, that's fine. Use Incubating or some such to indicate incubation. Meaningful words have meaning. I acknowledge we still have to indicate what commands, daemon names, and so on are related to a particular service. That issue is also fixable with some resources and effort and pays off in easier adoption and understanding. Anne 1. http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/terminology-codenames.html On May 11, 2013 3:59 PM, Davanum Srinivas dava...@gmail.com mailto:dava...@gmail.com wrote: Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net mailto:m...@amerine.net wrote: Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com mailto:jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Davanum Srinivas :: http://davanum.wordpress.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Davanum Srinivas :: http://davanum.wordpress.com ___ Mailing list:
Re: [Openstack] New code name for networks
quark Keeps the sciency theme going, same first two letters, and represents something fundamental to other sciency stuff (much like networking is fundamental to OpenStack). http://en.wikipedia.org/wiki/Quark -Dave On May 11, 2013, at 4:13 PM, Monty Taylor mord...@inaugust.com wrote: Jeremy Stanly on IRC just suggested kumquat... but to that I respond: qumkuat Same benefits as qumutna - except it's more pronouncable. On 05/11/2013 04:07 PM, Monty Taylor wrote: I have been arguing for: mutnuaq Granted, it takes a minute to learn how to type, but it's just a little snarky, and it takes up the exact same number of letter. However, it does screw with sorting. SO - what about: qumutna It's a little bit easier to wrap your head around, it's still clearly an homage, and it should be super easy to bulk cut/replace. On 05/11/2013 03:58 PM, Davanum Srinivas wrote: Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net wrote: Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
Same first THREE letters actually. Bonus points. On May 11, 2013, at 7:07 PM, David Shrewsbury shrewsbury.d...@gmail.com wrote: quark Keeps the sciency theme going, same first two letters, and represents something fundamental to other sciency stuff (much like networking is fundamental to OpenStack). http://en.wikipedia.org/wiki/Quark -Dave On May 11, 2013, at 4:13 PM, Monty Taylor mord...@inaugust.com wrote: Jeremy Stanly on IRC just suggested kumquat... but to that I respond: qumkuat Same benefits as qumutna - except it's more pronouncable. On 05/11/2013 04:07 PM, Monty Taylor wrote: I have been arguing for: mutnuaq Granted, it takes a minute to learn how to type, but it's just a little snarky, and it takes up the exact same number of letter. However, it does screw with sorting. SO - what about: qumutna It's a little bit easier to wrap your head around, it's still clearly an homage, and it should be super easy to bulk cut/replace. On 05/11/2013 03:58 PM, Davanum Srinivas wrote: Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net wrote: Tubes ;-) On Sat, May 11, 2013 at 12:51 PM, Jason Smith jason.sm...@rackspace.com wrote: Hello, I understand why we had to give up Quantum code name but rather than just refer to it as networking let's come up with a new code name! Thoughts? Thanks, -js ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
On 05/11/2013 05:48 PM, Anne Gentle wrote: On Sat, May 11, 2013 at 3:12 PM, Monty Taylor mord...@inaugust..com mailto:mord...@inaugust.com wrote: On 05/11/2013 04:07 PM, Asher Newcomer wrote: Or even better, just continue to call it openstack networking. The code names only serve to confuse the uninitiated. They needlessly steepen the learning curve and slow uptake. The problem with OpenStack Networking (or getting rid of codenames) is seen with pre-incubation-incubation-integrated cycle. A project cannot call itself OpenStack Foo until it actually _is_ openstack foo. So any new project by necessity has to start off as something else. But - if we then require them to drop that name and become openstack foo when they become incubated or integrated, then we've got what's become a stable project with a decent amount of contributors renaming itself. Every. Time. The code names aren't just cute. I kind of wish they were, because it would make several things much easier if we could just ditch them and do a pure openstack. code namespace. But the reality is that it gets really really tricky to deal with a bunch of things if they go away. I told Monty and the TC this at the Summit (sorry I couldn't attend the session about code names). I promise, it wasn't the world's most fun session. :) I find this trickiness a weak argument in the face of the invented names that are getting to be as bad as U.S. pharmaceuticals. Plus it forces us to put a lookup table in the docs forever. [1] Let's find a process for naming that meets a few reqs: - describes the service - goes through a legal review - enables new eyes to understanding it by reading the English word that the service represents (that can be translated into a meaningful word in other languages) I don't think it's a weak argument at all. There are real technical issues. That assumes that OpenStack is involved with the project pre-incubation. That's was the case with Quantum and Ceilometer and Ironic. On the other hand, the heat folks had heat-api.org and a heat github org and other things before they started down the stackforge road. Looking right now at non-incubated projects just off the top of my head: Libra is an LBaaS solution that was started on stackforge and which it's increasingly unlikely will go to incubation rather than just atttempt to merge stuff in with Quantum LBaaS. Moniker is a DNSaaS that hasn't applied for incubation, might do so, but as of right now has been around for almost a year yet has no formal relationship with OpenStack. healthnmon may or may not be an incubation candidate. Before that, reddwarf was not-incubated for pretty much the entire time OpenStack has existed until just now. All of these things have had to have lifecycles during a period of time before they have any interaction with us formally. On the other hand, if we did checking pre-incubation, we'd be in a very odd position of granting permission/blessing/tentative interest in projects before they come close to sorting things out. Moniker is great, but 6 months ago there were as many as 4 different DNSaaS possibilities. In any case, I don't think there is any way that we can, become directly involved in projects before they are incubated. Stackforge helps already, in that moniker is stackforge/moniker rather than openstack/moniker. But neither has any effect on the fact that there is a directory named moniker in moniker repository. If we go with 'descriptive' names, then there are two choices: a) moniker starts life with a directory structure underneath openstack/dns inside of its repository, even though it is not an openstack project. b) moniker starts life with a moniker directory, and then when incubated, renames that directory from moniker to openstack/dns. We can't stop anybody from doing (a) of course, but let me tell you - you wanna talk about confusing and bad messaging - we had apt repos at the beginning of the project with giant letters on them FOR TESTING ONLY but because they had our name on them people assumed we supported them. (b) sound easy, until you reckon with things like line-wrapping changes, sort order changes, and client library/API consumption changes. If something is using python-monikerclient and thus the monikerclient namespace of the API, that person would have to port their code to now do something like openstack.dns.client or similar. Even ignoring people who may have already been using the code (many of these things start life as a service by one of our member companies and then enters incubation when it's become baked a little bit - reddwarf was in production at RAX and HP before it got incubated, moniker is in production at HP, etc) and just focusing on our own code base, the massive undertaking that it is to change the name of the project inside of the project is daunting enough that we're
Re: [Openstack] New code name for networks
On 05/11/2013 01:07 PM, Monty Taylor wrote: I have been arguing for: mutnuaq As someone who named a netperf test MAERTS because it transfered data the opposite direction as the STREAM test, I'm good with that. If that does not work, with Quantum being something of Spooky networking at a distance - perhaps something else in the realm of quantum physics? rick jones ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
On Sat, May 11, 2013 at 6:43 PM, Monty Taylor mord...@inaugust.com wrote: On 05/11/2013 05:48 PM, Anne Gentle wrote: On Sat, May 11, 2013 at 3:12 PM, Monty Taylor mord...@inaugust..com mailto:mord...@inaugust.com wrote: On 05/11/2013 04:07 PM, Asher Newcomer wrote: Or even better, just continue to call it openstack networking. The code names only serve to confuse the uninitiated. They needlessly steepen the learning curve and slow uptake. The problem with OpenStack Networking (or getting rid of codenames) is seen with pre-incubation-incubation-integrated cycle. A project cannot call itself OpenStack Foo until it actually _is_ openstack foo. So any new project by necessity has to start off as something else. But - if we then require them to drop that name and become openstack foo when they become incubated or integrated, then we've got what's become a stable project with a decent amount of contributors renaming itself. Every. Time. The code names aren't just cute. I kind of wish they were, because it would make several things much easier if we could just ditch them and do a pure openstack. code namespace. But the reality is that it gets really really tricky to deal with a bunch of things if they go away. I told Monty and the TC this at the Summit (sorry I couldn't attend the session about code names). I promise, it wasn't the world's most fun session. :) I'm sure. :) I think I don't have much regret but do feel sorry that I don't know more. I find this trickiness a weak argument in the face of the invented names that are getting to be as bad as U.S. pharmaceuticals. Plus it forces us to put a lookup table in the docs forever. [1] Let's find a process for naming that meets a few reqs: - describes the service - goes through a legal review - enables new eyes to understanding it by reading the English word that the service represents (that can be translated into a meaningful word in other languages) I don't think it's a weak argument at all. There are real technical issues. The technical issues, to me, and I may be missing something, are when the name is used as: - service/daemon name - command/CLI name You can use any pet name you want for your team and project while addressing technical issues some other way? Here's another way I'm looking at the naming autonomy/process. Why incubate? - you get to pick your cool name OR - you get access to infrastructure, tools, events, community, and branding that is OpenStack The naming can't be THAT crucial. I get that we want projects to be fun to work on. But it can't be just the naming that brings the fun. I think you believe I have some strict naming process in mind, so I'm trying to explain my position more. It's more that I believe we can have team/project names without naming technical things (repositories, CLIs) with that cool/fun name. Go with kumquat, but don't call the CLI kumquat. Call your team kumquat and your repo kumquat. That assumes that OpenStack is involved with the project pre-incubation. That's was the case with Quantum and Ceilometer and Ironic. On the other hand, the heat folks had heat-api.org and a heat github org and other things before they started down the stackforge road. Looking right now at non-incubated projects just off the top of my head: Libra is an LBaaS solution that was started on stackforge and which it's increasingly unlikely will go to incubation rather than just atttempt to merge stuff in with Quantum LBaaS. Moniker is a DNSaaS that hasn't applied for incubation, might do so, but as of right now has been around for almost a year yet has no formal relationship with OpenStack. healthnmon may or may not be an incubation candidate. Before that, reddwarf was not-incubated for pretty much the entire time OpenStack has existed until just now. All of these things have had to have lifecycles during a period of time before they have any interaction with us formally. On the other hand, if we did checking pre-incubation, we'd be in a very odd position of granting permission/blessing/tentative interest in projects before they come close to sorting things out. Moniker is great, but 6 months ago there were as many as 4 different DNSaaS possibilities. In any case, I don't think there is any way that we can, become directly involved in projects before they are incubated. Stackforge helps already, in that moniker is stackforge/moniker rather than openstack/moniker. But neither has any effect on the fact that there is a directory named moniker in moniker repository. If we go with 'descriptive' names, then there are two choices: a) moniker starts life with a directory structure underneath openstack/dns inside of its repository, even though it is not an openstack project. b) moniker starts life with a moniker directory,
Re: [Openstack] New code name for networks
How about netstack? We had originally coined this name for the collection of quantum, melange, and donabe services. Melange got folded into Quantum, so we stopped using netstack. But Quantum today is actually a collection of network services, both for network connectivity, and also for more advanced services like loadbalancers and firewall. So netstack might be appropriate. Thanks, ~Sumit. On Sat, May 11, 2013 at 5:58 PM, Anne Gentle a...@openstack.org wrote: On Sat, May 11, 2013 at 6:43 PM, Monty Taylor mord...@inaugust.com wrote: On 05/11/2013 05:48 PM, Anne Gentle wrote: On Sat, May 11, 2013 at 3:12 PM, Monty Taylor mord...@inaugust..com mailto:mord...@inaugust.com wrote: On 05/11/2013 04:07 PM, Asher Newcomer wrote: Or even better, just continue to call it openstack networking. The code names only serve to confuse the uninitiated. They needlessly steepen the learning curve and slow uptake. The problem with OpenStack Networking (or getting rid of codenames) is seen with pre-incubation-incubation-integrated cycle. A project cannot call itself OpenStack Foo until it actually _is_ openstack foo. So any new project by necessity has to start off as something else. But - if we then require them to drop that name and become openstack foo when they become incubated or integrated, then we've got what's become a stable project with a decent amount of contributors renaming itself. Every. Time. The code names aren't just cute. I kind of wish they were, because it would make several things much easier if we could just ditch them and do a pure openstack. code namespace. But the reality is that it gets really really tricky to deal with a bunch of things if they go away. I told Monty and the TC this at the Summit (sorry I couldn't attend the session about code names). I promise, it wasn't the world's most fun session. :) I'm sure. :) I think I don't have much regret but do feel sorry that I don't know more. I find this trickiness a weak argument in the face of the invented names that are getting to be as bad as U.S. pharmaceuticals. Plus it forces us to put a lookup table in the docs forever. [1] Let's find a process for naming that meets a few reqs: - describes the service - goes through a legal review - enables new eyes to understanding it by reading the English word that the service represents (that can be translated into a meaningful word in other languages) I don't think it's a weak argument at all. There are real technical issues. The technical issues, to me, and I may be missing something, are when the name is used as: - service/daemon name - command/CLI name You can use any pet name you want for your team and project while addressing technical issues some other way? Here's another way I'm looking at the naming autonomy/process. Why incubate? - you get to pick your cool name OR - you get access to infrastructure, tools, events, community, and branding that is OpenStack The naming can't be THAT crucial. I get that we want projects to be fun to work on. But it can't be just the naming that brings the fun. I think you believe I have some strict naming process in mind, so I'm trying to explain my position more. It's more that I believe we can have team/project names without naming technical things (repositories, CLIs) with that cool/fun name. Go with kumquat, but don't call the CLI kumquat. Call your team kumquat and your repo kumquat. That assumes that OpenStack is involved with the project pre-incubation. That's was the case with Quantum and Ceilometer and Ironic. On the other hand, the heat folks had heat-api.org and a heat github org and other things before they started down the stackforge road. Looking right now at non-incubated projects just off the top of my head: Libra is an LBaaS solution that was started on stackforge and which it's increasingly unlikely will go to incubation rather than just atttempt to merge stuff in with Quantum LBaaS. Moniker is a DNSaaS that hasn't applied for incubation, might do so, but as of right now has been around for almost a year yet has no formal relationship with OpenStack. healthnmon may or may not be an incubation candidate. Before that, reddwarf was not-incubated for pretty much the entire time OpenStack has existed until just now. All of these things have had to have lifecycles during a period of time before they have any interaction with us formally. On the other hand, if we did checking pre-incubation, we'd be in a very odd position of granting permission/blessing/tentative interest in projects before they come close to sorting things out. Moniker is great, but 6 months ago there were as many as 4 different DNSaaS possibilities. In any case, I don't think there is any way that we can, become directly involved in
Re: [Openstack] New code name for networks
On May 11, 2013, at 10:02 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: How about netstack? We had originally coined this name for the collection of quantum, melange, and donabe services. Melange got folded into Quantum, so we stopped using netstack. If you want to start re-naming everything in OpenStack to be SomethingStack, I guess you could do that. But then you run into lots of potential conflicts with all the other packages, tools, products, etc... that want to use stack in their name. To me, a stack is a collection of related but not necessarily all required objects, so the name OpenStack makes total sense. NetStack would make sense if there were a number of related objects that comprised the whole, but if you're going to fold them all into Quantum/Kumquat/Qumkwat/Quark/Quartum/Q-whatever-tum, and they're all going to be part of one larger unified service, then I'm not so sure that it would make sense to me anymore. IMO, you really only have two valid options here: 1. Stick with something that is more or less like what has been done before (albeit with more attention paid to the potential trademark infringement issues) 2. Switch everything over to OpenStack Something, which permanently removes all possibility of confusion, at least once the project has been adopted The sticky wicket is what you do during the transition phase. -- Brad Knowles bknow...@momentumsi.com Senior Consultant ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
On May 11, 2013, at 10:02 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: How about netstack? We had originally coined this name for the collection of quantum, melange, and donabe services. Melange got folded into Quantum, so we stopped using netstack. If you want to start re-naming everything in OpenStack to be SomethingStack, I guess you could do that. But then you run into lots of potential conflicts with all the other packages, tools, products, etc... that want to use stack in their name. To me, a stack is a collection of related but not necessarily all required objects, so the name OpenStack makes total sense. NetStack would make sense if there were a number of related objects that comprised the whole, but if you're going to fold them all into Quantum/Kumquat/Qumkwat/Quark/Quartum/Q-whatever-tum, and they're all going to be part of one larger unified service, then I'm not so sure that it would make sense to me anymore. IMO, you really only have two valid options here: 1. Stick with something that is more or less like what has been done before (albeit with more attention paid to the potential trademark infringement issues) 2. Switch everything over to OpenStack Something, which permanently removes all possibility of confusion, at least once the project has been adopted The sticky wicket is what you do during the transition phase. -- Brad Knowles bknow...@momentumsi.com Senior Consultant ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
Hi all: I actually like Quantum. I think that name has embedded into my brain for so long that I often refuse to look at an alternative name. What's the reason? Did I miss out the actual reason behind it? Anyway, I propose *Neptune.* 1. It has the net sound in it, and 2. Neptune as God of Sea. Without water we can't live. Also water has given us the ability to travel (think of rise of civilization and exploration). Our machines float via pipes (wires) like rivers. Best, John On Sun, May 12, 2013 at 1:17 AM, Brad Knowles bknow...@momentumsi.comwrote: On May 11, 2013, at 10:02 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: How about netstack? We had originally coined this name for the collection of quantum, melange, and donabe services. Melange got folded into Quantum, so we stopped using netstack. If you want to start re-naming everything in OpenStack to be SomethingStack, I guess you could do that. But then you run into lots of potential conflicts with all the other packages, tools, products, etc... that want to use stack in their name. To me, a stack is a collection of related but not necessarily all required objects, so the name OpenStack makes total sense. NetStack would make sense if there were a number of related objects that comprised the whole, but if you're going to fold them all into Quantum/Kumquat/Qumkwat/Quark/Quartum/Q-whatever-tum, and they're all going to be part of one larger unified service, then I'm not so sure that it would make sense to me anymore. IMO, you really only have two valid options here: 1. Stick with something that is more or less like what has been done before (albeit with more attention paid to the potential trademark infringement issues) 2. Switch everything over to OpenStack Something, which permanently removes all possibility of confusion, at least once the project has been adopted The sticky wicket is what you do during the transition phase. -- Brad Knowles bknow...@momentumsi.com Senior Consultant ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: precise_havana_cinder_trunk #49
Title: precise_havana_cinder_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_havana_cinder_trunk/49/Project:precise_havana_cinder_trunkDate of build:Sat, 11 May 2013 02:00:22 -0400Build duration:1 min 21 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesChange the type of free_capacity_gb to be floatby revieweditcinder/volume/drivers/huawei/huawei_iscsi.pyeditcinder/tests/test_huawei.pyConsole Output[...truncated 1406 lines...]patching file tools/pip-requiresHunk #1 FAILED at 17.1 out of 1 hunk FAILED -- rejects in file tools/pip-requiresPatch fix_cinder_dependencies.patch can be reverse-appliedERROR:root:Error occurred during package creation/build: Command '['/usr/bin/schroot', '-p', '-r', '-c', 'precise-amd64-218516ce-57da-4c4d-ab5d-cefcbce0c95d', '-u', 'jenkins', '--', 'bzr', 'builddeb', '-S', '--', '-sa', '-us', '-uc']' returned non-zero exit status 3ERROR:root:Command '['/usr/bin/schroot', '-p', '-r', '-c', 'precise-amd64-218516ce-57da-4c4d-ab5d-cefcbce0c95d', '-u', 'jenkins', '--', 'bzr', 'builddeb', '-S', '--', '-sa', '-us', '-uc']' returned non-zero exit status 3INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/cinder/havana /tmp/tmpR15fhx/cindermk-build-deps -i -r -t apt-get -y /tmp/tmpR15fhx/cinder/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log d0b5b93fe7611b35a8c6a9b09f46641f4fb859f4..HEAD --no-merges --pretty=format:[%h] %sdch -b -D precise --newversion 1:2013.2+git201305110200~precise-0ubuntu1 Automated Ubuntu testing build:dch -a [59fc6cb] Change the type of "free_capacity_gb" to be floatdch -a [4580ee9] Add missing spaces to iscsi_iotype helpdch -a [caeb4a2] Fix missing spaces in Huawei Loggingdch -a [d75fafa] Add pylint-based lintstack test to tox environmentdch -a [7dad062] Remove outdated cinder test docdch -a [7996aaa] Update import of oslo's processutils.dch -a [54a2ee4] Fix ability to add custom volume_backend_namedch -a [cb3fb51] Add db client packages to dev env setup doc.dch -a [db991e6] Remove old_name from kwargs when using IET helper.dch -a [d52a0f2] Copy the RHEL6 eventlet workaround from Oslodch -a [7546682] Remove setuptools-git as run time dependencydch -a [006d673] Fix LHN driver to allow backend name configurationdch -a [0ee20a0] Fixes 3par driver methods that were double lockingdebcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 139, in raise esubprocess.CalledProcessError: Command '['/usr/bin/schroot', '-p', '-r', '-c', 'precise-amd64-218516ce-57da-4c4d-ab5d-cefcbce0c95d', '-u', 'jenkins', '--', 'bzr', 'builddeb', '-S', '--', '-sa', '-us', '-uc']' returned non-zero exit status 3Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwd(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 139, in raise esubprocess.CalledProcessError: Command '['/usr/bin/schroot', '-p', '-r', '-c', 'precise-amd64-218516ce-57da-4c4d-ab5d-cefcbce0c95d', '-u', 'jenkins', '--', 'bzr', 'builddeb', '-S', '--', '-sa', '-us', '-uc']' returned non-zero exit status 3Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: saucy_havana_cinder_trunk #17
Title: saucy_havana_cinder_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/saucy_havana_cinder_trunk/17/Project:saucy_havana_cinder_trunkDate of build:Sat, 11 May 2013 02:00:23 -0400Build duration:1 min 52 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesChange the type of free_capacity_gb to be floatby revieweditcinder/volume/drivers/huawei/huawei_iscsi.pyeditcinder/tests/test_huawei.pyConsole Output[...truncated 2089 lines...]patching file tools/pip-requiresHunk #1 FAILED at 17.1 out of 1 hunk FAILED -- rejects in file tools/pip-requiresPatch fix_cinder_dependencies.patch can be reverse-appliedERROR:root:Error occurred during package creation/build: Command '['/usr/bin/schroot', '-p', '-r', '-c', 'saucy-amd64-3abd3b61-b341-45d3-941b-50d7b5e8a09e', '-u', 'jenkins', '--', 'bzr', 'builddeb', '-S', '--', '-sa', '-us', '-uc']' returned non-zero exit status 3ERROR:root:Command '['/usr/bin/schroot', '-p', '-r', '-c', 'saucy-amd64-3abd3b61-b341-45d3-941b-50d7b5e8a09e', '-u', 'jenkins', '--', 'bzr', 'builddeb', '-S', '--', '-sa', '-us', '-uc']' returned non-zero exit status 3INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/cinder/havana /tmp/tmpk_h_PP/cindermk-build-deps -i -r -t apt-get -y /tmp/tmpk_h_PP/cinder/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log d0b5b93fe7611b35a8c6a9b09f46641f4fb859f4..HEAD --no-merges --pretty=format:[%h] %sdch -b -D saucy --newversion 1:2013.2+git201305110200~saucy-0ubuntu1 Automated Ubuntu testing build:dch -a [59fc6cb] Change the type of "free_capacity_gb" to be floatdch -a [4580ee9] Add missing spaces to iscsi_iotype helpdch -a [caeb4a2] Fix missing spaces in Huawei Loggingdch -a [d75fafa] Add pylint-based lintstack test to tox environmentdch -a [7dad062] Remove outdated cinder test docdch -a [7996aaa] Update import of oslo's processutils.dch -a [54a2ee4] Fix ability to add custom volume_backend_namedch -a [cb3fb51] Add db client packages to dev env setup doc.dch -a [db991e6] Remove old_name from kwargs when using IET helper.dch -a [d52a0f2] Copy the RHEL6 eventlet workaround from Oslodch -a [7546682] Remove setuptools-git as run time dependencydch -a [006d673] Fix LHN driver to allow backend name configurationdch -a [0ee20a0] Fixes 3par driver methods that were double lockingdebcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 139, in raise esubprocess.CalledProcessError: Command '['/usr/bin/schroot', '-p', '-r', '-c', 'saucy-amd64-3abd3b61-b341-45d3-941b-50d7b5e8a09e', '-u', 'jenkins', '--', 'bzr', 'builddeb', '-S', '--', '-sa', '-us', '-uc']' returned non-zero exit status 3Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwd(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 139, in raise esubprocess.CalledProcessError: Command '['/usr/bin/schroot', '-p', '-r', '-c', 'saucy-amd64-3abd3b61-b341-45d3-941b-50d7b5e8a09e', '-u', 'jenkins', '--', 'bzr', 'builddeb', '-S', '--', '-sa', '-us', '-uc']' returned non-zero exit status 3Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: precise_havana_quantum_trunk #107
Title: precise_havana_quantum_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_havana_quantum_trunk/107/Project:precise_havana_quantum_trunkDate of build:Sat, 11 May 2013 04:00:22 -0400Build duration:2 min 46 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesDo not require sudo/rootwrap to check for dnsmasq versionby amigliaccioeditetc/quantum/rootwrap.d/dhcp.filterseditquantum/agent/dhcp_agent.pyeditquantum/tests/unit/test_linux_dhcp.pyeditquantum/agent/linux/dhcp.pyeditquantum/rootwrap/filters.pyConsole Output[...truncated 3335 lines...]dch -a [01a977b] Send 400 error if device specification contains unexpected attributesdch -a [62017cd] Imported Translations from Transifexdch -a [26b98b7] lbaas: check object state before update for pools, members, health monitorsdch -a [49c1c98] Metadata agent: reuse authentication info across eventlet threadsdch -a [11639a2] Imported Translations from Transifexdch -a [35988f1] Make the 'admin' role configurabledch -a [ee50162] Simplify delete_health_monitor() using cascadesdch -a [765baf8] Imported Translations from Transifexdch -a [15a1445] Update latest OSLO codedch -a [343ca18] Imported Translations from Transifexdch -a [c117074] Remove locals() from strings substitutionsdch -a [fb66e24] Imported Translations from Transifexdch -a [e001a8d] Add string 'quantum'/ version to scope/tag in NVPdch -a [5896322] Changed DHCPV6_PORT from 467 to 547, the correct port for DHCPv6.dch -a [80ffdde] Imported Translations from Transifexdch -a [929cbab] Imported Translations from Transifexdch -a [2a24058] Imported Translations from Transifexdch -a [b6f0f68] Imported Translations from Transifexdch -a [1e1c513] Imported Translations from Transifexdch -a [6bbcc38] Imported Translations from Transifexdch -a [bd702cb] Imported Translations from Transifexdch -a [a13295b] Enable automatic validation of many HACKING rules.dch -a [91bed75] Ensure unit tests work with all interface typesdch -a [0446eac] Shorten the path of the nicira nvp plugin.dch -a [8354133] Implement LB plugin delete_pool_health_monitor().dch -a [147038a] Parallelize quantum unit testing:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC quantum_2013.2+git201305110400~precise-0ubuntu1_source.changessbuild -d precise-havana -n -A quantum_2013.2+git201305110400~precise-0ubuntu1.dscTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 139, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'precise-havana', '-n', '-A', 'quantum_2013.2+git201305110400~precise-0ubuntu1.dsc']' returned non-zero exit status 2Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwd(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 139, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'precise-havana', '-n', '-A', 'quantum_2013.2+git201305110400~precise-0ubuntu1.dsc']' returned non-zero exit status 2Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: saucy_havana_quantum_trunk #37
Title: saucy_havana_quantum_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/saucy_havana_quantum_trunk/37/Project:saucy_havana_quantum_trunkDate of build:Sat, 11 May 2013 04:00:23 -0400Build duration:6 min 30 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesDo not require sudo/rootwrap to check for dnsmasq versionby amigliaccioeditetc/quantum/rootwrap.d/dhcp.filterseditquantum/tests/unit/test_linux_dhcp.pyeditquantum/rootwrap/filters.pyeditquantum/agent/dhcp_agent.pyeditquantum/agent/linux/dhcp.pyConsole Output[...truncated 14704 lines...]dch -a [6a5edbc] Create a common function for method _parse_network_vlan_ranges used by plugins.dch -a [791e220] Imported Translations from Transifexdch -a [a397df3] Don't run metadata proxy when it is not neededdch -a [8a9e7ac] in dhcp_agent, always use quantum.conf root_helperdch -a [6d26dd5] Fix usage of SQLAlchemy Query.first() methoddch -a [f8f2a7f] Fix usage of NexusPortBindingNotFound exceptiondch -a [0e49ad3] Imported Translations from Transifexdch -a [9751562] Avoid extra queries when retrieving routersdch -a [3640328] Log a warning if dnsmasq version is below the minimum requireddch -a [6db5b0b] Change Daemon class to better match process command lines.dch -a [fa69228] Improve checking of return values for functions in linuxbridge agent plugindch -a [3bf88f4] Imported Translations from Transifexdch -a [09dd1ec] Validate that netaddr does not receive a string with whitespacedch -a [4056e8e] Import recent rootwrap features in local rootwrapdch -a [17336b9] Fix 500 raised on disassociate_floatingips when out of syncdch -a [9b2fb56] Update import of oslo's processutils.dch -a [6acbc05] Calculate nicira plugin NAT rules order according to CIDR prefixdch -a [ea29aeb] Log msg for load policy file only if the file is actually loadeddch -a [0fee496] Fetch routers ports for metadata access from DBdch -a [31946eb] update-port error if port does not exist in nvpdch -a [3ba9b98] blueprint cisco-plugin-exception-handlingdch -a [2db451d] Imported Translations from Transifexdch -a [87d0f81] Duplicate line in Brocade plugindch -a [9051f68] Imported Translations from Transifexdch -a [6f01194] Perform a joined query for ports and security group associationsdch -a [9581e5b] Copy the RHEL6 eventlet workaround from Oslodebcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC quantum_2013.2+git201305110400~saucy-0ubuntu1_source.changessbuild -d saucy-havana -n -A quantum_2013.2+git201305110400~saucy-0ubuntu1.dscTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 139, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'saucy-havana', '-n', '-A', 'quantum_2013.2+git201305110400~saucy-0ubuntu1.dsc']' returned non-zero exit status 2Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwd(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 139, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'saucy-havana', '-n', '-A', 'quantum_2013.2+git201305110400~saucy-0ubuntu1.dsc']' returned non-zero exit status 2Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
