Re: [Openstack] [Openstack :: Folsom] Quantum DHCP Agent in Compute HOST

[balaji patnala]

Hi Salvatore,

Just want to understand more on Network Node in the below given app_demo
page.

As i see in the setup, it looks like there will be one Quantum Network Node
for one Data centre setup. Please correct me if my assumptions are wrong.

This Quantum Network Node will have all the virtual routers, gateway which
can be created with quantum-l3-agent plugin.

Also my assumption is that this quantum Network Node will serve all the
Tenant virtual gateways and routers created using quantum.

Please give us some more information on this to understand the setup.

Also do we have any specific reason for having quantum Network Node instead
of keeping these plugin on the Controller Node similar to earlier release
like Essex.

Thanks in advance.

Regards,
Balaji

On Fri, Oct 26, 2012 at 3:31 PM, Salvatore Orlando wrote:

> Hi Trinath,
>
> Even if is perfectly reasonable to run the DHCP/L3 agents in the
> controller node, the advice we give in the administration guide is slightly
> different.
> As suggested in [1], the only Quantum component running on the controller
> node should be the API server.
> The DHCP and L3 agents might run in a dedicated "network node". Please
> note you will need also the L2 agent running on that node.
>
> Regards,
> Salvatore
>
> [1]
> http://docs.openstack.org/trunk/openstack-network/admin/content/app_demo.html
>
>  On 26 October 2012 10:50, Trinath Somanchi wrote:
>
>>  Hi Stackers-
>>
>> I have found many installation and configuration manuals for Openstack
>> Folsom which state the installation and configuration of Quantum-DHCP-Agent
>> in the Controller machine.
>>
>> But I have doubt here,
>>
>> Can't we have the Quantum-DHCP/L3-Agent to be running in the Compute NODE
>> rather than in the controller.
>>
>> How does the Installation and configuration change with this type of
>> Installation?
>>
>> Please guide me on How to achieve the same.
>>
>> Thanking you
>>
>> --
>> Regards,
>> --
>> Trinath Somanchi,
>> +91 9866 235 130
>>
>>
>> ___
>> 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] Troubleshooting Swift 1.7.4 on mini servers

[Pete Zaitcev]

On Mon, 29 Oct 2012 18:16:52 -0700
Nathan Trueblood  wrote:

> Definitely NOT a problem with the filesystem, but something is causing the
> object-server to think there is a problem with the filesystem.

If you are willing to go all-out, you can probably catch the
error with strace, if it works on ARM. Failing that, find all places
where 507 is generated and see if any exceptions are caught, by
modifying the source, I'm afraid to say.

> I suspect a bug in one of the underlying libraries.

That's a possibility. Or, it could be a kernel bug. You are using XFS,
right? If it were something other than XFS or ext4, I would suspect
ARM blowing over the 2GB barrier somewhere, since your object is
called "bigfile3". As it is, you have little option than to divide
the layers until you identify the one that's broken.

BTW, make sure to disable the fallocate, since we're at it.

-- Pete

___
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] Troubleshooting Swift 1.7.4 on mini servers

[Alex Yang]

There are any error about disk in the kern.log?

2012/10/30 Nathan Trueblood 

> Still no further clues.   I re-created all the volumes I'm using for
> Swift.  Plenty of Inodes free:
>
> lab@data02:~$ df -i
> FilesystemInodes IUsed IFree IUse% Mounted on
> /dev/sda2   12214272 39290  121749821% /
> none  107979   4821074971% /dev
> none  107979   2681077111% /run
> none  107979 21079771% /run/lock
> none  107979 11079781% /run/shm
> /dev/sda1  4915223 491291% /boot
> /dev/sda4  13404640037 1340463631% /srv/node/sda4
>
> I successfully upload a small object to container cont1, then cont2.
> When I upload to cont3, I see the following in the object-server log
> (data02)
>
> This seems to be the problematic sequence:
>
> Data02 has ip 192.168.1.202
> Data03 has ip 192.168.1.203
>
> 1. First the account server reports an HTTP 201 on the container from a
> different object server in a different zone.
> 2. Then the object server reports a 404 trying to HEAD the new object.
> 3. Then the object server reports a 507 trying to PUT the new object.
>
> From this point the operation eventually fails and the proxy reports a 503.
>
> Oct 29 17:58:20 data02 account-server 192.168.1.203 - -
> [30/Oct/2012:00:58:20 +] "PUT /sda4/116021/AUTH_system/cont3" 201 -
> "tx5a3ca6c845af41928e0ba6b7bc58d2da" "-" "-" 0.0082 ""
> Oct 29 17:58:20 data02 object-server 192.168.1.111 - -
> [30/Oct/2012:00:58:20 +] "HEAD
> /sda4/257613/AUTH_system/cont3/home/lab/bigfile3" 404 - "-"
> "tx5f21503ff12e45e39a80eb52f6757261" "-" 0.0011
> Oct 29 17:58:20 data02 object-server 192.168.1.111 - -
> [30/Oct/2012:00:58:20 +] "PUT
> /sda4/257613/AUTH_system/cont3/home/lab/bigfile3" 507 - "-"
> "tx425494dc372740e28d043a07d3a08b9a" "-" 0.0031
>
> In an earlier, successful transaction I noticed that between Steps 1 and 2
> above, there is a response from the container-server:
>
> Oct 29 17:57:59 data02 account-server 192.168.1.204 - -
> [30/Oct/2012:00:57:59 +] "PUT /sda4/116021/AUTH_system/cont2" 201 -
> "txb10d75886bf14e4eba14fcc52d81c5d9" "-" "-" 0.0182 ""
> Oct 29 17:57:59 data02 container-server 192.168.1.111 - -
> [30/Oct/2012:00:57:59 +] "PUT /sda4/122355/AUTH_system/cont2" 201 -
> "txb10d75886bf14e4eba14fcc52d81c5d9" "-" "-" 0.1554
> Oct 29 17:57:59 data02 object-server 192.168.1.111 - -
> [30/Oct/2012:00:57:59 +] "HEAD
> /sda4/226151/AUTH_system/cont2/home/lab/bigfile3" 404 - "-"
> "tx1c514850530849d1bfbfa716d9039b87" "-" 0.0012
> Oct 29 17:57:59 data02 container-server 192.168.1.204 - -
> [30/Oct/2012:00:57:59 +] "PUT
> /sda4/122355/AUTH_system/cont2/home/lab/bigfile3" 201 -
> "tx8130af5cae484e5f9c5a25541d1c87aa" "-" "-" 0.0041
> Oct 29 17:57:59 data02 object-server 192.168.1.111 - -
> [30/Oct/2012:00:57:59 +] "PUT
> /sda4/226151/AUTH_system/cont2/home/lab/bigfile3" 201 - "-"
> "tx8130af5cae484e5f9c5a25541d1c87aa" "-" 0.1716
>
>
> So maybe the container server is failing to create the new container?
> Maybe a bug in auto-create of containers?
>
> Definitely NOT a problem with the filesystem, but something is causing the
> object-server to think there is a problem with the filesystem.
>
> I suspect a bug in one of the underlying libraries.
>
> Any further suggestions on how to troubleshoot?
>
> Thanks.   When I finally find the solution, I'll post my results.
>
> -N
>
> On Fri, Oct 26, 2012 at 11:21 PM, John Dickinson  wrote:
>
>> A 507 is returned by the object servers in 2 situations: 1) the drives
>> are full or 2) the drives have been unmounted because of disk error.
>>
>> It's highly likely that you simply have full drives. Remember that the
>> usable space in your cluster is 1/N where N = replica count. As an example,
>> with 3 replicas and 5 nodes with a single 1TB drive each, you only have
>> about 1.6TB available for data.
>>
>> As Pete suggested in his response, how big are your drives, and what does
>> `df` tell you?
>>
>> --John
>>
>>
>> On Oct 26, 2012, at 5:26 PM, Nathan Trueblood 
>> wrote:
>>
>> > Hey folks-
>> >
>> > I'm trying to figure out what's going wrong with my Swift deployment on
>> a small cluster of "mini" servers.   I have a small test cluster (5 storage
>> nodes, 1 proxy) of mini-servers that are ARM-based.   The proxy is a
>> regular, Intel-based server with plenty of RAM.   The
>> object/account/container servers are relatively small, with 2GB of RAM per
>> node.
>> >
>> > Everything starts up fine, but now I'm trying to troubleshoot a strange
>> problem.   After I successfully upload a few test files, it seems like the
>> storage system stops responding and the proxy gives me a 503 error.
>> >
>> > Here's the test sequence I run on my proxy:
>> >
>> > lab@proxy01:~/bin$ ./swiftcl.sh stat
>> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat
>> >Account: AUTH_system
>> > Containers: 5
>> >Objects: 4
>> >  Bytes: 4

