[Openstack] Howto Nova setup with HA?

[i3D.net - Tristan van Bokkem]

Hi Stackers,

It seems running Openstack components in High Availability hasn't been really a 
focus point lately, am I right?

The general docs don't really mention HA except for nova-network. So I did some 
resource on how to run Nova in a High Availability and have some questions 
about it:

The docs guides you on how to setup one cloud controller (running MySQL, 
nova-api, RabbitMQ etc.) and 2+n nodes for nova compute/network. But it does 
not mention how to make the cloud controller redundant. If the cloud controller 
brakes we have a serious problem!

So, we can run MySQL in master-master mode on multiple hosts, we can run 
nova-api on serveral hosts and load balance those and RabbitMQ has a cluster ha 
setup as well but is this the way to go? I can't find a clear answer to this. I 
am hoping one can shine some light on this!

Best regards,

Tristan van Bokkem
Datacenter Operations

Contact:
E-mail Personal: tristanvanbok...@i3d.net
E-mail Support: i...@i3d.net
E-mail NOC: n...@i3d.net
Website: http://www.i3d.net Office:
Interactive 3D B.V.
Meent 93b
3011 JG Rotterdam
The Netherlands

Visit www.smartdc.net – SmartDC is our in-house 36,000 sq. ft. datacenter in 
Rotterdam, The Netherlands. High density hosting – multiple fiber carriers 
in-house – Level3 PoP.

Interactive 3D (i3D.net) is a company registered in The Netherlands at Meent 
93b, Rotterdam. Registration #: 14074337 - VAT # NL 8202.63.886.B01. 
Interactive 3D (i3D.net) is CDSA certified on content protection and security. 
We are ranked in the Deloitte Technology Fast 50 as one of the fastest growing 
technology companies.___
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] python-swiftclient?

[Juan J.]

On Mon, 2012-02-13 at 15:29 +0100, Chmouel Boudjnah wrote:
 [...]
 https://github.com/chmouel/python-swiftclient
 
 Let me know what do you think.

+1, we did that internally some time ago.

We're the swift structure (swift.commn.client) and added bufferedhttp.py
too to the swift-client package. What do you think about that?

Regards,

Juan

-- 
Juan J. Martinez
Development, MEMSET

mail: j...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.


___
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] NFS for nova-volume

[Christian Berendt]

Hi Salman.

On Mon, 13 Feb 2012 20:21:30 -0500
Salman A Baset saba...@us.ibm.com wrote:
 I was wondering if anyone has tried setting up nova-volume on NFS
 backend without making any changes to nova-volume code?

I think it's not possible to do that without any changes to the
nova-volume code at the moment.

We opened a report for this missing feature a long time ago:
https://bugs.launchpad.net/nova/+bug/715102. But we had no time to
finish the implementation. Feel free.. :)

HTH, Christian.

-- 
Christian Berendt
Linux / Unix Consultant  Developer
Mail: bere...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

___
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] NFS for nova-volume

[Diego Parrilla Santamaría]

We have developed a QEMUDriver for stable/diablo, sadly the essex build is
still broken. We are a bit overwhelmed, and we would like to contribute it
in the future (gue rivero will help us with Gerrit).

Still, if anybody wants to test it in stable/diablo, we are more than open
to help him to use it.

Cheers
Diego
-- 
Diego Parrilla
http://www.stackops.com/*CEO*
*www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29 |
skype:diegoparrilla*
* http://www.stackops.com/
**



On Tue, Feb 14, 2012 at 2:21 AM, Salman A Baset saba...@us.ibm.com wrote:

  Hello folks,

 I was wondering if anyone has tried setting up nova-volume on NFS backend
 without making any changes to nova-volume code?

 There is a Xen Storage Manager Volume driver that can support NFS, but I
 am looking for a non-Xen solution.
 http://nova.openstack.org/devref/xensmvolume.html

 Thanks.
 Salman

 ___
 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] Howto Nova setup with HA?

[Christian Berendt]

Hi Tristan.

 So, we can run MySQL in master-master mode on multiple hosts, we can
 run nova-api on serveral hosts and load balance those and RabbitMQ
 has a cluster ha setup as well but is this the way to go? I can't
 find a clear answer to this. I am hoping one can shine some light on
 this!

I would prefer to use MySQL Cluster:
http://www.mysql.com/products/cluster/. You meant that with MySQL
master-master?

For RabbitMQ there are several ways to setup it:
http://www.rabbitmq.com/ha.html.

I think the customer site has to decide which HA setup they want use.
All types have advantages and disadvantages.

HTH, Christian.

-- 
Christian Berendt
Linux / Unix Consultant  Developer
Mail: bere...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

___
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] Howto Nova setup with HA?

[Sébastien Han]

Hi Tristan,

When I saw your post, I though what about an pacemaker ressource agent?
Corosync for the messaging layer and pacemaker for the ressource
management. Maybe someone as wrote a script ressource agent for nova in
order to manage the failover.
Also DRBD can be useful.
And then after a couple of research on Google, I found this 3 links:

   - https://lists.launchpad.net/openstack/pdfGiNwMEtUBJ.pdf
   - http://wiki.openstack.org/HAforNovaDB
   - http://www.pixelbeat.org/docs/pacemaker-cloud/

Hope this will help you.

--
Yours sincerely.
Sébastien HAN.



On Tue, Feb 14, 2012 at 12:05 PM, i3D.net - Tristan van Bokkem 
tristanvanbok...@i3d.nl wrote:

 **
 Hi Christian,

 Thanks for your reply.

 With mysql master/master i meant the following: http://mysql-mmm.org/ but
 it seems they are using 2 different locations for mysql reads and writes.
 Something nova is (yet) not able to configure (i.e. --sql_connection= which
 is being used for reads and rights.)

 Maybe http://www.mysql.com/products/cluster/ is a better way..

 RabbitMQ HA i am aware of. This is something we are looking at as well.

 The main question is how does other companies reach HA with openstack? I
 can't find any good information on the net about it.
 And how does Essex change things?


 Best regards,

 Tristan van Bokkem
 Datacenter Operations

 Contact:
 E-mail Personal: tristanvanbok...@i3d.net
 E-mail Support: i...@i3d.net
 E-mail NOC: n...@i3d.net
 Website: http://www.i3d.net Office:
 Interactive 3D B.V.
 Meent 93b
 3011 JG Rotterdam
 The Netherlands

 Visit www.smartdc.net – SmartDC is our in-house 36,000 sq. ft. datacenter
 in Rotterdam, The Netherlands. High density hosting – multiple fiber
 carriers in-house – Level3 PoP.

 Interactive 3D (i3D.net) is a company registered in The Netherlands at
 Meent 93b, Rotterdam. Registration #: 14074337 - VAT # NL 8202.63.886.B01.
 Interactive 3D (i3D.net) is CDSA certified on content protection and
 security. We are ranked in the Deloitte Technology Fast 50 as one of the
 fastest growing technology companies.

 --
 *From:* Christian Berendt [mailto:bere...@b1-systems.de]
 *To:* i3D.net - Tristan van Bokkem [mailto:tristanvanbok...@i3d.nl]
 *Cc:* openstack@lists.launchpad.net
 *Sent:* Tue, 14 Feb 2012 11:54:38 +0100
 *Subject:* Re: [Openstack] Howto Nova setup with HA?


 Hi Tristan.

  So, we can run MySQL in master-master mode on multiple hosts, we can
  run nova-api on serveral hosts and load balance those and RabbitMQ
  has a cluster ha setup as well but is this the way to go? I can't
  find a clear answer to this. I am hoping one can shine some light on
  this!

 I would prefer to use MySQL Cluster:
 http://www.mysql.com/products/cluster/. You meant that with MySQL
 master-master?

 For RabbitMQ there are several ways to setup it:
 http://www.rabbitmq.com/ha.html.

 I think the customer site has to decide which HA setup they want use.
 All types have advantages and disadvantages.

 HTH, Christian.

 --
 Christian Berendt
 Linux / Unix Consultant  Developer
 Mail: bere...@b1-systems.de

 B1 Systems GmbH
 Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
 GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537


 ___
 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] Howto Nova setup with HA?

[Major Hayden]

On Feb 14, 2012, at 2:07 AM, i3D.net - Tristan van Bokkem wrote:

 So, we can run MySQL in master-master mode on multiple hosts, we can run 
 nova-api on serveral hosts and load balance those and RabbitMQ has a cluster 
 ha setup as well but is this the way to go? I can't find a clear answer to 
 this. I am hoping one can shine some light on this!

If you want to make things a little simpler, an active/passive MySQL setup with 
pacemaker, corosync, and DRBD will work quite well.  ClusterLabs has a pretty 
decent howto on their site:

  http://www.clusterlabs.org/wiki/DRBD_MySQL_HowTo

As for RabbitMQ clustering, I worked with it for several days and had quite a 
few problems with data consistency and availability.  We eventually settled on 
the legacy H/A method for RabbitMQ using pacemaker and DRBD.  There's a 
pretty good walkthrough on RabbitMQ's site:

  http://www.rabbitmq.com/pacemaker.html

-- 
Major Hayden
___
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] python-swiftclient?

[Juan J.]

On Tue, 2012-02-14 at 12:14 +, Chmouel Boudjnah wrote:
 2012/2/14 Juan J. juan@:
  https://github.com/chmouel/python-swiftclient
  +1, we did that internally some time ago.
  We're the swift structure (swift.commn.client) and added bufferedhttp.py
  too to the swift-client package. What do you think about that?
 
 I think this is great but that would need to depend of the swiftclient
 package for swift (or duplicated code) and I don't know if the swift
 team would want that.

I don't know the answer, but I wouldn't install swift-client package
where Swift is already installed (I guess both packages should
conflict).

My point in my previous mail is that instead of a fork that can get out
of sync, looks like that's just a packaging problem. That's why I didn't
bother to release my swift-client package, because it's just a setup.py
for swift.common.client.

My 2 cents, I still think that it's a brilliant idea distribute a
swift-client package that it's independent of swift.

Regards,

Juan

-- 
Juan J. Martinez
Development, MEMSET

mail: j...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.


___
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] Fwd: NFS for nova-volume

[Diego Parrilla Santamaría]

Hi Salman,

you can checkout the directory in our stable/diablo branch in our repos in
GitHub:

https://github.com/StackOps/nova/commits/stable/diablo

You need to configure it as follows:

