date:20120503

Hi,


As I told you, I have also a problem for instance IP assignement.


My architecture :

I use Quantum with OVS plugin on 2 servers Essex-1  Essex-2. Essex-1
runs all services and Essex-2 runs OVS, Quantum-agent  nova-compute
only.

You can see more details here.

My configurations files are here and in my documentation.



Problem Description :

When an instance is created in ESSEX-1, all is working (network).

But when the VM is started on ESSEX-2, it does not get an IP address.
(log file)

I'm sure the problem comes from OVS connection with ESSEX-1.


Do I need to configure something like a trunk or a tunnel between
Essex-1  Essex-2 ?

I miss something in my configuration, if you have any idea...


Regards


Emilien


Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a écrit :
 It may help if you can share the log of your launched instance as
 well. There is a possibility that we both are having the same issue. 
 Netstack developers can give a definitive answer to this, but it would
 be interesting to learn what goes wrong with a launched instance.
 
 Salman
 
 
 
 
 
 
 __
 Subject: RE: [Openstack] Instance IP assignment problem
 From: emilien.openst...@gmail.com
 To: salma...@live.com
 CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net
 Date: Tue, 1 May 2012 21:26:26 +0200
 
 Le mardi 01 mai 2012 à 14:22 -0500, Salman Malik a écrit : 
 
 Regarding L3 gateway, I believe its not necessary to have one
 (as the VM hasn't obtained an IP right now, so it can't talk
 to anything outside its net), but I am not sure.
 Regarding your problem, do you see any DHCP responses from the
 DHCP server ? I am asking this because I was having a similar
 problem earlier where I was getting assigned an IP address no
 in my desired fixed_network and I believe that was cause by
 another interfering DHCP server that was replying to discover
 messages before the nova-network could. 
 
 
 Here my nova.conf and I don't have any interfering DHCP server :
 
 https://github.com/EmilienM/doc-openstack/blob/master/Configuration%
 20Files/Essex-1/nova.conf
 
 
 Thanks
 
 
 Salman
 
 
 
 
 __
 
 Subject: RE: [Openstack] Instance IP assignment problem
 From: emilien.openst...@gmail.com
 To: salma...@live.com
 CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net
 Date: Tue, 1 May 2012 21:06:01 +0200
 
 Hi Salman,
 
 
 I'm thinking about a networking issue. Where is your L3
 gateway in this architecture ? Maybe do you need an ip helper
 tool to redirect DHCP broadcast ?
 
 
 What do you think about my problem (follow up to my last
 e-mail) ?
 
 
 Thanks
 
 
 Emilien
 
 Le mardi 01 mai 2012 à 14:00 -0500, Salman Malik a écrit : 
 
 Hi,
 
 Here is the error log: http://pastebin.com/KrNZDrvD
 and nova.conf: http://pastebin.com/Fvd6dSZs
 
 Emilien, I am trying to get an understanding of how
 different Quantum plugins work with OpenStack. Ryu
 plugin is particularly interesting as it uses an
 OpenFlow controller to configure Vswitches.
 
 The problem I am faced with is  (I think ) that I
 already have a private network and Quantum should
 assign IP addresses to instances using DHCP. But
 instances send out discover message on laucnh but
 never find a DHCP server (although there are 2
 dnsmasqs running). 
 
 Any ideas?
 
 Thanks,
 Salman
 
 
 
 
 __
 
 
 Date: Tue, 1 May 2012 20:43:44 +0200
 Subject: Re: [Openstack] Instance IP assignment
 problem
 From: jorge.delac...@stackops.com
 To: emilien.openst...@gmail.com
 CC: openstack@lists.launchpad.net; salma...@live.com
 
 Hi Emilien and Salman,
 Please, could you upload all the files, errors and
 conf in pastebin or something like that? 
 I have troubles to open in phone :)
 Thank you
 El 01/05/2012 20:39, Emilien Macchi
 emilien.openst...@gmail.com escribió:
 
 Hi,

Re: [Openstack] Instance IP assignment problem

Fixed IP or Floating IP ?

From: emilien.openst...@gmail.com
To: salma...@live.com
Date: Thu, 3 May 2012 09:55:31 +0200
CC: openstack@lists.launchpad.net
Subject: Re: [Openstack] Instance IP assignment problem

Hi,

As I told you, I have also a problem for instance IP assignement.

My architecture :

I use Quantum with OVS plugin on 2 servers Essex-1  Essex-2. Essex-1 runs all 
services and Essex-2 runs OVS, Quantum-agent  nova-compute only.

You can see more details here.

My configurations files are here and in my documentation.

Problem Description :

When an instance is created in ESSEX-1, all is working (network).

But when the VM is started on ESSEX-2, it does not get an IP address. (log file)

I'm sure the problem comes from OVS connection with ESSEX-1.

Do I need to configure something like a trunk or a tunnel between Essex-1  
Essex-2 ?

I miss something in my configuration, if you have any idea...

Regards

Emilien

Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a écrit :

It may help if you can share the log of your launched instance as well. 
There is a possibility that we both are having the same issue. 

Netstack developers can give a definitive answer to this, but it would be 
interesting to learn what goes wrong with a launched instance.

Salman

Subject: RE: [Openstack] Instance IP assignment problem

From: emilien.openst...@gmail.com

To: salma...@live.com

CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net

Date: Tue, 1 May 2012 21:26:26 +0200

Le mardi 01 mai 2012 à 14:22 -0500, Salman Malik a écrit : 

Regarding L3 gateway, I believe its not necessary to have one (as the 
VM hasn't obtained an IP right now, so it can't talk to anything outside its 
net), but I am not sure.

Regarding your problem, do you see any DHCP responses from the DHCP 
server ? I am asking this because I was having a similar problem earlier where 
I was getting assigned an IP address no in my desired fixed_network and I 
believe that was cause by another interfering DHCP server that was replying to 
discover messages before the nova-network could. 

Here my nova.conf and I don't have any interfering DHCP server :

https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf

Thanks

Salman

Subject: RE: [Openstack] Instance IP assignment problem

From: emilien.openst...@gmail.com

To: salma...@live.com

CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net

Date: Tue, 1 May 2012 21:06:01 +0200

Hi Salman,

I'm thinking about a networking issue. Where is your L3 gateway in this 
architecture ? Maybe do you need an ip helper tool to redirect DHCP broadcast ?

What do you think about my problem (follow up to my last e-mail) ?

Thanks

Emilien

Le mardi 01 mai 2012 à 14:00 -0500, Salman Malik a écrit : 

Hi,

Here is the error log: http://pastebin.com/KrNZDrvD

and nova.conf: http://pastebin.com/Fvd6dSZs

Emilien, I am trying to get an understanding of how different 
Quantum plugins work with OpenStack. Ryu plugin is particularly interesting as 
it uses an OpenFlow controller to configure Vswitches.

The problem I am faced with is  (I think ) that I already have a 
private network and Quantum should assign IP addresses to instances using DHCP. 
But instances send out discover message on laucnh but never find a DHCP server 
(although there are 2 dnsmasqs running). 

Any ideas?

Thanks,

Salman

Date: Tue, 1 May 2012 20:43:44 +0200

Subject: Re: [Openstack] Instance IP assignment problem

From: jorge.delac...@stackops.com

To: emilien.openst...@gmail.com

CC: openstack@lists.launchpad.net; salma...@live.com

Hi Emilien and Salman,

Please, could you upload all the files, errors and conf in pastebin 
or something like that? 

I have troubles to open in phone :)

Thank you

El 01/05/2012 20:39, Emilien Macchi emilien.openst...@gmail.com 
escribió:

Hi,

I have a similar problem when I create a network per project_id 
with Quantum.

My VMs don't get IP and I can't understand why today.

Re: [Openstack] Instance IP assignment problem

Fixed IP



Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit :
 Fixed IP or Floating IP ?
 
 
 
 
 
 __
 From: emilien.openst...@gmail.com
 To: salma...@live.com
 Date: Thu, 3 May 2012 09:55:31 +0200
 CC: openstack@lists.launchpad.net
 Subject: Re: [Openstack] Instance IP assignment problem
 
 Hi,
 
 
 As I told you, I have also a problem for instance IP assignement.
 
 
 My architecture :
 
 I use Quantum with OVS plugin on 2 servers Essex-1  Essex-2. Essex-1
 runs all services and Essex-2 runs OVS, Quantum-agent  nova-compute
 only.
 
 You can see more details here.
 
 My configurations files are here and in my documentation.
 
 
 
 Problem Description :
 
 When an instance is created in ESSEX-1, all is working (network).
 
 But when the VM is started on ESSEX-2, it does not get an IP address.
 (log file)
 
 I'm sure the problem comes from OVS connection with ESSEX-1.
 
 
 Do I need to configure something like a trunk or a tunnel between
 Essex-1  Essex-2 ?
 
 I miss something in my configuration, if you have any idea...
 
 
 Regards
 
 
 Emilien
 
 
 Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a écrit : 
 
 It may help if you can share the log of your launched instance
 as well. There is a possibility that we both are having the
 same issue. 
 Netstack developers can give a definitive answer to this, but
 it would be interesting to learn what goes wrong with a
 launched instance.
 
 Salman
 
 
 
 
 __
 
 Subject: RE: [Openstack] Instance IP assignment problem
 From: emilien.openst...@gmail.com
 To: salma...@live.com
 CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net
 Date: Tue, 1 May 2012 21:26:26 +0200
 
 Le mardi 01 mai 2012 à 14:22 -0500, Salman Malik a écrit : 
 
 Regarding L3 gateway, I believe its not necessary to
 have one (as the VM hasn't obtained an IP right now,
 so it can't talk to anything outside its net), but I
 am not sure.
 Regarding your problem, do you see any DHCP responses
 from the DHCP server ? I am asking this because I was
 having a similar problem earlier where I was getting
 assigned an IP address no in my desired fixed_network
 and I believe that was cause by another interfering
 DHCP server that was replying to discover messages
 before the nova-network could. 
 
 
 Here my nova.conf and I don't have any interfering DHCP
 server :
 
 
 https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf
 
 
 Thanks
 
 
 Salman
 
 
 
 
 __
 
 
 Subject: RE: [Openstack] Instance IP assignment
 problem
 From: emilien.openst...@gmail.com
 To: salma...@live.com
 CC: jorge.delac...@stackops.com;
 openstack@lists.launchpad.net
 Date: Tue, 1 May 2012 21:06:01 +0200
 
 Hi Salman,
 
 
 I'm thinking about a networking issue. Where is your
 L3 gateway in this architecture ? Maybe do you need an
 ip helper tool to redirect DHCP broadcast ?
 
 
 What do you think about my problem (follow up to my
 last e-mail) ?
 
 
 Thanks
 
 
 Emilien
 
 Le mardi 01 mai 2012 à 14:00 -0500, Salman Malik a
 écrit : 
 
 Hi,
 
 Here is the error log:
 http://pastebin.com/KrNZDrvD
 and nova.conf: http://pastebin.com/Fvd6dSZs
 
 Emilien, I am trying to get an understanding
 of how different Quantum plugins work with
 OpenStack. Ryu plugin is particularly
 interesting as it uses an OpenFlow controller
 to configure Vswitches.
 
 The problem I am faced with is  (I think )
 that I already have a private network and
 Quantum

Re: [Openstack] Backporting test fixes

Hi,

On Wed, 2012-05-02 at 14:37 +0200, Ionuț Arțăriși wrote:
 I recently submitted a few fixes to the test suite in various components
 of openstack.

Thanks for that!


 These fixes are being merged in master, but the code remains broken in
 the stable/essex branch. Review requests for  stable/essex either get
 rejected or stuck in limbo because it seems that people don't know
 what to do about them.

We're talking about this?

  https://review.openstack.org/#/c/6619/

The issue here is that Swift is different :)

Swift's releases are intended to be stable updates and AFAIK the Swift
team feels that they don't need to do separate stable update releases.
So the stable branch process we've put in place for the other projects
doesn't apply to Swift.

I've added a note to the wiki page about this.

 I am aware of the procedure for backporting fixes[1], but I think it
 does not deal with this issue correctly.
 
 Fixes to test scripts are for our benefit, the developers'. They don't
 affect the users in any way. I don't think test code should be thrown
 together with application code when thinking about making changes to
 it.
 
 Only making test changes to the master branches reflects a belief that
 tests are only used during development. I don't think this is
 true. Tests, especially functional tests, are also incredibly useful
 during maintenance. e.g. They help us test against different library
 versions/distro than the one that's used for development and using
 different deployment configurations.
 
 I suspect we're not the only downstream running the various testsuites
 against their own packaged versions of different openstack
 branches. Backporting these changes not only spares the time of other
 projects who might run into these bugs on the stable branches later, it
 also gives all of us the benefit of not having to fork the project just
 so we can attach our patches. OTOH blocking test backports removes the
 incentive that downstream projects have for reporting those bugs and
 sending fixes for them upstream.
 
 So can we talk about separating the tests from the application code at
 least as far as the backports are concerned? What about having the 
 'test/' directory as a git submodule?
 
 Or maybe I don't understand this problem enough. What are the downsides
 to backporting test-only fixes? Do they really outweigh the advantages?

I think you've misinterpreted the response to your review so I won't go
into the specifics of your points, but here's how I think about the
backporting of unit tests:

  - Unit test's main value IMHO is preventing regressions during 
development.

Adding new unit tests can occasionally find new bugs too but, if I 
want to find bugs on a stable branch, it would be functional tests 
I'd write.

  - As such, I don't think a concerted effort across the project to 
systematically backport unit tests from master to the stable branch 
is time well spent.

However, anyone is welcome to maintain their own tree based off the 
stable branch and use that as a venue for finding bugs with new 
unit tests. I'd hope those tests would go into master first, though.

  - Also, a worthwhile goal on a stable branch is to keep churn to a 
minimum. You could argue that tests deserve a free pass because 
changes to those can't introduce regressions but, when it comes to 
a stable branch, I'm sceptical that any patch is zero risk never 
mind a whole class of (generally quite large) patches.

Part of keeping churn to a minimum on a stable branch is that 
reviewers default answer should be no. Unless a patch meets the 
safe fix for a high-impact, user-visible issue then it doesn't 
belong in the stable branch.

  - That said, if someone adds a new test to master and it uncovers a 
significant user-visible bug (or uncovers a bug and adds a test for 
it), then I think it makes sense to backport the unit test to master
along with the bug fix. It helps verify that the backported patch
does fix the bug.

  - And finally, I think it's sane for downstreams to run the unit 
tests. As you say, it can catch issues where downstream is using a 
different version of a library than upstream. If a downstream 
uncovers an issue like this, fixes it on master with a unit test 
and backports the fix and unit test to stable, I think that's great 
too.

Hope that clears things up?

Cheers,
Mark.


___
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] Instance IP assignment problem

Then the problem isn't in the instance but in the nova-network service , please 
check if it is working well as well as give us the output log when you attempt 
to create a new instance.

Subject: RE: [Openstack] Instance IP assignment problem
From: emilien.openst...@gmail.com
To: ski...@hotmail.fr
CC: salma...@live.com; openstack@lists.launchpad.net
Date: Thu, 3 May 2012 10:21:37 +0200

Fixed IP

Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit :

Fixed IP or Floating IP ?

From: emilien.openst...@gmail.com

To: salma...@live.com

Date: Thu, 3 May 2012 09:55:31 +0200

CC: openstack@lists.launchpad.net

Subject: Re: [Openstack] Instance IP assignment problem

Hi,

As I told you, I have also a problem for instance IP assignement.

My architecture :

I use Quantum with OVS plugin on 2 servers Essex-1  Essex-2. Essex-1 runs 
all services and Essex-2 runs OVS, Quantum-agent  nova-compute only.

You can see more details here.

My configurations files are here and in my documentation.

Problem Description :

When an instance is created in ESSEX-1, all is working (network).

But when the VM is started on ESSEX-2, it does not get an IP address. (log 
file)

I'm sure the problem comes from OVS connection with ESSEX-1.

Do I need to configure something like a trunk or a tunnel between Essex-1  
Essex-2 ?

I miss something in my configuration, if you have any idea...

Regards

Emilien

Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a écrit : 

It may help if you can share the log of your launched instance as well. 
There is a possibility that we both are having the same issue. 

Netstack developers can give a definitive answer to this, but it would 
be interesting to learn what goes wrong with a launched instance.

Salman

Subject: RE: [Openstack] Instance IP assignment problem

From: emilien.openst...@gmail.com

To: salma...@live.com

CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net

Date: Tue, 1 May 2012 21:26:26 +0200

Le mardi 01 mai 2012 à 14:22 -0500, Salman Malik a écrit : 

Regarding L3 gateway, I believe its not necessary to have one (as 
the VM hasn't obtained an IP right now, so it can't talk to anything outside 
its net), but I am not sure.

Regarding your problem, do you see any DHCP responses from the DHCP 
server ? I am asking this because I was having a similar problem earlier where 
I was getting assigned an IP address no in my desired fixed_network and I 
believe that was cause by another interfering DHCP server that was replying to 
discover messages before the nova-network could. 

Here my nova.conf and I don't have any interfering DHCP server :

https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf

Thanks

Salman

Subject: RE: [Openstack] Instance IP assignment problem

From: emilien.openst...@gmail.com

To: salma...@live.com

CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net

Date: Tue, 1 May 2012 21:06:01 +0200

Hi Salman,

I'm thinking about a networking issue. Where is your L3 gateway in 
this architecture ? Maybe do you need an ip helper tool to redirect DHCP 
broadcast ?

What do you think about my problem (follow up to my last e-mail) ?

Thanks

Emilien

Le mardi 01 mai 2012 à 14:00 -0500, Salman Malik a écrit : 

Hi,

Here is the error log: http://pastebin.com/KrNZDrvD

and nova.conf: http://pastebin.com/Fvd6dSZs

Emilien, I am trying to get an understanding of how different 
Quantum plugins work with OpenStack. Ryu plugin is particularly interesting as 
it uses an OpenFlow controller to configure Vswitches.

The problem I am faced with is  (I think ) that I already have 
a private network and Quantum should assign IP addresses to instances using 
DHCP. But instances send out discover message on laucnh but never find a DHCP 
server (although there are 2 dnsmasqs running). 

Any ideas?

Thanks,

Re: [Openstack] Energy efficiency

2012-05-03 Thread Yuriy Taraday

Just note that since Essex release Nova by default use fill-first cost
function, meaning that nodes with less free RAM will be preferred for
new instances.

Kind regards, Yuriy.


On Sun, Apr 29, 2012 at 8:28 PM, Szymon Grzybowski semy...@gmail.com wrote:
 Hi,

 Me and my colleague are doing research about openstack and energy efficiency
 during part of our master thesis about cloud computing. And mayby we would
 like to write something inside nova-scheduler to dynamically manage vms from
 cloud administrator's point of view. the general idea is to automate process
 of vm migration to suite current policy. For example, we have 10 servers in
 cloud with nova-compute, each is capable of running 5 vm. I'd like to run 20
 vms. Aaccording to current nova-scheduler (filters), each server will run 2
 VMs, but it would be cheaper (this is policy defined by administrator) if we
 run all of them on just 4 servers. of course, cloud has to keep proper QoS
 rate (response time etc.). This is general idea.

 Energy efficiency is really popular topic, when we talk about
 servers,datacenters and virtualization, but I can't find any papers about it
 in context of openstack. Are there any projects doing such researches or
 articles? in fact it would be really surprising if there is nothing about
 energy efficiency in context of openstack.

 Cheers,


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


___
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] Instance IP assignment problem

All seems alright but not working yet.


http://paste.openstack.org/show/14791/



I have executed on both servers :

ovs-vsctl add-port br-int eth1


Need I do something else ?

How the DHCP is working in this case ?






Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit :
 Then the problem isn't in the instance but in the nova-network
 service , please check if it is working well 
 
 as well as give us the output log when you attempt to create a new
 instance.
 
 
 
 
 
 __
 Subject: RE: [Openstack] Instance IP assignment problem
 From: emilien.openst...@gmail.com
 To: ski...@hotmail.fr
 CC: salma...@live.com; openstack@lists.launchpad.net
 Date: Thu, 3 May 2012 10:21:37 +0200
 
 Fixed IP
 
 
 
 Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit : 
 
 Fixed IP or Floating IP ?
 
 
 
 __
 
 From: emilien.openst...@gmail.com
 To: salma...@live.com
 Date: Thu, 3 May 2012 09:55:31 +0200
 CC: openstack@lists.launchpad.net
 Subject: Re: [Openstack] Instance IP assignment problem
 
 Hi,
 
 
 As I told you, I have also a problem for instance IP
 assignement.
 
 
 My architecture :
 
 I use Quantum with OVS plugin on 2 servers Essex-1  Essex-2.
 Essex-1 runs all services and Essex-2 runs OVS, Quantum-agent
  nova-compute only.
 
 You can see more details here.
 
 My configurations files are here and in my documentation.
 
 
 
 Problem Description :
 
 When an instance is created in ESSEX-1, all is working
 (network).
 
 But when the VM is started on ESSEX-2, it does not get an IP
 address. (log file)
 
 I'm sure the problem comes from OVS connection with ESSEX-1.
 
 
 Do I need to configure something like a trunk or a tunnel
 between Essex-1  Essex-2 ?
 
 I miss something in my configuration, if you have any idea...
 
 
 Regards
 
 
 Emilien
 
 
 Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a écrit : 
 
 It may help if you can share the log of your launched
 instance as well. There is a possibility that we both
 are having the same issue. 
 Netstack developers can give a definitive answer to
 this, but it would be interesting to learn what goes
 wrong with a launched instance.
 
 Salman
 
 
 
 
 __
 
 
 Subject: RE: [Openstack] Instance IP assignment
 problem
 From: emilien.openst...@gmail.com
 To: salma...@live.com
 CC: jorge.delac...@stackops.com;
 openstack@lists.launchpad.net
 Date: Tue, 1 May 2012 21:26:26 +0200
 
 Le mardi 01 mai 2012 à 14:22 -0500, Salman Malik a
 écrit : 
 
 Regarding L3 gateway, I believe its not
 necessary to have one (as the VM hasn't
 obtained an IP right now, so it can't talk to
 anything outside its net), but I am not sure.
 Regarding your problem, do you see any DHCP
 responses from the DHCP server ? I am asking
 this because I was having a similar problem
 earlier where I was getting assigned an IP
 address no in my desired fixed_network and I
 believe that was cause by another interfering
 DHCP server that was replying to discover
 messages before the nova-network could. 
 
 
 Here my nova.conf and I don't have any interfering
 DHCP server :
 
 
 https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf
 
 
 Thanks
 
 
 Salman
 
 
 
 
 __
 
 
 
 Subject: RE:

Re: [Openstack] Backporting test fixes

2012-05-03 Thread Ionuț Arțăriși


Hi Mark, thanks for your answer.

On 05/03/2012 10:25 AM, Mark McLoughlin wrote:

Hi,

On Wed, 2012-05-02 at 14:37 +0200, Ionuț Arțăriși wrote:

I recently submitted a few fixes to the test suite in various components
of openstack.


Thanks for that!



These fixes are being merged in master, but the code remains broken in
the stable/essex branch. Review requests for  stable/essex either get
rejected or stuck in limbo because it seems that people don't know
what to do about them.


We're talking about this?

   https://review.openstack.org/#/c/6619/



and this: https://bugs.launchpad.net/keystone/+bug/983800/ (comment #2)



The issue here is that Swift is different :)

Swift's releases are intended to be stable updates and AFAIK the Swift
team feels that they don't need to do separate stable update releases.
So the stable branch process we've put in place for the other projects
doesn't apply to Swift.

I've added a note to the wiki page about this.



Ok, good to know. Thanks.


I am aware of the procedure for backporting fixes[1], but I think it
does not deal with this issue correctly.

Fixes to test scripts are for our benefit, the developers'. They don't
affect the users in any way. I don't think test code should be thrown
together with application code when thinking about making changes to
it.

Only making test changes to the master branches reflects a belief that
tests are only used during development. I don't think this is
true. Tests, especially functional tests, are also incredibly useful
during maintenance. e.g. They help us test against different library
versions/distro than the one that's used for development and using
different deployment configurations.

I suspect we're not the only downstream running the various testsuites
against their own packaged versions of different openstack
branches. Backporting these changes not only spares the time of other
projects who might run into these bugs on the stable branches later, it
also gives all of us the benefit of not having to fork the project just
so we can attach our patches. OTOH blocking test backports removes the
incentive that downstream projects have for reporting those bugs and
sending fixes for them upstream.

So can we talk about separating the tests from the application code at
least as far as the backports are concerned? What about having the
'test/' directory as a git submodule?

Or maybe I don't understand this problem enough. What are the downsides
to backporting test-only fixes? Do they really outweigh the advantages?


I think you've misinterpreted the response to your review so I won't go
into the specifics of your points, but here's how I think about the
backporting of unit tests:

   - Unit test's main value IMHO is preventing regressions during
 development.

 Adding new unit tests can occasionally find new bugs too but, if I
 want to find bugs on a stable branch, it would be functional tests
 I'd write.

   - As such, I don't think a concerted effort across the project to
 systematically backport unit tests from master to the stable branch
 is time well spent.


I'm not advocating that someone spend time to look through all the 
patches to unittests in master and backport them to stable. What I'm 
asking for is that when someone submits a test fix backport it would be 
*accepted* in a stable branch after the proper review process.




 However, anyone is welcome to maintain their own tree based off the
 stable branch and use that as a venue for finding bugs with new
 unit tests. I'd hope those tests would go into master first, though.

   - Also, a worthwhile goal on a stable branch is to keep churn to a
 minimum. You could argue that tests deserve a free pass because
 changes to those can't introduce regressions but, when it comes to
 a stable branch, I'm sceptical that any patch is zero risk never
 mind a whole class of (generally quite large) patches.



I think you're again talking about backporting all test fixes here in 
bulk. But apart from that, I don't really see how testsuite-only patches 
which go through the same review process as normal patches can break 
anything in application code and be deemed risky?




 Part of keeping churn to a minimum on a stable branch is that
 reviewers default answer should be no. Unless a patch meets the
 safe fix for a high-impact, user-visible issue then it doesn't
 belong in the stable branch.

   - That said, if someone adds a new test to master and it uncovers a
 significant user-visible bug (or uncovers a bug and adds a test for
 it), then I think it makes sense to backport the unit test to master
 along with the bug fix. It helps verify that the backported patch
 does fix the bug.

   - And finally, I think it's sane for downstreams to run the unit
 tests. As you say, it can catch issues where downstream is using a
 different version of a library than upstream. If a downstream

Re: [Openstack] Openstack Essex - Guide for Ubuntu 12.04

2012-05-03 Thread Shake Chen

Hi Emilien

I have some question about document. please correct me if wrong.

1: nova-api

I found you install nova-api in both machine. but in nova.conf

--nova_url=http://10.68.1.40:8774/v1.1/

whether really need install nova-api in compute node.


2: nova-network

I found  install nova-network in both machine. but nova.conf not set

--*multi**-host*=T

also the the machine nova.conf
--routing_source_ip=10.68.1.40











On Wed, May 2, 2012 at 5:30 PM, Emilien Macchi
emilien.openst...@gmail.comwrote:

 **
 HI Edgar,


 Thank's !


 Yes,as you can read in the doc, it will evoluate in the future.

 Maybe someone will do it before me, the documentation is under a free
 license, so feel free to add some features !


 Best regards



 Le mardi 01 mai 2012 à 23:52 -0700, Edgar Magana (eperdomo) a écrit :

 Hi Emilien,



 Good document in general, any plans to add swift here?



 Thanks,



 Edgar Magana



  *From:* openstack-bounces+eperdomo=cisco@lists.launchpad.net [mailto:
 openstack-bounces+eperdomo=cisco@lists.launchpad.net] *On Behalf Of 
 *Emilien
 Macchi
 *Sent:* Monday, April 30, 2012 12:42 AM
 *To:* openstack@lists.launchpad.net
 *Subject:* [Openstack] Openstack Essex - Guide for Ubuntu 12.04




 Hi,

 I release my first documentation on OpenStack Essex for Ubuntu 12.04.

 I've been working for three weeks with StackOps for my internship, and my
 work is focused ont Quantum (Networking as a service in OpenStack).


 It was quite difficult to have a working infrastructure because Quantum is
 only in incubation for Essex release. That's why I publish a
 documentation in which anyone can test this fabulous software.

 You can find this documentation in attachment and 
 herehttps://github.com/EmilienM/doc-openstackwith all configuration files  
 scripts.


 *Please let me know if I did some mistakes, and of course I will do by
 best tocorrect it.*


 Best regards

   --
 *Emilien Macchi*
 Phone : +33 685 117 748
 Skype : memilien69
 Twitter : EmilienMacchi https://twitter.com/
 Website : http://my1.fr








 ___
 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

Re: [Openstack] Instance IP assignment problem

èmm , can you do this on your instance : nova show %instance_Id so that i may 
see the problem in the resume of spawning ?and are you sure you have enough 
fixed ip addresses left for use ?

The configuration of nova and quantum is almost the same as me and the 
instances are getting Fixed Ips without any problem !
Subject: RE: [Openstack] Instance IP assignment problem
From: emilien.openst...@gmail.com
To: ski...@hotmail.fr
CC: salma...@live.com; openstack@lists.launchpad.net
Date: Thu, 3 May 2012 10:48:43 +0200

All seems alright but not working yet.

http://paste.openstack.org/show/14791/

I have executed on both servers :

ovs-vsctl add-port br-int eth1

Need I do something else ?

How the DHCP is working in this case ?

Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit :

Then the problem isn't in the instance but in the nova-network service , 
please check if it is working well 

as well as give us the output log when you attempt to create a new instance.

Subject: RE: [Openstack] Instance IP assignment problem

From: emilien.openst...@gmail.com

To: ski...@hotmail.fr

CC: salma...@live.com; openstack@lists.launchpad.net

Date: Thu, 3 May 2012 10:21:37 +0200

Fixed IP

Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit : 

Fixed IP or Floating IP ?

From: emilien.openst...@gmail.com

To: salma...@live.com

Date: Thu, 3 May 2012 09:55:31 +0200

CC: openstack@lists.launchpad.net

Subject: Re: [Openstack] Instance IP assignment problem

Hi,

As I told you, I have also a problem for instance IP assignement.

My architecture :

I use Quantum with OVS plugin on 2 servers Essex-1  Essex-2. Essex-1 
runs all services and Essex-2 runs OVS, Quantum-agent  nova-compute only.

You can see more details here.

My configurations files are here and in my documentation.

Problem Description :

When an instance is created in ESSEX-1, all is working (network).

But when the VM is started on ESSEX-2, it does not get an IP address. 
(log file)

I'm sure the problem comes from OVS connection with ESSEX-1.

Do I need to configure something like a trunk or a tunnel between 
Essex-1  Essex-2 ?

I miss something in my configuration, if you have any idea...

Regards

Emilien

Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a écrit : 

It may help if you can share the log of your launched instance as 
well. There is a possibility that we both are having the same issue. 

Netstack developers can give a definitive answer to this, but it 
would be interesting to learn what goes wrong with a launched instance.

Salman

Subject: RE: [Openstack] Instance IP assignment problem

From: emilien.openst...@gmail.com

To: salma...@live.com

CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net

Date: Tue, 1 May 2012 21:26:26 +0200

Le mardi 01 mai 2012 à 14:22 -0500, Salman Malik a écrit : 

Regarding L3 gateway, I believe its not necessary to have one 
(as the VM hasn't obtained an IP right now, so it can't talk to anything 
outside its net), but I am not sure.

Regarding your problem, do you see any DHCP responses from the 
DHCP server ? I am asking this because I was having a similar problem earlier 
where I was getting assigned an IP address no in my desired fixed_network and I 
believe that was cause by another interfering DHCP server that was replying to 
discover messages before the nova-network could. 

Here my nova.conf and I don't have any interfering DHCP server :

https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf

Thanks

Salman

Subject: RE: [Openstack] Instance IP assignment problem

From: emilien.openst...@gmail.com

To: salma...@live.com

CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net

Date: Tue, 1 May 2012 21:06:01 +0200

Re: [Openstack] Instance IP assignment problem

Ok :

http://paste.openstack.org/show/14797/


I know where is the problem but I dont know yet how to fix it :


- Quantum creates TAP interface on ESSEX-2

- From ESSEX-2, I can't ping VMs on ESSEX-1


Here my ovs_quantum_plugin.ini :

[DATABASE]
sql_connection =
mysql://ovs_quantum:password@10.68.1.40:3306/ovs_quantum


[OVS]
integration-bridge = br-int


[AGENT]
root_helper = sudo



Do we need enable bridge ?




Le jeudi 03 mai 2012 à 10:00 +0100, Bilel Msekni a écrit :
 èmm , can you do this on your instance : nova show %instance_Id so
 that i may see the problem in the resume of spawning ?
 
 and are you sure you have enough fixed ip addresses left for use ?
 
 The configuration of nova and quantum is almost the same as me and the
 instances are getting Fixed Ips without any problem !
 
 
 
 
 __
 Subject: RE: [Openstack] Instance IP assignment problem
 From: emilien.openst...@gmail.com
 To: ski...@hotmail.fr
 CC: salma...@live.com; openstack@lists.launchpad.net
 Date: Thu, 3 May 2012 10:48:43 +0200
 
 All seems alright but not working yet.
 
 
 http://paste.openstack.org/show/14791/
 
 
 
 I have executed on both servers :
 
 ovs-vsctl add-port br-int eth1
 
 
 Need I do something else ?
 
 How the DHCP is working in this case ?
 
 
 
 
 
 
 Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit : 
 
 Then the problem isn't in the instance but in the nova-network
 service , please check if it is working well 
 as well as give us the output log when you attempt to create a
 new instance.
 
 
 
 __
 
 Subject: RE: [Openstack] Instance IP assignment problem
 From: emilien.openst...@gmail.com
 To: ski...@hotmail.fr
 CC: salma...@live.com; openstack@lists.launchpad.net
 Date: Thu, 3 May 2012 10:21:37 +0200
 
 Fixed IP
 
 
 
 Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit : 
 
 Fixed IP or Floating IP ?
 
 
 
 __
 
 
 From: emilien.openst...@gmail.com
 To: salma...@live.com
 Date: Thu, 3 May 2012 09:55:31 +0200
 CC: openstack@lists.launchpad.net
 Subject: Re: [Openstack] Instance IP assignment
 problem
 
 Hi,
 
 
 As I told you, I have also a problem for instance IP
 assignement.
 
 
 My architecture :
 
 I use Quantum with OVS plugin on 2 servers Essex-1 
 Essex-2. Essex-1 runs all services and Essex-2 runs
 OVS, Quantum-agent  nova-compute only.
 
 You can see more details here.
 
 My configurations files are here and in my
 documentation.
 
 
 
 Problem Description :
 
 When an instance is created in ESSEX-1, all is working
 (network).
 
 But when the VM is started on ESSEX-2, it does not get
 an IP address. (log file)
 
 I'm sure the problem comes from OVS connection with
 ESSEX-1.
 
 
 Do I need to configure something like a trunk or a
 tunnel between Essex-1  Essex-2 ?
 
 I miss something in my configuration, if you have any
 idea...
 
 
 Regards
 
 
 Emilien
 
 
 Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a
 écrit : 
 
 It may help if you can share the log of your
 launched instance as well. There is a
 possibility that we both are having the same
 issue. 
 Netstack developers can give a definitive
 answer to this, but it would be interesting to
 learn what goes wrong with a launched
 instance.
 
 Salman
 
 
 
 
 __

Re: [Openstack] Backporting test fixes

On Thu, 2012-05-03 at 10:51 +0200, Ionuț Arțăriși wrote:
 Hi Mark, thanks for your answer.
 
 On 05/03/2012 10:25 AM, Mark McLoughlin wrote:
  Hi,
 
  On Wed, 2012-05-02 at 14:37 +0200, Ionuț Arțăriși wrote:
  I recently submitted a few fixes to the test suite in various components
  of openstack.
 
  Thanks for that!
 
 
  These fixes are being merged in master, but the code remains broken in
  the stable/essex branch. Review requests for  stable/essex either get
  rejected or stuck in limbo because it seems that people don't know
  what to do about them.
 
  We're talking about this?
 
 https://review.openstack.org/#/c/6619/
 
 
 and this: https://bugs.launchpad.net/keystone/+bug/983800/ (comment #2)

Ah, ok. Thanks for bringing this one up

[..]

 - And finally, I think it's sane for downstreams to run the unit
   tests. As you say, it can catch issues where downstream is using a
   different version of a library than upstream. If a downstream
   uncovers an issue like this, fixes it on master with a unit test
   and backports the fix and unit test to stable, I think that's great
   too.
 
 Well you think it's great and I think it's great, but somehow we don't 
 agree with one another? This is what I did. Uncovered a bug in the tests 
 on a different version/configuration, submitted the fix to master - it 
 got accepted. Submitted the fix to stable - it got rejected. Or are you 
 saying that these fixes are not important because they're only testsuite 
 fixes?
 
 Finally, I'm fine with any attitude to backporting test fixes (though I 
 strongly prefer backporting them), but let's please make it deliberate 
 and clear and then document it on the wiki page. This is why I started 
 this discussion.

Cool, no problem.

Again, in this case, there are extenuating circumstances :-)

Keystone only became core in essex, so it's new to the stable branch
process and the stable-maint team haven't paid it much attention yet.
And, in any case, we're all still finding our way with the stable branch
process generally.

So ... I agree the fix for bug #983800 should go into essex. I've
commented in the bug. I'll backport it myself soon unless you get there
first.

Cheers,
Mark.


___
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 Essex - Guide for Ubuntu 12.04

Hi Shake,

Le jeudi 03 mai 2012 à 16:56 +0800, Shake Chen a écrit :

 I have some question about document. please correct me if wrong.
 
 1: nova-api
 
 I found you install nova-api in both machine. but in nova.conf
 
 --nova_url=http://10.68.1.40:8774/v1.1/
 
 whether really need install nova-api in compute node.


So can I delete nova-api from nova compute node (ESSEX-2) ?



 2: nova-network
 
 I found  install nova-network in both machine. but nova.conf not set
 
 --multi-host=T
 
 also the the machine nova.conf 
 --routing_source_ip=10.68.1.40



That's a mistake from me. I just copy/paste the files and change some
parameters.

Please tell me what I can drop from nova.conf of Essex-2.

N.B: I don't want to use multi-host because I'm using Quantum, and it's
not compatible yet for multi hosts.

Tell me if I say wrong !


Thank you for your feedback,

After your response, I'm going to correct it and update my Git.


Regards


Emilien



 
 
 
 
 
 
 
 
 On Wed, May 2, 2012 at 5:30 PM, Emilien Macchi
 emilien.openst...@gmail.com wrote:
 
 HI Edgar,
 
 
 Thank's !
 
 
 Yes,as you can read in the doc, it will evoluate in the
 future.
 
 Maybe someone will do it before me, the documentation is under
 a free license, so feel free to add some features !
 
 
 Best regards
 
 
 
 Le mardi 01 mai 2012 à 23:52 -0700, Edgar Magana (eperdomo) a
 écrit : 
 
  Hi Emilien,
  
   
  
  Good document in general, any plans to add swift here?
  
   
  
  Thanks,
  
   
  
  Edgar Magana
  
   
  
  From: openstack-bounces
  +eperdomo=cisco@lists.launchpad.net
  [mailto:openstack-bounces
  +eperdomo=cisco@lists.launchpad.net] On Behalf Of
  Emilien Macchi
  Sent: Monday, April 30, 2012 12:42 AM
  To: openstack@lists.launchpad.net
  Subject: [Openstack] Openstack Essex - Guide for Ubuntu
  12.04
  
  
   
  
  Hi,
  
  I release my first documentation on OpenStack Essex for
  Ubuntu 12.04.
  
  I've been working for three weeks with StackOps for my
  internship, and my work is focused ont Quantum (Networking
  as a service in OpenStack).
  
  
  It was quite difficult to have a working infrastructure
  because Quantum is only in incubation for Essex release.
  That's why I publish a documentation in which anyone can
  test this fabulous software.
  
  You can find this documentation in attachment and here with
  all configuration files  scripts.
  
  
  Please let me know if I did some mistakes, and of course I
  will do by best tocorrect it.
  
  
  Best regards
  
  
  
  
  
  
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IP assignment problem


Basing on your architecture picture , I think you mean ping VM that resides on 
Essex 2 from server containing Essex 1I had a similar networking problem and i 
honestly don't know i fixed it ( didn't enable tunneling) , this is what i 
did1- ifconfig eth0 0.0.0.02- dhclient br-int ( normally the bridge will take 
the address of eth0)
and pinging went back to working fine but i am still testing if there are any 
side effectsTry it out and txt me !
btw , i used your ubuntu 12.04 LTS cloud img and i can't seem to ping it but 
when i choose another image ( the default tty for example) it ping as a charm , 
probably you should pick another image !   

Subject: RE: [Openstack] Instance IP assignment problem
From: emilien.openst...@gmail.com
To: ski...@hotmail.fr
CC: openstack@lists.launchpad.net
Date: Thu, 3 May 2012 11:11:04 +0200




  
  


Ok :



http://paste.openstack.org/show/14797/





I know where is the problem but I dont know yet how to fix it :





- Quantum creates TAP interface on ESSEX-2



- From ESSEX-2, I can't ping VMs on ESSEX-1





Here my ovs_quantum_plugin.ini :



[DATABASE]

sql_connection = mysql://ovs_quantum:password@10.68.1.40:3306/ovs_quantum





[OVS]

integration-bridge = br-int





[AGENT]

root_helper = sudo







Do we need enable bridge ?









Le jeudi 03 mai 2012 à 10:00 +0100, Bilel Msekni a écrit :

èmm , can you do this on your instance : nova show %instance_Id so that i 
may see the problem in the resume of spawning ?


and are you sure you have enough fixed ip addresses left for use ?



The configuration of nova and quantum is almost the same as me and the 
instances are getting Fixed Ips without any problem !










Subject: RE: [Openstack] Instance IP assignment problem

From: emilien.openst...@gmail.com

To: ski...@hotmail.fr

CC: salma...@live.com; openstack@lists.launchpad.net

Date: Thu, 3 May 2012 10:48:43 +0200



All seems alright but not working yet.





http://paste.openstack.org/show/14791/







I have executed on both servers :



ovs-vsctl add-port br-int eth1





Need I do something else ?



How the DHCP is working in this case ?













Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit : 


Then the problem isn't in the instance but in the nova-network service 
, please check if it is working well 

as well as give us the output log when you attempt to create a new 
instance.











Subject: RE: [Openstack] Instance IP assignment problem

From: emilien.openst...@gmail.com

To: ski...@hotmail.fr

CC: salma...@live.com; openstack@lists.launchpad.net

Date: Thu, 3 May 2012 10:21:37 +0200



Fixed IP







Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit : 


Fixed IP or Floating IP ?













From: emilien.openst...@gmail.com

To: salma...@live.com

Date: Thu, 3 May 2012 09:55:31 +0200

CC: openstack@lists.launchpad.net

Subject: Re: [Openstack] Instance IP assignment problem



Hi,





As I told you, I have also a problem for instance IP assignement.





My architecture :



I use Quantum with OVS plugin on 2 servers Essex-1  Essex-2. 
Essex-1 runs all services and Essex-2 runs OVS, Quantum-agent  nova-compute 
only.



You can see more details here.



My configurations files are here and in my documentation.







Problem Description :



When an instance is created in ESSEX-1, all is working (network).



But when the VM is started on ESSEX-2, it does not get an IP 
address. (log file)



I'm sure the problem comes from OVS connection with ESSEX-1.





Do I need to configure something like a trunk or a tunnel between 
Essex-1  Essex-2 ?



I miss something in my configuration, if you have any idea...





Regards





Emilien





Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a écrit : 


It may help if you can share the log of your launched instance 
as well. There is a possibility that we both are having the same issue. 

Netstack developers can give a definitive answer to this, but 
it would be interesting to learn what goes wrong with a launched instance.



Salman

Re: [Openstack] extending rootwrap securely

2012-05-03 Thread Yuriy Taraday

We can do #includedir /etc/nova/sudoers.d from sudoers as well.
I think, a solution with a separate conf/dir for rootwrap is a step
back to sudo.

Kind regards, Yuriy.


On Wed, May 2, 2012 at 1:54 PM, Thierry Carrez thie...@openstack.org wrote:
 Andrew Bogott wrote:
     As part of the plugin framework, I'm thinking about facilities for
 adding commands to the nova-rootwrap list without directly editing the
 code in nova-rootwrap.  This is, naturally, super dangerous; I'm worried
 that I'm going to open a security hole big enough to pass a herd of
 elephants.

 It is dangerous :) I plan to work on that, with options being audited in
 the open like I did for the original implementation. So far I stayed
 away from using a configuration file (or .d directory) for
 nova-rootwrap, so that only the module loading path had to be secured
 (it has to anyway).

     It doesn't help that I mostly know about devstack, and don't know a
 whole lot about the variety of ways that Nova is installed on actual
 production systems.  So, my questions:

 a)  Is the nova code on a production system generally owned by root and
 read-only?  (If the answer to this one is ever 'no' then we're done,
 because we're already 100% insecure.)

 yes

 b)  Does nova usually run as root user?  (Again, thinking 'no' because
 otherwise we wouldn't need a rootwrap tool in the first place.)

 no

 c)  Who generally has rights to modify nova.conf and/or add command-line
 args to the nova launch?  (I want the answer to this to be 'just root'
 but I fear the answer is 'both root and the nova user.')

 depends on the distribution, though I suspect most of them would make
 nova.conf root-only.

 The security model of the current system is completely external to
 nova.conf: the sudoers file allows to the nova user to run
 /usr/bin/nova-rootwrap as root with a cleaned-up PATH, which does Python
 module loading from safe directories. No config file is loaded. So the
 sudoers file is the key to securing the model.

 The crux: If additional commands can be added to rootwrap via nova.conf
 or the commandline, does that open security holes that aren't already
 open?  Such a facility will give root to anyone who can modify the
 nova.conf or the nova commandline.  So, if the nova user can modify the
 commandline, the question is:  did the nova user /already/ have root
 access?

 One option is to use a separate /etc/nova/nova-rootwrap.conf that would
 be root-writeable (or more likely a /etc/nova/rootwrap.d directory). But
 then we probably have to hardcode the config file location.

 --
 Thierry Carrez (ttx)
 Release Manager, OpenStack

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

___
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] Instance IP assignment problem

2012-05-03 Thread Anton Haldin

can you find dhcp requests by using tcpdump for example ?

sorry for off-topic but there may be many reasons of such issue with
dhcp. last one for me was old dhcp client(Ubuntu) and udp checksum error. I
have essex on centos and was trying ubuntu vm.

On Thu, May 3, 2012 at 12:48 PM, Emilien Macchi emilien.openst...@gmail.com
wrote:

**
All seems alright but not working yet.

http://paste.openstack.org/show/14791/

I have executed on both servers :

ovs-vsctl add-port br-int eth1

Need I do something else ?

How the DHCP is working in this case ?

Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit :

Then the problem isn't in the instance but in the nova-network service ,
please check if it is working well

as well as give us the output log when you attempt to create a new
instance.

Subject: RE: [Openstack] Instance IP assignment problem
From: emilien.openst...@gmail.com
To: ski...@hotmail.fr
CC: salma...@live.com; openstack@lists.launchpad.net
Date: Thu, 3 May 2012 10:21:37 +0200

Fixed IP

Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit :

Fixed IP or Floating IP ?

From: emilien.openst...@gmail.com
To: salma...@live.com
Date: Thu, 3 May 2012 09:55:31 +0200
CC: openstack@lists.launchpad.net
Subject: Re: [Openstack] Instance IP assignment problem