[Openstack] Action Required: Use DocImpact flag when commits might impact docs

[Tom Fifield]

TL;DR - If anything you submit could have an impact on documentation,
just add "DocImpact" to a line in your commit message.

Developers,


We need your help.

In the face of the 500 contributors to the code base, those small
handful of us working on documentation are losing the war.

One of the worst pains we have right now is that we're not getting
information from you about the changes you make. We just don't have the
people to review every single commit on every single project for its
impact on documentation.

This is where you can make a difference.

If your commit could have an impact on documentation - be it an
added/altered/removed commandline option, a deprecated or new feature, a
caveat, if you've written docs in the patch, or if you're just not sure
- there's a way to let us know.

=> Just add "DocImpact" to a line in your commit message.

This sends us an email so we can triage. It doesn't guarantee docs will
be written, but at least it gives us visibility of the changes.


Thanks for reading.

As always - if you have any time to write/fix docs, we've more than one
hundred bugs waiting for your contribution . . .


Regards,


Tom, on behalf of the docs team.

___
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] Troubleshooting Swift 1.7.4 on mini servers

[Nathan Trueblood]

Still no further clues.   I re-created all the volumes I'm using for Swift.
 Plenty of Inodes free:

lab@data02:~$ df -i
FilesystemInodes IUsed IFree IUse% Mounted on
/dev/sda2   12214272 39290  121749821% /
none  107979   4821074971% /dev
none  107979   2681077111% /run
none  107979 21079771% /run/lock
none  107979 11079781% /run/shm
/dev/sda1  4915223 491291% /boot
/dev/sda4  13404640037 1340463631% /srv/node/sda4

I successfully upload a small object to container cont1, then cont2.   When
I upload to cont3, I see the following in the object-server log (data02)

This seems to be the problematic sequence:

Data02 has ip 192.168.1.202
Data03 has ip 192.168.1.203

1. First the account server reports an HTTP 201 on the container from a
different object server in a different zone.
2. Then the object server reports a 404 trying to HEAD the new object.
3. Then the object server reports a 507 trying to PUT the new object.

>From this point the operation eventually fails and the proxy reports a 503.

Oct 29 17:58:20 data02 account-server 192.168.1.203 - -
[30/Oct/2012:00:58:20 +] "PUT /sda4/116021/AUTH_system/cont3" 201 -
"tx5a3ca6c845af41928e0ba6b7bc58d2da" "-" "-" 0.0082 ""
Oct 29 17:58:20 data02 object-server 192.168.1.111 - -
[30/Oct/2012:00:58:20 +] "HEAD
/sda4/257613/AUTH_system/cont3/home/lab/bigfile3" 404 - "-"
"tx5f21503ff12e45e39a80eb52f6757261" "-" 0.0011
Oct 29 17:58:20 data02 object-server 192.168.1.111 - -
[30/Oct/2012:00:58:20 +] "PUT
/sda4/257613/AUTH_system/cont3/home/lab/bigfile3" 507 - "-"
"tx425494dc372740e28d043a07d3a08b9a" "-" 0.0031

In an earlier, successful transaction I noticed that between Steps 1 and 2
above, there is a response from the container-server:

Oct 29 17:57:59 data02 account-server 192.168.1.204 - -
[30/Oct/2012:00:57:59 +] "PUT /sda4/116021/AUTH_system/cont2" 201 -
"txb10d75886bf14e4eba14fcc52d81c5d9" "-" "-" 0.0182 ""
Oct 29 17:57:59 data02 container-server 192.168.1.111 - -
[30/Oct/2012:00:57:59 +] "PUT /sda4/122355/AUTH_system/cont2" 201 -
"txb10d75886bf14e4eba14fcc52d81c5d9" "-" "-" 0.1554
Oct 29 17:57:59 data02 object-server 192.168.1.111 - -
[30/Oct/2012:00:57:59 +] "HEAD
/sda4/226151/AUTH_system/cont2/home/lab/bigfile3" 404 - "-"
"tx1c514850530849d1bfbfa716d9039b87" "-" 0.0012
Oct 29 17:57:59 data02 container-server 192.168.1.204 - -
[30/Oct/2012:00:57:59 +] "PUT
/sda4/122355/AUTH_system/cont2/home/lab/bigfile3" 201 -
"tx8130af5cae484e5f9c5a25541d1c87aa" "-" "-" 0.0041
Oct 29 17:57:59 data02 object-server 192.168.1.111 - -
[30/Oct/2012:00:57:59 +] "PUT
/sda4/226151/AUTH_system/cont2/home/lab/bigfile3" 201 - "-"
"tx8130af5cae484e5f9c5a25541d1c87aa" "-" 0.1716


So maybe the container server is failing to create the new container?
Maybe a bug in auto-create of containers?

Definitely NOT a problem with the filesystem, but something is causing the
object-server to think there is a problem with the filesystem.

I suspect a bug in one of the underlying libraries.

Any further suggestions on how to troubleshoot?

Thanks.   When I finally find the solution, I'll post my results.

-N

On Fri, Oct 26, 2012 at 11:21 PM, John Dickinson  wrote:

> A 507 is returned by the object servers in 2 situations: 1) the drives are
> full or 2) the drives have been unmounted because of disk error.
>
> It's highly likely that you simply have full drives. Remember that the
> usable space in your cluster is 1/N where N = replica count. As an example,
> with 3 replicas and 5 nodes with a single 1TB drive each, you only have
> about 1.6TB available for data.
>
> As Pete suggested in his response, how big are your drives, and what does
> `df` tell you?
>
> --John
>
>
> On Oct 26, 2012, at 5:26 PM, Nathan Trueblood 
> wrote:
>
> > Hey folks-
> >
> > I'm trying to figure out what's going wrong with my Swift deployment on
> a small cluster of "mini" servers.   I have a small test cluster (5 storage
> nodes, 1 proxy) of mini-servers that are ARM-based.   The proxy is a
> regular, Intel-based server with plenty of RAM.   The
> object/account/container servers are relatively small, with 2GB of RAM per
> node.
> >
> > Everything starts up fine, but now I'm trying to troubleshoot a strange
> problem.   After I successfully upload a few test files, it seems like the
> storage system stops responding and the proxy gives me a 503 error.
> >
> > Here's the test sequence I run on my proxy:
> >
> > lab@proxy01:~/bin$ ./swiftcl.sh stat
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat
> >Account: AUTH_system
> > Containers: 5
> >Objects: 4
> >  Bytes: 47804968
> > Accept-Ranges: bytes
> > X-Timestamp: 1351294912.72119
> > lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles1 /home/lab/bigfile1
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass
> upload myfiles1 /home/lab/bigfile1
> > home/la

Re: [Openstack] Instance provisioning taking more time for all the instances

[Jay Pipes]

Hi Nagaraju, apologies for long delay in replying. Answer inline.

On 09/29/2012 05:40 AM, Nagaraju Bingi wrote:
> Hi,
> 
> We have deployed Openstack on VMware and we could able to provision
> Instances but image is not getting cached on compute/ESX server and for
> every provisioning of instances the image is getting downloaded from glance.
> 
> Please provide steps to cache VMDK images on compute.

I've cc'd Mikal Still, who wrote the original image cache in the libvirt
driver. I'm not sure but I think work was done in Folsom to make the
image cache more generic, but I'm not totally sure. Hoping Mikal has an
answer to that.

All the best,
-jay

___
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] Quotas in folsom

[Tim Bell]

+1 for Boson  ... this is a key area for CERN too. When you have a fixed budget 
and no credit cards, quota management is a strong requirement!

