Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

[P Balaji-B37839]

Thanks for Suggestions and Support on this.

Regards,
Balaji.P
-Original Message-
From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com] 
Sent: Wednesday, September 11, 2013 1:48 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

+1

This is the best approach and one we discussed in Portland and a track most 
folks are developing plugins under ML2 

/Alan

-Original Message-
From: Robert Kukura [mailto:rkuk...@redhat.com] 
Sent: September-10-13 12:27 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

On 09/10/2013 10:45 AM, Mark McClain wrote:
> I think Gary and Kyle have answered this very well; however I do have a few 
> things to add.  It is definitely too late for Havana, so Icehouse is next 
> available release for new plugins.  I can work with you offline to find you a 
> core sponsor.

One more thing: Rather than implementing and maintaining an entire new plugin, 
consider whether it might make sense to integrate as an ml2 MechanismDriver 
instead. The ml2 plugin's MechanismDrivers can interface with network devices 
or controllers, and can work in conjunction with the existing L2 agents if 
needed. See
https://wiki.openstack.org/wiki/Neutron/ML2 for more info.

-Bob

> 
> mark
>  
> On Sep 10, 2013, at 9:37 AM, "Kyle Mestery (kmestery)"  
> wrote:
> 
>> On Sep 10, 2013, at 4:05 AM, P Balaji-B37839  wrote:
>>>
>>> Hi,
>>>
>>> We have gone through the below link for new plug-in development.
>>>
>>> https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neut
>>> ron_Plugin
>>>
>>> Just want to confirm that is it mandatory to be Core Neutron Developer for 
>>> submitting a new plug-in.?
>>>
>> It's not necessary for you to have a core developer from your company, but 
>> you will need an existing core developer to support your plugin upstream. 
>> When you file the blueprint, let us know and we'll work with you on this one 
>> Balaji.
>>
>> Thanks,
>> Kyle
>>
>>> How do we get a reviewer for this like Can we approach any Core Neutron 
>>> developer for review our plugin?
>>>
>>> We are developing new plug-in for our product and want to make it upstream 
>>> to Neutron Core.
>>>
>>> Any information on this will be helpful!.
>>>
>>> Regards,
>>> Balaji.P
>>
>>
> 
> 
> ___
> 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



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

[openstack-dev] [Glance] No meeting this week

[Mark Washenberger]

Hi folks,

I will be out this week after 23:00 UTC Wednesday, so I can't hold the
glance meeting this Thursday. I'll be back next Wednesday the 19th.

Let's get those RC1 bugs finished and reviewed!

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

Re: [openstack-dev] [Heat] How the autoscale API should control scaling in Heat

[Adrian Otto]

I have a different point of view. First I will offer some assertions:

A-1) We need to keep it simple.
A-1.1) Systems that are hard to comprehend are hard to debug, and 
that's bad.
A-1.2) Complex systems tend to be much more brittle than simple ones.

A-2) Scale-up operations need to be as-fast-as-possible. 
A-2.1) Auto-Scaling only works right if your new capacity is added 
quickly when your controller detects that you need more. If you spend a bunch 
of time goofing around before actually adding a new resource to a pool when its 
under staring. 
A-2.2) The fewer network round trips between "add-more-resources-now" 
and "resources-added" the better. Fewer = less brittle.

A-3) The control logic for scaling different applications vary. 
A-3.1) What metrics are watched may differ between various use cases. 
A-3.2) The data types that represent sensor data may vary.
A-3.3) The policy that's applied to the metrics (such as max, min, and 
cooldown period) vary between applications. Not only the values vary, but the 
logic itself.
A-3.4) A scaling policy may not just be a handful of simple parameters. 
Ideally it allows configurable logic that the end-user can control to some 
extent.

A-4) Auto-scale operations are usually not orchestrations. They are usually 
simple linear workflows.
A-4.1) The Taskflow project[1] offers a simple way to do workflows and 
stable state management that can be integrated directly into Autoscale.
A-4.2) A task flow (workflow) can trigger a Heat orchestration if 
needed.

Now a mental tool to think about control policies:

Auto-scaling is like steering a car. The control policy says that you want to 
drive equally between the two lane lines, and that if you drift off center, you 
gradually correct back toward center again. If the road bends, you try to 
remain in your lane as the lane lines curve. You try not to weave around in 
your lane, and you try not to drift out of the lane.

If your controller notices that you are about to drift out of your lane because 
the road is starting to bend, and you are distracted, or your hands slip off 
the wheel, you might drift out of your lane into nearby traffic. That's why you 
don't want a Rube Goldberg Machine[2] between you and the steering wheel. See 
assertions A-1 and A-2.

If you are driving an 18-wheel tractor/trailer truck, steering is different 
than if you are driving a Fiat. You need to wait longer and steer toward the 
outside of curves so your trailer does not lag behind on the inside of the 
curve behind you as you correct for a bend in the road. When you are driving 
the Fiat, you may want to aim for the middle of the lane at all times, possibly 
even apexing bends to reduce your driving distance, which is actually the 
opposite of what truck drivers need to do. Control policies apply to other 
parts of driving too. I want a different policy for braking than I use for 
steering. On some vehicles I go through a gear shifting workflow, and on others 
I don't. See assertion A-3.

So, I don't intend to argue the technical minutia of each design point, but I 
challenge you to make sure that we (1) arrive at a simple system that any 
OpenStack user can comprehend, (2) responds quickly to alarm stimulus, (3) is 
unlikely to fail, (4) can be easily customized with user-supplied logic that 
controls how the scaling happens, and under what conditions.

It would be better if we could explain Autoscale like this:

Heat -> Autoscale -> Nova, etc.
-or-
User -> Autoscale -> Nova, etc.

This approach allows use cases where (for whatever reason) the end user does 
not want to use Heat at all, but still wants something simple to be auto-scaled 
for them. Nobody would be scratching their heads wondering why things are going 
in circles.

>From an implementation perspective, that means the auto-scale service needs at 
>least a simple linear workflow capability in it that may trigger a Heat 
>orchestration if there is a good reason for it. This way, the typical use 
>cases don't have anything resembling circular dependencies. The source of 
>truth for how many members are currently in an Autoscaling group should be the 
>Autoscale service, not in the Heat database. If you want to expose that in 
>list-stack-resources output, then cause Heat to call out to the Autoscale 
>service to fetch that figure as needed. It is irrelevant to orchestration. 
>Code does not need to be duplicated. Both Autoscale and Heat can use the same 
>exact source code files for the code that launches/terminates instances of 
>resources.

References:
[1] https://wiki.openstack.org/wiki/TaskFlow
[2] http://en.wikipedia.org/wiki/Rube_Goldberg_machine

Thanks,

Adrian


On Aug 16, 2013, at 11:36 AM, Zane Bitter  wrote:

> On 16/08/13 00:50, Christopher Armstrong wrote:
>> *Introduction and Requirements*
>> 
>> So there's kind of a perfect storm happening around autoscaling in Heat
>> right now. It

Re: [openstack-dev] run_tests in debug mode fails

[Clark Boylan]

On Mon, Sep 9, 2013 at 4:20 AM, Rosa, Andrea (HP Cloud Services)
 wrote:
> Hi all
>
> I need to debug a specific test but when I try to run it in debug mode using 
> the "run_tests -d" (I need to attach pdb) that command fails but if I run the 
> script without the "-d" option that works.
> I created a brand-new env so I don't think it's related to my local env.
> Anyone is experiencing the same issue?
> Should I file a nova bug for that?
>
> Error details:
> ./run_tests.sh -d 
> nova.tests.integrated.test_servers.ServersTestV3.test_create_and_rebuild_server
> Traceback (most recent call last):
>   File "nova/tests/integrated/test_servers.py", line 43, in setUp
> super(ServersTest, self).setUp()
>   File "nova/tests/integrated/integrated_helpers.py", line 87, in setUp
> self.consoleauth = self.start_service('consoleauth')
>   File "nova/test.py", line 279, in start_service
> svc = self.useFixture(ServiceFixture(name, host, **kwargs))
>   File 
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/testtools/testcase.py",
>  line 591, in useFixture
> fixture.setUp()
>   File "nova/test.py", line 174, in setUp
> self.service = service.Service.create(**self.kwargs)
>   File "nova/service.py", line 245, in create
> manager = CONF.get(manager_cls, None)
>   File "/home/ubuntu/nova/.venv/lib/python2.7/_abcoll.py", line 342, in get
> return self[key]
>   File 
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py",
>  line 1610, in __getitem__
> return self.__getattr__(key)
>   File 
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py",
>  line 1606, in __getattr__
> return self._get(name)
>   File 
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py",
>  line 1930, in _get
> value = self._substitute(self._do_get(name, group, namespace))
>   File 
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py",
>  line 1948, in _do_get
> info = self._get_opt_info(name, group)
>   File 
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py",
>  line 2029, in _get_opt_info
> raise NoSuchOptError(opt_name, group)
> NoSuchOptError: no such option: consoleauth_manager
>
> Ran 1 test in 11.296s
> FAILED (failures=1)
>
There are a couple interesting things going on here, and I haven't
quite untangled all of it. Basically the consoleauth_manager option
comes from nova.consoleauth.manager and when we don't import that
module the option isn't available to us. For some reason when running
`python -m subunit.run
nova.tests.integrated.test_servers.ServersTestV3.test_create_and_rebuild_server`
or `python -m testtools.run
nova.tests.integrated.test_servers.ServersTestV3.test_create_and_rebuild_server`
(this is what run_tests.sh -d does) nova.consoleauth.manager isn't
being imported, but when running `testr run
nova.tests.integrated.test_servers.ServersTestV3.test_create_and_rebuild_server`
it is. Not sure why there is a difference (possibly related to
discover?).

I did manage to confirm that the attached patch mostly fixes the
problem. It allows me to run the above commands out of the a tox built
virtualenv, but not a run_tests.sh built virtualenv. This is the other
piece of the puzzle that I haven't sorted yet. I do have a hunch it
has to do with how oslo.config is installed. As a work around you can
source the tox virtualenv then run run_tests.sh -N -d and that should
work given the attached patch. I would submit a change to Gerrit but
would like to understand more of what is going on first. If someone
else groks this more please feel free to submit the fix instead.

Clark


integrated_helpers.patch
Description: Binary data
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] run_tests in debug mode fails

[Jian Wen]

Hello,

I can confirm this is a bug.
I use nosetests instead for the moment.

nosetests -s test.module
nosetests -s another.test:TestCase.test_method
nosetests -s a.test:TestCase
nosetests -s /path/to/test/file.py:test_function



On Mon, Sep 9, 2013 at 7:20 PM, Rosa, Andrea (HP Cloud Services) <
andrea.r...@hp.com> wrote:

> Hi all
>
> I need to debug a specific test but when I try to run it in debug mode
> using the "run_tests -d" (I need to attach pdb) that command fails but if I
> run the script without the "-d" option that works.
> I created a brand-new env so I don't think it's related to my local env.
> Anyone is experiencing the same issue?
> Should I file a nova bug for that?
>
> Error details:
> ./run_tests.sh -d
> nova.tests.integrated.test_servers.ServersTestV3.test_create_and_rebuild_server
> Traceback (most recent call last):
>   File "nova/tests/integrated/test_servers.py", line 43, in setUp
> super(ServersTest, self).setUp()
>   File "nova/tests/integrated/integrated_helpers.py", line 87, in setUp
> self.consoleauth = self.start_service('consoleauth')
>   File "nova/test.py", line 279, in start_service
> svc = self.useFixture(ServiceFixture(name, host, **kwargs))
>   File
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/testtools/testcase.py",
> line 591, in useFixture
> fixture.setUp()
>   File "nova/test.py", line 174, in setUp
> self.service = service.Service.create(**self.kwargs)
>   File "nova/service.py", line 245, in create
> manager = CONF.get(manager_cls, None)
>   File "/home/ubuntu/nova/.venv/lib/python2.7/_abcoll.py", line 342, in get
> return self[key]
>   File
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py",
> line 1610, in __getitem__
> return self.__getattr__(key)
>   File
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py",
> line 1606, in __getattr__
> return self._get(name)
>   File
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py",
> line 1930, in _get
> value = self._substitute(self._do_get(name, group, namespace))
>   File
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py",
> line 1948, in _do_get
> info = self._get_opt_info(name, group)
>   File
> "/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py",
> line 2029, in _get_opt_info
> raise NoSuchOptError(opt_name, group)
> NoSuchOptError: no such option: consoleauth_manager
>
> Ran 1 test in 11.296s
> FAILED (failures=1)
>
> Thanks
> --
> Andrea
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [savanna] Program name and Mission statement

[Mike Spreitzer]

Jon Maron  wrote on 09/10/2013 08:50:23 PM:

> From: Jon Maron 
> To: OpenStack Development Mailing List 
, 
> Cc: OpenStack Development Mailing List 

> Date: 09/10/2013 08:55 PM
> Subject: Re: [openstack-dev] [savanna] Program name and Mission 
statement
> 
> Openstack Big Data Platform

Let's see if you mean that.  Does this project aim to cover big data 
things besides MapReduce?  Can you give examples of other things that are 
in scope?

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

Re: [openstack-dev] [savanna] Program name and Mission statement

[Jon Maron]

Openstack Big Data Platform


On Sep 10, 2013, at 8:39 PM, David Scott  wrote:

> I vote for 'Open Stack Data'
> 
> 
> On Tue, Sep 10, 2013 at 5:30 PM, Zhongyue Luo  wrote:
>> Why not "OpenStack MapReduce"? I think that pretty much says it all?
>> 
>> 
>> On Wed, Sep 11, 2013 at 3:54 AM, Glen Campbell  wrote:
>>> "performant" isn't a word. Or, if it is, it means "having performance." I 
>>> think you mean "high-performance."
>>> 
>>> 
>>> On Tue, Sep 10, 2013 at 8:47 AM, Matthew Farrellee  wrote:
 Rough cut -
 
 Program: OpenStack Data Processing
 Mission: To provide the OpenStack community with an open, cutting edge, 
 performant and scalable data processing stack and associated management 
 interfaces.
 
 
 On 09/10/2013 09:26 AM, Sergey Lukjanov wrote:
> It sounds too broad IMO. Looks like we need to define Mission Statement
> first.
> 
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
> 
> On Sep 10, 2013, at 17:09, Alexander Kuznetsov  > wrote:
> 
>> My suggestion OpenStack Data Processing.
>> 
>> 
>> On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov
>> mailto:slukja...@mirantis.com>> wrote:
>> 
>> Hi folks,
>> 
>> due to the Incubator Application we should prepare Program name
>> and Mission statement for Savanna, so, I want to start mailing
>> thread about it.
>> 
>> Please, provide any ideas here.
>> 
>> P.S. List of existing programs:
>> https://wiki.openstack.org/wiki/Programs
>> P.P.S. https://wiki.openstack.org/wiki/Governance/NewPrograms
>> 
>> Sincerely yours,
>> Sergey Lukjanov
>> Savanna Technical Lead
>> Mirantis Inc.
>> 
>> 
>> ___
>> 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
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>>> 
>>> -- 
>>> Glen Campbell
>>> http://glenc.io • @glenc
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> -- 
>> Intel SSG/STOD/DCST/CIT
>> 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, 
>> China
>> +862161166500
>> 
>> ___
>> 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

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [savanna] Program name and Mission statement

[David Scott]

I vote for 'Open Stack Data'


On Tue, Sep 10, 2013 at 5:30 PM, Zhongyue Luo wrote:

> Why not "OpenStack MapReduce"? I think that pretty much says it all?
>
>
> On Wed, Sep 11, 2013 at 3:54 AM, Glen Campbell  wrote:
>
>> "performant" isn't a word. Or, if it is, it means "having performance." I
>> think you mean "high-performance."
>>
>>
>> On Tue, Sep 10, 2013 at 8:47 AM, Matthew Farrellee wrote:
>>
>>> Rough cut -
>>>
>>> Program: OpenStack Data Processing
>>> Mission: To provide the OpenStack community with an open, cutting edge,
>>> performant and scalable data processing stack and associated management
>>> interfaces.
>>>
>>>
>>> On 09/10/2013 09:26 AM, Sergey Lukjanov wrote:
>>>
 It sounds too broad IMO. Looks like we need to define Mission Statement
 first.

 Sincerely yours,
 Sergey Lukjanov
 Savanna Technical Lead
 Mirantis Inc.

 On Sep 10, 2013, at 17:09, Alexander Kuznetsov >>> > wrote:

  My suggestion OpenStack Data Processing.
>
>
> On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov
> mailto:slukja...@mirantis.com**>> wrote:
>
> Hi folks,
>
> due to the Incubator Application we should prepare Program name
> and Mission statement for Savanna, so, I want to start mailing
> thread about it.
>
> Please, provide any ideas here.
>
> P.S. List of existing programs:
> 
> https://wiki.openstack.org/**wiki/Programs
> P.P.S. 
> https://wiki.openstack.org/**wiki/Governance/NewPrograms
>
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
>
>
> __**_
> 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


>>>
>>> __**_
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.**org 
>>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>>>
>>
>>
>>
>> --
>> *Glen Campbell*
>> http://glenc.io • @glenc
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> *Intel SSG/STOD/DCST/CIT*
> 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
> China
> +862161166500
>
> ___
> 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] Program name and Mission statement

[Zhongyue Luo]

Why not "OpenStack MapReduce"? I think that pretty much says it all?


On Wed, Sep 11, 2013 at 3:54 AM, Glen Campbell  wrote:

> "performant" isn't a word. Or, if it is, it means "having performance." I
> think you mean "high-performance."
>
>
> On Tue, Sep 10, 2013 at 8:47 AM, Matthew Farrellee wrote:
>
>> Rough cut -
>>
>> Program: OpenStack Data Processing
>> Mission: To provide the OpenStack community with an open, cutting edge,
>> performant and scalable data processing stack and associated management
>> interfaces.
>>
>>
>> On 09/10/2013 09:26 AM, Sergey Lukjanov wrote:
>>
>>> It sounds too broad IMO. Looks like we need to define Mission Statement
>>> first.
>>>
>>> Sincerely yours,
>>> Sergey Lukjanov
>>> Savanna Technical Lead
>>> Mirantis Inc.
>>>
>>> On Sep 10, 2013, at 17:09, Alexander Kuznetsov >> > wrote:
>>>
>>>  My suggestion OpenStack Data Processing.


 On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov
 mailto:slukja...@mirantis.com**>> wrote:

 Hi folks,

 due to the Incubator Application we should prepare Program name
 and Mission statement for Savanna, so, I want to start mailing
 thread about it.

 Please, provide any ideas here.

 P.S. List of existing programs:
 
 https://wiki.openstack.org/**wiki/Programs
 P.P.S. 
 https://wiki.openstack.org/**wiki/Governance/NewPrograms

 Sincerely yours,
 Sergey Lukjanov
 Savanna Technical Lead
 Mirantis Inc.


 __**_
 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
>>>
>>>
>>
>> __**_
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.**org 
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>>
>
>
>
> --
> *Glen Campbell*
> http://glenc.io • @glenc
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
*Intel SSG/STOD/DCST/CIT*
880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
China
+862161166500
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Comments/questions on the instance-group-api-extension blueprint

[Russell Bryant]

On 09/10/2013 04:58 PM, Mike Spreitzer wrote:
> First, I'm a newbie here, wondering: is this the right place for
> comments/questions on blueprints?  Supposing it is...

Yes, this is the right place.

> I am referring to
> https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension
> 
> In my own research group we have experience with a few systems that do
> something like that, and more (as, indeed, that blueprint explicitly
> states that it is only the start of a longer roadmap).  I would like to
> highlight a couple of differences that alarm me.  One is the general
> overlap between groups.  I am not saying this is wrong, but as a matter
> of natural conservatism we have shied away from unnecessary
> complexities.  The only overlap we have done so far is hierarchical
> nesting.  As the instance-group-api-extension explicitly contemplates
> groups of groups as a later development, this would cover the overlap
> that we have needed.  On the other hand, we already have multiple
> "policies" attached to a single group.  We have policies for a variety
> of concerns, so some can combine completely or somewhat independently.
>  We also have relationships (of various sorts) between groups (as well
> as between individuals, and between individuals and groups).  The
> policies and relationships, in general, are not simply names but also
> have parameters.

I'll let those driving this feature comment on this.  I just wanted to
confirm that you're in the right place.  :-)

-- 
Russell Bryant

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

Re: [openstack-dev] [nova] [pci device passthrough] fails with "NameError: global name '_' is not defined"

[David Kang]

- Original Message -
> From: "Russell Bryant" 
> To: "David Kang" 
> Cc: "OpenStack Development Mailing List" 
> Sent: Tuesday, September 10, 2013 5:17:15 PM
> Subject: Re: [openstack-dev] [nova] [pci device passthrough] fails with 
> "NameError: global name '_' is not defined"
> On 09/10/2013 05:03 PM, David Kang wrote:
> >
> > - Original Message -
> >> From: "Russell Bryant" 
> >> To: "OpenStack Development Mailing List"
> >> 
> >> Cc: "David Kang" 
> >> Sent: Tuesday, September 10, 2013 4:42:41 PM
> >> Subject: Re: [openstack-dev] [nova] [pci device passthrough] fails
> >> with "NameError: global name '_' is not defined"
> >> On 09/10/2013 03:56 PM, David Kang wrote:
> >>>
> >>>  Hi,
> >>>
> >>>   I'm trying to test pci device passthrough feature.
> >>> Havana3 is installed using Packstack on CentOS 6.4.
> >>> Nova-compute dies right after start with error "NameError: global
> >>> name '_' is not defined".
> >>> I'm not sure if it is due to misconfiguration of nova.conf or bug.
> >>> Any help will be appreciated.
> >>>
> >>> Here is the info:
> >>>
> >>> /etc/nova/nova.conf:
> >>> pci_alias={"name":"test", "product_id":"7190", "vendor_id":"8086",
> >>> "device_type":"ACCEL"}
> >>>
> >>> pci_passthrough_whitelist=[{"vendor_id":"8086","product_id":"7190"}]
> >>>
> >>>  With that configuration, nova-compute fails with the following
> >>>  log:
> >>>
> >>>   File
> >>>   "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py",
> >>>   line 461, in _process_data
> >>> **args)
> >>>
> >>>   File
> >>>   
> >>> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py",
> >>>   line 172, in dispatch
> >>> result = getattr(proxyobj, method)(ctxt, **kwargs)
> >>>
> >>>   File
> >>>   "/usr/lib/python2.6/site-packages/nova/conductor/manager.py",
> >>>   line 567, in object_action
> >>> result = getattr(objinst, objmethod)(context, *args, **kwargs)
> >>>
> >>>   File "/usr/lib/python2.6/site-packages/nova/objects/base.py",
> >>>   line
> >>>   141, in wrapper
> >>> return fn(self, ctxt, *args, **kwargs)
> >>>
> >>>   File
> >>>   "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py",
> >>>   line 242, in save
> >>> self._from_db_object(context, self, db_pci)
> >>>
> >>> NameError: global name '_' is not defined
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup Traceback (most recent call
> >>> last):
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup File
> >>> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py",
> >>> line 117, in wait
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup x.wait()
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup File
> >>> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py",
> >>> line 49, in wait
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup return self.thread.wait()
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup File
> >>> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line
> >>> 166, in wait
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup return self._exit_event.wait()
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup File
> >>> "/usr/lib/python2.6/site-packages/eventlet/event.py", line 116, in
> >>> wait
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup return hubs.get_hub().switch()
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup File
> >>> "/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py", line 177,
> >>> in switch
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup return self.greenlet.switch()
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup File
> >>> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line
> >>> 192, in main
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup result = function(*args,
> >>> **kwargs)
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup File
> >>> "/usr/lib/python2.6/site-packages/nova/openstack/common/service.py",
> >>> line 65, in run_service
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup service.start()
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup File
> >>> "/usr/lib/python2.6/site-packages/nova/service.py", line 164, in
> >>> start
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup self.manager.pre_start_hook()
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openstack.common.threadgroup File
> >>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line
> >>> 805, in pre_start_hook
> >>> 2013-09-10 12:52:23.774 14749 TRACE
> >>> nova.openst

Re: [openstack-dev] How to redirect the user from Horizon to a particular endpoint

[Jesse Pretorius]

On 10 September 2013 18:02, D.Selvaraj  wrote:

>  I am working in providing federated access to Horizon. As of now I have
> got a dropdown form that displays the list of Identity providers available
> in teh Keystone. But I am confused on how to redirect the user to the
> server that is to the Identity Provider from Horizon ? Please help
>
>
As I recall Horizon still has the concept of 'Regions' in its
configuration. When you configure the regions you indicate the keystone
endpoint for each region. This provides a drop-down box for the user to
select their region when they login.

It's been a while since I've tested it, so I'm not sure if it still works,
but perhaps that'll help.

Check local_settings for the keyword 'REGION'.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

[Alan Kavanagh]

+1

This is the best approach and one we discussed in Portland and a track most 
folks are developing plugins under ML2 

/Alan

-Original Message-
From: Robert Kukura [mailto:rkuk...@redhat.com] 
Sent: September-10-13 12:27 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

On 09/10/2013 10:45 AM, Mark McClain wrote:
> I think Gary and Kyle have answered this very well; however I do have a few 
> things to add.  It is definitely too late for Havana, so Icehouse is next 
> available release for new plugins.  I can work with you offline to find you a 
> core sponsor.

One more thing: Rather than implementing and maintaining an entire new plugin, 
consider whether it might make sense to integrate as an ml2 MechanismDriver 
instead. The ml2 plugin's MechanismDrivers can interface with network devices 
or controllers, and can work in conjunction with the existing L2 agents if 
needed. See
https://wiki.openstack.org/wiki/Neutron/ML2 for more info.

-Bob

> 
> mark
>  
> On Sep 10, 2013, at 9:37 AM, "Kyle Mestery (kmestery)"  
> wrote:
> 
>> On Sep 10, 2013, at 4:05 AM, P Balaji-B37839  wrote:
>>>
>>> Hi,
>>>
>>> We have gone through the below link for new plug-in development.
>>>
>>> https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neut
>>> ron_Plugin
>>>
>>> Just want to confirm that is it mandatory to be Core Neutron Developer for 
>>> submitting a new plug-in.?
>>>
>> It's not necessary for you to have a core developer from your company, but 
>> you will need an existing core developer to support your plugin upstream. 
>> When you file the blueprint, let us know and we'll work with you on this one 
>> Balaji.
>>
>> Thanks,
>> Kyle
>>
>>> How do we get a reviewer for this like Can we approach any Core Neutron 
>>> developer for review our plugin?
>>>
>>> We are developing new plug-in for our product and want to make it upstream 
>>> to Neutron Core.
>>>
>>> Any information on this will be helpful!.
>>>
>>> Regards,
>>> Balaji.P
>>
>>
> 
> 
> ___
> 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

[openstack-dev] [heat] Comments/questions on the instance-group-api-extension blueprint

[Mike Spreitzer]

First, I'm a newbie here, wondering: is this the right place for 
comments/questions on blueprints?  Supposing it is...

I am referring to 
https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension

In my own research group we have experience with a few systems that do 
something like that, and more (as, indeed, that blueprint explicitly 
states that it is only the start of a longer roadmap).  I would like to 
highlight a couple of differences that alarm me.  One is the general 
overlap between groups.  I am not saying this is wrong, but as a matter of 
natural conservatism we have shied away from unnecessary complexities. The 
only overlap we have done so far is hierarchical nesting.  As the 
instance-group-api-extension explicitly contemplates groups of groups as a 
later development, this would cover the overlap that we have needed.  On 
the other hand, we already have multiple "policies" attached to a single 
group.  We have policies for a variety of concerns, so some can combine 
completely or somewhat independently.  We also have relationships (of 
various sorts) between groups (as well as between individuals, and between 
individuals and groups).  The policies and relationships, in general, are 
not simply names but also have parameters.

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

Re: [openstack-dev] [Infra] Meeting Tuesday September 10th at 19:00 UTC

[Elizabeth Krumbach Joseph]

On Mon, Sep 9, 2013 at 10:57 AM, Elizabeth Krumbach Joseph
 wrote:
> The OpenStack Infrastructure (Infra) team is hosting our weekly
> meeting tomorrow, Tuesday September 10th, at 19:00 UTC in
> #openstack-meeting

Meeting minutes and logs:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-09-10-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-09-10-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-09-10-19.01.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

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

[openstack-dev] [nova] [pci device passthrough] fails with "NameError: global name '_' is not defined"

[David Kang]

 Hi,

  I'm trying to test pci device passthrough feature.
Havana3 is installed using Packstack on CentOS 6.4.
Nova-compute dies right after start with error "NameError: global name '_' is 
not defined".
I'm not sure if it is due to misconfiguration of nova.conf or bug.
Any help will be appreciated.

Here is the info:

/etc/nova/nova.conf:
pci_alias={"name":"test", "product_id":"7190", "vendor_id":"8086", 
"device_type":"ACCEL"}

pci_passthrough_whitelist=[{"vendor_id":"8086","product_id":"7190"}]

 With that configuration, nova-compute fails with the following log:

  File "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py", 
line 461, in _process_data
**args)

  File 
"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py", 
line 172, in dispatch
result = getattr(proxyobj, method)(ctxt, **kwargs)

  File "/usr/lib/python2.6/site-packages/nova/conductor/manager.py", line 567, 
in object_action
result = getattr(objinst, objmethod)(context, *args, **kwargs)

  File "/usr/lib/python2.6/site-packages/nova/objects/base.py", line 141, in 
wrapper
return fn(self, ctxt, *args, **kwargs)

  File "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py", line 242, 
in save
self._from_db_object(context, self, db_pci)

NameError: global name '_' is not defined
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup Traceback 
(most recent call last):
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py", line 
117, in wait
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
x.wait()
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py", line 
49, in wait
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
return self.thread.wait()
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line 166, in wait
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
return self._exit_event.wait()
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/eventlet/event.py", line 116, in wait
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
return hubs.get_hub().switch()
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py", line 177, in switch
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
return self.greenlet.switch()
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line 192, in main
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
result = function(*args, **kwargs)
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/nova/openstack/common/service.py", line 65, 
in run_service
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
service.start()
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/nova/service.py", line 164, in start
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
self.manager.pre_start_hook()
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 805, in 
pre_start_hook
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
self.update_available_resource(nova.context.get_admin_context())
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 4773, in 
update_available_resource
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
rt.update_available_resource(context)
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py", line 
246, in inner
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
return f(*args, **kwargs)
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py", line 318, 
in update_available_resource
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
self._sync_compute_node(context, resources)
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
"/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py", line 347, 
in _sync_compute_node
2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
self._update(context, resources, prune_stats=Tr

Re: [openstack-dev] [nova] [pci device passthrough] fails with "NameError: global name '_' is not defined"

[Russell Bryant]

On 09/10/2013 04:42 PM, Russell Bryant wrote:
> On 09/10/2013 03:56 PM, David Kang wrote:
>>
>>  Hi,
>>
>>   I'm trying to test pci device passthrough feature.
>> Havana3 is installed using Packstack on CentOS 6.4.
>> Nova-compute dies right after start with error "NameError: global name '_' 
>> is not defined".
>> I'm not sure if it is due to misconfiguration of nova.conf or bug.
>> Any help will be appreciated.
>>
>> Here is the info:
>>
>> /etc/nova/nova.conf:
>> pci_alias={"name":"test", "product_id":"7190", "vendor_id":"8086", 
>> "device_type":"ACCEL"}
>>
>> pci_passthrough_whitelist=[{"vendor_id":"8086","product_id":"7190"}]
>>
>>  With that configuration, nova-compute fails with the following log:
>>
>>   File "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py", 
>> line 461, in _process_data
>> **args)
>>
>>   File 
>> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py", 
>> line 172, in dispatch
>> result = getattr(proxyobj, method)(ctxt, **kwargs)
>>
>>   File "/usr/lib/python2.6/site-packages/nova/conductor/manager.py", line 
>> 567, in object_action
>> result = getattr(objinst, objmethod)(context, *args, **kwargs)
>>
>>   File "/usr/lib/python2.6/site-packages/nova/objects/base.py", line 141, in 
>> wrapper
>> return fn(self, ctxt, *args, **kwargs)
>>
>>   File "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py", line 
>> 242, in save
>> self._from_db_object(context, self, db_pci)
>>
>> NameError: global name '_' is not defined
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> Traceback (most recent call last):
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py", 
>> line 117, in wait
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> x.wait()
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py", 
>> line 49, in wait
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> return self.thread.wait()
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line 166, in wait
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> return self._exit_event.wait()
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/eventlet/event.py", line 116, in wait
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> return hubs.get_hub().switch()
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py", line 177, in switch
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> return self.greenlet.switch()
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line 192, in main
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> result = function(*args, **kwargs)
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/nova/openstack/common/service.py", line 
>> 65, in run_service
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> service.start()
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/nova/service.py", line 164, in start
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> self.manager.pre_start_hook()
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 805, in 
>> pre_start_hook
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> self.update_available_resource(nova.context.get_admin_context())
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 4773, in 
>> update_available_resource
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> rt.update_available_resource(context)
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py", line 
>> 246, in inner
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
>> return f(*args, **kwargs)
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
>> "/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py", line 
>> 318, in update_available_resource
>> 2013-09-10 12:52:23.774 14749 TRACE nova.openstac

Re: [openstack-dev] [nova] [pci device passthrough] fails with "NameError: global name '_' is not defined"

[Russell Bryant]

On 09/10/2013 03:56 PM, David Kang wrote:
> 
>  Hi,
> 
>   I'm trying to test pci device passthrough feature.
> Havana3 is installed using Packstack on CentOS 6.4.
> Nova-compute dies right after start with error "NameError: global name '_' is 
> not defined".
> I'm not sure if it is due to misconfiguration of nova.conf or bug.
> Any help will be appreciated.
> 
> Here is the info:
> 
> /etc/nova/nova.conf:
> pci_alias={"name":"test", "product_id":"7190", "vendor_id":"8086", 
> "device_type":"ACCEL"}
> 
> pci_passthrough_whitelist=[{"vendor_id":"8086","product_id":"7190"}]
> 
>  With that configuration, nova-compute fails with the following log:
> 
>   File "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py", 
> line 461, in _process_data
> **args)
> 
>   File 
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py", 
> line 172, in dispatch
> result = getattr(proxyobj, method)(ctxt, **kwargs)
> 
>   File "/usr/lib/python2.6/site-packages/nova/conductor/manager.py", line 
> 567, in object_action
> result = getattr(objinst, objmethod)(context, *args, **kwargs)
> 
>   File "/usr/lib/python2.6/site-packages/nova/objects/base.py", line 141, in 
> wrapper
> return fn(self, ctxt, *args, **kwargs)
> 
>   File "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py", line 
> 242, in save
> self._from_db_object(context, self, db_pci)
> 
> NameError: global name '_' is not defined
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> Traceback (most recent call last):
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py", line 
> 117, in wait
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> x.wait()
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py", line 
> 49, in wait
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> return self.thread.wait()
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line 166, in wait
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> return self._exit_event.wait()
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/eventlet/event.py", line 116, in wait
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> return hubs.get_hub().switch()
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py", line 177, in switch
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> return self.greenlet.switch()
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line 192, in main
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> result = function(*args, **kwargs)
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/nova/openstack/common/service.py", line 65, 
> in run_service
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> service.start()
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/nova/service.py", line 164, in start
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> self.manager.pre_start_hook()
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 805, in 
> pre_start_hook
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> self.update_available_resource(nova.context.get_admin_context())
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 4773, in 
> update_available_resource
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> rt.update_available_resource(context)
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py", line 
> 246, in inner
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> return f(*args, **kwargs)
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup   File 
> "/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py", line 
> 318, in update_available_resource
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.threadgroup 
> self._sync_compute_node(context, resources)
> 2013-09-10 12:52:23.774 14749 TRACE nova.openstack.common.th

Re: [openstack-dev] [nova] [pci device passthrough] fails with "NameError: global name '_' is not defined"

[David Kang]

- Original Message -
> From: "Russell Bryant" 
> To: "OpenStack Development Mailing List" 
> Cc: "David Kang" 
> Sent: Tuesday, September 10, 2013 4:42:41 PM
> Subject: Re: [openstack-dev] [nova] [pci device passthrough] fails with 
> "NameError: global name '_' is not defined"
> On 09/10/2013 03:56 PM, David Kang wrote:
> >
> >  Hi,
> >
> >   I'm trying to test pci device passthrough feature.
> > Havana3 is installed using Packstack on CentOS 6.4.
> > Nova-compute dies right after start with error "NameError: global
> > name '_' is not defined".
> > I'm not sure if it is due to misconfiguration of nova.conf or bug.
> > Any help will be appreciated.
> >
> > Here is the info:
> >
> > /etc/nova/nova.conf:
> > pci_alias={"name":"test", "product_id":"7190", "vendor_id":"8086",
> > "device_type":"ACCEL"}
> >
> > pci_passthrough_whitelist=[{"vendor_id":"8086","product_id":"7190"}]
> >
> >  With that configuration, nova-compute fails with the following log:
> >
> >   File
> >   "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py",
> >   line 461, in _process_data
> > **args)
> >
> >   File
> >   
> > "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py",
> >   line 172, in dispatch
> > result = getattr(proxyobj, method)(ctxt, **kwargs)
> >
> >   File "/usr/lib/python2.6/site-packages/nova/conductor/manager.py",
> >   line 567, in object_action
> > result = getattr(objinst, objmethod)(context, *args, **kwargs)
> >
> >   File "/usr/lib/python2.6/site-packages/nova/objects/base.py", line
> >   141, in wrapper
> > return fn(self, ctxt, *args, **kwargs)
> >
> >   File
> >   "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py",
> >   line 242, in save
> > self._from_db_object(context, self, db_pci)
> >
> > NameError: global name '_' is not defined
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup Traceback (most recent call last):
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup File
> > "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py",
> > line 117, in wait
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup x.wait()
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup File
> > "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py",
> > line 49, in wait
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup return self.thread.wait()
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup File
> > "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line
> > 166, in wait
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup return self._exit_event.wait()
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup File
> > "/usr/lib/python2.6/site-packages/eventlet/event.py", line 116, in
> > wait
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup return hubs.get_hub().switch()
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup File
> > "/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py", line 177,
> > in switch
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup return self.greenlet.switch()
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup File
> > "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line
> > 192, in main
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup result = function(*args, **kwargs)
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup File
> > "/usr/lib/python2.6/site-packages/nova/openstack/common/service.py",
> > line 65, in run_service
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup service.start()
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup File
> > "/usr/lib/python2.6/site-packages/nova/service.py", line 164, in
> > start
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup self.manager.pre_start_hook()
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup File
> > "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line
> > 805, in pre_start_hook
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup
> > self.update_available_resource(nova.context.get_admin_context())
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup File
> > "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line
> > 4773, in update_available_resource
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup
> > rt.update_available_resource(context)
> > 2013-09-10 12:52:23.774 14749 TRACE
> > nova.openstack.common.threadgroup File
> > "/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py",
> > line 246, in inner
> > 2013-09-10 12:

Re: [openstack-dev] [nova] [pci device passthrough] fails with "NameError: global name '_' is not defined"

[Russell Bryant]

On 09/10/2013 05:03 PM, David Kang wrote:
> 
> - Original Message -
>> From: "Russell Bryant" 
>> To: "OpenStack Development Mailing List" 
>> Cc: "David Kang" 
>> Sent: Tuesday, September 10, 2013 4:42:41 PM
>> Subject: Re: [openstack-dev] [nova] [pci device passthrough] fails with 
>> "NameError: global name '_' is not defined"
>> On 09/10/2013 03:56 PM, David Kang wrote:
>>>
>>>  Hi,
>>>
>>>   I'm trying to test pci device passthrough feature.
>>> Havana3 is installed using Packstack on CentOS 6.4.
>>> Nova-compute dies right after start with error "NameError: global
>>> name '_' is not defined".
>>> I'm not sure if it is due to misconfiguration of nova.conf or bug.
>>> Any help will be appreciated.
>>>
>>> Here is the info:
>>>
>>> /etc/nova/nova.conf:
>>> pci_alias={"name":"test", "product_id":"7190", "vendor_id":"8086",
>>> "device_type":"ACCEL"}
>>>
>>> pci_passthrough_whitelist=[{"vendor_id":"8086","product_id":"7190"}]
>>>
>>>  With that configuration, nova-compute fails with the following log:
>>>
>>>   File
>>>   "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py",
>>>   line 461, in _process_data
>>> **args)
>>>
>>>   File
>>>   
>>> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py",
>>>   line 172, in dispatch
>>> result = getattr(proxyobj, method)(ctxt, **kwargs)
>>>
>>>   File "/usr/lib/python2.6/site-packages/nova/conductor/manager.py",
>>>   line 567, in object_action
>>> result = getattr(objinst, objmethod)(context, *args, **kwargs)
>>>
>>>   File "/usr/lib/python2.6/site-packages/nova/objects/base.py", line
>>>   141, in wrapper
>>> return fn(self, ctxt, *args, **kwargs)
>>>
>>>   File
>>>   "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py",
>>>   line 242, in save
>>> self._from_db_object(context, self, db_pci)
>>>
>>> NameError: global name '_' is not defined
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup Traceback (most recent call last):
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup File
>>> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py",
>>> line 117, in wait
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup x.wait()
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup File
>>> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py",
>>> line 49, in wait
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup return self.thread.wait()
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup File
>>> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line
>>> 166, in wait
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup return self._exit_event.wait()
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup File
>>> "/usr/lib/python2.6/site-packages/eventlet/event.py", line 116, in
>>> wait
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup return hubs.get_hub().switch()
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup File
>>> "/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py", line 177,
>>> in switch
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup return self.greenlet.switch()
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup File
>>> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line
>>> 192, in main
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup result = function(*args, **kwargs)
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup File
>>> "/usr/lib/python2.6/site-packages/nova/openstack/common/service.py",
>>> line 65, in run_service
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup service.start()
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup File
>>> "/usr/lib/python2.6/site-packages/nova/service.py", line 164, in
>>> start
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup self.manager.pre_start_hook()
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup File
>>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line
>>> 805, in pre_start_hook
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup
>>> self.update_available_resource(nova.context.get_admin_context())
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup File
>>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line
>>> 4773, in update_available_resource
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup
>>> rt.update_available_resource(context)
>>> 2013-09-10 12:52:23.774 14749 TRACE
>>> nova.openstack.common.threadgroup File
>>> "/usr/lib/python2.6/site-packages/nova/openstack/common/loc

Re: [openstack-dev] [savanna] Program name and Mission statement

[Glen Campbell]

"performant" isn't a word. Or, if it is, it means "having performance." I
think you mean "high-performance."


On Tue, Sep 10, 2013 at 8:47 AM, Matthew Farrellee  wrote:

> Rough cut -
>
> Program: OpenStack Data Processing
> Mission: To provide the OpenStack community with an open, cutting edge,
> performant and scalable data processing stack and associated management
> interfaces.
>
>
> On 09/10/2013 09:26 AM, Sergey Lukjanov wrote:
>
>> It sounds too broad IMO. Looks like we need to define Mission Statement
>> first.
>>
>> Sincerely yours,
>> Sergey Lukjanov
>> Savanna Technical Lead
>> Mirantis Inc.
>>
>> On Sep 10, 2013, at 17:09, Alexander Kuznetsov > > wrote:
>>
>>  My suggestion OpenStack Data Processing.
>>>
>>>
>>> On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov
>>> mailto:slukja...@mirantis.com**>> wrote:
>>>
>>> Hi folks,
>>>
>>> due to the Incubator Application we should prepare Program name
>>> and Mission statement for Savanna, so, I want to start mailing
>>> thread about it.
>>>
>>> Please, provide any ideas here.
>>>
>>> P.S. List of existing programs:
>>> 
>>> https://wiki.openstack.org/**wiki/Programs
>>> P.P.S. 
>>> https://wiki.openstack.org/**wiki/Governance/NewPrograms
>>>
>>> Sincerely yours,
>>> Sergey Lukjanov
>>> Savanna Technical Lead
>>> Mirantis Inc.
>>>
>>>
>>> __**_
>>> 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
>>
>>
>
> __**_
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.**org 
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>



-- 
*Glen Campbell*
http://glenc.io • @glenc
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [savanna] Program name and Mission statement

[Ed Leafe]

On Sep 10, 2013, at 2:14 PM, Ian Wells  wrote:

> Speaking as someone who didn't know what Savanna was before now... I still 
> don't know what Savanna is.  You need to be more specific than that.

+1

-- Ed Leafe


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

[openstack-dev] How to redirect the user from Horizon to a particular endpoint

[D . Selvaraj]

Hi,

I am working in providing federated access to Horizon. As of now I have got a 
dropdown form that displays the list of Identity providers available in teh 
Keystone. But I am confused on how to redirect the user to the server that is 
to the Identity Provider from Horizon ? Please help

Thank you



Regards



Deepak Selvaraj

MSc.,Future Computing

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

Re: [openstack-dev] [savanna] Program name and Mission statement

[Ian Wells]

Speaking as someone who didn't know what Savanna was before now... I still
don't know what Savanna is.  You need to be more specific than that.
-- 
Ian.


On 10 September 2013 18:34, Sergey Lukjanov  wrote:

> +1 for both program name and mission statement
>
>
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
>
> On Sep 10, 2013, at 21:22, Ilya Elterman  wrote:
>
> +1 for OpenStack Data Processing and
>
> Mission: To provide the OpenStack community with an open, cutting edge,
>> performant and scalable data processing stack and associated management
>> interfaces.
>
>
>
> On Tue, Sep 10, 2013 at 6:47 AM, Matthew Farrellee wrote:
>
>> Rough cut -
>>
>> Program: OpenStack Data Processing
>> Mission: To provide the OpenStack community with an open, cutting edge,
>> performant and scalable data processing stack and associated management
>> interfaces.
>>
>>
>> On 09/10/2013 09:26 AM, Sergey Lukjanov wrote:
>>
>>> It sounds too broad IMO. Looks like we need to define Mission Statement
>>> first.
>>>
>>> Sincerely yours,
>>> Sergey Lukjanov
>>> Savanna Technical Lead
>>> Mirantis Inc.
>>>
>>> On Sep 10, 2013, at 17:09, Alexander Kuznetsov >> > wrote:
>>>
>>>  My suggestion OpenStack Data Processing.


 On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov
 mailto:slukja...@mirantis.com**>> wrote:

 Hi folks,

 due to the Incubator Application we should prepare Program name
 and Mission statement for Savanna, so, I want to start mailing
 thread about it.

 Please, provide any ideas here.

 P.S. List of existing programs:
 
 https://wiki.openstack.org/**wiki/Programs
 P.P.S. 
 https://wiki.openstack.org/**wiki/Governance/NewPrograms

 Sincerely yours,
 Sergey Lukjanov
 Savanna Technical Lead
 Mirantis Inc.


 __**_
 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
>>>
>>>
>>
>> __**_
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.**org 
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>>
>
>
>
> --
> Ilya Elterman
> Senior Director,
> Cloud Services,
> Mirantis
> http://www.mirantis.com
> tel. +1 650 963 9828
> mob. +1 650 561 5779
>  ___
> 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

[openstack-dev] Hyper-V Meeting Minutes

[Alessandro Pilotti]

Hi everyone,

Today’s Hyper-V meeting minutes.

Minutes:
http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-09-10-16.02.html
Minutes (text): 
http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-09-10-16.02.txt
Log:
http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-09-10-16.02.log.html


Thanks,

Alessandro



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

Re: [openstack-dev] OpenStack + PyPy: Status and goals

[Flavio Percoco]

On 10/09/13 08:18 -0700, Alex Gaynor wrote:

Hi Roman,

Yes eventlet works well on PyPy, both Marconi and Swift use it.


Small nit, Marconi is not using eventlet. It used to depend on eventlet
because openstack.common.local did but that part is gone now.

FF

--
@flaper87
Flavio Percoco

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

Re: [openstack-dev] [savanna] Program name and Mission statement

[Sergey Lukjanov]

+1 for both program name and mission statement

Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.

On Sep 10, 2013, at 21:22, Ilya Elterman  wrote:

> +1 for OpenStack Data Processing and
> 
> Mission: To provide the OpenStack community with an open, cutting edge, 
> performant and scalable data processing stack and associated management 
> interfaces.
> 
> 
> On Tue, Sep 10, 2013 at 6:47 AM, Matthew Farrellee  wrote:
> Rough cut -
> 
> Program: OpenStack Data Processing
> Mission: To provide the OpenStack community with an open, cutting edge, 
> performant and scalable data processing stack and associated management 
> interfaces.
> 
> 
> On 09/10/2013 09:26 AM, Sergey Lukjanov wrote:
> It sounds too broad IMO. Looks like we need to define Mission Statement
> first.
> 
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
> 
> On Sep 10, 2013, at 17:09, Alexander Kuznetsov  > wrote:
> 
> My suggestion OpenStack Data Processing.
> 
> 
> On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov
> mailto:slukja...@mirantis.com>> wrote:
> 
> Hi folks,
> 
> due to the Incubator Application we should prepare Program name
> and Mission statement for Savanna, so, I want to start mailing
> thread about it.
> 
> Please, provide any ideas here.
> 
> P.S. List of existing programs:
> https://wiki.openstack.org/wiki/Programs
> P.P.S. https://wiki.openstack.org/wiki/Governance/NewPrograms
> 
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
> 
> 
> ___
> 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
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Ilya Elterman
> Senior Director, 
> Cloud Services,
> Mirantis
> http://www.mirantis.com
> tel. +1 650 963 9828
> mob. +1 650 561 5779
> ___
> 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-dashboard] version 0.3 - updated UI mockups for EDP workflow

[Nadya Privalova]

Hi all,

I've created a temporary page for UIs mockups. Please take a look:
https://wiki.openstack.org/wiki/Savanna/UIMockups/JobCreationProposal

Chad, it's just pictures demonstrate how we see dependencies in UI. It's
not a final decision.
Guys, feel free to comment this. I think it's time to start discussions.

Regards,
Nadya


On Mon, Sep 9, 2013 at 10:19 PM, Chad Roberts  wrote:

> Updated UI mockups for savanna dashboard EDP.
> https://wiki.openstack.org/wiki/Savanna/UIMockups/JobCreation
>
> Regards,
> Chad
>
> ___
> 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] Program name and Mission statement

[Ilya Elterman]

+1 for OpenStack Data Processing and

Mission: To provide the OpenStack community with an open, cutting edge,
> performant and scalable data processing stack and associated management
> interfaces.



On Tue, Sep 10, 2013 at 6:47 AM, Matthew Farrellee  wrote:

> Rough cut -
>
> Program: OpenStack Data Processing
> Mission: To provide the OpenStack community with an open, cutting edge,
> performant and scalable data processing stack and associated management
> interfaces.
>
>
> On 09/10/2013 09:26 AM, Sergey Lukjanov wrote:
>
>> It sounds too broad IMO. Looks like we need to define Mission Statement
>> first.
>>
>> Sincerely yours,
>> Sergey Lukjanov
>> Savanna Technical Lead
>> Mirantis Inc.
>>
>> On Sep 10, 2013, at 17:09, Alexander Kuznetsov > > wrote:
>>
>>  My suggestion OpenStack Data Processing.
>>>
>>>
>>> On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov
>>> mailto:slukja...@mirantis.com**>> wrote:
>>>
>>> Hi folks,
>>>
>>> due to the Incubator Application we should prepare Program name
>>> and Mission statement for Savanna, so, I want to start mailing
>>> thread about it.
>>>
>>> Please, provide any ideas here.
>>>
>>> P.S. List of existing programs:
>>> 
>>> https://wiki.openstack.org/**wiki/Programs
>>> P.P.S. 
>>> https://wiki.openstack.org/**wiki/Governance/NewPrograms
>>>
>>> Sincerely yours,
>>> Sergey Lukjanov
>>> Savanna Technical Lead
>>> Mirantis Inc.
>>>
>>>
>>> __**_
>>> 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
>>
>>
>
> __**_
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.**org 
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>



-- 
Ilya Elterman
Senior Director,
Cloud Services,
Mirantis
http://www.mirantis.com
tel. +1 650 963 9828
mob. +1 650 561 5779
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] summit.openstack.org track label for TripleO -> Deployment

[Thierry Carrez]

Clint Byrum wrote:
> My point is this: The summit isn't just about us sitting around pushing
> our vision.  We need to be open to the OpenStack Deployment tool chain
> supporting other deployment models. So while I'm not sure calling it
> "Deployment" will have a positive effect, I am also not sure that calling
> it "TripleO" is the right answer either. Thoughts?

Robert followed up privately and a few hours ago we renamed the topic to
"TripleO (Deployment)".

Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] Conductor API has no attribute "xxxxxx"

[Peeyush Gupta]

Hi Dan,

Yeah, I figured that out. I was already using objects, but
I didn't add the interface to the conductor.rpcapi. It's working
fine now.

Thanks.
 
~Peeyush Gupta



 From: Dan Smith 
To: Peeyush Gupta ; OpenStack Development Mailing List 
 
Sent: Tuesday, 10 September 2013 5:29 PM
Subject: Re: [openstack-dev] Conductor API has no attribute "xx"
 

> I have been trying to add a new table to the database.

Just FYI, new database interfaces should be added using objects, which
are automatically remotable. New conductor interfaces should not be
added to make database queries.

> #In class LocalAPI
> def xx(self, context, node_id, values):
>         return self._manager.xx(context, node_id, values)
> 

Is this on top of master?

Adding to api -> rpcapi -> manager should do the trick. It would be
helpful to know what you're trying to build this on top of, as well as
a little more detail about what you've added.

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

Re: [openstack-dev] OpenStack + PyPy: Status and goals

[Thierry Carrez]

Alex Gaynor wrote:
> Many of you have probably seen me send review requests in the last few weeks
> about adding PyPy support to various OpenStack projects. A few people were
> confused by these, so I wanted to fill everyone in on what I'm up to :)
> 
> First, for those who aren't familiar with what PyPy is: PyPy is an
> implementation of the Python language which includes a high performance
> tracing
> just-in-time compiler and which is faster than CPython (the reference,
> and most
> widely deployed, implementation) on almost all workloads.
> 
> The current status is:
> [...]

Thanks Alex for the detailed status !

If you're present at the Hong-Kong design summit, I'd definitely like to
have a Pypy support status/plans session (which could be merged with a
Python 3 one). It could be filed under the "release management" topic if
nothing better fits.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [TripleO] summit.openstack.org track label for TripleO -> Deployment

[Clint Byrum]

Excerpts from Thierry Carrez's message of 2013-09-10 00:56:29 -0700:
> Robert Collins wrote:
> > Thierry, is it possible to change this to 'Deployment' rather than
> > TripleO in the summit tool? I think it would avoid folk interested in
> > Tuskar failing to find a place to submit their proposals, and as a
> > program we are multi-project - Tomas and I have just discussed this in
> > the tripleo meeting slot and think it would be a good idea.
> 
> Note that only official programs get time to the Design Summit,
> unofficial projects have to go to the unconference. That said, nothing
> prevents you from having one session from the TripleO track explore the
> possibilities of (and relationship with) Tuskar. You decide the content :)
> 
> We could even rename the track "Deployment" (which is your program name)
> but I fear that such a generic name would trigger dozens of off-topic
> suggestions: non-design discussions or having nothing to do with your
> program. Those would generate a lot of disappointment when you end up
> having to refuse them all...

I have to agree that the current TripleO set of work won't get discussed
as much if we open it up to all deployment. But to exclude all of the
other ideas about deployment from our discussions seems the wrong way
to go about growing this part of OpenStack.

One of the principles we've held most high in TripleO since I joined
the project has been to decouple everything that can be decoupled. So
while we are driving at a particular realistic deployment, we are not
excluding alternate courses. Diskimage-builder originally only worked on
Ubuntu, but we decoupled that, and now it has Fedora and RHEL. We are
currently working on accepting changes to allow qpid instead of rabbit
as well.  While we are working at an image update based solution using
the os-*-config tools, we would gladly welcome changes to enable a more
traditional approach to deployment using the other tools.

My point is this: The summit isn't just about us sitting around pushing
our vision.  We need to be open to the OpenStack Deployment tool chain
supporting other deployment models. So while I'm not sure calling it
"Deployment" will have a positive effect, I am also not sure that calling
it "TripleO" is the right answer either. Thoughts?

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

Re: [openstack-dev] OpenStack + PyPy: Status and goals

[Dolph Mathews]

On Mon, Sep 9, 2013 at 4:28 PM, Alex Gaynor  wrote:

> Hi all,
>
> Many of you have probably seen me send review requests in the last few
> weeks
> about adding PyPy support to various OpenStack projects. A few people were
> confused by these, so I wanted to fill everyone in on what I'm up to :)
>
> First, for those who aren't familiar with what PyPy is: PyPy is an
> implementation of the Python language which includes a high performance
> tracing
> just-in-time compiler and which is faster than CPython (the reference, and
> most
> widely deployed, implementation) on almost all workloads.
>
> The current status is:
>
> Two major projects work, both Marconi and Swift, Marconi is gating against
> PyPy
> already, Swift isn't yet since I needed to fix a few small PyPy bugs and
> those
> aren't in a release yet, expect it soon :)
>
> In terms of results, I've observed 30% performance improvements on GET
> workloads for Swift under PyPy vs. CPython (other workloads haven't been
> benchmarked tet). I believe the Marconi folks have also observed some
> performance wins, but I'll let them speak to that, I don't have the full
> details.
>

I'd definitely be curious as to keystone & python-keystoneclient's status,
in terms of potential performance gains or blockers.


>
> Many python-clients projects are also working out of the box and gating:
> including novaclient, swiftclient, marconiclient, ceilometerclient,
> heatclient,
> and ironicclient!
>
> There's a few outstanding reviews to add PyPy gating for cinderclient,
> troveclient, and glanceclient.
>
> In terms of future direction:
>
> I'm going to continue to work on getting more projects running and gating
> against PyPy.
>
> Right now I'm focusing a lot of my attention on improving Swift
> performance,
> particularly under PyPy, but also under CPython.
>
> I'm hoping some day PyPy will be the default way to deploy OpenStack!
>
>
> If you're interested in getting your project running on PyPy, or looking at
> performance under it, please let me know, I'm always interested in helping!
>
> Thanks,
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

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

Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

[Robert Kukura]

On 09/10/2013 10:45 AM, Mark McClain wrote:
> I think Gary and Kyle have answered this very well; however I do have a few 
> things to add.  It is definitely too late for Havana, so Icehouse is next 
> available release for new plugins.  I can work with you offline to find you a 
> core sponsor.

One more thing: Rather than implementing and maintaining an entire new
plugin, consider whether it might make sense to integrate as an ml2
MechanismDriver instead. The ml2 plugin's MechanismDrivers can
interface with network devices or controllers, and can work in
conjunction with the existing L2 agents if needed. See
https://wiki.openstack.org/wiki/Neutron/ML2 for more info.

-Bob

> 
> mark
>  
> On Sep 10, 2013, at 9:37 AM, "Kyle Mestery (kmestery)"  
> wrote:
> 
>> On Sep 10, 2013, at 4:05 AM, P Balaji-B37839  wrote:
>>>
>>> Hi,
>>>
>>> We have gone through the below link for new plug-in development.
>>>
>>> https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neutron_Plugin
>>>
>>> Just want to confirm that is it mandatory to be Core Neutron Developer for 
>>> submitting a new plug-in.?
>>>
>> It's not necessary for you to have a core developer from your company, but 
>> you will need an existing core developer to support your plugin upstream. 
>> When you file the blueprint, let us know and we'll work with you on this one 
>> Balaji.
>>
>> Thanks,
>> Kyle
>>
>>> How do we get a reviewer for this like Can we approach any Core Neutron 
>>> developer for review our plugin?
>>>
>>> We are developing new plug-in for our product and want to make it upstream 
>>> to Neutron Core.
>>>
>>> Any information on this will be helpful!.
>>>
>>> Regards,
>>> Balaji.P
>>
>>
> 
> 
> ___
> 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] Gate breakage for multi-process API patch.

[Baldwin, Carl (HPCS Neutron)]

Looking further in to this.  The bug you mentioned appears to have been
marked as a duplicate of a bug that was resolved about a month ago.  I
added the recheck comment to the gerrit review and Jenkins did not do
anything with it overnight.  I assume it noticed that the bug was marked
as resolved.

Further testing in devstack with this patch has gone well.  The patch
seems stable.  This patch is important for scaling the API servers as
Peter Feiner has pointed out a few times.  Can we get some eyes on this
Jenkins failure as I have yet to find anything to explain it.

Carl

From:  , Carl Baldwin 
Date:  Monday, September 9, 2013 6:05 PM
To:  OpenStack Development Mailing List 
Subject:  Re: [openstack-dev] [Neutron] Gate breakage for multi-process
API patch.


Thank you for that information.  I see that rechecks page referenced from
the wiki now that you have mentioned it.  I have learned something.

Carl

Sent from my HTC

- Reply message -
From: "Davanum Srinivas" 
To: "OpenStack Development Mailing List"

Subject: [openstack-dev] [Neutron] Gate breakage for multi-process API
patch.
Date: Mon, Sep 9, 2013 5:49 PM


Carl, 

if you check the "rechecks" page - http://status.openstack.org/rechecks/
you will see 18 other reviews hitting the same bug reported at
https://bugs.launchpad.net/tempest/+bug/1197476.

So, in your review for https://review.openstack.org/#/c/37131/, add a
comment "recheck bug 1197476" which will basically re-run the jenkins
tests and update the rechecks page with your review number.

See here for more info -
https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures

-- dims




On Mon, Sep 9, 2013 at 6:40 PM, Baldwin, Carl (HPCS Neutron)
 wrote:

Hi all,

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

This review has been consistently marked as fail for the last three patch
sets.  I'm scratching my head over how the failure is related to the
patch.  Can anyone lend some insight?  Is this a known failure that is not
caused by my patch or is this failure actually due to my patch?

The test breaking is "test_008_check_public_network_connectivity."  I have
run the patch with the new api_workers config option set to 0, 1, 2, and 5
and I've been able to create instances that have full network connectivity
to my public network in each case.

Thanks,
Carl


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






-- 
Davanum Srinivas :: http://davanum.wordpress.com


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

Re: [openstack-dev] OpenStack + PyPy: Status and goals

[Dolph Mathews]

On Tue, Sep 10, 2013 at 11:01 AM, Thierry Carrez wrote:

> Alex Gaynor wrote:
> > Many of you have probably seen me send review requests in the last few
> weeks
> > about adding PyPy support to various OpenStack projects. A few people
> were
> > confused by these, so I wanted to fill everyone in on what I'm up to :)
> >
> > First, for those who aren't familiar with what PyPy is: PyPy is an
> > implementation of the Python language which includes a high performance
> > tracing
> > just-in-time compiler and which is faster than CPython (the reference,
> > and most
> > widely deployed, implementation) on almost all workloads.
> >
> > The current status is:
> > [...]
>
> Thanks Alex for the detailed status !
>
> If you're present at the Hong-Kong design summit, I'd definitely like to
> have a Pypy support status/plans session (which could be merged with a
> Python 3 one). It could be filed under the "release management" topic if
> nothing better fits.
>

++ I would attend


>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

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

Re: [openstack-dev] [Savanna] Guidance for adding a new plugin (CDH)

[Andrei Savu]

Thanks Matt!

You can check the list of supported operating systems at:
http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM4Ent/latest/Cloudera-Manager-Installation-Guide/cmig_cm_requirements.html

Cheers,

-- Andrei

On Tue, Sep 10, 2013 at 2:55 PM, Matthew Farrellee  wrote:

> On 09/06/2013 03:00 PM, Andrei Savu wrote:
>
>>
>> On Fri, Sep 6, 2013 at 3:00 PM, Matthew Farrellee > > wrote:
>>
>> Once done, what will the procedure be for me to verify it without
>> becoming a Cloudera customer? What will the limitations be to its
>> use, if any, if I'm not a Cloudera customer?
>>
>>
>> Cloudera Standard is free and includes CDH and a version of Cloudera
>> Manager that has all the features we need to make this plugin useful
>> (except some advanced management features and support). For those
>> advanced features an enterprise license will be required but I think
>> that's out of scope now.
>>
>> To answer your question: you don't have to be a Cloudera customer to use
>> this plugin - everything should just work out of the box - you will only
>> need OpenStack and a compatible vanilla OS image.
>>
>> [1]
>> http://www.cloudera.com/**content/cloudera/en/products/**
>> cloudera-standard.html
>>
>> -- Andrei Savu / axemblr.com 
>>
>
> Great. If you start to need any of the non-free features, send a heads up
> so we can discuss.
>
> As for the compatible vanilla OS image, is that any image from -
>
> http://cloud.fedoraproject.org
>  or
> http://cloud-images.ubuntu.**com/ 
>  or
> http://docs.openstack.org/**trunk/openstack-image/content/**
> centos-image.html
>
> With no diskimage-builder (savanna-image-elements) customization?
>
>
> Best,
>
>
> matt
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

[Mark McClain]

I think Gary and Kyle have answered this very well; however I do have a few 
things to add.  It is definitely too late for Havana, so Icehouse is next 
available release for new plugins.  I can work with you offline to find you a 
core sponsor.

mark
 
On Sep 10, 2013, at 9:37 AM, "Kyle Mestery (kmestery)"  
wrote:

> On Sep 10, 2013, at 4:05 AM, P Balaji-B37839  wrote:
>> 
>> Hi,
>> 
>> We have gone through the below link for new plug-in development.
>> 
>> https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neutron_Plugin
>> 
>> Just want to confirm that is it mandatory to be Core Neutron Developer for 
>> submitting a new plug-in.?
>> 
> It's not necessary for you to have a core developer from your company, but 
> you will need an existing core developer to support your plugin upstream. 
> When you file the blueprint, let us know and we'll work with you on this one 
> Balaji.
> 
> Thanks,
> Kyle
> 
>> How do we get a reviewer for this like Can we approach any Core Neutron 
>> developer for review our plugin?
>> 
>> We are developing new plug-in for our product and want to make it upstream 
>> to Neutron Core.
>> 
>> Any information on this will be helpful!.
>> 
>> Regards,
>> Balaji.P
> 
> 


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

Re: [openstack-dev] OpenStack + PyPy: Status and goals

[Alex Gaynor]

Hi Roman,

Yes eventlet works well on PyPy, both Marconi and Swift use it.

Alex


On Mon, Sep 9, 2013 at 10:15 PM, Roman Podolyaka wrote:

> Hi Alex,
>
> That's really cool! I believe, performance is not the only benefit we can
> get from running OpenStack projects on PyPy. We  can also improve the
> overall "correctness" of our code (as PyPy behaves differently with
> non-closed files, etc), just like compiling of your C/C++ app using
> different compilers can show hidden errors.
>
> And what about eventlet? Does it work well on PyPy? (as it is used in
> Nova, Neutron, etc)
>
> Thanks,
> Roman
>
>
> On Tue, Sep 10, 2013 at 12:28 AM, Alex Gaynor wrote:
>
>> Hi all,
>>
>> Many of you have probably seen me send review requests in the last few
>> weeks
>> about adding PyPy support to various OpenStack projects. A few people were
>> confused by these, so I wanted to fill everyone in on what I'm up to :)
>>
>> First, for those who aren't familiar with what PyPy is: PyPy is an
>> implementation of the Python language which includes a high performance
>> tracing
>> just-in-time compiler and which is faster than CPython (the reference,
>> and most
>> widely deployed, implementation) on almost all workloads.
>>
>> The current status is:
>>
>> Two major projects work, both Marconi and Swift, Marconi is gating
>> against PyPy
>> already, Swift isn't yet since I needed to fix a few small PyPy bugs and
>> those
>> aren't in a release yet, expect it soon :)
>>
>> In terms of results, I've observed 30% performance improvements on GET
>> workloads for Swift under PyPy vs. CPython (other workloads haven't been
>> benchmarked tet). I believe the Marconi folks have also observed some
>> performance wins, but I'll let them speak to that, I don't have the full
>> details.
>>
>> Many python-clients projects are also working out of the box and gating:
>> including novaclient, swiftclient, marconiclient, ceilometerclient,
>> heatclient,
>> and ironicclient!
>>
>> There's a few outstanding reviews to add PyPy gating for cinderclient,
>> troveclient, and glanceclient.
>>
>> In terms of future direction:
>>
>> I'm going to continue to work on getting more projects running and gating
>> against PyPy.
>>
>> Right now I'm focusing a lot of my attention on improving Swift
>> performance,
>> particularly under PyPy, but also under CPython.
>>
>> I'm hoping some day PyPy will be the default way to deploy OpenStack!
>>
>>
>> If you're interested in getting your project running on PyPy, or looking
>> at
>> performance under it, please let me know, I'm always interested in
>> helping!
>>
>> Thanks,
>> Alex
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right
>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: 125F 5C67 DFE9 4084
>>
>> ___
>> 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
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [savanna] Program name and Mission statement

[Mike Spreitzer]

A quick dictionary lookup of "data processing" yields the following.  I 
wonder if you mean something more specific.

data processing |ˈˌdædə ˈprɑsɛsɪŋ|
noun
a series of operations on data, esp. by a computer, to retrieve, 
transform, or classify information.



From:   Matthew Farrellee 
To: OpenStack Development Mailing List 
, 
Date:   09/10/2013 09:53 AM
Subject:Re: [openstack-dev] [savanna] Program name and Mission 
statement



Rough cut -

Program: OpenStack Data Processing
Mission: To provide the OpenStack community with an open, cutting edge, 
performant and scalable data processing stack and associated management 
interfaces.

On 09/10/2013 09:26 AM, Sergey Lukjanov wrote:
> It sounds too broad IMO. Looks like we need to define Mission Statement
> first.
>
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
>
> On Sep 10, 2013, at 17:09, Alexander Kuznetsov  > wrote:
>
>> My suggestion OpenStack Data Processing.
>>
>>
>> On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov
>> mailto:slukja...@mirantis.com>> wrote:
>>
>> Hi folks,
>>
>> due to the Incubator Application we should prepare Program name
>> and Mission statement for Savanna, so, I want to start mailing
>> thread about it.
>>
>> Please, provide any ideas here.
>>
>> P.S. List of existing programs:
>> https://wiki.openstack.org/wiki/Programs
>> P.P.S. https://wiki.openstack.org/wiki/Governance/NewPrograms
>>
>> Sincerely yours,
>> Sergey Lukjanov
>> Savanna Technical Lead
>> Mirantis Inc.
>>
>>
>> ___
>> 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
>


___
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] [Heat] Meeting agenda for Wed Sept 11th at 2000 UTC

[Steven Hardy]

The Heat team holds a weekly meeting in #openstack-meeting, see

https://wiki.openstack.org/wiki/Meetings/HeatAgenda for more details

The next meeting is on Wed Sept 11th at 2000 UTC

Current topics for discussion:
* Review last week's actions
* RC1 bugs
* Summit design session proposals : http://summit.openstack.org/
* Open discussion

If anyone has any other topic to discuss, please add to the wiki.

Thanks!

Steve

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

Re: [openstack-dev] [savanna] Program name and Mission statement

[Matthew Farrellee]

Rough cut -

Program: OpenStack Data Processing
Mission: To provide the OpenStack community with an open, cutting edge, 
performant and scalable data processing stack and associated management 
interfaces.


On 09/10/2013 09:26 AM, Sergey Lukjanov wrote:

It sounds too broad IMO. Looks like we need to define Mission Statement
first.

Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.

On Sep 10, 2013, at 17:09, Alexander Kuznetsov mailto:akuznet...@mirantis.com>> wrote:


My suggestion OpenStack Data Processing.


On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov
mailto:slukja...@mirantis.com>> wrote:

Hi folks,

due to the Incubator Application we should prepare Program name
and Mission statement for Savanna, so, I want to start mailing
thread about it.

Please, provide any ideas here.

P.S. List of existing programs:
https://wiki.openstack.org/wiki/Programs
P.P.S. https://wiki.openstack.org/wiki/Governance/NewPrograms

Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.


___
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




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

Re: [openstack-dev] [nova] FFE Request: read-only-volumes feature

[Russell Bryant]

On 09/10/2013 03:15 AM, lzy@gmail.com wrote:
> Hello,
> 
> The feature BP at
> https://blueprints.launchpad.net/cinder/+spec/read-only-volumes. The
> Cinder server side change (https://review.openstack.org/#/c/38322/)
> was done and merged, but since there was a delay of a few weeks on the
> Cinder side while team debated between some design options, and I
> couldn't submit Nova side patchs until the corresponding Cinder patch
> was merged. So the follow Nova side changes need to request FFE, I
> need those changes to make the feature workable fully:
> 
> https://review.openstack.org/#/c/44455/
> https://review.openstack.org/#/c/44817/(depends on cinderclient
> change https://review.openstack.org/#/c/44672/ )
> https://review.openstack.org/#/c/45171/

Is there a nova blueprint for this?  I can't find one.

This wasn't on my radar at all.  I think the Nova parts should wait for
Icehouse.

-- 
Russell Bryant

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

[openstack-dev] Proposal to deprecate LDAP Assignments

[Adam Young]

Assignments (user to project, group to project, user to domain, group to 
domain) are OpenStack specific Data, where as Identity (users, groups, 
and user to group assignments) is general organizational data.  When all 
of this was in a single backend, we had no choice but to force people to 
use LDAP in a writeable mode, and put their assignments in there.


Assignments and LDAP were always a bad match.

With the split of the identity backend, we can now manage identity in a 
backend separate from assignments. There is an identity backend, and an 
assignments backend.  For Havana, if the user has configured the 
identity backend to use LDAP, and have not specified anything for 
assignments, assignments will be in LDAP as well
We can't drop support for LDAP assignments without breaking the 
deployments for all these people.  I'd like to propose deprecating the 
LDAP backend for assignments as soon as feasible, with an eye to helping 
people migrate their existing assignments to the SQL backend.


What might a migration look like:

1.  lock down the LDAP backend so that no updates can occur to Projects, 
ROles, or Role assignments
2.  For projects, roles, and role assignments, do an LDAP query and 
generate a single row in the SQL backend.  These don't need to be 
identical to the existing ones, but it is not required that the IDs be 
UUIDs:  they will be treated as blobs and keeping the old values is fine 
if desired.
3.  Change the config file so that the Assignments backend is SQL, not 
LDAP, and restart Keystone.


We should deprecate the LDAP Assignments backend when Icehouse is GA, to 
be removed two releases later. We know we have some rough spots to 
smooth over in the Havana and Icehouse timeframe regarding the LDAP/SQL  
approach.  I'd like to warn people that this is coming, so that we have 
some participation in discussions around this migration, and that, by 
the time we finally remove the last of the support for LDAP assignments, 
it will be nothing but a fading memory.





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

Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

[Kyle Mestery (kmestery)]

On Sep 10, 2013, at 4:05 AM, P Balaji-B37839  wrote:
> 
> Hi,
>  
> We have gone through the below link for new plug-in development.
>  
> https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neutron_Plugin
>  
> Just want to confirm that is it mandatory to be Core Neutron Developer for 
> submitting a new plug-in.?
>  
It's not necessary for you to have a core developer from your company, but you 
will need an existing core developer to support your plugin upstream. When you 
file the blueprint, let us know and we'll work with you on this one Balaji.

Thanks,
Kyle

> How do we get a reviewer for this like Can we approach any Core Neutron 
> developer for review our plugin?
>  
> We are developing new plug-in for our product and want to make it upstream to 
> Neutron Core.
>  
> Any information on this will be helpful!.
>  
> Regards,
> Balaji.P



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

Re: [openstack-dev] [savanna] Program name and Mission statement

[Sergey Lukjanov]

It sounds too broad IMO. Looks like we need to define Mission Statement first.

Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.

On Sep 10, 2013, at 17:09, Alexander Kuznetsov  wrote:

> My suggestion OpenStack Data Processing. 
> 
> 
> On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov  
> wrote:
> Hi folks,
> 
> due to the Incubator Application we should prepare Program name and Mission 
> statement for Savanna, so, I want to start mailing thread about it.
> 
> Please, provide any ideas here.
> 
> P.S. List of existing programs: https://wiki.openstack.org/wiki/Programs
> P.P.S. https://wiki.openstack.org/wiki/Governance/NewPrograms
> 
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
> 
> 
> ___
> 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] [savanna] Program name and Mission statement

[Alexander Kuznetsov]

My suggestion OpenStack Data Processing.


On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov wrote:

> Hi folks,
>
> due to the Incubator Application we should prepare Program name and
> Mission statement for Savanna, so, I want to start mailing thread about it.
>
> Please, provide any ideas here.
>
> P.S. List of existing programs: https://wiki.openstack.org/wiki/Programs
> P.P.S. https://wiki.openstack.org/wiki/Governance/NewPrograms
>
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
>
>
> ___
> 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] [Horizon] django_openstack_auth

[Julie Pichon]

Hi Daisy,

"Ying Chun Guo"  wrote:
> I noticed Horizon has dependency to the binary code of
> django_openstack_auth.
> When I want to enable I18n of Horizon, I also need to enable the I18n of
> django_openstack_auth ?
> The po files of django_openstack_auth were out of date. (only a small
> change)
> 
> Do I need to add the translation resource of django_openstack_auth to
> Transifex?
> After our translators finish the translation, what else need we do?

django_openstack_auth contains the strings for the login page. Updating the 
strings should work the same way as it currently does for Horizon (manually), 
except with the different repository name. It would be great to also have them 
in Transifex.

https://git.openstack.org/cgit/openstack/django_openstack_auth/tree/openstack_auth/locale/en/LC_MESSAGES/django.po

The login page is displayed in the language that the browser is set to, so the 
browser language preferences may need to be adjusted depending on the language 
the translators want to test (e.g. in Firefox it's in Preferences -> Content -> 
Languages).

Regards,

Julie

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

[openstack-dev] [savanna] Program name and Mission statement

[Sergey Lukjanov]

Hi folks,

due to the Incubator Application we should prepare Program name and Mission 
statement for Savanna, so, I want to start mailing thread about it. 

Please, provide any ideas here.

P.S. List of existing programs: https://wiki.openstack.org/wiki/Programs
P.P.S. https://wiki.openstack.org/wiki/Governance/NewPrograms

Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.


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

Re: [openstack-dev] Conductor API has no attribute "xxxxxx"

[Dan Smith]

> I have been trying to add a new table to the database.

Just FYI, new database interfaces should be added using objects, which
are automatically remotable. New conductor interfaces should not be
added to make database queries.

> #In class LocalAPI
> def xx(self, context, node_id, values):
>         return self._manager.xx(context, node_id, values)
> 

Is this on top of master?

Adding to api -> rpcapi -> manager should do the trick. It would be
helpful to know what you're trying to build this on top of, as well as
a little more detail about what you've added.

--Dan

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

Re: [openstack-dev] [Savanna] Guidance for adding a new plugin (CDH)

[Matthew Farrellee]

On 09/06/2013 03:00 PM, Andrei Savu wrote:


On Fri, Sep 6, 2013 at 3:00 PM, Matthew Farrellee mailto:m...@redhat.com>> wrote:

Once done, what will the procedure be for me to verify it without
becoming a Cloudera customer? What will the limitations be to its
use, if any, if I'm not a Cloudera customer?


Cloudera Standard is free and includes CDH and a version of Cloudera
Manager that has all the features we need to make this plugin useful
(except some advanced management features and support). For those
advanced features an enterprise license will be required but I think
that's out of scope now.

To answer your question: you don't have to be a Cloudera customer to use
this plugin - everything should just work out of the box - you will only
need OpenStack and a compatible vanilla OS image.

[1]
http://www.cloudera.com/content/cloudera/en/products/cloudera-standard.html

-- Andrei Savu / axemblr.com 


Great. If you start to need any of the non-free features, send a heads 
up so we can discuss.


As for the compatible vanilla OS image, is that any image from -

http://cloud.fedoraproject.org
 or
http://cloud-images.ubuntu.com/
 or
http://docs.openstack.org/trunk/openstack-image/content/centos-image.html

With no diskimage-builder (savanna-image-elements) customization?


Best,


matt

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

[openstack-dev] reg. Multihost dhcp feature in Havana ?

[Gopi Krishna B]

Hi
Was looking at the below link and checking if the feature to support
Multihost networking is part of Havana.

https://blueprints.launchpad.net/neutron/+spec/quantum-multihost

I couldnot find out the feature in the Havana blue print. Could you let me
know details reg. the feature ?

https://blueprints.launchpad.net/neutron/havana/+specs?show=all

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

Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

[P Balaji-B37839]

Thanks Gary.

We will target for IceHouse version.

Regards,
Balaji.P

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, September 10, 2013 2:46 PM
To: OpenStack Development Mailing List; Mark McClain; Thierry Carrez; Kyle 
Mestery (kmestery)
Subject: Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

Hi,
Anyone can submit a new plugin :). The proposed code will go through the 
regular review process.
It is best to open a blueprint for the proposed plugin 
(https://launchpad.net/neutron). At the moment we are in a feature freeze for 
the H cycle. So the chances of it getting in now are pretty slim (you are 
welcome to ask for e feature freeze exception but it is very late int he game). 
I suggest that you target for the Icehouse version.
Thanks
Gary

From: P Balaji-B37839 mailto:b37...@freescale.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, September 10, 2013 12:05 PM
To: Mark McClain 
mailto:mark.mccl...@dreamhost.com>>, Thierry Carrez 
mailto:thie...@openstack.org>>, "Kyle Mestery 
(kmestery)" mailto:kmest...@cisco.com>>
Cc: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron] New Plug-in development for Neutron

Hi,

We have gone through the below link for new plug-in development.

https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neutron_Plugin

Just want to confirm that is it mandatory to be Core Neutron Developer for 
submitting a new plug-in.?

How do we get a reviewer for this like Can we approach any Core Neutron 
developer for review our plugin?

We are developing new plug-in for our product and want to make it upstream to 
Neutron Core.

Any information on this will be helpful!.

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

[openstack-dev] [Horizon] django_openstack_auth

[Ying Chun Guo]

Hi,

I noticed Horizon has dependency to the binary code of
django_openstack_auth.
When I want to enable I18n of Horizon, I also need to enable the I18n of
django_openstack_auth ?
The po files of django_openstack_auth were out of date. (only a small
change)

Do I need to add the translation resource of django_openstack_auth to
Transifex?
After our translators finish the translation, what else need we do?

Regards
Ying Chun Guo (Daisy)___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Conductor API has no attribute "xxxxxx"

[Peeyush Gupta]

Hi all,


I have been trying to add a new table to the database. Now, I have created 
the table and I am going through conductor API to populate/update it. I have 
defined some function to achieve the task. There function are defined in 
conductor 
and db api, along with in conductor.manage and db.sqlalchemy.api. When I try 
to run the system it says 

 AttributeError: 'ConductorAPI' object has no attribute 'xx'

while the function is properly defined in Conductor API as well as manager and 
db.API. I back traced the flow of the code and it looks like the code reaches 
till
conductor.api. The function at the conductor API is defined as:

#In class LocalAPI
def xx(self, context, node_id, values):
        return self._manager.xx(context, node_id, values)

Now, after this it gives the error. Though the function is present in 
conductor.manager.
Please help me find out why am I getting this error.

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

Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

[Gary Kotton]

Hi,
Anyone can submit a new plugin :). The proposed code will go through the 
regular review process.
It is best to open a blueprint for the proposed plugin 
(https://launchpad.net/neutron). At the moment we are in a feature freeze for 
the H cycle. So the chances of it getting in now are pretty slim (you are 
welcome to ask for e feature freeze exception but it is very late int he game). 
I suggest that you target for the Icehouse version.
Thanks
Gary

From: P Balaji-B37839 mailto:b37...@freescale.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, September 10, 2013 12:05 PM
To: Mark McClain 
mailto:mark.mccl...@dreamhost.com>>, Thierry Carrez 
mailto:thie...@openstack.org>>, "Kyle Mestery 
(kmestery)" mailto:kmest...@cisco.com>>
Cc: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron] New Plug-in development for Neutron

Hi,

We have gone through the below link for new plug-in development.

https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neutron_Plugin

Just want to confirm that is it mandatory to be Core Neutron Developer for 
submitting a new plug-in.?

How do we get a reviewer for this like Can we approach any Core Neutron 
developer for review our plugin?

We are developing new plug-in for our product and want to make it upstream to 
Neutron Core.

Any information on this will be helpful!.

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

[openstack-dev] [Neutron] New Plug-in development for Neutron

[P Balaji-B37839]

Hi,

We have gone through the below link for new plug-in development.

https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neutron_Plugin

Just want to confirm that is it mandatory to be Core Neutron Developer for 
submitting a new plug-in.?

How do we get a reviewer for this like Can we approach any Core Neutron 
developer for review our plugin?

We are developing new plug-in for our product and want to make it upstream to 
Neutron Core.

Any information on this will be helpful!.

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

[openstack-dev] Reminder: Project & release status meeting - 21:00 UTC

[Thierry Carrez]

Today in the project/release status meeting, we'll check status for
feature freeze exceptions and review havana-rc1 buglists.

Feel free to add extra topics to the agenda:
[1] http://wiki.openstack.org/Meetings/ProjectMeeting

All Technical Leads for integrated programs should be present (if you
can't make it, please name a substitute on [1]). Other program leads and
everyone else is very welcome to attend.

The meeting will be held at 21:00 UTC on the #openstack-meeting channel
on Freenode IRC. You can look up how this time translates locally at:
[2] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130910T21

See you there,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [glance] FFE Request: Add swift_store_ssl_compression param

[Thierry Carrez]

Mark Washenberger wrote:
> I buy an exception here if the configuration defaults to off (no change).

+1

Also don't forget to mention that new configuration option to the Docs
team to make sure they are aware of its late addition.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [TripleO] summit.openstack.org track label for TripleO -> Deployment

[Thierry Carrez]

Robert Collins wrote:
> Thierry, is it possible to change this to 'Deployment' rather than
> TripleO in the summit tool? I think it would avoid folk interested in
> Tuskar failing to find a place to submit their proposals, and as a
> program we are multi-project - Tomas and I have just discussed this in
> the tripleo meeting slot and think it would be a good idea.

Note that only official programs get time to the Design Summit,
unofficial projects have to go to the unconference. That said, nothing
prevents you from having one session from the TripleO track explore the
possibilities of (and relationship with) Tuskar. You decide the content :)

We could even rename the track "Deployment" (which is your program name)
but I fear that such a generic name would trigger dozens of off-topic
suggestions: non-design discussions or having nothing to do with your
program. Those would generate a lot of disappointment when you end up
having to refuse them all...

Maybe "Deployment (TripleO)" ?

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [nova] FFE Request: read-only-volumes feature

[lzy....@gmail.com]

Hello,

The feature BP at
https://blueprints.launchpad.net/cinder/+spec/read-only-volumes. The
Cinder server side change (https://review.openstack.org/#/c/38322/)
was done and merged, but since there was a delay of a few weeks on the
Cinder side while team debated between some design options, and I
couldn't submit Nova side patchs until the corresponding Cinder patch
was merged. So the follow Nova side changes need to request FFE, I
need those changes to make the feature workable fully:

https://review.openstack.org/#/c/44455/
https://review.openstack.org/#/c/44817/(depends on cinderclient
change https://review.openstack.org/#/c/44672/ )
https://review.openstack.org/#/c/45171/

thanks,
zhiyan

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

[openstack-dev] Scheduler sub-group meeting on 9/10

[Gary Kotton]

Hi,
Don is on vacation. Lets try and have the meeting today.
Topics that come to mind:

 1.  https://etherpad.openstack.org/IceHouse-Nova-Scheduler-Sessions
 2.  Scheduling BP's that missed H. Bad timing or do we need to discuss and see 
how we can improve the process
 3.  Open issues

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