Hi,

As I told you, I have also a problem for instance IP assignement.

*My architecture :*

I use *Quantum* with *OVS plugin* on 2 servers Essex-1 Essex-2. Essex-1
runs all services and Essex-2 runs OVS, Quantum-agent nova-compute only.

You can see more details
herehttps://github.com/EmilienM/doc-openstack/blob/master/Documentation/How%20to%20setup%20OpenStack%20Essex.pdf
.

My configurations files are
herehttps://github.com/EmilienM/doc-openstack/tree/master/Configuration%20Filesand
in my documentation.

*Problem Description :*

When an instance is created in ESSEX-1, all is working (network).

But when the VM is started on ESSEX-2, it does not get an IP address. (log
file http://paste.openstack.org/show/14775/)

I'm sure the problem comes from OVS connection with ESSEX-1.

Do I need to configure something like a trunk or a tunnel between Essex-1
Essex-2 ?

I miss something in my configuration, if you have any idea...

Regards

Emilien

Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a écrit :

It may help if you can share the log of your launched instance as well.
There is a possibility that we both are having the same issue.
Netstack developers can give a definitive answer to this, but it would be
interesting to learn what goes wrong with a launched instance.

Salman

Subject: RE: [Openstack] Instance IP assignment problem
From: emilien.openst...@gmail.com
To: salma...@live.com
CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net
Date: Tue, 1 May 2012 21:26:26 +0200

Le mardi 01 mai 2012 à 14:22 -0500, Salman Malik a écrit :

Regarding L3 gateway, I believe its not necessary to have one (as the VM
hasn't obtained an IP right now, so it can't talk to anything outside its
net), but I am not sure.
Regarding your problem, do you see any DHCP responses from the DHCP server
? I am asking this because I was having a similar problem earlier where I
was getting assigned an IP address no in my desired fixed_network and I
believe that was cause by another interfering DHCP server that was replying
to discover messages before the nova-network could.

Here my nova.conf and I don't have any interfering DHCP server :

https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf

Thanks

Salman

Hi Salman,

I'm thinking about a networking issue. Where is your L3 gateway in this
architecture ? Maybe do you need an ip helper tool to redirect DHCP
broadcast ?

What do you think about my problem (follow up to my last e-mail) ?

Thanks

Emilien

Le mardi 01 mai 2012 à 14:00 -0500, Salman Malik a écrit :

Hi,

Here is the error log: http://pastebin.com/KrNZDrvD
and nova.conf: http://pastebin.com/Fvd6dSZs

Emilien, I am trying to get an understanding of how different Quantum
plugins work with OpenStack. Ryu plugin is particularly interesting as it
uses an OpenFlow controller to configure Vswitches.

The problem I am faced with is (I think ) that I already have a private
network and Quantum should assign IP addresses to instances using DHCP. But
instances send out discover message on laucnh but never find a DHCP server
(although there are 2 dnsmasqs running).

Any ideas?

Thanks,
Salman

Date: Tue, 1

Re: [Openstack] Proposal for manuals translation process

2012-05-03 Thread Ying Chun Guo

I agree that we should define our objectives with respect to translations.
And we should also define the criteria of the translation web tool. There
are three
tools mentioned in the community now: Launchpad, Transifex and Pootle.
They have their own characteristics. The strength and the shortage are
different.
Before we start selection, we need to decide the criteria, and the
priorities of the required features.

How can we start this work? Shall we start by a vote?

Regards
Ying Chun Guo (Daisy)
China Standards and Open Source Team
Emerging Technology Institute (ETI)
IBM China Development Lab
Tel:(86-10)82453491
Email: guoyi...@cn.ibm.com
Address: 1F Tower B, Diamond Building 19 Zhongguancun Software Park,
8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193

openstack-bounces+guoyingc=cn.ibm@lists.launchpad.net wrote on
05/02/2012 11:55:59 PM:

 Thierry Carrez thie...@openstack.org
 Sent by: openstack-bounces+guoyingc=cn.ibm@lists.launchpad.net

 05/02/2012 11:55 PM

 To

 openstack@lists.launchpad.net,

 cc

 Subject

 Re: [Openstack] Proposal for manuals translation process

 Ying Chun Guo wrote:
  Thank you for your comments. I'm glad to know that you are working for
a
  larger goal. I don't know
  Launchpad is broken with code strings now. What do you mean when you
  said Launchpad to be
  broken with code strings now ?

 Actually it's our tooling around that (and more specifically, I believe,
 the inclusion of translated strings back into code) that is currently
 broken. Launchpad Translations itself works quite well (and strings are
 still getting translated there).

 The question is whether it's worth fixing it, so we must define our
 objectives with respect to translations first :)

 --
 Thierry Carrez (ttx)
 Release Manager, OpenStack

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
___
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] problem with swift upload when using swift

2012-05-03 Thread khabou imen

hi everybody ,
when trying to upload images using keystone for authentification I got
 curl -X PUT -D - \
  -H X-Auth-Token: 012345SECRET99TOKEN012345 \
  https://192.168.1.13:8080/v1/AUTH_MyTenant/images
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a bundle
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.


can any one help me?


-- 
cordialement,
 Imen Khabou,
Elève Ingénieur en Informatique
___
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-operators] Missing linuxbridge_conf.ini

2012-05-03 Thread raja.meena

Please check the below.


http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin


Meena Raja
Consultant
__
WIPRO TECHNOLOGIES
No 53/1 Ganapa Towers ,Near Madivala Police Station , Hosur Main Road 
,Bangalore-560068
Hand Phone : +91-9880549725 | Desk : +91-80-39912554 |Fax No: +91-80-25502160
Email : raja.me...@wipro.com | Website : www.wipro.com

From: Igor Laskovy [igor.lask...@gmail.com]
Sent: Thursday, May 03, 2012 12:43 PM
To: Raja Meena (WT01 - Innovation Group)
Cc: openstack@lists.launchpad.net; openstack-operat...@lists.openstack.org; 
dun...@dreamhost.com
Subject: RE: [Openstack] [Openstack-operators] Missing linuxbridge_conf.ini


Nope, these packages already installed.
Look like that package with Linux Bridge plugin is missing in repository or 
merged with another.

On May 3, 2012 9:53 AM, raja.me...@wipro.commailto:raja.me...@wipro.com 
wrote:

Hi ,

  Make sure you have the following package(s) installed  on quantum server  
host as well as any hosts which run the agent (-- Python library dependencies).

  1. python-configobj
  2. bridge-utils
  3. python-mysqldb
  4. sqlite3

This should solve the issue.



Meena Raja
Consultant
__
WIPRO TECHNOLOGIES
No 53/1 Ganapa Towers ,Near Madivala Police Station , Hosur Main Road 
,Bangalore-560068
Hand Phone : +91-9880549725tel:%2B91-9880549725 | Desk : 
+91-80-39912554tel:%2B91-80-39912554 |Fax No: 
+91-80-25502160tel:%2B91-80-25502160
Email : raja.me...@wipro.commailto:raja.me...@wipro.com | Website : 
www.wipro.comhttp://www.wipro.com


From: 
openstack-bounces+raja.meena=wipro@lists.launchpad.netmailto:wipro@lists.launchpad.net
 
[openstack-bounces+raja.meena=wipro@lists.launchpad.netmailto:wipro@lists.launchpad.net]
 on behalf of Duncan McGreggor 
[dun...@dreamhost.commailto:dun...@dreamhost.com]
Sent: Thursday, May 03, 2012 2:19 AM
To: Igor Laskovy
Cc: 
openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org;
 openstack
Subject: Re: [Openstack] [Openstack-operators] Missing linuxbridge_conf.ini

cc'ing openstack list

On Wed, May 2, 2012 at 3:33 PM, Igor Laskovy 
igor.lask...@gmail.commailto:igor.lask...@gmail.com wrote:
 Privet all from sunny Kiev!

 I have playing with Quantum with Quantum Linux Bridge plugin on Ubuntu
 12.04 and have installed these packages:

 i   quantum-server
 i   quantum-plugin-linuxbridge-agent
 i A quantum-common
 i A python-quantumclient
 i A python-quantum

 I can't find plugin configuration file linuxbridge_conf.ini . Which
 package provide installation of the plugin and this file?

 --
 Igor Laskovy
 ___
 Openstack-operators mailing list
 openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Please do not print this email unless it is absolutely necessary.

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.comhttp://www.wipro.com

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email. 

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

Re: [Openstack] Missing(?) keystone service catalog

2012-05-03 Thread Nick Lothian

My /etc/keystone/keystone.conf says:

[catalog]
template_file = /etc/keystone/default_catalog.templates
# dynamic, sql-based backend (supports API/CLI-based management commands)
driver = keystone.catalog.backends.templated.TemplatedCatalog

(This is the default from devstack).

I did look at that, but made the mistake of assuming the comment was
correct and referred to the next line, especially since the next, commented
out entry said it was the file-based one. My mistake I guess - I'll try the
SQL one.

Shouldn't the API give a read-only view of the service catalog if CRUD
operations are unavailable?

On Thu, May 3, 2012 at 4:32 PM, Rafael Durán Castañeda 
rafadurancastan...@gmail.com wrote:

  On 05/03/2012 06:38 AM, Nick Lothian wrote:

 I'm having some trouble using the Keystone API.

  When I run

  keystone --os_username=admin --os_password=password --os_auth_url=
 http://192.168.1.50:5000/v2.0/ service-list

  I get the following:

  No handlers could be found for logger keystoneclient.v2_0.client
 Unable to communicate with identity service: 404 Not Found

  The resource could not be found.

 . (HTTP 404)


  The keystone log shows the following:

  (eventlet.wsgi.server): 2012-05-03 14:03:12,840 DEBUG wsgi write
 192.168.1.50 - - [03/May/2012 14:03:12] GET /v2.0/OS-KSADM/services
 HTTP/1.1 404 176 0.008028


  Additionally, if I use curl to call the keystone API directly (as
 documented at http://keystone.openstack.org/api_curl_examples.html#id4)
 my whole serviceCatalog section is empty (serviceCatalog: {})

  I am using a default devstack installation.

  What am I missing?


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

  I think DevStack is using TemplatedCatalog as catalog backend and it
 doesn't support CRUD. If you need CRUD operations you can use SQL backend.

 ___
 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] Can't get fix ip via dhcp and can't accociate Floating ip using quantum

2012-05-03 Thread livemoon

I use quantum as my nova-network in ubuntu 12.04LTS, there are two problem:

1: it can show fix ip, but in vm, the network interfaces have no ips. Using
dhclient eth0 does not make sense. Using ifconfig eth0 inet xxx netmask
xxx can work.

2: when I accociate floating ip to a vm , it show error, the nova-network
log is below:

2012-05-03 17:51:18 DEBUG nova.rpc.amqp
[req-f0a4fffa-d6fa-4ab6-9985-1bc4e248edf7 538eac0210274847a183a988f57fbd59
57eb0d7989c7457aa3818998fbf9a4dc] unpacked context: {'user_id':
u'538eac0210274847a183a988f57fbd59', 'roles': [u'Member'], 'timestamp':
'2012-05-03T09:51:18.403089', 'auth_token': 'SANITIZED',
'remote_address': u'127.0.0.1', 'is_admin': False, 'request_id':
u'req-f0a4fffa-d6fa-4ab6-9985-1bc4e248edf7', 'project_id':
u'57eb0d7989c7457aa3818998fbf9a4dc', 'read_deleted': u'no'} from (pid=3791)
_safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-05-03 17:51:18 DEBUG nova.rpc.amqp [-] received {u'_context_roles':
[u'Member'], u'_msg_id': u'c4056c388c26498b83a3909d33e6d4ce',
u'_context_read_deleted': u'no', u'_context_request_id':
u'req-ec319cc9-245d-4808-991b-a00b417b923e', u'args': {u'id': u'1'},
u'_context_auth_token': 'SANITIZED', u'_context_is_admin': False,
u'_context_project_id': u'57eb0d7989c7457aa3818998fbf9a4dc',
u'_context_timestamp': u'2012-05-03T09:51:18.787337', u'_context_user_id':
u'538eac0210274847a183a988f57fbd59', u'method': u'get_floating_ip',
u'_context_remote_address': u'127.0.0.1'} from (pid=3791) _safe_log
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-05-03 17:51:18 DEBUG nova.rpc.amqp
[req-ec319cc9-245d-4808-991b-a00b417b923e 538eac0210274847a183a988f57fbd59
57eb0d7989c7457aa3818998fbf9a4dc] unpacked context: {'user_id':
u'538eac0210274847a183a988f57fbd59', 'roles': [u'Member'], 'timestamp':
'2012-05-03T09:51:18.787337', 'auth_token': 'SANITIZED',
'remote_address': u'127.0.0.1', 'is_admin': False, 'request_id':
u'req-ec319cc9-245d-4808-991b-a00b417b923e', 'project_id':
u'57eb0d7989c7457aa3818998fbf9a4dc', 'read_deleted': u'no'} from (pid=3791)
_safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-05-03 17:51:18 DEBUG nova.rpc.amqp [-] received {u'_context_roles':
[u'Member', u'admin'], u'_msg_id': u'248d0e0cbff14809978e1b0333621772',
u'_context_read_deleted': u'no', u'_context_request_id':
u'req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1', u'args': {u'instance_id': 5,
u'instance_uuid': u'57f9432f-2177-4635-9692-645ed5a5f2f7', u'host':
u'cloud', u'project_id': u'57eb0d7989c7457aa3818998fbf9a4dc',
u'rxtx_factor': 1.0}, u'_context_auth_token': 'SANITIZED',
u'_context_is_admin': True, u'_context_project_id':
u'57eb0d7989c7457aa3818998fbf9a4dc', u'_context_timestamp':
u'2012-05-03T09:51:18.825231', u'_context_user_id':
u'538eac0210274847a183a988f57fbd59', u'method': u'get_instance_nw_info',
u'_context_remote_address': u'127.0.0.1'} from (pid=3791) _safe_log
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-05-03 17:51:18 DEBUG nova.rpc.amqp
[req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1 538eac0210274847a183a988f57fbd59
57eb0d7989c7457aa3818998fbf9a4dc] unpacked context: {'user_id':
u'538eac0210274847a183a988f57fbd59', 'roles': [u'Member', u'admin'],
'timestamp': '2012-05-03T09:51:18.825231', 'auth_token': 'SANITIZED',
'remote_address': u'127.0.0.1', 'is_admin': True, 'request_id':
u'req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1', 'project_id':
u'57eb0d7989c7457aa3818998fbf9a4dc', 'read_deleted': u'no'} from (pid=3791)
_safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-05-03 17:51:18 DEBUG nova.utils
[req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1 538eac0210274847a183a988f57fbd59
57eb0d7989c7457aa3818998fbf9a4dc] Attempting to grab semaphore get_dhcp
for method _get_dhcp_ip... from (pid=3791) inner
/usr/lib/python2.7/dist-packages/nova/utils.py:927
2012-05-03 17:51:18 DEBUG nova.utils
[req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1 538eac0210274847a183a988f57fbd59
57eb0d7989c7457aa3818998fbf9a4dc] Got semaphore get_dhcp for method
_get_dhcp_ip... from (pid=3791) inner
/usr/lib/python2.7/dist-packages/nova/utils.py:931
2012-05-03 17:51:18 DEBUG nova.utils
[req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1 538eac0210274847a183a988f57fbd59
57eb0d7989c7457aa3818998fbf9a4dc] Attempting to grab semaphore get_dhcp
for method _get_dhcp_ip... from (pid=3791) inner
/usr/lib/python2.7/dist-packages/nova/utils.py:927
2012-05-03 17:51:18 DEBUG nova.utils
[req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1 538eac0210274847a183a988f57fbd59
57eb0d7989c7457aa3818998fbf9a4dc] Got semaphore get_dhcp for method
_get_dhcp_ip... from (pid=3791) inner
/usr/lib/python2.7/dist-packages/nova/utils.py:931
2012-05-03 17:51:18 DEBUG nova.utils
[req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1 538eac0210274847a183a988f57fbd59
57eb0d7989c7457aa3818998fbf9a4dc] Attempting to grab semaphore get_dhcp
for method _get_dhcp_ip... from (pid=3791) inner
/usr/lib/python2.7/dist-packages/nova/utils.py:927
2012-05-03 17:51:18 DEBUG nova.utils

Re: [Openstack] Instance IP assignment problem

I ran a 'dhcpdump' on ESSEX-2 and I can see DHCP request, but no
response from ESSEX-1 DNSMASQ process...

I continue to investigate...





Le jeudi 03 mai 2012 à 13:31 +0400, Anton Haldin a écrit :

 can you find dhcp requests by using tcpdump for example ?
 
 
 
 sorry for off-topic but there may be many reasons of such issue with
 dhcp. last one for me was old dhcp client(Ubuntu) and udp checksum
 error. I have essex on centos and was trying ubuntu vm. 
 
 
 On Thu, May 3, 2012 at 12:48 PM, Emilien Macchi
 emilien.openst...@gmail.com wrote:
 
 All seems alright but not working yet.
 
 
 http://paste.openstack.org/show/14791/
 
 
 
 I have executed on both servers :
 
 ovs-vsctl add-port br-int eth1
 
 
 Need I do something else ?
 
 How the DHCP is working in this case ?
 
 
 
 
 
 
 Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit : 
 
  Then the problem isn't in the instance but in the
  nova-network service , please check if it is working well 
  as well as give us the output log when you attempt to create
  a new instance.
  
  
  
  
  
  Subject: RE: [Openstack] Instance IP assignment problem
  From: emilien.openst...@gmail.com
  To: ski...@hotmail.fr
  CC: salma...@live.com; openstack@lists.launchpad.net
  Date: Thu, 3 May 2012 10:21:37 +0200
  
  Fixed IP
  
  
  
  Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit : 
  
  Fixed IP or Floating IP ?
  
  
  
  
  
  
  From: emilien.openst...@gmail.com
  To: salma...@live.com
  Date: Thu, 3 May 2012 09:55:31 +0200
  CC: openstack@lists.launchpad.net
  Subject: Re: [Openstack] Instance IP assignment
  problem
  
  Hi,
  
  
  As I told you, I have also a problem for instance IP
  assignement.
  
  
  My architecture :
  
  I use Quantum with OVS plugin on 2 servers Essex-1 
  Essex-2. Essex-1 runs all services and Essex-2 runs
  OVS, Quantum-agent  nova-compute only.
  
  You can see more details here.
  
  My configurations files are here and in my
  documentation.
  
  
  
  Problem Description :
  
  When an instance is created in ESSEX-1, all is
  working (network).
  
  But when the VM is started on ESSEX-2, it does not
  get an IP address. (log file)
  
  I'm sure the problem comes from OVS connection with
  ESSEX-1.
  
  
  Do I need to configure something like a trunk or a
  tunnel between Essex-1  Essex-2 ?
  
  I miss something in my configuration, if you have
  any idea...
  
  
  Regards
  
  
  Emilien
  
  
  Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a
  écrit : 
  
  It may help if you can share the log of your
  launched instance as well. There is a
  possibility that we both are having the same
  issue. 
  Netstack developers can give a definitive
  answer to this, but it would be interesting
  to learn what goes wrong with a launched
  instance.
  
  Salman
  
  
  
  
  
  
  
  
  Subject: RE: [Openstack] Instance IP
  assignment problem
  From: emilien.openst...@gmail.com
  To: salma...@live.com

Re: [Openstack] Instance IP assignment problem

I share my OVS configuration with you :


root@essex-1:~# ovs-vsctl show
03583d51-03b8-4061-a147-1d892447bee2
Bridge br-int
Port tap21d51768-3c
tag: 12
Interface tap21d51768-3c
Port br-int
Interface br-int
type: internal
Port gw-2850687f-68
tag: 12
Interface gw-2850687f-68
type: internal
Port eth1
Interface eth1
ovs_version: 1.4.0+build0


root@essex-2:~# ovs-vsctl show
3defede8-df1c-4a99-9928-850d9f665194
Bridge br-int
Port br-int
Interface br-int
type: internal
Port tapa8899517-37
tag: 12
Interface tapa8899517-37
Port eth1
Interface eth1
ovs_version: 1.4.0+build0





Le jeudi 03 mai 2012 à 13:31 +0400, Anton Haldin a écrit :

 can you find dhcp requests by using tcpdump for example ?
 
 
 
 sorry for off-topic but there may be many reasons of such issue with
 dhcp. last one for me was old dhcp client(Ubuntu) and udp checksum
 error. I have essex on centos and was trying ubuntu vm. 
 
 
 On Thu, May 3, 2012 at 12:48 PM, Emilien Macchi
 emilien.openst...@gmail.com wrote:
 
 All seems alright but not working yet.
 
 
 http://paste.openstack.org/show/14791/
 
 
 
 I have executed on both servers :
 
 ovs-vsctl add-port br-int eth1
 
 
 Need I do something else ?
 
 How the DHCP is working in this case ?
 
 
 
 
 
 
 Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit : 
 
  Then the problem isn't in the instance but in the
  nova-network service , please check if it is working well 
  as well as give us the output log when you attempt to create
  a new instance.
  
  
  
  
  
  Subject: RE: [Openstack] Instance IP assignment problem
  From: emilien.openst...@gmail.com
  To: ski...@hotmail.fr
  CC: salma...@live.com; openstack@lists.launchpad.net
  Date: Thu, 3 May 2012 10:21:37 +0200
  
  Fixed IP
  
  
  
  Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit : 
  
  Fixed IP or Floating IP ?
  
  
  
  
  
  
  From: emilien.openst...@gmail.com
  To: salma...@live.com
  Date: Thu, 3 May 2012 09:55:31 +0200
  CC: openstack@lists.launchpad.net
  Subject: Re: [Openstack] Instance IP assignment
  problem
  
  Hi,
  
  
  As I told you, I have also a problem for instance IP
  assignement.
  
  
  My architecture :
  
  I use Quantum with OVS plugin on 2 servers Essex-1 
  Essex-2. Essex-1 runs all services and Essex-2 runs
  OVS, Quantum-agent  nova-compute only.
  
  You can see more details here.
  
  My configurations files are here and in my
  documentation.
  
  
  
  Problem Description :
  
  When an instance is created in ESSEX-1, all is
  working (network).
  
  But when the VM is started on ESSEX-2, it does not
  get an IP address. (log file)
  
  I'm sure the problem comes from OVS connection with
  ESSEX-1.
  
  
  Do I need to configure something like a trunk or a
  tunnel between Essex-1  Essex-2 ?
  
  I miss something in my configuration, if you have
  any idea...
  
  
  Regards
  
  
  Emilien
  
  
  Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a
  écrit : 
  
  It may help if you can share the log of your
  launched instance as well. There is a
  possibility that we both are having the same
  issue. 
  Netstack developers can give a definitive
  answer to this, but it

[Openstack] [nova-api] No module named nova_keystone_context

2012-05-03 Thread Leander Bessa

Hello,

Every time i start nova-api i get the following output:

nova-api --config-file=/etc/nova/nova.conf
 2012-04-30 15:23:51 CRITICAL nova [-] No module named nova_keystone_context
 2012-04-30 15:23:51 TRACE nova Traceback (most recent call last):
 2012-04-30 15:23:51 TRACE nova   File /usr/bin/nova-api, line 51, in
 module
 2012-04-30 15:23:51 TRACE nova servers.append(service.WSGIService(api))
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/nova/service.py, line 326, in __init__
 2012-04-30 15:23:51 TRACE nova self.app = self.loader.load_app(name)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/nova/wsgi.py, line 388, in load_app
 2012-04-30 15:23:51 TRACE nova return deploy.loadapp(config:%s %
 self.config_path, name=name)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in
 loadapp
 2012-04-30 15:23:51 TRACE nova return loadobj(APP, uri, name=name,
 **kw)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in
 loadobj
 2012-04-30 15:23:51 TRACE nova return context.create()
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in
 create
 2012-04-30 15:23:51 TRACE nova return self.object_type.invoke(self)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in
 invoke
 2012-04-30 15:23:51 TRACE nova **context.local_conf)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in
 fix_call
 2012-04-30 15:23:51 TRACE nova val = callable(*args, **kw)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/nova/api/openstack/urlmap.py, line 163,
 in urlmap_factory
 2012-04-30 15:23:51 TRACE nova app = loader.get_app(app_name,
 global_conf=global_conf)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in
 get_app
 2012-04-30 15:23:51 TRACE nova name=name,
 global_conf=global_conf).create()
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in
 create
 2012-04-30 15:23:51 TRACE nova return self.object_type.invoke(self)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in
 invoke
 2012-04-30 15:23:51 TRACE nova **context.local_conf)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in
 fix_call
 2012-04-30 15:23:51 TRACE nova val = callable(*args, **kw)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/nova/api/auth.py, line 48, in
 pipeline_factory
 2012-04-30 15:23:51 TRACE nova filters = [loader.get_filter(n) for n
 in pipeline[:-1]]
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 354, in
 get_filter
 2012-04-30 15:23:51 TRACE nova name=name,
 global_conf=global_conf).create()
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 366, in
 filter_context
 2012-04-30 15:23:51 TRACE nova FILTER, name=name,
 global_conf=global_conf)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 458, in
 get_context
 2012-04-30 15:23:51 TRACE nova section)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 517, in
 _context_from_explicit
 2012-04-30 15:23:51 TRACE nova value = import_string(found_expr)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 22, in
 import_string
 2012-04-30 15:23:51 TRACE nova return
 pkg_resources.EntryPoint.parse(x= + s).load(False)
 2012-04-30 15:23:51 TRACE nova   File
 /usr/lib/python2.7/dist-packages/pkg_resources.py, line 1989, in load
 2012-04-30 15:23:51 TRACE nova entry = __import__(self.module_name,
 globals(),globals(), ['__name__'])
 2012-04-30 15:23:51 TRACE nova ImportError: No module named
 nova_keystone_context
 2012-04-30 15:23:51 TRACE nova
 Exception KeyError: KeyError(140300442122736,) in module 'threading' from
 '/usr/lib/python2.7/threading.pyc' ignored



Am i missing something from my config file, or is it something else?

Here's my nova.conf file:

[DEFAULT]
 # LOG/State
 verbose=True
 # Authentication
 auth_strategy=keystone
 # Scheduler
 compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler
 # VOLUMES
 volume_group=nova-volumes
 volume_name_template=volume-%08x
 iscsi_helper=tgtadm
 iscsi_ip_prefix=192.168.164.128
 # COMPUTE
 libvirt_type=kvm
 connection_type=libvirt
 instance_name_template=instance-%08x
 api_paste_config=/etc/nova/api-paste.ini
 allow_resize_to_same_host=True
 root_helper=sudo nova-rootwrap

Re: [Openstack] Instance IP assignment problem

Can you send my your nova.conf of nova-compute servers ?



I'm thinking about flat interface...




Le jeudi 03 mai 2012 à 10:26 +0100, Bilel Msekni a écrit :
 Basing on your architecture picture , I think you mean ping VM that
 resides on Essex 2 from server containing Essex 1
 
 I had a similar networking problem and i honestly don't know i fixed
 it ( didn't enable tunneling) , this is what i did
 1- ifconfig eth0 0.0.0.0
 2- dhclient br-int ( normally the bridge will take the address of
 eth0)
 
 
 and pinging went back to working fine but i am still testing if there
 are any side effects
 Try it out and txt me !
 
 
 btw , i used your ubuntu 12.04 LTS cloud img and i can't seem to ping
 it but when i choose another image ( the default tty for example) it
 ping as a charm , probably you should pick another image !  
  
 
 
 
 
 
 __
 Subject: RE: [Openstack] Instance IP assignment problem
 From: emilien.openst...@gmail.com
 To: ski...@hotmail.fr
 CC: openstack@lists.launchpad.net
 Date: Thu, 3 May 2012 11:11:04 +0200
 
 Ok :
 
 http://paste.openstack.org/show/14797/
 
 
 I know where is the problem but I dont know yet how to fix it :
 
 
 - Quantum creates TAP interface on ESSEX-2
 
 - From ESSEX-2, I can't ping VMs on ESSEX-1
 
 
 Here my ovs_quantum_plugin.ini :
 
 [DATABASE]
 sql_connection =
 mysql://ovs_quantum:password@10.68.1.40:3306/ovs_quantum
 
 
 [OVS]
 integration-bridge = br-int
 
 
 [AGENT]
 root_helper = sudo
 
 
 
 Do we need enable bridge ?
 
 
 
 
 Le jeudi 03 mai 2012 à 10:00 +0100, Bilel Msekni a écrit : 
 
 èmm , can you do this on your instance : nova show %
 instance_Id so that i may see the problem in the resume of
 spawning ?
 and are you sure you have enough fixed ip addresses left for
 use ?
 
 The configuration of nova and quantum is almost the same as me
 and the instances are getting Fixed Ips without any problem !
 
 
 __
 
 Subject: RE: [Openstack] Instance IP assignment problem
 From: emilien.openst...@gmail.com
 To: ski...@hotmail.fr
 CC: salma...@live.com; openstack@lists.launchpad.net
 Date: Thu, 3 May 2012 10:48:43 +0200
 
 All seems alright but not working yet.
 
 
 http://paste.openstack.org/show/14791/
 
 
 
 I have executed on both servers :
 
 ovs-vsctl add-port br-int eth1
 
 
 Need I do something else ?
 
 How the DHCP is working in this case ?
 
 
 
 
 
 
 Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit : 
 
 Then the problem isn't in the instance but in the
 nova-network service , please check if it is working
 well 
 as well as give us the output log when you attempt to
 create a new instance.
 
 
 
 __
 
 
 Subject: RE: [Openstack] Instance IP assignment
 problem
 From: emilien.openst...@gmail.com
 To: ski...@hotmail.fr
 CC: salma...@live.com; openstack@lists.launchpad.net
 Date: Thu, 3 May 2012 10:21:37 +0200
 
 Fixed IP
 
 
 
 Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a
 écrit : 
 
 Fixed IP or Floating IP ?
 
 
 
 __
 
 
 
 From: emilien.openst...@gmail.com
 To: salma...@live.com
 Date: Thu, 3 May 2012 09:55:31 +0200
 CC: openstack@lists.launchpad.net
 Subject: Re: [Openstack] Instance IP
 assignment problem
 
 Hi,
 
 
 As I told you, I have also a problem for
 instance IP assignement.
 
 
 My architecture :
 
 I use Quantum with OVS plugin on 2 servers
 Essex-1  Essex-2. Essex-1 runs all services
 and Essex-2 runs OVS, Quantum-agent

[Openstack] Nova subsystem branches and feature branches

Hey,

We discussed this during the baking area for features design summit
session. I found that discussion fairly frustrating because there were
so many of us involved and we all were either wanting to discuss
slightly different things or had a slightly different understanding of
what we were discussing. So, here's my attempt to put some more
structure on the discussion.

tl;dr - subsystem branches are managed by trusted domain experts and
feature branches are just temporary rebasing branches on personal github
forks. We've got a tonne of work to do figuring out how this would all
work. We should probably pick a single subsystem and start with that.

...

Firstly, problem definition:

  - Nova is big, complex and has a fairly massive rate of churn. While 
the nova-core team is big, there isn't enough careful review going 
on by experts in particular areas and there's a consistently large
backlog of reviews.

  - Developers working on features are very keen to have their work 
land somewhere and this leads to half-finished features being 
merged onto master rather than developers collaborating to get a 
feature to a level of completeness and polish before merging into 
master.

Some assumptions about the solution:

  - There should be a small number of domain experts who can approve 
changes to each of major subsystems. This will encourage 
specialization and give more clear lines of responsibility.

  - There should be a small number of project dictators who have final 
approval on merge proposals, but who are not expected to review 
every patch in great detail. This is good because we need someone 
with an overall view of the project who can make sure efforts in 
the various subsystems are coordinated, without that someone being 
massively overloaded.

  - New features should be developed on a branch and brought to a level 
of completeness before being merged into master. This is good 
because we don't want half-baked stuff in master but also because 
it encourages developers to break their features into stages where 
each stage of the work can be brought to completion and merged 
before moving on to the next stage.

  - In essence, we're assuming some variation of the kernel distributed 
development model.

(FWIW, my instinct is to avoid the kernel model on projects. Mostly 
because it's extremely complex and massive overkill for most 
projects. Looking at the kernel history with gitk is enough to send 
anyone screaming for the hills. However, Nova seems to be big 
enough that we're experiencing the same pressures that drove the 
kernel to adopt their model)

Ok, what are subsystem branches and how would they work?

  - Subsystem branches would have a small number of maintainers who can 
approve a change. These would be domain experts providing strong 
oversight over a particular area.

(In gerrit, this is a branch with a small team or single person who 
can +1 approve a review)

  - Project dictators don't need to do detailed reviews of merge 
proposals from subsystem maintainers. The dictator's role is mostly 
just to sign off on the merge proposal. However, the dictator can 
comment in the proposal on things which could have been done better 
and the subsystem maintainer should take note of these comments and 
perhaps retroactively fix them up. Ultimately, though, the dictator 
can have exercise a veto if the merge proposal is unacceptable or 
if the subsystem maintainer is consistently making the same 
mistakes.

  - It would be up to the project dictators to help drive patches 
through the right subsystem branches - e.g. they might object if 
one subsystem maintainer merged a patch that inappropriately cut 
into another subsystem or they might refuse to merge a given patch
into the main branch unless it went through the appropriate 
subsystem branch.

(In gerrit, this would mean a small team or single person who can 
+1 approve merge proposals on master. They would -1 proposals
submitted against master which should have been submitted against a 
subsystem branch.)

  - Subsystem branches might not necessarily be blessed centrally. It 
might be a case that anyone can create such a branch and, over 
time, establish trust with the project dictators. Subsystem 
branches would come and go. This is the mechanism by which 
subsystem maintainership is transferred between people over time.

(In gerrit, this means people need to easily be able to create 
their own branches)

(What's more difficult to imagine in gerrit is how a new, potential 
subsystem maintainer comes along, starts hoovering up patches into 
her branch and submitting them in batches. Where does she hoover 
them up from and how does she say I've merged this into my branch, 
don't merge it via another branch)

  -

Re: [Openstack] Can't get fix ip via dhcp and can't accociate Floating ip using quantum


Network 2 could not be found.
That's your key 

Date: Thu, 3 May 2012 17:58:43 +0800
From: mwjpi...@gmail.com
To: openstack@lists.launchpad.net
Subject: [Openstack] Can't get fix ip via dhcp and can't accociate Floating 
ip using quantum

I use quantum as my nova-network in ubuntu 12.04LTS, there are two problem:
1: it can show fix ip, but in vm, the network interfaces have no ips. Using 
dhclient eth0 does not make sense. Using ifconfig eth0 inet xxx netmask xxx 
can work.

2: when I accociate floating ip to a vm , it show error, the nova-network log 
is below:
2012-05-03 17:51:18 DEBUG nova.rpc.amqp 
[req-f0a4fffa-d6fa-4ab6-9985-1bc4e248edf7 538eac0210274847a183a988f57fbd59 
57eb0d7989c7457aa3818998fbf9a4dc] unpacked context: {'user_id': 
u'538eac0210274847a183a988f57fbd59', 'roles': [u'Member'], 'timestamp': 
'2012-05-03T09:51:18.403089', 'auth_token': 'SANITIZED', 'remote_address': 
u'127.0.0.1', 'is_admin': False, 'request_id': 
u'req-f0a4fffa-d6fa-4ab6-9985-1bc4e248edf7', 'project_id': 
u'57eb0d7989c7457aa3818998fbf9a4dc', 'read_deleted': u'no'} from (pid=3791) 
_safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-05-03 17:51:18 DEBUG nova.rpc.amqp [-] received {u'_context_roles': 
[u'Member'], u'_msg_id': u'c4056c388c26498b83a3909d33e6d4ce', 
u'_context_read_deleted': u'no', u'_context_request_id': 
u'req-ec319cc9-245d-4808-991b-a00b417b923e', u'args': {u'id': u'1'}, 
u'_context_auth_token': 'SANITIZED', u'_context_is_admin': False, 
u'_context_project_id': u'57eb0d7989c7457aa3818998fbf9a4dc', 
u'_context_timestamp': u'2012-05-03T09:51:18.787337', u'_context_user_id': 
u'538eac0210274847a183a988f57fbd59', u'method': u'get_floating_ip', 
u'_context_remote_address': u'127.0.0.1'} from (pid=3791) _safe_log 
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-05-03 17:51:18 DEBUG nova.rpc.amqp 
[req-ec319cc9-245d-4808-991b-a00b417b923e 538eac0210274847a183a988f57fbd59 
57eb0d7989c7457aa3818998fbf9a4dc] unpacked context: {'user_id': 
u'538eac0210274847a183a988f57fbd59', 'roles': [u'Member'], 'timestamp': 
'2012-05-03T09:51:18.787337', 'auth_token': 'SANITIZED', 'remote_address': 
u'127.0.0.1', 'is_admin': False, 'request_id': 
u'req-ec319cc9-245d-4808-991b-a00b417b923e', 'project_id': 
u'57eb0d7989c7457aa3818998fbf9a4dc', 'read_deleted': u'no'} from (pid=3791) 
_safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-05-03 17:51:18 DEBUG nova.rpc.amqp [-] received {u'_context_roles': 
[u'Member', u'admin'], u'_msg_id': u'248d0e0cbff14809978e1b0333621772', 
u'_context_read_deleted': u'no', u'_context_request_id': 
u'req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1', u'args': {u'instance_id': 5, 
u'instance_uuid': u'57f9432f-2177-4635-9692-645ed5a5f2f7', u'host': u'cloud', 
u'project_id': u'57eb0d7989c7457aa3818998fbf9a4dc', u'rxtx_factor': 1.0}, 
u'_context_auth_token': 'SANITIZED', u'_context_is_admin': True, 
u'_context_project_id': u'57eb0d7989c7457aa3818998fbf9a4dc', 
u'_context_timestamp': u'2012-05-03T09:51:18.825231', u'_context_user_id': 
u'538eac0210274847a183a988f57fbd59', u'method': u'get_instance_nw_info', 
u'_context_remote_address': u'127.0.0.1'} from (pid=3791) _safe_log 
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-05-03 17:51:18 DEBUG nova.rpc.amqp 
[req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1 538eac0210274847a183a988f57fbd59 
57eb0d7989c7457aa3818998fbf9a4dc] unpacked context: {'user_id': 
u'538eac0210274847a183a988f57fbd59', 'roles': [u'Member', u'admin'], 
'timestamp': '2012-05-03T09:51:18.825231', 'auth_token': 'SANITIZED', 
'remote_address': u'127.0.0.1', 'is_admin': True, 'request_id': 
u'req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1', 'project_id': 
u'57eb0d7989c7457aa3818998fbf9a4dc', 'read_deleted': u'no'} from (pid=3791) 
_safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-05-03 17:51:18 DEBUG nova.utils [req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1 
538eac0210274847a183a988f57fbd59 57eb0d7989c7457aa3818998fbf9a4dc] Attempting 
to grab semaphore get_dhcp for method _get_dhcp_ip... from (pid=3791) inner 
/usr/lib/python2.7/dist-packages/nova/utils.py:927
2012-05-03 17:51:18 DEBUG nova.utils [req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1 
538eac0210274847a183a988f57fbd59 57eb0d7989c7457aa3818998fbf9a4dc] Got 
semaphore get_dhcp for method _get_dhcp_ip... from (pid=3791) inner 
/usr/lib/python2.7/dist-packages/nova/utils.py:931
2012-05-03 17:51:18 DEBUG nova.utils [req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1 
538eac0210274847a183a988f57fbd59 57eb0d7989c7457aa3818998fbf9a4dc] Attempting 
to grab semaphore get_dhcp for method _get_dhcp_ip... from (pid=3791) inner 
/usr/lib/python2.7/dist-packages/nova/utils.py:927
2012-05-03 17:51:18 DEBUG nova.utils [req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1 
538eac0210274847a183a988f57fbd59 57eb0d7989c7457aa3818998fbf9a4dc] Got 
semaphore get_dhcp for method _get_dhcp_ip... from (pid=3791) inner 
/usr/lib/python2.7/dist-packages/nova/utils.py:931
2012-05-03 17:51:18 DEBUG nova.utils

Re: [Openstack] Instance IP assignment problem

2012-05-03 Thread Soheil Hassas Yeganeh

I had a similar problem before. My problem was that the nic driver on the
compute instance (your Essex 2) was dropping vlan tags, and then,
openvswitch wasn

can you find dhcp requests by using tcpdump for example ?

sorry for off-topic but there may be many reasons of such issue with
dhcp. last one for me was old dhcp client(Ubuntu) and udp checksum error. I
have essex on centos and was trying ubuntu vm.

On Thu, May 3, 2012 at 12:48 PM, Emilien Macchi
emilien.openst...@gmail.com wrote:

**
All seems alright but not working yet.

http://paste.openstack.org/show/14791/

I have executed on both servers :

ovs-vsctl add-port br-int eth1

Need I do something else ?

How the DHCP is working in this case ?

Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit :

Then the problem isn't in the instance but in the nova-network service ,
please check if it is working well

as well as give us the output log when you attempt to create a new
instance.

Fixed IP

Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit :

Fixed IP or Floating IP ?

From: emilien.openst...@gmail.com
To: salma...@live.com
Date: Thu, 3 May 2012 09:55:31 +0200
CC: openstack@lists.launchpad.net
Subject: Re: [Openstack] Instance IP assignment problem

Hi,

As I told you, I have also a problem for instance IP assignement.

*My architecture :*

I use *Quantum* with *OVS plugin* on 2 servers Essex-1 Essex-2.
Essex-1 runs all services and Essex-2 runs OVS, Quantum-agent
nova-compute only.

You can see more details
herehttps://github.com/EmilienM/doc-openstack/blob/master/Documentation/How%20to%20setup%20OpenStack%20Essex.pdf
.

My configurations files are
herehttps://github.com/EmilienM/doc-openstack/tree/master/Configuration%20Filesand
in my documentation.

*Problem Description :*

When an instance is created in ESSEX-1, all is working (network).

But when the VM is started on ESSEX-2, it does not get an IP address. (log
file http://paste.openstack.org/show/14775/)

I'm sure the problem comes from OVS connection with ESSEX-1.

Do I need to configure something like a trunk or a tunnel between Essex-1
Essex-2 ?

I miss something in my configuration, if you have any idea...

Regards

Emilien

Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a écrit :

Salman

Le mardi 01 mai 2012 à 14:22 -0500, Salman Malik a écrit :

Regarding L3 gateway, I believe its not necessary to have one (as the VM
hasn't obtained an IP right now, so it can't talk to anything outside its
net), but I am not sure.
Regarding your problem, do you see any DHCP responses from the DHCP
server ? I am asking this because I was having a similar problem earlier
where I was getting assigned an IP address no in my desired fixed_network
and I believe that was cause by another interfering DHCP server that was
replying to discover messages before the nova-network could.

Here my nova.conf and I don't have any interfering DHCP server :

https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf

Thanks

Salman

Hi Salman,

I'm thinking about a networking issue. Where is your L3 gateway in this
architecture ? Maybe do you need an ip helper tool to redirect DHCP
broadcast ?

What do you think about my problem (follow up to my last e-mail) ?

Thanks

Emilien

Le mardi 01 mai 2012 à 14:00 -0500, Salman Malik a écrit :

Hi,

Here is the error log: http://pastebin.com/KrNZDrvD
and nova.conf: http://pastebin.com/Fvd6dSZs

Emilien, I am trying to get an understanding of how different Quantum
plugins work with OpenStack. Ryu plugin is particularly interesting as it
uses an OpenFlow controller to configure Vswitches.

The problem I am faced with is (I think ) that I already have a private
network and Quantum should assign IP addresses to instances using DHCP. But
instances send out discover message on

[Openstack] [Metering] Meeting agenda for today 16:00 UTC (May 3rd, 2012)

2012-05-03 Thread Loic Dachary

Hi,

The metering project team holds a meeting in #openstack-meeting, Thursdays at 
1600 UTC 
http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0. 
Everyone is welcome.
I propose an agenda based on the discussions we had on this list.

http://wiki.openstack.org/Meetings/MeteringAgenda
Topic : schema and counter definitions

 * counter definitions
   * Proposed http://wiki.openstack.org/EfficientMetering#Counters
 * schema definition
   * Proposed http://wiki.openstack.org/EfficientMetering#Storage
 * discuss storage assumptions
   * the storage will store all events
   * no aggregated value is permanently stored
 * discuss API assumptions
   * the API provide a sum() function to aggregate values
   * the API may transparently store results of the sum function in a cache
 * discuss event collection
   * events are collected from a components when possible
   * ceilometer agent is installed on a node when the a component does not 
provide the value
   * contribute to the component instead of developping a ceilometer agent 
plugin
 * engaging discussions with core components
   * nova
   * cinder
   * glance
   * swift
   * quantum
 *  open discussion

Cheers

-- 
Loïc Dachary Chief Research Officer
// eNovance labs   http://labs.enovance.com
// ? l...@enovance.com  ? +33 1 49 70 99 82

___
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] Nova subsystem branches and feature branches

2012-05-03 Thread Thierry Carrez

Mark McLoughlin wrote:
 We discussed this during the baking area for features design summit
 session. I found that discussion fairly frustrating because there were
 so many of us involved and we all were either wanting to discuss
 slightly different things or had a slightly different understanding of
 what we were discussing. So, here's my attempt to put some more
 structure on the discussion.

Thanks for that ! I'd not yet found the time to restart that discussion.
The session was a bit frustrating indeed: I've been pushing those ideas
around the end of the Essex cycle, but with release work we couldn't
come to a ready-to-implement solution that we could have switched to for
Folsom. The session was not completely useless though: there was general
consensus that this was the way to go, but that we had to carefully
experiment with this in the current cycle in order to be potentially
ready to propose a significant model evolution for the next cycle.

 Firstly, problem definition:
 
   - Nova is big, complex and has a fairly massive rate of churn. While 
 the nova-core team is big, there isn't enough careful review going 
 on by experts in particular areas and there's a consistently large
 backlog of reviews.

I think smaller teams of dedicated area-oriented reviewers will indeed
go a long way to solve the issues of speed and quality of review.

   - Developers working on features are very keen to have their work 
 land somewhere and this leads to half-finished features being 
 merged onto master rather than developers collaborating to get a 
 feature to a level of completeness and polish before merging into 
 master.

Yes, the absence of state between in master and nowhere led to both
half-implemented (incomplete) and half-baked (not release-ready yet)
features landing in master, milestones and potentially the release.

 Some assumptions about the solution:
 [...]

Agree on all points.

 Ok, what are subsystem branches and how would they work?
 [...]
   - It would be up to the project dictators to help drive patches 
 through the right subsystem branches - e.g. they might object if 
 one subsystem maintainer merged a patch that inappropriately cut 
 into another subsystem or they might refuse to merge a given patch
 into the main branch unless it went through the appropriate 
 subsystem branch.
 
 (In gerrit, this would mean a small team or single person who can 
 +1 approve merge proposals on master. They would -1 proposals
 submitted against master which should have been submitted against a 
 subsystem branch.)

IIUC under this model we would still accept changes to be directly
proposed to master (think bug fixes, or features that don't belong into
a specific subsystem) ? For those we would still need a review team
(separate from the project dictators who do the second-stage review)
with wide expertise on all things Nova.

 [...]
   - Plausible subsystem branches are e.g.:
 
   - OpenStack APIs
   - EC2 API
   - virt
  - libvirt driver
  - xenapi driver
  - vmware driver
   - networking
   - volumes
   - scheduler
   - RPC
 
 Deciding which areas make sense as a subsystem branch is 
 non-trivial.
 
 Should there be a DB subsystem? Probably not, because that would 
 mean every new feature needs to come through this branch or, 
 alternatively, the DB maintainer would need to accept DB schema 
 additions without the context of how it's being used higher up the 
 stack.
 
 Ok, so why does it make sense to have an OpenStack APIs 
 subsystem? Don't all features affect that branch too? Well, maybe, 
 but the APIs really do need strong oversight. Perhaps we can be 
 confident that we can add e.g. a new scheduler feature through the
 scheduler branch and then later merge any API additions through the 
 APIs branch.

I think there are two types of subsystems making sense: those areas of
code that are already separated into a self-contained module, and those
areas of the code where editorial control / extra expertise is needed.

As an example, sometimes I wish that all proposed run-as-root commands
would be through a security review before being accepted in master
(because sometimes they are overkill and needlessly increase the
run-as-root surface, and some other times they annihilate our efforts at
filtering nova-root escalation). This is difficult to do with a common
team of 25+ reviewers.

 And how about feature branches?
 
   - Feature branches are relatively short-lived (i.e. weeks or months
 rather than years) branches for a specific feature. They are a
 mechanism for developers to work on a patch series in the open until
 the feature is complete enough to be merged into a subsystem branch
 or master.
 
 (I'm not sure gerrit is right for this. Why not just do it in 
 folk's github forks? I think all people are looking for

Re: [Openstack] Instance IP assignment problem

2012-05-03 Thread Soheil Hassas Yeganeh

Oops accidently hit send on my phone.

I had a similar problem before. My problem was that the nic driver on the
compute instance (your Essex 2) was dropping vlan tags, and then,
openvswitch wasn't delivering packets. You can check it using tcpdump -e
-vvv.

BTW, if you are using virtualbox to run openstack, make sure you are not
using vbox intel drivers. Use pcnet fast instead.

OVS splinter may also be useful.

Hope that helps.

Cheers
Soheil

On Thursday, May 3, 2012, Soheil Hassas Yeganeh wrote:

I had a similar problem before. My problem was that the nic driver on the
compute instance (your Essex 2) was dropping vlan tags, and then,
openvswitch wasn

can you find dhcp requests by using tcpdump for example ?

sorry for off-topic but there may be many reasons of such issue with
dhcp. last one for me was old dhcp client(Ubuntu) and udp checksum error. I
have essex on centos and was trying ubuntu vm.

On Thu, May 3, 2012 at 12:48 PM, Emilien Macchi
emilien.openst...@gmail.com wrote:

**
All seems alright but not working yet.

http://paste.openstack.org/show/14791/

I have executed on both servers :

ovs-vsctl add-port br-int eth1

Need I do something else ?

How the DHCP is working in this case ?

Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit :

Then the problem isn't in the instance but in the nova-network service ,
please check if it is working well

as well as give us the output log when you attempt to create a new
instance.

Fixed IP

Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit :

Fixed IP or Floating IP ?

From: emilien.openst...@gmail.com
To: salma...@live.com
Date: Thu, 3 May 2012 09:55:31 +0200
CC: openstack@lists.launchpad.net
Subject: Re: [Openstack] Instance IP assignment problem

Hi,

As I told you, I have also a problem for instance IP assignement.

*My architecture :*

I use *Quantum* with *OVS plugin* on 2 servers Essex-1 Essex-2. Essex-1
runs all services and Essex-2 runs OVS, Quantum-agent nova-compute only.

You can see more details
herehttps://github.com/EmilienM/doc-openstack/blob/master/Documentation/How%20to%20setup%20OpenStack%20Essex.pdf
.

My configurations files are
herehttps://github.com/EmilienM/doc-openstack/tree/master/Configuration%20Filesand
in my documentation.

*Problem Description :*

When an instance is created in ESSEX-1, all is working (network).

But when the VM is started on ESSEX-2, it does not get an IP address. (log
file http://paste.openstack.org/show/14775/)

I'm sure the problem comes from OVS connection with ESSEX-1.

Do I need to configure something like a trunk or a tunnel between Essex-1
Essex-2 ?

I miss something in my configuration, if you have any idea...

Regards

Emilien

Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a écrit :

___
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] Data retrieval method (was: [Metering] schema and counter definitions)

2012-05-03 Thread Julien Danjou

Hi there,

I'll be working on the metering project for the next weeks.

I've started to collect data capture methods that could be used for the
various proposed counters in the blueprint:

http://wiki.openstack.org/EfficientMetering#line-28

So far I didn't check every counter, but I didn't find any good idea
where to hook the agent for v1 and v2. If anyone has one, feel free to
update the wiki.

See you at the next meeting,
-- 
Julien Danjou
// eNovance  http://enovance.com
// ✉ julien.dan...@enovance.com  ☎ +33 1 49 70 99 81

___
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] Can't get fix ip via dhcp and can't accociate Floating ip using quantum

Hi,

I know this problem.

You should :

- Delete the network with nova-manage network delete
--uuid=XXX (you can find the UUID with nova-manage network
quantum_list

- Clean the ovs_quantum database to check if the network has been
deleted

-Clean the nova database and purge all fixed_ips, networks


I remember after that, my problems was solved.


I hope that's works now for you ;-) - Let me now !



Regards


Le jeudi 03 mai 2012 à 17:58 +0800, livemoon a écrit :

 I use quantum as my nova-network in ubuntu 12.04LTS, there are two
 problem:
 
 
 
 1: it can show fix ip, but in vm, the network interfaces have no ips.
 Using dhclient eth0 does not make sense. Using ifconfig eth0 inet
 xxx netmask xxx can work.
 
 
 2: when I accociate floating ip to a vm , it show error, the
 nova-network log is below:
 
 
 2012-05-03 17:51:18 DEBUG nova.rpc.amqp
 [req-f0a4fffa-d6fa-4ab6-9985-1bc4e248edf7
 538eac0210274847a183a988f57fbd59 57eb0d7989c7457aa3818998fbf9a4dc]
 unpacked context: {'user_id': u'538eac0210274847a183a988f57fbd59',
 'roles': [u'Member'], 'timestamp': '2012-05-03T09:51:18.403089',
 'auth_token': 'SANITIZED', 'remote_address': u'127.0.0.1',
 'is_admin': False, 'request_id':
 u'req-f0a4fffa-d6fa-4ab6-9985-1bc4e248edf7', 'project_id':
 u'57eb0d7989c7457aa3818998fbf9a4dc', 'read_deleted': u'no'} from
 (pid=3791)
 _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
 2012-05-03 17:51:18 DEBUG nova.rpc.amqp [-] received
 {u'_context_roles': [u'Member'], u'_msg_id':
 u'c4056c388c26498b83a3909d33e6d4ce', u'_context_read_deleted': u'no',
 u'_context_request_id': u'req-ec319cc9-245d-4808-991b-a00b417b923e',
 u'args': {u'id': u'1'}, u'_context_auth_token': 'SANITIZED',
 u'_context_is_admin': False, u'_context_project_id':
 u'57eb0d7989c7457aa3818998fbf9a4dc', u'_context_timestamp':
 u'2012-05-03T09:51:18.787337', u'_context_user_id':
 u'538eac0210274847a183a988f57fbd59', u'method': u'get_floating_ip',
 u'_context_remote_address': u'127.0.0.1'} from (pid=3791)
 _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
 2012-05-03 17:51:18 DEBUG nova.rpc.amqp
 [req-ec319cc9-245d-4808-991b-a00b417b923e
 538eac0210274847a183a988f57fbd59 57eb0d7989c7457aa3818998fbf9a4dc]
 unpacked context: {'user_id': u'538eac0210274847a183a988f57fbd59',
 'roles': [u'Member'], 'timestamp': '2012-05-03T09:51:18.787337',
 'auth_token': 'SANITIZED', 'remote_address': u'127.0.0.1',
 'is_admin': False, 'request_id':
 u'req-ec319cc9-245d-4808-991b-a00b417b923e', 'project_id':
 u'57eb0d7989c7457aa3818998fbf9a4dc', 'read_deleted': u'no'} from
 (pid=3791)
 _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
 2012-05-03 17:51:18 DEBUG nova.rpc.amqp [-] received
 {u'_context_roles': [u'Member', u'admin'], u'_msg_id':
 u'248d0e0cbff14809978e1b0333621772', u'_context_read_deleted': u'no',
 u'_context_request_id': u'req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1',
 u'args': {u'instance_id': 5, u'instance_uuid':
 u'57f9432f-2177-4635-9692-645ed5a5f2f7', u'host': u'cloud',
 u'project_id': u'57eb0d7989c7457aa3818998fbf9a4dc', u'rxtx_factor':
 1.0}, u'_context_auth_token': 'SANITIZED', u'_context_is_admin':
 True, u'_context_project_id': u'57eb0d7989c7457aa3818998fbf9a4dc',
 u'_context_timestamp': u'2012-05-03T09:51:18.825231',
 u'_context_user_id': u'538eac0210274847a183a988f57fbd59', u'method':
 u'get_instance_nw_info', u'_context_remote_address': u'127.0.0.1'}
 from (pid=3791)
 _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
 2012-05-03 17:51:18 DEBUG nova.rpc.amqp
 [req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1
 538eac0210274847a183a988f57fbd59 57eb0d7989c7457aa3818998fbf9a4dc]
 unpacked context: {'user_id': u'538eac0210274847a183a988f57fbd59',
 'roles': [u'Member', u'admin'], 'timestamp':
 '2012-05-03T09:51:18.825231', 'auth_token': 'SANITIZED',
 'remote_address': u'127.0.0.1', 'is_admin': True, 'request_id':
 u'req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1', 'project_id':
 u'57eb0d7989c7457aa3818998fbf9a4dc', 'read_deleted': u'no'} from
 (pid=3791)
 _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
 2012-05-03 17:51:18 DEBUG nova.utils
 [req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1
 538eac0210274847a183a988f57fbd59 57eb0d7989c7457aa3818998fbf9a4dc]
 Attempting to grab semaphore get_dhcp for method _get_dhcp_ip...
 from (pid=3791)
 inner /usr/lib/python2.7/dist-packages/nova/utils.py:927
 2012-05-03 17:51:18 DEBUG nova.utils
 [req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1
 538eac0210274847a183a988f57fbd59 57eb0d7989c7457aa3818998fbf9a4dc] Got
 semaphore get_dhcp for method _get_dhcp_ip... from (pid=3791)
 inner /usr/lib/python2.7/dist-packages/nova/utils.py:931
 2012-05-03 17:51:18 DEBUG nova.utils
 [req-ac208065-fc2e-4c3b-8fd5-d3661ca33ce1
 538eac0210274847a183a988f57fbd59 57eb0d7989c7457aa3818998fbf9a4dc]
 Attempting to grab semaphore get_dhcp for method _get_dhcp_ip...
 from (pid=3791)
 inner /usr/lib/python2.7/dist-packages/nova/utils.py:927
 2012-05-03 17:51:18 DEBUG nova.utils

Re: [Openstack] [Swift][Keystone] Swift Quotas

2012-05-03 Thread Doug Weimer

On Tue, 01 May 2012, Everett Toews wrote:

 2. Where should the code for Swift quotas live?
 
 It was suggested during the session that this code could live in a
 middleware for Swift. Seems like a reasonable approach to me. I've taken a
 look at some of the code in /swift/common/middleware and it looks
 relatively straight-forward. Any thoughts or suggestions on implementing
 this as middleware?

I think a quota implementation should be split into two separate
middleware pieces; one for quota discovery and one for quota enforcement.
The discovery middleware could place the quota settings for a given tenant
into a set of X-Quota-* headers. The enforcement middleware would then
check for any existing X-Quota-* headers and take action if they were
present. This would allow a deployment to use a custom authentication
system or a new quota enforcement method more easily than if it were
combined in a single middleware.

Thanks,

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] Openstack Essex - Guide for Ubuntu 12.04

2012-05-03 Thread Razique Mahroua

Again thanks for that precious documentation EmilienI'm going to use it for working on the diablo - Essex migration. I'll let you know how it went on ubuntu 10.04. I think it would work.
Nuage  Co - Razique Mahrouarazique.mahr...@gmail.com

Le 30 avr. 2012 à 09:41, Emilien Macchi a écrit :How to setup OpenStack Essex.pdf___
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] Instance IP assignment problem

2012-05-03 Thread Salman Malik


Hi Emilien,

In your configuration you have the following flags:
--flat_network_bridge=br100--floating_range=10.68.5.0/24Can you please tell me 
why you need br100 when you are using br-int with OVS ? Secondly, you seem to 
use floating_range flag as the second flag. I assume that it is the pool of 
addresses that your instances will get IP from, right? It may be worthwhile to 
modify it to fixed_range because Bilal suggested here that this config worked 
for him. 

Let us know.

Thanks,
Salman

Date: Thu, 3 May 2012 08:29:42 -0400
Subject: Re: [Openstack] Instance IP assignment problem
From: soh...@cs.toronto.edu
To: emilien.openst...@gmail.com
CC: ahal...@griddynamics.com; openstack@lists.launchpad.net; salma...@live.com

Oops accidently hit send on my phone.

I had a similar problem before. My problem was that the nic driver on the 
compute instance (your Essex 2) was dropping vlan tags, and then, openvswitch 
wasn't delivering packets. You can check it using tcpdump -e -vvv.

BTW, if you are using virtualbox to run openstack, make sure you are not using 
vbox intel drivers. Use pcnet fast instead.

OVS splinter may also be useful.
Hope that helps.

CheersSoheil
On Thursday, May 3, 2012, Soheil Hassas Yeganeh  wrote:

I had a similar problem before. My problem was that the nic driver on the 
compute instance (your Essex 2) was dropping vlan tags, and then, openvswitch 
wasn

can you find dhcp requests by using tcpdump for example ?
sorry for off-topic but there may be many reasons of such issue with dhcp. 
last one for me was old dhcp client(Ubuntu) and udp checksum error. I have 
essex on centos and was trying ubuntu vm. 



On Thu, May 3, 2012 at 12:48 PM, Emilien Macchi emilien.openst...@gmail.com 
wrote:






  
  


All seems alright but not working yet.





http://paste.openstack.org/show/14791/







I have executed on both servers :



ovs-vsctl add-port br-int eth1





Need I do something else ?



How the DHCP is working in this case ?













Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit :

Then the problem isn't in the instance but in the nova-network service , 
please check if it is working well 


as well as give us the output log when you attempt to create a new instance.













Subject: RE: [Openstack] Instance IP assignment problem

From: emilien.openst...@gmail.com

To: ski...@hotmail.fr

CC: salma...@live.com; openstack@lists.launchpad.net

Date: Thu, 3 May 2012 10:21:37 +0200



Fixed IP







Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit : 


Fixed IP or Floating IP ?











From: emilien.openst...@gmail.com

To: salma...@live.com

Date: Thu, 3 May 2012 09:55:31 +0200

CC: openstack@lists.launchpad.net

Subject: Re: [Openstack] Instance IP assignment problem



Hi,





As I told you, I have also a problem for instance IP assignement.





My architecture :



I use Quantum with OVS plugin on 2 servers Essex-1  Essex-2. Essex-1 
runs all services and Essex-2 runs OVS, Quantum-agent  nova-compute only.



You can see more details here.



My configurations files are here and in my documentation.







Problem Description :



When an instance is created in ESSEX-1, all is working (network).



But when the VM is started on ESSEX-2, it does not get an IP address. 
(log file)



I'm sure the problem comes from OVS connection with ESSEX-1.





Do I need to configure something like a trunk or a tunnel between 
Essex-1  Essex-2 ?



I miss something in my configuration, if you have any idea...





Regards





Emilien





Le mardi 01 mai 2012 à 14:35 -0500, Salman Malik a écrit : 


It may help if you can share the log of your launched instance as 
well. There is a possibility that we both are having the same issue. 

Netstack developers can give a definitive answer to this, but it 
would be interesting to learn what goes wrong with a launched instance.




  ___
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] database migration cleanup