Tim

> -Original Message-
> From: openstack-bounces+tim.bell=cern...@lists.launchpad.net
> [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf
> Of Kevin L. Mitchell
> Sent: 29 October 2012 20:26
> To: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Quotas in folsom
> 
> On Mon, 2012-10-29 at 18:01 +, Gabriel Hurley wrote:
> > It's also worth noting that we are now in territory where quotas are
> > controlled by multiple projects: volumes and gigabytes have quotas in
> > both Nova and Cinder; network quotas are in both Nova and Quantum...
> >
> > While I don't think it makes sense to try and centralize these things,
> > I think the projects could coordinate more to understand "who" should
> > be managing a given quota and to try and make the end-user experience
> > less baffling.
> 
> It's also worth noting that I've finally been able to start working on Boson,
> which may help with that…
> --
> Kevin L. Mitchell 
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


smime.p7s
Description: S/MIME cryptographic signature
___
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] Finding/Making Windows 7 Images for OpenStack

[Curtis C.]

On Wed, Oct 24, 2012 at 3:05 PM, Mark Lehrer  wrote:
>>> for OpenStack? I know it's supposed to be as easy as using kvm to
>>> install it initially (as per the OpenStack docs) then importing that
>>> image into glance, but there are some subtle things that I might be
>
>
> Nope, it is indeed that simple.  Make sure you use the same hardware
> settings as Openstack for the nic and disk and configure DHCP.

It certainly might be that simple for a single instance, but I had
trouble reusing that instance without using sysprep and generalize.

Thanks,
Curtis.

>
> However, activation and licensing can be annoying.  We are considering using
> the datacenter edition here for this reason.
>
> Mark



-- 
Twitter: @serverascode
Blog: serverascode.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] Quotas in folsom

[Kevin L. Mitchell]

On Mon, 2012-10-29 at 18:01 +, Gabriel Hurley wrote:
> It's also worth noting that we are now in territory where quotas are
> controlled by multiple projects: volumes and gigabytes have quotas in
> both Nova and Cinder; network quotas are in both Nova and Quantum...
> 
> While I don't think it makes sense to try and centralize these things,
> I think the projects could coordinate more to understand "who" should
> be managing a given quota and to try and make the end-user experience
> less baffling. 

It's also worth noting that I've finally been able to start working on
Boson, which may help with that…
-- 
Kevin L. Mitchell 


___
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] Looking for a mailman administrator

[Stefano Maffulli]

Hello folks,

We need a new administrator for the mailman installation on 
lists.openstack.org. Duncan McGreggor has helped the community a lot in 
the past months, setting up the new machine, configuring and testing 
mailman's upgrades from the old servers and running the setup since 
June. I'm very grateful to him for this. He just communicated to me that 
he can't take care of lists.openstack.org anymore.


The person should be familiar with mailman and have time to help migrate 
the General list from Launchpad to lists.openstack.org, as we agreed.


If you (know somebody that) want to do it please contact me offlist.

Thank you,
Stefano

___
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] quantum: two ips one vif

[Dan Wendlandt]

On Fri, Oct 26, 2012 at 4:12 PM, Carl Bolterstein
 wrote:
> For the curiosity sake -
>
> After some trial and error.  It appears we have solved one half of our 
> conundrum.  Using the driver below, there is no ip data inserted into 
> libvirt.xml which allows any ip to be used.  It works for our uses (HA vip 
> services, secondary addresses).
>
> libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtOpenVswitchVirtualPortDriver

yes, the docs here
(http://docs.openstack.org/trunk/openstack-network/admin/content/nova_with_quantum_vifplugging_ovs.html)
talk about using the hybrid driver if you care about security groups.
We should expand it to also mention that this applies for
spoof-prevention as well.

>
> This however does not prevent quantum from assigning a used IP to a new port, 
> but working on that.
>

Would be great if you can provide more detail there.

Dan


> Carl Bolterstein
>
> -Original Message-
> From: openstack-bounces+cbolterstein=blackmesh@lists.launchpad.net 
> [mailto:openstack-bounces+cbolterstein=blackmesh@lists.launchpad.net] On 
> Behalf Of Jason Kölker
> Sent: Tuesday, October 23, 2012 6:38 PM
> To: openstack@lists.launchpad.net
> Subject: Re: [Openstack] quantum: two ips one vif
>
> On Tue, 2012-10-23 at 15:14 -0700, Dan Wendlandt wrote:
>> can you post your libvirt xml for the VM?  It maybe well be libvirt
>> filtering if you are using the OVS Hybrid vif driver:
>>
>> for example, a VM would have xml like:
>>
>>   
>> 
>> 
>> 
>> 
>>   
>>
>> I'm not sure what the nova code would generate for multiple IPs.
>
> Libvirt's driver only supports 1 ip per interface. It needs to be updated to 
> use the newer network models and not depend on the code in 
> nova.virt.netutils.get_injected_network_template.
>
> Happy Hacking!
>
> 7-11
>
>
> ___
> 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



-- 
~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~

___
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 mailing list for bare-metal provisioning

[Mark T. Voelker]

> subscribe to the Nova topic at the link above. When I write a message
> about nova I have to add '[Nova]' (or 'Nova') anywhere in the subject

(Sidenote: does 'Nova' actually work?  Looks to me like the regex in
mailman requires the square braces...)

Personally I'm fine with either model, but just to call out the common
complaint I hear about topics: I think a lot of folks feel that what you
just pointed out is actually a major weakness.  The topic functionality
requires that *each individual sender* be aware of that functionality
and format his subject lines accordingly.  That often doesn't happen
even with folks who've been active in the community for some time, let
alone folks who are new.  When someone doesn't format his subject
properly, it either causes clutter when email sorting filters break or
causes folks to miss messages about things they care about if they've
subscribed only to particular topics.  I know there have been at least a
couple of threads about Quantum in the past couple of weeks (one
pertaining to Ceilometer integration, one pertaining to the Folsom
stable branch come to mind) that didn't have [Quantum] (or [Ceilometer]
for that matter) in the subject line.  Thus, I'd have missed those
messages if I were only subscribed to the Quantum topic.

Personally I like to see everything so it doesn't much matter to me
other than in how I set up my email filters, but I think perhaps this is
one reason why we've had the discussion about more vs fewer mailing
lists more than once.

At Your Service,

Mark T. Voelker

On 10/29/2012 09:01 AM, Stefano Maffulli wrote:
> On 10/29/2012 12:32 PM, Thierry Carrez wrote:
>> We really shouldn't go in that direction: the openstack-dev list is
>> already an aggregator of topics, since we use "mailman topics" on it.
> 
> Indeed, mailman topics are very powerful. The current topics for
> openstack-dev are listed on each subscriber's personal page:
> 
> http://lists.openstack.org/cgi-bin/mailman/options/openstack-dev
> 
> As a subscriber of openstack-dev I can decide to receive only messages
> tagged for a topic by selecting the ones I'm interested in. As a writer
> of a message I can tag it by adding the topic to the subject line of the
> message.
> 
> For example, if I want to receive only messages for Nova, I can
> subscribe to the Nova topic at the link above. When I write a message
> about nova I have to add '[Nova]' (or 'Nova') anywhere in the subject.
> 
> Creating a topic of bare-metal is easy, using topics is a matter of
> habit. I believe that we should not create more lists unless strictly
> necessary. I also understood from David that the baremetal group felt
> very strongly against using any of the existing list, even when I
> suggested to use topics. I'm glad we're having this conversation now and
> I'm open to any outcome.
> 
> /stef
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp



signature.asc
Description: OpenPGP digital signature
___
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] Quotas in folsom

[Gabriel Hurley]

It's also worth noting that we are now in territory where quotas are controlled 
by multiple projects: volumes and gigabytes have quotas in both Nova and 
Cinder; network quotas are in both Nova and Quantum...

While I don't think it makes sense to try and centralize these things, I think 
the projects could coordinate more to understand "who" should be managing a 
given quota and to try and make the end-user experience less baffling.

- Gabriel

