Re: [openstack-dev] [higgins][devstack][swift] Service name conflict in devstack

[Sheel Rana Insaan]

Dear Eli Qiao,

>@Higgins team
>I workaround it by naming them as "higgi-api" and "higgi-cond" (seems no
magic in "-i")
>Also, the api-port number as "9517", any comments?

We should update the regex.
s- should be updated to ^s- @
https://github.com/openstack-dev/devstack/blob/master/lib/swift#L163

 "[[ ,${ENABLED_SERVICES} =~ ,"s-" ]]" should be updated to [[ ,
${ENABLED_SERVICES} =~ ,^s- ]]"
(this regex is still not tested, but regex update will work, this or that
way)

I will update this for swift soon in devstack after discussing with swift
team.

So, you can continue with higgins- as service name.

Please let me know in case I missed, something else, you wanted to point.

Best Regards,
Sheel Rana

On Fri, May 27, 2016 at 11:15 AM, taget  wrote:

> hi team,
>
> I am working on adding devstack plugin for Higgins, meet some troubles.
>
> I named the service name as higgins-api, higgins-cond. in the plugin, but
> I found that devstack try to install swift service,
> and I got the reason is that [1], swift plugin try to grep 's-' in the
> service name, this may not so good for other new project which has 's-'
> in it's service.
>
> Can we improve swift plugin to use full service name?
> Is there any doc that how to naming a new service or the service name list
> of OpenStack?
>
> @Higgins team
> I workaround it by naming them as "higgi-api" and "higgi-cond" (seems no
> magic in "-i")
> Also, the api-port number as "9517", any comments?
>
>
> [1] https://github.com/openstack-dev/devstack/blob/master/lib/swift#L163
>
>
> --
> Best Regards, Eli Qiao (乔立勇)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [congress] Spec for congress.conf

[Masahito MUROI]

Hi Bryan,

Oslo.config that Congress uses to manage config sets each fields to 
default value if you don't specify your configured values in 
congress.conf. In that meaning, all config is option/required.


In my experience, config values differing from each deployment, like ip 
address and so on, have to be configured, but others might be configured 
when you want Congress to run with different behaviors.


best regard,
Masahito

On 2016/05/27 3:36, SULLIVAN, BRYAN L wrote:

Hi Congress team,



Quick question for anyone. Is there a spec for fields in congress.conf
file? As of Liberty this has to be tox-generated but I need to know
which conf values are required vs optional. The generated sample output
doesn't clarify that. This is for the Puppet Module and JuJu Charm I am
developing with the help of RedHat and Canonical in OPNFV. I should have
Congress installed by default (for the RDO and JuJu installers) in the
OPNFV Colorado release in the next couple of weeks, and the
congress.conf file settings are an open question. The Puppet module will
also be used to create a Fuel plugin for installation.



Thanks,

Bryan Sullivan | AT&T





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] prototype of a DSL for generating Dockerfiles

[Steven Dake (stdake)]

On 5/26/16, 8:45 PM, "Swapnil Kulkarni (coolsvap)"  wrote:

>On Fri, May 27, 2016 at 8:35 AM, Steven Dake (stdake) 
>wrote:
>> Hey folks,
>>
>> While Swapnil has been busy churning the dockerfile.j2 files to all
>>match
>> the same style, and we also had summit where we declared we would solve
>>the
>> plugin problem, I have decided to begin work on a DSL prototype.
>>
>> Here are the problems I want to solve in order of importance by this
>>work:
>>
>> Build CentOS, Ubuntu, Oracle Linux, Debian, Fedora containers
>> Provide a programmatic way to manage Dockerfile construction rather
>>then a
>> manual (with vi or emacs or the like) mechanism
>> Allow complete overrides of every facet of Dockerfile construction, most
>> especially repositories per container (rather than in the base
>>container) to
>> permit the use case of dependencies from one version with dependencies
>>in
>> another version of a different service
>> Get out of the business of maintaining 100+ dockerfiles but instead
>>maintain
>> one master file which defines the data that needs to be used to
>>construct
>> Dockerfiles
>> Permit different types of optimizations or Dockerfile building by
>>changing
>> around the parser implementation ­ to allow layering of each operation,
>>or
>> alternatively to merge layers as we do today
>>
>> I don't believe we can proceed with both binary and source plugins
>>given our
>> current implementation of Dockerfiles in any sane way.
>>
>> I further don't believe it is possible to customize repositories &
>>installed
>> files per container, which I receive increasing requests for offline.
>>
>> To that end, I've created a very very rough prototype which builds the
>>base
>> container as well as a mariadb container.  The mariadb container builds
>>and
>> I suspect would work.
>>
>> An example of the DSL usage is here:
>> https://review.openstack.org/#/c/321468/4/dockerdsl/dsl.yml
>>
>> A very poorly written parser is here:
>> https://review.openstack.org/#/c/321468/4/dockerdsl/load.py
>>
>> I played around with INI as a format, to take advantage of oslo.config
>>and
>> kolla-build.conf, but that didn't work out.  YML is the way to go.
>>
>> I'd appreciate reviews on the YML implementation especially.
>>
>> How I see this work progressing is as follows:
>>
>> A yml file describing all docker containers for all distros is placed in
>> kolla/docker
>> The build tool adds an option ‹use-yml which uses the YML file
>> A parser (such as load.py above) is integrated into build.py to lay
>>down he
>> Dockerfiles
>> Wait 4-6 weeks for people to find bugs and complain
>> Make the ‹use-yml the default for 4-6 weeks
>> Once we feel confident in the yml implementation, remove all
>>Dockerfile.j2
>> files
>> Remove ‹use-yml option
>> Remove all jinja2-isms from build.py
>>
>> This is similar to the work that took place to convert from raw
>>Dockerfiles
>> to Dockerfile.j2 files.  We are just reusing that pattern.  Hopefully
>>this
>> will be the last major refactor of the dockerfiles unless someone has
>>some
>> significant complaints about the approach.
>>
>> Regards
>> -steve
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>The DSL template to generate the Dockerfile seems way better than the
>jinja templates in terms of extension which is currently a major
>bottleneck in the plugin implementation. I am +2+W on this plan of
>action to test it for next 4-6 weeks and see thereon.
>
>Swapnil
>

Agree.

Customization and plugins are the trigger for the work.  I was thinking of
the following:

Elemental.yml (ships with Kolla)
Elemental-merge.yml (operator provides in /etc/kolla, this file is yaml
merged with elemental.yml)
Elemental-override.yml (operator provides in /etc/kolla, this file
overrides any YAML sections defined)

I think merging and overriding the yaml files should be pretty easy,
compared to jinja2, where I don't even know where to begin in a way that
the operator doesn't have to have deep knowledge of Kolla's internal
implementation.

Regards
-steve
  
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [higgins][devstack][swift] Service name conflict in devstack

[taget]

hi team,

I am working on adding devstack plugin for Higgins, meet some troubles.

I named the service name as higgins-api, higgins-cond. in the plugin, 
but I found that devstack try to install swift service,
and I got the reason is that [1], swift plugin try to grep 's-' in the 
service name, this may not so good for other new project which has 's-'

in it's service.

Can we improve swift plugin to use full service name?
Is there any doc that how to naming a new service or the service name 
list of OpenStack?


@Higgins team
I workaround it by naming them as "higgi-api" and "higgi-cond" (seems no 
magic in "-i")

Also, the api-port number as "9517", any comments?


[1] https://github.com/openstack-dev/devstack/blob/master/lib/swift#L163


--
Best Regards, Eli Qiao (乔立勇)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] What's Up, Doc? 27 May 2016

[Lana Brindley]

Hi everyone,

This week I've been focused on getting the Install Guide project back up and 
running, with the team meeting being rebooted, our specs finally merged, and 
organising the list of tasks to be getting on with. Also, don't forget to vote 
in our naming poll: http://goo.gl/forms/Eqf9WOGqsXjkRbdc2 I'm still very much 
in need of representatives from the various project teams to pitch in and help 
us get things running. Please make sure your project is represented by coming 
along to meetings, or at least contacting us through the mailing list.

In other news, the Ops and Arch Guide re-architecture is proceeding apace. 
Specs were merged this week, and the new Arch Guide ToC is looking great! Check 
it out here: 
http://specs.openstack.org/openstack/docs-specs/specs/newton/arch-guide-restructure.html
 We are also still looking for feedback on the current Ops guide. Add your 
notes here: https://etherpad.openstack.org/p/ops-guide-reorg

== Progress towards Newton ==

131 days to go!

Bugs closed so far: 107

Newton deliverables 
https://wiki.openstack.org/wiki/Documentation/NewtonDeliverables
Feel free to add more detail and cross things off as they are achieved 
throughout the release.

== Speciality Team Reports ==

'''HA Guide: Bogdan Dobrelya'''
No report this week.

'''Install Guide: Lana Brindley'''
Specs are now merged, an blueprints created. Tasks listed here: 
https://wiki.openstack.org/wiki/Documentation/InstallGuideWorkItems Please go 
ahead and pick up work items. Need project representation in meetings. Next 
meeting: Tue 7 June 0600 UTC

'''Networking Guide: Edgar Magana'''
We did not have meeting this week. Nothing to report. Next IRC meeting: 
Thursday June 2nd at 1600 UTC

'''Security Guide: Nathaniel Dillon'''
No report this week.

'''User Guides: Joseph Robinson'''
Action items to follow up - email meeting minutes to the mailing list to update 
the community.
Currently, the team has two contributors. Please let me know if you're 
interested in working on the User Guide Team.

'''Ops Guide: Shilla Saebi'''
Shilla & Darren working on collecting enterprise docs to push upstream
Ops tasks are documented here: https://etherpad.openstack.org/p/ops-arch-tasks
OpenStack ops guide reorg in progress & documented here: 
https://etherpad.openstack.org/p/ops-guide-reorg
Spec was merged: https://review.openstack.org/#/c/311998/

'''API Guide: Anne Gentle'''
No report this week.

'''Config/CLI Ref: Tomoyuki Kato'''
A few configuration docs patches for some vendor plug-ins has been merged, with 
mitaka backport.
Heat CLI is marked as deprecated.

'''Training labs: Pranav Salunke, Roger Luethi'''
No report this week.

'''Training Guides: Matjaz Pancur'''
Updates for Upstream training material

'''Hypervisor Tuning Guide: Blair Bethwaite
No report this week.

'''UX/UI Guidelines: Michael Tullis, Stephen Ballard'''
No report this week.

== Site Stats ==

This month, two thirds of our site visitors have been using their Mac to read 
the docs. Just under 30% used Windows, and Linux rounded out the remainder at 
4%.

So far in the Install Guide naming poll, "OpenStack Installation Tutorial" has 
a commanding lead at 30%, with "Basic Install Guide" and "OpenStack Evaluation 
Setup Guide" (try saying that ten times fast!) tying for second place with 17% 
of the vote each. I'll keep the poll open for another week or so, and announce 
our winning name in next week's newsletter.

== Doc team meeting ==

Next meetings:

The US meeting was held this week, you can read the minutes here: 
https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2016-05-25

Next meetings:
APAC: Wednesday 1 June, 00:30 UTC
US: Wednesday 8 June, 19:00 UTC

Please go ahead and add any agenda items to the meeting page here: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#27_May_2016

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kuryr] Docker failed to add an existed network with GW interface already created

[毛立平]

Hi Irena,


Thanks for your comments.

Currently, kuryr will create gw port with owner kuryr:container, but this GW 
can't work obviously.
it can be modified to create gw port with owner network:router_interface, but 
seems like CNM module
do not have action can be map with attach GW with vrouter.

Do we have any reason why we need just create a neutron port but do not use 
it(attach to vrouter)?

So I still think we can leave it in neutron router-interface-add / 
router-interface-delete .
 what do you think?



Regards,
Liping Mao




At 2016-05-26 20:03:24, "Irena Berezovsky"  wrote:

Hi Liping Mao,




On Thu, May 26, 2016 at 12:31 PM, Liping Mao (limao)  wrote:
Hi Vikas, Antoni and Kuryr team,

When I use kuryr, I notice kuryr will failed to add an existed
network with gateway interface already created by neutron[1][2].

The bug is because kuryr will create a neutron port for gw
port in ipam_request_address.

I think kuryr should not do actual create neutron gw port at all.
Because CNM module do not have concept map with Neutron vRouter.
Till now, user have to use neutron api to attach GW port in
private network with vRouter. So I think the Kuryr should not
actually create GW port.


I think it possible to define via kuryr configuration file if kuryr should 
create or not gw port. Kuryr already does it for DHCP port.
What do you think? Thanks for any comments.


[1] https://bugs.launchpad.net/kuryr/+bug/1584286
[2] https://review.openstack.org/#/c/319524/4



Regards，
Liping Mao

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker] Proposing Lin Cheng for tacker-horizon core team

[Janki Chhatbar]

+1

Thanking you
Janki Chhatbar
OpenStack | SDN | Docker
simplyexplainedblog.wordpress.com
On May 26, 2016 11:16 PM, "Sridhar Ramaswamy"  wrote:

> Tackers,
>
> I'd like to propose Lin Cheng to join as a tacker-horizon core team
> member. Lin has been our go-to person for all guidance related to UI
> enhancements for Tacker. He has been actively reviewing patchsets in
> this area [1] and also contributed to setup the unit test framework for
> tacker-horizon repo.
>
> Please provide your +1/-1 votes.
>
> - Sridhar
>
> [1]
> http://stackalytics.com/?project_type=all&metric=marks&release=all&module=tacker-group&user_id=lin-hua-cheng
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] prototype of a DSL for generating Dockerfiles

[Swapnil Kulkarni (coolsvap)]

On Fri, May 27, 2016 at 8:35 AM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> While Swapnil has been busy churning the dockerfile.j2 files to all match
> the same style, and we also had summit where we declared we would solve the
> plugin problem, I have decided to begin work on a DSL prototype.
>
> Here are the problems I want to solve in order of importance by this work:
>
> Build CentOS, Ubuntu, Oracle Linux, Debian, Fedora containers
> Provide a programmatic way to manage Dockerfile construction rather then a
> manual (with vi or emacs or the like) mechanism
> Allow complete overrides of every facet of Dockerfile construction, most
> especially repositories per container (rather than in the base container) to
> permit the use case of dependencies from one version with dependencies in
> another version of a different service
> Get out of the business of maintaining 100+ dockerfiles but instead maintain
> one master file which defines the data that needs to be used to construct
> Dockerfiles
> Permit different types of optimizations or Dockerfile building by changing
> around the parser implementation – to allow layering of each operation, or
> alternatively to merge layers as we do today
>
> I don't believe we can proceed with both binary and source plugins given our
> current implementation of Dockerfiles in any sane way.
>
> I further don't believe it is possible to customize repositories & installed
> files per container, which I receive increasing requests for offline.
>
> To that end, I've created a very very rough prototype which builds the base
> container as well as a mariadb container.  The mariadb container builds and
> I suspect would work.
>
> An example of the DSL usage is here:
> https://review.openstack.org/#/c/321468/4/dockerdsl/dsl.yml
>
> A very poorly written parser is here:
> https://review.openstack.org/#/c/321468/4/dockerdsl/load.py
>
> I played around with INI as a format, to take advantage of oslo.config and
> kolla-build.conf, but that didn't work out.  YML is the way to go.
>
> I'd appreciate reviews on the YML implementation especially.
>
> How I see this work progressing is as follows:
>
> A yml file describing all docker containers for all distros is placed in
> kolla/docker
> The build tool adds an option —use-yml which uses the YML file
> A parser (such as load.py above) is integrated into build.py to lay down he
> Dockerfiles
> Wait 4-6 weeks for people to find bugs and complain
> Make the —use-yml the default for 4-6 weeks
> Once we feel confident in the yml implementation, remove all Dockerfile.j2
> files
> Remove —use-yml option
> Remove all jinja2-isms from build.py
>
> This is similar to the work that took place to convert from raw Dockerfiles
> to Dockerfile.j2 files.  We are just reusing that pattern.  Hopefully this
> will be the last major refactor of the dockerfiles unless someone has some
> significant complaints about the approach.
>
> Regards
> -steve
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

The DSL template to generate the Dockerfile seems way better than the
jinja templates in terms of extension which is currently a major
bottleneck in the plugin implementation. I am +2+W on this plan of
action to test it for next 4-6 weeks and see thereon.

Swapnil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] prototype of a DSL for generating Dockerfiles

[Steven Dake (stdake)]

Hey folks,

While Swapnil has been busy churning the dockerfile.j2 files to all match the 
same style, and we also had summit where we declared we would solve the plugin 
problem, I have decided to begin work on a DSL prototype.

Here are the problems I want to solve in order of importance by this work:

  1.  Build CentOS, Ubuntu, Oracle Linux, Debian, Fedora containers
  2.  Provide a programmatic way to manage Dockerfile construction rather then 
a manual (with vi or emacs or the like) mechanism
  3.  Allow complete overrides of every facet of Dockerfile construction, most 
especially repositories per container (rather than in the base container) to 
permit the use case of dependencies from one version with dependencies in 
another version of a different service
  4.  Get out of the business of maintaining 100+ dockerfiles but instead 
maintain one master file which defines the data that needs to be used to 
construct Dockerfiles
  5.  Permit different types of optimizations or Dockerfile building by 
changing around the parser implementation - to allow layering of each 
operation, or alternatively to merge layers as we do today

I don't believe we can proceed with both binary and source plugins given our 
current implementation of Dockerfiles in any sane way.

I further don't believe it is possible to customize repositories & installed 
files per container, which I receive increasing requests for offline.

To that end, I've created a very very rough prototype which builds the base 
container as well as a mariadb container.  The mariadb container builds and I 
suspect would work.

An example of the DSL usage is here:
https://review.openstack.org/#/c/321468/4/dockerdsl/dsl.yml

A very poorly written parser is here:
https://review.openstack.org/#/c/321468/4/dockerdsl/load.py

I played around with INI as a format, to take advantage of oslo.config and 
kolla-build.conf, but that didn't work out.  YML is the way to go.

I'd appreciate reviews on the YML implementation especially.

How I see this work progressing is as follows:

  1.  A yml file describing all docker containers for all distros is placed in 
kolla/docker
  2.  The build tool adds an option -use-yml which uses the YML file
  3.  A parser (such as load.py above) is integrated into build.py to lay down 
he Dockerfiles
  4.  Wait 4-6 weeks for people to find bugs and complain
  5.  Make the -use-yml the default for 4-6 weeks
  6.  Once we feel confident in the yml implementation, remove all 
Dockerfile.j2 files
  7.  Remove -use-yml option
  8.  Remove all jinja2-isms from build.py

This is similar to the work that took place to convert from raw Dockerfiles to 
Dockerfile.j2 files.  We are just reusing that pattern.  Hopefully this will be 
the last major refactor of the dockerfiles unless someone has some significant 
complaints about the approach.

Regards
-steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] 答复: [probably forge email可能是仿冒邮件] [vitrage] failed to show graph topology on graphwithout root

[dong . wenjuan]

Hi Eylon,

I think this commit caused the problem.
get topology API don't handle the parameter depth 
Change-Id: I68eac9e3d5c4bfddbbc6d4ed7dbcc5ccbf089fcd

I'll check and fix it. Sorry for that.
 

BR,
dwj





"Malin, Eylon (Nokia - IL)"  
2016-05-26 22:38
请答复 给
"OpenStack Development Mailing List \(not for usage questions\)" 



收件人
"openstack-dev@lists.openstack.org" 
抄送

主题
[probably forge email可能是仿冒邮件][openstack-dev] [vitrage] failed to 
show graph topology on graphwithout root






Hi all,

I use vitrage without any root graph (In my case there is no root).
Until few days ago I was able to request topology of type graph with no 
problems.
But I can't, I got 404, and the log says it can't find openstack.cluster 
node.

I think it have the problems since these commits : 
I1189047849f714d8435414cc48098d71837b3ed0, 
I1438713136c0177282e8ee8e19a651af5590feef 


Eylon

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [javascript] project name

[Zhang Yujun]

Hi, Michael,

I tried to fix an issue on project name in
https://review.openstack.org/#/c/321908/1 but one unit test fails and I
haven't figure it out yet.

Could you help me to clarify the rule for project name? It seems it could
be coming from the following

1. generator.appname => normalized parent directory name
2. project name entered by user
3. project name in .gitreivew

--
Yujun
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Leadership training - ideas to include those not in the room?

[Anita Kuno]

On 05/26/2016 06:03 PM, Colette Alexander wrote:
> On Thu, May 26, 2016 at 2:29 PM, Anita Kuno  wrote:
>> On 05/26/2016 05:01 PM, Colette Alexander wrote:
>>> On Thu, May 26, 2016 at 12:10 PM, Anita Kuno  wrote:
>>
>> Well I think you have just set the intent for the event that I should be
>> careful what I say or do since anyone is encouraged to blog my
>> statements or actions in their blog post. I will comply with
>> expectations, but I must say I had expected an intent that valued my
>> personal privacy higher for what was billed in my mind anyway as a
>> leadership training event.
>>
> 
> I actually think this is a very important point to bring up early re:
> training, so thanks for mentioning it, Anita! While it's certainly
> fair to share one's own experience and observations around training
> with the larger community if you choose, it is absolutely important to
> respect the boundaries of others' experiences of training and allow
> them space to talk about it, or not. It's also crucial that anything
> that is expressed by others be treated with a bias towards privacy and
> confidentiality (i.e., if you want to write about something someone
> said during training on social media, it's appropriate to ask them for
> permission to share, first).

Thank you, Colette, I appreciate you setting this intent. This is the
social agreement I am used to for the event to be productive for all
participants. I appreciate you stating it clearly.

My thanks,
Anita.


> I should add - I didn't intend to set any expectations that the
> etherpads even be used - I just wanted to provide them as an option to
> facilitate, if anyone desires to use them. If no one does, I'm also
> fine with that, and I'm happy to take responsibility to answer
> questions asked by community members who aren't present on them as I'm
> able to.
> 
> Thanks!
> 
> -colette
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Leadership training - ideas to include those not in the room?

[Colette Alexander]

On Thu, May 26, 2016 at 2:29 PM, Anita Kuno  wrote:
> On 05/26/2016 05:01 PM, Colette Alexander wrote:
>> On Thu, May 26, 2016 at 12:10 PM, Anita Kuno  wrote:
>
> Well I think you have just set the intent for the event that I should be
> careful what I say or do since anyone is encouraged to blog my
> statements or actions in their blog post. I will comply with
> expectations, but I must say I had expected an intent that valued my
> personal privacy higher for what was billed in my mind anyway as a
> leadership training event.
>

I actually think this is a very important point to bring up early re:
training, so thanks for mentioning it, Anita! While it's certainly
fair to share one's own experience and observations around training
with the larger community if you choose, it is absolutely important to
respect the boundaries of others' experiences of training and allow
them space to talk about it, or not. It's also crucial that anything
that is expressed by others be treated with a bias towards privacy and
confidentiality (i.e., if you want to write about something someone
said during training on social media, it's appropriate to ask them for
permission to share, first).

I should add - I didn't intend to set any expectations that the
etherpads even be used - I just wanted to provide them as an option to
facilitate, if anyone desires to use them. If no one does, I'm also
fine with that, and I'm happy to take responsibility to answer
questions asked by community members who aren't present on them as I'm
able to.

Thanks!

-colette

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] Wiki signups (was: Re: [ironic] third party CI systems - vendor requirement milestones status)

[Jeremy Stanley]

On 2016-05-26 21:18:06 + (+), Jay Faulkner wrote:
[...]
> This is a recurring issue though, and it affects new contributors
> disproportionately to those of us who have been in the community
> longer. Are there any plans in place to make it so wiki signups
> can occur in a more normal manner, or should projects move data
> that needs to be widely modifyable off the wiki?

I'll quote from my summit session summary:

Consensus within the room was that we want to continue the
current years-long effort of moving important content off the
wiki, deprecating it for specific use cases when there are more
suitable publication and information management mechanisms
available. Some current uses will still need new solutions
engineered of course, but over the coming year we'd like to get
to a point where sufficient content is moved off so that we can
better determine whether its continued existence is warranted.

I'll be starting a thread on the openstack at
lists.openstack.org mailing list in the next few days to cover
the situation in greater detail and get the community-facing
discussion going for this. Thierry Carrez volunteered to work on
identifying remaining wiki use cases, and on handling
discussion/collecting feedback throughout the wider community.
Elizabeth K. Joseph volunteered to research alternative
solutions for the current under-served use cases as they're
identified, and determine feasibility of implementation.

That said, we still need to have the wiki in sufficient shape to
be able to continue serving its current purpose, to enable us to
better identify its remaining stakeholders, and to provide them
with an opportunity to comfortably transition to other platforms
as we make them available. Paul Belanger volunteered (with
Spencer Krum and James Blair assisting as backups) to get the
current deployment into configuration management, and upgraded
into a usable and reasonably spam-resistant state again.

http://lists.openstack.org/pipermail/openstack-dev/2016-May/094540.html

I'll let the volunteers above chime in with additional details, but
know that we're aware this is a painful situation and we're trying
to balance keeping things sane for all consumers of the wiki against
the challenges of allowing new users to create/update content there.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi Haim,

Thanks for taking care of this. I see that Miguel has started working on the 
new L2 extension for Flow management。

https://bugs.launchpad.net/neutron/+bug/1563967
https://review.openstack.org/#/c/320439/

We may need to sync up the change with this new work too.

Thanks,
Cathy

From: Haim Daniel [mailto:hdan...@redhat.com]
Sent: Thursday, May 26, 2016 5:42 AM
To: Ihar Hrachyshka
Cc: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); 
Vikram Choudhary; Sean M. Collins; Mathieu Rohon; Shaughnessy, David; 
Eichberger, German; Henry Fourie; Armando M.
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi all,

sorry for digging up this thread. I took a liberty to submitt an RFE per Ihar's 
suggestion for the first step (switching to l2 agent extensions):
https://bugs.launchpad.net/networking-sfc/+bug/1586024

As a followup on that - hoping to send some wip patches in the near time.

Hope to hear your thoughts/suggestions on the $subj.

On Fri, Apr 15, 2016 at 2:44 AM, Ihar Hrachyshka 
mailto:ihrac...@redhat.com>> wrote:
Cathy Zhang mailto:cathy.h.zh...@huawei.com>> wrote:

I think there is no formal spec or anything, just some emails around there.

That said, I don’t follow why it’s a requirement for SFC to switch to l2 agent 
extension mechanism. Even today, with SFC maintaining its own agent, there are 
no clear guarantees for flow priorities that would avoid all possible conflicts.

Cathy> There is no requirement for SFC to switch. My understanding is that 
current L2 agent extension does not solve the conflicting entry issue if two 
features inject the same priority table entry. I think this new L2 agent effort 
is try to come up with a mechanism to resolve this issue. Of course if each 
feature( SFC or Qos) uses its own agent, then there is no coordination and no 
way to avoid conflicts.

Sorry, I probably used misleading wording. I meant, why do we consider the 
semantic flow management support in l2 agent extension framework a 
*prerequisite* for SFC to switch to l2 agent extensions? The existing framework 
should already allow SFC to achieve what you have in the subproject tree 
implemented as a separate agent (essentially a fork of OVS agent). It will also 
set SFC to use standard extension mechanisms instead of hacky inheritance from 
OVS agent classes. So even without the strict semantic flow management, there 
is benefit for the subproject.

With that in mind, I would split this job into 3 pieces:
* first, adopt l2 agent extension mechanism for SFC functionality (dropping 
custom agent);
* then, work on semantic flow management support in OVS agent API class [1];
* once the feature emerges, switch SFC l2 agent extension to the new framework 
to manage SFC flows.

I would at least prioritize the first point and target it to Newton-1. Other 
bullet points may take significant time to bake.

[1] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][nova][horizon] Serial console support for ironic instances

[Jim Rollenhagen]

On Wed, May 25, 2016 at 07:27:09AM -0400, Jim Rollenhagen wrote:
> On Wed, May 25, 2016 at 01:58:18PM +0900, Yuiko Takada wrote:
> > Hi!
> > 
> > Hironori, Lucas, thank you for bringing this topic up!
> > 
> > Yes, as Lucas says,  our latest spec is
> > https://review.openstack.org/#/c/319505
> > 
> > I and Tien, Hironori, Akira discussed and merged our idea.
> > 
> > And new Nova spec is here:
> > https://review.openstack.org/#/c/319507
> > 
> > As you guys know, Nova non-priority spec approval freeze is 5/30-6/3,
> > so that I guess Ironic spec need to be approved until it.
> 
> Just a note here, I talked with johnthetubaguy this morning, and we
> think the Nova blueprint doesn't need a spec. I updated the whiteboard
> on the BP with some details, added it to the agenda
> for the next Nova meeting, and will be there to discuss it.

And, this was approved in Nova. Let's get eyes on the ironic spec and
get this done this cycle. :)

// jim

> 
> // jim
> 
> > 
> > 
> > Best Regards,
> > Yuiko Takada Mori
> > 
> > 2016-05-25 1:15 GMT+09:00 Lucas Alvares Gomes :
> > 
> > > Hi,
> > >
> > > > I'm working with Tien who is a submitter of one[1] of console specs.
> > > > I joined the console session in Austin.
> > > >
> > > > In the session, we got the following consensus.
> > > > - focus on serial console in Newton
> > > > - use nova-serial proxy as is
> > > >
> > > > We also got some requirements[2] for this feature in the session.
> > > > We have started cooperating with Akira and Yuiko who submitted another
> > > similar spec[3].
> > > > We're going to unite our specs and add solutions for the requirements
> > > ASAP.
> > > >
> > >
> > > Great stuff! So do we have an update on this?
> > >
> > > I see [3] is now abandoned and a new spec was proposed recently [4].
> > > Is [4] the result of the union of both specs?
> > >
> > > > [1] ironic-ipmiproxy: https://review.openstack.org/#/c/296869/
> > > > [2] https://etherpad.openstack.org/p/ironic-newton-summit-console
> > > > [3] ironic-console-server: https://review.openstack.org/#/c/306755/
> > >
> > > [4] https://review.openstack.org/#/c/319505
> > >
> > > Cheers,
> > > Lucas
> > >
> > > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Leadership training - ideas to include those not in the room?

[Anita Kuno]

On 05/26/2016 05:01 PM, Colette Alexander wrote:
> On Thu, May 26, 2016 at 12:10 PM, Anita Kuno  wrote:
> 
>> I personally think that for any environment to be able to foster
>> personal growth the environment has to first and foremost protect the
>> privacy of the individual and the sanctity of the space. Personally I
>> feel that we as a group have lost the ability we used to have to listen
>> to each other in large part because we are expected to be fodder for the
>> public at all times. There is a time and a place for privacy. I had
>> hoped this event would cultivate this very necessary environment.
>>
>> As for what others read or what others write, that is up to them. But I
>> do hope they are encouraged to internalize, examine and process the
>> event rather than just consider themselves a voice for the non present
>> as that diminishes significantly from any possible benefit that could be
>> gained by those attending. I hope this isn't just another lost opportunity.
>>
>> I don't know if we have considered the cost of having to be constantly
>> on display but there is a cost and I think we are all paying the price.
> 
> 
> I should add, I guess, that I doubt there will be any room for laptops
> being open or online reaction to activities as-they-happen. there
> might be time to reflect on sections of the training at lunch times,
> or breaks, or after our day is done, and I wanted to give that option
> to folks who felt like sharing their thoughts in a more informal
> setting than a blog post. I apologize if it made anyone feel pressured
> to share who doesn't want to - that wasn't my intent at all.
> 
> -colette
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Well I think you have just set the intent for the event that I should be
careful what I say or do since anyone is encouraged to blog my
statements or actions in their blog post. I will comply with
expectations, but I must say I had expected an intent that valued my
personal privacy higher for what was billed in my mind anyway as a
leadership training event.

Thanks,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Who is going to fix the broken non-voting tests?

[Rodrigo Duarte]

The function-nv was depending of a first test to be merged =)

The v3 depends directly on it, the difference is that it passes a flag to
deactivate v2.0 in devstack.

On Thu, May 26, 2016 at 5:48 PM, Steve Martinelli 
wrote:

> On Thu, May 26, 2016 at 12:59 PM, Adam Young  wrote:
>
>> On 05/26/2016 11:36 AM, Morgan Fainberg wrote:
>>
>>
>>
>> On Thu, May 26, 2016 at 7:55 AM, Adam Young  wrote:
>>
>>> Some mix of these three tests is almost always failing:
>>>
>>> gate-keystone-dsvm-functional-nv FAILURE in 20m 04s (non-voting)
>>> gate-keystone-dsvm-functional-v3-only-nv FAILURE in 32m 45s (non-voting)
>>> gate-tempest-dsvm-keystone-uwsgi-full-nv FAILURE in 1h 07m 53s
>>> (non-voting)
>>>
>>>
>>> Are we going to keep them running and failing, or boot them?  If we are
>>> going to keep them, who is going to commit to fixing them?
>>>
>>> We should not live with broken windows.
>>>
>>>
>>>
>> The uwsgi check should be moved to a proper run utilizing mod_proxy_uwsgi.
>>
>> Who wants to own this?  I am not fielding demands for uwsgi support
>> mysqlf, and kind of think it is just a novelty, thus would not mind see it
>> going away.  If someone really cares, please make yourself known.
>>
>
> Brant has a patch (https://review.openstack.org/#/c/291817/) that adds
> support in devstack to use uwsgi and mod_proxy_http. This is blocked until
> infra moves to Ubuntu Xenial. Once this merges we can propose a patch that
> swaps out the uwsgi job for uwsgi + mod_proxy_http.
>
>
>>
>>
>> The v3 only one is a WIP that a few folks are working on
>>
>> Fair enough.
>>
>> The function-nv one was passing somewhere. I think that one is close.
>>
>>
>> Yeah, it seems to be intermittant.
>>
>>
> These two are actively being worked on.
>
>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [infra] Wiki signups (was: Re: [ironic] third party CI systems - vendor requirement milestones status)

[Jay Faulkner]

Infra team + Pablo,


I'm not sure if this is a pattern infra folks want to follow or not (I added 
[infra] to the title), but I know recently they did re-enable wiki signups for 
a short period of time to allow a couple of folks in IRC to get accounts. I''d 
try to ask in #openstack-infra and see if they can do the same for you.


This is a recurring issue though, and it affects new contributors 
disproportionately to those of us who have been in the community longer. Are 
there any plans in place to make it so wiki signups can occur in a more normal 
manner, or should projects move data that needs to be widely modifyable off the 
wiki?

Thanks,
Jay Faulkner


From: Pavlo Shchelokovskyy 
Sent: Wednesday, May 25, 2016 11:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ironic] third party CI systems - vendor 
requirement milestones status

Hi,

on a side-note concerning editing the Wiki, apparently registration of new 
accounts on OpenStack Wiki is disabled (closed some time ago due to bot spam), 
so if you do not have an account already, you won't be able to edit the page. 
The solution is only to ping people with valid accounts and ask them to make 
the changes for you.

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, May 25, 2016 at 7:56 PM, Kurt Taylor 
mailto:kurt.r.tay...@gmail.com>> wrote:
We are in the final stretch for requiring CI testing for ironic drivers. I have 
organized the CI teams that I know about and their current status into the 
following wiki page:
https://wiki.openstack.org/wiki/Ironic/Drivers#3rd_Party_CI_required_implementation_status

I have already heard from a few folks with edits, but please review this info 
and let me know if you have any changes. You can make needed changes yourself, 
but let me know so I can keep track.

Thanks!
Kurt Taylor (krtaylor)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Mid-cycle development sprint

[Doug Wiegley]

This is kind of tough timing-wise from the states. Since we lose about 24 hours 
to travel/time zone, that means realistically leaving on Saturday from over the 
pond. Not that I’m opposed to weekend travel, but summer logistics are hard 
(and not possible for me on this one.) Remote for me, I suppose? Or I’ll find a 
local approximation of a pub,and work there, in spirit.

doug


> On May 26, 2016, at 2:47 PM, Henry Gessau  wrote:
> 
> I am happy to announce that the location logistics for the Neutron mid-cycle
> have been finalized. The mid-cycle will take place in Cork, Ireland on August
> 15-17. I have updated the wiki [1] where you will find a link to an etherpad
> with all the details. There you can add yourself if you plan to attend, and
> make updates to topics that you would like to work on.
> 
> 
> [1] https://wiki.openstack.org/wiki/Sprints#Newton_sprints
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Leadership training - ideas to include those not in the room?

[Colette Alexander]

On Thu, May 26, 2016 at 12:10 PM, Anita Kuno  wrote:

> I personally think that for any environment to be able to foster
> personal growth the environment has to first and foremost protect the
> privacy of the individual and the sanctity of the space. Personally I
> feel that we as a group have lost the ability we used to have to listen
> to each other in large part because we are expected to be fodder for the
> public at all times. There is a time and a place for privacy. I had
> hoped this event would cultivate this very necessary environment.
>
> As for what others read or what others write, that is up to them. But I
> do hope they are encouraged to internalize, examine and process the
> event rather than just consider themselves a voice for the non present
> as that diminishes significantly from any possible benefit that could be
> gained by those attending. I hope this isn't just another lost opportunity.
>
> I don't know if we have considered the cost of having to be constantly
> on display but there is a cost and I think we are all paying the price.


I should add, I guess, that I doubt there will be any room for laptops
being open or online reaction to activities as-they-happen. there
might be time to reflect on sections of the training at lunch times,
or breaks, or after our day is done, and I wanted to give that option
to folks who felt like sharing their thoughts in a more informal
setting than a blog post. I apologize if it made anyone feel pressured
to share who doesn't want to - that wasn't my intent at all.

-colette

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [higgins] Continued discussion from the last team meeting

[Hongbin Lu]

I agree with you and Qiming. The Higgins project should start with basic 
functionalities and revisit advanced features later.

Best regards,
Hongbin

From: Yanyan Hu [mailto:huyanya...@gmail.com]
Sent: May-24-16 11:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [higgins] Continued discussion from the last team 
meeting

Hi, Hongbing, thanks a lot for the summary! The following is my thoughts on 
those two questions left:
About container composition, it is a really useful and important feature for 
enduser. But based on my understanding, user can actually achieve the same goal 
by leveraging other high level OpenStack services, e.g. defining a Heat 
template with Higgins container resources and app/service 
(softwareconfig/softwaredeployment resources) running inside containers. In 
future we can implement related functionality inside Higgins to better support 
this kind of use cases natively. But in current stage, I suggest we focus on 
container primitive and its basic operations.

For container host management, I agree we should expose related API interfaces 
to operator(admin). Ideally, Higgins should be able to manage all container 
hosts(baremetal and VM) automatically, but manual intervention could be 
necessary in many pratical use cases. But I suggest to hide these API 
interfaces from endusers since it's not their responsibility to manage those 
hosts.
Thanks.

2016-05-25 4:55 GMT+08:00 Hongbin Lu 
mailto:hongbin...@huawei.com>>:
Hi all,

At the last team meeting, we tried to define the scope of the Higgins project. 
In general, we agreed to focus on the following features as an initial start:

• Build a container abstraction and use docker as the first 
implementation.

• Focus on basic container operations (i.e. CRUD), and leave advanced 
operations (i.e. keep container alive, rolling upgrade, etc.) to users or other 
projects/services.

• Start with non-nested container use cases (e.g. containers on 
physical hosts), and revisit nested container use cases (e.g. containers on 
VMs) later.
The items below needs further discussion so I started this ML to discuss it.

1.   Container composition: implement a docker compose like feature

2.   Container host management: abstract container host
For #1, it seems we broadly agreed that this is a useful feature. The argument 
is where this feature belongs to. Some people think this feature belongs to 
other projects, such as Heat, and others think it belongs to Higgins so we 
should implement it. For #2, we were mainly debating two things: where the 
container hosts come from (provisioned by Nova or provided by operators); 
should we expose host management APIs to end-users? Thoughts?

Best regards,
Hongbin

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Best regards,

Yanyan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Who is going to fix the broken non-voting tests?

[Steve Martinelli]

On Thu, May 26, 2016 at 12:59 PM, Adam Young  wrote:

> On 05/26/2016 11:36 AM, Morgan Fainberg wrote:
>
>
>
> On Thu, May 26, 2016 at 7:55 AM, Adam Young  wrote:
>
>> Some mix of these three tests is almost always failing:
>>
>> gate-keystone-dsvm-functional-nv FAILURE in 20m 04s (non-voting)
>> gate-keystone-dsvm-functional-v3-only-nv FAILURE in 32m 45s (non-voting)
>> gate-tempest-dsvm-keystone-uwsgi-full-nv FAILURE in 1h 07m 53s
>> (non-voting)
>>
>>
>> Are we going to keep them running and failing, or boot them?  If we are
>> going to keep them, who is going to commit to fixing them?
>>
>> We should not live with broken windows.
>>
>>
>>
> The uwsgi check should be moved to a proper run utilizing mod_proxy_uwsgi.
>
> Who wants to own this?  I am not fielding demands for uwsgi support
> mysqlf, and kind of think it is just a novelty, thus would not mind see it
> going away.  If someone really cares, please make yourself known.
>

Brant has a patch (https://review.openstack.org/#/c/291817/) that adds
support in devstack to use uwsgi and mod_proxy_http. This is blocked until
infra moves to Ubuntu Xenial. Once this merges we can propose a patch that
swaps out the uwsgi job for uwsgi + mod_proxy_http.


>
>
> The v3 only one is a WIP that a few folks are working on
>
> Fair enough.
>
> The function-nv one was passing somewhere. I think that one is close.
>
>
> Yeah, it seems to be intermittant.
>
>
These two are actively being worked on.


>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Mid-cycle development sprint

[Henry Gessau]

I am happy to announce that the location logistics for the Neutron mid-cycle
have been finalized. The mid-cycle will take place in Cork, Ireland on August
15-17. I have updated the wiki [1] where you will find a link to an etherpad
with all the details. There you can add yourself if you plan to attend, and
make updates to topics that you would like to work on.


[1] https://wiki.openstack.org/wiki/Sprints#Newton_sprints



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Why do we disable the firewall by default?

[Emilien Macchi]

On Thu, May 26, 2016 at 4:16 PM, Ben Nemec  wrote:
> Pretty much what the subject says.  I've recently gotten several
> questions from the field about why their deployments had no firewall
> enabled, and discovered that although we have support built-in to enable
> the firewall, we turn it off by default.  This seems like a bad default
> to me, but I wanted to send something out in case there was a good
> historical reason we chose to do this.
>
> I'm also wondering about the upgrade implications of changing defaults
> in Heat templates.  If we did this, would it cause the firewall to be
> enabled on existing deployments when they upgraded to the new version?
> That seems like a significant concern since it's quite possible users
> are managing their own firewall rules (especially because we don't by
> default), and they may have customizations that they won't want us
> stepping on.
>
> I've pushed a review to flip the bit on this:
> https://review.openstack.org/#/c/321833 but I've set it WIP until we
> have answers to the topics above.
>
> -Ben

When Yanis and I wrote the feature back in times, we wanted the
feature experimental because it's very intrusive.
Now our CI is a good shape and has good coverage, I think we can give
a try to enable it.
If you enable, just make sure tripleo::firewall::post::debug is set at
False, otherwise traffic won't be dropped :-)

I don't see any issue on the upgrade thing, we just to iptables commands.

I like your idea and I'm in favor of enabling it by default, and
iterate on errors that we might encounter in CI.

Thanks!
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Why do we disable the firewall by default?

[Ben Nemec]

Pretty much what the subject says.  I've recently gotten several
questions from the field about why their deployments had no firewall
enabled, and discovered that although we have support built-in to enable
the firewall, we turn it off by default.  This seems like a bad default
to me, but I wanted to send something out in case there was a good
historical reason we chose to do this.

I'm also wondering about the upgrade implications of changing defaults
in Heat templates.  If we did this, would it cause the firewall to be
enabled on existing deployments when they upgraded to the new version?
That seems like a significant concern since it's quite possible users
are managing their own firewall rules (especially because we don't by
default), and they may have customizations that they won't want us
stepping on.

I've pushed a review to flip the bit on this:
https://review.openstack.org/#/c/321833 but I've set it WIP until we
have answers to the topics above.

-Ben

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Leadership training - ideas to include those not in the room?

[Amrith Kumar]

Anita, Colette, I too was wondering how effective my own participation in the 
training would be there was an implied expectation that I was to be taking 
notes for a live relay to others on the internet who were following along on an 
etherpad, not to mention what it would to the dynamics in the room with people 
relaying questions from out in the ether.

It brought up visions of the (unfortunately too often) news programs [sic] 
where an anchor reads tweets that are shown on an oversized screen.

And I remembered reading this paper[1] some time back where the authors 
conclude that as people take notes on computers, the fact that they now have 
the ability to take notes faster interferes with their own ability to 
understand and retain the information being thrown at them.

-amrith

[1] The Pen Is Mightier Than the Keyboard; Advantages of Longhand Over Laptop 
Note Taking. Mueller, Oppenheimer. Psychological Science, 2014, Vol 25. 
http://pss.sagepub.com/content/25/6/1159.full.pdf+html

> -Original Message-
> From: Anita Kuno [mailto:ante...@anteaya.info]
> Sent: Thursday, May 26, 2016 3:21 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc] Leadership training - ideas to include
> those not in the room?
> 
> On 05/26/2016 03:10 PM, Anita Kuno wrote:
> > On 05/26/2016 02:40 PM, Colette Alexander wrote:
> >> Hello Stackers!
> >>
> >> I just wanted to check in as we approach the leadership training
> >> session that some of the TC and community will be attending in Ann
> >> Arbor, Michigan together [0].
> >>
> >>
> >> First thing: fostering as much inclusion as possible.
> >>
> >> Because of the limited amount of space, I was wondering if anyone had
> >> any ideas of how we might be able to share the experience with anyone
> >> not-in-the-room who is interested.
> >>
> >> As a first step, I've set up an etherpad for each of the two days of
> >> training [1] where attendees can jot notes if they'd like to share,
> >> and where anyone not in the room can ask questions, potentially, about
> >> what's happening.
> >>
> >> I also expect a few attendees, at least, might find the training
> >> interesting enough to blog about after the fact.
> >>
> >> We're barred from recording the training to share with the larger
> >> community (for now) because of contracts, etc., but I can share a
> >> bunch of work from the ZingTrain camp related to the training we'll
> >> have:
> >>
> >> 1. Free essays (esp. the Leadership and Visioning sections):
> >>
> >> http://zingtrain.com/free-samples-and-enews
> >>
> >> 2. Free webinars (which contain a lot of the elements of blocks of the
> >> training):
> >>
> >> http://info.zingtrain.com/webinars
> >>
> >> 3. Books related to the ZingTrain leadership philosophy:
> >>
> >> http://zingtrain.com/being-a-better-leader
> >> and
> >> http://zingtrain.com/managing-ourselves
> >>
> >> If anyone has any other suggestions or questions, please respond with
> >> input (and feel free to write me privately if you'd prefer).
> >>
> >> Second thing: logistics for attendees
> >>
> >> I'm going to have to do some housekeeping/organizational things with
> >> the 19 people attending, and that will just be via private email (and
> >> using the existing etherpad [0]). Keep an eye out for that soon!
> >>
> >> Thanks - and I'm really looking forward to sharing this experience
> >> with the whole community!
> >>
> >> Sincerely,
> >>
> >> -colette/gothicmindfood
> >>
> >>
> >>
> >> [0] https://etherpad.openstack.org/p/Leadershiptraining
> >> [1] https://etherpad.openstack.org/p/ZingTrain1 and
> >> https://etherpad.openstack.org/p/ZingTrain2
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > I personally think that for any environment to be able to foster
> > personal growth the environment has to first and foremost protect the
> > privacy of the individual and the sanctity of the space. Personally I
> > feel that we as a group have lost the ability we used to have to listen
> > to each other in large part because we are expected to be fodder for the
> > public at all times. There is a time and a place for privacy. I had
> > hoped this event would cultivate this very necessary environment.
> >
> > As for what others read or what others write, that is up to them. But I
> > do hope they are encouraged to internalize, examine and process the
> > event rather than just consider themselves a voice for the non present
> > as that diminishes significantly from any possible benefit that could be
> > gained by those attending. I hope this isn't just another lost
> opportunity.
> >
> > I don't know if we have considered the cost of having to be constantly
> > on display but there is a cost and I think we are all payin

[openstack-dev] [Kuryr] IPAM issue with multiple docker networks having same cidr subnets

[Vikas Choudhary]

Hi All,

Recently, Banix observed and brought into notice this issue [1].

To solve this, i could think of two approaches:
1. Modifying the libnetwork apis to get PoolID also at network creation.
 OR
2. Enhancing the /network docker api to get PoolID details also

Problem with the first approach is that it is changing libnetwork interface
which is common for all remote drivers and thus chances of any break-ups
are high. So I preferred second one.

Here is the patch I pushed to docker [2].

Once this is merged, we can easily fix this issue by tagging poolID to
neutron networks and filtering subnets at address request time based on
this information.

Any thoughts/suggestions?


Thanks
Vikas

[1] https://bugs.launchpad.net/kuryr/+bug/1585572
[2] https://github.com/docker/docker/issues/23025
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [new][keystone] keystone 8.1.2 release (liberty)

[no-reply]

We are content to announce the release of:

keystone 8.1.2: OpenStack Identity

This release is part of the liberty stable release series.

For more details, please see below.

Changes in keystone 8.1.0..8.1.2


6bf21f3 Fix post jobs
cdc0c2c Updated from global requirements
f811287 Changed the key repo validation to allow read only
f3b9b41 Remove test_invalid_policy_raises_error
762b0c1 Updating sample configuration file
5e8a7a9 Keystone jobs should honor upper-constraints.txt
ce9572b Updated from global requirements
2ac19b7 Updating sample configuration file
9e9c442 Correct test to support changing N release name
cf9ebb4 Store config in drivers and use it to get list_limit
53a6dc0 Return 404 instead of 401 for tokens w/o roles

Diffstat (except docs and test files)
-

etc/keystone.conf.sample   |  4 +--
keystone/cmd/cli.py|  4 +--
keystone/identity/backends/ldap.py |  8 +++---
keystone/identity/backends/sql.py  |  1 +
keystone/identity/core.py  |  9 ++-
keystone/token/provider.py | 40 ++
keystone/token/providers/fernet/utils.py   | 32 +---
requirements.txt   |  6 ++---
tox.ini| 14 ++-
12 files changed, 116 insertions(+), 52 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 084f251..32aa439 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -11,2 +11,2 @@ Paste
-Routes!=2.0,!=2.1,>=1.12.3;python_version=='2.7'
-Routes!=2.0,>=1.12.3;python_version!='2.7'
+Routes!=2.0,!=2.1,!=2.3.0,>=1.12.3;python_version=='2.7' # MIT
+Routes!=2.0,!=2.3.0,>=1.12.3;python_version!='2.7' # MIT
@@ -19 +19 @@ passlib>=1.6
-python-keystoneclient!=1.8.0,>=1.6.0
+python-keystoneclient!=1.8.0,<3.0.0,>=1.6.0



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Leadership training - ideas to include those not in the room?

[Anita Kuno]

On 05/26/2016 03:10 PM, Anita Kuno wrote:
> On 05/26/2016 02:40 PM, Colette Alexander wrote:
>> Hello Stackers!
>>
>> I just wanted to check in as we approach the leadership training
>> session that some of the TC and community will be attending in Ann
>> Arbor, Michigan together [0].
>>
>>
>> First thing: fostering as much inclusion as possible.
>>
>> Because of the limited amount of space, I was wondering if anyone had
>> any ideas of how we might be able to share the experience with anyone
>> not-in-the-room who is interested.
>>
>> As a first step, I've set up an etherpad for each of the two days of
>> training [1] where attendees can jot notes if they'd like to share,
>> and where anyone not in the room can ask questions, potentially, about
>> what's happening.
>>
>> I also expect a few attendees, at least, might find the training
>> interesting enough to blog about after the fact.
>>
>> We're barred from recording the training to share with the larger
>> community (for now) because of contracts, etc., but I can share a
>> bunch of work from the ZingTrain camp related to the training we'll
>> have:
>>
>> 1. Free essays (esp. the Leadership and Visioning sections):
>>
>> http://zingtrain.com/free-samples-and-enews
>>
>> 2. Free webinars (which contain a lot of the elements of blocks of the
>> training):
>>
>> http://info.zingtrain.com/webinars
>>
>> 3. Books related to the ZingTrain leadership philosophy:
>>
>> http://zingtrain.com/being-a-better-leader
>> and
>> http://zingtrain.com/managing-ourselves
>>
>> If anyone has any other suggestions or questions, please respond with
>> input (and feel free to write me privately if you'd prefer).
>>
>> Second thing: logistics for attendees
>>
>> I'm going to have to do some housekeeping/organizational things with
>> the 19 people attending, and that will just be via private email (and
>> using the existing etherpad [0]). Keep an eye out for that soon!
>>
>> Thanks - and I'm really looking forward to sharing this experience
>> with the whole community!
>>
>> Sincerely,
>>
>> -colette/gothicmindfood
>>
>>
>>
>> [0] https://etherpad.openstack.org/p/Leadershiptraining
>> [1] https://etherpad.openstack.org/p/ZingTrain1 and
>> https://etherpad.openstack.org/p/ZingTrain2
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> I personally think that for any environment to be able to foster
> personal growth the environment has to first and foremost protect the
> privacy of the individual and the sanctity of the space. Personally I
> feel that we as a group have lost the ability we used to have to listen
> to each other in large part because we are expected to be fodder for the
> public at all times. There is a time and a place for privacy. I had
> hoped this event would cultivate this very necessary environment.
> 
> As for what others read or what others write, that is up to them. But I
> do hope they are encouraged to internalize, examine and process the
> event rather than just consider themselves a voice for the non present
> as that diminishes significantly from any possible benefit that could be
> gained by those attending. I hope this isn't just another lost opportunity.
> 
> I don't know if we have considered the cost of having to be constantly
> on display but there is a cost and I think we are all paying the price.
> 
> Thank you,
> Anita.
> 

I'll follow up by saying that personally I don't intend on bringing my
laptop and would feel that our chances of getting something of value out
of the experience are increased if others are encouraged to do the same.

Thanks,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Leadership training - ideas to include those not in the room?

[Anita Kuno]

On 05/26/2016 02:40 PM, Colette Alexander wrote:
> Hello Stackers!
> 
> I just wanted to check in as we approach the leadership training
> session that some of the TC and community will be attending in Ann
> Arbor, Michigan together [0].
> 
> 
> First thing: fostering as much inclusion as possible.
> 
> Because of the limited amount of space, I was wondering if anyone had
> any ideas of how we might be able to share the experience with anyone
> not-in-the-room who is interested.
> 
> As a first step, I've set up an etherpad for each of the two days of
> training [1] where attendees can jot notes if they'd like to share,
> and where anyone not in the room can ask questions, potentially, about
> what's happening.
> 
> I also expect a few attendees, at least, might find the training
> interesting enough to blog about after the fact.
> 
> We're barred from recording the training to share with the larger
> community (for now) because of contracts, etc., but I can share a
> bunch of work from the ZingTrain camp related to the training we'll
> have:
> 
> 1. Free essays (esp. the Leadership and Visioning sections):
> 
> http://zingtrain.com/free-samples-and-enews
> 
> 2. Free webinars (which contain a lot of the elements of blocks of the
> training):
> 
> http://info.zingtrain.com/webinars
> 
> 3. Books related to the ZingTrain leadership philosophy:
> 
> http://zingtrain.com/being-a-better-leader
> and
> http://zingtrain.com/managing-ourselves
> 
> If anyone has any other suggestions or questions, please respond with
> input (and feel free to write me privately if you'd prefer).
> 
> Second thing: logistics for attendees
> 
> I'm going to have to do some housekeeping/organizational things with
> the 19 people attending, and that will just be via private email (and
> using the existing etherpad [0]). Keep an eye out for that soon!
> 
> Thanks - and I'm really looking forward to sharing this experience
> with the whole community!
> 
> Sincerely,
> 
> -colette/gothicmindfood
> 
> 
> 
> [0] https://etherpad.openstack.org/p/Leadershiptraining
> [1] https://etherpad.openstack.org/p/ZingTrain1 and
> https://etherpad.openstack.org/p/ZingTrain2
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

I personally think that for any environment to be able to foster
personal growth the environment has to first and foremost protect the
privacy of the individual and the sanctity of the space. Personally I
feel that we as a group have lost the ability we used to have to listen
to each other in large part because we are expected to be fodder for the
public at all times. There is a time and a place for privacy. I had
hoped this event would cultivate this very necessary environment.

As for what others read or what others write, that is up to them. But I
do hope they are encouraged to internalize, examine and process the
event rather than just consider themselves a voice for the non present
as that diminishes significantly from any possible benefit that could be
gained by those attending. I hope this isn't just another lost opportunity.

I don't know if we have considered the cost of having to be constantly
on display but there is a cost and I think we are all paying the price.

Thank you,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Zaqar messages standardization

[Zane Bitter]

On 26/05/16 09:42, Dmitry Tantsur wrote:

On 05/25/2016 08:08 PM, Thomas Herve wrote:

On Fri, May 20, 2016 at 5:52 PM, Jiri Tomasek 
wrote:

Hey all,

I've been recently working on getting the TripleO UI integrated with
Zaqar,
so it can receive a messages from Mistral workflows and act upon them
without having to do various polling hacks.

Since there is currently quite a large amount of new TripleO workflows
comming to tripleo-common, we need to standardize this communication so
clients can consume the messages consistently.

I'll try to outline the requirements as I see it to start the
discussion.

Zaqar queues:
To listen to the Zaqar messages it requires the client to connect to
Zaqar
WebSocket, send authenticate message and subscribe to queue(s) which it
wants to listen to. The currently pending workflow patches which send
Zaqar
messages [1, 2] expect that the queue is created by client and name is
passed as an input to the workflow [3].

From the client perspective, it would IMHO be better if all workflows
sent
messages to the same queue and provide means to identify itself by
carrying
workflow name and execution id. The reason is, that if client creates a
queue and triggers the workflow and then disconnects from the Socket
(user
refreshes browser), then it does not know what queues it previously
created
and which it should listen to. If there is single 'tripleo' queue,
then all
clients always know that it is where it will get all the messages from.

Messages identification and content:
The client should be able to identify message by it's name so it can act
upon it. The name should probably be relevant to the action or
workflow it
reports on.

{
  body: {
name: 'tripleo.validations.v1.run_validation,
execution_id: '123123123'
data: {}
  }
}

Other parts of the message are optional but it would be good to provide
information relevant to the message's purpose, so the client can update
relevant state and does not have to do any additional API calls. So
e.g. in
case of running the validation a message includes validation id.


Hi,

Sorry for not responding earlier, but I have some inputs. In Heat we
publish events on Zaqar queue, and we defined this format:

{
'timestamp': $timestamp,
'version': '0.1',
'type': 'os.heat.event',
'id': $uuid,
'payload': {
'XXX
}
}

I don't think we have strong requirements on that, and we can
certainly make some tweaks. If we can converge towards something
simimar that'd be great.


One more datapoint here. Ironic agreed on the following format:
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/notifications.html#proposed-change


That's a different thing - oslo.messaging notifications vs. Zaqar messages.


but I'm not sure if we implemented it already.



Thanks,




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker] Proposing Lin Cheng for tacker-horizon core team

[HADDLETON, Robert W (Bob)]

+1


On 5/26/2016 12:45 PM, Sridhar Ramaswamy wrote:

Tackers,

I'd like to propose Lin Cheng to join as a tacker-horizon core team 
member. Lin has been our go-to person for all guidance related to UI 
enhancements for Tacker. He has been actively reviewing patchsets in 
this area [1] and also contributed to setup the unit test framework 
for tacker-horizon repo.


Please provide your +1/-1 votes.

- Sridhar

[1] 
http://stackalytics.com/?project_type=all&metric=marks&release=all&module=tacker-group&user_id=lin-hua-cheng



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


<>__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc] Leadership training - ideas to include those not in the room?

[Colette Alexander]

Hello Stackers!

I just wanted to check in as we approach the leadership training
session that some of the TC and community will be attending in Ann
Arbor, Michigan together [0].


First thing: fostering as much inclusion as possible.

Because of the limited amount of space, I was wondering if anyone had
any ideas of how we might be able to share the experience with anyone
not-in-the-room who is interested.

As a first step, I've set up an etherpad for each of the two days of
training [1] where attendees can jot notes if they'd like to share,
and where anyone not in the room can ask questions, potentially, about
what's happening.

I also expect a few attendees, at least, might find the training
interesting enough to blog about after the fact.

We're barred from recording the training to share with the larger
community (for now) because of contracts, etc., but I can share a
bunch of work from the ZingTrain camp related to the training we'll
have:

1. Free essays (esp. the Leadership and Visioning sections):

http://zingtrain.com/free-samples-and-enews

2. Free webinars (which contain a lot of the elements of blocks of the
training):

http://info.zingtrain.com/webinars

3. Books related to the ZingTrain leadership philosophy:

http://zingtrain.com/being-a-better-leader
and
http://zingtrain.com/managing-ourselves

If anyone has any other suggestions or questions, please respond with
input (and feel free to write me privately if you'd prefer).

Second thing: logistics for attendees

I'm going to have to do some housekeeping/organizational things with
the 19 people attending, and that will just be via private email (and
using the existing etherpad [0]). Keep an eye out for that soon!

Thanks - and I'm really looking forward to sharing this experience
with the whole community!

Sincerely,

-colette/gothicmindfood



[0] https://etherpad.openstack.org/p/Leadershiptraining
[1] https://etherpad.openstack.org/p/ZingTrain1 and
https://etherpad.openstack.org/p/ZingTrain2

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [congress] Spec for congress.conf

[SULLIVAN, BRYAN L]

Hi Congress team,

Quick question for anyone. Is there a spec for fields in congress.conf file? As 
of Liberty this has to be tox-generated but I need to know which conf values 
are required vs optional. The generated sample output doesn't clarify that. 
This is for the Puppet Module and JuJu Charm I am developing with the help of 
RedHat and Canonical in OPNFV. I should have Congress installed by default (for 
the RDO and JuJu installers) in the OPNFV Colorado release in the next couple 
of weeks, and the congress.conf file settings are an open question. The Puppet 
module will also be used to create a Fuel plugin for installation.

Thanks,
Bryan Sullivan | AT&T

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Question about service subnets spec

[Carl Baldwin]

Hi folks,

Some (but not all) of you will remember a discussion we had about
service subnets at the last mid-cycle.  We've been iterating a little
bit on a spec [1] and we have just one issue that we'd like to get a
little bit more feedback on.

As a summary:  To me, the idea of this spec is to reserve certain
subnets for certain kinds of ports.  For example, DVR FIP gateway
ports, and router ports.  The goal of this is to be able to use
subnets with private addresses for these kinds of ports instead of
wasting public IP addresses.

The remaining question is how to expose this through the API.  I had
thought about just attaching a list of device_owners to the subnet
resource.  If a list is attached, then only ports with the right
device_owner will be allocated IP addresses from that subnet.  I
thought this would be an easy way to implement it and I thought since
device owner is already exposed through the API, maybe it would be
acceptable.  However, there is some concern that this exposes too much
of the internal implementation.  I understand this concern.

At the mid-cycle we had discussed some enumeration values that
combined several types to avoid having to allow a list of types on a
subnet.  They were going to look like this:

  dvr_gateway -> ["network:floatingip_agent_gateway"]
  router_gateway -> ["network:floatingip_agent_gateway",
"network:router_gateway"]

The idea was that we'd only allow one value for a subnet and the
difference between the two would be whether you wanted router ports to
use private IPs.  I think it would be clearer if we just have simpler
definitions of types and allow a list of them.

At this point the enumeration values map simply to device owners.  For example:

  router_ports -> "network:router_gateway"
  dvr_fip_ports -> "network:floatingip_agent_gateway"

It was at this point that I questioned the need for the abstraction at
all.  Hence the proposal to use the device owners directly.

Armando expressed some concern about using the device owner as a
security issue.  We have the following policy on device_owner:

  "not rule:network_device or rule:context_is_advsvc or
rule:admin_or_network_owner"

At the moment, I don't see this as much of an issue.  Do you?

Carl

[1] 
https://review.openstack.org/#/c/300207/3/specs/newton/subnet-service-types.rst

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker] Proposing Lin Cheng for tacker-horizon core team

[Stephen Wong]

+1. Great addition!

On Thu, May 26, 2016 at 10:51 AM, Sripriya Seetharam 
wrote:

> +1 , glad to have Lin Cheng on board.
>
>
>
> *From:* Sridhar Ramaswamy [mailto:sric...@gmail.com]
> *Sent:* Thursday, May 26, 2016 7:45 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [tacker] Proposing Lin Cheng for
> tacker-horizon core team
>
>
>
> Tackers,
>
>
>
> I'd like to propose Lin Cheng to join as a tacker-horizon core team
> member. Lin has been our go-to person for all guidance related to UI
> enhancements for Tacker. He has been actively reviewing patchsets in
> this area [1] and also contributed to setup the unit test framework for
> tacker-horizon repo.
>
>
>
> Please provide your +1/-1 votes.
>
>
>
> - Sridhar
>
>
>
> [1]
> http://stackalytics.com/?project_type=all&metric=marks&release=all&module=tacker-group&user_id=lin-hua-cheng
> 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker] Proposing Lin Cheng for tacker-horizon core team

[Sripriya Seetharam]

+1 , glad to have Lin Cheng on board.

From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Thursday, May 26, 2016 7:45 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [tacker] Proposing Lin Cheng for tacker-horizon core 
team

Tackers,

I'd like to propose Lin Cheng to join as a tacker-horizon core team member. Lin 
has been our go-to person for all guidance related to UI enhancements for 
Tacker. He has been actively reviewing patchsets in this area [1] and also 
contributed to setup the unit test framework for tacker-horizon repo.

Please provide your +1/-1 votes.

- Sridhar

[1] 
http://stackalytics.com/?project_type=all&metric=marks&release=all&module=tacker-group&user_id=lin-hua-cheng
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][kolla]

[Ryan Hallisey]

I think the community will want to split apart the CLI to run tasks.  This was 
an idea being thrown around at the same time
as the ectd addition.  This would give the operator the ability to like you 
said, to skip any task that isn't required.

Using etcd is a way for the operator to guarantee that a bootstrapping task can 
run without another service interrupting it.
The goal is to try and make use of the Kubernetes like workflow as much as 
possible.  I agree, the community should avoid
automagic setup.  It can lead to a lot of dangerous corner cases. I think Kolla 
learned this lesson way back during the
compose era.

The tasks are define as:
  - bootstrap /
  - deploy /

Any further workflow tweaking could be handled by contacting etcd.  The 
community could also break down the tasks further
if there is a use case for it.

Thanks,
Ryan

- Original Message -
From: "Kevin M Fox" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Thursday, May 26, 2016 11:41:12 AM
Subject: Re: [openstack-dev] [kubernetes]

Two issues I can see with that approach.

1. It needs to be incredibly well documented as well as tools provided to 
update states in etcd manually when an op needs to recover from things 
partially working.
2. Consider the case where an op has an existing cloud. He/She installs k8s on 
their existing control plane, and then one openstack service at a time wants to 
"upgrade" the system from non container to containers. If the user wants to do 
so, with the jobs method, the op just skips the bootstrap jobs. With magic 
baked into the containers and etcd, the same kinds of things in issue #1 needs 
fixing in etcd so it doesn't try and reinit things. This makes it harder to get 
clouds migrated to kolla-k8s.

I know the idea is to try and simplify deployment by making the containers do 
all the initing automagically. but I'm afraid that just sweeps issues under the 
rug, out of the light where they still will come up, but more unexpectedly. The 
ops still need to understand the automagic that is happening. As an Op, I'd 
rather it be explicit, out front, where I know its happening, and I can easily 
tweak the workflow when necessary to get out of a bind.

Thanks,
Kevin

From: Ryan Hallisey [rhall...@redhat.com]
Sent: Thursday, May 26, 2016 5:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kubernetes]

Thanks for the feedback Kevin.

The community has been investigation other options this week.  The option that 
is currently being looked at involves
using etcd to provide a locking mechanic so that services in the cluster are 
aware bootstrapping is underway.

The concept involves extending kolla's dockerfiles and having them poll etcd to 
determine whether a bootstrap is in progress or complete [1].

I'll follow up by adding this to the spec.

Thanks,
Ryan

[1] - https://review.openstack.org/#/c/320744/

- Original Message -
From: "Kevin M Fox" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, May 23, 2016 11:37:33 AM
Subject: Re: [openstack-dev] [kubernetes]

+1 for using k8s to do work where possible.

-1 for trying to shoehorn a feature in so that k8s can deal with stuff its not 
ready to handle. We need to ensure Operators have everything they need in order 
to successfully operate their cloud.

The current upgrade stuff in k8s is focused around replacing one, usually 
stateless, thing for another. It never had Database Schema upgrades in mind.  
It is great to use for minor version bumps. It is insufficient for major 
OpenStack upgrades. If you follow the OpenStack release notes, they tend to be 
quite linear, in a workflow. K8s isn't designed for that. Hence the need for a 
tool outside of k8s to drive the creation/upgrading of Deployments and Jobs in 
the proper order.

Init containers also do not look like a good fit. As far as I can gather from 
the spec, they are intended to init something on a node when a pod is spawned. 
This is a very different thing from upgrading a shared database's schema. I 
don't believe they should be used for that.

I've upgraded many OpenStack clouds over the years. One of the things that has 
bit me from time to time is a failed schema update and having to tweak code and 
then rerun schema upgrades. This will continue to happen and needs to be 
covered. The Job's workflow as discussed in the spec allows an operator to do 
just that. Hiding it in an init container makes that much harder for Operators.

As an Op, we need the ability to tweak the workflow as needed and run/rerun 
only the pieces that we need.

Thanks,
Kevin

From: Ryan Hallisey [rhall...@redhat.com]
Sent: Sunday, May 22, 2016 12:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev]  [kolla][kolla-kubernetes][kubernetes]

Hi all,

At the Kolla meeting last w

Re: [openstack-dev] [tacker] Proposing Lin Cheng for tacker-horizon core team

[Karthik Natarajan]

+1

From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Thursday, May 26, 2016 10:45 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [tacker] Proposing Lin Cheng for tacker-horizon core 
team

Tackers,

I'd like to propose Lin Cheng to join as a tacker-horizon core team member. Lin 
has been our go-to person for all guidance related to UI enhancements for 
Tacker. He has been actively reviewing patchsets in this area [1] and also 
contributed to setup the unit test framework for tacker-horizon repo.

Please provide your +1/-1 votes.

- Sridhar

[1] 
http://stackalytics.com/?project_type=all&metric=marks&release=all&module=tacker-group&user_id=lin-hua-cheng
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Elzur, Uri]

Hi
The OVN point is not about its interaction w Neutron API it is about the 
criteria to use about plugin support for a new code on Neutron. OvS is planning 
to move to OVN but is still building the code AND it is the SINGLE plugin to 
support OVN.
Similarly ODL already has code for NSH so using that very same criteria it 
should be allowed to support NSH (with appropriate abstractions into a generic 
SFC API)

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

From: Armando M. [mailto:arma...@gmail.com]
Sent: Wednesday, May 25, 2016 1:50 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



On 25 May 2016 at 12:29, Elzur, Uri 
mailto:uri.el...@intel.com>> wrote:
Armando

I’m asking for a clear answer “I think the position here is as follows: if a 
technology is not mainstream, i.e. readily available via distros and the 
various channels, it can only be integrated via an experimental path”

If we can allow for the EXPERIMENTAL path for NSH, then we can stand up the 
whole stack in EXPERIMENTAL mode and quickly move to mainstream when other 
pieces outside of Neutron fall in place.

As I said, you're free to experiment. The general directive is to allow these 
experimentations to take place and use them as a feedback tool to iterate on 
the abstractions. However the abstraction would only be considered community 
accepted if and only if there's enough evidence that there is established 
support from a broad variety of plugins (open source and non).


As to OVN – it has to be EXPERIMENTAL too. I guess, if I interpret your 
response correctly, that unlike their future intention for OVN,  OvS is not 
willing to signal interest in integrating NSH

We're mixing two things here: OVN is not experimenting with (Neutron) APIs (as 
it's adopting those as is), but it's experimenting with implementations. So I 
would not conflate OVN and NSH in the same discussion. I simply brought it up 
as another example (alongside DPDK) of how innovation can be fostered in open 
source communities.


Thx

Uri (“Oo-Ree”)
C: 949-378-7568

From: Armando M. [mailto:arma...@gmail.com]
Sent: Wednesday, May 25, 2016 9:33 AM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



On 24 May 2016 at 21:53, Elzur, Uri 
mailto:uri.el...@intel.com>> wrote:
Hi Tim

Sorry for the delay due to travel...

This note is very helpful!

We are in agreement that the team including the individuals cited below are 
supportive. We also agree that SFC belongs in the networking-SFC project (with 
proper API adjustment)

It seems networking-sfc still holds the position that without OvS accepting 
VXLAN-gpe and NSH patches they can't support NSH. I'm trying to get a clear 
read on where is this stated as requirement

I think the position here is as follows: if a technology is not mainstream, 
i.e. readily available via distros and the various channels, it can only be 
integrated via an experimental path. No-one is preventing anyone from posting 
patches and instructions to compile kernels and kernel modules, but ultimately 
as an OpenStack project that is suppose to produce commercial and production 
grade software, we should be very sensitive in investing time and energy in 
supporting a technology that may or may not have a viable path towards 
inclusion into mainstream (Linux and OVS in this instance).

One another clear example we had in the past was DPDK (that enabled fast path 
processing in Neutron with OVS) and connection tracking (that enabled security 
groups natively build on top of OVS). We, as a project have consistently 
avoided endorsing efforts until they mature and show a clear path forward.


Like you, we are closely following the progress of the patches and honestly I 
have hard time seeing OpenStack supporting NSH in production even by the end of 
2017. I think this amounts to slowing down the market...

I think we need to break the logjam.

We are not the ones (Neutron) you're supposed to break the logjam with. I think 
the stakeholders here go well beyond the Neutron team alone.


I've reviewed 
(https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
 and found nowhere a guideline suggesting that before a backend has fully 
implemented and merged upstream a technology (i.e. another project outside of 
OepnStack!), OpenStack Neutron can't make any move. ODL is working >2 years to 
support NSH using patches, yet to be accepted into Linux Kernel (almost done) 
and OvS (preliminary) - as you stated. Otherwise we create a serialization, 
that gets worse and worse over time and with additional layers.

No one suggests the such code needs to be PRODUCTION, but we need a way to roll 
out EXPERIMENTAL functions and later merge them quickly when all layers are 
ready, this creates a nice para

[openstack-dev] [tacker] Proposing Lin Cheng for tacker-horizon core team

[Sridhar Ramaswamy]

Tackers,

I'd like to propose Lin Cheng to join as a tacker-horizon core team member.
Lin has been our go-to person for all guidance related to UI enhancements
for Tacker. He has been actively reviewing patchsets in this area [1] and
also contributed to setup the unit test framework for tacker-horizon repo.

Please provide your +1/-1 votes.

- Sridhar

[1]
http://stackalytics.com/?project_type=all&metric=marks&release=all&module=tacker-group&user_id=lin-hua-cheng
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Log spool in the context

[Doug Hellmann]

Excerpts from Alexis Lee's message of 2016-05-26 17:29:27 +0100:
> Doug Hellmann said on Thu, May 26, 2016 at 10:16:31AM -0400:
> > I'm not sure silencing all messages for successful requests is a good
> > idea. That was not my understanding of the intent of this work, for
> > sure. I thought the idea was to run the spool logger at debug, but
> > maintain the other normal logging at info level so that monitoring
> > systems could still do things like track request rates and whatever else
> > one might want to do with logs aside from debugging failures.
> 
> We can still emit a few messages per request on the normal logger,
> EG log the request and response for auditability [A]. It's important
> records for a topic come out in-order though.
> 
> By default spooled records will end up in the main log so we also have
> to avoid making it look like more events occurred than actually did.
> This means logging every record to at most one logger. Even if there are
> clues, it's easy to miss them at 3am on an incident, better to avoid
> duplicate messages entirely.
> 
> Please could you go through the usecase you're worried about? For my

It sounded like you were suggesting that all request logging would be
spooled, and there would only be any log messages at all if there was an
error of some sort. I think you've clarified that's not the case.

What I expected was the spool logger would record info at a higher
level than the main logger, but write it to a different location.
That way monitoring tools that do things with the info-level messages
would still be able to look at the main log, but debug tools (or
humans) could look at the spooled log.

> money, either a high-level logrecord is 1) to do with the request
> failing, 2) an issue that does not cause the request to fail or 3)
> something you noticed en-passant, maybe related to the request but
> mostly to do with the overall health of the system.
> 
> 1) Spool like normal, emitted when the request fails.
> 2) Who cares? The code dealt with it.
> 3) Put this on the normal logger. It gets emitted immediately.
> 
> There may be case 2s we care about, EG deprecation warnings. Those
> shouldn't be logged per-request anyway though? So we probably shouldn't
> have case 2s. I'd not expect any case 3s below INFO.
> 
> The normal case will be messages up to INFO getting spooled; INFOs and
> WARNs usually getting spooled, occasionally not; and ERRORs always being
> spooled but flushed very quickly (unless they're so fatal they bring the
> whole system down).
> 
> 
> Alexis (lxsli)
> 
> [A] Logs are not a notification API though, anyone using them as such is
> asking to be broken.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Who is going to fix the broken non-voting tests?

[Adam Young]

On 05/26/2016 11:36 AM, Morgan Fainberg wrote:



On Thu, May 26, 2016 at 7:55 AM, Adam Young > wrote:


Some mix of these three tests is almost always failing:

gate-keystone-dsvm-functional-nv FAILURE in 20m 04s (non-voting)
gate-keystone-dsvm-functional-v3-only-nv FAILURE in 32m 45s
(non-voting)
gate-tempest-dsvm-keystone-uwsgi-full-nv FAILURE in 1h 07m 53s
(non-voting)


Are we going to keep them running and failing, or boot them?  If
we are going to keep them, who is going to commit to fixing them?

We should not live with broken windows.



The uwsgi check should be moved to a proper run utilizing mod_proxy_uwsgi.
Who wants to own this?  I am not fielding demands for uwsgi support 
mysqlf, and kind of think it is just a novelty, thus would not mind see 
it going away.  If someone really cares, please make yourself known.




The v3 only one is a WIP that a few folks are working on

Fair enough.


The function-nv one was passing somewhere. I think that one is close.


Yeah, it seems to be intermittant.





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] [stable] Proposal to add Ian Cordasco to glance-stable-maint

[Brian Rosmaita]

I am definitely +1 on this!  Thanks for volunteering, Ian.

On 5/26/16, 2:42 AM, "Tony Breeds"  wrote:

>On Wed, May 25, 2016 at 05:12:56PM -0400, Nikhil Komawar wrote:
>> Hi all,
>> 
>> 
>> I would like to propose adding Ian to glance-stable-maint team. The
>> interest is coming from him and I've already asked for feedback from the
>> current glance-stable-maint folks, which has been in Ian's favor. Also,
>> as Ian mentions the current global stable team isn't going to subsume
>> the per-project teams anytime soon.
>
>+1 to adding Ian.  He's been active on stable branches for a while and his
>reviews indicates he understand the stable policy.
>
>Thanks Nikhil and Ian.
>
>Yours Tony.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][api] POST /api-wg/news

[michael mccune]

Greetings OpenStack community,

Welcome to another edition of the API working group's weekly newsletter.

# Recently merged guidelines

These guidelines have been recently merged by the group.

* Description of how to use etags to avoid lost updates
  https://review.openstack.org/#/c/301846
* Delete multiple metadata items with a single request
  https://review.openstack.org/#/c/281511

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


* None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on 
for consistency and language. We encourage any interested parties to 
join in the conversation.


* Actions guideline
  https://review.openstack.org/234994
* Add description of pagination parameters
  https://review.openstack.org/190743
* Add guideline for Experimental APIs
  https://review.openstack.org/273158
* Add version discovery guideline
  https://review.openstack.org/254895

# APIImpact reviews currently open

Reviews marked as APIImpact are meant to help inform the working group 
about changes which would benefit from wider inspection by group members 
and liaisons. While the working group will attempt to address these 
reviews whenever possible, it is highly recommended that interested 
parties attend the API-WG meetings [1] to promote communication 
surrounding their reviews.


https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

Thanks for reading and see you next week!

[1] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Log spool in the context

[Alexis Lee]

Doug Hellmann said on Thu, May 26, 2016 at 10:16:31AM -0400:
> I'm not sure silencing all messages for successful requests is a good
> idea. That was not my understanding of the intent of this work, for
> sure. I thought the idea was to run the spool logger at debug, but
> maintain the other normal logging at info level so that monitoring
> systems could still do things like track request rates and whatever else
> one might want to do with logs aside from debugging failures.

We can still emit a few messages per request on the normal logger,
EG log the request and response for auditability [A]. It's important
records for a topic come out in-order though.

By default spooled records will end up in the main log so we also have
to avoid making it look like more events occurred than actually did.
This means logging every record to at most one logger. Even if there are
clues, it's easy to miss them at 3am on an incident, better to avoid
duplicate messages entirely.

Please could you go through the usecase you're worried about? For my
money, either a high-level logrecord is 1) to do with the request
failing, 2) an issue that does not cause the request to fail or 3)
something you noticed en-passant, maybe related to the request but
mostly to do with the overall health of the system.

1) Spool like normal, emitted when the request fails.
2) Who cares? The code dealt with it.
3) Put this on the normal logger. It gets emitted immediately.

There may be case 2s we care about, EG deprecation warnings. Those
shouldn't be logged per-request anyway though? So we probably shouldn't
have case 2s. I'd not expect any case 3s below INFO.

The normal case will be messages up to INFO getting spooled; INFOs and
WARNs usually getting spooled, occasionally not; and ERRORs always being
spooled but flushed very quickly (unless they're so fatal they bring the
whole system down).


Alexis (lxsli)

[A] Logs are not a notification API though, anyone using them as such is
asking to be broken.
-- 
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB 314 1496 79

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

My (incomplete) throughts about the flow-classifier are:

1)  ACL’s are more about denying access, while the flow classifier is more 
about steering selected traffic to a path, so we would need to deny-all except 
allowed flows.
2)  The networking-sfc team has done a nice job with the drivers so ovn has its 
own flow-classifier driver which allows us to align the flow-classifier with 
the matches supported in ovs/ovn, which could be an advantage.

What were your thoughts on the schema it adds a lot of tables and a lot of 
commands – cannot think of anyway around it

Regards

John

From: Ryan Moats mailto:rmo...@us.ibm.com>>
Date: Wednesday, May 25, 2016 at 9:12 PM
To: John McDowall 
mailto:jmcdow...@paloaltonetworks.com>>
Cc: Ben Pfaff mailto:b...@ovn.org>>, 
"disc...@openvswitch.org" 
mailto:disc...@openvswitch.org>>, Justin Pettit 
mailto:jpet...@ovn.org>>, OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>, 
Russell Bryant mailto:russ...@ovn.org>>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
mailto:jmcdow...@paloaltonetworks.com>> wrote 
on 05/25/2016 07:27:46 PM:

> From: John McDowall 
> mailto:jmcdow...@paloaltonetworks.com>>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> mailto:disc...@openvswitch.org>>, "OpenStack
> Development Mailing List" 
> mailto:openstack-dev@lists.openstack.org>>,
>  Ben
> Pfaff mailto:b...@ovn.org>>, Justin Pettit 
> mailto:jpet...@ovn.org>>, Russell Bryant
> mailto:russ...@ovn.org>>
> Date: 05/25/2016 07:28 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Ok – I will let the experts weigh in on load balancing.
>
> In the meantime I have attached a couple of files to show where I am
> going. The first is sfc_dict.py and is a representation of the dict
> I am passing from SFC to OVN. This will then translate to the
> attached ovn-nb schema file.
>
> One of my concerns is that SFC almost doubles the size of the ovn-nb
> schema but I could not think of any other way of doing it.
>
> Thoughts?
>
> John

The dictionary looks fine for a starting point, and the more I look
at the classifier, the more I wonder if we can't do something with
the current ACL table to avoid duplication in the NB database
definition...

Ryan

> From: Ryan Moats mailto:rmo...@us.ibm.com>>
> Date: Wednesday, May 25, 2016 at 7:27 AM
> To: John McDowall 
> mailto:jmcdow...@paloaltonetworks.com>>
> Cc: "disc...@openvswitch.org" 
> mailto:disc...@openvswitch.org>>, OpenStack
> Development Mailing List 
> mailto:openstack-dev@lists.openstack.org>>,
>  Ben Pfaff <
> b...@ovn.org>, Justin Pettit 
> mailto:jpet...@ovn.org>>, Russell Bryant 
> mailto:russ...@ovn.org>
> >
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall 
> mailto:jmcdow...@paloaltonetworks.com>> wrote 
> on 05/24/2016
> 06:33:05 PM:
>
> > From: John McDowall 
> > mailto:jmcdow...@paloaltonetworks.com>>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" 
> > mailto:disc...@openvswitch.org>>, "OpenStack
> > Development Mailing List" 
> > mailto:openstack-dev@lists.openstack.org>>
> > Date: 05/24/2016 06:33 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Thanks for getting back to me and pointing me in a more OVS like
> > direction. What you say makes sense, let me hack something together.
> > I have been a little distracted getting some use cases together. The
> > other area is how to better map the flow-classifier I have been
> > thinking about it a little, but I will leave it till after we get
> > the chains done.
> >
> > Your load-balancing comment was very interesting – I saw some
> > patches for load-balancing a few months ago but nothing since. It
> > would be great if we could align with load-balancing as that would
> > make a really powerful solution.
> >
> > Regards
> >
> > John
>
> John-
>
> For the load balancing, I believe that you'll want to look at
> openvswitch's select group, as that should let you set up multiple
> buckets for each egress port in the port pairs that make up a port
> group.
>
> As I understand it, Table 0 identifies the logical port and logical
> flow. I'm worried that this means we'll end up with separate bucket
> rules for each ingress port of the port pairs that make up a port
> group, leading to a cardinality product in the number of rules.
> I'm trying to think of a way where Table 0 could identify the packet
> as being part of a particular port group, and then I'd only need one
> set of bucket rules to figure out the egress side.  However, the
> amount of free metadata space is limited and so before we go down
> this path, I'm going to pull Justin, Ben and Russell in to see if
> they buy into this idea or if they can think of an alternative.

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Agree with your description of the problem. The only thing I would add is that 
in the case of bi-directional chains the return flows need to go through the 
same VNF(Port-pair).

Regards

John

From: Ryan Moats mailto:rmo...@us.ibm.com>>
Date: Wednesday, May 25, 2016 at 9:29 PM
To: Ben Pfaff mailto:b...@ovn.org>>
Cc: "disc...@openvswitch.org" 
mailto:disc...@openvswitch.org>>, John McDowall 
mailto:jmcdow...@paloaltonetworks.com>>, Justin 
Pettit mailto:jpet...@ovn.org>>, OpenStack Development Mailing 
List 
mailto:openstack-dev@lists.openstack.org>>, 
Russell Bryant mailto:russ...@ovn.org>>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


Ben Pfaff mailto:b...@ovn.org>> wrote on 05/25/2016 07:44:43 PM:

> From: Ben Pfaff mailto:b...@ovn.org>>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: John McDowall 
> mailto:jmcdow...@paloaltonetworks.com>>,
> "disc...@openvswitch.org" 
> mailto:disc...@openvswitch.org>>, OpenStack
> Development Mailing List 
> mailto:openstack-dev@lists.openstack.org>>,
>  Justin
> Pettit mailto:jpet...@ovn.org>>, Russell Bryant 
> mailto:russ...@ovn.org>>
> Date: 05/25/2016 07:44 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> On Wed, May 25, 2016 at 09:27:31AM -0500, Ryan Moats wrote:
> > As I understand it, Table 0 identifies the logical port and logical
> > flow. I'm worried that this means we'll end up with separate bucket
> > rules for each ingress port of the port pairs that make up a port
> > group, leading to a cardinality product in the number of rules.
> > I'm trying to think of a way where Table 0 could identify the packet
> > as being part of a particular port group, and then I'd only need one
> > set of bucket rules to figure out the egress side.  However, the
> > amount of free metadata space is limited and so before we go down
> > this path, I'm going to pull Justin, Ben and Russell in to see if
> > they buy into this idea or if they can think of an alternative.
>
> I've barely been following the discussion, so a recap of the question
> here would help a lot.
>

Sure (and John gets to correct me where I'm wrong) - the SFC proposal
is to carry a chain as a ordered set of port groups, where each group
consists of multiple port pairs. Each port pair consists of an ingress
port and an egress port, so that traffic is load balanced between
the ingress ports of a group. Traffic from the egress port of a group
is sent to the ingress port of the next group (ingress and egress here
are from the point of view of the thing getting the traffic).

I was suggesting to John that from the view of the switch, this would
be reversed in the openvswitch rules - the proposed CHAINING stage
in the ingress pipeline would apply the classifier for traffic entering
a chain and identify traffic coming from an egress SFC port in the
midst of a chain. The egress pipeline would identify the next ingress SFC
port that gets the traffic or the final destination for traffic exiting
the chain.

Further, I pointed him at the select group for how traffic could be
load balanced between the different ports that are contained in a port
group, but that I was worried that I'd need a cartesian product of rules
in the egress chain stage.  Having thought about this some more, I'm
realizing that I'm confused and the number of rules should not be that
bad:

- Table 0 will identify the logical port the traffic comes from
- The CHAINING stage of the ingress pipeline can map that logical
  port information to the port group the port is part of.
- The CHAINING stage of the egress pipeline would use that port
  group information to select the next logical port via a select group.

I believe this requires a total number of rules in the CHAINING stages
of the order of the number of ports in the service chain.

The above is predicated on carrying the port group information from
the ingress pipeline to the egress pipeline in metadata, so I would
be looking to you for ideas on where this data could be carried, since
I know that we don't have infinite space for said metadata...

Ryan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

[Ed Leafe]

On May 25, 2016, at 7:25 AM, Denis Makogon  wrote:

> Correct me if i'm wrong, none of the messages above were stating about 
> support Go-extensions for Python (C extensions were mentioned couple times). 
> Starting Go v1.5 it is possible to develop extension for Python [1] (lib that 
> helps to develop extensions [2])

No, you’re not wrong at all.

This is much more in the original spirit for dealing with the inevitable issues 
where Python just doesn’t cut it performance-wise. The idea was to do 
everything in Python, and where there was a bottleneck, write a C module for 
that function and integrate it using ctypes. 

So could someone from the Designate team do the following: isolate the part(s) 
of the process where Go kicks Python’s butt, create small Go packages to handle 
them, and then use gopy to integrate it? I think there would be little or no 
controversy with this approach, as it’s much less disruptive to the overall 
community.


-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes]

[Fox, Kevin M]

Two issues I can see with that approach.

1. It needs to be incredibly well documented as well as tools provided to 
update states in etcd manually when an op needs to recover from things 
partially working.
2. Consider the case where an op has an existing cloud. He/She installs k8s on 
their existing control plane, and then one openstack service at a time wants to 
"upgrade" the system from non container to containers. If the user wants to do 
so, with the jobs method, the op just skips the bootstrap jobs. With magic 
baked into the containers and etcd, the same kinds of things in issue #1 needs 
fixing in etcd so it doesn't try and reinit things. This makes it harder to get 
clouds migrated to kolla-k8s.

I know the idea is to try and simplify deployment by making the containers do 
all the initing automagically. but I'm afraid that just sweeps issues under the 
rug, out of the light where they still will come up, but more unexpectedly. The 
ops still need to understand the automagic that is happening. As an Op, I'd 
rather it be explicit, out front, where I know its happening, and I can easily 
tweak the workflow when necessary to get out of a bind.

Thanks,
Kevin

From: Ryan Hallisey [rhall...@redhat.com]
Sent: Thursday, May 26, 2016 5:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kubernetes]

Thanks for the feedback Kevin.

The community has been investigation other options this week.  The option that 
is currently being looked at involves
using etcd to provide a locking mechanic so that services in the cluster are 
aware bootstrapping is underway.

The concept involves extending kolla's dockerfiles and having them poll etcd to 
determine whether a bootstrap is in progress or complete [1].

I'll follow up by adding this to the spec.

Thanks,
Ryan

[1] - https://review.openstack.org/#/c/320744/

- Original Message -
From: "Kevin M Fox" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, May 23, 2016 11:37:33 AM
Subject: Re: [openstack-dev] [kubernetes]

+1 for using k8s to do work where possible.

-1 for trying to shoehorn a feature in so that k8s can deal with stuff its not 
ready to handle. We need to ensure Operators have everything they need in order 
to successfully operate their cloud.

The current upgrade stuff in k8s is focused around replacing one, usually 
stateless, thing for another. It never had Database Schema upgrades in mind.  
It is great to use for minor version bumps. It is insufficient for major 
OpenStack upgrades. If you follow the OpenStack release notes, they tend to be 
quite linear, in a workflow. K8s isn't designed for that. Hence the need for a 
tool outside of k8s to drive the creation/upgrading of Deployments and Jobs in 
the proper order.

Init containers also do not look like a good fit. As far as I can gather from 
the spec, they are intended to init something on a node when a pod is spawned. 
This is a very different thing from upgrading a shared database's schema. I 
don't believe they should be used for that.

I've upgraded many OpenStack clouds over the years. One of the things that has 
bit me from time to time is a failed schema update and having to tweak code and 
then rerun schema upgrades. This will continue to happen and needs to be 
covered. The Job's workflow as discussed in the spec allows an operator to do 
just that. Hiding it in an init container makes that much harder for Operators.

As an Op, we need the ability to tweak the workflow as needed and run/rerun 
only the pieces that we need.

Thanks,
Kevin

From: Ryan Hallisey [rhall...@redhat.com]
Sent: Sunday, May 22, 2016 12:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev]  [kolla][kolla-kubernetes][kubernetes]

Hi all,

At the Kolla meeting last week, I brought up some of the challenges around the 
bootstrapping
process in Kubernetes.  The main highlight revolved around how the 
bootstrapping process will
work.

Currently, in the kolla-kubernetes spec [1], the process for bootstrapping 
involves
outside orchestration running Kubernetes 'Jobs' that will handle the database 
initialization,
creating users, etc...  One of the flaws in this approach, is that 
kolla-kubernetes can't use
native Kubernetes upgrade tooling. Kubernetes does upgrades as a single action 
that scales
down running containers and replaces them with the upgraded containers. So 
instead of having
Kubernetes manage the upgrade, it would be guided by an external engine.  Not 
saying this is
a bad thing, but it does loosen the control Kubernetes would have over stack 
management.

Kubernetes does have some incoming new features that are a step in the right 
direction to
allow for kolla-kubernetes to make complete use of Kubernetes tooling like init 
containers [2].
There is also the introduction to wait.for conditions i

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

[Ed Leafe]

On May 25, 2016, at 7:09 PM, Adrian Otto  wrote:

> In order to evolve, OpenStack must allow alternatives.

A tautology, for sure, and it certainly doesn’t require changing languages in 
order to evolve. All sorts of alternative approaches can bring about evolution.

Evolution is also not without pain; without such stress evolution simply 
doesn’t happen. The discussion is about one such pain point, and how to best 
address it so as to eliminate the pain with the minimal amount of impact on the 
community.

-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] integrating keystone with oauth2 (keycloak)

[Adam Young]

On 05/26/2016 11:20 AM, Shtilman, Tomer (Nokia - IL) wrote:


Hi

Does keystone has any plugin/extension for oauth2 authentication 
(keycloak in our case)


We would like to integrate keystone with an external oauth2 system in 
this way:


1/ Credentials / being sent to keystone

2/ Keystone will interact with external oauth2 server to  validate and 
fetch user details,tenant(project),roles etc.. (no endpoints) and will 
generate a token


Keycloak supports SAML2, which I've confirmed works using 
mod_auth_mellon and Federation on the Keystone side. We are working on 
confirming ECP.  I think ECP is the only viable Federation CLI approach 
for Keycloak right now, but we might be pleasantly surprised.


3/ Token will be used from this point , token will need to be 
validated with oauth2 through keystone until expiry


Any thought/insights will be highly appreciated

Thanks



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Who is going to fix the broken non-voting tests?

[Morgan Fainberg]

On Thu, May 26, 2016 at 7:55 AM, Adam Young  wrote:

> Some mix of these three tests is almost always failing:
>
> gate-keystone-dsvm-functional-nv FAILURE in 20m 04s (non-voting)
> gate-keystone-dsvm-functional-v3-only-nv FAILURE in 32m 45s (non-voting)
> gate-tempest-dsvm-keystone-uwsgi-full-nv FAILURE in 1h 07m 53s (non-voting)
>
>
> Are we going to keep them running and failing, or boot them?  If we are
> going to keep them, who is going to commit to fixing them?
>
> We should not live with broken windows.
>
>
>
The uwsgi check should be moved to a proper run utilizing mod_proxy_uwsgi.
The v3 only one is a WIP that a few folks are working on
The function-nv one was passing somewhere. I think that one is close.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas]Question about MPLS VPN

[Kosnik, Lubosz]

I had a discussion with few operators and after what I heard about VPNaaS I can 
tell that we not suppose to help with that implementation.
Maybe we should work on service VM’s and prepare implementation of VPNaaS using 
them and using some prebuild images like VyOS or other.

Lubosz Kosnik
Cloud Software Engineer OSIC
lubosz.kos...@intel.com

> On May 26, 2016, at 9:39 AM, Ihar Hrachyshka  wrote:
> 
> 
>> On 26 May 2016, at 16:23, Kosnik, Lubosz  wrote:
>> 
>> You should read e-mails on ML. VPNaaS will be removed in next 6 months from 
>> repo. You need to look into something else like starting VyOS image, pfSense 
>> or other.
> 
> Strictly speaking, vpnaas is on probation right now, and if interested 
> parties actually revive the project, it may stay past those 6 months. That 
> said, I haven’t heard about anyone stepping in since the summit.
> 
> Ihar
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] integrating keystone with oauth2 (keycloak)

[Shtilman, Tomer (Nokia - IL)]

Hi
Does keystone has any plugin/extension for oauth2 authentication (keycloak in 
our case)
We would like to integrate keystone with an external oauth2 system in this way:
1/ Credentials / being sent to keystone
2/ Keystone will interact with external oauth2 server to  validate and fetch 
user details,tenant(project),roles etc.. (no endpoints) and will generate a 
token
3/ Token will be used from this point , token will need to be validated with 
oauth2 through keystone until expiry
Any thought/insights will be highly appreciated
Thanks




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [gate] [nova] live migration, libvirt 1.3, and the gate

[Sean Dague]

On 05/24/2016 01:59 PM, Sean Dague wrote:

> So, we have a number of open questions:
> 
> * Have our cloud providers standardized enough that we might get away
> without this custom cpu model? (Have some of them done it and only use
> those for multinode?)

This is definitely not true on RAX. Experimenting with not doing the
gate64 cpu setting failed in one of the live migration jobs on RAX
because of cpu compat. Here is the cpu comparison between the master and
subnode (http://paste.openstack.org/show/505672/)

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [vitrage] failed to show graph topology on graph without root

[Malin, Eylon (Nokia - IL)]

I use vitrage cli :vitrage topology show

I’m using vitrage in env without openstack, so it would be pretty difficult to 
provide the data.

But I think that if you would remove nova datasource from the vitrage.conf it 
would be reproduced also for you.

Eylon

From: Zhang Yujun [mailto:zhangyujun+...@gmail.com]
Sent: Thursday, May 26, 2016 6:00 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [vitrage] failed to show graph topology on graph 
without root

Hi Eylon,

Could you please provide the query and data which will reproduce this issue?

--
Yujun

On Thu, May 26, 2016 at 10:44 PM Malin, Eylon (Nokia - IL) 
mailto:eylon.ma...@nokia.com>> wrote:
Hi all,

I use vitrage without any root graph (In my case there is no root).
Until few days ago I was able to request topology of type graph with no 
problems.
But I can't, I got 404, and the log says it can't find openstack.cluster node.

I think it have the problems since these commits : 
I1189047849f714d8435414cc48098d71837b3ed0, 
I1438713136c0177282e8ee8e19a651af5590feef


Eylon

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [vitrage] failed to show graph topology on graph without root

[Zhang Yujun]

Hi Eylon,

Could you please provide the query and data which will reproduce this issue?

--
Yujun

On Thu, May 26, 2016 at 10:44 PM Malin, Eylon (Nokia - IL) <
eylon.ma...@nokia.com> wrote:

> Hi all,
>
> I use vitrage without any root graph (In my case there is no root).
> Until few days ago I was able to request topology of type graph with no
> problems.
> But I can't, I got 404, and the log says it can't find openstack.cluster
> node.
>
> I think it have the problems since these commits :
> I1189047849f714d8435414cc48098d71837b3ed0,
> I1438713136c0177282e8ee8e19a651af5590feef
>
>
> Eylon
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] Who is going to fix the broken non-voting tests?

[Adam Young]

Some mix of these three tests is almost always failing:

gate-keystone-dsvm-functional-nv FAILURE in 20m 04s (non-voting)
gate-keystone-dsvm-functional-v3-only-nv FAILURE in 32m 45s (non-voting)
gate-tempest-dsvm-keystone-uwsgi-full-nv FAILURE in 1h 07m 53s (non-voting)


Are we going to keep them running and failing, or boot them?  If we are 
going to keep them, who is going to commit to fixing them?


We should not live with broken windows.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [gate] [nova] live migration, libvirt 1.3, and the gate

[Sean Dague]

On 05/26/2016 05:38 AM, Kashyap Chamarthy wrote:
> On Wed, May 25, 2016 at 05:42:04PM +0200, Kashyap Chamarthy wrote:
> 
> [...]
> 
>> So, in short, the central issue seems to be this: the custom 'gate64'
>> model is not being trasnalted by libvirt into a model that QEMU can
>> recognize.
> 
> An update:
> 
> Upstream libvirt points out that this turns to be regression, and
> bisected it to commit (in libvirt Git): 1.2.9-31-g445a09b -- "qemu:
> Don't compare CPU against host for TCG".
> 
> So, I expect there's going to be fix pretty soon upstream libvirt.

Which is good... I wonder how long we'll be waiting for that back in our
distro packages though.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][all] oslo.log `verbose` and $your project

[Amrith Kumar]

Ihar,

I entered 1586066[1] for Trove and the Trove change is 321585.

Thanks,

-amrith

[1] https://bugs.launchpad.net/trove/+bug/1586066
[2] https://review.openstack.org/#/c/321585/


> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Thursday, May 26, 2016 7:21 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [oslo][all] oslo.log `verbose` and $your
> project
> 
> Neutron patch is at: https://review.openstack.org/#/c/321481/
> 
> It could be worth reporting a bug and add all identified components to it.
> 
> > On 26 May 2016, at 12:39, Alexis Lee  wrote:
> >
> > I see a few reviews still open:
> >
> > https://review.openstack.org/#/c/315868 - designate
> > https://review.openstack.org/#/c/315655 - devstack
> > https://review.openstack.org/#/c/317579 - glance
> > https://review.openstack.org/#/c/317556 - glance_store
> >
> > Please could these get some attention?
> >
> > From browsing codesearch.openstack.org, I also see possible hits in:
> >
> > * cerberus
> > * charm-ceilometer
> > * charm-cinder
> > * charm-glance
> > * charm-heat ?
> > * charm-keystone
> > * charm-neutron-api
> > * charm-neutron-gateway
> > * charm-neutron-openvswitch
> > * charm-nova-cloud-controller
> > * charm-nova-compute
> > * charm-openstack-dashboard
> > * cloudpulse
> > * compass-adapters
> > * cookbook-openstack-database
> > * cue
> > * fuel-agent
> > * fuel-plugin-dbaas-trove
> > * fuel-plugin-ironic
> > * fuel-qa
> > * kolla
> > * neutron
> > * openstack-chef
> > * openstack-manuals
> > * osops-example-configs
> > * osops-tools-contrib
> > * packstack
> > * puppet-glance
> > * rack
> > * sahara
> > * salt-formula-ceilometer
> > * salt-formula-cinder
> > * salt-formula-glance
> > * salt-formula-neutron
> > * salt-formula-nova
> > * shaker
> > * solar-resources
> > * tacker
> > * tripleo-image-elements
> > * trove
> > * zaqar
> > * and many more!
> > * that's only half of the list
> > * I got bored
> >
> > Please check your projects!
> >
> >
> http://codesearch.openstack.org/?q=INFO%20instead%20of%20default%20WARNING
> %20level
> > http://codesearch.openstack.org/?q=verbose
> >
> >
> > Alexis (lxsli)
> > --
> > Nova developer, Hewlett-Packard Limited.
> > Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
> > Registered Number: 00690597 England
> > VAT number: GB 314 1496 79
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas]Question about MPLS VPN

[Ihar Hrachyshka]

> On 26 May 2016, at 16:23, Kosnik, Lubosz  wrote:
> 
> You should read e-mails on ML. VPNaaS will be removed in next 6 months from 
> repo. You need to look into something else like starting VyOS image, pfSense 
> or other.

Strictly speaking, vpnaas is on probation right now, and if interested parties 
actually revive the project, it may stay past those 6 months. That said, I 
haven’t heard about anyone stepping in since the summit.

Ihar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [vitrage] failed to show graph topology on graph without root

[Malin, Eylon (Nokia - IL)]

Hi all,

I use vitrage without any root graph (In my case there is no root).
Until few days ago I was able to request topology of type graph with no 
problems.
But I can't, I got 404, and the log says it can't find openstack.cluster node.

I think it have the problems since these commits : 
I1189047849f714d8435414cc48098d71837b3ed0, 
I1438713136c0177282e8ee8e19a651af5590feef 


Eylon

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] proposal about puppet versions testing coverage

[Iury Gregory]

So here's my proposal, feel fee to comment:
>
> * Reduce puppet versions testing to 3.6, 3.8, 4.5 and latest (keep the
> last one non-voting). It seems that 3.6 and 3.8 are widely used by our
> consumers (default in centos7 & ubuntu LTS), and 4.5 is the latest
> release in the 4.x series.
> * Move functional puppet4 jobs from experimental to check pipeline
> (non-voting). They'll bring very useful feedback. It will add 6 more
> jobs in the check queue, but since we will drop 2 unit tests jobs (in
> both check & gate pipelines), it will add 2 jobs at total (in term of
> time, unit tests jobs take 15 min and functional jobs take ~30 min) so
> the impact of node consumption is IMHO not relevant here.
>

Awesome idea Emilien (+1)
I agree with Mat that we should have Puppet4 voting, for now no-voting but
agree with Denis
that the puppet-team can make efforts on this =)

-- 
~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@gmail.com *
~
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas]Question about MPLS VPN

[Kosnik, Lubosz]

You should read e-mails on ML. VPNaaS will be removed in next 6 months from 
repo. You need to look into something else like starting VyOS image, pfSense or 
other.

Lubosz Kosnik
Cloud Software Engineer OSIC
lubosz.kos...@intel.com

> On May 26, 2016, at 1:50 AM, zhangyali (D)  wrote:
> 
> Hi all,
> 
> I am interested in the VPNaaS project in Neutron. Now I notice that only 
> IPsec tunnel has completed, but other types of VPN, such as, MPLS/BGP, have 
> not completed. I'd like to know how's going about MPLS/BGP vpn? What's the 
> mechanism or extra work need to be done? 
> 
> Thanks.
> 
> Best,
> Yali
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Log spool in the context

[Doug Hellmann]

Excerpts from Alexis Lee's message of 2016-05-26 11:58:46 +0100:
> Doug Hellmann said on Wed, May 25, 2016 at 11:56:55AM -0400:
> > But that leaves it up to the application or library author to have to
> > make that call for every log message, which makes logging more
> > complicated.
> 
> Almost all messages generated while processing a request should only go
> to the request logger. If a message is obviously important outside the
> context of that single request, it can also/instead be logged to the
> normal logger, but this should very much be the exception to the rule.
> 
> > The point of the spooling logger is to dump everything about a request
> > when the request fails, right? And we want the "normal" behavior the
> > rest of the time? It seems like we should look at a way to make that
> > happen without a lot of impact on application logic.
> > 
> > It's OK to have the same message go to both loggers, right? Could we
> > have a wrapper class that takes a normal logger and a spooling logger
> > and sends its messages to both?
> 
> No, definitely not. Log records associated with successful requests
> should not be emitted at all. This will make the practice of running at
> DEBUG more bearable. IE the goal is to reduce logging volume, not double
> it!
> 
> > Even better would be to find a way to configure the logger hierarchy
> > so that is completely transparent, so that messages going to the
> > SpoolLogger are propagated to the normal logger based on their log
> > level.
> 
> The logger a message should go to is orthogonal to its level. If a
> requested resource, which should exist, does not - this might be logged
> at ERROR, a very high level. It doesn't need to go to the normal log
> though because it's strictly to do with that request. So if we duplicate
> all high level logs to the normal logger, we'll see unnecessary records
> in the normal log.
> 
> If someone really wanted these duplicates, they could add their normal
> handler to the 'spool' logger with a high loglevel.
> 
> 
> Alexis (lxsli)

I'm not sure silencing all messages for successful requests is a good
idea. That was not my understanding of the intent of this work, for
sure. I thought the idea was to run the spool logger at debug, but
maintain the other normal logging at info level so that monitoring
systems could still do things like track request rates and whatever else
one might want to do with logs aside from debugging failures.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Can not get fixed_ips during the db transaction of updating port

[Hong Hui Xiao]

Hi all.

I was working on this bug [1] (ML2 doesn't return fixed_ips on a port 
update with binding)

I think it should be a DB issue, and I put some investigation result at 
[2]. I even made up some code change [3] to resolve the bug. But, I don't 
know the actual root cause for the problem. And why the code resolve the 
bug.

Can someone tell me the reason?

[1] https://bugs.launchpad.net/neutron/+bug/1585738
[2] https://bugs.launchpad.net/neutron/+bug/1585738/comments/5
[3] https://review.openstack.org/#/c/321152/3//COMMIT_MSG


Thanks

HongHui Xiao(肖宏辉) PMP®

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Zaqar messages standardization

[Dmitry Tantsur]

On 05/25/2016 08:08 PM, Thomas Herve wrote:

On Fri, May 20, 2016 at 5:52 PM, Jiri Tomasek  wrote:

Hey all,

I've been recently working on getting the TripleO UI integrated with Zaqar,
so it can receive a messages from Mistral workflows and act upon them
without having to do various polling hacks.

Since there is currently quite a large amount of new TripleO workflows
comming to tripleo-common, we need to standardize this communication so
clients can consume the messages consistently.

I'll try to outline the requirements as I see it to start the discussion.

Zaqar queues:
To listen to the Zaqar messages it requires the client to connect to Zaqar
WebSocket, send authenticate message and subscribe to queue(s) which it
wants to listen to. The currently pending workflow patches which send Zaqar
messages [1, 2] expect that the queue is created by client and name is
passed as an input to the workflow [3].

From the client perspective, it would IMHO be better if all workflows sent
messages to the same queue and provide means to identify itself by carrying
workflow name and execution id. The reason is, that if client creates a
queue and triggers the workflow and then disconnects from the Socket (user
refreshes browser), then it does not know what queues it previously created
and which it should listen to. If there is single 'tripleo' queue, then all
clients always know that it is where it will get all the messages from.

Messages identification and content:
The client should be able to identify message by it's name so it can act
upon it. The name should probably be relevant to the action or workflow it
reports on.

{
  body: {
name: 'tripleo.validations.v1.run_validation,
execution_id: '123123123'
data: {}
  }
}

Other parts of the message are optional but it would be good to provide
information relevant to the message's purpose, so the client can update
relevant state and does not have to do any additional API calls. So e.g. in
case of running the validation a message includes validation id.


Hi,

Sorry for not responding earlier, but I have some inputs. In Heat we
publish events on Zaqar queue, and we defined this format:

{
'timestamp': $timestamp,
'version': '0.1',
'type': 'os.heat.event',
'id': $uuid,
'payload': {
'XXX
}
}

I don't think we have strong requirements on that, and we can
certainly make some tweaks. If we can converge towards something
simimar that'd be great.


One more datapoint here. Ironic agreed on the following format:
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/notifications.html#proposed-change
but I'm not sure if we implemented it already.



Thanks,




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet] 7.1.0 released (Liberty)

[Emilien Macchi]

Hi,

We're happy to announce the release of 7.1.0 (Liberty).
All you need to know is documented here:
http://releases.openstack.org/teams/puppet_openstack.html
You'll also find tarballs and release notes.

Feedback about this release:
For the first time we used openstack/releases tools, and it's really
cool. It makes release management much simpler for us and more
consistent with other projects.
We still have an issue with e-mails announcements but I'm working on
it this week. Thanks Tony & Doug for your help on this one!

Regards,
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Haim Daniel]

Hi all,

sorry for digging up this thread. I took a liberty to submitt an RFE per
Ihar's suggestion for the first step (switching to l2 agent extensions):
https://bugs.launchpad.net/networking-sfc/+bug/1586024

As a followup on that - hoping to send some wip patches in the near time.

Hope to hear your thoughts/suggestions on the $subj.

On Fri, Apr 15, 2016 at 2:44 AM, Ihar Hrachyshka 
wrote:

> Cathy Zhang  wrote:
>
>
>> I think there is no formal spec or anything, just some emails around
>> there.
>>
>> That said, I don’t follow why it’s a requirement for SFC to switch to l2
>> agent extension mechanism. Even today, with SFC maintaining its own agent,
>> there are no clear guarantees for flow priorities that would avoid all
>> possible conflicts.
>>
>> Cathy> There is no requirement for SFC to switch. My understanding is
>> that current L2 agent extension does not solve the conflicting entry issue
>> if two features inject the same priority table entry. I think this new L2
>> agent effort is try to come up with a mechanism to resolve this issue. Of
>> course if each feature( SFC or Qos) uses its own agent, then there is no
>> coordination and no way to avoid conflicts.
>>
>
> Sorry, I probably used misleading wording. I meant, why do we consider the
> semantic flow management support in l2 agent extension framework a
> *prerequisite* for SFC to switch to l2 agent extensions? The existing
> framework should already allow SFC to achieve what you have in the
> subproject tree implemented as a separate agent (essentially a fork of OVS
> agent). It will also set SFC to use standard extension mechanisms instead
> of hacky inheritance from OVS agent classes. So even without the strict
> semantic flow management, there is benefit for the subproject.
>
> With that in mind, I would split this job into 3 pieces:
> * first, adopt l2 agent extension mechanism for SFC functionality
> (dropping custom agent);
> * then, work on semantic flow management support in OVS agent API class
> [1];
> * once the feature emerges, switch SFC l2 agent extension to the new
> framework to manage SFC flows.
>
> I would at least prioritize the first point and target it to Newton-1.
> Other bullet points may take significant time to bake.
>
> [1]
> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py
>
> Ihar
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][oslo] Mitaka neutron-*aas are broken when --config-dir is passed

[Ihar Hrachyshka]

> On 25 May 2016, at 18:47, Armando M.  wrote:
> 
> 
> 
> On 25 May 2016 at 09:02, Brandon Logan  wrote:
> +1
> 
> This sounds like a sane plane.  That magical config load caused me some
> problems in the past when I didn't know about it, would be glad to see
> it go.  I thought it being deprecated and removed was planned anyway,
> and honestly didn't think it was still in the code base because I hadn't
> run into any issues recently.
> 
> If my memory doesn't fail me, that code is still around for a couple of 
> reasons, and one being documented in [1] (the other one I think was because 
> of the devstack's way of configuring *-aas). My suggestion would be to 
> thoroughly think what the implications are before we let it up in flames. 
> Things might have changed since the last time this code was touched, but one 
> never knows.
> 
> [1] https://bugs.launchpad.net/neutron/+bug/1492069

Thanks for the link. So as far as I understand the use case, it’s to allow an 
external service plugin to drop neutron_.conf file into 
/etc/neutron and expect it to load service providers definition from there, 
without the need to change neutron-server CLI. Right?

If that’s the case, it may be achieved with oslo.config --config-dir option, 
where you would create a directory somewhere under /etc/neutron and drop all 
your additional configuration files there (or symlink them from there), and 
then pass the directory name thru --config-dir, so that oslo.config would load 
all *.conf files from the directory. In that way, you have your CLI stable for 
neutron-server process, while the list of configuration files to load 
service_providers sections from is dynamic and depends on subprojects installed.

Actually, that’s exactly how we handle additional configuration files in RDO 
where we create /etc/neutron/conf.d/ directories per service and 
make sure that each service loads configuration files from there. F.e. that’s 
CLI we use for neutron-server:

https://github.com/openstack-packages/neutron/blob/rpm-master/neutron-server.service#L8

/usr/bin/neutron-server […]  --config-dir /etc/neutron/conf.d/neutron-server […]

So when you want to make neutron-server to load an additional config file for 
you, you just drop your .conf file there.

I would prefer neutron upstream comes up with a standard directory layout for 
exactly that need, and document it as a deployment requirement, so that all 
subprojects may rely on the directory being created and loaded by the 
controller. Of course, I would prefer if it reflects what RDO already does, so 
that we don’t need to make the change. :)

As for devstack, yes indeed we load neutron_*aas.conf files there relying on 
the magic code. This should not stop us from deprecating and eventually 
removing the code though. I am happy to push the needed devstack patches if we 
agree that’s the end goal to have pure oslo.config configuration loading.

Ihar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes]

[Ryan Hallisey]

Thanks for the feedback Kevin.

The community has been investigation other options this week.  The option that 
is currently being looked at involves
using etcd to provide a locking mechanic so that services in the cluster are 
aware bootstrapping is underway.

The concept involves extending kolla's dockerfiles and having them poll etcd to 
determine whether a bootstrap is in progress or complete [1].

I'll follow up by adding this to the spec.

Thanks,
Ryan

[1] - https://review.openstack.org/#/c/320744/

- Original Message -
From: "Kevin M Fox" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, May 23, 2016 11:37:33 AM
Subject: Re: [openstack-dev] [kubernetes]

+1 for using k8s to do work where possible.

-1 for trying to shoehorn a feature in so that k8s can deal with stuff its not 
ready to handle. We need to ensure Operators have everything they need in order 
to successfully operate their cloud.

The current upgrade stuff in k8s is focused around replacing one, usually 
stateless, thing for another. It never had Database Schema upgrades in mind.  
It is great to use for minor version bumps. It is insufficient for major 
OpenStack upgrades. If you follow the OpenStack release notes, they tend to be 
quite linear, in a workflow. K8s isn't designed for that. Hence the need for a 
tool outside of k8s to drive the creation/upgrading of Deployments and Jobs in 
the proper order.

Init containers also do not look like a good fit. As far as I can gather from 
the spec, they are intended to init something on a node when a pod is spawned. 
This is a very different thing from upgrading a shared database's schema. I 
don't believe they should be used for that.

I've upgraded many OpenStack clouds over the years. One of the things that has 
bit me from time to time is a failed schema update and having to tweak code and 
then rerun schema upgrades. This will continue to happen and needs to be 
covered. The Job's workflow as discussed in the spec allows an operator to do 
just that. Hiding it in an init container makes that much harder for Operators.

As an Op, we need the ability to tweak the workflow as needed and run/rerun 
only the pieces that we need.

Thanks,
Kevin

From: Ryan Hallisey [rhall...@redhat.com]
Sent: Sunday, May 22, 2016 12:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev]  [kolla][kolla-kubernetes][kubernetes]

Hi all,

At the Kolla meeting last week, I brought up some of the challenges around the 
bootstrapping
process in Kubernetes.  The main highlight revolved around how the 
bootstrapping process will
work.

Currently, in the kolla-kubernetes spec [1], the process for bootstrapping 
involves
outside orchestration running Kubernetes 'Jobs' that will handle the database 
initialization,
creating users, etc...  One of the flaws in this approach, is that 
kolla-kubernetes can't use
native Kubernetes upgrade tooling. Kubernetes does upgrades as a single action 
that scales
down running containers and replaces them with the upgraded containers. So 
instead of having
Kubernetes manage the upgrade, it would be guided by an external engine.  Not 
saying this is
a bad thing, but it does loosen the control Kubernetes would have over stack 
management.

Kubernetes does have some incoming new features that are a step in the right 
direction to
allow for kolla-kubernetes to make complete use of Kubernetes tooling like init 
containers [2].
There is also the introduction to wait.for conditions in the kubectl [3].

   kubectl get pod my-pod --wait --wait-for="pod-running"

Upgrades will be in the distant future for kolla-kubernetes, but I want to make 
sure the
community maintains an open mind about bootstrap/upgrades since there are 
potentially many
options that could come down the road.

I encourage everyone to add your input to the spec!

Thanks,
Ryan

[1] SPEC - https://review.openstack.org/#/c/304182/
[2] Init containers - https://github.com/kubernetes/kubernetes/pull/23567
[3] wait.for kubectl - https://github.com/kubernetes/kubernetes/issues/1899

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kuryr] Docker failed to add an existed network with GW interface already created

[Irena Berezovsky]

Hi Liping Mao,


On Thu, May 26, 2016 at 12:31 PM, Liping Mao (limao) 
wrote:

> Hi Vikas, Antoni and Kuryr team,
>
> When I use kuryr, I notice kuryr will failed to add an existed
> network with gateway interface already created by neutron[1][2].
>
> The bug is because kuryr will create a neutron port for gw
> port in ipam_request_address.
>
> I think kuryr should not do actual create neutron gw port at all.
> Because CNM module do not have concept map with Neutron vRouter.
> Till now, user have to use neutron api to attach GW port in
> private network with vRouter. So I think the Kuryr should not
> actually create GW port.
>
> I think it possible to define via kuryr configuration file if kuryr should
create or not gw port. Kuryr already does it for DHCP port.

> What do you think? Thanks for any comments.
>
>
> [1] https://bugs.launchpad.net/kuryr/+bug/1584286
> [2] https://review.openstack.org/#/c/319524/4
>
>
>
> Regards，
> Liping Mao
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [api] os-api-ref 0.2.0 released

[Sean Dague]

os-api-ref (the sphinx extension to support new api ref sites) 0.2.0 it out

This includes the first set of unit tests in the program using
sphinx-testing and bs4 modules to make sure we don't realize versions of
the extensions where the stanzas break in odd ways. It's very basic
coverage, but hopefully a pattern that can be extended over time (and
will be required for any new features).

It also includes a styling change that makes different methods different
colors - http://i.imgur.com/bncAhYj.png

And lastly, the docs are not being published online -
http://docs.openstack.org/developer/os-api-ref/. There is a basic
documentation for the stanzas there and how they are expected to be
used. Contributions welcomed in making those better.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kuryr][magnum]Installing kuryr for mutlinode openstack setup

[Eli Qiao]

Akshay's right,
tox -egenconfig does the neutron git repo clone, will someone clarify if 
it's normal?


.tox/genconfig/log/genconfig-1.log:+ pip install -U 
-egit+https://git.openstack.org/openstack/neutron#egg=neutron
.tox/genconfig/log/genconfig-1.log:Obtaining neutron from 
git+https://git.openstack.org/openstack/neutron#egg=neutron
.tox/genconfig/log/genconfig-1.log:  Cloning 
https://git.openstack.org/openstack/neutron to ./.tox/genconfig/src/neutron
.tox/genconfig/src/neutron/.git/config:url = 
https://git.openstack.org/openstack/neutron



On 2016年05月26日 19:06, Vikas Choudhary wrote:
As per my understanding, it should not be cloning neutron repo. 
Anyways PFA




-Vikas

On Thu, May 26, 2016 at 4:06 PM, Akshay Kumar Sanghai 
mailto:akshaykumarsang...@gmail.com>> 
wrote:


Hi Vikas,
Thanks for the command. I don't understand why the command clones
the neutron repo. Can i directly download kuryr.conf from
somewhere else? or tox does more than creating kuryr_sample.conf?

Thanks
Akshay

On Thu, May 26, 2016 at 9:08 AM, Vikas Choudhary
mailto:choudharyvika...@gmail.com>>
wrote:

Hi Akshay,

Sorry about that. You need to run "tox -e genconfig" . After
this inside kuryr/etc "kuryr.conf_sample" file will get
generated. Copy this file to /etc/kuryr/ after renaming to
kuryr.conf.

Documentation will be updated soon.

-Vikas
.

On Wed, May 25, 2016 at 8:44 PM, Akshay Kumar Sanghai
mailto:akshaykumarsang...@gmail.com>> wrote:

Hi,
Thanks Jaume and Antoni.
I tried the installation by git cloning the kuryr repo. I
did pip install -r requirements.txt. After that I did pip
install . . But it doesn't end successfully. There are no
config files in /etc/kuryr directory.
root@compute1:~/kuryr# pip install .
Unpacking /root/kuryr
  Running setup.py (path:/tmp/pip-4kbPa8-build/setup.py)
egg_info for package from file:///root/kuryr
[pbr] Processing SOURCES.txt
warning: LocalManifestMaker: standard file '-c' not found

[pbr] In git context, generating filelist from git
warning: no previously-included files matching '*.pyc'
found anywhere in distribution
  Requirement already satisfied (use --upgrade to
upgrade): kuryr==0.1.0.dev422 from file:///root/kuryr in
/usr/local/lib/python2.7/dist-packages
Requirement already satisfied (use --upgrade to upgrade):
pbr>=1.6 in /usr/lib/python2.7/dist-packages (from
kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
Babel>=2.3.4 in /usr/local/lib/python2.7/dist-packages
(from kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
Flask<1.0,>=0.10 in /usr/local/lib/python2.7/dist-packages
(from kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
jsonschema!=2.5.0,<3.0.0,>=2.0.0 in
/usr/lib/python2.7/dist-packages (from kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
netaddr!=0.7.16,>=0.7.12 in
/usr/lib/python2.7/dist-packages (from kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
oslo.concurrency>=3.5.0 in
/usr/local/lib/python2.7/dist-packages (from
kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
oslo.log>=1.14.0 in /usr/local/lib/python2.7/dist-packages
(from kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
oslo.serialization>=1.10.0 in
/usr/local/lib/python2.7/dist-packages (from
kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
oslo.utils>=3.5.0 in
/usr/local/lib/python2.7/dist-packages (from
kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
python-neutronclient>=4.2.0 in
/usr/local/lib/python2.7/dist-packages (from
kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
pyroute2>=0.3.10 in /usr/local/lib/python2.7/dist-packages
(from kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
os-client-config>=1.13.1 in
/usr/local/lib/python2.7/dist-packages (from
kuryr==0.1.0.dev422)
Requirement already satisfied (use --upgrade to upgrade):
neutron-lib>=0.1.0 in
/usr/local/lib/python2.7/dist-packages (from
k

Re: [openstack-dev] [ironic][neutron] bonding?

[Jim Rollenhagen]

On Tue, May 24, 2016 at 12:18:40PM -0700, Armando M. wrote:
> On 24 May 2016 at 04:51, Jim Rollenhagen  wrote:
> 
> > Hi,
> >
> > There's rumors floating around about Neutron having a bonding model in
> > the near future. Are there any solid plans for that?
> >
> 
> Who spreads these rumors :)?
> 
> To the best of my knowledge I have not seen any RFE proposed recently along
> these lines.

Thanks Armando. Long live portgroups :)

// jim

> 
> 
> > For context, as part of the multitenant networking work, ironic has a
> > portgroup concept proposed, where operators can configure bonding for
> > NICs in a baremetal machine. There are ML2 drivers that support this
> > model and will configure a bond.
> >
> > Some folks have concerns about landing this code if Neutron is going to
> > support bonding as a first-class citizen. So before we delay any
> > further, I'd like to find out if there's any truth to this, and what the
> > timeline for that might look like.
> >
> > Thanks!
> >
> > // jim
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] proposal about puppet versions testing coverage

[Ivan Berezovskiy]

>
> Greating folks,
>
> In a recent poll [1], we asked to our community to tell which version
> of Puppet they were running.
> The motivation is to make sure our Puppet OpenStack CI test the right
> things, that are really useful.
>
> Right now, we run unit test jobs on puppet on 3.3, 3.4, 3.6, 3.8, 4.0
> and latest (current is 4.5).
> We also have functional jobs (non-voting, in periodic pipeline), that
> run puppet 4.5. Those ones break very often because nobody (except
> me?) regularly checks puppet4 periodic jobs.
>
> So here's my proposal, feel fee to comment:
>
> * Reduce puppet versions testing to 3.6, 3.8, 4.5 and latest (keep the
> last one non-voting). It seems that 3.6 and 3.8 are widely used by our
> consumers (default in centos7 & ubuntu LTS), and 4.5 is the latest
> release in the 4.x series.
> * Move functional puppet4 jobs from experimental to check pipeline
> (non-voting). They'll bring very useful feedback. It will add 6 more
> jobs in the check queue, but since we will drop 2 unit tests jobs (in
> both check & gate pipelines), it will add 2 jobs at total (in term of
> time, unit tests jobs take 15 min and functional jobs take ~30 min) so
> the impact of node consumption is IMHO not relevant here.
>
> [1]
> https://docs.google.com/forms/d/1rJZxP52LyrFhFTy8w4J_5tnA7-A5g32YVhHSaCd7-F8/edit#responses


+1

I am also agree with Matt and Denis that we should work on making
functional puppet4 jobs stable and then enable them in voting mode.



-- 
Thanks, Ivan Berezovskiy
MOS Puppet Team Lead
at Mirantis 

slack: iberezovskiy
skype: bouhforever
phone: + 7-960-343-42-46
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][all] oslo.log `verbose` and $your project

[Ihar Hrachyshka]

Neutron patch is at: https://review.openstack.org/#/c/321481/

It could be worth reporting a bug and add all identified components to it.

> On 26 May 2016, at 12:39, Alexis Lee  wrote:
> 
> I see a few reviews still open:
> 
> https://review.openstack.org/#/c/315868 - designate
> https://review.openstack.org/#/c/315655 - devstack
> https://review.openstack.org/#/c/317579 - glance
> https://review.openstack.org/#/c/317556 - glance_store
> 
> Please could these get some attention?
> 
> From browsing codesearch.openstack.org, I also see possible hits in:
> 
> * cerberus
> * charm-ceilometer
> * charm-cinder
> * charm-glance
> * charm-heat ?
> * charm-keystone
> * charm-neutron-api
> * charm-neutron-gateway
> * charm-neutron-openvswitch
> * charm-nova-cloud-controller
> * charm-nova-compute
> * charm-openstack-dashboard
> * cloudpulse
> * compass-adapters
> * cookbook-openstack-database
> * cue
> * fuel-agent
> * fuel-plugin-dbaas-trove
> * fuel-plugin-ironic
> * fuel-qa
> * kolla
> * neutron
> * openstack-chef
> * openstack-manuals
> * osops-example-configs
> * osops-tools-contrib
> * packstack
> * puppet-glance
> * rack
> * sahara
> * salt-formula-ceilometer
> * salt-formula-cinder
> * salt-formula-glance
> * salt-formula-neutron
> * salt-formula-nova
> * shaker
> * solar-resources
> * tacker
> * tripleo-image-elements
> * trove
> * zaqar
> * and many more!
> * that's only half of the list
> * I got bored
> 
> Please check your projects!
> 
> http://codesearch.openstack.org/?q=INFO%20instead%20of%20default%20WARNING%20level
> http://codesearch.openstack.org/?q=verbose
> 
> 
> Alexis (lxsli)
> -- 
> Nova developer, Hewlett-Packard Limited.
> Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
> Registered Number: 00690597 England
> VAT number: GB 314 1496 79
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kuryr][magnum]Installing kuryr for mutlinode openstack setup

[Vikas Choudhary]

As per my understanding, it should not be cloning neutron repo. Anyways PFA



-Vikas

On Thu, May 26, 2016 at 4:06 PM, Akshay Kumar Sanghai <
akshaykumarsang...@gmail.com> wrote:

> Hi Vikas,
> Thanks for the command. I don't understand why the command clones the
> neutron repo. Can i directly download kuryr.conf from somewhere else? or
> tox does more than creating kuryr_sample.conf?
>
> Thanks
> Akshay
>
> On Thu, May 26, 2016 at 9:08 AM, Vikas Choudhary <
> choudharyvika...@gmail.com> wrote:
>
>> Hi Akshay,
>>
>> Sorry about that. You need to run "tox -e genconfig" . After this inside
>> kuryr/etc "kuryr.conf_sample" file will get generated. Copy this file to
>> /etc/kuryr/ after renaming to kuryr.conf.
>>
>> Documentation will be updated soon.
>>
>> -Vikas
>> .
>>
>> On Wed, May 25, 2016 at 8:44 PM, Akshay Kumar Sanghai <
>> akshaykumarsang...@gmail.com> wrote:
>>
>>> Hi,
>>> Thanks Jaume and Antoni.
>>> I tried the installation by git cloning the kuryr repo. I did pip
>>> install -r requirements.txt. After that I did pip install . . But it
>>> doesn't end successfully. There are no config files in /etc/kuryr
>>> directory.
>>> root@compute1:~/kuryr# pip install .
>>> Unpacking /root/kuryr
>>>   Running setup.py (path:/tmp/pip-4kbPa8-build/setup.py) egg_info for
>>> package from file:///root/kuryr
>>> [pbr] Processing SOURCES.txt
>>> warning: LocalManifestMaker: standard file '-c' not found
>>>
>>> [pbr] In git context, generating filelist from git
>>> warning: no previously-included files matching '*.pyc' found
>>> anywhere in distribution
>>>   Requirement already satisfied (use --upgrade to upgrade):
>>> kuryr==0.1.0.dev422 from file:///root/kuryr in
>>> /usr/local/lib/python2.7/dist-packages
>>> Requirement already satisfied (use --upgrade to upgrade): pbr>=1.6 in
>>> /usr/lib/python2.7/dist-packages (from kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade): Babel>=2.3.4
>>> in /usr/local/lib/python2.7/dist-packages (from kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> Flask<1.0,>=0.10 in /usr/local/lib/python2.7/dist-packages (from
>>> kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> jsonschema!=2.5.0,<3.0.0,>=2.0.0 in /usr/lib/python2.7/dist-packages (from
>>> kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> netaddr!=0.7.16,>=0.7.12 in /usr/lib/python2.7/dist-packages (from
>>> kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> oslo.concurrency>=3.5.0 in /usr/local/lib/python2.7/dist-packages (from
>>> kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> oslo.log>=1.14.0 in /usr/local/lib/python2.7/dist-packages (from
>>> kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> oslo.serialization>=1.10.0 in /usr/local/lib/python2.7/dist-packages (from
>>> kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> oslo.utils>=3.5.0 in /usr/local/lib/python2.7/dist-packages (from
>>> kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> python-neutronclient>=4.2.0 in /usr/local/lib/python2.7/dist-packages (from
>>> kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> pyroute2>=0.3.10 in /usr/local/lib/python2.7/dist-packages (from
>>> kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> os-client-config>=1.13.1 in /usr/local/lib/python2.7/dist-packages (from
>>> kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> neutron-lib>=0.1.0 in /usr/local/lib/python2.7/dist-packages (from
>>> kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade): Werkzeug>=0.7
>>> in /usr/local/lib/python2.7/dist-packages (from
>>> Flask<1.0,>=0.10->kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade): Jinja2>=2.4 in
>>> /usr/lib/python2.7/dist-packages (from
>>> Flask<1.0,>=0.10->kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade):
>>> itsdangerous>=0.21 in /usr/local/lib/python2.7/dist-packages (from
>>> Flask<1.0,>=0.10->kuryr==0.1.0.dev422)
>>> Requirement already satisfied (use --upgrade to upgrade): markupsafe in
>>> /usr/lib/python2.7/dist-packages (from
>>> Jinja2>=2.4->Flask<1.0,>=0.10->kuryr==0.1.0.dev422)
>>> Cleaning up...
>>> root@compute1:~/kuryr#
>>>
>>>
>>> Thanks
>>> Akshay
>>>
>>>
>>>
>>>
>>> On Wed, May 25, 2016 at 4:24 PM, Antoni Segura Puimedon <
>>> toni+openstac...@midokura.com> wrote:
>>>


 On Wed, May 25, 2016 at 11:20 AM, Jaume Devesa 
 wrote:

> Hello Akshay,
>
> responses inline:
>
> On Wed, 25 May 2016 10:48, Akshay Kumar Sanghai wrote:
> > Hi,
> > I have a 4 node openstack setup (1 controller, 1 network, 2 compute
> nodes).
> > I want t

[openstack-dev] [Fuel] [QA] package-testrail-reporter

[Kirill Rozin]

I would like to inform about movement testrail repoter from
fuel-qa/fuelweb_test/testrail/ to fuel-qa/reporter

Blueprint is
https://blueprints.launchpad.net/fuel/+spec/package-testrail-reporter

Please, take into account that we still support old way of running several
report scripts. We would like to move reporter to separatly repo in future
and we just go ahead step by step. That is a step #1.
As soon as reporter will be moved to separately repo then need to fix CI
env and other places where those reports are going to used.

Thanks and best regards
Kirill Rozin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Log spool in the context

[Alexis Lee]

Doug Hellmann said on Wed, May 25, 2016 at 11:56:55AM -0400:
> But that leaves it up to the application or library author to have to
> make that call for every log message, which makes logging more
> complicated.

Almost all messages generated while processing a request should only go
to the request logger. If a message is obviously important outside the
context of that single request, it can also/instead be logged to the
normal logger, but this should very much be the exception to the rule.

> The point of the spooling logger is to dump everything about a request
> when the request fails, right? And we want the "normal" behavior the
> rest of the time? It seems like we should look at a way to make that
> happen without a lot of impact on application logic.
> 
> It's OK to have the same message go to both loggers, right? Could we
> have a wrapper class that takes a normal logger and a spooling logger
> and sends its messages to both?

No, definitely not. Log records associated with successful requests
should not be emitted at all. This will make the practice of running at
DEBUG more bearable. IE the goal is to reduce logging volume, not double
it!

> Even better would be to find a way to configure the logger hierarchy
> so that is completely transparent, so that messages going to the
> SpoolLogger are propagated to the normal logger based on their log
> level.

The logger a message should go to is orthogonal to its level. If a
requested resource, which should exist, does not - this might be logged
at ERROR, a very high level. It doesn't need to go to the normal log
though because it's strictly to do with that request. So if we duplicate
all high level logs to the normal logger, we'll see unnecessary records
in the normal log.

If someone really wanted these duplicates, they could add their normal
handler to the 'spool' logger with a high loglevel.


Alexis (lxsli)
-- 
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB 314 1496 79

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][all] oslo.log `verbose` and $your project

[Alexis Lee]

I see a few reviews still open:

https://review.openstack.org/#/c/315868 - designate
https://review.openstack.org/#/c/315655 - devstack
https://review.openstack.org/#/c/317579 - glance
https://review.openstack.org/#/c/317556 - glance_store

Please could these get some attention?

>From browsing codesearch.openstack.org, I also see possible hits in:

* cerberus
* charm-ceilometer
* charm-cinder
* charm-glance
* charm-heat ?
* charm-keystone
* charm-neutron-api
* charm-neutron-gateway
* charm-neutron-openvswitch
* charm-nova-cloud-controller
* charm-nova-compute
* charm-openstack-dashboard
* cloudpulse
* compass-adapters
* cookbook-openstack-database
* cue
* fuel-agent
* fuel-plugin-dbaas-trove
* fuel-plugin-ironic
* fuel-qa
* kolla
* neutron
* openstack-chef
* openstack-manuals
* osops-example-configs
* osops-tools-contrib
* packstack
* puppet-glance
* rack
* sahara
* salt-formula-ceilometer
* salt-formula-cinder
* salt-formula-glance
* salt-formula-neutron
* salt-formula-nova
* shaker
* solar-resources
* tacker
* tripleo-image-elements
* trove
* zaqar
* and many more!
* that's only half of the list
* I got bored

Please check your projects!

http://codesearch.openstack.org/?q=INFO%20instead%20of%20default%20WARNING%20level
http://codesearch.openstack.org/?q=verbose


Alexis (lxsli)
-- 
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB 314 1496 79

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kuryr][magnum]Installing kuryr for mutlinode openstack setup

[Akshay Kumar Sanghai]

Hi Vikas,
Thanks for the command. I don't understand why the command clones the
neutron repo. Can i directly download kuryr.conf from somewhere else? or
tox does more than creating kuryr_sample.conf?

Thanks
Akshay

On Thu, May 26, 2016 at 9:08 AM, Vikas Choudhary  wrote:

> Hi Akshay,
>
> Sorry about that. You need to run "tox -e genconfig" . After this inside
> kuryr/etc "kuryr.conf_sample" file will get generated. Copy this file to
> /etc/kuryr/ after renaming to kuryr.conf.
>
> Documentation will be updated soon.
>
> -Vikas
> .
>
> On Wed, May 25, 2016 at 8:44 PM, Akshay Kumar Sanghai <
> akshaykumarsang...@gmail.com> wrote:
>
>> Hi,
>> Thanks Jaume and Antoni.
>> I tried the installation by git cloning the kuryr repo. I did pip install
>> -r requirements.txt. After that I did pip install . . But it doesn't end
>> successfully. There are no config files in /etc/kuryr directory.
>> root@compute1:~/kuryr# pip install .
>> Unpacking /root/kuryr
>>   Running setup.py (path:/tmp/pip-4kbPa8-build/setup.py) egg_info for
>> package from file:///root/kuryr
>> [pbr] Processing SOURCES.txt
>> warning: LocalManifestMaker: standard file '-c' not found
>>
>> [pbr] In git context, generating filelist from git
>> warning: no previously-included files matching '*.pyc' found anywhere
>> in distribution
>>   Requirement already satisfied (use --upgrade to upgrade):
>> kuryr==0.1.0.dev422 from file:///root/kuryr in
>> /usr/local/lib/python2.7/dist-packages
>> Requirement already satisfied (use --upgrade to upgrade): pbr>=1.6 in
>> /usr/lib/python2.7/dist-packages (from kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade): Babel>=2.3.4 in
>> /usr/local/lib/python2.7/dist-packages (from kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> Flask<1.0,>=0.10 in /usr/local/lib/python2.7/dist-packages (from
>> kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> jsonschema!=2.5.0,<3.0.0,>=2.0.0 in /usr/lib/python2.7/dist-packages (from
>> kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> netaddr!=0.7.16,>=0.7.12 in /usr/lib/python2.7/dist-packages (from
>> kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> oslo.concurrency>=3.5.0 in /usr/local/lib/python2.7/dist-packages (from
>> kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> oslo.log>=1.14.0 in /usr/local/lib/python2.7/dist-packages (from
>> kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> oslo.serialization>=1.10.0 in /usr/local/lib/python2.7/dist-packages (from
>> kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> oslo.utils>=3.5.0 in /usr/local/lib/python2.7/dist-packages (from
>> kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> python-neutronclient>=4.2.0 in /usr/local/lib/python2.7/dist-packages (from
>> kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> pyroute2>=0.3.10 in /usr/local/lib/python2.7/dist-packages (from
>> kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> os-client-config>=1.13.1 in /usr/local/lib/python2.7/dist-packages (from
>> kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> neutron-lib>=0.1.0 in /usr/local/lib/python2.7/dist-packages (from
>> kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade): Werkzeug>=0.7
>> in /usr/local/lib/python2.7/dist-packages (from
>> Flask<1.0,>=0.10->kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade): Jinja2>=2.4 in
>> /usr/lib/python2.7/dist-packages (from
>> Flask<1.0,>=0.10->kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade):
>> itsdangerous>=0.21 in /usr/local/lib/python2.7/dist-packages (from
>> Flask<1.0,>=0.10->kuryr==0.1.0.dev422)
>> Requirement already satisfied (use --upgrade to upgrade): markupsafe in
>> /usr/lib/python2.7/dist-packages (from
>> Jinja2>=2.4->Flask<1.0,>=0.10->kuryr==0.1.0.dev422)
>> Cleaning up...
>> root@compute1:~/kuryr#
>>
>>
>> Thanks
>> Akshay
>>
>>
>>
>>
>> On Wed, May 25, 2016 at 4:24 PM, Antoni Segura Puimedon <
>> toni+openstac...@midokura.com> wrote:
>>
>>>
>>>
>>> On Wed, May 25, 2016 at 11:20 AM, Jaume Devesa 
>>> wrote:
>>>
 Hello Akshay,

 responses inline:

 On Wed, 25 May 2016 10:48, Akshay Kumar Sanghai wrote:
 > Hi,
 > I have a 4 node openstack setup (1 controller, 1 network, 2 compute
 nodes).
 > I want to install kuryr in liberty version. I cannot find a package in
 > ubuntu repo.

 There is not yet official version of Kuryr. You'll need to install
 using the
 current master branch of the repo[1] (by cloning it, install
 dependencies and
 `python setup.py install`

>>>
>>>  Or you could run it dockerized. R

Re: [openstack-dev] [puppet] proposal about puppet versions testing coverage

[Denis Egorenko]

>
> * Reduce puppet versions testing to 3.6, 3.8, 4.5 and latest (keep the
> last one non-voting). It seems that 3.6 and 3.8 are widely used by our
> consumers (default in centos7 & ubuntu LTS), and 4.5 is the latest
> release in the 4.x series.


+1 from me too

 * Move functional puppet4 jobs from experimental to check pipeline
> (non-voting). They'll bring very useful feedback. It will add 6 more
> jobs in the check queue, but since we will drop 2 unit tests jobs (in
> both check & gate pipelines), it will add 2 jobs at total (in term of
> time, unit tests jobs take 15 min and functional jobs take ~30 min) so
> the impact of node consumption is IMHO not relevant here.


it's a good start for using puppet4. For first time i agree, that should be
non-voting.
I think our puppet team can also start work fpr making our modules be
compatible
with puppet4. Thank you for bringing up this!

2016-05-25 22:40 GMT+03:00 Matt Fischer :

> On Wed, May 25, 2016 at 1:09 PM, Emilien Macchi 
> wrote:
>
>> Greating folks,
>>
>> In a recent poll [1], we asked to our community to tell which version
>> of Puppet they were running.
>> The motivation is to make sure our Puppet OpenStack CI test the right
>> things, that are really useful.
>>
>> Right now, we run unit test jobs on puppet on 3.3, 3.4, 3.6, 3.8, 4.0
>> and latest (current is 4.5).
>> We also have functional jobs (non-voting, in periodic pipeline), that
>> run puppet 4.5. Those ones break very often because nobody (except
>> me?) regularly checks puppet4 periodic jobs.
>>
>> So here's my proposal, feel fee to comment:
>>
>> * Reduce puppet versions testing to 3.6, 3.8, 4.5 and latest (keep the
>> last one non-voting). It seems that 3.6 and 3.8 are widely used by our
>> consumers (default in centos7 & ubuntu LTS), and 4.5 is the latest
>> release in the 4.x series.
>>
>
>
> +1
>
>
>
>> * Move functional puppet4 jobs from experimental to check pipeline
>> (non-voting). They'll bring very useful feedback. It will add 6 more
>> jobs in the check queue, but since we will drop 2 unit tests jobs (in
>> both check & gate pipelines), it will add 2 jobs at total (in term of
>> time, unit tests jobs take 15 min and functional jobs take ~30 min) so
>> the impact of node consumption is IMHO not relevant here.
>>
>
>
> What's the plan for making Puppet4 jobs voting? I think this is a good
> start but we should more towards voting jobs I think.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards,
Egorenko Denis,
Senior Deployment Engineer
Mirantis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Zaqar messages standardization

[Thomas Herve]

On Thu, May 26, 2016 at 11:48 AM, Jiri Tomasek  wrote:
> On 05/25/2016 08:08 PM, Thomas Herve wrote:

>> Sorry for not responding earlier, but I have some inputs. In Heat we
>> publish events on Zaqar queue, and we defined this format:
>>
>>  {
>>  'timestamp': $timestamp,
>>  'version': '0.1',
>>  'type': 'os.heat.event',
>>  'id': $uuid,
>>  'payload': {
>>  'XXX
>>  }
>>  }
>
>
> Thanks, it totally makes sense. So when I convert my example to your usage
> it looks like this:
>
> {
> body: {
> 'timestamp': $timestamp,
> 'type': 'tripleo.validations.v1.run_validation',
> 'id': $uuid,
> 'payload': {
> execution_id: '123123123',
> validation_id: '123321'
> ...
>  }
> }
> }
>
> I am not sure whether to separate the version from type as it would become
> complicated to reconstruct the workflow name (at least for tripleo
> workflows).
> The most important is the 'type' as that is the key which we'd like to use
> on client to identify what action to take.

Looks great to me, thanks!

-- 
Thomas

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Intel NFV CI failing all shelve/unshelve tests

[Znoinski, Waldemar]

Hi all,

I'll disable the shelve/unshelve failing tests in Intel NFV CI for the time 
being till we have clarity on the problem.
Stephen Finucane will be working on that in next week or so.

 >-Original Message-
 >From: Chris Friesen [mailto:chris.frie...@windriver.com]
 >Sent: Wednesday, May 25, 2016 5:40 PM
 >To: openstack-dev@lists.openstack.org
 >Subject: Re: [openstack-dev] [nova] Intel NFV CI failing all shelve/unshelve
 >tests
 >
 >On 05/22/2016 05:41 PM, Jay Pipes wrote:
 >> Hello Novaites,
 >>
 >> I've noticed that the Intel NFV CI has been failing all test runs for
 >> quite some time (at least a few days), always failing the same tests
 >> around shelve/unshelve operations.
 >
 >
 >
 >> I looked through the conductor and compute logs to see if I could find
 >> any possible reasons for the errors and found a number of the
 >> following errors in the compute logs:
 >>
 >> 2016-05-22 22:18:59.403 8145 ERROR nova.compute.manager [instance:
 >> cae6fd47-0968-4922-a03e-3f2872e4eb52] Traceback (most recent call last):
 >> 2016-05-22 22:18:59.403 8145 ERROR nova.compute.manager [instance:
 >> cae6fd47-0968-4922-a03e-3f2872e4eb52]   File
 >> "/opt/stack/new/nova/nova/compute/manager.py", line 4230, in
 >> _unshelve_instance
 >> 2016-05-22 22:18:59.403 8145 ERROR nova.compute.manager [instance:
 >> cae6fd47-0968-4922-a03e-3f2872e4eb52] with rt.instance_claim(context,
 >> instance, limits):
 >
 >
 >
 >> 2016-05-22 22:18:59.403 8145 ERROR nova.compute.manager [instance:
 >> cae6fd47-0968-4922-a03e-3f2872e4eb52]
 >newcell.unpin_cpus(pinned_cpus)
 >> 2016-05-22 22:18:59.403 8145 ERROR nova.compute.manager [instance:
 >> cae6fd47-0968-4922-a03e-3f2872e4eb52]   File
 >> "/opt/stack/new/nova/nova/objects/numa.py", line 94, in unpin_cpus
 >> 2016-05-22 22:18:59.403 8145 ERROR nova.compute.manager [instance:
 >> cae6fd47-0968-4922-a03e-3f2872e4eb52] pinned=list(self.pinned_cpus))
 >> 2016-05-22 22:18:59.403 8145 ERROR nova.compute.manager [instance:
 >> cae6fd47-0968-4922-a03e-3f2872e4eb52] CPUPinningInvalid: Cannot
 >> pin/unpin cpus [6] from the following pinned set [0, 2, 4]
 >>
 >> on or around the time of the failures in Tempest.
 >>
 >> Perhaps tomorrow morning we can look into handling the above exception
 >> properly from the compute manager, since clearly we shouldn't be
 >> allowing CPUPinningInvalid to be raised in the resource tracker's
 >_update_usage() call
 >
 >First, it seems wrong to me that an _unshelve_instance() call would result in
 >unpinning any CPUs.  If the instance was using pinned CPUs then I would
 >expect the CPUs to be unpinned when doing the "shelve" operation.  When
 >we do an instance claim as part of the "unshelve" operation we should be
 >pinning CPUs, not unpinning them.
 >
 >Second, the reason why CPUPinningInvalid gets raised in _update_usage() is
 >that it has discovered an inconsistency in its view of resources.  In this 
 >case,
 >it's trying to unpin CPU 6 from a set of pinned cpus that doesn't include CPU
 >6.  I think this is a valid concern and should result in an error log.  
 >Whether it
 >should cause the unshelve operation to fail is a separate question, but it's
 >definitely a symptom that something is wrong with resource tracking on this
 >compute node.
 >
 >Chris
 >
 >
 >__
 >
 >OpenStack Development Mailing List (not for usage questions)
 >Unsubscribe: OpenStack-dev-
 >requ...@lists.openstack.org?subject:unsubscribe
 >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Zaqar messages standardization

[Jiri Tomasek]

On 05/25/2016 08:08 PM, Thomas Herve wrote:

On Fri, May 20, 2016 at 5:52 PM, Jiri Tomasek  wrote:

Hey all,

I've been recently working on getting the TripleO UI integrated with Zaqar,
so it can receive a messages from Mistral workflows and act upon them
without having to do various polling hacks.

Since there is currently quite a large amount of new TripleO workflows
comming to tripleo-common, we need to standardize this communication so
clients can consume the messages consistently.

I'll try to outline the requirements as I see it to start the discussion.

Zaqar queues:
To listen to the Zaqar messages it requires the client to connect to Zaqar
WebSocket, send authenticate message and subscribe to queue(s) which it
wants to listen to. The currently pending workflow patches which send Zaqar
messages [1, 2] expect that the queue is created by client and name is
passed as an input to the workflow [3].

 From the client perspective, it would IMHO be better if all workflows sent
messages to the same queue and provide means to identify itself by carrying
workflow name and execution id. The reason is, that if client creates a
queue and triggers the workflow and then disconnects from the Socket (user
refreshes browser), then it does not know what queues it previously created
and which it should listen to. If there is single 'tripleo' queue, then all
clients always know that it is where it will get all the messages from.

Messages identification and content:
The client should be able to identify message by it's name so it can act
upon it. The name should probably be relevant to the action or workflow it
reports on.

{
   body: {
 name: 'tripleo.validations.v1.run_validation,
 execution_id: '123123123'
 data: {}
   }
}

Other parts of the message are optional but it would be good to provide
information relevant to the message's purpose, so the client can update
relevant state and does not have to do any additional API calls. So e.g. in
case of running the validation a message includes validation id.

Hi,

Sorry for not responding earlier, but I have some inputs. In Heat we
publish events on Zaqar queue, and we defined this format:

 {
 'timestamp': $timestamp,
 'version': '0.1',
 'type': 'os.heat.event',
 'id': $uuid,
 'payload': {
 'XXX
 }
 }


Thanks, it totally makes sense. So when I convert my example to your 
usage it looks like this:


{
body: {
'timestamp': $timestamp,
'type': 'tripleo.validations.v1.run_validation',
'id': $uuid,
'payload': {
execution_id: '123123123',
validation_id: '123321'
...
 }
}
}

I am not sure whether to separate the version from type as it would 
become complicated to reconstruct the workflow name (at least for 
tripleo workflows).
The most important is the 'type' as that is the key which we'd like to 
use on client to identify what action to take.




I don't think we have strong requirements on that, and we can
certainly make some tweaks. If we can converge towards something
simimar that'd be great.

Thanks,



Jirka

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [gate] [nova] live migration, libvirt 1.3, and the gate

[Kashyap Chamarthy]

On Wed, May 25, 2016 at 05:42:04PM +0200, Kashyap Chamarthy wrote:

[...]

> So, in short, the central issue seems to be this: the custom 'gate64'
> model is not being trasnalted by libvirt into a model that QEMU can
> recognize.

An update:

Upstream libvirt points out that this turns to be regression, and
bisected it to commit (in libvirt Git): 1.2.9-31-g445a09b -- "qemu:
Don't compare CPU against host for TCG".

So, I expect there's going to be fix pretty soon upstream libvirt.

> I could reproduce it with upstream libvirt
> (libvirt-1.3.4-2.fc25.x86_64), and filed this bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1339680 -- libvirt CPU
> driver fails to translate a custom CPU model into something that
> QEMU recognizes

[...]

-- 
/kashyap

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kuryr] Docker failed to add an existed network with GW interface already created

[Liping Mao (limao)]

Hi Vikas, Antoni and Kuryr team,

When I use kuryr, I notice kuryr will failed to add an existed
network with gateway interface already created by neutron[1][2].

The bug is because kuryr will create a neutron port for gw
port in ipam_request_address.

I think kuryr should not do actual create neutron gw port at all.
Because CNM module do not have concept map with Neutron vRouter.
Till now, user have to use neutron api to attach GW port in
private network with vRouter. So I think the Kuryr should not
actually create GW port.

What do you think? Thanks for any comments.


[1] https://bugs.launchpad.net/kuryr/+bug/1584286
[2] https://review.openstack.org/#/c/319524/4



Regards，
Liping Mao

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] New Core Reviewer (sent on behalf of Steve Martinelli)

[Henry Nash]

Congratulations - thanks for your continued commitment to OpenStack and 
keystone.

Henry

> On 25 May 2016, at 23:58, Rodrigo Duarte  wrote:
> 
> Thank you all, it's a privilege to be part of a team from where I've learned 
> so much. =)
> 
>> On Wed, May 25, 2016 at 1:05 PM, Brad Topol  wrote:
>> CONGRATULATIONS Rodrigo!!! Very well deserved!!!
>> 
>> --Brad
>> 
>> 
>> Brad Topol, Ph.D.
>> IBM Distinguished Engineer
>> OpenStack
>> (919) 543-0646
>> Internet: bto...@us.ibm.com
>> Assistant: Kendra Witherspoon (919) 254-0680
>> 
>> Lance Bragstad ---05/25/2016 09:09:55 AM---Congratulations 
>> Rodrigo! Thank you for all the continued and consistent reviews.
>> 
>> From: Lance Bragstad 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> Date: 05/25/2016 09:09 AM
>> Subject: Re: [openstack-dev] [keystone] New Core Reviewer (sent on behalf of 
>> Steve Martinelli)
>> 
>> 
>> 
>> 
>> Congratulations Rodrigo!
>> 
>> Thank you for all the continued and consistent reviews.
>> 
>> On Tue, May 24, 2016 at 1:28 PM, Morgan Fainberg  
>> wrote:
>> I want to welcome Rodrigo Duarte (rodrigods) to the keystone core team. 
>> Rodrigo has been a consistent contributor to keystone and has been 
>> instrumental in the federation implementations. Over the last cycle he has 
>> shown an understanding of the code base and contributed quality reviews.
>> 
>> I am super happy (as proxy for Steve) to welcome Rodrigo to the Keystone 
>> Core team.
>> 
>> Cheers,
>> --Morgan
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Rodrigo Duarte Sousa
> Senior Quality Engineer @ Red Hat
> MSc in Computer Science
> http://rodrigods.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev