Re: [openstack-dev] [Neutron][Nova][Tempest][Devstack] Change in default security group settings?

[Kevin Benton]

Neutron security groups were broken with ML2 in icehouse.

Fixed in these two patches on the date range you noticed the change:
https://review.openstack.org/#/c/83280/
https://review.openstack.org/#/c/83190/

--
Kevin Benton


On Wed, Apr 2, 2014 at 11:34 PM, Eugene Nikanorov
wrote:

> Hi devs,
>
> While working of one of tempest scenario tests I've found out that the
> code that spawns VM and access it on 80 port stopped working due security
> group rule allowing ingress for 80 port is not there.
>
> I'm saying 'stopped working' because previously it worked fine without any
> additional configuration.
> The change happened between 27 and 30 of March.
> Can someone point me to that change?
>
> Thanks,
> Eugene.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [Neutron][Nova][Tempest][Devstack] Change in default security group settings?

[Eugene Nikanorov]

Hi devs,

While working of one of tempest scenario tests I've found out that the code
that spawns VM and access it on 80 port stopped working due security group
rule allowing ingress for 80 port is not there.

I'm saying 'stopped working' because previously it worked fine without any
additional configuration.
The change happened between 27 and 30 of March.
Can someone point me to that change?

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

Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Sebastian Herzberg]

Concerning dnsmasq: There is still no 2.66 version in the repos for Ubuntu 
12.04. You always need to remove 2.59 and dpkg a newer version into it.


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

[openstack-dev] [Heat] Some thoughts on the mapping section

[Qiming Teng]

Hi, 

Regarding the discussion about the adding of a native 'mappings' section
to HOT [1], which has been abandoned, I have some different thoughts for
the team to consider.  Maybe having that section added is not a bad
idea.

I do think we need a 'mappings' kind of functionality in HOT, to allow
users to make a from available options.  There are objections to adopt
this change:

  1) Too similar to CFN... Which should not be the criteria for
  excluding this.  We can use other section names, if we really believe
  that is an important factor to consider.
  
  2) The functionality can be covered by 'environments'.  That is
 where the team really concerns about.

My understanding to the item 2) is that people might have been somehow 
misled by the existing sample templates or the examples used in 
discussion (most of which were using imageId as an example).  

A 'mappings' section, IMO, provides the user an opportunity to make 
selections from many options, period.  Its usage is far beyond guest 
image Id selection. Not all use cases are suitable to be expressed as 
'environments'. 

As the name suggests, 'environment' is a concept to decouple a
template from the cloud/host/guest where it is created.  It helps
promote portability or reusability of the template.  If you have
some settings that will change between clouds, or different guest
OS. 'environment' is the ideal place to put those variances. 

However, a 'mappings' section is about functionality, not usage
scenario.  It can be treated as a subsection of 'parameters', to
make a template even more reusable when the stack can be used with
different resources (say, softwareconfigs, cloudconfigs, different
sources for get_file etc.).  

Say I have three DB backends to choose from, for my application [2].
The DB backend is better treated as a component of the application, 
instead of part of the environment.  A 'mappings' section can be 
used for a quick selection of OpenStack level options (such as 
scaling policies, security groups, different templates for a nested 
stack, different versions of external templates residing on a GIT
website...) or any application-level options (such as a different
SoftwareDeployment for the same SoftwareConfig), irrespective to which
cloud (the 'environments', my understanding) is hosting the stack.  

Speaking of offering options for selection, there is another proposal on
adding conditional creation of resources [3], whose use case to enable
or disable a resource creation (among others).  My perception is that
these are all relevant enhancements to the reusability of HOT templates,
though I don't think we really need very sophisticated combinatory
conditionals.

Regards,
  - Qiming

[1] https://review.openstack.org/#/c/81918/
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-April/031712.html
[3] https://review.openstack.org/#/c/84468/


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

[openstack-dev] [cinder] the ability about list the available volume back-ends and their capabilities

[Zhangleiqiang (Trump)]

Hi stackers:

I think the ability about list the available volume back-ends, along with 
their capabilities, total capacity, available capacity is useful for admin. For 
example, this can help admin to select a destination for volume migration.
But I can't find the cinder api about this ability.

I find a BP about this ability:  
https://blueprints.launchpad.net/cinder/+spec/list-backends-and-capabilities
But the BP is not approved. Who can tell me the reason?

Thanks.


--
zhangleiqiang (Trump)

Best Regards



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

Re: [openstack-dev] [Cinder]a question about os-volume_upload_image

[Mike Perez]

On 02:58 Thu 03 Apr , Bohai (ricky) wrote:
> Hi,
> 
> When I use an image to create a cinder volume, I found image's metadata is 
> saved into DB table "volume_glance_metadata".
> 
> But when I use " os-volume_upload_image" to create image from cinder volume, 
> the metadata in "volume_glance_metadata" 
> is not setted back to the newly created image. I can't found the reason for 
> this.
> Anyone can give me a hint?
> 
> I am a newbie for cinder and i apologize if I am missing something very 
> obvious.
> 
> Best regards to you.
> Ricky

Hi Ricky,

The glance metadata is currently only stored for creating new volumes, new
snapshots or backups. It's used for in the volume creation to know if the
volume is bootable.

-- 
Mike Perez

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

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed.

[Eugene Nikanorov]

Stephen,

Agree with you. Basically the page starts looking as requirements page.
I think we need to move to google spreadsheet, where table is organized
easily.
Here's the doc that may do a better job for us:
https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing

Thanks,
Eugene.


On Thu, Apr 3, 2014 at 5:34 AM, Prashanth Hari  wrote:

> More additions to the use cases (
> https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases).
> I have updated some of the features we are interested in.
>
>
>
> Thanks,
> Prashanth
>
>
>
> On Wed, Apr 2, 2014 at 8:12 PM, Stephen Balukoff wrote:
>
>> Hi y'all--
>>
>> Looking at the data in the page already, it looks more like a feature
>> wishlist than actual usage data. I thought we agreed to provide data based
>> on percentage usage of a given feature, the end result of the data
>> collection being that it would become more obvious which features are the
>> most relevant to the most users, and therefore are more worthwhile targets
>> for software development.
>>
>> Specifically, I was expecting to see something like the following (using
>> hypothetical numbers of course, and where technical people from "Company A"
>> & etc. fill out the data for their organization):
>>
>> == L7 features ==
>>
>> "Company A" (Cloud operator serving external customers): 56% of
>> load-balancer instances use
>> "Company B" (Cloud operator serving external customers): 92% of
>> load-balancer instances use
>> "Company C" (Fortune 100 company serving internal customers): 0% of
>> load-balancer instances use
>>
>> == SSL termination ==
>>
>> "Company A" (Cloud operator serving external customers): 95% of
>> load-balancer instances use
>> "Company B" (Cloud operator serving external customers): 20% of
>> load-balancer instances use
>> "Company C" (Fortune 100 company serving internal customers): 50% of
>> load-balancer instances use.
>>
>> == Racing stripes ==
>>
>> "Company A" (Cloud operator serving external customers): 100% of
>> load-balancer instances use
>> "Company B" (Cloud operator serving external customers): 100% of
>> load-balancer instances use
>> "Company C" (Fortune 100 company serving internal customers): 100% of
>> load-balancer instances use
>>
>>
>> In my mind, a wish-list of features is only going to be relevant to this
>> discussion if (after we agree on what the items under consideration ought
>> to be) each technical representative presents a prioritized list for their
>> organization. :/ A wish-list is great for brain-storming what ought to be
>> added, but is less relevant for prioritization.
>>
>> In light of last week's meeting, it seems useful to list the features
>> most recently discussed in that meeting and on the mailing list as being
>> points on which we want to gather actual usage data (ie. from what people
>> are actually using on the load balancers in their organization right now).
>> Should we start a new page that lists actual usage percentages, or just
>> re-vamp the one above?  (After all, wish-list can be useful for discovering
>> things we're missing, especially if we get people new to the discussion to
>> add their $0.02.)
>>
>> Thanks,
>> Stephen
>>
>>
>>
>>
>> On Wed, Apr 2, 2014 at 3:46 PM, Jorge Miramontes <
>> jorge.miramon...@rackspace.com> wrote:
>>
>>>   Thanks Eugene,
>>>
>>>  I added our data onto the requirements page since I was hoping to
>>> prioritize requirements based on the operator data that gets provided. We
>>> can move it over to the other page if you think that makes sense. See
>>> everyone on the weekly meeting tomorrow!
>>>
>>>  Cheers,
>>> --Jorge
>>>
>>>   From: Susanne Balle 
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" 
>>> Date: Tuesday, April 1, 2014 4:09 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev@lists.openstack.org>
>>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases.
>>> Data from Operators needed.
>>>
>>>   I added two more. I am still working on our HA use cases. Susanne
>>>
>>>
>>> On Tue, Apr 1, 2014 at 4:16 PM, Fox, Kevin M  wrote:
>>>
  I added our priorities. I hope its formatted well enough. I just took
 a stab in the dark.

 Thanks,
 Kevin
  --
 *From:* Eugene Nikanorov [enikano...@mirantis.com]
 *Sent:* Tuesday, April 01, 2014 3:02 AM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [Neutron][LBaaS] Load balancing use cases.
 Data from Operators needed.

Hi folks,

  On the last meeting we decided to collect usage data so we could
 prioritize features and see what is demanded most.

  Here's the blank page to do that (in a free form). I'll structure it
 once we have some data.
 https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases

  Please fill with the data you have.

  Thanks,
 Eugene.

 __

[openstack-dev] [nova] Nova API meeting

[Christopher Yeoh]

Hi,

Just a reminder that the weekly Nova API meeting is being held tomorrow
Friday UTC . 

We encourage cloud operators and those who use the REST API such as
SDK developers and others who and are interested in the future of the
API to participate. 

In other timezones the meeting is at:

EST 20:00 (Thu)
Japan 09:00 (Fri)
China 08:00 (Fri)
ACDT 10:30 (Fri)

The proposed agenda and meeting details are here: 

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda. 

Chris

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

Re: [openstack-dev] [heat] metadata for a HOT

[Mike Spreitzer]

Zane Bitter  wrote on 04/02/2014 05:36:43 PM:

> I think that if you're going to propose a new feature, you should at 
> least give us a clue who you think is going to use it and what for ;)

I was not eager to do that yet because I have not found a fully 
satisfactory answer yet, at this point I am exploring options.  But the 
problem I am thinking about is how Heat might connect to a holistic 
scheduler (a scheduler that makes a joint decision about a bunch of 
resources of various types).  Such a scheduler needs input describing the 
things to be scheduled and the policies to apply in scheduling; the first 
half of that sounds a lot like a Heat template, so my thoughts go in that 
direction.  But the HOT language today (since 
https://review.openstack.org/#/c/83758/ was merged) does not have a place 
to put policy that is not specific to a single resource.

> IIRC this has been discussed in the past and the justifications for 
> including it in the template (as opposed to allowing metadata to be 
> attached in the ReST API, as other projects already do for many things) 
> were not compelling.

I see that Keith Bray mentioned 
https://wiki.openstack.org/wiki/Heat/StackMetadata and 
https://wiki.openstack.org/wiki/Heat/UI in another reply on this thread. 
Are there additional places to look to find that discussion?

I have also heard that there has been discussion of language extension 
issues.  Is that a separate discussion and, if so, where can I read it?

Thanks,
Mike

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

Re: [openstack-dev] [heat] Standing down as PTL

[Steve Kowalik]

On 03/04/14 16:03, Monty Taylor wrote:
> All hail the Mooball release.
> 
> Now we just have to find a city that's in a state or country with a
> placename of "Mooball" - that shouldn't be too hard ...

http://en.wikipedia.org/wiki/Mooball,_New_South_Wales

> On 04/02/2014 08:20 PM, Qiming Teng wrote:
>> Let's vote for the K, L, M release names now. :)
>>
>> Thanks, Steve.
>>
>> On Mon, Mar 31, 2014 at 11:22:49AM +1300, Steve Baker wrote:
>>> I don't intend to run for PTL for the Juno cycle; thankfully there are
>>> many Heat developers who would do a great job.
>>>
>>> Hopefully this wasn't a one-off though. I may run again for Kilmacow,
>>> Lacrosse or Mooball.
>>>
>>> cheers
>>>
>>> ___
>>> 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


-- 
Steve
Wrong is endian little that knows everyone but.
 - Sam Hocevar

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

Re: [openstack-dev] [heat] Standing down as PTL

[Monty Taylor]

All hail the Mooball release.

Now we just have to find a city that's in a state or country with a 
placename of "Mooball" - that shouldn't be too hard ...


On 04/02/2014 08:20 PM, Qiming Teng wrote:

Let's vote for the K, L, M release names now. :)

Thanks, Steve.

On Mon, Mar 31, 2014 at 11:22:49AM +1300, Steve Baker wrote:

I don't intend to run for PTL for the Juno cycle; thankfully there are
many Heat developers who would do a great job.

Hopefully this wasn't a one-off though. I may run again for Kilmacow,
Lacrosse or Mooball.

cheers

___
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] [State-Management] Agenda for meeting (tommorow) at 2000 UTC

[Joshua Harlow]

Hi all,


The [state-management] project team holds a weekly meeting in 
#openstack-meeting on thursdays, 2000 UTC. The next meeting is tommorow, 
2014-04-03!!!


As usual, everyone is welcome :-)


Link: https://wiki.openstack.org/wiki/Meetings/StateManagement

Taskflow: https://wiki.openstack.org/TaskFlow

Docs: http://docs.openstack.org/developer/taskflow

Blueprints: https://blueprints.launchpad.net/taskflow


## Agenda (30-60 mins):


- Discuss any action items from last meeting.

- 0.2 Release FTW!

- 0.2.1 and 0.3 planning and ideas [blueprints and features and ideas]

- Lazy engine idea, concept, thoughts ... [http://tinyurl.com/kdh789z and 
supporting threads]

- Discuss about any other potential new use-cases for said library.

- Discuss about any other ideas, reviews needing help, questions and answers 
(and more!).


Any other topics are welcome :-)


See you all soon!


--


Joshua Harlow


It's openstack, relax... | harlo...@yahoo-inc.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] metadata for a HOT

[Keith Bray]

https://wiki.openstack.org/wiki/Heat/StackMetadata

https://wiki.openstack.org/wiki/Heat/UI

-Keith

From: Lingxian Kong mailto:anlin.k...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 2, 2014 9:31 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [heat] metadata for a HOT

Is there any relevant wiki or specification doc?


2014-04-03 4:45 GMT+08:00 Mike Spreitzer 
mailto:mspre...@us.ibm.com>>:
I would like to suggest that a metadata section be allowed at the top level of 
a HOT.  Note that while resources in a stack can have metadata, there is no way 
to put metadata on a stack itself.  What do you think?

Thanks,
Mike
___
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] [heat] metadata for a HOT

[Lingxian Kong]

Is there any relevant wiki or specification doc?


2014-04-03 4:45 GMT+08:00 Mike Spreitzer :

> I would like to suggest that a metadata section be allowed at the top
> level of a HOT.  Note that while resources in a stack can have metadata,
> there is no way to put metadata on a stack itself.  What do you think?
>
> Thanks,
> Mike
> ___
> 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] [heat] Standing down as PTL

[Qiming Teng]

Let's vote for the K, L, M release names now. :)

Thanks, Steve.  

On Mon, Mar 31, 2014 at 11:22:49AM +1300, Steve Baker wrote:
> I don't intend to run for PTL for the Juno cycle; thankfully there are
> many Heat developers who would do a great job.
> 
> Hopefully this wasn't a one-off though. I may run again for Kilmacow,
> Lacrosse or Mooball.
> 
> cheers
> 
> ___
> 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] python-keystoneclient v3 functionality

[Yaguang Tang]

2014-04-03 7:12 GMT+08:00 Jamie Lennox :

>
>
> - Original Message -
> > From: "Adam Young" 
> > To: openstack-dev@lists.openstack.org
> > Sent: Wednesday, 2 April, 2014 11:13:22 PM
> > Subject: Re: [openstack-dev] [Keystone] python-keystoneclient v3
>  functionality
> >
> > On 04/01/2014 07:36 AM, Yaguang Tang wrote:
> >
> >
> >
> > Thanks Jamie,
> >
> > then the following question is do we intend to move other services client
> > library V3 identity support to python-openstackclient?
> > AFAIK it's poorly supported for Nova Cinder Neutron client library, and
> I am
> > working on add v3 support for those libraries[1], just
> > want to make sure that is the correct direction.
> >
> > [1] https://review.openstack.org/#/c/81749/
> > https://review.openstack.org/#/c/81767/
> >
> >
> > Sort of. The Keystone client should be responsible for all fo the service
> > catalog manipulations throughout openstack. So the Cinder client should
> use
> > the Keystone client.
> >
> > To see the idea, read Jamie's blog post:
> >
> > http://www.jamielennox.net/blog/2014/02/24/client-session-objects/
> >
> > The main idea is that Keystone will handle the HTTP session setup, so
> that we
> > have a single place to focus attention on for HTTP network security
> issues.
> > And you should not need to parse the service catalog at all.
> >
> >
>
> So Adam is right in that the general idea to transition people to using
> the V3 API will be to use the keystoneclient.session.Session object and
> that will do everything for you. This is not going to be an easy transition
> for everyone and i've got a summit session proposed:
> http://summit.openstack.org/cfp/details/205 in which i want to deal with
> precisely this problem.
>
> Regarding your notion of openstackclient though, you need to seperate the
> concept of a CLI and the library.
>
> Take for example Heat or Horizon, they communicate with keystone through
> the python-keystoneclient and nova via the python-novaclient etc. They do
> not use the keystone or nova cli utility. The primary job of the
> python-*client libraries is NOT to provide a cli. The cli is just an
> application that makes use of the library.
>

  Yeah, but when we talking about the support of v3 for Nova Cinder and
Neutron. I think it's mostly about the auth token middleware and CLI
support of the client library.

>
> So yes, i think it has generally been accepted that the clients will move
> (at there own pace) to using openstackclient for there CLI, but
> openstackclient will still rely on the various libraries to do the actual
> communication with services
>

   I wonder is it worth to enable v3 for CLI when we moving to
openstackclient  so that  OpenStack users and operators can test and
evaluate v3 API , and we may probably add a v3 test gate to CI. what we
face is that   user can use v3 API with novaclient CLI, this has been asked
many times in the OpenStack user mailing list.


>
>
> Jamie
>
> >
> >
> > 2014-04-01 12:08 GMT+08:00 Jamie Lennox < jamielen...@redhat.com > :
> >
> >
> >
> > On Tue, 2014-04-01 at 11:53 +0800, Yaguang Tang wrote:
> > > Hi all,
> > >
> > >
> > > I am sorry if this has been discussed before, the question is will we
> > > support keystone v3 operation
> > > in python-keystoneclient? I know most of the v3 functionality have
> > > been implemented in python-openstackclient, but from the
> > > python-openstackclient wiki says, it's primarily a wrapper of
> > > python-*client, and provides unified interface to user. The end user
> > > uses python-keystoneclient to manage
> > > user, tenant, service before, if we don't intend to support v3
> > > functionality in keystoneclient, then
> > > it means we force end user to change from keystoneclient to
> > > openstackclient, is this what we want to
> > > do?
> > >
> >
> > It depends what you mean by python-keystoneclient.
> >
> > If you mean the python library then yes it supports the V3 API already.
> >
> > If you mean the keystone CLI that is currently bundled as part of the
> > python-keystoneclient then yes that is deprecated in favour of
> > python-openstackclient.
> >
> > We will maintain the CLI application in keystoneclient however even for
> > V2 API calls I recommend that you use the openstack CLI tool.
> >
> > Jamie
> >
> > >
> > > --
> > > Tang Yaguang
> > >
> > >
> > > Canonical Ltd. | www.ubuntu.com | www.canonical.com
> > > Mobile: +86 152 1094 6968
> > > gpg key: 0x187F664F
> > >
> > > ___
> > > 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
> >
> >
> >
> > --
> > Tang Yaguang
> >
> > Canonical Ltd. | www.ubuntu.com | www.canonical.com
> > Mobile: +86 152 1094 6968
> > gpg key: 

[openstack-dev] [Tempest][Nova] Can we remove XML tests of Nova v2 API from Tempest?

[Kenichi Oomichi]

Hi,

The XML support of Nova v2 API is marked as deprecated, and the message is
'XML support has been deprecated and will be removed in the Juno release.'
with https://review.openstack.org/#/c/75439

Now we are in Juno cycle, so can we remove these tests from Tempest?
If doing it, the gate testing time would shrink and the implementations of
Nova v2 API test would be more easy.


Thanks
Ken'ichi Ohmichi


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

[openstack-dev] [Cinder]a question about os-volume_upload_image

[Bohai (ricky)]

Hi,

When I use an image to create a cinder volume, I found image's metadata is 
saved into DB table "volume_glance_metadata".

But when I use " os-volume_upload_image" to create image from cinder volume, 
the metadata in "volume_glance_metadata" 
is not setted back to the newly created image. I can't found the reason for 
this.
Anyone can give me a hint?

I am a newbie for cinder and i apologize if I am missing something very obvious.

Best regards to you.
Ricky


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

[openstack-dev] [ceilometer] Serveral questions about alarm function of ceilometer

[Yuanjing (D)]

Hi

I have a requirement of monitoring VMs, if a VM's meter like cpu_util become 
too high, then system generate an alarm for this VM with meter information.

I have tested alarm function of ceilometer, below are commands I used to create 
alarm object with meter and resource id or not:
ceilometer alarm-threshold-create  --name alarm1 --meter-name cpu_util --period 
60 --evaluation-periods 1 --statistic avg --comparison-operator gt --threshold 
1 -q resource_id=757dadaa-0707-4fad-808d-81edc11438aa
ceilometer alarm-threshold-create  --name alarm1 --meter-name cpu_util --period 
60 --evaluation-periods 1 --statistic avg --comparison-operator gt --threshold 1

I have the following question:
If I have to define alarm object for every VM and every meter?
Take 100 VM and 2 meter cpu_util, memory_util as an example, I will have to 
define 100*2 alarm objects for them.
I think if I just define alarm object with meter not but VM(resource_id), then 
alarm evaluator will count all VM's meter.

Another question produced by question above: I know that alarm evaluator will 
process alarm object one by one, so too many alarm object may result in 
performance problems too.

I am not a ceilometer programmer and I apologize if I am missing something very 
obvious.
Can you give me some help to make me clear about them and how to implement my 
requirement?

Thanks

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

Re: [openstack-dev] [neutron]Success to create securitygroup with invalid tenant_id. Does it need to check the tenant_id?

[Aaron Rosen]

Hi Lee,

No, currently only an admin user can create something with a different
tenant_id by default. The issue with validating the tenant_id is we need to
involve keystone in order to check if the tenant_id is valid (which will
cause things to slow down). I believe this question has already come up on
the list before if you want to search the archive. This issue isn't
specific to just security_groups in neutron its allowed with all neutron
resources.

Aaron



On Tue, Apr 1, 2014 at 1:58 AM, 黎林果  wrote:

> Hi,
>all
>
>Such as the subject, there is no mechanism to check the tenant_id, Do
> you think it is necessary?
>
>
>Thanks!
>
>Lee Li
>
> ___
> 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] [Openstack] [NOVA] Missing network info in nova list

[Aaron Rosen]

Hi Slawek,

Interesting, I haven't seen this issue of network info not showing up on
nova list and the instance being in ACTIVE state. Could you check out the
nova logs and see if there are any TRACE's there?  If you're using icehouse
you should be able to do neutron port-update  that maps to the
instance's port and doing that will send a notification to nova  to update
it's cache for the instance.

Best,

Aaron


On Tue, Apr 1, 2014 at 12:10 AM, Sławek Kapłoński wrote:

> Hello,
>
> Maybe the problem is not that missing data in nova's database becasue when
> I
> made:
> nova --debug list
> then I see that it is asking neutron about ports and this missing IP is
> corretly send from neutron.
> Also when I made:
> nova interface-list 
> then there is no problem and IP is displayed. But still this IP is missing
> in
> list of instances and I displaying instance details (also in horizon).
>
> --
> Best regards
> Sławek Kapłoński
>
> Dnia poniedziałek, 31 marca 2014 18:17:18 Sławek Kapłoński pisze:
> > Hello,
> >
> > I have openstack installation with neutron. When I made test and create
> > many instances in one query (using --num-instances) all was ok but one
> > instance (from 80 created) has no IP address when I made "nova list" or
> > "nova show ". I found that there is missing value in "network info" in
> > nova database in "Instance-info-cache" table. Everything except that is
> > working fine: port with this IP is assigned to instance in neutron,
> > binding is ok, instance has got configured this IP and I can ping it.
> > Maybe someone know why this informations are missing in nova database
> > and how to refresh it?
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/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

[openstack-dev] [Oslo][Nova][Heat] Sample config generator issue

[Zane Bitter]

We have an issue in Heat where the sample config generator from Oslo is 
currently broken (see bug #1288586). Unfortunately it turns out that 
there is no fix to the generator script itself that can do the Right 
Thing for both Heat and Nova.


A brief recap on how the sample config generator works: it goes through 
all of the files specified and finds all the ConfigOpt objects at the 
top level. It then searches for them in the registered options, and 
returns the name of the group in which they are registered. Previously 
it looked for the identical object being registered, but now it just 
looks for any equivalent ones. When you register two or more equivalent 
options, the second and subsequent ones are just ignored by oslo.config.


The situation in Heat is that we have a bunch of equivalent options 
registered in multiple groups. This is because we have a set of options 
for each client library (i.e. python-novaclient, python-cinderclient, 
&c.), with each set containing equivalent options (e.g. every client has 
an "endpoint_type" option for looking up the keystone catalog). This 
used to work, but now that equivalent options (and not just identical 
options) match when searching for them in a group, we just end up with 
multiple copies of each option in the first group to be searched, and 
none in any of the other groups, in the generated sample config.


Nova, on the other hand, has the opposite problem (see bug #1262148). 
Nova adds the auth middleware from python-keystoneclient to its list of 
files to search for options. That middleware imports a file from 
oslo-incubator that registers the option in the default group - a 
registration that is *not* wanted by the keystone middleware, because it 
registers an equivalent option in a different group instead (or, as it 
turns out, as well). Just to make it interesting, Nova uses the same 
oslo-incubator module and relies on the option being registered in the 
default group. Of course, oslo-incubator is not a real library, so it 
gets registered a second time but ignored (since an equivalent one is 
already present). Crucially, the oslo-incubator file from 
python-keystoneclient is not on the list of extra modules to search in 
Nova, so when the generator script was looking for options identical to 
the ones it found in modules, it didn't see this option at all. Hence 
the change to looking for equivalent options, which broke Heat.


Neither comparing for equivalence nor for identity in the generator 
script can solve both use cases. It's hard to see what Heat could or 
should be doing differently. I think it follows that the fix needs to be 
in either Nova or python-keystoneclient in the first instance.


One option I suggested was for the auth middleware to immediately 
deregister the extra option that had accidentally been registered upon 
importing a module from oslo-incubator. I put up patches to do this, but 
it seemed to be generally agreed by Oslo folks that this was a Bad Idea.


Another option would be to specifically include the relevant module from 
keystoneclient.openstack.common when generating the sample config. This 
seems quite brittle to me.


We could fix it by splitting the oslo-incubator module into one that 
provides the code needed by the auth middleware and one that does the 
registration of options, but this will likely result in cascading 
changes to a whole bunch of projects.


Does anybody have any thoughts on what the right fix looks like here? 
Currently, verification of the sample config is disabled in the Heat 
gate because of this issue, so it would be good to get it resolved.


cheers,
Zane.

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

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed.

[Prashanth Hari]

More additions to the use cases (
https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases).
I have updated some of the features we are interested in.



Thanks,
Prashanth



On Wed, Apr 2, 2014 at 8:12 PM, Stephen Balukoff wrote:

> Hi y'all--
>
> Looking at the data in the page already, it looks more like a feature
> wishlist than actual usage data. I thought we agreed to provide data based
> on percentage usage of a given feature, the end result of the data
> collection being that it would become more obvious which features are the
> most relevant to the most users, and therefore are more worthwhile targets
> for software development.
>
> Specifically, I was expecting to see something like the following (using
> hypothetical numbers of course, and where technical people from "Company A"
> & etc. fill out the data for their organization):
>
> == L7 features ==
>
> "Company A" (Cloud operator serving external customers): 56% of
> load-balancer instances use
> "Company B" (Cloud operator serving external customers): 92% of
> load-balancer instances use
> "Company C" (Fortune 100 company serving internal customers): 0% of
> load-balancer instances use
>
> == SSL termination ==
>
> "Company A" (Cloud operator serving external customers): 95% of
> load-balancer instances use
> "Company B" (Cloud operator serving external customers): 20% of
> load-balancer instances use
> "Company C" (Fortune 100 company serving internal customers): 50% of
> load-balancer instances use.
>
> == Racing stripes ==
>
> "Company A" (Cloud operator serving external customers): 100% of
> load-balancer instances use
> "Company B" (Cloud operator serving external customers): 100% of
> load-balancer instances use
> "Company C" (Fortune 100 company serving internal customers): 100% of
> load-balancer instances use
>
>
> In my mind, a wish-list of features is only going to be relevant to this
> discussion if (after we agree on what the items under consideration ought
> to be) each technical representative presents a prioritized list for their
> organization. :/ A wish-list is great for brain-storming what ought to be
> added, but is less relevant for prioritization.
>
> In light of last week's meeting, it seems useful to list the features most
> recently discussed in that meeting and on the mailing list as being points
> on which we want to gather actual usage data (ie. from what people are
> actually using on the load balancers in their organization right now).
> Should we start a new page that lists actual usage percentages, or just
> re-vamp the one above?  (After all, wish-list can be useful for discovering
> things we're missing, especially if we get people new to the discussion to
> add their $0.02.)
>
> Thanks,
> Stephen
>
>
>
>
> On Wed, Apr 2, 2014 at 3:46 PM, Jorge Miramontes <
> jorge.miramon...@rackspace.com> wrote:
>
>>   Thanks Eugene,
>>
>>  I added our data onto the requirements page since I was hoping to
>> prioritize requirements based on the operator data that gets provided. We
>> can move it over to the other page if you think that makes sense. See
>> everyone on the weekly meeting tomorrow!
>>
>>  Cheers,
>> --Jorge
>>
>>   From: Susanne Balle 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, April 1, 2014 4:09 PM
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases.
>> Data from Operators needed.
>>
>>   I added two more. I am still working on our HA use cases. Susanne
>>
>>
>> On Tue, Apr 1, 2014 at 4:16 PM, Fox, Kevin M  wrote:
>>
>>>  I added our priorities. I hope its formatted well enough. I just took
>>> a stab in the dark.
>>>
>>> Thanks,
>>> Kevin
>>>  --
>>> *From:* Eugene Nikanorov [enikano...@mirantis.com]
>>> *Sent:* Tuesday, April 01, 2014 3:02 AM
>>> *To:* OpenStack Development Mailing List
>>> *Subject:* [openstack-dev] [Neutron][LBaaS] Load balancing use cases.
>>> Data from Operators needed.
>>>
>>>Hi folks,
>>>
>>>  On the last meeting we decided to collect usage data so we could
>>> prioritize features and see what is demanded most.
>>>
>>>  Here's the blank page to do that (in a free form). I'll structure it
>>> once we have some data.
>>> https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases
>>>
>>>  Please fill with the data you have.
>>>
>>>  Thanks,
>>> Eugene.
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
> ___
> OpenStack-d

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed.

[Stephen Balukoff]

Hi y'all--

Looking at the data in the page already, it looks more like a feature
wishlist than actual usage data. I thought we agreed to provide data based
on percentage usage of a given feature, the end result of the data
collection being that it would become more obvious which features are the
most relevant to the most users, and therefore are more worthwhile targets
for software development.

Specifically, I was expecting to see something like the following (using
hypothetical numbers of course, and where technical people from "Company A"
& etc. fill out the data for their organization):

== L7 features ==

"Company A" (Cloud operator serving external customers): 56% of
load-balancer instances use
"Company B" (Cloud operator serving external customers): 92% of
load-balancer instances use
"Company C" (Fortune 100 company serving internal customers): 0% of
load-balancer instances use

== SSL termination ==

"Company A" (Cloud operator serving external customers): 95% of
load-balancer instances use
"Company B" (Cloud operator serving external customers): 20% of
load-balancer instances use
"Company C" (Fortune 100 company serving internal customers): 50% of
load-balancer instances use.

== Racing stripes ==

"Company A" (Cloud operator serving external customers): 100% of
load-balancer instances use
"Company B" (Cloud operator serving external customers): 100% of
load-balancer instances use
"Company C" (Fortune 100 company serving internal customers): 100% of
load-balancer instances use


In my mind, a wish-list of features is only going to be relevant to this
discussion if (after we agree on what the items under consideration ought
to be) each technical representative presents a prioritized list for their
organization. :/ A wish-list is great for brain-storming what ought to be
added, but is less relevant for prioritization.

In light of last week's meeting, it seems useful to list the features most
recently discussed in that meeting and on the mailing list as being points
on which we want to gather actual usage data (ie. from what people are
actually using on the load balancers in their organization right now).
Should we start a new page that lists actual usage percentages, or just
re-vamp the one above?  (After all, wish-list can be useful for discovering
things we're missing, especially if we get people new to the discussion to
add their $0.02.)

Thanks,
Stephen




On Wed, Apr 2, 2014 at 3:46 PM, Jorge Miramontes <
jorge.miramon...@rackspace.com> wrote:

>   Thanks Eugene,
>
>  I added our data onto the requirements page since I was hoping to
> prioritize requirements based on the operator data that gets provided. We
> can move it over to the other page if you think that makes sense. See
> everyone on the weekly meeting tomorrow!
>
>  Cheers,
> --Jorge
>
>   From: Susanne Balle 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, April 1, 2014 4:09 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases.
> Data from Operators needed.
>
>   I added two more. I am still working on our HA use cases. Susanne
>
>
> On Tue, Apr 1, 2014 at 4:16 PM, Fox, Kevin M  wrote:
>
>>  I added our priorities. I hope its formatted well enough. I just took a
>> stab in the dark.
>>
>> Thanks,
>> Kevin
>>  --
>> *From:* Eugene Nikanorov [enikano...@mirantis.com]
>> *Sent:* Tuesday, April 01, 2014 3:02 AM
>> *To:* OpenStack Development Mailing List
>> *Subject:* [openstack-dev] [Neutron][LBaaS] Load balancing use cases.
>> Data from Operators needed.
>>
>>Hi folks,
>>
>>  On the last meeting we decided to collect usage data so we could
>> prioritize features and see what is demanded most.
>>
>>  Here's the blank page to do that (in a free form). I'll structure it
>> once we have some data.
>> https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases
>>
>>  Please fill with the data you have.
>>
>>  Thanks,
>> Eugene.
>>
>> ___
>> 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
>
>


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] [Murano] [Solum] applications in the cloud

[Georgy Okrokvertskhov]

Hi Steve,

I think this is exactly the place where we have a boundary between Murano
catalog and HOT.

In your example one can use abstract resource type and specify a correct
implementation via environment file. This is how it will be done on the
final stage in Murano too.

Murano will solve another issue. In your example user should know what
template to use as a provider template. In Murano this will be done in the
following way:
1) User selects an app which requires a DB
2) Murano sees this requirement for DB and do a search in the app catalog
to find all apps which expose this functionality. Murano uses app package
definitions for that.
3) User select in UI specific DB implementation he wants to use.

As you see, in Murano case user has no preliminary knowledge of available
apps\templates and it uses catalog to find it. A search criteria can be
quite complex with using different application attribute. If we think about
moving application definition to HOT format it should provide all necessary
information for catalog.

In order to search apps in catalog which uses HOT format we need something
like that:

One needs to define abstract resource like
OS:HOT:DataBase

Than in each DB implementation of DB resource one has to somehow refer this
abstract resource as a parent like

Resource OS:HOT:MySQLDB
  Parent: OS:HOT:DataBase

Then catalog part can use this information and build a list of all
apps\HOTs with resources with parents OS:HOT:DataBase

That is what we are looking for. As you see, in this example I am not
talking about version and other attributes which might be required for
catalog.

Thanks
Georgy


On Wed, Apr 2, 2014 at 3:30 PM, Steve Baker  wrote:

> On 03/04/14 10:39, Ruslan Kamaldinov wrote:
> > This is a continuation of the "MuranoPL questions" thread.
> >
> > As a result of ongoing discussions, we figured out that definition of
> layers
> > which each project operates on and has responsibility for is not yet
> agreed
> > and discussed between projects and teams (Heat, Murano, Solum (in
> > alphabetical order)).
> >
> > Our suggestion and expectation from this working group is to have such
> > a definition of layers, agreement on it and an approach of reaching it.
> >
> > As a starting point, we suggest the following:
> >
> > There are three layers of responsibility:
> > 1. Resources of the cloud
> > 2. Applications of the cloud
> > 3. Layers specific for Murano and Solum (to be further discussed and
> >clarified, for this discussion it's out of scope)
> >
> > Layer 1 is obviously covered by Heat.
> >
> > Most of the disagreement is around layer 2. Our suggestion is to figure
> out
> > the way where we can have common engine, DSL and approach to apps
> description.
> > For this we'll take HOT and TOSCA as a basis and will work on addition of
> > functionality missing from Murano and Solum point of view.
> >
> > We'll be happy if existing Heat team continue working on it, having the
> full
> > control of the project, provided that we agree on functionality missing
> there
> > from Murano and Solum point of view and addition of this functionality
> in a
> > systematic way.
> >
> > Let me outline the main concern in regards to HOT from Murano
> perspective.
> > Others concerns could be figured out later. The typical use case for
> Murano is
> > the following:
> > Application writer sets a requirement for her application to use RDBMS
> > assuming that it can be MySQL, PostgreSQL or MSSQL. HOT engine should be
> able
> > to understand such requirements and be able to satisfy them by
> instantiating
> > instances with DB. End user should be able to control which particular
> type of
> > DB should be used. This is quite similar to abstract requirements
> described in
> > TOSCA. As Heat wants to cover TOSCA format too this Murano requirement is
> > pretty well aligned with what HOT\TOSCA can provide.
> >
> >
> > Hopefully this functionality can be introduced into HOT. Solum and
> Murano will
> > leverage it by using some common API, and implementing layer 3 as thin as
> > possible.
> >
> > Again, this is only suggested starting point, something to begin with.
> >
> Thanks for bring this discussion back to solving specific problems. The
> above database abstraction can be nicely represented using HOT
> environments and provider resources [1].
>
> Take the following template snippet:
>
> resources:
>   my_db:
> type: My::Database
> properties:
>   # ...
>
>   my_server
> type: OS::Nova::Server
> properties:
>   # ... including a {get_attr: [my_db, connection_url]}
>
> My::Database is a type defined in the environment which is included in
> the stack-create call. Different environments can provide different
> database implementations, for example:
>
> resource_registry:
>   "My::Database": path/to/trove_wrapper.yaml
>
> resource_registry:
>   "My::Database": path/to/nova_galera_ubercluster.yaml
>
> resource_registry:
>   "My::Database": path/to/postgresql.yaml
>
> Each of

[openstack-dev] [Mistral] Next crack at real workflows

[Dmitri Zimine]

Two more workflows drafted - cloud cron, and lifecycle, version 1. 

The mindset questions are: 
1) is DSL syntax expressive, and capable and convenient to handle real use 
cases?
2) most importantly: what are the implied workflow capabilities which make it 
all work? 
 
* Take a look here: 
https://github.com/dzimine/mistral-workflows/tree/add-usecases

* Leave your comments - generally, or  line-by-line, in the pull request  
https://github.com/dzimine/mistral-workflows/pull/1/files

* Fork, do your own modifications and do another pull request. 

* Or just reply with your comments  in email (lazy option :)) 

NOTE: please keep this thread for specific comments on DSL and workflow 
capabilities, create another thread if changing topic. Thanks! 

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

Re: [openstack-dev] [Heat] [Murano] [Solum] applications in the cloud

[Steve Baker]

On 03/04/14 10:39, Ruslan Kamaldinov wrote:
> This is a continuation of the "MuranoPL questions" thread.
>
> As a result of ongoing discussions, we figured out that definition of layers
> which each project operates on and has responsibility for is not yet agreed
> and discussed between projects and teams (Heat, Murano, Solum (in
> alphabetical order)).
>
> Our suggestion and expectation from this working group is to have such
> a definition of layers, agreement on it and an approach of reaching it.
>
> As a starting point, we suggest the following:
>
> There are three layers of responsibility:
> 1. Resources of the cloud
> 2. Applications of the cloud
> 3. Layers specific for Murano and Solum (to be further discussed and
>clarified, for this discussion it's out of scope)
>
> Layer 1 is obviously covered by Heat.
>
> Most of the disagreement is around layer 2. Our suggestion is to figure out
> the way where we can have common engine, DSL and approach to apps description.
> For this we'll take HOT and TOSCA as a basis and will work on addition of
> functionality missing from Murano and Solum point of view.
>
> We'll be happy if existing Heat team continue working on it, having the full
> control of the project, provided that we agree on functionality missing there
> from Murano and Solum point of view and addition of this functionality in a
> systematic way.
>
> Let me outline the main concern in regards to HOT from Murano perspective.
> Others concerns could be figured out later. The typical use case for Murano is
> the following:
> Application writer sets a requirement for her application to use RDBMS
> assuming that it can be MySQL, PostgreSQL or MSSQL. HOT engine should be able
> to understand such requirements and be able to satisfy them by instantiating
> instances with DB. End user should be able to control which particular type of
> DB should be used. This is quite similar to abstract requirements described in
> TOSCA. As Heat wants to cover TOSCA format too this Murano requirement is
> pretty well aligned with what HOT\TOSCA can provide.
>
>
> Hopefully this functionality can be introduced into HOT. Solum and Murano will
> leverage it by using some common API, and implementing layer 3 as thin as
> possible.
>
> Again, this is only suggested starting point, something to begin with.
>
Thanks for bring this discussion back to solving specific problems. The
above database abstraction can be nicely represented using HOT
environments and provider resources [1].

Take the following template snippet:

resources:
  my_db:
type: My::Database
properties:
  # ...

  my_server
type: OS::Nova::Server
properties:
  # ... including a {get_attr: [my_db, connection_url]}

My::Database is a type defined in the environment which is included in
the stack-create call. Different environments can provide different
database implementations, for example:

resource_registry:
  "My::Database": path/to/trove_wrapper.yaml

resource_registry:
  "My::Database": path/to/nova_galera_ubercluster.yaml

resource_registry:
  "My::Database": path/to/postgresql.yaml

Each of these templates could be implemented to have the same parameters
and outputs so the template will work with any of these resource
provider templates.

One thing we could consider adding to HOT is allow the defining of a
type interface, and validating that a given template/resource implements
its declared interfaces. However the above example works just fine
without interfaces, and this duck-typing approach may provide a better
user experience anyway.

[1] http://docs.openstack.org/developer/heat/template_guide/environment.html

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

Re: [openstack-dev] [ceilometer] PTL candidacy

[Sandy Walsh]

On 04/02/2014 05:47 PM, Gordon Chung wrote:
> I'd like to announce my candidacy for PTL of Ceilometer.

Woot!


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

Re: [openstack-dev] [Keystone] python-keystoneclient v3 functionality

[Jamie Lennox]

- Original Message -
> From: "Adam Young" 
> To: openstack-dev@lists.openstack.org
> Sent: Wednesday, 2 April, 2014 11:13:22 PM
> Subject: Re: [openstack-dev] [Keystone] python-keystoneclient v3  
> functionality
> 
> On 04/01/2014 07:36 AM, Yaguang Tang wrote:
> 
> 
> 
> Thanks Jamie,
> 
> then the following question is do we intend to move other services client
> library V3 identity support to python-openstackclient?
> AFAIK it's poorly supported for Nova Cinder Neutron client library, and I am
> working on add v3 support for those libraries[1], just
> want to make sure that is the correct direction.
> 
> [1] https://review.openstack.org/#/c/81749/
> https://review.openstack.org/#/c/81767/
> 
> 
> Sort of. The Keystone client should be responsible for all fo the service
> catalog manipulations throughout openstack. So the Cinder client should use
> the Keystone client.
> 
> To see the idea, read Jamie's blog post:
> 
> http://www.jamielennox.net/blog/2014/02/24/client-session-objects/
> 
> The main idea is that Keystone will handle the HTTP session setup, so that we
> have a single place to focus attention on for HTTP network security issues.
> And you should not need to parse the service catalog at all.
> 
> 

So Adam is right in that the general idea to transition people to using the V3 
API will be to use the keystoneclient.session.Session object and that will do 
everything for you. This is not going to be an easy transition for everyone and 
i've got a summit session proposed: http://summit.openstack.org/cfp/details/205 
in which i want to deal with precisely this problem. 

Regarding your notion of openstackclient though, you need to seperate the 
concept of a CLI and the library.

Take for example Heat or Horizon, they communicate with keystone through the 
python-keystoneclient and nova via the python-novaclient etc. They do not use 
the keystone or nova cli utility. The primary job of the python-*client 
libraries is NOT to provide a cli. The cli is just an application that makes 
use of the library. 

So yes, i think it has generally been accepted that the clients will move (at 
there own pace) to using openstackclient for there CLI, but openstackclient 
will still rely on the various libraries to do the actual communication with 
services. 


Jamie

> 
> 
> 2014-04-01 12:08 GMT+08:00 Jamie Lennox < jamielen...@redhat.com > :
> 
> 
> 
> On Tue, 2014-04-01 at 11:53 +0800, Yaguang Tang wrote:
> > Hi all,
> > 
> > 
> > I am sorry if this has been discussed before, the question is will we
> > support keystone v3 operation
> > in python-keystoneclient? I know most of the v3 functionality have
> > been implemented in python-openstackclient, but from the
> > python-openstackclient wiki says, it's primarily a wrapper of
> > python-*client, and provides unified interface to user. The end user
> > uses python-keystoneclient to manage
> > user, tenant, service before, if we don't intend to support v3
> > functionality in keystoneclient, then
> > it means we force end user to change from keystoneclient to
> > openstackclient, is this what we want to
> > do?
> > 
> 
> It depends what you mean by python-keystoneclient.
> 
> If you mean the python library then yes it supports the V3 API already.
> 
> If you mean the keystone CLI that is currently bundled as part of the
> python-keystoneclient then yes that is deprecated in favour of
> python-openstackclient.
> 
> We will maintain the CLI application in keystoneclient however even for
> V2 API calls I recommend that you use the openstack CLI tool.
> 
> Jamie
> 
> > 
> > --
> > Tang Yaguang
> > 
> > 
> > Canonical Ltd. | www.ubuntu.com | www.canonical.com
> > Mobile: +86 152 1094 6968
> > gpg key: 0x187F664F
> > 
> > ___
> > 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
> 
> 
> 
> --
> Tang Yaguang
> 
> Canonical Ltd. | www.ubuntu.com | www.canonical.com
> Mobile: +86 152 1094 6968
> gpg key: 0x187F664F
> 
> 
> ___
> 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] [Tuskar][Horizon] Javascript linter

[Michael Krotscheck]

+1 on talking to lawyers. 

Some more context: JSHint is a fork of JSLint, from which the problem license 
originates. The 
team has made a significant effort to strip out and replace JSLint code, 
however there remains
one file which they haven’t tackled yet. There’s a large discussion here, 
including a statement
where the author of the original license calls it “ineffective”.

https://github.com/jshint/jshint/issues/1234

Michael

On Apr 2, 2014, at 7:24 AM, Kevin Conway  wrote:

> I understand, and appreciate, the concern for licensing, but it would be a
> real shame to discount some of the most widely used linters because of a
> clause that prevents us from being evil.
> 
> Any chance we could run this by legal-disc...@lists.openstack.org and hear
> their reactions before we axe the JS*int projects from OpenStack?

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

Re: [openstack-dev] [Glance] PTL candidacy

[Anita Kuno]

confirmed

On 04/02/2014 06:51 PM, Mark Washenberger wrote:
> Hi all,
> 
> I'd like to submit myself as a candidate to continue in the role of Glance
> PTL for the Juno release cycle.
> 
> A bit of history about me: I joined Rackspace's Team Titan back in February
> 2011, where were initially focused on filling out the OpenStack 1.1 api for
> nova. I've been working with Glance apis and core functionality for about 5
> cycles now. Since November 2012 I've been an employee of Nebula, working
> alongside some of the original NASA OpenStack folks and the former Glance
> PTL Brian Waldon (until he left to go manufacture oreos).
> 
> As Juno PTL, I expect to proceed much in the same way as during Havana and
> Icehouse, hopefully with lots of realized opportunities for incremental
> improvement. I'm very open to any advice, suggestions, or other
> contributors who want to take on more responsibility in the near future.
> 
> Thank you,
> markwash
> 
> 
> 
> ___
> 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] PTL Candidacy

[Anita Kuno]

confirmed

On 04/02/2014 06:23 PM, Robert Collins wrote:
> I'm running for TripleO PTL again!
> 
> Over the last 6 months TripleO has come a long way in the last 6 months:
>  - CI on all changes (not yet gating)
>  - Persistent storage on nodes
>  - a significantly increased community
> 
> I've been thrilled to see our progress - and the more time we spend
> running running clouds the more feedback we generate to other
> OpenStack programs.
> 
> My view on PTL is unchanged from 6 months ago - it is an enabling
> position: working with the
> team to identify blockers, constraints issues and weak points in the
> (design/code/architecture) and then respectively remove/socialise and
> target them.
> 
> I think I fell short of that aspiration in the last cycle, and commit
> to doing better if I am elected.
> 
> For folk who are new to the community in the last 6 months, this was
> my platform last time -
> http://lists.openstack.org/pipermail/openstack-dev/2013-September/015431.html
> 
> 
> Last cycle I said "
> Icehouse is the first opportunity we'll have to have a fully
> functional story, and even now thats still a fairly aggressive goal :
> my focus over the next 6 months will be getting us out of fire-drill
> mode and into the steady-state that is needed for confident
> deployments... in addition to fleshing out the features required for
> Tuskar, overcloud upgrades and undercloud upgrades. That means, in big
> ticket items...
> "
> 
> I believe the delivery of scaled CI has been a crucial step - we no
> longer break ourselves, and we find out quickly when changes elsewhere
> in openstack break the tripleo tooling. Thats been invaluable so far -
> and will be more so as we broaden CI and make it voting and then
> gating.
> 
> 
> To my mind over the next 6 months we need to focus on
> 
> * Continuing the CI path
> * HA of everything out of the box
> * Graceful upgrades
> * pushing our deployment experience feedback to the project we deploy
> * expanding our coverage to deploy everything
> * Migrating to Tuskar for everything but the deployment of the seed
> 
> Obviously, if you have questions please ask!
> 
> -Rob
> 


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

[openstack-dev] [Glance] PTL candidacy

[Mark Washenberger]

Hi all,

I'd like to submit myself as a candidate to continue in the role of Glance
PTL for the Juno release cycle.

A bit of history about me: I joined Rackspace's Team Titan back in February
2011, where were initially focused on filling out the OpenStack 1.1 api for
nova. I've been working with Glance apis and core functionality for about 5
cycles now. Since November 2012 I've been an employee of Nebula, working
alongside some of the original NASA OpenStack folks and the former Glance
PTL Brian Waldon (until he left to go manufacture oreos).

As Juno PTL, I expect to proceed much in the same way as during Havana and
Icehouse, hopefully with lots of realized opportunities for incremental
improvement. I'm very open to any advice, suggestions, or other
contributors who want to take on more responsibility in the near future.

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

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed.

[Jorge Miramontes]

Thanks Eugene,

I added our data onto the requirements page since I was hoping to prioritize 
requirements based on the operator data that gets provided. We can move it over 
to the other page if you think that makes sense. See everyone on the weekly 
meeting tomorrow!

Cheers,
--Jorge

From: Susanne Balle mailto:sleipnir...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 1, 2014 4:09 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data 
from Operators needed.

I added two more. I am still working on our HA use cases. Susanne


On Tue, Apr 1, 2014 at 4:16 PM, Fox, Kevin M 
mailto:kevin@pnnl.gov>> wrote:
I added our priorities. I hope its formatted well enough. I just took a stab in 
the dark.

Thanks,
Kevin

From: Eugene Nikanorov [enikano...@mirantis.com]
Sent: Tuesday, April 01, 2014 3:02 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from 
Operators needed.

Hi folks,

On the last meeting we decided to collect usage data so we could prioritize 
features and see what is demanded most.

Here's the blank page to do that (in a free form). I'll structure it once we 
have some data.
https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases

Please fill with the data you have.

Thanks,
Eugene.

___
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] [Murano] [Solum] applications in the cloud

[Clint Byrum]

Excerpts from Ruslan Kamaldinov's message of 2014-04-02 14:39:17 -0700:
> This is a continuation of the "MuranoPL questions" thread.
> 
> As a result of ongoing discussions, we figured out that definition of layers
> which each project operates on and has responsibility for is not yet agreed
> and discussed between projects and teams (Heat, Murano, Solum (in
> alphabetical order)).
> 
> Our suggestion and expectation from this working group is to have such
> a definition of layers, agreement on it and an approach of reaching it.
> 
> As a starting point, we suggest the following:
> 
> There are three layers of responsibility:
> 1. Resources of the cloud
> 2. Applications of the cloud
> 3. Layers specific for Murano and Solum (to be further discussed and
>clarified, for this discussion it's out of scope)
> 
> Layer 1 is obviously covered by Heat.
> 
> Most of the disagreement is around layer 2. Our suggestion is to figure out
> the way where we can have common engine, DSL and approach to apps description.
> For this we'll take HOT and TOSCA as a basis and will work on addition of
> functionality missing from Murano and Solum point of view.
> 
> We'll be happy if existing Heat team continue working on it, having the full
> control of the project, provided that we agree on functionality missing there
> from Murano and Solum point of view and addition of this functionality in a
> systematic way.
> 
> Let me outline the main concern in regards to HOT from Murano perspective.
> Others concerns could be figured out later. The typical use case for Murano is
> the following:
> Application writer sets a requirement for her application to use RDBMS
> assuming that it can be MySQL, PostgreSQL or MSSQL. HOT engine should be able
> to understand such requirements and be able to satisfy them by instantiating
> instances with DB. End user should be able to control which particular type of
> DB should be used. This is quite similar to abstract requirements described in
> TOSCA. As Heat wants to cover TOSCA format too this Murano requirement is
> pretty well aligned with what HOT\TOSCA can provide.
> 

IMO that is too high level for Heat. Heat speaks to APIs. It has a few of
its own that are low-level generic facilities, or high level left-over's
from the early days that all have better native replacements.

If there is no API to get a PostgreSQL or MSSQL database, then there is
no PostgreSQL or MSSQL database for Heat. What there may be is an API to
get a server and configure it. And Providers can handle the abstraction.
However,Heat isn't specifically going to ever know how one resource is
going to depend on another. It is just going to obey your commands to
create them and share configuration between them.

Meanwhile, Trove is the place to drive database as a service features.

> 
> Hopefully this functionality can be introduced into HOT. Solum and Murano will
> leverage it by using some common API, and implementing layer 3 as thin as
> possible.
> 

I'm not really sure what is missing from HOT that you need. With
providers you should be able to achieve anything you need around
portability.

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

[openstack-dev] [TripleO] PTL Candidacy

[Robert Collins]

I'm running for TripleO PTL again!

Over the last 6 months TripleO has come a long way in the last 6 months:
 - CI on all changes (not yet gating)
 - Persistent storage on nodes
 - a significantly increased community

I've been thrilled to see our progress - and the more time we spend
running running clouds the more feedback we generate to other
OpenStack programs.

My view on PTL is unchanged from 6 months ago - it is an enabling
position: working with the
team to identify blockers, constraints issues and weak points in the
(design/code/architecture) and then respectively remove/socialise and
target them.

I think I fell short of that aspiration in the last cycle, and commit
to doing better if I am elected.

For folk who are new to the community in the last 6 months, this was
my platform last time -
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015431.html


Last cycle I said "
Icehouse is the first opportunity we'll have to have a fully
functional story, and even now thats still a fairly aggressive goal :
my focus over the next 6 months will be getting us out of fire-drill
mode and into the steady-state that is needed for confident
deployments... in addition to fleshing out the features required for
Tuskar, overcloud upgrades and undercloud upgrades. That means, in big
ticket items...
"

I believe the delivery of scaled CI has been a crucial step - we no
longer break ourselves, and we find out quickly when changes elsewhere
in openstack break the tripleo tooling. Thats been invaluable so far -
and will be more so as we broaden CI and make it voting and then
gating.


To my mind over the next 6 months we need to focus on

* Continuing the CI path
* HA of everything out of the box
* Graceful upgrades
* pushing our deployment experience feedback to the project we deploy
* expanding our coverage to deploy everything
* Migrating to Tuskar for everything but the deployment of the seed

Obviously, if you have questions please ask!

-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] [ceilometer] PTL candidacy

[Anita Kuno]

confirmed

On 04/02/2014 04:47 PM, Gordon Chung wrote:
> hi,
> 
> i'd like to announce my candidacy for PTL of Ceilometer.
> 
> as a little background, i've been a contributor to OpenStack for the past 
> year and a half and have been primarily focused on Ceilometer for the past 
> two cycles where i've been a core contributor. i contribute regularly to 
> the project with code [1] and am one of the top reviewers [2]. i am also a 
> developer at IBM where i work on the IBM software standards team, building 
> standards such as the Cloud Audit Data Federation Working Group (CADF) 
> specification.
> 
> there's a great deal to be discussed at the upcoming summit and i'm sure 
> Ceilometers' contributors and deployers have a lot of ideas. in addition 
> to those, i think some key items to focus on are:
> 
> - improving collector performance in Ceilometer. this has been a major 
> item in Ceilometer recently as we tried to expand our integration tests in 
> tempest and have found there are inefficiencies in how Ceilometer is 
> collecting data. Ceilometer should be a lightweight service, capable of 
> processing heavy load and we need to ensure it can handle this. i'd like 
> to revisit our models (to ensure our model match what operators require) 
> and build our backends around this so they are highly tuned to writes and 
> reads for these use cases.
> - improving polling agents. the compute agent currently creates a heavy 
> load on compute-api[3] and the central agent has it's own performance and 
> HA issues... it's something we should really considering looking at.
> - continue to expand tempest testing in ceilometer. the tempest tests have 
> been helpful in identifying gaps/performance issues and will help later in 
> identifying regression.
> - review how we log in Ceilometer. we have a very repetitive framework 
> design so our logs can be extremely overwhelming or extremely sparse. 
> 
> some other items to track (depending on resource) are:
> 
> - enhancing event support. there is a framework for events in Ceilometer 
> but there is work to be done to make it a true monitoring tool. we have a 
> few blueprints existing in Ceilometer that should help.
> - re-evaluating the alarming service. we currently require two services to 
> run for alarms, a notifier and an evaluator which also depends on the 
> ceilometerclient. there is an interesting bp to move some alarm logic to 
> the pipeline and i think we should take a look at it to see if it provides 
> a cleaner, leaner solution.[4]. if not, we should work on documenting our 
> current implementation.
> 
> [1] 
> https://review.openstack.org/#/q/owner:chungg+status:merged+project:openstack/ceilometer,n,z
> [2] http://russellbryant.net/openstack-stats/ceilometer-reviewers-365.txt
> [3] 
> http://openstack-in-production.blogspot.ca/2014/03/cern-cloud-architecture-update-for.html
> [4] https://blueprints.launchpad.net/ceilometer/+spec/alarm-pipelines
> 
> cheers,
> gordon chung
> openstack, ibm software standards
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

[openstack-dev] [Heat] [Murano] [Solum] applications in the cloud

[Ruslan Kamaldinov]

This is a continuation of the "MuranoPL questions" thread.

As a result of ongoing discussions, we figured out that definition of layers
which each project operates on and has responsibility for is not yet agreed
and discussed between projects and teams (Heat, Murano, Solum (in
alphabetical order)).

Our suggestion and expectation from this working group is to have such
a definition of layers, agreement on it and an approach of reaching it.

As a starting point, we suggest the following:

There are three layers of responsibility:
1. Resources of the cloud
2. Applications of the cloud
3. Layers specific for Murano and Solum (to be further discussed and
   clarified, for this discussion it's out of scope)

Layer 1 is obviously covered by Heat.

Most of the disagreement is around layer 2. Our suggestion is to figure out
the way where we can have common engine, DSL and approach to apps description.
For this we'll take HOT and TOSCA as a basis and will work on addition of
functionality missing from Murano and Solum point of view.

We'll be happy if existing Heat team continue working on it, having the full
control of the project, provided that we agree on functionality missing there
from Murano and Solum point of view and addition of this functionality in a
systematic way.

Let me outline the main concern in regards to HOT from Murano perspective.
Others concerns could be figured out later. The typical use case for Murano is
the following:
Application writer sets a requirement for her application to use RDBMS
assuming that it can be MySQL, PostgreSQL or MSSQL. HOT engine should be able
to understand such requirements and be able to satisfy them by instantiating
instances with DB. End user should be able to control which particular type of
DB should be used. This is quite similar to abstract requirements described in
TOSCA. As Heat wants to cover TOSCA format too this Murano requirement is
pretty well aligned with what HOT\TOSCA can provide.


Hopefully this functionality can be introduced into HOT. Solum and Murano will
leverage it by using some common API, and implementing layer 3 as thin as
possible.

Again, this is only suggested starting point, something to begin with.


Thanks,
Ruslan

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

Re: [openstack-dev] [heat] metadata for a HOT

[Zane Bitter]

On 02/04/14 16:45, Mike Spreitzer wrote:

I would like to suggest that a metadata section be allowed at the top
level of a HOT.  Note that while resources in a stack can have metadata,
there is no way to put metadata on a stack itself.  What do you think?


I think that if you're going to propose a new feature, you should at 
least give us a clue who you think is going to use it and what for ;)


IIRC this has been discussed in the past and the justifications for 
including it in the template (as opposed to allowing metadata to be 
attached in the ReST API, as other projects already do for many things) 
were not compelling.


cheers,
Zane.

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

[openstack-dev] [ceilometer] PTL candidacy

[Gordon Chung]

hi,

i'd like to announce my candidacy for PTL of Ceilometer.

as a little background, i've been a contributor to OpenStack for the past 
year and a half and have been primarily focused on Ceilometer for the past 
two cycles where i've been a core contributor. i contribute regularly to 
the project with code [1] and am one of the top reviewers [2]. i am also a 
developer at IBM where i work on the IBM software standards team, building 
standards such as the Cloud Audit Data Federation Working Group (CADF) 
specification.

there's a great deal to be discussed at the upcoming summit and i'm sure 
Ceilometers' contributors and deployers have a lot of ideas. in addition 
to those, i think some key items to focus on are:

- improving collector performance in Ceilometer. this has been a major 
item in Ceilometer recently as we tried to expand our integration tests in 
tempest and have found there are inefficiencies in how Ceilometer is 
collecting data. Ceilometer should be a lightweight service, capable of 
processing heavy load and we need to ensure it can handle this. i'd like 
to revisit our models (to ensure our model match what operators require) 
and build our backends around this so they are highly tuned to writes and 
reads for these use cases.
- improving polling agents. the compute agent currently creates a heavy 
load on compute-api[3] and the central agent has it's own performance and 
HA issues... it's something we should really considering looking at.
- continue to expand tempest testing in ceilometer. the tempest tests have 
been helpful in identifying gaps/performance issues and will help later in 
identifying regression.
- review how we log in Ceilometer. we have a very repetitive framework 
design so our logs can be extremely overwhelming or extremely sparse. 

some other items to track (depending on resource) are:

- enhancing event support. there is a framework for events in Ceilometer 
but there is work to be done to make it a true monitoring tool. we have a 
few blueprints existing in Ceilometer that should help.
- re-evaluating the alarming service. we currently require two services to 
run for alarms, a notifier and an evaluator which also depends on the 
ceilometerclient. there is an interesting bp to move some alarm logic to 
the pipeline and i think we should take a look at it to see if it provides 
a cleaner, leaner solution.[4]. if not, we should work on documenting our 
current implementation.

[1] 
https://review.openstack.org/#/q/owner:chungg+status:merged+project:openstack/ceilometer,n,z
[2] http://russellbryant.net/openstack-stats/ceilometer-reviewers-365.txt
[3] 
http://openstack-in-production.blogspot.ca/2014/03/cern-cloud-architecture-update-for.html
[4] https://blueprints.launchpad.net/ceilometer/+spec/alarm-pipelines

cheers,
gordon chung
openstack, ibm software standards___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] metadata for a HOT

[Mike Spreitzer]

I would like to suggest that a metadata section be allowed at the top 
level of a HOT.  Note that while resources in a stack can have metadata, 
there is no way to put metadata on a stack itself.  What do you think?

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

Re: [openstack-dev] [Neutron LBaaS] Need help with LBaaS drivers

[Vijay B]

Hi VijayV, Oleg!

Thanks for the pointers! It turns out I had to put in an __init__.py in the
dummy/ directory, else the driver wouldn't get loaded. Now I see newer
issues, and am trying to fix those. I'll ping back on how that goes and if
I have any questions..

Cheers!
Regards,
Vijay


On Wed, Apr 2, 2014 at 1:34 AM, Oleg Bondarev wrote:

> Hi Vijay,
>
> Currently you may follow two ways in writing an LBaaS driver:
> 1) write it from scratch (like Radware, Netscaler, Embrane drivers) -
> in this case your driver should inherit 
> abstract_driver.LoadBalancerAbstractDriver
> and
> will be running on Neutron service process, LBaaS agent won't be used.
> So you should restart not q-lbaas but q-svc process in order for new
> driver to be used and it should work with the steps you've described.
>
> 2) leverage
> neutron/services/loadbalancer/drivers/common/agent_drive_base.py framework
> and in fact write only device driver which inheritits
>
> neutron.services.loadbalancer.agent.agent_device_driver.AgentDeviceDriver.
> This is how HAProxy driver is implemented, please see
> neutron/services/loadbalancer/drivers/haproxy/plugin_driver.py
> and namespace_driver.py (this is device driver).
> Along with updating service_provider in neutron.conf you should also
> add your device driver to lbaas_agent.ini file (again please check how it
> is done for haproxy)
> In this case your driver will be running on LBaaS agent and you should
> restart both q-svc and q-lbaas.
>
> Generally, the second approach is preferable as it's better scalable and
> provides you a built-in async mechanism.
>
> Thanks,
> Oleg
>
>
> On Wed, Apr 2, 2014 at 5:44 AM, Vijay B  wrote:
>
>> Hi,
>>
>>
>> I'm trying to understand how LBaaS drivers work and so am attempting to
>> write a dummy driver that does nothing for now, but instead of loading my
>> dummy driver, neutron always loads the HAProxy namespace driver. These are
>> the steps I followed:
>>
>>
>> 1) I created a new directory
>> neutron/services/loadbalancer/drivers/dummy/, and in that directory I
>> put in a new file dummy_driver.py, which basically has a class class
>> DummyPluginDriver(abstract_driver.LoadBalancerAbstractDriver):
>>
>> and has empty __init__(), create_vip(), delete_vip() etc functions.
>>
>>
>> 2) I'm testing using a devstack setup, so I also edited the
>> /etc/neutron/neutron.conf file, commenting out the default loadbalancer
>> driver entry for HAProxy, and added a line for my dummy driver as follows:
>>
>>
>>
>> service_provider=LOADBALANCER:Dummy:neutron.services.loadbalancer.drivers.dummy.dummy_driver.DummyPluginDriver:default
>>
>>
>>
>> 3) I created a /etc/neutron/services/loadbalancer/dummy/lbaas_agent.ini
>> directory/file
>>
>> I simply copied over the haproxy's lbaas_agent.ini file and changed
>> [haproxy] to [dummy]
>>
>> and then I restarted the q-lbaas service using cd /opt/stack/neutron &&
>> python /usr/local/bin/neutron-lbaas-agent --config-file
>> /etc/neutron/neutron.conf
>> --config-file=/etc/neutron/services/loadbalancer/dummy/lbaas_agent.ini
>>
>>
>>
>> However, I see that the default HAProxyNS driver is still being loaded
>>
>> When I put a breakpoint in loadbalancer/agent/agent_manager.py:86, I see
>> this (relevant text marked in red):
>>
>>
>>
>> 2014-03-31 13:47:16.998 DEBUG neutron.common.utils [-] Reloading cached
>> file /etc/neutron/policy.json from (pid=28405) read_cached_file
>> /opt/stack/neutron/neutron/common/utils.py:53
>>
>> 2014-03-31 13:47:16.998 DEBUG neutron.policy [-] Loading policies from
>> file: /etc/neutron/policy.json from (pid=28405) _set_rules
>> /opt/stack/neutron/neutron/policy.py:89
>>
>> >
>> /opt/stack/neutron/neutron/services/loadbalancer/agent/agent_manager.py(86)_load_drivers()
>>
>> -> self.device_drivers = {}
>>
>> (Pdb) l
>>
>>  81 # pool_id->device_driver_name mapping used to store known
>> instances
>>
>>  82 self.instance_mapping = {}
>>
>>  83
>>
>>  84 def _load_drivers(self):
>>
>>  85 import pdb; pdb.set_trace()
>>
>>  86  -> self.device_drivers = {}
>>
>>  87 for driver in self.conf.device_driver:
>>
>>  88 try:
>>
>>  89 driver_inst = importutils.import_object(
>>
>>  90 driver,
>>
>>  91 self.conf,
>>
>> (Pdb) self.conf.device_driver
>>
>>
>> ['neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver']
>>
>> (Pdb)
>>
>>
>> I'm not sure what I'm doing wrong - am I missing something that needs to
>> be done within the dummy driver itself? (in dummy_driver.py?). Should I
>> register some opts or similar?
>>
>>
>> Any help would be much appreciated!
>>
>>
>>
>>  Thanks,
>>
>> Regards,
>>
>> Vijay
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _

[openstack-dev] [QA] Meeting Thursday April 3rd at 22:00UTC

[Matthew Treinish]

Just a quick reminder that the weekly OpenStack QA team IRC meeting will be
tomorrow Thursday, April 3rd at 22:00 UTC in the #openstack-meeting channel.

The agenda for tomorrow's meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
Anyone is welcome to add an item to the agenda.

To help people figure out what time 22:00 UTC is in other timezones tomorrow's
meeting will be at:

18:00 EDT
07:00 JST
08:30 ACDT
23:00 CET
17:00 CDT
15:00 PDT

-Matt Treinish

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

Re: [openstack-dev] Summit session for config validation and diagnostic

[Boris Pavlovic]

Oleg,

Seems like very interesting topic.

Especially I am interested in how could be this integrated with production
clouds (could it be run on controllers?). What API it present and is there
integration with horizon?



Best regards,
Boris Pavlovic


On Wed, Apr 2, 2014 at 11:20 PM, Oleg Gelbukh  wrote:

> Hello, OpenStack developers
>
> Everyone knows that finding out the root cause of some failure in
> OpenStack with many projects interacting with each other and external
> components could be serious challenge even for seasoned stacker. I've seen
> more than one attempt to attack this task since I joined this community
> (including our own project Rubick).
>
> Now I want to make somewhat bold attempt to bring all interested parties
> face to face in Atlanta during a summit session in 'Other projects' track:
>
> http://summit.openstack.org/cfp/details/208
>
> I see it as a good place to coordinate efforts scattered across multiple
> projects now. Let's find out what are most important and common use cases
> for us, and outline how we're going to solve them.
>
> What do you think?
>
> --
> Best regards,
> Oleg Gelbukh
> Mirantis Labs
>
> ___
> 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][ML2][Ml2Plugin] Setting _original_network in NetworkContext:

[Andre Pech]

On Fri, Mar 28, 2014 at 6:44 PM, Nader Lahouti wrote:

> Hi Mathieu,
>
> Thanks a lot for your reply.
>
> Even in the neutron/neutron/db/db_base_plugin_v2.py: create_network()
> passes network object:
>
> 911 
> 
> *def* create_network 
> (self 
> , context 
> , network 
> ):912 
> 
> """Handle creation of a single network."""913 
> 
> # single request processing914 
> 
> n = network 
> ['network']   
> * 'n' has all the network info (including extensions)*915 
> 
> # NOTE(jkoelker) Get the tenant_id outside of the session to avoid916 
> 
> #unneeded db action if the operation raises917 
> 
> tenant_id  
> = self 
> ._get_tenant_id_for_create
>  
> (context
>  , n)918 
> 
> *with* context 
> .session 
> .begin 
> (subtransactions 
> =True 
> ):919 
> 
> args  = 
> {'tenant_id': tenant_id 
> ,920 
> 
> 'id': n.get 
> ('id') *or* uuidutils 
> .generate_uuid
>  (),921 
> 
> 'name': n['name'],922 
> 
> 'admin_state_up': n['admin_state_up'],923 
> 
> 'shared': n['shared'],924 
> 
> 'status': n.get 
> ('status', constants 
> .NET_STATUS_ACTIVE
>  )}925 
> 
> network  
> = models_v2 
> .Network
>  (**args 
> )  <<*= 'network' does 
> not include extensions.*926 
> 
> context 
> .session 
> .add 
> (network 
> )927 
> 
> *return* self 
> ._make_network_dict 
> (network
>  

[openstack-dev] Summit session for config validation and diagnostic

[Oleg Gelbukh]

Hello, OpenStack developers

Everyone knows that finding out the root cause of some failure in OpenStack
with many projects interacting with each other and external components
could be serious challenge even for seasoned stacker. I've seen more than
one attempt to attack this task since I joined this community (including
our own project Rubick).

Now I want to make somewhat bold attempt to bring all interested parties
face to face in Atlanta during a summit session in 'Other projects' track:

http://summit.openstack.org/cfp/details/208

I see it as a good place to coordinate efforts scattered across multiple
projects now. Let's find out what are most important and common use cases
for us, and outline how we're going to solve them.

What do you think?

--
Best regards,
Oleg Gelbukh
Mirantis Labs
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara] team meeting April 3 1800 UTC [savanna]

[Dmitry]

Hi,
I'm wondering if you have plans to use Murano for a cluster management?
Thanks,
Dmitry


On Wed, Apr 2, 2014 at 4:48 PM, Sergey Lukjanov wrote:

> Hi folks,
>
> We'll be having the Sahara team meeting as usual in
> #openstack-meeting-alt channel.
>
> Agenda:
> https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Agenda_for_April.2C_3
>
>
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20140403T18
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Mirantis Inc.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Support for multiple sort keys and sort directions in REST GET APIs

[Steven Kaufer]

I have proposed blueprints in both nova and cinder for supporting multiple
sort keys and sort directions for the GET APIs (servers and volumes).  I am
trying to get feedback from other projects in order to have a more uniform
API across services.

Problem description from nova proposal:

"There is no support for retrieving server data in a specific order, it is
defaulted to descending sort order by the "created date" and "id" keys. In
order to retrieve data in any sort order and direction, the REST APIs need
to accept multiple sort keys and directions.

Use Case: A UI that displays a table with only the page of data that it has
retrieved from the server. The items in this table need to be sorted by
status first and by display name second. In order to retrieve data in this
order, the APIs must accept multiple sort keys/directions."

See nova proposal .rst file (cinder is basically the same) for more
information:  https://review.openstack.org/#/c/84451/

Most projects have similar GET requests and I am trying to get some
consensus on this approach across the various projects; the goal is to have
this type of functionality common across projects (not just nova and
cinder).  Note that some projects (ie, cinder) already support a single
sort key and sort direction, see
https://github.com/openstack/cinder/blob/master/cinder/api/v2/volumes.py#L212-L213

Note that the DB layer already accepts multiple sort keys and sort
directions (see
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/utils.py#L62),
 the work I am describing here only exposes the sorting options at the REST
API layer.

Please provide feedback on this direction.  Specifically, do you see any
issues (and, if so, why) with allowing the caller to specify sort orders
and directions on the GET APIs?

Feel free to leave your feedback in the Gerrit review for the nova
blueprint or reply to this thread.

Thanks,

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

Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

[Monty Taylor]

On 04/02/2014 11:05 AM, Ana Krivokapic wrote:

On 04/02/2014 07:36 PM, Dougal Matthews wrote:



On my phone so I can't follow this up more now, but it looks like
JSHint is already used.

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



That commit has since been reverted and JSHint removed from Horizon
codebase:
https://bugs.launchpad.net/horizon/+bug/1270764
https://review.openstack.org/#/c/68268/

Seems like there's some controversy around whether the licenses are
actually incompatible or not. How do we go about clearing that up? :)



I was a little unclear before.

Two things:

- We should use the same stuff we've put together for storyboard

- It is not needed to include jshint in the codebase to be able to use it

To expand on the second point - we've found tooling to allow us to 
integrate things like jshint into python virtualenv (just go ahead and 
be amazed) So it's entirely possible to do _ALL_ of this in a way that 
is consistent with how we work in OpenStack. Check out these two patches 
to zuul:


https://review.openstack.org/#/c/82307/
https://review.openstack.org/#/c/82308/

Which show incorporating it into a standing python project. If I get a 
chance this weekend - I can try to cook up a similar one for 
horizon/tuskar if nobody beats me to it.


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

Re: [openstack-dev] [All][Keystone] Deprecation of the v2 API

[Kevin L. Mitchell]

On Wed, 2014-04-02 at 17:08 +, Tim Bell wrote:
> I’ve added the depreciation process to the section on meet the PTLs/TC
> for the Atlanta Ops unconference
> (https://etherpad.openstack.org/p/ATL-ops-unconference-RFC).
> Currently, it is difficult to tell how much a particular feature is
> being used and the impact of depreciation.

Exercising my penchant for precision: "depreciation" or "deprecation"?
I hope that the openstack code base isn't depreciating, even if parts of
it are being deprecated :)
-- 
Kevin L. Mitchell 
Rackspace


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

Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

[Ana Krivokapic]

On 04/02/2014 07:36 PM, Dougal Matthews wrote:



On my phone so I can't follow this up more now, but it looks like 
JSHint is already used.


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



That commit has since been reverted and JSHint removed from Horizon 
codebase:

https://bugs.launchpad.net/horizon/+bug/1270764
https://review.openstack.org/#/c/68268/

Seems like there's some controversy around whether the licenses are 
actually incompatible or not. How do we go about clearing that up? :)


--
Regards,

Ana Krivokapic
Associate Software Engineer
OpenStack team
Red Hat Inc.


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

Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

[Dougal Matthews]

On my phone so I can't follow this up more now, but it looks like JSHint is 
already used.


https://review.openstack.org/#/c/41087/___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] icehouse-rc1 libvirt broken - VIR_DOMAIN_START_PAUSED

[Russell Bryant]

On 04/02/2014 12:37 PM, iain macdonnell wrote:
> I tried icehouse-rc1 in my libvirt-Xen environment, and found that
> instance launches were failing. Some digging determined that it was
> caused by use of the libvirt VIR_DOMAIN_START_PAUSED flag, which is
> not supported with Xen. I was about to report this when Google found:
> 
> https://bugs.launchpad.net/nova/+bug/1301453
> 
> I realise that libvirt-Xen is "Group C", but I think this is a
> show-stopping issue, and it seems to affect platforms other than Xen
> (maybe anything other than Qemu/KVM), based on Andrew's bug report.

Given that these platforms are "group C" (untested), I do not consider
this a release blocker.  If it gets fixed, that would be great.
Otherwise, it will just have be noted as a known issue in the initial
Icehouse release and fixed later with a backport.

In the meantime, I have added this as a known issue for Nova here:

https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse

-- 
Russell Bryant

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

Re: [openstack-dev] Missleading and hardly parseable default neutron config files

[Thomas Goirand]

On 04/02/2014 06:38 PM, Salvatore Orlando wrote:
> Hi Thomas,
> 
> it probably won't be a bad idea if you can share the patches you're
> applying to the default configuration files.
> I think all distros are patching them anyway, so this might allow us to
> provide mostly ready to use config files.
> 
> Is there a chance you can push something to gerrit?
> 
> Salvatore

Hi,

here it is:
https://review.openstack.org/84809

If only a subset of my changes are accepted, that's already some
progress for me. I will also enjoy comments, so feel free to let me know
if what I'm doing is stupid! :)

Thomas


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

Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

[Monty Taylor]

I agree - it's not a viral license, and we're not shipping it anyway.

I'm going to go back to the original thing:

"
Recently we have been discussing the topic of Javascript linters for 
Horizon and Tuskar-UI with Radomir, and he told me that JSLint and 
JSHint can not be integrated into the test environment due to some 
license issues."


This is just not true. In fact, we have a full grunt-based jslint gate 
on storyboard-webclient running in infra currently. It's integrated with 
tox even.


I suggest:

a) use jslint
b) use it via grunt
c) use grunt via tox and nodeenv
d) use the job templates we have in infra to run this sort of thing

I'm happy to help point people to how this works.

On 04/02/2014 09:10 AM, Adam Nelson wrote:

I don't see why the license of a piece of software used to check the
codebase (i.e. the linter) infects the codebase being checked.  That
would be like saying the Google terms of service under which I'm writing
this email (Google Apps) infects the codebase.

--
Kili - Cloud for Africa: kili.io 
Musings: twitter.com/varud 
More Musings: varud.com 
About Adam: www.linkedin.com/in/adamcnelson



On Wed, Apr 2, 2014 at 6:53 PM, Ben Nemec mailto:openst...@nemebean.com>> wrote:

I think that would be a good idea.  We're not shipping this, we're
just using it in test (AIUI), so I don't think incompatibility with
the OpenStack license is necessarily an issue.  But IANAL. :-)

-Ben


On 04/02/2014 09:24 AM, Kevin Conway wrote:

I understand, and appreciate, the concern for licensing, but it
would be a
real shame to discount some of the most widely used linters
because of a
clause that prevents us from being evil.

Any chance we could run this by
legal-discuss@lists.openstack.__org
 and hear
their reactions before we axe the JS*int projects from OpenStack?

On 4/2/14 8:43 AM, "Radomir Dopieralski" mailto:openst...@sheep.art.pl>> wrote:

On 02/04/14 15:26, Kevin Conway wrote:

What licensing issues were brought up that prevent the
use of JSLint or
JSHint? Both are MIT licensed.

Granted, JSLint has an additional clause:

  The Software shall be used for Good, not Evil.


Maybe that's it? If so, Crockford has been known to make
exceptions for
organizations that wish to use his code for potentially evil
purposes:

https://www.youtube.com/watch?__v=-C-JoyNuQJs&feature=player___detailpage#t=2


480s.


Yes, that's exactly it. An exception is not enough -- that
clause simply
makes that license incompatible with OpenStack's license. To
use it, we
would need to change OpenStack's license too, and it quickly
becomes
quite complex.

You have to remember that organizations like NSA use
OpenStack, so we
can't possibly include that clause in its license ;)

--
Radomir Dopieralski


_
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] [All][Keystone] Deprecation of the v2 API

[Tim Bell]

I’ve added the depreciation process to the section on meet the PTLs/TC for the 
Atlanta Ops unconference 
(https://etherpad.openstack.org/p/ATL-ops-unconference-RFC). Currently, it is 
difficult to tell how much a particular feature is being used and the impact of 
depreciation.

Tim


Sessions are great, but shouldn't be the only forum, nor should it be a
place any decisions are actually made, IMO, given that not everyone can
be present.  It's one place of many used to gather input before making
an informed decision.

++ I intended to suggest it as a supplementary approach for gathering feedback.


--
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] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Okay, cool! I'll... Tks!


On 2 April 2014 12:49, Collins, Sean wrote:

> On Wed, Apr 02, 2014 at 11:40:39AM EDT, Martinx - ジェームズ wrote:
> > But, can this current "neutron-ipv6.patch" at least, be used to enable
> > Neutron IPv6 with RA (--ipv6_ra_mode slaac --ipv6_address_mode slaac) ?
>
> No, because even if you solved all the merge conflicts, the
> tests were not passing in the last patch set.
>
> Keep an eye on the ML and the subteam IRC meeting, I'll make sure to add
> an agenda item for next week to discuss backporting potential.
>
> --
> Sean M. Collins
> ___
> 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] [Nova] icehouse-rc1 libvirt broken - VIR_DOMAIN_START_PAUSED

[iain macdonnell]

I tried icehouse-rc1 in my libvirt-Xen environment, and found that
instance launches were failing. Some digging determined that it was
caused by use of the libvirt VIR_DOMAIN_START_PAUSED flag, which is
not supported with Xen. I was about to report this when Google found:

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

I realise that libvirt-Xen is "Group C", but I think this is a
show-stopping issue, and it seems to affect platforms other than Xen
(maybe anything other than Qemu/KVM), based on Andrew's bug report.

~iain

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

Re: [openstack-dev] [Murano] MuranoPL => UML visualization <- best implementation practices?

[Dmitry Teselkin]

On Wed, Apr 2, 2014 at 7:54 PM, Ed Cranford wrote:

> Granted, it'll take some work to build a similar visual style--I see
> elaborate record nodes in your future--but you don't have to be bound to
> PlantUML if you don't want to be.
> I've used Graphviz before for a few applications, and if I can help get
> you started with building dot files, let me know.
>

Actually I've tried to generate GraphViz input data (in .dot format)
directly from MuranoPL manifests, and the result was a little
disappointment. Graphs looked fine until the number of nodes were
relatively small (less then 4), and dependencies between them remain
linear. As soon as the number of nodes increases, or cross links appears,
the graph becomes a mess. So that's why we decided to look for some
external tool. And now we trying to find another tool which doesn't
requires such heavy dependencies as Java. :)

I'm not shure that writing our own tool worth it, however I might be wrong
here.



-- 
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Missleading and hardly parseable default neutron config files

[Thomas Goirand]

On 04/02/2014 11:01 PM, Solly Ross wrote:
> IMHO, having "Example:" on a separate line from the actual option is a lot 
> easier for humans:
> you just delete a single character or use your editor-of-choice's uncomment 
> macro to activate
> a line.

Please re-read what I wrote. There's things like:

# Example:
# directive = value
# 
# directive = value

So your argument doesn't work, since there's already a "just delete a
char" kind of things, it's just there TWICE !!!

Thomas


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

Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

[Adam Nelson]

I don't see why the license of a piece of software used to check the
codebase (i.e. the linter) infects the codebase being checked.  That would
be like saying the Google terms of service under which I'm writing this
email (Google Apps) infects the codebase.

--
Kili - Cloud for Africa: kili.io
Musings: twitter.com/varud 
More Musings: varud.com
About Adam: www.linkedin.com/in/adamcnelson


On Wed, Apr 2, 2014 at 6:53 PM, Ben Nemec  wrote:

> I think that would be a good idea.  We're not shipping this, we're just
> using it in test (AIUI), so I don't think incompatibility with the
> OpenStack license is necessarily an issue.  But IANAL. :-)
>
> -Ben
>
>
> On 04/02/2014 09:24 AM, Kevin Conway wrote:
>
>> I understand, and appreciate, the concern for licensing, but it would be a
>> real shame to discount some of the most widely used linters because of a
>> clause that prevents us from being evil.
>>
>> Any chance we could run this by legal-disc...@lists.openstack.org and
>> hear
>> their reactions before we axe the JS*int projects from OpenStack?
>>
>> On 4/2/14 8:43 AM, "Radomir Dopieralski"  wrote:
>>
>>  On 02/04/14 15:26, Kevin Conway wrote:
>>>
 What licensing issues were brought up that prevent the use of JSLint or
 JSHint? Both are MIT licensed.

 Granted, JSLint has an additional clause:

  The Software shall be used for Good, not Evil.


 Maybe that's it? If so, Crockford has been known to make exceptions for
 organizations that wish to use his code for potentially evil
 purposes:
 https://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_
 detailpage#t=2
 480s.

>>>
>>> Yes, that's exactly it. An exception is not enough -- that clause simply
>>> makes that license incompatible with OpenStack's license. To use it, we
>>> would need to change OpenStack's license too, and it quickly becomes
>>> quite complex.
>>>
>>> You have to remember that organizations like NSA use OpenStack, so we
>>> can't possibly include that clause in its license ;)
>>>
>>> --
>>> Radomir Dopieralski
>>>
>>>
>>> ___
>>> 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] Missleading and hardly parseable default neutron config files

[Russell Bryant]

On 04/02/2014 11:01 AM, Solly Ross wrote:
> IMHO, having "Example:" on a separate line from the actual option is a lot 
> easier for humans:
> you just delete a single character or use your editor-of-choice's uncomment 
> macro to activate
> a line.

Sure, agreed.  But in any case, it seems to make sense to handle sample
config files consistently across projects.  If a usability enhancement
related to examples is made, it will then make its way to all projects.

-- 
Russell Bryant

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

Re: [openstack-dev] Missleading and hardly parseable default neutron config files

[Ben Nemec]

On 04/02/2014 10:10 AM, Russell Bryant wrote:

On 04/02/2014 11:01 AM, Solly Ross wrote:

IMHO, having "Example:" on a separate line from the actual option is a lot 
easier for humans:
you just delete a single character or use your editor-of-choice's uncomment 
macro to activate
a line.


Sure, agreed.  But in any case, it seems to make sense to handle sample
config files consistently across projects.  If a usability enhancement
related to examples is made, it will then make its way to all projects.



Yes, and there seems to be some momentum behind the idea of getting 
these out of the git tree, so automatic generation is going to be needed 
then.


We have a bug open (https://bugs.launchpad.net/oslo/+bug/1300546) for 
tracking what needs to happen for Glance to be able to do this, so if 
there's something blocking Neutron please let us know and we will figure 
out how to make it work.  Thanks.


-Ben

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

Re: [openstack-dev] [Murano] MuranoPL => UML visualization <- best implementation practices?

[Ed Cranford]

So it does, I hadn't realized that. The earlier message mentioned using a 
command-line tool to produce pretty graph images, and I figured I knew just the 
tool for the job.

Since you're already indirectly using Graphviz, if you're only using PlantUML 
for processing the output of umlgen.py into a PNG, why not skip a step and 
generate the Graphviz input file yourself?
Granted, it'll take some work to build a similar visual style--I see elaborate 
record nodes in your future--but you don't have to be bound to PlantUML if you 
don't want to be.
I've used Graphviz before for a few applications, and if I can help get you 
started with building dot files, let me know.

That said, weighing effort against result, you may just be better off sticking 
with Plant at least in the short term.
I'm sorry I can't suggest a simpler alternative for you right now.

From: Dmitry Teselkin mailto:dtesel...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 2, 2014 at 12:05 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Murano] MuranoPL => UML visualization <- best 
implementation practices?

Hi,

GraphViz is alreary used by Plant UML to produce output PNG file, see 'image 
generation chain' below:
* umlgen.py walks through MuranoPL class(es) and generated temporary file which 
contains Plant UML definitions for the entire graph
* Plant UML is called with that file as input
* Plant UML processes input file somehow and uses GraphViz to build output image



On Tue, Apr 1, 2014 at 11:25 PM, Ed Cranford 
mailto:ed.cranf...@rackspace.com>> wrote:
What about Graphviz?

On 4/1/14, 1:34 PM, "Timur Sufiev" 
mailto:tsuf...@mirantis.com>> wrote:

>Hello!
>
>Recently we've made an attempt to make MuranoPL class definitions more
>conceivable for everyone, and decided to use UML diagrams for that
>purpose. The most obvious (and quick) solution was to use a well-known
>tool [1], the command-line script which uses it is almost ready [2],
>and the final result seems quite satisfying to us [3] (pictures are
>drawn using current version of script). Moreover, we liked these
>diagrams so much that decided to show them also in Murano's WebUI
>(right after the uploaded App Package has been validated).
>
>But we're little uncertain about using Java-based tool in the long
>run: it doesn't seem to fit very well with OpenStack common practices.
>So could you advice some good enough Python and/or Javascript library
>for generating UML diagrams? The most important criteria is an ability
>to produce graphics as beautiful as Plant UML does.
>
>[1] http://plantuml.sourceforge.net/
>[2] https://review.openstack.org/#/c/83348/
>[3]
>https://www.dropbox.com/sh/pesyejyjo624o34/fCe1_OM-OH#lh:null-io.murano.En
>vironment.png
>
>--
>Timur Sufiev
>
>___
>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,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

[Ben Nemec]

I think that would be a good idea.  We're not shipping this, we're just 
using it in test (AIUI), so I don't think incompatibility with the 
OpenStack license is necessarily an issue.  But IANAL. :-)


-Ben

On 04/02/2014 09:24 AM, Kevin Conway wrote:

I understand, and appreciate, the concern for licensing, but it would be a
real shame to discount some of the most widely used linters because of a
clause that prevents us from being evil.

Any chance we could run this by legal-disc...@lists.openstack.org and hear
their reactions before we axe the JS*int projects from OpenStack?

On 4/2/14 8:43 AM, "Radomir Dopieralski"  wrote:


On 02/04/14 15:26, Kevin Conway wrote:

What licensing issues were brought up that prevent the use of JSLint or
JSHint? Both are MIT licensed.

Granted, JSLint has an additional clause:

 The Software shall be used for Good, not Evil.


Maybe that's it? If so, Crockford has been known to make exceptions for
organizations that wish to use his code for potentially evil
purposes:
https://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2
480s.


Yes, that's exactly it. An exception is not enough -- that clause simply
makes that license incompatible with OpenStack's license. To use it, we
would need to change OpenStack's license too, and it quickly becomes
quite complex.

You have to remember that organizations like NSA use OpenStack, so we
can't possibly include that clause in its license ;)

--
Radomir Dopieralski


___
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] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Collins, Sean]

On Wed, Apr 02, 2014 at 11:40:39AM EDT, Martinx - ジェームズ wrote:
> But, can this current "neutron-ipv6.patch" at least, be used to enable
> Neutron IPv6 with RA (--ipv6_ra_mode slaac --ipv6_address_mode slaac) ?

No, because even if you solved all the merge conflicts, the 
tests were not passing in the last patch set.

Keep an eye on the ML and the subteam IRC meeting, I'll make sure to add
an agenda item for next week to discuss backporting potential.

-- 
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] Documenting FWaaS

[Sumit Naiksatam]

Hi Israel,

Thanks for taking this up. There is currently an ongoing effort to
provide some level of developer documentation within the neutron
source tree itself. The patch in review proposes creating placeholders
for advanced services, and details for each of the services can be
added in follow up patches:
https://review.openstack.org/#/c/80825/3

Then there are the admin and API documents:
Admin:
http://docs.openstack.org/admin-guide-cloud/content/
https://bugs.launchpad.net/openstack-manuals
Config reference:
http://docs.openstack.org/trunk/config-reference/content/section_networking-options-reference.html

API:
http://docs.openstack.org/api/openstack-network/2.0/content/
https://bugs.launchpad.net/openstack-api-site/+bugs?field.tag=netconn-api
https://github.com/openstack/netconn-api

See following for how to contribute to the OpenStack docs:
https://wiki.openstack.org/wiki/Documentation/HowTo/FirstTimers

For items in flight, or which do not fit into the above categories, we
often tend to document them in OpenStack wiki pages. The landing page
for FWaaS wiki page is here (you can create links from there):
https://wiki.openstack.org/wiki/Neutron/FWaaS

Hope that helps.

Thanks,
~Sumit.

On Wed, Apr 2, 2014 at 3:50 AM, Israel Ziv  wrote:
> Hi!
>
> I am currently documenting FWaaS for development purposes. My focus is to
> have a detailed end-to-end flow (from plugin to driver.
>
> I thought it would be a good idea to share my deliverables (document +
> images) with the community and have feedback from the community.
>
> Since I am a newcomer to openstack-dev I am not sure what will be the proper
> location where to place these deliverables.
>
> Thanks
>
> Israel Ziv (israel@huawei.com )
>
>
> ___
> 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] Icehouse RC1 available

[Devananda van der Veen]

Hello everyone,

Ironic published its first Icehouse release candidate yesterday. The list of
bugs fixed since feature freeze and the RC1 tarball are available at:

https://launchpad.net/ironic/icehouse/icehouse-rc1

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the 2014.1 final
version on April 17. You are therefore strongly encouraged to test and
validate this tarball.

Alternatively, you can directly test the milestone-proposed branch at:
https://github.com/openstack/ironic/tree/milestone-proposed

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/ironic/+filebug

and tag it *icehouse-rc-potential* to bring it to the release crew's
attention.

Note that the "master" branch of Ironic is now open for Juno
development, and feature freeze restrictions no longer apply there.

Many thanks should be directed to Thierry for his assistance in making the
release happen, and for answering my endless stream of questions as I learn
[*].

Regards,
Devananda


[*] and for the excellent announcement template which I have shamelessly
copied.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

LOL! AWESOME!! No problem... I know that you guys have a lot to do...   :-)

But, can this current "neutron-ipv6.patch" at least, be used to enable
Neutron IPv6 with RA (--ipv6_ra_mode slaac --ipv6_address_mode slaac) ?

Otherwise, is a nutshell, what can be achieved these days with the bleeding
edge Neutron IPv6 code?!

I'm watching https://review.openstack.org/#/c/70649/ :)

Tks Sean!
Thiago

On 2 April 2014 12:24, Collins, Sean wrote:

> On Wed, Apr 02, 2014 at 11:13:32AM EDT, Martinx - ジェームズ wrote:
> > Awesome guys! I'll do it!
>
> OK - so keep an eye on:
>
> https://review.openstack.org/#/c/70649/
>
> Once it is rebased to solve the merge conflicts, and all the tests pass,
> then perhaps we can look into any of this backporting or PPA business.
> So keep your powder dry ;)
>
> --
> Sean M. Collins
> ___
> 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] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Collins, Sean]

On Wed, Apr 02, 2014 at 11:13:32AM EDT, Martinx - ジェームズ wrote:
> Awesome guys! I'll do it!

OK - so keep an eye on:

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

Once it is rebased to solve the merge conflicts, and all the tests pass,
then perhaps we can look into any of this backporting or PPA business.
So keep your powder dry ;)

-- 
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] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Awesome guys! I'll do it!

I have the "neutron-ipv6.patch" that came from the output of "git
format-patch -1 --stdout FETCH_HEAD" but, it did not got applied
successfully against "neutron-2014.1.rc1", look:

---
builder@neutron-dev-1:~/neutron/neutron-2014.1.rc1$ patch -p1 <
../ipv6-bits/neutron-shixiong/neutron-ipv6.patch
patching file neutron/agent/l3_agent.py
Hunk #1 succeeded at 696 (offset 31 lines).
Hunk #2 succeeded at 722 (offset 31 lines).
patching file neutron/agent/linux/dhcp.py
Hunk #2 FAILED at 334.
Hunk #3 FAILED at 419.
Hunk #4 succeeded at 534 with fuzz 2 (offset 56 lines).
Hunk #5 succeeded at 548 (offset 56 lines).
Hunk #6 succeeded at 664 (offset 56 lines).
2 out of 6 hunks FAILED -- saving rejects to file
neutron/agent/linux/dhcp.py.rej
patching file neutron/common/constants.py
Hunk #1 succeeded at 113 (offset 1 line).
patching file neutron/tests/unit/test_dhcp_agent.py
Hunk #2 succeeded at 221 (offset 4 lines).
Hunk #3 succeeded at 260 (offset 4 lines).
patching file neutron/tests/unit/test_l3_agent.py
Hunk #1 succeeded at 145 (offset -1 lines).
patching file neutron/tests/unit/test_linux_dhcp.py
Hunk #6 succeeded at 578 (offset -1 lines).
Hunk #7 succeeded at 595 (offset -1 lines).
Hunk #8 succeeded at 666 (offset -1 lines).
Hunk #9 FAILED at 740.
Hunk #13 FAILED at 1068.
Hunk #14 FAILED at 1085.
Hunk #15 FAILED at 1110.
Hunk #16 FAILED at 1117.
Hunk #17 succeeded at 1101 with fuzz 1 (offset -34 lines).
Hunk #18 FAILED at 1162.
6 out of 18 hunks FAILED -- saving rejects to file
neutron/tests/unit/test_linux_dhcp.py.rej
---

It failed and I'm not a coder but, I think I can work on this (it might
take days) to build Neutron IPv6 Ubuntu packages for us... Nevertheless, if
someone (Shixiong ?  :-D ) can update it (to be applied on top of
neutron-2014.1.rc1), I think I'll be able to publish the packages on PPA on
the next day!

-

The CLI command may look like, for example, something below:

---
neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode
off NETWORK CIDR
neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode
dhcpv6-stateful NETWORK CIDR
neutron subnet-create --ip-version 6 --ipv6_ra_mode slaac
--ipv6_address_mode slaac NETWORK CIDR
neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateful
--ipv6_address_mode off NETWORK CIDR
neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateless
--ipv6_address_mode dhcpv6-stateless NETWORK CIDR
---

References:

neutron-ipv6.patch: http://paste.openstack.org/show/74857/

http://lists.openstack.org/pipermail/openstack-dev/2014-February/026589.html
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026809.html


Cheers!
Thiago


On 2 April 2014 08:44, Sebastian Herzberg wrote:

> Hi,
>
> from my side there is definite interest in this, as the changes didn't
> make it yet.
>
> Thanks
> Sebastian
> ___
> 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] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Collins, Sean]

The patch that enables the new attribute support in dnsmasq still has a
lot of work that needs to be done. Once that patch is ready, I suppose we
can ask for it to be backported to Icehouse. 

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

[openstack-dev] [OSSG][OSSN] Potential token revocation abuse via group membership

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Potential token revocation abuse via group membership
- ---

### Summary ###
Deletion of groups in Keystone causes token revocation for group
members.  If group capabilities are delegated to users, they can abuse
those capabilities to maliciously revoke tokens for other users.

### Affected Services / Software ###
Keystone, Grizzly, Havana, Icehouse

### Discussion ###
If a group is deleted from Keystone, all tokens for all users that are
members of that group are revoked.  By adding users to a group without
those users' knowledge and then deleting that group, a group admin can
revoke all of the users' tokens.  While the default policy file gives
the group admin role to global admin, an alternative policy could
delegate the "create_group", "add_user_to_group", and "delete_group"
capabilities to a set of users.  In such a system, those users will also
get a token revocation capability.  Only setups using a custom policy
file in Keystone are affected.

### Recommended Actions ###
Keystone's default policy.json file uses the "admin_required" rule for
the "create_group", "delete_group", and "add_user_to_group"
capabilities.  It is recommended that you use this default configuration
if possible.  Here is an example snippet of a properly configured
policy.json file:

-  begin example policy.json snippet 
"identity:create_group": "rule:admin_required",
"identity:delete_group": "rule:admin_required",
"identity:add_user_to_group": "rule:admin_required",
-  end example policy.json snippet 

If you need to delegate the above capabilities to non-admin users, you
need to take into account that those users will be able to revoke
tokens for other users by performing group deletion operations.  You
should take caution with who you delegate these capabilities to.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0009
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1268751
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTPCYGAAoJEJa+6E7Ri+EVw+wIAI1RaoIuHf7VAQSI8J/RhUK/
sKmoKUmEq0yDTQwKnbW2X8PMM6t4d4NDV0bSJfrKZYjnIWBNoh0hk3yg4GYytn2s
s8o31ctOhWWOx/EGfnhlm7IrJZ91KmnhrVTLMdSFOQhiIzxa2gyEk0Fw3k6oYlDN
wJWC5NyKKeNpjb7SSoHhifcQ/7FGUJIcd8tnm1KT3vMrK9pUM46Jsb8sdfZ2+8hE
ym3vCSc47t5K/32HFDjiAsfaCKBVIoJeOBOJGOcsQIpuW6GkRB8Ic5n2+EW25Z3O
y5tgwhHZaoTL6K0KlpGHPvVSoeJea09yTL97KqCIcMM89KwNcKvobM2KHgtwqHY=
=i6VA
-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] Missleading and hardly parseable default neutron config files

[Solly Ross]

IMHO, having "Example:" on a separate line from the actual option is a lot 
easier for humans:
you just delete a single character or use your editor-of-choice's uncomment 
macro to activate
a line.

- Original Message -
From: "Russell Bryant" 
To: openstack-dev@lists.openstack.org
Sent: Wednesday, April 2, 2014 9:45:05 AM
Subject: Re: [openstack-dev] Missleading and hardly parseable default neutron 
config files

On 04/02/2014 06:38 AM, Salvatore Orlando wrote:
> Hi Thomas,
> 
> it probably won't be a bad idea if you can share the patches you're
> applying to the default configuration files.
> I think all distros are patching them anyway, so this might allow us to
> provide mostly ready to use config files.
> 
> Is there a chance you can push something to gerrit?

How about auto generate the sample config like most other projects?

-- 
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] [Ceilometer] Collector no recheck the db status

[Gordon Chung]

> I found that when collector service starting, if the db has not yet 
> ready, it will log an error info like 'Could not load 'database': 
> could not connect to...' but the service still goes on. Later when 
> the db is ready, but there are no mechanisms to check the db status 
> and reconnect it. so the collector service keeps useless to record the 
data.

is this against master? does this patch resolve the issue for you? 
https://review.openstack.org/#/c/83595/


gordon chung
openstack, ibm software standards___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All][Keystone] Deprecation of the v2 API

[Dolph Mathews]

On Wed, Apr 2, 2014 at 8:43 AM, Russell Bryant  wrote:

> On 04/02/2014 09:20 AM, Dolph Mathews wrote:
> >
> > On Tue, Apr 1, 2014 at 7:40 PM, Anne Gentle  > > wrote:
> >
> >
> >
> >
> > On Wed, Mar 26, 2014 at 5:30 AM, Thierry Carrez
> > mailto:thie...@openstack.org>> wrote:
> >
> > Russell Bryant wrote:
> > > [...]
> > > First, it seems there isn't a common use of "deprecated".  To
> me,
> > > marking something deprecated means that the deprecated feature:
> > >
> > >  - has been completely replaced by something else
> > >
> > >  - end users / deployers should take action to migrate to the
> > >new thing immediately.
> > >
> > >  - The project has provided a documented migration path
> > >
> > >  - the old thing will be removed at a specific date/release
> >
> > Agreed, IMHO we need to reserve the use the "deprecated"
> > terminology for
> > the idea of moving end users, deployers, external client library
> > developers (people outside of OpenStack direct reach) off a
> > given API
> > version. Deprecation is about giving them a fair heads-up about
> > something that is about to be removed, so that they are
> > encouraged to
> > move off it. It needs to be discussed and announced with the user
> > community, and come with a precise plan.
> >
> > Internal consumption of APIs between OpenStack projects is a
> > different
> > beast: (1) it's under our control and (2) we really can't remove
> > an API
> > until all our internal pieces have migrated off it.
> >
> > So I wouldn't use "deprecation warnings" to encourage other
> > OpenStack
> > projects to move off an API. They can't come with a precise date
> > since
> > if projects don't comply with this "suggestion" we just can't
> remove
> > that API support. I would therefore go this way:
> >
> > 1. API vN is stable and supported
> > 2. API vN+1 is being developed and experimental
> > 3. API vN+1 is marked stable and supported
> > 4. Engage with other consuming OpenStack projects to migrate to
> vN+1
> > 5. Migration is completed
> > 6. Deprecation plan (and removal date) is discussed with
> > stakeholders
> > 7. Deprecation plan (and removal date) is decided and announced
> > 8. Deprecation messages are added to code for API vN users
> > 9. At removal date, API vN is removed
> >
> > Keystone is at step 4. It shouldn't use "deprecation"
> > terminology before
> > step 6.
> >
> >
> > Hi all, I wanted to double-check some wording. I'm chasing down how
> > to update docs based on a DocImpact flag[1]  with related bugs and
> > the nova blueprint to deprecate XML. [2] I'm pretty sure "deprecate"
> > is the term we're using as the message says "XML support has been
> > deprecated and will be removed in the Juno release." [3]
> >
> >
> > I don't see any issue with using the term "deprecate" here. However, I
> > think it's important to say it "may" be removed, not "will."
> > Deprecations are frequently delayed, so the wording has potential to be
> > inaccurate as-is. You could even go so far as to say "it *may* be
> > removed *as early as* the Juno release." Oslo's deprecation decorator
> > (the "deprecator") does not use the wording today, though.
>
> Agree that the wording should be changed.
>
> https://review.openstack.org/84725
>
> https://bugs.launchpad.net/nova/+bug/1301384
>
> I'll get this into icehouse-rc2 for Nova.
>
> >
> >
> >
> > To me, the same arguments that caused a different message to be
> > substituted for Keystone's v2.0 API could be used here. Is that
> > inaccurate? Has the discussion been carried to the logical
> > conclusion? Should "deprecated" be used yet?
> >
> >
> > I just want to point out that Keystone followed Nova's lead on this one
> > - Keystone's XML support, which is only rigorously tested against a very
> > small portion of the v2 API, is deprecated as of Icehouse as well. I
> > think XML is a broader community issue, not one that needs to be
> > discussed per-project.
>
> In terms of the the project-wide issue, the TC at least formalized that
> the only thing we expect from a project is a REST API with JSON support.
>  We didn't want to *prevent* XML support.
>
>
> http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements#n40
>
> "Project must have a REST API with at least a JSON entity representation"
>
> > I think we could follow a similar pattern for XML in the Compute API
> > v2 -- we need to define "discussed with stakeholders" and how/when
> > we say the discussion is done. I wanted to put up a set of ideas for
> > the 

Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

[Kevin Conway]

I understand, and appreciate, the concern for licensing, but it would be a
real shame to discount some of the most widely used linters because of a
clause that prevents us from being evil.

Any chance we could run this by legal-disc...@lists.openstack.org and hear
their reactions before we axe the JS*int projects from OpenStack?

On 4/2/14 8:43 AM, "Radomir Dopieralski"  wrote:

>On 02/04/14 15:26, Kevin Conway wrote:
>> What licensing issues were brought up that prevent the use of JSLint or
>> JSHint? Both are MIT licensed.
>> 
>> Granted, JSLint has an additional clause:
>> 
>> The Software shall be used for Good, not Evil.
>> 
>> 
>> Maybe that's it? If so, Crockford has been known to make exceptions for
>> organizations that wish to use his code for potentially evil
>> purposes: 
>>https://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2
>>480s.
>
>Yes, that's exactly it. An exception is not enough -- that clause simply
>makes that license incompatible with OpenStack's license. To use it, we
>would need to change OpenStack's license too, and it quickly becomes
>quite complex.
>
>You have to remember that organizations like NSA use OpenStack, so we
>can't possibly include that clause in its license ;)
>
>-- 
>Radomir Dopieralski
>
>
>___
>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] [tempest][scenario] independece test between Stack and backing services?

[Martina Kollarova]

On Wed 02 Apr 2014 03:38:18 PM CEST, Sean Dague wrote:

Good stuff. I like the semantics of what the destroy stack tests look
like, very clean.

I still think there would be value in doing this as a API service, which
would let you decouple the test cases (and even put them in Tempest), as
the tests could just assume certain fault semantics, and the
implementation (which could even start with the ssh to nodes approach)
would be left to the fault service.



This would still leave some problems that would make it difficult to 
add these tests into Tempest. First, to check if if some things are 
working beyond some basic "yep, it sent back 200", you need access to 
the nodes. For example, when I'm testing Swift, I check if there are 3 
replicas of each object by looking into the internals a bit - there is 
no API for this and I wouldn't trust it even if there was.


Another problem would be test isolation - how would you do test 
clean-up in Tempest if you don't have access to the servers and cannot 
even start up a service? You would need a full OpenStack management 
service (could TripleO somehow do this?).


But it would be interesting...the first implementation of Daas - 
Destruction as a Service.


Martina


Do you think this would be an interesting evolution of destroystack, or
is that different enough in goals that we should think about this
problem separately.

-Sean

On 04/02/2014 08:55 AM, Martina Kollarova wrote:

Hi Sean,

I'm already working on something similar. What I'm trying to do is not a
service, but a set of tests that would be able to run commands on the
nodes and restart services, kill disks, etc. The basic idea is to inject
some fault, see if everything still works as expected and restore the
state back to what it was before the fault. So far I only have some
basic tests for Swift, but I'm planning more. The state restoration is
going to be via snapshots (so it will have to be running in VMs, or I
could add support for LVM snapshots too) .

The project is called DestroyStack and is located here:
https://github.com/mkollaro/destroystack/tree/devel

It's still WIP, please don't try to run it yet, not everything is
implemented. I'm currently trying to create that demo.

Martina

On Wed 02 Apr 2014 12:34:43 PM CEST, Sean Dague wrote:

Fault injection is a problem I've been thinking about, though I don't
have time to dive into it any time soon. But I'll share my ideas in case
they are interesting.

I think we need a Fault Injection Service for OpenStack. It would act
like many of the other OpenStack services, have an API service, and a
worker on every node. It would be our own kind of chaos monkey, except
very programmable. It would look like any multi host service,
communicating over RPC between API and the nodes.

The Fault injection service would have the ability to kill process on
the hosts (libvirt, nova-compute, c-vol). It would also have the ability
to delete did data (simulating a hardware fault).

We could definitely use something like this to also signal a service
restart, or some other behind the scenes action that we'd expect would
be regularly happening.

If we had a Fault Injection service, then we could have a class of tests
(possibly in Tempest, possibly in another place) which would start
resources with the OpenStack API, then inject faults, then continue
along the way.

I feel like Juno is too soon for this, as we have lots of other issues
to address. However, K might work. That being said, if anyone wants to
dive in early, have at. The important thing would be that this has REST
API, and that it be multi node.

 -Sean

On 04/02/2014 04:37 AM, Tomoya Goto wrote:

Hello, Igawa-san

Thanks for pointing out Tempest principles. I wasn't aware of them.

ok, I'll probably use the current test cases with manually stopping
services.
I'm checking with Temest(icehouse) and if I write or think up something
useful, I'll be back.  Also Grenade, too. :)


Thank you  for valuable advices,
  - Tomoya Goto




Hi,

On 04/02, Tomoya Goto wrote:

Thanks for quick replies Igawa-san and Mr.Sean! :)
and sorry foy my slow reply :(


np :)




The task I wantetd to conduct is not only for upgrading but also for
rather small maintenace, say stopping openstack-cinder* for changing
configuration.

Now, Grenade is for upgrade purpose but not for such small
maintenace, right?
So I think tempest is more suitable than Grenade for such task.

what do you say?


This kind (fault injection?) of tests that you said are interesting and
we should have them in future. But Tempest should not operate OpenStack
components directly. e.g. stop/start Cinder/Glance/Nova services.
This is one of design principles[1]. So I think we need a new project
for these types of tests or need to change the principles.

[1]
http://docs.openstack.org/developer/tempest/overview.html#design-principles



Thanks,
-- Masayuki Igawa



- Tomoya Goto



You are correct. The testing we do for this is in Grenade

[openstack-dev] [sahara] team meeting April 3 1800 UTC [savanna]

[Sergey Lukjanov]

Hi folks,

We'll be having the Sahara team meeting as usual in
#openstack-meeting-alt channel.

Agenda: 
https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Agenda_for_April.2C_3

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20140403T18

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Mirantis Inc.

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

Re: [openstack-dev] Missleading and hardly parseable default neutron config files

[Russell Bryant]

On 04/02/2014 06:38 AM, Salvatore Orlando wrote:
> Hi Thomas,
> 
> it probably won't be a bad idea if you can share the patches you're
> applying to the default configuration files.
> I think all distros are patching them anyway, so this might allow us to
> provide mostly ready to use config files.
> 
> Is there a chance you can push something to gerrit?

How about auto generate the sample config like most other projects?

-- 
Russell Bryant

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

Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?

[Sean Dague]

Good stuff. I like the semantics of what the destroy stack tests look
like, very clean.

I still think there would be value in doing this as a API service, which
would let you decouple the test cases (and even put them in Tempest), as
the tests could just assume certain fault semantics, and the
implementation (which could even start with the ssh to nodes approach)
would be left to the fault service.

Do you think this would be an interesting evolution of destroystack, or
is that different enough in goals that we should think about this
problem separately.

-Sean

On 04/02/2014 08:55 AM, Martina Kollarova wrote:
> Hi Sean,
> 
> I'm already working on something similar. What I'm trying to do is not a
> service, but a set of tests that would be able to run commands on the
> nodes and restart services, kill disks, etc. The basic idea is to inject
> some fault, see if everything still works as expected and restore the
> state back to what it was before the fault. So far I only have some
> basic tests for Swift, but I'm planning more. The state restoration is
> going to be via snapshots (so it will have to be running in VMs, or I
> could add support for LVM snapshots too) .
> 
> The project is called DestroyStack and is located here:
> https://github.com/mkollaro/destroystack/tree/devel
> 
> It's still WIP, please don't try to run it yet, not everything is
> implemented. I'm currently trying to create that demo.
> 
> Martina
> 
> On Wed 02 Apr 2014 12:34:43 PM CEST, Sean Dague wrote:
>> Fault injection is a problem I've been thinking about, though I don't
>> have time to dive into it any time soon. But I'll share my ideas in case
>> they are interesting.
>>
>> I think we need a Fault Injection Service for OpenStack. It would act
>> like many of the other OpenStack services, have an API service, and a
>> worker on every node. It would be our own kind of chaos monkey, except
>> very programmable. It would look like any multi host service,
>> communicating over RPC between API and the nodes.
>>
>> The Fault injection service would have the ability to kill process on
>> the hosts (libvirt, nova-compute, c-vol). It would also have the ability
>> to delete did data (simulating a hardware fault).
>>
>> We could definitely use something like this to also signal a service
>> restart, or some other behind the scenes action that we'd expect would
>> be regularly happening.
>>
>> If we had a Fault Injection service, then we could have a class of tests
>> (possibly in Tempest, possibly in another place) which would start
>> resources with the OpenStack API, then inject faults, then continue
>> along the way.
>>
>> I feel like Juno is too soon for this, as we have lots of other issues
>> to address. However, K might work. That being said, if anyone wants to
>> dive in early, have at. The important thing would be that this has REST
>> API, and that it be multi node.
>>
>> -Sean
>>
>> On 04/02/2014 04:37 AM, Tomoya Goto wrote:
>>> Hello, Igawa-san
>>>
>>> Thanks for pointing out Tempest principles. I wasn't aware of them.
>>>
>>> ok, I'll probably use the current test cases with manually stopping
>>> services.
>>> I'm checking with Temest(icehouse) and if I write or think up something
>>> useful, I'll be back.  Also Grenade, too. :)
>>>
>>>
>>> Thank you  for valuable advices,
>>>  - Tomoya Goto
>>>
>>>
>>>
 Hi,

 On 04/02, Tomoya Goto wrote:
> Thanks for quick replies Igawa-san and Mr.Sean! :)
>and sorry foy my slow reply :(

 np :)

>
>
> The task I wantetd to conduct is not only for upgrading but also for
> rather small maintenace, say stopping openstack-cinder* for changing
> configuration.
>
> Now, Grenade is for upgrade purpose but not for such small
> maintenace, right?
> So I think tempest is more suitable than Grenade for such task.
>
> what do you say?

 This kind (fault injection?) of tests that you said are interesting and
 we should have them in future. But Tempest should not operate OpenStack
 components directly. e.g. stop/start Cinder/Glance/Nova services.
 This is one of design principles[1]. So I think we need a new project
 for these types of tests or need to change the principles.

 [1]
 http://docs.openstack.org/developer/tempest/overview.html#design-principles



 Thanks,
 -- Masayuki Igawa

>
>- Tomoya Goto
>
>
>> You are correct. The testing we do for this is in Grenade, which
>> we run
>> in the gate. Grenade tests an upgrade from last stable release to
>> current master. It creates a few resources before the upgrade, and
>> fails
>> if those are interupted after the upgrade.
>>
>> Grenade is still pretty light on the number of resources it creates
>> before the upgrade, and is definitely a place where enhancement is
>> welcome.
>>
>>  -Sean
>>
>>
>> On 04/01/2014 04:

Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

[Radomir Dopieralski]

On 02/04/14 15:26, Kevin Conway wrote:
> What licensing issues were brought up that prevent the use of JSLint or
> JSHint? Both are MIT licensed.
> 
> Granted, JSLint has an additional clause:
> 
> The Software shall be used for Good, not Evil.
> 
> 
> Maybe that's it? If so, Crockford has been known to make exceptions for
> organizations that wish to use his code for potentially evil
> purposes: 
> https://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2480s.

Yes, that's exactly it. An exception is not enough -- that clause simply
makes that license incompatible with OpenStack's license. To use it, we
would need to change OpenStack's license too, and it quickly becomes
quite complex.

You have to remember that organizations like NSA use OpenStack, so we
can't possibly include that clause in its license ;)

-- 
Radomir Dopieralski


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

Re: [openstack-dev] [All][Keystone] Deprecation of the v2 API

[Russell Bryant]

On 04/02/2014 09:20 AM, Dolph Mathews wrote:
> 
> On Tue, Apr 1, 2014 at 7:40 PM, Anne Gentle  > wrote:
> 
> 
> 
> 
> On Wed, Mar 26, 2014 at 5:30 AM, Thierry Carrez
> mailto:thie...@openstack.org>> wrote:
> 
> Russell Bryant wrote:
> > [...]
> > First, it seems there isn't a common use of "deprecated".  To me,
> > marking something deprecated means that the deprecated feature:
> >
> >  - has been completely replaced by something else
> >
> >  - end users / deployers should take action to migrate to the
> >new thing immediately.
> >
> >  - The project has provided a documented migration path
> >
> >  - the old thing will be removed at a specific date/release
> 
> Agreed, IMHO we need to reserve the use the "deprecated"
> terminology for
> the idea of moving end users, deployers, external client library
> developers (people outside of OpenStack direct reach) off a
> given API
> version. Deprecation is about giving them a fair heads-up about
> something that is about to be removed, so that they are
> encouraged to
> move off it. It needs to be discussed and announced with the user
> community, and come with a precise plan.
> 
> Internal consumption of APIs between OpenStack projects is a
> different
> beast: (1) it's under our control and (2) we really can't remove
> an API
> until all our internal pieces have migrated off it.
> 
> So I wouldn't use "deprecation warnings" to encourage other
> OpenStack
> projects to move off an API. They can't come with a precise date
> since
> if projects don't comply with this "suggestion" we just can't remove
> that API support. I would therefore go this way:
> 
> 1. API vN is stable and supported
> 2. API vN+1 is being developed and experimental
> 3. API vN+1 is marked stable and supported
> 4. Engage with other consuming OpenStack projects to migrate to vN+1
> 5. Migration is completed
> 6. Deprecation plan (and removal date) is discussed with
> stakeholders
> 7. Deprecation plan (and removal date) is decided and announced
> 8. Deprecation messages are added to code for API vN users
> 9. At removal date, API vN is removed
> 
> Keystone is at step 4. It shouldn't use "deprecation"
> terminology before
> step 6.
> 
> 
> Hi all, I wanted to double-check some wording. I'm chasing down how
> to update docs based on a DocImpact flag[1]  with related bugs and
> the nova blueprint to deprecate XML. [2] I'm pretty sure "deprecate"
> is the term we're using as the message says "XML support has been
> deprecated and will be removed in the Juno release." [3] 
> 
> 
> I don't see any issue with using the term "deprecate" here. However, I
> think it's important to say it "may" be removed, not "will."
> Deprecations are frequently delayed, so the wording has potential to be
> inaccurate as-is. You could even go so far as to say "it *may* be
> removed *as early as* the Juno release." Oslo's deprecation decorator
> (the "deprecator") does not use the wording today, though.

Agree that the wording should be changed.

https://review.openstack.org/84725

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

I'll get this into icehouse-rc2 for Nova.

>  
> 
> 
> To me, the same arguments that caused a different message to be
> substituted for Keystone's v2.0 API could be used here. Is that
> inaccurate? Has the discussion been carried to the logical
> conclusion? Should "deprecated" be used yet?
> 
> 
> I just want to point out that Keystone followed Nova's lead on this one
> - Keystone's XML support, which is only rigorously tested against a very
> small portion of the v2 API, is deprecated as of Icehouse as well. I
> think XML is a broader community issue, not one that needs to be
> discussed per-project.

In terms of the the project-wide issue, the TC at least formalized that
the only thing we expect from a project is a REST API with JSON support.
 We didn't want to *prevent* XML support.

http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements#n40

"Project must have a REST API with at least a JSON entity representation"

> I think we could follow a similar pattern for XML in the Compute API
> v2 -- we need to define "discussed with stakeholders" and how/when
> we say the discussion is done. I wanted to put up a set of ideas for
> the channels (push) and inputs (pull):
> - posted a collaborative statement expressing need to deprecate to
> the openstack-dev mailing list 
> 
> - posted a request for comment to the openstack mailing list
> 
> 
> In the case of XML, I think we alread

Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

[Kevin Conway]

What licensing issues were brought up that prevent the use of JSLint or
JSHint? Both are MIT licensed.

Granted, JSLint has an additional clause:

> The Software shall be used for Good, not Evil.


Maybe that's it? If so, Crockford has been known to make exceptions for
organizations that wish to use his code for potentially evil purposes:
https://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2480s
.


On Wed, Apr 2, 2014 at 4:23 AM, Peter Belanyi  wrote:

> Hi all,
>
> Recently we have been discussing the topic of Javascript linters for
> Horizon and Tuskar-UI with Radomir, and he told me that JSLint and JSHint
> can not be integrated into the test environment due to some license issues.
>
> I did some search and found Closure Linter [1] by Google which might be an
> alternative, and I wanted to get some feedback on it.
>
> Pros:
> - Open source, Apache License
> - Written in Python, available from pip
> - Used by Google, so probably it's production ready (or at least beta)
>
> Cons:
> - Javascript style is not configurable, it is hard coded to check The
> Google JavaScript Style [2], which might not exactly match OpenStack's
> desired coding style
> - It could take a long time to fix all js code to be accepted by the linter
>
> Does it look like something we could use?
>
> Thanks,
> Peter
>
>
> [1] https://developers.google.com/closure/utilities/
> [2] http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] Operators & Design Summit ideas for Atlanta

[Dolph Mathews]

On Mon, Mar 31, 2014 at 10:40 PM, Adam Young  wrote:

> On 03/28/2014 03:01 AM, Tom Fifield wrote:
>
>> Thanks to those projects that responded. I've proposed sessions in swift,
>> ceilometer, tripleO and horizon.
>>
>
>
> Keystone would also be interested in user feedback, of course.


Crossing openstack-dev threads [1] here, gathering feedback on proposed
deprecations would be a great topic for such a session.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-April/031652.html


>
>
>> On 17/03/14 07:54, Tom Fifield wrote:
>>
>>> All,
>>>
>>> Many times we've heard a desire for more feedback and interaction from
>>> users. However, their attendance at design summit sessions is met with
>>> varied success.
>>>
>>> However, last summit, by happy accident, a swift session turned into a
>>> something a lot more user driven. A competent user was able to describe
>>> their use case, and the developers were able to stage a number of
>>> question to them. In this way, some of the assumptions about the way
>>> certain things were implemented, and the various priorities of future
>>> plans became clearer. It worked really well ... perhaps this is
>>> something we'd like to have happen for all the projects?
>>>
>>> *Idea*: Add an "ops" session for each project in the design summit
>>> https://etherpad.openstack.org/p/ATL-ops-dedicated-
>>> design-summit-sessions
>>>
>>>
>>> Most operators running OpenStack tend to treat it more holistically than
>>> those coding it. They are aware of, but don't necessarily think or work
>>> in terms of project  breakdowns. To this end, I'd imagine the such
>>> sessions would:
>>>
>>>   * have a primary purpose for developers to ask the operators to answer
>>> questions, and request information
>>>
>>>   * allow operators to tell the developers things (give feedback) as a
>>> secondary purpose that could potentially be covered better in a
>>> cross-project session
>>>
>>>   * need good moderation, for example to push operator-to-operator
>>> discussion into forums with more time available (eg
>>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC )
>>>
>>>   * be reinforced by having volunteer "good" users in potentially every
>>> design summit session
>>> (https://etherpad.openstack.org/p/ATL-ops-in-design-sessions )
>>>
>>>
>>> Anyway, just a strawman - please jump on the etherpad
>>> (https://etherpad.openstack.org/p/ATL-ops-dedicated-
>>> design-summit-sessions)
>>> or leave your replies here!
>>>
>>>
>>> Regards,
>>>
>>>
>>> Tom
>>>
>>>
>>> ___
>>> 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] [All][Keystone] Deprecation of the v2 API

[Dolph Mathews]

On Tue, Apr 1, 2014 at 7:40 PM, Anne Gentle  wrote:

>
>
>
> On Wed, Mar 26, 2014 at 5:30 AM, Thierry Carrez wrote:
>
>> Russell Bryant wrote:
>> > [...]
>> > First, it seems there isn't a common use of "deprecated".  To me,
>> > marking something deprecated means that the deprecated feature:
>> >
>> >  - has been completely replaced by something else
>> >
>> >  - end users / deployers should take action to migrate to the
>> >new thing immediately.
>> >
>> >  - The project has provided a documented migration path
>> >
>> >  - the old thing will be removed at a specific date/release
>>
>> Agreed, IMHO we need to reserve the use the "deprecated" terminology for
>> the idea of moving end users, deployers, external client library
>> developers (people outside of OpenStack direct reach) off a given API
>> version. Deprecation is about giving them a fair heads-up about
>> something that is about to be removed, so that they are encouraged to
>> move off it. It needs to be discussed and announced with the user
>> community, and come with a precise plan.
>>
>> Internal consumption of APIs between OpenStack projects is a different
>> beast: (1) it's under our control and (2) we really can't remove an API
>> until all our internal pieces have migrated off it.
>>
>> So I wouldn't use "deprecation warnings" to encourage other OpenStack
>> projects to move off an API. They can't come with a precise date since
>> if projects don't comply with this "suggestion" we just can't remove
>> that API support. I would therefore go this way:
>>
>> 1. API vN is stable and supported
>> 2. API vN+1 is being developed and experimental
>> 3. API vN+1 is marked stable and supported
>> 4. Engage with other consuming OpenStack projects to migrate to vN+1
>> 5. Migration is completed
>> 6. Deprecation plan (and removal date) is discussed with stakeholders
>> 7. Deprecation plan (and removal date) is decided and announced
>> 8. Deprecation messages are added to code for API vN users
>> 9. At removal date, API vN is removed
>>
>> Keystone is at step 4. It shouldn't use "deprecation" terminology before
>> step 6.
>>
>
> Hi all, I wanted to double-check some wording. I'm chasing down how to
> update docs based on a DocImpact flag[1]  with related bugs and the nova
> blueprint to deprecate XML. [2] I'm pretty sure "deprecate" is the term
> we're using as the message says "XML support has been deprecated and will
> be removed in the Juno release." [3]
>

I don't see any issue with using the term "deprecate" here. However, I
think it's important to say it "may" be removed, not "will." Deprecations
are frequently delayed, so the wording has potential to be inaccurate
as-is. You could even go so far as to say "it *may* be removed *as early
as* the Juno release." Oslo's deprecation decorator (the "deprecator") does
not use the wording today, though.


>
> To me, the same arguments that caused a different message to be
> substituted for Keystone's v2.0 API could be used here. Is that inaccurate?
> Has the discussion been carried to the logical conclusion? Should
> "deprecated" be used yet?
>

I just want to point out that Keystone followed Nova's lead on this one -
Keystone's XML support, which is only rigorously tested against a very
small portion of the v2 API, is deprecated as of Icehouse as well. I think
XML is a broader community issue, not one that needs to be discussed
per-project.


>
> I think we could follow a similar pattern for XML in the Compute API v2 --
> we need to define "discussed with stakeholders" and how/when we say the
> discussion is done. I wanted to put up a set of ideas for the channels
> (push) and inputs (pull):
> - posted a collaborative statement expressing need to deprecate to the
> openstack-dev mailing list
>
- posted a request for comment to the openstack mailing list
>

In the case of XML, I think we already have a sufficiently long history of
relevant mailing list discussions suggesting a focus on a single
serialization format (JSON, in our case).


> - questions added to the user survey that indicate amount of use and
> desire to move away from
> - responses to user survey compiled showing a certain percent of agreement
> on deprecation
>

This would be really interesting to see, at least for XML. I wouldn't
recommend it for all the smaller features that face deprecation each
release.


>
> Would that be sufficient for the "discussed with stakeholders" step? Any
> other channels I'm missing? If the discussion requires six months of
> discussion at a minimum, is that acceptable?
>

One of keystone's summit sessions in Hong Kong partly focused on producing
a list of things to deprecate during Icehouse. We ended up deprecating
things that there was a clear consensus on (redundant middleware, etc).
Although there were certainly deployers represented in that session, I like
the idea of making deprecations a regular topic in a project-specific
design session focused on collecting deployer feedback (using the session

Re: [openstack-dev] [Keystone] python-keystoneclient v3 functionality

[Adam Young]

On 04/01/2014 07:36 AM, Yaguang Tang wrote:

Thanks Jamie,

then the following question is do we intend to move other services 
client library V3 identity support to python-openstackclient?
AFAIK it's poorly supported for Nova Cinder Neutron client library, 
and I am working on add v3 support for those libraries[1], just

want to make sure that is the correct direction.

[1] https://review.openstack.org/#/c/81749/
https://review.openstack.org/#/c/81767/



Sort of.  The Keystone client should be responsible for all fo the 
service catalog manipulations throughout openstack.  So the Cinder 
client should use the Keystone client.


To see the idea, read Jamie's blog post:

http://www.jamielennox.net/blog/2014/02/24/client-session-objects/

The main idea is that Keystone will handle the HTTP session setup, so 
that we have a single place to focus attention on for HTTP network 
security issues.  And you should not need to parse the service catalog 
at all.









2014-04-01 12:08 GMT+08:00 Jamie Lennox >:


On Tue, 2014-04-01 at 11:53 +0800, Yaguang Tang wrote:
> Hi all,
>
>
> I am sorry if this has been discussed before, the question is
will we
> support keystone v3 operation
> in python-keystoneclient? I know most of the v3 functionality have
> been implemented in python-openstackclient, but from the
> python-openstackclient wiki says, it's primarily a wrapper of
> python-*client, and provides unified interface to user. The end user
> uses python-keystoneclient to manage
> user, tenant, service before, if we don't intend to support v3
> functionality in keystoneclient, then
> it means we force end user to change from keystoneclient to
> openstackclient, is this what we want to
> do?
>

It depends what you mean by python-keystoneclient.

If you mean the python library then yes it supports the V3 API
already.

If you mean the keystone CLI that is currently bundled as part of the
python-keystoneclient then yes that is deprecated in favour of
python-openstackclient.

We will maintain the CLI application in keystoneclient however
even for
V2 API calls I recommend that you use the openstack CLI tool.

Jamie

>
> --
> Tang Yaguang
>
>
> Canonical Ltd. | www.ubuntu.com  |
www.canonical.com 
> Mobile: +86 152 1094 6968 
> gpg key: 0x187F664F
>
> ___
> 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




--
Tang Yaguang

Canonical Ltd. | www.ubuntu.com  | 
www.canonical.com 

Mobile:  +86 152 1094 6968
gpg key: 0x187F664F


___
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] [tempest][scenario] independece test between Stack and backing services?

[Martina Kollarova]

Hi Sean,

I'm already working on something similar. What I'm trying to do is not 
a service, but a set of tests that would be able to run commands on the 
nodes and restart services, kill disks, etc. The basic idea is to 
inject some fault, see if everything still works as expected and 
restore the state back to what it was before the fault. So far I only 
have some basic tests for Swift, but I'm planning more. The state 
restoration is going to be via snapshots (so it will have to be running 
in VMs, or I could add support for LVM snapshots too) .


The project is called DestroyStack and is located here:
https://github.com/mkollaro/destroystack/tree/devel

It's still WIP, please don't try to run it yet, not everything is 
implemented. I'm currently trying to create that demo.


Martina

On Wed 02 Apr 2014 12:34:43 PM CEST, Sean Dague wrote:

Fault injection is a problem I've been thinking about, though I don't
have time to dive into it any time soon. But I'll share my ideas in case
they are interesting.

I think we need a Fault Injection Service for OpenStack. It would act
like many of the other OpenStack services, have an API service, and a
worker on every node. It would be our own kind of chaos monkey, except
very programmable. It would look like any multi host service,
communicating over RPC between API and the nodes.

The Fault injection service would have the ability to kill process on
the hosts (libvirt, nova-compute, c-vol). It would also have the ability
to delete did data (simulating a hardware fault).

We could definitely use something like this to also signal a service
restart, or some other behind the scenes action that we'd expect would
be regularly happening.

If we had a Fault Injection service, then we could have a class of tests
(possibly in Tempest, possibly in another place) which would start
resources with the OpenStack API, then inject faults, then continue
along the way.

I feel like Juno is too soon for this, as we have lots of other issues
to address. However, K might work. That being said, if anyone wants to
dive in early, have at. The important thing would be that this has REST
API, and that it be multi node.

-Sean

On 04/02/2014 04:37 AM, Tomoya Goto wrote:

Hello, Igawa-san

Thanks for pointing out Tempest principles. I wasn't aware of them.

ok, I'll probably use the current test cases with manually stopping
services.
I'm checking with Temest(icehouse) and if I write or think up something
useful, I'll be back.  Also Grenade, too. :)


Thank you  for valuable advices,
 - Tomoya Goto




Hi,

On 04/02, Tomoya Goto wrote:

Thanks for quick replies Igawa-san and Mr.Sean! :)
   and sorry foy my slow reply :(


np :)




The task I wantetd to conduct is not only for upgrading but also for
rather small maintenace, say stopping openstack-cinder* for changing
configuration.

Now, Grenade is for upgrade purpose but not for such small
maintenace, right?
So I think tempest is more suitable than Grenade for such task.

what do you say?


This kind (fault injection?) of tests that you said are interesting and
we should have them in future. But Tempest should not operate OpenStack
components directly. e.g. stop/start Cinder/Glance/Nova services.
This is one of design principles[1]. So I think we need a new project
for these types of tests or need to change the principles.

[1]
http://docs.openstack.org/developer/tempest/overview.html#design-principles


Thanks,
-- Masayuki Igawa



   - Tomoya Goto



You are correct. The testing we do for this is in Grenade, which we run
in the gate. Grenade tests an upgrade from last stable release to
current master. It creates a few resources before the upgrade, and
fails
if those are interupted after the upgrade.

Grenade is still pretty light on the number of resources it creates
before the upgrade, and is definitely a place where enhancement is
welcome.

 -Sean


On 04/01/2014 04:18 AM, Masayuki Igawa wrote:

Hi Goto-san,

I think this is an interesting test case. But AFAIK, Tempest and its
scenario tests don't have such test cases now, and we can't stop the
OpenStack processes through Tempest.

Do you know Grenade[1]? I think Grenade is the only one upgrading
test in
the OpenStack community now. So I guess Grenade can test these kind of
tests but not yet though.

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


On 04/01, 後藤 僚哉 wrote:

Hello everyone.

I'm looking for an independence test between an OpenStack environment
and virtual environments.

In case of updating an openstack environment, you need to stop each
OpenStack process, but you don't want the instances to be affected by
OpenStack outages.
So before maintenane, you want to make sure OpenStack and backing
services(KVM, OVS, storage,.) are separate.

For example.
   1) Creating a virtual environment on a OpenStack environment. this
includes Nova instances, Neutron L2/3 networks, Cinder volumes and
etc.


I'd like to clarify more. Do you mean OpenStack on OpenStack
environment?

Re: [openstack-dev] Keystone PTL Candidacy

[Tristan Cacqueray]

confirmed

On 04/02/2014 02:48 PM, Dolph Mathews wrote:
> Hello, everyone!
> 
> I'd like to keep my name in the hat as PTL for Keystone during the Juno
> release cycle.
> 
> As I'm not looking to shake things up for Juno, I'm going to direct you to
> my Icehouse PTL candidacy email [1], and promise that I will continue to
> deliver on that philosophy in Juno.
> 
> Specifically, it's worth reiterating that my primary focus is in "...
> supporting our outstanding community of contributors in any way that I can
> so that they can be as productive as possible. Never mind the PTL,
> Keystone's success would not be possible without the community behind it."
> 
> I actually view the client-side pieces to be the most important parts of
> keystone (and keystoneclient.middleware.auth_token, in particular) due to
> the more immediate impact on our stakeholders. In terms of Juno, I'm
> especially looking forward to landing support for ephemeral, signed tokens
> backed by revocation events on the client-side, along with increasing
> adoption for keystoneclient.session (and therefore the v3 API) across
> OpenStack.
> 
> To all of our contributors during Icehouse: THANK YOU!
> 
> -Dolph
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2013-September/015387.html
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




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 PTL Candidacy

[Dolph Mathews]

Hello, everyone!

I'd like to keep my name in the hat as PTL for Keystone during the Juno
release cycle.

As I'm not looking to shake things up for Juno, I'm going to direct you to
my Icehouse PTL candidacy email [1], and promise that I will continue to
deliver on that philosophy in Juno.

Specifically, it's worth reiterating that my primary focus is in "...
supporting our outstanding community of contributors in any way that I can
so that they can be as productive as possible. Never mind the PTL,
Keystone's success would not be possible without the community behind it."

I actually view the client-side pieces to be the most important parts of
keystone (and keystoneclient.middleware.auth_token, in particular) due to
the more immediate impact on our stakeholders. In terms of Juno, I'm
especially looking forward to landing support for ephemeral, signed tokens
backed by revocation events on the client-side, along with increasing
adoption for keystoneclient.session (and therefore the v3 API) across
OpenStack.

To all of our contributors during Icehouse: THANK YOU!

-Dolph

[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015387.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Trove] Icehouse RC1 available

[Thierry Carrez]

Hello everyone,

Trove just published its first Icehouse release candidate. The list of
bugs fixed since feature freeze and the RC1 tarball are available at:

https://launchpad.net/trove/icehouse/icehouse-rc1

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the 2014.1 final
version on April 17. You are therefore strongly encouraged to test and
validate this tarball.

Alternatively, you can directly test the milestone-proposed branch at:
https://github.com/openstack/trove/tree/milestone-proposed

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/trove/+filebug

and tag it *icehouse-rc-potential* to bring it to the release crew's
attention.

Note that the "master" branch of Trove is now open for Juno
development, and feature freeze restrictions no longer apply there.

Regards,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] Nova Live Migration issue

[abhishek jain]

Hi Parthi

I have confirmed on the destination node i.e( newer compute node on which
the instance is migrated ) by using sudo virsh list and the instance is
being  reflected there.

Moreover on the source node the sudo virsh list command reflects nothing.
Also I'll try with libvirt 1.x and let you know the result.

I'll also try to send you the libvirt logs whenever i try the setup again.

Thanks


On Wed, Apr 2, 2014 at 5:14 PM, Parthipan, Loganathan wrote:

>  Hello Abhishek,
>
>
>
> Did you check on the source node whether the instance is still running or
> even defined (virsh list -all). This is because nova notices that the
> migration is completed when the VM in the source is gone and then triggers
> the post-migration.
>
>
>
> IIRC, there's a bug in 0.x libvirt where the destination qemu
> disconnection is not picked up by the source libvirt, causing nova
> migration thread to wait. I don't know if libvirt 1.x works with nova
> properly yet.
>
>
>
> Cheers
>
> ~parthi
>
>
>
>
>
> *From:* abhishek jain [mailto:ashujain9...@gmail.com]
> *Sent:* 02 April 2014 12:28
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] Nova Live Migration issue
>
>
>
> Thanks Nikolay and Parthipan
>
>
> I have confirmed that the instance is running on the newer compute node by
> using sudo virsh list command.
>
> I'm using below libvirt version ..
>
> libvirtd (libvirt) 0.9.8
>
> Actually I will not be able to present  the libvirt logs due to setup
> problem.I'll send logs as soon as possible.
>
> Please let me know if any thing needs to be taken care in libvirt during
> the configuration
>
>
>
>
>
> On Wed, Apr 2, 2014 at 3:00 PM, Parthipan, Loganathan 
> wrote:
>
> Can you confirm that it's no longer running on the source node and only
> running on the destination node?
>
>
>
> What's your libvirt version?
>
>
>
> Possibly the libvirt monitor lost connection and didn't complete the
> post-migration which would update the db. As Nikolay suggested, the
> libvirt.log would tell more, good if it also had debug turned on.
>
>
>
> *From:* Nikolay Starodubtsev [mailto:nstarodubt...@mirantis.com]
> *Sent:* 02 April 2014 09:01
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] Nova Live Migration issue
>
>
>
> Hi!
> Can you show libvirt logs?
>
>
>
>
> Nikolay Starodubtsev
>
> Software Engineer
>
> Mirantis Inc.
>
>
>
> Skype: dark_harlequine1
>
>
>
> 2014-04-02 11:55 GMT+04:00 abhishek jain :
>
> Hi all
>
> I'm following the below link for VM migration from one compute node to the
> another from the controller node using devstack ..
>
>
> http://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/
>
> I'm able to migrate the instance from one compute node to the other
> compute node using the below command.
>
> nova live-migration b33b23f8-4510-4ed3-8cd1-2d68c8186e40 salaria1
>
> The instance is able to migrate properly and that i have confirmed using
> the sudo virsh list command over the newer compute node.
>
>
> However the problem is when i type nova list at the same time.The status
> of instance is stuck at migrating and does not changes even after some time.
>
> Moreover when i type nova show  command,the old host of the
> instance is reflected instead of the new one.
>
> Please help regarding this.
>
> Thanks
>
> Abhishek Jain
>
>
> ___
> 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 Live Migration issue

[Parthipan, Loganathan]

Hello Abhishek,

Did you check on the source node whether the instance is still running or even 
defined (virsh list -all). This is because nova notices that the migration is 
completed when the VM in the source is gone and then triggers the 
post-migration.

IIRC, there's a bug in 0.x libvirt where the destination qemu disconnection is 
not picked up by the source libvirt, causing nova migration thread to wait. I 
don't know if libvirt 1.x works with nova properly yet.

Cheers
~parthi


From: abhishek jain [mailto:ashujain9...@gmail.com]
Sent: 02 April 2014 12:28
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Nova Live Migration issue

Thanks Nikolay and Parthipan

I have confirmed that the instance is running on the newer compute node by 
using sudo virsh list command.
I'm using below libvirt version ..

libvirtd (libvirt) 0.9.8
Actually I will not be able to present  the libvirt logs due to setup 
problem.I'll send logs as soon as possible.
Please let me know if any thing needs to be taken care in libvirt during the 
configuration


On Wed, Apr 2, 2014 at 3:00 PM, Parthipan, Loganathan 
mailto:parthi...@hp.com>> wrote:
Can you confirm that it's no longer running on the source node and only running 
on the destination node?

What's your libvirt version?

Possibly the libvirt monitor lost connection and didn't complete the 
post-migration which would update the db. As Nikolay suggested, the libvirt.log 
would tell more, good if it also had debug turned on.

From: Nikolay Starodubtsev 
[mailto:nstarodubt...@mirantis.com]
Sent: 02 April 2014 09:01
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Nova Live Migration issue

Hi!
Can you show libvirt logs?




Nikolay Starodubtsev

Software Engineer

Mirantis Inc.



Skype: dark_harlequine1

2014-04-02 11:55 GMT+04:00 abhishek jain 
mailto:ashujain9...@gmail.com>>:
Hi all
I'm following the below link for VM migration from one compute node to the 
another from the controller node using devstack ..

http://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/
I'm able to migrate the instance from one compute node to the other compute 
node using the below command.

nova live-migration b33b23f8-4510-4ed3-8cd1-2d68c8186e40 salaria1
The instance is able to migrate properly and that i have confirmed using the 
sudo virsh list command over the newer compute node.

However the problem is when i type nova list at the same time.The status of 
instance is stuck at migrating and does not changes even after some time.
Moreover when i type nova show  command,the old host of the 
instance is reflected instead of the new one.
Please help regarding this.
Thanks
Abhishek Jain

___
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] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Sebastian Herzberg]

Hi,

from my side there is definite interest in this, as the changes didn’t make it 
yet.

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

Re: [openstack-dev] Nova Live Migration issue

[abhishek jain]

Thanks Nikolay and Parthipan

I have confirmed that the instance is running on the newer compute node by
using sudo virsh list command.
I'm using below libvirt version ..

libvirtd (libvirt) 0.9.8

Actually I will not be able to present  the libvirt logs due to setup
problem.I'll
send logs as soon as possible.
Please let me know if any thing needs to be taken care in libvirt during
the configuration




On Wed, Apr 2, 2014 at 3:00 PM, Parthipan, Loganathan wrote:

>  Can you confirm that it's no longer running on the source node and only
> running on the destination node?
>
>
>
> What's your libvirt version?
>
>
>
> Possibly the libvirt monitor lost connection and didn't complete the
> post-migration which would update the db. As Nikolay suggested, the
> libvirt.log would tell more, good if it also had debug turned on.
>
>
>
> *From:* Nikolay Starodubtsev [mailto:nstarodubt...@mirantis.com]
> *Sent:* 02 April 2014 09:01
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] Nova Live Migration issue
>
>
>
> Hi!
> Can you show libvirt logs?
>
>
>
>
> Nikolay Starodubtsev
>
> Software Engineer
>
> Mirantis Inc.
>
>
>
> Skype: dark_harlequine1
>
>
>
> 2014-04-02 11:55 GMT+04:00 abhishek jain :
>
> Hi all
>
> I'm following the below link for VM migration from one compute node to the
> another from the controller node using devstack ..
>
>
> http://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/
>
> I'm able to migrate the instance from one compute node to the other
> compute node using the below command.
>
> nova live-migration b33b23f8-4510-4ed3-8cd1-2d68c8186e40 salaria1
>
> The instance is able to migrate properly and that i have confirmed using
> the sudo virsh list command over the newer compute node.
>
>
> However the problem is when i type nova list at the same time.The status
> of instance is stuck at migrating and does not changes even after some time.
>
> Moreover when i type nova show  command,the old host of the
> instance is reflected instead of the new one.
>
> Please help regarding this.
>
> Thanks
>
> Abhishek Jain
>
>
> ___
> 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] Facing an issue in swift

[Coles, Alistair]

In my experience 'Endpoint for object-store not found - have you specified a 
region?' can be returned by swift client if:

(a) You have specified a region that isn't found among the service endpoints 
e.g.

% swift --os-auth-url http://example:5000/v2.0 --os-password=testing stat 
--os-username=tester  --os-tenant-name=test --os-region-name=foo
Endpoint for object-store not found - have you specified a region?

Or (b) you did not specify a tenant-name or tenant-id e.g.

% swift --os-auth-url http://example:5000/v2.0 --os-password=testing stat 
--os-username=tester
Endpoint for object-store not found - have you specified a region?



From: Sowmya Nethi [mailto:sowmya_ne...@persistent.co.in]
Sent: 02 April 2014 07:43
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Facing an issue in swift

Hi all,
   Question: Endpoint for object-store not found - have you specified a region?

  I am facing this issue while integrating swift with keystone in havana:
  I changed proxy-server.conf file with the below contents
   [pipeline:main]
   pipeline = authtoken keystoneauth proxy-logging proxy-server

   [filter:authtoken]
paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory
auth_host = controller
auth_port = 35357
auth_protocol = http
auth_uri = http://10.233.52.110:35357/v2.0
admin_tenant_name = admin
admin_user = admin
admin_password = ADMIN_PASS
cache = swift.cache
include_service_catalog = False

[filter:keystoneauth]
use = egg:swift#keystoneauth
operator_roles = admin, swiftoperator

 and restarted all the swift services, while executing swift commands 
output is Endpoint for object-store not found - have you specified a region?
 Can anyone help me on this issue ?
 And I referred the below link:
 http://docs.openstack.org/developer/swift/overview_auth.html



Thanks and Regards,
Sowmya Nethi

sowmya_ne...@persistent.co.in | Tel: 
+91(40)674 42026
Persistent Systems Ltd. |  Partners in Innovation | 
www.persistentsys.com


DISCLAIMER == This e-mail may contain privileged and confidential 
information which is the property of Persistent Systems Ltd. It is intended 
only for the use of the individual or entity to which it is addressed. If you 
are not the intended recipient, you are not authorized to read, retain, copy, 
print, distribute or use this message. If you have received this communication 
in error, please notify the sender and delete all copies of this message. 
Persistent Systems Ltd. does not accept any liability for virus infected mails.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Documenting FWaaS

[Israel Ziv]

Hi!
I am currently documenting FWaaS for development purposes. My focus is to have 
a detailed end-to-end flow (from plugin to driver.
I thought it would be a good idea to share my deliverables (document + images) 
with the community and have feedback from the community.
Since I am a newcomer to openstack-dev I am not sure what will be the proper 
location where to place these deliverables.
Thanks
Israel Ziv (israel@huawei.com )
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Missleading and hardly parseable default neutron config files

[Salvatore Orlando]

Hi Thomas,

it probably won't be a bad idea if you can share the patches you're
applying to the default configuration files.
I think all distros are patching them anyway, so this might allow us to
provide mostly ready to use config files.

Is there a chance you can push something to gerrit?

Salvatore


On 2 April 2014 12:12, Thomas Goirand  wrote:

> Hi,
>
> The default neutron configuration files aren't useable by default. So,
> I'm heavily patching them in my Debian package. This isn't an idea
> situation already, especially that I have to rebase my patch on each
> (pre-)release. Though here, if I'm not mistaking, we're having a
> completely *wrong* example as a comment. From the default neutron.conf:
>
> # Example: service_plugins = router,firewall,lbaas,vpnaas,metering
>
> AFAIU, "router" and "firewall" aren't valid values (they make
> neutron-db-manage crash dump for example), and we should use instead
> something like:
>
> service_plugins = l3_router,fwaas,lbaas,vpnaas,metering
>
> Am I mistaking? If no, then how come neutron.conf advertizes for
> non-working directive values?
>
> Also, and it's been like this for quite long: what Neutron ships as
> configuration file isn't parseable in a satisfying way. For example,
> everywhere in the files, we have things like this:
>
> # Example:
> # connection = mysql://root:pass@127.0.0.1:3306/neutron
> # Replace 127.0.0.1 above with the IP address of the database used
> # by the main neutron server. (Leave it as is if the database runs
> # on this host.)
> # connection = sqlite://
>
> (above comments rewraped to make it fit in this message)
>
> How exactly a script is supposed to make the difference between the 2
> commented-out "connection" directives? They both look like occurrences
> of the same directives, and there's no way to distinguish the first one
> (and example) from the 2nd one (a commented out directive). Could we
> instead use something like this instead?
>
> -# Example:
> -# connection = mysql://root:pass@127.0.0.1:3306/neutron
> +# Example: connection = mysql://root:pass@127.0.0.1:3306/neutron
>
> It'd be nice if these changes could make it to the Icehouse release.
>
> Thoughts anyone?
> Cheers,
>
> Thomas Goirand (zigo)
>
> ___
> 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] [tempest][scenario] independece test between Stack and backing services?

[Sean Dague]

Fault injection is a problem I've been thinking about, though I don't
have time to dive into it any time soon. But I'll share my ideas in case
they are interesting.

I think we need a Fault Injection Service for OpenStack. It would act
like many of the other OpenStack services, have an API service, and a
worker on every node. It would be our own kind of chaos monkey, except
very programmable. It would look like any multi host service,
communicating over RPC between API and the nodes.

The Fault injection service would have the ability to kill process on
the hosts (libvirt, nova-compute, c-vol). It would also have the ability
to delete did data (simulating a hardware fault).

We could definitely use something like this to also signal a service
restart, or some other behind the scenes action that we'd expect would
be regularly happening.

If we had a Fault Injection service, then we could have a class of tests
(possibly in Tempest, possibly in another place) which would start
resources with the OpenStack API, then inject faults, then continue
along the way.

I feel like Juno is too soon for this, as we have lots of other issues
to address. However, K might work. That being said, if anyone wants to
dive in early, have at. The important thing would be that this has REST
API, and that it be multi node.

-Sean

On 04/02/2014 04:37 AM, Tomoya Goto wrote:
> Hello, Igawa-san
> 
> Thanks for pointing out Tempest principles. I wasn't aware of them.
> 
> ok, I'll probably use the current test cases with manually stopping
> services.
> I'm checking with Temest(icehouse) and if I write or think up something
> useful, I'll be back.  Also Grenade, too. :)
> 
> 
> Thank you  for valuable advices,
> - Tomoya Goto
> 
> 
> 
>> Hi,
>>
>> On 04/02, Tomoya Goto wrote:
>>> Thanks for quick replies Igawa-san and Mr.Sean! :)
>>>   and sorry foy my slow reply :(
>>
>> np :)
>>
>>>
>>>
>>> The task I wantetd to conduct is not only for upgrading but also for
>>> rather small maintenace, say stopping openstack-cinder* for changing
>>> configuration.
>>>
>>> Now, Grenade is for upgrade purpose but not for such small
>>> maintenace, right?
>>> So I think tempest is more suitable than Grenade for such task.
>>>
>>> what do you say?
>>
>> This kind (fault injection?) of tests that you said are interesting and
>> we should have them in future. But Tempest should not operate OpenStack
>> components directly. e.g. stop/start Cinder/Glance/Nova services.
>> This is one of design principles[1]. So I think we need a new project
>> for these types of tests or need to change the principles.
>>
>> [1]
>> http://docs.openstack.org/developer/tempest/overview.html#design-principles
>>
>>
>> Thanks,
>> -- Masayuki Igawa
>>
>>>
>>>   - Tomoya Goto
>>>
>>>
 You are correct. The testing we do for this is in Grenade, which we run
 in the gate. Grenade tests an upgrade from last stable release to
 current master. It creates a few resources before the upgrade, and
 fails
 if those are interupted after the upgrade.

 Grenade is still pretty light on the number of resources it creates
 before the upgrade, and is definitely a place where enhancement is
 welcome.

 -Sean


 On 04/01/2014 04:18 AM, Masayuki Igawa wrote:
> Hi Goto-san,
>
> I think this is an interesting test case. But AFAIK, Tempest and its
> scenario tests don't have such test cases now, and we can't stop the
> OpenStack processes through Tempest.
>
> Do you know Grenade[1]? I think Grenade is the only one upgrading
> test in
> the OpenStack community now. So I guess Grenade can test these kind of
> tests but not yet though.
>
> [1] https://wiki.openstack.org/wiki/Grenade
>
>
> On 04/01, 後藤 僚哉 wrote:
>> Hello everyone.
>>
>> I'm looking for an independence test between an OpenStack environment
>> and virtual environments.
>>
>> In case of updating an openstack environment, you need to stop each
>> OpenStack process, but you don't want the instances to be affected by
>> OpenStack outages.
>> So before maintenane, you want to make sure OpenStack and backing
>> services(KVM, OVS, storage,.) are separate.
>>
>> For example.
>>   1) Creating a virtual environment on a OpenStack environment. this
>> includes Nova instances, Neutron L2/3 networks, Cinder volumes and
>> etc.
>
> I'd like to clarify more. Do you mean OpenStack on OpenStack
> environment?
> Or just mean VMs on OpenStack env?
>>>
>>> I meant just VMs on OpenStack env.
>>> When you stop some processes for update, say openstack-cinder-*, you
>>> want to make sure it won't disconnect volume/VM.
>>
>> Thanks, I got it.
>>
>>>
>>   2) Stopping one or more OpenStack's processes.
>
> Currently, Tempest can't stop the OpenStack processes. Because Tempest
> can operate OpenStack components through OpenStack APIs only for now.
>>>

[openstack-dev] Missleading and hardly parseable default neutron config files

[Thomas Goirand]

Hi,

The default neutron configuration files aren't useable by default. So,
I'm heavily patching them in my Debian package. This isn't an idea
situation already, especially that I have to rebase my patch on each
(pre-)release. Though here, if I'm not mistaking, we're having a
completely *wrong* example as a comment. From the default neutron.conf:

# Example: service_plugins = router,firewall,lbaas,vpnaas,metering

AFAIU, "router" and "firewall" aren't valid values (they make
neutron-db-manage crash dump for example), and we should use instead
something like:

service_plugins = l3_router,fwaas,lbaas,vpnaas,metering

Am I mistaking? If no, then how come neutron.conf advertizes for
non-working directive values?

Also, and it's been like this for quite long: what Neutron ships as
configuration file isn't parseable in a satisfying way. For example,
everywhere in the files, we have things like this:

# Example:
# connection = mysql://root:pass@127.0.0.1:3306/neutron
# Replace 127.0.0.1 above with the IP address of the database used
# by the main neutron server. (Leave it as is if the database runs
# on this host.)
# connection = sqlite://

(above comments rewraped to make it fit in this message)

How exactly a script is supposed to make the difference between the 2
commented-out "connection" directives? They both look like occurrences
of the same directives, and there's no way to distinguish the first one
(and example) from the 2nd one (a commented out directive). Could we
instead use something like this instead?

-# Example:
-# connection = mysql://root:pass@127.0.0.1:3306/neutron
+# Example: connection = mysql://root:pass@127.0.0.1:3306/neutron

It'd be nice if these changes could make it to the Icehouse release.

Thoughts anyone?
Cheers,

Thomas Goirand (zigo)

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