Re: [openstack-dev] [tc][masakari] new project teams application for Masakari

[Sam P]

Hi Dims. Thanks, done.

Hi Tim,

Thanks for the question.
In OpenStack HA community, we discussed about converged upstream
solution for 3 cycles now [1][2]. Adam Spiers and I present our findings and
proposal in Boston summit [3]. Comparison with other F/OSS solutions are
in [4] and, as the HA community we presented our unified architecture.
Our unified solution for compute node failure scenario is in [5],
where Masakari is a key component of the architecture. For other
failure scenarios such as, process failure or instance failure, only
Masakari can
recover instances.  From all the discussions I had with community
members so far,
I  think Masakari is the right solution to address VMs HA.
Or otherwise, anyone is welcome to raise their concerns now.
I will be happy to discuss them.

[1] https://etherpad.openstack.org/p/newton-instance-ha
[2] 
https://review.openstack.org/#/q/project:openstack/openstack-resource-agents-specs
[3] 
https://www.openstack.org/videos/boston-2017/high-availability-for-instances-moving-to-a-converged-upstream-solution
[4] 
https://aspiers.github.io/openstack-summit-2017-boston-compute-ha/#/comparison
[5] 
https://aspiers.github.io/openstack-summit-2017-boston-compute-ha/#/grand-unified-architecture




--- Regards,
Sampath



On Sat, Sep 2, 2017 at 3:30 AM, Tim Bell  wrote:
> Great to see efforts for this use case.
>
> Is there community convergence that Masakari is the solution to address VMs 
> high availability?
>
> Tim
>
> -Original Message-
> From: Sam P 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: Friday, 1 September 2017 at 19:27
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Subject: [openstack-dev] [tc][masakari] new project teams application for 
>   Masakari
>
> Hi All,
>
> I have just proposed inclusion of Masakari[1] (Instances High Availability
> Service) into list of official OpenStack projects in [2]. Regarding this
> proposal, I would like to ask OpenStack community for what else can be 
> improved
> in the project to meet all the necessary requirements.
>
> And I would like use this thread to extend the discussion about project
> masakari. It would be great if you can post your comments/questions in 
> [2] or in
> this thread. I would be happy to discuss and answer to your questions.
>
> I will be at PTG in Denver from 9/12 (Tuesday) to 9/14(Thursday). Other 
> Masakari
> team members also will be there at PTG. We are happy to discuss anything
> regarding to Masakari in PTG.
> Please contact us via freenode IRC @ #openstack-masakari, or 
> openstack-dev ML
> with prefix [masakari].
>
> Thank you.
>
> [1] https://wiki.openstack.org/wiki/Masakari
> [2] https://review.openstack.org/#/c/500118/
>
> --- Regards,
> Sampath
>
> __
> 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] [all] [oslo] schedule for Denver PTG is ready !

[Lance Bragstad]

Thanks for the schedule! I should be somewhat available Monday afternoon
for the policy deprecation discussion. The only conflict that might come
up for me is with the Baremetal/VM group [0]. Keystone has a few topics
to iron out there, but I'm not exactly sure when that group plans to
talk about those things. Also, I proposed another oslo spec detailing
some additional policy work [1]. Let me know if you have thoughts, or
would like to discuss it in Denver.

[0] https://etherpad.openstack.org/p/keystone-queens-ptg
[1] https://review.openstack.org/#/c/500207/

On 08/28/2017 09:44 PM, ChangBo Guo wrote:
> sure, will adjust the schedule
>
> 2017-08-29 2:24 GMT+08:00 Doug Hellmann  >:
>
> Excerpts from ChangBo Guo's message of 2017-08-28 23:14:05 +0800:
> > Please check  for the draft in [1], we can adjust if you have conflicts
> > with other discussions.
> >
> > We have specific cross projects coding event  in the Tuesday
> afternoon, for
> > more details please
> > check [2] and [3],  please join us if you're free from 1:00 PM
> to 3: PM on
> > Tuesday.
> >
> > [1] https://etherpad.openstack.org/p/oslo-ptg-queens
> 
> > [2]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2017-August/121345.html
> 
> 
> > [3] https://etherpad.openstack.org/p/oslo-queens-tasks
> 
> >
>
> I think we can drop the discussion of retiring oslosphinx from the
> schedule. We had no objections, and the way forward is clear (see the
> other thread [4] for details).
>
> Doug
>
> [4]
> http://lists.openstack.org/pipermail/openstack-dev/2017-August/121564.html
> 
> 
>
> __
> 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
> 
>
>
>
>
> -- 
> ChangBo Guo(gcb)
>
>
> __
> 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



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

[openstack-dev] Developer ML Digest August 26- September 1

[Kendall Nelson]

Hello Everyone!

HTML Version:
https://www.openstack.org/blog/2017/09/openstack-developer-mailing-list-digest-august-26th-september-1st/

Succesbot Says!

   -

   ttx: Pike is released! [21]
   -

   ttx: Release automation made Pike release process the smoothest ever [22]


PTG Planning

   -

   Monasca (virtual)[1]
   -

   Vitrage(virtual)[2]
   -

   General Info & Price Hike[3]
   -

  Price Goes up to $150 USD
  -

  Happy Hour from 5-6 on Tuesday
  -

  Event Feedback during Lunch on Thursday
  -

   Queens Goal Tempest Plugin Split [4]
   -

   Denver City Guide [5]
   -

  Please add to and peruse
  -

   ETSI NFV workshop[6][7]


Summaries

   -

   TC Update [8]
   -

   Placement/Resource Providers Update 34 [9]


Updates

   -

   Pike is official! [10]
   -

   Outreachy Call for Mentors and Sponsors! [11]
   -

  More info here[12]
  -

  Next round runs December 5th to March 5th
  -

   Libraries published to pypi with .X.Z versions[13]
   -

  During Kilo when the neutron vendor decomposition happened, the
  release version was set to 2015.1.0 for basically all of the networking
  projects
  -

  Main issue is that networking-hyperv == 2015.1.0 is currently on Pypi
  and whenever someone upgrades through pip, it ‘upgrades’ to 2015.1.0
  because its considered the latest version
  -

  Should that version be unpublished?
  -

  Three options[14]
  -

 Unpublish- simplest, but goes against policy of pypi never
 unpublishing
 -

+1 from tonyb, made a rough list of others to unpublish that
need to be confirmed with PTL’s before passing to infra to
unpublish[15]
-

 Rename- a bunch of work for downstreams, but cleaner than
 unpublishing
 -

 Reversion- Start new versions at 3000 or something, but very hacky
 and ugly
 -

  dhellman, ttx, and fungi think that deleting it from pypi is the
  simplest route though not the typically recommended way of handling things
  -

   Removing Screen from devstack-RSN[16]
   -

  Work to make devstack only have a single execution mode- same between
  automated QA & local- is almost done!
  -

  Want to merge before PTG
  -

  Test your devstack plugins against this patch before it gets merged
  -

  Patch [17]
  -

   Release Countdown for week R+1 and R+2[18]
   -

  Still have release trailing deliverables to take care of
  -

  Need to post their Pike final release before the cycle-trailing
  release deadline (September 14th)
  -

  Join #openstack-release if you have questions
  -

  ttx passes RelMgmgt mantle to smcginnis


Pike Retrospectives

   -

   Nova [19]
   -

   QA [20]


-Kendall (diablo_rojo)

[1] https://etherpad.openstack.org/p/monasca_queens_midcycle

[2] https://etherpad.openstack.org/p/vitrage-ptg-queens

[3]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121637.html

[4]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121715.html

[5] https://wiki.openstack.org/wiki/PTG/Queens/CityGuide

[6]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121494.html

[7] https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver

[8]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121711.html

[9]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121734.html

[10]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121647.html

[11]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121656.html

[12] https://wiki.openstack.org/wiki/Outreachy/Mentors

[13]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121598.html

[14]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121602.html

[15]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121623.html

[16]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121681.html

[17] https://review.openstack.org/#/c/499186/

[18]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121706.html

[19] https://etherpad.openstack.org/p/nova-pike-retrospective

[20] https://etherpad.openstack.org/p/qa-pike-retrospective

[21]
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-08-30.log.html#t2017-08-30T16:07:24
[22]
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-08-30.log.html#t2017-08-30T16:08:07
__
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] Add support for Neutron NSX driver

[Tong Liu]

Hi,

In pike release, we added supported for Neutron NSX driver in TripleO [1]
by the following patches. This will enable TripleO overcloud deployment to
use vmware_nsx as Neutron core_plugin.
https://review.openstack.org/#/c/441668/
https://review.openstack.org/#/c/452047/
https://review.openstack.org/#/c/452391/

However, there are some critical issues which prevent it from functional
correctly, and we fixed them in master with the following patches.
https://review.openstack.org/#/c/499395/
https://review.openstack.org/#/c/498143/
https://review.openstack.org/#/c/498142/

Can we merged these patches and back port to pike?

Thanks,
Tong
[1] Blueprint:
https://blueprints.launchpad.net/tripleo/+spec/neutron-nsx-driver
__
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] [nova] placement/resource providers update 34

[Chris Dent]

Update 34 has many links.

# Most Important

Besides reviewing all the stuff in this document, another important
thing to do is to make additions and edits on the PTG etherpad

https://etherpad.openstack.org/p/nova-ptg-queens

There's also now an etherpad for gathering retrospective thoughts. If
you have some ideas on things that went well or less than well in
placement related work it would be great if you could add your
thoughts there:

https://etherpad.openstack.org/p/nova-pike-retrospective

# Help Wanted

Reviewing things that are fixes for backportable problems is the main
thing.

# Bugs needing attention

(Bugs which are not yet in progress or beyond.)

## Current

* https://bugs.launchpad.net/nova/+bug/1683858
   Allocation records do not contain overhead information

* https://bugs.launchpad.net/nova/+bug/1679750
   Allocations are not cleaned up in placement for instance 'local delete' case

* https://bugs.launchpad.net/nova/+bug/1427772
   Instance that uses force-host still needs to run some filters
   (old bug, but newly relevant in a placement world)

* https://bugs.launchpad.net/nova/+bug/1713796
  Failed unshelve does not remove allocations from destination node

* https://bugs.launchpad.net/nova/+bug/1713739
  VM resize and confirm on the same host fails with custom resources

* https://bugs.launchpad.net/nova/+bug/1714237
  After deleting a migration the allocations are not ceased from the
  destination host

* https://bugs.launchpad.net/nova/+bug/1714402
  When setting an allocation with multiple resource providers and one
  of them does not exist the error message can be wrong

* https://bugs.launchpad.net/nova/+bug/1714248
  Compute node HA for ironic doesn't work due to the name duplication
  of Resource Provider
  (this one has interesting ramifications beyond the specific bug)

## Old (need to be flushed or refreshed:?)

* https://bugs.launchpad.net/nova/+bug/1652099
   placement requests from n-cpu logs not found in placement-api logs

* https://bugs.launchpad.net/nova/+bug/1674694
   In placement api error responses choose poor default content-type
   (this was partially fixed in the resource tracker, but not generally.
   As described in the bug, this ought to be relatively straightforward
   to make go)

# Docs

The illustrated guide to scheduling has been published:
https://docs.openstack.org/nova/latest/reference/scheduling.html

Placement docs being linked into useful place:
https://review.openstack.org/#/c/498977/

# Main Themes

## Alternate Destinations

The complexity of the response data has led to some confusion on how
it should be represented. A spec has been started to try to come to
grips with the issues and resolve to a solution:

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

There are a lot of open questions. The code for that work is in a
stack starting at:

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

## Migration UUIDs in Allocations

As most people have probably noticed, managing allocations during
various types of move operations is chaotic. One way to help make it
more understandable will be to use the uuid of a migration to identify
one of the "claims" used in the "doubling" process. This first
requires a uuid on the migration object. That's starting at:

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

You'll see there that there is a large stack including things like
"Revert allocations by migration uuid". That's the goal, but if
implemented with currently available APIs there are some race
conditions so a new spec has been started to add a way to POST
allocation for multiple consumers in one go:

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

It has a few options which need to be resolved, and the POC
implementation has exposed some other things will need to be tweaked:

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

## Traits

Work continues apace on getting filtering by traits working:

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

This has some overlap with shared provider handling (below).

## Shared Resource Providers

There's some support for shared resource providers on the placement
side of the scheduling equation, but the resource tracker is not yet
ready to support it. There is some work in progress, starting with
functional tests:

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

## Nested Resource Providers

This will start back up after we clean off the windscreen. The stack
begins at https://review.openstack.org/#/c/470575/5

# Other Code

* https://review.openstack.org/#/c/493865/
   functional tests for live migrate

* https://review.openstack.org/#/c/494136/
   Allow shuffling of best weighted hosts

* https://review.openstack.org/#/c/495159/
   tests for resource allocation during soft delete

* https://review.openstack.org/#/c/485209/
   gabbi tests for shared custom resource class

* https://review.openstack.org/#/c/496853/
   Spec for minimal cache-headers in placement
   poc: https://review.openstack.org/#/c/495380/

* https:

Re: [openstack-dev] [Openstack-dev][keystone][AAA] Unable to log in to DLUX UI using keystone created users

[Lance Bragstad]

It looks like the users exist in keystone. Are you able to authenticate
directly against keystone and see if that works?


On 09/01/2017 06:22 AM, A Vamsikrishna wrote:
>
> Hi All,
>
>  
>
> *Setup details: *
>
>  
>
> ubuntu-16.04.2-server-amd64
>
> Docker version 1.12.6
>
> Installed keystone in the docker
>
>  
>
> *Inside the keystone container:*
>
>  
>
> root@82c53b328012 /root #
>
> root@82c53b328012 /root # mysql --version
>
> mysql  Ver 15.1 Distrib 10.0.28-MariaDB, for Linux (x86_64) using
> readline 5.1
>
> root@82c53b328012 /root #
>
> root@82c53b328012 /root #
>
>  
>
> *Issue:*
>
> 1.created some users in keystone container (PFA)  [creating users and
> assigning roles.txt]
>
> 2.Can see those user details in mysql DB (PFA) [users stored in mysql
> DB.txt]
>
> 3.But I see some warnings in keystone logs (PFA) [keystone logs.txt]
>
> *4.And Unable to log in to DLUX UI using the created users(PFA) [DLUX
> UI snapshot]*
>
>  
>
> PFA for *karaf.log* and wireshark captures*(docker0.pcap)* taken
> during authentication.
>
>  
>
> Can someone help me out on this ?
>
>  
>
> Please let me now if you need any more details from myside.
>
>  
>
>  
>
> Thanks,
>
> Vamsi
>
>  
>
>  
>
>
>
> __
> 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




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] [tc][masakari] new project teams application for Masakari

[Tim Bell]

Great to see efforts for this use case.

Is there community convergence that Masakari is the solution to address VMs 
high availability?

Tim

-Original Message-
From: Sam P 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, 1 September 2017 at 19:27
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [tc][masakari] new project teams application for   
Masakari

Hi All,

I have just proposed inclusion of Masakari[1] (Instances High Availability
Service) into list of official OpenStack projects in [2]. Regarding this
proposal, I would like to ask OpenStack community for what else can be 
improved
in the project to meet all the necessary requirements.

And I would like use this thread to extend the discussion about project
masakari. It would be great if you can post your comments/questions in [2] 
or in
this thread. I would be happy to discuss and answer to your questions.

I will be at PTG in Denver from 9/12 (Tuesday) to 9/14(Thursday). Other 
Masakari
team members also will be there at PTG. We are happy to discuss anything
regarding to Masakari in PTG.
Please contact us via freenode IRC @ #openstack-masakari, or openstack-dev 
ML
with prefix [masakari].

Thank you.

[1] https://wiki.openstack.org/wiki/Masakari
[2] https://review.openstack.org/#/c/500118/

--- Regards,
Sampath

__
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] [nova][cinder][glance] What should be the response for invalid 'Accpet' header?

[Chris Dent]

On Fri, 1 Sep 2017, Sean McGinnis wrote:


Thanks Chris, I wasn't aware of that. What's your opinion - change
it to be more strict, or leave it as is?


Ideally we'd have true content negotiation and support multiple
representations with different content types and diferent versions.

;)/2

But since we don't I think existing services can probably forgo
making any changes unless they are eager to tighten things up.

For some additional context:

Placement vaguely supports content negotiation but not in any
significant way. The docstring of a check_accept decorator says:
"If accept is set explicitly, try to follow it. If there is no match
for the incoming accept header send a 406 response code.  If accept
is not set send our usual content-type in response."

Because of the way placement uses webob, and the way webob uses the
accept header to control the formatting of error responses then
content negotiation comes into play on error responses: They are
text/html unless there is an accept header of application/json.


--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
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][masakari] new project teams application for Masakari

[Davanum Srinivas]

Sam,

Please add Masakari to
https://etherpad.openstack.org/p/queens-PTG-TC-SWG and find us in the
"Technical Committee / Stewardship WG room" at the PTG.

Thanks,
Dims


On Fri, Sep 1, 2017 at 1:25 PM, Sam P  wrote:
> Hi All,
>
> I have just proposed inclusion of Masakari[1] (Instances High Availability
> Service) into list of official OpenStack projects in [2]. Regarding this
> proposal, I would like to ask OpenStack community for what else can be 
> improved
> in the project to meet all the necessary requirements.
>
> And I would like use this thread to extend the discussion about project
> masakari. It would be great if you can post your comments/questions in [2] or 
> in
> this thread. I would be happy to discuss and answer to your questions.
>
> I will be at PTG in Denver from 9/12 (Tuesday) to 9/14(Thursday). Other 
> Masakari
> team members also will be there at PTG. We are happy to discuss anything
> regarding to Masakari in PTG.
> Please contact us via freenode IRC @ #openstack-masakari, or openstack-dev ML
> with prefix [masakari].
>
> Thank you.
>
> [1] https://wiki.openstack.org/wiki/Masakari
> [2] https://review.openstack.org/#/c/500118/
>
> --- Regards,
> Sampath
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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][masakari] new project teams application for Masakari

[Sam P]

Hi All,

I have just proposed inclusion of Masakari[1] (Instances High Availability
Service) into list of official OpenStack projects in [2]. Regarding this
proposal, I would like to ask OpenStack community for what else can be improved
in the project to meet all the necessary requirements.

And I would like use this thread to extend the discussion about project
masakari. It would be great if you can post your comments/questions in [2] or in
this thread. I would be happy to discuss and answer to your questions.

I will be at PTG in Denver from 9/12 (Tuesday) to 9/14(Thursday). Other Masakari
team members also will be there at PTG. We are happy to discuss anything
regarding to Masakari in PTG.
Please contact us via freenode IRC @ #openstack-masakari, or openstack-dev ML
with prefix [masakari].

Thank you.

[1] https://wiki.openstack.org/wiki/Masakari
[2] https://review.openstack.org/#/c/500118/

--- Regards,
Sampath

__
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] [ptg][interop][refstack][all]RefStack and Interop WG PTG Agenda

[Chris Hoge]

The RefStack and Interop WG teams will host a small work room on Monday
and Tuesday at the PTG. We would like for projects interested in the
interop guideline expansion to participate in guiding the development of
future guidelines. The draft schedule focuses on Interop work for Monday,
and RefStack work for Tuesday.

The Interop WG work will have a general session for future planning and
guideline work. We will also have sessions targeted towards new vertical
programs, with a focus on NFV. We would also like to invite
representatives from projects that can be installed as standalone
services, like Cinder and Ironic, to discuss the creation of vertical
programs to test for standalone interoperability of their services. In
another session covering extension programs, we would like to invite
representatives from the Designate and Heat projects to attend to discuss
the plans for the two proposed extension programs[1][2]. Any other
projects interested in building an extension program are invited to
attend as well.

On Tuesday the RefStack team will meet to discuss general planning, and
new features such as refstack-client auto configuration, and secure
uploading and storage of subunit test results to the RefStack server.
Members of adjacent communities such as NFV that are using RefStack for
their own interoperability programs are encoraged to attend as well.

If you're interested in attending any of the sessions, please add your
name and availability to the agenda[3]. We will also accomodate remote
attendance for anyone who can't make it to Denver in person. If the
scheduling doesn't work out for you, I will be at the PTG all week and am
available to drop into any other projects. 

Chris

[1] https://review.openstack.org/#/c/490648/ [2]
https://review.openstack.org/#/c/492635/ [3]
https://etherpad.openstack.org/p/InteropDenver2017PTG


__
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] [ptl][release] Queens release management communications

[Sean McGinnis]

Hello, fellow PTLs,

For those paying attention, yes, this is a shameless plagiarization of
Thierry's email from Pike. If something works well, why change it? :)

Following Thierry and Doug's great examples from past cycles, I want to
start the Queens cycle by making sure the expectations for communications
with the release team are clear to everyone so there is no confusion or
miscommunication about any of the process or deadlines. This email is
being sent to the openstack-dev mailing list as well as the PTLs of all
official OpenStack projects individually, to improve the odds that all of
the PTLs see it. Note that future release-related emails will *not* be CCed
to all individual PTLs.

(If you were a PTL/release liaison last cycle, feel free to skip ahead
to the "things for you to do right now" section at the end.)

The release liaison for your project is responsible for coordinating
with the release management team, validating your team release requests,
and ensuring that the release cycle deadlines are met. If you don't
nominate a release liaison for your project (something I encourage you
to do), this task falls back to the PTL. Note that release liaisons do
not have to be core reviewers.

Please ensure that your liaison has the time and ability to handle the
communication necessary to manage your release: the release team is here
to facilitate, but finishing the release work is ultimately the
responsibility of the project team. Failing to follow through on a
needed process step may block you from successfully meeting deadlines or
releasing. In particular, our release milestones and deadlines are
date-based, not feature-based. When the date passes, so does the
milestone. If you miss it, you miss it. A few of you ran into problems
in past cycles because of missed communications. My goal is to have all
teams meet all deadlines during Queens. If there are any questions, or
anything you need to reach this goal, please ask any time in the
#openstack-release IRC channel or contact me directly.

To ensure smooth coordination, we rely on three primary communication tools:

1. Email, for announcements and asynchronous communication.

The release management team will be using the "[release]" topic tag on
the openstack-dev mailing list for important messages. This includes
weekly countdown emails with details on focus, tasks, and upcoming
dates. As PTL or release liaison, you should ensure that you see and
read those messages (by configuring your mailing list subscription and
email client as needed) so that you are aware of all deadlines, process
changes, etc.

2. IRC, for time-sensitive interactions.

With more than 50 teams involved, the four members of the release team
can't track you each of you down when there is a deadline. We rely on
your daily presence in the #openstack-release IRC channel during
deadline weeks. You are, of course, welcome to stay in channel all the
time, but we need you to be there at least during deadline weeks.

3. Written documentation, for relatively stable information.

The release team has published the schedule for the Queens cycle to
http://releases.openstack.org/queens/schedule.html. Although I will
highlight dates in the countdown emails, you may want to add important
dates from the schedule to your calendar. One way to do that is to
subscribe to the ICS feed for community-wide deadlines:
https://releases.openstack.org/schedule.ics

Note that there are many holidays throughout the cycle. If you are
planning time off, please make sure your duties are being covered by
someone else on the team. It's best to let the release team know in
advance so we don't delay approval for release requests from someone
we don't recognize, waiting for your +1.

Things for you to do right now:

1. Update your release liaison on
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

2. Make sure your IRC nickname and email address listed in
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
are correct. The release team, foundation staff, and TC all use those
contact details to try to reach you at important points during the
cycle. Please make sure they are correct, and that the email address
delivers messages to a mailbox you check regularly.

3. Update your mail filters to ensure you see messages sent to the
openstack-dev list with [release] in the subject line.

4. Reply to this message, off-list, to me so I know that you have
received it. A simple “ack” is enough :)

-- 
Sean McGinnis (smcginnis)
Release Management PTL


__
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][cinder][glance] What should be the response for invalid 'Accpet' header?

[Sean McGinnis]

However, this isn't violating the HTTP 1.1 RFCs.
https://tools.ietf.org/html/rfc7231#section-5.3.2 says:

"If the header field is present in a request and none of the
available representations for the response have a media type that is
listed as acceptable, the origin server can either honor the header
field by sending a 406 (Not Acceptable) response or disregard the
header field by treating the response as if it is not subject to
content negotiation."

As far as I'm aware very very few (if any) openstack services do
content negotiation. They only return JSON. Given that, it is
acceptable (ha!) for the header to be disregarded if that's what
people choose.



Thanks Chris, I wasn't aware of that. What's your opinion - change
it to be more strict, or leave it as is?


__
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] [relmgt] No meeting Sept 8

[Sean McGinnis]

As discussed in this weeks meeting, we will skip next Friday's weekly 
meeting due to
many people traveling for the PTG. Regular weekly meetings will resume 
Sept 15.


Next week we will have a shared relmgt/stable/infra room designated 
Mon-Tues.
Most folks will be busy running back and forth to other sessions, but 
someone

should be around to answer questions and give advice if needed.

Some time early next week we will try to figure out a time block for 
later in the

week to all grab a corner somewhere and work through our PTG agenda items:

https://etherpad.openstack.org/p/queens-PTG-relmgt

Please add any additional topics to discuss if you think of something 
else we should

cover while we have the face-to-face time.

Safe travels!

Sean


__
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][cinder][glance] What should be the response for invalid 'Accpet' header?

[Chris Dent]

On Thu, 31 Aug 2017, Singh, Niraj wrote:


As of now, when user passes 'Accept' header in request other than JSON and XML 
using curl command then it returns 200 OK response with json format data.
In api-ref guide [1] also it's not clearly mentioned about what response it 
should return if invalid value for 'Accept' header is specified. IMO instead of 
'HTTP 200 OK' it should return 'HTTP 406 Not Acceptable' response.


I posted this on the bug you created (thanks for that) too but will
paste it here too for completeness:

I generally agree that this is bad behavior and it would be nice if
406 were the response.

However, this isn't violating the HTTP 1.1 RFCs.
https://tools.ietf.org/html/rfc7231#section-5.3.2 says:

"If the header field is present in a request and none of the
available representations for the response have a media type that is
listed as acceptable, the origin server can either honor the header
field by sending a 406 (Not Acceptable) response or disregard the
header field by treating the response as if it is not subject to
content negotiation."

As far as I'm aware very very few (if any) openstack services do
content negotiation. They only return JSON. Given that, it is
acceptable (ha!) for the header to be disregarded if that's what
people choose.


--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
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] Gate is broken - Do not approve any patch until further notice

[Emilien Macchi]

On Fri, Sep 1, 2017 at 8:27 AM, Marios Andreou  wrote:
> I don't think this ^^ patch is what causes/ed that bug, at least I haven't
> found or seen that this is the case. As we discussed a bit on Wednesday
> evening, if you see the elastic-recheck query @
> http://status.openstack.org/elastic-recheck/#1713832 the issue was seen
> twice in the last 24 hours and 5 times since the revert landed early
> Wednesday EU morning. I think that's roughly the same rate it was being seen
> before and after my patch was reverted.
>
> Do you think we can now consider landing that again with
> https://review.openstack.org/#/c/499116/ please ?

At that point I would say no.
We have been merging so many stuffs lately because of release that we
don't even know why this thing broke.
Is it in Zaqar? In Swift? In TripleO?

So yeah maybe it's not your patch but it's maybe related or maybe not.
Since nobody is able to tell it, I would suggest to not revert the
revert until we find the root cause and we fix it.
Because if we don't do that, we'll merge your patch again and
eventually increase the number of hits in the gate which is something
we don't want at this stage.

When we discussed you told me this patch wasn't a requirement to
upgrade but an enhancement. At this stage of the cycle we are looking
for stability and not for enhancements, I hope you understand that.
It's a difficult choice to make for me but I'll prefer us to fix bugs
before we continue to merge new features from now.

Keep in mind feature freeze and why we're doing this.

> I also see you assigned me that bug - I'll try and have another look at it
> next week but we may want to reach out to someone from zaqar see if they
> have any ideas about why that happens.

Thank you, that would be very helpful.
-- 
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] [tripleo] Gate is broken - Do not approve any patch until further notice

[Marios Andreou]

On Wed, Aug 30, 2017 at 2:17 AM, Emilien Macchi  wrote:

> We are currently dealing with 4 issues and until they are fix, please
> do not approve any patch. We want to keep the gate clear to merge the
> fixes for the 4 problems first.
>
> 1) devstack-gate broke us because we use it as a library (bad)
> https://bugs.launchpad.net/tripleo/+bug/1713868
>
> 2) https://review.openstack.org/#/c/474578/ broke us and we're
> reverting it https://bugs.launchpad.net/tripleo/+bug/1713832
>
>
I don't think this ^^ patch is what causes/ed that bug, at least I haven't
found or seen that this is the case. As we discussed a bit on Wednesday
evening, if you see the elastic-recheck query @
http://status.openstack.org/elastic-recheck/#1713832 the issue was seen
twice in the last 24 hours and 5 times since the revert landed early
Wednesday EU morning. I think that's roughly the same rate it was being
seen before and after my patch was reverted.

Do you think we can now consider landing that again with
https://review.openstack.org/#/c/499116/ please ?

I also see you assigned me that bug - I'll try and have another look at it
next week but we may want to reach out to someone from zaqar see if they
have any ideas about why that happens.

have a good weekend all

marios



> 3) We shouldn't build images on multinode jobs
> https://bugs.launchpad.net/tripleo/+bug/1713167
>
> 4) We should use pip instead of git for delorean
> https://bugs.launchpad.net/tripleo/+bug/1708832
>
>
> Until further notice from Alex or myself, please do not approve any patch.
>
> 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 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] PTG Agenda draft - action required

[Emilien Macchi]

On Fri, Sep 1, 2017 at 6:20 AM, Giulio Fidente  wrote:
[...]
> roger, I have added to the thursday afternoon a 1h slot to discuss future
> developments around Ceph integration
>
> specifically three topics:
>
>  - is use of jinja to create multiple ceph clusters a good idea?
>  - upgrade ceph to luminous (maybe also in Kolla)
>  - support multiple ceph-pools for cinder-volume

Cool works for me.
Kolla PTL in CC, to make sure it's visible.
Michal, can you join you think? and some from your team?

> ack, will do and add links to the etherpad to some LP blueprints
>
> thanks Emilien for setting everything up :D

I appreciate your help in doing the agenda :-)
-- 
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] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

Thanks for the proposal. The aim of this workshop is to accelerate the 
collaboration between OpenStack and ETSI and not to execute demonstrations. 
However if you have technical questions to IFA about IFA007 then we can add 
that as an agenda point.

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com]
Sent: Friday, September 1, 2017 1:03 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Hello!

I would also like to discuss the possibility of using Glare for cataloging VNF 
packages. Generally speaking Glare satisfies all the requirements from the 
standard 
http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf
Could we include this topic in the discussions, too?

I plan to create an artifact type and present a short demo there, about how 
glare can work with the packages. If this topic is interesting, then we can 
discuss it in more detail on Wednesday or Thursday in dedicated Glare team room.

Best regards,
Mikhail Fedosin

On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) 
mailto:gergely.csat...@nokia.com>> wrote:
Hi,

Thanks for the clarification.

Our understanding was that with Panko it is possible to subscribe to the state 
of the different resource of the cloud as it is descibed in [1]. This is why we 
mapped the Virtualised [Compute|Network|Storage] Resources Capacity Management 
Interfaces to Panko.

[1]: https://wiki.openstack.org/wiki/Telemetry#Managed

Br,
Gerg0


-Original Message-
From: gordon chung [mailto:g...@live.ca]
Sent: Monday, August 28, 2017 3:05 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017


> Gaps to be discussed are here:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined

i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if you 
need storagE) and not Panko. Panko only handles storage of events (more 
metadata focused data) while Ceilometer handles the actual generation of both 
events and metrics, the latter being the one you want it seems. Gnocchi is used 
for optimised time-series metric storage.

unfortunately, i don't believe anyone from Telemetry teams are attending the 
PTG but we can be reached on ML or #openstack-telemetry.

cheers,

--
gord
__
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-dev] [ptg] Denver City Guide

[Thierry Carrez]

To Denver locals and PTG attendees:

In case you missed it, there is a wiki page with suggestions of bars,
group-friendly dining places and other things to do in Denver that was
started at:

https://wiki.openstack.org/wiki/PTG/Queens/CityGuide

It definitely could use some more material, as teams have started
looking into organizing dinners and all. So if you've done some research
of your own, or if you're local and know places, please add to the wiki!

Also quick reminder that the PTG registration prices are going up in a
few hours, so if you haven't registered yet, you should do so now to
avoid the stragglers tax !

Cheers,

-- 
Thierry Carrez (ttx)

__
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] connecting nova notification users and developers

[gordon chung]

On 2017-08-30 10:30 AM, Balazs Gibizer wrote:
> 1) We in the nova developer community would like to see which projects 
> are using (or planning to use) the nova notification interface. Also we 
> would like to know if you are using the legacy unversioned notifications 
> or the new versioned ones. We would like to know what are your use cases 
> towards our notification interface and we also would like to get any 
> type of feedback about the interface (both the old and the new one). 
> Based on this information we can make better decision where to focus our 
> development effort. As a good example we already have a  cooperation 
> with the searchlight project to enhance nova's versioned notification 
> interface based on their needs [3].

ceilometer uses it to create events and meters. events just capture the 
message as is and might strip out some superfluous details. meters are 
numerical values (associated with time). in both cases, we have yaml 
files where we just define 'if message event_type equals blah, strip out 
values x, y, and z'[1][2]

we don't use versioned notifications but if we had resources we might[3]

> 
> I opened an etherpad [4] to collect the projects and the feedback and we 
> can go through that feedback in the PTG to define some actions.

most of us wont' be at PTG. if you find Hanxi Liu, then you might have 
someone with some knowledge of telemetry projects. we can be reached on 
irc or ML regardless.

[1] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline/data/event_definitions.yaml
[2] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/data/meters.d/meters.yaml
[3] https://bugs.launchpad.net/ceilometer/+bug/1665449

cheers,

-- 
gord
__
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] PTG Agenda draft - action required

[Giulio Fidente]

On 08/29/2017 05:36 PM, Emilien Macchi wrote:

On Mon, Aug 28, 2017 at 3:17 PM, Emilien Macchi  wrote:
[...]

Also, it's still time to propose topics, please go ahead and
contribute to the etherpad. We'll review the schedule before the PTG
(probably during our weekly meetings tomorrow and next week).

[...]

I forgot to remind folks that PTG is a very good time to discuss about
blueprints, as we want to schedule together what we do in the next
cycle.


roger, I have added to the thursday afternoon a 1h slot to discuss 
future developments around Ceph integration


specifically three topics:

 - is use of jinja to create multiple ceph clusters a good idea?
 - upgrade ceph to luminous (maybe also in Kolla)
 - support multiple ceph-pools for cinder-volume


Which means, please be prepared and create blueprints / specs (even
drafts) prior to the PTG, so we have some support that we can use for
scheduling and discussions.


ack, will do and add links to the etherpad to some LP blueprints

thanks Emilien for setting everything up :D
--
Giulio Fidente
GPG KEY: 08D733BA

__
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] Queens Goal for Kingbird

[Goutham Pratapa]

Hi all,

For this Queens cycle, we would like to implement *Kingbird dashboard* so
that it can be used as a *plugin in horizon* using which


*- Admin can manage quota across multiple-regions and *




*- Users can manage their respective resources (for now flavor, image,
keypairs) across multiple regions*
through *front-end*.

We are planning to extend resource_management to *glance image-metadefs* as
well.

-- 
Thanks!!!
Goutham Pratapa
__
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] Queens Goal for Tempest Plugin Split

[Chandan kumar]

Hello,

Since Tempest Plugin Split[0] is added as Queen Goal and most of the
projects have already started the work.
It is just a heads up. If you are going to Denver PTG.
Andreaf is doing a walkthrough on migrating a plugin from in-tree to
own repo [1]. Do not forget to attend this.
The OpenStack-QA team will be also hosting sprints in order to help on
splitting tempest plugins. If you are volunteering for the
same, take some time to participate in that.
If you have any queries or any help you need on this, I will be
available on #openstack-qa channel, Feel free to ping me.
My IRC nick is chandankumar.

After PTG, I will start sneaking in project's weekly meeting to help
the project team to achieve this goal.
One last thing, if you are volunteering for this goal, don't forgot to
update the tempest plugin split wiki page[2].

Links:
[0]. https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
[1]. https://etherpad.openstack.org/p/qa-queens-ptg
[2]. https://wiki.openstack.org/wiki/Tempest_plugin_split_status

Thanks,

Chandan Kumar

__
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] [release] Release countdown for week R+1 and R+2, September 4-15

[Davanum Srinivas]

Thanks for your leadership Thierry!

-- Dims

On Fri, Sep 1, 2017 at 4:04 AM, Thierry Carrez  wrote:
> What? A release countdown at R+1 week? Did someone have too many
> celebratory drinks after Pike release? Well, we are not all done yet. We
> have release-trailing deliverables to take care of.
>
> General Information
> ---
>
> As you probably know, Pike was successfully released[1] on the target
> date this Wednesday. Projects and libraries following the
> cycle-with-intermediary model can now propose early Queens releases.
>
> However, some deployment-oriented deliverables (from Puppet-OpenStack,
> Kolla, TripleO...) have opted for a *cycle-trailing* release model, in
> order to finalize their Pike deliverables *after* the main components
> are released. Those deliverables should already have published their
> first release candidates. They can push additional RCs (or last-minute
> intermediary releases) during the R+1 and R+2 weeks, but need to post
> their Pike final release before the cycle-trailing release deadline
> (September 14).
>
> [1]
> http://lists.openstack.org/pipermail/openstack-announce/2017-August/002009.html
>
> Upcoming Deadlines & Dates
> --
>
> Release deadline for cycle-trailing deliverables: September 14
> Queens PTG in Denver: Sept 11-15
>
> As usual come find us on #openstack-release IRC channel if you have any
> questions or concerns.
>
> This is the last of the release countdown emails you'll receive from me
> for Pike. You should soon receive Queens-related communications from our
> new fearless leader, Sean McGinnis. Thanks again everyone for a great
> development cycle and a smooth release. Take a step back, look at what
> you achieved, and be proud.
>
> --
> Thierry Carrez (ttx)
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

[Mikhail Fedosin]

Hello!

I would also like to discuss the possibility of using Glare for cataloging
VNF packages. Generally speaking Glare satisfies all the requirements from
the standard http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/
02.01.01_60/gs_NFV-IFA007v020101p.pdf
Could we include this topic in the discussions, too?

I plan to create an artifact type and present a short demo there, about how
glare can work with the packages. If this topic is interesting, then we can
discuss it in more detail on Wednesday or Thursday in dedicated Glare team
room.

Best regards,
Mikhail Fedosin

On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) <
gergely.csat...@nokia.com> wrote:

> Hi,
>
> Thanks for the clarification.
>
> Our understanding was that with Panko it is possible to subscribe to the
> state of the different resource of the cloud as it is descibed in [1]. This
> is why we mapped the Virtualised [Compute|Network|Storage] Resources
> Capacity Management Interfaces to Panko.
>
> [1]: https://wiki.openstack.org/wiki/Telemetry#Managed
>
> Br,
> Gerg0
>
>
> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Monday, August 28, 2017 3:05 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
> > Gaps to be discussed are here:
> > https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> > ined
>
> i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if
> you need storagE) and not Panko. Panko only handles storage of events (more
> metadata focused data) while Ceilometer handles the actual generation of
> both events and metrics, the latter being the one you want it seems.
> Gnocchi is used for optimised time-series metric storage.
>
> unfortunately, i don't believe anyone from Telemetry teams are attending
> the PTG but we can be reached on ML or #openstack-telemetry.
>
> cheers,
>
> --
> gord
> __
> 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-dev] [tc] Technical Committee Status update, September 1st

[Thierry Carrez]

Hi!

This is the weekly update on Technical Committee initiatives. You can
find the full list of all open topics at:

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


== Recently-approved changes ==

* Allow teams to host meetings in their channels [1][2]
* PTL updates following the Queens elections [3][4]
* Amend leaderless program resolution timeframe [5]
* Docs URL updates [6]
* Pike goals updates: ironic
* New repositories: solum-tempest-plugin
* Retired repositories: oslo-incubator

[1] https://review.openstack.org/#/c/485117/
[2] https://review.openstack.org/#/c/495886/
[3] https://review.openstack.org/#/c/493846/
[4] https://review.openstack.org/#/c/498363/
[5] https://review.openstack.org/#/c/492578/
[6] https://review.openstack.org/#/c/496321/

Mostly administrative updates this week, except the final approval of
the resolution allowing teams to host meetings in their own channels:

https://governance.openstack.org/tc/resolutions/20170718-allow-scheduling-meetings-on-team-channels.html

The irc-meetings framework should be updated to allow such meetings to
be scheduled.


== PTG prep ==

We'll have a TC / StewardshipWG room on Monday-Tuesday at the PTG. You
can chime in on topics we should cover there on the planning etherpad:

https://etherpad.openstack.org/p/queens-PTG-TC-SWG


== New project teams ==

We still have 4 new project teams applications up: Stackube, Glare,
Blazar and Gluon. We'll likely meet three of those teams during the PTG,
withe Glare and Blazar being likely to be approved really soon now.
However the Stackube folks are not likely to be present, so it would be
great to give that review some extra attention now, so that we can make
progress:

https://review.openstack.org/462460


== Open discussions ==

Chris and John both suggested additions to the Top-5 list:

Reduce Development Complexity: https://review.openstack.org/496404
Service layering: https://review.openstack.org/498719

The discussion so far mostly revolved around whether the top-5 list,
originally meant for highly-tactical TC shouts for help in struggling
areas, is the right medium for more strategic / long-term ideas. And if
not, what would be the right way to express that.

Monty's proposal to be explicit about supported database versions is
likely to need a new patchset to incorporate the early feedback:

https://review.openstack.org/493932

John's resolution on how decisions should be globally inclusive is still
mostly blocked, waiting to be converted into project-team-guide material:

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


== Voting in progress ==

Flavio's resolution on dropping Technical Committee meetings is still
missing a couple of votes before it can be approved:

https://review.openstack.org/459848


== TC member actions for the coming week(s) ==

All members should review the PTG room etherpad and add any topic they
want to discuss in the room on Monday/Tuesday of the PTG.

Jeremy should find time to raise a discussion (and/or file a proposal)
around adding Infra to the Top-5 list.

Monty should answer the feedback on the supported database version
resolution so that we can make progress there.

All members should familiarize themselves with the new project teams
being proposed for addition and comment on their reviews (or prepare
questions for in-person discussions).


== Need for a TC meeting next Tuesday ==

No proposal is really blocked due to member disagreement at this stage,
most are caught in the post-release pre-PTG hiatus. With the PTG coming
up the week after, I don't think we need an in-person meeting next week.
We should definitely take advantage of the Office Hours[7] for
preparatory discussions as we prep for the Board+TC+UC+Staff meeting on
Sunday and the PTG week after, though.

[7] https://governance.openstack.org/tc/#office-hours

Cheers,

-- 
Thierry Carrez (ttx)

__
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][scheduling] Can VM placement consider the VM network traffic need?

[Balazs Gibizer]

On Fri, Sep 1, 2017 at 10:42 AM, Rua, Philippe (Nokia - FI/Espoo) 
 wrote:
Will it be possible to include network bandwidth as a resource in 
Nova scheduling, for VM placement decision?


I think it will.




Context: in telecommunication applications, the network traffic is an 
important dimension of resource usage. For example, it is often 
important to distribute "bandwidth-greedy" VMs to different compute 
nodes. There were some earlier discussions on this topic, but I could 
not find a concrete outcome. [1][2][3]


After some reading, I wonder whether the Custom resource classes can 
provide a generic mechanism? [4][5][6]

Here is what I have in mind:
- The VM need is specified in the flavor extra-specs, e.g. 
resources:CUSTOM_BANDWIDTH=123.
- The compute node total capacity is specified in host aggregate 
metadata, e.g. CUSTOM_BANDWIDTH=999.


I'm not aware of any feature that considers aggregate metadata key as 
resource inventory. As far as I know you have to define new resource 
providers for your CUSTOM_BANDWIDTH resource via the placement API and 
you have to report the 999 as inventory on those resource providers 
also via placement API. Also don't forget to connect your resource 
provider to the existing compute resource providers via an aggregate 
(this is an aggregate in placement which is different from the host 
aggregate concept in nova). This review contains some test cases that 
can help you how to set things up 
https://review.openstack.org/#/c/497399


- Nova then takes care of the rest: scheduling where the free 
capacity is sufficient, and performing simple resource usage 
accounting (updating the compute node free network bandwidth capacity 
as required).


With the above flavor extra spec as request and the above resource 
provider setup nova will do the rest of the resource accounting for the 
your custom resource. Except in case you hit one of the bugs we 
discovered in this area 
https://bugs.launchpad.net/nova/+bugs?field.tag=placement





Is the outline above according to current plans?
If not, what would be possible/needed in order to achieve the same 
result, i.e. consider the VM network traffic need during VM placement?


You might want to keep an eye on the nested-resource-provider work 
planned for Queens as it will give you better options to model your 
resources: 
https://blueprints.launchpad.net/nova/+spec/nested-resource-providers


Cheers,
gibi




BR,
Philippe

[1] 
https://blueprints.launchpad.net/nova/+spec/bandwidth-as-scheduler-metric

[2] https://wiki.openstack.org/wiki/NetworkBandwidthEntitlement
[3] 
https://openstack.nimeyo.com/80515/openstack-scheduling-bandwidth-resources-nic_bw_kb-resource

[4] https://docs.openstack.org/nova/latest/user/placement.html
[5] 
http://specs.openstack.org/openstack/nova-specs/priorities/pike-priorities.html#placement

[6] https://review.openstack.org/#/c/473627/

__
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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Claudiu Belu]

networking-hyperv is under the Winstackers governance [1], of which I am the 
PTL of, and you have my +1. :)

[1] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n4656


From: Thierry Carrez [thie...@openstack.org]
Sent: Friday, September 01, 2017 10:51 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [relmgt] Libraries published to pypi with .X.Z 
versions

Claudiu Belu wrote:
> So, I believe the general consensus is that the easiest thing to do is to 
> unpublish the 2015.1.0 version from pypi, with which I also agree.
> [...]

Yes, for a first batch I propose we clean up the following:

python-congressclient 2015.1.0
python-congressclient 2015.1.0rc1
python-designateclient 2013.1.a8.g3a2a320
networking-hyperv 2015.1.0

For the remaining (official) ones (mistral-extra, networking-odl,
murano-dashboard, networking-hyperv, networking-midonet,
sahara-image-elements, freezer-api, murano-agent, mistral-dashboard,
sahara-dashboard) let's wait until we can get PTL signoff.

--
Thierry Carrez (ttx)

__
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] [nova][scheduling] Can VM placement consider the VM network traffic need?

[Rua, Philippe (Nokia - FI/Espoo)]

Will it be possible to include network bandwidth as a resource in Nova 
scheduling, for VM placement decision?

Context: in telecommunication applications, the network traffic is an important 
dimension of resource usage. For example, it is often important to distribute 
"bandwidth-greedy" VMs to different compute nodes. There were some earlier 
discussions on this topic, but I could not find a concrete outcome. [1][2][3]

After some reading, I wonder whether the Custom resource classes can provide a 
generic mechanism? [4][5][6]
Here is what I have in mind:
- The VM need is specified in the flavor extra-specs, e.g. 
resources:CUSTOM_BANDWIDTH=123.
- The compute node total capacity is specified in host aggregate metadata, e.g. 
CUSTOM_BANDWIDTH=999.
- Nova then takes care of the rest: scheduling where the free capacity is 
sufficient, and performing simple resource usage accounting (updating the 
compute node free network bandwidth capacity as required).

Is the outline above according to current plans?
If not, what would be possible/needed in order to achieve the same result, i.e. 
consider the VM network traffic need during VM placement?

BR,
Philippe

[1] https://blueprints.launchpad.net/nova/+spec/bandwidth-as-scheduler-metric
[2] https://wiki.openstack.org/wiki/NetworkBandwidthEntitlement
[3] 
https://openstack.nimeyo.com/80515/openstack-scheduling-bandwidth-resources-nic_bw_kb-resource
[4] https://docs.openstack.org/nova/latest/user/placement.html
[5] 
http://specs.openstack.org/openstack/nova-specs/priorities/pike-priorities.html#placement
[6] https://review.openstack.org/#/c/473627/

__
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] [release] Release countdown for week R+1 and R+2, September 4-15

[Thierry Carrez]

What? A release countdown at R+1 week? Did someone have too many
celebratory drinks after Pike release? Well, we are not all done yet. We
have release-trailing deliverables to take care of.

General Information
---

As you probably know, Pike was successfully released[1] on the target
date this Wednesday. Projects and libraries following the
cycle-with-intermediary model can now propose early Queens releases.

However, some deployment-oriented deliverables (from Puppet-OpenStack,
Kolla, TripleO...) have opted for a *cycle-trailing* release model, in
order to finalize their Pike deliverables *after* the main components
are released. Those deliverables should already have published their
first release candidates. They can push additional RCs (or last-minute
intermediary releases) during the R+1 and R+2 weeks, but need to post
their Pike final release before the cycle-trailing release deadline
(September 14).

[1]
http://lists.openstack.org/pipermail/openstack-announce/2017-August/002009.html

Upcoming Deadlines & Dates
--

Release deadline for cycle-trailing deliverables: September 14
Queens PTG in Denver: Sept 11-15

As usual come find us on #openstack-release IRC channel if you have any
questions or concerns.

This is the last of the release countdown emails you'll receive from me
for Pike. You should soon receive Queens-related communications from our
new fearless leader, Sean McGinnis. Thanks again everyone for a great
development cycle and a smooth release. Take a step back, look at what
you achieved, and be proud.

-- 
Thierry Carrez (ttx)

__
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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Thierry Carrez]

Claudiu Belu wrote:
> So, I believe the general consensus is that the easiest thing to do is to 
> unpublish the 2015.1.0 version from pypi, with which I also agree.
> [...]

Yes, for a first batch I propose we clean up the following:

python-congressclient 2015.1.0
python-congressclient 2015.1.0rc1
python-designateclient 2013.1.a8.g3a2a320
networking-hyperv 2015.1.0

For the remaining (official) ones (mistral-extra, networking-odl,
murano-dashboard, networking-hyperv, networking-midonet,
sahara-image-elements, freezer-api, murano-agent, mistral-dashboard,
sahara-dashboard) let's wait until we can get PTL signoff.

-- 
Thierry Carrez (ttx)

__
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] [PTG][I18n][Doc] PTG planning Denver

[Frank Kloeker]

Good morning,

it's only a week to the next PTG in Denver. I would like to invite you 
to visit our project etherpad on [1]. We as I18n team are together with 
the Doc team in the same room and we share also our planning on the 
etherpad.
Monday morning we reserved some time to say "Hello" to everybody. Take 
the chance to meet us and let me know if you have some topics for the 
translation team.


kind regards

Frank (eumel8)
PTL I18n

[1] https://etherpad.openstack.org/p/docs-i18n-ptg-queens

__
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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Claudiu Belu]

So, I believe the general consensus is that the easiest thing to do is to 
unpublish the 2015.1.0 version from pypi, with which I also agree.

Even if someone actually needs the Kilo version (it's a very old branch, very 
few people still use it, at most), it can still be done via [1]:

pip install 
git+http://github.com/openstack/networking-hyperv@2015.1.0#networking-hyperv

or

pip install 
http://tarballs.openstack.org/networking-hyperv/networking_hyperv-2015.1.0-py2-none-any.whl

If someone *actually* needs it on pypi, We could publish a 0.x.y version, but I 
don't think it will be necessary.

Also, @Tony, using upper-constraints wouldn't work when installing 
networking-hyperv won't really help, as it isn't defined there. 
networking-hyperv is not a requirement in any project, it's only needed by 
neutron if the "hyperv" mechanism_driver is used.

Thanks @all for your opinions!

Best regards,

Claudiu Belu


From: Jeremy Stanley [fu...@yuggoth.org]
Sent: Thursday, August 31, 2017 3:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [relmgt] Libraries published to pypi with .X.Z 
versions

On 2017-08-31 15:21:19 +1000 (+1000), Tony Breeds wrote:
[...]
> I assume it's infra that needs to do the actual unpublish?

We're the ones with the most consistent access to all of them,
though in a majority of cases there's at least one other account
with sufficient access to do the same (it just tends to vary by team
and origination timeframe). So, yes, probably easiest to give the
Infra team a list once it's been confirmed.
--
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