- NovaVolume nodes must have access to qemu-img executable. Otherwise it
won't be able to create the nodes.
- Share a filesystem for the volumes, for example /var/lib/nova/volumes
- in the configuration file of NovaVolume, you need to enter this flags:
flags.DEFINE_string('volumes_path', '/var/lib/nova/volumes', 'shared
directory for the volumes virtual disks')
flags.DEFINE_string('volumes_path_testfile', '%s/testfile' %
FLAGS.volumes_path, 'Test file to check if qemu-img works')
flags.DEFINE_string('volume_driver', 'nova.volume.nas.QEMUDriver', 'QEMU
Volumes driver')

We have an experimental release in our 0.4 version of the StackOps Distro
and in our Enterprise Distro, hopefully to release in the coming weeks.
Cheers
Diego
-- 
 Diego Parrilla
http://www.stackops.com*CEO*
*www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29 |
skype:diegoparrilla*
* http://www.stackops.com
*

*

 ADVERTENCIA LEGAL 
Le informamos, como destinatario de este mensaje, que el correo electrónico
y las comunicaciones por medio de Internet no permiten asegurar ni
garantizar la confidencialidad de los mensajes transmitidos, así como
tampoco su integridad o su correcta recepción, por lo que STACKOPS
TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias.
Si no consintiese en la utilización del correo electrónico o de las
comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro
conocimiento de manera inmediata. Este mensaje va dirigido, de manera
exclusiva, a su destinatario y contiene información confidencial y sujeta
al secreto profesional, cuya divulgación no está permitida por la ley. En
caso de haber recibido este mensaje por error, le rogamos que, de forma
inmediata, nos lo comunique mediante correo electrónico remitido a nuestra
atención y proceda a su eliminación, así como a la de cualquier documento
adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o
utilización de este mensaje, o de cualquier documento adjunto al mismo,
cualquiera que fuera su finalidad, están prohibidas por la ley.

* PRIVILEGED AND CONFIDENTIAL 
We hereby inform you, as addressee of this message, that e-mail and
Internet do not guarantee the confidentiality, nor the completeness or
proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L.
does not assume any liability for those circumstances. Should you not agree
to the use of e-mail or to communications via Internet, you are kindly
requested to notify us immediately. This message is intended exclusively
for the person to whom it is addressed and contains privileged and
confidential information protected from disclosure by law. If you are not
the addressee indicated in this message, you should immediately delete it
and any attachments and notify the sender by reply e-mail. In such case,
you are hereby notified that any dissemination, distribution, copying or
use of this message or any attachments, for any purpose, is strictly
prohibited by law.





2012/2/14 Diego Parrilla Santamaría diego.parrilla.santama...@gmail.com

 We have developed a QEMUDriver for stable/diablo, sadly the essex build is
 still broken. We are a bit overwhelmed, and we would like to contribute it
 in the future (gue rivero will help us with Gerrit).

 Still, if anybody wants to test it in stable/diablo, we are more than open
 to help him to use it.

 Cheers
 Diego
 --
 Diego Parrilla
 http://www.stackops.com/*CEO*
 *www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29 |
 skype:diegoparrilla*
 * http://www.stackops.com/
 **



 On Tue, Feb 14, 2012 at 2:21 AM, Salman A Baset saba...@us.ibm.comwrote:

  Hello folks,

 I was wondering if anyone has tried setting up nova-volume on NFS backend
 without making any changes to nova-volume code?

 There is a Xen Storage Manager Volume driver that can support NFS, but I
 am looking for a non-Xen solution.
 http://nova.openstack.org/devref/xensmvolume.html

 Thanks.
 Salman

 ___
 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] Fwd: NFS for nova-volume

[Salman A Baset]

Hi Diego,

Many thanks. Let me try it.

Salman



From:   Diego Parrilla Santamaría diego.parrilla.santama...@gmail.com
To: openstack@lists.launchpad.net
Date:   02/14/2012 11:53 AM
Subject:[Openstack] Fwd:  NFS for nova-volume
Sent by:openstack-bounces+sabaset=us.ibm@lists.launchpad.net



Hi Salman,

you can checkout the directory in our stable/diablo branch in our repos in
GitHub:

https://github.com/StackOps/nova/commits/stable/diablo

You need to configure it as follows:

- NovaVolume nodes must have access to qemu-img executable. Otherwise it
won't be able to create the nodes.
- Share a filesystem for the volumes, for example /var/lib/nova/volumes
- in the configuration file of NovaVolume, you need to enter this flags:
flags.DEFINE_string('volumes_path', '/var/lib/nova/volumes', 'shared
directory for the volumes virtual disks')
flags.DEFINE_string('volumes_path_testfile', '%s/testfile' %
FLAGS.volumes_path, 'Test file to check if qemu-img works')
flags.DEFINE_string('volume_driver', 'nova.volume.nas.QEMUDriver', 'QEMU
Volumes driver')

We have an experimental release in our 0.4 version of the StackOps Distro
and in our Enterprise Distro, hopefully to release in the coming weeks.
Cheers
Diego
--
Diego Parrilla
CEO
www.stackops.com |  diego.parri...@stackops.com | +34 649 94 43 29 |
skype:diegoparrilla





 ADVERTENCIA LEGAL 
Le informamos, como destinatario de este mensaje, que el correo electrónico
y las comunicaciones por medio de Internet no permiten asegurar ni
garantizar la confidencialidad de los mensajes transmitidos, así como
tampoco su integridad o su correcta recepción, por lo que STACKOPS
TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias.
Si no consintiese en la utilización del correo electrónico o de las
comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro
conocimiento de manera inmediata. Este mensaje va dirigido, de manera
exclusiva, a su destinatario y contiene información confidencial y sujeta
al secreto profesional, cuya divulgación no está permitida por la ley. En
caso de haber recibido este mensaje por error, le rogamos que, de forma
inmediata, nos lo comunique mediante correo electrónico remitido a nuestra
atención y proceda a su eliminación, así como a la de cualquier documento
adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o
utilización de este mensaje, o de cualquier documento adjunto al mismo,
cualquiera que fuera su finalidad, están prohibidas por la ley.

* PRIVILEGED AND CONFIDENTIAL 
We hereby inform you, as addressee of this message, that e-mail and
Internet do not guarantee the confidentiality, nor the completeness or
proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L.
does not assume any liability for those circumstances. Should you not agree
to the use of e-mail or to communications via Internet, you are kindly
requested to notify us immediately. This message is intended exclusively
for the person to whom it is addressed and contains privileged and
confidential information protected from disclosure by law. If you are not
the addressee indicated in this message, you should immediately delete it
and any attachments and notify the sender by reply e-mail. In such case,
you are hereby notified that any dissemination, distribution, copying or
use of this message or any attachments, for any purpose, is strictly
prohibited by law.








2012/2/14 Diego Parrilla Santamaría diego.parrilla.santama...@gmail.com
  We have developed a QEMUDriver for stable/diablo, sadly the essex build
  is still broken. We are a bit overwhelmed, and we would like to
  contribute it in the future (gue rivero will help us with Gerrit).

  Still, if anybody wants to test it in stable/diablo, we are more than
  open to help him to use it.

  Cheers
  Diego
  --
  Diego Parrilla
  CEO
  www.stackops.com |  diego.parri...@stackops.com | +34 649 94 43 29
  | skype:diegoparrilla



  On Tue, Feb 14, 2012 at 2:21 AM, Salman A Baset saba...@us.ibm.com
  wrote:
   Hello folks,

   I was wondering if anyone has tried setting up nova-volume on NFS
   backend without making any changes to nova-volume code?

   There is a Xen Storage Manager Volume driver that can support NFS, but I
   am looking for a non-Xen solution.
   http://nova.openstack.org/devref/xensmvolume.html

   Thanks.
   Salman

   ___
   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
inline: 

Re: [Openstack] Any block storage folks interested in getting together?

[Vladimir Popovski]

Folks,



We’ve used IRC #openstack-volumes for that and had a mailing-list set up
for the team. Check it out on https://launchpad.net/~openstack-volume



Unfortunately, there was not much going on lately. Primarily I suppose you
can blame me on this as our team was completely overwhelmed by
production/beta launch and we had no chance to contribute.



It will be great to get together and I’m looking forward for it.



Regards,

-Vladimir

Zadara Storage





*From:* openstack-bounces+vladimir=zadarastorage@lists.launchpad.net[mailto:
openstack-bounces+vladimir=zadarastorage@lists.launchpad.net] *On
Behalf Of *Oleg Gelbukh
*Sent:* Monday, February 13, 2012 9:24 PM
*To:* John Griffith
*Cc:* openstack@lists.launchpad.net
*Subject:* Re: [Openstack] Any block storage folks interested in getting
together?



Hello,



We are interested in participating. Looking forward to talk to all Nova
block storage developers.



--

Best regards,

Oleg

On Tue, Feb 14, 2012 at 2:31 AM, John Griffith john.griff...@solidfire.com
wrote:

Hi Bob,
Just pop into IRC: #openstack-meeting

John


On Mon, Feb 13, 2012 at 3:17 PM, Bob Van Zant b...@veznat.com wrote:
 I'm interested in joining in. I've never joined one of the calls before,
 where do I get more information on how to join?


 On Mon, Feb 13, 2012 at 12:06 PM, Diego Parrilla
 diego.parrilla.santama...@gmail.com wrote:

 Sounds great. We will try to join the meeting.

 Enviado desde mi iPad

 El 13/02/2012, a las 19:06, John Griffith john.griff...@solidfire.com
 escribió:

  There's been a lot of new work going on specific to Nova Volumes the
  past month or so.  I was thinking that it's been a long time since
  we've had a Nova-Volume team meeting and thought I'd see if there was
  any interest in trying to get together next week?  I'm open to
  suggestions regarding time slots but thought I'd propose our old slot,
  Thursday Feb 23, 18:00 - 19:00 UTC.
 
  Here's a proposed agenda:
 
 * Quick summary of new blueprints you have submitted and completed
  (or targeting for completion) in Essex
 * Any place folks might need some help with items they've targeted
  for Essex (see if we have any volunteers to help out if needed)
 * Any updates regarding BSaaS
 * Gauge interest in resurrecting a standing meeting, perhaps every 2
  weeks?
 
  If you have specific items that you'd be interested in
  sharing/discussing let me know.
 
  Thanks,
  John
 
  ___
  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

[Openstack] Multiple compute hosts with HA configuration - compute node doesn't bring ip from dnsmasq-dhcp

[Jayashree(Jay) Beltur]

Hello,
I have a two node cluster running on Ubuntu 11.04 (natty) with the Diablo 
release from ppa:openstack- release/ 2011.3
[2011.3 (2011.3-nova-milestone-tarball:tarmac-20110922115702-k9nkvxqzhj130av2)]

Controller node  runs nova-compute, nova-volume, nova-network, nova-api - 2 NICs
Compute node runs nova-compute, nova-network and nova_api - 2 NICs
 
I am using flatDHCPManager.

When I launch on instance on the compute node, the VM is getting ip from the 
company dhcp server. It is not getting IP from the dnsmasq-dhcp server.
Also, I do not see dnsmasq-dhcp up on the compute node.

In the console log, I see that 
 
Sending discover...
Sending select for 16.89.26.95...
Lease of 16.89.26.95 obtained, lease time 1296000
starting DHCP forEthernet interface eth0  [  OK  ]
cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id
wget: can't connect to remote host (169.254.169.254): No route to host
cloud-setup: failed 1/30: up 2.04. request failed
wget: can't connect to remote host (169.254.169.254): No route to host
cloud-setup: failed 2/30: up 6.05. request failed

How to bring up dnsmasq-dhcp on the compute node?
 
Any help is appreciated.
 
Thanks,
-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] Multiple compute hosts with HA configuration - compute node doesn't bring ip from dnsmasq-dhcp

[Dan Wendlandt]

Hi Jay,

If you are running nova-network in a mode that performs DHCP, you should be
sure that the network Nova is connecting VMs to does not have your
corporate DHCP server on it.  Having two conflicting DHCP servers on the
same network will give unpredictable results.  What may be happening is a
race between the two DHCP servers.

The second question is whether dnsmasq is actually running.  You didn't say
that you were using --multi_host=True, so by default the network may have
been assigned to either of the two network-nodes you created.  This would
mean that dnsmasq might be running on either of the two servers running
nova-network (either the controller server or compute server).  Can you
check if it is running on the other server?  If it is not running on
either, we'd probably have to see nova-network logs.   For more info on the
--multi_host flag, see:
http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html

Dan



On Tue, Feb 14, 2012 at 9:31 AM, Jayashree(Jay) Beltur
jaybel...@yahoo.comwrote:

   Hello,
 I have a two node cluster running on Ubuntu 11.04 (natty) with the Diablo
 release from ppa:openstack- release/ 2011.3
 [2011.3
 (2011.3-nova-milestone-tarball:tarmac-20110922115702-k9nkvxqzhj130av2)]

 Controller node  runs nova-compute, nova-volume, nova-network, nova-api -
 2 NICs
 Compute node runs nova-compute, nova-network and nova_api - 2 NICs

 I am using flatDHCPManager.

 When I launch on instance on the compute node, the VM is getting ip from
 the company dhcp server. It is not getting IP from the dnsmasq-dhcp server.
 Also, I do not see dnsmasq-dhcp up on the compute node.

 In the console log, I see that

 Sending discover...
 Sending select for 16.89.26.95...
 Lease of 16.89.26.95 obtained, lease time 1296000
 starting DHCP forEthernet interface eth0  [  OK  ]
 cloud-setup: checking
 http://169.254.169.254/2009-04-04/meta-data/instance-id
 wget: can't connect to remote host (169.254.169.254): No route to host
 cloud-setup: failed 1/30: up 2.04. request failed
 wget: can't connect to remote host (169.254.169.254): No route to host
 cloud-setup: failed 2/30: up 6.05. request failed
  How to bring up dnsmasq-dhcp on the compute node?

 Any help is appreciated.

 Thanks,
 -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




-- 
~~~
Dan Wendlandt
Nicira Networks: 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] Multiple compute hosts with HA configuration - compute node doesn't bring ip from dnsmasq-dhcp

[Jayashree(Jay) Beltur]

Thanks for the reply Dan!
Yes, I am running with the option --multi_host=T on both controller and compute 
nodes [I followed the same URL that you mentioned in your email]
Controller node is running dnsmasq-dhcp correctly (There are 2 instances of 
it). If the VM is launched on the controller, then, everything works fine. It 
gets  ip leased from dnsmasq-dhcp server. However, if the VM is launched on the 
compute node (that runs nova-network/nova-compute/nova-api), then, it is 
getting ip leased from the corporate dhcp server.
Thanks,
-Jay

From: Dan Wendlandt d...@nicira.com
To: Jayashree(Jay) Beltur jaybel...@yahoo.com 
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net 
Sent: Tuesday, February 14, 2012 9:55 AM
Subject: Re: [Openstack] Multiple compute hosts with HA configuration - compute 
node doesn't bring ip from dnsmasq-dhcp

Hi Jay, 

If you are running nova-network in a mode that performs DHCP, you should be 
sure that the network Nova is connecting VMs to does not have your corporate 
DHCP server on it.  Having two conflicting DHCP servers on the same network 
will give unpredictable results.  What may be happening is a race between the 
two DHCP servers.  

The second question is whether dnsmasq is actually running.  You didn't say 
that you were using --multi_host=True, so by default the network may have been 
assigned to either of the two network-nodes you created.  This would mean that 
dnsmasq might be running on either of the two servers running nova-network 
(either the controller server or compute server).  Can you check if it is 
running on the other server?  If it is not running on either, we'd probably 
have to see nova-network logs.   For more info on the --multi_host flag, 
see: http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html

Dan

On Tue, Feb 14, 2012 at 9:31 AM, Jayashree(Jay) Beltur jaybel...@yahoo.com 
wrote: 
Hello,
I have a two node cluster running on Ubuntu 11.04 (natty) with the Diablo 
release from ppa:openstack- release/ 2011.3
[2011.3 (2011.3-nova-milestone-tarball:tarmac-20110922115702-k9nkvxqzhj130av2)]

Controller node  runs nova-compute, nova-volume, nova-network, nova-api - 2 
NICs
Compute node runs nova-compute, nova-network and nova_api - 2 NICs
 
I am using flatDHCPManager.

When I launch on instance on the compute node, the VM is getting ip from the 
company dhcp server. It is not getting IP from the dnsmasq-dhcp server.
Also, I do not see dnsmasq-dhcp up on the compute node.

In the console log, I see that 
 
Sending discover...Sending select for 16.89.26.95...Lease of 16.89.26.95 
obtained, lease time 1296000starting DHCP forEthernet interface eth0  [  OK  
]cloud-setup: checking 
http://169.254.169.254/2009-04-04/meta-data/instance-idwget: can't connect to 
remote host (169.254.169.254): No route to hostcloud-setup: failed 1/30: up 
2.04. request failedwget: can't connect to remote host (169.254.169.254): No 
route to hostcloud-setup: failed 2/30: up 6.05. request failed
How to bring up dnsmasq-dhcp on the compute node?

Any help is appreciated.

Thanks,
-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

-- ~~~Dan Wendlandt  
Nicira Networks: 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

[Openstack] RHEL / CentOS - interfaces.template

[Leandro Reox]

Hi guys,

Anyone already implemented networking injection to RHEL systems acting as a
guest ? If no any plans to make it to Essex final ?

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

Re: [Openstack] RHEL / CentOS - interfaces.template

[Nathanael Burton]

The Fedora / EPEL packaging does this.

http://fedoraproject.org/wiki/OpenStack
http://koji.fedoraproject.org/koji/packageinfo?packageID=12510

Thanks,

Nate

On Tue, Feb 14, 2012 at 1:23 PM, Leandro Reox leandro.r...@gmail.com wrote:
 Hi guys,

 Anyone already implemented networking injection to RHEL systems acting as a
 guest ? If no any plans to make it to Essex final ?

 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


___
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] RHEL / CentOS - interfaces.template

[Joshua Harlow]

So is that in the openstack mainline or is that an add-on that fedora/RH/EPEL 
has done?

Something in the mainline would be great (then there would be one solution 
and not X+1 solutions to this).

I guess this goes beyond the networking injection and also applies to any other 
adjustments those packages have to do.

On 2/14/12 10:38 AM, Nathanael Burton nathanael.i.bur...@gmail.com wrote:

The Fedora / EPEL packaging does this.

http://fedoraproject.org/wiki/OpenStack
http://koji.fedoraproject.org/koji/packageinfo?packageID=12510

Thanks,

Nate

On Tue, Feb 14, 2012 at 1:23 PM, Leandro Reox leandro.r...@gmail.com wrote:
 Hi guys,

 Anyone already implemented networking injection to RHEL systems acting as a
 guest ? If no any plans to make it to Essex final ?

 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


___
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] RHEL / CentOS - interfaces.template

[Scott Moser]

On Tue, 14 Feb 2012, Leandro Reox wrote:

 Hi guys,

 Anyone already implemented networking injection to RHEL systems acting as a
 guest ? If no any plans to make it to Essex final ?


Before we go down the road of trying to write system network configuration
scripts for each potential guest OS, I'd suggest that its would be better
to either:
 a.) just accept that 'interfaces' is the openstack format and guests
 should need to read that.
 b.) create a OS agnostic interface configuration format.

While you may be looking at my email address and assuming that I think 'a'
is the right answer only to make it harder for anyone else.

However, the reason I dislike the current solution (or going down a path
of implementing population mechanisms for other operating systems) is
 1.) you cannot possibly support all possible operating systems
 2.) injecting files assumes host OS knowledge (or guestfs knowledge) of
 the guest filesystem
 3.) specific files indicates that the host can somehow determine which
 format the guest is expecting (or also unacceptable, only allowing
 this configuration for one OS per cloud).
 4.) injecting files via overwriting them is lossy and possibly
 destructive to a guest (imagine other vpn routes inserted there or
 something else more advanced).

I would *much* rather there be a openstack networking configuration file
format that was put into config_drive if dhcp was not sufficient.

Then, the guests are just made to read that information that is in a
standard, easily documetable format and respond accordingly.

___
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] RHEL / CentOS - interfaces.template

[Leandro Reox]

Nathan i forgot to mention that were actually running ubuntu as host, so we
were thinking about a way of inject ips on Red Hat as guest, but without
forcing any interfaces.template so Ubuntu guests can reside in the same
hosts too. Maybe if we can merge the aditions to the mainline package.

Thats a nice hack, and i agree that will be nice to get this pulled in. I
think that cutting up libvirt.connection.py its inevitable but its hard to
support many potential guest OS.  We really need to think in a more
unpersonalized way of storing this on Openstack.

If the guest os is part of the instance creation json, maybe we can
implement a way to read from a more simpler format of network configuration
template and based on this, use guestfs, qcow or whatever we need, of
course, if dhcp its not an option

Regards
Lean



On Tue, Feb 14, 2012 at 3:42 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:

  I know various companies/groups have hacked it in themselves.

 Guestfs just showed up in essex. But the networking part would seem
 equally important.

 Possible something like
 https://github.com/griddynamics/nova/blob/master/nova/virt/netcfg.py can
 get pulled in??

 My only concern though is that cutting up nova/virt/libvirt/connection.py
 might not go so easily (imho that needs to happen anyway, whenever a file
 approaches 2000+ lines, then something is up – ie time to refactor). But
 people will eventually have to put it in if it doesn’t hit essex since RHEL
 is used.


 On 2/14/12 10:23 AM, Leandro Reox leandro.r...@gmail.com wrote:

 Hi guys,

 Anyone already implemented networking injection to RHEL systems acting as
 a guest ? If no any plans to make it to Essex final ?

 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

Re: [Openstack] RHEL / CentOS - interfaces.template

[Russell Bryant]

On 02/14/2012 01:47 PM, Joshua Harlow wrote:
 So is that in the openstack “mainline” or is that an add-on that
 fedora/RH/EPEL has done?
 
 Something in the “mainline” would be great (then there would be one
 solution and not X+1 solutions to this).
 
 I guess this goes beyond the networking injection and also applies to
 any other “adjustments” those packages have to do.  

We don't have any changes in this area in the Fedora package that have
not been sent upstream.

-- 
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

Re: [Openstack] RHEL / CentOS - interfaces.template

[Joshua Harlow]

Ok, so that sounds nice and would be ideal.

But what is realistic?

Is there some kind of OS agonistic interface format that exists?

If there is that's great, lets us it! If there isn't what is plan B. Do we make 
one? Something like guestfs for networking would seem pretty nice :-P

On 2/14/12 10:48 AM, Scott Moser smo...@ubuntu.com wrote:

On Tue, 14 Feb 2012, Leandro Reox wrote:

 Hi guys,

 Anyone already implemented networking injection to RHEL systems acting as a
 guest ? If no any plans to make it to Essex final ?


Before we go down the road of trying to write system network configuration
scripts for each potential guest OS, I'd suggest that its would be better
to either:
 a.) just accept that 'interfaces' is the openstack format and guests
 should need to read that.
 b.) create a OS agnostic interface configuration format.

While you may be looking at my email address and assuming that I think 'a'
is the right answer only to make it harder for anyone else.

However, the reason I dislike the current solution (or going down a path
of implementing population mechanisms for other operating systems) is
 1.) you cannot possibly support all possible operating systems
 2.) injecting files assumes host OS knowledge (or guestfs knowledge) of
 the guest filesystem
 3.) specific files indicates that the host can somehow determine which
 format the guest is expecting (or also unacceptable, only allowing
 this configuration for one OS per cloud).
 4.) injecting files via overwriting them is lossy and possibly
 destructive to a guest (imagine other vpn routes inserted there or
 something else more advanced).

I would *much* rather there be a openstack networking configuration file
format that was put into config_drive if dhcp was not sufficient.

Then, the guests are just made to read that information that is in a
standard, easily documetable format and respond accordingly.

___
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] Remove Zones code - FFE

[Jay Pipes]

-1 on shard b/c of database terminology. -1 on cluster because of HPC 
and database terminology.


Zone was originally used because it is general -- referring to merely a 
collection of hosts or other zones and not having a geographic 
connotation like Region does.


Other possibilities:

* Container (not recommended, as it is overloaded with Solaris or Linux 
container virtualization)

* ServerGroup
* HostGroup
* Group
* Collection

If Zone isn't used, I suppose I would prefer ServerGroup

-jay

On 02/13/2012 08:45 PM, Yun Mao wrote:

agreed..

-1 on shard, +1 on cluster

Yun

On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com  wrote:

Please not 'shards'
Sharding as a concept is so intertwined with databases IMHO that it
will serve to confuse even more. Why not 'cluster'?

Martin

On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com  wrote:

Sorry, I'm late.  Really getting down to the wire here. :)

I've thrown up a version here: https://review.openstack.org/#change,4062

I've not functionally tested it yet, but there's really good test coverage for 
the zones service itself.   I also have added a test_compute_zones which tests 
that all of the compute tests pass while using the new ComputeZonesAPI class.

There's a couple bugs I note in the review and then I think I'm missing pushing 
some instance updates to the top in libvirt code.  And missing an update for 
instance deletes in the compute manager.  Going to hit those up today and 
finish this off.

One other comment:  It's been suggested we not call this stuff 'Zones' anymore. 
 It gets confused with availability zones and so forth.  Since this is really a 
way to shard nova, it has been suggested to call this 'Shards'. :)   Not sure I 
dig that name completely, although it makes sense.  Thoughts?

- Chris


On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote:


Awesome Chris !!!

Lean

On Thu, Feb 9, 2012 at 3:26 PM, Alejandro 
Comisarioalejandro.comisa...@mercadolibre.com  wrote:
Niceee !!

Alejandro.

On 02/09/2012 02:02 PM, Chris Behrens wrote:

I should be pushing something up by end of day...  Even if it's not granted an 
FFE, I'll have a need to keep my branch updated and working, so I should at 
least always have a branch pushed up to a github account somewhere until F1 
opens up.  So, I guess worst case... there'll be a branch somewhere for you to 
play with. :)

- Chris


On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote:



Just raising another deployment waiting on this new Zone implementation - we currently 
have 2000 cores sitting idle in another datacentre that we can use better if 
this is done.

How can we help? ;)

Regards,

Tom

On 02/08/2012 07:30 PM, Ziad Sawalha wrote:


We were working on providing the necessary functionality in Keystone but
stopped when we heard of the alternative solution. We could resume the
conversation about what is needed on the Keystone side and implement if
needed.

Z

From: Sandy Walsh
sandy.wa...@rackspace.com
mailto:sandy.wa...@rackspace.com



Date: Thu, 2 Feb 2012 01:49:58 +
To: Joshua McKenty
jos...@pistoncloud.com
mailto:jos...@pistoncloud.com

, Vishvananda Ishaya


vishvana...@gmail.commailto:vishvana...@gmail.com



Cc: 
openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.netopenstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net



Subject: Re: [Openstack] Remove Zones code - FFE

Understood, timing is everything. I'll let Chris talk about expected
timing for the replacement. From a deployers side, nothing would really
change, just some configuration options ... but a replacement should be
available.

I'm sure we could get it working pretty easily. The Keystone integration
was the biggest pita.

I can keep this branch fresh with trunk for when we're ready to pull the
trigger.

-S


*From:* Joshua McKenty [
jos...@pistoncloud.com
mailto:jos...@pistoncloud.com
]
*Sent:* Wednesday, February 01, 2012 4:45 PM
*To:* Vishvananda Ishaya
*Cc:* Sandy Walsh;
openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net

*Subject:* Re: [Openstack] Remove Zones code - FFE

+1 to Vish's points. I know there are some folks coming online in the
Folsom timeline that can help out with the new stuff, but this feels a
bit like going backwards.

--
Joshua McKenty, CEO
Piston Cloud Computing, Inc.
w: (650) 24-CLOUD
m: (650) 283-6846

http://www.pistoncloud.com


Oh, Westley, we'll never survive!
Nonsense. You're only saying that because no one ever has.

On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote:



I am all for pulling this out, but I'm a bit concerned with the fact
that we have nothing to replace it with. There are some groups still
trying to use it. MercadoLibre is trying to use it for example. I know
you guys are trying to replace this with something better, but it
would be nice not to break people for 7+ months


So I guess I have some questions:
1.a) is 

Re: [Openstack] RHEL / CentOS - interfaces.template

[Joshua Harlow]

Great. Thx!

On 2/14/12 11:00 AM, Russell Bryant rbry...@redhat.com wrote:

On 02/14/2012 01:47 PM, Joshua Harlow wrote:
 So is that in the openstack mainline or is that an add-on that
 fedora/RH/EPEL has done?

 Something in the mainline would be great (then there would be one
 solution and not X+1 solutions to this).

 I guess this goes beyond the networking injection and also applies to
 any other adjustments those packages have to do.

We don't have any changes in this area in the Fedora package that have
not been sent upstream.

--
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

Re: [Openstack] RHEL / CentOS - interfaces.template

[Joshua Harlow]

Does anyone have any experience with https://fedorahosted.org/netcf/ (RH??)

Just from a little search that project seems to be oriented to do this (os 
agonistic net cfg)

It just seems to be missing a python api (at the moment).

On 2/14/12 10:48 AM, Scott Moser smo...@ubuntu.com wrote:

On Tue, 14 Feb 2012, Leandro Reox wrote:

 Hi guys,

 Anyone already implemented networking injection to RHEL systems acting as a
 guest ? If no any plans to make it to Essex final ?


Before we go down the road of trying to write system network configuration
scripts for each potential guest OS, I'd suggest that its would be better
to either:
 a.) just accept that 'interfaces' is the openstack format and guests
 should need to read that.
 b.) create a OS agnostic interface configuration format.

While you may be looking at my email address and assuming that I think 'a'
is the right answer only to make it harder for anyone else.

However, the reason I dislike the current solution (or going down a path
of implementing population mechanisms for other operating systems) is
 1.) you cannot possibly support all possible operating systems
 2.) injecting files assumes host OS knowledge (or guestfs knowledge) of
 the guest filesystem
 3.) specific files indicates that the host can somehow determine which
 format the guest is expecting (or also unacceptable, only allowing
 this configuration for one OS per cloud).
 4.) injecting files via overwriting them is lossy and possibly
 destructive to a guest (imagine other vpn routes inserted there or
 something else more advanced).

I would *much* rather there be a openstack networking configuration file
format that was put into config_drive if dhcp was not sufficient.

Then, the guests are just made to read that information that is in a
standard, easily documetable format and respond accordingly.

___
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] RHEL / CentOS - interfaces.template

[Leandro Reox]

What about http://git.fedorahosted.org/git/?p=python-netcf.git

On Tue, Feb 14, 2012 at 5:20 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:

  Does anyone have any experience with https://fedorahosted.org/netcf/(RH??)

 Just from a little search that project seems to be oriented to do this (os
 agonistic net cfg)

 It just seems to be missing a python api (at the moment).


 On 2/14/12 10:48 AM, Scott Moser smo...@ubuntu.com wrote:

 On Tue, 14 Feb 2012, Leandro Reox wrote:

  Hi guys,
 
  Anyone already implemented networking injection to RHEL systems acting
 as a
  guest ? If no any plans to make it to Essex final ?


 Before we go down the road of trying to write system network configuration
 scripts for each potential guest OS, I'd suggest that its would be better
 to either:
  a.) just accept that 'interfaces' is the openstack format and guests
  should need to read that.
  b.) create a OS agnostic interface configuration format.

 While you may be looking at my email address and assuming that I think 'a'
 is the right answer only to make it harder for anyone else.

 However, the reason I dislike the current solution (or going down a path
 of implementing population mechanisms for other operating systems) is
  1.) you cannot possibly support all possible operating systems
  2.) injecting files assumes host OS knowledge (or guestfs knowledge) of
  the guest filesystem
  3.) specific files indicates that the host can somehow determine which
  format the guest is expecting (or also unacceptable, only allowing
  this configuration for one OS per cloud).
  4.) injecting files via overwriting them is lossy and possibly
  destructive to a guest (imagine other vpn routes inserted there or
  something else more advanced).

 I would *much* rather there be a openstack networking configuration file
 format that was put into config_drive if dhcp was not sufficient.

 Then, the guests are just made to read that information that is in a
 standard, easily documetable format and respond accordingly.

 ___
 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] RHEL / CentOS - interfaces.template

[Joshua Harlow]

Even better, guess I didn't see that :-P

On 2/14/12 12:25 PM, Leandro Reox leandro.r...@gmail.com wrote:

What about http://git.fedorahosted.org/git/?p=python-netcf.git

On Tue, Feb 14, 2012 at 5:20 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:
Does anyone have any experience with https://fedorahosted.org/netcf/ (RH??)

Just from a little search that project seems to be oriented to do this (os 
agonistic net cfg)

It just seems to be missing a python api (at the moment).


On 2/14/12 10:48 AM, Scott Moser smo...@ubuntu.com 
http://smo...@ubuntu.com  wrote:

On Tue, 14 Feb 2012, Leandro Reox wrote:

 Hi guys,

 Anyone already implemented networking injection to RHEL systems acting as a
 guest ? If no any plans to make it to Essex final ?


Before we go down the road of trying to write system network configuration
scripts for each potential guest OS, I'd suggest that its would be better
to either:
 a.) just accept that 'interfaces' is the openstack format and guests
 should need to read that.
 b.) create a OS agnostic interface configuration format.

While you may be looking at my email address and assuming that I think 'a'
is the right answer only to make it harder for anyone else.

However, the reason I dislike the current solution (or going down a path
of implementing population mechanisms for other operating systems) is
 1.) you cannot possibly support all possible operating systems
 2.) injecting files assumes host OS knowledge (or guestfs knowledge) of
 the guest filesystem
 3.) specific files indicates that the host can somehow determine which
 format the guest is expecting (or also unacceptable, only allowing
 this configuration for one OS per cloud).
 4.) injecting files via overwriting them is lossy and possibly
 destructive to a guest (imagine other vpn routes inserted there or
 something else more advanced).

