Re: [Openstack] [Folsom] First Guide to try Folsom Packages into Ubuntu 12.04

[Shake Chen]

Thanks for the greate document and script.

I have read the document and have some question,

queston 1


If eth1 is connected to a Switch, it should be in tagged mode.

my question is
If the eth1 not connected to Switch,  it wolud work?


queston 2

Enable IP forwarding :

my question is
In Essex, seem no need Enable IP forwarding ,

 just because we use quantum, so we need setting Enable IP forwarding,
right?











On Sat, Sep 8, 2012 at 12:22 AM, Emilien Macchi  wrote:

> Hi Stackers,
>
> This week, I've been moving forward with Folsom testing.
> It seems that I'm not alone in wanting to see what will provide Folsom and
> what will be the changes for Deployment. I also decided to start a guide
> (with some scripts) [1] which helps anyone who wants to deploy Folsom
> Testing Packages [1] into Ubuntu 12.04.
>
> Keep in mind my work is still under development, but please fill free to
> report any problem.
> At this moment, Networking with Quantum is not working since I've some
> packaging issues but it should be fixed very soon.
>
> Of course, this doc is really far to be ready for full deployment, but it
> will evolute in the future and I hope everyone will enjoy with it.
>
> Thank's to the developers for the great job which has been done, and good
> testing !
>
> [1] https://github.com/EmilienM/openstack-folsom-guide
> [2]
> https://launchpad.net/~openstack-ubuntu-testing/+archive/folsom-trunk-testing
>
>
> Regards,
> --
> Emilien Macchi
> *System Engineer*
> *www.stackops.com
>
> | *emilien.mac...@stackops.com**  *|* skype:emilien.macchi*
> * 
> *
>
> *
>
>  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.
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Shake Chen
___
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] OpenStack Community Weekly Newsletter (Aug 31-Sep 7)

[Stefano Maffulli]

Highlights of the week


  New OpenStack Foundation Gold Members: Intel, VmWare, NEC
  


Today, the OpenStack Board of Directors approved the applications of
three companies wishing to become Gold Members: Intel, NEC and VMware.
The factors considered by the Board included a commitment to helping
achieve the OpenStack Foundation Mission through demonstrated and
potential contribution to the OpenStack community in terms of code,
adoption into product roadmaps, adoption as an end user, geographic and
industry diversity and community development efforts. Join us to welcome
them to the Foundation.


  Session proposals for the Design Summit now open
  


Differently from previous OpenStack Design Summit and Confernece, this
time the "Design Summit" is a specific track in the overall "OpenStack
Summit" event. It is different from other tracks, too. Please make sure
to read the full announcement

and help make this summit the best Design Summit ever.


Caimito 0.9 -- WebDAV frontend
e
for OpnStack Swift
Cloud Storage 

Caimito is an open source (Apache Software License 2.0) WebDAV,caching,
and content management and delivery server frontend for cloud storage.
Caimito supports Openstack Swift Storage
 (Rackspace, Softlayer, etc.),
and Amazon S3 . Caimito also features a REST
API in addition to the Web interface for configuring user access.
Caimito is designed with an event-driven and non-blocking architecture
for Scalability. Caimito is ideal for Hosting and Reseller environments.


  Quantum vs. Nova-network in Folsom
  

tl;dr both Quantum and nova-network will be core and fully supported in
Folsom. More details from Quantum and Nova PTLs on Quantum vs.
Nova-network in Folsom .


  OpenStack, Xen and XenServer: a match made in Heaven!
  


A report from John Garbutt, back from XenSummit in San Diego.  There was
lots of OpenStack related news in many of the CloudOpen sessions,
including the announcement from SUSE that they have an OpenStack
distribution that supports Xen.


XCP-XAPI on Precise


The Citrix-Openstack team is already running automated OpenStack tests
against the stable, and the latest XenServer. As the XCP-XAPI is already
available for Ubuntu systems, the team plans to run the tests against
that platform as well.


  Register now for OpenStack Summit in San Diego
  

The OpenStack room rate is now sold out at the Grand Hyatt. We've set up
another room block at the Embassy Suites located across the street.
Reserve a room

at the OpenStack rate.


Security announcements

  * Horizon, Open redirect through 'next' parameter (CVE-2012-3540)


  * Keystone, Lack of authorization for adding users to tenants
(CVE-2012-3542)




Tips and tricks

  * By Mirantis: Using Software Load Balancing in High Availability (HA)
for OpenStack Cloud API Services


  * By Mate Lakat: VHD to OpenStack using a XAPI host plugin


  * By Brian Waldon: Upgrading OpenStack Glance -- Essex to Folsom

  * A paper on handling compromised components of IaaS with a specific
use case in OpenStack. Definitely worth a read: Aryan TaheriMonfared
/ Martin G Jaatun -- Handling Compromised Components in an IaaS
Cloud Installation


  * By Everett Toews: Getting jclouds and OpenStack work together



Upcoming Events

  * OpenStack Summit  Oct 15 -- 18, 2012 -- San
Diego, CA


Other news

  * OpenStack election of Project Tech Leads is ongoing. Results wil

Re: [Openstack] [Nova] Instance Type Extra Specs clarifications

[Dugger, Donald D]