2012-05-03 Thread John Garbutt

I may have missed this in the discussions, but does this impact on upgrade?

I am guessing you have tested Essex - Folsom upgrade, but does this affect 
people upgrading from any of the Essex milestones to Folsom? I guess the deeper 
question is which upgrade paths do we want to maintain...

Thanks,
John

 -Original Message-
 From: openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net
 [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net]
 On Behalf Of Dan Prince
 Sent: 02 May 2012 21:20
 To: Vishvananda Ishaya
 Cc: openstack@lists.launchpad.net
 Subject: Re: [Openstack] database migration cleanup
 
 
 
 - Original Message -
  From: Vishvananda Ishaya vishvana...@gmail.com
  To: Dan Prince dpri...@redhat.com
  Cc: openstack@lists.launchpad.net
  Sent: Thursday, April 26, 2012 4:14:25 PM
  Subject: Re: [Openstack] database migration cleanup
 
  +1.  Might be nice to have some kind of test to verify that the new
  migration leaves the tables in exactly the same state as the old
  migrations.
 
 Hey Vish,
 
 This is an outline of what I did to test MySQL and PostgreSQL to ensure the
 compact migration script generates *exactly* the same schemas as before:
 
 http://wiki.openstack.org/database_migration_testing
 
 As things stand both MySQL and PostgreSQL are exactly the same. I have
 some pending changes that I've found in the schemas that need to be fixed
 in Folsom... but the goal here was to replicate Essex with migration 082 so
 that is what I did.
 
 Sqlite has a few differences (indexes for example). How important is it that
 the Sqlite schema be exactly the same? Unit tests are passing.
 
 Dan
 
 
 
  Vish
 
  On Apr 26, 2012, at 12:24 PM, Dan Prince wrote:
 
   The OpenStack Essex release had 82 database migrations. As these
   grow in number it seems reasonable to clean house from time to time.
   Now seems as good a time as any.
  
   I came up with a first go at it here:
  
   https://review.openstack.org/#/c/6847/
  
   The idea is that we would:
  
   * Do this early in the release cycle to minimize risk.
  
   * Compact all pre-Folsom migrations into a single migration. This
   migration would be used for new installations.
  
   * New migrations during the Folsom release cycle would proceed as
   normal.
  
   * Migrations added during Folsom release cycle could be compacted
   during E release cycle. TBD if/when we do the next compaction.
  
   * Users upgrading from pre-Essex would need to upgrade to Essex
   first. Then Folsom.
  
   --
  
   I think this scheme would support users who follow stable releases
   as well as users who follow trunk very closely.
  
   We talked about this at the conference but I thought this issue
   might be near and dear to some of our end users so it was worth
   discussing on the list.
  
   What are general thoughts on this approach?
  
   Dan (dprince)
  
   ___
   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] Instance IP assignment problem

Hi Salman,

Le jeudi 03 mai 2012 à 09:47 -0500, Salman Malik a écrit :
 Hi Emilien,
 
 In your configuration you have the following flags:
 
 --flat_network_bridge=br100

I'm going to try to change it in both servers.

 --floating_range=10.68.5.0/24

That's actually my public pool, sot it's not my fixed pool (privates
IPs).

After my tests, I will let you know of course.


Thanks,



Regards


 
 Can you please tell me why you need br100 when you are using br-int
 with OVS ? Secondly, you seem to use floating_range flag as the second
 flag. I assume that it is the pool of addresses that your instances
 will get IP from, right? It may be worthwhile to modify it to
 fixed_range because Bilal suggested here that this config worked for
 him. 
 
 Let us know.
 
 Thanks,
 Salman
 
 
 
 
 
 
 __
 Date: Thu, 3 May 2012 08:29:42 -0400
 Subject: Re: [Openstack] Instance IP assignment problem
 From: soh...@cs.toronto.edu
 To: emilien.openst...@gmail.com
 CC: ahal...@griddynamics.com; openstack@lists.launchpad.net;
 salma...@live.com
 
 
 Oops accidently hit send on my phone.
 
 
 I had a similar problem before. My problem was that the nic driver on
 the compute instance (your Essex 2) was dropping vlan tags, and then,
 openvswitch wasn't delivering packets. You can check it using tcpdump
 -e -vvv.
 
 
 
 BTW, if you are using virtualbox to run openstack, make sure you are
 not using vbox intel drivers. Use pcnet fast instead.
 
 
 OVS splinter may also be useful.
 
 
 Hope that helps.
 
 
 Cheers
 Soheil
 
 On Thursday, May 3, 2012, Soheil Hassas Yeganeh wrote:
 
 I had a similar problem before. My problem was that the nic
 driver on the compute instance (your Essex 2) was dropping
 vlan tags, and then, openvswitch wasn
 
 can you find dhcp requests by using tcpdump for
 example ?
 
 
 
 sorry for off-topic but there may be many reasons of
 such issue with dhcp. last one for me was old dhcp
 client(Ubuntu) and udp checksum error. I have essex on
 centos and was trying ubuntu vm. 
 
 
 On Thu, May 3, 2012 at 12:48 PM, Emilien Macchi
 emilien.openst...@gmail.com wrote:
 
 All seems alright but not working yet.
 
 
 http://paste.openstack.org/show/14791/
 
 
 
 I have executed on both servers :
 
 ovs-vsctl add-port br-int eth1
 
 
 Need I do something else ?
 
 How the DHCP is working in this case ?
 
 
 
 
 
 
 Le jeudi 03 mai 2012 à 09:29 +0100, Bilel
 Msekni a écrit : 
 
 Then the problem isn't in the instance
 but in the nova-network service ,
 please check if it is working well 
 as well as give us the output log when
 you attempt to create a new instance.
 
 
 
 __
 
 Subject: RE: [Openstack] Instance IP
 assignment problem
 From: emilien.openst...@gmail.com
 To: ski...@hotmail.fr
 CC: salma...@live.com;
 openstack@lists.launchpad.net
 Date: Thu, 3 May 2012 10:21:37 +0200
 
 Fixed IP
 
 
 
 Le jeudi 03 mai 2012 à 09:15 +0100,
 Bilel Msekni a écrit : 
 
 Fixed IP or Floating IP ?
 
 
 
 __

Re: [Openstack] database migration cleanup

2012-05-03 Thread Dan Prince

- Original Message -
 From: John Garbutt john.garb...@citrix.com
 To: Dan Prince dpri...@redhat.com, Vishvananda Ishaya 
 vishvana...@gmail.com
 Cc: openstack@lists.launchpad.net
 Sent: Thursday, May 3, 2012 10:56:44 AM
 Subject: RE: [Openstack] database migration cleanup

 I may have missed this in the discussions, but does this impact on
 upgrade?

 I am guessing you have tested Essex - Folsom upgrade, but does this
 affect people upgrading from any of the Essex milestones to Folsom?

What this does is compact the pre-Essex (final) migrations into a single 
migration. Users of any of the Essex milestones would need to first upgrade to 
the final Essex release and then upgrade to Folsom.

This seemed like a reasonable approach since most distributions release updates 
that contain the final releases anyway.

 I guess the deeper question is which upgrade paths do we want to
 maintain...

 Thanks,
 John

  -Original Message-
  From:
  openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net
  [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net]
  On Behalf Of Dan Prince
  Sent: 02 May 2012 21:20
  To: Vishvananda Ishaya
  Cc: openstack@lists.launchpad.net
  Subject: Re: [Openstack] database migration cleanup

  - Original Message -
   From: Vishvananda Ishaya vishvana...@gmail.com
   To: Dan Prince dpri...@redhat.com
   Cc: openstack@lists.launchpad.net
   Sent: Thursday, April 26, 2012 4:14:25 PM
   Subject: Re: [Openstack] database migration cleanup

   +1.  Might be nice to have some kind of test to verify that the
   new
   migration leaves the tables in exactly the same state as the old
   migrations.

  Hey Vish,

  This is an outline of what I did to test MySQL and PostgreSQL to
  ensure the
  compact migration script generates *exactly* the same schemas as
  before:

  http://wiki.openstack.org/database_migration_testing

  As things stand both MySQL and PostgreSQL are exactly the same. I
  have
  some pending changes that I've found in the schemas that need to be
  fixed
  in Folsom... but the goal here was to replicate Essex with
  migration 082 so
  that is what I did.

  Sqlite has a few differences (indexes for example). How important
  is it that
  the Sqlite schema be exactly the same? Unit tests are passing.

  Dan

   Vish

   On Apr 26, 2012, at 12:24 PM, Dan Prince wrote:

The OpenStack Essex release had 82 database migrations. As
these
grow in number it seems reasonable to clean house from time to
time.
Now seems as good a time as any.

I came up with a first go at it here:

https://review.openstack.org/#/c/6847/

The idea is that we would:

* Do this early in the release cycle to minimize risk.

* Compact all pre-Folsom migrations into a single migration.
This
migration would be used for new installations.

* New migrations during the Folsom release cycle would proceed
as
normal.

* Migrations added during Folsom release cycle could be
compacted
during E release cycle. TBD if/when we do the next
compaction.

* Users upgrading from pre-Essex would need to upgrade to Essex
first. Then Folsom.

--

I think this scheme would support users who follow stable
releases
as well as users who follow trunk very closely.

We talked about this at the conference but I thought this issue
might be near and dear to some of our end users so it was worth
discussing on the list.

What are general thoughts on this approach?

Dan (dprince)

___
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] Nova idear, thoughts wanted.

2012-05-03 Thread Sandy Walsh

Agreed. That's largely the effort of the Orchestration group.

From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Joshua Harlow [harlo...@yahoo-inc.com]
Sent: Thursday, May 03, 2012 12:35 AM
To: openstack
Subject: [Openstack] Nova idear, thoughts wanted.

Hi all,

I was thinking today about how nova-compute could become more pluggable.
I was wondering if there had been any thought into how say each method, say in 
the compute-manager could almost become a set of stages in a pipeline.
For example the run instance method is really doing the following steps:

run_instance:
   steps:
  - check_instance_not_already_created
  - check_image_size
  - notify_about_instance_usage
  - instance_update(BUILDING)
  - allocate_network
  - prep_block_device
  - spawn:
 - instance_update(BUILD)
 - driver_spawn
 - instance_update(ACTIVE)
   on_failure:
   - deallocate_network

This reminds me slightly of what devstackpy (to be renamed soon) does but 
instead of via code, actions are partially defined via config/persona/ Now 
say if the above steps are plugins (similar to say a paste pipeline) then it 
becomes easy for company Y to add special sauce Z before or after stage W. I 
was just wondering what people thought about this. It sort of makes nova more 
of a orchestrator that loads plugins that perform various pipelines, where in 
nova’s case those pipelines are VM related.

Comments welcome. This might already have been thought of, but if so, that’s ok 
also :-)

-Josh
___
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 API question

2012-05-03 Thread Dolph Mathews

The philosophy in essex is that it's meaningless for a user to have a role
without that role being applied to a tenant, so the call that's implemented
is:

GET /tenants/{tenant_id}/users/{user_id}/roles

Calling this instead should get you an HTTP 501 stating User roles not
supported: tenant ID required.

GET /users/{user_id}/roles

Also, the term roleRefs was deprecated late in the diablo cycle (AFAIK)
in favor of roles.

-Dolph

On Wed, May 2, 2012 at 3:44 PM, Luis Gervaso l...@woorea.es wrote:

 Hi,

 In Diablo was:

 GET /users/{user_id}/roleRefs

 In Essex it is maintained for compatibility reasons. I understand that
 this is the obsolete now.

 I can find:

 PUT  DELETE /users/{user_id}/roles/OS-KSADM/{role_id}

 How can get all the roles having a user_id?

 GET /users/{user_id}/roles (i can't find this on stable/essex)

 Returning role list with tenant associated

 Another option that would work for me is:

 GET /users/{user_id}/tenants

 Returning tenant list with role list associated per tenant


 When i GET /user/{user_id} i obtain only this info

 {user: {name: admin, enabled: true, email: ad...@example.com,
 id: ef1e63df85b641d7bf3c575bb8670cef, tenantId: null}}

 Regards

 --
 ---
 Luis Alberto Gervaso Martin
 Woorea Solutions, S.L
 CEO  CTO
 mobile: (+34) 627983344
 luis@ luis.gerv...@gmail.comwoorea.es



 ___
 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] [Swift][Keystone] Swift Quotas

2012-05-03 Thread Kevin L. Mitchell

I missed the first post(s) in this thread, but I should probably put out
there that I'm currently working on refactoring quotas in Nova; see:

  * https://blueprints.launchpad.net/nova/+spec/quota-refactor
  * https://github.com/klmitch/nova/tree/quota-atomicity
  * https://review.openstack.org/#/c/6774
  * https://review.openstack.org/#/c/7048

To get a sense of what I'm doing.  I've also been thinking about the
constraints of an external quota manager, but haven't gotten much
further than some kind of RPC or REST-based API.

(Note I haven't been strongly considering integrating this with Keystone
for a couple of reasons: 1. I tend to prefer the UNIX paradigm of doing
one thing well; 2. I want to ensure that this external quota manager is
usable for those who choose to use something other than Keystone.)

Feel free to ask me questions; I'm sure there's a lot of stuff I've
thought of that may not be obvious from the above references, and your
questions will probably help me articulate it better :)
-- 
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

Re: [Openstack] Missing(?) keystone service catalog

2012-05-03 Thread Dolph Mathews

service-list calls the admin API (port 35357), but the auth_url you
provided was port 5000. I don't think the current keystoneclient is smart
enough to try and switch to the correct endpoint. If you have an admin
role, switching to port 35357 should work for you.

Additionally, you won't get a service catalog without also providing a
tenant, so that behavior is by design as well. Try --os_tenant_name or
--os_tenant_id if using the client, or providing tenantName or tenantId
in your auth object for curl.

-Dolph

On Wed, May 2, 2012 at 11:38 PM, Nick Lothian nick.loth...@gmail.comwrote:

 I'm having some trouble using the Keystone API.

 When I run

 keystone --os_username=admin --os_password=password --os_auth_url=
 http://192.168.1.50:5000/v2.0/ service-list

 I get the following:

 No handlers could be found for logger keystoneclient.v2_0.client
 Unable to communicate with identity service: 404 Not Found

 The resource could not be found.

. (HTTP 404)


 The keystone log shows the following:

 (eventlet.wsgi.server): 2012-05-03 14:03:12,840 DEBUG wsgi write
 192.168.1.50 - - [03/May/2012 14:03:12] GET /v2.0/OS-KSADM/services
 HTTP/1.1 404 176 0.008028


 Additionally, if I use curl to call the keystone API directly (as
 documented at http://keystone.openstack.org/api_curl_examples.html#id4)
 my whole serviceCatalog section is empty (serviceCatalog: {})

 I am using a default devstack installation.

 What am I missing?

 ___
 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] Nova subsystem branches and feature branches

2012-05-03 Thread Monty Taylor



On 05/03/2012 05:24 AM, Thierry Carrez wrote:

(snip things I pretty much agree with)

 (I'm not sure gerrit is right for this. Why not just do it in 
 folk's github forks? I think all people are looking for is for 
 people to be more aware of feature branches. How about if you put 
 details of your feature branch in the blueprint for the feature?)

 (If not using gerrit, can developers configure Jenkins to CI their 
 branch? Or is Smokestack the right tool?)
 
 I think preserving the ability to run your branch through integration
 testing is a necessary prerequisite of the new model.

Agree, otherwise it gets weird.

HOWEVER - I also agree that the current UI as we're presenting it might
not be optimal. Let me follow up with some sketched out thoughts on how
we can address both concerns.

 Thanks again for starting the discussion on this. I'll meet with Jim
 Blair (and hopefully Monty) next week to brainstorm solutions, so
 discussing the needed properties of the system is a very nice step forward.
 
 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] Nova subsystem branches and feature branches

Hey,

On Thu, 2012-05-03 at 14:24 +0200, Thierry Carrez wrote:
 Mark McLoughlin wrote:

  Ok, what are subsystem branches and how would they work?
  [...]
- It would be up to the project dictators to help drive patches 
  through the right subsystem branches - e.g. they might object if 
  one subsystem maintainer merged a patch that inappropriately cut 
  into another subsystem or they might refuse to merge a given patch
  into the main branch unless it went through the appropriate 
  subsystem branch.
  
  (In gerrit, this would mean a small team or single person who can 
  +1 approve merge proposals on master. They would -1 proposals
  submitted against master which should have been submitted against a 
  subsystem branch.)
 
 IIUC under this model we would still accept changes to be directly
 proposed to master (think bug fixes, or features that don't belong into
 a specific subsystem) ? For those we would still need a review team
 (separate from the project dictators who do the second-stage review)
 with wide expertise on all things Nova.

Yes. Until we get to a point where every change should obviously go
through a particular subsystem branch, you need this. And we may never
need to get there.

Even if you had subsystem branches for everything, allowing people to go
direct to master is a nice way to be sure that people don't need to be
blocked by a subsystem maintainer. If a subsystem maintainer is
non-responsive or totally non-cooperative, then just go directly to
master. This only works if the project dictator flames/ignores anyone
abusing this route.

On the practical point about project dictators vs review team, you
can give +1 approve rights to the former and give +2 review rights to
both.

That means the dictators need to approve everything coming into master,
but that should mostly just be (1) signing off on a submission from a
subsystem maintainer and (2) signing off on a review which has 2 +2s
from the review team.

  [...]
- Plausible subsystem branches are e.g.:
  
- OpenStack APIs
- EC2 API
- virt
   - libvirt driver
   - xenapi driver
   - vmware driver
- networking
- volumes
- scheduler
- RPC
  
  Deciding which areas make sense as a subsystem branch is 
  non-trivial.
  
  Should there be a DB subsystem? Probably not, because that would 
  mean every new feature needs to come through this branch or, 
  alternatively, the DB maintainer would need to accept DB schema 
  additions without the context of how it's being used higher up the 
  stack.
  
  Ok, so why does it make sense to have an OpenStack APIs 
  subsystem? Don't all features affect that branch too? Well, maybe, 
  but the APIs really do need strong oversight. Perhaps we can be 
  confident that we can add e.g. a new scheduler feature through the
  scheduler branch and then later merge any API additions through the 
  APIs branch.
 
 I think there are two types of subsystems making sense: those areas of
 code that are already separated into a self-contained module, and those
 areas of the code where editorial control / extra expertise is needed.
 
 As an example, sometimes I wish that all proposed run-as-root commands
 would be through a security review before being accepted in master
 (because sometimes they are overkill and needlessly increase the
 run-as-root surface, and some other times they annihilate our efforts at
 filtering nova-root escalation). This is difficult to do with a common
 team of 25+ reviewers.

Yes, but it would be difficult to co-ordinate this stuff as a separate
subsystem tree. You'd have two options:

  - Any rootwrap changes must be incorporated separately into the
rootwrap subsystem tree before they can be merged into another 
subsystem tree. But how can you review rootwrap changes without 
seeing the context of why they're needed?

  - Any rootwrap changes get merged into the various subsystem trees 
first, but they must then go through the rootwrap subsystem tree 
before being merged into master.

In reality, I think you just need to trust the combination of the
subsystem maintainers and project dictators to be on top of this kind of
stuff. Or at least that they would be sensible to pull in an appropriate
reviewer to double check it before merging it.

  And how about feature branches?
  
- Feature branches are relatively short-lived (i.e. weeks or months
  rather than years) branches for a specific feature. They are a
  mechanism for developers to work on a patch series in the open until
  the feature is complete enough to be merged into a subsystem branch
  or master.
  
  (I'm not sure gerrit is right for this. Why not just do it in 
  folk's github forks? I think all people are looking for is for 
  people to be more aware of feature branches. How about if you put

Re: [Openstack] Nova subsystem branches and feature branches

On Thu, 2012-05-03 at 16:46 +0100, Mark McLoughlin wrote:
 Hey,
 
 On Thu, 2012-05-03 at 14:24 +0200, Thierry Carrez wrote:
  Mark McLoughlin wrote:

   And how about feature branches?
   
 - Feature branches are relatively short-lived (i.e. weeks or months
   rather than years) branches for a specific feature. They are a
   mechanism for developers to work on a patch series in the open until
   the feature is complete enough to be merged into a subsystem branch
   or master.
   
   (I'm not sure gerrit is right for this. Why not just do it in 
   folk's github forks? I think all people are looking for is for 
   people to be more aware of feature branches. How about if you put 
   details of your feature branch in the blueprint for the feature?)
   
   (If not using gerrit, can developers configure Jenkins to CI their 
   branch? Or is Smokestack the right tool?)
  
  I think preserving the ability to run your branch through integration
  testing is a necessary prerequisite of the new model.
 
 Yes, it's only really needed at the point where the feature branch is
 merged into the subsystem tree. The developer should be able to break
 stuff on their WIP feature branch if they wish, since they'll be expect
 to rebase/fix before proposing it to be merged into the subsystem tree.
 
 So Jenkins/Smokestack would be nice tools to provide to folks working on
 feature branches, but they don't need to be gating.

Put another way - the gating tests should be run on every single commit
that is ultimately merged into master.

However, this should not mean that we apply gating to every commit on
feature branches, since feature branches are allowed to rebase until
they are merged into a subsystem tree or directly into master.

Cheers,
Mark.


___
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] Missing(?) keystone service catalog

2012-05-03 Thread Adam Spiers

Nick Lothian (nick.loth...@gmail.com) wrote:
 My /etc/keystone/keystone.conf says:
 
 [catalog]
 template_file = /etc/keystone/default_catalog.templates
 # dynamic, sql-based backend (supports API/CLI-based management commands)
 driver = keystone.catalog.backends.templated.TemplatedCatalog

[snipped]

 Shouldn't the API give a read-only view of the service catalog if CRUD
 operations are unavailable?

That's what I would have expected too.

___
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] Missing(?) keystone service catalog

2012-05-03 Thread Joseph Heck

The service-list should give you a list of the services in the catalog, driven 
by the template. What's in your catalog file at 
/etc/keystone/default_catalog.templates? It sounds like it's empty - that's 
what it's reading to report on services. You won't be able to use any of the 
add/remove CRUD operations unless you switch to the SQL based back-end, but 
service-list should do what you want.

When you did the curl, I assume you used the token retrieved from the admin 
user with the /tokens/{token_id}/endpoints call?

-joe

On May 3, 2012, at 2:54 AM, Nick Lothian wrote:

 My /etc/keystone/keystone.conf says:
 
 [catalog]
 template_file = /etc/keystone/default_catalog.templates
 # dynamic, sql-based backend (supports API/CLI-based management commands)
 driver = keystone.catalog.backends.templated.TemplatedCatalog
 
 (This is the default from devstack).
 
 I did look at that, but made the mistake of assuming the comment was correct 
 and referred to the next line, especially since the next, commented out entry 
 said it was the file-based one. My mistake I guess - I'll try the SQL one. 
 
 Shouldn't the API give a read-only view of the service catalog if CRUD 
 operations are unavailable?
 
 On Thu, May 3, 2012 at 4:32 PM, Rafael Durán Castañeda 
 rafadurancastan...@gmail.com wrote:
 On 05/03/2012 06:38 AM, Nick Lothian wrote:
 I'm having some trouble using the Keystone API.
 
 When I run 
 
 keystone --os_username=admin --os_password=password 
 --os_auth_url=http://192.168.1.50:5000/v2.0/ service-list
 
 I get the following:
 
 No handlers could be found for logger keystoneclient.v2_0.client
 Unable to communicate with identity service: 404 Not Found
 
 The resource could not be found.
 
. (HTTP 404)
 
 
 The keystone log shows the following:
 
 (eventlet.wsgi.server): 2012-05-03 14:03:12,840 DEBUG wsgi write 
 192.168.1.50 - - [03/May/2012 14:03:12] GET /v2.0/OS-KSADM/services 
 HTTP/1.1 404 176 0.008028
 
 
 Additionally, if I use curl to call the keystone API directly (as documented 
 at http://keystone.openstack.org/api_curl_examples.html#id4) my whole 
 serviceCatalog section is empty (serviceCatalog: {})
 
 I am using a default devstack installation.
 
 What am I missing?
 
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
 I think DevStack is using TemplatedCatalog as catalog backend and it doesn't 
 support CRUD. If you need CRUD operations you can use SQL backend.
 
 ___
 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] [Metering] how should it be done ? ( Was: schema and counter definitions)

2012-05-03 Thread Loic Dachary

On 05/03/2012 09:58 AM, Robert Collins wrote:
 On Wed, May 2, 2012 at 10:28 AM, Loic Dachary l...@enovance.com wrote:

 As I wrote in a previous mail, once we manage to provide an implementation 
 that proves useful, we will be in a position to approach the core OpenStack 
 components. Integrating the metering agents as part of the core component, 
 much in the same way it's currently done in nova. That will reduce the 
 overall complexity of deploying OpenStack with metering (which must not be 
 mandatory). However, there is very little chance that all components 
 developed around OpenStack are convinced and there will always be a need for 
 a metering that is external to the component. Therefore, even if metering 
 eventually manages to become a first class concern for the core OpenStack 
 components, the proposed architecture of the metering project ( per node 
 agents when necessary and a collector harvesting them into a storage ) will 
 keep being used for other components.

 Do you think I'm wrong ? We're at a very early stage and now is the time to 
 question everything :-)
 I would avoid node agents as a primary interface: they can always be
 written to workaround components that don't provide metering
 themselves -  like the nagios plugins example given by Andrew. node
 agents are more complex than implementing metering in each component
 because they require a handoff, parsing of local logs (or whatever
 relevant store the component uses), and they are another process to
 keep running; they probably devolve to polling, and polling is a good
 way to use a lot of resources up :(.

 The key thing I see is having a clear contract for how metering is
 done, so that anyone writing a new component can add metering easily.
 This is easier for the component author than having to write their
 component *and* write a metering node agent for that component.

 E.g.
  - define the signals, extension points, and python API for
 implementing metering in a component.
  - implement a no-op implementation of that metering API which
 discards all data.
  - implement a AMQP based implementation which shoves all the data out
 to some queue somewhere.
  - submit patches to existing components to add metering
  - and if a component owner rejects metering altogether, you can still
 implement a node agent to gather the data and push it out via the
 metering API - that will always be an option.

 Then we will have a situation where:
  - new components can meter easily
  - folk with different delivery constraints can change the network
 layer easily (drop in a different implementation of the Python API)
 [e.g. to log directly to a NoSQL store]
I could not agree more. This way we have the best of both worlds : integration 
in components when possible and standalone agents when it can't be done for 
whatever reason.

Cheers


-- 
Loïc Dachary Chief Research Officer
// eNovance labs   http://labs.enovance.com
// ✉ l...@enovance.com  ☎ +33 1 49 70 99 82


___
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] [nova-api] No module named nova_keystone_context

2012-05-03 Thread Joseph Heck

Morning Leander,

The key file is what's in your nova api-paste.ini file - it's what is defining 
the WSGI pipeline that loads up the various bits that set context. What version 
of Nova and Keystone are you running?

I rather suspect you might have updated your code without also getting the 
updates into your api-paste.ini file.

-joe

On May 3, 2012, at 3:28 AM, Leander Bessa wrote:

 Hello,
 
 Every time i start nova-api i get the following output:
 
 nova-api --config-file=/etc/nova/nova.conf 
 2012-04-30 15:23:51 CRITICAL nova [-] No module named nova_keystone_context
 2012-04-30 15:23:51 TRACE nova Traceback (most recent call last):
 2012-04-30 15:23:51 TRACE nova   File /usr/bin/nova-api, line 51, in 
 module
 2012-04-30 15:23:51 TRACE nova servers.append(service.WSGIService(api))
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/nova/service.py, line 326, in __init__
 2012-04-30 15:23:51 TRACE nova self.app = self.loader.load_app(name)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/nova/wsgi.py, line 388, in load_app
 2012-04-30 15:23:51 TRACE nova return deploy.loadapp(config:%s % 
 self.config_path, name=name)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in 
 loadapp
 2012-04-30 15:23:51 TRACE nova return loadobj(APP, uri, name=name, **kw)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in 
 loadobj
 2012-04-30 15:23:51 TRACE nova return context.create()
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in 
 create
 2012-04-30 15:23:51 TRACE nova return self.object_type.invoke(self)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in 
 invoke
 2012-04-30 15:23:51 TRACE nova **context.local_conf)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call
 2012-04-30 15:23:51 TRACE nova val = callable(*args, **kw)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/nova/api/openstack/urlmap.py, line 163, in 
 urlmap_factory
 2012-04-30 15:23:51 TRACE nova app = loader.get_app(app_name, 
 global_conf=global_conf)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in 
 get_app
 2012-04-30 15:23:51 TRACE nova name=name, 
 global_conf=global_conf).create()
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in 
 create
 2012-04-30 15:23:51 TRACE nova return self.object_type.invoke(self)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in 
 invoke
 2012-04-30 15:23:51 TRACE nova **context.local_conf)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call
 2012-04-30 15:23:51 TRACE nova val = callable(*args, **kw)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/nova/api/auth.py, line 48, in 
 pipeline_factory
 2012-04-30 15:23:51 TRACE nova filters = [loader.get_filter(n) for n in 
 pipeline[:-1]]
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 354, in 
 get_filter
 2012-04-30 15:23:51 TRACE nova name=name, 
 global_conf=global_conf).create()
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 366, in 
 filter_context
 2012-04-30 15:23:51 TRACE nova FILTER, name=name, global_conf=global_conf)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 458, in 
 get_context
 2012-04-30 15:23:51 TRACE nova section)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 517, in 
 _context_from_explicit
 2012-04-30 15:23:51 TRACE nova value = import_string(found_expr)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 22, in 
 import_string
 2012-04-30 15:23:51 TRACE nova return pkg_resources.EntryPoint.parse(x= 
 + s).load(False)
 2012-04-30 15:23:51 TRACE nova   File 
 /usr/lib/python2.7/dist-packages/pkg_resources.py, line 1989, in load
 2012-04-30 15:23:51 TRACE nova entry = __import__(self.module_name, 
 globals(),globals(), ['__name__'])
 2012-04-30 15:23:51 TRACE nova ImportError: No module named 
 nova_keystone_context
 2012-04-30 15:23:51 TRACE nova 
 Exception KeyError: KeyError(140300442122736,) in module 'threading' from 
 '/usr/lib/python2.7/threading.pyc' ignored
 
 
 Am i missing something from my config file, or is it something else?
 
 Here's my nova.conf file:
 
 [DEFAULT]
 # LOG/State
 verbose=True
 # Authentication

Re: [Openstack] Energy efficiency

2012-05-03 Thread Yuriy Taraday

Fill-first cost function returns the amount of free RAM. By default it
is negated (multiplied by -1.0), so the less free RAM is better.

I think, this is a bit misguiding, but was changed right before Essex
(see https://bugs.launchpad.net/nova/+bug/965732 ).

Kind regards, Yuriy.


On Thu, May 3, 2012 at 8:05 PM, Lorin Hochstein
lo...@nimbisservices.com wrote:
 Yuriy:


 On May 3, 2012, at 4:46 AM, Yuriy Taraday wrote:

 Just note that since Essex release Nova by default use fill-first cost
 function, meaning that nodes with less free RAM will be preferred for
 new instances.

 Kind regards, Yuriy.


 I thought the default behavior in essex was spread-first:

 From:

 https://github.com/openstack/nova/blob/stable/essex/nova/scheduler/least_cost.py#L41

     cfg.FloatOpt('compute_fill_first_cost_fn_weight',
              default=-1.0,
                help='How much weight to give the fill-first cost function. '
                     'A negative value will reverse behavior: '
                     'e.g. spread-first'),
     ]




 Take care,

 Lorin
 --
 Lorin Hochstein
 Lead Architect - Cloud Services
 Nimbis Services, Inc.
 www.nimbisservices.com



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

Re: [Openstack] questions about IP addressing and network config

2012-05-03 Thread Jimmy Tsai

I tried with following tests:
1)
add firewall_driver = nova.virt.firewall.IptablesFirewallDriver to
nova.conf
restart nova-compute
Change the following lines in
/usr/share/pyshared/nova/virt/libvirt/firewall.py
self._define_filter(self._filter_container('nova-base',
   ['no-mac-spoofing',
'no-ip-spoofing',
'no-arp-spoofing',

'allow-dhcp-server']))
to
self._define_filter(self._filter_container('nova-base',

['allow-dhcp-server']))
then flush ebtables ruleset : ebtables -t nat -F
stop libvirt-bin  start libvirt-bin
Still generate the anti-spoofing rules

2)
change the action='drop' with 'accept' to following XML files
sed -i s/action='drop'/ action='accept'/g
/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml
sed -i s/action='drop'/ action='accept'/g /etc/libvirt/nwfilter/
no-arp-mac-spoofing.xml
sed -i s/action='drop'/ action='accept'/g /etc/libvirt/nwfilter/
no-ip-spoofing.xml
sed -i s/action='drop'/ action='accept'/g /etc/libvirt/nwfilter/
no-mac-broadcast.xml
sed -i s/action='drop'/ action='accept'/g /etc/libvirt/nwfilter/
no-mac-spoofing.xml
sed -i s/action='drop'/ action='accept'/g /etc/libvirt/nwfilter/
no-other-l2-traffic.xml
sed -i s/action='drop'/ action='accept'/g /etc/libvirt/nwfilter/
no-other-rarp-traffic.xml

then flush ebtables ruleset : ebtables -t nat -F
stop libvirt-bin  start libvirt-bin

Okay, I can see accept rules, but the kvm processes is also gone at the
same time.
Don't know why.

still waiting for some help!!

-Jimmy





2012/5/3 Yong Sheng Gong gong...@cn.ibm.com

 It seems change https://review.openstack.org/#/c/6569/ can help. Please
 see how it add a new configuration item to remove some filters.


 -openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -

 To: Mike Scherbakov mih...@gmail.com mih...@gmail.com
 From: Jimmy Tsai cmi...@gmail.com cmi...@gmail.com
 Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
 Date: 05/03/2012 01:45AM
 Cc: openstack@lists.launchpad.net, jimmy.t...@104.com.tw
 Subject: Re: [Openstack] questions about IP addressing and network config


 Hi Mike,

 I really need to bind loopback IP on my environment, I use the command
 ebtables -t nat -F will flush the ebtables rule, so I can bind any IP I
 wish,
 but if I do stop libvirt-bin and start libvir-bin, the security rules will
 be applied again,
 if I remark no-ip-spoofing  no-arp-spoofing on file
 /etc/libvirt/nwfilter/nova-base.xml, after launching a instance, the file
 will reset to default,
 I think I use the wrong way, Is there any way to ignore the nova-base rule
 on /usr/lib/python2.7/dist-packages/nova/virt/libvirt/firewall.py ?

 Thanks for you help.
 -Jimmy

 2012/4/27 Mike Scherbakov mih...@gmail.com

 Jimmy,
 Nova is designed to manage IP addresses.
 That means that even with Flat manager it will be allocating IP addresses
 for you,
  storing them in DB. The difference btw FlatDHCP is Flat injects
 /etc/network/interfaces to the instance,
 not providing IP by DHCP. So, anti-spoofing rules should be the same (I
 never checked though for Flat).

 If you want to provide your own addresses to instances, I believe you
 will need to extend nova code
 to provide your custom IP address in API request, and then if it's not
 already allocated, it should get allocated.

 Regards,

 On Fri, Apr 27, 2012 at 3:27 PM, Jimmy Tsai cmi...@gmail.com wrote:

 Thanks Vish  Mike.

 It works very well after flush the anti-spoofing rules , I  change the
 IP address and bind alias IP to an interface,
 but when I restart nova-network and nova-compute , I can't ping neither
 the IP I changed nor the instances I haven't changed.
 I'll try to figure out what happened with that !!

 Even I change the IP address, I can't not see the correct address on
 Dashboard, because the record of nova.fixed_ips not changed.
 I should try with FlatManager to allocate static IP.

 Thanks,
 -Jimmy


 2012/4/27 Mike Scherbakov mih...@gmail.com



 On Thu, Apr 26, 2012 at 10:31 PM, Vishvananda Ishaya 
 vishvana...@gmail.com wrote:


 On Apr 25, 2012, at 7:31 PM, Jimmy Tsai wrote:

 
  Hi everyone,
 
  I'm running with Essex 2012.1,
  and have some questions about the nova network operation,
 
  1. Is it possible manually assigned IP address to a launched
 instance, my situation is :
  after instance boot up (OS: CentOS 6.2), I changed the
 /etc/sysconfig/network-scripts/ifcfg-eth0 setting
  from dhcp to static (the same subnet as created by command :
 nova-manage create network), and restart the network service,
  And then I couldn't ssh or ping the instance from other server with
 the same subnet.
  What is the problem ?  I checked the iptables policies on the
 compute host, and find nothing about the DROP packets.
  I also tried to changed the record from nova.fixed_ips table and
 libvirt.xml of the instance, then reboot the

[Openstack] [QA] Aligning smoke / acceptance / promotion test efforts

2012-05-03 Thread Jay Pipes


Hi all,

I'd like to get some alignment on the following:

1) The definition of what is a smoke test
2) How we envision the Tempest project's role in running such tests

First, a discussion on #1.

There seem to be very loose semantics used to describe what a smoke 
test is. Some groups use the term smoke test. Others use promotion 
test. And still others use acceptance test.


I will only use the term smoke test here and I'm hoping we can 
standardize on this term to reduce confusion.


Now, what exactly *is* a smoke test? According to Wikipedia [1], a smoke 
test is preliminary to further testing, intended to reveal simple 
failures severe enough to reject a prospective software release. 
Further, it states that smoke tests are a subset of test cases that 
cover the most important functionality of a component or system are 
selected and run, to ascertain if the most crucial functions of a 
program work correctly.


From the above, I would surmise that smoke tests should have all three 
of the following characteristics:


* Test basic operations of an API, usually in a specific order that 
makes sense as a bare-bones use case of the API
* Test only the correct action paths -- in other words, smoke tests do 
not throw random or invalid input at an API

* Use the default client tools to complete the actions
* Take a short amount of time to complete

Currently in the OpenStack community, there are a number of things that 
act as smoke tests, or something like them:


* The devstack exercises [2]
* The Torpedo tests that SmokeStack runs against proposed commits to 
core projects [3]

* The next incarnation of the Kong tests -- now called exerstack [4]
* Tests within Tempest that are annotated (using the nosetest @attr 
decorator) with type=smoke
* Various companies have promotion tests that are essentially the same 
as exercises from devstack -- for instance, at HPCS we have a set of 
promotion tests that do virtually the exact same thing as the devstack 
exercises, only are a mixture of some Python and bash code and have 
additional stuffs like validating the HPCS billing setup


It would be super-awesome if Tempest could be used to remove some of 
this duplication of efforts.


However, before this can happen, a number of improvements need to be 
made to Tempest. The issue with the smoke tests in Tempest is that 
they aren't really smoke tests. They do not use the default client tools 
(like novaclient, keystoneclient, etc) and are not annotated consistently.


I would like to have Tempest have a full set of real smoke tests that 
can be used as the upstream core projects' gates.


Steps I think we need to take:

* Create a base test class that uses the default CLI tools instead of 
raw HTTP calls
* Create a set of Manager classes that would provide a config object and 
one or more client objects to test cases -- this is similar to the 
tempest.openstack.Manager class currently in the source code, but would 
allow using the default project client libraries instead of the raw HTTP 
client currently in Tempest
* Allow test cases that derive from the base SmokeTest class to use an 
ordered test method system -- e.g.  test_001_foo, test_002_bar
* Have the base smoke test case class automatically annotate all of its 
test methods with type=smoke so that we can run all smoke tests with:


nosetests --attr=type=smoke tempest

I have put together some code that shows the general idea as a draft 
patchset [5]


I've asked David to include this in the QA meeting agenda for this week. 
Hopefully interested folks can take a look at the example code in the 
patchset above, give it some thought, and we can chat about this on 
Thursday.


Best,
-jay

[1] http://en.wikipedia.org/wiki/Smoke_testing#Software_development
[2] https://github.com/openstack-dev/devstack/tree/master/exercises
[3] https://github.com/dprince/torpedo
[4] https://github.com/rcbops/exerstack/
[5] https://review.openstack.org/#/c/7069/

___
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] [metering] interesting notes on billing issues with Azure

2012-05-03 Thread Doug Hellmann

Via @jessenoller: http://www.nasuni.com/blog/177-azure_fair_and_balanced
___
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] Nova subsystem branches and feature branches

2012-05-03 Thread Monty Taylor



On 05/03/2012 08:50 AM, Mark McLoughlin wrote:
 On Thu, 2012-05-03 at 16:46 +0100, Mark McLoughlin wrote:
 Hey,

 On Thu, 2012-05-03 at 14:24 +0200, Thierry Carrez wrote:
 Mark McLoughlin wrote:
 
 And how about feature branches?

   - Feature branches are relatively short-lived (i.e. weeks or months
 rather than years) branches for a specific feature. They are a
 mechanism for developers to work on a patch series in the open until
 the feature is complete enough to be merged into a subsystem branch
 or master.

 (I'm not sure gerrit is right for this. Why not just do it in 
 folk's github forks? I think all people are looking for is for 
 people to be more aware of feature branches. How about if you put 
 details of your feature branch in the blueprint for the feature?)

 (If not using gerrit, can developers configure Jenkins to CI their 
 branch? Or is Smokestack the right tool?)

 I think preserving the ability to run your branch through integration
 testing is a necessary prerequisite of the new model.

 Yes, it's only really needed at the point where the feature branch is
 merged into the subsystem tree. The developer should be able to break
 stuff on their WIP feature branch if they wish, since they'll be expect
 to rebase/fix before proposing it to be merged into the subsystem tree.

 So Jenkins/Smokestack would be nice tools to provide to folks working on
 feature branches, but they don't need to be gating.
 
 Put another way - the gating tests should be run on every single commit
 that is ultimately merged into master.
 
 However, this should not mean that we apply gating to every commit on
 feature branches, since feature branches are allowed to rebase until
 they are merged into a subsystem tree or directly into master.

Yes. This all makes sense to me and I can be in support of this plan
(and continue work on making that process of moving from feature branch
to subsystem branch is not painful)

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

Re: [Openstack] [Metering] schema and counter definitions

2012-05-03 Thread Turner, Whit (Cloud Services)

Hi - I think a flexible aggregation scheme is needed; the levels of aggregation 
available should be definable in the meter independent of the sources of usage 
data themselves. If invoices need to be very granular down to the lowest 
possible level, then this drives higher data requirements all through the 
processing chain, including the rating engine. Traditional systems tend to pass 
less granular (more highly aggregated) data into the rating engine so that bill 
runs and invoices can be generated efficiently. At cloud-scale, this can be 
problematic. Given some “big data” approaches, though, this could be handled in 
a more granular and real-time fashion.

 

Regards

 

Whit

 

From: openstack-bounces+whit.turner=hp@lists.launchpad.net 
[mailto:openstack-bounces+whit.turner=hp@lists.launchpad.net] On Behalf Of 
Doug Hellmann
Sent: Monday, April 30, 2012 2:03 PM
To: Loic Dachary
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [Metering] schema and counter definitions

 

 

On Mon, Apr 30, 2012 at 11:43 AM, Loic Dachary l...@enovance.com wrote:

On 04/30/2012 03:49 PM, Doug Hellmann wrote: 

 

On Mon, Apr 30, 2012 at 6:46 AM, Loic Dachary l...@enovance.com wrote:

On 04/30/2012 12:15 PM, Loic Dachary wrote:
 We could start a discussion from the content of the following sections:

 http://wiki.openstack.org/EfficientMetering#Counters

I think the rationale of the counter aggregation needs to be explained. My 
understanding is that the metering system will be able to deliver the following 
information: 10 floating IPv4 addresses were allocated to the tenant during 
three months and were leased from provider NNN. From this, the billing system 
could add a line to the invoice : 10 IPv4, $N each = $10xN because it has been 
configured to invoice each IPv4 leased from provider NNN for $N.

It is not the purpose of the metering system to display each IPv4 used, 
therefore it only exposes the aggregated information. The counters define how 
the information should be aggregated. If the idea was to expose each resource 
usage individually, defining counters would be meaningless as they would 
duplicate the activity log from each OpenStack component.

What do you think ?

 

At DreamHost we are going to want to show each individual resource (the IPv4 
address, the instance, etc.) along with the charge information. Having the 
metering system aggregate that data will make it difficult/impossible to 
present the bill summary and detail views that we want. It would be much more 
useful for us if it tracked the usage details for each resource, and let us 
aggregate the data ourselves.

 

If other vendors want to show the data differently, perhaps we should provide 
separate APIs for retrieving the detailed and aggregate data.

 

Doug

 

Hi,

For the record, here is the unfinished conversation we had on IRC

(04:29:06 PM) dhellmann: dachary, did you see my reply about counter 
definitions on the list today?
(04:39:05 PM) dachary: It means some counters must not be aggregated. Only the 
amount associated with it is but there is one counter per IP. 
(04:55:01 PM) dachary: dhellmann: what about this :the id of the ressource 
controls the agregation of all counters : if it is missing, all resources of 
the same kind and their measures are aggregated. Otherwise only the measures 
are agreggated. http://wiki.openstack.org/EfficientMetering?action=diff 
http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 
rev2=40rev1=39
(04:55:58 PM) dachary: it makes me a little unconfortable to define such an 
ad-hoc grouping 
(04:56:53 PM) dachary: i.e. you actuall control the aggregation by chosing 
which value to put in the id column
(04:58:43 PM) dachary: s/actuall/actually/
(05:05:38 PM) ***dachary reading http://www.ogf.org/documents/GFD.98.pdf
(05:05:54 PM) dachary: I feel like we're trying to resolve a non problem here
(05:08:42 PM) dachary: values need to be aggregated. The raw input is a full 
description of the resource and a value ( gauge ). The question is how to 
control the aggregation in a reasonably flexible way. 
(05:11:34 PM) dachary: The definition of a counter could probably be described 
as : the id of a resource and code to fill each column associated with it.

I tried to append the following, but the wiki kept failing. 

Propose that the counters are defined by a function instead of being fixed. 
That helps addressing the issue of aggregating the bandwidth associated to a 
given IP into a single counter.

Alternate idea : 
 * a counter is defined by
  * a name ( o1, n2, etc. ) that uniquely identifies the nature of the measure 
( outbound internet transit, amount of RAM, etc. )
  * the component in which it can be found ( nova, swift etc.)
 * and by columns, each one is set with the result of 
aggregate(find(record),record) where
  * find() looks for the existing column as found by selecting with the unique 
key ( maybe the name and the resource id )
  * record is a

Re: [Openstack] database migration cleanup

2012-05-03 Thread Trey Morris

merge prop: https://review.openstack.org/#/c/6847/
now has both required +2s. I'll wait a day or two to approve just in case
there are any lingering objections.

-tr3buchet

On Thu, May 3, 2012 at 10:07 AM, Dan Prince dpri...@redhat.com wrote:



 - Original Message -
  From: John Garbutt john.garb...@citrix.com
  To: Dan Prince dpri...@redhat.com, Vishvananda Ishaya 
 vishvana...@gmail.com
  Cc: openstack@lists.launchpad.net
  Sent: Thursday, May 3, 2012 10:56:44 AM
  Subject: RE: [Openstack] database migration cleanup
 
  I may have missed this in the discussions, but does this impact on
  upgrade?
 
  I am guessing you have tested Essex - Folsom upgrade, but does this
  affect people upgrading from any of the Essex milestones to Folsom?

 What this does is compact the pre-Essex (final) migrations into a single
 migration. Users of any of the Essex milestones would need to first upgrade
 to the final Essex release and then upgrade to Folsom.

 This seemed like a reasonable approach since most distributions release
 updates that contain the final releases anyway.


  I guess the deeper question is which upgrade paths do we want to
  maintain...
 
  Thanks,
  John
 
   -Original Message-
   From:
   openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net
   [mailto:openstack-bounces+john.garbutt=
 eu.citrix@lists.launchpad.net]
   On Behalf Of Dan Prince
   Sent: 02 May 2012 21:20
   To: Vishvananda Ishaya
   Cc: openstack@lists.launchpad.net
   Subject: Re: [Openstack] database migration cleanup
  
  
  
   - Original Message -
From: Vishvananda Ishaya vishvana...@gmail.com
To: Dan Prince dpri...@redhat.com
Cc: openstack@lists.launchpad.net
Sent: Thursday, April 26, 2012 4:14:25 PM
Subject: Re: [Openstack] database migration cleanup
   
+1.  Might be nice to have some kind of test to verify that the
new
migration leaves the tables in exactly the same state as the old
migrations.
  
   Hey Vish,
  
   This is an outline of what I did to test MySQL and PostgreSQL to
   ensure the
   compact migration script generates *exactly* the same schemas as
   before:
  
   http://wiki.openstack.org/database_migration_testing
  
   As things stand both MySQL and PostgreSQL are exactly the same. I
   have
   some pending changes that I've found in the schemas that need to be
   fixed
   in Folsom... but the goal here was to replicate Essex with
   migration 082 so
   that is what I did.
  
   Sqlite has a few differences (indexes for example). How important
   is it that
   the Sqlite schema be exactly the same? Unit tests are passing.
  
   Dan
  
  
   
Vish
   
On Apr 26, 2012, at 12:24 PM, Dan Prince wrote:
   
 The OpenStack Essex release had 82 database migrations. As
 these
 grow in number it seems reasonable to clean house from time to
 time.
 Now seems as good a time as any.

 I came up with a first go at it here:

 https://review.openstack.org/#/c/6847/

 The idea is that we would:

 * Do this early in the release cycle to minimize risk.

 * Compact all pre-Folsom migrations into a single migration.
 This
 migration would be used for new installations.

 * New migrations during the Folsom release cycle would proceed
 as
 normal.

 * Migrations added during Folsom release cycle could be
 compacted
 during E release cycle. TBD if/when we do the next
 compaction.

 * Users upgrading from pre-Essex would need to upgrade to Essex
 first. Then Folsom.

 --

 I think this scheme would support users who follow stable
 releases
 as well as users who follow trunk very closely.

 We talked about this at the conference but I thought this issue
 might be near and dear to some of our end users so it was worth
 discussing on the list.

 What are general thoughts on this approach?

 Dan (dprince)

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

Re: [Openstack] Glance store question??

2012-05-03 Thread Doug Hellmann

Andrew is doing some work on a plugin architecture. This sounds like
another good application of that.

On Wed, May 2, 2012 at 7:01 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:

  Right, if there isn’t that existing, then I think I might just make a
 blueprint out of that. I just wanted to check beforehand that I am doing
 this right, or if it already exists and I did it wrong...

 Thx :-)


 On 5/2/12 3:57 PM, Brian Waldon brian.wal...@rackspace.com wrote:

 Jay might have a better answer, but as far as I know, yes. You could
 probably make the images stores truly pluggable (i.e. not needing to
 explicitly list them out) without much work.

 Brian


 On May 2, 2012, at 12:23 PM, Joshua Harlow wrote:

 Glance store question??
 Hi all,

 I am making a y! specific backing store for glance and I was wondering if
 its really necessary to modify the following file to ensure that the code
 for that new store gets pulled in (or maybe I’m just doing it wrong).

 diff --git a/glance/api/v1/images.py b/glance/api/v1/images.py
 index 9839d2e..7c4f565 100644
 --- a/glance/api/v1/images.py
 +++ b/glance/api/v1/images.py
 @@ -47,6 +47,7 @@ import glance.store.http
  import glance.store.rbd
  import glance.store.s3
  import glance.store.swift
 +import glance.store.SUPERAWESOMEYSTORE
  from glance.store import (get_from_backend,
get_size_from_backend,
schedule_delete_from_backend,

 Is there another way to make that happen so that it gets registered with
 glance besides either modifying that file or having a patch which will
 modify it upon installation (ie an RPM patch)?

 Thx!

 -Josh
 ___
 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] Glance store question??

2012-05-03 Thread Brian Waldon

He definitely is, but its scope is limited to Nova (for now?). The idea 
discussed below is something we could use without having to worry about a 
Glance plugin implementation. We can talk about plugins for Glance later.

Brian


On May 3, 2012, at 10:58 AM, Doug Hellmann wrote:

 Andrew is doing some work on a plugin architecture. This sounds like another 
 good application of that.
 
 On Wed, May 2, 2012 at 7:01 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:
 Right, if there isn’t that existing, then I think I might just make a 
 blueprint out of that. I just wanted to check beforehand that I am doing this 
 right, or if it already exists and I did it wrong...
 
 Thx :-)
 
 
 On 5/2/12 3:57 PM, Brian Waldon brian.wal...@rackspace.com wrote:
 
 Jay might have a better answer, but as far as I know, yes. You could probably 
 make the images stores truly pluggable (i.e. not needing to explicitly list 
 them out) without much work.
 
 Brian
 
 
 On May 2, 2012, at 12:23 PM, Joshua Harlow wrote:
 
 Glance store question?? 
 Hi all,
 
 I am making a y! specific backing store for glance and I was wondering if its 
 really necessary to modify the following file to ensure that the code for 
 that new store gets pulled in (or maybe I’m just doing it wrong).
 
 diff --git a/glance/api/v1/images.py b/glance/api/v1/images.py
 index 9839d2e..7c4f565 100644
 --- a/glance/api/v1/images.py
 +++ b/glance/api/v1/images.py
 @@ -47,6 +47,7 @@ import glance.store.http
  import glance.store.rbd
  import glance.store.s3
  import glance.store.swift
 +import glance.store.SUPERAWESOMEYSTORE
  from glance.store import (get_from_backend,
get_size_from_backend,
schedule_delete_from_backend,
 
 Is there another way to make that happen so that it gets registered with 
 glance besides either modifying that file or having a patch which will modify 
 it upon installation (ie an RPM patch)?
 
 Thx!
 
 -Josh 
 ___
 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] Glance store question??

2012-05-03 Thread Joshua Harlow

Ok, although I wonder if a plug-in framework could benefit from just being 
generic enough to be used in either place?

I think he's focusing on the notification system right now (being more 
pluggable) there, so that be his scope for now. I'm willing to work together to 
make that more generic so that it isn't limited to just that though, this seems 
like one place that could be fixed easily either way (either via simple fix or 
via plugins).

On 5/3/12 11:02 AM, Brian Waldon brian.wal...@rackspace.com wrote:

He definitely is, but its scope is limited to Nova (for now?). The idea 
discussed below is something we could use without having to worry about a 
Glance plugin implementation. We can talk about plugins for Glance later.

Brian


On May 3, 2012, at 10:58 AM, Doug Hellmann wrote:

Andrew is doing some work on a plugin architecture. This sounds like another 
good application of that.

On Wed, May 2, 2012 at 7:01 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:
Right, if there isn't that existing, then I think I might just make a blueprint 
out of that. I just wanted to check beforehand that I am doing this right, or 
if it already exists and I did it wrong...

Thx :-)


On 5/2/12 3:57 PM, Brian Waldon brian.wal...@rackspace.com 
http://brian.wal...@rackspace.com/  wrote:

Jay might have a better answer, but as far as I know, yes. You could probably 
make the images stores truly pluggable (i.e. not needing to explicitly list 
them out) without much work.

Brian


On May 2, 2012, at 12:23 PM, Joshua Harlow wrote:

Glance store question??
Hi all,

I am making a y! specific backing store for glance and I was wondering if its 
really necessary to modify the following file to ensure that the code for that 
new store gets pulled in (or maybe I'm just doing it wrong).

diff --git a/glance/api/v1/images.py b/glance/api/v1/images.py
index 9839d2e..7c4f565 100644
--- a/glance/api/v1/images.py
+++ b/glance/api/v1/images.py
@@ -47,6 +47,7 @@ import glance.store.http
 import glance.store.rbd
 import glance.store.s3
 import glance.store.swift
+import glance.store.SUPERAWESOMEYSTORE
 from glance.store import (get_from_backend,
   get_size_from_backend,
   schedule_delete_from_backend,

Is there another way to make that happen so that it gets registered with glance 
besides either modifying that file or having a patch which will modify it upon 
installation (ie an RPM patch)?

Thx!

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




___
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] [Glance] Replication implementations

2012-05-03 Thread Brian Waldon

I think the path forward is first to gather information on what people are 
already doing w.r.t. replication, which you have helped trigger with this 
email. I'm definitely interested in seeing your solution. Once we get this 
information out in the open, we need to explore these existing solutions can be 
included with Glance. I'd prefer to go with an external tool that handles 
replication rather than baking it directly into the code right now, but if the 
work has already been done, I'm more than happy to consider it.

Brian


On May 2, 2012, at 8:24 PM, Michael Still wrote:

 Hi.
 
 I'd be interested in hearing from people who have implemented some form
 of replication with glance. I'm especially interested in how you went
 about it. I attended the session at the dev summit, but that was forward
 looking, and I am pretty sure that there wasn't any mention of current
 implementations.
 
 I'll get the ball rolling -- I have just implemented API level
 replication for glance for an internal project. It uses the glance API
 to replicate images from a master glance to slave glances. Its not very
 smart at the moment, it just copies everything.
 
 Current warts:
 - no support for metadata update
 - no support for filtering of what is replicated
 - maintaining amazon ec2 ids across regions requires twiddling the nova
 database where this mapping is stored
 
 Advantages of this approach:
 - API level replication means that I can run different versions of
 glance at each end of the replication relationship
 - it really wasn't that hard to do
 
 Would other people be interested in getting this code into glance,
 probably as a stand alone command line tool? Or has someone done
 something much better that I should be using instead?
 
 Cheers,
 Mikal
 
 ___
 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] Has anyone tested Juju with 12.04 Essex installation?

2012-05-03 Thread Adam Gandelman


On 05/03/2012 06:04 AM, Jorge Luiz Correa wrote:

Hi list!

I would like to know if someone has tested juju with Essex. I've 
installed OpenStack using Ubuntu 12.04 and its packages (Essex). The 
nova components are working fine. I can create and destroy instances. 
So I'm using Juju from a 11.10 Oneiric. I've made some modifications 
in my environment.yaml configuration file to work with keystone. In my 
first tests I could bootstrap, creating a new instance. However, some 
problems that I'm having now:


I'd recommend using the latest Juju version, either from the Juju PPA 
[1] on oneiric or the version shipped with precise.




1) Juju and nova aren't creating secgroup-rules in the right way. I 
can see new secgroup-rules, like juju-sample, juju-sample-0 and so on. 
But, when I list the rules, there are NO rules. The immediately impact 
is that when running 'juju status' the host is not able to access the 
instances created by juju. If I go to dashboard and add access with 
the right ports, so juju gets working.


This should be working fine.  We fixed some bugs in nova around security 
groups during Essex that I uncovered trying to get Juju working against 
it, but since then its been working nicely.  I've just bootstrapped 
against an Essex/12.04 and get a functioning security group rule set.  
This may look a bit different depending on what you've named the 
environment, but should be similar: http://paste.ubuntu.com/965169/




2) The host running juju 'should' know how to resolve the instance 
names, like server-8, server-10 to address from cloud network. How we 
need to deal with it? Host running juju has to use the same DNS that 
serves the cloud? I've changed the dhcp configuration in juju host to 
add the address of nova network that runs a dnsmasq and knows how to 
resolve these names. Is this the right way? Recommendations?




This is mostly a Nova config thing. By default, new instances' public 
hostnames are the same as their private hostnames.If you want to be 
able to reach instances via their private hostname, you'd need to do 
some DNS magic outside of Juju like you are doing, or perhaps there is a 
documented way of achieving this in Nova itself.  The best solution is 
to instead add '--auto_assign_floating_ip' to nova.conf.  This will 
ensure a public floating IP is associated with new instances and allow 
Juju to reach its nodes that way instead.   This matches the behavior of 
EC2.



Adam

[1] Juju PPA - ppa:juju/pkgs


Thanks!

--
- MSc. Correa, J.L.



___
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] SmokeStack: xenserver tests offline :(

2012-05-03 Thread Dan Prince

Several people asked me on IRC about SmokeStack being down.

I'm having some issues with the image snapshot I used to spin up server groups 
for XenServer testing... so until I get a couple hours to go have a look at 
either creating a new snapshot or fixing the existing snapshot the XenServer 
SmokeStack tests are broken.

In the meantime I made a slight adjustment to Bellows so that he will continue 
to post unit test, and libvirt results to merge proposals.

Not giving up on the XenServer testing... its just going to take a bit longer 
to fix this one.

Dan

___
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] 401 not authorized with glance

2012-05-03 Thread Ask Stack

Hi
I configured glance and swift + keystone backend. The username and password I 
picked are (glanceadmin, verybadpass) and (swiftadmin, verybadpass). 

I think I varified the user name password and rights with the following 
command. But glance add still gives me the 401 not authorized message. 
Thanks in advance for your help.


[root@keystone glance]# swift -v -V 2.0 -A http://127.0.0.1:5000/v2.0/ -U 
service:glanceadmin -K verybadpass statStorageURL: 
http://127.0.0.1:8080/v1/AUTH_8baec00689c64b0791d2a5a4f110575a
Auth Token: 5346c5ba184840c1a95d762ebec86405
   Account: AUTH_8baec00689c64b0791d2a5a4f110575a
Containers: 1
   Objects: 0
 Bytes: 0
Accept-Ranges: bytes
X-Trans-Id: txe9e92ce3dec14e2cae71e8372bd42dcb


[root@keystone glance]# curl -d '{auth: {tenantName: service, 
passwordCredentials:{username: glanceadmin, password: verybadpass}}}' 
-H Content-type: application/json  http://127.0.0.1:35357/v2.0/tokens | 
python -mjson.tool
  % Total    % Received % Xferd  Average Speed   Time    Time Time  Current
 Dload  Upload   Total   Spent    Left  Speed
100  2255    0  2142  100   113  11680    616 --:--:-- --:--:-- --:--:-- 11704
{
    access: {
    serviceCatalog: [
    {
    endpoints: [
    {
    adminURL: 
http://localhost:8774/v1.1/8baec00689c64b0791d2a5a4f110575a;;, 
    internalURL: 
http://localhost:8774/v1.1/8baec00689c64b0791d2a5a4f110575a;;, 
    publicURL: 
http://localhost:8774/v1.1/8baec00689c64b0791d2a5a4f110575a;;, 
    region: RegionOne
    }
    ], 
    endpoints_links: [], 
    name: nova, 
    type: compute
    }, 
    {
    endpoints: [
    {
    adminURL: http://localhost:9292/v1;;, 
    internalURL: http://localhost:9292/v1;;, 
    publicURL: http://localhost:9292/v1;;, 
    region: RegionOne
    }
    ], 
    endpoints_links: [], 
    name: glance, 
    type: image
    }, 
    {
    endpoints: [
    {
    adminURL: 
http://localhost:8776/v1/8baec00689c64b0791d2a5a4f110575a;;, 
    internalURL: 
http://localhost:8776/v1/8baec00689c64b0791d2a5a4f110575a;;, 
    publicURL: 
http://localhost:8776/v1/8baec00689c64b0791d2a5a4f110575a;;, 
    region: RegionOne
    }
    ], 
    endpoints_links: [], 
    name: nova-volume, 
    type: volume
    }, 
    {
    endpoints: [
    {
    adminURL: http://localhost:8773/services/Admin;;, 
    internalURL: http://localhost:8773/services/Cloud;;, 
    publicURL: http://localhost:8773/services/Cloud;;, 
    region: RegionOne
    }
    ], 
    endpoints_links: [], 
    name: ec2, 
    type: ec2
    }, 
    {
    endpoints: [
    {
    adminURL: 
http://127.0.0.1:8080/v1/AUTH_8baec00689c64b0791d2a5a4f110575a;;, 
    internalURL: 
http://127.0.0.1:8080/v1/AUTH_8baec00689c64b0791d2a5a4f110575a;;, 
    publicURL: 
http://127.0.0.1:8080/v1/AUTH_8baec00689c64b0791d2a5a4f110575a;;, 
    region: regionOne
    }
    ], 
    endpoints_links: [], 
    name: swift, 
    type: object-store
    }, 
    {
    endpoints: [
    {
    adminURL: http://localhost:35357/v2.0;;, 
    internalURL: http://localhost:35357/v2.0;;, 
    publicURL: http://localhost:5000/v2.0;;, 
    region: RegionOne
    }
    ], 
    endpoints_links: [], 
    name: keystone, 
    type: identity
    }
    ], 
    token: {
    expires: 2012-05-04T19:01:27Z, 
    id: 8bb7add1ae4c4396bf974082604248fc, 
    tenant: {
    description: null, 
    enabled: true, 
    id: 8baec00689c64b0791d2a5a4f110575a, 
    name: service
    }
    }, 
    user: {
    id: 8d79596669964ae483265b15c8672f6d, 
    name: glanceadmin, 
    roles: [
    {
    id: 227ca9ac2e784195b6d276601a4b6a2d, 
    name: admin
    }
    ], 
    roles_links: [], 
    username: glanceadmin

[Openstack] Summary of QA Weekly Status meeting

2012-05-03 Thread David Kranz

The QA team had its weekly IRC meeting today. Here is a summary of the 
progress  and decisions coming out of the meeting.


* Progress

 There were a bunch of problems that were preventing the tempest gating 
job from running successfully. The last (:-) ) problem was identified. 
We hope to turn this on to gate checkins to Tempest itself by the end of 
the day.  Thanks to Monty Taylor for his continuing attention to this. 
We will also be doing a complete tempest run each day to check on other 
projects and hope that identified bugs can be fixed quickly.  We will 
soon start running the stress tests nightly as well.


 A set of tempest tests for Swift should be coming online next week.


* Decisions made

 New tempest tests that do not require a lot of changes will be 
backported to tempest essex/stable. We will do a nightly run to check on 
changes that are made
to other essex/stable branches. A few more changes need to go into 
tempest stable/diablo but, generally, new tests will not be backported 
there.


We have been focusing on black-box tests to get wide coverage. A lot of 
progress has been made and we are now going to be looking at white-box 
tests as

well.

* Outstanding Reviews

Community, please feel free to provide code reviews on outstanding 
Tempest merge proposals:


https://review.openstack.org/#/q/status:open+project:openstack/tempest,n,z

Thanks!
-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] Instance IP assignment problem

2012-05-03 Thread Salman Malik

I see. So where do you use private IP's in your setup ?

Thanks,
Salman

Subject: RE: [Openstack] Instance IP assignment problem
From: emilien.openst...@gmail.com
To: salma...@live.com
CC: soh...@cs.toronto.edu; ahal...@griddynamics.com; 
openstack@lists.launchpad.net
Date: Thu, 3 May 2012 17:02:23 +0200

Hi Salman,

Le jeudi 03 mai 2012 à 09:47 -0500, Salman Malik a écrit :

Hi Emilien,

In your configuration you have the following flags:

--flat_network_bridge=br100

I'm going to try to change it in both servers.

--floating_range=10.68.5.0/24

That's actually my public pool, sot it's not my fixed pool (privates IPs).

After my tests, I will let you know of course.

Thanks,

Regards

Can you please tell me why you need br100 when you are using br-int with 
OVS ? Secondly, you seem to use floating_range flag as the second flag. I 
assume that it is the pool of addresses that your instances will get IP from, 
right? It may be worthwhile to modify it to fixed_range because Bilal suggested 
here that this config worked for him. 

Let us know.

Thanks,

Salman

Date: Thu, 3 May 2012 08:29:42 -0400

Subject: Re: [Openstack] Instance IP assignment problem

From: soh...@cs.toronto.edu

To: emilien.openst...@gmail.com

CC: ahal...@griddynamics.com; openstack@lists.launchpad.net; 
salma...@live.com

Oops accidently hit send on my phone.

I had a similar problem before. My problem was that the nic driver on the 
compute instance (your Essex 2) was dropping vlan tags, and then, openvswitch 
wasn't delivering packets. You can check it using tcpdump -e -vvv.

BTW, if you are using virtualbox to run openstack, make sure you are not 
using vbox intel drivers. Use pcnet fast instead.

OVS splinter may also be useful.

Hope that helps.

Cheers

Soheil

On Thursday, May 3, 2012, Soheil Hassas Yeganeh wrote:

I had a similar problem before. My problem was that the nic driver on 
the compute instance (your Essex 2) was dropping vlan tags, and then, 
openvswitch wasn

can you find dhcp requests by using tcpdump for example ?

sorry for off-topic but there may be many reasons of such issue 
with dhcp. last one for me was old dhcp client(Ubuntu) and udp checksum error. 
I have essex on centos and was trying ubuntu vm. 

On Thu, May 3, 2012 at 12:48 PM, Emilien Macchi 
emilien.openst...@gmail.com wrote:

All seems alright but not working yet.

http://paste.openstack.org/show/14791/

I have executed on both servers :

ovs-vsctl add-port br-int eth1

Need I do something else ?

How the DHCP is working in this case ?

Le jeudi 03 mai 2012 à 09:29 +0100, Bilel Msekni a écrit : 

Then the problem isn't in the instance but in the 
nova-network service , please check if it is working well 

as well as give us the output log when you attempt to 
create a new instance.

Subject: RE: [Openstack] Instance IP assignment problem

From: emilien.openst...@gmail.com

To: ski...@hotmail.fr

CC: salma...@live.com; openstack@lists.launchpad.net

Date: Thu, 3 May 2012 10:21:37 +0200

Fixed IP

Le jeudi 03 mai 2012 à 09:15 +0100, Bilel Msekni a écrit : 

Fixed IP or Floating IP ?

From: emilien.openst...@gmail.com

To: salma...@live.com

Date: Thu, 3 May 2012 09:55:31 +0200

CC: openstack@lists.launchpad.net

Subject: Re: [Openstack] Instance IP assignment problem

Hi,

Re: [Openstack] [QA] Aligning smoke / acceptance / promotion test efforts

2012-05-03 Thread Daryl Walleck

So my first question is around this. So is the claim is that the client tools 
are the default interface for the applications? While that works for coders in 
python, what about people using other languages? Even then, there's no 
guarantee that the clients in different languages are implemented in the same 
way. Tempest was designed originally because while it does use an abstraction 
between the API and the tests, there is nothing to assist the user by 
retrying and the like. While I think there's a place for writing tests using 
the command line clients, to me that would be a smoke test of a client and not 
as much a smoke test of the API.

Daryl

On May 3, 2012, at 12:01 PM, Jay Pipes wrote:

However, before this can happen, a number of improvements need to be made to 
Tempest. The issue with the smoke tests in Tempest is that they aren't really 
smoke tests. They do not use the default client tools (like novaclient, 
keystoneclient, etc) and are not annotated consistently.

___
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 API question

2012-05-03 Thread Everett Toews

I get the same as Luis when trying GET /users/{user_id}/roles on
stable/essex (using devstack). Keystone spits back an

AttributeError: 'UserController' object has no attribute 'get_user_roles'

message instead of a nice 501.

GET /tenants/{tenant_id}/users/{user_id}/roles works fine. For a bit more
detail have a look at

http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_listRolesForUserOnTenant_v2.0_tenants__tenantId__users__user_id__roles_Admin_API_Service_Developer_Operations-d1e1356.html

Everett

On Thu, May 3, 2012 at 9:34 AM, Dolph Mathews dolph.math...@gmail.comwrote:

 The philosophy in essex is that it's meaningless for a user to have a role
 without that role being applied to a tenant, so the call that's implemented
 is:

 GET /tenants/{tenant_id}/users/{user_id}/roles

 Calling this instead should get you an HTTP 501 stating User roles not
 supported: tenant ID required.

 GET /users/{user_id}/roles

 Also, the term roleRefs was deprecated late in the diablo cycle (AFAIK)
 in favor of roles.

 -Dolph

 On Wed, May 2, 2012 at 3:44 PM, Luis Gervaso l...@woorea.es wrote:

 Hi,

 In Diablo was:

 GET /users/{user_id}/roleRefs

 In Essex it is maintained for compatibility reasons. I understand that
 this is the obsolete now.

 I can find:

 PUT  DELETE /users/{user_id}/roles/OS-KSADM/{role_id}

 How can get all the roles having a user_id?

 GET /users/{user_id}/roles (i can't find this on stable/essex)

 Returning role list with tenant associated

 Another option that would work for me is:

 GET /users/{user_id}/tenants

 Returning tenant list with role list associated per tenant


 When i GET /user/{user_id} i obtain only this info

 {user: {name: admin, enabled: true, email: ad...@example.com,
 id: ef1e63df85b641d7bf3c575bb8670cef, tenantId: null}}

 Regards

 --
 ---
 Luis Alberto Gervaso Martin
 Woorea Solutions, S.L
 CEO  CTO
 mobile: (+34) 627983344
 luis@ luis.gerv...@gmail.comwoorea.es



 ___
 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] Has anyone tested Juju with 12.04 Essex installation?

2012-05-03 Thread Sébastien Han

Hi!

I'm sorry but I can't helpyou, however I'm very interested in your setup.
I'm also using Juju combined to MAAS. I have some issues at the moment
(juju status, ssh keys and so on...)

Are you also working on Bare Metal or on EC2 instances?

Cheers!


On Thu, May 3, 2012 at 3:04 PM, Jorge Luiz Correa corre...@gmail.comwrote:

 Hi list!

 I would like to know if someone has tested juju with Essex. I've installed
 OpenStack using Ubuntu 12.04 and its packages (Essex). The nova components
 are working fine. I can create and destroy instances. So I'm using Juju
 from a 11.10 Oneiric. I've made some modifications in my environment.yaml
 configuration file to work with keystone. In my first tests I could
 bootstrap, creating a new instance. However, some problems that I'm having
 now:

 1) Juju and nova aren't creating secgroup-rules in the right way. I can
 see new secgroup-rules, like juju-sample, juju-sample-0 and so on. But,
 when I list the rules, there are NO rules. The immediately impact is that
 when running 'juju status' the host is not able to access the instances
 created by juju. If I go to dashboard and add access with the right ports,
 so juju gets working.

 2) The host running juju 'should' know how to resolve the instance names,
 like server-8, server-10 to address from cloud network. How we need to deal
 with it? Host running juju has to use the same DNS that serves the cloud?
 I've changed the dhcp configuration in juju host to add the address of nova
 network that runs a dnsmasq and knows how to resolve these names. Is this
 the right way? Recommendations?

 Thanks!

 --
 - MSc. Correa, J.L.


 ___
 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 API question

2012-05-03 Thread Luis Gervaso

Yes, this is the real issue.

Since /tenants is only valid for the current user (that's X-Auth-Token
dependant)

How can an administrator user list all the tenants a user belongs to?

Another issue i've detected is that endpoints are always dependant on a
service,
may be i'm wrong but for me:

/service/{service_id}/endpoints

is more appropiate than

/endpoints

Dolph, please correct me

Luis


On Thu, May 3, 2012 at 10:12 PM, Everett Toews everett.to...@cybera.cawrote:

 I get the same as Luis when trying GET /users/{user_id}/roles on
 stable/essex (using devstack). Keystone spits back an

 AttributeError: 'UserController' object has no attribute 'get_user_roles'

 message instead of a nice 501.

 GET /tenants/{tenant_id}/users/{user_id}/roles works fine. For a bit more
 detail have a look at


 http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_listRolesForUserOnTenant_v2.0_tenants__tenantId__users__user_id__roles_Admin_API_Service_Developer_Operations-d1e1356.html

 Everett


 On Thu, May 3, 2012 at 9:34 AM, Dolph Mathews dolph.math...@gmail.comwrote:

 The philosophy in essex is that it's meaningless for a user to have a
 role without that role being applied to a tenant, so the call that's
 implemented is:

 GET /tenants/{tenant_id}/users/{user_id}/roles

 Calling this instead should get you an HTTP 501 stating User roles not
 supported: tenant ID required.

 GET /users/{user_id}/roles

 Also, the term roleRefs was deprecated late in the diablo cycle (AFAIK)
 in favor of roles.

 -Dolph

 On Wed, May 2, 2012 at 3:44 PM, Luis Gervaso l...@woorea.es wrote:

 Hi,

 In Diablo was:

 GET /users/{user_id}/roleRefs

 In Essex it is maintained for compatibility reasons. I understand that
 this is the obsolete now.

 I can find:

 PUT  DELETE /users/{user_id}/roles/OS-KSADM/{role_id}

 How can get all the roles having a user_id?

 GET /users/{user_id}/roles (i can't find this on stable/essex)

 Returning role list with tenant associated

 Another option that would work for me is:

 GET /users/{user_id}/tenants

 Returning tenant list with role list associated per tenant


 When i GET /user/{user_id} i obtain only this info

 {user: {name: admin, enabled: true, email: ad...@example.com,
 id: ef1e63df85b641d7bf3c575bb8670cef, tenantId: null}}

 Regards

 --
 ---
 Luis Alberto Gervaso Martin
 Woorea Solutions, S.L
 CEO  CTO
 mobile: (+34) 627983344
 luis@ luis.gerv...@gmail.comwoorea.es



 ___
 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





-- 
---
Luis Alberto Gervaso Martin
Woorea Solutions, S.L
CEO  CTO
mobile: (+34) 627983344
luis@ luis.gerv...@gmail.comwoorea.es
___
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] [Metering] schema and counter definitions

2012-05-03 Thread Robert Collins

On Fri, May 4, 2012 at 5:27 AM, Turner, Whit (Cloud Services)
whit.tur...@hp.com wrote:
 Hi - I think a flexible aggregation scheme is needed; the levels of
 aggregation available should be definable in the meter independent of the
 sources of usage data themselves. If invoices need to be very granular down
 to the lowest possible level, then this drives higher data requirements all
 through the processing chain, including the rating engine. Traditional
 systems tend to pass less granular (more highly aggregated) data into the
 rating engine so that bill runs and invoices can be generated efficiently.
 At cloud-scale, this can be problematic. Given some “big data” approaches,
 though, this could be handled in a more granular and real-time fashion.

Has anyone looked at what statsd does? It has very similar
requirements (simple to use, no hard a-priori definition of things to
count, a few base types to track), and needs to be horizontally
scalable.

We could, as a riff on my prior email, define the statsd (or a similar
thing) as a common substrate, and then let different implementations
discard detail, or preserve it as needed. The key difference I see vs
defining a Python API is that if someone is writing a different
language implementation of an Openstack component, they would have a
common thing to target.

OTOH it should be trivial to write a network component that thunks
*into* the stock Python API, and from there to the configured backend,
so there is no need to pick any specific network protocol up front -
though bearing in mind that we want network handoffs is probably a
good thing when looking at the nitty gritty.

-Rob

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

[Openstack] Ubuntu packaging team

2012-05-03 Thread Paul Belanger


List,

I'm looking for pointers on how I can get some packaging bugs closed 
out.  I have 5 open issue[1][2][3], with 2 being new features[4][5] 
(dbconfig-common support for nova / glance). All have patches attached, 
ready for review and merging however they don't seem to be getting any 
traction.


I'd like to offer up my packaging services to the Ubuntu packaging team, 
however I've not had much success or feedback.  I know everybody was 
busy with the Essex release, but now that we are starting a new 
development cycle for Folsom I'd like to before more involved.


Any pointers or ProTips?

[1] https://bugs.launchpad.net/ubuntu/+source/glance/+bug/989205
[2] https://bugs.launchpad.net/ubuntu/+source/nova/+bug/989241
[3] https://bugs.launchpad.net/ubuntu/+source/nova/+bug/989242
[4] https://bugs.launchpad.net/ubuntu/+source/glance/+bug/953093
[5] https://bugs.launchpad.net/ubuntu/+source/nova/+bug/954915

--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: 
https://twitter.com/pabelanger


___
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] Instance IP assignment problem