I would *much* rather there be a openstack networking configuration file
format that was put into config_drive if dhcp was not sufficient.

Then, the guests are just made to read that information that is in a
standard, easily documetable format and respond accordingly.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net 
http://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] Bug launching instance in Essex packages on Precise - for nw, info in nw_info: too many values to unpack (network/manager.py)

[Kevin Jackson]

Dear cloud folk,
I raised https://bugs.launchpad.net/nova/+bug/928819 last week that's
not getting any love so was wondering if it was user error rather than
a bug (as its a show stopper for my setup that I previously didn't
have).

My setup is simple -
Fresh install of Precise A2
Installed OpenStack
nova.conf, etc all in the bug info

I go to launch an instance, and get the stack trace below

I've got --auto_assign_floating_ip flag in my confg and the above bug
triggers causing the following:

012-02-08 11:02:04,345 DEBUG nova.utils [-] Got semaphore get_dhcp
for method _get_dhcp_ip... from (pid=3270) inner
/usr/lib/python2.7/dist-packages/nova/utils.py:817
2012-02-08 11:02:04,436 DEBUG nova.network.manager [-] QUOTA: 1 from
(pid=3270) allocate_floating_ip
/usr/lib/python2.7/dist-packages/nova/network/manager.py:370
2012-02-08 11:02:04,521 ERROR nova.rpc [-] Exception during message handling
(nova.rpc): TRACE: Traceback (most recent call last):
(nova.rpc): TRACE: File
/usr/lib/python2.7/dist-packages/nova/rpc/amqp.py, line 249, in
_process_data
(nova.rpc): TRACE: rval = node_func(context=ctxt, **node_args)
(nova.rpc): TRACE: File
/usr/lib/python2.7/dist-packages/nova/network/manager.py, line 240,
in wrapped
(nova.rpc): TRACE: return func(self, context, *args, **kwargs)
(nova.rpc): TRACE: File
/usr/lib/python2.7/dist-packages/nova/network/manager.py, line 303,
in allocate_for_instance
(nova.rpc): TRACE: for nw, info in nw_info:
(nova.rpc): TRACE: ValueError: too many values to unpack
(nova.rpc): TRACE:
2012-02-08 11:02:04,522 ERROR nova.rpc [-] Returning exception too
many values to unpack to caller
2012-02-08 11:02:04,522 ERROR nova.rpc [-] ['Traceback (most recent
call last):\n', ' File
/usr/lib/python2.7/dist-packages/nova/rpc/amqp.py, line 249, in
_process_data\n rval = node_func(context=ctxt, **node_args)\n', ' File
/usr/lib/python2.7/dist-packages/nova/network/manager.py, line 240,
in wrapped\n return func(self, context, *args, **kwargs)\n', ' File
/usr/lib/python2.7/dist-packages/nova/network/manager.py, line 303,
in allocate_for_instance\n for nw, info in nw_info:\n', 'ValueError:
too many values to unpack\n']

I know very little of Python but adding in a debug message to log the
value of nw_info showed the following

[VIF({'network': Network({'bridge': 'br4025', 'subnets':
[Subnet({'ips': [FixedIP({'meta': {}, 'version': 4, 'type': 'fixed',
'floating_ips': [], 'address': '10.0.0.12'})], 'version': 4, 'meta':
{'dhcp_server': '10.0.0.4'}, 'dns': [], 'routes': [], 'cidr':
'10.0.0.0/26', 'gateway': IP({'meta': {}, 'version': 4, 'type':
'gateway', 'address': '10.0.0.1'})}), Subnet({'ips': [], 'version':
None, 'meta': {'dhcp_server': '10.0.0.4'}, 'dns': [], 'routes': [],
'cidr': None, 'gateway': IP({'meta': {}, 'version': None, 'type':
'gateway', 'address': None})})], 'meta': {'multi_host': True,
'should_create_bridge': True, 'should_create_vlan': True,
'bridge_interface': 'eth0', 'tenant_id':
'15a82b3d665d4fd7883ad0d142c8603c', 'vlan': 4025L}, 'id':
'76828f39-8bef-4d80-8c68-f3b8b601580a', 'label': 'vmnet'}), 'meta':
{}, 'id': '2b55771b-e488-4b19-8f5a-255bf67d72f0', 'address':
'02:16:3e:18:fb:15'})]

Any assistance appreciated so I can test Essex on Precise.

Cheers,

Kev
-- 
Kevin Jackson
@itarchitectkev

___
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] Remove Zones code - FFE

[Gabe Westmaas]

This really is more of about sharding than grouping though.  The specific
goal of this implementation is to shard your nova database (on a capacity
basis, not on a special key) and allow you to split (or shard :)
connections to your rabbit server. This implementation should be used for
performance reasons and no other.

Its not really a way to organize your servers into different groups, or
clusters or anything else, but to split lots and lots of hosts up.

I'm not completely in love with shards either, but I do hope the name
makes it clear the exact goal of this code, so that we don't attribute too
much meaning to it.

Gabe



On 2/14/12 2:25 PM, Jay Pipes jaypi...@gmail.com wrote:

-1 on shard b/c of database terminology. -1 on cluster because of HPC
and database terminology.

Zone was originally used because it is general -- referring to merely a
collection of hosts or other zones and not having a geographic
connotation like Region does.

Other possibilities:

* Container (not recommended, as it is overloaded with Solaris or Linux
container virtualization)
* ServerGroup
* HostGroup
* Group
* Collection

If Zone isn't used, I suppose I would prefer ServerGroup

-jay

On 02/13/2012 08:45 PM, Yun Mao wrote:
 agreed..

 -1 on shard, +1 on cluster

 Yun

 On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com
wrote:
 Please not 'shards'
 Sharding as a concept is so intertwined with databases IMHO that it
 will serve to confuse even more. Why not 'cluster'?

 Martin

 On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com  wrote:
 Sorry, I'm late.  Really getting down to the wire here. :)

 I've thrown up a version here:
https://review.openstack.org/#change,4062

 I've not functionally tested it yet, but there's really good test
coverage for the zones service itself.   I also have added a
test_compute_zones which tests that all of the compute tests pass
while using the new ComputeZonesAPI class.

 There's a couple bugs I note in the review and then I think I'm
missing pushing some instance updates to the top in libvirt code.  And
missing an update for instance deletes in the compute manager.  Going
to hit those up today and finish this off.

 One other comment:  It's been suggested we not call this stuff
'Zones' anymore.  It gets confused with availability zones and so
forth.  Since this is really a way to shard nova, it has been
suggested to call this 'Shards'. :)   Not sure I dig that name
completely, although it makes sense.  Thoughts?

 - Chris


 On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote:

 Awesome Chris !!!

 Lean

 On Thu, Feb 9, 2012 at 3:26 PM, Alejandro
Comisarioalejandro.comisa...@mercadolibre.com  wrote:
 Niceee !!

 Alejandro.

 On 02/09/2012 02:02 PM, Chris Behrens wrote:
 I should be pushing something up by end of day...  Even if it's not
granted an FFE, I'll have a need to keep my branch updated and
working, so I should at least always have a branch pushed up to a
github account somewhere until F1 opens up.  So, I guess worst
case... there'll be a branch somewhere for you to play with. :)

 - Chris


 On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote:


 Just raising another deployment waiting on this new Zone
implementation - we currently have 2000 cores sitting idle in
another datacentre that we can use better if this is done.

 How can we help? ;)

 Regards,

 Tom

 On 02/08/2012 07:30 PM, Ziad Sawalha wrote:

 We were working on providing the necessary functionality in
Keystone but
 stopped when we heard of the alternative solution. We could
resume the
 conversation about what is needed on the Keystone side and
implement if
 needed.

 Z

 From: Sandy Walsh
 sandy.wa...@rackspace.com
 mailto:sandy.wa...@rackspace.com

 Date: Thu, 2 Feb 2012 01:49:58 +
 To: Joshua McKenty
 jos...@pistoncloud.com
 mailto:jos...@pistoncloud.com
 , Vishvananda Ishaya
 
 vishvana...@gmail.commailto:vishvana...@gmail.com

 Cc: 
 openstack@lists.launchpad.net
 
mailto:openstack@lists.launchpad.netopenstack@lists.launchpad.n
et
 mailto:openstack@lists.launchpad.net

 Subject: Re: [Openstack] Remove Zones code - FFE

 Understood, timing is everything. I'll let Chris talk about
expected
 timing for the replacement. From a deployers side, nothing would
really
 change, just some configuration options ... but a replacement
should be
 available.

 I'm sure we could get it working pretty easily. The Keystone
integration
 was the biggest pita.

 I can keep this branch fresh with trunk for when we're ready to
pull the
 trigger.

 -S

 
---
-
 *From:* Joshua McKenty [
 jos...@pistoncloud.com
 mailto:jos...@pistoncloud.com
 ]
 *Sent:* Wednesday, February 01, 2012 4:45 PM
 *To:* Vishvananda Ishaya
 *Cc:* Sandy Walsh;
 openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net

 *Subject:* Re: [Openstack] Remove Zones code - FFE

 +1 to Vish's points. I know there are some folks coming online in
the
 Folsom timeline that 

Re: [Openstack] Remove Zones code - FFE

[Gabe Westmaas]

Partitions maybe?

On 2/14/12 4:01 PM, Gabe Westmaas gabe.westm...@rackspace.com wrote:

This really is more of about sharding than grouping though.  The specific
goal of this implementation is to shard your nova database (on a capacity
basis, not on a special key) and allow you to split (or shard :)
connections to your rabbit server. This implementation should be used for
performance reasons and no other.

Its not really a way to organize your servers into different groups, or
clusters or anything else, but to split lots and lots of hosts up.

I'm not completely in love with shards either, but I do hope the name
makes it clear the exact goal of this code, so that we don't attribute too
much meaning to it.

Gabe



On 2/14/12 2:25 PM, Jay Pipes jaypi...@gmail.com wrote:

-1 on shard b/c of database terminology. -1 on cluster because of HPC
and database terminology.

Zone was originally used because it is general -- referring to merely a
collection of hosts or other zones and not having a geographic
connotation like Region does.

Other possibilities:

* Container (not recommended, as it is overloaded with Solaris or Linux
container virtualization)
* ServerGroup
* HostGroup
* Group
* Collection

If Zone isn't used, I suppose I would prefer ServerGroup

-jay

On 02/13/2012 08:45 PM, Yun Mao wrote:
 agreed..

 -1 on shard, +1 on cluster

 Yun

 On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com
wrote:
 Please not 'shards'
 Sharding as a concept is so intertwined with databases IMHO that it
 will serve to confuse even more. Why not 'cluster'?

 Martin

 On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com
wrote:
 Sorry, I'm late.  Really getting down to the wire here. :)

 I've thrown up a version here:
https://review.openstack.org/#change,4062

 I've not functionally tested it yet, but there's really good test
coverage for the zones service itself.   I also have added a
test_compute_zones which tests that all of the compute tests pass
while using the new ComputeZonesAPI class.

 There's a couple bugs I note in the review and then I think I'm
missing pushing some instance updates to the top in libvirt code.  And
missing an update for instance deletes in the compute manager.  Going
to hit those up today and finish this off.

 One other comment:  It's been suggested we not call this stuff
'Zones' anymore.  It gets confused with availability zones and so
forth.  Since this is really a way to shard nova, it has been
suggested to call this 'Shards'. :)   Not sure I dig that name
completely, although it makes sense.  Thoughts?

 - Chris


 On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote:

 Awesome Chris !!!

 Lean

 On Thu, Feb 9, 2012 at 3:26 PM, Alejandro
Comisarioalejandro.comisa...@mercadolibre.com  wrote:
 Niceee !!

 Alejandro.

 On 02/09/2012 02:02 PM, Chris Behrens wrote:
 I should be pushing something up by end of day...  Even if it's not
granted an FFE, I'll have a need to keep my branch updated and
working, so I should at least always have a branch pushed up to a
github account somewhere until F1 opens up.  So, I guess worst
case... there'll be a branch somewhere for you to play with. :)

 - Chris


 On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote:


 Just raising another deployment waiting on this new Zone
implementation - we currently have 2000 cores sitting idle in
another datacentre that we can use better if this is done.

 How can we help? ;)

 Regards,

 Tom

 On 02/08/2012 07:30 PM, Ziad Sawalha wrote:

 We were working on providing the necessary functionality in
Keystone but
 stopped when we heard of the alternative solution. We could
resume the
 conversation about what is needed on the Keystone side and
implement if
 needed.

 Z

 From: Sandy Walsh
 sandy.wa...@rackspace.com
 mailto:sandy.wa...@rackspace.com

 Date: Thu, 2 Feb 2012 01:49:58 +
 To: Joshua McKenty
 jos...@pistoncloud.com
 mailto:jos...@pistoncloud.com
 , Vishvananda Ishaya
 
 vishvana...@gmail.commailto:vishvana...@gmail.com

 Cc: 
 openstack@lists.launchpad.net
 
mailto:openstack@lists.launchpad.netopenstack@lists.launchpad.
n
et
 mailto:openstack@lists.launchpad.net

 Subject: Re: [Openstack] Remove Zones code - FFE

 Understood, timing is everything. I'll let Chris talk about
expected
 timing for the replacement. From a deployers side, nothing would
really
 change, just some configuration options ... but a replacement
should be
 available.

 I'm sure we could get it working pretty easily. The Keystone
integration
 was the biggest pita.

 I can keep this branch fresh with trunk for when we're ready to
pull the
 trigger.

 -S

 
--
-
-
 *From:* Joshua McKenty [
 jos...@pistoncloud.com
 mailto:jos...@pistoncloud.com
 ]
 *Sent:* Wednesday, February 01, 2012 4:45 PM
 *To:* Vishvananda Ishaya
 *Cc:* Sandy Walsh;
 openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net

 *Subject:* Re: [Openstack] Remove Zones code - FFE

 +1 

Re: [Openstack] Bug launching instance in Essex packages on Precise - for nw, info in nw_info: too many values to unpack (network/manager.py)

[Jason Kölker]

On Tue, 2012-02-14 at 20:43 +, Kevin Jackson wrote:
 Dear cloud folk,
 I raised https://bugs.launchpad.net/nova/+bug/928819 last week that's
 not getting any love so was wondering if it was user error rather than
 a bug (as its a show stopper for my setup that I previously didn't
 have).

I think this diff might fix it:

diff --git a/nova/network/manager.py b/nova/network/manager.py
index e42e066..502baba 100644
--- a/nova/network/manager.py
+++ b/nova/network/manager.py
@@ -299,10 +299,8 @@ class FloatingIP(object):
 self.db.floating_ip_set_auto_assigned(context,
floating_address)
 
 # get the first fixed address belonging to the instance