OS-FLV-EXTRA-DATA:  Do you really need a 17 character scope?  Your current 
scope (I assume it's a derivative of OpenStack Flavor Extra Data) is really 
just redundant info, we know it's extra data for a flavor since we're talking 
about the `extra_specs' table which is used for flavors.  I would think 
something like `disk:qos' would be sufficient, informative and succinct.

Naming consistency: I don't see a real problem here.  As long as a unique scope 
is used then the actual key names can be arbitrary.  Since they are limited to 
a specific scope there is no danger of overlap so no need for a naming 
convention.

Deletion issues:  You raise a good point and I think we should address this.  
When a flavor is deleted any `extra_specs' entries for that flavor should be 
deleted also.  Not a major issue but it would avoid surprises where sale 
`extra_specs' could be associated with a new flavor that re-used an ID.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

From: Vinay Bannai [mailto:vban...@gmail.com]
Sent: Friday, September 07, 2012 2:41 PM
To: Dugger, Donald D
Cc: Patrick Petit; Jiang, Yunhong; openstack@lists.launchpad.net 
(openstack@lists.launchpad.net)
Subject: Re: [Openstack] [Nova] Instance Type Extra Specs clarifications

Yes, the intent has been to use something along the lines of
"OS-FLV-EXTRA-DATA:disk_qos"

This leads to another question which I saw being discussed earlier in the email 
thread. Are we looking for consistency in adding the extra specs? For the most 
obvious ones it may be worth while to come up with a standardized convention 
for the names.

I was looking at the code and it appears that the extra_specs and the 
instance_types creation don't have similar code flow. When you delete a 
instance_type that you created with extra_specs (using the set_key method in 
nova-manage), the extra_specs are not cleaned up. I would have thought that 
they should go away too, right? Unless I understood the concept of extra_specs 
wrong.

Vinay


On Fri, Sep 7, 2012 at 1:27 PM, Dugger, Donald D 
mailto:donald.d.dug...@intel.com>> wrote:
Well, Yunhong added the API to allow you to update the extra specs table so he 
should be able to give you the details on that (he's in China, he might not get 
back to you until next week).

Also, make sure you add a scope (where scope is a string followed by a `:' at 
the beginning of the key) to whatever key you are adding to the extra specs 
table, otherwise your key will create problems with some of the scheduler 
filters.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

From: Vinay Bannai [mailto:vban...@gmail.com]
Sent: Friday, September 07, 2012 2:20 PM
To: Patrick Petit
Cc: Dugger, Donald D; 
openstack@lists.launchpad.net 
(openstack@lists.launchpad.net)
Subject: Re: [Openstack] [Nova] Instance Type Extra Specs clarifications

Hello all,

I am part of the SF south bay meetup group and trying to add a Disk I/O QoS 
feature which is based on the blkiotune in libvirt.
We would like to add flavor types in which we specify the blkiotune in the 
create flavor screen. After reviewing the discussions and some emails it 
appears that it makes sense to use the "instance_type_extra_specs" to add the 
blkiotune as a key/value pair instead of extending the "instance_type" table in 
nova db.

I am able to use nova-manage to create instance type and use "set_key" to add 
extra specs. The set_key seems to make a direct call to the db to insert the 
keys whereas the instance_type create takes the more traditional path through 
the flavomanage controller. However I notice that there is no documentation on 
how to add the extra_specs keys using a RESTful api. Is this something still in 
discussions?

Thanks
Vinay

On Tue, Aug 28, 2012 at 8:02 AM, Patrick Petit 
mailto:patrick.michel.pe...@gmail.com>> wrote:
Hi Don,

I added a comment in https://bugs.launchpad.net/nova/+bug/1039386 regarding 
your point.
Best regards,
Patrick
2012/8/24 Dugger, Donald D 
mailto:donald.d.dug...@intel.com>>

Patrick-

We've enhanced `nova-manage' to manipulate the `extra_specs' entries, c.f. 
https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value,   You can 
add an `extra_specs' key/value pair to a flavor with the command:

nova-manage instance_type add_key m1.humongous cpu_type itanium

And delete a key/value pair with the command:

nova-manage instance_type del_key m1.humongous cpu_type

We're in the process of enhancing `python-novaclient' and Horizon with similar 
capabilities and hope to have them ready for the Folsom release.

Currently, there's no hook to set `extra_specs' through the `nova.conf' file, 
the mechanism is to dynamically add the `extra_specs' key/values after the 
administrator has created a flavor.

Currently, the keys are completely free form but there

Re: [Openstack] [Nova] Instance Type Extra Specs clarifications

[Vinay Bannai]

Yes, the intent has been to use something along the lines of
"OS-FLV-EXTRA-DATA:disk_qos"

This leads to another question which I saw being discussed earlier in the
email thread. Are we looking for consistency in adding the extra specs? For
the most obvious ones it may be worth while to come up with a standardized
convention for the names.

I was looking at the code and it appears that the extra_specs and the
instance_types creation don't have similar code flow. When you delete a
instance_type that you created with extra_specs (using the set_key method
in nova-manage), the extra_specs are not cleaned up. I would have thought
that they should go away too, right? Unless I understood the concept of
extra_specs wrong.

Vinay



On Fri, Sep 7, 2012 at 1:27 PM, Dugger, Donald D
wrote:

>  Well, Yunhong added the API to allow you to update the extra specs table
> so he should be able to give you the details on that (he’s in China, he
> might not get back to you until next week).
>
> ** **
>
> Also, make sure you add a scope (where scope is a string followed by a `:’
> at the beginning of the key) to whatever key you are adding to the extra
> specs table, otherwise your key will create problems with some of the
> scheduler filters.
>
> ** **
>
> --
>
> Don Dugger
>
> "Censeo Toto nos in Kansa esse decisse." - D. Gale
>
> Ph: 303/443-3786
>
> ** **
>
> *From:* Vinay Bannai [mailto:vban...@gmail.com]
> *Sent:* Friday, September 07, 2012 2:20 PM
> *To:* Patrick Petit
> *Cc:* Dugger, Donald D; openstack@lists.launchpad.net (
> openstack@lists.launchpad.net)
> *Subject:* Re: [Openstack] [Nova] Instance Type Extra Specs clarifications
> 
>
> ** **
>
> Hello all,
>
> ** **
>
> I am part of the SF south bay meetup group and trying to add a Disk I/O
> QoS feature which is based on the blkiotune in libvirt. 
>
> We would like to add flavor types in which we specify the blkiotune in the
> create flavor screen. After reviewing the discussions and some emails it
> appears that it makes sense to use the "instance_type_extra_specs" to add
> the blkiotune as a key/value pair instead of extending the "instance_type"
> table in nova db. 
>
> ** **
>
> I am able to use nova-manage to create instance type and use "set_key" to
> add extra specs. The set_key seems to make a direct call to the db to
> insert the keys whereas the instance_type create takes the more traditional
> path through the flavomanage controller. However I notice that there is no
> documentation on how to add the extra_specs keys using a RESTful api. Is
> this something still in discussions? 
>
> ** **
>
> Thanks
>
> Vinay
>
> ** **
>
> On Tue, Aug 28, 2012 at 8:02 AM, Patrick Petit <
> patrick.michel.pe...@gmail.com> wrote:
>
> Hi Don,
>
> ** **
>
> I added a comment in https://bugs.launchpad.net/nova/+bug/1039386regarding 
> your point.
> 
>
> Best regards,
>
> Patrick
>
> 2012/8/24 Dugger, Donald D 
>
> ** **
>
> Patrick-
>
>  
>
> We’ve enhanced `nova-manage’ to manipulate the `extra_specs’ entries, c.f.
> https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value,
>   You can add an `extra_specs’ key/value pair to a flavor with the command:
> 
>
>  
>
> nova-manage instance_type add_key m1.humongous cpu_type
> itanium
>
>  
>
> And delete a key/value pair with the command:
>
>  
>
> nova-manage instance_type del_key m1.humongous cpu_type***
> *
>
>  
>
> We’re in the process of enhancing `python-novaclient’ and Horizon with
> similar capabilities and hope to have them ready for the Folsom release.**
> **
>
>  
>
> Currently, there’s no hook to set `extra_specs’ through the `nova.conf’
> file, the mechanism is to dynamically add the `extra_specs’ key/values
> after the administrator has created a flavor.
>
>  
>
> Currently, the keys are completely free form but there are some issues
> with that so that should change.  Checkout the bug:
>
>  
>
> https://bugs.launchpad.net/nova/+bug/1039386
>
>  
>
> Based upon that bug we need to put some sort of scope on the keys to
> indicate which components a key applies to. I’m in favor of adding a new
> column to the `extra_specs’ table that would explicitly set the scope but
> an alternative would be to encode the scope into the key itself, something
> like `TrustedFilter:trust’ to indicate that  the `trust’ key only applies
> to the `TrustedFilter’ scheduler component.  Feel free to chime in on the
> BZ entry on how to specify the scope, once we decide on how to deal with
> this I’ll create a patch to handle it.
>
>  
>
> --
>
> Don Dugger
>
> "Censeo Toto nos in Kansa esse decisse." - D. Gale
>
> Ph: 303/443-3786
>
>  
>
> *From:* 
> openstack-bounces+donald.d.dugger=intel@lists.launchpad.net[mailto:
> openstack-bounces+donald.d.dugger=intel@lists.launchpad.net] *On
> Behalf Of *Patrick Pe

Re: [Openstack] [Nova] Instance Type Extra Specs clarifications

[Dugger, Donald D]

Well, Yunhong added the API to allow you to update the extra specs table so he 
should be able to give you the details on that (he's in China, he might not get 
back to you until next week).

Also, make sure you add a scope (where scope is a string followed by a `:' at 
the beginning of the key) to whatever key you are adding to the extra specs 
table, otherwise your key will create problems with some of the scheduler 
filters.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

From: Vinay Bannai [mailto:vban...@gmail.com]
Sent: Friday, September 07, 2012 2:20 PM
To: Patrick Petit
Cc: Dugger, Donald D; openstack@lists.launchpad.net 
(openstack@lists.launchpad.net)
Subject: Re: [Openstack] [Nova] Instance Type Extra Specs clarifications

Hello all,

I am part of the SF south bay meetup group and trying to add a Disk I/O QoS 
feature which is based on the blkiotune in libvirt.
We would like to add flavor types in which we specify the blkiotune in the 
create flavor screen. After reviewing the discussions and some emails it 
appears that it makes sense to use the "instance_type_extra_specs" to add the 
blkiotune as a key/value pair instead of extending the "instance_type" table in 
nova db.

I am able to use nova-manage to create instance type and use "set_key" to add 
extra specs. The set_key seems to make a direct call to the db to insert the 
keys whereas the instance_type create takes the more traditional path through 
the flavomanage controller. However I notice that there is no documentation on 
how to add the extra_specs keys using a RESTful api. Is this something still in 
discussions?

Thanks
Vinay

On Tue, Aug 28, 2012 at 8:02 AM, Patrick Petit 
mailto:patrick.michel.pe...@gmail.com>> wrote:
Hi Don,

I added a comment in https://bugs.launchpad.net/nova/+bug/1039386 regarding 
your point.
Best regards,
Patrick
2012/8/24 Dugger, Donald D 
mailto:donald.d.dug...@intel.com>>

Patrick-

We've enhanced `nova-manage' to manipulate the `extra_specs' entries, c.f. 
https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value,   You can 
add an `extra_specs' key/value pair to a flavor with the command:

nova-manage instance_type add_key m1.humongous cpu_type itanium

And delete a key/value pair with the command:

nova-manage instance_type del_key m1.humongous cpu_type

We're in the process of enhancing `python-novaclient' and Horizon with similar 
capabilities and hope to have them ready for the Folsom release.

Currently, there's no hook to set `extra_specs' through the `nova.conf' file, 
the mechanism is to dynamically add the `extra_specs' key/values after the 
administrator has created a flavor.

Currently, the keys are completely free form but there are some issues with 
that so that should change.  Checkout the bug:

https://bugs.launchpad.net/nova/+bug/1039386

Based upon that bug we need to put some sort of scope on the keys to indicate 
which components a key applies to. I'm in favor of adding a new column to the 
`extra_specs' table that would explicitly set the scope but an alternative 
would be to encode the scope into the key itself, something like 
`TrustedFilter:trust' to indicate that  the `trust' key only applies to the 
`TrustedFilter' scheduler component.  Feel free to chime in on the BZ entry on 
how to specify the scope, once we decide on how to deal with this I'll create a 
patch to handle it.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

From: 
openstack-bounces+donald.d.dugger=intel@lists.launchpad.net
 
[mailto:openstack-bounces+donald.d.dugger=intel@lists.launchpad.net]
 On Behalf Of Patrick Petit
Sent: Friday, August 24, 2012 7:13 AM
To: openstack@lists.launchpad.net 
(openstack@lists.launchpad.net)
Subject: [Openstack] [Nova] Instance Type Extra Specs clarifications

Hi,

Could someone give a practical overview of how configuring and using the 
instance type extra specs extension capability introduced in Folsom?

If how extending an instance type is relatively clear.

Eg.: #nova-manage instance_type set_key --name= --key 
 --value <'s== x86_64'>

The principles of capability advertising is less clearer. Is it assumed that 
the key/value pairs are always declared statically as flags in nova.conf of the 
compute node, or can they be generated dynamically and if so, who would that 
be? And also, are the keys completely free form strings or strings that are 
known (reserved) by Nova?

Thanks in advance for clarifying this.

Patrick



--
"Give me a place to stand, and I shall move the earth with a lever"

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

Re: [Openstack] [Nova] Instance Type Extra Specs clarifications

[Vinay Bannai]

Hello all,

I am part of the SF south bay meetup group and trying to add a Disk I/O QoS
feature which is based on the blkiotune in libvirt.
We would like to add flavor types in which we specify the blkiotune in the
create flavor screen. After reviewing the discussions and some emails it
appears that it makes sense to use the "instance_type_extra_specs" to add
the blkiotune as a key/value pair instead of extending the "instance_type"
table in nova db.

I am able to use nova-manage to create instance type and use "set_key" to
add extra specs. The set_key seems to make a direct call to the db to
insert the keys whereas the instance_type create takes the more traditional
path through the flavomanage controller. However I notice that there is no
documentation on how to add the extra_specs keys using a RESTful api. Is
this something still in discussions?

Thanks
Vinay

On Tue, Aug 28, 2012 at 8:02 AM, Patrick Petit <
patrick.michel.pe...@gmail.com> wrote:

> Hi Don,
>
> I added a comment in https://bugs.launchpad.net/nova/+bug/1039386regarding 
> your point.
> Best regards,
> Patrick
>
> 2012/8/24 Dugger, Donald D 
>
>  Patrick-
>>
>> ** **
>>
>> We’ve enhanced `nova-manage’ to manipulate the `extra_specs’ entries,
>> c.f. https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value,
>>   You can add an `extra_specs’ key/value pair to a flavor with the command:
>> 
>>
>> ** **
>>
>> nova-manage instance_type add_key m1.humongous cpu_type
>> itanium
>>
>> ** **
>>
>> And delete a key/value pair with the command:
>>
>> ** **
>>
>> nova-manage instance_type del_key m1.humongous cpu_type**
>> **
>>
>> ** **
>>
>> We’re in the process of enhancing `python-novaclient’ and Horizon with
>> similar capabilities and hope to have them ready for the Folsom release.*
>> ***
>>
>> ** **
>>
>> Currently, there’s no hook to set `extra_specs’ through the `nova.conf’
>> file, the mechanism is to dynamically add the `extra_specs’ key/values
>> after the administrator has created a flavor.
>>
>> ** **
>>
>> Currently, the keys are completely free form but there are some issues
>> with that so that should change.  Checkout the bug:
>>
>> ** **
>>
>> https://bugs.launchpad.net/nova/+bug/1039386
>>
>> ** **
>>
>> Based upon that bug we need to put some sort of scope on the keys to
>> indicate which components a key applies to. I’m in favor of adding a new
>> column to the `extra_specs’ table that would explicitly set the scope but
>> an alternative would be to encode the scope into the key itself, something
>> like `TrustedFilter:trust’ to indicate that  the `trust’ key only applies
>> to the `TrustedFilter’ scheduler component.  Feel free to chime in on the
>> BZ entry on how to specify the scope, once we decide on how to deal with
>> this I’ll create a patch to handle it.
>>
>> ** **
>>
>> --
>>
>> Don Dugger
>>
>> "Censeo Toto nos in Kansa esse decisse." - D. Gale
>>
>> Ph: 303/443-3786
>>
>> ** **
>>
>> *From:* 
>> openstack-bounces+donald.d.dugger=intel@lists.launchpad.net[mailto:
>> openstack-bounces+donald.d.dugger=intel@lists.launchpad.net] *On
>> Behalf Of *Patrick Petit
>> *Sent:* Friday, August 24, 2012 7:13 AM
>> *To:* openstack@lists.launchpad.net (openstack@lists.launchpad.net)
>> *Subject:* [Openstack] [Nova] Instance Type Extra Specs clarifications***
>> *
>>
>> ** **
>>
>> Hi,
>>
>> ** **
>>
>> Could someone give a practical overview of how configuring and using the
>> instance type extra specs extension capability introduced in Folsom?
>>
>> ** **
>>
>> If how extending an instance type is relatively clear.
>>
>> ** **
>>
>> Eg.: #nova-manage instance_type set_key --name= --key
>>  --value <'s== x86_64'> 
>>
>> ** **
>>
>> The principles of capability advertising is less clearer. Is it assumed
>> that the key/value pairs are always declared statically as flags in
>> nova.conf of the compute node, or can they be generated dynamically and if
>> so, who would that be? And also, are the keys completely free form strings
>> or strings that are known (reserved) by Nova?
>>
>> ** **
>>
>> Thanks in advance for clarifying this.
>>
>> ** **
>>
>> Patrick
>>
>
>
>
> --
> *"Give me a place to stand, and I shall move the earth with a lever"*
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Vinay Bannai
Email: vban...@gmail.com
Google Voice: 415 938 7576
___
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] ResourceExtension member_actions question

[Paul Chmielewski]

Is it possible to define a ResourceExtension with a member_action that is
the same for both PUT and GET requests?

For example, let's say I want to add "foo" as a member action for images. I
tried to define the extension as:
res = extensions.ResourceExtension('images',
MyController(),
member_actions={'foo':'PUT', 'foo' :'GET'},
collection_actions={})
But the mapper only finds my foo method for either the PUT or the GET and
not both (depending on whether the method has declared a body parameter).

I'd like to use the same URL (/images//foo) for both PUT and GET
requests.
It works if I define 2 different controllers with the PUT in one and GET in
the other, but it seems like there should be a better way.
Any ideas?
Thanks.
-Paul___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [openstack-hpc] [HPC] Reminder monthly telecon Sep. 10

[Colin McNamara]

I am guessing your intent is to determine the maximum available bandwidth and 
lowest latency (commonly implemented as least hops) path between hosts. In 
other platforms there is the notion of Cell, Zone, Row, Rack etc where the host 
that you are running your workload has the topology encoded in the host meta 
information itself. 

In instances where this is not encoded within some sort of meta of the host 
either shortest path first or constrained shortest path first can be run to 
determine the network, topology and either distributed to the nodes. The 
challenge here is that it is really hard to take into account available 
bandwidth between nodes vs hops.

Regards,

Colin

If you would like to schedule a time to speak with me, please click here to see 
my calendar and pick a time that works for your schedule. The system will 
automatically send us both an outlook meeting invite.

Colin McNamara
(858)208-8105
CCIE #18233,VCP
http://www.colinmcnamara.com
http://www.linkedin.com/in/colinmcnamara

"The difficult we do immediately, the impossible just takes a little
longer"





On Sep 7, 2012, at 9:54 AM, Joseph Suh  wrote:

> All,
> 
> I have a blue print on proximity scheduler at 
> http://wiki.openstack.org/ProximityScheduler, and would like to get feedback 
> on it.
> 
> Thanks,
> 
> Joseph
> 
> - Original Message -
> From: "John Paul Walters" 
> To: openstack@lists.launchpad.net
> Cc: openstack-...@lists.openstack.org
> Sent: Friday, September 7, 2012 12:12:20 PM
> Subject: [openstack-hpc] [HPC] Reminder monthly telecon Sep. 10
> 
> 
> Hi, 
> 
> 
> This is a reminder that we'll hold our next monthly HPC telecon this coming 
> Monday, Sep. 10 and 12:00 noon Eastern Time. We'll use webex (details below). 
> The agenda is somewhat open. Our default will be to start the conversation 
> about HPC features that folks are interested in adding to the Grizzly 
> release. If anyone has any other specific agenda items, they're welcome to 
> propose them. 
> 
> 
> I'm unable to attend, so my colleague David Kang will be hosting this 
> meeting. We look forward to talking to you! 
> 
> 
> best, 
> JP 
> 
> 
> John Paul Walters invites you to attend this online meeting. 
> 
> Topic: HPC Monthly Telecon 
> Date: Monday, September 10, 2012 
> Time: 12:00 pm, Eastern Daylight Time (New York, GMT-04:00) 
> Meeting Number: 927 246 497 
> Meeting Password: hpcmonthly 
> 
> 
> --- 
> To join the online meeting (Now from mobile devices!) 
> --- 
> 1. Go to 
> https://openstack.webex.com/openstack/j.php?ED=203524102&UID=1431607857&PW=NYzljOTEwYThj&RT=MiMxMQ%3D%3D
>  
> 2. If requested, enter your name and email address. 
> 3. If a password is required, enter the meeting password: hpcmonthly 
> 4. Click "Join". 
> 
> To view in other time zones or languages, please click the link: 
> https://openstack.webex.com/openstack/j.php?ED=203524102&UID=1431607857&PW=NYzljOTEwYThj&ORT=MiMxMQ%3D%3D
>  
> 
> 
> ___
> OpenStack-HPC mailing list
> openstack-...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom

[Syd (Sydney) Logan]

I've observed and studied the OVS L3oL3 tunneling in a multi-node configuration 
with F3 by packet sniffing VM to VM pings, and have a basic understanding about 
how the mesh of tunnels comes into existence. Pretty cool.

Guessing 
https://github.com/openstack/quantum/commit/3005d16fe3588bdf4b928e79f640b991df9fae3b
 is the merge you are referring to that implements the blueprint. There was 
also a link to a quantum fork created by CISCO that was mentioned in the 
blueprint, not sure how the code relates (I'm reading both right now).

How this ties in with VXLAN and NVGRE (which I guessed from the blueprint both 
would be plugin instances) is still a bit of a mystery to me, so I look forward 
to whatever documentation appears.

Thanks,

syd

-Original Message-
From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Friday, September 07, 2012 11:11 AM
To: Syd (Sydney) Logan
Cc: OpenStack Development Mailing List; 
openstack-operat...@lists.openstack.org; andi abes; 
openstack@lists.launchpad.net
Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom

Hi Syd,

On Fri, Sep 7, 2012 at 10:34 AM, Syd (Sydney) Logan  wrote:
> I'm I correct in believing that the Quantum L3 Abstractions and API Framework 
> (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api) is the 
> current plan of record for bringing L2toL3 functionality (e.g., VXLAN/NVGRE) 
> into Quantum?

Several Quantum plugins already have L3-over-L3 "overlay" tunneling
capability to provide private L2 tenant networks without VLANs.  These
plugins include the Open vSwitch plugin (completely free/open source)
and the Nicira NVP plugin (commercial).  I suspect others will add
this capability as well in the future, and in general its a great
example of the new network technologies that Quantum enables.

The blueprint above is actually complete and merged, but is actually
about letting tenants define "routers" that connect multiple L2
Quantum networks (e.g., to make multi-tier web applications).  These
routers can also provide access to external networks and implement
floating IPs.  We're still wrapping up the Folsom Quantum docs, but
hopefully this capability will be more clear soon.  Thanks,

Dan


>
> Is anyone signed up to do this or has this blueprint been deprecated in favor 
> of some other approach?
>
> Thanks,
>
> syd
>
> -Original Message-
> From: openstack-bounces+slogan=broadcom@lists.launchpad.net 
> [mailto:openstack-bounces+slogan=broadcom@lists.launchpad.net] On Behalf 
> Of Dan Wendlandt
> Sent: Friday, September 07, 2012 9:57 AM
> To: OpenStack Development Mailing List
> Cc: openstack-operat...@lists.openstack.org; andi abes; 
> openstack@lists.launchpad.net
> Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom
>
> On Fri, Sep 7, 2012 at 8:36 AM, rohon mathieu  wrote:
>> great work thanks;
>>
>> As you said the main missing feature of quantum is the multi-host L3-agent.
>> So I wonder if we can combine nova-network and quantum in a way that
>> nova-network is only used for L3 features?
>
> I agree that it would be great if there was a simple work around like
> that, but I think the core of the problem is the multi_host logic in
> nova-network is closely tied to the IP Address Management (IPAM) logic
> in nova.  Quantum has its own IPAM logic, as it supports more advanced
> scenarios like overlapping IP addresses on different networks.  As a
> result, I think trying to get the nova-network multi_host logic
> working with Quantum would be on the same order of difficultly has
> getting a multi_host equivalent working in Quantum.  I don't think its
> fundamentally hard, we just need to be spending our current Quantum
> cycles on testing, bug fixing, and documentation and so had to drop
> this feature for the Folsom release.
>
> Dan
>
>
>
>>
>>
>> On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt  wrote:
>>>
>>> On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu 
>>> wrote:
>>> > There is still the security filtering issue
>>> > (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
>>> > which prevent some cloud operator from using OVS.
>>> >
>>> > Do you have a workaround to use security group with OVS in folsom?
>>>
>>> Yes, it merged into Nova yesterday.
>>> https://bugs.launchpad.net/quantum/+bug/1039400
>>>
>>> We're still working on the new Quantum docs for Folsom, but if you're
>>> already familiar with using Quantum + Nova, the key difference is that
>>> you use should a libvirt vif-plugging config of
>>> LibvirtHybridOVSBridgeDriver, rather than just
>>> LibvirtOpenVswitchDriver .
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>> >
>>> > On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt  wrote:
>>> >>
>>> >> On Wed, Sep 5, 2012 at 5:23 AM, andi abes  wrote:
>>> >> > late to the party... but I'll dabble.
>>> >> >
>>> >> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright 
>>> >> > wrote:
>>> >> >> * rob_hirschf...@dell.com (rob_hirschf...@dell.com) wrote:
>>> >> >>> We've been

Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom

[Dan Wendlandt]

Hi Syd,

On Fri, Sep 7, 2012 at 10:34 AM, Syd (Sydney) Logan  wrote:
> I'm I correct in believing that the Quantum L3 Abstractions and API Framework 
> (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api) is the 
> current plan of record for bringing L2toL3 functionality (e.g., VXLAN/NVGRE) 
> into Quantum?

Several Quantum plugins already have L3-over-L3 "overlay" tunneling
capability to provide private L2 tenant networks without VLANs.  These
plugins include the Open vSwitch plugin (completely free/open source)
and the Nicira NVP plugin (commercial).  I suspect others will add
this capability as well in the future, and in general its a great
example of the new network technologies that Quantum enables.

The blueprint above is actually complete and merged, but is actually
about letting tenants define "routers" that connect multiple L2
Quantum networks (e.g., to make multi-tier web applications).  These
routers can also provide access to external networks and implement
floating IPs.  We're still wrapping up the Folsom Quantum docs, but
hopefully this capability will be more clear soon.  Thanks,

Dan


>
> Is anyone signed up to do this or has this blueprint been deprecated in favor 
> of some other approach?
>
> Thanks,
>
> syd
>
> -Original Message-
> From: openstack-bounces+slogan=broadcom@lists.launchpad.net 
> [mailto:openstack-bounces+slogan=broadcom@lists.launchpad.net] On Behalf 
> Of Dan Wendlandt
> Sent: Friday, September 07, 2012 9:57 AM
> To: OpenStack Development Mailing List
> Cc: openstack-operat...@lists.openstack.org; andi abes; 
> openstack@lists.launchpad.net
> Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom
>
> On Fri, Sep 7, 2012 at 8:36 AM, rohon mathieu  wrote:
>> great work thanks;
>>
>> As you said the main missing feature of quantum is the multi-host L3-agent.
>> So I wonder if we can combine nova-network and quantum in a way that
>> nova-network is only used for L3 features?
>
> I agree that it would be great if there was a simple work around like
> that, but I think the core of the problem is the multi_host logic in
> nova-network is closely tied to the IP Address Management (IPAM) logic
> in nova.  Quantum has its own IPAM logic, as it supports more advanced
> scenarios like overlapping IP addresses on different networks.  As a
> result, I think trying to get the nova-network multi_host logic
> working with Quantum would be on the same order of difficultly has
> getting a multi_host equivalent working in Quantum.  I don't think its
> fundamentally hard, we just need to be spending our current Quantum
> cycles on testing, bug fixing, and documentation and so had to drop
> this feature for the Folsom release.
>
> Dan
>
>
>
>>
>>
>> On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt  wrote:
>>>
>>> On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu 
>>> wrote:
>>> > There is still the security filtering issue
>>> > (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
>>> > which prevent some cloud operator from using OVS.
>>> >
>>> > Do you have a workaround to use security group with OVS in folsom?
>>>
>>> Yes, it merged into Nova yesterday.
>>> https://bugs.launchpad.net/quantum/+bug/1039400
>>>
>>> We're still working on the new Quantum docs for Folsom, but if you're
>>> already familiar with using Quantum + Nova, the key difference is that
>>> you use should a libvirt vif-plugging config of
>>> LibvirtHybridOVSBridgeDriver, rather than just
>>> LibvirtOpenVswitchDriver .
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>> >
>>> > On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt  wrote:
>>> >>
>>> >> On Wed, Sep 5, 2012 at 5:23 AM, andi abes  wrote:
>>> >> > late to the party... but I'll dabble.
>>> >> >
>>> >> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright 
>>> >> > wrote:
>>> >> >> * rob_hirschf...@dell.com (rob_hirschf...@dell.com) wrote:
>>> >> >>> We've been discussing using Open vSwitch as the basis for
>>> >> >>> non-Quantum
>>> >> >>> Nova Networking deployments in Folsom.  While not Quantum, it feels
>>> >> >>> like
>>> >> >>> we're bringing Nova Networking a step closer to some of the core
>>> >> >>> technologies that Quantum uses.
>>> >> >>
>>> >> >> To what end?
>>> >> >
>>> >> > OVS provides much more robust monitoring and operational facilities
>>> >> > (e.g sFlow monitoring, better switch table visibility etc).
>>> >>
>>> >> You won't find any disagreement from me about OVS having more advanced
>>> >> capabilities :)
>>> >>
>>> >> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
>>> >> > [1]), which should work out-of-box with the linux-bridge. As such,
>>> >> > switching to using OVS rather than the linux bridge could be done
>>> >> > without any code changes to nova, just deployment changes (e.g.
>>> >> > ensure
>>> >> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>>> >>
>>> >> Using ovs-brcompatd would be possible, though some distros do not
>>> >> package and run it by def

Re: [Openstack] [Keystone] LDAP integratiom

[Adam Young]

On 09/07/2012 10:31 AM, Dolph Mathews wrote:
pip-requires/test-requires is aimed at developers and is broken up 
into two files more-so for documentation/organization purposes.


IMO, including LDAP as a dependency should be solved by real packaging 
(e.g. $ apt-get install keystone keystone-ldap).



True, and now that I think of it, I would agree that a pip-requires 
would not make sense here.


Where it would make sense is in devstack.

And I have a ticket for that already.

https://bugs.launchpad.net/devstack/+bug/1021319

My thinking is that if we add ldap to the supported list, keystone would 
be configured to use LDAP as the identity store.




-Dolph


On Fri, Sep 7, 2012 at 8:30 AM, Adam Young > wrote:


On 09/06/2012 05:23 PM, Ivan Kolodyazhny wrote:

Hi Everyone,

Keystone uses python-ldap library to communicate with LDAP
server. There are to points where Keystone communicates with LDAP
server: keystone.common ldap and keystone.identity.backends.ldap
packages. According to the current Keystone architecture it is
solid application w/o extensions or plugins. So it will be useful
to add python-ldap library to pip-requires file. This dependency
is already resolved in the test-requires with comment: 'Optional
backend: LDAP'.


LDAP support is optional, which is why it is not currently in
pip-requires,  but I suspect that, as it grows in visibility, it
will make sense to include it.

It would be helpful to  report things like this as a bug and to
provide a patch.




Best regards,
Ivan Kolodyazhny


___
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] [openstack-dev] Quantum vs. Nova-network in Folsom

[Syd (Sydney) Logan]

I'm I correct in believing that the Quantum L3 Abstractions and API Framework 
(https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api) is the current 
plan of record for bringing L2toL3 functionality (e.g., VXLAN/NVGRE) into 
Quantum?

Is anyone signed up to do this or has this blueprint been deprecated in favor 
of some other approach?

Thanks,

syd

-Original Message-
From: openstack-bounces+slogan=broadcom@lists.launchpad.net 
[mailto:openstack-bounces+slogan=broadcom@lists.launchpad.net] On Behalf Of 
Dan Wendlandt
Sent: Friday, September 07, 2012 9:57 AM
To: OpenStack Development Mailing List
Cc: openstack-operat...@lists.openstack.org; andi abes; 
openstack@lists.launchpad.net
Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom

On Fri, Sep 7, 2012 at 8:36 AM, rohon mathieu  wrote:
> great work thanks;
>
> As you said the main missing feature of quantum is the multi-host L3-agent.
> So I wonder if we can combine nova-network and quantum in a way that
> nova-network is only used for L3 features?

I agree that it would be great if there was a simple work around like
that, but I think the core of the problem is the multi_host logic in
nova-network is closely tied to the IP Address Management (IPAM) logic
in nova.  Quantum has its own IPAM logic, as it supports more advanced
scenarios like overlapping IP addresses on different networks.  As a
result, I think trying to get the nova-network multi_host logic
working with Quantum would be on the same order of difficultly has
getting a multi_host equivalent working in Quantum.  I don't think its
fundamentally hard, we just need to be spending our current Quantum
cycles on testing, bug fixing, and documentation and so had to drop
this feature for the Folsom release.

Dan



>
>
> On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt  wrote:
>>
>> On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu 
>> wrote:
>> > There is still the security filtering issue
>> > (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
>> > which prevent some cloud operator from using OVS.
>> >
>> > Do you have a workaround to use security group with OVS in folsom?
>>
>> Yes, it merged into Nova yesterday.
>> https://bugs.launchpad.net/quantum/+bug/1039400
>>
>> We're still working on the new Quantum docs for Folsom, but if you're
>> already familiar with using Quantum + Nova, the key difference is that
>> you use should a libvirt vif-plugging config of
>> LibvirtHybridOVSBridgeDriver, rather than just
>> LibvirtOpenVswitchDriver .
>>
>> Dan
>>
>>
>>
>>
>>
>> >
>> > On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt  wrote:
>> >>
>> >> On Wed, Sep 5, 2012 at 5:23 AM, andi abes  wrote:
>> >> > late to the party... but I'll dabble.
>> >> >
>> >> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright 
>> >> > wrote:
>> >> >> * rob_hirschf...@dell.com (rob_hirschf...@dell.com) wrote:
>> >> >>> We've been discussing using Open vSwitch as the basis for
>> >> >>> non-Quantum
>> >> >>> Nova Networking deployments in Folsom.  While not Quantum, it feels
>> >> >>> like
>> >> >>> we're bringing Nova Networking a step closer to some of the core
>> >> >>> technologies that Quantum uses.
>> >> >>
>> >> >> To what end?
>> >> >
>> >> > OVS provides much more robust monitoring and operational facilities
>> >> > (e.g sFlow monitoring, better switch table visibility etc).
>> >>
>> >> You won't find any disagreement from me about OVS having more advanced
>> >> capabilities :)
>> >>
>> >> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
>> >> > [1]), which should work out-of-box with the linux-bridge. As such,
>> >> > switching to using OVS rather than the linux bridge could be done
>> >> > without any code changes to nova, just deployment changes (e.g.
>> >> > ensure
>> >> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>> >>
>> >> Using ovs-brcompatd would be possible, though some distros do not
>> >> package and run it by default and in general it is not the "preferred"
>> >> way to run things according to email on the OVS mailing list.
>> >>
>> >> >
>> >> > For the more adventurous, there could be any number of interesting
>> >> > scenarios enabled by having access to ovs capabilities  (e.g.
>> >> > tunneling)
>> >>
>> >> Tunneling is definitely a huge benefit of OVS, but you still need
>> >> someone to setup the tunnels and direct packets into them correctly.
>> >> That's is exactly what the Quantum OVS plugin does and it is
>> >> completely open source and freely available, so if people want to
>> >> experiment with OVS tunneling, using Quantum would seem like the
>> >> obvious way to do this.
>> >>
>> >> Dan
>> >>
>> >>
>> >> --
>> >> ~~~
>> >> Dan Wendlandt
>> >> Nicira, Inc: www.nicira.com
>> >> twitter: danwendlandt
>> >> ~~~
>> >>
>> >> ___
>> >> OpenStack-dev mailing list
>> >> openstack-...@lists.openstack.org
>> >> htt

Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom

[Dan Wendlandt]

On Fri, Sep 7, 2012 at 8:36 AM, rohon mathieu  wrote:
> great work thanks;
>
> As you said the main missing feature of quantum is the multi-host L3-agent.
> So I wonder if we can combine nova-network and quantum in a way that
> nova-network is only used for L3 features?

I agree that it would be great if there was a simple work around like
that, but I think the core of the problem is the multi_host logic in
nova-network is closely tied to the IP Address Management (IPAM) logic
in nova.  Quantum has its own IPAM logic, as it supports more advanced
scenarios like overlapping IP addresses on different networks.  As a
result, I think trying to get the nova-network multi_host logic
working with Quantum would be on the same order of difficultly has
getting a multi_host equivalent working in Quantum.  I don't think its
fundamentally hard, we just need to be spending our current Quantum
cycles on testing, bug fixing, and documentation and so had to drop
this feature for the Folsom release.

Dan



>
>
> On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt  wrote:
>>
>> On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu 
>> wrote:
>> > There is still the security filtering issue
>> > (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
>> > which prevent some cloud operator from using OVS.
>> >
>> > Do you have a workaround to use security group with OVS in folsom?
>>
>> Yes, it merged into Nova yesterday.
>> https://bugs.launchpad.net/quantum/+bug/1039400
>>
>> We're still working on the new Quantum docs for Folsom, but if you're
>> already familiar with using Quantum + Nova, the key difference is that
>> you use should a libvirt vif-plugging config of
>> LibvirtHybridOVSBridgeDriver, rather than just
>> LibvirtOpenVswitchDriver .
>>
>> Dan
>>
>>
>>
>>
>>
>> >
>> > On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt  wrote:
>> >>
>> >> On Wed, Sep 5, 2012 at 5:23 AM, andi abes  wrote:
>> >> > late to the party... but I'll dabble.
>> >> >
>> >> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright 
>> >> > wrote:
>> >> >> * rob_hirschf...@dell.com (rob_hirschf...@dell.com) wrote:
>> >> >>> We've been discussing using Open vSwitch as the basis for
>> >> >>> non-Quantum
>> >> >>> Nova Networking deployments in Folsom.  While not Quantum, it feels
>> >> >>> like
>> >> >>> we're bringing Nova Networking a step closer to some of the core
>> >> >>> technologies that Quantum uses.
>> >> >>
>> >> >> To what end?
>> >> >
>> >> > OVS provides much more robust monitoring and operational facilities
>> >> > (e.g sFlow monitoring, better switch table visibility etc).
>> >>
>> >> You won't find any disagreement from me about OVS having more advanced
>> >> capabilities :)
>> >>
>> >> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
>> >> > [1]), which should work out-of-box with the linux-bridge. As such,
>> >> > switching to using OVS rather than the linux bridge could be done
>> >> > without any code changes to nova, just deployment changes (e.g.
>> >> > ensure
>> >> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>> >>
>> >> Using ovs-brcompatd would be possible, though some distros do not
>> >> package and run it by default and in general it is not the "preferred"
>> >> way to run things according to email on the OVS mailing list.
>> >>
>> >> >
>> >> > For the more adventurous, there could be any number of interesting
>> >> > scenarios enabled by having access to ovs capabilities  (e.g.
>> >> > tunneling)
>> >>
>> >> Tunneling is definitely a huge benefit of OVS, but you still need
>> >> someone to setup the tunnels and direct packets into them correctly.
>> >> That's is exactly what the Quantum OVS plugin does and it is
>> >> completely open source and freely available, so if people want to
>> >> experiment with OVS tunneling, using Quantum would seem like the
>> >> obvious way to do this.
>> >>
>> >> Dan
>> >>
>> >>
>> >> --
>> >> ~~~
>> >> Dan Wendlandt
>> >> Nicira, Inc: www.nicira.com
>> >> twitter: danwendlandt
>> >> ~~~
>> >>
>> >> ___
>> >> OpenStack-dev mailing list
>> >> openstack-...@lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > openstack-...@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> ~~~
>> Dan Wendlandt
>> Nicira, Inc: www.nicira.com
>> twitter: danwendlandt
>> ~~~
>>
>> ___
>> OpenStack-dev mailing list
>> openstack-...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> openstack-...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/

Re: [Openstack] [openstack-hpc] [HPC] Reminder monthly telecon Sep. 10

[Joseph Suh]

All,

I have a blue print on proximity scheduler at 
http://wiki.openstack.org/ProximityScheduler, and would like to get feedback on 
it.

Thanks,

Joseph

- Original Message -
From: "John Paul Walters" 
To: openstack@lists.launchpad.net
Cc: openstack-...@lists.openstack.org
Sent: Friday, September 7, 2012 12:12:20 PM
Subject: [openstack-hpc] [HPC] Reminder monthly telecon Sep. 10


Hi, 


This is a reminder that we'll hold our next monthly HPC telecon this coming 
Monday, Sep. 10 and 12:00 noon Eastern Time. We'll use webex (details below). 
The agenda is somewhat open. Our default will be to start the conversation 
about HPC features that folks are interested in adding to the Grizzly release. 
If anyone has any other specific agenda items, they're welcome to propose them. 


I'm unable to attend, so my colleague David Kang will be hosting this meeting. 
We look forward to talking to you! 


best, 
JP 


John Paul Walters invites you to attend this online meeting. 

Topic: HPC Monthly Telecon 
Date: Monday, September 10, 2012 
Time: 12:00 pm, Eastern Daylight Time (New York, GMT-04:00) 
Meeting Number: 927 246 497 
Meeting Password: hpcmonthly 


--- 
To join the online meeting (Now from mobile devices!) 
--- 
1. Go to 
https://openstack.webex.com/openstack/j.php?ED=203524102&UID=1431607857&PW=NYzljOTEwYThj&RT=MiMxMQ%3D%3D
 
2. If requested, enter your name and email address. 
3. If a password is required, enter the meeting password: hpcmonthly 
4. Click "Join". 

To view in other time zones or languages, please click the link: 
https://openstack.webex.com/openstack/j.php?ED=203524102&UID=1431607857&PW=NYzljOTEwYThj&ORT=MiMxMQ%3D%3D
 


___
OpenStack-HPC mailing list
openstack-...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc

___
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] After expanding fixed ip range instances no longer have network

[Jonathan Proulx]

Thanks Vish,

Your directions were correct & would have saved me a few hours of
floundering had I just started a little later :)

particularly the `killall dnsmasq`

-Jon

On Fri, Sep 07, 2012 at 09:12:52AM -0700, Vishvananda Ishaya wrote:
:If you are sure this is the issue:
:
:killall dnsmasq
:restart nova-network
:
:Vish
:
:On Sep 7, 2012, at 8:59 AM, Jonathan Proulx  wrote:
:
:> On Fri, Sep 7, 2012 at 11:33 AM, Jonathan Proulx  wrote:
:> 
:>> Can any one tell me what I've looked?
:> 
:> I assumed stopping and restarting nova-network would restart dnsmasq
:> since dnsmasq doesn't have it's own init script, but this seems not to
:> be the case.
:> 
:> dnsmasq is listening on an IP the system nolonger has, I'm sure I'll
:> find the answer ot this on my own soon enough but how does one
:> properly restart openstack's dnsmasq (on ubuntu)?  It clearly gets
:> started with lots of command line args from nova.conf
:> 
:> -Jon
:> 
:> ___
:> 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] [HPC] Reminder monthly telecon Sep. 10

[John Paul Walters]

Hi,

This is a reminder that we'll hold our next monthly HPC telecon this coming 
Monday, Sep. 10 and 12:00 noon Eastern Time.  We'll use webex (details below).  
The agenda is somewhat open.  Our default will be to start the conversation 
about HPC features that folks are interested in adding to the Grizzly release.  
 If anyone has any other specific agenda items, they're welcome to propose them.

I'm unable to attend, so my colleague David Kang will be  hosting this meeting. 
 We look forward to talking to you!

best,
JP

John Paul Walters invites you to attend this online meeting. 

Topic: HPC Monthly Telecon 
Date: Monday, September 10, 2012 
Time: 12:00 pm, Eastern Daylight Time (New York, GMT-04:00) 
Meeting Number: 927 246 497 
Meeting Password: hpcmonthly 


--- 
To join the online meeting (Now from mobile devices!) 
--- 
1. Go to 
https://openstack.webex.com/openstack/j.php?ED=203524102&UID=1431607857&PW=NYzljOTEwYThj&RT=MiMxMQ%3D%3D
 
2. If requested, enter your name and email address. 
3. If a password is required, enter the meeting password: hpcmonthly 
4. Click "Join". 

To view in other time zones or languages, please click the link: 
https://openstack.webex.com/openstack/j.php?ED=203524102&UID=1431607857&PW=NYzljOTEwYThj&ORT=MiMxMQ%3D%3D
 

___
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] After expanding fixed ip range instances no longer have network

[Vishvananda Ishaya]

If you are sure this is the issue:

killall dnsmasq
restart nova-network

Vish

On Sep 7, 2012, at 8:59 AM, Jonathan Proulx  wrote:

> On Fri, Sep 7, 2012 at 11:33 AM, Jonathan Proulx  wrote:
> 
>> Can any one tell me what I've looked?
> 
> I assumed stopping and restarting nova-network would restart dnsmasq
> since dnsmasq doesn't have it's own init script, but this seems not to
> be the case.
> 
> dnsmasq is listening on an IP the system nolonger has, I'm sure I'll
> find the answer ot this on my own soon enough but how does one
> properly restart openstack's dnsmasq (on ubuntu)?  It clearly gets
> started with lots of command line args from nova.conf
> 
> -Jon
> 
> ___
> 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] [Folsom] First Guide to try Folsom Packages into Ubuntu 12.04

[Emilien Macchi]

Hi Stackers,

This week, I've been moving forward with Folsom testing.
It seems that I'm not alone in wanting to see what will provide Folsom and
what will be the changes for Deployment. I also decided to start a guide
(with some scripts) [1] which helps anyone who wants to deploy Folsom
Testing Packages [1] into Ubuntu 12.04.

Keep in mind my work is still under development, but please fill free to
report any problem.
At this moment, Networking with Quantum is not working since I've some
packaging issues but it should be fixed very soon.

