Re: [openstack-dev] [Neutron][docs] Why is the neutron security group extension disabled by default?

[Nachi Ueno]

Hi folks

Thank you for pointing this.
I'll take this one

Best
Nachi

2013/7/13 Tom Fifield :
> "Dear caller, your bug is important to us, and will be addressed by the
> first available operator. You are currently. number. two ... hundred ...
> and. forty. eight. in the queue."
>
> http://bit.ly/17cJejn
>
>
> https://bugs.launchpad.net/openstack-manuals/+bug/1190940
>
> ;)
>
>
> Regards,
>
> Tom
>
>
> On 14/07/13 12:44, Robert Collins wrote:
>>
>> I've previously filed a bug about the docs; I agree that this seems like
>> something to make enabled by default, particularly with nova-network now
>> on the deprecation path.
>>
>> -Rob
>>
>> On 14 July 2013 14:08, Matt Riedemann > > wrote:
>>
>> I had to figure out via the code that unless you specify a firewall
>> driver in the neutron plugin's ini file (I'm using openvswitch in
>> this case), the neutron security group extension is disabled.
>>
>> The admin doc tells you what to do in nova.conf to get nova to proxy
>> security group calls through neutron:
>>
>>
>> _http://docs.openstack.org/trunk/openstack-network/admin/content/nova_config_security_groups.html_
>>
>>
>> But there is no mention of setting the firwall_driver property in
>> the [securitygroup] section of your plugin's ini file.  For OVS, it
>> would be setting this:
>>
>>
>> _http://gerrit.rtp.raleigh.ibm.com/gitweb?p=osee-tools.git;a=blob;f=install/build.include;h=2089a32f1da4ad92a61601a4d46a5b34b312f644;hb=refs/heads/osee-havana#l103_
>>
>>
>> In nova, security groups work out of the box (well, at least they
>> are enabled, you still have to setup the rules).
>>
>> Is there a design point of why the neutron security group extension
>> is disabled by default (maybe so it doesn't interfere with nova
>> somehow)?  If so, we can work on getting the docs updated.
>>   Otherwise it seems like a bug in the code.
>>
>>
>> Thanks,
>>
>> *MATT RIEDEMANN*
>>
>> Advisory Software Engineer
>> Cloud Solutions and OpenStack Development
>>
>> 
>> *Phone:*1-507-253-7622 | *Mobile:*1-507-990-1889
>> *
>> E-mail:*_mrie...@us.ibm.com_ 
>>
>> IBM
>>
>> 3605 Hwy 52 N
>> Rochester, MN 55901-1407
>> United States
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> Robert Collins mailto:rbtcoll...@hp.com>>
>>
>> Distinguished Technologist
>> HP Cloud Services
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron][docs] Why is the neutron security group extension disabled by default?

[Tom Fifield]

"Dear caller, your bug is important to us, and will be addressed by the 
first available operator. You are currently. number. two ... hundred ... 
and. forty. eight. in the queue."


http://bit.ly/17cJejn


https://bugs.launchpad.net/openstack-manuals/+bug/1190940

;)


Regards,

Tom

On 14/07/13 12:44, Robert Collins wrote:

I've previously filed a bug about the docs; I agree that this seems like
something to make enabled by default, particularly with nova-network now
on the deprecation path.

-Rob

On 14 July 2013 14:08, Matt Riedemann mailto:mrie...@us.ibm.com>> wrote:

I had to figure out via the code that unless you specify a firewall
driver in the neutron plugin's ini file (I'm using openvswitch in
this case), the neutron security group extension is disabled.

The admin doc tells you what to do in nova.conf to get nova to proxy
security group calls through neutron:


_http://docs.openstack.org/trunk/openstack-network/admin/content/nova_config_security_groups.html_

But there is no mention of setting the firwall_driver property in
the [securitygroup] section of your plugin's ini file.  For OVS, it
would be setting this:


_http://gerrit.rtp.raleigh.ibm.com/gitweb?p=osee-tools.git;a=blob;f=install/build.include;h=2089a32f1da4ad92a61601a4d46a5b34b312f644;hb=refs/heads/osee-havana#l103_

In nova, security groups work out of the box (well, at least they
are enabled, you still have to setup the rules).

Is there a design point of why the neutron security group extension
is disabled by default (maybe so it doesn't interfere with nova
somehow)?  If so, we can work on getting the docs updated.
  Otherwise it seems like a bug in the code.


Thanks,