-for nw, info in nw_info:
-if info.get('ips'):
-fixed_address = info['ips'][0]['ip']
-break
+fixed_ips = nw_info.fixed_ips()
+fixed_address = fixed_ips[0]['address']
 
 # associate the floating ip to fixed_ip
 self.associate_floating_ip(context,

I unfortunately do not have the setup to test it. If it works for you
let me know, and I'll merge prop it to trunk.

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

[Openstack] FFE request - glance image upload copied from external store

[Eoghan Glynn]

Folks,

I like to request an Essex feature freeze exception for this blueprint:

  https://blueprints.launchpad.net/glance/+spec/retrieve-image-from

as implemented by the following patch:

  https://review.openstack.org/#change,4096

The blueprint was raised in response to a late-breaking feature request
from the Horizon team, as discussed on the mailing list:

  https://lists.launchpad.net/openstack/msg07417.html

Cheers,
Eoghan

___
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] Flavor change in Essex?

[David Kranz]

In tracking down a problem with the tempest flavors test I noticed that 
'nova flavor-list' returns this in Essex:


++---+---+--+--+---+-+
| ID |Name   | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Factor |
++---+---+--+--+---+-+
| 1  | m1.tiny   | 512   |  | 0| 1 | 1.0 |
| 2  | m1.small  | 2048  |  | 10   | 1 | 1.0 |
| 3  | m1.medium | 4096  |  | 10   | 2 | 1.0 |
| 4  | m1.large  | 8192  |  | 10   | 4 | 1.0 |
| 5  | m1.xlarge | 16384 |  | 10   | 8 | 1.0 |
++---+---+--+--+---+-+

and this in Diablo:

++---+---+--+--+---+-+
| ID |Name   | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Factor |
++---+---+--+--+---+-+
| 1  | m1.tiny   | 512   | 0| 0| 1 | |
| 2  | m1.small  | 2048  | 0| 20   | 1 | |
| 3  | m1.medium | 4096  | 0| 40   | 2 | |
| 4  | m1.large  | 8192  | 0| 80   | 4 | |
| 5  | m1.xlarge | 16384 | 0| 160  | 8 | |
++---+---+--+--+---+-+

Note that Local_GB changed from 0,20,40,80,160 to 0,10,10,10,10. These 
values are coming straight from the API call.

Is this a bug or a deliberate change?

 -David

___
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] Flavor change in Essex?

[Jesse Andrews]

Deliberate change.

It used to be that KVM and XS did different things as far as disk partitioning.

https://blueprints.launchpad.net/nova/+spec/disk-configuration-parity

Now a flavor can specify the root vs ephemeral partition size
independently instead of being decided by choice of hypervisor.

Jesse

On Tue, Feb 14, 2012 at 1:47 PM, David Kranz david.kr...@qrclab.com wrote:
 In tracking down a problem with the tempest flavors test I noticed that
 'nova flavor-list' returns this in Essex:

 ++---+---+--+--+---+-+
 | ID |    Name   | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Factor |
 ++---+---+--+--+---+-+
 | 1  | m1.tiny   | 512       |      | 0        | 1     | 1.0         |
 | 2  | m1.small  | 2048      |      | 10       | 1     | 1.0         |
 | 3  | m1.medium | 4096      |      | 10       | 2     | 1.0         |
 | 4  | m1.large  | 8192      |      | 10       | 4     | 1.0         |
 | 5  | m1.xlarge | 16384     |      | 10       | 8     | 1.0         |
 ++---+---+--+--+---+-+

 and this in Diablo:

 ++---+---+--+--+---+-+
 | ID |    Name   | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Factor |
 ++---+---+--+--+---+-+
 | 1  | m1.tiny   | 512       | 0    | 0        | 1     |             |
 | 2  | m1.small  | 2048      | 0    | 20       | 1     |             |
 | 3  | m1.medium | 4096      | 0    | 40       | 2     |             |
 | 4  | m1.large  | 8192      | 0    | 80       | 4     |             |
 | 5  | m1.xlarge | 16384     | 0    | 160      | 8     |             |
 ++---+---+--+--+---+-+

 Note that Local_GB changed from 0,20,40,80,160 to 0,10,10,10,10. These
 values are coming straight from the API call.
 Is this a bug or a deliberate change?

  -David

 ___
 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] RHEL / CentOS - interfaces.template

[Pádraig Brady]

On 02/14/2012 06:48 PM, Scott Moser wrote:
 On Tue, 14 Feb 2012, Leandro Reox wrote:
 
 Hi guys,

 Anyone already implemented networking injection to RHEL systems acting as a
 guest ? If no any plans to make it to Essex final ?
 
 
 Before we go down the road of trying to write system network configuration
 scripts for each potential guest OS, I'd suggest that its would be better
 to either:
  a.) just accept that 'interfaces' is the openstack format and guests
  should need to read that.
  b.) create a OS agnostic interface configuration format.
 
 While you may be looking at my email address and assuming that I think 'a'
 is the right answer only to make it harder for anyone else.
 
 However, the reason I dislike the current solution (or going down a path
 of implementing population mechanisms for other operating systems) is
  1.) you cannot possibly support all possible operating systems
  2.) injecting files assumes host OS knowledge (or guestfs knowledge) of
  the guest filesystem
  3.) specific files indicates that the host can somehow determine which
  format the guest is expecting (or also unacceptable, only allowing
  this configuration for one OS per cloud).
  4.) injecting files via overwriting them is lossy and possibly
  destructive to a guest (imagine other vpn routes inserted there or
  something else more advanced).
 
 I would *much* rather there be a openstack networking configuration file
 format that was put into config_drive if dhcp was not sufficient.
 
 Then, the guests are just made to read that information that is in a
 standard, easily documetable format and respond accordingly.

I have to agree with this.

Ideally openstack would not be polluted with all the
vagaries of guest network configuration.
Though if --flat_injected is a required and common case,
then perhaps in the short term it would be worth adding something
like the griddynamics patch to support the two most common linux formats?
Until now, we've not considered this a priority.

Notes:

This issue is already tracked at:
https://bugs.launchpad.net/nova/+bug/678395

The Red Hat openstack packages do not have any extra support in this regard
(especially since this is a guest issue). All file injection patches supporting
Red Hat (derived) _hosts_, including libguestfs support, are upstream in Essex.

The netcf lib looks interesting. Perhaps it could leverage libguestfs
(already integrated) to maximise the types and configurations of guests it 
could target?

Points 1  2 above are more general and apply to ssh key injection also I think.
libguestfs helps a lot to abstract those guest specific issues away.

cheers,
Pádraig.

___
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] Flavor change in Essex?

[Anthony Young]

It sounds like we need to update the cli to reflect this
disk-configuration-parity change.  It is also likely that some nova-api
work will need to be done to get this humming.
https://bugs.launchpad.net/nova/+bug/932423

On Tue, Feb 14, 2012 at 1:57 PM, Jesse Andrews anotherje...@gmail.comwrote:

 Deliberate change.

 It used to be that KVM and XS did different things as far as disk
 partitioning.

 https://blueprints.launchpad.net/nova/+spec/disk-configuration-parity

 Now a flavor can specify the root vs ephemeral partition size
 independently instead of being decided by choice of hypervisor.

 Jesse

 On Tue, Feb 14, 2012 at 1:47 PM, David Kranz david.kr...@qrclab.com
 wrote:
  In tracking down a problem with the tempest flavors test I noticed that
  'nova flavor-list' returns this in Essex:
 
  ++---+---+--+--+---+-+
  | ID |Name   | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Factor |
  ++---+---+--+--+---+-+
  | 1  | m1.tiny   | 512   |  | 0| 1 | 1.0 |
  | 2  | m1.small  | 2048  |  | 10   | 1 | 1.0 |
  | 3  | m1.medium | 4096  |  | 10   | 2 | 1.0 |
  | 4  | m1.large  | 8192  |  | 10   | 4 | 1.0 |
  | 5  | m1.xlarge | 16384 |  | 10   | 8 | 1.0 |
  ++---+---+--+--+---+-+
 
  and this in Diablo:
 
  ++---+---+--+--+---+-+
  | ID |Name   | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Factor |
  ++---+---+--+--+---+-+
  | 1  | m1.tiny   | 512   | 0| 0| 1 | |
  | 2  | m1.small  | 2048  | 0| 20   | 1 | |
  | 3  | m1.medium | 4096  | 0| 40   | 2 | |
  | 4  | m1.large  | 8192  | 0| 80   | 4 | |
  | 5  | m1.xlarge | 16384 | 0| 160  | 8 | |
  ++---+---+--+--+---+-+
 
  Note that Local_GB changed from 0,20,40,80,160 to 0,10,10,10,10. These
  values are coming straight from the API call.
  Is this a bug or a deliberate change?
 
   -David
 
  ___
  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] Remove Zones code - FFE

[Martin Paulo]

ServerGroup gets my vote at the moment: it's a term that has an
overloaded meaning (as far as I know)

Martin

On 15 February 2012 06:25, Jay Pipes jaypi...@gmail.com wrote:
 -1 on shard b/c of database terminology. -1 on cluster because of HPC and
 database terminology.

 Zone was originally used because it is general -- referring to merely a
 collection of hosts or other zones and not having a geographic connotation
 like Region does.

 Other possibilities:

 * Container (not recommended, as it is overloaded with Solaris or Linux
 container virtualization)
 * ServerGroup
 * HostGroup
 * Group
 * Collection

 If Zone isn't used, I suppose I would prefer ServerGroup

 -jay


 On 02/13/2012 08:45 PM, Yun Mao wrote:

 agreed..

 -1 on shard, +1 on cluster

 Yun

 On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com
  wrote:

 Please not 'shards'
 Sharding as a concept is so intertwined with databases IMHO that it
 will serve to confuse even more. Why not 'cluster'?

 Martin

 On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com  wrote:

 Sorry, I'm late.  Really getting down to the wire here. :)

 I've thrown up a version here: https://review.openstack.org/#change,4062

 I've not functionally tested it yet, but there's really good test
 coverage for the zones service itself.   I also have added a
 test_compute_zones which tests that all of the compute tests pass while
 using the new ComputeZonesAPI class.

 There's a couple bugs I note in the review and then I think I'm missing
 pushing some instance updates to the top in libvirt code.  And missing an
 update for instance deletes in the compute manager.  Going to hit those up
 today and finish this off.

 One other comment:  It's been suggested we not call this stuff 'Zones'
 anymore.  It gets confused with availability zones and so forth.  Since 
 this
 is really a way to shard nova, it has been suggested to call this 'Shards'.
 :)   Not sure I dig that name completely, although it makes sense.
  Thoughts?

 - Chris


 On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote:

 Awesome Chris !!!

 Lean

 On Thu, Feb 9, 2012 at 3:26 PM, Alejandro
 Comisarioalejandro.comisa...@mercadolibre.com  wrote:
 Niceee !!

 Alejandro.

 On 02/09/2012 02:02 PM, Chris Behrens wrote:

 I should be pushing something up by end of day...  Even if it's not
 granted an FFE, I'll have a need to keep my branch updated and working, 
 so I
 should at least always have a branch pushed up to a github account 
 somewhere
 until F1 opens up.  So, I guess worst case... there'll be a branch 
 somewhere
 for you to play with. :)

 - Chris


 On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote:


 Just raising another deployment waiting on this new Zone
 implementation - we currently have 2000 cores sitting idle in another
 datacentre that we can use better if this is done.

 How can we help? ;)

 Regards,

 Tom

 On 02/08/2012 07:30 PM, Ziad Sawalha wrote:

 We were working on providing the necessary functionality in Keystone
 but
 stopped when we heard of the alternative solution. We could resume
 the
 conversation about what is needed on the Keystone side and implement
 if
 needed.

 Z

 From: Sandy Walsh
 sandy.wa...@rackspace.com
 mailto:sandy.wa...@rackspace.com


 Date: Thu, 2 Feb 2012 01:49:58 +
 To: Joshua McKenty
 jos...@pistoncloud.com
 mailto:jos...@pistoncloud.com

 , Vishvananda Ishaya

 
 vishvana...@gmail.commailto:vishvana...@gmail.com


 Cc: 
 openstack@lists.launchpad.net

 mailto:openstack@lists.launchpad.netopenstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net


 Subject: Re: [Openstack] Remove Zones code - FFE

 Understood, timing is everything. I'll let Chris talk about expected
 timing for the replacement. From a deployers side, nothing would
 really
 change, just some configuration options ... but a replacement should
 be
 available.

 I'm sure we could get it working pretty easily. The Keystone
 integration
 was the biggest pita.

 I can keep this branch fresh with trunk for when we're ready to pull
 the
 trigger.

 -S


 
 *From:* Joshua McKenty [
 jos...@pistoncloud.com
 mailto:jos...@pistoncloud.com
 ]
 *Sent:* Wednesday, February 01, 2012 4:45 PM
 *To:* Vishvananda Ishaya
 *Cc:* Sandy Walsh;
 openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net

 *Subject:* Re: [Openstack] Remove Zones code - FFE

 +1 to Vish's points. I know there are some folks coming online in
 the
 Folsom timeline that can help out with the new stuff, but this feels
 a
 bit like going backwards.

 --
 Joshua McKenty, CEO
 Piston Cloud Computing, Inc.
 w: (650) 24-CLOUD
 m: (650) 283-6846

 http://www.pistoncloud.com


 Oh, Westley, we'll never survive!
 Nonsense. You're only saying that because no one ever has.

 On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya
 wrote:


 I am all for pulling this out, but I'm a bit concerned with the
 fact
 that we have 

[Openstack] Feature Freeze Update

[Vishvananda Ishaya]

Hello Everyone,

We had excellent discussion about the outstanding Feature Freeze Exceptions. 
Overall e-4 is going very well. We have had tons of fixes and updates and 
almost all of the FFes are in. Here is an update about all of the outstanding 
items.  All of these patches need to be merged by the release meeting next week 
or they will miss essex:

https://blueprints.launchpad.net/nova/+spec/keystone-export-rewrite
https://blueprints.launchpad.net/nova/+spec/remove-deprecated-auth

These two have been waiting on the keystone redux branch to land.  It looks 
like the branch will land today, so we should have something up for review very 
soon


https://blueprints.launchpad.net/nova/+spec/scaling-zones

We had a long discussion about this one.  We decided on the following steps:

1) remove old zones code (approve sandy's branch)
2) comstud splits core changes out of his patch and proposes
3) FFe for comstud's branch
4) added zones code goes into a separate branch
5) critical bug update python-novaclient to remove zone stuff

The core changes will include some minor additions to rpc api and network api, 
a simple modification to compute api, and a couple of small database migrations.

https://blueprints.launchpad.net/nova/+spec/libvirt-resize

This one is very close.  Lots of reviews.  I expect it to land by tomorrow