Of course, this doc is really far to be ready for full deployment, but it
will evolute in the future and I hope everyone will enjoy with it.

Thank's to the developers for the great job which has been done, and good
testing !

[1] https://github.com/EmilienM/openstack-folsom-guide
[2]
https://launchpad.net/~openstack-ubuntu-testing/+archive/folsom-trunk-testing


Regards,
-- 
Emilien Macchi
*System Engineer*
*www.stackops.com

| *emilien.mac...@stackops.com**  *|* skype:emilien.macchi*
* 
*

*

 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.
___
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] After expanding fixed ip range instances no longer have network

[Jonathan Proulx]

On Fri, Sep 07, 2012 at 11:59:20AM -0400, Jonathan Proulx wrote:
:On Fri, Sep 7, 2012 at 11:33 AM, Jonathan Proulx  wrote:

:dnsmasq is listening on an IP the system nolonger has, I'm sure I'll
:find the answer ot this on my own soon enough but how does one
:properly restart openstack's dnsmasq (on ubuntu)?  It clearly gets
:started with lots of command line args from nova.conf

For teh record: One way that works is to kill all dnsmasq processes then restart
nova-network. Hopefully there's a cleaner way, but I no longer *need*
to find it.

___
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] After expanding fixed ip range instances no longer have network

[Vishvananda Ishaya]

VERY IMPORTANT FIRST STEP: nova will have moved the ip from eth0 (or whichever 
device br100 is on) to br100, so if that ip address is needed, you will have to 
move it back to eth0. If you are connecting over that ip you will have to do it 
in a script so your connection doesn't drop. Check the / by using 
ip addr show.

DISCLAIMER: writing this from memory so check for typos
(if br100 was bridged into a device without an ip address you can skip moving 
the ips but i would still delete br100)

On each node running nova-network:
ip addr del / dev br100
ifconfig br100 down
brctl delbr br100
ip addr add / dev eth0 


Now you should be able to make nova recreate everything for you
On each node running nova-network:
stop nova-network
killall dnsmasq
rm /var/lib/nova/networks/*
start nova-network

Vish

On Sep 7, 2012, at 8:33 AM, Jonathan Proulx  wrote:

> Hi All,
> 
> Running Essex on Ununtu 12.04 using multi-host  FlatDHCP nova-networking
> 
> I ran out of IPs on my fixed_ip range so I shut everything (instances,
> nova-network, nova-compute) down deleted the old network and recreated
> it with a smaller netmask.  This seems to have almost worked.
> 
> I can start more instances than I previously had fixed ip's, the right
> ones seem to be being assigned and the mask on the recreated bridge
> interfaces is correct, but the (ubuntu-cloudimage) instances can't
> seem to see their NIC's any more, or perhaps aren't getting dhcp
> properly I'm still trying to force my way in as our instances rather
> rely on net access for accounts.
> 
> On the compute node things seem OK the bridge is up and the right
> things are connected:
> 
> root@nova-5:/var/log/nova# brctl show br100
> bridge name   bridge id   STP enabled interfaces
> br100 8000.60eb69d22521   no  eth1
>   vnet0
>   vnet1
>   vnet2
> 
> 
> I do notice this in iptables:
> 
> Chain nova-network-POSTROUTING (1 references)
> target prot opt source   destination
> ACCEPT all  --  10.0.0.0/16  nova-5.csail.mit.edu
> ACCEPT all  --  10.0.0.0/16  10.128.0.0/24
> ACCEPT all  --  10.0.0.0/16  10.0.0.0/16  ! ctstate DNAT
> 
> 
> my fixed range is 10.0.0.0/16 not sure where 10.128.0.0/24 comes into
> it as I don't use that network, but can't see that as a problem.
> 
> Can any one tell me what I've looked?
> 
> -Jon
> 
> ___
> 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] After expanding fixed ip range instances no longer have network

[Jonathan Proulx]

On Fri, Sep 7, 2012 at 11:33 AM, Jonathan Proulx  wrote:

> Can any one tell me what I've looked?

I assumed stopping and restarting nova-network would restart dnsmasq
since dnsmasq doesn't have it's own init script, but this seems not to
be the case.

dnsmasq is listening on an IP the system nolonger has, I'm sure I'll
find the answer ot this on my own soon enough but how does one
properly restart openstack's dnsmasq (on ubuntu)?  It clearly gets
started with lots of command line args from nova.conf

-Jon

___
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] After expanding fixed ip range instances no longer have network

[Jonathan Proulx]

Hi All,

Running Essex on Ununtu 12.04 using multi-host  FlatDHCP nova-networking

I ran out of IPs on my fixed_ip range so I shut everything (instances,
nova-network, nova-compute) down deleted the old network and recreated
it with a smaller netmask.  This seems to have almost worked.

I can start more instances than I previously had fixed ip's, the right
ones seem to be being assigned and the mask on the recreated bridge
interfaces is correct, but the (ubuntu-cloudimage) instances can't
seem to see their NIC's any more, or perhaps aren't getting dhcp
properly I'm still trying to force my way in as our instances rather
rely on net access for accounts.

On the compute node things seem OK the bridge is up and the right
things are connected:

root@nova-5:/var/log/nova# brctl show br100
bridge name bridge id   STP enabled interfaces
br100   8000.60eb69d22521   no  eth1
vnet0
vnet1
vnet2


I do notice this in iptables:

Chain nova-network-POSTROUTING (1 references)
target prot opt source   destination
ACCEPT all  --  10.0.0.0/16  nova-5.csail.mit.edu
ACCEPT all  --  10.0.0.0/16  10.128.0.0/24
ACCEPT all  --  10.0.0.0/16  10.0.0.0/16  ! ctstate DNAT


my fixed range is 10.0.0.0/16 not sure where 10.128.0.0/24 comes into
it as I don't use that network, but can't see that as a problem.

Can any one tell me what I've looked?

-Jon

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

Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom

[rohon mathieu]

great work thanks;

As you said the main missing feature of quantum is the multi-host L3-agent.
So I wonder if we can combine nova-network and quantum in a way that
nova-network is only used for L3 features?

On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt  wrote:

> On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu 
> wrote:
> > There is still the security filtering issue
> > (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
> > which prevent some cloud operator from using OVS.
> >
> > Do you have a workaround to use security group with OVS in folsom?
>
> Yes, it merged into Nova yesterday.
> https://bugs.launchpad.net/quantum/+bug/1039400
>
> We're still working on the new Quantum docs for Folsom, but if you're
> already familiar with using Quantum + Nova, the key difference is that
> you use should a libvirt vif-plugging config of
> LibvirtHybridOVSBridgeDriver, rather than just
> LibvirtOpenVswitchDriver .
>
> Dan
>
>
>
>
>
> >
> > On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt  wrote:
> >>
> >> On Wed, Sep 5, 2012 at 5:23 AM, andi abes  wrote:
> >> > late to the party... but I'll dabble.
> >> >
> >> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright 
> >> > wrote:
> >> >> * rob_hirschf...@dell.com (rob_hirschf...@dell.com) wrote:
> >> >>> We've been discussing using Open vSwitch as the basis for
> non-Quantum
> >> >>> Nova Networking deployments in Folsom.  While not Quantum, it feels
> like
> >> >>> we're bringing Nova Networking a step closer to some of the core
> >> >>> technologies that Quantum uses.
> >> >>
> >> >> To what end?
> >> >
> >> > OVS provides much more robust monitoring and operational facilities
> >> > (e.g sFlow monitoring, better switch table visibility etc).
> >>
> >> You won't find any disagreement from me about OVS having more advanced
> >> capabilities :)
> >>
> >> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
> >> > [1]), which should work out-of-box with the linux-bridge. As such,
> >> > switching to using OVS rather than the linux bridge could be done
> >> > without any code changes to nova, just deployment changes (e.g. ensure
> >> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
> >>
> >> Using ovs-brcompatd would be possible, though some distros do not
> >> package and run it by default and in general it is not the "preferred"
> >> way to run things according to email on the OVS mailing list.
> >>
> >> >
> >> > For the more adventurous, there could be any number of interesting
> >> > scenarios enabled by having access to ovs capabilities  (e.g.
> >> > tunneling)
> >>
> >> Tunneling is definitely a huge benefit of OVS, but you still need
> >> someone to setup the tunnels and direct packets into them correctly.
> >> That's is exactly what the Quantum OVS plugin does and it is
> >> completely open source and freely available, so if people want to
> >> experiment with OVS tunneling, using Quantum would seem like the
> >> obvious way to do this.
> >>
> >> Dan
> >>
> >>
> >> --
> >> ~~~
> >> Dan Wendlandt
> >> Nicira, Inc: www.nicira.com
> >> twitter: danwendlandt
> >> ~~~
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> openstack-...@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > openstack-...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> ~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~
>
> ___
> OpenStack-dev mailing list
> openstack-...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
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] LDAP integratiom

[Dolph Mathews]

pip-requires/test-requires is aimed at developers and is broken up into two
files more-so for documentation/organization purposes.

IMO, including LDAP as a dependency should be solved by real packaging
(e.g. $ apt-get install keystone keystone-ldap).

-Dolph


On Fri, Sep 7, 2012 at 8:30 AM, Adam Young  wrote:

>  On 09/06/2012 05:23 PM, Ivan Kolodyazhny wrote:
>
> Hi Everyone,
>
>  Keystone uses python-ldap library to communicate with LDAP server. There
> are to points where Keystone communicates with LDAP server: keystone.common
> ldap and keystone.identity.backends.ldap packages. According to the current
> Keystone architecture it is solid application w/o extensions or plugins. So
> it will be useful to add python-ldap library to pip-requires file. This
> dependency is already resolved in the test-requires with comment: 'Optional
> backend: LDAP'.
>
>
> LDAP support is optional, which is why it is not currently in
> pip-requires,  but I suspect that, as it grows in visibility, it will make
> sense to include it.
>
> It would be helpful to  report things like this as a bug and to provide a
> patch.
>
>
>
> Best regards,
> Ivan Kolodyazhny
>
>
> ___
> 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] [ceilometer] Weekly irc meetings time change?

[Surya_Prabhakar]

Does 6PM UTC , Thursdays work?? This slot looks free.

From: openstack-bounces+surya_prabhakar=dell@lists.launchpad.net 
[openstack-bounces+surya_prabhakar=dell@lists.launchpad.net] On Behalf Of 
Doug Hellmann [doug.hellm...@dreamhost.com]
Sent: Friday, September 07, 2012 4:27 PM
To: Nick Barcet
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [ceilometer] Weekly irc meetings time change?

On Fri, Sep 7, 2012 at 6:39 AM, Nick Barcet 
mailto:nick.bar...@canonical.com>> wrote:
On 09/05/2012 11:51 AM, Nick Barcet wrote:
> Thanks for asking, I was just about to come up with this.  So based on
> the poll, it seems that the 3-4pm UTC time slot received the most favors
> with 9 yes, 1 "if need be" and 1 no.  So I guess we'll have to do
> without Angus, unless we want to do alternating meetings to satisfy both
> sides of the planet. In the later case we could do one week at 3pm UTC,
> and the other at 9PM.  What would the others think about this?
>
> In any case, the next meeting will be tomorrow at 3pm UTC.  I'll be
> sending a formal invite later today.

Based on yesterday's meeting, we decided to try alternating time. Since
9PM UTC is taken on thursdays, I am proposing to move it on Wednesdays.
 If Nobody objects, this means that starting next week we'll have our
meetings on:

Wednesday at 9PM UTC for odd weeks (September 12, 26)
Thursday at 3PM UTC for even weeks (September 20 and October 4)

Does this work for everyone?

That time on Wednesday does not work for me. An hour earlier or later would 
work, if you want to try to stay close to the same time.

I am available during the Thursday time slot.

Doug

___
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] LDAP integratiom

[Adam Young]

On 09/06/2012 05:23 PM, Ivan Kolodyazhny wrote:

Hi Everyone,

Keystone uses python-ldap library to communicate with LDAP server. 
There are to points where Keystone communicates with LDAP server: 
keystone.common ldap and keystone.identity.backends.ldap packages. 
According to the current Keystone architecture it is solid application 
w/o extensions or plugins. So it will be useful to add python-ldap 
library to pip-requires file. This dependency is already resolved in 
the test-requires with comment: 'Optional backend: LDAP'.


LDAP support is optional, which is why it is not currently in 
pip-requires,  but I suspect that, as it grows in visibility, it will 
make sense to include it.


It would be helpful to  report things like this as a bug and to provide 
a patch.





Best regards,
Ivan Kolodyazhny


___
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] issues with fixed_range blocking new instance creation?

[Jonathan Proulx]

On Thu, Sep 6, 2012 at 9:59 PM, Vishvananda Ishaya
 wrote:
> fixed range is likely fine. I suspect you created your network with a 
> 10.0.0.0/24 though. It might be a bit tricky to switch to a larger range now. 
> You may have to create the rest of your fixed ips manually in the db 
> associated with the same network and then change the cidr entry on the 
> network in the db to 10.0.0.0/16. You also might have to manually destroy the 
> bridges and let nova-network recreate them.

That does seem to be the case, if you'd asked me 24hr ago I'd have
sworn I never put /24 anywhere but that's the only explaination that
fits observed reality.  Luckily I haven't quite called the system
production yet so I'm taking a maintenance window now, terminating all
instances and deleting and recreating network

Being able to expand networks more easily would be a nice thing (and
in a dhcp controlled world it's not too disruptive as long as you
don't go pushing the gateway address around), but best I can tell this
is what I've got right now.

Thanks,
-Jon

___
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] [ceilometer] Weekly irc meetings time change?

[Doug Hellmann]

On Fri, Sep 7, 2012 at 6:39 AM, Nick Barcet wrote:

> On 09/05/2012 11:51 AM, Nick Barcet wrote:
> > Thanks for asking, I was just about to come up with this.  So based on
> > the poll, it seems that the 3-4pm UTC time slot received the most favors
> > with 9 yes, 1 "if need be" and 1 no.  So I guess we'll have to do
> > without Angus, unless we want to do alternating meetings to satisfy both
> > sides of the planet. In the later case we could do one week at 3pm UTC,
> > and the other at 9PM.  What would the others think about this?
> >
> > In any case, the next meeting will be tomorrow at 3pm UTC.  I'll be
> > sending a formal invite later today.
>
> Based on yesterday's meeting, we decided to try alternating time. Since
> 9PM UTC is taken on thursdays, I am proposing to move it on Wednesdays.
>  If Nobody objects, this means that starting next week we'll have our
> meetings on:
>
> Wednesday at 9PM UTC for odd weeks (September 12, 26)
> Thursday at 3PM UTC for even weeks (September 20 and October 4)
>
> Does this work for everyone?
>

That time on Wednesday does not work for me. An hour earlier or later would
work, if you want to try to stay close to the same time.

I am available during the Thursday time slot.

Doug
___
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] [ceilometer] Weekly irc meetings time change?

[Angus Salkeld]

On 07/09/12 12:39 +0200, Nick Barcet wrote:

On 09/05/2012 11:51 AM, Nick Barcet wrote:

Thanks for asking, I was just about to come up with this.  So based on
the poll, it seems that the 3-4pm UTC time slot received the most favors
with 9 yes, 1 "if need be" and 1 no.  So I guess we'll have to do
without Angus, unless we want to do alternating meetings to satisfy both
sides of the planet. In the later case we could do one week at 3pm UTC,
and the other at 9PM.  What would the others think about this?

In any case, the next meeting will be tomorrow at 3pm UTC.  I'll be
sending a formal invite later today.


Based on yesterday's meeting, we decided to try alternating time. Since
9PM UTC is taken on thursdays, I am proposing to move it on Wednesdays.
If Nobody objects, this means that starting next week we'll have our
meetings on:

Wednesday at 9PM UTC for odd weeks (September 12, 26)


Cool thanks, good idea!

-Angus


Thursday at 3PM UTC for even weeks (September 20 and October 4)

Does this work for everyone?

Nick







___
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] [ceilometer] Weekly irc meetings time change?

[Nick Barcet]

On 09/05/2012 11:51 AM, Nick Barcet wrote:
> Thanks for asking, I was just about to come up with this.  So based on
> the poll, it seems that the 3-4pm UTC time slot received the most favors
> with 9 yes, 1 "if need be" and 1 no.  So I guess we'll have to do
> without Angus, unless we want to do alternating meetings to satisfy both
> sides of the planet. In the later case we could do one week at 3pm UTC,
> and the other at 9PM.  What would the others think about this?
> 
> In any case, the next meeting will be tomorrow at 3pm UTC.  I'll be
> sending a formal invite later today.

Based on yesterday's meeting, we decided to try alternating time. Since
9PM UTC is taken on thursdays, I am proposing to move it on Wednesdays.
 If Nobody objects, this means that starting next week we'll have our
meetings on:

Wednesday at 9PM UTC for odd weeks (September 12, 26)
Thursday at 3PM UTC for even weeks (September 20 and October 4)

Does this work for everyone?

Nick




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack][Nova] Help with Cloudpipe setup

[Leander Bessa Beernaert]

I'd like to add that i'm unable to ping or ssh this instance from any nodes
in my setup. Ping and ssh are working on normal instances.

On Fri, Sep 7, 2012 at 10:28 AM, Leander Bessa Beernaert <
leande...@gmail.com> wrote:

> Hello,
>
> I've been trying to set up cloud pipe for OpenStack. I'm running OpenStack
> Essex on Ubuntu 12.04 with the default packages.
> I'm following the instructions from [1,2].
>
> When i get to the part of generating certificates to connect to the
> cloudpipe instance i get this error [3].
>
> Any ideas?
>
> [1] http://docs.openstack.org/developer/nova/devref/cloudpipe.html
> [2]
> http://docs.openstack.org/essex/openstack-compute/admin/content/cloudpipe-per-project-vpns.html
> [3] http://paste.openstack.org/show/20735/
>
> --
> Cumprimentos / Regards,
> Leander
>



-- 
Cumprimentos / Regards,
Leander
___
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] [OpenStack][Nova] Help with Cloudpipe setup

[Leander Bessa Beernaert]

Hello,

I've been trying to set up cloud pipe for OpenStack. I'm running OpenStack
Essex on Ubuntu 12.04 with the default packages.
I'm following the instructions from [1,2].

When i get to the part of generating certificates to connect to the
cloudpipe instance i get this error [3].

Any ideas?

[1] http://docs.openstack.org/developer/nova/devref/cloudpipe.html
[2]
http://docs.openstack.org/essex/openstack-compute/admin/content/cloudpipe-per-project-vpns.html
[3] http://paste.openstack.org/show/20735/

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