[openstack-dev] Etherpad for self-healing

[Furukawa, Yushiro]

Hi everyone,

I am seeing Self-healing scheduled on Tuesday afternoon[1], but the etherpad 
for it is not listed in [2].
I made following etherpad by some chance.  Would it be possible to update 
Etherpads wiki page?
https://etherpad.openstack.org/p/self-healing-ptg-rocky

Best regards,

[1] https://www.openstack.org/ptg/#tab_schedule 
[2] https://wiki.openstack.org/wiki/PTG/Rocky/Etherpads


Yushiro Furukawa




__
OpenStack Development Mailing 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-dashboard 1.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

A new release candidate for octavia-dashboard for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/octavia-dashboard/

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

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


http://git.openstack.org/cgit/openstack/octavia-dashboard/log/?h=stable/queens

Release notes for octavia-dashboard can be found at:

http://docs.openstack.org/releasenotes/octavia-dashboard/

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

https://storyboard.openstack.org/#!/project/909

and tag it *queens-rc-potential* to bring it to the octavia-dashboard
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] [octavia] octavia 2.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

A new release candidate for octavia for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/octavia/

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

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

http://git.openstack.org/cgit/openstack/octavia/log/?h=stable/queens

Release notes for octavia can be found at:

http://docs.openstack.org/releasenotes/octavia/




__
OpenStack Development Mailing 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] [horizon] horizon 13.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

A new release candidate for horizon for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/horizon/

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

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

http://git.openstack.org/cgit/openstack/horizon/log/?h=stable/queens

Release notes for horizon can be found at:

http://docs.openstack.org/releasenotes/horizon/




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

[openstack-dev] [all] [QA] PTG QA Help Room on Monday-Tuesday: open discussion + stestr + tempest plugins

[Ghanshyam Mann]

Hi All,

As you might have notice about QA Help Rooms in mail thread[1], this
is further announcement of the QA Help Room from Monday- Tuesday in
Dublin PTG.

QA team will be present in "Davin Suite" along with infra, stable,
release and other horizontal team [2]. Main idea for conducting the
helproom is to get together and discuss the topuics or any help you
want from QA or knowledge sharing etc.

We are open to discuss any topic during helproom. Along with that we
also have 2 dedicated Topic to cover. Schedule & Details for QA
helproom can be found in QA PTG etherpad [3]

1. "Stestr Sessions followed by Q&A". - Interested people can learn
about stestr, how to use, migrate to stestr. If you have some feedback
or improvement points Or i will say if you need any kind of help on
stestr then, this is good sessions to join. Thanks to matt and
masayuki for giving time for this.

2. "Tempest Plugin, May we Assist you". - We will spend some dedicated
time for Tempest Plugins. There are always many queries about what all
tempest interfaces plugins should use and sometime complain (or many
time :)) Tempest always change their interface and break plugins.
Let's understand the interface change issue and what interfaces
plugins should and should not use. Though we have very clear
documentation for that but still it is good to talk face to face.  If
you want to implement new Tempest plugin, you can ask us how to do or
if you have existing plugin, you can ask for any kind of help/queries.
In addition, feedback/improvement/specific requirement can be
discussed.

3. Open Discussion - Everyone is most welcome to discuss any topic,
learn about QA, help us or get help from us.


.. [1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127407.html
.. [2] http://ptg.openstack.org/ptg.html
.. [3] https://ethercalc.openstack.org/Rocky-PTG-QA-Schedule
https://etherpad.openstack.org/p/qa-rocky-ptg

-gmann

__
OpenStack Development Mailing 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] [QA] Queens Retrospective

[Ghanshyam Mann]

Hi All,

I have started an etherpad for a Queens cycle retrospective for QA -
https://etherpad.openstack.org/p/qa-queens-retrospective

This will be discussed in PTG on Wed 9.30-10.00 AM, so please add your
feedback/comment before that.

Everyone is welcome to add the feedback which help us to improve the
required things in next cycle.

-gmann

__
OpenStack Development Mailing 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] [QA] [all] QA Rocky PTG Planning

[Ghanshyam Mann]

Hi All,

As we are close to PTG, I have prepared the QA PTG Schedule -
https://ethercalc.openstack.org/Rocky-PTG-QA-Schedule

Detail of each sessions can be found in this etherpad -
https://etherpad.openstack.org/p/qa-rocky-ptg

We still have space for more sessions or topic if any of you would
like to add. If so please write those to etherpad with your irc name.
Sessions Scheduled is flexible and we can reschedule based on request
but do let me know before 22nd Feb.

We do have some sessions where we need cross projects interaction and
QA help rooms which i will be publishing separately.

-gmann

On Thu, Jan 18, 2018 at 7:32 PM, Andrea Frittoli
 wrote:
> and the link [1]
>
> [1] https://etherpad.openstack.org/p/qa-rocky-ptg
>
> On Thu, Jan 18, 2018 at 10:28 AM Andrea Frittoli 
> wrote:
>>
>> Dear all,
>>
>> I started the etherpad for planning the QA work in Dublin.
>> Please add your ideas / proposals for sessions and intention of attending.
>> We have a room for the QA team for three full days Wed-Fri.
>>
>> This time I also included a "Request for Sessions" - if anyone would like
>> to discuss a QA related topic with the QA team or do a hands-on / sprint on
>> something feel free to add it in there. We can also handle them in a less
>> unstructured format during the PTG - but if there are a few requests on
>> similar topics we can setup a session on Mon/Tue for everyone interested to
>> attend.
>>
>> Andrea Frittoli (andreaf)
>
>
> __
> OpenStack Development Mailing 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] Release Naming for S - time to suggest a name!

[Paul Belanger]

Hey everybody,

Once again, it is time for us to pick a name for our "S" release.

Since the associated Summit will be in Berlin, the Geographic
Location has been chosen as "Berlin" (State).

Nominations are now open. Please add suitable names to
https://wiki.openstack.org/wiki/Release_Naming/S_Proposals between now
and 2018-03-05 23:59 UTC.

In case you don't remember the rules:

* Each release name must start with the letter of the ISO basic Latin
alphabet following the initial letter of the previous release, starting
with the initial release of "Austin". After "Z", the next name should
start with "A" again.

* The name must be composed only of the 26 characters of the ISO basic
Latin alphabet. Names which can be transliterated into this character
set are also acceptable.

* The name must refer to the physical or human geography of the region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic region
under consideration must be declared before the opening of nominations,
as part of the initiation of the selection process.

* The name must be a single word with a maximum of 10 characters. Words
that describe the feature should not be included, so "Foo City" or "Foo
Peak" would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may
make an exception for one or more of them to be considered in the
Condorcet poll. The naming official is responsible for presenting the
list of exceptional names for consideration to the TC before the poll opens.

Let the naming begin.

Paul

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

[openstack-dev] [all][infra] Some new Zuul features

[James E. Blair]

Hi,

We've rolled out a few new Zuul features you may find useful.

Added a post-timeout job attribute
==

We refined the way timeouts are handled.  The "timeout" attribute of a
job (which defaults to 30 minutes but can be changed by any job) now
covers the time used in the pre-run and run phases of the job.  There is
now a separate "post-timeout" attribute, which also defaults to 30
minutes, that covers the "post-run" phase of the job.

This means you can adjust the timeout setting for a long running job,
and maintain a lower post-timeout setting so that if the job encounters
a problem in the post-run phase, we aren't waiting 3 hours for it to
time out.

You generally shouldn't need to adjust this value, unless you have a job
which performs a long artifact upload in its post-run phase.

Docs: 
https://docs.openstack.org/infra/zuul/user/config.html#attr-job.post-timeout

Added host and group vars
=

We added two new job attributes, "host-vars" and "group-vars" which
behave just like "vars" in that they define variables for use by
Ansible, but they apply to specific hosts or host groups respectively,
whereas "vars" applies to all hosts.

Docs: https://docs.openstack.org/infra/zuul/user/config.html#attr-job.host-vars

-Jim

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

[openstack-dev] [manila] manila 6.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

A new release candidate for manila for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/manila/

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

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

http://git.openstack.org/cgit/openstack/manila/log/?h=stable/queens

Release notes for manila can be found at:

http://docs.openstack.org/releasenotes/manila/




__
OpenStack Development Mailing 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] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

[Andrea Frittoli]

Dear all,

updates:

- host/group vars: zuul now supports declaring host and group vars in the
job definition [0][1] - thanks corvus and infra team!
  This is a great help towards writing the devstack and tempest base
multinode jobs [2][3]
  * NOTE: zuul merges dict variables through job inheritance. Variables in
host/group_vars override global ones. I will write some examples further
clarify this.

- stable/pike: devstack ansible changes have been backported to
stable/pike, so we can now run zuulv3 jobs against stable/pike too - thank
you tosky!
  next change in progress related to pike is to provide tempest-full-pike
for branchless repositories [4]

- documentation: devstack now publishes documentation on its ansible roles
[5].
  More devstack documentation patches are in progress to provide jobs
reference, examples and a job migration how-to [6].


Andrea Frittoli (andreaf)

[0]
https://docs.openstack.org/infra/zuul/user/config.html#attr-job.host_vars
[1]
https://docs.openstack.org/infra/zuul/user/config.html#attr-job.group_vars
[2] https://review.openstack.org/#/c/545696/
[3] https://review.openstack.org/#/c/545724/
[4] https://review.openstack.org/#/c/546196/
[5] https://docs.openstack.org/devstack/latest/roles.html
[6] https://review.openstack.org/#/c/545992/

On Mon, Feb 19, 2018 at 2:46 PM Andrea Frittoli 
wrote:

> Dear all,
>
> updates:
> - tempest-full-queens and tempest-full-py3-queens are now available for
> testing of branchless repositories [0]. They are used for tempest and
> devstack-gate. If you own a tempest plugin in a branchless repo, you may
> consider adding similar jobs to your plugin if you use it for tests on
> stable/queen as well.
> - if you have migrated jobs based on devstack-tempest please let me know,
> I'm building reference docs and I'd like to include as many examples as
> possible
> - work on multi-node is in progress, but not ready still - you can follow
> the patches in the multinode branch [1]
> - updates on some of the points from my previous email are inline below
>
> Andrea Frittoli (andreaf)
>
> [0] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n73
> [1]
> https://review.openstack.org/#/q/status:open++branch:master+topic:multinode
>
>
>
> On Thu, Feb 15, 2018 at 11:31 PM Andrea Frittoli <
> andrea.fritt...@gmail.com> wrote:
>
>> Dear all,
>>
>> this is the first or a series of ~regular updates on the migration of
>> Tempest / Grenade jobs to  Zuul v3 native.
>>
>> The QA team together with the infra team are working on providing the
>> OpenStack community with a set of base Tempest / Grenade jobs that can be
>> used as a basis to write new CI jobs / migrate existing legacy ones with a
>> minimal effort and very little or no Ansible knowledge as a precondition.
>>
>> The effort is tracked in an etherpad [0]; I'm trying to keep the
>> etherpad up to date but it may not always be a source of truth.
>>
>> Useful jobs available so far:
>> - devstack-tempest [0] is a simple tempest/devstack job that runs
>> keystone glance nova cinder neutron swift and tempest *smoke* filter
>> - tempest-full [1] is similar but runs a full test run - it replaces the
>> legacy tempest-dsvm-neutron-full from the integrated gate
>> - tempest-full-py3 [2] runs a full test run on python3 - it replaces the
>> legacy tempest-dsvm-py35
>>
>
> Some more details on this topic: what I did not mention in my previous
> email is that the autogenerated Tempest / Grenade CI jobs (legacy-*
> playbooks) are not meant to be used as a basis for Zuul V3 native jobs. To
> create Zuul V3 Tempest / Grenade native jobs for your projects you need to
> through away the legacy playbooks and defined new jobs in .zuul.yaml, as
> documented in the zuul v3 docs [2].
> The parent job for a single node Tempest job will usually be
> devstack-tempest. Example migrated jobs are avilable, for instance: [3] [4].
>
> [2]
> https://docs.openstack.org/infra/manual/zuulv3.html#howto-update-legacy-jobs
>
> [3]
> http://git.openstack.org/cgit/openstack/sahara-tests/tree/.zuul.yaml#n21
> [4] https://review.openstack.org/#/c/543048/5
>
>
>>
>> Both tempest-full and tempest-full-py3 are part of integrated-gate
>> templates, starting from stable/queens on.
>> The other stable branches still run the legacy jobs, since
>> devstack ansible changes have not been backported (yet). If we do backport
>> it will be up to pike maximum.
>>
>> Those jobs work in single node mode only at the moment. Enabling
>> multinode via job configuration only require a new Zuul feature [4][5] that
>> should be available soon; the new feature allows defining host/group
>> variables in the job definition, which means setting variables which are
>> specific to one host or a group of hosts.
>> Multinode DVR and Ironic jobs will require migration of the ovs-* roles
>> form devstack-gate to devstack as well.
>>
>> Grenade jobs (single and multinode) are still legacy, even if the
>> *legacy* word has been removed from the name.
>> They are current

Re: [openstack-dev] [masakari] [masakari-monitors] : Intrusive Instance Monitoring through QEMU Guest Agent Design Update

[Kwan, Louie]

Hi Sam

Make sense and will do option 2.

FYI, we are planning to upload the second iim patch within a week and may do 
the masakari engine in different patch shortly.

Thanks for your reply.

Louie

From: Sam P [mailto:sam47pr...@gmail.com]
Sent: Tuesday, February 20, 2018 3:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari] [masakari-monitors] : Intrusive 
Instance Monitoring through QEMU Guest Agent Design Update

​Hi Louie,
 Thank you for patch and Sorry for the delay​ response.
I prefer ​option 2.
From Masakari point of view, this is an instance event. Because, even if some 
thing
wrong inside the VM, Masakari only can try to fix it by restart, rebuilt, 
migrate... etc the VM.
Which are the same recovery work flow for instance failures.  Therefore, I 
prefer option 2
rather than option1.
 Currently, we are discussing how to implement recovery method customization 
feature [0] in
Masakari. With this feature, you may able to call external workflows for 
certain failure events.
For this feature, different failure models required distinguishable events and 
option 3 will not
be appropriate.

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


​> 1. define a new type of event for Intrusive Instance monitoring or
> 2. add a new event within the INSTANCE_EVENTS as we may  eventually integrate 
> with instance monitoring  or
>3.simply reuse the LIFECYCLE/STOPPED_FAILED event ( which is what we are 
>implementing for now.)

--- Regards,
Sampath


On Fri, Feb 16, 2018 at 12:05 AM, Kwan, Louie 
mailto:louie.k...@windriver.com>> wrote:
We submitted the first implementation patch for the following blueprint

https://blueprints.launchpad.net/openstack/?searchtext=intrusive-instance-monitoring

i.e. https://review.openstack.org/#/c/534958/

The second patch  will be pushed within a week time or so.

One item we would like to seek clarification among the community is about  how 
we should integrate the notification within the masakari engine.

One option is to reuse what has been defined at  
masakari/engine/instance_events.py.

e.g.
def masakari_notifier(self, domain_uuid):
if self.getJournalObject(domain_uuid).getSentNotification():
LOG.debug('notifier.send_notification Skipped:' + domain_uuid)
else:
hostname = socket.gethostname()
noticeType = ec.EventConstants.TYPE_VM
current_time = timeutils.utcnow()
event = {
'notification': {
'type': noticeType,
'hostname': hostname,
'generated_time': current_time,
'payload': {
'event': 'LIFECYCLE',
'instance_uuid': domain_uuid,
'vir_domain_event': 'STOPPED_FAILED'
}
}
}
LOG.debug(str(event))
self.notifier.send_notification(CONF.callback.retry_max,
CONF.callback.retry_interval,
event)
self.getJournalObject(domain_uuid).setSentNotification(True)


​​
Should we


1.   define a new type of event for Intrusive Instance monitoring or

2.   add a new event within the INSTANCE_EVENTS as we may  eventually 
integrate with instance monitoring  or

3.   simply reuse the LIFECYCLE/STOPPED_FAILED event ( which is what we are 
implementing for now.)

One of our reference test case is to detect application meltdown within VM 
which QEMU may not  aware the failure. The recovery should pretty much be the 
same as LIFECYCLE/STOPPED_FAILED event. What do you think?

Thanks.
Louie

Ntoe:

Here is what we got from masakari/engine/instance_events.py

These are the events which needs to be processed by masakari in case of
instance recovery failure.
"""

INSTANCE_EVENTS = {
# Add more events and vir_domain_events here.
'LIFECYCLE': ['STOPPED_FAILED'],
'IO_ERROR': ['IO_ERROR_REPORT']
}


__
OpenStack Development Mailing 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] Generalized issues in the unit testing of ML2 mechanism drivers

[Isaku Yamahata]

On Tue, Feb 13, 2018 at 05:48:32PM -0500,
Assaf Muller  wrote:

> On Wed, Dec 13, 2017 at 7:30 AM, Michel Peterson  wrote:
> > Through my work in networking-odl I've found what I believe is an issue
> > present in a majority of ML2 drivers. An issue I think needs awareness so
> > each project can decide a course of action.
> >
> > The issue stems from the adopted practice of importing
> > `neutron.tests.unit.plugins.ml2.test_plugin` and creating classes with noop
> > operation to "inherit" tests for free [1]. The idea behind is nice, you
> > inherit >600 tests that cover several scenarios.
> >
> > There are several issues of adopting this pattern, two of which are
> > paramount:
> >
> > 1. If the mechanism driver is not loaded correctly [2], the tests then don't
> > test the mechanism driver but still succeed and therefore there is no
> > indication that there is something wrong with the code. In the case of
> > networking-odl it wasn't discovered until last week, which means that for >1
> > year it this was adding PASSed tests uselessly.
> >
> > 2. It gives a false sense of reassurance. If the code of those tests is
> > analyzed it's possible to see that the code itself is mostly centered around
> > testing the REST endpoint of neutron than actually testing that the
> > mechanism succeeds on the operation it was supposed to test. As a result of
> > this, there is marginally added value on having those tests. To be clear,
> > the hooks for the respective operations are called on the mechanism driver,
> > but the result of the operation is not asserted.
> >
> > I would love to hear more voices around this, so feel free to comment.
> >
> > Regarding networking-odl the solution I propose is the following:
> >   **First**, discard completely the change mentioned in the footnote #2.
> >   **Second**, create a patch that completely removes the tests that follow
> > this pattern.
> 
> An interesting exercise would be to add 'raise ValueError' type
> exceptions in various ODL ML2 mech driver flows and seeing which tests
> fail. Basically, if a test passes without the ODL mech driver loaded,
> or with a faulty ODL mech driver, then you don't need to run the test
> for networking-odl changes. I'd be hesitant to remove all tests
> though, it's a good investment of time to figure out which tests are
> valuable to you.

Mike and Michel should raise it at the PTG for discussion.
I know Mike will attend.

thanks,
-- 
Isaku Yamahata 

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

[openstack-dev] [ptl][all][release] published release notes may be out of date

[Doug Hellmann]

Thomas Bechtold reported some issues with the oslo.config release
notes not showing some information. As part of investigating the
problem, I discovered that reno's own release notes were not up to
date, either. I think the problem is a combination of a (now fixed)
reno bug [1] and some unrelated issues with the doc publishing jobs.

The issue is most likely to affect libraries, since those have been
frozen and may not have landed patches to retrigger the publishing
jobs, but server projects without a lot of activity over the last
few weeks may also have out of date release notes.

Please take a look at your projects' release notes and documentation.
If they were last updated before 1 Feb 2018, land a trivial (or
real) patch to the project to cause the documentation jobs to run.
If you have a current global requirements sync patch or translation
patch those are good candidates. The change in [2] is an example
of a trivial patch that might be good if you need one.

Doug

[1] https://bugs.launchpad.net/reno/+bug/1746076
[2] https://review.openstack.org/545846

__
OpenStack Development Mailing 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] [all] TC Report 18-08

[Chris Dent]

HTML: https://anticdent.org/tc-report-18-08.html


Most TC activity has either been in preparation for the
[PTG](https://www.openstack.org/ptg) or stalling to avoid starting
something that won't be finished before the PTG. But a few discussions
to point at.


# When's the Next PTG?

Last [Tuesday
evening](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-02-13.log.html#t2018-02-13T20:10:37)
had a brief discussion asking when (and where) the next PTG will be,
after Dublin. The answer? We don't know yet. It will likely come up
in Dublin.

# Base Services and Eventlet

A [question about base
services](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-02-15.log.html#t2018-02-15T15:08:21)
led to discussion about ways to technically and socially avoid the use
of eventlet. Notable was the observation that we continue to have new
projects that adopt patterns established in Nova that while perfectly
workable are no longer considered ideal. There's some work to do to
make sure we provide a bit more guidance.

# Naming for S Release

Rocky is starting, so it is time to be thinking about [naming for
S](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-02-15.log.html#t2018-02-15T15:34:37).
Berlin is the geographic location that will be the source for names
beginning with "S".

# Python 3.6

Most of
[Friday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-02-16.log.html)
was devoted to Python 3.6. Many distros are headed that way and
OpenStack CI is currently 2.7 and 3.5.

# TC Topics at the PTG

A reminder that there is an [etherpad for TC
topics](https://etherpad.openstack.org/p/PTG-Dublin-TC-topics) at the
PTG.

Because of the PTG there won't be a TC Report next week, but I will
endeavor to write up standalone reports of the discussions started by
that etherpad. Those discussion will hopefully grant a bit more vigor,
drive, and context to the TC Report, which has wandered a bit of late.

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

[openstack-dev] [tripleo] The Weekly Owl - 10th Edition

[Emilien Macchi]

Note: this is the tenth edition of a weekly update of what happens in
TripleO.
The goal is to provide a short reading (less than 5 minutes) to learn where
we are and what we're doing.
Any contributions and feedback are welcome.
Link to the previous version:
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127331.html

+-+
| General announcements |
+-+

+--> Focus is still on releasing Queens RC1 and branching stable/queens
before the end of February if possible.
+--> PTG draft scheduled on
https://etherpad.openstack.org/p/tripleo-ptg-rocky
+--> PTG is next week, your fellow reporter will be too busy to write a
weekly owl, next edition on March 6th with fresh post-ptg news!

+--+
| Continuous Integration |
+--+

+--> Rover is Ronelle and ruck is Arx. Please let them know any new CI
issue.
+--> Master promotion (and Queens) is 22 days, Pike is 0 days and Ocata is
0 days.
+--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting and
https://goo.gl/D4WuBP

+-+
| Upgrades |
+-+

+--> Work in progress: FFU, Queens update/upgrade workflows
+--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status
and https://etherpad.openstack.org/p/tripleo-upgrade-squad-meeting

+---+
| Containers |
+---+

+--> Containerized undercloud is the major ongoing effort in the squad.
+--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status

+--+
| Integration |
+--+

+--> No major updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status

+-+
| UI/CLI |
+-+

+--> Team is still planning work in Rocky and preparing RC1.
+--> Still working Automated UI testing in CI
+--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status

+---+
| Validations |
+---+

+--> No major updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status

+---+
| Networking |
+---+

+--> Containerized Neutron has a regression where DHCP server and L3
routers fail if the respective agent container is stopped. Fix is WIP.
+--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status

+--+
| Workflows |
+--+

+--> Node deletion is broken, team is working on
https://bugs.launchpad.net/tripleo/+bug/1749426
+--> Team is planning PTG:
https://etherpad.openstack.org/p/tripleo-workflows-squad-ptg
+--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status

++
| Owl fact |
++

Owls can rotate their necks 270 degrees.
A blood-pooling system collects blood to power their brains and eyes when
neck movement cuts off circulation.
Source: http://www.audubon.org/news/11-fun-facts-about-owls

Stay tuned!
--
Your fellow reporter, 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] Community Voting NOW OPEN - OpenStack Summit Vancouver 2018

[Kendall Waters]

Hi everyone, 

Session voting is now open for the May 2018 OpenStack Summit in Vancouver!

VOTE HERE 
Hurry, voting closes Sunday, February 25 at 11:59pm Pacific Time (Monday, 
February 26 at 7:59 UTC). 

The Programming Committees will ultimately determine the final schedule. 
Community votes are meant to help inform the decision, but are not considered 
to be the deciding factor. The Programming Committee members exercise judgment 
in their area of expertise and help ensure diversity. View full details of the 
session selection process here 
.
 

Continue to visit https://www.openstack.org/summit/vancouver-2018 
 for all Summit-related 
information.

REGISTER
Register HERE  before 
prices increase in early April!

VISA APPLICATION PROCESS
More information about the visa process can be found HERE 
.

TRAVEL SUPPORT PROGRAM
March 22 is the last day to submit applications. Please submit your 
applications HERE 
 by 
11:59pm Pacific Time (March 23 at 6:59am UTC). 

If you have any questions, please email sum...@openstack.org 
.

Cheers,
Kendall


Kendall Waters
OpenStack Marketing
kend...@openstack.org

__
OpenStack Development Mailing 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][networking-vsphere] neutron-lib patches for review

[Boden Russell]

Could I please ask the folks from networking-vsphere to keep an eye on
their review queue for incoming neutron-lib related patches?

Today we have at least 3 in the networking-vsphere queue that haven't
gotten a core review for over a month.

In order to keep the neutron-lib effort moving and stable, it's
important for networking projects using stable branches to assist with
these reviews. In general the code changes are minimal so I hoping this
isn't asking for a lot of time.

Thanks much

__
OpenStack Development Mailing 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] [docs] About the convention to use '.' instead of 'source'.

[Dean Troyer]

>> On 2018-02-18 03:55:51 -0600 (-0600), Monty Taylor wrote:
>> > That said - I completely agree with fungi on the description of
>> > the tradeoffs of each direction, and I do think it's valuable to
>> > pick one for the docs.

FWIW, DevStack declared long ago that it was built to use bash, even
though in some cases the shebang may even be /bin/sh.  While other
similar shells have been accommodated in the past they are considered
unsupported because we do not expect reviewers to know the subtlties
of similar shells.   Those who use zsh and friends are on the hook to
maintain the compatibility and their patches are (mostly?) accepted.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Doug Hellmann]

Excerpts from Robert Collins's message of 2018-02-20 22:58:59 +1300:
> On 20 February 2018 at 04:39, Andrey Kurilin  wrote:
> > Can someone explain me the reason for including "tests" module into
> > packages?
> 
> Namespacing the tests makes the test ids unique which is very helpful
> for aggregating test data as we do. Including that in the tar.gz that
> is uploaded to PyPI is pretty standard - a) its how you can verify
> that what you downloaded works in your context (and no, going to git
> is not a good answer there because that means you now need the entire
> ecosystem of tools to build man pages etc etc etc). and b) its
> providing the full source of the thing we're releasing. Thats you
> know, how F/LOSS works.

Thanks, Robert, that's the argument I was trying to remember earlier in
the thread.

> It should be possible, if we care to, to exclude the tests from wheels
> made from those distributions, which would make the footprint for
> binary usage smaller - I have no strong opinion on whether thats wise
> or not, but I will say I can't see a use case for needing the tests in
> that scenario.
> 
> Similarly whether those tests should be included in Linux distribution
> packages or not is a debate I don't care to enter - but again I don't
> see a use case: binary distributions are presumed to be integration
> tested by the distributor, not the consumers.
> 
> I don't think importing code from another packages 'tests' module is
> wrong or right - python is very much a consenting-adults language -
> but I do think that in OpenStack with the sheer number of people
> involved we should set very clear guidance; and I'd suggest that
> saying its not supported is a good default: if folk want to offer a
> contract where something can be imported they can always put it in a
> different package.

Exactly. The Oslo team struggles sometimes to support project teams
using the libraries in unexpected ways. This is one of those
unexpected uses, and I think we don't want to support it because
we have not designed the test suite with backwards compatibility
in mind. We just need to be clear about that.

> 
> In summary:
>  - moving 'tests' to the root is a poor idea, please don't do it - we
> had this debate back in 2011 or so and nothing has changed that I can
> see.
>  - we can, and perhaps should, exclude $package.tests from wheels to
> save bandwidth (but *not* from .tar.gz).
>  - linux distributions should IMO follow what we put in wheels.
> 
> -Rob
> 

__
OpenStack Development Mailing 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] [yaql] [tripleo] Backward incompatible change in YAQL minor version

[Sofer Athlan-Guyot]

Hi,

Zane Bitter  writes:

> On 17/02/18 16:40, Dan Prince wrote:
>> Thanks for the update Emilien. A couple of things to add:
>> 
>> 1) This was really difficult to pin-point via the Heat stack error
>> message ('list index out of range'). I actually had to go and add
>> LOG.debug statements to Heat to get to the bottom of it. I aim to sync
>> with a few of the Heat folks next week on this to see if we can do
>> better here.
>
> The message itself is pretty much all we get from yaql, even in its own 
> interpreter:
>
> (py27) cat yaql_data.json
> {"data": [{"foo": "bar"}]}
> (py27) yaql -d yaql_data.json
> Yet Another Query Language - command-line query tool
> Version 1.1.3
> Copyright (c) 2013-2017 Mirantis, Inc
>
> yaql> dict($.data.where($ != 
> null).flatten().selectMany($.items()).groupBy($[0], $[1], $.flatten()))
> {
>  "foo": [
>  "bar"
>  ]
> }
> yaql> dict($.data.where($ != 
> null).flatten().selectMany($.items()).groupBy($[0], $[1], [$[0], 
> $[1].flatten()]))
> Execution exception: list index out of range
> yaql>
>
> (Note that different lengths of data will give you different errors though.)
>
> The big issue here though is that for failures in validation we report 
> the path in the template to the function that failed, but we don't do 
> the same for failures in actually resolving the function at runtime. A 
> comprehensive fix is challenging without breaking what is supposed to be 
> a stable third-party plugin API, but it might be possible. Was that the 
> information you needed to debug this?
>
> We do report which resource failed, but for something with a huge 
> definition like allNodesConfig I can see why that might not help as much 
> as you'd hope.
>
>> 2) I had initially thought it would have been much better to revert
>> the (breaking) change to python-yaql. That said it was from 2016! So I
>> think our window of opportunity for the revert is probably way too
>> large to consider that. Sounds like we need to publish the yaql
>> package more often in RDO, etc. So your patch to update our queries is
>> probably our only option.
>
> I _think_ this should be OK for upgrades, as long as you never do a 
> stack update using the existing (Pike) templates after upgrading the 
> undercloud to Queens, but... sadface.

So as can be seen there[1] during a P->M upgrade this is not safe for
upgrade :)  Beside the fact that it breaks all hope of having any kind
of mixed upgrade CI testing (where the undercloud is N and expected to
deploy overcloud N-1) it breaks mixed version operation as well. 

[1] 
http://logs.openstack.org/62/545762/3/experimental/tripleo-ci-centos-7-scenario001-multinode-oc-upgrade/afc98a5/logs/undercloud/home/zuul/overcloud_deploy.log.txt.gz#_2018-02-19_09_48_54


> I think we need to either merge Thomas's patch that gets rid of this 
> function altogether (https://review.openstack.org/#/c/545856/)

I'm currently testing the pike's backport of this[2] in the experimental
pipeline.  I'll report inside the review.

[2] https://review.openstack.org/#/c/546094/

>>> On Mon, Feb 19, 2018 at 03:24:24PM +0100, Bogdan Dobrelya wrote:
>>>
>>> With a backport of the YAQL fixes for tht made for Pike, would it be the
>>> full fix to make a backport of yaql 1.1.3 for Pike repos as well? Or am I
>>> missing something?
>>
>> At some level that should be fine.  In the broader OpenSteck perspective
>> we've been gating with yaql 1.1.3 from pypi for releases > newton.  So
>> while updating the yaql package on pike to 1.1.3 isn't guaranteed to be
>> safe it should be fine.

So we fast forward upgrade, we need to make sure that master undercloud
is able to deploy the newton templates for CI testing and support of
some mixed version operations.

So if Thomas' patch enables us to support both yaql version that would
be ideal from an upgrade perspective.  It will need backport all the way
to newton.

> backport it to older versions of t-h-t, or make yaql itself 
> backward-compatible by doing something like 
> https://review.openstack.org/#/c/545996/
>
> cheers,
> Zane.
>
>> On Fri, Feb 16, 2018 at 8:36 PM, Emilien Macchi  wrote:
>>> Upgrading YAQL from 1.1.0 to 1.1.3 breaks advanced queries with groupBy
>>> aggregation.
>>>
>>> The commit that broke it is
>>> https://github.com/openstack/yaql/commit/3fb91784018de335440b01b3b069fe45dc53e025
>>>
>>> It broke TripleO: https://bugs.launchpad.net/tripleo/+bug/1750032
>>> But Alex and I figured (after a strong headache) that we needed to update
>>> the query like this: https://review.openstack.org/545498
>>>
>>> It would be great to avoid this kind of change within minor versions, please
>>> please.
>>>
>>> Happy weekend,
>>>
>>> PS: I'm adding YAQL to my linkedin profile right now.
>> 
>> Be careful here. Do you really want to write YAQL queries all day!
>> 
>> Dan
>> 
>>> --
>>> Emilien Macchi
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage quest

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Robert Collins]

On 20 February 2018 at 04:39, Andrey Kurilin  wrote:
> Can someone explain me the reason for including "tests" module into
> packages?

Namespacing the tests makes the test ids unique which is very helpful
for aggregating test data as we do. Including that in the tar.gz that
is uploaded to PyPI is pretty standard - a) its how you can verify
that what you downloaded works in your context (and no, going to git
is not a good answer there because that means you now need the entire
ecosystem of tools to build man pages etc etc etc). and b) its
providing the full source of the thing we're releasing. Thats you
know, how F/LOSS works.

It should be possible, if we care to, to exclude the tests from wheels
made from those distributions, which would make the footprint for
binary usage smaller - I have no strong opinion on whether thats wise
or not, but I will say I can't see a use case for needing the tests in
that scenario.

Similarly whether those tests should be included in Linux distribution
packages or not is a debate I don't care to enter - but again I don't
see a use case: binary distributions are presumed to be integration
tested by the distributor, not the consumers.

I don't think importing code from another packages 'tests' module is
wrong or right - python is very much a consenting-adults language -
but I do think that in OpenStack with the sheer number of people
involved we should set very clear guidance; and I'd suggest that
saying its not supported is a good default: if folk want to offer a
contract where something can be imported they can always put it in a
different package.

In summary:
 - moving 'tests' to the root is a poor idea, please don't do it - we
had this debate back in 2011 or so and nothing has changed that I can
see.
 - we can, and perhaps should, exclude $package.tests from wheels to
save bandwidth (but *not* from .tar.gz).
 - linux distributions should IMO follow what we put in wheels.

-Rob

__
OpenStack Development Mailing 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] [masakari] [masakari-monitors] : Intrusive Instance Monitoring through QEMU Guest Agent Design Update

[Sam P]

​Hi Louie,
 Thank you for patch and Sorry for the delay​ response.
I prefer ​option 2.
>From Masakari point of view, this is an instance event. Because, even if
some thing
wrong inside the VM, Masakari only can try to fix it by restart, rebuilt,
migrate... etc the VM.
Which are the same recovery work flow for instance failures.  Therefore, I
prefer option 2
rather than option1.
 Currently, we are discussing how to implement recovery method
customization feature [0] in
Masakari. With this feature, you may able to call external workflows for
certain failure events.
For this feature, different failure models required distinguishable events
and option 3 will not
be appropriate.

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


​> 1. define a new type of event for Intrusive Instance monitoring or
> 2. add a new event within the INSTANCE_EVENTS as we may  eventually
integrate with instance monitoring  or
>3.simply reuse the LIFECYCLE/STOPPED_FAILED event ( which is what we are
implementing for now.)

--- Regards,
Sampath


On Fri, Feb 16, 2018 at 12:05 AM, Kwan, Louie 
wrote:

> We submitted the first implementation patch for the following blueprint
>
>
>
> https://blueprints.launchpad.net/openstack/?searchtext=
> intrusive-instance-monitoring
>
>
>
> i.e. https://review.openstack.org/#/c/534958/
>
>
>
> The second patch  will be pushed within a week time or so.
>
>
>
> One item we would like to seek clarification among the community is about
>  how we should integrate the notification within the masakari engine.
>
>
>
> One option is to reuse what has been defined at  masakari/engine/instance_
> events.py.
>
>
>
> e.g.
>
> def masakari_notifier(self, domain_uuid):
>
> if self.getJournalObject(domain_uuid).getSentNotification():
>
> LOG.debug('notifier.send_notification Skipped:' + domain_uuid)
>
> else:
>
> hostname = socket.gethostname()
>
> noticeType = ec.EventConstants.TYPE_VM
>
> current_time = timeutils.utcnow()
>
> event = {
>
> 'notification': {
>
> 'type': noticeType,
>
> 'hostname': hostname,
>
> 'generated_time': current_time,
>
> 'payload': {
>
> 'event': 'LIFECYCLE',
>
> 'instance_uuid': domain_uuid,
>
> 'vir_domain_event': 'STOPPED_FAILED'
>
> }
>
> }
>
> }
>
> LOG.debug(str(event))
>
> self.notifier.send_notification(CONF.callback.retry_max,
>
> CONF.callback.retry_interval,
>
> event)
>
> self.getJournalObject(domain_uuid).setSentNotification(True)
>
>
>
>
>
> ​​
> Should we
>
>
>
> 1.   define a new type of event for Intrusive Instance monitoring or
>
> 2.   add a new event within the INSTANCE_EVENTS as we may  eventually
> integrate with instance monitoring  or
>
> 3.   simply reuse the LIFECYCLE/STOPPED_FAILED event ( which is what
> we are implementing for now.)
>
>
>
> One of our reference test case is to detect application meltdown within VM
> which QEMU may not  aware the failure. The recovery should pretty much be
> the same as LIFECYCLE/STOPPED_FAILED event. What do you think?
>
>
>
> Thanks.
>
> Louie
>
>
>
> Ntoe:
>
>
>
> Here is what we got from masakari/engine/instance_events.py
>
>
>
> These are the events which needs to be processed by masakari in case of
>
> instance recovery failure.
>
> """
>
>
>
> INSTANCE_EVENTS = {
>
> # Add more events and vir_domain_events here.
>
> 'LIFECYCLE': ['STOPPED_FAILED'],
>
> 'IO_ERROR': ['IO_ERROR_REPORT']
>
> }
>
>
>
> __
> OpenStack Development Mailing 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