https://blueprints.launchpad.net/nova/+spec/optional-host-and-admin-information

Small api extension, but code has not been proposed yet.  This one needs code 
ASAP


https://blueprints.launchpad.net/nova/+spec/nexenta-volume-driver

No code available yet.  I spoke with the author today, and code should be up 
for review by tomorrow


https://blueprints.launchpad.net/nova/+spec/zeromq-rpc-driver

Code has had some initial reviews already, waiting on updates from the author


https://blueprints.launchpad.net/nova/+spec/netapp-volume-driver

Waiting on updates and tests from the author


I really appreciate all of the effort going into bug discovery and fixing as 
well.

Vish
___
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] Remove Zones code - FFE

[Monsyne Dragon]

On Feb 14, 2012, at 1:25 PM, Jay Pipes wrote:

 -1 on shard b/c of database terminology. -1 on cluster because of HPC and 
 database terminology.
 
 Zone was originally used because it is general -- referring to merely a 
 collection of hosts or other zones and not having a geographic connotation 
 like Region does.
 
 Other possibilities:
 
 * Container (not recommended, as it is overloaded with Solaris or Linux 
 container virtualization)
 * ServerGroup
 * HostGroup
 * Group
 * Collection

- Set
- Cell
- Huddle
- Constellation
- Herd/Flock//Pod/Animal metaphor of choice.
- System


 If Zone isn't used, I suppose I would prefer ServerGroup
 
 -jay
 
 On 02/13/2012 08:45 PM, Yun Mao wrote:
 agreed..
 
 -1 on shard, +1 on cluster
 
 Yun
 
 On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com  wrote:
 Please not 'shards'
 Sharding as a concept is so intertwined with databases IMHO that it
 will serve to confuse even more. Why not 'cluster'?
 
 Martin
 
 On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com  wrote:
 Sorry, I'm late.  Really getting down to the wire here. :)
 
 I've thrown up a version here: https://review.openstack.org/#change,4062
 
 I've not functionally tested it yet, but there's really good test coverage 
 for the zones service itself.   I also have added a test_compute_zones 
 which tests that all of the compute tests pass while using the new 
 ComputeZonesAPI class.
 
 There's a couple bugs I note in the review and then I think I'm missing 
 pushing some instance updates to the top in libvirt code.  And missing an 
 update for instance deletes in the compute manager.  Going to hit those up 
 today and finish this off.
 
 One other comment:  It's been suggested we not call this stuff 'Zones' 
 anymore.  It gets confused with availability zones and so forth.  Since 
 this is really a way to shard nova, it has been suggested to call this 
 'Shards'. :)   Not sure I dig that name completely, although it makes 
 sense.  Thoughts?
 
 - Chris
 
 
 On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote:
 
 Awesome Chris !!!
 
 Lean
 
 On Thu, Feb 9, 2012 at 3:26 PM, Alejandro 
 Comisarioalejandro.comisa...@mercadolibre.com  wrote:
 Niceee !!
 
 Alejandro.
 
 On 02/09/2012 02:02 PM, Chris Behrens wrote:
 I should be pushing something up by end of day...  Even if it's not 
 granted an FFE, I'll have a need to keep my branch updated and working, 
 so I should at least always have a branch pushed up to a github account 
 somewhere until F1 opens up.  So, I guess worst case... there'll be a 
 branch somewhere for you to play with. :)
 
 - Chris
 
 
 On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote:
 
 
 Just raising another deployment waiting on this new Zone implementation 
 - we currently have 2000 cores sitting idle in another datacentre that 
 we can use better if this is done.
 
 How can we help? ;)
 
 Regards,
 
 Tom
 
 On 02/08/2012 07:30 PM, Ziad Sawalha wrote:
 
 We were working on providing the necessary functionality in Keystone 
 but
 stopped when we heard of the alternative solution. We could resume the
 conversation about what is needed on the Keystone side and implement if
 needed.
 
 Z
 
 From: Sandy Walsh
 sandy.wa...@rackspace.com
 mailto:sandy.wa...@rackspace.com
 
 Date: Thu, 2 Feb 2012 01:49:58 +
 To: Joshua McKenty
 jos...@pistoncloud.com
 mailto:jos...@pistoncloud.com
 , Vishvananda Ishaya
 
 vishvana...@gmail.commailto:vishvana...@gmail.com
 
 Cc: 
 openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.netopenstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net
 
 Subject: Re: [Openstack] Remove Zones code - FFE
 
 Understood, timing is everything. I'll let Chris talk about expected
 timing for the replacement. From a deployers side, nothing would really
 change, just some configuration options ... but a replacement should be
 available.
 
 I'm sure we could get it working pretty easily. The Keystone 
 integration
 was the biggest pita.
 
 I can keep this branch fresh with trunk for when we're ready to pull 
 the
 trigger.
 
 -S
 
 
 *From:* Joshua McKenty [
 jos...@pistoncloud.com
 mailto:jos...@pistoncloud.com
 ]
 *Sent:* Wednesday, February 01, 2012 4:45 PM
 *To:* Vishvananda Ishaya
 *Cc:* Sandy Walsh;
 openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net
 
 *Subject:* Re: [Openstack] Remove Zones code - FFE
 
 +1 to Vish's points. I know there are some folks coming online in the
 Folsom timeline that can help out with the new stuff, but this feels a
 bit like going backwards.
 
 --
 Joshua McKenty, CEO
 Piston Cloud Computing, Inc.
 w: (650) 24-CLOUD
 m: (650) 283-6846
 
 http://www.pistoncloud.com
 
 
 Oh, Westley, we'll never survive!
 Nonsense. You're only saying that because no one ever has.
 
 On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote:
 
 
 I am all for pulling this out, but I'm a bit concerned with the fact
 

Re: [Openstack] RHEL / CentOS - interfaces.template

[Joshua Harlow]

Ya, it seems like guestfs and netcf are being worked on by RH (at least in some 
part).
Maybe someone from there can chime in.
It would be awesome to just use guestfs and something like guestnetwork 
(using netcf?) for network config or just have it be a part of guestfs.
Josh

On 2/14/12 2:56 PM, Pádraig Brady p...@draigbrady.com wrote:

On 02/14/2012 06:48 PM, Scott Moser wrote:
 On Tue, 14 Feb 2012, Leandro Reox wrote:

 Hi guys,

 Anyone already implemented networking injection to RHEL systems acting as a
 guest ? If no any plans to make it to Essex final ?


 Before we go down the road of trying to write system network configuration
 scripts for each potential guest OS, I'd suggest that its would be better
 to either:
  a.) just accept that 'interfaces' is the openstack format and guests
  should need to read that.
  b.) create a OS agnostic interface configuration format.

 While you may be looking at my email address and assuming that I think 'a'
 is the right answer only to make it harder for anyone else.

 However, the reason I dislike the current solution (or going down a path
 of implementing population mechanisms for other operating systems) is
  1.) you cannot possibly support all possible operating systems
  2.) injecting files assumes host OS knowledge (or guestfs knowledge) of
  the guest filesystem
  3.) specific files indicates that the host can somehow determine which
  format the guest is expecting (or also unacceptable, only allowing
  this configuration for one OS per cloud).
  4.) injecting files via overwriting them is lossy and possibly
  destructive to a guest (imagine other vpn routes inserted there or
  something else more advanced).

 I would *much* rather there be a openstack networking configuration file
 format that was put into config_drive if dhcp was not sufficient.

 Then, the guests are just made to read that information that is in a
 standard, easily documetable format and respond accordingly.

I have to agree with this.

Ideally openstack would not be polluted with all the
vagaries of guest network configuration.
Though if --flat_injected is a required and common case,
then perhaps in the short term it would be worth adding something
like the griddynamics patch to support the two most common linux formats?
Until now, we've not considered this a priority.

Notes:

This issue is already tracked at:
https://bugs.launchpad.net/nova/+bug/678395

The Red Hat openstack packages do not have any extra support in this regard
(especially since this is a guest issue). All file injection patches supporting
Red Hat (derived) _hosts_, including libguestfs support, are upstream in Essex.

The netcf lib looks interesting. Perhaps it could leverage libguestfs
(already integrated) to maximise the types and configurations of guests it 
could target?

Points 1  2 above are more general and apply to ssh key injection also I think.
libguestfs helps a lot to abstract those guest specific issues away.

cheers,
Pádraig.

___
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] Remove Zones code - FFE

[Kevin L. Mitchell]

On Wed, 2012-02-15 at 00:00 +, Monsyne Dragon wrote:
  Other possibilities:
  
  * Container (not recommended, as it is overloaded with Solaris or Linux 
  container virtualization)
  * ServerGroup
  * HostGroup
  * Group
  * Collection
 
 - Set
 - Cell
 - Huddle
 - Constellation
 - Herd/Flock//Pod/Animal metaphor of choice.
 - System

- Realm
- Universe
- Galaxy
- Kingdom
- Nebula

...
-- 
Kevin L. Mitchell kevin.mitch...@rackspace.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

[Openstack] Keystone: Redux (Dubstep Remix)

[Andy Smith]

tl;dr proposal to merge keystone redux: same API, same client, new
service.  Please review and ask questions!

FRIENDS, ROMANS

We are gathered here today to celebrate the commencement of Keystone
(redux) to fill the role of Keystone (henceforth known as legacy). It is
with great pride that we propose this stand-up-fellow of a refactor to join
the ranks of the other OpenStack projects.

There will be differences, both in how you develop and how you use it,
though we've tried to keep those to a minimum (it has the same API, client,
and migration paths from existing deploys)

You will notice that the code is organized rather differently in most
cases, though still in line with the general form of OpenStack projects,
and we use the standard tools and procedures you may be familiar with from
work on a project like Nova.  (Your wrists will be shattered if you attempt
to use double quotes where single quotes might better suffice.)

The bulk of the work put into `redux` has been to reduce the complexity of
and provide a more easily extensible version of `legacy` while still
providing the features that the other projects require. We think we have
been successful in this, and we hope you'll agree.

Read on for more specifics.

MERGE PROPOSAL:

Please voice your comments  votes on the merge proposal:

  *
https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

Since this is a rather large merge, you can explore the code at github
(reviews should happen in gerrit using the above link):

  * https://github.com/openstack/keystone/tree/redux
  * https://github.com/openstack-dev/devstack/tree/redux

DELTA:

The two major items we are working on adding to redux at time of writing.
Support for XML and LDAP integration.  We propose evaluating the merge with
these known issues, as work is being done to re-add support before E4.

State of XML (via Dolph Mathews)

   Work is underway to support the existing XSD/WADLs
   XML code in its current state is posted to
https://review.openstack.org/#change,4037
   Our hope is to convert XML to/from python objects with minor tweaks
where needed to meet the spec.
   Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to
verify correctness, we hope to use a more pythonic tool in redux

State of LDAP (via Adam Young):

   LDAP code in its current state is posted to
https://github.com/admiyo/keystone/tree/ldap2
   Unit tests pass against fakeldap, with the exception of the ones that
check for uniqueness.  I suspect that is supposed to be enforced by SLAPD
   I am working on getting the scheme documented for the LDAP server, and
for prepopulating Roles.
   Authentication against a live LDAP server works.  Roles and Tenants are
currently ignored.  Getting the schema straight needs to happen first.
   Should have working code in the next day or two.

BUGS:

We've been tagging bugs as redux that are against the rewrite.  You can
view the full list at full bug list at
https://bugs.launchpad.net/keystone/+bugs?field.tag=redux  We marked bugs
that are needed to land before this merge as CRITICAL, and before E4 as
HIGH.

Post Merge:

After merge we will continue improving Keystone, specifically:

 * Target critical/high bugs for E4
 * Work with downstream/packagers on changes needed for their distros
 * Work with tempest on test coverage
 * Another pass through the bugs  blueprints to update the state

Thanks to all the contributors to the rewrite:

Andy Smith
Anthony Young
Brian Waldon
Chmouel Boudjnah
Chuck Short
Dean Troyer
Devin Carlen
Dolph Mathews
James E. Blair
Jesse Andrews
Joe Heck
Justin Santa Barbara
Monty Taylor
Vishvananda Ishaya

HOYOOO!


p.s. wubwubwubSKRwubwub
___
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] Remove Zones code - FFE

[Jason Kölker]

On Wed, 2012-02-15 at 00:00 +, Monsyne Dragon wrote:
 On Feb 14, 2012, at 1:25 PM, Jay Pipes wrote:
 
  -1 on shard b/c of database terminology. -1 on cluster because of HPC and 
  database terminology.
  
  Zone was originally used because it is general -- referring to merely a 
  collection of hosts or other zones and not having a geographic connotation 
  like Region does.
  
  Other possibilities:
  
  * Container (not recommended, as it is overloaded with Solaris or Linux 
  container virtualization)
  * ServerGroup
  * HostGroup
  * Group
  * Collection
 
 - Set
 - Cell
 - Huddle
 - Constellation
 - Herd/Flock//Pod/Animal metaphor of choice.
 - System

% Flange

;)

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

Re: [Openstack] Keystone: Redux (Dubstep Remix)

[Joshua Harlow]

Great!

A question I never understood, why was a redux needed?
Isn't keystone pretty new anyway? Maybe I missed that message/memo.
Was there some kind of learnings/oops moment that happened that we can all 
benefit from (and not repeat?).

Sorry if this is a repeat...

On 2/14/12 4:38 PM, Andy Smith andys...@gmail.com wrote:

tl;dr proposal to merge keystone redux: same API, same client, new service.  
Please review and ask questions!

FRIENDS, ROMANS

We are gathered here today to celebrate the commencement of Keystone (redux) to 
fill the role of Keystone (henceforth known as legacy). It is with great pride 
that we propose this stand-up-fellow of a refactor to join the ranks of the 
other OpenStack projects.

There will be differences, both in how you develop and how you use it, though 
we've tried to keep those to a minimum (it has the same API, client, and 
migration paths from existing deploys)

You will notice that the code is organized rather differently in most cases, 
though still in line with the general form of OpenStack projects, and we use 
the standard tools and procedures you may be familiar with from work on a 
project like Nova.  (Your wrists will be shattered if you attempt to use double 
quotes where single quotes might better suffice.)

The bulk of the work put into `redux` has been to reduce the complexity of and 
provide a more easily extensible version of `legacy` while still providing the 
features that the other projects require. We think we have been successful in 
this, and we hope you'll agree.

Read on for more specifics.

MERGE PROPOSAL:

Please voice your comments  votes on the merge proposal:

  * 
https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

Since this is a rather large merge, you can explore the code at github (reviews 
should happen in gerrit using the above link):

  * https://github.com/openstack/keystone/tree/redux
  * https://github.com/openstack-dev/devstack/tree/redux

DELTA:

The two major items we are working on adding to redux at time of writing.  
Support for XML and LDAP integration.  We propose evaluating the merge with 
these known issues, as work is being done to re-add support before E4.

State of XML (via Dolph Mathews)

   Work is underway to support the existing XSD/WADLs
   XML code in its current state is posted to 
https://review.openstack.org/#change,4037
   Our hope is to convert XML to/from python objects with minor tweaks where 
needed to meet the spec.
   Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to verify 
correctness, we hope to use a more pythonic tool in redux

State of LDAP (via Adam Young):

   LDAP code in its current state is posted to 
https://github.com/admiyo/keystone/tree/ldap2
   Unit tests pass against fakeldap, with the exception of the ones that check 
for uniqueness.  I suspect that is supposed to be enforced by SLAPD
   I am working on getting the scheme documented for the LDAP server, and for 
prepopulating Roles.
   Authentication against a live LDAP server works.  Roles and Tenants are 
currently ignored.  Getting the schema straight needs to happen first.
   Should have working code in the next day or two.

BUGS:

We've been tagging bugs as redux that are against the rewrite.  You can view 
the full list at full bug list at 
https://bugs.launchpad.net/keystone/+bugs?field.tag=redux  We marked bugs that 
are needed to land before this merge as CRITICAL, and before E4 as HIGH.

Post Merge:

After merge we will continue improving Keystone, specifically:

 * Target critical/high bugs for E4
 * Work with downstream/packagers on changes needed for their distros
 * Work with tempest on test coverage
 * Another pass through the bugs  blueprints to update the state

Thanks to all the contributors to the rewrite:

Andy Smith
Anthony Young
Brian Waldon
Chmouel Boudjnah
Chuck Short
Dean Troyer
Devin Carlen
Dolph Mathews
James E. Blair
Jesse Andrews
Joe Heck
Justin Santa Barbara
Monty Taylor
Vishvananda Ishaya

HOYOOO!


p.s. wubwubwubSKRwubwub

___
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] Remove Zones code - FFE

[Ed Leafe]

On Feb 14, 2012, at 6:28 PM, Kevin L. Mitchell wrote:

 On Wed, 2012-02-15 at 00:00 +, Monsyne Dragon wrote:
 Other possibilities:
 
 * Container (not recommended, as it is overloaded with Solaris or Linux 
 container virtualization)
 * ServerGroup
 * HostGroup
 * Group
 * Collection
 
 - Set
 - Cell
 - Huddle
 - Constellation
 - Herd/Flock//Pod/Animal metaphor of choice.
 - System
 
 - Realm
 - Universe
 - Galaxy
 - Kingdom
 - Nebula


Since TCFKAZ (The Concept Formerly Known As Zones) represents a series 
of related but independent deployments of nova, something like 'Cell' or 
'Galaxy'  would be closest analogies. IMO, though, 'Galaxy' is too grandiose a 
term, despite the NASA heritage. So +1 to 'Cell'.


-- Ed Leafe


___
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] Keystone: Redux (Dubstep Remix)

[Andy Smith]

Hey there Joshua,

Good question! `redux` started due to a variety of frustrations with the
previous design that arose from decisions made early in the original
development and were deemed infeasible to resolve in an evolutionary way.

My team and the teams we work with closely felt we were in a good position
to re-imagine some of those decisions while still providing a service that
was functional (since we rely on it heavily for day to day work) and robust.

There will certainly be bugs introduced by this move, but we have an
extremely strong vested interest in fixing them rapidly and feel that the
new code base will greatly improve our ability to do so.

--andy

On Tue, Feb 14, 2012 at 4:53 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:

  Great!

 A question I never understood, why was a redux needed?
 Isn’t keystone “pretty” new anyway? Maybe I missed that message/memo.
 Was there some kind of “learnings/oops moment” that happened that we can
 all benefit from (and not repeat?).

 *Sorry if this is a repeat*...


 On 2/14/12 4:38 PM, Andy Smith andys...@gmail.com wrote:

 tl;dr proposal to merge keystone redux: same API, same client, new
 service.  Please review and ask questions!

 FRIENDS, ROMANS

 We are gathered here today to celebrate the commencement of Keystone
 (redux) to fill the role of Keystone (henceforth known as legacy). It is
 with great pride that we propose this stand-up-fellow of a refactor to join
 the ranks of the other OpenStack projects.

 There will be differences, both in how you develop and how you use it,
 though we've tried to keep those to a minimum (it has the same API, client,
 and migration paths from existing deploys)

 You will notice that the code is organized rather differently in most
 cases, though still in line with the general form of OpenStack projects,
 and we use the standard tools and procedures you may be familiar with from
 work on a project like Nova.  (Your wrists will be shattered if you attempt
 to use double quotes where single quotes might better suffice.)

 The bulk of the work put into `redux` has been to reduce the complexity of
 and provide a more easily extensible version of `legacy` while still
 providing the features that the other projects require. We think we have
 been successful in this, and we hope you'll agree.

 Read on for more specifics.

 MERGE PROPOSAL:

 Please voice your comments  votes on the merge proposal:

   *
 https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

 Since this is a rather large merge, you can explore the code at github
 (reviews should happen in gerrit using the above link):

   * https://github.com/openstack/keystone/tree/redux
   * https://github.com/openstack-dev/devstack/tree/redux

 DELTA:

 The two major items we are working on adding to redux at time of writing.
 Support for XML and LDAP integration.  We propose evaluating the merge with
 these known issues, as work is being done to re-add support before E4.

 State of XML (via Dolph Mathews)

Work is underway to support the existing XSD/WADLs
XML code in its current state is posted to
 https://review.openstack.org/#change,4037
Our hope is to convert XML to/from python objects with minor tweaks
 where needed to meet the spec.
Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to
 verify correctness, we hope to use a more pythonic tool in redux

 State of LDAP (via Adam Young):

LDAP code in its current state is posted to
 https://github.com/admiyo/keystone/tree/ldap2
Unit tests pass against fakeldap, with the exception of the ones that
 check for uniqueness.  I suspect that is supposed to be enforced by SLAPD
I am working on getting the scheme documented for the LDAP server, and
 for prepopulating Roles.
Authentication against a live LDAP server works.  Roles and Tenants are
 currently ignored.  Getting the schema straight needs to happen first.
Should have working code in the next day or two.

 BUGS:

 We've been tagging bugs as redux that are against the rewrite.  You can
 view the full list at full bug list at
 https://bugs.launchpad.net/keystone/+bugs?field.tag=redux  We marked bugs
 that are needed to land before this merge as CRITICAL, and before E4 as
 HIGH.

 Post Merge:

 After merge we will continue improving Keystone, specifically:

  * Target critical/high bugs for E4
  * Work with downstream/packagers on changes needed for their distros
  * Work with tempest on test coverage
  * Another pass through the bugs  blueprints to update the state

 Thanks to all the contributors to the rewrite:

 Andy Smith
 Anthony Young
 Brian Waldon
 Chmouel Boudjnah
 Chuck Short
 Dean Troyer
 Devin Carlen
 Dolph Mathews
 James E. Blair
 Jesse Andrews
 Joe Heck
 Justin Santa Barbara
 Monty Taylor
 Vishvananda Ishaya

 HOYOOO!


 p.s. wubwubwubSKRwubwub


___
Mailing list: https://launchpad.net/~openstack
Post to : 

Re: [Openstack] Keystone: Redux (Dubstep Remix)

[Dolph Mathews]

There's probably several ways to answer this, but I'd say that the original
development of keystone was not sufficiently focused on it's integration
with other projects (and the focus on testing in general came late), while
redux was quite literally born from integration testing.

- Dolph

On Tue, Feb 14, 2012 at 6:53 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:

  Great!

 A question I never understood, why was a redux needed?
 Isn’t keystone “pretty” new anyway? Maybe I missed that message/memo.
 Was there some kind of “learnings/oops moment” that happened that we can
 all benefit from (and not repeat?).

 *Sorry if this is a repeat*...


 On 2/14/12 4:38 PM, Andy Smith andys...@gmail.com wrote:

 tl;dr proposal to merge keystone redux: same API, same client, new
 service.  Please review and ask questions!

 FRIENDS, ROMANS

 We are gathered here today to celebrate the commencement of Keystone
 (redux) to fill the role of Keystone (henceforth known as legacy). It is
 with great pride that we propose this stand-up-fellow of a refactor to join
 the ranks of the other OpenStack projects.

 There will be differences, both in how you develop and how you use it,
 though we've tried to keep those to a minimum (it has the same API, client,
 and migration paths from existing deploys)

 You will notice that the code is organized rather differently in most
 cases, though still in line with the general form of OpenStack projects,
 and we use the standard tools and procedures you may be familiar with from
 work on a project like Nova.  (Your wrists will be shattered if you attempt
 to use double quotes where single quotes might better suffice.)

 The bulk of the work put into `redux` has been to reduce the complexity of
 and provide a more easily extensible version of `legacy` while still
 providing the features that the other projects require. We think we have
 been successful in this, and we hope you'll agree.

 Read on for more specifics.

 MERGE PROPOSAL:

 Please voice your comments  votes on the merge proposal:

   *
 https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

 Since this is a rather large merge, you can explore the code at github
 (reviews should happen in gerrit using the above link):

   * https://github.com/openstack/keystone/tree/redux
   * https://github.com/openstack-dev/devstack/tree/redux

 DELTA:

 The two major items we are working on adding to redux at time of writing.
 Support for XML and LDAP integration.  We propose evaluating the merge with
 these known issues, as work is being done to re-add support before E4.

 State of XML (via Dolph Mathews)

Work is underway to support the existing XSD/WADLs
XML code in its current state is posted to
 https://review.openstack.org/#change,4037
Our hope is to convert XML to/from python objects with minor tweaks
 where needed to meet the spec.
Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to
 verify correctness, we hope to use a more pythonic tool in redux

 State of LDAP (via Adam Young):

LDAP code in its current state is posted to
 https://github.com/admiyo/keystone/tree/ldap2
Unit tests pass against fakeldap, with the exception of the ones that
 check for uniqueness.  I suspect that is supposed to be enforced by SLAPD
I am working on getting the scheme documented for the LDAP server, and
 for prepopulating Roles.
Authentication against a live LDAP server works.  Roles and Tenants are
 currently ignored.  Getting the schema straight needs to happen first.
Should have working code in the next day or two.

 BUGS:

 We've been tagging bugs as redux that are against the rewrite.  You can
 view the full list at full bug list at
 https://bugs.launchpad.net/keystone/+bugs?field.tag=redux  We marked bugs
 that are needed to land before this merge as CRITICAL, and before E4 as
 HIGH.

 Post Merge:

 After merge we will continue improving Keystone, specifically:

  * Target critical/high bugs for E4
  * Work with downstream/packagers on changes needed for their distros
  * Work with tempest on test coverage
  * Another pass through the bugs  blueprints to update the state

 Thanks to all the contributors to the rewrite:

 Andy Smith
 Anthony Young
 Brian Waldon
 Chmouel Boudjnah
 Chuck Short
 Dean Troyer
 Devin Carlen
 Dolph Mathews
 James E. Blair
 Jesse Andrews
 Joe Heck
 Justin Santa Barbara
 Monty Taylor
 Vishvananda Ishaya

 HOYOOO!


 p.s. wubwubwubSKRwubwub


 ___
 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] Keystone: Redux (Dubstep Remix)

[Jesse Andrews]

The major lessons of keystone:

While keystone served as an effective proof of concept for unified
authentication (before keystone each component had its own
users/passwords), it didn't get enough attention from other developers and
integration with other core projects.

The pain caused by not having shared authentication caused it to grow up
too fast.  Keystone was in incubation during Diablo and is scheduled for
official core at the Essex release.

Going forward when something is added to core we need to make sure it has
the project wide support necessary to present a consistent openstack during
the transition and afterwards.

As an example, before quantum becomes a core project we are documenting
what becomes of Nova network and existing APIs.  Glance integration into
nova was a good example where the image list API call proxies to glance.

Additional if the code is vastly different, it is harder to get existing
contributors to participate.

The original keystone team had a hard task and didn't get enough time and
help due to circumstances (some within their control and some not)

Jesse


On Feb 14, 2012 5:53 PM, Andy Smith andys...@gmail.com wrote:

 Hey there Joshua,

 Good question! `redux` started due to a variety of frustrations with the
previous design that arose from decisions made early in the original
development and were deemed infeasible to resolve in an evolutionary way.

 My team and the teams we work with closely felt we were in a good
position to re-imagine some of those decisions while still providing a
service that was functional (since we rely on it heavily for day to day
work) and robust.

 There will certainly be bugs introduced by this move, but we have an
extremely strong vested interest in fixing them rapidly and feel that the
new code base will greatly improve our ability to do so.

 --andy


 On Tue, Feb 14, 2012 at 4:53 PM, Joshua Harlow harlo...@yahoo-inc.com
wrote:

 Great!

 A question I never understood, why was a redux needed?
 Isn’t keystone “pretty” new anyway? Maybe I missed that message/memo.
 Was there some kind of “learnings/oops moment” that happened that we can
all benefit from (and not repeat?).

 Sorry if this is a repeat...


 On 2/14/12 4:38 PM, Andy Smith andys...@gmail.com wrote:

 tl;dr proposal to merge keystone redux: same API, same client, new
service.  Please review and ask questions!

 FRIENDS, ROMANS

 We are gathered here today to celebrate the commencement of Keystone
(redux) to fill the role of Keystone (henceforth known as legacy). It is
with great pride that we propose this stand-up-fellow of a refactor to join
the ranks of the other OpenStack projects.

 There will be differences, both in how you develop and how you use it,
though we've tried to keep those to a minimum (it has the same API, client,
and migration paths from existing deploys)

 You will notice that the code is organized rather differently in most
cases, though still in line with the general form of OpenStack projects,
and we use the standard tools and procedures you may be familiar with from
work on a project like Nova.  (Your wrists will be shattered if you attempt
to use double quotes where single quotes might better suffice.)

 The bulk of the work put into `redux` has been to reduce the complexity
of and provide a more easily extensible version of `legacy` while still
providing the features that the other projects require. We think we have
been successful in this, and we hope you'll agree.

 Read on for more specifics.

 MERGE PROPOSAL:

 Please voice your comments  votes on the merge proposal:

   *
https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

 Since this is a rather large merge, you can explore the code at github
(reviews should happen in gerrit using the above link):

   * https://github.com/openstack/keystone/tree/redux
   * https://github.com/openstack-dev/devstack/tree/redux

 DELTA:

 The two major items we are working on adding to redux at time of
writing.  Support for XML and LDAP integration.  We propose evaluating the
merge with these known issues, as work is being done to re-add support
before E4.

 State of XML (via Dolph Mathews)

Work is underway to support the existing XSD/WADLs
XML code in its current state is posted to
https://review.openstack.org/#change,4037
Our hope is to convert XML to/from python objects with minor tweaks
where needed to meet the spec.
Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to
verify correctness, we hope to use a more pythonic tool in redux

 State of LDAP (via Adam Young):

LDAP code in its current state is posted to
https://github.com/admiyo/keystone/tree/ldap2
Unit tests pass against fakeldap, with the exception of the ones
that check for uniqueness.  I suspect that is supposed to be enforced by
SLAPD
I am working on getting the scheme documented for the LDAP server,
and for prepopulating Roles.
Authentication against a live LDAP server 

Re: [Openstack] Keystone: Redux (Dubstep Remix)

[Nathanael Burton]

Are keystone light and keystone redux the same thing? Or is one just a
light beer?
___
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] Keystone: Redux (Dubstep Remix)

[Jesse Andrews]

Yes

Light was the codename when it was an internal tool.

The first version was a couple hundred lines and supported all core APIs.

After it was decided it would be more effective to flesh out light than
continue to tweak the existing code base, it became the redux branch of the
official keystone repository.
On Feb 14, 2012 6:29 PM, Nathanael Burton nathanael.i.bur...@gmail.com
wrote:

 Are keystone light and keystone redux the same thing? Or is one just a
 light beer?

 ___
 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] Any block storage folks interested in getting together?

[heut2008]

hi,all
   to be first,I am not to be proficient in filesystem and storage,so what
I say may not correct,forgive me.
  to realize EBS like amazon, openstack first use LVM,through iSCSI
PROTOCOL,so we can use remote
storage as block devices.and other problem is snapshot,the ideal situation
is we can make snapshots which
only record the added data.and every snapshot can be deleted without warry
about othe snapshots.also, snapshots can be stores in any s3 like
distributed storage system.
what I want to say is how about use qemu-nbd or an  implementation of nbd
PROTOCOL.because we can
 use qenu-nbd feture of rebae and commit to make snapshots more flexable,a
remaining problem may be
the date read/write rate.
any feedback is appricate^_^.

2012/2/14 Oleg Gelbukh ogelb...@mirantis.com

 Hello,

 We are interested in participating. Looking forward to talk to all Nova
 block storage developers.

 --
 Best regards,
 Oleg


 On Tue, Feb 14, 2012 at 2:31 AM, John Griffith 
 john.griff...@solidfire.com wrote:

 Hi Bob,
 Just pop into IRC: #openstack-meeting

 John

 On Mon, Feb 13, 2012 at 3:17 PM, Bob Van Zant b...@veznat.com wrote:
  I'm interested in joining in. I've never joined one of the calls before,
  where do I get more information on how to join?
 
 
  On Mon, Feb 13, 2012 at 12:06 PM, Diego Parrilla
  diego.parrilla.santama...@gmail.com wrote:
 
  Sounds great. We will try to join the meeting.
 
  Enviado desde mi iPad
 
  El 13/02/2012, a las 19:06, John Griffith john.griff...@solidfire.com
 
  escribió:
 
   There's been a lot of new work going on specific to Nova Volumes the
   past month or so.  I was thinking that it's been a long time since
   we've had a Nova-Volume team meeting and thought I'd see if there was
   any interest in trying to get together next week?  I'm open to
   suggestions regarding time slots but thought I'd propose our old
 slot,
   Thursday Feb 23, 18:00 - 19:00 UTC.
  
   Here's a proposed agenda:
  
  * Quick summary of new blueprints you have submitted and completed
   (or targeting for completion) in Essex
  * Any place folks might need some help with items they've targeted
   for Essex (see if we have any volunteers to help out if needed)
  * Any updates regarding BSaaS
  * Gauge interest in resurrecting a standing meeting, perhaps
 every 2
   weeks?
  
   If you have specific items that you'd be interested in
   sharing/discussing let me know.
  
   Thanks,
   John
  
   ___
   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] Keystone: Redux (Dubstep Remix)

[Devin Carlen]

I agree fully with Jesse.  I think given the timelines the first cut of 
Keystone was great.  Moving forward we'll also have more folks that are 
burdened (honored?) with operating it in production environments which means 
that more rubber meets the road kinds of issues will be identified and dealt 
with quickly. 

Keystone was originally pushed into core a bit too soon, but this was simply a 
byproduct of the fact that the need for it was very real.  All the groundwork 
done to unify the projects was a huge benefit to the community.  Before that 
point, most of the time when someone was working on OpenStack, they were 
really just working on one individual component in an isolated environment.  
Keystone forced the issue for the community and led to the creation of the 
fabulous DevStack project.  This integration made it far simpler to do 
integration testing, and projects like Tempest greatly benefited from it as 
well.

Devin 


On Tuesday, February 14, 2012 at 6:20 PM, Jesse Andrews wrote:

 The major lessons of keystone:
 While keystone served as an effective proof of concept for unified 
 authentication (before keystone each component had its own users/passwords), 
 it didn't get enough attention from other developers and integration with 
 other core projects.
 The pain caused by not having shared authentication caused it to grow up too 
 fast.  Keystone was in incubation during Diablo and is scheduled for official 
 core at the Essex release.
 Going forward when something is added to core we need to make sure it has the 
 project wide support necessary to present a consistent openstack during the 
 transition and afterwards.
 As an example, before quantum becomes a core project we are documenting what 
 becomes of Nova network and existing APIs.  Glance integration into nova was 
 a good example where the image list API call proxies to glance.
 Additional if the code is vastly different, it is harder to get existing 
 contributors to participate.
 The original keystone team had a hard task and didn't get enough time and 
 help due to circumstances (some within their control and some not)
 Jesse
 

___
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] run_tests.sh (-x | --stop) is broken, optparse and nosetests

[Joe Gordon]

Hi Developers,

I have been looking at https://bugs.launchpad.net/nova/+bug/931608,
run_tests.sh (-x | --stop) is broken.  A fix was committed but it only
stopped ./run_tests.sh -x from failing, and not restoring the
./run_tests.sh -x functionality.

run_tests.sh (-x | --stop) is a nosetests parameter which gets passed in
via nova/testing/runner.py:367.  sys.argv for nova/testing/runner.py, takes
two sets of parameters nova parameters and any arbitrary nosetests
parameter.  The nova flags (hide-elapsed etc.) are handled via
'flags.FLAGS.register_cli_opt' and the nosetest parameters are generated
from the args return value from optparse (nova/openstack/common/cfg.py:768:
  (values, args) = self._oparser.parse_args(self._args) ).

The problem is when optparse sees an unknown flag (such as '-x') it
terminates the program without throwing an error.  Additionally the 'args'
return value doesn't contain the flags just flag arguments (only 'a' in '-x
a').  So there is no way of passing on just the unknown flags to nosetest.
 Additionally nosetest uses optparse itself so if you pass in sys.argv to
nosetest with a nova argument set will case the tests to break too.member:jog0


While I can write a hack to look for 'hide-elapsed' or other nova flags, I
am looking for more elegant solutions.  Should this solution live in the
cfg module?


best,
Joe Gordon


member:jog0
___
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] run_tests.sh (-x | --stop) is broken, optparse and nosetests

[Monty Taylor]

Hi!

On 02/14/2012 07:29 PM, Joe Gordon wrote:
 Hi Developers,
 
 I have been looking at https://bugs.launchpad.net/nova/+bug/931608,
 run_tests.sh (-x | --stop) is broken.  A fix was committed but it only
 stopped ./run_tests.sh -x from failing, and not restoring the
 ./run_tests.sh -x functionality.
 
 run_tests.sh (-x | --stop) is a nosetests parameter which gets passed
 in via nova/testing/runner.py:367.  sys.argv for nova/testing/runner.py,
 takes two sets of parameters nova parameters and any arbitrary nosetests
 parameter.  The nova flags (hide-elapsed etc..) are handled via 
 'flags.FLAGS.register_cli_opt' and the nosetest parameters are generated
 from the args return value from optparse
 (nova/openstack/common/cfg.py:768:   (values, args) =
 self._oparser.parse_args(self._args) ).
 
 The problem is when optparse sees an unknown flag (such as '-x') it
 terminates the program without throwing an error.  Additionally the
 'args' return value doesn't contain the flags just flag arguments (only
 'a' in '-x a').  So there is no way of passing on just the unknown flags
 to nosetest.  Additionally nosetest uses optparse itself so if you pass
 in sys.argv to nosetest with a nova argument set will case the tests to
 break too.member:jog0
 
 
 While I can write a hack to look for 'hide-elapsed' or other nova flags,
 I am looking for more elegant solutions.  Should this solution live in
 the cfg module?

So - you and I may be working in parallel here, but in different directions.

I'm currently working on getting install_venv/with_venv replaced by tox.
That may not sound related to your issue, but step #2 on my list of that
project is to get nova/testing/runner.py replaced by pure nosetests
(with the openstack.nose_plugin installed so that we can get our pretty
output)

My vote is - gimme a hand with that, and we can then pass things
straight through to their proper place, and we can stop carrying a
custom test runner.

Monty

___
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] swift with keystone

[ljvsss]

hi,
   i wnat to makw  swift use keystone to auth.

   i config as here https://github.com/openstack/keystone  Swift
Integration - Quick Start



 but at here swift-init main start

object-server already started...
Traceback (most recent call last):
  File /usr/bin/swift-proxy-server, line 22, in module
run_wsgi(conf_file, 'proxy-server', default_port=8080, **options)
  File /usr/lib/python2.7/dist-packages/swift/common/wsgi.py, line 122,
in run_wsgi
loadapp('config:%s' % conf_file, global_conf={'log_name': log_name})
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 204,
in loadapp
return loadobj(APP, uri, name=name, **kw)
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 224,
in loadobj
global_conf=global_conf)
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 248,
in loadcontext
global_conf=global_conf)
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 278,
in _loadconfig
return loader.get_context(object_type, name, global_conf)
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 405,
in get_context
global_additions=global_additions)
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 503,
in _pipeline_app_context
for name in pipeline[:-1]]
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 409,
in get_context
section)
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 431,
in _context_from_use
object_type, name=use, global_conf=global_conf)
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 361,
in get_context
global_conf=global_conf)
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 248,
in loadcontext
global_conf=global_conf)
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 285,
in _loadegg
return loader.get_context(object_type, name, global_conf)
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 561,
in get_context
object_type, name=name)
  File /usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py, line 600,
in find_egg_entry_point
for prot in protocol_options] or '(no entry points)'
LookupError: Entry point 'tokenauth' not found in egg 'keystone' (dir:
/root/keystone; protocols: paste.filter_factory, paste.filter_app_factory;
entry_points: )

is there anybody can help me ?

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

[Openstack-poc] [Bug 930270] Re: flagfile interpolation breaks instance_name_template

[Michael Still]

** Summary changed:

- flagfile interpolation breaks instance_name_tempalte
+ flagfile interpolation breaks instance_name_template

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/930270

Title:
  flagfile interpolation breaks instance_name_template

Status in OpenStack Compute (Nova):
  Fix Committed
Status in openstack-common:
  Fix Committed

Bug description:
  When --volume_name_template=volume-%08x and
  --instance_name_template=instance-%08x are present in nova.conf,
  ConfigParser attempts to interpolate the '%' strings.  There are meant
  for nova to interpolate.

  2012-02-10 10:54:49,089 DEBUG nova.service [-] osapi_compute_link_prefix : 
None from (pid=22867) wait /opt/stack/nova/nova/service.py:409
  2012-02-10 10:54:49,089 CRITICAL nova [-] '%' must be followed by '%' or '(', 
found: '%08x'
  (nova): TRACE: Traceback (most recent call last):
  (nova): TRACE:   File /opt/stack/nova/bin/nova-api, line 53, in module
  (nova): TRACE: service.wait()
  (nova): TRACE:   File /opt/stack/nova/nova/service.py, line 402, in wait
  (nova): TRACE: flag_get = FLAGS.get(flag, None)
  (nova): TRACE:   File /opt/stack/nova/nova/flags.py, line 73, in get
  (nova): TRACE: value = getattr(self, name)
  (nova): TRACE:   File /opt/stack/nova/nova/flags.py, line 70, in __getattr__
  (nova): TRACE: return getattr(self._conf, name)
  (nova): TRACE:   File /opt/stack/nova/nova/openstack/common/cfg.py, line 
784, in __getattr__
  (nova): TRACE: return self._substitute(self._get(name))
  (nova): TRACE:   File /opt/stack/nova/nova/openstack/common/cfg.py, line 
985, in _get
  (nova): TRACE: return opt._get_from_config_parser(self._cparser, section)
  (nova): TRACE:   File /opt/stack/nova/nova/openstack/common/cfg.py, line 
433, in _get_from_config_parser
  (nova): TRACE: return cparser.get(section, self.dest)
  (nova): TRACE:   File /usr/lib/python2.7/ConfigParser.py, line 615, in get
  (nova): TRACE: return self._interpolate(section, option, value, d)
  (nova): TRACE:   File /usr/lib/python2.7/ConfigParser.py, line 683, in 
_interpolate
  (nova): TRACE: self._interpolate_some(option, L, rawval, section, vars, 1)
  (nova): TRACE:   File /usr/lib/python2.7/ConfigParser.py, line 724, in 
_interpolate_some
  (nova): TRACE: '%%' must be followed by '%%' or '(', found: %r % 
(rest,))
  (nova): TRACE: InterpolationSyntaxError: '%' must be followed by '%' or '(', 
found: '%08x'
  (nova): TRACE:
  stack@356591-essex-k1:/opt/stack/nova$

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/930270/+subscriptions

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

Re: [Openstack-poc] Meeting tomorrow

[Dan Wendlandt]

Thanks Jonathan,

I'm not totally sure of the procedure here, so I created a wiki page
that is an updated version of the original application for incubation:
http://wiki.openstack.org/Projects/CoreApplication/Quantum

I look forward to talking with you all about this in more detail
tomorrow at the PPB meeting.

Dan


On Mon, Feb 13, 2012 at 12:48 PM, Jonathan Bryce jbr...@jbryce.com wrote:
 I know it's slightly past the 2 pm cutoff, but would like to go ahead and 
 meet tomorrow to discuss Quantum. Dan is interested in getting Quantum 
 promoted to core for the Folsom release cycle and we need to review soon if 
 we're going to make it. I updated the agenda on the wiki.

 Jonathan.



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

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

Re: [Openstack-poc] Meeting tomorrow

[Thierry Carrez]

Dan Wendlandt wrote:
 Thanks Jonathan,
 
 I'm not totally sure of the procedure here, so I created a wiki page
 that is an updated version of the original application for incubation:
 http://wiki.openstack.org/Projects/CoreApplication/Quantum
 
 I look forward to talking with you all about this in more detail
 tomorrow at the PPB meeting.

Won't be around for the meeting today. FWIW, as far as release
management is concerned, Quantum did the best job for a project in
incubation so far in tracking features and aligning with release
policies ahead of time.

Cheers,

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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