> -Original Message-
> From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
> [mailto:openstack-
> bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of
> Kevin L. Mitchell
> Sent: Monday, October 29, 2012 9:28 AM
> To: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Quotas in folsom
> 
> On Mon, 2012-10-29 at 10:53 -0400, Mitchell Broome wrote:
> > I'm running into quota problems trying to increase the number of
> > security groups and rules within security groups per tenant.  Setting
> > quota_security_groups and quota_security_group_rules in nova.conf
> seem
> > to have no effect.  There also doesn't seem to be any way to change
> > the quota limits for security groups through the nova client or
> > horizon.
> 
> The quotas system checks the database for quotas specific to the tenant,
> then for quotas for the tenant's quota class (if you're using quota classes).
> Only if it can't find any such quotas will it go to the values defined in
> nova.conf.
> 
> You're right that these particular quotas are not among the quotas
> recognized by the nova shell command, but you can access them through the
> pythonic API; I'm guessing that the new quotas were added to nova itself
> during the folsom release cycle, but nobody remembered to update
> novaclient to recognize them.  Could you log a bug against folsom for that,
> please?
> 
> > How do I go about changing these quotas or is there a way to disable
> > all quotas all together?
> 
> Check the database itself for quota records for your tenants; you can revert
> to defaults (drawn from nova.conf) by deleting any 'quotas' table rows for
> the resources you're interested in.  If it still doesn't take the values you 
> set in
> nova.conf, then there's likely some other bug that needs to be looked into…
> --
> Kevin L. Mitchell 
> 
> 
> ___
> 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] Local vlan id number is less than virtual network numbers

[Dan Wendlandt]

this was answered in LP questions:
https://answers.launchpad.net/quantum/+question/212613

dan

On Thu, Oct 25, 2012 at 2:45 AM, 吉海  wrote:
> Hello, i am a new quantum fun. I have a question about provision local
> vlan of ovs plugin.
> Plugin ovs agent can provide 4094 local vlan for local vlan mapping on
> integration bridge 'br-int'. But each physical network can have a vlan
> range, it may be 1-4094. If compute node has two physical network. Each
> physical network vlan range is 1 - 4094. The node supports 4094 * 2
> network. Now plugin agent of this node can only provide 4094  local vlan
> id for mapping physical network segmentation id(physical vlan id).  If i
> create other network more than 4094, it will log error "No local VLAN
> availabel for net-id=" . Is it right?
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>



-- 
~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~

___
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] Instrumentation Monitoring Next Step - quick meet up

[Sandy Walsh]

np ... I realize it's tricky to change this stuff.

I'll see if I can jump on remote.

-S


From: Annie Cheng [ann...@yahoo-inc.com]
Sent: Monday, October 29, 2012 1:44 PM
To: 'doug.hellm...@dreamhost.com'; Sandy Walsh
Cc: 'openstack@lists.launchpad.net'
Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up


We also have to stick with the schedule on our end.

Sandy, all discussion will be tracked in IRC log. We can also have follow up 
discussion via mailing list or more meetings.

Annie


From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com]
Sent: Monday, October 29, 2012 09:37 AM
To: Sandy Walsh 
Cc: Annie Cheng; openstack@lists.launchpad.net 
Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up

I can't meet later than that tonight.

Doug

On Mon, Oct 29, 2012 at 10:21 AM, Sandy Walsh 
mailto:sandy.wa...@rackspace.com>> wrote:
Ugh, I just realized I have a conflict. Can we push it an hour later? (sorry!)

-S


From: 
openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net]
 on behalf of Annie Cheng [ann...@yahoo-inc.com]
Sent: Monday, October 29, 2012 11:18 AM
To: openstack@lists.launchpad.net

Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Apologize .. Correction

Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (3pm PDT if you are in California)
Location: IRC #openstack-meeting


From: Annie Cheng mailto:ann...@yahoo-inc.com>>
Date: Mon, 29 Oct 2012 07:14:08 -0700
To: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Reminder:
Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in California)
Location: IRC #openstack-meeting

Thanks!

Annie

From: Annie Cheng mailto:ann...@yahoo-inc.com>>
Date: Thu, 25 Oct 2012 14:17:09 -0700
To: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Hi all,

Couple of us chat in the summit design sessions and and after summit on 
#openstack irc regarding topic of Monitoring.  We think it's best to do a quick 
meeting to get everyone on the same page, split works, and get at least a 
prototype going in Grizzly.

Time: Monday (10/29/2012) 2200 UTC – 2300 UTC
Location: IRC #openstack-meeting
I checked http://wiki.openstack.org/Meetings, this tme slot seems to be empty

Top level agenda would be

  1.  Get everyone on the same page on high level direction
  2.  Discuss different design/implementation possibility
  3.  Split up works

Before the meeting, if you want to read up, here are some links I know.  Please 
jump in with others I missed:
Blueprint:
https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring
Etherpad:
https://etherpad.openstack.org/grizzly-common-instrumentation
Different code samples:
https://github.com/asalkeld/statgen

Looking forward, some of those conversation probably will fold into the regular 
Metering meeting.  Just like to do a one off for now so we can go deeper on 
monitoring specific topics.

Thanks!

Annie

___
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] Instrumentation Monitoring Next Step - quick meet up

[Annie Cheng]

We also have to stick with the schedule on our end.

Sandy, all discussion will be tracked in IRC log. We can also have follow up 
discussion via mailing list or more meetings.

Annie


From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com]
Sent: Monday, October 29, 2012 09:37 AM
To: Sandy Walsh 
Cc: Annie Cheng; openstack@lists.launchpad.net 
Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up

I can't meet later than that tonight.

Doug

On Mon, Oct 29, 2012 at 10:21 AM, Sandy Walsh 
mailto:sandy.wa...@rackspace.com>> wrote:
Ugh, I just realized I have a conflict. Can we push it an hour later? (sorry!)

-S


From: 
openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net]
 on behalf of Annie Cheng [ann...@yahoo-inc.com]
Sent: Monday, October 29, 2012 11:18 AM
To: openstack@lists.launchpad.net

Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Apologize .. Correction

Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (3pm PDT if you are in California)
Location: IRC #openstack-meeting


From: Annie Cheng mailto:ann...@yahoo-inc.com>>
Date: Mon, 29 Oct 2012 07:14:08 -0700
To: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Reminder:
Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in California)
Location: IRC #openstack-meeting

Thanks!

Annie

From: Annie Cheng mailto:ann...@yahoo-inc.com>>
Date: Thu, 25 Oct 2012 14:17:09 -0700
To: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Hi all,

Couple of us chat in the summit design sessions and and after summit on 
#openstack irc regarding topic of Monitoring.  We think it's best to do a quick 
meeting to get everyone on the same page, split works, and get at least a 
prototype going in Grizzly.

Time: Monday (10/29/2012) 2200 UTC – 2300 UTC
Location: IRC #openstack-meeting
I checked http://wiki.openstack.org/Meetings, this tme slot seems to be empty

Top level agenda would be

 1.  Get everyone on the same page on high level direction
 2.  Discuss different design/implementation possibility
 3.  Split up works

Before the meeting, if you want to read up, here are some links I know.  Please 
jump in with others I missed:
Blueprint:
https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring
Etherpad:
https://etherpad.openstack.org/grizzly-common-instrumentation
Different code samples:
https://github.com/asalkeld/statgen

Looking forward, some of those conversation probably will fold into the regular 
Metering meeting.  Just like to do a one off for now so we can go deeper on 
monitoring specific topics.

Thanks!

Annie

___
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] Instrumentation Monitoring Next Step - quick meet up

[Doug Hellmann]

I can't meet later than that tonight.

Doug

On Mon, Oct 29, 2012 at 10:21 AM, Sandy Walsh wrote:

>  Ugh, I just realized I have a conflict. Can we push it an hour later?
> (sorry!)
>
> -S
>
>  --
> *From:* 
> openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net[openstack-bounces+sandy.walsh=
> rackspace@lists.launchpad.net] on behalf of Annie Cheng [
> ann...@yahoo-inc.com]
> *Sent:* Monday, October 29, 2012 11:18 AM
> *To:* openstack@lists.launchpad.net
>
> *Subject:* Re: [Openstack] Instrumentation Monitoring Next Step - quick
> meet up
>
>   Apologize .. Correction
>
>  Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (*3pm PDT *if you are in
> California)
>  Location: IRC #openstack-meeting
>
>
>   From: Annie Cheng 
> Date: Mon, 29 Oct 2012 07:14:08 -0700
> To: "openstack@lists.launchpad.net" 
> Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick
> meet up
>
>   Reminder:
> Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in
> California)
>  Location: IRC #openstack-meeting
>
>  Thanks!
>
>  Annie
>
>   From: Annie Cheng 
> Date: Thu, 25 Oct 2012 14:17:09 -0700
> To: "openstack@lists.launchpad.net" 
> Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up
>
>   Hi all,
>
>  Couple of us chat in the summit design sessions and and after summit on
> #openstack irc regarding topic of Monitoring.  We think it's best to do a
> quick meeting to get everyone on the same page, split works, and get at
> least a prototype going in Grizzly.
>
>  Time: Monday (10/29/2012) 2200 UTC – 2300 UTC
> Location: IRC #openstack-meeting
> I checked http://wiki.openstack.org/Meetings, this tme slot seems to be
> empty
>
>  Top level agenda would be
>
>1. Get everyone on the same page on high level direction
>2. Discuss different design/implementation possibility
>3. Split up works
>
> Before the meeting, if you want to read up, here are some links I know.
>  Please jump in with others I missed:
> Blueprint:
>
> https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring
> Etherpad:
> https://etherpad.openstack.org/grizzly-common-instrumentation
> Different code samples:
> https://github.com/asalkeld/statgen
>
>  Looking forward, some of those conversation probably will fold into the
> regular Metering meeting.  Just like to do a one off for now so we can go
> deeper on monitoring specific topics.
>
>  Thanks!
>
>  Annie
>
> ___
> 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] Quotas in folsom

[Kevin L. Mitchell]

On Mon, 2012-10-29 at 10:53 -0400, Mitchell Broome wrote:
> I'm running into quota problems trying to increase the number of
> security groups and rules within security groups per tenant.  Setting
> quota_security_groups and quota_security_group_rules in nova.conf seem
> to have no effect.  There also doesn't seem to be any way to change
> the quota limits for security groups through the nova client or
> horizon.

The quotas system checks the database for quotas specific to the tenant,
then for quotas for the tenant's quota class (if you're using quota
classes).  Only if it can't find any such quotas will it go to the
values defined in nova.conf.

You're right that these particular quotas are not among the quotas
recognized by the nova shell command, but you can access them through
the pythonic API; I'm guessing that the new quotas were added to nova
itself during the folsom release cycle, but nobody remembered to update
novaclient to recognize them.  Could you log a bug against folsom for
that, please?

> How do I go about changing these quotas or is there a way to disable
> all quotas all together?

Check the database itself for quota records for your tenants; you can
revert to defaults (drawn from nova.conf) by deleting any 'quotas' table
rows for the resources you're interested in.  If it still doesn't take
the values you set in nova.conf, then there's likely some other bug that
needs to be looked into…
-- 
Kevin L. Mitchell 


___
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] Allocate specific floating IP to an instance

[Sébastien Han]

Hi Stacker,

I know OpenStack is not designed that way and I don't think it's
possible (or maybe I misses something :)) but I was wondering if there
is any simple workaround to choose a specific floating IP to allocate.
In other words, don't give me a random or N+1 next floating IP
available but let me decide which floating IP I want to assign to my
instance. It doesn't make sense in a public cloud but it does for a
corporate/private cloud. It would be nice to have :)

Thanks in advance.

Cheers!

___
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] Troubleshooting Swift 1.7.4 on mini servers

[John Dickinson]

Also check the number of inodes used: `df -i`

--John



On Oct 29, 2012, at 8:31 AM, Nathan Trueblood  wrote:

> Yeah, I read about the 507 error.However, when the error occurs on my I 
> can see with 'df' that the drive is only 1% full and is definitely not 
> unmounted.   I can write files to the mounted filesystem directly before, 
> during, and after the Swift error occurs.   So the problem must be some kind 
> of timeout that is causing the object server to think that something is wrong 
> with the disk.
> 
> I'll keep digging... 
> 
> On Fri, Oct 26, 2012 at 11:21 PM, John Dickinson  wrote:
> A 507 is returned by the object servers in 2 situations: 1) the drives are 
> full or 2) the drives have been unmounted because of disk error.
> 
> It's highly likely that you simply have full drives. Remember that the usable 
> space in your cluster is 1/N where N = replica count. As an example, with 3 
> replicas and 5 nodes with a single 1TB drive each, you only have about 1.6TB 
> available for data.
> 
> As Pete suggested in his response, how big are your drives, and what does 
> `df` tell you?
> 
> --John
> 
> 
> On Oct 26, 2012, at 5:26 PM, Nathan Trueblood  wrote:
> 
> > Hey folks-
> >
> > I'm trying to figure out what's going wrong with my Swift deployment on a 
> > small cluster of "mini" servers.   I have a small test cluster (5 storage 
> > nodes, 1 proxy) of mini-servers that are ARM-based.   The proxy is a 
> > regular, Intel-based server with plenty of RAM.   The 
> > object/account/container servers are relatively small, with 2GB of RAM per 
> > node.
> >
> > Everything starts up fine, but now I'm trying to troubleshoot a strange 
> > problem.   After I successfully upload a few test files, it seems like the 
> > storage system stops responding and the proxy gives me a 503 error.
> >
> > Here's the test sequence I run on my proxy:
> >
> > lab@proxy01:~/bin$ ./swiftcl.sh stat
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat
> >Account: AUTH_system
> > Containers: 5
> >Objects: 4
> >  Bytes: 47804968
> > Accept-Ranges: bytes
> > X-Timestamp: 1351294912.72119
> > lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles1 /home/lab/bigfile1
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload 
> > myfiles1 /home/lab/bigfile1
> > home/lab/bigfile1
> > lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles2 /home/lab/bigfile1
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload 
> > myfiles2 /home/lab/bigfile1
> > home/lab/bigfile1
> > lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles3 /home/lab/bigfile1
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload 
> > myfiles3 /home/lab/bigfile1
> > home/lab/bigfile1
> > lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles4 /home/lab/bigfile1
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload 
> > myfiles4 /home/lab/bigfile1
> > home/lab/bigfile1
> > lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles5 /home/lab/bigfile1
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass upload 
> > myfiles5 /home/lab/bigfile1
> > Object PUT failed: 
> > http://172.16.1.111:8080/v1/AUTH_system/myfiles5/home/lab/bigfile1 503 
> > Service Unavailable  [first 60 chars of response] 503 Service Unavailable
> >
> > The server is currently unavailable
> > lab@proxy01:~/bin$ ./swiftcl.sh stat
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat
> >Account: AUTH_system
> > Containers: 6
> >Objects: 5
> >  Bytes: 59756210
> > Accept-Ranges: bytes
> > X-Timestamp: 1351294912.72119
> >
> > Here's the corresponding log on the Proxy:
> >
> > Oct 26 17:06:52 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/06/52 GET 
> > /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010
> > Oct 26 17:07:13 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/13 GET 
> > /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0017
> > Oct 26 17:07:13 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/13 GET 
> > /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016
> > Oct 26 17:07:22 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/22 GET 
> > /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010
> > Oct 26 17:07:22 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/22 GET 
> > /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016
> > Oct 26 17:07:27 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/27 GET 
> > /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010
> > Oct 26 17:07:27 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/27 GET 
> > /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016
> > Oct 26 17:07:27 proxy01 proxy-server Handoff requested (1) (txn: 
> > tx6946419daba54efe9c2878f8a2a78f88) (client_ip: 172.16.1.111)
> > Oct 26 17:07:27 proxy01 proxy-server Handoff requested (2) (txn: 
> > tx6946419daba54efe9c2878f8a2a78f88) (client_ip: 172.16.1.111)
> > Oct 26 17:07:33 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/33 GET 
> > /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010

Re: [Openstack] Troubleshooting Swift 1.7.4 on mini servers

[Nathan Trueblood]

Yeah, I read about the 507 error.However, when the error occurs on my I
can see with 'df' that the drive is only 1% full and is definitely not
unmounted.   I can write files to the mounted filesystem directly before,
during, and after the Swift error occurs.   So the problem must be some
kind of timeout that is causing the object server to think that something
is wrong with the disk.

I'll keep digging...

On Fri, Oct 26, 2012 at 11:21 PM, John Dickinson  wrote:

> A 507 is returned by the object servers in 2 situations: 1) the drives are
> full or 2) the drives have been unmounted because of disk error.
>
> It's highly likely that you simply have full drives. Remember that the
> usable space in your cluster is 1/N where N = replica count. As an example,
> with 3 replicas and 5 nodes with a single 1TB drive each, you only have
> about 1.6TB available for data.
>
> As Pete suggested in his response, how big are your drives, and what does
> `df` tell you?
>
> --John
>
>
> On Oct 26, 2012, at 5:26 PM, Nathan Trueblood 
> wrote:
>
> > Hey folks-
> >
> > I'm trying to figure out what's going wrong with my Swift deployment on
> a small cluster of "mini" servers.   I have a small test cluster (5 storage
> nodes, 1 proxy) of mini-servers that are ARM-based.   The proxy is a
> regular, Intel-based server with plenty of RAM.   The
> object/account/container servers are relatively small, with 2GB of RAM per
> node.
> >
> > Everything starts up fine, but now I'm trying to troubleshoot a strange
> problem.   After I successfully upload a few test files, it seems like the
> storage system stops responding and the proxy gives me a 503 error.
> >
> > Here's the test sequence I run on my proxy:
> >
> > lab@proxy01:~/bin$ ./swiftcl.sh stat
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat
> >Account: AUTH_system
> > Containers: 5
> >Objects: 4
> >  Bytes: 47804968
> > Accept-Ranges: bytes
> > X-Timestamp: 1351294912.72119
> > lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles1 /home/lab/bigfile1
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass
> upload myfiles1 /home/lab/bigfile1
> > home/lab/bigfile1
> > lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles2 /home/lab/bigfile1
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass
> upload myfiles2 /home/lab/bigfile1
> > home/lab/bigfile1
> > lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles3 /home/lab/bigfile1
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass
> upload myfiles3 /home/lab/bigfile1
> > home/lab/bigfile1
> > lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles4 /home/lab/bigfile1
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass
> upload myfiles4 /home/lab/bigfile1
> > home/lab/bigfile1
> > lab@proxy01:~/bin$ ./swiftcl.sh upload myfiles5 /home/lab/bigfile1
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass
> upload myfiles5 /home/lab/bigfile1
> > Object PUT failed:
> http://172.16.1.111:8080/v1/AUTH_system/myfiles5/home/lab/bigfile1 503
> Service Unavailable  [first 60 chars of response] 503 Service Unavailable
> >
> > The server is currently unavailable
> > lab@proxy01:~/bin$ ./swiftcl.sh stat
> > swift -A http://proxy01:8080/auth/v1.0 -U system:root -K testpass stat
> >Account: AUTH_system
> > Containers: 6
> >Objects: 5
> >  Bytes: 59756210
> > Accept-Ranges: bytes
> > X-Timestamp: 1351294912.72119
> >
> > Here's the corresponding log on the Proxy:
> >
> > Oct 26 17:06:52 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/06/52
> GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010
> > Oct 26 17:07:13 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/13
> GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0017
> > Oct 26 17:07:13 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/13
> GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016
> > Oct 26 17:07:22 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/22
> GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010
> > Oct 26 17:07:22 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/22
> GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016
> > Oct 26 17:07:27 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/27
> GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010
> > Oct 26 17:07:27 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/27
> GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016
> > Oct 26 17:07:27 proxy01 proxy-server Handoff requested (1) (txn:
> tx6946419daba54efe9c2878f8a2a78f88) (client_ip: 172.16.1.111)
> > Oct 26 17:07:27 proxy01 proxy-server Handoff requested (2) (txn:
> tx6946419daba54efe9c2878f8a2a78f88) (client_ip: 172.16.1.111)
> > Oct 26 17:07:33 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/33
> GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0010
> > Oct 26 17:07:33 proxy01 proxy-server - 127.0.0.1 27/Oct/2012/00/07/33
> GET /auth/v1.0/ HTTP/1.0 200 - - - - - - - - 0.0016
> > Oct 26 17:07:33 proxy01 proxy-server Handoff requested (1) (txn:
> tx5f9659f74cb2491f

Re: [Openstack] Retrieve Endpoints

[Dolph Mathews]

It's hard to say without docs, as the openstack.identity.endpoint shown
there is just throwing errors for me, and the openstack.endpoint is raising
401.

However, the port used for the identity endpoint is typically used for the
administrative/management identity endpoint (keystone), and the
openstack.endpoint refers to specifically to "compute" in the hostname
(nova).

-Dolph


On Sun, Oct 28, 2012 at 11:21 PM, Tummala Pradeep <
pradeep.tumm...@ericsson.com> wrote:

>  Hi Joe,
>
> I am actually trying to integrate cloudify with Openstack. To accomplish
> this, I have to configure openstack.groovy file in cloudify.
>
> There are two fields here - openstack.endpoint &
> openstack.identity.endpoint. I have an example for cloudify integration
> with HP Openstack cloud. Hope, it will help you to understand what exactly
> these two fields (Last 4 lines) require.
>
>   
>   cloud {
>
>   // Mandatory. The name of the cloud, as it will appear in the Cloudify 
> UI.
>   name = "Openstack"
>   configuration {
>   // Mandatory - openstack Diablo cloud driver.
>   className 
> "org.cloudifysource.esc.driver.provisioning.openstack.OpenstackCloudDriver"
>   // Optional. The template name for the management machines. 
> Defaults to the first template in the templates section below.
>   managementMachineTemplate "SMALL_LINUX"
>   **// Optional. Indicates whether internal cluster 
> communications should use the machine private IP. Defaults to true.
>   connectToPrivateIp true
>remoteUsername "REPLACE_WITH_THE_SSH_USER_NAME"
>remotePassword "REPLACE_WITH_THE_SS_USER_PASSWORD"
>   }
>   provider {
>   // optional
>   provider "openstack"
>   localDirectory "tools/cli/plugins/esc/hp/upload"
>   remoteDirectory "/root/gs-files"
>   cloudifyUrl 
> "http://s3.amazonaws.com/gigaspaces-cloudify/cloudify/hp/gigaspaces-hp.zip"; 
> 
>   machineNamePrefix "agent"
>   dedicatedManagementMachines true
>   managementOnlyFiles ([])
>   managementGroup "management"
>   numberOfManagementMachines 1
>   zones (["agent"])
>   reservedMemoryCapacityPerMachineInMB 1024
>   }
>   user {
>   user "ENTER_USER"
>   apiKey "ENTER_KEY"
>   keyFile "ENTER_KEY_FILE"
>   }
>   templates ([
>   SMALL_LINUX : template{
>   imageId "221"
>   machineMemoryMB 1600
>   
>   hardwareId "102"
>   //locationId "us-east-1"
>   options ([
>   "openstack.securityGroup" : 
> "test",
>   "openstack.keyPair" : 
> "hp-cloud-demo",
>   // indicates if a floating IP 
> should be assigned to this machine. Defaults to true.
>   
> "openstack.allocate-floating-ip" : "true"
>   ])
>   }
>   ])
>   custom ([
>   *"openstack.endpoint" : 
> "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/"; 
> ,*
> * "openstack.identity.endpoint": 
> "https://region-a.geo-1.identity.hpcloudsvc.com:35357/"; 
> ,*
>   "openstack.tenant" : "ENTER_TENANT",
>   "openstack.wireLog": "false"
>   ])
> }
>
> Now, I am trying the integration with OpenStack deployed on my server. Do
> let me know if you get any idea from the above example.
>
> Thanks
>
> Pradeep
>
>
> On 10/26/2012 01:36 AM, heckj wrote:
>
> Hi Pradeep,
>
> I'm not sure what the context is for these values, so it's a little hard to 
> assert a clear answer.
>
> For most openstack projects, (all but keystone), there's generally a single 
> API endpoints, and the keystone service catalog is configured on deployment 
> to point to those. The service catalog supports exposing internal and public 
> endpoints.
>
> Keystone (quirky thing that it is) has two endpoints - one for general public 
> authorization with a very limited API - in the docs and on the CLI, this is 
> referred to as the "auth_url". In a devstack setup, this auth_url is 
> "http://localhost:5000/v2.0";  - your deployment 
> I'd expect to be different.
>
> There's also an administrative endpoint for Keystone where a Keystone admin 
> (or associated scripts) can configure services, endpoints, users, etc 
> depending on the keystone 

[Openstack] Nova different sr

[Egoitz Aurrekoetxea Aurre]

Good afternoon,

Is it possible for Nova to deploy vm in different storages?? rather than just 
use the storage which matches sr_matching_filter parameter??

Best regards,

___
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] Quotas in folsom

[Mitchell Broome]

I'm running into quota problems trying to increase the number of
security groups and rules within security groups per tenant.  Setting
quota_security_groups and quota_security_group_rules in nova.conf seem
to have no effect.  There also doesn't seem to be any way to change
the quota limits for security groups through the nova client or
horizon.

How do I go about changing these quotas or is there a way to disable
all quotas all together?

___
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] Instrumentation Monitoring Next Step - quick meet up

[Sandy Walsh]

Ugh, I just realized I have a conflict. Can we push it an hour later? (sorry!)

-S


From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Annie Cheng [ann...@yahoo-inc.com]
Sent: Monday, October 29, 2012 11:18 AM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Apologize .. Correction

Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (3pm PDT if you are in California)
Location: IRC #openstack-meeting


From: Annie Cheng mailto:ann...@yahoo-inc.com>>
Date: Mon, 29 Oct 2012 07:14:08 -0700
To: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Reminder:
Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in California)
Location: IRC #openstack-meeting

Thanks!

Annie

From: Annie Cheng mailto:ann...@yahoo-inc.com>>
Date: Thu, 25 Oct 2012 14:17:09 -0700
To: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Hi all,

Couple of us chat in the summit design sessions and and after summit on 
#openstack irc regarding topic of Monitoring.  We think it's best to do a quick 
meeting to get everyone on the same page, split works, and get at least a 
prototype going in Grizzly.

Time: Monday (10/29/2012) 2200 UTC – 2300 UTC
Location: IRC #openstack-meeting
I checked http://wiki.openstack.org/Meetings, this tme slot seems to be empty

Top level agenda would be

  1.  Get everyone on the same page on high level direction
  2.  Discuss different design/implementation possibility
  3.  Split up works

Before the meeting, if you want to read up, here are some links I know.  Please 
jump in with others I missed:
Blueprint:
https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring
Etherpad:
https://etherpad.openstack.org/grizzly-common-instrumentation
Different code samples:
https://github.com/asalkeld/statgen

Looking forward, some of those conversation probably will fold into the regular 
Metering meeting.  Just like to do a one off for now so we can go deeper on 
monitoring specific topics.

Thanks!

Annie
___
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] Instrumentation Monitoring Next Step - quick meet up

[Annie Cheng]

Apologize .. Correction

Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (3pm PDT if you are in California)
Location: IRC #openstack-meeting


From: Annie Cheng mailto:ann...@yahoo-inc.com>>
Date: Mon, 29 Oct 2012 07:14:08 -0700
To: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Reminder:
Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in California)
Location: IRC #openstack-meeting

Thanks!

Annie

From: Annie Cheng mailto:ann...@yahoo-inc.com>>
Date: Thu, 25 Oct 2012 14:17:09 -0700
To: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Hi all,

Couple of us chat in the summit design sessions and and after summit on 
#openstack irc regarding topic of Monitoring.  We think it's best to do a quick 
meeting to get everyone on the same page, split works, and get at least a 
prototype going in Grizzly.

Time: Monday (10/29/2012) 2200 UTC – 2300 UTC
Location: IRC #openstack-meeting
I checked http://wiki.openstack.org/Meetings, this tme slot seems to be empty

Top level agenda would be

 1.  Get everyone on the same page on high level direction
 2.  Discuss different design/implementation possibility
 3.  Split up works

Before the meeting, if you want to read up, here are some links I know.  Please 
jump in with others I missed:
Blueprint:
https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring
Etherpad:
https://etherpad.openstack.org/grizzly-common-instrumentation
Different code samples:
https://github.com/asalkeld/statgen

Looking forward, some of those conversation probably will fold into the regular 
Metering meeting.  Just like to do a one off for now so we can go deeper on 
monitoring specific topics.

Thanks!

Annie
___
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] Instrumentation Monitoring Next Step - quick meet up

[Annie Cheng]

Reminder:
Time: Monday (10/29/2012) 2200 UTC – 2300 UTC (2pm PDT if you are in California)
Location: IRC #openstack-meeting

Thanks!

Annie

From: Annie Cheng mailto:ann...@yahoo-inc.com>>
Date: Thu, 25 Oct 2012 14:17:09 -0700
To: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: [Openstack] Instrumentation Monitoring Next Step - quick meet up

Hi all,

Couple of us chat in the summit design sessions and and after summit on 
#openstack irc regarding topic of Monitoring.  We think it's best to do a quick 
meeting to get everyone on the same page, split works, and get at least a 
prototype going in Grizzly.

Time: Monday (10/29/2012) 2200 UTC – 2300 UTC
Location: IRC #openstack-meeting
I checked http://wiki.openstack.org/Meetings, this tme slot seems to be empty

Top level agenda would be

 1.  Get everyone on the same page on high level direction
 2.  Discuss different design/implementation possibility
 3.  Split up works

Before the meeting, if you want to read up, here are some links I know.  Please 
jump in with others I missed:
Blueprint:
https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring
Etherpad:
https://etherpad.openstack.org/grizzly-common-instrumentation
Different code samples:
https://github.com/asalkeld/statgen

Looking forward, some of those conversation probably will fold into the regular 
Metering meeting.  Just like to do a one off for now so we can go deeper on 
monitoring specific topics.

Thanks!

Annie
___
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 mailing list for bare-metal provisioning

[Sean Dague]

On 10/28/2012 08:19 PM, David Kang wrote:


  I agree that subject prefix is a way.
There are pros and cons of either approach.
However, when I asked a few of the people who showed interest in bare-metal 
discussion,
a new mailing list was preferred by them.
And we thought a separate mailing list makes people easier to participate and 
to manage the discussion.

  We can discuss this issue again among the people who signed up the new 
mailing list.


I think the more general concern is that part of the challenges of 
getting the current bare-metal approach in has been that it's largely 
been developed on the side. I think the path for successful evolution of 
bare-metal in nova is to stop thinking about it as a side effort, and 
more a part of normal nova development, as other changes in nova will 
have implications for bare-metal for sure.


So driving the discussion back onto the main list would be really 
beneficial.


-Sean

--
Sean Dague
IBM Linux Technology Center
email: sda...@linux.vnet.ibm.com
alt-email: slda...@us.ibm.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 mailing list for bare-metal provisioning

[Stefano Maffulli]

On 10/29/2012 12:32 PM, Thierry Carrez wrote:

We really shouldn't go in that direction: the openstack-dev list is
already an aggregator of topics, since we use "mailman topics" on it.


Indeed, mailman topics are very powerful. The current topics for 
openstack-dev are listed on each subscriber's personal page:


http://lists.openstack.org/cgi-bin/mailman/options/openstack-dev

As a subscriber of openstack-dev I can decide to receive only messages 
tagged for a topic by selecting the ones I'm interested in. As a writer 
of a message I can tag it by adding the topic to the subject line of the 
message.


For example, if I want to receive only messages for Nova, I can 
subscribe to the Nova topic at the link above. When I write a message 
about nova I have to add '[Nova]' (or 'Nova') anywhere in the subject.


Creating a topic of bare-metal is easy, using topics is a matter of 
habit. I believe that we should not create more lists unless strictly 
necessary. I also understood from David that the baremetal group felt 
very strongly against using any of the existing list, even when I 
suggested to use topics. I'm glad we're having this conversation now and 
I'm open to any outcome.


/stef

___
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] How can I specify which filesystem to use for ephemeral storage per image?

[Erik Lindblad]

Hi!

I'm running a nova cloud (essex) with both linux and windows
instances. I want the windows images to boot with an ephemeral
pre-formatted ntfs drive.

I've tried setting:
virt_mkfs="windows=mkfs.ntfs --force --fast --label %(fs_label)s %(target)s"

in nova.conf and I've also set the os_type metadata on the windows
image, but nova still uses ext4:
2012-10-29 12:41:24 DEBUG nova.utils
[req-33b476e7-6412-4caa-ba51-839c36ab35b0
ec731931e03544d89e46468a3a268d9b 526fedd9083647fbbbc167261f10ecfc]
Running cmd (subprocess): mkfs.ext4 -L ephemeral0 -F
/var/lib/nova/instances/_base/ephemeral_0_20_windows from (pid=10597)
execute /usr/lib/python2.7/dist-packages/nova/utils.py:219

Cheers,
Erik

___
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] Failed to get metadata for ip x.x.x.x

[John Garbutt]

If you are using XenServer I automatically install the tools shipped with the 
product.
It is a free download, so that might be your best bet for getting started right 
now.

I will follow up with the XCP guys to see what we should be doing long term.

Thank you for the heads up!

John

From: Afef MDHAFFAR [mailto:afef.mdhaf...@gmail.com]
Sent: Monday, October 29, 2012 7:53 AM
To: John Garbutt
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Failed to get metadata for ip x.x.x.x

Hi,

The folsom release solves the problem!
However, I noticed that the url used by devstack to download xe-guest-utilities 
(http://images.ansolabs.com/xen/xe-guest-utilities_5.6.100-651_amd64.deb) does 
not work any more. For me, I just used my last downloads. But, a new devstack 
user will not be able to install openstack with XCP, without this deb file. 
Please try to fix this problem as soon as possible.

Thank you

Regards,
Afef

2012/10/29 John Garbutt 
mailto:john.garb...@citrix.com>>
I was fairly sure trunk has been fixed now, just about the sametime his patch 
was uploaded, that had other issues.

Are you still seeing the problem?

I will double check the bug has been updated when I get online.

Thanks,
John


Robert Collins mailto:robe...@robertcollins.net>> 
wrote:
On Tue, Oct 9, 2012 at 3:56 AM, John Garbutt 
mailto:john.garb...@citrix.com>> wrote:
> I think Mate has just spotted this bug on trunk this morning.
>
> He should be raising the bug and uploading a patch for that ASAP.
>
> Clearly some unit tests are missing in this bit of code.

It's been nearly three weeks now - can we revert the broken patch
(which looks like it will break for everyone) and get back to a good
state? If thats acceptable, I'll propose a patch to do that.

-Rob




___
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 mailing list for bare-metal provisioning

[Thierry Carrez]

Sam Stoelinga wrote:
> If mailing list gets separated, it would be good to have an aggregate
> mailing list we can subscribe to which has all nova related mailing lists.

We really shouldn't go in that direction: the openstack-dev list is
already an aggregator of topics, since we use "mailman topics" on it.

I see a lot of drawbacks in having the ML separate. The only drawback I
can think of in having the baremetal discussions on the main
openstack-dev list is that some people might only want to receive
baremetal stuff. Those (hopefully rare) people can use client-side
filtering on the subject... or we also can setup a "baremetal" mailman
topic so that you can directly filter using your ML preferences.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

___
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 mailing list for bare-metal provisioning

[Sam Stoelinga]

If mailing list gets separated, it would be good to have an aggregate
mailing list we can subscribe to which has all nova related mailing lists.

On Mon, Oct 29, 2012 at 3:53 PM, Gary Kotton  wrote:

>  On 10/29/2012 02:59 AM, Asher Newcomer wrote:
>
> +1
>
> On Sun, Oct 28, 2012 at 8:39 PM, Russell Bryant wrote:
>
>> On 10/28/2012 08:19 PM, David Kang wrote:
>> >
>> >  I agree that subject prefix is a way.
>> > There are pros and cons of either approach.
>> > However, when I asked a few of the people who showed interest in
>> bare-metal discussion,
>> > a new mailing list was preferred by them.
>> > And we thought a separate mailing list makes people easier to
>> participate and to manage the discussion.
>> >
>> >  We can discuss this issue again among the people who signed up the new
>> mailing list.
>>
>>  There are quite a few people, like myself, who are interested in *all*
>> nova development.  Signing up for a new mailing list for every new
>> development effort would be a nightmare to keep up with.  I *really,
>> really* think the list should be dropped and all discussions should be
>> on openstack-dev.
>>
>
> I agree.
>
>
>> --
>> Russell Bryant
>>
>> ___
>> 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] Failed to get metadata for ip x.x.x.x

[Robert Collins]

On Mon, Oct 29, 2012 at 8:34 PM, John Garbutt  wrote:
> I was fairly sure trunk has been fixed now, just about the sametime his
> patch was uploaded, that had other issues.
>
> Are you still seeing the problem?

I reproduced it on the baremetal branch we've been hacking on, which
isn't completely up to date with trunk, reverting the patch identified
by Thierry fixed it for me, so we're working with that reverted
locally for now. It's my EOD but I'm sure we can try to reproduce with
tip itself easily enough.

> I will double check the bug has been updated when I get online.

It hasn't :)

-Rob

___
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 mailing list for bare-metal provisioning

[Gary Kotton]

On 10/29/2012 02:59 AM, Asher Newcomer wrote:

+1

On Sun, Oct 28, 2012 at 8:39 PM, Russell Bryant > wrote:


On 10/28/2012 08:19 PM, David Kang wrote:
>
>  I agree that subject prefix is a way.
> There are pros and cons of either approach.
> However, when I asked a few of the people who showed interest in
bare-metal discussion,
> a new mailing list was preferred by them.
> And we thought a separate mailing list makes people easier to
participate and to manage the discussion.
>
>  We can discuss this issue again among the people who signed up
the new mailing list.

There are quite a few people, like myself, who are interested in *all*
nova development.  Signing up for a new mailing list for every new
development effort would be a nightmare to keep up with.  I *really,
really* think the list should be dropped and all discussions should be
on openstack-dev.



I agree.



--
Russell Bryant

___
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] Failed to get metadata for ip x.x.x.x

[Afef MDHAFFAR]

Hi,

The folsom release solves the problem!
However, I noticed that the url used by devstack to download
xe-guest-utilities (
http://images.ansolabs.com/xen/xe-guest-utilities_5.6.100-651_amd64.deb)
does not work any more. For me, I just used my last downloads. But, a new
devstack user will not be able to install openstack with XCP, without this
deb file. Please try to fix this problem as soon as possible.

Thank you

Regards,
Afef


2012/10/29 John Garbutt 

>  I was fairly sure trunk has been fixed now, just about the sametime his
> patch was uploaded, that had other issues.
>
> Are you still seeing the problem?
>
> I will double check the bug has been updated when I get online.
>
> Thanks,
> John
>
>
> Robert Collins  wrote:
> On Tue, Oct 9, 2012 at 3:56 AM, John Garbutt 
> wrote:
> > I think Mate has just spotted this bug on trunk this morning.
> >
> > He should be raising the bug and uploading a patch for that ASAP.
> >
> > Clearly some unit tests are missing in this bit of code.
>
> It's been nearly three weeks now - can we revert the broken patch
> (which looks like it will break for everyone) and get back to a good
> state? If thats acceptable, I'll propose a patch to do that.
>
> -Rob
>
___
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] Failed to get metadata for ip x.x.x.x

[John Garbutt]

I was fairly sure trunk has been fixed now, just about the sametime his patch 
was uploaded, that had other issues.

Are you still seeing the problem?

I will double check the bug has been updated when I get online.

Thanks,
John


Robert Collins  wrote:
On Tue, Oct 9, 2012 at 3:56 AM, John Garbutt  wrote:
> I think Mate has just spotted this bug on trunk this morning.
>
> He should be raising the bug and uploading a patch for that ASAP.
>
> Clearly some unit tests are missing in this bit of code.

It's been nearly three weeks now - can we revert the broken patch
(which looks like it will break for everyone) and get back to a good
state? If thats acceptable, I'll propose a patch to do that.

-Rob
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp