date:20131210

On 12/11/2013 08:22 AM, Gary Kotton wrote:
> Hi,
> An example for this
> is: 
> http://logs.openstack.org/94/59994/10/check/gate-nova-docs/b0f3910/console.html
> Any ideas?
> Thanks
> Gary
> 
There is a thread about this:
http://lists.openstack.org/pipermail/openstack-dev/2013-December/021863.html

Best regards,
Matthias


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

[openstack-dev] [Ceilometer] RFC: blueprint monitoring-network

2013-12-10 Thread Yuuichi Fujioka

Hi, Ceilometer team.

We have posted 2 blueprints.[1][2]

This feature collects the network information(device, link status, statistics) 
via NorthBound API from SDN Controller.
The purpose of this feature is testing network route, resource optimization 
based on network proximity and etc.

In particular, the feature collects statistics and information about ports, 
flows and tables in switches.

We feel ceilometer shouldn't talk to switches directly.
If having made pollster that talks to switches directly via SouthBound API, 
pollsters would be created for each switch vendor.
It would make large maintenance cost.
In general, NorthBound API abstracts differences between hardwares. Thus this 
feature collects via NorthBound API.

We define some meters in this feature on the blueprints.
The meters are based on the OpenFlow Switch Specification.
But, We have no intention of limiting to OpenFlow Switch.
We guess OpenFlow Switch Specification covers general the network information.
If you know other necessary meters, please let me know.

Details are written in wiki.[3]

We hope feedback of you.

[1]https://blueprints.launchpad.net/ceilometer/+spec/monitoring-network
[2]https://blueprints.launchpad.net/ceilometer/+spec/monitoring-network-from-opendaylight
[3]https://wiki.openstack.org/wiki/Ceilometer/blueprints/monitoring-network

Thanks.

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

[openstack-dev] [Gating-Failures] Docs creation is failing

2013-12-10 Thread Gary Kotton

Hi,
An example for this is: 
http://logs.openstack.org/94/59994/10/check/gate-nova-docs/b0f3910/console.html
Any ideas?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Third party Neutron plugin testing meeting

2013-12-10 Thread Irena Berezovsky

Please take guys and girls from Israel into account ☺.


From: Yongsheng Gong [mailto:gong...@unitedstack.com]
Sent: Wednesday, December 11, 2013 5:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin testing 
meeting

UTC 22:00+, which is 6:am beijing time，but if there are guys from Israel alike, 
I can get up one hour earlier, just like what I do for neutron meeting.

On Wed, Dec 11, 2013 at 11:08 AM, Kyle Mestery 
mailto:mest...@siliconloons.com>> wrote:
I suspect we'll need another meeting next week, I propose we have it
at a time friendly to those in Asian timezones. Yong and Akihiro, can
you guys propose a timeslot which works for you guys and I'll see
about setting the followup meeting up.

Thanks,
Kyle

On Dec 10, 2013, at 8:14 PM, Yongsheng Gong 
mailto:gong...@unitedstack.com>> wrote:

> It is 1am beijing time, so I am afraid I will not join.
>
>
> On Wed, Dec 11, 2013 at 10:10 AM, Akihiro Motoki 
> mailto:amot...@gmail.com>> wrote:
> Thanks Kyle for coordinating the meeting.
>
> The time is midnight to me, but it fits everyone except me. I'll try the time 
> but not sure. Anyway I will follow the log.
>
> 2013年12月11日水曜日 Shiv Haris sha...@brocade.com:
>
> +1
>
>
>
> Will join via IRC or voice call
>
>
>
>
>
>
>
> From: Gary Duan [mailto:gd...@varmour.com]
> Sent: Tuesday, December 10, 2013 10:59 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin 
> testingmeeting
>
>
>
> I will be joining IRC too.
>
>
>
> Thanks,
>
> Gary
>
>
>
> On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana 
> mailto:emag...@plumgrid.com>> wrote:
>
> Also joining!
> Looking forward to hearing your ideas folks!
>
> Edgar
>
>
> On 12/10/13 10:16 AM, "Nachi Ueno" mailto:na...@ntti3.com>> 
> wrote:
>
> >+1 ! I'll join.
> >I'm also working on investigating how to use openstack gating system.
> >(This document is still draft version)
> >https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
> >efQalL5Q0/edit#slide=id.p
> >
> >2013/12/10 Ivar Lazzaro mailto:i...@embrane.com>>:
> >> +1 for 1700UTC Thursday on IRC
> >>
> >> -Original Message-
> >> From: Kyle Mestery 
> >> [mailto:mest...@siliconloons.com]
> >> Sent: Tuesday, December 10, 2013 9:21 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
> >>testing meeting
> >>
> >> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
> >>mailto:anthony_ve...@cable.comcast.com>> 
> >>wrote:
> >>> -Original Message-
> >>> From: Kyle Mestery 
> >>> mailto:mest...@siliconloons.com>>
> >>> Reply-To: "OpenStack Development Mailing List (not for usage
> >>>questions)"
> >>> mailto:openstack-dev@lists.openstack.org>>
> >>> Date: Tuesday, December 10, 2013 10:48
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> mailto:openstack-dev@lists.openstack.org>>
> >>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
> >>> meeting
> >>>
>  Last week I took an action item to organize a meeting for everyone
>  who is doing third-party testing in Neutron for plugins, whether this
>  is vendor or Open Source based. The idea is to share ideas around
>  setups and any issues people hit. I'd like to set this meeting up for
>  this week, Thursday at 1700UTC. I would also like to propose we make
>  this a dial in meeting using the Infrastructure Conferencing bridges
>  [1]. If this time works, I'll set something up and reply to this
>  thread with the dial in information.
> >>>
> >>> +1 for the meeting time.  Any particular reason for voice over IRC?
> >>>
> >> We kind of decided that doing this over voice initially would be
> >>expedient, but I am fine with moving to IRC. If I don't hear objections,
> >>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
> >>
> >>
> 
>  Also, I've started a etherpad page [2] with information. It would be
>  good for people to add information to this etherpad as well. I've
>  coupled this pad with information around multi-node gate testing for
>  Neutron as well, as I suspect most of the third-party testing will
>  require multiple nodes as well.
> >>>
> >>> I'll start filling out our setup.  I have some questions around
> >>> Third-Party Testing in particular, and look forward to this discussion.
> >>>
> >> Awesome, thanks Anthony!
> >>
> 
>  Thanks!
>  Kyle
> 
>  [1]
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing

Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

2013-12-10 Thread Irena Berezovsky

+1
Will join the IRC too

-Original Message-
From: Kyle Mestery [mailto:mest...@siliconloons.com] 
Sent: Tuesday, December 10, 2013 10:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

OK, looks like we've reached consensus. I've set the time and channel to 
12-12-2013 (Thursday), 1700UTC, on #openstack-meeting-alt.

Thanks!
Kyle

On Dec 10, 2013, at 12:59 PM, Gary Duan  wrote:

> I will be joining IRC too.
> 
> Thanks,
> Gary
> 
> 
> On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana  wrote:
> Also joining!
> Looking forward to hearing your ideas folks!
> 
> Edgar
> 
> On 12/10/13 10:16 AM, "Nachi Ueno"  wrote:
> 
> >+1 ! I'll join.
> >I'm also working on investigating how to use openstack gating system.
> >(This document is still draft version) 
> >https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BV
> >buk1e
> >efQalL5Q0/edit#slide=id.p
> >
> >2013/12/10 Ivar Lazzaro :
> >> +1 for 1700UTC Thursday on IRC
> >>
> >> -Original Message-
> >> From: Kyle Mestery [mailto:mest...@siliconloons.com]
> >> Sent: Tuesday, December 10, 2013 9:21 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin 
> >>testing meeting
> >>
> >> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
> >> wrote:
> >>> -Original Message-
> >>> From: Kyle Mestery 
> >>> Reply-To: "OpenStack Development Mailing List (not for usage 
> >>>questions)"
> >>> 
> >>> Date: Tuesday, December 10, 2013 10:48
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> 
> >>> Subject: [openstack-dev] [neutron] Third party Neutron plugin 
> >>>testing  meeting
> >>>
>  Last week I took an action item to organize a meeting for 
>  everyone who is doing third-party testing in Neutron for plugins, 
>  whether this is vendor or Open Source based. The idea is to share 
>  ideas around setups and any issues people hit. I'd like to set 
>  this meeting up for this week, Thursday at 1700UTC. I would also 
>  like to propose we make this a dial in meeting using the 
>  Infrastructure Conferencing bridges [1]. If this time works, I'll 
>  set something up and reply to this thread with the dial in information.
> >>>
> >>> +1 for the meeting time.  Any particular reason for voice over IRC?
> >>>
> >> We kind of decided that doing this over voice initially would be 
> >>expedient, but I am fine with moving to IRC. If I don't hear 
> >>objections, lets assume we will meet at 1700UTC Thursday on 
> >>#openstack-meeting-alt.
> >>
> >>
> 
>  Also, I've started a etherpad page [2] with information. It would 
>  be good for people to add information to this etherpad as well. 
>  I've coupled this pad with information around multi-node gate 
>  testing for Neutron as well, as I suspect most of the third-party 
>  testing will require multiple nodes as well.
> >>>
> >>> I'll start filling out our setup.  I have some questions around 
> >>> Third-Party Testing in particular, and look forward to this discussion.
> >>>
> >> Awesome, thanks Anthony!
> >>
> 
>  Thanks!
>  Kyle
> 
>  [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing
>  [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest
> 
>  ___
>  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 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] [Scheduler] about scheduler-as-a-service

2013-12-10 Thread Qiu Yu

On Tue, Dec 10, 2013 at 5:30 PM, Lingxian Kong  wrote:

> we know that there is a scheduler-as-a-service[1] working in progress now,
> aiming at smart resource placement and also providing the instance group
> API work for nova.
>
> But what I wonder is does it include the feature of DRS(Distributed
> Resource Scheduler, something like that), as it is in vCenter[2], or is
> there any project related to this? or some related bp?
>
> Any hints are appreciated. I apologize if this question was already
> covered and I missed it.
>
>
For the "smart" portion, maybe you should take a look at
https://blueprints.launchpad.net/nova/+spec/solver-scheduler

And for the DRS feature, I think it's more likely to be fit in nova
conductor's role. After all the migration task have been moved to
conductor, then some feature like DRS could be discussed as the next step.
https://blueprints.launchpad.net/nova/+spec/cold-migrations-to-conductor
https://blueprints.launchpad.net/nova/+spec/unified-migrations

[1]https://etherpad.openstack.org/p/icehouse-external-scheduler
> [2]https://www.vmware.com/cn/products/vsphere/features/drs-dpm.html
>
>
BTW, the second link you provided seems to be in Chinese. For those who
interested, please use this one instead.
http://www.vmware.com/pdf/vmware_drs_wp.pdf

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

[openstack-dev] [Solum] Git workgroup meeting 8AM PST Wednesday

2013-12-10 Thread Krishna Raman

Hello,

As a reminder, the next git workgroup meeting is tomorrow at 8 AM PST 
(http://www.worldtimebuddy.com/?qm=1&lid=8,524901,2158177,100&h=8&date=2013-12-11&sln=8-9)

Agenda:
* Topics:
* Monty to present idea/diagram about using Zuul for git 
workflow
* Q&A about Zuul
- Process of moving Zuul out to a normal OpenStack 
project. Volunteer?
- Is Zuul required for Solum or is it a 
pluggable/optional component?
- Other questions?
* Reserve topics:
* Discuss integration with lang-pack workflow
* General discussion

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

Re: [openstack-dev] {opestack][Neutron - FWaaS] CLI Firewall-Policy-Update Bug

2013-12-10 Thread trinath.soman...@freescale.com

Hi-

Thanks a lot for the reply.

Can you kindly also add the help guideline in the FWaaS Documentation too.. 
This might be helpful.

Thanking you.



--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048

From: Yongsheng Gong [mailto:gong...@unitedstack.com]
Sent: Wednesday, December 11, 2013 11:48 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] {opestack][Neutron - FWaaS] CLI 
Firewall-Policy-Update Bug

try to use:
 neutron firewall-policy-update dd2c7d33-2c36-4200-b1f8-daaa1ab202d5 
--firewall-rules list=true rule1

On Wed, Dec 11, 2013 at 1:37 PM, 
trinath.soman...@freescale.com 
mailto:trinath.soman...@freescale.com>> wrote:
Hi -

I found this issue with FWaaS CLI commands.

When I issue the command,

$> neutron firewall-policy-update dd2c7d33-2c36-4200-b1f8-daaa1ab202d5 
--firewall-rules "rule1"

404-{u'NeutronError': {u'message': u'Firewall Rule r could not be found.', 
u'type': u'FirewallRuleNotFound', u'detail': u''}}

With respect to the code, I see that the split is not happening based on the 
white space character rather, the string is being split or parsed.

Is there a bug assigned to this and is that resolved ?

Kindly help me in this regard.

--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 
4048


___
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] {opestack][Neutron - FWaaS] CLI Firewall-Policy-Update Bug

2013-12-10 Thread Yongsheng Gong

try to use:
 neutron firewall-policy-update dd2c7d33-2c36-4200-b1f8-daaa1ab202d5
--firewall-rules list=true rule1


On Wed, Dec 11, 2013 at 1:37 PM, trinath.soman...@freescale.com <
trinath.soman...@freescale.com> wrote:

>  Hi –
>
>
>
> I found this issue with FWaaS CLI commands.
>
>
>
> When I issue the command,
>
>
>
> $> neutron firewall-policy-update dd2c7d33-2c36-4200-b1f8-daaa1ab202d5
> --firewall-rules "rule1"
>
>
>
> 404-{u'NeutronError': {u'message': u'Firewall Rule r could not be found.',
> u'type': u'FirewallRuleNotFound', u'detail': u''}}
>
>
>
> With respect to the code, I see that the split is not happening based on
> the white space character rather, the string is being split or parsed.
>
>
>
> Is there a bug assigned to this and is that resolved ?
>
>
>
> Kindly help me in this regard.
>
>
>
> --
>
> Trinath Somanchi - B39208
>
> trinath.soman...@freescale.com | extn: 4048
>
>
>
> ___
> 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] {opestack][Neutron - FWaaS] CLI Firewall-Policy-Update Bug

2013-12-10 Thread trinath.soman...@freescale.com

Hi -

I found this issue with FWaaS CLI commands.

When I issue the command,

$> neutron firewall-policy-update dd2c7d33-2c36-4200-b1f8-daaa1ab202d5 
--firewall-rules "rule1"

404-{u'NeutronError': {u'message': u'Firewall Rule r could not be found.', 
u'type': u'FirewallRuleNotFound', u'detail': u''}}

With respect to the code, I see that the split is not happening based on the 
white space character rather, the string is being split or parsed.

Is there a bug assigned to this and is that resolved ?

Kindly help me in this regard.

--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048

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

Re: [openstack-dev] [Solum] Plan files and resources

2013-12-10 Thread Adrian Otto

Devdatta,

On Dec 10, 2013, at 12:37 PM, devdatta kulkarni 
 wrote:

> Hi Adrian,
> 
> Thanks for creating https://etherpad.openstack.org/p/solum-demystified
> 
> I am really excited to see the examples. Especially cool is how
> examples 2 and 3 demonstrate using a component ("solum_glance_id") created
> as part of example 1.
> 
> 
> Some questions/comments:
> 
> 1) Summarizing the sequence of events just to make sure I understand them 
> correctly: 
>   a) User selects a language pack and specifies its id in the plan file

They could put the language pack reference into a Plan file, or we could 
generate a Plan file with a CLI command that feeds an auto-generated file to 
the API for the user. That might reduce the user complexity a bit for the 
general case.

>   b) User creates repo with the plan file in it.

We could scan the repo for a Plan file to override the auto-generation step, to 
allow a method for customization.

>   After this the flow could be:
>   c.1) User uses solum cli to 'create' an application by giving reference to 
>  the repo uri

I view this as the use of the cli "app create" command as the first step. They 
can optionally specify a Plan file to use for either the build sequence, or the 
app deployment sequence, or both (for a total of TWO Plan files). We could also 
allow plan files to be placed in the Git repo, and picked up there in the event 
that none are specified on the command line.

Note that they may also put a HOT file in their repo, and bypass HOT file 
generation/catalog-lookup and cause Solum to use the supplied template. This 
would be useful for power users who want the ability to further influence the 
arrangement of the Heat stack.

>   c.1.1) Solum creates a plan resource
>   c.1.2) Solum model interpreter creates a Heat stack and does the rest 
> of the
>things needed to create a assembly. 
>   (The created plan resource does not play any part in assembly creation 
> as such.
>Its only role is being a 'trackback' to track the plan from which the 
> assembly was created.)

It's also a way to find out what services the given requirements were mapped 
to. In a Plan file, the services array contains ServiceSpecfications (see the 
EX[1-3] YAML examples under the "services" node for an example of what those 
look like. In a Plan resource, the services array includes a list of service 
resources so you can see what Solum's model interpreter mapped your 
requirements to.

>   or, 
>   c.2) User uses solum cli to 'create/register' a plan by providing reference 
> to the repo uri. 
>c.2.1) Solum creates the plan resource.
>   c.2) User uses solum cli to 'create' an application by specifying the 
> created plan
>resource uri
>(In this flow, the plan is actively used).

Yes, this would be another option. I expect that this approach may be used by 
users who want to create multitudes of Assemblies from a given Plan resource. 

> 2) Addition of new solum specific attributes in a plan specification is 
> interesting.
>   I imagine those can be contributed back as "Solum" profile to CAMP spec?

If we want, that input would certainly be welcomed.

> 3) Model interpreter for generating Heat stack from a plan is a nice idea.
>   For all: Are there any recommended libraries for this?

Good question. There are a number of orchestration systems that we could look 
at as case studies. Anything that has a declarative DSL is likely to have 
implementations that are relevant to our need for a model interpreter. This 
includes Heat.

> 4) Just to confirm, I assume that the api-spec-review etherpad 
> (https://etherpad.openstack.org/p/solum-api-spec-review), 
>   is for fyi purpose only. If someone wants to know what is the current 
> thinking about API, they should
>   just look at the solum-demystified etherpad 
> (https://etherpad.openstack.org/p/solum-demystified)

I just updated the solum-api-spec-review, as that's actually still WIP. I 
labeled it as such.

Thanks,

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

Re: [openstack-dev] [openstack-qa] [qa][nova] The document for the changes from Nova v2 api to v3

2013-12-10 Thread Alex Xu

yeah, that's good idea. That can keep the doc update with code. I will 
try to convert the wiki to rst format, then submit to gerrit.


On 2013?12?07? 00:12, Anne Gentle wrote:

Hi all,
Now that you've got a decent start, how about checking it in as a 
doc/source/ document in the nova repository? Seems better than keeping 
it in the wiki so that you can update with code changes.

Anne


On Wed, Nov 13, 2013 at 11:11 PM, Alex Xu > wrote:


On 2013?11?14? 07:09, Christopher Yeoh wrote:

On Thu, Nov 14, 2013 at 7:52 AM, David Kranz mailto:dkr...@redhat.com>> wrote:

On 11/13/2013 08:30 AM, Alex Xu wrote:

Hi, guys

This is the document for the changes from Nova v2 api to v3:
https://wiki.openstack.org/wiki/NovaAPIv2tov3
I will appreciate if anyone can help for review it.

Another problem comes up - how to keep the doc updated. So
can we ask people, who change
something of api v3, update the doc accordingly? I think
it's a way to resolve it.

Thanks
Alex



___
openstack-qa mailing list
openstack...@lists.openstack.org  

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

Thanks, this is great. I fixed a bug in the os-services
section. BTW, openstack...@lists.openstack.org
 list is obsolete.
openstack-dev with subject starting with [qa] is the current
"qa list". About updating, I think this will have to be
heavily socialized in the nova team. The initial review
should happen by those reviewing the tempest v3 api changes.
That is how I found the os-services bug.


Can we leverage off the DocImpact flag with the commit message
somehow - say anytime there is a changeset
with DocImpact and that changes a file under
nova/api/openstack/compute we generate a notification?

I think we're getting much better at enforcing the DocImpact flag
during reviews.

+1 for DocImpact flag, that's good idea.


Chris.


___
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] [keystone] domain admin role query

2013-12-10 Thread Jamie Lennox

Using the default policies it will simply check for the admin role and not care 
about the domain that admin is limited to. This is partially a left over from 
the V2 api when there wasn't domains to worry about.

A better example of policies are in the file etc/policy.v3cloudsample.json. In 
there you will see the rule for create_project is: 

"identity:create_project": "rule:admin_required and 
domain_id:%(project.domain_id)s",

as opposed to (in policy.json): 

"identity:create_project": "rule:admin_required",

This is what you are looking for to scope the admin role to a domain. 


Jamie

- Original Message -
> From: "Ravi Chunduru" 
> To: "OpenStack Development Mailing List" 
> Sent: Wednesday, 11 December, 2013 11:23:15 AM
> Subject: [openstack-dev] [keystone] domain admin role query
> 
> Hi,
> I am trying out Keystone V3 APIs and domains.
> I created an domain, created a project in that domain, created an user in
> that domain and project.
> Next, gave an admin role for that user in that domain.
> 
> I am assuming that user is now admin to that domain.
> Now, I got a scoped token with that user, domain and project. With that
> token, I tried to create a new project in that domain. It worked.
> 
> But, using the same token, I could also create a new project in a 'default'
> domain too. I expected it should throw authentication error. Is it a bug?
> 
> Thanks,
> --
> Ravi
> 
> ___
> 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] DHCP Agent Reliability

2013-12-10 Thread Maru Newby


On Dec 11, 2013, at 8:39 AM, Isaku Yamahata  wrote:

> On Wed, Dec 11, 2013 at 01:23:36AM +0900,
> Maru Newby  wrote:
> 
>> 
>> On Dec 10, 2013, at 6:36 PM, Isaku Yamahata  wrote:
>> 
>>> On Mon, Dec 09, 2013 at 08:43:59AM +1300,
>>> Robert Collins  wrote:
>>> 
>> listening: when an agent connects after an outage, it first starts
>> listening, then does a poll for updates it missed.
> 
> Are you suggesting that processing of notifications and full state 
> synchronization are able to cooperate safely?  Or hoping that it will be 
> so in the future?
 
 I'm saying that you can avoid race conditions by a combination of
 'subscribe to changes' + 'give me the full state'.
>>> 
>>> Like this?
>>> https://review.openstack.org/#/c/61057/
>>> This patch is just to confirm the idea.
>> 
>> I'm afraid the proposed patch is no more reliable than the current approach 
>> of using file-based locking.   I am working on an alternate patch that puts 
>> the rpc event loop in the dhcp agent so that better coordination between 
>> full synchronization and notification handling is possible.  This approach 
>> has already been taken with the L3 agent and work on the L2 agent is in 
>> process.  
> 
> You objected against agent polling in the discussion.
> But you're now proposing polling now. Did you change your mind?

Uh, no.  I'm proposing better coordination between notification processing and 
full state synchronization beyond simple exclusionary primitives  
(utils.synchronize etc).  I apologize if my language was unclear.  


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

Re: [openstack-dev] [Neutron] ML2 improvement, more extensible and more modular

2013-12-10 Thread Robert Kukura

On 12/04/2013 05:37 AM, Zang MingJie wrote:
> Hi, all:
> 
> I have already written a patch[1] which makes ml2 segment more
> extensible, where segments can contains more fields other than physical
> network and segmentation id, but there is still a lot of work to do to
> make the ml2 more extensible. Here are some of my thoughts.

Hi Zang,

Thanks for putting this together - hopefully we can cover this at
tomorrow's ML2 meeting.

> 
> First, introduce a new extension to abandon provider extension.

Doesn't the existing multiprovidernet extension already serve this
purpose? If not, I'd like to understand why a different extension is
needed, or how the multiprovidernet extension API needs to change.

Whether/how/when we abandon the old provider extension seems separable
from whether the multiprovidernet extension is sufficient or needs
replacement/modification. Assuming we do merge your patch, my current
thinking is that we should declare the provider extension deprecated for
ML2 in icehouse, but maintain the ability to use the provider extension
when there is only a single segment and the segment's type can be fully
described with the old provider attributes. We could then remove the
provider extension from ML2 in the J release.

> Currently the provider extension only support physical network and
> segmentation id, as a result the net-create and net-show calls can't
> handle any extra fields. Because we already have multi-segment support,
> we may need an extension which extends the network with only one field,
> segments; json can be used to describe segments when accessing the API
> (net-create/show). 

The multiprovidernet extension already does add a "segments" attribute
to network. This attribute is a list of dictionaries, one per segment,
with no constraints on the keys used in the dictionaries. My
understanding of the main objective of your current patch (which I
apologize that I still haven't completed reviewing) is that it allows
type drivers to use arbitrary keys in these dictionaries. Is that correct?

>  But there comes a new problem, type drivers must
> check the access policy of fields inside segment very carefully, there
> is nowhere to ensure the access permission other than the type driver.

I'm not sure what you mean by "access policy" here. Is this read-only
vs. read/write? Clearly if type drivers can define arbitrary keys, only
they can check access or validate supplied values. Are you suggesting
adding some mechanism to let the API framework know about each type
driver's keys and handle this for them?

> multiprovidernet extension is a good start point, but some modification
> still required.

I'm still not entirely clear on what modifications to the
multiprovidernet API you feel are required.

> 
> Second, add segment calls to mechanism driver. There is an one-to-many
> relation between network and segments, but it is not clear and hide
> inside multi-segment implementation, it should be more clear and more
> extensible, so people can use it wisely. I want to add some new APIs to
> mechanism manager which handles segment relate operations, eg,
> segment_create/segment_release, and separate segment operations from
> network.

Maybe this is the extension API modification you were referring to above
(or maybe not). When I first proposed ML2 and then wrote the blueprint
for multi-segment networks in ML2, I envisioned segments as being
exposed in the API as a new type of REST resource, possibly a
sub-resource of network. But we ended up going with the much simpler
multiprovidernet approach that Aaron Rosen came up with for the NVP
plugin instead.

Regardless of whether we stick with the existing multiprovidernet
extension or switch to an API with segment as a 1st class resource, I
think your idea of adding explicit operations to MechanismManager (and
MechanismDriver I presume) that are called when adding and removing
segments is worth considering. The original thinking was that
MechanismDrivers would see these changes via the network_update
operations. An alternative might be to simply add a
previous_network_segments attribute to NetworkContext so a
MechanismDriver can easily compare it with network_segments in
network_update calls to see what's changed. But your approach may be
more clear and easier to use.

> 
> Last, as our l2 agent (ovs-agent) only handles l2 segments operations,
> and do nothing with networks or subnets, I wonder if we can remove all
> network related code inside agent implementation, and only handle
> segments, change lvm map from {network_id->segment/ports} to
> {segment_id->segment/ports}. The goal is to make the ovs-agent pure l2
> agent.

I like this idea as well. It might be more realistic to consider after
the monolithic openvswitch and linuxbridge plugins are removed from the
tree in the J cycle, and we only need to worry about keeping the agents
compatible with the ML2 plugin. Or maybe it could be done in icehouse
and compatibility maintai

Re: [openstack-dev] [neutron] Third party Neutron plugin testing meeting

2013-12-10 Thread Yongsheng Gong

UTC 22:00+, which is 6:am beijing time，but if there are guys from Israel
alike, I can get up one hour earlier, just like what I do for neutron
meeting.


On Wed, Dec 11, 2013 at 11:08 AM, Kyle Mestery wrote:

> I suspect we'll need another meeting next week, I propose we have it
> at a time friendly to those in Asian timezones. Yong and Akihiro, can
> you guys propose a timeslot which works for you guys and I'll see
> about setting the followup meeting up.
>
> Thanks,
> Kyle
>
> On Dec 10, 2013, at 8:14 PM, Yongsheng Gong 
> wrote:
>
> > It is 1am beijing time, so I am afraid I will not join.
> >
> >
> > On Wed, Dec 11, 2013 at 10:10 AM, Akihiro Motoki 
> wrote:
> > Thanks Kyle for coordinating the meeting.
> >
> > The time is midnight to me, but it fits everyone except me. I'll try the
> time but not sure. Anyway I will follow the log.
> >
> > 2013年12月11日水曜日 Shiv Haris sha...@brocade.com:
> >
> > +1
> >
> >
> >
> > Will join via IRC or voice call
> >
> >
> >
> >
> >
> >
> >
> > From: Gary Duan [mailto:gd...@varmour.com]
> > Sent: Tuesday, December 10, 2013 10:59 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
> testingmeeting
> >
> >
> >
> > I will be joining IRC too.
> >
> >
> >
> > Thanks,
> >
> > Gary
> >
> >
> >
> > On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana 
> wrote:
> >
> > Also joining!
> > Looking forward to hearing your ideas folks!
> >
> > Edgar
> >
> >
> > On 12/10/13 10:16 AM, "Nachi Ueno"  wrote:
> >
> > >+1 ! I'll join.
> > >I'm also working on investigating how to use openstack gating system.
> > >(This document is still draft version)
> > >
> https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
> > >efQalL5Q0/edit#slide=id.p
> > >
> > >2013/12/10 Ivar Lazzaro :
> > >> +1 for 1700UTC Thursday on IRC
> > >>
> > >> -Original Message-
> > >> From: Kyle Mestery [mailto:mest...@siliconloons.com]
> > >> Sent: Tuesday, December 10, 2013 9:21 AM
> > >> To: OpenStack Development Mailing List (not for usage questions)
> > >> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
> > >>testing meeting
> > >>
> > >> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
> > >> wrote:
> > >>> -Original Message-
> > >>> From: Kyle Mestery 
> > >>> Reply-To: "OpenStack Development Mailing List (not for usage
> > >>>questions)"
> > >>> 
> > >>> Date: Tuesday, December 10, 2013 10:48
> > >>> To: "OpenStack Development Mailing List (not for usage questions)"
> > >>> 
> > >>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
> > >>> meeting
> > >>>
> >  Last week I took an action item to organize a meeting for everyone
> >  who is doing third-party testing in Neutron for plugins, whether
> this
> >  is vendor or Open Source based. The idea is to share ideas around
> >  setups and any issues people hit. I'd like to set this meeting up
> for
> >  this week, Thursday at 1700UTC. I would also like to propose we make
> >  this a dial in meeting using the Infrastructure Conferencing bridges
> >  [1]. If this time works, I'll set something up and reply to this
> >  thread with the dial in information.
> > >>>
> > >>> +1 for the meeting time.  Any particular reason for voice over IRC?
> > >>>
> > >> We kind of decided that doing this over voice initially would be
> > >>expedient, but I am fine with moving to IRC. If I don't hear
> objections,
> > >>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
> > >>
> > >>
> > 
> >  Also, I've started a etherpad page [2] with information. It would be
> >  good for people to add information to this etherpad as well. I've
> >  coupled this pad with information around multi-node gate testing for
> >  Neutron as well, as I suspect most of the third-party testing will
> >  require multiple nodes as well.
> > >>>
> > >>> I'll start filling out our setup.  I have some questions around
> > >>> Third-Party Testing in particular, and look forward to this
> discussion.
> > >>>
> > >> Awesome, thanks Anthony!
> > >>
> > 
> >  Thanks!
> >  Kyle
> > 
> >  [1]
> >
> >
> > ___
> > 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] [neutron] Third party Neutron plugin testing meeting

2013-12-10 Thread Kyle Mestery

I suspect we'll need another meeting next week, I propose we have it
at a time friendly to those in Asian timezones. Yong and Akihiro, can
you guys propose a timeslot which works for you guys and I'll see
about setting the followup meeting up.

Thanks,
Kyle

On Dec 10, 2013, at 8:14 PM, Yongsheng Gong  wrote:

> It is 1am beijing time, so I am afraid I will not join.
> 
> 
> On Wed, Dec 11, 2013 at 10:10 AM, Akihiro Motoki  wrote:
> Thanks Kyle for coordinating the meeting.
> 
> The time is midnight to me, but it fits everyone except me. I'll try the time 
> but not sure. Anyway I will follow the log.
> 
> 2013年12月11日水曜日 Shiv Haris sha...@brocade.com:
> 
> +1
> 
>  
> 
> Will join via IRC or voice call
> 
>  
> 
>  
> 
>  
> 
> From: Gary Duan [mailto:gd...@varmour.com] 
> Sent: Tuesday, December 10, 2013 10:59 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin 
> testingmeeting
> 
>  
> 
> I will be joining IRC too.
> 
>  
> 
> Thanks,
> 
> Gary
> 
>  
> 
> On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana  wrote:
> 
> Also joining!
> Looking forward to hearing your ideas folks!
> 
> Edgar
> 
> 
> On 12/10/13 10:16 AM, "Nachi Ueno"  wrote:
> 
> >+1 ! I'll join.
> >I'm also working on investigating how to use openstack gating system.
> >(This document is still draft version)
> >https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
> >efQalL5Q0/edit#slide=id.p
> >
> >2013/12/10 Ivar Lazzaro :
> >> +1 for 1700UTC Thursday on IRC
> >>
> >> -Original Message-
> >> From: Kyle Mestery [mailto:mest...@siliconloons.com]
> >> Sent: Tuesday, December 10, 2013 9:21 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
> >>testing meeting
> >>
> >> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
> >> wrote:
> >>> -Original Message-
> >>> From: Kyle Mestery 
> >>> Reply-To: "OpenStack Development Mailing List (not for usage
> >>>questions)"
> >>> 
> >>> Date: Tuesday, December 10, 2013 10:48
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> 
> >>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
> >>> meeting
> >>>
>  Last week I took an action item to organize a meeting for everyone
>  who is doing third-party testing in Neutron for plugins, whether this
>  is vendor or Open Source based. The idea is to share ideas around
>  setups and any issues people hit. I'd like to set this meeting up for
>  this week, Thursday at 1700UTC. I would also like to propose we make
>  this a dial in meeting using the Infrastructure Conferencing bridges
>  [1]. If this time works, I'll set something up and reply to this
>  thread with the dial in information.
> >>>
> >>> +1 for the meeting time.  Any particular reason for voice over IRC?
> >>>
> >> We kind of decided that doing this over voice initially would be
> >>expedient, but I am fine with moving to IRC. If I don't hear objections,
> >>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
> >>
> >>
> 
>  Also, I've started a etherpad page [2] with information. It would be
>  good for people to add information to this etherpad as well. I've
>  coupled this pad with information around multi-node gate testing for
>  Neutron as well, as I suspect most of the third-party testing will
>  require multiple nodes as well.
> >>>
> >>> I'll start filling out our setup.  I have some questions around
> >>> Third-Party Testing in particular, and look forward to this discussion.
> >>>
> >> Awesome, thanks Anthony!
> >>
> 
>  Thanks!
>  Kyle
> 
>  [1]
> 
> 
> ___
> 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] ml2 and vxlan configurations, neutron-server fails to start

2013-12-10 Thread Robert Kukura

On 11/28/2013 07:01 AM, Gopi Krishna B wrote:
> 
> Hi
> I am configuring Havana on fedora 19. Observing the below errors in case
> of neutron. 
> Please help me resolve this issue.
>  copied only few lines from the server.log, in case full log is
> required, let me know.

You may have resolved this by now, or given up, but a few comments (in
addition to the sqlalchemy version issues others have addressed).

> 
> /etc/neutron/plugins/ml2/ml2_conf.ini
> type_drivers = vxlan,local
> tenant_network_types = vxlan
> mechanism_drivers = neutron.plugins.ml2.drivers.OpenvswitchMechanismDriver

The type_drivers and mechanism_drivers lists are entry point names
rather than class names, so the above line should be:

mechanism_drivers = openvswitch

> network_vlan_ranges = physnet1:1000:2999

You don't need to set the above unless you've enabled the vlan type
driver, but it won't hurt anything. If used, it needs to be in the
[ml2_type_vlan] section.

> vni_ranges = 5000:6000
> vxlan_group = 239.10.10.1

The two lines above need to be in the [ml2_type_vxlan] section.

-Bob

> 
> 
> ERROR neutron.common.legacy [-] Skipping unknown group key: firewall_driver
> 
> ERROR stevedore.extension [-] Could not load 'local': (SQLAlchemy 0.8.3
> (/usr/lib64/python2.7/site-packages),
> Requirement.parse('SQLAlchemy>=0.7.8,<=0.7.99'))
>  ERROR stevedore.extension [-] (SQLAlchemy 0.8.3
> (/usr/lib64/python2.7/site-packages),
> Requirement.parse('SQLAlchemy>=0.7.8,<=0.7.99'))
> 
> ERROR stevedore.extension [-] Could not load 'vxlan': (SQLAlchemy 0.8.3
> (/usr/lib64/python2.7/site-packages),
> Requirement.parse('SQLAlchemy>=0.7.8,<=0.7.99'))
> ERROR stevedore.extension [-] (SQLAlchemy 0.8.3
> (/usr/lib64/python2.7/site-packages),
> Requirement.parse('SQLAlchemy>=0.7.8,<=0.7.99'))
> TRACE stevedore.extension VersionConflict: (SQLAlchemy 0.8.3
> (/usr/lib64/python2.7/site-packages),
> Requirement.parse('SQLAlchemy>=0.7.8,<=0.7.99'))
> 
> ERROR neutron.common.config [-] Unable to load neutron from
> configuration file /etc/neutron/api-paste.ini.
> TRACE neutron.common.config LookupError: No section 'quantum' (prefixed
> by 'app' or 'application' or 'composite' or 'composit' or 'pipeline' or
> 'filter-app') found in config /etc/neutron/api-paste.ini
> 
> 
>  ERROR neutron.service [-] In serve_wsgi()
> TRACE neutron.service RuntimeError: Unable to load quantum from
> configuration file /etc/neutron/api-paste.ini.
> 
> Regards
> Gopi Krishna
> 
> 
> 
> 
> 
> 
> ___
> 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] Sphinx 1.2 incompatibility (failing -docs jobs)




On 12/10/2013 6:32 PM, Angus Salkeld wrote:

On 10/12/13 14:57 -0800, James E. Blair wrote:

Hi,

Sphinx 1.2 was just released and it is incompatible with distutils in
python 2.7.  See these links for more info:

 
https://bitbucket.org/birkenfeld/sphinx/pull-request/193/builddoc-shouldnt-fail-on-unicode-paths/diff

 http://bugs.python.org/issue19570


Is there a bug number that we can reference in recheck/reverifies?


The bug is 1259511.





This has caused all -docs jobs to fail.  This morning we merged a change
to openstack/requirements to pin Sphinx to version 1.2:

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

Sergey Lukjanov, Clark Boylan, and Jeremy Stanley finished up the
automatic requirements proposal job (Thanks!), and so now updates have
been automatically proposed to all projects that subscribe:

 https://review.openstack.org/#/q/topic:openstack/requirements,n,z

Once those changes merge, -docs jobs for affected projects should start
working again.

Note that requirements updates for stable branches are proceeding
separately; you can track their progress here:

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


-Jim

___
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



--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [neutron] Third party Neutron plugin testing meeting

2013-12-10 Thread Yongsheng Gong

It is 1am beijing time, so I am afraid I will not join.


On Wed, Dec 11, 2013 at 10:10 AM, Akihiro Motoki  wrote:

> Thanks Kyle for coordinating the meeting.
>
> The time is midnight to me, but it fits everyone except me. I'll try the
> time but not sure. Anyway I will follow the log.
>
> 2013年12月11日水曜日 Shiv Haris sha...@brocade.com:
>
> +1
>>
>>
>>
>> Will join via IRC or voice call
>>
>>
>>
>>
>>
>>
>>
>> *From:* Gary Duan [mailto:gd...@varmour.com]
>> *Sent:* Tuesday, December 10, 2013 10:59 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [neutron] Third party Neutron plugin
>> testingmeeting
>>
>>
>>
>> I will be joining IRC too.
>>
>>
>>
>> Thanks,
>>
>> Gary
>>
>>
>>
>> On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana 
>> wrote:
>>
>> Also joining!
>> Looking forward to hearing your ideas folks!
>>
>> Edgar
>>
>>
>> On 12/10/13 10:16 AM, "Nachi Ueno"  wrote:
>>
>> >+1 ! I'll join.
>> >I'm also working on investigating how to use openstack gating system.
>> >(This document is still draft version)
>> >
>> https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
>> >efQalL5Q0/edit#slide=id.p
>> >
>> >2013/12/10 Ivar Lazzaro :
>> >> +1 for 1700UTC Thursday on IRC
>> >>
>> >> -Original Message-
>> >> From: Kyle Mestery [mailto:mest...@siliconloons.com]
>> >> Sent: Tuesday, December 10, 2013 9:21 AM
>> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
>> >>testing meeting
>> >>
>> >> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
>> >> wrote:
>> >>> -Original Message-
>> >>> From: Kyle Mestery 
>> >>> Reply-To: "OpenStack Development Mailing List (not for usage
>> >>>questions)"
>> >>> 
>> >>> Date: Tuesday, December 10, 2013 10:48
>> >>> To: "OpenStack Development Mailing List (not for usage questions)"
>> >>> 
>> >>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
>> >>> meeting
>> >>>
>>  Last week I took an action item to organize a meeting for everyone
>>  who is doing third-party testing in Neutron for plugins, whether this
>>  is vendor or Open Source based. The idea is to share ideas around
>>  setups and any issues people hit. I'd like to set this meeting up for
>>  this week, Thursday at 1700UTC. I would also like to propose we make
>>  this a dial in meeting using the Infrastructure Conferencing bridges
>>  [1]. If this time works, I'll set something up and reply to this
>>  thread with the dial in information.
>> >>>
>> >>> +1 for the meeting time.  Any particular reason for voice over IRC?
>> >>>
>> >> We kind of decided that doing this over voice initially would be
>> >>expedient, but I am fine with moving to IRC. If I don't hear objections,
>> >>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
>> >>
>> >>
>> 
>>  Also, I've started a etherpad page [2] with information. It would be
>>  good for people to add information to this etherpad as well. I've
>>  coupled this pad with information around multi-node gate testing for
>>  Neutron as well, as I suspect most of the third-party testing will
>>  require multiple nodes as well.
>> >>>
>> >>> I'll start filling out our setup.  I have some questions around
>> >>> Third-Party Testing in particular, and look forward to this
>> discussion.
>> >>>
>> >> Awesome, thanks Anthony!
>> >>
>> 
>>  Thanks!
>>  Kyle
>> 
>>  [1] 
>>
>
> ___
> 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] Third party Neutron plugin testing meeting

2013-12-10 Thread Akihiro Motoki

Thanks Kyle for coordinating the meeting.

The time is midnight to me, but it fits everyone except me. I'll try the
time but not sure. Anyway I will follow the log.

2013年12月11日水曜日 Shiv Haris sha...@brocade.com:

> +1
>
>
>
> Will join via IRC or voice call
>
>
>
>
>
>
>
> *From:* Gary Duan [mailto:gd...@varmour.com  'gd...@varmour.com');>]
> *Sent:* Tuesday, December 10, 2013 10:59 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron] Third party Neutron plugin
> testingmeeting
>
>
>
> I will be joining IRC too.
>
>
>
> Thanks,
>
> Gary
>
>
>
> On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana 
> wrote:
>
> Also joining!
> Looking forward to hearing your ideas folks!
>
> Edgar
>
>
> On 12/10/13 10:16 AM, "Nachi Ueno"  wrote:
>
> >+1 ! I'll join.
> >I'm also working on investigating how to use openstack gating system.
> >(This document is still draft version)
> >
> https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
> >efQalL5Q0/edit#slide=id.p
> >
> >2013/12/10 Ivar Lazzaro :
> >> +1 for 1700UTC Thursday on IRC
> >>
> >> -Original Message-
> >> From: Kyle Mestery [mailto:mest...@siliconloons.com]
> >> Sent: Tuesday, December 10, 2013 9:21 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
> >>testing meeting
> >>
> >> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
> >> wrote:
> >>> -Original Message-
> >>> From: Kyle Mestery 
> >>> Reply-To: "OpenStack Development Mailing List (not for usage
> >>>questions)"
> >>> 
> >>> Date: Tuesday, December 10, 2013 10:48
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> 
> >>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
> >>> meeting
> >>>
>  Last week I took an action item to organize a meeting for everyone
>  who is doing third-party testing in Neutron for plugins, whether this
>  is vendor or Open Source based. The idea is to share ideas around
>  setups and any issues people hit. I'd like to set this meeting up for
>  this week, Thursday at 1700UTC. I would also like to propose we make
>  this a dial in meeting using the Infrastructure Conferencing bridges
>  [1]. If this time works, I'll set something up and reply to this
>  thread with the dial in information.
> >>>
> >>> +1 for the meeting time.  Any particular reason for voice over IRC?
> >>>
> >> We kind of decided that doing this over voice initially would be
> >>expedient, but I am fine with moving to IRC. If I don't hear objections,
> >>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
> >>
> >>
> 
>  Also, I've started a etherpad page [2] with information. It would be
>  good for people to add information to this etherpad as well. I've
>  coupled this pad with information around multi-node gate testing for
>  Neutron as well, as I suspect most of the third-party testing will
>  require multiple nodes as well.
> >>>
> >>> I'll start filling out our setup.  I have some questions around
> >>> Third-Party Testing in particular, and look forward to this discussion.
> >>>
> >> Awesome, thanks Anthony!
> >>
> 
>  Thanks!
>  Kyle
> 
>  [1] 
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Fwd: [OpenStack-dev] How to modify a bug across multiple repo?

2013-12-10 Thread wu jiang

Hi Chris & Rob,


Thanks for your reply ,and sorry for my late response..

- I tested again. The modification won't effect tempest test because it's
an optional argument, so I can commit it later in tempest. Lucky.

- But the bug in Cinder exists at the API layer, so the modification will
effect the CinderClient behavior..  :(

So, that's quite a complex problem.. Any ideas?


wingwj




On Fri, Dec 6, 2013 at 5:41 PM, Lingxian Kong  wrote:

>
>
> -- Forwarded message --
> From: Christopher Yeoh 
> Date: 2013/12/3
> Subject: Re: [openstack-dev] [OpenStack-dev] How to modify a bug across
> multiple repo?
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
>
>
> Hi,
>
> On Tue, Dec 3, 2013 at 7:21 PM, Robert Collins 
> wrote:
>
>> No, you need to manually arrange to land your changes in first one
>> repo then the other.
>>
>> -Rob
>>
>>
>> On 3 December 2013 19:17, wu jiang  wrote:
>> > Hi all,
>> >
>> > Recently, I found a bug at API layer in Cinder, but the modifications
>> relate
>> > to CinderClient & Tempest.
>> > So, I'm confused how to commit it. Can 'git --dependence' cross
>> different
>> > Repo?
>>
>
>
> Just to expand on what Rob mentioned - for situations like this its pretty
> common
> not to be able to just say make a change in cinder first because the
> tempest test will
> fail. And at the same time you can't make the final change in tempest
> first because the
> cinder change hasn't applied yet. If this is your situation what I'd
> suggest you do is:
>
> - Submit the cinder change, it will fail tempest, that's ok, you might
> want to leave a comment
> saying you are waiting on a tempest change to land first.
>
> - Submit a tempest change which disables the tempest tests which fail
> because of your change
> and in the commit message reference the gerrit url for the cinder change.
> Its very helpful, but not
> always necessary if you can get a cinder core to +1 this patch so the
> tempest cores know that the
> cinder team is happy with what is going on.
>
> - Once the tempest change has merged, the cinder change should be able to
> merge.
>
> - Submit a tempest change enabling the disabled test(s) and modifying it
> for the expected behaviour.
>
> Yes, it would be nice to be able to have cross project dependent patches :)
>
> Chris
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> *---*
> *Lingxian Kong*
> Huawei Technologies Co.,LTD.
> IT Product Line CloudOS PDU
> China, Xi'an
> Mobile: +86-18602962792
> Email: konglingx...@huawei.com; anlin.k...@gmail.com
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][qa] How will ironic tests run in tempest?

2013-12-10 Thread Devananda van der Veen

 Tue, Dec 10, 2013 at 12:43 PM, David Kranz  wrote:

>  On 12/09/2013 01:37 PM, Devananda van der Veen wrote:
>
>  On Fri, Dec 6, 2013 at 2:13 PM, Clark Boylan wrote:
>
>>  On Fri, Dec 6, 2013 at 1:53 PM, David Kranz  wrote:
>> > It's great that tempest tests for ironic have been submitted! I was
>> > reviewing https://review.openstack.org/#/c/48109/ and noticed that the
>> tests
>> > do not actually run. They are skipped because baremetal is not enabled.
>> This
>> > is not terribly surprising but we have had a policy in tempest to only
>> merge
>> > code that has demonstrated that it works. For services that cannot run
>> in
>> > the single-vm environment of the upstream gate we said there could be a
>> > system running somewhere that would run them and report a result to
>> gerrit.
>> > Is there a plan for this, or to make an exception for ironic?
>> >
>> >  -David
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>  There is a change[0] to openstack-infra/config to add experimental
>> tempest jobs to test ironic. I think that change is close to being
>> ready, but I need to give it time for a proper review. Once in that
>> will allow you to test 48109 (in theory, not sure if all the bits will
>> just work). I don't think these tests fall under the cannot run in a
>> single vm environment umbrella, we should be able to test the
>> baremetal code via the pxe booting of VMs within the single VM
>> environment.
>>
>> [0] https://review.openstack.org/#/c/53917/
>>
>>
>> Clark
>>
>>
>  We can test the ironic services, database, and the driver interfaces by
> using our "fake" driver within a single devstack VM today (I'm not sure the
> exercises for all of this have been written yet, but it's practical to test
> it). OTOH, I don't believe we can test a PXE deploy within a single VM
> today, and need to resume discussions with infra about this.
>
>  There are some other aspects of Ironic (IPMI, SOL access, any
> vendor-specific drivers) which we'll need real hardware to test because
> they can't effectively be virtualized. TripleO should cover some (much?) of
> those needs, once they are able to switch to using Ironic instead of
> nova-baremetal.
>
>  -Devananda
>
> So it seems that the code in the submitted tempest tests can run in a
> regular job if devstack is configured to enable ironic, but that this
> cannot be the default. So I propose that we create a regular
> devstack+ironic job that will run in the ironic and tempest gates, and run
> just the ironic tests. When third-party bare-metal results can be reported
> for ironic, tempest can then accept tests that require bare-metal.  Does
> any one have a problem with this approach?
>
>  -David
>
>
As I understand it, the infra/config patch which Clark already linked (
https://review.openstack.org/#/c/53917), which has gone through several
iterations, should be enabling Ironic within devstack -- and thus causing
tempest to run the relevant tests -- within the Ironic and Tempest check
and gate pipelines. This will exercise Ironic's API by performing CRUD
actions on resources. It doesn't do any more than that yet.

David, I'm not sure what you mean by "when third-party bare-metal results
can be reported for ironic" -- I don't see any reason why we couldn't
accept third-party smoke tests right now, except that none of the tempest
tests are written... Am I missing something?

In the longer term, we are planning to enable tempest testing of deployment
by ironic within devstack-gate as all the pieces come together. This will
take a fair bit more work / time, but I'm going to start nudging resources
in this direction very soon. In fact, we just talked about this in #infra
for a bit. Here's an attempt to summarize what came of it w.r.t. Ironic's
testing plans. We will need:

- some changes in devstack-gate to prepare a new environment by...
-- install sshd + firewall it to only allow connections from localhost
-- create a bunch of tiny qemu VMs (of configurable size and number)
- some changes in devstack to...
-- suck up a list of those VM's MAC addresses and enroll them in Ironic
-- configure nova to use ironic
-- configure ironic to use the pxe+ssh driver
- a new test job that turns all this on, thus allowing tempest to do all
its usual work against a "virtual baremetal" cloud

Also, it's worth mentioning, the above-described plan won't exercise the
CRUD of Ironic resources -- I think they need to be pre-enrolled with
Ironic before tempest starts (maybe not? maybe tempest can enroll them,
instead of devstack?). This is one reason why we have proposed separate
tempest tests for exercising Ironic's API. Another reason is, testing our
API is a valuable thing all by itself, and has a much lower development
cost than all the changes above.

-Devananda
___
OpenStack-dev mail

Re: [openstack-dev] [ironic][qa] How will ironic tests run in tempest?

2013-12-10 Thread Sean Dague

On 12/10/2013 07:05 PM, Robert Collins wrote:
> On 11 December 2013 09:43, David Kranz  wrote:
> 
>> So it seems that the code in the submitted tempest tests can run in a
>> regular job if devstack is configured to enable ironic, but that this cannot
>> be the default. So I propose that we create a regular devstack+ironic job
>> that will run in the ironic and tempest gates, and run just the ironic
>> tests. When third-party bare-metal results can be reported for ironic,
>> tempest can then accept tests that require bare-metal.  Does any one have a
>> problem with this approach?
> 
> Whats the connection between accepting baremetal tests and third-party
> testing? AIUI the criteria for acceptance is 'the thing is incubated
> or integrated'.

We also take the general policy of not landing things we've not seen
execute, otherwise we've found we end up with a bunch of non working
tests, because they aren't executed, a refactor happens, they don't get
caught, fail

So landing additional function means we need some data on it running.
That means either something in infra (ideally, it can be a periodic and
not an every patch sort of thing) though we can also handle that with
something coming back on 3rd party testing.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] domain admin role query

2013-12-10 Thread Ravi Chunduru

Hi,
  I am trying out Keystone V3 APIs and domains.
I created an domain, created a project in that domain, created an user in
that domain and project.
Next, gave an admin role for that user in that domain.

I am assuming that user is now admin to that domain.
Now, I got a scoped token with that user, domain and project. With that
token, I tried to create a new project in that domain. It worked.

But, using the same token, I could also create a new project in a 'default'
domain too. I expected it should throw authentication error. Is it a bug?

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

Re: [openstack-dev] Sphinx 1.2 incompatibility (failing -docs jobs)

2013-12-10 Thread Anita Kuno

On 12/10/2013 07:32 PM, Angus Salkeld wrote:
> On 10/12/13 14:57 -0800, James E. Blair wrote:
>> Hi,
>>
>> Sphinx 1.2 was just released and it is incompatible with distutils in
>> python 2.7.  See these links for more info:
>>
>>  
>> https://bitbucket.org/birkenfeld/sphinx/pull-request/193/builddoc-shouldnt-fail-on-unicode-paths/diff
>>
>>  http://bugs.python.org/issue19570
> 
> Is there a bug number that we can reference in recheck/reverifies?
Would it not be more helpful to submit a patch to the project in
question, for example: https://review.openstack.org/#/c/61245/
and go on irc to get core approval?

I do believe that docs jobs won't pass without the pin.

Thanks,
Anita.
> 
>>
>> This has caused all -docs jobs to fail.  This morning we merged a change
>> to openstack/requirements to pin Sphinx to version 1.2:
>>
>>  https://review.openstack.org/#/c/61164/
>>
>> Sergey Lukjanov, Clark Boylan, and Jeremy Stanley finished up the
>> automatic requirements proposal job (Thanks!), and so now updates have
>> been automatically proposed to all projects that subscribe:
>>
>>  https://review.openstack.org/#/q/topic:openstack/requirements,n,z
>>
>> Once those changes merge, -docs jobs for affected projects should start
>> working again.
>>
>> Note that requirements updates for stable branches are proceeding
>> separately; you can track their progress here:
>>
>>  
>> https://review.openstack.org/#/q/I0487b4eca8f2755b882689289e3cdf429729b1fb,n,z
>>
>>
>> -Jim
>>
>> ___
>> 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] [qa] [Solum] [tempest] Use of pecan test framework in functional tests

2013-12-10 Thread Adrian Otto

On Dec 10, 2013, at 3:12 PM, Russell Bryant 
 wrote:

> On 12/10/2013 04:10 PM, Georgy Okrokvertskhov wrote:
>> Hi,
>> 
>> In Solum project we are currently creating tests environments for future
>> test. We split unit tests and functional tests in order to use tempest
>> framework from the beginning. 
>> 
>> Tempest framework assumes that you run your service and test APi
>> endpoints by sending HTTP requests. Solum uses Pecan WSGI framework
>> which has its own test framework based on WebTest. This framework allows
>> to test application without sending actual HTTP traffic. It mocks low
>> level stuff related to transport but keeps all high level WSGI part as
>> it is a real life application\service.
>> 
>> There is a question to QA\Tempest teams, what do you think about using
>> pecan test framework in tempest for Pecan based applications?
> 
> I don't think that makes sense.  Then we're not using the code like it
> would be used normally (via HTTP).

I agree. The benefits we might get from bypassing HTTP for testing would likely 
be limited to speed of execution of the test, right? Unless we are suffering 
productivity problems from slow tests, I'd rather test it through HTTP just 
like a user would experience it.

Adrian


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

Re: [openstack-dev] Sphinx 1.2 incompatibility (failing -docs jobs)

2013-12-10 Thread Angus Salkeld


On 10/12/13 14:57 -0800, James E. Blair wrote:

Hi,

Sphinx 1.2 was just released and it is incompatible with distutils in
python 2.7.  See these links for more info:

 
https://bitbucket.org/birkenfeld/sphinx/pull-request/193/builddoc-shouldnt-fail-on-unicode-paths/diff
 http://bugs.python.org/issue19570


Is there a bug number that we can reference in recheck/reverifies?



This has caused all -docs jobs to fail.  This morning we merged a change
to openstack/requirements to pin Sphinx to version 1.2:

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

Sergey Lukjanov, Clark Boylan, and Jeremy Stanley finished up the
automatic requirements proposal job (Thanks!), and so now updates have
been automatically proposed to all projects that subscribe:

 https://review.openstack.org/#/q/topic:openstack/requirements,n,z

Once those changes merge, -docs jobs for affected projects should start
working again.

Note that requirements updates for stable branches are proceeding
separately; you can track their progress here:

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

-Jim

___
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] [Ironic] cleaning up our core reviewer list

2013-12-10 Thread Devananda van der Veen

Hi all,

It's about time that I look at the ironic review stats to see who should be
added / removed again.

There are several non-core folks doing reviews during the last month [1] --
thanks! These have been very helpful. I am also looking at the folks who
are contributing code [3] to get another view on depth of knowledge of the
project.

I'm not looking just at the numbers. Good review feedback is very
important, as is the ability to spot architectural problems in a patchset.
For contributors, whether a patch is a superficial fix or a meaningful
improvement is more important than the number of patches submitted. Right
now, I'm looking for folks who have both a general understanding of the
code and project architecture, and a deep knowledge in at least one area,
who have time to review at least one patch a day and attend the weekly
meeting.

Our stats for the last 30 days [1] are:

Total reviews: 711 (23.7/day)
Total reviewers: 23 (avg 1.0 reviews/day)
Total reviews by core team: 347 (11.6/day)
Core team size: 6 (avg 1.9 reviews/day)
New patch sets in the last 30 days: 519 (17.3/day)
Changes involved in the last 30 days: 147 (4.9/day)
  New changes in the last 30 days: 124 (4.1/day)
  Changes merged in the last 30 days: 99 (3.3/day)
  Changes abandoned in the last 30 days: 15 (0.5/day)
  Changes left in state WIP in the last 30 days: 4 (0.1/day)
  Queue growth in the last 30 days: 6 (0.2/day)
  Average number of patches per changeset: 3.5


With an average of 4 patches per day, and 4 active core reviewers, we
currently need to maintain a rate of 2 reviews per core member per day to
keep the backlog from growing.

With all that in mind, I don't see anyone who I feel is both an active
reviewer and has a solid grasp on the project (and who isn't already core)
at the moment. I'll be reaching out to a few people who I think are very
close to see if they are interested and able to commit to a few more
reviews, and revisit this mid-january.

Now for the goodbyes. Michael and Sean initially helped a lot with
nova-baremetal reviews and seeded Ironic's review team when the project
started out. However, they haven't been actively reviewing lately [2] and
when I chatted with them at the summit, neither indicated that they would
return to reviewing this code, so I have removed them from the core team.
I'd like to thank them both for the help jump-starting the project!

-Devananda


[1] - http://russellbryant.net/openstack-stats/ironic-reviewers-30.txt
[2] - http://russellbryant.net/openstack-stats/ironic-reviewers-90.txt
[3] -
http://www.stackalytics.com/?release=icehouse&metric=commits&project_type=openstack&module=ironic-group&company=&user_id=
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][qa] How will ironic tests run in tempest?

2013-12-10 Thread Robert Collins

On 11 December 2013 09:43, David Kranz  wrote:

> So it seems that the code in the submitted tempest tests can run in a
> regular job if devstack is configured to enable ironic, but that this cannot
> be the default. So I propose that we create a regular devstack+ironic job
> that will run in the ironic and tempest gates, and run just the ironic
> tests. When third-party bare-metal results can be reported for ironic,
> tempest can then accept tests that require bare-metal.  Does any one have a
> problem with this approach?

Whats the connection between accepting baremetal tests and third-party
testing? AIUI the criteria for acceptance is 'the thing is incubated
or integrated'.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] Sphinx 1.2 incompatibility (failing -docs jobs)

2013-12-10 Thread Chuck Short

On Tue, Dec 10, 2013 at 5:57 PM, James E. Blair wrote:

> Hi,
>
> Sphinx 1.2 was just released and it is incompatible with distutils in
> python 2.7.  See these links for more info:
>
>
> https://bitbucket.org/birkenfeld/sphinx/pull-request/193/builddoc-shouldnt-fail-on-unicode-paths/diff
>   http://bugs.python.org/issue19570
>
> This has caused all -docs jobs to fail.  This morning we merged a change
> to openstack/requirements to pin Sphinx to version 1.2:
>
>   https://review.openstack.org/#/c/61164/
>
> Sergey Lukjanov, Clark Boylan, and Jeremy Stanley finished up the
> automatic requirements proposal job (Thanks!), and so now updates have
> been automatically proposed to all projects that subscribe:
>
>   https://review.openstack.org/#/q/topic:openstack/requirements,n,z
>
> Once those changes merge, -docs jobs for affected projects should start
> working again.
>
> Note that requirements updates for stable branches are proceeding
> separately; you can track their progress here:
>
>
> https://review.openstack.org/#/q/I0487b4eca8f2755b882689289e3cdf429729b1fb,n,z
>
> -Jim
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


Hi,

i am seeing this issue already on Icehouse builds on trusty already, We are
shipping python-sphinx 1.2~b3 and we were getting the same error. We worked
around it in our builds by using sphinx-build rather than using python
setup.py build_sphinx in our packages.

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

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-10 Thread Fox, Kevin M

Yeah. Its likely that the metadata server stuff will get more scalable/hardened 
over time. If it isn't enough now, lets fix it rather then coming up with a new 
system to work around it.

I like the idea of using the network since all the hypervisors have to support 
network drivers already. They also already have to support talking to the 
metadata server. This keeps OpenStack out of the hypervisor driver business.

Kevin


From: Clint Byrum [cl...@fewbar.com]
Sent: Tuesday, December 10, 2013 1:02 PM
To: openstack-dev
Subject: Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Dmitry Mescheryakov's message of 2013-12-10 12:37:37 -0800:
> >> What is the exact scenario you're trying to avoid?
>
> It is DDoS attack on either transport (AMQP / ZeroMQ provider) or server
> (Salt / Our own self-written server). Looking at the design, it doesn't
> look like the attack could be somehow contained within a tenant it is
> coming from.
>

We can push a tenant-specific route for the metadata server, and a tenant
specific endpoint for in-agent things. Still simpler than hypervisor-aware
guests. I haven't seen anybody ask for this yet, though I'm sure if they
run into these problems it will be the next logical step.

> In the current OpenStack design I see only one similarly vulnerable
> component - metadata server. Keeping that in mind, maybe I just
> overestimate the threat?
>

Anything you expose to the users is "vulnerable". By using the localized
hypervisor scheme you're now making the compute node itself vulnerable.
Only now you're asking that an already complicated thing (nova-compute)
add another job, rate limiting.

___
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] DHCP Agent Reliability

2013-12-10 Thread Isaku Yamahata

On Wed, Dec 11, 2013 at 01:23:36AM +0900,
Maru Newby  wrote:

> 
> On Dec 10, 2013, at 6:36 PM, Isaku Yamahata  wrote:
> 
> > On Mon, Dec 09, 2013 at 08:43:59AM +1300,
> > Robert Collins  wrote:
> > 
>  listening: when an agent connects after an outage, it first starts
>  listening, then does a poll for updates it missed.
> >>> 
> >>> Are you suggesting that processing of notifications and full state 
> >>> synchronization are able to cooperate safely?  Or hoping that it will be 
> >>> so in the future?
> >> 
> >> I'm saying that you can avoid race conditions by a combination of
> >> 'subscribe to changes' + 'give me the full state'.
> > 
> > Like this?
> > https://review.openstack.org/#/c/61057/
> > This patch is just to confirm the idea.
> 
> I'm afraid the proposed patch is no more reliable than the current approach 
> of using file-based locking.   I am working on an alternate patch that puts 
> the rpc event loop in the dhcp agent so that better coordination between full 
> synchronization and notification handling is possible.  This approach has 
> already been taken with the L3 agent and work on the L2 agent is in process.  

You objected against agent polling in the discussion.
But you're now proposing polling now. Did you change your mind?
-- 
Isaku Yamahata 

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

Re: [openstack-dev] [Nova][Cells] compute api and objects

2013-12-10 Thread Chris Behrens

On Dec 9, 2013, at 2:58 PM, Sam Morrison  wrote:

> Hi,
> 
> I’m trying to fix up some cells issues related to objects. Do all compute api 
> methods take objects now?
> cells is still sending DB objects for most methods (except start and stop) 
> and I know there are more than that.
> 
> Eg. I know lock/unlock, shelve/unshelve take objects, I assume there are 
> others if not all methods now?

I don't think all of them do.  As the compute API methods were changing, we 
were changing the cells code at the same time to not use the generic 
'call_compute_api_method' RPC call.

It's possible some got missed, however.  And in fact, it does look like this is 
the case.  The shelve calls appear to be example of where things were 
converted, but the cells code was forgotten.  :-/

We'll want to implement new RPC calls in nova/cells/rpcapi that are compatible 
with the compute_rpcapi calls that are normally used.  And then add the 
appropriate code in nova/cells/manager.py and nova/cells/messaging.py.

I can help fix this all up.  I guess we'll want to find and file bugs for all 
of these.  It appears you've got a bug filed for unlock… (lock would also be 
broken, I would think).

- Chris

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

[openstack-dev] [Neutron] Does any plugin require hairpinning to be enabled?

2013-12-10 Thread Collins, Sean (Contractor)

Hi,

We currently have a bug for IPv6 work, which is to disable hairpinning
on the bridge that Nova creates. By default, it is always turned on,
which prevents instances from configuring IPv6 SLAAC addresses

https://launchpad.net/bugs/1251235

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

Daniel Berrange has suggested that it be a per-VIF attribute - and in
principle I agree - provided that the default is to not enable
hairpinning.

I would appreciate anyone's thoughts in the matter.


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

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-10 Thread Vladik Romanovsky


Maybe it will be useful to use Ovirt guest agent as a base.

http://www.ovirt.org/Guest_Agent
https://github.com/oVirt/ovirt-guest-agent

It is already working well on linux and windows and has a lot of functionality.
However, currently it is using virtio-serial for communication, but I think it 
can be extended for other bindings.

Vladik

- Original Message -
> From: "Clint Byrum" 
> To: "openstack-dev" 
> Sent: Tuesday, 10 December, 2013 4:02:41 PM
> Subject: Re: [openstack-dev] Unified Guest Agent proposal
> 
> Excerpts from Dmitry Mescheryakov's message of 2013-12-10 12:37:37 -0800:
> > >> What is the exact scenario you're trying to avoid?
> > 
> > It is DDoS attack on either transport (AMQP / ZeroMQ provider) or server
> > (Salt / Our own self-written server). Looking at the design, it doesn't
> > look like the attack could be somehow contained within a tenant it is
> > coming from.
> > 
> 
> We can push a tenant-specific route for the metadata server, and a tenant
> specific endpoint for in-agent things. Still simpler than hypervisor-aware
> guests. I haven't seen anybody ask for this yet, though I'm sure if they
> run into these problems it will be the next logical step.
> 
> > In the current OpenStack design I see only one similarly vulnerable
> > component - metadata server. Keeping that in mind, maybe I just
> > overestimate the threat?
> > 
> 
> Anything you expose to the users is "vulnerable". By using the localized
> hypervisor scheme you're now making the compute node itself vulnerable.
> Only now you're asking that an already complicated thing (nova-compute)
> add another job, rate limiting.
> 
> ___
> 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] Sphinx 1.2 incompatibility (failing -docs jobs)

2013-12-10 Thread James E. Blair

Hi,

Sphinx 1.2 was just released and it is incompatible with distutils in
python 2.7.  See these links for more info:

  
https://bitbucket.org/birkenfeld/sphinx/pull-request/193/builddoc-shouldnt-fail-on-unicode-paths/diff
  http://bugs.python.org/issue19570

This has caused all -docs jobs to fail.  This morning we merged a change
to openstack/requirements to pin Sphinx to version 1.2:

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

Sergey Lukjanov, Clark Boylan, and Jeremy Stanley finished up the
automatic requirements proposal job (Thanks!), and so now updates have
been automatically proposed to all projects that subscribe:

  https://review.openstack.org/#/q/topic:openstack/requirements,n,z

Once those changes merge, -docs jobs for affected projects should start
working again.

Note that requirements updates for stable branches are proceeding
separately; you can track their progress here:

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

-Jim

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

Re: [openstack-dev] [qa] [Solum] [tempest] Use of pecan test framework in functional tests

2013-12-10 Thread Georgy Okrokvertskhov

Thanks everyone for feedback. Will follow the standard approach with HTTP
requests in tempest tests.

Thanks
Georgy


On Tue, Dec 10, 2013 at 2:47 PM, Sean Dague  wrote:

> Pretty much 100% agree with Russell and Ryan.
>
> Webtest is interesting for in tree testing with Solum, because it's
> specifically *not* bringing up the full stack.
>
> When it comes to Tempest, you are hitting a live OpenStack cloud, most
> likely not on the same machine as Tempest is on (not true in the gate
> today... but we try to act like it is). So you must hit HTTP.
>
> -Sean
>
> On 12/10/2013 04:24 PM, Ryan Petrello wrote:
> > My opinion is that there’s value in both.  Writing functional tests for
> Solum’s test suite using WebTest can be pretty useful for testing the API’s
> logic without having to involve HTTP (to e.g., call API endpoints with
> certain POST arguments and assert that certain mocked functions end up
> being called down the line).
> >
> > When you involve Tempest, though, you’re generally pointing at a real
> HTTP server and testing for correctness, so using HTTP here makes sense
> (imo).
> >
> > ---
> > Ryan Petrello
> > Senior Developer, DreamHost
> > ryan.petre...@dreamhost.com
> >
> > On Dec 10, 2013, at 4:12 PM, Russell Bryant  wrote:
> >
> >> On 12/10/2013 04:10 PM, Georgy Okrokvertskhov wrote:
> >>> Hi,
> >>>
> >>> In Solum project we are currently creating tests environments for
> future
> >>> test. We split unit tests and functional tests in order to use tempest
> >>> framework from the beginning.
> >>>
> >>> Tempest framework assumes that you run your service and test APi
> >>> endpoints by sending HTTP requests. Solum uses Pecan WSGI framework
> >>> which has its own test framework based on WebTest. This framework
> allows
> >>> to test application without sending actual HTTP traffic. It mocks low
> >>> level stuff related to transport but keeps all high level WSGI part as
> >>> it is a real life application\service.
> >>>
> >>> There is a question to QA\Tempest teams, what do you think about using
> >>> pecan test framework in tempest for Pecan based applications?
> >>
> >> I don't think that makes sense.  Then we're not using the code like it
> >> would be used normally (via HTTP).
> >>
> >> --
> >> Russell Bryant
> >>
> >> ___
> >> 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
> >
>
>
> --
> Sean Dague
> http://dague.net
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Nominations to Horizon Core

2013-12-10 Thread Paul McMillan

+1 on Tatiana Mazur, she's been doing a bunch of good work lately.

I'm fine with me being removed from core provided you have someone else 
qualified to address security issues as they come up. My contributions have 
lately been reviewing and responding to security issues, vetting fixes for 
those, and making sure they happen in a timely fashion. Fortunately, we haven't 
had too many of those lately. Other than that, I've been lurking and reviewing 
to make sure nothing egregious gets committed.

If you don't have anyone else who is a web security specialist on the core 
team, I'd like to stay. Since I'm also a member of the Django security team, I 
offer a significant chunk of knowledge about how the underlying security 
protections are intended work.

-Paul


From: Gabriel Hurley 
Sent: Tuesday, December 10, 2013 1:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Horizon]  Nominations to Horizon Core

+1 on Tatiana Mazur being added to Core.

I'm also okay with cleaning out the Core list. I considered doing it myself 
last cycle since none of those folks are involved anymore, but figured I'd 
leave them as a posthumous honor. ;-) I think now's a good time to trim it down.

Glad I didn't make the axe list,

- Gabriel

> -Original Message-
> From: Lyle, David [mailto:david.l...@hp.com]
> Sent: Tuesday, December 10, 2013 12:24 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Horizon] Nominations to Horizon Core
>
> I would like to nominate Tatiana Mazur to Horizon Core.  Tatiana has been a
> significant code contributor in the last two releases, understands the code
> base well and has been doing a significant number of reviews for the last to
> milestones.
>
>
> Additionally, I'd like to remove some inactive members of Horizon-core who
> have been inactive since the early Grizzly release at the latest.
> Devin Carlen
> Jake Dahn
> Jesse Andrews
> Joe Heck
> John Postlethwait
> Paul McMillan
> Todd Willey
> Tres Henry
> paul-tashima
> sleepsonthefloor
>
>
> Please respond with a +1/-1 by this Friday.
>
> -David Lyle
>
>
>
>
> ___
> 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] [qa] [Solum] [tempest] Use of pecan test framework in functional tests

2013-12-10 Thread Sean Dague

Pretty much 100% agree with Russell and Ryan.

Webtest is interesting for in tree testing with Solum, because it's
specifically *not* bringing up the full stack.

When it comes to Tempest, you are hitting a live OpenStack cloud, most
likely not on the same machine as Tempest is on (not true in the gate
today... but we try to act like it is). So you must hit HTTP.

-Sean

On 12/10/2013 04:24 PM, Ryan Petrello wrote:
> My opinion is that there’s value in both.  Writing functional tests for 
> Solum’s test suite using WebTest can be pretty useful for testing the API’s 
> logic without having to involve HTTP (to e.g., call API endpoints with 
> certain POST arguments and assert that certain mocked functions end up being 
> called down the line).
> 
> When you involve Tempest, though, you’re generally pointing at a real HTTP 
> server and testing for correctness, so using HTTP here makes sense (imo).
> 
> ---
> Ryan Petrello
> Senior Developer, DreamHost
> ryan.petre...@dreamhost.com
> 
> On Dec 10, 2013, at 4:12 PM, Russell Bryant  wrote:
> 
>> On 12/10/2013 04:10 PM, Georgy Okrokvertskhov wrote:
>>> Hi,
>>>
>>> In Solum project we are currently creating tests environments for future
>>> test. We split unit tests and functional tests in order to use tempest
>>> framework from the beginning. 
>>>
>>> Tempest framework assumes that you run your service and test APi
>>> endpoints by sending HTTP requests. Solum uses Pecan WSGI framework
>>> which has its own test framework based on WebTest. This framework allows
>>> to test application without sending actual HTTP traffic. It mocks low
>>> level stuff related to transport but keeps all high level WSGI part as
>>> it is a real life application\service.
>>>
>>> There is a question to QA\Tempest teams, what do you think about using
>>> pecan test framework in tempest for Pecan based applications?
>>
>> I don't think that makes sense.  Then we're not using the code like it
>> would be used normally (via HTTP).
>>
>> -- 
>> Russell Bryant
>>
>> ___
>> 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
> 


-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]

2013-12-10 Thread Vasudevan, Swaminathan (PNB Roseville)




On Tuesday, December 10, 2013 4:17:45 PM, Maithem Munshed 71510 wrote:

Hello,

I was wondering, what is the reason behind having nova audit resources
as opposed to using usage stats directly from what is reported by the
compute driver. The available resources reported from the audit can be
incorrect in some cases. Also, in many cases the reported usage stats
from the driver are correct, so auditing periodically while having the
usage stats from the driver is inefficient. One of the which result in
an incorrect audit is: existing VMs on a hypervisor that are created
prior to deploying nova. As a result, the scheduler will see more
available resources than what actually is available. I am aware that
Nova shouldn’t be managing VMs that it hasn’t created, but the
reported available resources should be as accurate as possible.

I have proposed the following blueprint to provide the option of using
usage stats directly from the driver :

https://blueprints.launchpad.net/nova/+spec/use-driver-usage-stats

I would like to know what your thoughts are and would appreciate feedback.

Regards,

Maithem



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


One (big) problem is the virt drivers don't follow a standard format 
for the usage diagnostics, which has been discussed before in the 
mailing list [1].


There is a nova blueprint [2] for standard auditing formats like in 
ceilometer which might be related to what you're looking for.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2013-October/016385.html
[2] 
https://blueprints.launchpad.net/nova/+spec/support-standard-audit-formats


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Horizon] Nominations to Horizon Core

2013-12-10 Thread Julie Pichon

"David Lyle"  wrote:
> I would like to nominate Tatiana Mazur to Horizon Core.  Tatiana has been a
> significant code contributor in the last two releases, understands the code
> base well and has been doing a significant number of reviews for the last to
> milestones.

+1

> Additionally, I'd like to remove some inactive members of Horizon-core who
> have been inactive since the early Grizzly release at the latest.
> Devin Carlen
> Jake Dahn
> Jesse Andrews
> Joe Heck
> John Postlethwait
> Paul McMillan
> Todd Willey
> Tres Henry
> paul-tashima
> sleepsonthefloor

+1. Thank you for your work in creating and building up Horizon!

Julie

> 
> Please respond with a +1/-1 by this Friday.
> 
> -David Lyle
> 
> 
> 
> 
> ___
> 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] [keystone] Service scoped role definition

2013-12-10 Thread Tiwari, Arvind

My Comments in line.

Arvind

-Original Message-
From: Adam Young [mailto:ayo...@redhat.com] 
Sent: Tuesday, December 10, 2013 2:54 PM
To: David Chadwick; Tiwari, Arvind; OpenStack Development Mailing List (not for 
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

On 12/10/2013 04:26 PM, David Chadwick wrote:
> Hi Arvind
>
> the granularity in naming can be as fine as required i.e. a naming
> hierarchy can be as deep as required. So if there is a requirement for
> individual endpoints to name their own roles, then the addition of
> endpoint_id to the naming structure is fine.
>
> regards
>
> David
>
> On 10/12/2013 16:42, Tiwari, Arvind wrote:
>> Hi David,
>>
>> I am cool with the proposal, just wanted to grad you attention on may
>> question which I asked in my last email (which is below)
>>
>> Q. what if two (or more) endpoints want to have same role_name for a
>> service (nova.east.admin, nova.west.admin, nova.north.admin .)?
>>
>> (Can we think of adding an optional endpoint_id attribute in role
>> data model to allow such role, which is also needed to envision
>> endpoint scoped tokens for our use case)
>>
>> { "role": { "id": "76e72a", "domain_id" = "--id--",(optional, if
>> present, role is named by specific domain) "project_id" = "--id--",
>> (optional, if present, role is named by project) "service_id" =
>> "--id--",(optional, if present, role is named by service)
>> "endpoint_id" = "--id--",(optional, if present, role is named by
>> service) "name": "---role_name---",  (must be unique when combined
>> with domain, project and service ids) "scope": {"id": "---id---",
>> (resource_id) "type": "service | file | domain etc.",
>> "endpoint":"---endpoint---" } } }
>>
>> For Adam's question " We are not linking role names to service id."
>> (email attached) AT: These attributes are all optional and will not
>> stop anyone how don't want to included service_id or (any other
>> attribute) for role name uniqueness. So in particular deployment want
>> to keep just the role name unique, this model will not restrict you.

Unnecessary.  You are basically putting in documentation about how they 
are to be enforced, which does not belong there.
Just do the basic:  allow for the role naming to be nested under 
projects and domains, and use that to support your use case.
This discussion is taking up too much time and effort.  Please stop 
trying to make it more complex than necessary.

AT: We are not putting in documentation but we are trying to come up with 
generic role data model so that it will support all (private and public cloud) 
of our role needs as explained in BP and extensible.
If you really have a solution for all the problems listed in below BPs, please 
draft it and present in detail.
So far, two high level ideas (nested role-def and name space) proposed by you 
are not helping which is clear.

https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens.

I will appreciate and definitely consider them if they will resolve our 
problems.


  

>>
>> Thoughts?
>>
>>
>>
>> Thanks, Arvind
>>
>>
>>
>> -Original Message- From: David Chadwick
>> [mailto:d.w.chadw...@kent.ac.uk] Sent: Tuesday, December 10, 2013
>> 1:30 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing
>> List (not for usage questions) Cc: Henry Nash;
>> dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev]
>> [keystone] Service scoped role definition
>>
>> How about the following which clearly separates naming and scoping
>> constraints
>>
>> { "role": { "id": "76e72a", "domain_id" = "--id--",(optional, if
>> present, role is named by specific domain) "project_id" = "--id--",
>> (optional, if present, role is named by project) "service_id" =
>> "--id--",(optional, if present, role is named by service) "name":
>> "---role_name---",  (must be unique when combined with domain,
>> project and service ids) "scope": {"id": "---id---", (resource_id)
>> "type": "service | file | domain etc.", "endpoint":"---endpoint---"
>> } } }
>>
>> regards
>>
>> David
>>


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

Re: [openstack-dev] Neutron Distributed Virtual Router

Hi Nachi/Akihiro motoki,

I am not clear.

Today the L3 Service Plugin does not support the "service_type" attribute to 
define the provider option.



Are we suggesting that we need to include the service_type for the L3 Service 
Plugin and then we can make use of the "service_type" attribute to distinguish 
between the "edge" and "distributed".





So if I understand correctly, a "provider" router will be an Edge router and a 
non-provider router will be a "distributed router".



Thanks

Swami



>I'm +1 for 'provider'.



2013/12/9 Akihiro Motoki :

> Neutron defines "provider" attribute and it is/will be used in advanced

> services (LB, FW, VPN).

> Doesn't it fit for a distributed router case? If we can cover all services

> with one concept, it would be nice.

>

> According to this thread, we assumes at least two types "edge" and

> "distributed".

> Though "edge" and "distributed" is a type of implementations, I think they

> are some kind of "provider".

>

> I just would like to add an option. I am open to "provider" vs "distirbute"

> attributes.

>

> Thanks,

> Akihiro

>

> (2013/12/10 7:01), Vasudevan, Swaminathan (PNB Roseville) wrote:

>> Hi Folks,

>>

>> We are in the process of defining the API for the Neutron Distributed

>> Virtual Router, and we have a question.

>>

>> Just wanted to get the feedback from the community before we implement and

>> post for review.

>>

>> We are planning to use the "distributed" flag for the routers that are

>> supposed to be routing traffic locally (both East West and North South).

>> This "distributed" flag is already there in the "neutronclient" API, but

>> currently only utilized by the "Nicira Plugin".

>> We would like to go ahead and use the same "distributed" flag and add an

>> extension to the router table to accommodate the "distributed flag".

>>

>> Please let us know your feedback.

>>

>> Thanks.

>>

>> Swaminathan Vasudevan

>> Systems Software Engineer (TC)

>> HP Networking

>> Hewlett-Packard

>> 8000 Foothills Blvd

>> M/S 5541

>> Roseville, CA - 95747

>> tel: 916.785.0937

>> fax: 916.785.1815

>> email: swaminathan.vasude...@hp.com 


Swaminathan Vasudevan
Systems Software Engineer (TC)


HP Networking
Hewlett-Packard
8000 Foothills Blvd
M/S 5541
Roseville, CA - 95747
tel: 916.785.0937
fax: 916.785.1815
email: swaminathan.vasude...@hp.com


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

[openstack-dev] [nova]

2013-12-10 Thread Maithem Munshed 71510

Hello,

 

I was wondering, what is the reason behind having nova audit resources as
opposed to using usage stats directly from what is reported by the compute
driver. The available resources reported from the audit can be incorrect
in some cases. Also, in many cases the reported usage stats from the
driver are correct, so auditing periodically while having the usage stats
from the driver is inefficient. One of the which result in an incorrect
audit is: existing VMs on a hypervisor that are created prior to deploying
nova. As a result, the scheduler will see more available resources than
what actually is available. I am aware that Nova shouldn't be managing VMs
that it hasn't created, but the reported available resources should be as
accurate as possible. 

 

I have proposed the following blueprint to provide the option of using
usage stats directly from the driver :

https://blueprints.launchpad.net/nova/+spec/use-driver-usage-stats

 

I would like to know what your thoughts are and would appreciate feedback.

 

Regards,

Maithem

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

[openstack-dev] Neutron Distributed Virtual Router

2013-12-10 Thread Vasudevan, Swaminathan (PNB Roseville)

Hi Nachi,
Yes you are right, NSX deals with (local or distributed) routers and Service 
Routers.
Thanks
Swami


>Hi Yong



>NSX have two kind of router.

>Edge and distributed router.



>Edge node will work as some VPN services and advanced service nodes.



>Actually, VPNaaS OSS impl is running in l3-agent.

>so IMO, we need l3-agent also for basis of some edge services.











2013/12/9 Yongsheng Gong :

> If distributed router is good enough, why do we still need non-distributed

> router?

>

>

> On Tue, Dec 10, 2013 at 9:04 AM, Ian Wells  wrote:

>>

>> I would imagine that, from the Neutron perspective, you get a single

>> router whether or not it's distributed.  I think that if a router is

>> distributed - regardless of whether it's tenant-tenant or tenant-outside -

>> it certainly *could* have some sort of SLA flag, but I don't think a simple

>> 'distributed' flag is either here or there; it's not telling the tenant

>> anything meaningful.

>>

>>

>> On 10 December 2013 00:48, Mike Wilson  wrote:

>>>

>>> I guess the question that immediately comes to mind is, is there anyone

>>> that doesn't want a distributed router? I guess there could be someone out

>>> there that hates the idea of traffic flowing in a balanced fashion, but

>>> can't they just run a single router then? Does there really need to be some

>>> flag to disable/enable this behavior? Maybe I am oversimplifying things...

>>> you tell me.

>>>

>>> -Mike Wilson

>>>

>>>

>>> On Mon, Dec 9, 2013 at 3:01 PM, Vasudevan, Swaminathan (PNB Roseville)

>>>  wrote:



 Hi Folks,



 We are in the process of defining the API for the Neutron Distributed

 Virtual Router, and we have a question.







 Just wanted to get the feedback from the community before we implement

 and post for review.







 We are planning to use the "distributed" flag for the routers that are

 supposed to be routing traffic locally (both East West and North South).



 This "distributed" flag is already there in the "neutronclient" API, but

 currently only utilized by the "Nicira Plugin".



 We would like to go ahead and use the same "distributed" flag and add an

 extension to the router table to accommodate the "distributed flag".







 Please let us know your feedback.







 Thanks.







 Swaminathan Vasudevan



 Systems Software Engineer (TC)











 HP Networking



 Hewlett-Packard



 8000 Foothills Blvd



 M/S 5541



 Roseville, CA - 95747



 tel: 916.785.0937



 fax: 916.785.1815



 email: swaminathan.vasude...@hp.com




Swaminathan Vasudevan
Systems Software Engineer (TC)


HP Networking
Hewlett-Packard
8000 Foothills Blvd
M/S 5541
Roseville, CA - 95747
tel: 916.785.0937
fax: 916.785.1815
email: swaminathan.vasude...@hp.com


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

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-10 Thread Robert Collins

On 11 December 2013 05:42, Jaromir Coufal  wrote:
> On 2013/09/12 23:38, Tzu-Mainn Chen wrote:
>> The disagreement comes from whether we need manual node assignment or not.
>> I would argue that we
>> need to step back and take a look at the real use case: heterogeneous
>> nodes.  If there are literally
>> no characteristics that differentiate nodes A and B, then why do we care
>> which gets used for what?  Why
>> do we need to manually assign one?
>
>
> Ideally, we don't. But with this approach we would take out the possibility
> to change something or decide something from the user.

So, I think this is where the confusion is. Using the nova scheduler
doesn't prevent change or control. It just ensures the change and
control happen in the right place: the Nova scheduler has had years of
work, of features and facilities being added to support HPC, HA and
other such use cases. It should have everything we need [1], without
going down to manual placement. For clarity: manual placement is when
any of the user, Tuskar, or Heat query Ironic, select a node, and then
use a scheduler hint to bypass the scheduler.

> The 'easiest' way is to support bigger companies with huge deployments,
> tailored infrastructure, everything connected properly.
>
> But there are tons of companies/users who are running on old heterogeneous
> hardware. Very likely even more than the number of companies having already
> mentioned large deployments. And giving them only the way of 'setting up
> rules' in order to get the service on the node - this type of user is not
> gonna use our deployment system.

Thats speculation. We don't know if they will or will not because we
haven't given them a working system to test.

Lets break the concern into two halves:
A) Users who could have their needs met, but won't use TripleO because
meeting their needs in this way is too hard/complex/painful.

B) Users who have a need we cannot meet with the current approach.

For category B users, their needs might be specific HA things - like
the oft discussed failure domains angle, where we need to split up HA
clusters across power bars, aircon, switches etc. Clearly long term we
want to support them, and the undercloud Nova scheduler is entirely
capable of being informed about this, and we can evolve to a holistic
statement over time. Lets get a concrete list of the cases we can
think of today that won't be well supported initially, and we can
figure out where to do the work to support them properly.

For category A users, I think that we should get concrete examples,
and evolve our design (architecture and UX) to make meeting those
needs pleasant.

What we shouldn't do is plan complex work without concrete examples
that people actually need. Jay's example of some shiny new compute
servers with special parts that need to be carved out was a great one
- we can put that in category A, and figure out if it's easy enough,
or obvious enough - and think about whether we document it or make it
a guided workflow or $whatever.

> Somebody might argue - why do we care? If user doesn't like TripleO
> paradigm, he shouldn't use the UI and should use another tool. But the UI is
> not only about TripleO. Yes, it is underlying concept, but we are working on
> future *official* OpenStack deployment tool. We should care to enable people
> to deploy OpenStack - large/small scale, homo/heterogeneous hardware,
> typical or a bit more specific use-cases.

The difficulty I'm having is that the discussion seems to assume that
'heterogeneous implies manual', but I don't agree that that
implication is necessary!

> As an underlying paradigm of how to install cloud - awesome idea, awesome
> concept, it works. But user doesn't care about how it is being deployed for
> him. He cares about getting what he wants/needs. And we shouldn't go that
> far that we violently force him to treat his infrastructure as cloud. I
> believe that possibility to change/control - if needed - is very important
> and we should care.

I propose that we make concrete use cases: 'Fred cannot use TripleO
without manual assignment because XYZ'. Then we can assess how
important XYZ is to our early adopters and go from there.

> And what is key for us is to *enable* users - not to prevent them from using
> our deployment tool, because it doesn't work for their requirements.

Totally agreed :)

>> If we can agree on that, then I think it would be sufficient to say that
>> we want a mechanism to allow
>> UI users to deal with heterogeneous nodes, and that mechanism must use
>> nova-scheduler.  In my mind,
>> that's what resource classes and node profiles are intended for.
>
>
> Not arguing on this point. Though that mechanism should support also cases,
> where user specifies a role for a node / removes node from a role. The rest
> of nodes which I don't care about should be handled by nova-scheduler.

Why! What is a use case for removing a role from a node while leaving
that node in service? Lets be specific, alway

Re: [openstack-dev] FW: [Bug 1257788] Re: nova-network doesn't handle large amount of concurrent booting instances well

2013-12-10 Thread Joe Gordon

On Dec 10, 2013 7:38 PM, "Joshua Harlow"  wrote:
>
> Yup, IMHO this is where the rally[1] project, and others that attempt to
> push the boundaries are really helping openstack become much better around
> these types of issues. At yahoo! in a short-time it will not be that
> uncommon to boot 100+ VMs concurrently (traffic spikes, other random QA
> testing that requires more than 10 instances...). So the earlier these
> issues get solved then the better it will be for everyone (and they likely
> are not simple issues to solve, sadly).

I don't think this issue in particular is very hard to fix for
nova-networking but I don't know enough about neutron to speak for it as
well. I included a possible route to fixing this in the bug itself.

>
> [1] https://wiki.openstack.org/wiki/Rally
>
> On 12/10/13 10:17 AM, "Edgar Magana"  wrote:
>
> >FYI. Concurrent calls are a problem all around in OpenStack!
> >
> >Edgar
> >
> >On 12/10/13 8:47 AM, "Abhishek Chanda"  wrote:
> >
> >>** Changed in: nova
> >>   Status: New => Triaged
> >>
> >>--
> >>You received this bug notification because you are subscribed to
> >>neutron.
> >>https://bugs.launchpad.net/bugs/1257788
> >>
> >>Title:
> >>  nova-network doesn't handle large amount of concurrent booting
> >>  instances well
> >>
> >>Status in OpenStack Neutron (virtual network service):
> >>  Triaged
> >>Status in OpenStack Compute (Nova):
> >>  Triaged
> >>
> >>Bug description:
> >>  As seen by the large-ops test nova-network has trouble booting 150 VMs
> >>  concurrently. Part of the problem is that setting up the network for
> >>  each instance is relatively expensive with many locks and root-wrapped
> >>  calls. Both of which significantly hurt performance.  One possible fix
> >>  would be to do more bulk network operations when possible, so instead
> >>  of 100 separate calls to a root-wrapped tool call it once.
> >>
> >>To manage notifications about this bug go to:
> >>https://bugs.launchpad.net/neutron/+bug/1257788/+subscriptions
> >
> >
> >
> >___
> >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] [keystone] Service scoped role definition

2013-12-10 Thread Tiwari, Arvind

Yes, it is required to address one of public cloud use case where we want 
regional service admins and to support 
https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP. 

Based on our discussion I am going to start API specs and submit for review.

{
 "role": {
  "id": "76e72a",
  "domain_id" = "--id--",(optional, if present, role is named by 
specific domain)
  "project_id" = "--id--",(optional, if present, role is named by 
project)
  "service_id" = "--id--",(optional, if present, role is named by 
service)
  "endpoint_id" = "--id--",(optional, if present, role is named by 
service)
  "name": "---role_name---",  (must be unique when combined with domain, 
project and service ids)
  "scope": {"id": "---id---", (resource_id)
 "type": "service | file | domain etc.",
 "endpoint":"---endpoint---"
   }
}
 }


For Adam's Concern, "You are over designing.  Services and Endpoints have no 
business in this design.  That is enforcement, not definition or assignment of 
the Roles.  We need a clean namespace, and mixing services and endpoints in 
there adds no benefit."
AT: To support following two BPs and these are the basic requirements for 
public cloud deployment with Keystone otherwise we are locked.  I  am asking 
for endpoint_id extension in role data model to support endpoint scoped tokens 
which you mentioned in IRC around a week back. 

1. 
https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
2. https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens.


Thanks.
Arvind 

-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] 
Sent: Tuesday, December 10, 2013 2:27 PM
To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for 
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

Hi Arvind

the granularity in naming can be as fine as required i.e. a naming
hierarchy can be as deep as required. So if there is a requirement for
individual endpoints to name their own roles, then the addition of
endpoint_id to the naming structure is fine.

regards

David

On 10/12/2013 16:42, Tiwari, Arvind wrote:
> Hi David,
> 
> I am cool with the proposal, just wanted to grad you attention on may
> question which I asked in my last email (which is below)
> 
> Q. what if two (or more) endpoints want to have same role_name for a
> service (nova.east.admin, nova.west.admin, nova.north.admin .)?
> 
> (Can we think of adding an optional endpoint_id attribute in role
> data model to allow such role, which is also needed to envision
> endpoint scoped tokens for our use case)
> 
> { "role": { "id": "76e72a", "domain_id" = "--id--",(optional, if
> present, role is named by specific domain) "project_id" = "--id--",
> (optional, if present, role is named by project) "service_id" =
> "--id--",(optional, if present, role is named by service) 
> "endpoint_id" = "--id--",(optional, if present, role is named by
> service) "name": "---role_name---",  (must be unique when combined
> with domain, project and service ids) "scope": {"id": "---id---",
> (resource_id) "type": "service | file | domain etc.", 
> "endpoint":"---endpoint---" } } }
> 
> For Adam's question " We are not linking role names to service id."
> (email attached) AT: These attributes are all optional and will not
> stop anyone how don't want to included service_id or (any other
> attribute) for role name uniqueness. So in particular deployment want
> to keep just the role name unique, this model will not restrict you.
> 
> Thoughts?
> 
> 
> 
> Thanks, Arvind
> 
> 
> 
> -Original Message- From: David Chadwick
> [mailto:d.w.chadw...@kent.ac.uk] Sent: Tuesday, December 10, 2013
> 1:30 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing
> List (not for usage questions) Cc: Henry Nash;
> dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev]
> [keystone] Service scoped role definition
> 
> How about the following which clearly separates naming and scoping 
> constraints
> 
> { "role": { "id": "76e72a", "domain_id" = "--id--",(optional, if
> present, role is named by specific domain) "project_id" = "--id--",
> (optional, if present, role is named by project) "service_id" =
> "--id--",(optional, if present, role is named by service) "name":
> "---role_name---",  (must be unique when combined with domain,
> project and service ids) "scope": {"id": "---id---", (resource_id) 
> "type": "service | file | domain etc.", "endpoint":"---endpoint---" 
> } } }
> 
> regards
> 
> David
> 

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

Re: [openstack-dev] [keystone] Service scoped role definition

2013-12-10 Thread Adam Young


On 12/10/2013 04:26 PM, David Chadwick wrote:

Hi Arvind

the granularity in naming can be as fine as required i.e. a naming
hierarchy can be as deep as required. So if there is a requirement for
individual endpoints to name their own roles, then the addition of
endpoint_id to the naming structure is fine.

regards

David

On 10/12/2013 16:42, Tiwari, Arvind wrote:

Hi David,

I am cool with the proposal, just wanted to grad you attention on may
question which I asked in my last email (which is below)

Q. what if two (or more) endpoints want to have same role_name for a
service (nova.east.admin, nova.west.admin, nova.north.admin .)?

(Can we think of adding an optional endpoint_id attribute in role
data model to allow such role, which is also needed to envision
endpoint scoped tokens for our use case)

{ "role": { "id": "76e72a", "domain_id" = "--id--",(optional, if
present, role is named by specific domain) "project_id" = "--id--",
(optional, if present, role is named by project) "service_id" =
"--id--",(optional, if present, role is named by service)
"endpoint_id" = "--id--",(optional, if present, role is named by
service) "name": "---role_name---",  (must be unique when combined
with domain, project and service ids) "scope": {"id": "---id---",
(resource_id) "type": "service | file | domain etc.",
"endpoint":"---endpoint---" } } }

For Adam's question " We are not linking role names to service id."
(email attached) AT: These attributes are all optional and will not
stop anyone how don't want to included service_id or (any other
attribute) for role name uniqueness. So in particular deployment want
to keep just the role name unique, this model will not restrict you.


Unnecessary.  You are basically putting in documentation about how they 
are to be enforced, which does not belong there.
Just do the basic:  allow for the role naming to be nested under 
projects and domains, and use that to support your use case.
This discussion is taking up too much time and effort.  Please stop 
trying to make it more complex than necessary.





Thoughts?



Thanks, Arvind



-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Tuesday, December 10, 2013
1:30 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing
List (not for usage questions) Cc: Henry Nash;
dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev]
[keystone] Service scoped role definition

How about the following which clearly separates naming and scoping
constraints

{ "role": { "id": "76e72a", "domain_id" = "--id--",(optional, if
present, role is named by specific domain) "project_id" = "--id--",
(optional, if present, role is named by project) "service_id" =
"--id--",(optional, if present, role is named by service) "name":
"---role_name---",  (must be unique when combined with domain,
project and service ids) "scope": {"id": "---id---", (resource_id)
"type": "service | file | domain etc.", "endpoint":"---endpoint---"
} } }

regards

David




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

Re: [openstack-dev] [Nova][Cells] compute api and objects




On Monday, December 09, 2013 4:58:31 PM, Sam Morrison wrote:

Hi,

I’m trying to fix up some cells issues related to objects. Do all compute api 
methods take objects now?
cells is still sending DB objects for most methods (except start and stop) and 
I know there are more than that.

Eg. I know lock/unlock, shelve/unshelve take objects, I assume there are others 
if not all methods now?

Cheers,
Sam



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



I don't know the answer about cells, but posting a few bugs you've 
opened on the topic:


https://bugs.launchpad.net/nova/+bug/1251043
https://bugs.launchpad.net/nova/+bug/1257168

As for "Do all compute api methods take objects now?", I believe the 
answer is 'no'.  There are still some objects blueprints in the works.  
Here is a big one:


https://blueprints.launchpad.net/nova/+spec/compute-manager-objects

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [nova] ExtraSpecs format bug




On Thursday, December 05, 2013 1:38:45 PM, Costantino, Leandro I wrote:

Hi!

i am working on the Horizon 'side' of
https://bugs.launchpad.net/nova/+bug/1256119 , where basically
if you create a ExtraSpec key containing '/', then it cannot be
deleted anymore.

Is there any restriction about this?
Shall the format of the keys be limited to some specific format or any
combination should be valid?

For instance, heat use this pattern for stack names:
[a-zA-Z][a-zA-Z0-9_.-]* .


Regards
Leandro




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



My response when this was brought up in IRC:

(3:12:11 PM) mriedem: lcostantino: looks like flavorid is checked 
against a regex in the code
(3:12:11 PM) mriedem: 
https://github.com/openstack/nova/blob/master/nova/compute/flavors.py#L57

(3:12:18 PM) mriedem: would think you could do the same for extra specs

I don't see any specific rules for extra_specs in the API docs or 
validation happening in the code.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [heat] Stack preview

2013-12-10 Thread Zane Bitter

On 10/12/13 15:10, Randall Burt wrote:

On Dec 10, 2013, at 1:27 PM, Zane Bitter
wrote:

On 10/12/13 12:46, Richard Lee wrote:

Hey all,

We're working on a blueprint
that adds
the ability to preview what a given template+parameters would create in
terms of resources. We think this would provide significant value for
blueprint authors and for other heat users that want to see what
someone's template would create before actually launching resources (and
possibly having to pay for them).

+1 for this use case.

BTW AWS supports something similar, which we never bothered to implement in the
compatibility API. You might want to do some research on that as a starting
point:

http://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_EstimateTemplateCost.html

However the fact that we have pluggable resource types would make it very
difficult for us to do cost calculations inside Heat (and, in fact,
CloudFormation doesn't do that either, it just spits out a URL for their
separate calculator) - e.g. it's very hard to know which resources will create,
say, a Nova server unless they are all annotated in some way.

Are you thinking the API will simply return a list of resource types and
counts? e.g.:

{
"OS::Nova::Server": 2,
"OS::Cinder::Volume": 1,
"OS::Neutron::FloatingIP: 1
}

If so, +1 for that implementation too. Don't forget that you will have to
recurse through provider templates, which may not contain what they say on the
tin.

That sounds more than reasonable to me. I don't think we could begin to do any sort of
meaningful "cost" calculation without having to mostly punt to the service
provider anyway.

Yeah, exactly.

Although it occurs to me that we may want more detail than I originally
thought... e.g. knowing the flavor of any Nova servers is probably quite
important. Any ideas?

The first thing that comes to mind is that we could annotate resource
types with the list of parameters we want to group by. That would enable
something like:

{
"OS::Nova::Server":
[{config: {"flavor": m1.small}, count: 1},
{config: {"flavor": m3.large}, count: 1}],
"OS::Cinder::Volume":
[{config: {"size": 10}, count: 1}],
"OS::Neutron::FloatingIP":
[{config: {}, count: 1}],
}

- ZB

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

Re: [openstack-dev] OK to Use Flufl.enum

2013-12-10 Thread Adam Young

On 12/10/2013 11:43 AM, Jay Pipes wrote:

On 12/10/2013 11:26 AM, Alex Gaynor wrote:

 >>> from flufl.enum import IntEnum
 >>> class A(IntEnum):
...   a = 3
...
 >>> A.a

If the __repr__ is *really* the only value of IntEnum, I'm less than 
impressed.

-jay

On Tue, Dec 10, 2013 at 8:23 AM, Jay Pipes mailto:jaypi...@gmail.com>> wrote:

On 12/10/2013 09:55 AM, Adam Young wrote:

On 12/10/2013 05:24 AM, Flavio Percoco wrote:

On 09/12/13 19:45 -0800, Alex Gaynor wrote:

Would it make sense to use the `enum34` package, which
is a backport
of teh
enum package from py3k?

+1

This is what we were using in Marconi.

So... they seem to be doing something different from Flufl, as
IntEnums
are not working the same way.  I wonder if it is just update
lag, and
Flufl is the Upstream for the changes.

With only a change to the import and requirements, it builds and
runs,
but raises:

Traceback (most recent call last):
File "keystone/tests/test_revoke.__py", line 65, in
test_list_is_sorted
  valid_until=valid_until))
File "keystone/contrib/revoke/core.__py", line 74, in 
__init__

  setattr(self, k, v)
File "keystone/contrib/revoke/core.__py", line 82, in 
scope_type

  self._scope_type = ScopeType[value]
File
"/opt/stack/keystone/.venv/__lib/python2.7/site-packages/__enum/__init__.py",
line
352, in __getitem__
  return cls._member_map_[name]
KeyError: 1

This seems to say that you cannot access an IntEnum as an
integer, which
just seems broken.

What precisely is the benefit of an IntEnum? From the example in the
flufl.enum docs:

 >>> from flufl.enum import IntEnum
 >>> class Animals(IntEnum):
... ant = 1
... bee = 2
... cat = 3

 >>> int(Animals.bee)
2

Wow. That is so amazing. Thank goodness there is a library for that.

Oh wait... I can do exactly the same thing without flufl.enum or any
other library:

 >>> class Animals:
... ant = 1
... bee = 2
... cat = 3
...
 >>> int(Animals.bee)
2

The IntEnum is my new definition of the most worthless class ever
invented in the Python ecosystem -- taking the place of
zope.interface on my personal wall of worthlessness.

Best,
-jay

Jay,  It is the other way around:  How do you go from an integer to one 
of the pre-defined values?

I want 1, 2, 3, and 4 to be valid, but not 0 or 6, and each to map to 
both a Symbolic and a text based representation.

In the database store 1, 2, 3, 4

From the outside world I want to parse "user, project, domain"  etc.

from text parse "user, project, domain, trust"

Instead of having to to an explicit translation.  Doing it once is no 
big deal.  It is the need to do it for every enumerated field in 
Keystone that made me look into how to do a standardized enumeration.

_
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

___
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] Less compiler dependency

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/10/2013 07:04 PM, Jordan OMara wrote:

> 
> I'm a bit newer to this conversation than some, but I'm not sure
> what exactly the "NodeJS packaging nightmare" is? Isn't it already
> packaged for many major distributions?
> 
I might speak for Fedora here. We had a long history in getting
Node.js in. We have strict policies, what may be included and what is
prohibited.
- - bundling other libraries is forbidden
- - static linking is forbidden

For example node.js used to bundle httplib, libssl, and a few others
as well. For a long time, it was nearly impossible to build it using
dynamic linking.

It introduces its own packaging system, thus doesn't update packages
via the distribution repositories. Releases are quite often, even
major releases. Introducing major releases of a software in a release
cycle of a distribution is not wanted at all.

More details are in the original package review
https://bugzilla.redhat.com/show_bug.cgi?id=815018

Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSp4plAAoJEOnz8qQwcaIWFjQH/jFqEqTye52wRUXXxFmm2PUx
TzptBQr96At1JBUFyIAmOIZhvQKD15EGBeuEExxI6A7l+eFeKanvLkWhdyBgaXxj
G41mUz7RkGuFseyklped/gpfDrGY8h2xAwFwyo/eQoxz7hbmDIZNukXvc7LrS+t6
Irf4eVpv3XzP2mkhW7faLJWvYN4p+iy+vIhwpq7IZC5b9wnASXkasGRWZuq73wpQ
kB5qfOyLiI/SMlhCpaWWsvjf2UXNzl8os0c1bGSagwJRkwoG3kUcZ2f7XtBzKs4m
n+rakAdxUKCu76r/8QNAQACmDDNiLNLzJxdN8NPaC1nz8MRFFbM5HA1XSJOUM7I=
=KjEZ
-END PGP SIGNATURE-

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

Re: [openstack-dev] [qa] [Solum] [tempest] Use of pecan test framework in functional tests

2013-12-10 Thread David Kranz


On 12/10/2013 04:12 PM, Russell Bryant wrote:

On 12/10/2013 04:10 PM, Georgy Okrokvertskhov wrote:

Hi,

In Solum project we are currently creating tests environments for future
test. We split unit tests and functional tests in order to use tempest
framework from the beginning.

Tempest framework assumes that you run your service and test APi
endpoints by sending HTTP requests. Solum uses Pecan WSGI framework
which has its own test framework based on WebTest. This framework allows
to test application without sending actual HTTP traffic. It mocks low
level stuff related to transport but keeps all high level WSGI part as
it is a real life application\service.

There is a question to QA\Tempest teams, what do you think about using
pecan test framework in tempest for Pecan based applications?

I don't think that makes sense.  Then we're not using the code like it
would be used normally (via HTTP).

+1 There are other projects that do things like this as well in their 
unit tests. But Tempest is supposed to test the real API in a blackbox 
fashion and protect against unintentional api changes. It is also 
proposed to be used with refstack.


And to clarify, Tempest uses REST apis for the api stability tests. The 
scenario tests use the official python clients.


 -David

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

Re: [openstack-dev] [keystone] Service scoped role definition

2013-12-10 Thread David Chadwick

Hi Arvind

the granularity in naming can be as fine as required i.e. a naming
hierarchy can be as deep as required. So if there is a requirement for
individual endpoints to name their own roles, then the addition of
endpoint_id to the naming structure is fine.

regards

David

On 10/12/2013 16:42, Tiwari, Arvind wrote:
> Hi David,
> 
> I am cool with the proposal, just wanted to grad you attention on may
> question which I asked in my last email (which is below)
> 
> Q. what if two (or more) endpoints want to have same role_name for a
> service (nova.east.admin, nova.west.admin, nova.north.admin .)?
> 
> (Can we think of adding an optional endpoint_id attribute in role
> data model to allow such role, which is also needed to envision
> endpoint scoped tokens for our use case)
> 
> { "role": { "id": "76e72a", "domain_id" = "--id--",(optional, if
> present, role is named by specific domain) "project_id" = "--id--",
> (optional, if present, role is named by project) "service_id" =
> "--id--",(optional, if present, role is named by service) 
> "endpoint_id" = "--id--",(optional, if present, role is named by
> service) "name": "---role_name---",  (must be unique when combined
> with domain, project and service ids) "scope": {"id": "---id---",
> (resource_id) "type": "service | file | domain etc.", 
> "endpoint":"---endpoint---" } } }
> 
> For Adam's question " We are not linking role names to service id."
> (email attached) AT: These attributes are all optional and will not
> stop anyone how don't want to included service_id or (any other
> attribute) for role name uniqueness. So in particular deployment want
> to keep just the role name unique, this model will not restrict you.
> 
> Thoughts?
> 
> 
> 
> Thanks, Arvind
> 
> 
> 
> -Original Message- From: David Chadwick
> [mailto:d.w.chadw...@kent.ac.uk] Sent: Tuesday, December 10, 2013
> 1:30 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing
> List (not for usage questions) Cc: Henry Nash;
> dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev]
> [keystone] Service scoped role definition
> 
> How about the following which clearly separates naming and scoping 
> constraints
> 
> { "role": { "id": "76e72a", "domain_id" = "--id--",(optional, if
> present, role is named by specific domain) "project_id" = "--id--",
> (optional, if present, role is named by project) "service_id" =
> "--id--",(optional, if present, role is named by service) "name":
> "---role_name---",  (must be unique when combined with domain,
> project and service ids) "scope": {"id": "---id---", (resource_id) 
> "type": "service | file | domain etc.", "endpoint":"---endpoint---" 
> } } }
> 
> regards
> 
> David
> 

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

Re: [openstack-dev] [qa] [Solum] [tempest] Use of pecan test framework in functional tests

2013-12-10 Thread Ryan Petrello

My opinion is that there’s value in both.  Writing functional tests for Solum’s 
test suite using WebTest can be pretty useful for testing the API’s logic 
without having to involve HTTP (to e.g., call API endpoints with certain POST 
arguments and assert that certain mocked functions end up being called down the 
line).

When you involve Tempest, though, you’re generally pointing at a real HTTP 
server and testing for correctness, so using HTTP here makes sense (imo).

---
Ryan Petrello
Senior Developer, DreamHost
ryan.petre...@dreamhost.com

On Dec 10, 2013, at 4:12 PM, Russell Bryant  wrote:

> On 12/10/2013 04:10 PM, Georgy Okrokvertskhov wrote:
>> Hi,
>> 
>> In Solum project we are currently creating tests environments for future
>> test. We split unit tests and functional tests in order to use tempest
>> framework from the beginning. 
>> 
>> Tempest framework assumes that you run your service and test APi
>> endpoints by sending HTTP requests. Solum uses Pecan WSGI framework
>> which has its own test framework based on WebTest. This framework allows
>> to test application without sending actual HTTP traffic. It mocks low
>> level stuff related to transport but keeps all high level WSGI part as
>> it is a real life application\service.
>> 
>> There is a question to QA\Tempest teams, what do you think about using
>> pecan test framework in tempest for Pecan based applications?
> 
> I don't think that makes sense.  Then we're not using the code like it
> would be used normally (via HTTP).
> 
> -- 
> Russell Bryant
> 
> ___
> 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] Less compiler dependency

On 12/10/2013 06:06 PM, Thomas Goirand wrote:
> On 12/10/2013 11:41 PM, Jiri Tomasek wrote:
>> On 12/09/2013 12:47 PM, Jaromir Coufal wrote:
>>> So I would like to ask everybody, if we can reconsider this dependency
>>> and find some other alternative. I know we moved from nodejs, because
>>> it is packaging nightmare. But honestly, better to invest more into
>>> packaging than being blocked months waiting for features we need to
>>> get in.
> 
> I don't agree, because ... I'll be doing the work! :)
> 
> More seriously, we are much better off NodeJS, and keep everything in
> Python.
> 
This is awesome, thank you!

I totally agree, we're much better in supporting python packages.

Matthias


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

Re: [openstack-dev] [qa] [Solum] [tempest] Use of pecan test framework in functional tests

On 12/10/2013 04:10 PM, Georgy Okrokvertskhov wrote:
> Hi,
> 
> In Solum project we are currently creating tests environments for future
> test. We split unit tests and functional tests in order to use tempest
> framework from the beginning. 
> 
> Tempest framework assumes that you run your service and test APi
> endpoints by sending HTTP requests. Solum uses Pecan WSGI framework
> which has its own test framework based on WebTest. This framework allows
> to test application without sending actual HTTP traffic. It mocks low
> level stuff related to transport but keeps all high level WSGI part as
> it is a real life application\service.
> 
> There is a question to QA\Tempest teams, what do you think about using
> pecan test framework in tempest for Pecan based applications?

I don't think that makes sense.  Then we're not using the code like it
would be used normally (via HTTP).

-- 
Russell Bryant

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

[openstack-dev] [qa] [Solum] [tempest] Use of pecan test framework in functional tests

2013-12-10 Thread Georgy Okrokvertskhov

Hi,

In Solum project we are currently creating tests environments for future
test. We split unit tests and functional tests in order to use tempest
framework from the beginning.

Tempest framework assumes that you run your service and test APi endpoints
by sending HTTP requests. Solum uses Pecan WSGI framework which has its own
test framework based on WebTest. This framework allows to test application
without sending actual HTTP traffic. It mocks low level stuff related to
transport but keeps all high level WSGI part as it is a real life
application\service.

There is a question to QA\Tempest teams, what do you think about using
pecan test framework in tempest for Pecan based applications?

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

Re: [openstack-dev] [Horizon] Nominations to Horizon Core

2013-12-10 Thread Gabriel Hurley

+1 on Tatiana Mazur being added to Core.

I'm also okay with cleaning out the Core list. I considered doing it myself 
last cycle since none of those folks are involved anymore, but figured I'd 
leave them as a posthumous honor. ;-) I think now's a good time to trim it down.

Glad I didn't make the axe list,

- Gabriel

> -Original Message-
> From: Lyle, David [mailto:david.l...@hp.com]
> Sent: Tuesday, December 10, 2013 12:24 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Horizon] Nominations to Horizon Core
> 
> I would like to nominate Tatiana Mazur to Horizon Core.  Tatiana has been a
> significant code contributor in the last two releases, understands the code
> base well and has been doing a significant number of reviews for the last to
> milestones.
> 
> 
> Additionally, I'd like to remove some inactive members of Horizon-core who
> have been inactive since the early Grizzly release at the latest.
> Devin Carlen
> Jake Dahn
> Jesse Andrews
> Joe Heck
> John Postlethwait
> Paul McMillan
> Todd Willey
> Tres Henry
> paul-tashima
> sleepsonthefloor
> 
> 
> Please respond with a +1/-1 by this Friday.
> 
> -David Lyle
> 
> 
> 
> 
> ___
> 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] [heat] Stack preview

2013-12-10 Thread Steve Baker

On 12/11/2013 06:46 AM, Richard Lee wrote:
> Hey all,
>
> We're working on a blueprint
>  that adds
> the ability to preview what a given template+parameters would create
> in terms of resources.  We think this would provide significant value
> for blueprint authors and for other heat users that want to see what
> someone's template would create before actually launching resources
> (and possibly having to pay for them).
>
> We'd love to hear any thoughts regarding this feature
>
The REST call for this would have to be different to the current create
call, the user may be surprised when they do a preview call on an older
heat and it just goes ahead and launches the stack ;)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-10 Thread Clint Byrum

Excerpts from Dmitry Mescheryakov's message of 2013-12-10 12:37:37 -0800:
> >> What is the exact scenario you're trying to avoid?
> 
> It is DDoS attack on either transport (AMQP / ZeroMQ provider) or server
> (Salt / Our own self-written server). Looking at the design, it doesn't
> look like the attack could be somehow contained within a tenant it is
> coming from.
> 

We can push a tenant-specific route for the metadata server, and a tenant
specific endpoint for in-agent things. Still simpler than hypervisor-aware
guests. I haven't seen anybody ask for this yet, though I'm sure if they
run into these problems it will be the next logical step.

> In the current OpenStack design I see only one similarly vulnerable
> component - metadata server. Keeping that in mind, maybe I just
> overestimate the threat?
> 

Anything you expose to the users is "vulnerable". By using the localized
hypervisor scheme you're now making the compute node itself vulnerable.
Only now you're asking that an already complicated thing (nova-compute)
add another job, rate limiting.

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

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-10 Thread Ian Wells

On 10 December 2013 20:55, Clint Byrum  wrote:

> If it is just a network API, it works the same for everybody. This
> makes it simpler, and thus easier to scale out independently of compute
> hosts. It is also something we already support and can very easily expand
> by just adding a tiny bit of functionality to neutron-metadata-agent.
>
> In fact we can even push routes via DHCP to send agent traffic through
> a different neutron-metadata-agent, so I don't see any issue where we
> are piling anything on top of an overstressed single resource. We can
> have neutron route this traffic directly to the Heat API which hosts it,
> and that can be load balanced and etc. etc. What is the exact scenario
> you're trying to avoid?
>

You may be making even this harder than it needs to be.  You can create
multiple networks and attach machines to multiple networks.  Every point so
far has been 'why don't we use  as a backdoor into our VM without
affecting the VM in any other way' - why can't that just be one more
network interface set aside for whatever management  instructions are
appropriate?  And then what needs pushing into Neutron is nothing more
complex than strong port firewalling to prevent the slaves/minions talking
to each other.  If you absolutely must make the communication come from a
system agent and go to a VM, then that can be done by attaching the system
agent to the administrative network - from within the system agent, which
is the thing that needs this, rather than within Neutron, which doesn't
really care how you use its networks.  I prefer solutions where other tools
don't have to make you a special case.
-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Nominations to Horizon Core

On 12/10/2013 09:24 PM, Lyle, David wrote:
> I would like to nominate Tatiana Mazur to Horizon Core.  Tatiana has been a 
> significant code contributor in the last two releases, understands the code 
> base well and has been doing a significant number of reviews for the last to 
> milestones.
> 
> 
> Additionally, I'd like to remove some inactive members of Horizon-core who 
> have been inactive since the early Grizzly release at the latest.
> Devin Carlen
> Jake Dahn
> Jesse Andrews
> Joe Heck
> John Postlethwait
> Paul McMillan
> Todd Willey
> Tres Henry
> paul-tashima
> sleepsonthefloor
> 
+1
and +1.

Matthias


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

Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

2013-12-10 Thread Shiv Haris

+1

Will join via IRC or voice call



From: Gary Duan [mailto:gd...@varmour.com]
Sent: Tuesday, December 10, 2013 10:59 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

I will be joining IRC too.

Thanks,
Gary

On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana 
mailto:emag...@plumgrid.com>> wrote:
Also joining!
Looking forward to hearing your ideas folks!

Edgar

On 12/10/13 10:16 AM, "Nachi Ueno" mailto:na...@ntti3.com>> 
wrote:

>+1 ! I'll join.
>I'm also working on investigating how to use openstack gating system.
>(This document is still draft version)
>https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
>efQalL5Q0/edit#slide=id.p
>
>2013/12/10 Ivar Lazzaro mailto:i...@embrane.com>>:
>> +1 for 1700UTC Thursday on IRC
>>
>> -Original Message-
>> From: Kyle Mestery 
>> [mailto:mest...@siliconloons.com]
>> Sent: Tuesday, December 10, 2013 9:21 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
>>testing meeting
>>
>> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
>>mailto:anthony_ve...@cable.comcast.com>> 
>>wrote:
>>> -Original Message-
>>> From: Kyle Mestery 
>>> mailto:mest...@siliconloons.com>>
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>questions)"
>>> mailto:openstack-dev@lists.openstack.org>>
>>> Date: Tuesday, December 10, 2013 10:48
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> mailto:openstack-dev@lists.openstack.org>>
>>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
>>> meeting
>>>
 Last week I took an action item to organize a meeting for everyone
 who is doing third-party testing in Neutron for plugins, whether this
 is vendor or Open Source based. The idea is to share ideas around
 setups and any issues people hit. I'd like to set this meeting up for
 this week, Thursday at 1700UTC. I would also like to propose we make
 this a dial in meeting using the Infrastructure Conferencing bridges
 [1]. If this time works, I'll set something up and reply to this
 thread with the dial in information.
>>>
>>> +1 for the meeting time.  Any particular reason for voice over IRC?
>>>
>> We kind of decided that doing this over voice initially would be
>>expedient, but I am fine with moving to IRC. If I don't hear objections,
>>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
>>
>>

 Also, I've started a etherpad page [2] with information. It would be
 good for people to add information to this etherpad as well. I've
 coupled this pad with information around multi-node gate testing for
 Neutron as well, as I suspect most of the third-party testing will
 require multiple nodes as well.
>>>
>>> I'll start filling out our setup.  I have some questions around
>>> Third-Party Testing in particular, and look forward to this discussion.
>>>
>> Awesome, thanks Anthony!
>>

 Thanks!
 Kyle

 [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing
 [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest

 ___
 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 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] [ironic][qa] How will ironic tests run in tempest?

2013-12-10 Thread David Kranz

On 12/09/2013 01:37 PM, Devananda van der Veen wrote:
On Fri, Dec 6, 2013 at 2:13 PM, Clark Boylan > wrote:

On Fri, Dec 6, 2013 at 1:53 PM, David Kranz mailto:dkr...@redhat.com>> wrote:
> It's great that tempest tests for ironic have been submitted! I was
> reviewing https://review.openstack.org/#/c/48109/ and noticed
that the tests
> do not actually run. They are skipped because baremetal is not
enabled. This
> is not terribly surprising but we have had a policy in tempest
to only merge
> code that has demonstrated that it works. For services that
cannot run in
> the single-vm environment of the upstream gate we said there
could be a
> system running somewhere that would run them and report a result
to gerrit.
> Is there a plan for this, or to make an exception for ironic?
>
>  -David
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org

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

There is a change[0] to openstack-infra/config to add experimental
tempest jobs to test ironic. I think that change is close to being
ready, but I need to give it time for a proper review. Once in that
will allow you to test 48109 (in theory, not sure if all the bits will
just work). I don't think these tests fall under the cannot run in a
single vm environment umbrella, we should be able to test the
baremetal code via the pxe booting of VMs within the single VM
environment.

[0] https://review.openstack.org/#/c/53917/

Clark

We can test the ironic services, database, and the driver interfaces 
by using our "fake" driver within a single devstack VM today (I'm not 
sure the exercises for all of this have been written yet, but it's 
practical to test it). OTOH, I don't believe we can test a PXE deploy 
within a single VM today, and need to resume discussions with infra 
about this.

There are some other aspects of Ironic (IPMI, SOL access, any 
vendor-specific drivers) which we'll need real hardware to test 
because they can't effectively be virtualized. TripleO should cover 
some (much?) of those needs, once they are able to switch to using 
Ironic instead of nova-baremetal.

-Devananda
So it seems that the code in the submitted tempest tests can run in a 
regular job if devstack is configured to enable ironic, but that this 
cannot be the default. So I propose that we create a regular 
devstack+ironic job that will run in the ironic and tempest gates, and 
run just the ironic tests. When third-party bare-metal results can be 
reported for ironic, tempest can then accept tests that require 
bare-metal.  Does any one have a problem with this approach?

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

Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

2013-12-10 Thread Kyle Mestery

OK, looks like we've reached consensus. I've set the time and channel
to 12-12-2013 (Thursday), 1700UTC, on #openstack-meeting-alt.

Thanks!
Kyle

On Dec 10, 2013, at 12:59 PM, Gary Duan  wrote:

> I will be joining IRC too.
> 
> Thanks,
> Gary
> 
> 
> On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana  wrote:
> Also joining!
> Looking forward to hearing your ideas folks!
> 
> Edgar
> 
> On 12/10/13 10:16 AM, "Nachi Ueno"  wrote:
> 
> >+1 ! I'll join.
> >I'm also working on investigating how to use openstack gating system.
> >(This document is still draft version)
> >https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
> >efQalL5Q0/edit#slide=id.p
> >
> >2013/12/10 Ivar Lazzaro :
> >> +1 for 1700UTC Thursday on IRC
> >>
> >> -Original Message-
> >> From: Kyle Mestery [mailto:mest...@siliconloons.com]
> >> Sent: Tuesday, December 10, 2013 9:21 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
> >>testing meeting
> >>
> >> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
> >> wrote:
> >>> -Original Message-
> >>> From: Kyle Mestery 
> >>> Reply-To: "OpenStack Development Mailing List (not for usage
> >>>questions)"
> >>> 
> >>> Date: Tuesday, December 10, 2013 10:48
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> 
> >>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
> >>> meeting
> >>>
>  Last week I took an action item to organize a meeting for everyone
>  who is doing third-party testing in Neutron for plugins, whether this
>  is vendor or Open Source based. The idea is to share ideas around
>  setups and any issues people hit. I'd like to set this meeting up for
>  this week, Thursday at 1700UTC. I would also like to propose we make
>  this a dial in meeting using the Infrastructure Conferencing bridges
>  [1]. If this time works, I'll set something up and reply to this
>  thread with the dial in information.
> >>>
> >>> +1 for the meeting time.  Any particular reason for voice over IRC?
> >>>
> >> We kind of decided that doing this over voice initially would be
> >>expedient, but I am fine with moving to IRC. If I don't hear objections,
> >>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
> >>
> >>
> 
>  Also, I've started a etherpad page [2] with information. It would be
>  good for people to add information to this etherpad as well. I've
>  coupled this pad with information around multi-node gate testing for
>  Neutron as well, as I suspect most of the third-party testing will
>  require multiple nodes as well.
> >>>
> >>> I'll start filling out our setup.  I have some questions around
> >>> Third-Party Testing in particular, and look forward to this discussion.
> >>>
> >> Awesome, thanks Anthony!
> >>
> 
>  Thanks!
>  Kyle
> 
>  [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing
>  [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest
> 
>  ___
>  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 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] Unified Guest Agent proposal

2013-12-10 Thread Dmitry Mescheryakov

>> What is the exact scenario you're trying to avoid?

It is DDoS attack on either transport (AMQP / ZeroMQ provider) or server
(Salt / Our own self-written server). Looking at the design, it doesn't
look like the attack could be somehow contained within a tenant it is
coming from.

In the current OpenStack design I see only one similarly vulnerable
component - metadata server. Keeping that in mind, maybe I just
overestimate the threat?


2013/12/10 Clint Byrum 

> Excerpts from Dmitry Mescheryakov's message of 2013-12-10 11:08:58 -0800:
> > 2013/12/10 Clint Byrum 
> >
> > > Excerpts from Dmitry Mescheryakov's message of 2013-12-10 08:25:26
> -0800:
> > > > And one more thing,
> > > >
> > > > Sandy Walsh pointed to the client Rackspace developed and use - [1],
> [2].
> > > > Its design is somewhat different and can be expressed by the
> following
> > > > formulae:
> > > >
> > > > App -> Host (XenStore) <-> Guest Agent
> > > >
> > > > (taken from the wiki [3])
> > > >
> > > > It has an obvious disadvantage - it is hypervisor dependent and
> currently
> > > > implemented for Xen only. On the other hand such design should not
> have
> > > > shared facility vulnerability as Agent accesses the server not
> directly
> > > but
> > > > via XenStore (which AFAIU is compute node based).
> > > >
> > >
> > > I don't actually see any advantage to this approach. It seems to me
> that
> > > it would be simpler to expose and manage a single network protocol than
> > > it would be to expose hypervisor level communications for all
> hypervisors.
> > >
> >
> > I think the Rackspace agent design could be expanded as follows:
> >
> > Controller (Savanna/Trove) <-> AMQP/ZeroMQ <-> Agent on Compute host <->
> > XenStore <-> Guest Agent
> >
> > That is somewhat speculative because if I understood it correctly the
> > opened code covers only the second part of exchange:
> >
> > Python API / CMD interface <-> XenStore <-> Guest Agent
> >
> > Assuming I got it right:
> > While more complex, such design removes pressure from AMQP/ZeroMQ
> > providers: on the 'Agent on Compute' you can easily control the amount of
> > messages emitted by Guest with throttling. It is easy since such agent
> runs
> > on a compute host. In the worst case, if it is happened to be abused by a
> > guest, it affect this compute host only and not the whole segment of
> > OpenStack.
> >
>
> This still requires that we also write a backend to talk to the host
> for all virt drivers. It also means that any OS we haven't written an
> implementation for needs to be hypervisor-aware. That sounds like a
> never ending battle.
>
> If it is just a network API, it works the same for everybody. This
> makes it simpler, and thus easier to scale out independently of compute
> hosts. It is also something we already support and can very easily expand
> by just adding a tiny bit of functionality to neutron-metadata-agent.
>
> In fact we can even push routes via DHCP to send agent traffic through
> a different neutron-metadata-agent, so I don't see any issue where we
> are piling anything on top of an overstressed single resource. We can
> have neutron route this traffic directly to the Heat API which hosts it,
> and that can be load balanced and etc. etc. What is the exact scenario
> you're trying to avoid?
>
> ___
> 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] Nominations to Horizon Core

2013-12-10 Thread Tihomir Trifonov

+1 for Tatiana.


On Tue, Dec 10, 2013 at 10:24 PM, Lyle, David  wrote:

> I would like to nominate Tatiana Mazur to Horizon Core.  Tatiana has been
> a significant code contributor in the last two releases, understands the
> code base well and has been doing a significant number of reviews for the
> last to milestones.
>
>
> Additionally, I'd like to remove some inactive members of Horizon-core who
> have been inactive since the early Grizzly release at the latest.
> Devin Carlen
> Jake Dahn
> Jesse Andrews
> Joe Heck
> John Postlethwait
> Paul McMillan
> Todd Willey
> Tres Henry
> paul-tashima
> sleepsonthefloor
>
>
> Please respond with a +1/-1 by this Friday.
>
> -David Lyle
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [Horizon] Nominations to Horizon Core

2013-12-10 Thread Lyle, David

I would like to nominate Tatiana Mazur to Horizon Core.  Tatiana has been a 
significant code contributor in the last two releases, understands the code 
base well and has been doing a significant number of reviews for the last to 
milestones.


Additionally, I'd like to remove some inactive members of Horizon-core who have 
been inactive since the early Grizzly release at the latest.
Devin Carlen
Jake Dahn
Jesse Andrews
Joe Heck
John Postlethwait
Paul McMillan
Todd Willey
Tres Henry
paul-tashima
sleepsonthefloor


Please respond with a +1/-1 by this Friday.

-David Lyle




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

Re: [openstack-dev] [heat] Stack convergence first steps

2013-12-10 Thread Randall Burt

On Dec 10, 2013, at 1:03 PM, Anderson Mesquita 
mailto:anderson...@thoughtworks.com>>
 wrote:

To try and keep this conversation moving forward, is it safe to say that we at 
least need to change the current status attribute to something like 
action_status? And the same with status_reason being changed to 
action_status_reason? Does anybody see a reason why we shouldn't go this way, 
since it's really what status currently refers to?

IMO, this sort of change should be proposed for the v2 api, since there are 
already expectations in the v1 api as to what these things mean. For v1, I 
wouldn't be opposed to adding a synthetic resource_state attribute that 
reflects the actual "status" of the underlying resource (ACTIVE, RESIZE, etc).

2013/12/8 Mitsuru Kanabuchi 
mailto:kanabuchi.mits...@po.ntts.co.jp>>

On Thu, 5 Dec 2013 22:13:18 -0600
Christopher Armstrong 
mailto:chris.armstr...@rackspace.com>> wrote:

> On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt 
> mailto:randall.b...@rackspace.com>>wrote:
>
> >  On Dec 5, 2013, at 6:25 PM, Christopher Armstrong <
> > chris.armstr...@rackspace.com>
> >  wrote:
> >
> >   On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita <
> > anderson...@thoughtworks.com> wrote:
> >
> >> Hey stackers,
> >>
> >> We've been working towards making stack convergence (
> >> https://blueprints.launchpad.net/heat/+spec/stack-convergence) one step
> >> closer to being ready at a time.  After the first patch was submitted we
> >> got positive feedback on it as well as some good suggestions as to how to
> >> move it forward.
> >>
> >> The first step (https://blueprints.launchpad.net/heat/+spec/stack-check)
> >> is to get all the statuses back from the real world resources and update
> >> our stacks accordingly so that we'll be able to move on to the next step:
> >> converge it to the desired state, fixing any errors that may have happened.
> >>
> >> We just submitted another WiP for review, and as we were doing it, a few
> >> questions were raised and we'd like to get everybody's input on them. Our
> >> main concern is around the use and purpose of the `status` of a
> >> stack/resource.  `status` currently appears to represent the status of the
> >> last action taken, and it seems that we may need to repurpose it or
> >> possibly create something else to represent a stack's "health" (i.e.
> >> everything is up and running as expected, something smells fishy, something
> >> broke, stack's is doomed).  We described this thoroughly here:
> >> https://etherpad.openstack.org/p/heat-convergence
> >>
> >> Any thoughts?
> >>
> >> Cheers,
> >>
> >>
> >  I think a lot of OpenStack projects use "status" fields as "status of
> > the most recent operation", and I think it's totally wrong. "status" should
> > be a known state of the _object_, not an action, and if we need statuses
> > for operations, then those operations should be addressable REST objects.
> > Of course there are cases where object status should be updated to reflect
> > an operating status if it's a completely exclusive operation (BUILDING and
> > DELETING make sense, for example).
> >
> >  Actually, I think most projects are the opposite where "status" means
> > "what's the state of the resource" (Nova, Trove, Cinder, etc), whereas Heat
> > uses status as the state of the last operation. Probably wouldn't be too
> > terrible to have a new "state" for stacks and their resources then perhaps
> > deprecate and use "status" in the accepted way in the v2 API?
>
> Well, my point is that it's done inconsistently. Yes, it's mostly used as
> an object status, but nova for example uses it as an operation status for
> things like resize.

Nova's status of in resize is "RESIZE" and "VERITY_RESIZE".
This status means "Currently, Instance is ACTIVE and resize in progress".
I think Heat can assume resource status is "ACTIVE" in this case.

Thus, several status that contain operation status have to map resource(object)
status. However in my impression, a status that should assume another status
isn't a lot.

In my opinion, status mapping table is reasonable in present time.

Regards

--
Mitsuru Kanabuchi


___
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] Recruiting developers for Neutron API tests in Tempest

2013-12-10 Thread Miguel Lavalle

For the Icehouse cycle, the OpenStack community is undertaking a focused
effort to strengthen the suite of Tempest API tests for Neutron. If you are
interested on contributing to this effort, please go to
https://etherpad.openstack.org/p/icehouse-summit-qa-neutron. Please scroll
down to the "API tests gap analysis" section and select the topics you want
to contribute to.

Helping to develop Tempest tests (particularly API tests) is an excellent
way for new contributors to learn Neutron. To get you going, we have
developed a detailed how to guide that can by found here:
https://wiki.openstack.org/wiki/Neutron/TempestAPITests

Should you need further assistance, please contact mlavalle in the
#openstack-neutron or #openstack-qa channels in irc.freenode.net
___
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 December 10th at 19:00 UTC

2013-12-10 Thread Elizabeth Krumbach Joseph

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

Meeting minutes and log:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-12-10-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-12-10-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-12-10-19.02.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

Re: [openstack-dev] [heat] Stack preview

2013-12-10 Thread Randall Burt

On Dec 10, 2013, at 1:27 PM, Zane Bitter 
 wrote:

> On 10/12/13 12:46, Richard Lee wrote:
>> Hey all,
>> 
>> We're working on a blueprint
>>  that adds
>> the ability to preview what a given template+parameters would create in
>> terms of resources.  We think this would provide significant value for
>> blueprint authors and for other heat users that want to see what
>> someone's template would create before actually launching resources (and
>> possibly having to pay for them).
> 
> +1 for this use case.
> 
> BTW AWS supports something similar, which we never bothered to implement in 
> the compatibility API. You might want to do some research on that as a 
> starting point:
> 
> http://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_EstimateTemplateCost.html
> 
> However the fact that we have pluggable resource types would make it very 
> difficult for us to do cost calculations inside Heat (and, in fact, 
> CloudFormation doesn't do that either, it just spits out a URL for their 
> separate calculator) - e.g. it's very hard to know which resources will 
> create, say, a Nova server unless they are all annotated in some way.
> 
> Are you thinking the API will simply return a list of resource types and 
> counts? e.g.:
> 
> {
>   "OS::Nova::Server": 2,
>   "OS::Cinder::Volume": 1,
>   "OS::Neutron::FloatingIP: 1
> }
> 
> If so, +1 for that implementation too. Don't forget that you will have to 
> recurse through provider templates, which may not contain what they say on 
> the tin.

That sounds more than reasonable to me. I don't think we could begin to do any 
sort of meaningful "cost" calculation without having to mostly punt to the 
service provider anyway.

> 
> cheers,
> Zane.
> 
> ___
> 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] Unified Guest Agent proposal

2013-12-10 Thread Clint Byrum

Excerpts from Dmitry Mescheryakov's message of 2013-12-10 11:08:58 -0800:
> 2013/12/10 Clint Byrum 
> 
> > Excerpts from Dmitry Mescheryakov's message of 2013-12-10 08:25:26 -0800:
> > > And one more thing,
> > >
> > > Sandy Walsh pointed to the client Rackspace developed and use - [1], [2].
> > > Its design is somewhat different and can be expressed by the following
> > > formulae:
> > >
> > > App -> Host (XenStore) <-> Guest Agent
> > >
> > > (taken from the wiki [3])
> > >
> > > It has an obvious disadvantage - it is hypervisor dependent and currently
> > > implemented for Xen only. On the other hand such design should not have
> > > shared facility vulnerability as Agent accesses the server not directly
> > but
> > > via XenStore (which AFAIU is compute node based).
> > >
> >
> > I don't actually see any advantage to this approach. It seems to me that
> > it would be simpler to expose and manage a single network protocol than
> > it would be to expose hypervisor level communications for all hypervisors.
> >
> 
> I think the Rackspace agent design could be expanded as follows:
> 
> Controller (Savanna/Trove) <-> AMQP/ZeroMQ <-> Agent on Compute host <->
> XenStore <-> Guest Agent
> 
> That is somewhat speculative because if I understood it correctly the
> opened code covers only the second part of exchange:
> 
> Python API / CMD interface <-> XenStore <-> Guest Agent
> 
> Assuming I got it right:
> While more complex, such design removes pressure from AMQP/ZeroMQ
> providers: on the 'Agent on Compute' you can easily control the amount of
> messages emitted by Guest with throttling. It is easy since such agent runs
> on a compute host. In the worst case, if it is happened to be abused by a
> guest, it affect this compute host only and not the whole segment of
> OpenStack.
> 

This still requires that we also write a backend to talk to the host
for all virt drivers. It also means that any OS we haven't written an
implementation for needs to be hypervisor-aware. That sounds like a
never ending battle.

If it is just a network API, it works the same for everybody. This
makes it simpler, and thus easier to scale out independently of compute
hosts. It is also something we already support and can very easily expand
by just adding a tiny bit of functionality to neutron-metadata-agent.

In fact we can even push routes via DHCP to send agent traffic through
a different neutron-metadata-agent, so I don't see any issue where we
are piling anything on top of an overstressed single resource. We can
have neutron route this traffic directly to the Heat API which hosts it,
and that can be load balanced and etc. etc. What is the exact scenario
you're trying to avoid?

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

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-10 Thread Joe Gordon

On Dec 10, 2013 7:00 PM, "Clint Byrum"  wrote:
>
> Excerpts from Dmitry Mescheryakov's message of 2013-12-10 08:15:15 -0800:
> > Guys,
> >
> > I see two major trends in the thread:
> >
> >  * use Salt
> >  * write our own solution with architecture similar to Salt or
MCollective
> >
> > There were points raised pro and contra both solutions. But I have a
> > concern which I believe was not covered yet. Both solutions use either
> > ZeroMQ or message queues (AMQP/STOMP) as a transport. The thing is
there is
> > going to be a shared facility between all the tenants. And unlike all
other
> > OpenStack services, this facility will be directly accessible from VMs,
> > which leaves tenants very vulnerable to each other. Harm the facility
from
> > your VM, and the whole Region/Cell/Availability Zone will be left out of
> > service.
> >
> > Do you think that is solvable, or maybe I overestimate the threat?
> >
>
> I think Salt would be thrilled if we tested and improved its resiliency
> to abuse. We're going to have to do that with whatever we expose to VMs.

+1 to not reinventing the wheel, and using a friendly ecosystem tool that
we can improve as needed.

>
> ___
> 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] [Heat] workflow for fixes involving numerous changes

2013-12-10 Thread Zane Bitter


On 10/12/13 13:34, Clint Byrum wrote:

Excerpts from Steven Hardy's message of 2013-12-10 03:00:26 -0800:

On Tue, Dec 10, 2013 at 11:45:11AM +0200, Pavlo Shchelokovskyy wrote:

- wouldn't it be better to keep all these changes in one bug and fix all
misuses per file basis (with one file per patch-set for example)? It seems
to me it would be easier to review in this way.


One file per patch is not a good idea IMO, I think the review burden is
minimised if you make sure that each commit just contains the exact same
change to many files, then it's quick to click through them all and confirm
all looks OK.


+1


FWIW I think I would have picked the other way. TBH any patch that 
contains dozens of lines of changes to 80+ files might as well not be 
reviewed at all, because the chance of any errors being spotted 
approaches zero. Hopefully everything will be done in an automated 
manner to minimise the possibility of that, and these are the unit tests 
so you'd expect a higher than usual chance of the gate failing if there 
is a problem. A change that touches just about every unit test file is 
also practically guaranteed to conflict with a high proportion of other 
patches going in, so it will be interesting to see if this makes it or 
gets stuck in an infinite rebase loop. By all means give it a go though :)


cheers,
Zane.

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

Re: [openstack-dev] [heat] Stack preview

2013-12-10 Thread Zane Bitter

On 10/12/13 12:46, Richard Lee wrote:

Hey all,

+1 for this use case.

BTW AWS supports something similar, which we never bothered to implement
in the compatibility API. You might want to do some research on that as
a starting point:

http://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_EstimateTemplateCost.html

However the fact that we have pluggable resource types would make it
very difficult for us to do cost calculations inside Heat (and, in fact,
CloudFormation doesn't do that either, it just spits out a URL for their
separate calculator) - e.g. it's very hard to know which resources will
create, say, a Nova server unless they are all annotated in some way.

Are you thinking the API will simply return a list of resource types and
counts? e.g.:

{
"OS::Nova::Server": 2,
"OS::Cinder::Volume": 1,
"OS::Neutron::FloatingIP: 1
}

If so, +1 for that implementation too. Don't forget that you will have
to recurse through provider templates, which may not contain what they
say on the tin.

cheers,
Zane.

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

[openstack-dev] [Nova] icehouse-2 blueprint deadline

Greetings,

We have a lot of blueprints targeted to icehouse-2 [1] that are still
under review.  The blueprints that do not have a priority are still
under review.  We need a deadline for blueprints to be finalized for
this milestone.  I propose that deadline to be Thursday, December 19.

Any blueprints that have not been approved at that point will be moved
to the icehouse-3 milestone.

If you have an icehouse-2 blueprint, please check its status.
Specifically, check the "Definition" field of the blueprint.  Here is
what it means:

  Approved - blueprint has been approved for this milestone

  Pending Approval - waiting on a blueprint reviewer to follow up

  Review - waiting on the blueprint submitter to provide more
information.  Change to "Pending Approval" once you feel that the
information has been provided.

  Drafting - Details still being written up by the submitter, so the
blueprint has not been reviewed.  Update to "Pending Approval" when ready.

  Discussion - Blueprint approval hinges on the result of a discussion.
 The blueprint should contain a link to a mailing list thread discussing
the blueprint.  Once you feel the discussion has concluded and more
review is needed, update it to "Pending Approval".

  New - new blueprints that have not been triaged yet.  A blueprint
reviewer (member of nova-drivers) will triage it soon.


After this deadline, anything left in "Review, Drafting, or Discussion"
state will be moved to icehouse-3.

Thanks,

[1] https://launchpad.net/nova/+milestone/icehouse-2

-- 
Russell Bryant

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

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-10 Thread Dmitry Mescheryakov

2013/12/10 Clint Byrum 

> Excerpts from Dmitry Mescheryakov's message of 2013-12-10 08:25:26 -0800:
> > And one more thing,
> >
> > Sandy Walsh pointed to the client Rackspace developed and use - [1], [2].
> > Its design is somewhat different and can be expressed by the following
> > formulae:
> >
> > App -> Host (XenStore) <-> Guest Agent
> >
> > (taken from the wiki [3])
> >
> > It has an obvious disadvantage - it is hypervisor dependent and currently
> > implemented for Xen only. On the other hand such design should not have
> > shared facility vulnerability as Agent accesses the server not directly
> but
> > via XenStore (which AFAIU is compute node based).
> >
>
> I don't actually see any advantage to this approach. It seems to me that
> it would be simpler to expose and manage a single network protocol than
> it would be to expose hypervisor level communications for all hypervisors.
>

I think the Rackspace agent design could be expanded as follows:

Controller (Savanna/Trove) <-> AMQP/ZeroMQ <-> Agent on Compute host <->
XenStore <-> Guest Agent

That is somewhat speculative because if I understood it correctly the
opened code covers only the second part of exchange:

Python API / CMD interface <-> XenStore <-> Guest Agent

Assuming I got it right:
While more complex, such design removes pressure from AMQP/ZeroMQ
providers: on the 'Agent on Compute' you can easily control the amount of
messages emitted by Guest with throttling. It is easy since such agent runs
on a compute host. In the worst case, if it is happened to be abused by a
guest, it affect this compute host only and not the whole segment of
OpenStack.



> ___
> 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] [heat] Stack convergence first steps

2013-12-10 Thread Anderson Mesquita

To try and keep this conversation moving forward, is it safe to say that we
at least need to change the current status attribute to something like
action_status? And the same with status_reason being changed to
action_status_reason? Does anybody see a reason why we shouldn't go this
way, since it's really what status currently refers to?


2013/12/8 Mitsuru Kanabuchi 

>
> On Thu, 5 Dec 2013 22:13:18 -0600
> Christopher Armstrong  wrote:
>
> > On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt  >wrote:
> >
> > >  On Dec 5, 2013, at 6:25 PM, Christopher Armstrong <
> > > chris.armstr...@rackspace.com>
> > >  wrote:
> > >
> > >   On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita <
> > > anderson...@thoughtworks.com> wrote:
> > >
> > >> Hey stackers,
> > >>
> > >> We've been working towards making stack convergence (
> > >> https://blueprints.launchpad.net/heat/+spec/stack-convergence) one
> step
> > >> closer to being ready at a time.  After the first patch was submitted
> we
> > >> got positive feedback on it as well as some good suggestions as to
> how to
> > >> move it forward.
> > >>
> > >> The first step (
> https://blueprints.launchpad.net/heat/+spec/stack-check)
> > >> is to get all the statuses back from the real world resources and
> update
> > >> our stacks accordingly so that we'll be able to move on to the next
> step:
> > >> converge it to the desired state, fixing any errors that may have
> happened.
> > >>
> > >> We just submitted another WiP for review, and as we were doing it, a
> few
> > >> questions were raised and we'd like to get everybody's input on them.
> Our
> > >> main concern is around the use and purpose of the `status` of a
> > >> stack/resource.  `status` currently appears to represent the status
> of the
> > >> last action taken, and it seems that we may need to repurpose it or
> > >> possibly create something else to represent a stack's "health" (i.e.
> > >> everything is up and running as expected, something smells fishy,
> something
> > >> broke, stack's is doomed).  We described this thoroughly here:
> > >> https://etherpad.openstack.org/p/heat-convergence
> > >>
> > >> Any thoughts?
> > >>
> > >> Cheers,
> > >>
> > >>
> > >  I think a lot of OpenStack projects use "status" fields as "status of
> > > the most recent operation", and I think it's totally wrong. "status"
> should
> > > be a known state of the _object_, not an action, and if we need
> statuses
> > > for operations, then those operations should be addressable REST
> objects.
> > > Of course there are cases where object status should be updated to
> reflect
> > > an operating status if it's a completely exclusive operation (BUILDING
> and
> > > DELETING make sense, for example).
> > >
> > >  Actually, I think most projects are the opposite where "status" means
> > > "what's the state of the resource" (Nova, Trove, Cinder, etc), whereas
> Heat
> > > uses status as the state of the last operation. Probably wouldn't be
> too
> > > terrible to have a new "state" for stacks and their resources then
> perhaps
> > > deprecate and use "status" in the accepted way in the v2 API?
> >
> > Well, my point is that it's done inconsistently. Yes, it's mostly used as
> > an object status, but nova for example uses it as an operation status for
> > things like resize.
>
> Nova's status of in resize is "RESIZE" and "VERITY_RESIZE".
> This status means "Currently, Instance is ACTIVE and resize in progress".
> I think Heat can assume resource status is "ACTIVE" in this case.
>
> Thus, several status that contain operation status have to map
> resource(object)
> status. However in my impression, a status that should assume another
> status
> isn't a lot.
>
> In my opinion, status mapping table is reasonable in present time.
>
> Regards
>
> --
> Mitsuru Kanabuchi
>
>
> ___
> 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] Third party Neutron plugin testingmeeting

2013-12-10 Thread Gary Duan

I will be joining IRC too.

Thanks,
Gary


On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana  wrote:

> Also joining!
> Looking forward to hearing your ideas folks!
>
> Edgar
>
> On 12/10/13 10:16 AM, "Nachi Ueno"  wrote:
>
> >+1 ! I'll join.
> >I'm also working on investigating how to use openstack gating system.
> >(This document is still draft version)
> >
> https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
> >efQalL5Q0/edit#slide=id.p
> >
> >2013/12/10 Ivar Lazzaro :
> >> +1 for 1700UTC Thursday on IRC
> >>
> >> -Original Message-
> >> From: Kyle Mestery [mailto:mest...@siliconloons.com]
> >> Sent: Tuesday, December 10, 2013 9:21 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
> >>testing meeting
> >>
> >> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
> >> wrote:
> >>> -Original Message-
> >>> From: Kyle Mestery 
> >>> Reply-To: "OpenStack Development Mailing List (not for usage
> >>>questions)"
> >>> 
> >>> Date: Tuesday, December 10, 2013 10:48
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> 
> >>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
> >>> meeting
> >>>
>  Last week I took an action item to organize a meeting for everyone
>  who is doing third-party testing in Neutron for plugins, whether this
>  is vendor or Open Source based. The idea is to share ideas around
>  setups and any issues people hit. I'd like to set this meeting up for
>  this week, Thursday at 1700UTC. I would also like to propose we make
>  this a dial in meeting using the Infrastructure Conferencing bridges
>  [1]. If this time works, I'll set something up and reply to this
>  thread with the dial in information.
> >>>
> >>> +1 for the meeting time.  Any particular reason for voice over IRC?
> >>>
> >> We kind of decided that doing this over voice initially would be
> >>expedient, but I am fine with moving to IRC. If I don't hear objections,
> >>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
> >>
> >>
> 
>  Also, I've started a etherpad page [2] with information. It would be
>  good for people to add information to this etherpad as well. I've
>  coupled this pad with information around multi-node gate testing for
>  Neutron as well, as I suspect most of the third-party testing will
>  require multiple nodes as well.
> >>>
> >>> I'll start filling out our setup.  I have some questions around
> >>> Third-Party Testing in particular, and look forward to this discussion.
> >>>
> >> Awesome, thanks Anthony!
> >>
> 
>  Thanks!
>  Kyle
> 
>  [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing
>  [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest
> 
>  ___
>  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 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] [TripleO][Tuskar] Icehouse Requirements

2013-12-10 Thread Jay Dobies


Thanks for the explanation!

I'm going to claim that the thread revolves around two main areas of 
disagreement.  Then I'm going
to propose a way through:

a) Manual Node Assignment

I think that everyone is agreed that automated node assignment through 
nova-scheduler is by
far the most ideal case; there's no disagreement there.

The disagreement comes from whether we need manual node assignment or not.  I 
would argue that we
need to step back and take a look at the real use case: heterogeneous nodes.  
If there are literally
no characteristics that differentiate nodes A and B, then why do we care which 
gets used for what?  Why
do we need to manually assign one?


This is a better way of verbalizing my concerns. I suspect there are 
going to be quite a few heterogeneous environments built from legacy 
pieces in the near term and fewer built from the ground up with all new 
matching hotness.


On the other side of it, instead of handling legacy hardware I was 
worried about the new hotness (not sure why I keep using that term) 
specialized for a purpose. This is exactly what Robert described in his 
GPU example. I think his explanation of how to use the scheduler to 
accommodate that makes a lot of sense, so I'm much less behind the idea 
of a strict manual assignment than I previously was.



If we can agree on that, then I think it would be sufficient to say that we 
want a mechanism to allow
UI users to deal with heterogeneous nodes, and that mechanism must use 
nova-scheduler.  In my mind,
that's what resource classes and node profiles are intended for.

One possible objection might be: nova scheduler doesn't have the appropriate 
filter that we need to
separate out two nodes.  In that case, I would say that needs to be taken up 
with nova developers.


b) Terminology

It feels a bit like some of the disagreement come from people using different 
words for the same thing.
For example, the wireframes already details a UI where Robert's roles come 
first, but I think that message
was confused because I mentioned "node types" in the requirements.

So could we come to some agreement on what the most exact terminology would be? 
 I've listed some examples below,
but I'm sure there are more.

node type | role
management node | ?
resource node | ?
unallocated | available | undeployed
create a node distribution | size the deployment
resource classes | ?
node profiles | ?

Mainn

- Original Message -

On 10 December 2013 09:55, Tzu-Mainn Chen  wrote:

* created as part of undercloud install process



By that note I meant, that Nodes are not resources, Resource instances
run on Nodes. Nodes are the generic pool of hardware we can deploy
things onto.


I don't think "resource nodes" is intended to imply that nodes are
resources; rather, it's supposed to
indicate that it's a node where a resource instance runs.  It's supposed to
separate it from "management node"
and "unallocated node".


So the question is are we looking at /nodes/ that have a /current
role/, or are we looking at /roles/ that have some /current nodes/.

My contention is that the role is the interesting thing, and the nodes
is the incidental thing. That is, as a sysadmin, my hierarchy of
concerns is something like:
  A: are all services running
  B: are any of them in a degraded state where I need to take prompt
action to prevent a service outage [might mean many things: - software
update/disk space criticals/a machine failed and we need to scale the
cluster back up/too much load]
  C: are there any planned changes I need to make [new software deploy,
feature request from user, replacing a faulty machine]
  D: are there long term issues sneaking up on me [capacity planning,
machine obsolescence]

If we take /nodes/ as the interesting thing, and what they are doing
right now as the incidental thing, it's much harder to map that onto
the sysadmin concerns. If we start with /roles/ then can answer:
  A: by showing the list of roles and the summary stats (how many
machines, service status aggregate), role level alerts (e.g. nova-api
is not responding)
  B: by showing the list of roles and more detailed stats (overall
load, response times of services, tickets against services
  and a list of in trouble instances in each role - instances with
alerts against them - low disk, overload, failed service,
early-detection alerts from hardware
  C: probably out of our remit for now in the general case, but we need
to enable some things here like replacing faulty machines
  D: by looking at trend graphs for roles (not machines), but also by
looking at the hardware in aggregate - breakdown by age of machines,
summary data for tickets filed against instances that were deployed to
a particular machine

C: and D: are (F) category work, but for all but the very last thing,
it seems clear how to approach this from a roles perspective.

I've tried to approach this using /nodes/ as the starting point, and
after two terrible drafts I've deleted th

Re: [openstack-dev] [keystone] Service scoped role definition

2013-12-10 Thread Adam Young


On 12/10/2013 11:42 AM, Tiwari, Arvind wrote:

Hi David,

I am cool with the proposal, just wanted to grad you attention on may question 
which I asked in my last email (which is below)

Q. what if two (or more) endpoints want to have same role_name for a service 
(nova.east.admin, nova.west.admin, nova.north.admin .)?

(Can we think of adding an optional endpoint_id attribute in role data model to 
allow such role, which is also needed to envision endpoint scoped tokens for 
our use case)


You are over designing.  Services and Endpoints have no business in this 
design.  That is enforcement, not definition or assignment of the 
Roles.  We need a clean namespace, and mixing services and endpoints in 
there adds no benefit.




{
  "role": {
   "id": "76e72a",
   "domain_id" = "--id--",(optional, if present, role is named by 
specific domain)
   "project_id" = "--id--",(optional, if present, role is named by 
project)
   "service_id" = "--id--",(optional, if present, role is named by 
service)
   "endpoint_id" = "--id--",(optional, if present, role is named by 
service)
   "name": "---role_name---",  (must be unique when combined with domain, 
project and service ids)
   "scope": {"id": "---id---", (resource_id)
  "type": "service | file | domain etc.",
  "endpoint":"---endpoint---"
}
 }
  }

For Adam's question " We are not linking role names to service id." (email 
attached)
AT: These attributes are all optional and will not stop anyone how don't want 
to included service_id or (any other attribute) for role name uniqueness. So in 
particular deployment want to keep just the role name unique, this model will 
not restrict you.

Thoughts?



Thanks,
Arvind



-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Tuesday, December 10, 2013 1:30 AM
To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for 
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

How about the following which clearly separates naming and scoping
constraints

  {
  "role": {
   "id": "76e72a",
   "domain_id" = "--id--",(optional, if present, role is named by 
specific domain)
   "project_id" = "--id--",(optional, if present, role is named by 
project)
   "service_id" = "--id--",(optional, if present, role is named by 
service)
   "name": "---role_name---",  (must be unique when combined with domain, 
project and service ids)
   "scope": {"id": "---id---", (resource_id)
  "type": "service | file | domain etc.",
  "endpoint":"---endpoint---"
}
 }
  }

regards

David



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

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-10 Thread Tzu-Mainn Chen

Thanks for the reply!  Comments in-line:

> > The disagreement comes from whether we need manual node assignment or not.
> > I would argue that we
> > need to step back and take a look at the real use case: heterogeneous
> > nodes.  If there are literally
> > no characteristics that differentiate nodes A and B, then why do we care
> > which gets used for what?  Why
> > do we need to manually assign one?
> 
> Ideally, we don't. But with this approach we would take out the
> possibility to change something or decide something from the user.
> 
> The 'easiest' way is to support bigger companies with huge deployments,
> tailored infrastructure, everything connected properly.
> 
> But there are tons of companies/users who are running on old
> heterogeneous hardware. Very likely even more than the number of
> companies having already mentioned large deployments. And giving them
> only the way of 'setting up rules' in order to get the service on the
> node - this type of user is not gonna use our deployment system.
> 
> Somebody might argue - why do we care? If user doesn't like TripleO
> paradigm, he shouldn't use the UI and should use another tool. But the
> UI is not only about TripleO. Yes, it is underlying concept, but we are
> working on future *official* OpenStack deployment tool. We should care
> to enable people to deploy OpenStack - large/small scale,
> homo/heterogeneous hardware, typical or a bit more specific use-cases.

I think this is a very important clarification, and I'm glad you made it.  It 
sounds
like manual assignment is actually a sub-requirement, and the feature you're 
arguing
for is: supporting non-TripleO deployments.

That might be a worthy goal, but I think it's a distraction for the Icehouse 
timeframe.
Each new deployment strategy requires not only a new UI, but different 
deployment
architectures that could have very little common with each other.  Designing 
them all
to work in the same space is a recipe for disaster, a convoluted gnarl of code 
that
doesn't do any one thing particularly well.  To use an analogy: there's a 
reason why
no one makes a flying boat car.

I'm going to strongly advocate that for Icehouse, we focus exclusively on large 
scale
TripleO deployments, working to make that UI and architecture as sturdy as we 
can.  Future
deployment strategies should be discussed in the future, and if they're not 
TripleO based,
they should be discussed with the proper OpenStack group.


> As an underlying paradigm of how to install cloud - awesome idea,
> awesome concept, it works. But user doesn't care about how it is being
> deployed for him. He cares about getting what he wants/needs. And we
> shouldn't go that far that we violently force him to treat his
> infrastructure as cloud. I believe that possibility to change/control -
> if needed - is very important and we should care.
> 
> And what is key for us is to *enable* users - not to prevent them from
> using our deployment tool, because it doesn't work for their requirements.
> 
> 
> > If we can agree on that, then I think it would be sufficient to say that we
> > want a mechanism to allow
> > UI users to deal with heterogeneous nodes, and that mechanism must use
> > nova-scheduler.  In my mind,
> > that's what resource classes and node profiles are intended for.
> 
> Not arguing on this point. Though that mechanism should support also
> cases, where user specifies a role for a node / removes node from a
> role. The rest of nodes which I don't care about should be handled by
> nova-scheduler.
> 
> > One possible objection might be: nova scheduler doesn't have the
> > appropriate filter that we need to
> > separate out two nodes.  In that case, I would say that needs to be taken
> > up with nova developers.
> 
> Give it to Nova guys to fix it... What if that user's need would be
> undercloud specific requirement?  Why should Nova guys care? What should
> our unhappy user do until then? Use other tool? Will he be willing to
> get back to use our tool once it is ready?
> 
> I can also see other use-cases. It can be distribution based on power
> sockets, networking connections, etc. We can't think about all the ways
> which our user will need.

In this case - it would be our job to make the Nova guys care and to work with 
them to develop
the feature.  Creating parallel services with the same fundamental purpose - I 
think that
runs counter to what OpenStack is designed for.

> 
> > b) Terminology
> >
> > It feels a bit like some of the disagreement come from people using
> > different words for the same thing.
> > For example, the wireframes already details a UI where Robert's roles come
> > first, but I think that message
> > was confused because I mentioned "node types" in the requirements.
> >
> > So could we come to some agreement on what the most exact terminology would
> > be?  I've listed some examples below,
> > but I'm sure there are more.
> >
> > node type | role
> +1 role
> 
> > management node | ?
> > resource

[openstack-dev] [Solum] [Plan]

2013-12-10 Thread devdatta kulkarni

Hi Adrian,

Thanks for creating https://etherpad.openstack.org/p/solum-demystified

I am really excited to see the examples. Especially cool is how
examples 2 and 3 demonstrate using a component ("solum_glance_id") created
as part of example 1.


Some questions/comments:

1) Summarizing the sequence of events just to make sure I understand them 
correctly: 
   a) User selects a language pack and specifies its id in the plan file
   b) User creates repo with the plan file in it.

   After this the flow could be:
   c.1) User uses solum cli to 'create' an application by giving reference to 
  the repo uri
   c.1.1) Solum creates a plan resource
   c.1.2) Solum model interpreter creates a Heat stack and does the rest of 
the
things needed to create a assembly. 
   (The created plan resource does not play any part in assembly creation 
as such.
Its only role is being a 'trackback' to track the plan from which the 
assembly was created.)

   or, 
   c.2) User uses solum cli to 'create/register' a plan by providing reference 
to the repo uri. 
c.2.1) Solum creates the plan resource.
   c.2) User uses solum cli to 'create' an application by specifying the 
created plan
resource uri
(In this flow, the plan is actively used).
  

2) Addition of new solum specific attributes in a plan specification is 
interesting.
   I imagine those can be contributed back as "Solum" profile to CAMP spec?


3) Model interpreter for generating Heat stack from a plan is a nice idea.
   For all: Are there any recommended libraries for this?


4) Just to confirm, I assume that the api-spec-review etherpad 
(https://etherpad.openstack.org/p/solum-api-spec-review), 
   is for fyi purpose only. If someone wants to know what is the current 
thinking about API, they should
   just look at the solum-demystified etherpad 
(https://etherpad.openstack.org/p/solum-demystified)


Thanks,
Devdatta



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

Re: [openstack-dev] FW: [Bug 1257788] Re: nova-network doesn't handle large amount of concurrent booting instances well

2013-12-10 Thread Joshua Harlow

Yup, IMHO this is where the rally[1] project, and others that attempt to
push the boundaries are really helping openstack become much better around
these types of issues. At yahoo! in a short-time it will not be that
uncommon to boot 100+ VMs concurrently (traffic spikes, other random QA
testing that requires more than 10 instances...). So the earlier these
issues get solved then the better it will be for everyone (and they likely
are not simple issues to solve, sadly).

[1] https://wiki.openstack.org/wiki/Rally

On 12/10/13 10:17 AM, "Edgar Magana"  wrote:

>FYI. Concurrent calls are a problem all around in OpenStack!
>
>Edgar
>
>On 12/10/13 8:47 AM, "Abhishek Chanda"  wrote:
>
>>** Changed in: nova
>>   Status: New => Triaged
>>
>>-- 
>>You received this bug notification because you are subscribed to
>>neutron.
>>https://bugs.launchpad.net/bugs/1257788
>>
>>Title:
>>  nova-network doesn't handle large amount of concurrent booting
>>  instances well
>>
>>Status in OpenStack Neutron (virtual network service):
>>  Triaged
>>Status in OpenStack Compute (Nova):
>>  Triaged
>>
>>Bug description:
>>  As seen by the large-ops test nova-network has trouble booting 150 VMs
>>  concurrently. Part of the problem is that setting up the network for
>>  each instance is relatively expensive with many locks and root-wrapped
>>  calls. Both of which significantly hurt performance.  One possible fix
>>  would be to do more bulk network operations when possible, so instead
>>  of 100 separate calls to a root-wrapped tool call it once.
>>
>>To manage notifications about this bug go to:
>>https://bugs.launchpad.net/neutron/+bug/1257788/+subscriptions
>
>
>
>___
>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] [Heat] workflow for fixes involving numerous changes

2013-12-10 Thread Clint Byrum

Excerpts from Steven Hardy's message of 2013-12-10 03:00:26 -0800:
> On Tue, Dec 10, 2013 at 11:45:11AM +0200, Pavlo Shchelokovskyy wrote:
> > - wouldn't it be better to keep all these changes in one bug and fix all
> > misuses per file basis (with one file per patch-set for example)? It seems
> > to me it would be easier to review in this way.
> 
> One file per patch is not a good idea IMO, I think the review burden is
> minimised if you make sure that each commit just contains the exact same
> change to many files, then it's quick to click through them all and confirm
> all looks OK.

+1

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

Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

2013-12-10 Thread Edgar Magana

Also joining!
Looking forward to hearing your ideas folks!

Edgar

On 12/10/13 10:16 AM, "Nachi Ueno"  wrote:

>+1 ! I'll join.
>I'm also working on investigating how to use openstack gating system.
>(This document is still draft version)
>https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
>efQalL5Q0/edit#slide=id.p
>
>2013/12/10 Ivar Lazzaro :
>> +1 for 1700UTC Thursday on IRC
>>
>> -Original Message-
>> From: Kyle Mestery [mailto:mest...@siliconloons.com]
>> Sent: Tuesday, December 10, 2013 9:21 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
>>testing meeting
>>
>> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
>> wrote:
>>> -Original Message-
>>> From: Kyle Mestery 
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>questions)"
>>> 
>>> Date: Tuesday, December 10, 2013 10:48
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
>>> meeting
>>>
 Last week I took an action item to organize a meeting for everyone
 who is doing third-party testing in Neutron for plugins, whether this
 is vendor or Open Source based. The idea is to share ideas around
 setups and any issues people hit. I'd like to set this meeting up for
 this week, Thursday at 1700UTC. I would also like to propose we make
 this a dial in meeting using the Infrastructure Conferencing bridges
 [1]. If this time works, I'll set something up and reply to this
 thread with the dial in information.
>>>
>>> +1 for the meeting time.  Any particular reason for voice over IRC?
>>>
>> We kind of decided that doing this over voice initially would be
>>expedient, but I am fine with moving to IRC. If I don't hear objections,
>>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
>>
>>

 Also, I've started a etherpad page [2] with information. It would be
 good for people to add information to this etherpad as well. I've
 coupled this pad with information around multi-node gate testing for
 Neutron as well, as I suspect most of the third-party testing will
 require multiple nodes as well.
>>>
>>> I'll start filling out our setup.  I have some questions around
>>> Third-Party Testing in particular, and look forward to this discussion.
>>>
>> Awesome, thanks Anthony!
>>

 Thanks!
 Kyle

 [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing
 [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest

 ___
 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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

2013-12-10 Thread Rudra Rugge

+1 for the meeting time.

On Dec 10, 2013, at 10:16 AM, Nachi Ueno  wrote:

> +1 ! I'll join.
> I'm also working on investigating how to use openstack gating system.
> (This document is still draft version)
> https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1eefQalL5Q0/edit#slide=id.p
> 
> 2013/12/10 Ivar Lazzaro :
>> +1 for 1700UTC Thursday on IRC
>> 
>> -Original Message-
>> From: Kyle Mestery [mailto:mest...@siliconloons.com]
>> Sent: Tuesday, December 10, 2013 9:21 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin testing 
>> meeting
>> 
>> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony" 
>>  wrote:
>>> -Original Message-
>>> From: Kyle Mestery 
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Date: Tuesday, December 10, 2013 10:48
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
>>> meeting
>>> 
 Last week I took an action item to organize a meeting for everyone
 who is doing third-party testing in Neutron for plugins, whether this
 is vendor or Open Source based. The idea is to share ideas around
 setups and any issues people hit. I'd like to set this meeting up for
 this week, Thursday at 1700UTC. I would also like to propose we make
 this a dial in meeting using the Infrastructure Conferencing bridges
 [1]. If this time works, I'll set something up and reply to this
 thread with the dial in information.
>>> 
>>> +1 for the meeting time.  Any particular reason for voice over IRC?
>>> 
>> We kind of decided that doing this over voice initially would be expedient, 
>> but I am fine with moving to IRC. If I don't hear objections, lets assume we 
>> will meet at 1700UTC Thursday on #openstack-meeting-alt.
>> 
>> 
 
 Also, I've started a etherpad page [2] with information. It would be
 good for people to add information to this etherpad as well. I've
 coupled this pad with information around multi-node gate testing for
 Neutron as well, as I suspect most of the third-party testing will
 require multiple nodes as well.
>>> 
>>> I'll start filling out our setup.  I have some questions around
>>> Third-Party Testing in particular, and look forward to this discussion.
>>> 
>> Awesome, thanks Anthony!
>> 
 
 Thanks!
 Kyle
 
 [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing
 [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest
 
 ___
 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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] Loadbalancer instance

2013-12-10 Thread Eugene Nikanorov

Hi Neutron and LBaaS folks,

Initial version of blueprint lbaas-service-instance is on review:
https://review.openstack.org/#/c/60207/
This patch is one of few major features that we've planned for LBaaS in
Icehouse and is a basis for other important features like L7 rules,
multiple vips/pools.

The change preserves full API compatibility, e.g. the workflow that has
worked for Havana remains the same.

I understand that all new features have low priority in Icehouse and any
actual review will take place in I-3, but I would appreciate if lbaas
subteam and some of core neutron team could make an early review to get
familiar with the concepts.

I am also going to supply CLI-side changes and tempest API tests for this
patch soon.

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

Re: [openstack-dev] [heat] Stack preview

2013-12-10 Thread Anderson Mesquita

It's still sparse cause we're brainstorming what it'll look like, but if
anybody has suggestions, we more than welcome them!
More updates to the spec are coming soon! =)


2013/12/10 Clint Byrum 

> Excerpts from Richard Lee's message of 2013-12-10 09:46:49 -0800:
> > Hey all,
> >
> > We're working on a
> > blueprint
> > that
> > adds the ability to preview what a given template+parameters would create
> > in terms of resources.  We think this would provide significant value for
> > blueprint authors and for other heat users that want to see what
> someone's
> > template would create before actually launching resources (and possibly
> > having to pay for them).
> >
> > We'd love to hear any thoughts regarding this feature
>
> Thanks for starting with use cases. I like the use case of being able
> to preview the damage this template will do to your bank account when
> consuming templates without actually understanding the template language.
>
> I'd love to see more details in the spec.
>
> ___
> 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] New API requirements, review of GCE

On 12/10/2013 10:47 AM, Alexandre Levine wrote:
> Does nova actually have add-ons infrastructure in which our GCE API can
> fit? I see the plugins with xen-server only and have found this link:
> http://docs.openstack.org/developer/nova/api/nova.openstack.common.plugin.plugin.html.
> Is it the thing? I'm trying to understand what you meant by this: "If it
> doesn't go into Nova, this would be a good way to manage it as an add-on".

I mean as a place to host the code with infrastructure that can help
make sure it stays in sync with Nova.

There's no real plugin infrastructure that this would fit in to.  It
would be a new service in your repo, based on Nova's service code, that
loads the GCE API.  Your code would be importing nova.* stuff, even
though it's in a separate repo.

> Also if we do it a separate service does it remove necessity for support
> commitment from the nova core team? 

Yes.

> And if it does who would have to commit instead?

It could be anyone.  I presume it would be the original authors who were
planning to help maintain it anyway, as well as anyone else that the
project can attract that is interested in GCE.

> Sorry if I ask some obvious questions.

No problem ... there isn't an existing example for you follow exactly,
so it's not obvious.

-- 
Russell Bryant

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

[openstack-dev] FW: [Bug 1257788] Re: nova-network doesn't handle large amount of concurrent booting instances well

2013-12-10 Thread Edgar Magana

FYI. Concurrent calls are a problem all around in OpenStack!

Edgar

On 12/10/13 8:47 AM, "Abhishek Chanda"  wrote:

>** Changed in: nova
>   Status: New => Triaged
>
>-- 
>You received this bug notification because you are subscribed to
>neutron.
>https://bugs.launchpad.net/bugs/1257788
>
>Title:
>  nova-network doesn't handle large amount of concurrent booting
>  instances well
>
>Status in OpenStack Neutron (virtual network service):
>  Triaged
>Status in OpenStack Compute (Nova):
>  Triaged
>
>Bug description:
>  As seen by the large-ops test nova-network has trouble booting 150 VMs
>  concurrently. Part of the problem is that setting up the network for
>  each instance is relatively expensive with many locks and root-wrapped
>  calls. Both of which significantly hurt performance.  One possible fix
>  would be to do more bulk network operations when possible, so instead
>  of 100 separate calls to a root-wrapped tool call it once.
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/neutron/+bug/1257788/+subscriptions



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

Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

2013-12-10 Thread Nachi Ueno

+1 ! I'll join.
I'm also working on investigating how to use openstack gating system.
(This document is still draft version)
https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1eefQalL5Q0/edit#slide=id.p

2013/12/10 Ivar Lazzaro :
> +1 for 1700UTC Thursday on IRC
>
> -Original Message-
> From: Kyle Mestery [mailto:mest...@siliconloons.com]
> Sent: Tuesday, December 10, 2013 9:21 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin testing 
> meeting
>
> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony" 
>  wrote:
>> -Original Message-
>> From: Kyle Mestery 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, December 10, 2013 10:48
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
>> meeting
>>
>>> Last week I took an action item to organize a meeting for everyone
>>> who is doing third-party testing in Neutron for plugins, whether this
>>> is vendor or Open Source based. The idea is to share ideas around
>>> setups and any issues people hit. I'd like to set this meeting up for
>>> this week, Thursday at 1700UTC. I would also like to propose we make
>>> this a dial in meeting using the Infrastructure Conferencing bridges
>>> [1]. If this time works, I'll set something up and reply to this
>>> thread with the dial in information.
>>
>> +1 for the meeting time.  Any particular reason for voice over IRC?
>>
> We kind of decided that doing this over voice initially would be expedient, 
> but I am fine with moving to IRC. If I don't hear objections, lets assume we 
> will meet at 1700UTC Thursday on #openstack-meeting-alt.
>
>
>>>
>>> Also, I've started a etherpad page [2] with information. It would be
>>> good for people to add information to this etherpad as well. I've
>>> coupled this pad with information around multi-node gate testing for
>>> Neutron as well, as I suspect most of the third-party testing will
>>> require multiple nodes as well.
>>
>> I'll start filling out our setup.  I have some questions around
>> Third-Party Testing in particular, and look forward to this discussion.
>>
> Awesome, thanks Anthony!
>
>>>
>>> Thanks!
>>> Kyle
>>>
>>> [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing
>>> [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest
>>>
>>> ___
>>> 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

Re: [openstack-dev] [Nova] New API requirements, review of GCE