Re: [openstack-dev] [ptg] etherpad for Fast Forward Upgrading?

[Thierry Carrez]

Luo, Lujin wrote:
> Can someone be nice enough to point me to the Rocky Fast Forward Upgrading 
> etherpad page?
> 
> I am seeing Fast Forward Upgrading scheduled on Monday [1], but the etherpad 
> for it is not listed in [2].

Indeed, the etherpad is missing, and I realize we don't have anyone
signed up yet to clearly lead that track...

Is anyone interested in leading that track ?

-- 
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] Debian OpenStack packages switching to Py3 for Queens

[Thomas Goirand]

Hi,

Since I'm getting some pressure from other DDs to actively remove Py2
support from my packages, I'm very much considering switching all of the
Debian packages for Queens to using exclusively Py3. I would have like
to read some opinions about this. Is it a good time for such move? I
hope it is, because I'd like to maintain as few Python package with Py2
support at the time of Debian Buster freeze.

Also, doing Queens, I've noticed that os-xenapi is still full of py2
only stuff in os_xenapi/dom0. Can we get those fixes? Here's my patch:

https://review.openstack.org/544809

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing 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] [ptg] etherpad for Fast Forward Upgrading?

[Lee Yarwood]

On 15-02-18 02:19:48, Luo, Lujin wrote:
> Hello everyone,
> 
> Can someone be nice enough to point me to the Rocky Fast Forward Upgrading 
> etherpad page?
> 
> I am seeing Fast Forward Upgrading scheduled on Monday [1], but the etherpad 
> for it is not listed in [2].
> 
> Thanks in advance.
> 
> [1] https://www.openstack.org/ptg/#tab_schedule 
> [2] https://wiki.openstack.org/wiki/PTG/Rocky/Etherpads 

Hello Lujin,

My apologies, I created this a while ago and forgot to add it to the
list and ask for input on the ML:

https://etherpad.openstack.org/p/ffu-ptg-rocky

I'll get this added to the list now and will send a separate note to the
ML later today seeking additional input on the agenda.

Cheers,

-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76


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] [ptg] etherpad for Fast Forward Upgrading?

[Lee Yarwood]

On 15-02-18 09:28:09, Thierry Carrez wrote:
> Luo, Lujin wrote:
> > Can someone be nice enough to point me to the Rocky Fast Forward Upgrading 
> > etherpad page?
> > 
> > I am seeing Fast Forward Upgrading scheduled on Monday [1], but the 
> > etherpad for it is not listed in [2].
> 
> Indeed, the etherpad is missing, and I realize we don't have anyone
> signed up yet to clearly lead that track...
> 
> Is anyone interested in leading that track ?

I did sign up a while ago, I've just failed to follow up during the last
few weeks. I'll try to get things moving today.

Regards,

-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76

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

[openstack-dev] [ptg] ptgbot HOWTO for track leads

[Thierry Carrez]

Hi everyone,

In two weeks some of us will congregate in Dublin for the 3rd OpenStack
PTG. The event is made of several 'tracks' (organized around a specific
team or a specific theme).

Topics of discussions are loosely scheduled in those tracks, based on
the needs of the attendance. This allows to maximize attendee
productivity, but the downside is that it can make the event a bit
confusing to navigate. To mitigate that issue, we are using an IRC bot
to expose what's happening currently at the event at the following page:

http://ptg.openstack.org/ptg.html

As a track lead, it is imperative that you make use of the PTG bot to
communicate what's happening. This is done by joining the #openstack-ptg
IRC channel on Freenode and speaking commands to the bot.

To indicate what's currently being discussed, you will use the track
name hashtag (found in the "Scheduled tracks" section on the above
page), with the 'now' command:

#TRACK now 

Example:
#swift now brainstorming improvements to the ring

You can also mention other track names to make sure to get people
attention when the topic is cross-project:

#nova now discussing #cinder interactions

There can only be one 'now' entry for a given track at a time. To
indicate what will be discussed next, you can enter one or more 'next'
commands:

#TRACK next 

Example:
#api-sig next at 2pm we'll be discussing pagination woes

Note that in order to keep content current, entering a new 'now' command
for a track will erase any 'next' entry for that track.

Finally, if you want to clear all 'now' and 'next' entries for your
track, you can issue the 'clean' command:

#TRACK clean

Example:
#ironic clean

For more information on the bot commands, please see:
https://git.openstack.org/cgit/openstack/ptgbot/tree/README.rst

Pro tip: designate someone tasked with updating the PTGbot with what's
currently being discussed, so that you can focus on keeping the
discussion on track.

You can play with the bot in the coming week, data will be reset on the
Sunday before the event starts.

-- 
Thierry Carrez (ttx)


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

[openstack-dev] [ptg] Booking reservable rooms with the ptgbot

[Thierry Carrez]

Hi everyone,

At every PTG we have additional reservable space for extra un-scheduled
discussions, or smaller teams to take advantage of. In past PTGs we've
been using an ethercalc document to book that space.

The issue with that approach was that we were using two separate systems
and it was not possible to use the PTG bot to update everyone on what
was currently discussed in those reserved rooms.

In Dublin we'll be using the PTG bot to book reservable space. The PTG
bot page now shows which track is allocated to which room, as well as
available space:

http://ptg.openstack.org/ptg.html

Available slots display a slot code (room name - time slot) that you can
use to issue a 'book' command to the PTG bot on #openstack-ptg:

#TRACK book 

Example:
#relmgt book Coiste Bainisti-MonP2

Any track can book additional space and time using this system. All
slots are 1h45-long.

If your topic of discussion does not fall into an existing track, please
ask PTG bot admins (ttx, diablo_rojo, infra...) to create a track for
you (which they can do by getting op rights and issuing a ~add 
command).

In Dublin some of the teams do not have any pre-scheduled space, and
will solely be relying on this feature to book the time that makes the
most sense for them. Those teams are Shade/OpenStackSDK (#sdk),
OpenStackClient (#osc), Stable branch maintenance (#stable),
Requirements (#requirements), Winstackers (#winstackers), Puppet
OpenStack (#puppet), Dragonflow (#dragonflow), Release Management
(#relmgt), and Rally (#rally).

For more information on the bot commands, please see:
https://git.openstack.org/cgit/openstack/ptgbot/tree/README.rst

You can play with the bot in the coming week, data will be reset on the
Sunday before the event starts. Any booking made will be removed then.

-- 
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] [ptg] etherpad for Fast Forward Upgrading?

[Thierry Carrez]

Lee Yarwood wrote:
> On 15-02-18 09:28:09, Thierry Carrez wrote:
>> Luo, Lujin wrote:
>>> Can someone be nice enough to point me to the Rocky Fast Forward Upgrading 
>>> etherpad page?
>>>
>>> I am seeing Fast Forward Upgrading scheduled on Monday [1], but the 
>>> etherpad for it is not listed in [2].
>>
>> Indeed, the etherpad is missing, and I realize we don't have anyone
>> signed up yet to clearly lead that track...
>>
>> Is anyone interested in leading that track ?
> 
> I did sign up a while ago, I've just failed to follow up during the last
> few weeks. I'll try to get things moving today.

Oops, I knew there was someone, just failed to document it. Thanks Lee!

(I badly need a vacation.)

-- 
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] [Election] PTL Election Results & Conclusion

[Thierry Carrez]

Kendall Nelson wrote:
> Thank you to the electorate, to all those who voted and to all
> candidates who put their name forward for Project Team Lead (PTL) in
> this election. A healthy, open process breeds trust in our decision
> making capability thank you to all those who make this process possible.
> 
> Now for the results of the PTL election process, please join me in
> extending congratulations to the following PTLs: [...]

Congrats to all newly-elected PTLs, and thanks to the election officials
for their service !

On the stats side, we renewed 17 of the 64 PTLs, so around 27%. Our
usual renewal rate is more around 35%, but we did renew more at the last
elections (40%) so this is likely why we didn't renew as much as usual
this time.

-- 
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][ui] Network Configuration wizard

[Jiri Tomasek]

On Wed, Feb 14, 2018 at 11:16 PM, Ben Nemec  wrote:

>
>
> On 02/09/2018 08:49 AM, Jiri Tomasek wrote:
>
>> *Step 2. network-environment -> NIC configs*
>>
>> Second step of network configuration is NIC config. For this
>> network-environment.yaml is used which references NIC config templates
>> which define network_config in their resources section. User is currently
>> required to configure these templates manually. We would like to provide
>> interactive view which would allow user to setup these templates using
>> TripleO UI. A good example is a standalone tool created by Ben Nemec [3].
>>
>> There is currently work aimed for Pike to introduce jinja templating for
>> network environments and templates [4] (single-nic-with-vlans,
>> bond-with-vlans) to support composable networks and roles (integrate data
>> from roles_data.yaml and network_data.yaml) It would be great if we could
>> move this one step further by using these samples as a starting point and
>> let user specify full NIC configuration.
>>
>> Available information at this point:
>> - list of roles and networks as well as which networks need to be
>> configured at which role's NIC Config template
>> - os-net-config schema which defines NIC configuration elements and
>> relationships [5]
>> - jinja templated sample NIC templates
>>
>> Requirements:
>> - provide feedback to the user about networks assigned to role and have
>> not been configured in NIC config yet
>>
>
> I don't have much to add on this point, but I will note that because my UI
> is standalone and pre-dates composable networks it takes the opposite
> approach.  As a user adds a network to a role, it exposes the configuration
> for that network.  Since you have the networks ahead of time, you can
> obviously expose all of those settings up front and ensure the correct
> networks are configured for each nic-config.
>
> I say this mostly for everyone's awareness so design elements of my tool
> don't get copied where they don't make sense.
>
> - let user construct network_config section of NIC config templates for
>> each role (brigdes/bonds/vlans/interfaces...)
>> - provide means to assign network to vlans/interfaces and automatically
>> construct network_config section parameter references
>>
>
> So obviously your UI code is going to differ, but I will point out that
> the code in my tool for generating the actual os-net-config data is
> semi-standalone: https://github.com/cybertron/t
> ripleo-scripts/blob/master/net_processing.py
>
> It's also about 600 lines of code and doesn't even handle custom roles or
> networks yet.  I'm not clear whether it ever will at this point given the
> change in my focus.
>
> Unfortunately the input JSON schema isn't formally documented, although
> the unit tests do include a number of examples.
> https://github.com/cybertron/tripleo-scripts/blob/master/tes
> t-data/all-the-things/nic-input.json covers quite a few different cases.
>
> - populate parameter definitions in NIC config templates based on
>> role/networks assignment
>> - populate parameter definitions in NIC config templates based on
>> specific elements which use them e.g. BondInterfaceOvsOptions in case when
>> ovs_bond is used
>>
>
> I guess there's two ways to handle this - you could use the new jinja
> templating to generate parameters, or you could handle it in the generation
> code.
>
> I'm not sure if there's a chicken-and-egg problem with the UI generating
> jinja templates, but that's probably the simplest option if it works. The
> approach I took with my tool was to just throw all the parameters into all
> the files and if they're unused then oh well.  With jinja templating you
> could do the same thing - just copy a single boilerplate parameter header
> that includes the jinja from the example nic-configs and let the templating
> handle all the logic for you.
>
> It would be cleaner to generate static templates that don't need to be
> templated, but it would require re-implementing all of the custom network
> logic for the UI.  I'm not sure being cleaner is sufficient justification
> for doing that.
>
> - store NIC config templates in deployment plan and reference them from
>> network-environment.yaml
>>
>> Problems to solve:
>> As a biggest problem to solve I see defining logic which would
>> automatically handle assigning parameters to elements in network_config
>> based on Network which user assigns to the element. For example: Using GUI,
>> user is creating network_config for compute role based on
>> network/config/multiple-nics/compute.yaml, user adds an interface and
>> assigns the interface to Tenant network. Resulting template should then
>> automatically populate addresses/ip_netmask: get_param: TenantIpSubnet.
>> Question is whether all this logic should live in GUI or should GUI pass
>> simplified format to Mistral workflow which will convert it to proper
>> network_config format and populates the template with it.
>>
>
> I guess the fact that I separated the UI an

Re: [openstack-dev] [freezer] PTG planning Etherpad

[Saad Zaher]

Hi Adam,

Sorry I forgot the link in my first email, you can find it here  [1].

Best Regards,
Saad!

[1] https://etherpad.openstack.org/p/freezer-ptg-rocky

On Mon, Feb 12, 2018 at 2:51 PM, Adam Heczko  wrote:

> Hello Saad, I think you missed link to the [1] etherpad.
>
> On Mon, Feb 12, 2018 at 3:05 PM, Saad Zaher  wrote:
>
>> Hello everyone,
>>
>> Please, if anyone is going to attend the next PTG in dublin check
>> ehterpad [1] for discussion agenda.
>>
>> Feel free to add or comment on topics you want to discuss in this PTG.
>>
>> Please make sure to add your irc or name to participants section.
>>
>>
>> Best Regards,
>> Saad!
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
> __
> OpenStack Development Mailing 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,
Saad!
__
OpenStack Development Mailing 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] Debian OpenStack packages switching to Py3 for Queens

[Bob Ball]

Hi Thomas,

As noted on the patch, XenServer only has python 2 (and some versions of 
XenServer even has Python 2.4) in domain0.  This is code that will not run in 
Debian (only in XenServer's dom0) and therefore can be ignored or removed from 
the Debian package.
It's not practical to convert these to support python 3.

Bob

-Original Message-
From: Thomas Goirand [mailto:z...@debian.org] 
Sent: 15 February 2018 08:31
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Debian OpenStack packages switching to Py3 for Queens

Hi,

Since I'm getting some pressure from other DDs to actively remove Py2 support 
from my packages, I'm very much considering switching all of the Debian 
packages for Queens to using exclusively Py3. I would have like to read some 
opinions about this. Is it a good time for such move? I hope it is, because I'd 
like to maintain as few Python package with Py2 support at the time of Debian 
Buster freeze.

Also, doing Queens, I've noticed that os-xenapi is still full of py2 only stuff 
in os_xenapi/dom0. Can we get those fixes? Here's my patch:

https://review.openstack.org/544809

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing 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] [requirements][release] FFE for tooz 1.60.0

[Dirk Müller]

Hi,

I would like to ask for a exception to add tooz 1.60.0 to
stable/queens. As part of the msgpack-python -> msgpack switch over we
converted all
dependencies, but the tooz release did not include the dependency
switch (not sure why, the branch point was just before the fix).

As it is a one liner dependency change and it brings everything in
stable/queens in a consistent state related to the dependencies (and
for
those who try to package openstack msgpack and msgpack-python do
file-conflict so can not be coinstalled) I would like to ask for a
FFE.

TIA,
Dirk

__
OpenStack Development Mailing 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][plugins] Supported Django versions for Horizon in Rocky

[Ivan Kolodyazhny]

Hi team,

As was discussed at the weekly meeting on December, 20th, Horizon team is
going to bump minimum Django version to the next LTS release which is 1.11.
Django 1.8 will be supported at least until April 2018 [2].

In Rocky release, we agreed to support Django 1.11 and Django 2.x as
experimental [3]. We're going to drop Django <= 1.10 support early in Rocky
[4] to get plugins maintainers more time to adapt their project to the
latest supported Django.

Unfortunately, we can't support both Django 1.8 and 2.0 because of Django's
deprecations and removals. so we need to bump minimum version.

Debian will switch the default Django version to 2.x soon. Although Django
2.0 is not LTS, it seems worth considering support of Django 2.0.

We'll have continuation of this conversation at PTG [5]/



[1]
http://eavesdrop.openstack.org/meetings/horizon/2017/horizon.2017-12-20-20.00.log.html#l-39
[2] https://www.djangoproject.com/download/
[3] https://blueprints.launchpad.net/horizon/+spec/django2-support
[4]
https://review.openstack.org/#/q/topic:bp/django2-support+(status:open+OR+status:merged)
[5] https://etherpad.openstack.org/p/horizon-ptg-rocky


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] [masakari] [masakari-monitors] : Intrusive Instance Monitoring through QEMU Guest Agent Design Update

[Kwan, Louie]

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

Re: [openstack-dev] [Election] PTL Election Results & Conclusion

[Steven Dake (stdake)]

Agreed!

Congratulations to all our newly elected PTLs.  For past PTLs, thanks a bunch 
for your service!

The election process I'm certain is very difficult to execute, and as a 
community member, I'd like to thank the election officials for their work.

Cheers
-steve

On 2/15/18, 2:47 AM, "Thierry Carrez"  wrote:

Kendall Nelson wrote:
> Thank you to the electorate, to all those who voted and to all
> candidates who put their name forward for Project Team Lead (PTL) in
> this election. A healthy, open process breeds trust in our decision
> making capability thank you to all those who make this process possible.
> 
> Now for the results of the PTL election process, please join me in
> extending congratulations to the following PTLs: [...]

Congrats to all newly-elected PTLs, and thanks to the election officials
for their service !

On the stats side, we renewed 17 of the 64 PTLs, so around 27%. Our
usual renewal rate is more around 35%, but we did renew more at the last
elections (40%) so this is likely why we didn't renew as much as usual
this time.

-- 
Thierry Carrez (ttx)

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


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

[openstack-dev] [neutron] Proper usage of neutron extensions/modules

[Boden Russell]

If your networking project is using neutron/neutron-lib, please read on.

SUMMARY:
If you're using neutron or neutron-lib code (for example extensions),
please ensure you import/use the respective attributes of those modules
rather than duplicate such values (str constants and such).


DETAILS:
To fully consume neutron-lib changes; the respective code that was
rehomed into lib is removed from neutron once all consumers using stable
branches are updated to use lib (instead of neutron). In order to find
such consumers we generally search [1] for who imports the respective
modules of interest. This allows us to update the consumers and ensure
they don't break once we remove the code from neutron.

The implication is that if consumers are using (depending on) the
neutron code, but never import it, they are missed in this process and
can end up with breakage when we remove the code from neutron.

A recent example of such includes [2] mentioned on [3].
An example of what's being asked for can be found in [4].


ACTION:
If neutron consumers could please inspect their code to ensure they are
declaring their intent to use neutron with 'imports' and also use
neutron module attributes were applicable, we can minimize the number of
breakages that occur in this process.


Feel free to reach out to me (boden) on openstack-neutron with any
questions/comments.

Thank you!


[1] http://codesearch.openstack.org/
[2] https://review.openstack.org/#/c/544179/
[3]
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127385.html
[4] https://bugs.launchpad.net/kuryr-libnetwork/+bug/1749594


__
OpenStack Development Mailing 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][ui] Network Configuration wizard

[Ben Nemec]

Re-sending from the account I'm subscribed with.

On 02/15/2018 10:40 AM, Ben Nemec wrote:



On 02/15/2018 04:00 AM, Jiri Tomasek wrote:
With this approach, we'll create common API provided by Mistral to 
generate NIC config templates which can be reused by CLI and other 
clients, not TripleO UI specifically. Note that we will also need a 
'reverse' Mistral workflow which is going to convert template yaml 
network_config into the input json format, so GUI can display current 
configuration to the user and let him change that.


Oh, that reminds me: there were some things that I needed to store for 
GUI use that aren't represented in the output templates.  That's why my 
tool writes out a pickle file that contains the intermediate data 
format, and when it loads a set of templates it actually reads that 
pickle file, not the templates themselves.


I don't recall all of the bits, but at a glance I see that I had stored 
values for auto_routes, ipv6, and version.  You can probably ignore 
version since you'll only ever need to support version 2, and it's 
possible you could derive the other two values based on the values in 
the templates.  It would require some fuzzy logic though, I think.


I believe there was also some one-way transformation done on the data 
when converting the JSON data to templates.  I'm not sure whether that 
could be reversed from just the templates.  It would certainly be more 
complex to do it that way.


Just something to keep in mind.  Especially because these templates will 
mostly never be seen by end-users since they'll go straight into the 
plan, it may be much simpler to store intermediate data alongside the 
templates and use that for populating the GUI.


__
OpenStack Development Mailing 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] Adding Takashi Natsume to python-novaclient core

[Andrey Kurilin]

+1

Takashi, thanks for your contribution!

2018-02-11 4:48 GMT+02:00 Alex Xu :

> +1
>
> 2018-02-09 23:01 GMT+08:00 Matt Riedemann :
>
>> I'd like to add Takashi to the python-novaclient core team.
>>
>> python-novaclient doesn't get a ton of activity or review, but Takashi
>> has been a solid reviewer and contributor to that project for quite awhile
>> now:
>>
>> http://stackalytics.com/report/contribution/python-novaclient/180
>>
>> He's always fast to get new changes up for microversion support and help
>> review others that are there to keep moving changes forward.
>>
>> So unless there are objections, I'll plan on adding Takashi to the
>> python-novaclient-core group next week.
>>
>> --
>>
>> Thanks,
>>
>> Matt
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[michael mccune]

Greetings OpenStack community,

Today's meeting was brief and primarily covered planning for the PTG. 
Here's a quick recap.


We began by continuing to discuss the bug [8] that is the result of the 
Nova API not properly including caching information in the headers of 
its replies. Dmitry Tantsur has added comments to the bug and the SIG 
will most likely have more input on that report. The SIG has agreed with 
the position described by Chris Dent in the bug report, that this is bug 
and should be remedied as soon as possible. If you have thoughts on 
this, please add your perspective to that bug report.


Next we reviewed the etherpad[7] of topics for the upcoming PTG, with 
the entire group taking an action item to prioritize the issues. If you 
are interested in the topics listed on that etherpad, we invite you to 
please add a "+1" next to anything that you would like to discuss, or a 
-1 if you don't think that topic deserves discussion time.


Lastly, there was some talk of an informal API-SIG meetup for the PTG 
with no firm plans confirmed. Beers may or may not have been discussed.


As always if you're interested in helping out, in addition to coming to 
the meetings, there's also:


* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for 
changes over time. If you find something that's not quite right, submit 
a patch [6] to fix it.
* Have you done something for which you think guidance would have made 
things easier but couldn't find any? Submit a patch and help others [6].


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week.

# Guidelines Currently Under Review [3]

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and 
service discovery

  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready 
for review)

  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that 
you are developing or changing, please address your concerns in an email 
to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, 
and comments to help guide the discussion of the specific challenge you 
are facing.


To learn more about the API SIG mission and the work we do, see our wiki 
page [4] and guidelines [2].


Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://etherpad.openstack.org/p/api-sig-ptg-rocky
[8] https://bugs.launchpad.net/nova/+bug/1747935

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
OpenStack Development Mailing 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] [automaton] How to extend automaton?

[Kwan, Louie]

Thanks for the reply. I will take the subclass approach for now.

It will be nice if we can dynamically register additional info or even a 
callback function  after building  a machine from a state space listing.

-LK

From: Joshua Harlow [harlo...@fastmail.com]
Sent: Wednesday, February 14, 2018 1:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [automaton] How to extend automaton?

As far a 1, I'd recommend just use functools.partial or make an object
with all the extra stuff u want and have that object provide a __call__
method.

As far as 2, you might have to subclass the FSM baseclass and add those
into the internal data-structure (same for 3 I think); ie this one @
https://github.com/openstack/automaton/blob/master/automaton/machines.py#L186-L191

Of course feel free to do it differently and submit a patch that folks
(myself and others) can review.

-Josh

Kwan, Louie wrote:
> https://github.com/openstack/automaton
>
> Friendly state machines for python.
>
> A few questions about automaton.
>
> 1.I would like to know can we addition parameters on on_enter or on_exit
> callbacks. Right now, it seems it only allows state and triggered_event.
>
> a.I have many FSM running for different objects and it is much easier if
> I can pass on the some sort of ID back to the callbacks.
>
> 2.Can we or how can we store extra attribute like last state change
> *timestamp*?
>
> 3.Can we store additional identify info for the FSM object? Would like
> to add an */UUID/*
>
> Thanks.
>
> Louie
>
> def print_on_enter(new_state, triggered_event):
>
> print("Entered '%s' due to '%s'" % (new_state, triggered_event))
>
> def print_on_exit(old_state, triggered_event):
>
> print("Exiting '%s' due to '%s'" % (old_state, triggered_event))
>
> # This will contain all the states and transitions that our machine will
>
> # allow, the format is relatively simple and designed to be easy to use.
>
> state_space = [
>
> {
>
> 'name': 'stopped',
>
> 'next_states': {
>
> # On event 'play' transition to the 'playing' state.
>
> 'play': 'playing',
>
> 'open_close': 'opened',
>
> 'stop': 'stopped',
>
> },
>
> 'on_enter': print_on_enter,
>
> 'on_exit': print_on_exit,
>
> },
>
> __
> OpenStack Development Mailing 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] [nova] Adding Takashi Natsume to python-novaclient core

[Matt Riedemann]

On 2/9/2018 9:01 AM, Matt Riedemann wrote:

I'd like to add Takashi to the python-novaclient core team.

python-novaclient doesn't get a ton of activity or review, but Takashi 
has been a solid reviewer and contributor to that project for quite 
awhile now:


http://stackalytics.com/report/contribution/python-novaclient/180

He's always fast to get new changes up for microversion support and help 
review others that are there to keep moving changes forward.


So unless there are objections, I'll plan on adding Takashi to the 
python-novaclient-core group next week.


I've added Takashi to python-novaclient-core:

https://review.openstack.org/#/admin/groups/572,members

Thanks everyone.

--

Thanks,

Matt

__
OpenStack Development Mailing 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][stable] Py3 integration jobs on stable

[Andrea Frittoli]

Dear all,

since it's now RC1 time, C1 we're setting up CI jobs for stable branches
and periodic-stable jobs for stable/queens.

In the past, we used to run the py27 based tempest-full integration job
(legacy-tempest-dsvm-neutron-full).
With all the effort that went into py3 support, I think it's time to start
running the py3 integration job as well against stable branches.

The integrated-gate-py35 [1] already includes stable/queens.
I proposed a patch for the periodic-stable pipeline [2].

Please let me know if you have any concern.

Andrea Frittoli (andreaf)

[1]
https://github.com/openstack-infra/openstack-zuul-jobs/blob/master/zuul.d/project-templates.yaml#L1008

[2] https://review.openstack.org/#/c/521888/
__
OpenStack Development Mailing 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] Adding Takashi Natsume to python-novaclient core

[Andrey Kurilin]

\o/

Welcome to the team!

2018-02-15 19:18 GMT+02:00 Matt Riedemann :

> On 2/9/2018 9:01 AM, Matt Riedemann wrote:
>
>> I'd like to add Takashi to the python-novaclient core team.
>>
>> python-novaclient doesn't get a ton of activity or review, but Takashi
>> has been a solid reviewer and contributor to that project for quite awhile
>> now:
>>
>> http://stackalytics.com/report/contribution/python-novaclient/180
>>
>> He's always fast to get new changes up for microversion support and help
>> review others that are there to keep moving changes forward.
>>
>> So unless there are objections, I'll plan on adding Takashi to the
>> python-novaclient-core group next week.
>>
>
> I've added Takashi to python-novaclient-core:
>
> https://review.openstack.org/#/admin/groups/572,members
>
> Thanks everyone.
>
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing 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,
Andrey Kurilin.
__
OpenStack Development Mailing 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] [trove] PTG planning, weekly meeting for Trove

[Manoj Kumar]

 I would encourage everyone who is interested in providing input into the 
Rocky planning cycle for Trove to put their ideas into the etherpad at:

https://etherpad.openstack.org/p/trove-ptg-rocky

There are a good number of topics posted already. We would welcome input 
from operators as well.
We are planning to meet remotely using Skype. If you are interested in 
participating in the discussions do add your Skype ID as well.

As we prepare for the PTG, there will be no weekly meeting next week.

- Manoj




__
OpenStack Development Mailing 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] Debian OpenStack packages switching to Py3 for Queens

[Haïkel]

2018-02-15 11:25 GMT+01:00 Bob Ball :
> Hi Thomas,
>
> As noted on the patch, XenServer only has python 2 (and some versions of 
> XenServer even has Python 2.4) in domain0.  This is code that will not run in 
> Debian (only in XenServer's dom0) and therefore can be ignored or removed 
> from the Debian package.
> It's not practical to convert these to support python 3.
>
> Bob
>

We're not there yet but we also plan to work on migrating RDO to Python 3.
And I have to disagree, this code is called by other projects and their tests,
so it will likely be an impediment in migrating OpenStack to Python 3, not just
a "packaging" issue.

If this code is meant to run on Dom0, fine, then we won't package it,
but we also
have to decouple that dependency from Nova, Neutron, Ceilometer etc... to either
communicate directly through an API endpoint or a light wrapper around it.

Regards,
H.

> -Original Message-
> From: Thomas Goirand [mailto:z...@debian.org]
> Sent: 15 February 2018 08:31
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] Debian OpenStack packages switching to Py3 for Queens
>
> Hi,
>
> Since I'm getting some pressure from other DDs to actively remove Py2 support 
> from my packages, I'm very much considering switching all of the Debian 
> packages for Queens to using exclusively Py3. I would have like to read some 
> opinions about this. Is it a good time for such move? I hope it is, because 
> I'd like to maintain as few Python package with Py2 support at the time of 
> Debian Buster freeze.
>
> Also, doing Queens, I've noticed that os-xenapi is still full of py2 only 
> stuff in os_xenapi/dom0. Can we get those fixes? Here's my patch:
>
> https://review.openstack.org/544809
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing 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] Debian OpenStack packages switching to Py3 for Queens

[Bob Ball]

Hi,

> If this code is meant to run on Dom0, fine, then we won't package it,
> but we also have to decouple that dependency from Nova, Neutron,
> Ceilometer etc... to either
communicate directly through an API
> endpoint or a light wrapper around it.

There is already a light wrapper here - other parts of os-xenapi provide the 
API to Nova/Neutron/etc which make calls through to the plugins in Dom0.

These projects should now know nothing about the actual plugins or how they are 
called.

Bob

From: Haïkel 
Sent: Thursday, 15 February 2018 6:39 p.m.
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] Debian OpenStack packages switching to Py3 for 
Queens


2018-02-15 11:25 GMT+01:00 Bob Ball :
> Hi Thomas,
>
> As noted on the patch, XenServer only has python 2 (and some versions of 
> XenServer even has Python 2.4) in domain0.  This is code that will not run in 
> Debian (only in XenServer's dom0) and therefore can be ignored or removed 
> from the Debian package.
> It's not practical to convert these to support python 3.
>
> Bob
>

We're not there yet but we also plan to work on migrating RDO to Python 3.
And I have to disagree, this code is called by other projects and their tests,
so it will likely be an impediment in migrating OpenStack to Python 3, not just
a "packaging" issue.

If this code is meant to run on Dom0, fine, then we won't package it,
but we also
have to decouple that dependency from Nova, Neutron, Ceilometer etc... to either
communicate directly through an API endpoint or a light wrapper around it.

Regards,
H.

> -Original Message-
> From: Thomas Goirand [mailto:z...@debian.org]
> Sent: 15 February 2018 08:31
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] Debian OpenStack packages switching to Py3 for Queens
>
> Hi,
>
> Since I'm getting some pressure from other DDs to actively remove Py2 support 
> from my packages, I'm very much considering switching all of the Debian 
> packages for Queens to using exclusively Py3. I would have like to read some 
> opinions about this. Is it a good time for such move? I hope it is, because 
> I'd like to maintain as few Python package with Py2 support at the time of 
> Debian Buster freeze.
>
> Also, doing Queens, I've noticed that os-xenapi is still full of py2 only 
> stuff in os_xenapi/dom0. Can we get those fixes? Here's my patch:
>
> https://review.openstack.org/544809
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing 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

[openstack-dev] [Election] Process Tweaks

[Kendall Nelson]

Hello Everyone,

Over the last few elections, with changes to the election cycle (i.e. the
separation of PTL and TC elections not being back to back), the scripts in
place have become somewhat outdated and brittle.

A few days ago after fixing a number of candidates names in an exceptions
file[1] due to incorrect information given to the docs build by a gerrit
lookup function, we had a conversation about how to fix this and other
issues. The lengthy discussion expanded from how to improve the processes
for both generation of the governance docs with correct candidate names to
the validation of candidates when nominations are posted to Gerrit.

Basically, we are proposing several changes to the scripts that exist and
changes to how nominations are submitted.

1. Uncouple the TC and PTL election processes. Make changes to our tooling
to validate PTL candidates and make those separate from the changes to
validate TC candidates.

2. Change the how-to-submit-candidacy directions to require the candidate's
email address (matching in Gerrit and foundation member profile) as the
file name of their nomination. All other info (name, IRC nick, etc.) should
be set in the foundation member profile. This could also mean a
reformatting the nomination submission altoghether to be YAML or JSON (open
for debate).

3. Create separate jobs for both docs build and candidate validation (and
run separate validation functions for TC elections versus PTL elections).

Please feel free to raise comments, concerns, or better ideas!

The plan is to schedule time at the PTG to start hacking on some of these
items so feedback before then would be fantastic!

- Your Friendly Neighborhood Election Officials

1: http://git.openstack.org/cgit/openstack/election/tree/exceptions.txt
__
OpenStack Development Mailing 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][CI] Validating HA on upstream

[Raoul Scarazzini]

TL;DR: we would like to change the way HA is tested upstream to avoid
being hitten by evitable bugs that the CI process should discover.

Long version:

Today HA testing in upstream consist only in verifying that a three
controllers setup comes up correctly and can spawn an instance. That's
something, but it’s far from being enough since we continuously see "day
two" bugs.
We started covering this more than a year ago in internal CI and today
also on rdocloud using a project named tripleo-quickstart-utils [1].
Apart from his name, the project is not limited to tripleo-quickstart,
it covers three principal roles:

1 - stonith-config: a playbook that can be used to automate the creation
of fencing devices in the overcloud;
2 - instance-ha: a playbook that automates the seventeen manual steps
needed to configure instance HA in the overcloud, test them via rally
and verify that instance HA works;
3 - validate-ha: a playbook that runs a series of disruptive actions in
the overcloud and verifies it always behaves correctly by deploying a
heat-template that involves all the overcloud components;

To make this usable upstream, we need to understand where to put this
code. Here some choices:

1 - tripleo-validations: the most logical place to put this, at least
looking at the name, would be tripleo-validations. I've talked with some
of the folks working on it, and it came out that the meaning of
tripleo-validations project is not doing disruptive tests. Integrating
this stuff would be out of scope.

2 - tripleo-quickstart-extras: apart from the fact that this is not
something meant just for quickstart (the project supports infrared and
"plain" environments as well) even if we initially started there, in the
end, it came out that nobody was looking at the patches since nobody was
able to verify them. The result was a series of reviews stuck forever.
So moving back to extras would be a step backward.

3 - Dedicated project (tripleo-ha-utils or just tripleo-utils): like for
tripleo-upgrades or tripleo-validations it would be perfect having all
this grouped and usable as a standalone thing. Any integration is
possible inside the playbook for whatever kind of test. Today we're
using the bash framework to interact with the cluster, rally to test
instance-ha and Ansible itself to simulate full power outage scenarios.

There's been a lot of talk about this during the last PTG [2], and
unfortunately, I'll not be part of the next one, but I would like to see
things moving on this side.
Everything I wrote is of course up to discussion, that's precisely the
meaning of this mail.

Thanks to all who'll give advice, suggestions, and thoughts about all
this stuff.

[1] https://github.com/redhat-openstack/tripleo-quickstart-utils
[2] https://etherpad.openstack.org/p/qa-queens-ptg-destructive-testing

-- 
Raoul Scarazzini
ra...@redhat.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] [Election] Process Tweaks

[Anita Kuno]

On 2018-02-15 02:09 PM, Kendall Nelson wrote:

Hello Everyone,

Over the last few elections, with changes to the election cycle (i.e. the
separation of PTL and TC elections not being back to back), the scripts in
place have become somewhat outdated and brittle.

A few days ago after fixing a number of candidates names in an exceptions
file[1] due to incorrect information given to the docs build by a gerrit
lookup function, we had a conversation about how to fix this and other
issues. The lengthy discussion expanded from how to improve the processes
for both generation of the governance docs with correct candidate names to
the validation of candidates when nominations are posted to Gerrit.

Basically, we are proposing several changes to the scripts that exist and
changes to how nominations are submitted.

1. Uncouple the TC and PTL election processes. Make changes to our tooling
to validate PTL candidates and make those separate from the changes to
validate TC candidates.

2. Change the how-to-submit-candidacy directions to require the candidate's
email address (matching in Gerrit and foundation member profile) as the
file name of their nomination. All other info (name, IRC nick, etc.) should
be set in the foundation member profile. This could also mean a
reformatting the nomination submission altoghether to be YAML or JSON (open
for debate).

3. Create separate jobs for both docs build and candidate validation (and
run separate validation functions for TC elections versus PTL elections).

Please feel free to raise comments, concerns, or better ideas!


Please ensure that all who nominate themselves know that the process is 
meant as a means of communication not as a blockade to standing for 
nomination. That the process of nominating themselves has a back up 
solution, for example the low tech send-an-email-to-dev, should 
something untoward happen whilst they are working through the automated 
process in order to meet the deadline.


Technical glitches and failures do happen and should be acknowledged as 
such, not allowing them to prevent someone from standing should they 
wish to stand.


Thanks,
Anita.



The plan is to schedule time at the PTG to start hacking on some of these
items so feedback before then would be fantastic!

- Your Friendly Neighborhood Election Officials

1: http://git.openstack.org/cgit/openstack/election/tree/exceptions.txt





__
OpenStack Development Mailing 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] Debian OpenStack packages switching to Py3 for Queens

[Matthew Thode]

On 18-02-15 09:31:19, Thomas Goirand wrote:
> Hi,
> 
> Since I'm getting some pressure from other DDs to actively remove Py2
> support from my packages, I'm very much considering switching all of the
> Debian packages for Queens to using exclusively Py3. I would have like
> to read some opinions about this. Is it a good time for such move? I
> hope it is, because I'd like to maintain as few Python package with Py2
> support at the time of Debian Buster freeze.
> 
> Also, doing Queens, I've noticed that os-xenapi is still full of py2
> only stuff in os_xenapi/dom0. Can we get those fixes? Here's my patch:
> 
> https://review.openstack.org/544809
> 

Gentoo has Openstack packaged for both python2.7 and python3.(5,6) for
pike.  Queens will be the same for us at least, but I haven't had
problems with at least the core services running them all through
python3.x.

-- 
Matthew Thode (prometheanfire)


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] [requirements][release] FFE for tooz 1.60.0

[Matthew Thode]

On 18-02-15 15:13:59, Dirk Müller wrote:
> Hi,
> 
> I would like to ask for a exception to add tooz 1.60.0 to
> stable/queens. As part of the msgpack-python -> msgpack switch over we
> converted all
> dependencies, but the tooz release did not include the dependency
> switch (not sure why, the branch point was just before the fix).
> 
> As it is a one liner dependency change and it brings everything in
> stable/queens in a consistent state related to the dependencies (and
> for
> those who try to package openstack msgpack and msgpack-python do
> file-conflict so can not be coinstalled) I would like to ask for a
> FFE.
> 

+2+W from requirements

-- 
Matthew Thode (prometheanfire)


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] [kolla] role change and introductions

[Kurt Taylor]

My downstream responsibilities have shifted over the last few months and it
probably comes as no surprise that I am not going to be able to be as
involved in the kolla project, including being the doc liaison. I'm having
to remove myself from that role and will also not be attending PTG. The
Kolla team has made great strides in improving the documentation, keep it
going!

Second, there will be 2 others from my ppc64le team getting involved in
Kolla, Mark Hamzy and Ed Leafe. Ed will be attending PTG and will try to
get a chance to meet a few of you there.

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

Re: [openstack-dev] Debian OpenStack packages switching to Py3 for Queens

[Matthew Thode]

On 18-02-15 13:38:45, Matthew Thode wrote:
> On 18-02-15 09:31:19, Thomas Goirand wrote:
> > Hi,
> > 
> > Since I'm getting some pressure from other DDs to actively remove Py2
> > support from my packages, I'm very much considering switching all of the
> > Debian packages for Queens to using exclusively Py3. I would have like
> > to read some opinions about this. Is it a good time for such move? I
> > hope it is, because I'd like to maintain as few Python package with Py2
> > support at the time of Debian Buster freeze.
> > 
> > Also, doing Queens, I've noticed that os-xenapi is still full of py2
> > only stuff in os_xenapi/dom0. Can we get those fixes? Here's my patch:
> > 
> > https://review.openstack.org/544809
> > 
> 
> Gentoo has Openstack packaged for both python2.7 and python3.(5,6) for
> pike.  Queens will be the same for us at least, but I haven't had
> problems with at least the core services running them all through
> python3.x.
> 

Edit: Everything BUT swift...

-- 
Matthew Thode (prometheanfire)


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] [kolla] role change and introductions

[Marcin Juszkiewicz]

W dniu 15.02.2018 o 20:48, Kurt Taylor pisze:
> My downstream responsibilities have shifted over the last few months
> and it probably comes as no surprise that I am not going to be able
> to be as involved in the kolla project, including being the doc
> liaison. I'm having to remove myself from that role and will also not
> be attending PTG. The Kolla team has made great strides in improving
> the documentation, keep it going!

Sad to see you leaving man. But such is life and work duties.

> Second, there will be 2 others from my ppc64le team getting involved
> in Kolla, Mark Hamzy and Ed Leafe. Ed will be attending PTG and will
> try to get a chance to meet a few of you there.

Please tell him that I would like to chat about ppc64le stuff ;D


__
OpenStack Development Mailing 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] PTG schedule and social event

[Tom Barron]

Manila sessions at the PTG are scheduled for Tuesday and Friday.

Ben Swartzlander and I worked together to distribute topics across the two
days and you can see the results here:

https://etherpad.openstack.org/p/manila-rocky-ptg

We'll of course end up shifting topics and times around as required, but this
will be our starting point.  So look it over and if anything has a time slot
that just won't work for you, let me know and we'll likely be able to adjust.

Also, if you have a topic and it's not on the etherpad, add it under
"Proposed Topics" and give me a ping.

Finally, we're planning a social event for Tuesday evening, so stay tuned for
more details.  If you think you can join us, please add your name to the
etherpad above under the "Team Dinner Planned" section.

-- Tom Barron



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] [masakari] [notification api] How to clean up or purging of records

[Kwan, Louie]

Hi All,

Just wondering, how can we clean up the masakari notification list or purging 
all old records in the DB?

openstack notification list
  returns too many old records

During semi-auto testing, I created a long list of history of records and would 
like to clean it up and avoid unnecessary actions.

Any short term solution is what I am looking for and/or ideas how to extend the 
CLI is also welcomed so that some of us can extend it later.

Thanks,
Louie


__
OpenStack Development Mailing 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] [Election] Process Tweaks

[Frank Kloeker]

Am 2018-02-15 20:09, schrieb Kendall Nelson:

Hello Everyone,

Over the last few elections, with changes to the election cycle (i.e.
the separation of PTL and TC elections not being back to back), the
scripts in place have become somewhat outdated and brittle.

[...]

3. Create separate jobs for both docs build and candidate validation
(and run separate validation functions for TC elections versus PTL
elections).

Please feel free to raise comments, concerns, or better ideas!

The plan is to schedule time at the PTG to start hacking on some of
these items so feedback before then would be fantastic!


Hi Kendall,

we have this in developement for I18n Extra-ATC collection on [1], the 
generated stats on [2].
There is one task with validation openstackid, which validated the given 
email address. Problem is here, translators using different email 
addresses for Zanata and it's not possible to validate the user with his 
name. Difficult.

PTG hacking session would be nice. Wednesday/Thursday afternoon?

kind regards

Frank

[1] https://review.openstack.org/#/c/531600/7/playbooks/generate_atc.yml
[2] 
https://wiki.openstack.org/wiki/I18nTeam/ATC_statistics#Queens_cycle_.282017-07-01_to_2018-01-10.29


__
OpenStack Development Mailing 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] role change and introductions

[Ed Leafe]

On Feb 15, 2018, at 2:41 PM, Marcin Juszkiewicz  
wrote:
> 
>> Second, there will be 2 others from my ppc64le team getting involved
>> in Kolla, Mark Hamzy and Ed Leafe. Ed will be attending PTG and will
>> try to get a chance to meet a few of you there.
> 
> Please tell him that I would like to chat about ppc64le stuff ;D

Of course, as long as you don’t expect me to know very much! :)

-- Ed Leafe






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

Re: [openstack-dev] [PTL][SIG][PTG]Team Photos

[Kendall Nelson]

Updates!

So, we have gotten permission to do photos down on the pitch at the stadium
which is awesome!

The only issue is that we need to condense into a more dense blocks
(Tuesday afternoon or Thursday morning) so looking at the schedule we have
to move some teams. If the following teams could move their times so that
we can make this happen:

   - QA
   - SIG K8s
   - Cyborg
   - Neutron
   - Octavia
   - Requirements
   - Release Mgmt
   - OpenStack Ansible
   - Cinder

I'm really sorry to make you guys move, but since we need to pay for an
escort (with a 4 hour minimum) and don't want to conflict with lunch, we
need to shift.

We will have your team meet at registration at your selected time. Because
we get to go on the pitch and this requires an escort, you NEED TO BE AT
REG ON TIME OR EARLY. If you aren't, you will miss your chance to be in the
photo.

I will send out a reminder on Monday of PTG week.

-Kendall (diablo_rojo)

On Thu, Feb 8, 2018 at 10:21 AM Kendall Nelson 
wrote:

> This link might work better for everyone:
>
> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>
> -Kendall (diablo_rojo)
>
>
> On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson 
> wrote:
>
>> Hello PTLs and SIG Chairs!
>>
>> So here's the deal, we have 50 spots that are first come, first
>> served. We have slots available before and after lunch both Tuesday and
>> Thursday.
>>
>> The google sheet here[1] should be set up so you have access to edit, but
>> if you can't for some reason just reply directly to me and I can add your
>> team to the list (I need team/sig name and contact email).
>>
>> I will be locking the google sheet on *Monday February 26th so I need to
>> know if your team is interested by then. *
>>
>> See you soon!
>>
>> - Kendall Nelson (diablo_rojo)
>>
>> [1]
>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>
>>
>>
>>
>>
__
OpenStack Development Mailing 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] [PTL][SIG][PTG]Team Photos

[Andrea Frittoli]

I set Thursday 12:00-12:10 for the QA team.

Andrea Frittoli (andreaf)

On Thu, Feb 15, 2018 at 9:56 PM Kendall Nelson 
wrote:

> Updates!
>
> So, we have gotten permission to do photos down on the pitch at the
> stadium which is awesome!
>
> The only issue is that we need to condense into a more dense blocks
> (Tuesday afternoon or Thursday morning) so looking at the schedule we have
> to move some teams. If the following teams could move their times so that
> we can make this happen:
>
>- QA
>- SIG K8s
>- Cyborg
>- Neutron
>- Octavia
>- Requirements
>- Release Mgmt
>- OpenStack Ansible
>- Cinder
>
> I'm really sorry to make you guys move, but since we need to pay for an
> escort (with a 4 hour minimum) and don't want to conflict with lunch, we
> need to shift.
>
> We will have your team meet at registration at your selected time. Because
> we get to go on the pitch and this requires an escort, you NEED TO BE AT
> REG ON TIME OR EARLY. If you aren't, you will miss your chance to be in the
> photo.
>
> I will send out a reminder on Monday of PTG week.
>
> -Kendall (diablo_rojo)
>
> On Thu, Feb 8, 2018 at 10:21 AM Kendall Nelson 
> wrote:
>
>> This link might work better for everyone:
>>
>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>
>> -Kendall (diablo_rojo)
>>
>>
>> On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson 
>> wrote:
>>
>>> Hello PTLs and SIG Chairs!
>>>
>>> So here's the deal, we have 50 spots that are first come, first
>>> served. We have slots available before and after lunch both Tuesday and
>>> Thursday.
>>>
>>> The google sheet here[1] should be set up so you have access to edit,
>>> but if you can't for some reason just reply directly to me and I can add
>>> your team to the list (I need team/sig name and contact email).
>>>
>>> I will be locking the google sheet on *Monday February 26th so I need
>>> to know if your team is interested by then. *
>>>
>>> See you soon!
>>>
>>> - Kendall Nelson (diablo_rojo)
>>>
>>> [1]
>>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>>
>>>
>>>
>>>
>>>
__
OpenStack Development Mailing 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] [Election] Process Tweaks

[Jeremy Stanley]

On 2018-02-15 22:24:31 +0100 (+0100), Frank Kloeker wrote:
[...]
> There is one task with validation openstackid, which validated the given
> email address. Problem is here, translators using different email addresses
> for Zanata and it's not possible to validate the user with his name.
> Difficult.
[...]

As long as the address you get from Zanata appears in at least one
of the E-mail address fields of the contributor's foundation
individual member profile, then the foundation member lookup API
should be able to locate the correct record for validation. In that
regard, it shouldn't be any more of a problem than it is for code
contributors (where at least one of the addresses for their Gerrit
account needs to appear in at least one of the E-mail address fields
for their member profile).
-- 
Jeremy Stanley


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] [PTL][SIG][PTG]Team Photos

[Sean McGinnis]

On Thu, Feb 15, 2018 at 09:56:25PM +, Kendall Nelson wrote:
> Updates!
> 
> So, we have gotten permission to do photos down on the pitch at the stadium
> which is awesome!
> 
> The only issue is that we need to condense into a more dense blocks
> (Tuesday afternoon or Thursday morning) so looking at the schedule we have
> to move some teams. If the following teams could move their times so that
> we can make this happen:
> 
>- QA
>- SIG K8s
>- Cyborg
>- Neutron
>- Octavia
>- Requirements
>- Release Mgmt
>- OpenStack Ansible
>- Cinder
> 
> I'm really sorry to make you guys move, but since we need to pay for an
> escort (with a 4 hour minimum) and don't want to conflict with lunch, we
> need to shift.
> 

Apparently my other email address wasn't subscribed to the ML so resending.
Apologies to anyone that gets this twice...

That sounds fun, but should we really do this?

At past PTG's, it was a disruption for teams to put things on hold to quick run
down a couple floors to take a photo. I think it is worth the brief disruption
- something like this is definitely worthy of taking the time to have a photo
of the team.

But in those cases it was quick and fairly easy to context switch back to what
had been the topic before the break. Now, if we are going to need to leave the
building, wait for the photo, then walk back to the in to the venue, that
seems like it's going to be a longer disruption that would be a bigger context
switch and require more time to remember where things were before the break.

I'm fine doing it either way, but I have some concerns about how big of a
disruption this could now be.

Sean

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

Re: [openstack-dev] [PTL][SIG][PTG]Team Photos

[prometheanf...@gentoo.org]

On 18-02-15 21:56:25, Kendall Nelson wrote:
> Updates!
> 
> So, we have gotten permission to do photos down on the pitch at the stadium
> which is awesome!
> 
> The only issue is that we need to condense into a more dense blocks
> (Tuesday afternoon or Thursday morning) so looking at the schedule we have
> to move some teams. If the following teams could move their times so that
> we can make this happen:
> 
>- QA
>- SIG K8s
>- Cyborg
>- Neutron
>- Octavia
>- Requirements
>- Release Mgmt
>- OpenStack Ansible
>- Cinder
> 
> I'm really sorry to make you guys move, but since we need to pay for an
> escort (with a 4 hour minimum) and don't want to conflict with lunch, we
> need to shift.
> 
> We will have your team meet at registration at your selected time. Because
> we get to go on the pitch and this requires an escort, you NEED TO BE AT
> REG ON TIME OR EARLY. If you aren't, you will miss your chance to be in the
> photo.
> 
> I will send out a reminder on Monday of PTG week.
> 
> -Kendall (diablo_rojo)
> 
> On Thu, Feb 8, 2018 at 10:21 AM Kendall Nelson 
> wrote:
> 
> > This link might work better for everyone:
> >
> > https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
> >
> > -Kendall (diablo_rojo)
> >
> >
> > On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson 
> > wrote:
> >
> >> Hello PTLs and SIG Chairs!
> >>
> >> So here's the deal, we have 50 spots that are first come, first
> >> served. We have slots available before and after lunch both Tuesday and
> >> Thursday.
> >>
> >> The google sheet here[1] should be set up so you have access to edit, but
> >> if you can't for some reason just reply directly to me and I can add your
> >> team to the list (I need team/sig name and contact email).
> >>
> >> I will be locking the google sheet on *Monday February 26th so I need to
> >> know if your team is interested by then. *
> >>
> >> See you soon!
> >>
> >> - Kendall Nelson (diablo_rojo)
> >>
> >> [1]
> >> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
> >>

Tuesday 2:40-2:50 for requirements can work

-- 
Matthew Thode (prometheanfire)


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] [release] Collecting Queens demos

[Anne Bertucio]

Hi all,

We’re getting the Queens Release communications ready, and I’ve seen a handful 
of video demos and tutorials of new Queens features. We’d like to compile a 
list of these to share with the marketing community. If you have a demo, would 
you please send a link my way so we can make sure to include it? 

If you don’t have a demo and have the time, I’d encourage you to make one of a 
feature you’re really excited about! We’ve heard really positive feedback about 
what’s already out there; people love them! 


Cheers,
Anne Bertucio
OpenStack Foundation
a...@openstack.org | 206-992-7961




__
OpenStack Development Mailing 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,

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

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 currently temporarily hosted in the neutron repository. They are
going to be implemented as Zuul v3 native in the grenade repository.

Roles are documented, and a couple of migration tips for DEVSTACK_GATE
flags is available in the etherpad [0]; more comprehensive examples /
docs will be available as soon as possible.

Please let me know if you find this update useful and / or if you would
like to see different information in it.
I will send further updates as soon as significant changes / new features
become available.

Andrea Frittoli (andreaf)

[0] https://etherpad.openstack.org/p/zuulv3-native-devstack-tempest-jobs
[1] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n1
[2] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n29
[3] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n47
[4] https://etherpad.openstack.org/p/zuulv3-group-variables
[5] https://review.openstack.org/#/c/544562/
__
OpenStack Development Mailing 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] [PTL][SIG][PTG]Team Photos

[Jay S Bryant]

All,

I have moved Cinder's time to the slot before lunch on Thursday. We can 
just break early for lunch so it will not be a huge disruption.


Jay


On 2/15/2018 3:56 PM, Kendall Nelson wrote:

Updates!

So, we have gotten permission to do photos down on the pitch at the 
stadium which is awesome!


The only issue is that we need to condense into a more dense blocks 
(Tuesday afternoon or Thursday morning) so looking at the schedule we 
have to move some teams. If the following teams could move their times 
so that we can make this happen:


  * QA
  * SIG K8s
  * Cyborg
  * Neutron
  * Octavia
  * Requirements
  * Release Mgmt
  * OpenStack Ansible
  * Cinder

I'm really sorry to make you guys move, but since we need to pay for 
an escort (with a 4 hour minimum) and don't want to conflict with 
lunch, we need to shift.


We will have your team meet at registration at your selected time. 
Because we get to go on the pitch and this requires an escort, you 
NEED TO BE AT REG ON TIME OR EARLY. If you aren't, you will miss your 
chance to be in the photo.


I will send out a reminder on Monday of PTG week.

-Kendall (diablo_rojo)

On Thu, Feb 8, 2018 at 10:21 AM Kendall Nelson > wrote:


This link might work better for everyone:

https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing


-Kendall (diablo_rojo)


On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson
mailto:kennelso...@gmail.com>> wrote:

Hello PTLs and SIG Chairs!

So here's the deal, we have 50 spots that are first come,
first served. We have slots available before and after lunch
both Tuesday and Thursday.

The google sheet here[1] should be set up so you have access
to edit, but if you can't for some reason just reply directly
to me and I can add your team to the list (I need team/sig
name and contact email).

I will be locking the google sheet on *Monday February 26th so
I need to know if your team is interested by then. *

See you soon!

- Kendall Nelson (diablo_rojo)

[1]

https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing






__
OpenStack Development Mailing 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] [PTL][SIG][PTG]Team Photos

[Miguel Lavalle]

Kendall,

I updated the Neutron team slot to 12:20 - 12:30 on Thursday? Hope that is
ok

Thanks

On Thu, Feb 15, 2018 at 3:56 PM, Kendall Nelson 
wrote:

> Updates!
>
> So, we have gotten permission to do photos down on the pitch at the
> stadium which is awesome!
>
> The only issue is that we need to condense into a more dense blocks
> (Tuesday afternoon or Thursday morning) so looking at the schedule we have
> to move some teams. If the following teams could move their times so that
> we can make this happen:
>
>- QA
>- SIG K8s
>- Cyborg
>- Neutron
>- Octavia
>- Requirements
>- Release Mgmt
>- OpenStack Ansible
>- Cinder
>
> I'm really sorry to make you guys move, but since we need to pay for an
> escort (with a 4 hour minimum) and don't want to conflict with lunch, we
> need to shift.
>
> We will have your team meet at registration at your selected time. Because
> we get to go on the pitch and this requires an escort, you NEED TO BE AT
> REG ON TIME OR EARLY. If you aren't, you will miss your chance to be in the
> photo.
>
> I will send out a reminder on Monday of PTG week.
>
> -Kendall (diablo_rojo)
>
> On Thu, Feb 8, 2018 at 10:21 AM Kendall Nelson 
> wrote:
>
>> This link might work better for everyone:
>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoT
>> ypX66eNURsopQY/edit?usp=sharing
>>
>> -Kendall (diablo_rojo)
>>
>>
>> On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson 
>> wrote:
>>
>>> Hello PTLs and SIG Chairs!
>>>
>>> So here's the deal, we have 50 spots that are first come, first
>>> served. We have slots available before and after lunch both Tuesday and
>>> Thursday.
>>>
>>> The google sheet here[1] should be set up so you have access to edit,
>>> but if you can't for some reason just reply directly to me and I can add
>>> your team to the list (I need team/sig name and contact email).
>>>
>>> I will be locking the google sheet on *Monday February 26th so I need
>>> to know if your team is interested by then. *
>>>
>>> See you soon!
>>>
>>> - Kendall Nelson (diablo_rojo)
>>>
>>> [1] https://docs.google.com/spreadsheets/d/
>>> 1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>>
>>>
>>>
>>>
> __
> OpenStack Development Mailing 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] [masakari] [notification api] How to clean up or purging of records

[Bhor, Dinesh]

Hi Kwan Louie,

I think you are looking for this:
https://review.openstack.org/#/c/487430/

Thank you,
Dinesh Bhor


From: Kwan, Louie 
Sent: 16 February 2018 02:46:14
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [masakari] [notification api] How to clean up or 
purging of records

Hi All,

Just wondering, how can we clean up the masakari notification list or purging 
all old records in the DB?

openstack notification list
  returns too many old records

During semi-auto testing, I created a long list of history of records and would 
like to clean it up and avoid unnecessary actions.

Any short term solution is what I am looking for and/or ideas how to extend the 
CLI is also welcomed so that some of us can extend it later.

Thanks,
Louie


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
OpenStack Development Mailing 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] [PTL][SIG][PTG]Team Photos

[Kendall Nelson]

I totally understand the concern.

I don't know if I have stressed it before, but team photos are 100%
optional. If its going to be too much of a distraction for anyone's team,
they definitely don't need to sign up.

The plan is to meet at reg, walk to the field entrance where the escort
will take us onto the pitch, take the photo and go back. It won't be like
this next time either, we just wanted to try to take advantage of what the
location has to offer.

-Kendall (diablo_rojo)

On Thu, Feb 15, 2018 at 2:11 PM Sean McGinnis 
wrote:

> On Thu, Feb 15, 2018 at 3:56 PM, Kendall Nelson 
> wrote:
>
>> Updates!
>>
>> So, we have gotten permission to do photos down on the pitch at the
>> stadium which is awesome!
>>
>> The only issue is that we need to condense into a more dense blocks
>> (Tuesday afternoon or Thursday morning) so looking at the schedule we have
>> to move some teams. If the following teams could move their times so that
>> we can make this happen:
>>
>>- QA
>>- SIG K8s
>>- Cyborg
>>- Neutron
>>- Octavia
>>- Requirements
>>- Release Mgmt
>>- OpenStack Ansible
>>- Cinder
>>
>> I'm really sorry to make you guys move, but since we need to pay for an
>> escort (with a 4 hour minimum) and don't want to conflict with lunch, we
>> need to shift.
>>
>>
> That sounds fun, but should we really do this?
>
> At past PTG's, it was a disruption for teams to put things on hold to
> quick run down a couple floors to take a photo. I think it is worth the
> brief disruption - something like this is definitely worthy of taking the
> time to have a photo of the team.
>
> But in those cases it was quick and fairly easy to context switch back to
> what had been the topic before the break. Now, if we are going to need to
> leave the building, wait for the photo, then walk back to the in to the
> venue, that seems like it's going to be a longer disruption that would be a
> bigger context switch and require more time to remember where things were
> before the break.
>
> I'm fine doing it either way, but I have some concerns about how big of a
> disruption this could now be.
>
> Sean
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA][stable] Py3 integration jobs on stable

[Tony Breeds]

On Thu, Feb 15, 2018 at 05:28:29PM +, Andrea Frittoli wrote:
> Dear all,
> 
> since it's now RC1 time, C1 we're setting up CI jobs for stable branches
> and periodic-stable jobs for stable/queens.
> 
> In the past, we used to run the py27 based tempest-full integration job
> (legacy-tempest-dsvm-neutron-full).
> With all the effort that went into py3 support, I think it's time to start
> running the py3 integration job as well against stable branches.
> 
> The integrated-gate-py35 [1] already includes stable/queens.
> I proposed a patch for the periodic-stable pipeline [2].
> 
> Please let me know if you have any concern.

Sounds good to me.  Thanks!

Yours Tony.


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

[James E. Blair]

Andrea Frittoli  writes:

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

Thanks!

One other issue we noticed when using the new job is related to devstack
plugin ordering.  We're trying to design an interface to the job that
makes it easy to take the standard devstack and/or tempest job and add
in a plugin for a project.  This should greatly reduce the boilerplate
needed for new devstack jobs compared to Zuul v2.  However, our
interface for enabling plugins in Zuul is not ordered, but sometimes
ordering is important.

To address this, we've added a feature to devstack plugins which allow
them to express a dependency on other plugins.  Nothing else but Zuul
uses this right now, though we expand support for this in devstack in
the future.

If you maintain a devstack plugin which depends on another devstack
plugin, you can go ahead and indicate that with "plugin_requires" in the
settings file.  See [1] for more details.

We also need to land a change to the role that writes the devstack
config in order to use this new feature; it's ready for review in [2].

-Jim

[1] https://docs.openstack.org/devstack/latest/plugins.html#plugin-interface
[2] https://review.openstack.org/522054

__
OpenStack Development Mailing 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] [requirements][trove][tatu][barbican][compass][daisycloud][freezer][fuel][nova][openstack-ansible][pyghmi][solum] Migration from pycrypto

[Tony Breeds]

On Wed, Feb 14, 2018 at 01:59:29PM -0600, Matthew Thode wrote:
> On 18-02-14 13:55:53, Sean McGinnis wrote:
> > On Wed, Feb 14, 2018 at 10:09:47AM -0600, Matthew Thode wrote:
> > > Development has stalled, (since 2014).  It's been forked but now would
> > > be a good time to move to a more actively maintained crypto library like
> > > cryptography.
> > > 
> > > Requirements wishes to drop pycrypto.  Let me know if there's anything
> > > we can do to facilitate this.
> > > 
> > > -- 
> > > Matthew Thode (prometheanfire)
> > 
> > We did have a discussion on the ML, and I think a little at one of the PTGs,
> > about the path forward for this. IIRC, there was one other potential 
> > supported
> > package that was considered for an option, but we settled on cryptography as
> > the recommended path forward to get off of pycrypto. I think it had to do 
> > with
> > ease of being able to just drop in the new package with minimal affected 
> > code.
> > 
> 
> Yep, I remember it, I'm not mentioning it because I'd like to focus on
> moving to cryptography rather than move to the fork.

Seems like a good PTG ad-hoc session.

But looking at the dump below I don't actually think that we have that much 
work to do to switch.

$ get-all-requirements.py --all --pkgs pycrypto
Package  : pycrypto [pycrypto>=2.6] (used by 11 projects)
Included in  : 4 projects
openstack/barbican[cycle-with-milestones]
openstack/freezer [cycle-with-milestones]
openstack/solum   [cycle-with-intermediary]
openstack/trove   [cycle-with-milestones]
Also affects : 7 projects
openstack-dev/heat-cfnclient  [None]
openstack/compass-core[None]
openstack/nova-powervm[None]
openstack/openstack-ansible   [cycle-trailing]
openstack/pyghmi  [None]
openstack/rpm-packaging   [None]
openstack/tatu[None]

$ bash ./check_more_pycrypto.sh openstack/barbican openstack/freezer 
openstack/solum openstack/trove openstack-dev/heat-cfnclient 
openstack/compass-core openstack/nova-powervm openstack/openstack-ansible 
openstack/pyghmi openstack/rpm-packaging openstack/tatu
openstack/barbican:origin/master:barbican/tests/tasks/test_certificate_resources.py:555:
def test_should_return_for_pycrypto_stored_key_with_passphrase(self):
openstack/barbican:origin/master:barbican/tests/tasks/test_certificate_resources.py:597:
def test_should_return_for_pycrypto_stored_key_without_passphrase(self):
openstack/barbican:origin/master:barbican/tests/tasks/test_certificate_resources.py:632:
def test_should_raise_for_pycrypto_stored_key_no_container(self):
openstack/barbican:origin/master:barbican/tests/tasks/test_certificate_resources.py:666:
def test_should_raise_for_pycrypto_stored_key_no_private_key(self):
openstack/barbican:origin/master:requirements.txt:25:pycrypto>=2.6 # Public 
Domain
openstack/barbican:origin/master:barbican/plugin/dogtag.py:22:from 
Crypto.PublicKey import RSA  # nosec
openstack/barbican:origin/master:barbican/plugin/dogtag.py:23:from Crypto.Util 
import asn1  # nosec
openstack/barbican:origin/master:barbican/tests/plugin/test_dogtag.py:21:from 
Crypto.PublicKey import RSA  # nosec
openstack/freezer:origin/master:README.rst:127:-  pycrypto
openstack/freezer:origin/master:README.rst:590:restore. When a key is provided, 
it uses OpenSSL or pycrypto module (OpenSSL compatible)
openstack/freezer:origin/master:requirements.txt:21:pycrypto>=2.6 # Public 
Domain
openstack/freezer:origin/master:freezer/utils/crypt.py:17:from Crypto.Cipher 
import AES
openstack/freezer:origin/master:freezer/utils/crypt.py:18:from Crypto import 
Random
openstack/solum:origin/master:devstack/devstack-provenance:253:pip|pycrypto|2.6.1
openstack/solum:origin/master:requirements.txt:24:pycrypto>=2.6 # Public Domain
openstack/solum:origin/master:solum/api/handlers/plan_handler.py:20:from 
Crypto.PublicKey import RSA
openstack/solum:origin/master:solum/common/utils.py:14:from Crypto.Cipher 
import AES
openstack/trove:origin/master:integration/scripts/files/requirements/fedora-requirements.txt:30:pycrypto>=2.6
  # Public Domain
openstack/trove:origin/master:integration/scripts/files/requirements/ubuntu-requirements.txt:29:pycrypto>=2.6
  # Public Domain
openstack/trove:origin/master:requirements.txt:47:pycrypto>=2.6 # Public Domain
openstack/trove:origin/master:trove/common/crypto_utils.py:19:from 
Crypto.Cipher import AES
openstack/trove:origin/master:trove/common/crypto_utils.py:20:from Crypto 
import Random
openstack/trove:origin/master:trove/tests/unittests/common/test_crypto_utils.py:17:from
 Crypto import Random
openstack/trove:origin/master:trove/tests/unittests/common/test_stream_codecs.py:17:from
 Crypto import Random
openstack/compass-core:origin/master:test-requirements.txt:9:pycrypto
openstack/n

Re: [openstack-dev] [Election] PTL Election Results & Conclusion

[Ed Leafe]

On Feb 15, 2018, at 9:43 AM, Steven Dake (stdake)  wrote:
> 
> The election process I'm certain is very difficult to execute, and as a 
> community member, I'd like to thank the election officials for their work.

Having done it once, I can agree! Thanks for making things run so smoothly.


-- Ed Leafe






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

Re: [openstack-dev] [release] Collecting Queens demos

[Kaz Shinohara]

Hi Anne,


I'm wondering if I can send a demo video for heat-dashboard which is a
new feature in Queens.
Is there any format of the video ?

Regards,
Kaz


2018-02-16 8:09 GMT+09:00 Anne Bertucio :
> Hi all,
>
> We’re getting the Queens Release communications ready, and I’ve seen a
> handful of video demos and tutorials of new Queens features. We’d like to
> compile a list of these to share with the marketing community. If you have a
> demo, would you please send a link my way so we can make sure to include it?
>
> If you don’t have a demo and have the time, I’d encourage you to make one of
> a feature you’re really excited about! We’ve heard really positive feedback
> about what’s already out there; people love them!
>
>
> Cheers,
> Anne Bertucio
> OpenStack Foundation
> a...@openstack.org | 206-992-7961
>
>
>
>
>
> __
> OpenStack Development Mailing 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] [glance] glance 16.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/glance/

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/glance/log/?h=stable/queens

Release notes for glance can be found at:

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




__
OpenStack Development Mailing 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] [tap-as-a-service] queens

[Takashi Yamamoto]

hi,

1. i'm going to create a release and stable branch for tap-as-a-service/queens.

2. to clean up the queue before a release, i approved a bunch of
patches today without waiting for two +2s.
given the current review bandwidth, i guess we should relax the policy.
how do you think?

3. what to do for tap-as-a-service-dashboard?  kaz?

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

[openstack-dev] [release] Release countdown for week R-1, February 17 - 23

[Sean McGinnis]

Welcome to one of the last countdown emails for Queens!

Development Focus
-

Teams should be working on release critical bugs in preparation of the final
release.

Teams attending the PTG should also be preparing for those discussions and
capturing information in the etherpads:

https://wiki.openstack.org/wiki/PTG/Rocky/Etherpads

General Information
---

Thursday, February 22 is the deadline for final Queens release candidates. We
will then enter a quiet period until we tag the final release on February 28.

Actions
-

Watch for any translation patches coming through and merge them quickly. If
your project has a stable/queens branch created, please make sure those
patches are also merged there.

Liaisons for projects with independent deliverables should import the release
history by preparing patches to openstack/releases.

Projects following the cycle-trailing model should be getting ready for the
cycle-trailing RC deadline coming up on March 1.

Please drop by #openstack-release with any questions or concerns about the
upcoming release.


Upcoming Deadlines & Dates
--

Queens Final Release Candidate deadline: February 22
Rocky PTG in Dublin: Week of February 26, 2018
Queens cycle-trailing RC deadline: March 1

-- 
Sean McGinnis (smcginnis)

__
OpenStack Development Mailing 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] nova 17.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/nova/

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/nova/log/?h=stable/queens

Release notes for nova can be found at:

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




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