[openstack-dev] [Neutron] ImportError: No module named neutron_lib

[Sam]

Hi,

I'm using neutron mitaka version, I found lots of files include this:
"from neutron_lib import exceptions as e"
But I don't find where is neutron_lib, and I got error as "ImportError: No
module named neutron_lib"

Is there some error?
__
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] ask.openstack.org site is down!

[Abed Abu-Dbai]

__
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] [Watcher] Weekly meeting

[Чадин Александр]

Watcher folks,

We will have meeting this Wednesday at 14:00 UTC. I won't be available in IRC 
until the meeting (we have holiday tomorrow), so if you have urgent questions, 
text me an email.

Best regards
_
Alexander Chadin
OpenStack Developer
Servionica LTD
a.cha...@servionica.ru
+7 (916) 693-58-81
__
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] [oslo] question about oslo_utils and oslo_versonedobjects

[zengchen]

Hi, guys:
 I find a non-coincidence definition in Oslo, 


 oslo_utils.timeutils.utcnow is defined like this:
 def utcnow(with_timezone=False):


oslo_versonedobjects.fields.DateTimeField is defined like this
class DateTimeField(AutoTypedField): def __init__(self, tzinfo_aware=True, 
**kwargs):


a = utcnow()
class ABC(VersionedObject):
fields = {
created_at = fields.DateTimeField()
}
b = ABC(), and fill it by db record.


If I compare a and b.created_at,  it will raise an exception like this:
   'TypeError: can't compare offset-naive and offset-aware datetimes'
because a's value is like this:
datetime.datetime(2017, 3, 7, 2, 34, 50, 859002)
b.created_at 's value is like this:
 datetime.datetime(2017, 3, 7, 2, 35, 27, 400786, tzinfo=)


   Can these two kinds of time's definition be coincident? For example:
   def utcnow(with_timezone=False):


   class DateTimeField(AutoTypedField):
def __init__(self, tzinfo_aware=False, **kwargs):


best wishes
zeng chen













__
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] [oslo_reports]Does GMR work for uwsgi mode service?

[hao wang]

Hi, stackers,

I'm trying to use Guru Meditation Report in Zaqar project which can
support uwsgi server.  I imported gmr and used
"gmr.TextGuruMeditation.setup_autorun(version, conf=conf)",  but it
didn't work under uwsgi mode.

Did I do something wrong,  or  GMR doesn't support uwsgi mode yet?

Thanks for your help!

Wang Hao

__
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] [picasso] First meeting on 7th of March

[Derek Schultz]

Update: the patch to openstack-infra/irc-meetings was merged, so we should
be good to go. The only change was moving the meeting time from 1800 UTC to
1700 UTC.

Meeting details can be found here
https://wiki.openstack.org/wiki/Meetings/Picasso

On Mon, Mar 6, 2017 at 6:45 PM Derek Schultz 
wrote:

> All good points, it's important that we do not diverge from the community.
> Today I created an #openstack-functions channel on IRC and have submitted
> the necessary patches to the openstack-infra project-config and
> irc-meetings repositories. Due to this, I may have to move the first
> meeting from this Tuesday to another day or week as we wait for approval..
> I'll keep this thread posted as soon as I know more.
>
> Regards,
> Derek
>
> On Thu, Mar 2, 2017 at 11:54 AM Paul Belanger 
> wrote:
>
> On Thu, Mar 02, 2017 at 05:41:24PM +, Derek Schultz wrote:
> > Hi Emilien,
> >
> > Thanks for the feedback! I'm aware that IRC is the standard for OpenStack
> > folks, but at this current stage it's just easier to hold the discussion
> in
> > Slack as Picasso ties into the IronFunctions open source project and
> > important context would be lost if we were to maintain different chat
> > platforms. That said, I think we can move Picasso from Slack to IRC in
> the
> > future (once we prepare for the big tent).
> >
> I agree with Emilien here, by using a proprietary platform you are
> potentially
> alienation existing openstack developers from contributing to your project.
> Yes IRC would be needed for big tent, but why start consuming IRC out of
> the
> gate?
>
> Are are already hosting code on git.openstack.org, seems like the next
> step
> would be to move to IRC.
>
> > Regards,
> > Derek Schultz
> >
> > On Wed, Mar 1, 2017 at 7:49 AM Emilien Macchi 
> wrote:
> >
> > > On Tue, Feb 28, 2017 at 12:30 PM, Derek Schultz <
> schultz.de...@gmail.com>
> > > wrote:
> > > > Hello all,
> > > >
> > > > The Picasso team will be running our first meeting next Tuesday. All
> > > those
> > > > interested in the project are welcome!
> > > >
> > > > For those of you not familiar with Picasso, it provides a platform
> for
> > > > Functions as a Service (FaaS) on OpenStack [1].
> > > >
> > > > Tuesday, March 7th, 2017 Meeting Agenda:
> > > > Starting at UTC 18:00
> > > >
> > > > 1. From Python to Go. (What Picasso needs from IronFunctions to
> implement
> > > > multi-tenancy)
> > > > 2. Blueprints [2]
> > > > 3. Figure out best time slot for future meetings.
> > > > 4. Roadmap discussion.
> > > >
> > > > How to join:
> > > > http://slack.iron.io in the #openstack channel
> > >
> > > I would recommend using IRC for consistency with other projects.
> > > Nothing forces you to do so, unless you plan to apply to the Big Tent.
> > > My personal recommendation would be to use IRC so you can get more
> > > visibility, since most of OpenStack folks are on IRC (and not always
> > > on Slack).
> > >
> > > Good luck for your first meeting!
> > >
> > > > Etherpad:  https://etherpad.openstack.org/p/picasso-first-meeting
> > > >
> > > > [1] https://wiki.openstack.org/wiki/Picasso
> > > > [2] https://blueprints.launchpad.net/picasso
> > > >
> > > >
> > > >
> > > >
> > >
> __
> > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > 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
>
>
> __
> 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] Stepping down from Neutron roles

[Kevin Benton]

Hi Nate,

Thanks for all of your contributions and good luck in your future
endeavors! You're always welcome back. :)


On Mar 6, 2017 13:15, "Nate Johnston"  wrote:

All,

I have been delaying this long enough... sadly, due to changes in direction
I
am no longer able to spend time working on OpenStack, and as such I need to
resign my duties as Services lieutenant, and liaison to the Infra team.  My
time in the Neutron and FWaaS community has been one of the most rewarding
experiences of my career.  Thank you to everyone I met at the summits and
who
took the time to work with me on my contributions.  And thank you to the
many
of you who have become my personal friends.  If I see an opportunity in the
future to return to OpenStack development I will jump on it in a hot minute.
But until then, I'll be cheering you on from the sidelines.

All the best,

--N.

__
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] A Summary of Atlanta PTG Summaries (!)

[Hugh Blemings]

Hiya,

As has been done for the last few Summits/PTGs in Lwood[1] I've pulled 
together a list of the various posts to openstack-dev that summarise 
things at the PTG - projects, videos, anecdotes etc.


The aggregated list is in this blog post;

http://hugh.blemings.id.au/2017/03/07/openstack-ptg-atlanta-2017-summary-of-summaries/

Which should aggregate across to planet.openstack.org as well.

I'll update this as further summaries appear, corrections/contributions 
welcome.


Cheers,
Hugh

[1] http://hugh.blemings.id.au/openstack/lwood/


__
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] [heat] heat PTG recap

[Rico Lin]

Hi everyone,

Heat team gathered at the PTG from 2/22-2/24

Here is some discussion that we have targeted during PTG:
https://etherpad.openstack.org/p/heat-pike-ptg-sessions

Targeted tasks or discussions:
* We have reached an agreement with release team about the stable mint list
management for Heat will remain on stable mint cores. Members who give
enough review to stable releases patches will have more chance to be
promoted as Stable mint for heat. All above information is now in the
official policy from release team.

* We need Python 3 support, This is the community width goal. We will have
to make sure all heat's repo has reached this requirement. There already
landed some patches for Python 35 support (see
https://etherpad.openstack.org/p/pike-heat-ptg-python3 ).
* We have to collaborate with Interop team to define tests(API and scenario
tests) for heat for all can define what is heat.

* We agree with heat should have an interface for resources for any
resource plugins. So the resources won't directly use inner methods.
* For Convergence 2.0+ required, we need a notification system for heat
resources. Also, we have talked about if no volunteer for convergence
doc(we decide to do in Ocata release), we will postpone our doc plan for
convergence.
For above two tasks, you can find reference here
https://etherpad.openstack.org/p/pike-heat-ptg-convergence2

* For convergence adoption, we might still require some memory improvement
for the tripleO project to adopt convergence mode.

* Feedback from Sahara and Magnum team, when a lot of resources been
deleted (like stack-delete action), we might throw a huge number of API
calls in a very short period (For example, to Cinder) and course some
service overload situation. This might be one issue we can try to help to
make some more friendly API calling schedule to other services.
* Feedback from user survey,
What's the current/expected load on your Heat deployment?
Few big stacks (>100 resources each) = 6 (9%)
Few small stacks (<100 resources each) = 50 (78%)
Lots of big stacks (>100 resources each) = 1
Lots of small stacks (<100 resources each) = 7 (10%)
( You can find the reference here
https://etherpad.openstack.org/p/pike-cp-ptg-orchestration-feedback )

* Feedback from TripleO team and Magnum team asking the possibility for
Heat to adopt Jinja2. As we do not recommend to use heat for deep layer
resource structure (A flat structure might work better.), we will consider
adding Jinja once more detail from other projects about how they might
using it (make sure we reach the target requirements.)
* Also, we have some interest use case that combining Heat and Mistral
(and/or Jinja) from TripleO team, would like to trace them with the entire
use case, and hope we can get complete use case and share out to any other
projects who might get benefit from it.
(Some reference you can see in
https://etherpad.openstack.org/p/pike-cp-ptg-orchestration-integrate )

* Identity trust and federate still not working for Heat (and some other
services). we have to make an announcement about heat user should not use
federation until keystone fix it. (see
https://etherpad.openstack.org/p/keystone-pike-ptg)

For specs, we're consider fallowing actions:
We have obsolete some very old PB (feel free to raise any discussion if you
have some very important BP been obsoleted).
Also lower the Blueprint priority, for V2 API, we still mark v2(or maybe we
should call v1.1) API as the next thing we need to do, but seems should not
settle down during Pike cycle. For more other actions please reference here
https://etherpad.openstack.org/p/pike-heat-ptg-track-and-design

We also spend some more time with reviewing patches, which all listed in
Etherpads, so I'm not going to list all of it here.
Feel free to raise further discussion for any topics, we can always discuss
anything in detail through the entire cycle.


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
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] [picasso] First meeting on 7th of March

[Derek Schultz]

All good points, it's important that we do not diverge from the community.
Today I created an #openstack-functions channel on IRC and have submitted
the necessary patches to the openstack-infra project-config and
irc-meetings repositories. Due to this, I may have to move the first
meeting from this Tuesday to another day or week as we wait for approval..
I'll keep this thread posted as soon as I know more.

Regards,
Derek

On Thu, Mar 2, 2017 at 11:54 AM Paul Belanger  wrote:

> On Thu, Mar 02, 2017 at 05:41:24PM +, Derek Schultz wrote:
> > Hi Emilien,
> >
> > Thanks for the feedback! I'm aware that IRC is the standard for OpenStack
> > folks, but at this current stage it's just easier to hold the discussion
> in
> > Slack as Picasso ties into the IronFunctions open source project and
> > important context would be lost if we were to maintain different chat
> > platforms. That said, I think we can move Picasso from Slack to IRC in
> the
> > future (once we prepare for the big tent).
> >
> I agree with Emilien here, by using a proprietary platform you are
> potentially
> alienation existing openstack developers from contributing to your project.
> Yes IRC would be needed for big tent, but why start consuming IRC out of
> the
> gate?
>
> Are are already hosting code on git.openstack.org, seems like the next
> step
> would be to move to IRC.
>
> > Regards,
> > Derek Schultz
> >
> > On Wed, Mar 1, 2017 at 7:49 AM Emilien Macchi 
> wrote:
> >
> > > On Tue, Feb 28, 2017 at 12:30 PM, Derek Schultz <
> schultz.de...@gmail.com>
> > > wrote:
> > > > Hello all,
> > > >
> > > > The Picasso team will be running our first meeting next Tuesday. All
> > > those
> > > > interested in the project are welcome!
> > > >
> > > > For those of you not familiar with Picasso, it provides a platform
> for
> > > > Functions as a Service (FaaS) on OpenStack [1].
> > > >
> > > > Tuesday, March 7th, 2017 Meeting Agenda:
> > > > Starting at UTC 18:00
> > > >
> > > > 1. From Python to Go. (What Picasso needs from IronFunctions to
> implement
> > > > multi-tenancy)
> > > > 2. Blueprints [2]
> > > > 3. Figure out best time slot for future meetings.
> > > > 4. Roadmap discussion.
> > > >
> > > > How to join:
> > > > http://slack.iron.io in the #openstack channel
> > >
> > > I would recommend using IRC for consistency with other projects.
> > > Nothing forces you to do so, unless you plan to apply to the Big Tent.
> > > My personal recommendation would be to use IRC so you can get more
> > > visibility, since most of OpenStack folks are on IRC (and not always
> > > on Slack).
> > >
> > > Good luck for your first meeting!
> > >
> > > > Etherpad:  https://etherpad.openstack.org/p/picasso-first-meeting
> > > >
> > > > [1] https://wiki.openstack.org/wiki/Picasso
> > > > [2] https://blueprints.launchpad.net/picasso
> > > >
> > > >
> > > >
> > > >
> > >
> __
> > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > 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
>
>
> __
> 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] [cross-project][nova][cinder][designate][neutron] Common support-matrix.py

[Sean Dague]

On 03/06/2017 06:27 PM, Mike Perez wrote:

On 15:55 Mar 02, Morales, Victor wrote:

I got this link[11] from Ankur, apparently Nova and Neutron has already started 
a common effort

[11] https://review.openstack.org/#/c/330027/


Thanks for pointing me to this Victor! I have spoke to Doug and Sean Dague in
#openstack-dev about this, and I think it'll be fine for us to keep the current
INI file approach. I've reached out to Ankur to hopefully restore and continue
this effort.

What do Designate and Cinder folks think of this approach?


The only thing I'd suggest is not to wrap it into oslosphinx but just do 
it as a dedicated extension. When we did os-api-ref we eventually had to 
jump themes because this was going to end up outside the devref in 
projects, and being decoupled made that possible.


-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] [networking-sfc] Stable/Ocata Version

[Jeffrey Zhang]

roger. thanks all guys.

On Tue, Mar 7, 2017 at 3:26 AM, Cathy Zhang 
wrote:

> Just completed.
>
>
>
> Cathy
>
>
>
> *From:* Jeffrey Zhang [mailto:zhang.lei@gmail.com]
> *Sent:* Friday, March 03, 2017 6:59 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [networking-sfc] Stable/Ocata Version
>
>
>
> any update for releasing stable/ocata branch or tag? It is Mar already.
>
>
>
> On Tue, Feb 21, 2017 at 1:23 AM, Henry Fourie 
> wrote:
>
> Gary,
>
>The plan is to have a stable/ocata branch by end of month.
>
> -Louis
>
>
>
> *From:* Gary Kotton [mailto:gkot...@vmware.com]
> *Sent:* Sunday, February 19, 2017 4:29 AM
> *To:* OpenStack List
> *Subject:* [openstack-dev] [networking-sfc] Stable/Ocata Version
>
>
>
> Hi,
>
> When will this repo have a stable/ocata branch?
>
> Thanks
>
> Gary
>
>
> __
> 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
>
>
>
>
>
> --
>
> Regards,
>
> Jeffrey Zhang
>
> Blog: http://xcodest.me
>
> __
> 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
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [octavia] Octavia PTG summary - Octavia team discussions (e-mail 2 of 2)

[Michael Johnson]

Some of the Octavia team attended the first OpenStack Project Team Gathering
(PTG) held in Atlanta the week of February 27th.  Below is a summary of the
notes we kept in the Octavia etherpad here:
https://etherpad.openstack.org/p/octavia-ptg-pike

This e-mail details discussions we had about Octavia specific topics.  A
second e-mail will cover topics the Octavia team discussed with the
cross-project teams.

Michael

Active/Active

  * This is a priority for Pike.  Cores will be actively reviewing these
patches.
  * We need to make sure there is good velocity for comments getting
addressed.

Amphora in containers

  * We need to work on this in Pike.  We cannot implement upgrade tests
under the current gate host limitations without containers being available.
  * Currently nova-lxd looks to be the shortest path for octavia.
  * It was noted that Docker can now support hot-plugging networks.
  * There is community interest in using Docker for the amphora.
  * There was interest in booting amphora via kubernetes, but we need to
research the implications and OpenStack support more.

Barbican

  * We discussed Octavia's ongoing use of barbican and our need for a
cascading ACL API.  This will greatly simplify the user experience for TLS
offloading load balancers via Octavia.  I captured the need in a barbican
bug here: https://bugs.launchpad.net/barbican/+bug/1666963
  * The barbican team requested that we do a bug scrub through the barbican
bugs to pull out any LBaaS/Octavia bugs that may be mis-filed or out of
date.  Michael (johnsom) will do that.

Container networking

  * Currently using neutron-lbaas with kubernetes, but planning to move to
Octavia.
  * Interested to use the L7 capability to save public IPs.

Documentation

  * Documentation is a priority for Pike!
  * API-REF is work in progress (johnsom):
https://review.openstack.org/#/q/topic:bug/1558385
  * API-guide we are deferring until after Pike
  * Upgrade guide is targeted for Pike (diltram/johnsom)
  * HA guide is targeted for Pike (diltram/johnsom)
  * OpenStack Ansible guide is targeted for Pike (xgerman)
  * Detailed setup guide is targetd for Pike (KeithMnemonic)
  * Admin guide we are deferring until after the documentation team spins it
out into the project repositories (https://review.openstack.org/439122)
  * Networking guide - discuss with john-davidge about a link out to Octavia
documentation.
  * Developer guide started, maybe Pike? (sindhu):
https://review.openstack.org/#/c/410419/
  * OpenStack Client guide - is this autogenerated?
  * User guide - Cookbooks kind of cover this, defer additional work until
after Pike
  * Troubleshooting guide - Pike?  (KeithMnemonic/johnsom)
  * Monitoring guide - defer until after Pike
  * Operator guide?
  * Runbooks?

Dragonflow

  * The dragonflow team wanted to meet with the Octavia team to discuss
integration points.  We talked about how dragonflow could be used with
Octavia and how offset style L7 rules might be implemented with dragonflow.
  * We gave an overview of how a dragonflow load balancing driver could be
added to Octavia.
  * We also asked if dragonflow would have the same issues as DVR does with
VRRP and provided a use case.

Drivers / Providers

  * Octavia provider support will be implemented via the named extension
model
  * Providers will be implemented as handlers like the existing noop and
Octavia driver are implemented.
  * Change in the interaction model with barbican (octavia service account
is authorized for barbican containers and content) means that octavia will
need to pass the required secure content to the providers.  This may be
different than how vendor drivers handled this content in neutron-lbaas, but
the old model should still be available to the vendor if they choose to not
adopt the new parameters passed to the handler.
  * Octavia will implement a new endpoint spawned from the health manager
processes that will receive statistics, status, and agent health information
from vendor agents or drivers.  This will establish a stable and scalable
interface for drivers to update this information.
o Proposed using a similar UDP endpoint to how the amps are reporting
this information.
o Would use a per-provider key for signing, seeded with the agent ID
o An method for agents to query the list of available agent health
endpoints will need to be created to allow the vendor agents to update their
list of available endpoints.
  * Octavia will add an agent database table similar to the neutron agents
idea.
  * Vendor agents can update this information via the above mechanism
providing the operator with visibility to the vendor agent health.
  * Octavia may include the octavia processes in the list of agents.
  * We need to understand if any of the vendor drivers are considering using
the driver shim (neutron-lbaas translation layer) or if they are all going
to update to the octavia handler API.

Flavors

  * It appears that the flavors spec is stalled:

Re: [openstack-dev] [cinder] Create backup with snapshots

[王玺源]

Cool. That's the way which I desire  mostly. Here is the bug:
https://bugs.launchpad.net/cinder/+bug/1670541 and I'll update the patch
ASAP.

Thanks very much for your explanation and  suggestion.

2017-03-06 22:43 GMT+08:00 yang, xing :

> I don't think we should add a separate API for backing up a snapshot.  We
> could do a check in the backup API to see whether snapshot_id is provided
> or not.  If provided, we change the status of the snapshot; otherwise, we
> change the status of the volume as usual.  Changes are needed in
> backup/api.py and backup/manager.py (to change the status back).
>
> Do you want to submit a bug fix for this change?
>
> Thanks,
> Xing
>
>
> 
> From: 王玺源 [wangxiyuan1...@gmail.com]
> Sent: Sunday, March 5, 2017 9:51 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [cinder] Create backup with snapshots
>
> Thanks, Xing.
>
> I got the history reason now. So is it possible that we can devide the
> create API into two APIs? One is for create backup from volumes, another is
> from snapshots. Then we can control the volumes' and snapshots' status
> dividually and easily.
>
> When create a backup from a large snapshot, such as larger than 1 TB, It
> will costs few hours generally. It's really a problem that the volume is
> not available for such a long time.
>
> 2017-03-03 22:43 GMT+08:00 yang, xing  g.y...@dell.com>>:
> In the original backup API design, volume_id is a required field.  In the
> CLI, volume_id is positional and required as well.  So when I added support
> to backup from a snapshot, I added snapshot_id as an optional field in the
> request body of the backup API.  While backup is in process, you cannot
> delete the volume.  Backup from snapshot and backup from volume are using
> the same API.  So I think volume status should be changed to “backing-up”
> to be consistent.  Now I’m thinking the status of the snapshot should be
> changed to “backing-up” too if snapshot_id is provided.
>
> Thanks,
> Xing
>
>
> 
> From: 王玺源 [wangxiyuan1...@gmail.com]
> Sent: Thursday, March 2, 2017 10:21 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [cinder] Create backup with snapshots
>
> Hi cinder team:
> We met a problem about backup create recently.
>
> The backup can be created from volumes or snapshots. In the both cases,
> the volume' s status is set to 'backing-up'.
>
> But as I know, when users create backup with snapshots, the volume is not
> used(Correct me if I'm wrong). So why the volume's status is changed ?
> Should it keep available? It's a little strange that the volume is
> "backing-up" but actually only the snapshot is used for backup creation.
> the volume in "backing-up" means that it can't be used for some other
> actions. Such as: attach, delete, export to image, extend, create from
> volume, create backup from volume and so on.
>
> So is there any reason we changed the volume' status here? Or is there any
> third part driver need the volume's status must be "backing-up" when create
> backup from snapshots?
>
> 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
>
__
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] [octavia] Octavia PTG summary - Cross-project teams (e-mail 1 of 2)

[Michael Johnson]

Some of the Octavia team attended the first OpenStack Project Team Gathering
(PTG) held in Atlanta the week of February 27th.  Below is a summary of the
notes we kept in the Octavia etherpad here:
https://etherpad.openstack.org/p/octavia-ptg-pike

This e-mail details discussions we had with the cross-project teams.  A
follow-up e-mail will cover topics the Octavia team covered.

Sorry this is a bit long.  Octavia collaborates with a lot of OpenStack!  I
want to thank the cross-project teams for the warm and supportive reception
the Octavia team received.

Michael

Documentation team

  * Attended the discussion about "distributed documentation repositories"
to voice our support for this model.  Designate was also vocal in their
support of moving more of the documentation into the project repositories.
  * I proposed an approach for managing distributed documentation
repositories similar to how i18n manages localization for the projects.  We
agreed to pursue moving the administrator guide to a distributed model like
the installation guide.  I volunteered to capture the discussion from the
room in a docs spec which is here: https://review.openstack.org/#/c/439122/
  * We attended the discussion about the "HA guide".  The discussion in the
room was to keep the main HA guide a high-level guide and allow links out to
the project specific HA guides, such as the one we are planning to write for
Octavia in Pike.
  * Octavia documentation is a priority for Pike (discussion in the octavia
specific email).

Hierarchical quotas

  * The proposal is to store the quota limits in keystone.
  * The projects would still enforce the quotas and handle usage.
  * Octavia team should track this, but I don't think we will implement this
in Pike

Horizon team
  * The horizon team has lost a lot of developers.  They are down from
twelve active cores to three.
  * They are happy to help us with the dashboard, but do not have developer
resource available to work on the neutron-lbaas-dashboard
  * AngularJS is still the path forward for horizon plugins
  * The horizon team will be using the [horizon-plugin] tag for e-mails to
the mailing list that are relevant to teams with a horizon plugin.
  * There are currently test framework gaps for the AngularJS plugins.  They
will be re-examining options.
  * I inquired about the future of quotas in horizon as octavia will now
have quotas separate from neutron's.  It sounds like the quotas in horizon
need some work.  We (octavia) will defer integrating the octavia quotas into
horizon to a future release.

Neutron

  * The DVR "unbound allowed_address_pair with floatingip" bug that has been
open a few cycles is getting attention again
(https://bugs.launchpad.net/neutron/+bug/1583694 among others).
  * Swami has some new DVR patches: https://review.openstack.org/320669 and
https://review.openstack.org/#/c/323618 that he would like us to look at.
  * We provided Swami a list of Octavia/neutron-lbaas scenario tests that
fail with DVR enabled.
  * We discussed the use of the "device owner" property of the ports and the
DVR coding to look for "lbaas" and/or "" device owners in the above patches.
  * Kevin was interested in hearing about the neutron-lbaas pass through
proxy (lbaasv2-proxy) work.  This is the neutron extension that allows load
balancing requests to still be made via neutron for some time (deprecation
cycle).  German has a patch up for review:
https://review.openstack.org/#/c/418530
  * We also had a brief discussion about the plan for the OpenStack Client
Octavia plugin planned for Pike.

OpenStack Ansible (OSA)

  * Octavia patch is up for review: https://review.openstack.org/417210
  * xgerman worked with the OSA team on the patch and tying up the loose
ends.
  * OSA is discussing giving German core on the OSA octavia repo.
  * OSA is investigating alternative packaging format e.g. Snaps (Ubuntu
snappy), Helm, etc.

OpenStack Client (OSC)

  * Dean Troyer and the OSC team were kind enough to spend some time with us
and make sure we are on the right track for our client in Pike.
  * We decided that we will be creating a python-octaviaclient repository
for our OSC plugin.  (request has already been submitted)
  * We discussed how octavia should fit into the OSC terminology and agreed
that the following is a good approach
o loadbalancer (create, etc.)
o loadbalancer listener (CRUD)
o loadbalancer pool (CRUD)
o loadbalancer member (CRUD)
o loadbalancer healthmonitor (CRUD)
o loadbalancer quota? (CRUD) -> can be included in the common quotas
o loadbalancer l7policy (CRUD)
o loadbalancer l7rule (CRUD)
o loadbalancer flavor

Pike Goals

  * Python 3.5 support
o Work has started.  Octavia functional tests still need work.
Neutron-lbaas tests need work.
  * Control plane API via WSGI
o No work for neutron-lbaas as it is under the neutron API.
o Octavia API is already WSGI, just needs the wsgi configuration file
created and devstack updates 

Re: [openstack-dev] [kolla][keystone] better way to rotate and distribution keystone fernet keys in container env

[Jeffrey Zhang]

On Tue, Mar 7, 2017 at 2:09 AM, Matt Fischer  wrote:

> I don't think it would cause an issue if every controller rotated all at
> once. The issues are more along the lines of rotating to key C when there
> are tokens out there that are encrypted with keys A and B. In other words
> over-rotation. As long as your keys are properly staged, do the rotation
> all at once or space them out, should not make any difference.
>

​The issue is "at once".
It takes some time to rotate and distribute the keys. There is one case
that.
controller A and controller B generate a new different keys. Then they copy
the ​key to other by using rsync.

A: 0 1 2 3
B: 0' 1' 2 3

When distributing, the 0/0' and 1/1' may be overrode(rsync hold the delete
file handler and copy it to other one). it will lead to

A: 0' 1' 2 3
B: 0 1 2 3

next rotation, it may become

A: 0' 1' 2' 3
B: 0 1 2 3

after distribute , it become

A: 0 1 2 3
B: 0' 1' 2' 3

Next rotation and distribute, issue happen.

This is a small probability， but it still possible.


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [Murano] ERROR murano.common.engine [-] yaql.language.exceptions.NoMatchingMethodException: No method "values" for receiver None matches supplied arguments

[Waines, Greg]

Thanks for the input Stan.

I re-wrote the Murano Application Packaging … basing it on the Apache Murano 
App on the community catalog … and things are working when I use this updated 
Murano APP.  ☺

HOWEVER … for future reference …
how do I go about seeing the internal HEAT STACK that Murano builds based on 
the Murano Application / Packaging ?

Greg.

From: Stan Lagun 
Date: Monday, March 6, 2017 at 6:22 PM
To: Greg Waines , 
"openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [Murano] ERROR murano.common.engine [-] 
yaql.language.exceptions.NoMatchingMethodException: No method "values" for 
receiver None matches supplied arguments

Greg,

based on the stack trace provided I see that it happened because the Heat stack 
output had wrong value.

If you look at 
https://github.com/openstack/murano/blob/stable/newton/meta/io.murano/Classes/resources/Instance.yaml#L178-L179

  - $netIdToIpsMap: $outputs.get(format('{0}-assigned-ips', 
$this.name))
  - $.ipAddresses: $netIdToIpsMap.values().flatten().distinct()  # <--- 
exception is thrown here

"No method "values" for receiver None..." means that $netIdToIpsMap is null 
(None), which, in turn, means that
ether there in no output value with the name "$instanceName-assigned-ips" or 
its value is null. In both cases it is not
something that can happen under normal conditions. Unfortunately I cannot tell 
why it happened in your case.
I'd start with debugging of the Heat stack in attempt to find out why Heat 
didn't set the output values

Regards,
Stan



On March 6, 2017 at 12:02:59 PM, Waines, Greg 
(greg.wai...@windriver.com) wrote:
We are attempting to integrate a NEWTON-version of MURANO integrated into our 
OpenStack solution.

With a very simple murano package/app, that basically just does a “ 
$.instance.deploy() “ in its deploy method of its main class,
we are getting the following traceback error (see end of email).

Any thoughts / guidance on potential issues ?

( NOTE … we had been trying to run with the secondary rabbit server, but now 
(temporarily) just pointing murano at the core rabbit server to get past some 
issues with not having the secondary rabbit server running. )

thanks in advance,
Greg.


2017-03-06 19:28:08.904 184898 ERROR murano.common.engine [-]
  yaql.language.exceptions.NoMatchingMethodException: No method "values" for 
receiver None matches supplied arguments
  Traceback (most recent call last):
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/37e6dfe1415c4caa9150a53fc18506ef/Classes/Environment.yaml",
 line 120:9 in method deploy of type io.murano.Environment
$.applications.pselect($.deploy())
File 
"/tmp/murano-packages-cache/wrs.titanium.murano.examples.cgcs_guest/0.0.0/b7554a5f915748629da6e425005e1933/Classes/cgcs_guest.yaml",
 line 41:13 in method deploy of type wrs.titanium.murano.examples.cgcs_guest
$.instance.deploy()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/37e6dfe1415c4caa9150a53fc18506ef/Classes/resources/Instance.yaml",
 line 194:9 in method deploy of type io.murano.resources.Instance
$this.endDeploy()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/37e6dfe1415c4caa9150a53fc18506ef/Classes/resources/Instance.yaml",
 line 179:24 in method endDeploy of type io.murano.resources.Instance
$netIdToIpsMap.values().flatten().distinct()
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 53 in 
method evaluate
return value(context)
File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_expression.py", line 
85 in method __call__
return self._parsed_expression.evaluate(context=context)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
165 in method evaluate
return self(utils.NO_VALUE, context, self.engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
156 in method __call__
return super(Statement, self).__call__(receiver, context, engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
37 in method __call__
return context(self.name, engine, receiver, 
context)(*self.args)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 49 in 
method call
name, all_overloads, engine, receiver, data_context, args, kwargs)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method choose_overload
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method 
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File 

Re: [openstack-dev] [Murano] Errors on $.instance.deploy() ... WHEN RUNNING WITHOUT MURANO-AGENT RABBIT

[Waines, Greg]

Thanks Stan … we’ll try this out.

Greg.

From: Stan Lagun 
Date: Monday, March 6, 2017 at 6:10 PM
To: "openstack-dev@lists.openstack.org" , 
Greg Waines 
Cc: "Sun, Yicheng (Jerry)" 
Subject: Re: [openstack-dev] [Murano] Errors on $.instance.deploy() ... WHEN 
RUNNING WITHOUT MURANO-AGENT RABBIT

Hi Greg,

this is yet another similar bug in another place.
Here is the fix for you: https://review.openstack.org/#/c/442198/

Also please consider using LinuxInstance class instead of LinuxMuranoInstance.
LinuxInstance doesn't try to build agent config and push it through cloud-init 
and thus should not
have such problems

Regards,
Stan



On March 6, 2017 at 6:51:11 AM, Waines, Greg 
(greg.wai...@windriver.com) wrote:
Hey Stan,

We tried doing the changes from https://review.openstack.org/#/c/441477/
i.e.
changing the first couple of lines in the __init__ of AgentListener in 
agent_listener.py
 class AgentListener(object):
 def __init__(self, name):
-self._enabled = False
-if CONF.engine.disable_murano_agent:
-return
-self._enabled = True
+self._enabled = not CONF.engine.disable_murano_agent
 self._results_queue = str('-execution-results-%s' % name.lower())
 self._subscriptions = {}
 self._receive_thread = None


But still get the following issue: ??? Any suggestions ???
Greg.



2017-03-06 14:24:01.870 28884 ERROR murano.common.engine [-]
  AttributeError: 'Agent' object has no attribute '_queue'
  Traceback (most recent call last):
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/Environment.yaml",
 line 120:9 in method deploy of type io.murano.Environment
$.applications.pselect($.deploy())
File 
"/tmp/murano-packages-cache/wrs.titanium.murano.examples.VmFip_NoAppDeploy/0.0.0/829a861c408a4516b0589d04cce23248/Classes/VmFip_NoAppDeploy.yaml",
 line 41:13 in method deploy of type 
wrs.titanium.murano.examples.VmFip_NoAppDeploy
$.instance.deploy()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/Instance.yaml",
 line 193:9 in method deploy of type io.murano.resources.Instance
$this.beginDeploy()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/Instance.yaml",
 line 131:28 in method beginDeploy of type io.murano.resources.Instance
$.prepareUserData()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/LinuxMuranoInstance.yaml",
 line 14:19 in method prepareUserData of type 
io.murano.resources.LinuxMuranoInstance
$.generateUserData()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/LinuxMuranoInstance.yaml",
 line 80:39 in method generateUserData of type 
io.murano.resources.LinuxMuranoInstance
$.agent.queueName()
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 58 in 
method evaluate
for d_key, d_value in six.iteritems(value))
File "/usr/lib/python2.7/site-packages/yaql/language/utils.py", line 122 in 
method __init__
self._d = dict(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 58 in 
method 
for d_key, d_value in six.iteritems(value))
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 53 in 
method evaluate
return value(context)
File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_expression.py", line 
85 in method __call__
return self._parsed_expression.evaluate(context=context)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
165 in method evaluate
return self(utils.NO_VALUE, context, self.engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
156 in method __call__
return super(Statement, self).__call__(receiver, context, engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
37 in method __call__
return context(self.name, engine, receiver, 
context)(*self.args)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 49 in 
method call
name, all_overloads, engine, receiver, data_context, args, kwargs)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method choose_overload
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method 
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
  

Re: [openstack-dev] [kolla][keystone] better way to rotate and distribution keystone fernet keys in container env

[Jeffrey Zhang]

On Mon, Mar 6, 2017 at 6:05 PM, Paul Bourke  wrote:

> Two initial ideas:
>
> We could create a specific ansible task to rotate the keys, and document
> that operator should set up a cron job on the deployment node to run this
> periodically.
>
> We could also look at making use of VRRP (keepalived). Potentially the
> cron job could run on every controller, but only take action if it
> identifies it's the one with the VIP.
>
> The second seems preferable to me as it requires no additional effort on
> the part of the operator. Maybe there's problems with this though that I'm
> not thinking of.
>
> -Paul
>

​Thanks Paul, ​

​second seems better. We can implement a file lock to ensure only one
rotate and distribute process is running at the same time.




-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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][tripleo][fuel][kolla][ansible] Ocata Release countdown for R+2 Week, 6-10 March

[Jeffrey Zhang]

Sorry for late. But Kolla project need a new release candidate. I will push
it today.

On Tue, Mar 7, 2017 at 6:27 AM, Doug Hellmann  wrote:

> Excerpts from Doug Hellmann's message of 2017-03-06 11:00:15 -0500:
> > Excerpts from Doug Hellmann's message of 2017-03-02 18:24:12 -0500:
> > >
> > > Release Tasks
> > > -
> > >
> > > Liaisons for cycle-trailing projects should prepare their final
> > > release candidate tags by Monday 6 March. The release team will
> > > prepare a patch showing the final release versions on Wednesday 7
> > > March, and PTLs and liaisons for affected projects should +1. We
> > > will then approve the final releases on Thursday 8 March.
> >
> > We have 13 cycle-trailing deliverables without final releases for Ocata.
> > All have at least one release candidate, so if no new release candidates
> > are proposed *today* I will prepare a patch using these versions as the
> > final and we will approve that early Wednesday.
> >
> > If you know that you need a new release candidate, please speak up now.
> >
> > If you know that you do not need a new release candidate, please also
> > let me know that.
> >
> > Thanks!
> > Doug
> >
> > $ list-deliverables --series ocata --missing-final -v
> > fuel   fuel 11.0.0.0rc1 other
>cycle-trailing
> > instack-undercloud tripleo  6.0.0.0rc1 other
>cycle-trailing
> > kolla-ansible  kolla4.0.0.0rc1 other
>cycle-trailing
> > kolla  kolla4.0.0.0rc1 other
>cycle-trailing
> > openstack-ansible  OpenStackAnsible 15.0.0.0rc1 other
>cycle-trailing
> > os-apply-configtripleo  6.0.0.0rc1 other
>cycle-with-milestones
> > os-cloud-configtripleo  6.0.0.0rc1 other
>cycle-with-milestones
> > os-collect-config  tripleo  6.0.0.0rc1 other
>cycle-with-milestones
> > os-net-config  tripleo  6.0.0.0rc1 other
>cycle-with-milestones
> > os-refresh-config  tripleo  6.0.0.0rc1 other
>cycle-with-milestones
> > tripleo-heat-templates tripleo  6.0.0.0rc1 other
>cycle-trailing
> > tripleo-image-elements tripleo  6.0.0.0rc1 other
>cycle-trailing
> > tripleo-puppet-elementstripleo  6.0.0.0rc1 other
>cycle-trailing
> >
>
> I have lined up patches with the final release tags for all 3 projects.
> Please review and +1 or propose a new patch with an updated release
> candidate.
>
> Ansible: https://review.openstack.org/442138
> Kolla: https://review.openstack.org/442137
> TripleO: https://review.openstack.org/442129
>
> 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
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] VTG Action item sorting

[Antoni Segura Puimedon]

Hi Kuryrs!

Thanks a lot for the hard work in last week's VTG sessions. We created
quite a few Action items and tomorrow will be the time to sort them:

https://trello.com/b/1Ij919E8

I'll try to eventually move it to storyboard, but we need to get some
stuff created.

The session will be held as videoconference (will post recording as
usual) at 13:30 UTC. To join:

https://bluejeans.com/5508709975

You can also join by phone finding a local number in [1] and entering
the meeting id "5508709975" followed by a '#'.

[1] https://www.intercallonline.com/listNumbersByCode.action?confCode=5508709975

__
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][sfc] stable/ocata version

[Jeffrey Zhang]

great. thanks.

On Tue, Mar 7, 2017 at 3:14 AM, Dariusz Śmigiel 
wrote:

> 2017-03-06 11:27 GMT-06:00 Henry Fourie :
> > Gary,
> >
> >Awaiting approval:
> >
> > https://review.openstack.org/#/c/439200
> >
> > -Louis
> >
> It's merged. Stable branch is created.
>
> __
> 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
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] Reminder meeting Mar 7th @ 1500 UTC

[Alex Schultz]

Hey Puppet Folk,

Just a reminder, but we will be having our meeting tomorrow. Please
add something to the meeting etherpad[0] if you have a specific topic
you wish to talk about.

Thanks,
-Alex

[0] https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20170307

__
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] [cross-project][nova][cinder][designate][neutron] Common support-matrix.py

[Mike Perez]

On 15:55 Mar 02, Morales, Victor wrote:
> I got this link[11] from Ankur, apparently Nova and Neutron has already 
> started a common effort
> 
> [11] https://review.openstack.org/#/c/330027/

Thanks for pointing me to this Victor! I have spoke to Doug and Sean Dague in
#openstack-dev about this, and I think it'll be fine for us to keep the current
INI file approach. I've reached out to Ankur to hopefully restore and continue
this effort.

What do Designate and Cinder folks think of this approach?

-- 
Mike Perez


signature.asc
Description: PGP 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] [Murano] ERROR murano.common.engine [-] yaql.language.exceptions.NoMatchingMethodException: No method "values" for receiver None matches supplied arguments

[Stan Lagun]

Greg,

based on the stack trace provided I see that it happened because the Heat
stack output had wrong value.

If you look at
https://github.com/openstack/murano/blob/stable/newton/meta/io.murano/Classes/resources/Instance.yaml#L178-L179

  - $netIdToIpsMap: $outputs.get(format('{0}-assigned-ips', $this.name))
  - $.ipAddresses: $netIdToIpsMap.values().flatten().distinct()  # <---
exception is thrown here

"No method "values" for receiver None..." means that $netIdToIpsMap is null
(None), which, in turn, means that
ether there in no output value with the name "$instanceName-assigned-ips"
or its value is null. In both cases it is not
something that can happen under normal conditions. Unfortunately I cannot
tell why it happened in your case.
I'd start with debugging of the Heat stack in attempt to find out why Heat
didn't set the output values

Regards,
Stan


On March 6, 2017 at 12:02:59 PM, Waines, Greg (greg.wai...@windriver.com)
wrote:

We are attempting to integrate a NEWTON-version of MURANO integrated into
our OpenStack solution.



With a very simple murano package/app, that basically just does a “
$.instance.deploy() “ in its deploy method of its main class,

we are getting the following traceback error (see end of email).



Any thoughts / guidance on potential issues ?



( NOTE … we had been trying to run with the secondary rabbit server, but
now (temporarily) just pointing murano at the core rabbit server to get
past some issues with not having the secondary rabbit server running. )



thanks in advance,

Greg.





2017-03-06 19:28:08.904 184898 ERROR murano.common.engine [-]

  yaql.language.exceptions.NoMatchingMethodException: No method "values"
for receiver None matches supplied arguments

  Traceback (most recent call last):

File
"/tmp/murano-packages-cache/io.murano/0.0.0/37e6dfe1415c4caa9150a53fc18506ef/Classes/Environment.yaml",
line 120:9 in method deploy of type io.murano.Environment

$.applications.pselect($.deploy())

File
"/tmp/murano-packages-cache/wrs.titanium.murano.examples.cgcs_guest/0.0.0/b7554a5f915748629da6e425005e1933/Classes/cgcs_guest.yaml",
line 41:13 in method deploy of type wrs.titanium.murano.examples.cgcs_guest

$.instance.deploy()

File
"/tmp/murano-packages-cache/io.murano/0.0.0/37e6dfe1415c4caa9150a53fc18506ef/Classes/resources/Instance.yaml",
line 194:9 in method deploy of type io.murano.resources.Instance

$this.endDeploy()

File
"/tmp/murano-packages-cache/io.murano/0.0.0/37e6dfe1415c4caa9150a53fc18506ef/Classes/resources/Instance.yaml",
line 179:24 in method endDeploy of type io.murano.resources.Instance

$netIdToIpsMap.values().flatten().distinct()

File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 53
in method evaluate

return value(context)

File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_expression.py",
line 85 in method __call__

return self._parsed_expression.evaluate(context=context)

File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py",
line 165 in method evaluate

return self(utils.NO_VALUE, context, self.engine)

File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py",
line 156 in method __call__

return super(Statement, self).__call__(receiver, context, engine)

File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py",
line 37 in method __call__

return context(self.name, engine, receiver, context)(*self.args)

File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line
65 in method 

data_context, use_convention, function_filter)

File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line
49 in method call

name, all_overloads, engine, receiver, data_context, args, kwargs)

File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line
117 in method choose_overload

args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))

File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line
117 in method 

args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))

File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line
113 in method 

and not isinstance(arg, expressions.Constant))

File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py",
line 37 in method __call__

return context(self.name, engine, receiver, context)(*self.args)

File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line
65 in method 

data_context, use_convention, function_filter)

File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line
49 in method call

name, all_overloads, engine, receiver, data_context, args, kwargs)



File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line
117 in method choose_overload

args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))

Re: [openstack-dev] [Murano] Errors on $.instance.deploy() ... WHEN RUNNING WITHOUT MURANO-AGENT RABBIT

[Stan Lagun]

Hi Greg,

this is yet another similar bug in another place.
Here is the fix for you: https://review.openstack.org/#/c/442198/

Also please consider using LinuxInstance class instead of
LinuxMuranoInstance.
LinuxInstance doesn't try to build agent config and push it through
cloud-init and thus should not
have such problems

Regards,
Stan


On March 6, 2017 at 6:51:11 AM, Waines, Greg (greg.wai...@windriver.com)
wrote:

Hey Stan,



We tried doing the changes from https://review.openstack.org/#/c/441477/

i.e.

changing the first couple of lines in the __init__ of AgentListener in
agent_listener.py

 class AgentListener(object):

 def __init__(self, name):

-self._enabled = False

-if CONF.engine.disable_murano_agent:

-return

-self._enabled = True

+self._enabled = not CONF.engine.disable_murano_agent

 self._results_queue = str('-execution-results-%s' % name.lower())

 self._subscriptions = {}

 self._receive_thread = None





But still get the following issue: ??? Any suggestions ???

Greg.







2017-03-06 14:24:01.870 28884 ERROR murano.common.engine [-]

  AttributeError: 'Agent' object has no attribute '_queue'

  Traceback (most recent call last):

File
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/Environment.yaml",
line 120:9 in method deploy of type io.murano.Environment

$.applications.pselect($.deploy())

File
"/tmp/murano-packages-cache/wrs.titanium.murano.examples.VmFip_NoAppDeploy/0.0.0/829a861c408a4516b0589d04cce23248/Classes/VmFip_NoAppDeploy.yaml",
line 41:13 in method deploy of type
wrs.titanium.murano.examples.VmFip_NoAppDeploy

$.instance.deploy()

File
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/Instance.yaml",
line 193:9 in method deploy of type io.murano.resources.Instance

$this.beginDeploy()

File
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/Instance.yaml",
line 131:28 in method beginDeploy of type io.murano.resources.Instance

$.prepareUserData()

File
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/LinuxMuranoInstance.yaml",
line 14:19 in method prepareUserData of type
io.murano.resources.LinuxMuranoInstance

$.generateUserData()

File
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/LinuxMuranoInstance.yaml",
line 80:39 in method generateUserData of type
io.murano.resources.LinuxMuranoInstance

$.agent.queueName()

File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 58
in method evaluate

for d_key, d_value in six.iteritems(value))

File "/usr/lib/python2.7/site-packages/yaql/language/utils.py", line
122 in method __init__

self._d = dict(*args, **kwargs)

File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 58
in method 

for d_key, d_value in six.iteritems(value))

File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 53
in method evaluate

return value(context)

File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_expression.py",
line 85 in method __call__

return self._parsed_expression.evaluate(context=context)

File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py",
line 165 in method evaluate

return self(utils.NO_VALUE, context, self.engine)

File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py",
line 156 in method __call__

return super(Statement, self).__call__(receiver, context, engine)

File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py",
line 37 in method __call__

return context(self.name, engine, receiver, context)(*self.args)

File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line
65 in method 

data_context, use_convention, function_filter)

File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line
49 in method call

name, all_overloads, engine, receiver, data_context, args, kwargs)

File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line
117 in method choose_overload

args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))

File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line
117 in method 

args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))

File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line
113 in method 

and not isinstance(arg, expressions.Constant))

File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py",
line 37 in method __call__

return context(self.name, engine, receiver, context)(*self.args)

File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line
65 in method 

Re: [openstack-dev] [release][tripleo][fuel][kolla][ansible] Ocata Release countdown for R+2 Week, 6-10 March

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-03-06 11:00:15 -0500:
> Excerpts from Doug Hellmann's message of 2017-03-02 18:24:12 -0500:
> > 
> > Release Tasks
> > -
> > 
> > Liaisons for cycle-trailing projects should prepare their final
> > release candidate tags by Monday 6 March. The release team will
> > prepare a patch showing the final release versions on Wednesday 7
> > March, and PTLs and liaisons for affected projects should +1. We
> > will then approve the final releases on Thursday 8 March.
> 
> We have 13 cycle-trailing deliverables without final releases for Ocata.
> All have at least one release candidate, so if no new release candidates
> are proposed *today* I will prepare a patch using these versions as the
> final and we will approve that early Wednesday.
> 
> If you know that you need a new release candidate, please speak up now.
> 
> If you know that you do not need a new release candidate, please also
> let me know that.
> 
> Thanks!
> Doug
> 
> $ list-deliverables --series ocata --missing-final -v
> fuel   fuel 11.0.0.0rc1 other 
>   cycle-trailing
> instack-undercloud tripleo  6.0.0.0rc1 other  
>  cycle-trailing
> kolla-ansible  kolla4.0.0.0rc1 other  
>  cycle-trailing
> kolla  kolla4.0.0.0rc1 other  
>  cycle-trailing
> openstack-ansible  OpenStackAnsible 15.0.0.0rc1 other 
>   cycle-trailing
> os-apply-configtripleo  6.0.0.0rc1 other  
>  cycle-with-milestones
> os-cloud-configtripleo  6.0.0.0rc1 other  
>  cycle-with-milestones
> os-collect-config  tripleo  6.0.0.0rc1 other  
>  cycle-with-milestones
> os-net-config  tripleo  6.0.0.0rc1 other  
>  cycle-with-milestones
> os-refresh-config  tripleo  6.0.0.0rc1 other  
>  cycle-with-milestones
> tripleo-heat-templates tripleo  6.0.0.0rc1 other  
>  cycle-trailing
> tripleo-image-elements tripleo  6.0.0.0rc1 other  
>  cycle-trailing
> tripleo-puppet-elementstripleo  6.0.0.0rc1 other  
>  cycle-trailing
> 

I have lined up patches with the final release tags for all 3 projects.
Please review and +1 or propose a new patch with an updated release
candidate.

Ansible: https://review.openstack.org/442138
Kolla: https://review.openstack.org/442137
TripleO: https://review.openstack.org/442129

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] Centralizing config options and sample patches for stadium projects

[Singh, Aradhana1]

Hello Everyone,
Bug 1563069[1] aims to refactor neutron configuration options to be in one 
place 'neutron/conf'. This effort was started in newton release and four 
patches[2] in neutron are remaining. This bug was discussed earlier on 
openstack-dev mailing list [3].

These patches might affect stadium projects and sample patches can be found in 
[2].

[1] https://bugs.launchpad.net/neutron/+bug/1563069
[2] https://review.openstack.org/#/q/topic:bug/1563069+is:open
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-October/106369.html

Regards,
Aradhana
__
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] Stepping down from Neutron roles

[Nate Johnston]

All,

I have been delaying this long enough... sadly, due to changes in direction I
am no longer able to spend time working on OpenStack, and as such I need to
resign my duties as Services lieutenant, and liaison to the Infra team.  My
time in the Neutron and FWaaS community has been one of the most rewarding
experiences of my career.  Thank you to everyone I met at the summits and who
took the time to work with me on my contributions.  And thank you to the many
of you who have become my personal friends.  If I see an opportunity in the
future to return to OpenStack development I will jump on it in a hot minute.
But until then, I'll be cheering you on from the sidelines.

All the best,

--N.

__
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] [ironic] OpenStack client default ironic API version

[Mario Villaplana]

Hi ironic,

At the PTG, an issue regarding the default version of the ironic API
used in our python-openstackclient plugin was discussed. [0] In short,
the issue is that we default to a very old API version when the user
doesn't otherwise specify it. This limits discoverability of new
features and makes the client more difficult to use for deployments
running the latest version of the code.

We came to the following consensus:

1. For a deprecation period, we should log a warning whenever the user
doesn't specify an API version, informing them of this change.

2. After the deprecation period:

a) OSC baremetal plugin will default to the latest available version

b) Specifying just macroversion will default to latest microversion
within that macroversion (example: --os-baremetal-api-version=1 would
default to 1.31 if 1.31 is the last microversion with 1 macroversion,
even if we have API 2.2 supported)

I have a patch up for review with the deprecation warning:
https://review.openstack.org/442153

Please comment on that patch with any concerns.

We also still have yet to decide what a suitable deprecation period is
for this change, as far as I'm aware. Please respond to this email
with any suggestions on the deprecation period.

Thanks,
Mario


[0] https://etherpad.openstack.org/p/ironic-pike-ptg-operations L30

__
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] introducing python-tripleo-helper

[Paul Belanger]

On Mon, Mar 06, 2017 at 02:28:31PM -0500, Emilien Macchi wrote:
> On Fri, Feb 24, 2017 at 3:02 PM, Gonéri Le Bouder  wrote:
> > Hi all,
> >
> > TL/DR:
> >
> > - use Python to do drive TripleO deployment
> > - RPM based
> > - used to be a bit specific, closer to upstream now (RDO)
> > - unit-test
> > - maybe a good candidate to join the TripleO umbrella
> >
> > Following a discussion with Emilien, I would like to introduce
> > python-tripleo-helper.
> >
> > python-tripleo-helper is a Python library that wrapper all the
> > operations required to get a working TripleO. The initial goal was to
> > have a solution to automate and validate the deployment of TripleO in
> > our lab environment.
> >
> > Since the full deployment flow is based on a modern programming
> > language, it's also possible to write more complex operations.
> >
> > For instance, this is a test that I did some month ago:
> > Once the Overcloud was running, we started a "chaos monkey" thread that
> > was randomly disconnecting controllers. We were running tempest in the
> > main thread to collect results. Python makes all these interactions
> > easy.
> >
> > At this point, we support libvirt and the OpenStack as the target
> > environment. We use a couple of hacks to be able to use a regular
> > OpenStack cloud (OSP7). bare-metal is not supported yet even if it's
> > definitely a low-hanging fruit.
> >
> > python-tripleo-helper relies on RPM packages but we are open to
> > contribution to support the other packaging solutions.
> >
> > Till some weeks ago python-tripleo-helper was not really generical. This
> > is the reason why it's still maintained in the redhat-openstack
> > namespace. Nicolas Hicher pushed a couple of patches to be able to use
> > it with RDO and CentOS, I guess we can now consider a move to the
> > TripleO umbrella.
> 
> Have you investigated what could (and / or couldn't if applies) reside
> in tripleoclient / tripleo-common instead of having a new tool?
> 
> If we found out that we need this new tool in TripleO, let's move it
> upstream. Otherwise, I'm in favor of consolidating tools and re-use
> our existing workflow & client tools.
> 
> Thanks,
> 
So, by quickly looking at the code here and the documentation, I see a lot of
duplicated things with existing tools. For example, the
tripleohelper/undercloud.py file appears to be a re-write of ansible and shade.
While other parts, seem to relate to how nodepool works today.

Would you be open to the idea of porting some of this code to use ansible for
remote code execution?  Additionally, I would strong recommend using shade as
your interface for openstack, over nova API directly.

BTW have you looked at linch-pin[1]? I am sure there is some difference, but
python-tripleo-helper looks very similar to linch-pin.  Maybe it is possible to
extend it.

[1] https://github.com/CentOS-PaaS-SIG/linch-pin

__
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] [Sahara] Cross Project Liaisons

[Telles Nobrega]

Hello Saharans, in the last two or three cycles our team has undergone
 some changes and we need to update our Cross project liaisons.
Currently we have the following setup:

*| Project  |Liaison |*
| Oslo  | Huichun Lu, Elise Gafford |
| Release Management | Telles Nobrega |
| QA| Luigi Toscano  |
| Documentation   |   |
| Stable Branch| Vitaly Gridnev  |
| Vulnerability Mg.| Michael McCune, Vitaly|
| Logging working group| Elise Gafford|
| Infra  | Nikita, Vitaly|
| Product Working Gr   | Elise Gafford|
| I18n  | Nikita Konovalov   |
*| Cross project spec | Michael McCune, Vitaly|*

So, basically we need to update the liaisons for most of the projects,
Nikita and Elise are both working limited on the project and may speak up
if they still want to be liaisons on the projects they are signed up we
will be glad, if not we need to assign new people to them.

Michael is no longer working actively on Sahara so we need to replace him.
Vitaly please let us know what projects do you want to continue working as
liaisons.
I will work as liaison for documentation with Elise (previously agreed on
Sahara meeting) and also arrange the other projects depending on people's
will and availability.

Thanks all,
__
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][diskimage-builder] Status of diskimage-builder

[Gregory Haynes]

On Sat, Mar 4, 2017, at 12:13 PM, Andre Florath wrote:
> Hello!
> 
> Thanks Greg for sharing your thoughts.  The idea of splitting off DIB
> from OpenStack is new for me, therefore I collect some pros and
> cons:
> 
> Stay in OpenStack:
> 
> + Use available OpenStack infrastructure and methods
> + OpenStack should include a possibility to create images for ironic,
>   VMs and docker. (Yes - there are others, but DIB is the best! :-) )
> + Customers use DIB because it's part of OpenStack and for OpenStack
>   (see e.g. [1])
> + Popularity of OpenStack attracts more developers than a separate
>   project (IMHO running DIB as a separate project even lowers the low
>   number of contributors).
> + 'Short Distances' if there are special needs for OpenStack.
> + Some OpenStack projects use DIB - and also use internal 'knowledge'
>   (like build-, run- or test-dependencies) - it would be not that easy
>   to completely separate this in short term.
> 

Ah, I may have not been super clear - I definitely agree that we
wouldn't want to move off of being hosted by OpenStack infra (for all
the reasons you list). There are actually two classes of project hosted
by OpenStack infra - OpenStack projects and OpenStack related projects
which have differing requirements
(https://docs.openstack.org/infra/manual/creators.html#decide-status-of-your-project).
What I've noticed is we tend to align more with the openstack-related
projects in terms of what we ask for / how we develop (e.g. not
following the normal release cycle, not really being a 'deliverable' of
an OpenStack release). AIUI though the distinction of whether you're an
official project team or a related project just distinguishes what
restrictions are placed on you, not whether you can be hosted by
OpenStack infra.

> As a separate project:
> 
> - Possibly less organizational overhead.
> - Independent releases possible.
> - Develop / include / concentrate also for / on other non-OpenStack
>   based virtualization platforms (EC2, Google Cloud, ...)
> - Extend the use cases to something like 'DIB can install a wide range
>   of Linux distributions on everything you want'.
>   Example: DIB Element to install Raspberry Pi [2] (which is currently
>   not the core use-case but shows how flexible DIB is).
> 
> In my opinion the '+' arguments are more important, therefore DIB
> should stay within OpenStack as a sub-project.  I don't really care
> about the master: TripleO, Infra, glance, ...
> 
> 

Out of this list I think infra is really the only one which makes sense.
TripleO is the current setup and makes only slightly more sense than
Glance at this point: we'd be an odd appendage in both situations.
Having been in this situation for some time I tend to agree that it
isn't a big issue it tends to just be a mild annoyance every now and
then. IMO it'd be nice to resolve this issue once and for all, though
:).

> I want to touch an important point: Greg you are right that there are
> only a very few developers contributing for DIB.  One reason
> is IMHO, that it is not very attractive to work on DIB; some examples:
> 
> o The documentation how to set up a DIB development environment [3]
>   is out of date.
> o Testing DIB is nightmare: a developer has no chance to test
>   as it is done in the CI (which is currently setup by other OpenStack
>   projects?). Round-trip times of ~2h - and then it often fails,
>   because of some mirror problem...
> o It takes sometimes very long until a patch is reviewed and merged
>   (e.g. still open since 1y1d [6]; basic refactoring [7] was filed
>   about 9 month ago and still not in the master).
> o There are currently about 100 elements in DIB. Some of them are
>   highly hardware dependent; some are known not to work; a lot of them
>   need refactoring.

I cant agree more on all of this. TBH I think working on docs is
probably the most effective thing someone could do with DIB ATM because,
as you say, that's how you enable people to contribute. The theory is
that this is also what helps with the review latency - ask newer
contributors to help with initial reviews. That being said, I'd be
surprised if the large contributor count grows much unless some of the
use cases change simply because its very much a plumbing tool for many
of our consumers, not something people are looking to drive feature
development in to.

> 
> It is important to work on these topics to make DIB more attractive and
> possible have more contributors.  Discussions about automated
> development environment setup [4] or better developer tests [5] started
> but need more attention and discussions (and maybe a different setting
> than a patch / review).
> In addition we should concentrate on the core functionalities: block
> device setup, minimal system installation, bootloader, kernel and
> ramdisk creation and a stable extensible element interface; drop
> non-core elements or move them to the projects where they are used.
> 

+1

> Kind regards
> 
> Andre
> 
> 
> [1] 

[openstack-dev] [ironic] this week's priorities and subteam reports

[Loo, Ruby]

Hi,

We are magnanimous to present this week's priorities and subteam report for 
Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and 
formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. PTG summary and deciding on Pike priorities: 
https://review.openstack.org/439710
1.1. update subteam list afterwards
2. portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
3. "standalone" (without nova) tests: https://review.openstack.org/#/c/423556/
4. get multi-node grenade job up and running
5. review e-tags spec: https://review.openstack.org/#/c/381991/
6. rebase, review and land node tags: 
https://review.openstack.org/#/q/topic:bug/1526266


Bugs (dtantsur, mjturek)

- Stats (diff between 27 Feb 2017 and 06 Mar 2017)
- Ironic: 232 bugs (+5) + 243 wishlist items (+5). 14 new (-6), 191 in progress 
(+2), 0 critical, 26 high (+2) and 32 incomplete (+3)
- Inspector: 16 bugs (+1) + 26 wishlist items (+3). 2 new (-1), 16 in progress 
(+3), 0 critical, 1 high and 4 incomplete
- Nova bugs with Ironic tag: 13 (+2). 2 new (+2), 0 critical, 0 high

CI refactoring and missing test coverage (dtantsur, lucasagomes)

* trello: https://trello.com/c/c96zb3dm/32-ci-refactoring
- status as of most recent weekly meeting:
- standalone tests proposed by vsaienk0 
https://review.openstack.org/#/c/423556/
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476

Rolling upgrades and grenade-partial (rloo, jlvillal)
=
* trello: 
https://trello.com/c/GAlhSzLm/2-rolling-upgrades-and-grenade-with-multi-node
- status as of most recent weekly meeting:
- patches need reviews: https://review.openstack.org/#/q/topic:bug/1526283.
- Testing work:
- 6-Mar-2017: Multi-node + multi-tenant + grenade job is passing with 
patches
- Currently one patch to devstack remaining to get merged.
- https://review.openstack.org/#/c/440303/
- Big thanks to vsaienk0 for his work! :) +1
- Multinode job random failures due to nova bug: 
https://bugs.launchpad.net/nova/+bug/1670319

Generic boot-from-volume (TheJulia)
===
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- status as of most recent weekly meeting:
- API side changes for volume connector information has a procedural -2 
until we can begin making use of the data in the conductor, but should stil be 
reviewed
- https://review.openstack.org/#/c/214586/
- This change has been rebased on top of the iPXE template update 
revision to support cinder/iscsi booting.
- Boot from volume/storage cinder interface is up for review
- Patch series is in need of being updataed, and validated against the 
data model for volume connection information.
- Hopefully we will have our first meeting this week, please respond to 
the doodle poll http://doodle.com/poll/qwhnpqazmf7fn5ik regarding scheduling.
- 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1559691
- Original volume connection information client patches
- These changes should be expected to land once Pike opens.
- 
https://review.openstack.org/#/q/status:open+project:openstack/python-ironicclient+branch:master+topic:bug/1526231
- we cannot land these until we land Ironic API bits

Driver composition (dtantsur, jroll)

* trello: https://trello.com/c/fTya14y6/14-driver-composition
- gerrit topic: https://review.openstack.org/#/q/status:open+topic:bug/1524745
- status as of most recent weekly meeting:
- TODO as of 6 Mar 2017
- install guide / admin guide docs
- client changes:
- driver commands update: https://review.openstack.org/419274
- node-update update: https://review.openstack.org/#/c/431542/
- talked at PTG about anything missing, path to getting vendor hw types, 
etc. jroll will update with what is left to do.

Rescue mode (JayF / mariojv)

* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- Working in devstack! http://imgur.com/a/dqvE2
- 3/6 status
- ironic patch chain order updated to make reviews easier
- Please review :D
- ironic
- https://review.openstack.org/#/c/350831/ - API/conductor methods
- https://review.openstack.org/#/c/353156/ - rescuewait timeout 
periodic task
- https://review.openstack.org/#/c/400437/ - agent driver patch
- client
- https://review.openstack.org/#/c/408341/ - client support patch - 
potentially needs update
- IPA
- https://review.openstack.org/#/c/423521 - IPA support for CoreOS 

[openstack-dev] [Murano] ERROR murano.common.engine [-] yaql.language.exceptions.NoMatchingMethodException: No method "values" for receiver None matches supplied arguments

[Waines, Greg]

We are attempting to integrate a NEWTON-version of MURANO integrated into our 
OpenStack solution.

With a very simple murano package/app, that basically just does a “ 
$.instance.deploy() “ in its deploy method of its main class,
we are getting the following traceback error (see end of email).

Any thoughts / guidance on potential issues ?

( NOTE … we had been trying to run with the secondary rabbit server, but now 
(temporarily) just pointing murano at the core rabbit server to get past some 
issues with not having the secondary rabbit server running. )

thanks in advance,
Greg.


2017-03-06 19:28:08.904 184898 ERROR murano.common.engine [-]
  yaql.language.exceptions.NoMatchingMethodException: No method "values" for 
receiver None matches supplied arguments
  Traceback (most recent call last):
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/37e6dfe1415c4caa9150a53fc18506ef/Classes/Environment.yaml",
 line 120:9 in method deploy of type io.murano.Environment
$.applications.pselect($.deploy())
File 
"/tmp/murano-packages-cache/wrs.titanium.murano.examples.cgcs_guest/0.0.0/b7554a5f915748629da6e425005e1933/Classes/cgcs_guest.yaml",
 line 41:13 in method deploy of type wrs.titanium.murano.examples.cgcs_guest
$.instance.deploy()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/37e6dfe1415c4caa9150a53fc18506ef/Classes/resources/Instance.yaml",
 line 194:9 in method deploy of type io.murano.resources.Instance
$this.endDeploy()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/37e6dfe1415c4caa9150a53fc18506ef/Classes/resources/Instance.yaml",
 line 179:24 in method endDeploy of type io.murano.resources.Instance
$netIdToIpsMap.values().flatten().distinct()
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 53 in 
method evaluate
return value(context)
File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_expression.py", line 
85 in method __call__
return self._parsed_expression.evaluate(context=context)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
165 in method evaluate
return self(utils.NO_VALUE, context, self.engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
156 in method __call__
return super(Statement, self).__call__(receiver, context, engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
37 in method __call__
return context(self.name, engine, receiver, context)(*self.args)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 49 in 
method call
name, all_overloads, engine, receiver, data_context, args, kwargs)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method choose_overload
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method 
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 113 
in method 
and not isinstance(arg, expressions.Constant))
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
37 in method __call__
return context(self.name, engine, receiver, context)(*self.args)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 49 in 
method call
name, all_overloads, engine, receiver, data_context, args, kwargs)

File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method choose_overload
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method 
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 113 
in method 
and not isinstance(arg, expressions.Constant))
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
37 in method __call__
return context(self.name, engine, receiver, context)(*self.args)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 49 in 
method call
name, all_overloads, engine, receiver, data_context, args, kwargs)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method choose_overload
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File 

[openstack-dev] [tripleo] tripleo-image-elements 6.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

A new release candidate for tripleo-image-elements for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-image-elements/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:


http://git.openstack.org/cgit/openstack/tripleo-image-elements/log/?h=stable/ocata

Release notes for tripleo-image-elements can be found at:

http://docs.openstack.org/releasenotes/tripleo-image-elements/



__
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] preparing final Ocata release

[Emilien Macchi]

tripleo ocata-rc2 has been pushed today: https://review.openstack.org/441964
We fixed 41 bugs in Ocata RC2!

We'll release final ocata on Wednesday: https://review.openstack.org/442129
All ocata-rc2 bugs have been pushed to pike-1. ocata-rc2 is now closed
and pike-1 should be used.

Thanks,

Kudos to Doug for your help as usual.

On Mon, Mar 6, 2017 at 7:51 AM, Emilien Macchi  wrote:
> Hello folks,
>
> I'm currently preparing the final Ocata release for all TripleO projects.
> It means that all unfinished bugs will moved from
> https://launchpad.net/tripleo/+milestone/ocata-rc2 to
> https://launchpad.net/tripleo/+milestone/pike-1.
>
> If you need some patches in stable/ocata, make sure to report a bug in
> Launchpad first and then submit the backport once the patch has been
> merged into master.
> Also, please tag the bug with "ocata-backport-potential", so it's
> easier to track what we want to backport.
>
> Please let me know any concern or feedback asap, I'm working on it today.
>
> Thanks,
> --
> Emilien Macchi



-- 
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] tripleo-puppet-elements 6.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

A new release candidate for tripleo-puppet-elements for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-puppet-elements/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:


http://git.openstack.org/cgit/openstack/tripleo-puppet-elements/log/?h=stable/ocata

Release notes for tripleo-puppet-elements can be found at:

http://docs.openstack.org/releasenotes/tripleo-puppet-elements/



__
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] tripleo-heat-templates 6.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

A new release candidate for tripleo-heat-templates for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-heat-templates/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:


http://git.openstack.org/cgit/openstack/tripleo-heat-templates/log/?h=stable/ocata

Release notes for tripleo-heat-templates can be found at:

http://docs.openstack.org/releasenotes/tripleo-heat-templates/

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

http://bugs.launchpad.net/tripleo

and tag it *ocata-rc-potential* to bring it to the tripleo-heat-templates
release crew's attention.

__
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] instack-undercloud 6.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

A new release candidate for instack-undercloud for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/instack-undercloud/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:


http://git.openstack.org/cgit/openstack/instack-undercloud/log/?h=stable/ocata

Release notes for instack-undercloud can be found at:

http://docs.openstack.org/releasenotes/instack-undercloud/

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

http://bugs.launchpad.net/tripleo

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

__
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] upgrades PTG recap

[Ihar Hrachyshka]

On Mon, Mar 6, 2017 at 10:50 AM, Morales, Victor
 wrote:
> Regarding this testing, is there a place where it was documented, scripted or 
> shared? Something that helps to someone else can take a look.  And in the 
> other hand,  is there a way to simulate a “fake change” for similar releases 
> where didn’t add significant features but we still need to guarantees its 
> functionality.

I don't think Artur shared any write-up. It would be nice to have one
for later reference. Artur, what d'you think?

As for 'fake' change, I am not sure I follow what you mean. If/when we
have gate job covering the scenario, it will be validated on each
patch.

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] [tripleo] introducing python-tripleo-helper

[Emilien Macchi]

On Fri, Feb 24, 2017 at 3:02 PM, Gonéri Le Bouder  wrote:
> Hi all,
>
> TL/DR:
>
> - use Python to do drive TripleO deployment
> - RPM based
> - used to be a bit specific, closer to upstream now (RDO)
> - unit-test
> - maybe a good candidate to join the TripleO umbrella
>
> Following a discussion with Emilien, I would like to introduce
> python-tripleo-helper.
>
> python-tripleo-helper is a Python library that wrapper all the
> operations required to get a working TripleO. The initial goal was to
> have a solution to automate and validate the deployment of TripleO in
> our lab environment.
>
> Since the full deployment flow is based on a modern programming
> language, it's also possible to write more complex operations.
>
> For instance, this is a test that I did some month ago:
> Once the Overcloud was running, we started a "chaos monkey" thread that
> was randomly disconnecting controllers. We were running tempest in the
> main thread to collect results. Python makes all these interactions
> easy.
>
> At this point, we support libvirt and the OpenStack as the target
> environment. We use a couple of hacks to be able to use a regular
> OpenStack cloud (OSP7). bare-metal is not supported yet even if it's
> definitely a low-hanging fruit.
>
> python-tripleo-helper relies on RPM packages but we are open to
> contribution to support the other packaging solutions.
>
> Till some weeks ago python-tripleo-helper was not really generical. This
> is the reason why it's still maintained in the redhat-openstack
> namespace. Nicolas Hicher pushed a couple of patches to be able to use
> it with RDO and CentOS, I guess we can now consider a move to the
> TripleO umbrella.

Have you investigated what could (and / or couldn't if applies) reside
in tripleoclient / tripleo-common instead of having a new tool?

If we found out that we need this new tool in TripleO, let's move it
upstream. Otherwise, I'm in favor of consolidating tools and re-use
our existing workflow & client tools.

Thanks,

> --
> Gonéri Le Bouder
>
> __
> 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
>



-- 
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] [networking-sfc] Stable/Ocata Version

[Cathy Zhang]

Just completed.

Cathy

From: Jeffrey Zhang [mailto:zhang.lei@gmail.com]
Sent: Friday, March 03, 2017 6:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

any update for releasing stable/ocata branch or tag? It is Mar already.

On Tue, Feb 21, 2017 at 1:23 AM, Henry Fourie 
> wrote:
Gary,
   The plan is to have a stable/ocata branch by end of month.

-Louis

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Sunday, February 19, 2017 4:29 AM
To: OpenStack List
Subject: [openstack-dev] [networking-sfc] Stable/Ocata Version

Hi,
When will this repo have a stable/ocata branch?
Thanks
Gary

__
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



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [Openstack-operators] [nova] Ops midcycle Live migration session

[Ala, Raddaoui]

Hi OPS community,


The Ops midcycle is next week. I will be moderating the Nova live migration 
session during that.

I put up together an etherpad as a starting point for the session. At this 
point, Since this is a good opportunity for Nova team to hear back from 
operators and for Operators to provide feedback to nova on 
issues/painpoints/wishlist…

I strongly encourage everyone to fill/put his thoughts in the etherpad[1] where 
relevant before the midcycle so that we have an efficient session.


Best regards,


Ala Raddaoui | DevOps Engineer | OpenStack Innovation Center


[1] https://etherpad.openstack.org/p/MIL-ops-live-migration

__
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][sfc] stable/ocata version

[Dariusz Śmigiel]

2017-03-06 11:27 GMT-06:00 Henry Fourie :
> Gary,
>
>Awaiting approval:
>
> https://review.openstack.org/#/c/439200
>
> -Louis
>
It's merged. Stable branch is created.

__
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] [networking-sfc] Stable/Ocata Version

[Dariusz Śmigiel]

2017-03-06 11:25 GMT-06:00 Henry Fourie :
> Jeffrey,
>
>The branch pull is awaiting approval:
>
> https://review.openstack.org/#/c/439200

Just got merged.

__
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] [Sahara][infra] Jenkins based 3rd party CIs

[James E. Blair]

Telles Nobrega  writes:

> Hello,
>
> we from Sahara use the compatibility layer with Zuulv2.5 and we are
> wondering if with the change to Zuulv3 this compatibility layer will still
> be maintained.
> If the layer is removed it will reflect into some changes on our side and
> we are looking for this information to identify how much work will be
> needed on our CI.

Hi,

If you are referring to the ability to run jobs in Jenkins, no, Zuul
will no longer have direct support for that.

If you are asking about using the zuul-launcher in Zuul v2.5 (which
reads job configurations in jenkins-job-builder and uses Ansible to run
jobs in the same way that Jenkins would), we won't have direct support
for that either (this is part of the reason we are not encouraging
people to use that).

However, in *either* case, we do expect to have some kind of automated
process to convert many jobs written in JJB.  Much of the code that we
wrote for Zuul v2.5 to translate JJB into Ansible should be able to be
reused for that purpose.  The output may not be optimal -- it will
likely be a series of bulky Ansible shell tasks, but we hope it will
accomplish much of the work in an automated fashion so that an operator
will be able to improve the result over time.

You may wish to keep an eye out for periodic updates to our progress
that Robyn Bergeron is planning to send out, such as this one:

  http://lists.openstack.org/pipermail/openstack-dev/2017-March/113148.html

-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

Re: [openstack-dev] [Manila] PTG summary

[Chris Dent]

On Fri, 3 Mar 2017, Ben Swartzlander wrote:


Experimental Features
-
This was a highly contentious issue with strong opinions on both sides. There 
remain good arguments for and against the continued use of "experimental" 
features. It's likely that we will evolve the exact mechanism for 
experimental APIs in the future because the existing mechanism has serious 
flaws. For feature development in general though there is not much support 
for feature branches or other styles of iterating on large features. We 
agreed to follow up on this topic in the weekly meeting to decide how to 
handle future experimental features.


As you may be aware there's some discussion of potential ideas on
how to do experimental features without breaking API compatibility
and stability in the review for the updated stability guidelines:

https://review.openstack.org/421846

The gist is: do it on a different endpoint in the service catalog
while experimental and then migrate it or kill it as needed. That's
just an idea. If you have others would be great to hear them.

--
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] [neutron] upgrades PTG recap

[Morales, Victor]

On 3/6/17, 8:28 AM, "Ihar Hrachyshka"  wrote:

>Hi all,
>
>This is a report on upgrades related topics discussed during PTG in
>Atlanta. A general PTG report from PTL can be found at:
>
>http://lists.openstack.org/pipermail/openstack-dev/2017-February/113032.html
>
>Topics discussed:
>1. OVO progress;
>2. running mixed server versions;
>3. online data migration framework;
>4. impact of new features (multiple port bindings) for mixed
>server execution, and how to deal with it;
>5. gate.
>
>=> OVO progress
>The effort is a bit stalled but slowly progressing. Progress is
>sometimes blocked by external ongoing initiatives: new oslo.db
>enginefacade; other code refactoring. Sometimes we need to back off
>and fix plugin database logic before switching to objects (think of
>lock_for_update removal in all places in current code). The initiative
>is critical only as long as there are other initiatives that would
>benefit from it. At this point, we are mainly looking at multiple port
>bindings feature and its potential impact on our ability to run mixed
>server versions at the same time. Other objects are worth an effort
>but are not critical. There may be other objects during the cycle that
>may be determined critical for rolling upgrades support.
>
>Specifically talking about lock_for_update support in objects layer:
>https://review.openstack.org/#/c/435598/ , Kevin is hesitant to add
>it. Instead we are going to clean up remaining code that uses the
>locking feature, like in https://review.openstack.org/#/c/438144/ . We
>need the same approach applied for quotas.
>
>=> Running mixed server versions
>Initial testing done by Artur showed that it's now possible to execute
>Newton and Ocata server versions in the same environment with some
>success. This is partly the result of OVO work, but also the fact that
>Ocata cycle was short and not rich on new features. We should build on
>top of that to deliver the same for Pike. We should give special
>attention to initiatives that may disrupt the work (multiple port
>bindings and others).

Regarding this testing, is there a place where it was documented, scripted or 
shared? Something that helps to someone else can take a look.  And in the other 
hand,  is there a way to simulate a “fake change” for similar releases where 
didn’t add significant features but we still need to guarantees its 
functionality. 

>
>=> Online data migration framework
>We discussed that in general there are 3 steps needed for online
>migration 1) Declaration of the intent and creating a general
>framework for online migration, 2) CLI for online migration (example
>patch https://review.openstack.org/#/c/432494/) and, 3) The changes
>made in the object layer for online data migration needs to be
>backward compatible. We sat down and looked at specific contract
>migrations from the past as a matter of case study excercise. During
>our discussion we found out that all the migrations might not be
>addressed by the general framework and will require case-by-case code
>to implement the needed transition. Actually, intent for most
>non-obvious contractions would be hard to express in a general way.

It seems like we can completely discard the point number one(the creation of a 
common framework), in other words, online data migration will be analyzed 
case-by-case.

>
>=> Impact of multiple port bindings
>Discussions suggest that the feature may be of high impact for our
>ability to deliver mixed server versions for Ocata->Pike upgrade. This
>is not because of database access not being properly aligned for the
>newly expected feature. Instead, we may hit issues because of the
>nature of the extension usage, that is usually consumed by compute
>component. Once nova switches to using the new extension to drive port
>bindings if the extension is present, and if neutron replies to nova
>that it indeed supports the new extension before all neutron-servers
>are upgraded to Pike, then it may turn out that some data stored in
>the database may not be easily implemented/acted on by older
>neutron-servers.
>
>Ideally, we would instead block any new API requests till the moment
>when all neutron-servers are running the new code, at which point they
>could start advertising the fact on /extensions/ endpoint. That would
>imply that neutron-servers become aware of each other, and extensions
>each of them support and expose. In that case, they could negotiate to
>use the common subset of extensions, and avoid exposing any extensions
>that are not implemented by any other neutron-server. In that case,
>newer servers would still behave as if they don't support new API
>features. Then once the upgrade to the new release is complete,
>neutron-servers could detect the end of upgrade phase (either through
>some external event, like admin initiated signals; or by periodic
>inspection of the server db table) and reload extensions to enable new
>API. I am going to report the 

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2017-03-06 11:37:06 -0600:
> On 3/6/2017 10:28 AM, Ian Y. Choi wrote:
> >
> > +1 and for such discussions including openstack-i...@lists.openstack.org
> > mailing list would be also nice :)
> >
> > On Barcelona Design Summit, there were I18n contributor meetup and I18n
> > team members discussed a lot.
> > One of things was not to translate log-level strings for server projects.
> >
> > Note that such decision was made not because translator time is limited.
> >
> > Log messages are important to better identify which errors are being
> > posed and most operators (+ developers)
> > diagnose and start to solve error situations from the log messages.
> > I18n team previously translated log messages a lot especially thanks to
> > translation contribution from IBM. (AFAIK)
> 
>  From what I remember working on an openstack-based product at IBM years 
> ago, non-debug messages required translation. That wasn't an openstack 
> requirement, that was an IBM product requirement. And way back when the 
> IBM products had their own plumbing for i18n and did our own 
> translations, and the upstream team of developers pushed and pushed on 
> the translation teams to upstream that work to the community which they 
> eventually did. Now it sounds like the push from IBM for that work has 
> dropped off so no one is really maintaining it.

This matches my memory of the origin of the feature in oslo.i18n to
support log translations.

> > However, after then, there have been some voices - why I18n team
> > translated log messages?
> > After listening to the voices in details, I18n team identified that the
> > background of such voices was related with searching log messages on
> > Internet.
> > Searching English log messages on the Internet will retrieve more number
> > of results than searching translated log messages on the Internet.

This was, perhaps not surprisingly, the primary argument against
implementing log translations originally. As a counter argument,
we actually enabled oslo.log to write to multiple log files, using
a different language for each one. I'm not sure if any of the log
translation work was ever deployed in production, so I have no idea if
anyone took advantage of this aspect of the system.

> > Translating log messages now has two different point of views:
> >  - Will be useful for OpenStack users to better understand log messages
> > in details with translated log messages?
> >  - Or will not be useful for OpenStack users because the original log
> > messages will have better chance to find solutions who occurred the
> > similar cases on the Internet?
> 
> Another IBM-specific product thing is non-debug translated messages get 
> a unique code which isn't translated. So the message is translated, but 
> the code isn't, and the code is what you use to lookup the error on the 
> internet. There was a proposal to do this in openstack many years ago 
> but it never happened.

I've been involved in a bunch of the discussions about log and error
message codes, and so far I haven't seen a proposal that included
a system for allocating unique codes that would scale to a distributed
project like OpenStack. All of them either relied on a central registry
of IDs or on an allocation scheme that didn't take into account the
number of projects we had at the time.

If we do come up with a workable system, I would be reluctant to
go through the effort of implementing it and rolling it out if there
is not wide-spread interest in maintaining the uniqueness of those
log message IDs and ensuring they are useful. Otherwise I expect
we'll end up having a similar conversation to this one.

In Atlanta at the PTG, Eddie Ramirez showed off some work he is
doing to build a reference site based on all of the exception classes
discoverable by scanning OpenStack application code. It's not
complete, but it shows good promise. One especially nice feature
is that it would give us a single well-known URL for each exception
class that we could (a) include in the logs automatically and (b)
extend with helpful information.

> > I18n team discussed with such point of views and on Barcelona Summit the
> > latter point would be more important than the former point.
> > Also, it would be just a point of view from PTL, but it is difficult for
> > me to encourage to contribution translations which have such kind of
> > controversy.
> >
> > Now I would like to listen again to not only developers, but also
> > operators and translators - for log string translation.
> > If someone thinks that the former point would be more important than the
> > latter point, please share through this mailing list to reconsider the
> > current decision.
> >
> >
> > With many thanks,
> >
> > /Ian
> >
> 
> I'm just trying to provide some context. I don't much care about this 
> either way, but it would probably also be good to get input from the 
> product work group, user committee and operators to make sure everyone 

Re: [openstack-dev] [kolla][keystone] better way to rotate and distribution keystone fernet keys in container env

[Matt Fischer]

I don't think it would cause an issue if every controller rotated all at
once. The issues are more along the lines of rotating to key C when there
are tokens out there that are encrypted with keys A and B. In other words
over-rotation. As long as your keys are properly staged, do the rotation
all at once or space them out, should not make any difference.


On Sun, Mar 5, 2017 at 10:52 PM, Jeffrey Zhang 
wrote:

> fix subject typo
>
> On Mon, Mar 6, 2017 at 12:28 PM, Jeffrey Zhang 
> wrote:
>
>> Kolla have support keystone fernet keys. But there are still some
>> topics worth to talk.
>>
>> The key issue is key distribution. Kolla's solution is like
>>
>> * there is a task run frequently by cronjob to check whether
>>   the key should be rotate. This is controlled by
>>   `fernet_token_expiry` variable
>> * When key rotate is required, the task in cron job will generate a
>>   new key by using `keystone-manage fernet-rotate` and distribute all
>>   keys in /etc/keystone/fernet-keys folder to other by using
>>   `rsync --delete`
>>
>> one issue is: there is no global lock in rotate and distribute steps.
>> above command is ran on all controllers. it may cause issues if
>> all controllers run this at the same time.
>>
>> Since we are using Ansible as deployment tools. there is not daemon
>> agent at all to keep rotate and distribution atomic. Is there any
>> easier way to implement a global lock?
>>
>> possible solution:
>> 1. configure cron job with different time on each controller
>> 2. implement a global lock? ( no idea how )
>>
>> [0] https://docs.openstack.org/admin-guide/identity-fernet-token-faq.html
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> 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] [Openstack-operators] Ops midcycle Live migration session

[Ala, Raddaoui]

Hi OPS community,


The Ops midcycle is next week. I will be moderating the Nova live migration 
session during that.

I put up together an etherpad as a starting point for the session. At this 
point, Since this is a good opportunity for Nova team to hear back from 
operators and for Operators to provide feedback to nova on 
issues/painpoints/wishlist…

I strongly encourage everyone to fill/put his thoughts in the etherpad[1] where 
relevant before the midcycle so that we have an efficient session.


Best regards,


Ala Raddaoui | DevOps Engineer | OpenStack Innovation Center


[1] https://etherpad.openstack.org/p/MIL-ops-live-migration

__
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] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Matt Riedemann]

On 3/6/2017 10:28 AM, Ian Y. Choi wrote:


+1 and for such discussions including openstack-i...@lists.openstack.org
mailing list would be also nice :)

On Barcelona Design Summit, there were I18n contributor meetup and I18n
team members discussed a lot.
One of things was not to translate log-level strings for server projects.

Note that such decision was made not because translator time is limited.

Log messages are important to better identify which errors are being
posed and most operators (+ developers)
diagnose and start to solve error situations from the log messages.
I18n team previously translated log messages a lot especially thanks to
translation contribution from IBM. (AFAIK)


From what I remember working on an openstack-based product at IBM years 
ago, non-debug messages required translation. That wasn't an openstack 
requirement, that was an IBM product requirement. And way back when the 
IBM products had their own plumbing for i18n and did our own 
translations, and the upstream team of developers pushed and pushed on 
the translation teams to upstream that work to the community which they 
eventually did. Now it sounds like the push from IBM for that work has 
dropped off so no one is really maintaining it.



However, after then, there have been some voices - why I18n team
translated log messages?
After listening to the voices in details, I18n team identified that the
background of such voices was related with searching log messages on
Internet.
Searching English log messages on the Internet will retrieve more number
of results than searching translated log messages on the Internet.

Translating log messages now has two different point of views:
 - Will be useful for OpenStack users to better understand log messages
in details with translated log messages?
 - Or will not be useful for OpenStack users because the original log
messages will have better chance to find solutions who occurred the
similar cases on the Internet?


Another IBM-specific product thing is non-debug translated messages get 
a unique code which isn't translated. So the message is translated, but 
the code isn't, and the code is what you use to lookup the error on the 
internet. There was a proposal to do this in openstack many years ago 
but it never happened.




I18n team discussed with such point of views and on Barcelona Summit the
latter point would be more important than the former point.
Also, it would be just a point of view from PTL, but it is difficult for
me to encourage to contribution translations which have such kind of
controversy.

Now I would like to listen again to not only developers, but also
operators and translators - for log string translation.
If someone thinks that the former point would be more important than the
latter point, please share through this mailing list to reconsider the
current decision.


With many thanks,

/Ian



I'm just trying to provide some context. I don't much care about this 
either way, but it would probably also be good to get input from the 
product work group, user committee and operators to make sure everyone 
is aware of the fact that service logs are no longer translated; this 
was news to me when we were releasing Ocata actually and I was waiting 
for translations for ocata RC2.


--

Thanks,

Matt Riedemann

__
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][sfc] stable/ocata version

[Henry Fourie]

Gary,
   Awaiting approval:
https://review.openstack.org/#/c/439200

-Louis

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Saturday, March 04, 2017 11:01 PM
To: OpenStack List
Subject: [openstack-dev] [neutron][sfc] stable/ocata version

Hi,
We are pretty blocked at the moment with our gating on stable/ocata. This is 
due to the fact that there is no networking-sfc version tagged for ocata.
Is there any ETA for this?
Thanks
Gary

__
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] [networking-sfc] Stable/Ocata Version

[Henry Fourie]

Jeffrey,
   The branch pull is awaiting approval:
https://review.openstack.org/#/c/439200

-Louis

From: Jeffrey Zhang [mailto:zhang.lei@gmail.com]
Sent: Friday, March 03, 2017 6:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

any update for releasing stable/ocata branch or tag? It is Mar already.

On Tue, Feb 21, 2017 at 1:23 AM, Henry Fourie 
> wrote:
Gary,
   The plan is to have a stable/ocata branch by end of month.

-Louis

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Sunday, February 19, 2017 4:29 AM
To: OpenStack List
Subject: [openstack-dev] [networking-sfc] Stable/Ocata Version

Hi,
When will this repo have a stable/ocata branch?
Thanks
Gary

__
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



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Sean Dague]

On 03/06/2017 12:16 PM, Ihar Hrachyshka wrote:
> I have a question: why can't operators just switch to en_US to execute 
> services?
> 
> Another question: what makes log messages so much different from API
> responses? Couldn't you make the same argument that it's easier to
> find a reason for a request failure if the error message is in
> English? Should we then just stop translating any messages and say
> English is the only OpenStack language we recommend?
> 
> I try to see what makes logs so much different from API error
> messages, and why operators cannot pick the right language based on
> their priorities.

I think what I have gathered from the conversation here, and some on IRC
is that the i18n team did some reflection in Barcelona, and found that
the value of providing these translations for log messages was low
enough that they stopped wanting to commit to them.

They removed all that from their system, and pushed deletes to projects
(here is the Nova one I merged - https://review.openstack.org/#/c/439925/).

Without upstream support of these catalogs (and content in the .po
files), there is no reason for projects to have all this plumbing.

It causes quite a bit of confusion to new folks, and trips up lots of
people making changes when they forget about it (and hacking fails them).

-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] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ihar Hrachyshka]

I have a question: why can't operators just switch to en_US to execute services?

Another question: what makes log messages so much different from API
responses? Couldn't you make the same argument that it's easier to
find a reason for a request failure if the error message is in
English? Should we then just stop translating any messages and say
English is the only OpenStack language we recommend?

I try to see what makes logs so much different from API error
messages, and why operators cannot pick the right language based on
their priorities.

On Mon, Mar 6, 2017 at 8:28 AM, Ian Y. Choi  wrote:
> Doug Hellmann wrote on 3/7/2017 12:53 AM:
>>
>> Excerpts from Sean Dague's message of 2017-03-06 09:06:18 -0500:
>>>
>>> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:

 On 2017-03-06 14:03, Sean Dague  wrote:
>
> I'm trying to understand the implications of
> https://review.openstack.org/#/c/439500. And the comment in the linked
> email:
>
> ">> Yes, we decided some time ago to not translate the log files
> anymore and
>>>
>>> thus our tools do not handle them anymore - and in general, we remove
>>> these kind of files."
>
> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> fully removed? Nova currently enforces those things are there -
>
> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> and want to make sure our tools aren't making us do work that the i18n
> team is ignoring and throwing away.

 Sean, this was removed as followup to:


 http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html

 Let me copy Ian as i18n PTL,

 Andreas
>>>
>>> That all seems reasonable, and I'm happy to follow the i18n team's lead
>>> here. It is however a significant reversal of policy, and there is
>>> substantial code infrastructure in projects (like Nova) to support the
>>> old policy.
>>>
>>> So if this is new policy, a much wider dissemination of it would be
>>> welcomed, as it means we can purge this infrastructure from projects
>>> like Nova.
>>>
>>>  -Sean
>>>
>> Yes, we went to a great deal of trouble to enable log translations,
>> so I'm surprised to see it being dropped to quickly.  I don't
>> necessarily disagree with the decision, because I know translator
>> time is limited. But it would be nice to have the discussion here,
>
>
> +1 and for such discussions including openstack-i...@lists.openstack.org
> mailing list would be also nice :)
>
> On Barcelona Design Summit, there were I18n contributor meetup and I18n team
> members discussed a lot.
> One of things was not to translate log-level strings for server projects.
>
> Note that such decision was made not because translator time is limited.
>
> Log messages are important to better identify which errors are being posed
> and most operators (+ developers)
> diagnose and start to solve error situations from the log messages.
> I18n team previously translated log messages a lot especially thanks to
> translation contribution from IBM. (AFAIK)
> However, after then, there have been some voices - why I18n team translated
> log messages?
> After listening to the voices in details, I18n team identified that the
> background of such voices was related with searching log messages on
> Internet.
> Searching English log messages on the Internet will retrieve more number of
> results than searching translated log messages on the Internet.
>
> Translating log messages now has two different point of views:
>  - Will be useful for OpenStack users to better understand log messages in
> details with translated log messages?
>  - Or will not be useful for OpenStack users because the original log
> messages will have better chance to find solutions who occurred the similar
> cases on the Internet?
>
> I18n team discussed with such point of views and on Barcelona Summit the
> latter point would be more important than the former point.
> Also, it would be just a point of view from PTL, but it is difficult for me
> to encourage to contribution translations which have such kind of
> controversy.
>
> Now I would like to listen again to not only developers, but also operators
> and translators - for log string translation.
> If someone thinks that the former point would be more important than the
> latter point, please share through this mailing list to reconsider the
> current decision.
>
>
> With many thanks,
>
> /Ian
>
>
>> instead of on a list most of the community isn't subscribed to, so
>> everyone involved can understand the reason for the change and so
>> the folks who asked for it originally can be included in the
>> conversation. As Sean points out, the policy change has a lot of
>> other implications about how logging is handled throughout the
>> applications.
>>
>> Doug
>>
>> 

Re: [openstack-dev] [openstack-ansible] [nova] Compute node failing to come up in hypervisor list after first reboot

[Lawrence J. Albinson]

Hey Andy,

Thanks again. Yes, it is almost certainly an SSL issue. I re-built with SSL 
turned off and things now work.

In the morning (UK time) I'm going to re-build with SSL on and add 
'insecure=True' to the nova config. I'll report the result when done.

Kindests, Lawrence


From: Andy McCrae
Sent: 06 March 2017 15:14
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack-ansible] [nova] Compute node failing to 
come up in hypervisor list after first reboot

Hey Lawrence,

The nc -z is checking that you can connect to the port, but the error itself 
looks to be related to the handshake when using SSL certificates in rabbitmq.

"getrandom() initialization failed. (_ssl.c:590)" being the important bit 
there. You'll probably find more if you start searching around that area rather 
than the connection failure itself.

On a side note - this sounds like it may well be a bug with SSL certs in 
rabbitmq in OpenStack-Ansible, I'd love to get that fixed if that is the case!

Hope that helps though.

Andy

On 6 March 2017 at 15:38, Lawrence J. Albinson 
> wrote:
I've been chasing a problems with a build for some days now and would greatly 
appreciate any pointers the community can offer.

The build is built of three nodes (infra+storage+compute) each of which is a 
KVM virtual machine.

After installation everything seems fine. However, after rebooting the compute 
node the hypervisor list reports it as being down.

The /var/log/nova/nova-compute.log is filling up with messages of the form:

 2017-03-06 14:13:11.209 4380 ERROR oslo.messaging._drivers.impl_rabbit 
[req-7fa52faa-c21f-4a1c-8413-fddad9e52c2e - - - - -] 
[fd4c494d-1ef5-4502-991f-521f0a8a2bc3] AMQP server on 
172.29.237.147:5671 is unreachable: getrandom() 
initialization failed. (_ssl.c:590). Trying again in 32 seconds. Client port: 
None

I can confirm that 172.29.237.147 is in fact reachable from compute1.

Furthermore,  'nc -z -v -w5 172.29.237.147 5671' reports:

Connection to 172.29.237.147 5671 port [tcp/amqps] succeeded!

Any pointers would be greatly appreciated.

Kind regards, Lawrence

__
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][infra] Any idea why patch is not gating

[Gary Kotton]

Thanks!
439565 was abandoned. Sorry for the trouble


On 3/6/17, 5:32 PM, "Paul Belanger"  wrote:

On Mon, Mar 06, 2017 at 03:44:59PM +, Gary Kotton wrote:
> Hi,
> When we recheck https://review.openstack.org/#/c/388157/ or any patch 
that depends on this one, they just hang. Any idea why?
> Thanks
> Gary

After looking at the zuul debug.log, it appears to be because 439565 [1] 
had an
incorrect Depends-On header, it created a dependency cycle on itself.

I had to rebase and recheck 388157, but it is working now.

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

> __
> 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][infra] Any idea why patch is not gating

[Paul Belanger]

On Mon, Mar 06, 2017 at 03:44:59PM +, Gary Kotton wrote:
> Hi,
> When we recheck https://review.openstack.org/#/c/388157/ or any patch that 
> depends on this one, they just hang. Any idea why?
> Thanks
> Gary

After looking at the zuul debug.log, it appears to be because 439565[1] had an
incorrect Depends-On header, it created a dependency cycle on itself.

I had to rebase and recheck 388157, but it is working now.

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

> __
> 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][sfc][release] stable/ocata version

[Gary Kotton]

Great! Thanks for the update

From: "Armando M." 
Reply-To: OpenStack List 
Date: Monday, March 6, 2017 at 5:03 PM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron][sfc][release] stable/ocata version



On 5 March 2017 at 23:24, Ihar Hrachyshka 
> wrote:
With https://review.openstack.org/#/c/437699/ in, stadium projects
will no longer have any other option but to follow the common
schedule. That change is new for Pike+ so we may still see some issues
with Ocata release process.

The stable branch for Ocata is being cut in [1]. Everything else that targets 
Pike is a go.

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


Ihar

On Sun, Mar 5, 2017 at 8:03 PM, Jeffrey Zhang 
> wrote:
> Add [release] tag in subject.
>
> Do not follow the OpenStack release schedule will cause lots of issues. Like
> requirements changes, patches is merged which should not be merged into
> stable.
>
> It also may break the deploy project release schedule( like Kolla will not
> be
> released until sfc release ocata branch and tag ).
>
> I hope sfc team could follow the OpenStack release schedule, even though it
> may
> cause some cherry-pick, but it is safer and how OpenStack project live.
>
>
> On Sun, Mar 5, 2017 at 3:44 PM, Gary Kotton 
> > wrote:
>>
>> Please note that things are going to start to get messy now – there are
>> changes in neutron that break master and these will affect the cutting of
>> the stable version. One example is https://review.openstack.org/441654
>>
>>
>>
>> So I suggest cutting a stable ASAP and then cherrypicking patches
>>
>>
>>
>> From: Gary Kotton >
>> Reply-To: OpenStack List 
>> >
>> Date: Sunday, March 5, 2017 at 9:36 AM
>>
>>
>> To: OpenStack List 
>> >
>> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
>>
>>
>>
>> Thanks!
>>
>>
>>
>> From: Jeffrey Zhang >
>> Reply-To: OpenStack List 
>> >
>> Date: Sunday, March 5, 2017 at 9:12 AM
>> To: OpenStack List 
>> >
>> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
>>
>>
>>
>> This is talked in [0]. sfc team said
>>
>>
>>
>> > we will pull a stable/ocata branch around end of Feb or early March the
>> > latest.
>>
>>
>>
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-February/112580.html
>>
>>
>>
>> On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton 
>> > wrote:
>>
>> Hi,
>>
>> We are pretty blocked at the moment with our gating on stable/ocata. This
>> is due to the fact that there is no networking-sfc version tagged for ocata.
>>
>> Is there any ETA for this?
>>
>> Thanks
>>
>> Gary
>>
>>
>>
>>
>> __
>> 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
>>
>>
>>
>>
>>
>> --
>>
>> Regards,
>>
>> Jeffrey Zhang
>>
>> Blog: 
>> http://xcodest.me
>>
>>
>> __
>> 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
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: 
> http://xcodest.me
>
> __
> 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] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ian Y. Choi]

Doug Hellmann wrote on 3/7/2017 12:53 AM:

Excerpts from Sean Dague's message of 2017-03-06 09:06:18 -0500:

On 03/06/2017 08:43 AM, Andreas Jaeger wrote:

On 2017-03-06 14:03, Sean Dague  wrote:

I'm trying to understand the implications of
https://review.openstack.org/#/c/439500. And the comment in the linked
email:

">> Yes, we decided some time ago to not translate the log files anymore and

thus our tools do not handle them anymore - and in general, we remove
these kind of files."

Does that mean that all the _LE, _LI, _LW stuff in projects should be
fully removed? Nova currently enforces those things are there -
https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
and want to make sure our tools aren't making us do work that the i18n
team is ignoring and throwing away.

Sean, this was removed as followup to:

http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html

Let me copy Ian as i18n PTL,

Andreas

That all seems reasonable, and I'm happy to follow the i18n team's lead
here. It is however a significant reversal of policy, and there is
substantial code infrastructure in projects (like Nova) to support the
old policy.

So if this is new policy, a much wider dissemination of it would be
welcomed, as it means we can purge this infrastructure from projects
like Nova.

 -Sean


Yes, we went to a great deal of trouble to enable log translations,
so I'm surprised to see it being dropped to quickly.  I don't
necessarily disagree with the decision, because I know translator
time is limited. But it would be nice to have the discussion here,


+1 and for such discussions including openstack-i...@lists.openstack.org 
mailing list would be also nice :)


On Barcelona Design Summit, there were I18n contributor meetup and I18n 
team members discussed a lot.

One of things was not to translate log-level strings for server projects.

Note that such decision was made not because translator time is limited.

Log messages are important to better identify which errors are being 
posed and most operators (+ developers)

diagnose and start to solve error situations from the log messages.
I18n team previously translated log messages a lot especially thanks to 
translation contribution from IBM. (AFAIK)
However, after then, there have been some voices - why I18n team 
translated log messages?
After listening to the voices in details, I18n team identified that the 
background of such voices was related with searching log messages on 
Internet.
Searching English log messages on the Internet will retrieve more number 
of results than searching translated log messages on the Internet.


Translating log messages now has two different point of views:
 - Will be useful for OpenStack users to better understand log messages 
in details with translated log messages?
 - Or will not be useful for OpenStack users because the original log 
messages will have better chance to find solutions who occurred the 
similar cases on the Internet?


I18n team discussed with such point of views and on Barcelona Summit the 
latter point would be more important than the former point.
Also, it would be just a point of view from PTL, but it is difficult for 
me to encourage to contribution translations which have such kind of 
controversy.


Now I would like to listen again to not only developers, but also 
operators and translators - for log string translation.
If someone thinks that the former point would be more important than the 
latter point, please share through this mailing list to reconsider the 
current decision.



With many thanks,

/Ian


instead of on a list most of the community isn't subscribed to, so
everyone involved can understand the reason for the change and so
the folks who asked for it originally can be included in the
conversation. As Sean points out, the policy change has a lot of
other implications about how logging is handled throughout the
applications.

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 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][sfc][release] stable/ocata version

[Armando M.]

On 5 March 2017 at 23:24, Ihar Hrachyshka  wrote:

> With https://review.openstack.org/#/c/437699/ in, stadium projects
> will no longer have any other option but to follow the common
> schedule. That change is new for Pike+ so we may still see some issues
> with Ocata release process.
>

The stable branch for Ocata is being cut in [1]. Everything else that
targets Pike is a go.

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


> Ihar
>
> On Sun, Mar 5, 2017 at 8:03 PM, Jeffrey Zhang 
> wrote:
> > Add [release] tag in subject.
> >
> > Do not follow the OpenStack release schedule will cause lots of issues.
> Like
> > requirements changes, patches is merged which should not be merged into
> > stable.
> >
> > It also may break the deploy project release schedule( like Kolla will
> not
> > be
> > released until sfc release ocata branch and tag ).
> >
> > I hope sfc team could follow the OpenStack release schedule, even though
> it
> > may
> > cause some cherry-pick, but it is safer and how OpenStack project live.
> >
> >
> > On Sun, Mar 5, 2017 at 3:44 PM, Gary Kotton  wrote:
> >>
> >> Please note that things are going to start to get messy now – there are
> >> changes in neutron that break master and these will affect the cutting
> of
> >> the stable version. One example is https://review.openstack.org/441654
> >>
> >>
> >>
> >> So I suggest cutting a stable ASAP and then cherrypicking patches
> >>
> >>
> >>
> >> From: Gary Kotton 
> >> Reply-To: OpenStack List 
> >> Date: Sunday, March 5, 2017 at 9:36 AM
> >>
> >>
> >> To: OpenStack List 
> >> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
> >>
> >>
> >>
> >> Thanks!
> >>
> >>
> >>
> >> From: Jeffrey Zhang 
> >> Reply-To: OpenStack List 
> >> Date: Sunday, March 5, 2017 at 9:12 AM
> >> To: OpenStack List 
> >> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
> >>
> >>
> >>
> >> This is talked in [0]. sfc team said
> >>
> >>
> >>
> >> > we will pull a stable/ocata branch around end of Feb or early March
> the
> >> > latest.
> >>
> >>
> >>
> >> [0]
> >> http://lists.openstack.org/pipermail/openstack-dev/2017-Febr
> uary/112580.html
> >>
> >>
> >>
> >> On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton  wrote:
> >>
> >> Hi,
> >>
> >> We are pretty blocked at the moment with our gating on stable/ocata.
> This
> >> is due to the fact that there is no networking-sfc version tagged for
> ocata.
> >>
> >> Is there any ETA for this?
> >>
> >> Thanks
> >>
> >> Gary
> >>
> >>
> >>
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.op
> enstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> Regards,
> >>
> >> Jeffrey Zhang
> >>
> >> Blog: http://xcodest.me
> >>
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.op
> enstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.op
> enstack.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] [release][tripleo][fuel][kolla][ansible] Ocata Release countdown for R+2 Week, 6-10 March

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-03-02 18:24:12 -0500:
> 
> Release Tasks
> -
> 
> Liaisons for cycle-trailing projects should prepare their final
> release candidate tags by Monday 6 March. The release team will
> prepare a patch showing the final release versions on Wednesday 7
> March, and PTLs and liaisons for affected projects should +1. We
> will then approve the final releases on Thursday 8 March.

We have 13 cycle-trailing deliverables without final releases for Ocata.
All have at least one release candidate, so if no new release candidates
are proposed *today* I will prepare a patch using these versions as the
final and we will approve that early Wednesday.

If you know that you need a new release candidate, please speak up now.

If you know that you do not need a new release candidate, please also
let me know that.

Thanks!
Doug

$ list-deliverables --series ocata --missing-final -v
fuel   fuel 11.0.0.0rc1 other   
cycle-trailing
instack-undercloud tripleo  6.0.0.0rc1 other   
cycle-trailing
kolla-ansible  kolla4.0.0.0rc1 other   
cycle-trailing
kolla  kolla4.0.0.0rc1 other   
cycle-trailing
openstack-ansible  OpenStackAnsible 15.0.0.0rc1 other   
cycle-trailing
os-apply-configtripleo  6.0.0.0rc1 other   
cycle-with-milestones
os-cloud-configtripleo  6.0.0.0rc1 other   
cycle-with-milestones
os-collect-config  tripleo  6.0.0.0rc1 other   
cycle-with-milestones
os-net-config  tripleo  6.0.0.0rc1 other   
cycle-with-milestones
os-refresh-config  tripleo  6.0.0.0rc1 other   
cycle-with-milestones
tripleo-heat-templates tripleo  6.0.0.0rc1 other   
cycle-trailing
tripleo-image-elements tripleo  6.0.0.0rc1 other   
cycle-trailing
tripleo-puppet-elementstripleo  6.0.0.0rc1 other   
cycle-trailing

__
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] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-03-06 09:06:18 -0500:
> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
> > On 2017-03-06 14:03, Sean Dague  wrote:
> >> I'm trying to understand the implications of
> >> https://review.openstack.org/#/c/439500. And the comment in the linked
> >> email:
> >>
> >> ">> Yes, we decided some time ago to not translate the log files anymore 
> >> and
>  thus our tools do not handle them anymore - and in general, we remove
>  these kind of files."
> >>
> >> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> >> fully removed? Nova currently enforces those things are there -
> >> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> >> and want to make sure our tools aren't making us do work that the i18n
> >> team is ignoring and throwing away.
> > 
> > Sean, this was removed as followup to:
> > 
> > http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html
> > 
> > Let me copy Ian as i18n PTL,
> > 
> > Andreas
> 
> That all seems reasonable, and I'm happy to follow the i18n team's lead
> here. It is however a significant reversal of policy, and there is
> substantial code infrastructure in projects (like Nova) to support the
> old policy.
> 
> So if this is new policy, a much wider dissemination of it would be
> welcomed, as it means we can purge this infrastructure from projects
> like Nova.
> 
> -Sean
> 

Yes, we went to a great deal of trouble to enable log translations,
so I'm surprised to see it being dropped to quickly.  I don't
necessarily disagree with the decision, because I know translator
time is limited. But it would be nice to have the discussion here,
instead of on a list most of the community isn't subscribed to, so
everyone involved can understand the reason for the change and so
the folks who asked for it originally can be included in the
conversation. As Sean points out, the policy change has a lot of
other implications about how logging is handled throughout the
applications.

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][infra] Any idea why patch is not gating

[Gary Kotton]

Hi,
When we recheck https://review.openstack.org/#/c/388157/ or any patch that 
depends on this one, they just hang. Any idea why?
Thanks
Gary
__
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][searchlight] When do instances get removed from Searchlight?

[McLellan, Steven]

Storing the data isn't a problem, but one issue we've had with situations like 
this where there should be a default filter (soft_deleted==false) that can be 
overridden is that it's quite hard within the context of the query parser to do 
it, because it involves examining an incoming query to see whether that term 
appears at all which can become difficult when looking at, for instance, 
query_string queries.

It probably would not be too difficult, however, to enforce that if a term 
("soft_deleted") appears as the term in a structured query we remove such a 
default filter - so under the 'normal' case, nova would filter out soft_deleted 
instances as well as other instances invisible due to RBAC rules, but if 
{soft_deleted: false} is present as a query term we'd allow them through.

Steve




On 3/6/17, 8:56 AM, "Balazs Gibizer"  wrote:

>
>
>On Mon, Mar 6, 2017 at 3:06 PM, Lei Zhang  
>wrote:
>> 
>> 
>> On Mon, Mar 6, 2017 at 1:21 AM, Matt Riedemann  
>> wrote:
>>> 
>>> So I'm wondering at what point instances stored in searchlight will 
>>> be removed. Maybe there is already an answer to this and the 
>>> searchlight team can just inform me. Otherwise we might need to 
>>> think about data retention policies and how long a deleted instances 
>>> will be stored in searchlight before it's removed. Again, I'm not 
>>> sure if nova would control this or if it's something searchlight 
>>> supports already.
>>> 
>> 
>> Hi,
>> 
>> Currently Searchlight doesn't capture soft delete notifications and 
>> simply remove instance from ES if real delete notification comes. If 
>> these two kind of notifications can be distinguished we could fix 
>> this issue by marking the document in the ES instead of removing it. 
>> And we also need to capture some extra notifications like 
>> restore(suppose it exists) .
>
>Yes, there is instance.restore notification [1] to match 
>instance.soft_delete.
>
>Cheers,
>gibi
>
>[1] https://review.openstack.org/#/c/331972/
>> 
>> About data retention policies, I'm not sure if something like ttl to 
>> define how long a deleted instance should be stored in searchlight is 
>> enough. I know Nova has cli to purge the database about deleted 
>> instances, if there are no notification emitted for these operations, 
>> it's impossible for searchlight to know when these delete instances 
>> are removed.
>
>
>__
>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] [openstack-ansible] [nova] Compute node failing to come up in hypervisor list after first reboot

[Andy McCrae]

Hey Lawrence,

The nc -z is checking that you can connect to the port, but the error
itself looks to be related to the handshake when using SSL certificates in
rabbitmq.

"getrandom() initialization failed. (_ssl.c:590)" being the important bit
there. You'll probably find more if you start searching around that area
rather than the connection failure itself.

On a side note - this sounds like it may well be a bug with SSL certs in
rabbitmq in OpenStack-Ansible, I'd love to get that fixed if that is the
case!

Hope that helps though.

Andy

On 6 March 2017 at 15:38, Lawrence J. Albinson 
wrote:

> I've been chasing a problems with a build for some days now and would
> greatly appreciate any pointers the community can offer.
>
> The build is built of three nodes (infra+storage+compute) each of which is
> a KVM virtual machine.
>
> After installation everything seems fine. However, after rebooting the
> compute node the hypervisor list reports it as being down.
>
> The /var/log/nova/nova-compute.log is filling up with messages of the form:
>
>  2017-03-06 14:13:11.209 4380 ERROR oslo.messaging._drivers.impl_rabbit
> [req-7fa52faa-c21f-4a1c-8413-fddad9e52c2e - - - - -]
> [fd4c494d-1ef5-4502-991f-521f0a8a2bc3] AMQP server on 172.29.237.147:5671
> is unreachable: getrandom() initialization failed. (_ssl.c:590). Trying
> again in 32 seconds. Client port: None
>
> I can confirm that 172.29.237.147 is in fact reachable from compute1.
>
> Furthermore,  'nc -z -v -w5 172.29.237.147 5671' reports:
>
> Connection to 172.29.237.147 5671 port [tcp/amqps] succeeded!
>
> Any pointers would be greatly appreciated.
>
> Kind regards, Lawrence
>
> __
> 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][searchlight] When do instances get removed from Searchlight?

[Balazs Gibizer]

On Mon, Mar 6, 2017 at 3:06 PM, Lei Zhang  
wrote:



On Mon, Mar 6, 2017 at 1:21 AM, Matt Riedemann  
wrote:


So I'm wondering at what point instances stored in searchlight will 
be removed. Maybe there is already an answer to this and the 
searchlight team can just inform me. Otherwise we might need to 
think about data retention policies and how long a deleted instances 
will be stored in searchlight before it's removed. Again, I'm not 
sure if nova would control this or if it's something searchlight 
supports already.




Hi,

Currently Searchlight doesn't capture soft delete notifications and 
simply remove instance from ES if real delete notification comes. If 
these two kind of notifications can be distinguished we could fix 
this issue by marking the document in the ES instead of removing it. 
And we also need to capture some extra notifications like 
restore(suppose it exists) .


Yes, there is instance.restore notification [1] to match 
instance.soft_delete.


Cheers,
gibi

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


About data retention policies, I'm not sure if something like ttl to 
define how long a deleted instance should be stored in searchlight is 
enough. I know Nova has cli to purge the database about deleted 
instances, if there are no notification emitted for these operations, 
it's impossible for searchlight to know when these delete instances 
are removed.



__
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] [Murano] Errors on $.instance.deploy() ... WHEN RUNNING WITHOUT MURANO-AGENT RABBIT

[Waines, Greg]

Hey Stan,

We tried doing the changes from https://review.openstack.org/#/c/441477/
i.e.
changing the first couple of lines in the __init__ of AgentListener in 
agent_listener.py
 class AgentListener(object):
 def __init__(self, name):
-self._enabled = False
-if CONF.engine.disable_murano_agent:
-return
-self._enabled = True
+self._enabled = not CONF.engine.disable_murano_agent
 self._results_queue = str('-execution-results-%s' % name.lower())
 self._subscriptions = {}
 self._receive_thread = None


But still get the following issue: ??? Any suggestions ???
Greg.



2017-03-06 14:24:01.870 28884 ERROR murano.common.engine [-]
  AttributeError: 'Agent' object has no attribute '_queue'
  Traceback (most recent call last):
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/Environment.yaml",
 line 120:9 in method deploy of type io.murano.Environment
$.applications.pselect($.deploy())
File 
"/tmp/murano-packages-cache/wrs.titanium.murano.examples.VmFip_NoAppDeploy/0.0.0/829a861c408a4516b0589d04cce23248/Classes/VmFip_NoAppDeploy.yaml",
 line 41:13 in method deploy of type 
wrs.titanium.murano.examples.VmFip_NoAppDeploy
$.instance.deploy()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/Instance.yaml",
 line 193:9 in method deploy of type io.murano.resources.Instance
$this.beginDeploy()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/Instance.yaml",
 line 131:28 in method beginDeploy of type io.murano.resources.Instance
$.prepareUserData()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/LinuxMuranoInstance.yaml",
 line 14:19 in method prepareUserData of type 
io.murano.resources.LinuxMuranoInstance
$.generateUserData()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/LinuxMuranoInstance.yaml",
 line 80:39 in method generateUserData of type 
io.murano.resources.LinuxMuranoInstance
$.agent.queueName()
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 58 in 
method evaluate
for d_key, d_value in six.iteritems(value))
File "/usr/lib/python2.7/site-packages/yaql/language/utils.py", line 122 in 
method __init__
self._d = dict(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 58 in 
method 
for d_key, d_value in six.iteritems(value))
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 53 in 
method evaluate
return value(context)
File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_expression.py", line 
85 in method __call__
return self._parsed_expression.evaluate(context=context)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
165 in method evaluate
return self(utils.NO_VALUE, context, self.engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
156 in method __call__
return super(Statement, self).__call__(receiver, context, engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
37 in method __call__
return context(self.name, engine, receiver, context)(*self.args)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 49 in 
method call
name, all_overloads, engine, receiver, data_context, args, kwargs)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method choose_overload
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method 
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 113 
in method 
and not isinstance(arg, expressions.Constant))
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
37 in method __call__
return context(self.name, engine, receiver, context)(*self.args)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 51 in 
method call
result = delegate()
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 142 
in method 
return lambda: delegate()
File "/usr/lib/python2.7/site-packages/yaql/language/specs.py", line 341 in 
method func
six.iteritems(keyword_args)))
File 

Re: [openstack-dev] [cinder] Create backup with snapshots

[yang, xing]

I don't think we should add a separate API for backing up a snapshot.  We could 
do a check in the backup API to see whether snapshot_id is provided or not.  If 
provided, we change the status of the snapshot; otherwise, we change the status 
of the volume as usual.  Changes are needed in backup/api.py and 
backup/manager.py (to change the status back).

Do you want to submit a bug fix for this change?

Thanks,
Xing



From: 王玺源 [wangxiyuan1...@gmail.com]
Sent: Sunday, March 5, 2017 9:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Create backup with snapshots

Thanks, Xing.

I got the history reason now. So is it possible that we can devide the create 
API into two APIs? One is for create backup from volumes, another is from 
snapshots. Then we can control the volumes' and snapshots' status dividually 
and easily.

When create a backup from a large snapshot, such as larger than 1 TB, It will 
costs few hours generally. It's really a problem that the volume is not 
available for such a long time.

2017-03-03 22:43 GMT+08:00 yang, xing 
>:
In the original backup API design, volume_id is a required field.  In the CLI, 
volume_id is positional and required as well.  So when I added support to 
backup from a snapshot, I added snapshot_id as an optional field in the request 
body of the backup API.  While backup is in process, you cannot delete the 
volume.  Backup from snapshot and backup from volume are using the same API.  
So I think volume status should be changed to “backing-up” to be consistent.  
Now I’m thinking the status of the snapshot should be changed to “backing-up” 
too if snapshot_id is provided.

Thanks,
Xing



From: 王玺源 [wangxiyuan1...@gmail.com]
Sent: Thursday, March 2, 2017 10:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [cinder] Create backup with snapshots

Hi cinder team:
We met a problem about backup create recently.

The backup can be created from volumes or snapshots. In the both cases, the 
volume' s status is set to 'backing-up'.

But as I know, when users create backup with snapshots, the volume is not 
used(Correct me if I'm wrong). So why the volume's status is changed ? Should 
it keep available? It's a little strange that the volume is "backing-up" but 
actually only the snapshot is used for backup creation. the volume in 
"backing-up" means that it can't be used for some other actions. Such as: 
attach, delete, export to image, extend, create from volume, create backup from 
volume and so on.

So is there any reason we changed the volume' status here? Or is there any 
third part driver need the volume's status must be "backing-up" when create 
backup from snapshots?

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

[openstack-dev] [openstack-ansible] [nova] Compute node failing to come up in hypervisor list after first reboot

[Lawrence J. Albinson]

I've been chasing a problems with a build for some days now and would greatly 
appreciate any pointers the community can offer.

The build is built of three nodes (infra+storage+compute) each of which is a 
KVM virtual machine.

After installation everything seems fine. However, after rebooting the compute 
node the hypervisor list reports it as being down.

The /var/log/nova/nova-compute.log is filling up with messages of the form:

 2017-03-06 14:13:11.209 4380 ERROR oslo.messaging._drivers.impl_rabbit 
[req-7fa52faa-c21f-4a1c-8413-fddad9e52c2e - - - - -] 
[fd4c494d-1ef5-4502-991f-521f0a8a2bc3] AMQP server on 172.29.237.147:5671 is 
unreachable: getrandom() initialization failed. (_ssl.c:590). Trying again in 
32 seconds. Client port: None

I can confirm that 172.29.237.147 is in fact reachable from compute1.

Furthermore,  'nc -z -v -w5 172.29.237.147 5671' reports:

Connection to 172.29.237.147 5671 port [tcp/amqps] succeeded!

Any pointers would be greatly appreciated.

Kind regards, Lawrence
__
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][searchlight] When do instances get removed from Searchlight?

[Balazs Gibizer]

On Mon, Mar 6, 2017 at 3:06 PM, Zhenyu Zheng 
 wrote:

Hi, Gibi

Yes, soft_delete.end notification didn't got handled in SL, and we 
should do it, but what Matt mean here is deferent, even you 'hard' 
delete an instance the record still exists in DB and user with 
certain role can list it using deleted=true, so we should also do it 
in SL


Yes, that is really different. If SL should be able to return hard 
deleted instances as well then the catching the soft_delete 
notification would not help.


Cheers,
gibi




On Monday, March 6, 2017, Balazs Gibizer 
 wrote:



On Mon, Mar 6, 2017 at 3:09 AM, Zhenyu Zheng 
 wrote:

Hi, Matt

AFAIK, searchlight did delete the record, it catch the 
instance.delete notification and perform the action:

http://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/elasticsearch/plugins/nova/notification_handler.py#n100
-> 
http://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/elasticsearch/plugins/nova/notification_handler.py#n307


Hi,

There is instance.soft_delete legacy notification [2] (delete_type 
== 'soft_delete'). This could be transformed to versioned 
notification along with [3]. So I guess there could be a way to 
distinguish between soft delete and real delete on searchlight side 
based on these notifications.


Cheers,
gibi

[2] 
https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1872

[3] https://review.openstack.org/#/c/410297/


I will double check with others from the SL team, and if it is the 
case, we will try to find a way to solve this ASAP.


Thanks,

Kevin Zheng

On Mon, Mar 6, 2017 at 1:21 AM, Matt Riedemann 
 wrote:
I've posted a spec [1] for nova's integration with searchlight for 
listing instance across multiple cells. One of the open questions 
I have on that is when/how do instances get removed from 
searchlight?


When an instance gets deleted via the compute API today, it's not 
really deleted from the database. It's considered "soft" deleted 
and you can still list (soft) deleted instances from the database 
via the compute API if you're an admin.


Nova will be sending instance.destroy notifications to searchlight 
but we don't really want the ES entry removed because we still 
have to support the compute API contract to list deleted 
instances. Granted, this is a pretty limp contract because there 
is no guarantee that you'll be able to list those deleted 
instances forever because once they get archived (moved to shadow 
tables in the nova database) or purged (hard delete), then they 
are gone from that API query path.


So I'm wondering at what point instances stored in searchlight 
will be removed. Maybe there is already an answer to this and the 
searchlight team can just inform me. Otherwise we might need to 
think about data retention policies and how long a deleted 
instances will be stored in searchlight before it's removed. 
Again, I'm not sure if nova would control this or if it's 
something searchlight supports already.


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

--

Thanks,

Matt Riedemann

__
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] [neutron] upgrades PTG recap

[Ihar Hrachyshka]

Hi all,

This is a report on upgrades related topics discussed during PTG in
Atlanta. A general PTG report from PTL can be found at:

http://lists.openstack.org/pipermail/openstack-dev/2017-February/113032.html

Topics discussed:
1. OVO progress;
2. running mixed server versions;
3. online data migration framework;
4. impact of new features (multiple port bindings) for mixed
server execution, and how to deal with it;
5. gate.

=> OVO progress
The effort is a bit stalled but slowly progressing. Progress is
sometimes blocked by external ongoing initiatives: new oslo.db
enginefacade; other code refactoring. Sometimes we need to back off
and fix plugin database logic before switching to objects (think of
lock_for_update removal in all places in current code). The initiative
is critical only as long as there are other initiatives that would
benefit from it. At this point, we are mainly looking at multiple port
bindings feature and its potential impact on our ability to run mixed
server versions at the same time. Other objects are worth an effort
but are not critical. There may be other objects during the cycle that
may be determined critical for rolling upgrades support.

Specifically talking about lock_for_update support in objects layer:
https://review.openstack.org/#/c/435598/ , Kevin is hesitant to add
it. Instead we are going to clean up remaining code that uses the
locking feature, like in https://review.openstack.org/#/c/438144/ . We
need the same approach applied for quotas.

=> Running mixed server versions
Initial testing done by Artur showed that it's now possible to execute
Newton and Ocata server versions in the same environment with some
success. This is partly the result of OVO work, but also the fact that
Ocata cycle was short and not rich on new features. We should build on
top of that to deliver the same for Pike. We should give special
attention to initiatives that may disrupt the work (multiple port
bindings and others).

=> Online data migration framework
We discussed that in general there are 3 steps needed for online
migration 1) Declaration of the intent and creating a general
framework for online migration, 2) CLI for online migration (example
patch https://review.openstack.org/#/c/432494/) and, 3) The changes
made in the object layer for online data migration needs to be
backward compatible. We sat down and looked at specific contract
migrations from the past as a matter of case study excercise. During
our discussion we found out that all the migrations might not be
addressed by the general framework and will require case-by-case code
to implement the needed transition. Actually, intent for most
non-obvious contractions would be hard to express in a general way.

=> Impact of multiple port bindings
Discussions suggest that the feature may be of high impact for our
ability to deliver mixed server versions for Ocata->Pike upgrade. This
is not because of database access not being properly aligned for the
newly expected feature. Instead, we may hit issues because of the
nature of the extension usage, that is usually consumed by compute
component. Once nova switches to using the new extension to drive port
bindings if the extension is present, and if neutron replies to nova
that it indeed supports the new extension before all neutron-servers
are upgraded to Pike, then it may turn out that some data stored in
the database may not be easily implemented/acted on by older
neutron-servers.

Ideally, we would instead block any new API requests till the moment
when all neutron-servers are running the new code, at which point they
could start advertising the fact on /extensions/ endpoint. That would
imply that neutron-servers become aware of each other, and extensions
each of them support and expose. In that case, they could negotiate to
use the common subset of extensions, and avoid exposing any extensions
that are not implemented by any other neutron-server. In that case,
newer servers would still behave as if they don't support new API
features. Then once the upgrade to the new release is complete,
neutron-servers could detect the end of upgrade phase (either through
some external event, like admin initiated signals; or by periodic
inspection of the server db table) and reload extensions to enable new
API. I am going to report the proposal as RFE and write it up in form
of a spec where we will be able to discuss it in more details.

Since multiple port bindings work is scheduled to land this cycle, we
should work on that proposal in Pike too.

=> Gating
It's still not clear what to do with mixed server version gating, and
apparently we will need to sync again with folks driving it for nova
gate. In the meantime, we may want to continue periodic local
validations of mixed setup to assure nothing is borked.

As for grenade multinode linuxbridge job, there is lack of clear
interest in the subgroup, so I asked Kevin if he is interested in
making it working. Kevin said he will 

[openstack-dev] [neutron] [classifier] New CCF meeting time

[Duarte Cardoso, Igor]

Hi community,

The following text was sent earlier to people that were recently engaged on the 
Common Classification Framework (mainly at the PTG) and also earlier 
contributors to neutron-classifier, I'm now resending this to the 
community-scope, in case someone is very interested in joining our IRC meetings 
but the current time isn't really compatible.

The current IRC meeting time for the CCF is meant to be US friendly. However, 
most of the people now interested in this effort are outside of the US, and 
some have expressed how difficult it is to connect to the meeting on their 
local timezones.

I intend to move the meeting to a time that is compatible with the majority of 
people, since that is the best we can achieve without creating 2 different 
times.

I have created a Doodle where you can specify what times you're available: 
http://doodle.com/poll/9s2meppbkdg7ya7e.

The possibilities right now are from 8am to midnight UTC, since both I and 
David are located at that timezone and would be impossible for us to make it.

At Doodle you can select your own timezone (there's a link at the top-right of 
the table view) so you can view the possibilities and vote for them in local 
time.

I appreciate if you can fill in the Doodle so we can meet more often on IRC, 
thank you!

So far, there is majority for Tuesdays at 2:00 PM.

The pending patch is at https://review.openstack.org/#/c/441068/. It also 
changes from odd Tuesdays to even Tuesdays so we can keep meeting at 
#openstack-meeting.

Best regards,
Igor.

__
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][searchlight] When do instances get removed from Searchlight?

[Lei Zhang]

On Mon, Mar 6, 2017 at 1:21 AM, Matt Riedemann  wrote:

>
> So I'm wondering at what point instances stored in searchlight will be
> removed. Maybe there is already an answer to this and the searchlight team
> can just inform me. Otherwise we might need to think about data retention
> policies and how long a deleted instances will be stored in searchlight
> before it's removed. Again, I'm not sure if nova would control this or if
> it's something searchlight supports already.
>
>
Hi,

Currently Searchlight doesn't capture soft delete notifications and simply
remove instance from ES if real delete notification comes. If these two
kind of notifications can be distinguished we could fix this issue by
marking the document in the ES instead of removing it. And we also need to
capture some extra notifications like restore(suppose it exists) .

About data retention policies, I'm not sure if something like ttl to define
how long a deleted instance should be stored in searchlight is enough. I
know Nova has cli to purge the database about deleted instances, if there
are no notification emitted for these operations, it's impossible for
searchlight to know when these delete instances are removed.
__
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][searchlight] When do instances get removed from Searchlight?

[Zhenyu Zheng]

Hi, Gibi

Yes, soft_delete.end notification didn't got handled in SL, and we should
do it, but what Matt mean here is deferent, even you 'hard' delete an
instance the record still exists in DB and user with certain role can list
it using deleted=true, so we should also do it in SL

On Monday, March 6, 2017, Balazs Gibizer 
wrote:

>
>
> On Mon, Mar 6, 2017 at 3:09 AM, Zhenyu Zheng 
> wrote:
>
>> Hi, Matt
>>
>> AFAIK, searchlight did delete the record, it catch the instance.delete
>> notification and perform the action:
>> http://git.openstack.org/cgit/openstack/searchlight/tree/sea
>> rchlight/elasticsearch/plugins/nova/notification_handler.py#n100
>> -> http://git.openstack.org/cgit/openstack/searchlight/tree/sea
>> rchlight/elasticsearch/plugins/nova/notification_handler.py#n307
>>
>
> Hi,
>
> There is instance.soft_delete legacy notification [2] (delete_type ==
> 'soft_delete'). This could be transformed to versioned notification along
> with [3]. So I guess there could be a way to distinguish between soft
> delete and real delete on searchlight side based on these notifications.
>
> Cheers,
> gibi
>
> [2] https://github.com/openstack/nova/blob/master/nova/compute/a
> pi.py#L1872
> [3] https://review.openstack.org/#/c/410297/
>
>
> I will double check with others from the SL team, and if it is the case,
>> we will try to find a way to solve this ASAP.
>>
>> Thanks,
>>
>> Kevin Zheng
>>
>> On Mon, Mar 6, 2017 at 1:21 AM, Matt Riedemann 
>> wrote:
>>
>>> I've posted a spec [1] for nova's integration with searchlight for
>>> listing instance across multiple cells. One of the open questions I have on
>>> that is when/how do instances get removed from searchlight?
>>>
>>> When an instance gets deleted via the compute API today, it's not really
>>> deleted from the database. It's considered "soft" deleted and you can still
>>> list (soft) deleted instances from the database via the compute API if
>>> you're an admin.
>>>
>>> Nova will be sending instance.destroy notifications to searchlight but
>>> we don't really want the ES entry removed because we still have to support
>>> the compute API contract to list deleted instances. Granted, this is a
>>> pretty limp contract because there is no guarantee that you'll be able to
>>> list those deleted instances forever because once they get archived (moved
>>> to shadow tables in the nova database) or purged (hard delete), then they
>>> are gone from that API query path.
>>>
>>> So I'm wondering at what point instances stored in searchlight will be
>>> removed. Maybe there is already an answer to this and the searchlight team
>>> can just inform me. Otherwise we might need to think about data retention
>>> policies and how long a deleted instances will be stored in searchlight
>>> before it's removed. Again, I'm not sure if nova would control this or if
>>> it's something searchlight supports already.
>>>
>>> [1] https://review.openstack.org/#/c/441692/
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Sean Dague]

On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
> On 2017-03-06 14:03, Sean Dague  wrote:
>> I'm trying to understand the implications of
>> https://review.openstack.org/#/c/439500. And the comment in the linked
>> email:
>>
>> ">> Yes, we decided some time ago to not translate the log files anymore and
 thus our tools do not handle them anymore - and in general, we remove
 these kind of files."
>>
>> Does that mean that all the _LE, _LI, _LW stuff in projects should be
>> fully removed? Nova currently enforces those things are there -
>> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
>> and want to make sure our tools aren't making us do work that the i18n
>> team is ignoring and throwing away.
> 
> Sean, this was removed as followup to:
> 
> http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html
> 
> Let me copy Ian as i18n PTL,
> 
> Andreas

That all seems reasonable, and I'm happy to follow the i18n team's lead
here. It is however a significant reversal of policy, and there is
substantial code infrastructure in projects (like Nova) to support the
old policy.

So if this is new policy, a much wider dissemination of it would be
welcomed, as it means we can purge this infrastructure from projects
like Nova.

-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] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Andreas Jaeger]

On 2017-03-06 14:03, Sean Dague  wrote:
> I'm trying to understand the implications of
> https://review.openstack.org/#/c/439500. And the comment in the linked
> email:
> 
> ">> Yes, we decided some time ago to not translate the log files anymore and
>>> thus our tools do not handle them anymore - and in general, we remove
>>> these kind of files."
> 
> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> fully removed? Nova currently enforces those things are there -
> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> and want to make sure our tools aren't making us do work that the i18n
> team is ignoring and throwing away.

Sean, this was removed as followup to:

http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html

Let me copy Ian as i18n PTL,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Sean Dague]

I'm trying to understand the implications of
https://review.openstack.org/#/c/439500. And the comment in the linked
email:

">> Yes, we decided some time ago to not translate the log files anymore and
>> thus our tools do not handle them anymore - and in general, we remove
>> these kind of files."

Does that mean that all the _LE, _LI, _LW stuff in projects should be
fully removed? Nova currently enforces those things are there -
https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
and want to make sure our tools aren't making us do work that the i18n
team is ignoring and throwing away.

-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

[openstack-dev] [tripleo] preparing final Ocata release

[Emilien Macchi]

Hello folks,

I'm currently preparing the final Ocata release for all TripleO projects.
It means that all unfinished bugs will moved from
https://launchpad.net/tripleo/+milestone/ocata-rc2 to
https://launchpad.net/tripleo/+milestone/pike-1.

If you need some patches in stable/ocata, make sure to report a bug in
Launchpad first and then submit the backport once the patch has been
merged into master.
Also, please tag the bug with "ocata-backport-potential", so it's
easier to track what we want to backport.

Please let me know any concern or feedback asap, I'm working on it today.

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

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

[Flavio Percoco]

On 06/03/17 12:26 +0100, Thierry Carrez wrote:

Hello everyone,

The App Catalog was created early 2015 as a marketplace of pre-packaged
applications that you can deploy using Murano. Initially a demo by
Mirantis, it was converted into an open upstream project team, and
deployed as a "beta" as apps.openstack.org.

Since then it grew additional categories (Glance images, Heat & Tosca
templates), but otherwise did not pick up a lot of steam. The website
(still labeled "beta") features 45 glance images, 6 Tosca templates, 13
heat templates and 94 murano packages (~30% of which are just thin
wrappers around Docker containers). Traffic stats show around 100 visits
per week, 75% of which only read the index page.

In parallel, Docker developed a pretty successful containerized
application marketplace (the Docker Hub), with hundreds of thousands of
regularly-updated apps. Keeping the App Catalog around (including its
thinly-wrapped Docker container Murano packages) make us look like we
are unsuccessfully trying to compete with that ecosystem, while
OpenStack is in fact completely complementary.


This is the part I think is more important when thinking about App Catalog. As a
community, I think we should be working more and more with other communities.
Containers, in general, are a technology we've been embracing for a couple of
years already. We've talked about building bridges between the OpenStack
community and other containers community because we can indeed complement each
other.

I think this is a great opportunity for us to not only adopt an existing
marketplace but also for us to not re-invent the wheel when it comes to shipping
apps that can be consumed by people outside OpenStack. By building containers
for apps in our marketplace and using docker hub, we would not only be
standardazing what we have with an already-known format but we'd also be
building better bridges across the OpenStack community, Docker's community and 
other
COEs' communities.

As it stands right now, I'd be all for doing this change but I'm also curious to
know what other members (especially folks that have worked on App Catalog) think
about it.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP 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] [tc][appcat] The future of the App Catalog

[Thierry Carrez]

Hello everyone,

The App Catalog was created early 2015 as a marketplace of pre-packaged
applications that you can deploy using Murano. Initially a demo by
Mirantis, it was converted into an open upstream project team, and
deployed as a "beta" as apps.openstack.org.

Since then it grew additional categories (Glance images, Heat & Tosca
templates), but otherwise did not pick up a lot of steam. The website
(still labeled "beta") features 45 glance images, 6 Tosca templates, 13
heat templates and 94 murano packages (~30% of which are just thin
wrappers around Docker containers). Traffic stats show around 100 visits
per week, 75% of which only read the index page.

In parallel, Docker developed a pretty successful containerized
application marketplace (the Docker Hub), with hundreds of thousands of
regularly-updated apps. Keeping the App Catalog around (including its
thinly-wrapped Docker container Murano packages) make us look like we
are unsuccessfully trying to compete with that ecosystem, while
OpenStack is in fact completely complementary.

In the past we have retired projects that were dead upstream. The App
Catalog is not in this case: it has an active maintenance team, which
has been successfully maintaining the framework and accepting
applications. If we end up retiring the App Catalog, it would clearly
not be a reflection on that team performance, which has been stellar
despite limited resources. It would be because the beta was arguably not
successful in building an active marketplace of applications, and
because its continuous existence is not a great fit from a strategy
perspective. Such removal would be a first for our community, but I
think it's now time to consider it.

Before we discuss or decide anything at the TC level, I'd like to
collect everyone thoughts (and questions) on this. Please feel free to
reply to this thread (or reach out to me privately if you prefer). Thanks !

-- 
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] [tripleo][diskimage-builder] Status of diskimage-builder

[Luke Hinds]

On Sat, Mar 4, 2017 at 6:13 PM, Andre Florath  wrote:

> Hello!
>
> Thanks Greg for sharing your thoughts.  The idea of splitting off DIB
> from OpenStack is new for me, therefore I collect some pros and
> cons:
>
> Stay in OpenStack:
>
> + Use available OpenStack infrastructure and methods
> + OpenStack should include a possibility to create images for ironic,
>   VMs and docker. (Yes - there are others, but DIB is the best! :-) )
> + Customers use DIB because it's part of OpenStack and for OpenStack
>   (see e.g. [1])
> + Popularity of OpenStack attracts more developers than a separate
>   project (IMHO running DIB as a separate project even lowers the low
>   number of contributors).
> + 'Short Distances' if there are special needs for OpenStack.
> + Some OpenStack projects use DIB - and also use internal 'knowledge'
>   (like build-, run- or test-dependencies) - it would be not that easy
>   to completely separate this in short term.
>
> As a separate project:
>
> - Possibly less organizational overhead.
> - Independent releases possible.
> - Develop / include / concentrate also for / on other non-OpenStack
>   based virtualization platforms (EC2, Google Cloud, ...)
> - Extend the use cases to something like 'DIB can install a wide range
>   of Linux distributions on everything you want'.
>   Example: DIB Element to install Raspberry Pi [2] (which is currently
>   not the core use-case but shows how flexible DIB is).
>
> In my opinion the '+' arguments are more important, therefore DIB
> should stay within OpenStack as a sub-project.  I don't really care
> about the master: TripleO, Infra, glance, ...
>
>
> I want to touch an important point: Greg you are right that there are
> only a very few developers contributing for DIB.  One reason
> is IMHO, that it is not very attractive to work on DIB; some examples:
>
> o The documentation how to set up a DIB development environment [3]
>   is out of date.
> o Testing DIB is nightmare: a developer has no chance to test
>   as it is done in the CI (which is currently setup by other OpenStack
>   projects?). Round-trip times of ~2h - and then it often fails,
>   because of some mirror problem...
> o It takes sometimes very long until a patch is reviewed and merged
>   (e.g. still open since 1y1d [6]; basic refactoring [7] was filed
>   about 9 month ago and still not in the master).
> o There are currently about 100 elements in DIB. Some of them are
>   highly hardware dependent; some are known not to work; a lot of them
>   need refactoring.
>
> It is important to work on these topics to make DIB more attractive and
> possible have more contributors.  Discussions about automated
> development environment setup [4] or better developer tests [5] started
> but need more attention and discussions (and maybe a different setting
> than a patch / review).
> In addition we should concentrate on the core functionalities: block
> device setup, minimal system installation, bootloader, kernel and
> ramdisk creation and a stable extensible element interface; drop
> non-core elements or move them to the projects where they are used.
>
> Kind regards
>
> Andre
>
>
> [1] https://imagefactory.otc.t-systems.com/
> [2] https://github.com/florath/dib-element-raspberrypi3
> [3] https://docs.openstack.org/developer/diskimage-builder/
> developer/index.html
> [4] https://review.openstack.org/#/c/419655/
> [5] https://review.openstack.org/#/c/414347/
> [6] https://review.openstack.org/#/c/287784/
> [7] https://review.openstack.org/#/c/319591/
>
>
> __
> 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
>


Merging into infra sounds pragmatic, especially if a lack of testing / CI
presence is an area that needs improvement. Yolanda from infra has been
very active in DIB as of recent (in terms of CI).

Unless there are strong objections, infra seems a good choice of home to
me.
__
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][tripleo-quickstart] Multiple parallel deployments on a single virthost

[Raoul Scarazzini]

Hi Lars,
trying to the same result, I documented this process [1] named "TripleO
Quickstart Multi-virtual Undercloud" (if you can't access the doc please
ask and I'll enable you).
The base principle is the same, but I need just one patch on oooq, I
actually manage up to 5 different overcloud from the same virthost. What
is different is that I use 5 different undercloud vms. But this keep
things clean and separated, with the same isolation grade you aim.

Hope this can be somehow useful.

[1]
https://docs.google.com/presentation/d/1v2zqrNn2qWtfpRzkJRGbZJ2LXTostaX-O8-gQ6jaPnI/edit#slide=id.p

-- 
Raoul Scarazzini
ra...@redhat.com

On 04/03/2017 05:52, Lars Kellogg-Stedman wrote:
> I've just submitted a slew of changes to tripleo-quickstart with the
> ultimate goal of being able to spin up multiple openstack deployments
> in parallel on the same target virthost.
> 
> The meat of the change is an attempt to clearly separate the virthost
> from the undercloud; we had several tasks that worked only because the
> user name (and working directory) happened to be the same in both
> environments.
> 
> With these changes in place, I am able to rapidly deploy multiple
> tripleo-deployments on a single virthost, each one isolated to a
> particular user account.  I'm using a playbook that includes
> just the libvirt/setup, undercloud-deploy, and overlcoud-* roles.
> This is extremely convenient for some of the work that I'm doing now.
> 
> This does require some pre-configuration on the virthost (each user
> gets their own overcloud bridge) and in the quickstart (each user gets
> their own underlcoud_external_network_cidr).
> 
> - https://review.openstack.org/441559 modify basic test to not require 
> quickstart-extras
> - https://review.openstack.org/441560 use a non-default virthost_user for the 
> basic test
> - https://review.openstack.org/441561 restore support for multiple 
> deployments on virthost
> - https://review.openstack.org/441562 improve generated ssh configuration
> - https://review.openstack.org/441563 derive overcloud_public_vip and 
> overcloud_public_vip6
> - https://review.openstack.org/441564 yaml cleanup and formatting
> - https://review.openstack.org/441565 don't make ssh_config files executable
> - https://review.openstack.org/441566 restrict bashate to files in repository
> - https://review.openstack.org/441567 restrict pep8 to files in repository
> - https://review.openstack.org/441568 fix ansible-lint error ANSIBLE0012
> - https://review.openstack.org/439133 define non_root_group explicitly
> 
> 
> 
> __
> 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] [infra] where the mail-man lives?

[Thierry Carrez]

James E. Blair wrote:
> "bogda...@mail.ru"  writes:
> 
>> The mail-man for the openstack-dev mail list is missing at least 'kolla'
>> and 'development' checkboxes. It would be nice to make its filter case
>> unsensitive as well, so it would match both 'All' and 'all' tags. How
>> could we fix that? Any place to submit a PR?
> 
> Unfortunately that has to be changed through the mailman web interface.
> I've CC'd the folks listed as contacts for the mailing list.

Thanks Jim, missed that one. Topics are created on-demand, by sending
email to openstack-dev-ow...@lists.openstack.org.

I created a "Kolla" topic.

I don't see the point of creating a "development" topic since (1) nobody
uses that prefix and (2) all discussions on openstack-dev should be
about development.

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

[openstack-dev] [nova] notification update week 9

[Balazs Gibizer]

Hi,

As we agreed on the PTG I will send out short status update / 
focus-setting mail about notifications work items to the ML weekly.



Bugs

There are couple of important outstanding bugs:

[High] https://bugs.launchpad.net/nova/+bug/1665263 The legacy 
instance.delete notification is missing for unscheduled instance. This 
is a regression introduced when the instance creation was moved to the 
conductor. Patch has couple of +1s but needs core attention 
https://review.openstack.org/#/c/437222/


[Medium] https://bugs.launchpad.net/nova/+bug/1657428 The instance 
notifications are sent with inconsistent timestamp format. Fix is ready 
for the cores to review https://review.openstack.org/#/c/421981


[Medium] https://bugs.launchpad.net/nova/+bug/1653221 Lazy loaded and 
uninitialized object fields are missing from the notification payloads. 
The patch needs review from the subteam 
https://review.openstack.org/#/c/415857/



Versioned notification transformation
-
Plenty of transformation patches has been rebased to Pike and reviewed 
by the subteam. These are easy to review patches so  let's focus on 
merging the below short list this week:
* https://review.openstack.org/#/c/384922 Transform instance.rebuild 
notification
* https://review.openstack.org/#/c/396621 Transform 
instance.rebuild.error notification
* https://review.openstack.org/#/c/382959 Transform instance.reboot 
notification


There are a long list of patches that needs to be respin to target the 
new Pike blueprint versioned-notification-transformation-pike



Searchlight integration
---
Listing instances
~
Matt proposed a patch to list instances using searchlight 
https://review.openstack.org/#/c/441692/ . Separate ML thread has bee 
started to sort out the open issues: 
http://lists.openstack.org/pipermail/openstack-dev/2017-March/113355.html 
.


bp additional-notification-fields-for-searchlight
~~
4 patch from blueprint additional-notification-fields-for-searchlight 
has been reviewed by the subteam and waiting for core review 
https://review.openstack.org/#/q/label:Code-Review%253E%253D1+status:open+branch:master+topic:bp/additional-notification-fields-for-searchlight


The blueprint needs discussion about how to model BlockDeviceMapping in 
the instance notifications.



Other items
---
Short circuit notification payload generation
~
Code review is ongoing to short circuit notification payload generation 
if the notifications are not configured to be emitted to avoid 
unnecessary load (e.g. db load). There is a generic patch on 
oslo_messaging that needs some iteration 
https://review.openstack.org/#/c/441221 and then the nova patch can be 
adapted to the new oslo feature https://review.openstack.org/#/c/428260/


bp json-schema-for-versioned-notifications
~~~
The implementation progressed in Ocata but the bp hasn't been 
reproposed to Pike yet as we need somebody to pick up the 
implementation work for Pike. 
https://blueprints.launchpad.net/nova/+spec/json-schema-for-versioned-notifications



--
The notification subteam holds it's weekly meeting on Tuesday 17:00 UTC 
on openstack-meeting-4 so the next meeting will be held on 7th of March 
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170307T17


Cheers,
gibi





__
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][keystone] better way to rotate and distribution keystone fernet keys in container env

[Paul Bourke]

Two initial ideas:

We could create a specific ansible task to rotate the keys, and document 
that operator should set up a cron job on the deployment node to run 
this periodically.


We could also look at making use of VRRP (keepalived). Potentially the 
cron job could run on every controller, but only take action if it 
identifies it's the one with the VIP.


The second seems preferable to me as it requires no additional effort on 
the part of the operator. Maybe there's problems with this though that 
I'm not thinking of.


-Paul

On 06/03/17 05:52, Jeffrey Zhang wrote:

fix subject typo

On Mon, Mar 6, 2017 at 12:28 PM, Jeffrey Zhang > wrote:

Kolla have support keystone fernet keys. But there are still some
topics worth to talk.

The key issue is key distribution. Kolla's solution is like

* there is a task run frequently by cronjob to check whether
  the key should be rotate. This is controlled by
  `fernet_token_expiry` variable
* When key rotate is required, the task in cron job will generate a
  new key by using `keystone-manage fernet-rotate` and distribute all
  keys in /etc/keystone/fernet-keys folder to other by using
  `rsync --delete`

one issue is: there is no global lock in rotate and distribute steps.
above command is ran on all controllers. it may cause issues if
all controllers run this at the same time.

Since we are using Ansible as deployment tools. there is not daemon
agent at all to keep rotate and distribution atomic. Is there any
easier way to implement a global lock?

possible solution:
1. configure cron job with different time on each controller
2. implement a global lock? ( no idea how )

[0] https://docs.openstack.org/admin-guide/identity-fernet-token-faq.html


--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me 




--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me 


__
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] [karbor][stackalytics] Karbor Missing Commits in Stackalytics

[Yuval Brik]

On my local Stackalytics run it looks fine as well, but in stackalytics.com it 
doesn't.

Ilya, have you managed to find anything?


--Yuval


From: Zhenguo Niu 
Sent: Wednesday, February 15, 2017 11:21:18 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [karbor][stackalytics] Karbor Missing Commits in 
Stackalytics

hi Ilya,

I set up a local stackalytics and it works well, all git-related stats prior to 
the renaming of Mogan are displayed.

On Thu, Feb 9, 2017 at 9:37 PM, Ilya Shakhat 
> wrote:
Sure, I'll take a look at this.

--Ilya

2017-02-09 13:47 GMT+04:00 Zhenguo Niu 
>:
After the rename of Nimble to Mogan, all git-related stats are lost as well.


http://stackalytics.com/?metric=commits_type=openstack-others=mogan

Ilya, Can you please assist with rectifying this?

On Thu, Feb 9, 2017 at 5:00 PM, Thierry Carrez 
> wrote:
Yuval Brik wrote:
> By looking
> at 
> http://stackalytics.com/?metric=commits=all_type=all=karbor
> 
>  I
> noticed that Karbor has only 195 commits in Stackalytics, while in fact,
> it has 721 commits (438 of them are not Jenkin's merges). It seems like
> this happens because of the past Smaug -> Karbor rename. The cause might
> be the fact that Stackalytics only counts diffs, and older commits are
> already counted for Smaug instead of Karbor, but I'm not sure, and have
> no way of verifying that.
> The problem happens only in the Stackalytics commits and lines of code
> sections, and affects karbor-dashboard and python-karborclient as well.
> The reviews part in Stackalytics seem to be accurate
> ( 
> http://stackalytics.com/?metric=marks=all_type=all=karbor
> 
>  )
>
> Can anyone advise?

I suspect you're right, must be related to the rename. I would have
thought adding aliases would be sufficient:

http://git.openstack.org/cgit/openstack/stackalytics/commit/?id=606df2029ab4d3d03ba43fe6d3884346cb59ef16

Maybe Ilya can shed some light onto this...

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



--
Best Regards,
Zhenguo Niu

__
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




--
Best Regards,
Zhenguo Niu
-
This email and any files transmitted and/or attachments with it are 
confidential and proprietary information of
Toga Networks Ltd., and intended solely for the use of the individual or entity 
to whom they are addressed.
If you have received this email in error please notify the system manager. This 
message contains confidential
information of Toga Networks Ltd., and is intended only for the individual 
named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on
the contents of this information is strictly prohibited.


__
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][searchlight] When do instances get removed from Searchlight?

[Balazs Gibizer]

On Mon, Mar 6, 2017 at 3:09 AM, Zhenyu Zheng 
 wrote:

Hi, Matt

AFAIK, searchlight did delete the record, it catch the 
instance.delete notification and perform the action:

http://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/elasticsearch/plugins/nova/notification_handler.py#n100
-> 
http://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/elasticsearch/plugins/nova/notification_handler.py#n307


Hi,

There is instance.soft_delete legacy notification [2] (delete_type == 
'soft_delete'). This could be transformed to versioned notification 
along with [3]. So I guess there could be a way to distinguish between 
soft delete and real delete on searchlight side based on these 
notifications.


Cheers,
gibi

[2] 
https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1872

[3] https://review.openstack.org/#/c/410297/


I will double check with others from the SL team, and if it is the 
case, we will try to find a way to solve this ASAP.


Thanks,

Kevin Zheng

On Mon, Mar 6, 2017 at 1:21 AM, Matt Riedemann  
wrote:
I've posted a spec [1] for nova's integration with searchlight for 
listing instance across multiple cells. One of the open questions I 
have on that is when/how do instances get removed from searchlight?


When an instance gets deleted via the compute API today, it's not 
really deleted from the database. It's considered "soft" deleted and 
you can still list (soft) deleted instances from the database via 
the compute API if you're an admin.


Nova will be sending instance.destroy notifications to searchlight 
but we don't really want the ES entry removed because we still have 
to support the compute API contract to list deleted instances. 
Granted, this is a pretty limp contract because there is no 
guarantee that you'll be able to list those deleted instances 
forever because once they get archived (moved to shadow tables in 
the nova database) or purged (hard delete), then they are gone from 
that API query path.


So I'm wondering at what point instances stored in searchlight will 
be removed. Maybe there is already an answer to this and the 
searchlight team can just inform me. Otherwise we might need to 
think about data retention policies and how long a deleted instances 
will be stored in searchlight before it's removed. Again, I'm not 
sure if nova would control this or if it's something searchlight 
supports already.


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

--

Thanks,

Matt Riedemann

__
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] [mistral][cinder][keystone] Fixing Mistral & Cinder service type in the catalog

[Renat Akhmerov]

Hi,

There was a patch recently merged ([1]) that works around a bad decision that 
Cinder and Mistral team
(possible someone else too) to include api version in the name of service type 
in the catalog. For
example, for Mistral it was initially “workflow” when we were working on a POC 
of the project but once
we realized that we created a stable API we called it “v2” and changed service 
type to “workflowv2”.
Now we see it was a bad thing to do (see details in the patch).

I wonder if we can do something to get this fixed in long term. Ideally, i’d 
like to make it just “workflow”
again but that seems to be not easy now.

Would appreciate your input.

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



Renat Akhmerov
@Nokia

__
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