*MATT RIEDEMANN*
Advisory Software Engineer
Cloud Solutions and OpenStack Development

*Phone:*1-507-253-7622 | *Mobile:*1-507-990-1889
*
E-mail:*_mrie...@us.ibm.com_   
IBM

3605 Hwy 52 N
Rochester, MN 55901-1407
United States



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

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




--
Robert Collins mailto:rbtcoll...@hp.com>>
Distinguished Technologist
HP Cloud Services


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




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

Re: [openstack-dev] [Neutron][docs] Why is the neutron security group extension disabled by default?

[Robert Collins]

I've previously filed a bug about the docs; I agree that this seems like
something to make enabled by default, particularly with nova-network now on
the deprecation path.

-Rob

On 14 July 2013 14:08, Matt Riedemann  wrote:

> I had to figure out via the code that unless you specify a firewall driver
> in the neutron plugin's ini file (I'm using openvswitch in this case), the
> neutron security group extension is disabled.
>
> The admin doc tells you what to do in nova.conf to get nova to proxy
> security group calls through neutron:
>
> *
> http://docs.openstack.org/trunk/openstack-network/admin/content/nova_config_security_groups.html
> *
>
> But there is no mention of setting the firwall_driver property in the
> [securitygroup] section of your plugin's ini file.  For OVS, it would be
> setting this:
>
> *
> http://gerrit.rtp.raleigh.ibm.com/gitweb?p=osee-tools.git;a=blob;f=install/build.include;h=2089a32f1da4ad92a61601a4d46a5b34b312f644;hb=refs/heads/osee-havana#l103
> *
>
> In nova, security groups work out of the box (well, at least they are
> enabled, you still have to setup the rules).
>
> Is there a design point of why the neutron security group extension is
> disabled by default (maybe so it doesn't interfere with nova somehow)?  If
> so, we can work on getting the docs updated.  Otherwise it seems like a bug
> in the code.
>
>
> Thanks,
>
> *MATT RIEDEMANN*
> Advisory Software Engineer
> Cloud Solutions and OpenStack Development
> --
>  *Phone:* 1-507-253-7622 | *Mobile:* 1-507-990-1889*
> E-mail:* *mrie...@us.ibm.com* 
> [image: IBM]
>
> 3605 Hwy 52 N
> Rochester, MN 55901-1407
> United States
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services
<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][docs] Why is the neutron security group extension disabled by default?

[Matt Riedemann]

I had to figure out via the code that unless you specify a firewall driver 
in the neutron plugin's ini file (I'm using openvswitch in this case), the 
neutron security group extension is disabled.

The admin doc tells you what to do in nova.conf to get nova to proxy 
security group calls through neutron:

http://docs.openstack.org/trunk/openstack-network/admin/content/nova_config_security_groups.html
 


But there is no mention of setting the firwall_driver property in the 
[securitygroup] section of your plugin's ini file.  For OVS, it would be 
setting this:

http://gerrit.rtp.raleigh.ibm.com/gitweb?p=osee-tools.git;a=blob;f=install/build.include;h=2089a32f1da4ad92a61601a4d46a5b34b312f644;hb=refs/heads/osee-havana#l103
 


In nova, security groups work out of the box (well, at least they are 
enabled, you still have to setup the rules).

Is there a design point of why the neutron security group extension is 
disabled by default (maybe so it doesn't interfere with nova somehow)?  If 
so, we can work on getting the docs updated.  Otherwise it seems like a 
bug in the code.


Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development

Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.com


3605 Hwy 52 N
Rochester, MN 55901-1407
United States
<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] cells checks on patches

[Chris Behrens]

On Jul 13, 2013, at 8:28 AM, Sean Dague  wrote:

> Like I said, as long as someone is going to work on it, I'm happy. :) I just 
> don't want this to be an enable the tests and hope magically fairies come to 
> fix them issue. That's what we did on full neutron tests, and it's been 
> bouncing around like that for a while.
> 
> We are planning on disabling the devstack exercises, it wasn't so much that, 
> it's that it looks like there is fundamental lack of functioning nova on 
> devstack for cells right now. The security groups stack trace is just a side 
> effect of cells falling over in a really low level way (this is what's before 
> and after the trace).
> 
> 2013-07-13 00:12:18.605 ERROR nova.cells.scheduler 
> [req-dcbb868c-98a7-4d65-94b3-e1234c50e623 demo demo] Couldn't communicate 
> with cell 'child'
> 
> 2013-07-13 00:12:18.606 ERROR nova.cells.scheduler 
> [req-dcbb868c-98a7-4d65-94b3-e1234c50e623 demo demo] Couldn't communicate 
> with any cells
> 

Did you dig these out manually somehow?   It looks like that unfortunately 
there's no screen-n-cells.txt saved in the gate, which would be extremely 
useful. :)  It looks like all errors must be limited to that service right now… 
makes me wonder if the devstack needs tweaked now for cells.

In fact, I *might* know the problem.   Some cells config options were 
deprecated, and it appears that backwards compatibility was lost.  I ran into 
this myself, and I took a stab at fixing it (I was unable to reproduce it in 
tests, but it certainly showed up in one of our environments).

We should probably commit a fix to devstack to use the new config options no 
matter what:

1) Remove the usage of compute_api_class CONF option
2) Where compute_api_class was set to the ComputeCells class in the API cell, 
instead use this config:

[cells]
cell_type=api

3) In a child cell where you did not override compute_api_class, use this:
[cells]
cell_type=compute

Maybe someone could try committing that fix to devstack for me while I'm 
traveling? :)   I wonder if that'll get us a little further along...

- Chris



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

Re: [openstack-dev] cells checks on patches

[Chris Behrens]

I can make a commitment to help getting cells passing.  Basically, I'd like to 
do whatever I can to make sure we can have a useful gate on cells.  
Unfortunately I'm going to be mostly offline for the next 10 days or so, 
however. :)

I thought there was a sec group patch up for cells, but I've not fully reviewed 
it.  

The generic "cannot communicate with cell 'child'" almost sounds like some 
other basic issue I'll see if I can take a peak during my layovers tonight.

On Jul 13, 2013, at 8:28 AM, Sean Dague  wrote:

> On 07/13/2013 10:50 AM, Dan Smith wrote:
>>> Currently cells can even get past devstack exercises, which
>>> are very
>>> minor sanity checks for the environment (nothing tricky).
>> 
>> I thought that the plan was to deprecate the devstack exercises and
>> just use tempest. Is that not the case? I'd bet that the devstack
>> exercises are just not even on anyone's radar. Since the excellent work
>> you QA folks did to harden those tests before grizzly, I expect most
>> people take them for granted now :)
>> 
>> Digging into the logs just a bit, I see what looks like early failures
>> related to missing security group issues in the cells manager log. I
>> know there are some specific requirements in how things have to be set
>> up for cells, so I think it's likely that we'll need to do some
>> tweaking of configs to get all of this right.
>> 
>> We enabled the test knowing that it wasn't going to pass for a while,
>> and it's only been running for less than 24 hours. In the same way that
>> the grenade job had (until recently) been failing on everything, the
>> point of enabling the cells test now is so that we can start iterating
>> on fixes so that we can hopefully have some amount of regular test
>> coverage before havana.
> 
> Like I said, as long as someone is going to work on it, I'm happy. :) I just 
> don't want this to be an enable the tests and hope magically fairies come to 
> fix them issue. That's what we did on full neutron tests, and it's been 
> bouncing around like that for a while.
> 
> We are planning on disabling the devstack exercises, it wasn't so much that, 
> it's that it looks like there is fundamental lack of functioning nova on 
> devstack for cells right now. The security groups stack trace is just a side 
> effect of cells falling over in a really low level way (this is what's before 
> and after the trace).
> 
> 2013-07-13 00:12:18.605 ERROR nova.cells.scheduler 
> [req-dcbb868c-98a7-4d65-94b3-e1234c50e623 demo demo] Couldn't communicate 
> with cell 'child'
> 
> 2013-07-13 00:12:18.606 ERROR nova.cells.scheduler 
> [req-dcbb868c-98a7-4d65-94b3-e1234c50e623 demo demo] Couldn't communicate 
> with any cells
> 
> Again, mostly I want to know that we've got a blueprint or bug that's high 
> priority and someone's working on it. It did take a while to get grenade 
> there (we're 2 bugs away from being able to do it repeatably in the gate), 
> but during that time we did have people working on it. It just takes a while 
> to get to the bottom of these issues some times, so I want people to have a 
> realistic expectation on how quickly we'll go from running upstream to gating.
> 
>-Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Savanna] How to run hadoop jobs

[Arindam Choudhury]

Hi Ruslan,

As the output is quite long, I am providing pastebin link. Hope it does not 
boter you.

 The outputs of
$ http $SAVANNA_URL/images X-Auth-Token:$AUTH_TOKEN$ http 
$SAVANNA_URL/node-group-templates X-Auth-Token:$AUTH_TOKEN$ http 
$SAVANNA_URL/cluster-templates X-Auth-Token:$AUTH_TOKEN
are here:

 http://pastebin.com/ngu9HNdu

I followed the quick start guide,  the outputs are here:  

http://pastebin.com/TYmnQe2G

The logs are here, its contains log after I submitted the cluster:

http://pastebin.com/LjHxmi4j


Regards,
Arindam


Date: Sat, 13 Jul 2013 22:04:26 +0400
From: rkamaldi...@mirantis.com
To: arin...@live.com
CC: openstack-dev@lists.openstack.org; savanna-...@lists.launchpad.net
Subject: Re: [Savanna-all] How to run hadoop jobs



Hi Arindam,

There was a validation error during cluster creation. Can you send contents of 
cluster_create.json ?Also, please attach output of:
$ http $SAVANNA_URL/images X-Auth-Token:$AUTH_TOKEN$ http 
$SAVANNA_URL/node-group-templates X-Auth-Token:$AUTH_TOKEN$ http 
$SAVANNA_URL/cluster-templates X-Auth-Token:$AUTH_TOKEN
Savanna debug logs also would be helpful. 

Please use *openstack-dev* as a mail-list for Savanna-related questions. Just 
prefix the subject with [Savanna].
Thanks,Ruslan

 
On Saturday, July 13, 2013 at 9:24 PM, Arindam Choudhury wrote:




Hi,

I installed savanna from the git repository. I can create cluster but only with 
admin, when I try to create cluster with non-admin user it gives me an error:

(keystone_arindam)]# http $SAVANNA_URL/clusters X-Auth-Token:$AUTH_TOKEN  < 
cluster_create.json
HTTP/1.1 500 INTERNAL SERVER ERROR
Content-Length: 111
Content-Type: application/json
Date: Sat, 13 Jul 2013 16:47:25 GMT

{
"error_code": 500,
"error_message": "Error occurred during validation",
"error_name": "INTERNAL_SERVER_ERROR"
}

The hadoop daemons are not started automatically so I could not run the test 
job.

hadoop@cluster-1-master-001:/usr/share/hadoop$ hadoop jar hadoop-examples.jar 
pi 10 100
Exception in thread "main" java.io.IOException: Error opening job jar: 
hadoop-examples.jar
at org.apache.hadoop.util.RunJar.main(RunJar.java:90)
Caused by: java.io.FileNotFoundException: hadoop-examples.jar (No such file or 
directory)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:214)
at java.util.zip.ZipFile.(ZipFile.java:144)
at java.util.jar.JarFile.(JarFile.java:153)
at java.util.jar.JarFile.(JarFile.java:90)
at org.apache.hadoop.util.RunJar.main(RunJar.java:88)
hadoop@cluster-1-master-001:/usr/share/hadoop$ start-all.sh
mkdir: cannot create directory `/mnt/log': Permission denied
chown: cannot access `/mnt/log/hadoop/hadoop/': No such file or directory
starting namenode, logging to 
/mnt/log/hadoop/hadoop//hadoop-hadoop-namenode-cluster-1-master-001.out
/usr/sbin/hadoop-daemon.sh: line 136: 
/mnt/log/hadoop/hadoop//hadoop-hadoop-namenode-cluster-1-master-001.out: No 
such file or directory
head: cannot open 
`/mnt/log/hadoop/hadoop//hadoop-hadoop-namenode-cluster-1-master-001.out' for 
reading: No such file or directory
hadoop@localhost's password:

when I try to start hadoop manually, it asks for a password. How to do it? Am I 
missing something?

Regards,
Arindam


  
-- Mailing list: https://launchpad.net/~savanna-allPost to : 
savanna-all@lists.launchpad.netUnsubscribe : 
https://launchpad.net/~savanna-allMore help   : 
https://help.launchpad.net/ListHelp
 
 
 
 

 



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

Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer

[Michael Still]

I'm happy to help, although I'm pretty busy...

Michael

On Fri, Jul 12, 2013 at 9:37 PM, Boris Pavlovic  wrote:
> Hi Sean,
>
> I agree to help with sqlalchemy-migrate until we remove it.
> But probably there should be one more person mikal
>
> Best regards,
> Boris Pavlovic
>
>
> On Fri, Jul 12, 2013 at 3:31 PM, Sean Dague  wrote:
>>
>> On 07/12/2013 04:29 AM, Thierry Carrez wrote:
>>>
>>> Monty Taylor wrote:

 This brings us to the most important question:

 Who wants to be on the core team?
>>>
>>>
>>> That's the important question indeed. Accepting it (permanently or
>>> temporarily) under stackforge is an easy decision. But it's useless
>>> unless we have a set of people sufficiently interested in it not
>>> bitrotting to volunteer to maintain it...
>>
>>
>> I'd recommend the nova-db subteam folks, like: jog0, dripton, boris-42 as
>> good people to be +2 on this.
>>
>> -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rackspace Australia

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

[openstack-dev] Reset established vnc connections

[Parthipan, Loganathan (Cloud Services)]

Hello,

I've proposed the following blueprint and would appreciate feedback.

https://blueprints.launchpad.net/nova/+spec/reset-vnc-console

This is in response to some of the security concerns around VNC we have seen in 
deployed clusters. An established console connection can be passive and the 
user cannot do anything if he suspects a connected adversary without changing 
VM state. In this blueprint we propose that we allow the user to reset any 
existing console connections using a client call something like

nova reset-all-vnc-consoles 

My search didn't point towards any existing effort/blueprints in this line but 
please let me know if there's one so that I can join that. If not I'd like to 
start work on this.

Thanks
~parthi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bug #1194026

[Nachi Ueno]

HI Folks

I pushed  https://review.openstack.org/#/c/36890/ .
Since this is kind of critical problem, I'm very appreciate if this is
reviewed quickly.

Thanks
Nachi


2013/7/11 Nachi Ueno :
> Hi folks
>
> I think I found possible cause of this problems.
>
> so we expected all RPC call is executed serialized way on l3-agent
> However it is executed in random order.
>
> http://paste.openstack.org/show/40156/
> line starts from  Get is RPC message log.
> line starts from [ Process is when l3-agent start processing rpc messages.
> (I added rpc message number for debugging)
>
> https://bugs.launchpad.net/neutron/+bug/1194026
>
> Here is my proposal for fixing code.
>
> - Server side simply notifies when something updated.
> - Client will update updated flag in the client when it get updated
> - some looping call will check the flag,
>   if the flag is true, it will full sync with servers
>
> If this is OK, I'll start write it.
>
> Thanks
> Nachi
>
>
>
>
>
>
>
>
>
>
>
>
> 2013/7/11 Salvatore Orlando :
>> Adding openstack-dev to this discussion thread.
>> Looks like the test is going to be skipped at the moment, but we probably
>> need to consider raising the priority of this issue and assign our cores
>> with more experience with tempest/gating on this.
>>
>> salvatore
>>
>>
>> On 9 July 2013 22:48, Maru Newby  wrote:
>>>
>>> My suggestion is that the quantum exercise script be disabled for now if
>>> that will allow the tempest test to run, since the tempest test is more
>>> useful (it does an ssh check to ensure that the metadata service has
>>> configured the VM).  Doing so would allow useful gating while we look at
>>> resolving the timing bug.
>>>
>>>
>>> m.
>>>
>>> On Jul 9, 2013, at 5:42 PM, Nachi Ueno  wrote:
>>>
>>> > Hi Maru
>>> >
>>> > The gating test will not fail everytime. Sometimes, both of tests
>>> > works, sometimes not.
>>> > In this test, execise.sh works and tempest don't works.
>>> > I'm still not sure is there any dependencies in this failure or not.
>>> >
>>> > So I'm assuming this is kind of timing issue..
>>> >
>>> > hmm this kind of bug is hard to fix..
>>> >
>>> >
>>> > 2013/7/9 Maru Newby :
>>> >> If there is a conflict between the exercise test and the tempest test,
>>> >> does the tempest test pass if the exercise script isn't run beforehand?
>>> >>
>>> >>
>>> >> m.
>>> >>
>>> >> On Jul 9, 2013, at 5:20 PM, Nachi Ueno  wrote:
>>> >>
>>> >>> Hi
>>> >>>
>>> >>> I checked briefly, and it looks some timing bug of l3-agent.
>>> >>> I added note on the bug report.
>>> >>> https://bugs.launchpad.net/neutron/+bug/1194026
>>> >>>
>>> >>> 2013/7/9 Salvatore Orlando :
>>>  Sean Dague singled it out as the biggest cause for gate failures, and
>>>  invited us to have a look at it.
>>>  I've raised its importance to high, but I don't have the cycles to
>>>  look at
>>>  it in the short term.
>>>  It would be really if somebody from the core team finds some time to
>>>  triage
>>>  it.
>>> 
>>>  Salvatore
>>> >>
>>>
>>

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

Re: [openstack-dev] [Savanna-all] How to run hadoop jobs

[Ruslan Kamaldinov]

Hi Arindam, 

There was a validation error during cluster creation. Can you send contents of 
cluster_create.json ?
Also, please attach output of:

$ http $SAVANNA_URL/images X-Auth-Token:$AUTH_TOKEN
$ http $SAVANNA_URL/node-group-templates X-Auth-Token:$AUTH_TOKEN
$ http $SAVANNA_URL/cluster-templates X-Auth-Token:$AUTH_TOKEN

Savanna debug logs also would be helpful. 


Please use *openstack-dev* as a mail-list for Savanna-related questions. Just 
prefix the subject with [Savanna].

Thanks,
Ruslan


On Saturday, July 13, 2013 at 9:24 PM, Arindam Choudhury wrote:

> Hi,
> 
> I installed savanna from the git repository. I can create cluster but only 
> with admin, when I try to create cluster with non-admin user it gives me an 
> error:
> 
> (keystone_arindam)]# http $SAVANNA_URL/clusters X-Auth-Token:$AUTH_TOKEN  < 
> cluster_create.json
> HTTP/1.1 500 INTERNAL SERVER ERROR
> Content-Length: 111
> Content-Type: application/json
> Date: Sat, 13 Jul 2013 16:47:25 GMT
> 
> {
> "error_code": 500,
> "error_message": "Error occurred during validation",
> "error_name": "INTERNAL_SERVER_ERROR"
> }
> 
> The hadoop daemons are not started automatically so I could not run the test 
> job.
> 
> hadoop@cluster-1-master-001:/usr/share/hadoop$ hadoop jar hadoop-examples.jar 
> pi 10 100
> Exception in thread "main" java.io.IOException: Error opening job jar: 
> hadoop-examples.jar
> at org.apache.hadoop.util.RunJar.main(RunJar.java:90)
> Caused by: java.io.FileNotFoundException: hadoop-examples.jar (No such file 
> or directory)
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.(ZipFile.java:214)
> at java.util.zip.ZipFile.(ZipFile.java:144)
> at java.util.jar.JarFile.(JarFile.java:153)
> at java.util.jar.JarFile.(JarFile.java:90)
> at org.apache.hadoop.util.RunJar.main(RunJar.java:88)
> hadoop@cluster-1-master-001:/usr/share/hadoop$ start-all.sh 
> (http://start-all.sh)
> mkdir: cannot create directory `/mnt/log': Permission denied
> chown: cannot access `/mnt/log/hadoop/hadoop/': No such file or directory
> starting namenode, logging to 
> /mnt/log/hadoop/hadoop//hadoop-hadoop-namenode-cluster-1-master-001.out
> /usr/sbin/hadoop-daemon.sh (http://hadoop-daemon.sh): line 136: 
> /mnt/log/hadoop/hadoop//hadoop-hadoop-namenode-cluster-1-master-001.out: No 
> such file or directory
> head: cannot open 
> `/mnt/log/hadoop/hadoop//hadoop-hadoop-namenode-cluster-1-master-001.out' for 
> reading: No such file or directory
> hadoop@localhost's password:
> 
> when I try to start hadoop manually, it asks for a password. How to do it? Am 
> I missing something?
> 
> Regards,
> Arindam
> 
> 
> -- 
> Mailing list: https://launchpad.net/~savanna-all
> Post to : savanna-...@lists.launchpad.net 
> (mailto:savanna-...@lists.launchpad.net)
> Unsubscribe : https://launchpad.net/~savanna-all
> More help : https://help.launchpad.net/ListHelp
> 
> 


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

Re: [openstack-dev] [OSLO] Comments/Questions on Messaging Wiki

[Doug Hellmann]

On Fri, Jul 12, 2013 at 8:09 PM, William Henry  wrote:

>
>
> Sent from my iPhone
>
> On Jul 12, 2013, at 5:27 PM, Doug Hellmann 
> wrote:
>
>
>
>
> On Fri, Jul 12, 2013 at 5:40 PM, William Henry  wrote:
>
>> Hi all,
>>
>> I've been reading through the Messaging Wiki and have some comments. Not
>> criticisms, just comments and questions.
>>  I have found this to be a very useful document. Thanks.
>>
>> 1. "There are multiple backend transport drivers which implement the API
>> semantics using different messaging systems - e.g. RabbitMQ, Qpid, ZeroMQ.
>> While both sides of a connection must use the same transport driver
>> configured in the same way, the API avoids exposing details of transports
>> so that code written using one transport should work with any other
>> transport."
>>
>> The good news for AMQP 1.0 users is that technically "boths sides of the
>> connection" do not have to use same transport driver. In pre-AMQP 1.0 days
>> this was the case. But today interoperability between AMQP 1.0
>> implementations has been demonstrated.
>>
>
> In this case I think we mean the Transport driver from within Oslo. So you
> could not connect a ZMQ Transport on one end to an AMQP Transport on the
> other. It will be an implementation detail of the AMQP Transport class to
> decide whether it supports more than one version of AMQP, or if the
> different versions are implemented as different Transports.
>
>
>>
>> 2. I notice under the RPC concepts section that you mention Exchanges as
>> a container in which topics are scoped. Is this exchange a pre AMQP 1.0
>> artifact or just a general term for oslo.messaging that is loosely based on
>> the pre-AMQP 1.0 artifact called an Exchange? i.e. are you assuming that
>> messaging implementations have something called an exchange? Or do you mean
>> that messaging implementations can scope a topic and in oslo we call that
>> scoping an exchange?
>>
>
> The latter.
>
>
> Ack. Good. Fits very well into AMQP 1.0 then ;-)
>
>
>
>>
>> 3. Some messaging nomenclature: The way the wiki describes RPC "Invoke
>> Method on One of Multiple Servers" is more like a queue than a topic. In
>> messaging a queue is something that multiple consumers can attach to and
>> one of them gets and services a message/request.  A topic is where 1+
>> consumers are "connected" and each receives a the message and each can
>> service it as it sees fit.  In pre-AMQP 1.0 terms what this seems to
>> describe is a direct exchange. And a direct excahnge can have multiple
>> consumers listening to a queue on that exchange.  (Remember that fanout is
>> just a generalization of topic in that all consumers get all fanout
>> messages - there are no sub-topics etc.)
>>
>> In AMQP 1.0 the addressing doesn't care or know about exchanges but it
>> can support this queue type behavior on an address or topic type behavior
>> on an address.
>>
>> I know this isn't about AMQP specifically but therefore this is even more
>> important. Topics are pub/sub with multiple consumer/services responding to
>> a single message. Queues are next consumer up gets the next message.
>>
>
>>
>> (BTW I've seen this kind of confusion also in early versions of
>> MCollective in Puppet.)
>>
>> It might be better to change some of the references to "topic" to
>> "address". This would solve the problem. i.e. a use case where one of many
>> servers listening on an address services a message/request. And later all
>> of servers listening on an address service a message/request. Addressing
>> also solves the one-to-one as the address is specific to the server (and
>> the others don't have to receive and reject the message).
>>
>
> Too many of these terms are overloaded. :-)
>
>
> Yep. But topic pup/sub is certainly different to a queue. ;-)
>
>
> I'm not sure of the details of how "topic" and "address" are different in
> AMQP 1.0. The word "address" implies to me that the message sender knows
> where the message receiver is in some concrete sense. We don't want those
> semantics in a lot of our use cases. If the "address" is abstract, then it
> sounds like it works much as a topic does. Maybe you can expand on the
> differences?
>
>
>
> Nope the address is essentially a namespace. The send knows not where it
> ends up. Hence in some applications it doesn't even know of its a topic or
> a queue an it could go to one or many depending.
>

OK, that sounds like it would be part of the Transport's handling of a
Target (
https://github.com/markmc/oslo.messaging/blob/master/oslo/messaging/target.py
).

Doug


>
> William
>
>
> Thanks,
> Doug
>
>
>
>>
>> Please feel free to respond and critique my comments/suggestions.
>>
>> Best,
>> William
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.or

Re: [openstack-dev] cells checks on patches

[Sean Dague]

On 07/13/2013 10:50 AM, Dan Smith wrote:

Currently cells can even get past devstack exercises, which are very
minor sanity checks for the environment (nothing tricky).


I thought that the plan was to deprecate the devstack exercises and
just use tempest. Is that not the case? I'd bet that the devstack
exercises are just not even on anyone's radar. Since the excellent work
you QA folks did to harden those tests before grizzly, I expect most
people take them for granted now :)

Digging into the logs just a bit, I see what looks like early failures
related to missing security group issues in the cells manager log. I
know there are some specific requirements in how things have to be set
up for cells, so I think it's likely that we'll need to do some
tweaking of configs to get all of this right.

We enabled the test knowing that it wasn't going to pass for a while,
and it's only been running for less than 24 hours. In the same way that
the grenade job had (until recently) been failing on everything, the
point of enabling the cells test now is so that we can start iterating
on fixes so that we can hopefully have some amount of regular test
coverage before havana.


Like I said, as long as someone is going to work on it, I'm happy. :) I 
just don't want this to be an enable the tests and hope magically 
fairies come to fix them issue. That's what we did on full neutron 
tests, and it's been bouncing around like that for a while.


We are planning on disabling the devstack exercises, it wasn't so much 
that, it's that it looks like there is fundamental lack of functioning 
nova on devstack for cells right now. The security groups stack trace is 
just a side effect of cells falling over in a really low level way (this 
is what's before and after the trace).


2013-07-13 00:12:18.605 ERROR nova.cells.scheduler 
[req-dcbb868c-98a7-4d65-94b3-e1234c50e623 demo demo] Couldn't 
communicate with cell 'child'


2013-07-13 00:12:18.606 ERROR nova.cells.scheduler 
[req-dcbb868c-98a7-4d65-94b3-e1234c50e623 demo demo] Couldn't 
communicate with any cells


Again, mostly I want to know that we've got a blueprint or bug that's 
high priority and someone's working on it. It did take a while to get 
grenade there (we're 2 bugs away from being able to do it repeatably in 
the gate), but during that time we did have people working on it. It 
just takes a while to get to the bottom of these issues some times, so I 
want people to have a realistic expectation on how quickly we'll go from 
running upstream to gating.


-Sean

--
Sean Dague
http://dague.net

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

Re: [openstack-dev] cells checks on patches

[Dan Smith]

> Currently cells can even get past devstack exercises, which are very 
> minor sanity checks for the environment (nothing tricky).

I thought that the plan was to deprecate the devstack exercises and
just use tempest. Is that not the case? I'd bet that the devstack
exercises are just not even on anyone's radar. Since the excellent work
you QA folks did to harden those tests before grizzly, I expect most
people take them for granted now :)

Digging into the logs just a bit, I see what looks like early failures
related to missing security group issues in the cells manager log. I
know there are some specific requirements in how things have to be set
up for cells, so I think it's likely that we'll need to do some
tweaking of configs to get all of this right.

We enabled the test knowing that it wasn't going to pass for a while,
and it's only been running for less than 24 hours. In the same way that
the grenade job had (until recently) been failing on everything, the
point of enabling the cells test now is so that we can start iterating
on fixes so that we can hopefully have some amount of regular test
coverage before havana.

--Dan

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

[openstack-dev] cells checks on patches

[Sean Dague]

So I'm all in favor of having a cells checks on patches, and I knew they 
were going to be failing up front, however I just started looking at the 
fail logs - 
http://logs.openstack.org/36907/2/check/gate-tempest-devstack-vm-cells-full/17/console.html.gz


Currently cells can even get past devstack exercises, which are very 
minor sanity checks for the environment (nothing tricky). Which means we 
never get to tempest, because we bail early. It's not just one exercise, 
it's 4 (basically anything that talks to nova fails), and it's not 
flakey, all 4 of those exercises have failed on every one of the half 
dozen runs I've spot checked.


Is there someone actively working to get cells in the gate running? 
(like this is their only blueprint for H3?). I expect if anyone wants 
this for H3 it's really going to require someone to be dedicated on it 
from now until then. This has a long ways to go, and given that we're 
already seeing devstack node starvation at times, we might want to 
rethink having this thing just chew up resource if it's not being really 
aggressively worked.


-Sean

--
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Review] Use of exception for non-exceptional cases

[Robert Collins]

On 11 July 2013 20:50, Mark McLoughlin  wrote:

>
> That answer does begin with this, though:
>
>   I almost always use hasattr: it's the correct choice for most cases.

I have to disagree here, hasattr is basically a timebomb. Three-param
getattr, or safe_hasattr are *much* better choices in every case I've
seen so far.

(safe_hasattr is in extras, or I believe there is a copy in oslo now).

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services

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