Re: [openstack-dev] [horizon] how to get horizon related logs to syslog?

2018-11-19 Thread Doug Hellmann
Akihiro Motoki  writes:

> Hi,
>
> Horizon logging depends on Django configuration which supports full python
> logging [1].
> [1] does not provide enough examples.
> Perhaps [2] will help you (though I haven't tested it).

Based on https://docs.djangoproject.com/en/2.1/topics/logging/ it looks
like it should be possible to have Horizon's settings module disable
Django's logging configuration and call oslo.log to do that
configuration. I wonder if it would make sense to do that, for
consistency with the other services?

Doug


>
> [1] https://docs.djangoproject.com/en/2.0/topics/logging/
> [2]
> https://www.simonkrueger.com/2015/05/27/logging-django-apps-to-syslog.html
>
> Thanks,
> Akihiro
>
> 2018年11月16日(金) 18:47 Tikkanen, Viktor (Nokia - FI/Espoo) <
> viktor.tikka...@nokia.com>:
>
>> Hi!
>>
>> For most openstack parts (e.g. Aodh, Cinder, Glance, Heat, Ironic,
>> Keystone, Neutron, Nova) it was easy to get logs to syslog.
>>
>> For example for Heat something similar to this (into file
>> templates/heat.conf.j2):
>>
>> # Syslog usage
>> {% if heat_syslog_enabled %}
>> use_syslog = True
>> syslog_log_facility = LOG_LOCAL3
>> {% else %}
>> log_file = /var/log/heat/heat.log
>> {% endif %}
>>
>> But how to get Horizon related logs to syslog?
>>
>> -V.
>>
>> __
>> OpenStack Development Mailing 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

-- 
Doug

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


Re: [openstack-dev] [cloudkitty] IRC meetings and community

2018-11-07 Thread Doug Hellmann
Luka Peschke  writes:

> Hello Doug,
>
> Here's the patch: https://review.openstack.org/#/c/616205/. If it is 
> not merged by Friday (date of the first meeting), I'll send the log of 
> the first meeting to this ML.
>
> Luka

I was mostly concerned with future meetings, so that sounds like a good
plan.

Thanks!

>
> Le 2018-11-07 18:43, Doug Hellmann a écrit :
>> Luka Peschke  writes:
>> 
>>> Hello,
>>> 
>>> I'm making this e-mail to announce that the CloudKitty project will 
>>> be
>>> holding IRC meetings from now on. They will be held in the 
>>> #cloudkitty
>>> channel on Freenode. They should (for now) be held on the first 
>>> Friday
>>> of each month at 15h00 UTC. Of course, the time / frequency can be
>>> adapted to what suits the community the best.
>>> 
>>> The first meeting will be an exception to this schedule. It will be
>>> held on Friday the 9th of November at 15h00 UTC. Topics for this 
>>> meeting
>>> can be found and proposed at
>>> https://etherpad.openstack.org/p/cloudkitty-meeting-topics
>>> 
>>> These meetings were a thing in the project's early days and have 
>>> slowly
>>> stopped, which we really regret.
>>> 
>>> This is part of a larger effort to get more in touch with the
>>> community. We would gladly welcome new contributors, and any
>>> contribution of any kind (bug report, review, documentation
>>> suggestion/update, commit...),  is welcome. There are several points
>>> which should be tackled in order to ease interactions with the
>>> community. These will be detailled and discussed during the first
>>> meeting.
>>> 
>>> For those interested in CloudKitty attending the Berlin summit, the
>>> Project Update will happen on the 14/11 at 2:30pm in M-Räum 3 and the
>>> onboarding will be held on the 14/11 at 5:10pm in M-Räum 1.
>>> 
>>> Cheers,
>>> 
>>> Luka
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> Thanks, Luka.
>> 
>> Please propose an update to the openstack-infra/irc-meetings 
>> repository
>> to register the meeting info so it shows up on eavesdrop.openstack.org
>> and the calendar published there. That will make it easier for other
>> folks to find the meeting and keep it on their schedule.

-- 
Doug

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


Re: [openstack-dev] [cloudkitty] IRC meetings and community

2018-11-07 Thread Doug Hellmann
Luka Peschke  writes:

> Hello,
>
> I'm making this e-mail to announce that the CloudKitty project will be 
> holding IRC meetings from now on. They will be held in the #cloudkitty 
> channel on Freenode. They should (for now) be held on the first Friday 
> of each month at 15h00 UTC. Of course, the time / frequency can be 
> adapted to what suits the community the best.
>
> The first meeting will be an exception to this schedule. It will be 
> held on Friday the 9th of November at 15h00 UTC. Topics for this meeting 
> can be found and proposed at 
> https://etherpad.openstack.org/p/cloudkitty-meeting-topics
>
> These meetings were a thing in the project's early days and have slowly 
> stopped, which we really regret.
>
> This is part of a larger effort to get more in touch with the 
> community. We would gladly welcome new contributors, and any 
> contribution of any kind (bug report, review, documentation 
> suggestion/update, commit...),  is welcome. There are several points 
> which should be tackled in order to ease interactions with the 
> community. These will be detailled and discussed during the first 
> meeting.
>
> For those interested in CloudKitty attending the Berlin summit, the 
> Project Update will happen on the 14/11 at 2:30pm in M-Räum 3 and the 
> onboarding will be held on the 14/11 at 5:10pm in M-Räum 1.
>
> Cheers,
>
> Luka
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks, Luka.

Please propose an update to the openstack-infra/irc-meetings repository
to register the meeting info so it shows up on eavesdrop.openstack.org
and the calendar published there. That will make it easier for other
folks to find the meeting and keep it on their schedule.

-- 
Doug

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


Re: [openstack-dev] [Openstack-operators] FIPS Compliance

2018-11-07 Thread Doug Hellmann
Joshua Cornutt  writes:

> On Wed, Nov 7, 2018 at 7:30 AM Doug Hellmann  wrote:
>>
>> Joshua Cornutt  writes:
>>
>> > Doug,
>> >
>> > I have such a list put together (my various installation documents for
>> > getting these clouds working in FIPS mode) but it's hardly ready for
>> > public consumption. I planned on releasing each bit as a code change
>> > and/or bug ticket and letting the community consume it as it figures
>> > some of these things out.
>>
>> It's likely that the overall migration will go better if we all have the
>> full context. So I hope you can find some time to publish some of the
>> information you've compiled to help with that.
>>
>> > I agree that some changes may break backwards compatibility (such as
>> > Glance's image checksumming), but one approach I think could ease the
>> > transition would be the approach I took for SSH key pair
>> > fingerprinting (also MD5-based, as is Glance image checksums) found
>> > here - https://review.openstack.org/#/c/615460/ . This allows
>> > administrators to choose, hopefully at deployment time, the hashing
>> > algorithm with the default of being the existing MD5 algorithm.
>>
>> That certainly seems like it would provide the most compatibility in the
>> short term.
>>
>> That said, I honestly don't know the best approach for us to take. We're
>> going to need people who understand the issues around FIPS and the
>> issues around maintaining backwards-compatibility to work together to
>> create a recommended approach. Perhaps a few of the folks on this thread
>> would be interested in forming a team to work on that?
>>
>> Doug
>>
>
> I'd be interested in that. Good idea

I added "FIPS compliance" to the list of community goal ideas in
https://etherpad.openstack.org/p/community-goals (see number 35,
currently at the bottom of the etherpad).

Please add more detail there about what exactly is involved, references,
etc. -- whatever you think would be useful to someone learning about
what this is.

>
>> > Another approach would be to make the projects "FIPS aware" where we
>> > choose the hashing algorithm based on the system's FIPS-enforcing
>> > state. An example of doing so is what I'm proposing for Django
>> > (another FIPS-related patch that was needed for OSP 13) -
>> > https://github.com/django/django/pull/10605
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Doug

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


Re: [openstack-dev] [python3] Enabling py37 unit tests

2018-11-07 Thread Doug Hellmann
Mohammed Naser  writes:

> On Wed, Nov 7, 2018 at 2:07 PM Dr. Jens Harbott (frickler)
>  wrote:
>>
>> 2018-11-07 12:47 GMT+00:00 Mohammed Naser :
>> > On Wed, Nov 7, 2018 at 1:37 PM Doug Hellmann  wrote:
>> >>
>> >> Corey Bryant  writes:
>> >>
>> >> > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant 
>> >> > 
>> >> > wrote:
>> >> >
>> >> > I'd like to start moving forward with enabling py37 unit tests for a 
>> >> > subset
>> >> > of projects. Rather than putting too much load on infra by enabling 3 x 
>> >> > py3
>> >> > unit tests for every project, this would just focus on enablement of 
>> >> > py37
>> >> > unit tests for a subset of projects in the Stein cycle. And just to be
>> >> > clear, I would not be disabling any unit tests (such as py35). I'd just 
>> >> > be
>> >> > enabling py37 unit tests.
>> >> >
>> >> > As some background, this ML thread originally led to updating the
>> >> > python3-first governance goal (https://review.openstack.org/#/c/610708/)
>> >> > but has now led back to this ML thread for a +1 rather than updating the
>> >> > governance goal.
>> >> >
>> >> > I'd like to get an official +1 here on the ML from parties such as the 
>> >> > TC
>> >> > and infra in particular but anyone else's input would be welcomed too.
>> >> > Obviously individual projects would have the right to reject proposed
>> >> > changes that enable py37 unit tests. Hopefully they wouldn't, of course,
>> >> > but they could individually vote that way.
>> >> >
>> >> > Thanks,
>> >> > Corey
>> >>
>> >> This seems like a good way to start. It lets us make incremental
>> >> progress while we take the time to think about the python version
>> >> management question more broadly. We can come back to the other projects
>> >> to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out.
>> >
>> > What's the impact on the number of consumption in upstream CI node usage?
>>
>> I think the relevant metric here will be nodes_used * time_used.
>> nodes_used will increase by one, time_used for usual unit test jobs
>> seems to be < 10 minutes, so I'd think that the total increase in CI
>> usage should be neglegible compared to full tempest or similar jobs
>> that take 1-2 hours.
>
> Indeed it doesn't look too bad:
>
> http://zuul.openstack.org/builds?job_name=openstack-tox-py35
>
> It'll be good to try and aim to transition as quickly as possible to
> avoid extra 'wasted' resources in the infrastructure side

Right, I think we can live with it for a few weeks.

-- 
Doug

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


Re: [openstack-dev] [python3] Enabling py37 unit tests

2018-11-07 Thread Doug Hellmann
Corey Bryant  writes:

> On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant 
> wrote:
>
> I'd like to start moving forward with enabling py37 unit tests for a subset
> of projects. Rather than putting too much load on infra by enabling 3 x py3
> unit tests for every project, this would just focus on enablement of py37
> unit tests for a subset of projects in the Stein cycle. And just to be
> clear, I would not be disabling any unit tests (such as py35). I'd just be
> enabling py37 unit tests.
>
> As some background, this ML thread originally led to updating the
> python3-first governance goal (https://review.openstack.org/#/c/610708/)
> but has now led back to this ML thread for a +1 rather than updating the
> governance goal.
>
> I'd like to get an official +1 here on the ML from parties such as the TC
> and infra in particular but anyone else's input would be welcomed too.
> Obviously individual projects would have the right to reject proposed
> changes that enable py37 unit tests. Hopefully they wouldn't, of course,
> but they could individually vote that way.
>
> Thanks,
> Corey

This seems like a good way to start. It lets us make incremental
progress while we take the time to think about the python version
management question more broadly. We can come back to the other projects
to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out.

Doug

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


Re: [openstack-dev] [Openstack-operators] FIPS Compliance

2018-11-07 Thread Doug Hellmann
Joshua Cornutt  writes:

> Doug,
>
> I have such a list put together (my various installation documents for
> getting these clouds working in FIPS mode) but it's hardly ready for
> public consumption. I planned on releasing each bit as a code change
> and/or bug ticket and letting the community consume it as it figures
> some of these things out.

It's likely that the overall migration will go better if we all have the
full context. So I hope you can find some time to publish some of the
information you've compiled to help with that.

> I agree that some changes may break backwards compatibility (such as
> Glance's image checksumming), but one approach I think could ease the
> transition would be the approach I took for SSH key pair
> fingerprinting (also MD5-based, as is Glance image checksums) found
> here - https://review.openstack.org/#/c/615460/ . This allows
> administrators to choose, hopefully at deployment time, the hashing
> algorithm with the default of being the existing MD5 algorithm.

That certainly seems like it would provide the most compatibility in the
short term.

That said, I honestly don't know the best approach for us to take. We're
going to need people who understand the issues around FIPS and the
issues around maintaining backwards-compatibility to work together to
create a recommended approach. Perhaps a few of the folks on this thread
would be interested in forming a team to work on that?

Doug

> Another approach would be to make the projects "FIPS aware" where we
> choose the hashing algorithm based on the system's FIPS-enforcing
> state. An example of doing so is what I'm proposing for Django
> (another FIPS-related patch that was needed for OSP 13) -
> https://github.com/django/django/pull/10605
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)

2018-11-06 Thread Doug Hellmann
Ghanshyam Mann  writes:

>   On Wed, 07 Nov 2018 06:51:32 +0900 Slawomir Kaplonski 
>  wrote  
>  > Hi,
>  > 
>  > > Wiadomość napisana przez Jeremy Stanley  w dniu 
> 06.11.2018, o godz. 22:25:
>  > > 
>  > > On 2018-11-06 22:05:49 +0100 (+0100), Slawek Kaplonski wrote:
>  > > [...]
>  > >> also add jobs like "devstack-xenial" and "tempest-full-xenial"
>  > >> which projects can use still for some time if their job on Bionic
>  > >> would be broken now?
>  > > [...]
>  > > 
>  > > That opens the door to piecemeal migration, which (as we similarly
>  > > saw during the Trusty to Xenial switch) will inevitably lead to
>  > > projects who no longer gate on Xenial being unable to integration
>  > > test against projects who don't yet support Bionic. At the same
>  > > time, projects which have switched to Bionic will start merging
>  > > changes which only work on Bionic without realizing it, so that
>  > > projects which test on Xenial can't use them. In short, you'll be
>  > > broken either way. On top of that, you can end up with projects that
>  > > don't get around to switching completely before release comes, and
>  > > then they're stuck having to manage a test platform transition on a
>  > > stable branch.
>  > 
>  > I understand Your point here but will option 2) from first email lead to 
> the same issues then?
>
> seems so. approach 1 is less risky for such integrated testing issues and 
> requires less work. In approach 1, we can coordinate the base job migration 
> with project side testing with bionic.
>
> -gmann

I like the approach of updating the devstack jobs to move everything to
Bionic at one time because it sounds like it presents less risk of us
ending up with something that looks like it works together but doesn't
actually because it's tested on a different platform, as well as being
less likely to cause us to have to do major porting work in stable
branches after the release.

We'll need to take the same approach when updating the version of Python
3 used inside of devstack.

Doug

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


Re: [openstack-dev] [Openstack-operators] FIPS Compliance

2018-11-06 Thread Doug Hellmann
Luke Hinds  writes:

> On Tue, Nov 6, 2018 at 2:04 PM Julia Kreger 
> wrote:
>
>>
>>
>> On Tue, Nov 6, 2018 at 5:07 AM Doug Hellmann 
>> wrote:
>>
>>> Sean McGinnis  writes:
>>>
>>> > I'm interested in some feedback from the community, particularly those
>>> running
>>> > OpenStack deployments, as to whether FIPS compliance [0][1] is
>>> something folks
>>> > are looking for.
>>> [trim]
>>>
>>> I know we've had some interest in it at different times. I think some of
>>> the changes will end up being backwards-incompatible, so we may need a
>>> "FIPS-mode" configuration flag for those, but in other places we could
>>> just switch hashing algorithms and be fine.
>>>
>>> I'm not sure if anyone has put together the details of what would be
>>> needed to update each project, but this feels like it could be a
>>> candidate for a goal for a future cycle once we have that information
>>> and can assess the level of effort.
>>>
>>> Doug
>>>
>>>
>> +1 to a FIPS-mode. I think it would be fair to ask projects, to over the
>> course of the next month or three, to evaluate their current standing and
>> report what they perceive the effort to be.
>>
>> I think only then we can really determine if it is the right direction to
>> take for a cycle goal.
>>
>> -Julia
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> Understand it's early to be discussing design, but would like to get it on
> record  that if we can, we should try to use 'Algorithm Agility' rather
> then all moving to the next one up and setting to SHA. That way we can
> deal with what might seem unfathomable now, happening later (strong cryptos
> getting cracked).
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Yeah, it feels like we want 1 place to get the right "current"
algorithm. Unfortunately, we still need to support those old ones
because we need to be able to validate any existing data like stored
signatures.

Is there already a python library out in the wild that we could use for
providing a consistent API for that? If not, perhaps building that is an
independent step someone could be working on now.

Doug

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


Re: [openstack-dev] [Openstack-operators] FIPS Compliance

2018-11-06 Thread Doug Hellmann
Sean McGinnis  writes:

> I'm interested in some feedback from the community, particularly those running
> OpenStack deployments, as to whether FIPS compliance [0][1] is something folks
> are looking for.
>
> I've been seeing small changes starting to be proposed here and there for
> things like MD5 usage related to its incompatibility to FIPS mode. But looking
> across a wider stripe of our repos, it appears like it would be a wider effort
> to be able to get all OpenStack services compatible with FIPS mode.
>
> This should be a fairly easy thing to test, but before we put in much effort
> into updating code and figuring out testing, I'd like to see some input on
> whether something like this is needed.
>
> Thanks for any input on this.
>
> Sean
>
> [0] https://en.wikipedia.org/wiki/FIPS_140-2
> [1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

I know we've had some interest in it at different times. I think some of
the changes will end up being backwards-incompatible, so we may need a
"FIPS-mode" configuration flag for those, but in other places we could
just switch hashing algorithms and be fine.

I'm not sure if anyone has put together the details of what would be
needed to update each project, but this feels like it could be a
candidate for a goal for a future cycle once we have that information
and can assess the level of effort.

Doug

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


Re: [openstack-dev] [Openstack-sigs] Dropping lazy translation support

2018-11-05 Thread Doug Hellmann
Matt Riedemann  writes:

> On 11/5/2018 1:36 PM, Doug Hellmann wrote:
>> I think the lazy stuff was all about the API responses. The log
>> translations worked a completely different way.
>
> Yeah maybe. And if so, I came across this in one of the blueprints:
>
> https://etherpad.openstack.org/p/disable-lazy-translation
>
> Which says that because of a critical bug, the lazy translation was 
> disabled in Havana to be fixed in Icehouse but I don't think that ever 
> happened before IBM developers dropped it upstream, which is further 
> justification for nuking this code from the various projects.

I agree.

Doug

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


[openstack-dev] [tc] Technical Committee status update for 5 November

2018-11-05 Thread Doug Hellmann
This is the weekly summary of work being done by the Technical Committee
members. The full list of active items is managed in the wiki:
https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

It has been three weeks since the last update email, in part due to my
absence. We have lots of updates this time around.

Project updates:

* Add os_manila to openstack-ansible:
  https://review.openstack.org/#/c/608403/
* Add cells charms and interfaces:
  https://review.openstack.org/#/c/608866/
* Add octavia charm: https://review.openstack.org/#/c/608283/
* Add puppet-crane: https://review.openstack.org/#/c/610015/
* Add openstack-helm images repository:
  https://review.openstack.org/#/c/611895/
* Add blazar-specs repository: https://review.openstack.org/#/c/612431/
* Add openstack-helm docs repository:
  https://review.openstack.org/#/c/611896/
* Retire anchor: https://review.openstack.org/#/c/611187/
* Remove Dragonflow from governance:
  https://review.openstack.org/#/c/613856/

Other updates:

* Reword "open source" definition in 4 Opens document to remove language
  that does not come through clearly when translated:
  https://review.openstack.org/#/c/613894/
* Support "Train" as a candidate name for the T series:
  https://review.openstack.org/#/c/611511/
* Update the charter section on TC meetings:
  https://review.openstack.org/#/c/608751/

== TC Meetings ==

In order to fulfill our obligations under the OpenStack Foundation
bylaws, the TC needs to hold meetings at least once each quarter. We
agreed to meet monthly, and to emphasize agenda items that help us move
initiatives forward while leaving most of the discussion of those topics
to the mailing list. Our first meeting was held on 1 Nov. The agendas
for all of our meetings will be sent to the openstack-dev mailing list
in advance, and links to the logs and summary will be sent as a follow
up after the meeting.

* http://lists.openstack.org/pipermail/openstack-dev/2018-November/136220.html

The next meeting will be 6 December 1400 UTC in #openstack-tc

== Team Liaisons ==

The TC liaisons to each project team for the Stein series are now
assigned. Please contact your liaison if you have any issues the TC can
help with, and watch for email from them to check in with your team
before the end of this development cycle.

* https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams

== Sessions at the Forum ==

Many of us will be meeting in Berlin next week for the OpenStack Summit
and Forum. There are several sessions related to project governance or
community that may be of interest.

* Getting OpenStack Users Involved in the Project:
  
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22813/getting-openstack-users-involved-in-the-project
* Community outreach when culture, time zones, and language differ:
  
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22820/community-outreach-when-culture-time-zones-and-language-differ
* Wednesday Keynote segment, Community Contributor Recognition & How to
  Get Started:
  
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22959/community-contributor-recognition-and-how-to-get-started
* Expose SIGs and WGs:
  
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22750/expose-sigs-and-wgs
* Cross-technical leadership session (OpenStack, Kata, StarlingX,
  Airship, Zuul):
  
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22815/cross-technical-leadership-session-openstack-kata-starlingx-airship-zuul
* "Vision for OpenStack clouds" discussion:
  
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22818/vision-for-openstack-clouds-discussion
* Technical Committee Vision Retrospective:
  
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22825/technical-committee-vision-retrospective
* T series community goal discussion:
  
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22814/t-series-community-goal-discussion

== Ongoing Discussions ==

We have several governance changes up for review related to deciding how
we will manage future Python 3 upgrades (including adding 3.7 and
possibly dropping 3.5 during Stein).

* Make python 3 testing requirement less specific:
  https://review.openstack.org/#/c/611010/
* Explicitly declare stein supported runtimes:
  https://review.openstack.org/#/c/611080/
* Resolution on keeping up with Python 3 releases:
  https://review.openstack.org/#/c/613145/

== TC member actions/focus/discussions for the coming week(s) ==

The TC, UC, and leadership of other foundation projects will join the
foundation Board for a joint leadership meeting on 12 November. See the
wiki for details.

* https://wiki.openstack.org/wiki/Governance/Foundation/12Nov2018BoardMeeting

== Contacting the TC ==

The Technical Commi

[openstack-dev] [tc] liaison assignments

2018-11-05 Thread Doug Hellmann
TC members,

I have updated the liaison assignments to fill in all of the
gaps. Please take a moment to review the list [1] so you know your
assignments.

Next week will be a good opportunity to touch bases with your teams.

Doug

[1] https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams

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


Re: [openstack-dev] [Openstack-sigs] Dropping lazy translation support

2018-11-05 Thread Doug Hellmann
Matt Riedemann  writes:

> This is a follow up to a dev ML email [1] where I noticed that some 
> implementations of the upgrade-checkers goal were failing because some 
> projects still use the oslo_i18n.enable_lazy() hook for lazy log message 
> translation (and maybe API responses?).
>
> The very old blueprints related to this can be found here [2][3][4].
>
> If memory serves me correctly from my time working at IBM on this, this 
> was needed to:
>
> 1. Generate logs translated in other languages.
>
> 2. Return REST API responses if the "Accept-Language" header was used 
> and a suitable translation existed for that language.
>
> #1 is a dead horse since I think at least the Ocata summit when we 
> agreed to no longer translate logs since no one used them.
>
> #2 is probably something no one knows about. I can't find end-user 
> documentation about it anywhere. It's not tested and therefore I have no 
> idea if it actually works anymore.
>
> I would like to (1) deprecate the oslo_i18n.enable_lazy() function so 
> new projects don't use it and (2) start removing the enable_lazy() usage 
> from existing projects like keystone, glance and cinder.
>
> Are there any users, deployments or vendor distributions that still rely 
> on this feature? If so, please speak up now.
>
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-November/136285.html
> [2] https://blueprints.launchpad.net/oslo-incubator/+spec/i18n-messages
> [3] https://blueprints.launchpad.net/nova/+spec/i18n-messages
> [4] https://blueprints.launchpad.net/nova/+spec/user-locale-api
>
> -- 
>
> Thanks,
>
> Matt
>
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs

I think the lazy stuff was all about the API responses. The log
translations worked a completely different way.

Doug

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


Re: [openstack-dev] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs

2018-11-01 Thread Doug Hellmann
Doug Hellmann  writes:

> Doug Hellmann  writes:
>
> I asked the owners of the name "heat" to allow us to use it, and they
> rejected the request. So, I proposed a change to heat to update the
> sdist name to "openstack-heat".
>
> * https://review.openstack.org/606160

This patch is now passing tests. Please prioritize reviewing it, because
it is going to block releases of heat.

Doug

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


[openstack-dev] [tc][all][goals] selecting community-wide goals for T development cycle

2018-11-01 Thread Doug Hellmann
We will have a session at the forum to discuss the community-wide goals
[0] we want to select for the T cycle. That's a long way off, but given
the fact that we don't have a PTG between Berlin and Denver, and that
we've recently had feedback that we need to have tools finished better
before starting, I think we do need to begin the conversation now.

The Forum session is on Thursday at 17:10, at the end of the Forum
[1]. There's an etherpad up [2] for folks to start offering
suggestions. And the etherpad with the archives of past ideas is also
still online [3].

Let's use this thread to talk about the Forum session. If you want to
propose a specific goal, please start a *new* thread here on
openstack-dev so that we can keep all of the discussion clearly
separated. Please keep in mind that these goals should apply to most, if
not all, projects. Work to integrate 2 services can be managed through
the normal feature prioritization processes of the teams involved.

I will be moderating the discussion at the Forum, but I am not signing
up as a goal champion or to drive the goal selection. If you are
interested in helping with either of those things, please let me know.

Doug

[0] https://governance.openstack.org/tc/goals/index.html
[1] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22814/t-series-community-goal-discussion
[2] https://etherpad.openstack.org/p/BER-t-series-goals
[3] https://etherpad.openstack.org/p/community-goals


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


Re: [openstack-dev] [tc] agenda for TC meeting 1 Nov 1400 UTC

2018-11-01 Thread Doug Hellmann
Doug Hellmann  writes:

> TC members,
>
> The TC will be meeting on 1 Nov at 1400 UTC in #openstack-tc to discuss
> some of our ongoing initiatives. Here is the agenda for this week.
>
> * meeting procedures
>
> * discussion of topics for joint leadership meeting at Summit in
>   Berlin
>
> * completing TC liaison assignments
> ** https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams
>
> * documenting chair responsibilities
> ** https://etherpad.openstack.org/p/tc-chair-responsibilities
>
> * reviewing the health-check check list
> ** https://wiki.openstack.org/wiki/OpenStack_health_tracker#Health_check_list
>
> * deciding next steps on technical vision statement
> ** https://review.openstack.org/592205
>
> * deciding next steps on python 3 and distro versions for PTI
> ** https://review.openstack.org/610708 Add optional python3.7 unit test 
> enablement to python3-first
> ** https://review.openstack.org/611010 Make Python 3 testing requirement less 
> specific
> ** https://review.openstack.org/611080 Explicitly declare Stein supported 
> runtimes
> ** https://review.openstack.org/613145 Resolution on keeping up with Python 3 
> releases
>
> * reviews needing attention
> ** https://review.openstack.org/613268 Indicate relmgt style for each 
> deliverable
> ** https://review.openstack.org/613856 Remove Dragonflow from the official 
> projects list
>
> If you have suggestions for topics for the next meeting (6 Dec), please
> add them to the wiki at
> https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

The logs for this meeting are available now at

Minutes:
http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-11-01-14.01.html
Minutes (text): 
http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-11-01-14.01.txt
Log:
http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-11-01-14.01.log.html

Doug

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


Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed

2018-11-01 Thread Doug Hellmann
Jeremy Stanley  writes:

> On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote:
> [...]
>> Did I miss any options or issues with this approach?
>
> https://review.openstack.org/578557

How high of a priority is rolling that feature out? It does seem to
eliminate this particular issue (even the edge cases described in the
commit message shouldn't affect us based on our typical practices), but
until we have one of the two changes in place we're going to have this
issue with every release we tag.

Doug

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

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


[openstack-dev] [tc] publishing openstack_governance library to PyPI

2018-11-01 Thread Doug Hellmann
TC members,

I have a series of patches up for review starting at [1] to create a
small library for reading and manipulating the project reference data in
the YAML files in the openstack/governance repository. After copying
similar code into a 3rd repository that wants to consume it last cycle,
I thought I ought to just go ahead and do this properly.

The patch in [2] is an example of how the releases repository can take
advantage of having a library like this.

Please add the series to your review queue.

Doug

[1] https://review.openstack.org/#/c/614597
[2] https://review.openstack.org/614606

__
OpenStack Development Mailing 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-job-failures][release][infra] Tag of openstack/keystone failed

2018-11-01 Thread Doug Hellmann
Doug Hellmann  writes:

> z...@openstack.org writes:
>
>> Build failed.
>>
>> - publish-openstack-releasenotes-python3 
>> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes-python3/7347218/
>>  : POST_FAILURE in 13m 53s
>> - publish-openstack-releasenotes 
>> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes/a4c2e21/
>>  : SUCCESS in 13m 54s
>>
>> ___
>> Release-job-failures mailing list
>> release-job-failu...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
>
> Keystone is configured in stable/queens with the release-notes-jobs
> project template and in master with the release-notes-jobs-python3
> template. This is, AFAICT, exactly what we said should be done. However,
> both of the templates include jobs in the "tag" pipeline, and tags are
> not branch-aware. That means we end up running both versions of the
> release notes publishing jobs when we tag a release, and the results may
> be unpredictable. This problem will affect other projects as well.
>
> I think we have a few options.
>
> 1. Move the job settings out of the source repository into
>project-config, like we do for the release jobs, so that we always
>run the same version in all cases.
>
>This has two downsides.
>
>First, we would have to support the python3 variant even on very old
>stable branches. That shouldn't be a very big concern, though,
>because that job does not install the source for the project or its
>dependencies.
>
>Second, we would have to modify all of the zuul configurations for
>all of our old branches, again. As much as I'm enjoying the jokes
>about how I'm padding my contribution stats this cycle, I don't
>really want to do that.
>
> 2. Make the job itself smart enough to figure out whether to run with
>python 2 or 3.
>
>We could update both jobs to look at some setting in the repo to
>decide which version to use. This feels excessively complicated,
>might still result in having to modify some settings in the stable
>branches, and would mean we would have to customize the shared
>versions of the jobs defined in the zuul-jobs repo.
>
> 3. Modify the python 2 version of the project template
>("release-notes-jobs") to remove the "tag" pipeline settings.
>
>This would let us continue to use the python 2 variant for tests and
>when patches merge, and only use the python 3 job for tags. As with
>option 1, we would have to be sure that the release notes job works
>under python 3 for all repos, but as described above that isn't a big
>concern.
>
> I think we should take option 3, and will be preparing a patch to do
> that shortly.
>
> Did I miss any options or issues with this approach?
>
> Doug

See https://review.openstack.org/614758

Doug

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


Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed

2018-11-01 Thread Doug Hellmann
z...@openstack.org writes:

> Build failed.
>
> - publish-openstack-releasenotes-python3 
> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes-python3/7347218/
>  : POST_FAILURE in 13m 53s
> - publish-openstack-releasenotes 
> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes/a4c2e21/
>  : SUCCESS in 13m 54s
>
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

Keystone is configured in stable/queens with the release-notes-jobs
project template and in master with the release-notes-jobs-python3
template. This is, AFAICT, exactly what we said should be done. However,
both of the templates include jobs in the "tag" pipeline, and tags are
not branch-aware. That means we end up running both versions of the
release notes publishing jobs when we tag a release, and the results may
be unpredictable. This problem will affect other projects as well.

I think we have a few options.

1. Move the job settings out of the source repository into
   project-config, like we do for the release jobs, so that we always
   run the same version in all cases.

   This has two downsides.

   First, we would have to support the python3 variant even on very old
   stable branches. That shouldn't be a very big concern, though,
   because that job does not install the source for the project or its
   dependencies.

   Second, we would have to modify all of the zuul configurations for
   all of our old branches, again. As much as I'm enjoying the jokes
   about how I'm padding my contribution stats this cycle, I don't
   really want to do that.

2. Make the job itself smart enough to figure out whether to run with
   python 2 or 3.

   We could update both jobs to look at some setting in the repo to
   decide which version to use. This feels excessively complicated,
   might still result in having to modify some settings in the stable
   branches, and would mean we would have to customize the shared
   versions of the jobs defined in the zuul-jobs repo.

3. Modify the python 2 version of the project template
   ("release-notes-jobs") to remove the "tag" pipeline settings.

   This would let us continue to use the python 2 variant for tests and
   when patches merge, and only use the python 3 job for tags. As with
   option 1, we would have to be sure that the release notes job works
   under python 3 for all repos, but as described above that isn't a big
   concern.

I think we should take option 3, and will be preparing a patch to do
that shortly.

Did I miss any options or issues with this approach?

Doug

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


[openstack-dev] [goal][python3] week 12 update

2018-10-31 Thread Doug Hellmann
This is week 12 of the "Run under Python 3 by default" goal
(https://governance.openstack.org/tc/goals/stein/python3-first.html).

Observant readers will notice that the last update email was during week
9. I've been out for a couple of weeks, but you've all been busy in that
time!

== What we learned last week ==

I'm still working on an upgrade script for heat to allow us to rename it
and publish releases.

* https://review.openstack.org/#/c/606160/

== Ongoing and Completed Work ==

We are very very close to finishing the phase of work that updates the
tox settings and documentation build jobs.

Those documentation updates should be relatively quick to review because
they're very minimal patches. Please take a few minutes to look for them
and let's try to get them merged before the first milestone. The tox
patches may require a bit more work to update pylint and the goal
champions could use your help there (see below).

+-+--+-+--+-++---++
| Team| tox defaults | Docs| 3.6 unit | Failing | 
Unreviewed | Total | Champion   |
+-+--+-+--+-++---++
| adjutant|   1/  1  | -   | +    |   0 |  
1 | 2 | Doug Hellmann  |
| barbican| +|   1/  3 | +    |   1 |  
1 | 7 | Doug Hellmann  |
| blazar  | +| +   | +|   0 |  
0 | 9 | Nguyen Hai |
| Chef OpenStack  | +| -   | -    |   0 |  
0 | 2 | Doug Hellmann  |
| cinder  | +| +   | +    |   0 |  
0 |11 | Doug Hellmann  |
| cloudkitty  | +| +   | +    |   0 |  
0 | 9 | Doug Hellmann  |
| congress| +| +   | +|   0 |  
0 | 9 | Nguyen Hai |
| cyborg  | +| +   | +|   0 |  
0 | 7 | Nguyen Hai |
| designate   | +| +   | +|   0 |  
0 | 9 | Nguyen Hai |
| Documentation   | +| +   | +    |   0 |  
0 |10 | Doug Hellmann  |
| dragonflow  | -| +   | +|   0 |  
0 | 2 | Nguyen Hai |
| ec2-api |   2/  2  | +   | +|   2 |  
2 | 7 ||
| freezer | +| +   | +|   0 |  
0 |11 ||
| glance  | +| +   | +|   0 |  
0 |10 | Nguyen Hai |
| heat|   3/  8  | +   |   1/  7  |   2 |  
0 |21 | Doug Hellmann  |
| horizon | +| +   | +|   0 |  
0 |34 | Nguyen Hai |
| I18n| +| -   | -    |   0 |  
0 | 1 | Doug Hellmann  |
| InteropWG   |   3/  4  | +   |   1/  3  |   2 |  
2 |10 | Doug Hellmann  |
| ironic  |   1/ 10  | +   | +    |   0 |  
0 |35 | Doug Hellmann  |
| karbor  | +| +   | +|   0 |  
0 | 7 | Nguyen Hai |
| keystone| +| +   | +    |   0 |  
0 |18 | Doug Hellmann  |
| kolla   | +| +   | +|   0 |  
0 | 5 ||
| kuryr   | +| +   | +    |   0 |  
0 | 9 | Doug Hellmann  |
| magnum  |   2/  5  | +   | +|   0 |  
1 |10 ||
| manila  | +| +   | +|   0 |  
0 |13 | Goutham Pacha Ravi |
| masakari|   2/  5  | +   | -|   0 |  
2 | 6 | Nguyen Hai |
| mistral | +| +   | +|   0 |  
0 |13 | Nguyen Hai |
| monasca |   1/ 17  | +   | +    |   1 |  
1 |34 | Doug Hellmann  |
| murano  | +| +   | +|   0 |  
0 |14 ||
| neutron |   7/ 19  |   1/ 14 |   1/ 13  |   6 |  
3 |46 | Doug Hellmann  |
| nova| +| +   | +|   0 |  
0 |14 ||
| octavia | +| +   | +|   0 |  
0 |12 | Nguyen Hai |
| OpenStack Charms|  36/ 73  | -   | -    |  36 | 

Re: [openstack-dev] [tripleo] reducing our upstream CI footprint

2018-10-31 Thread Doug Hellmann
Alex Schultz  writes:

> Hey everyone,
>
> Based on previous emails around this[0][1], I have proposed a possible
> reducing in our usage by switching the scenario001--011 jobs to
> non-voting and removing them from the gate[2]. This will reduce the
> likelihood of causing gate resets and hopefully allow us to land
> corrective patches sooner.  In terms of risks, there is a risk that we
> might introduce breaking changes in the scenarios because they are
> officially non-voting, and we will still be gating promotions on these
> scenarios.  This means that if they are broken, they will need the
> same attention and care to fix them so we should be vigilant when the
> jobs are failing.
>
> The hope is that we can switch these scenarios out with voting
> standalone versions in the next few weeks, but until that I think we
> should proceed by removing them from the gate.  I know this is less
> than ideal but as most failures with these jobs in the gate are either
> timeouts or unrelated to the changes (or gate queue), they are more of
> hindrance than a help at this point.
>
> Thanks,
> -Alex
>
> [0] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-October/136141.html
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-October/135396.html
> [2] 
> https://review.openstack.org/#/q/topic:reduce-tripleo-usage+(status:open+OR+status:merged)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

This makes a lot of sense as a temporary measure. Thanks for continuing
to drive these changes!

Doug


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


[openstack-dev] [tc] agenda for TC meeting 1 Nov 1400 UTC

2018-10-30 Thread Doug Hellmann
TC members,

The TC will be meeting on 1 Nov at 1400 UTC in #openstack-tc to discuss
some of our ongoing initiatives. Here is the agenda for this week.

* meeting procedures

* discussion of topics for joint leadership meeting at Summit in
  Berlin

* completing TC liaison assignments
** https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams

* documenting chair responsibilities
** https://etherpad.openstack.org/p/tc-chair-responsibilities

* reviewing the health-check check list
** https://wiki.openstack.org/wiki/OpenStack_health_tracker#Health_check_list

* deciding next steps on technical vision statement
** https://review.openstack.org/592205

* deciding next steps on python 3 and distro versions for PTI
** https://review.openstack.org/610708 Add optional python3.7 unit test 
enablement to python3-first
** https://review.openstack.org/611010 Make Python 3 testing requirement less 
specific
** https://review.openstack.org/611080 Explicitly declare Stein supported 
runtimes
** https://review.openstack.org/613145 Resolution on keeping up with Python 3 
releases

* reviews needing attention
** https://review.openstack.org/613268 Indicate relmgt style for each 
deliverable
** https://review.openstack.org/613856 Remove Dragonflow from the official 
projects list

If you have suggestions for topics for the next meeting (6 Dec), please
add them to the wiki at
https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions

Doug

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


Re: [openstack-dev] [openstack-community] Sharing upstream contribution mentoring result with Korea user group

2018-10-30 Thread Doug Hellmann
"Ian Y. Choi"  writes:

> Hello,
>
> I got involved organizing & mentoring Korean people for OpenStack 
> upstream contribution for about last two months,
> and would like to share with community members.
>
> Total nine mentees had started to learn OpenStack, contributed, and 
> finally survived as volunteers for
>   1) developing OpenStack mobile app for better mobile user interfaces 
> and experiences
>      (inspired from https://github.com/stackerz/app which worked on Juno 
> release), and
>   2) translating OpenStack official project artifacts including documents,
>   and Container Whitepaper ( 
> https://www.openstack.org/containers/leveraging-containers-and-openstack/ ).
>
> Korea user group organizers (Seongsoo Cho, Taehee Jang, Hocheol Shin, 
> Sungjin Kang, and Andrew Yongjoon Kong)
> all helped to organize total 8 offline meetups + one mini-hackathon and 
> mentored to attendees.
>
> The followings are brief summary:
>   - "OpenStack Controller" Android app is available on Play Store
>    : 
> https://play.google.com/store/apps/details?id=openstack.contributhon.com.openstackcontroller
>     (GitHub: https://github.com/kosslab-kr/openstack-controller )
>
>   - Most high-priority projects (although it is not during string freeze 
> period) and documents are
>     100% translated into Korean: Horizon, OpenStack-Helm, I18n Guide, 
> and Container Whitepaper.
>
>   - Total 18,695 words were translated into Korean by four contributors
>    (confirmed through Zanata API: 
> https://translate.openstack.org/rest/stats/user/[Zanata 
> ID]/2018-08-16..2018-10-25 ):
>
> ++---+-+
> | Zanata ID  | Name  | Number of words |
> ++---+-+
> | ardentpark | Soonyeul Park | 12517   |
> ++---+-+
> | bnitech    | Dongbim Im    | 693 |
> ++---+-+
> | csucom | Sungwook Choi | 4397    |
> ++---+-+
> | jaeho93    | Jaeho Cho | 1088    |
> ++---+-+
>
>   - The list of projects translated into Korean are described as:
>
> +-+-+
> | Project | Number of words |
> +-+-+
> | api-site    | 20  |
> +-+-+
> | cinder  | 405 |
> +-+-+
> | designate-dashboard | 4   |
> +-+-+
> | horizon | 3226    |
> +-+-+
> | i18n    | 434 |
> +-+-+
> | ironic  | 4   |
> +-+-+
> | Leveraging Containers and OpenStack | 5480    |
> +-+-+
> | neutron-lbaas-dashboard | 5   |
> +-+-+
> | openstack-helm  | 8835    |
> +-+-+
> | trove-dashboard | 89  |
> +-+-+
> | zun-ui  | 193 |
> +-+-+
>
> I would like to really appreciate all co-mentors and participants on 
> such a big event for promoting OpenStack contribution.
> The venue and food were supported by Korea Open Source Software 
> Development Center ( https://kosslab.kr/ ).
>
>
> With many thanks,
>
> /Ian
>
> ___
> Community mailing list
> commun...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/community

This is an excellent success story, Ian, thank you for sharing it and
for leading the effort.

Doug

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


Re: [openstack-dev] Proposal for a process to keep up with Python releases

2018-10-30 Thread Doug Hellmann
Zane Bitter  writes:

> On 19/10/18 11:17 AM, Zane Bitter wrote:
>> I'd like to propose that we handle this by setting up a unit test 
>> template in openstack-zuul-jobs for each release. So for Stein we'd have 
>> openstack-python3-stein-jobs. This template would contain:
>> 
>> * A voting gate job for the highest minor version of py3 we want to 
>> support in that release.
>> * A voting gate job for the lowest minor version of py3 we want to 
>> support in that release.
>> * A periodic job for any interim minor releases.
>> * (Starting late in the cycle) a non-voting check job for the highest 
>> minor version of py3 we want to support in the *next* release (if 
>> different), on the master branch only.
>> 
>> So, for example, (and this is still under active debate) for Stein we 
>> might have gating jobs for py35 and py37, with a periodic job for py36. 
>> The T jobs might only have voting py36 and py37 jobs, but late in the T 
>> cycle we might add a non-voting py38 job on master so that people who 
>> haven't switched to the U template yet can see what, if anything, 
>> they'll need to fix.
>
> Just to make it easier to visualise, here is an example for how the Zuul 
> config _might_ look now if we had adopted this proposal during Rocky:
>
> https://review.openstack.org/611947
>
> And instead of having a project-wide goal in Stein to add 
> `openstack-python36-jobs` to the list that currently includes 
> `openstack-python35-jobs` in each project's Zuul config[1], we'd have 
> had a goal to change `openstack-python3-rocky-jobs` to 
> `openstack-python3-stein-jobs` in each project's Zuul config.

If we set up the template before we branch stein for T, we could
generate a patch as part of the branching process.

Doug

>
> - ZB
>
>
> [1] 
> https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs
>
> __
> OpenStack Development Mailing 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] [all] linter jobs testing packaging data

2018-10-30 Thread Doug Hellmann
Earlier today I learned that we have a few repositories with linter jobs
failing (or at least reporting warnings) because they are running
"python setup.py check" to test that the packaging meta-data is OK.

This method of testing has been deprecated in favor of using the command
"twine check", which requires a bit of extra setup but performs multiple
checks on the built packages. Luckily, test-release-openstack-python3
job already runs "twine check".

Since it is part of the publish-to-pypi-python3 template, any
python-based projects that are releasing using the new job template
(which should be all official projects now) have
test-release-openstack-python3 configured to run when any files related
to packaging are modified.

Therefore, rather than updating the failing linter jobs to perform the
steps necessary to run twine, teams should simply remove the check and
allow the existing test job to perform that check. In addition to
avoiding redundancy, this means we will be able update the job in one
place instead of having to touch every repo when twine inevitably
changes in the future.

Sean is working on a set of patches to fix up some of the repos that
have issues, so please approve those quickly when they come in.

Doug

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


Re: [openstack-dev] [goals][upgrade-checkers] [telemetry] Upgrade checks for telemetry services

2018-10-30 Thread Doug Hellmann
AKHIL Jain  writes:

> Hi Matt and Telemetry Team,
>
> I was going through the remaining project to be implemented with 
> upgrade-checkers placeholder framework. I would like to know about the 
> projects to implement the same under telemetry tab.
>
> According to my understanding from below link, multiple projects come under 
> telemetry:
> https://wiki.openstack.org/wiki/Telemetry#Managed
>
> Aodh being alarming service triggers alarm when collected data breaks over 
> set rules. Also, Aodh work as a standalone project using any 
> backend(ceilometer, gnocchi. etc.):
> So there are expected changes b/w releases.
>
> Ceilometer being data collection service(that helps in customer billing, 
> resource tracking, and alarming): As this service is involved in data pooling 
> from other projects. So there can be chances to perform upgrade checks.
>
> Panko being indexing service, that provides the ability to store and query 
> event data. Related changes to indexing objects can be checked while upgrading
>
> So, should we add upgrade-check command in each project or single command 
> upgrade-checks should be there to tell each service upgrade status?
>
> Thanks,
> Akhil
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Each of those services has its own configuration file and database, and
the code is in separate repositories, so it seems like we would want a
separate upgrade check command for each one.

Doug

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


Re: [openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk

2018-10-29 Thread Doug Hellmann
Monty Taylor  writes:

> On 10/29/18 10:47 AM, Doug Hellmann wrote:
>> Monty Taylor  writes:
>> 
>>> Heya,
>>>
>>> Tobias and I were chatting at OpenStack Days Nordic about the Public
>>> Cloud Working Group potentially taking over as custodians of the vendor
>>> profile information [0][1] we keep in openstacksdk (and previously in
>>> os-client-config)
>>>
>>> I think this is a fine idea, but we've got some dancing to do I think.
>>>
>>> A few years ago Dean and I talked about splitting the vendor data into
>>> its own repo. We decided not to at the time because it seemed like extra
>>> unnecessary complication. But I think we may have reached that time.
>>>
>>> We should split out a new repo to hold the vendor data json files. We
>>> can manage this repo pretty much how we manage the
>>> service-types-authority [2] data now. Also similar to that (and similar
>>> to tzdata) these are files that contain information that is true
>>> currently and is not release specific - so it should be possible to
>>> update to the latest vendor files without updating to the latest
>>> openstacksdk.
>>>
>>> If nobody objects, I'll start working through getting a couple of new
>>> repos created. I'm thinking openstack/vendor-profile-data, owned/managed
>>> by Public Cloud WG, with the json files, docs, json schema, etc, and a
>>> second one, openstack/os-vendor-profiles - owned/managed by the
>>> openstacksdk team that's just like os-service-types [3] and is a
>>> tiny/thin library that exposes the files to python (so there's something
>>> to depend on) and gets proposed patches from zuul when new content is
>>> landed in openstack/vendor-profile-data.
>>>
>>> How's that sound?
>> 
>> I understand the benefit of separating the data files from the SDK, but
>> what is the benefit of separating the data files from the code that
>> reads them?
>
> I'd say primarily so that the same data files can be used from other 
> languages. (similar to having the service-types-authority data exist 
> separate from the python library that consumes it.)
>
> Also - there is a separation of concerns, potentially. The review team 
> for a vendor-data repo could just be public cloud sig folks - and what 
> they are reviewing is the accuracy of the data. The python code to 
> consume that and interpret it is likely a different set of humans.

The argument about languages is more convincing but I'll accept both
answers. The plan makes sense to me, now.

Doug

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


Re: [openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk

2018-10-29 Thread Doug Hellmann
Monty Taylor  writes:

> Heya,
>
> Tobias and I were chatting at OpenStack Days Nordic about the Public 
> Cloud Working Group potentially taking over as custodians of the vendor 
> profile information [0][1] we keep in openstacksdk (and previously in 
> os-client-config)
>
> I think this is a fine idea, but we've got some dancing to do I think.
>
> A few years ago Dean and I talked about splitting the vendor data into 
> its own repo. We decided not to at the time because it seemed like extra 
> unnecessary complication. But I think we may have reached that time.
>
> We should split out a new repo to hold the vendor data json files. We 
> can manage this repo pretty much how we manage the 
> service-types-authority [2] data now. Also similar to that (and similar 
> to tzdata) these are files that contain information that is true 
> currently and is not release specific - so it should be possible to 
> update to the latest vendor files without updating to the latest 
> openstacksdk.
>
> If nobody objects, I'll start working through getting a couple of new 
> repos created. I'm thinking openstack/vendor-profile-data, owned/managed 
> by Public Cloud WG, with the json files, docs, json schema, etc, and a 
> second one, openstack/os-vendor-profiles - owned/managed by the 
> openstacksdk team that's just like os-service-types [3] and is a 
> tiny/thin library that exposes the files to python (so there's something 
> to depend on) and gets proposed patches from zuul when new content is 
> landed in openstack/vendor-profile-data.
>
> How's that sound?

I understand the benefit of separating the data files from the SDK, but
what is the benefit of separating the data files from the code that
reads them?

Doug

>
> Thanks!
> Monty
>
> [0] 
> http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/config/vendors
> [1] 
> https://docs.openstack.org/openstacksdk/latest/user/config/vendor-support.html
> [2] http://git.openstack.org/cgit/openstack/service-types-authority
> [3] http://git.openstack.org/cgit/openstack/os-service-types
>
> __
> OpenStack Development Mailing 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] [ptl][release] Proposed changes for cycle-with-milestones deliverables

2018-10-12 Thread Doug Hellmann
Sean McGinnis  writes:

> During the Stein PTG in Denver, the release management team talked about ways
> we can make things simpler and reduce the "paper pushing" work that all teams
> need to do right now. One topic that came up was the usefulness of pushing 
> tags
> around milestones during the cycle.
>
> There were a couple of needs identified for doing such "milestone releases":
> 1) It tests the release automation machinery to identify problems before
>the RC and final release crunch time.
> 2) It creates a nice cadence throughout the cycle to help teams stay on
>track and focus on the right things for each phase of the cycle.
> 3) It gives us an indication that teams are healthy, active, and planning
>to include their components in the final release.
>
> One of the big motivators in the past was also to have output that downstream
> distros and users could pick up for testing and early packaging. Based on our
> admittedly anecdotal small sample, it doesn't appear this is actually a big
> need, so we propose to stop tagging milestone releases for the
> cycle-with-milestone projects.

One of the issues that was raised from downstream consumers [1] is that
this complicates upgrade testing using packages, since tools like yum
will think that the stable branch (with a final version tag) has a
higher version number than master (with a dev version computed off of
the first release candidate where the stable branch was created).

We've discussed this problem in the past and not done anything because
the downstream folks were always able to live with the gap until the
first milestone. Now that we're unlikely to have milestone tags for most
projects, the gap will extend to the length of the cycle, blocking
upgrade testing until the release candidates are tagged, shortly before
we're ready to release. They could guess at the next version numbers,
but if they guess wrong they would be left with invalid packages and
have to do a bunch of testing work again. It's better for us to provide
authoritative information about version changes upstream.

We need all projects to increment their version at least by one minor
version at the start of each cycle to save space for patch releases on
the stable branch, so we looked at a few options for triggering that
update automatically.

One option is to add a tag, like an alpha. This is somewhat appealing
because the release team can just do it without anyone on the project
teams having to worry about it. However, I don't particularly like this
option for two reasons. First, the release team would have to monitor
the work in each project and wait for some patch to land after the fork,
so we could tag that (otherwise the branch would get the new version,
too). More importantly, the tag would trigger a release, and I don't
think we want to publish artifacts just to tweak the version
calculation.

A similarly low impact solution is to use pbr's Sem-Ver calculation
feature and inject patches into master to bump the version being
computed by 1 feature level (which should move from x.y.z.0rc1 to
somethinglike x.y+1.0.devN). See [2] for details about how this works.

This is the approach I prefer, and I have a patch to the branching
scripts to add the Sem-Ver instruction to the patches we already
generate to update reno [3].

That change should take care of our transition from Stein->T, but we're
left with versions in Stein that are lower than Rocky right now. So, as
a one time operation, Sean is going to propose empty patches with the
Sem-Ver instruction in the commit message to all of the repositories for
Stein deliverables that have stable/rocky branches.

Let us know if you have any questions.

Doug


[1] 
http://lists.openstack.org/pipermail/openstack-operators/2018-October/015991.html
[2] https://docs.openstack.org/pbr/latest/user/features.html#version 
[3] https://review.openstack.org/#/c/609827/

__
OpenStack Development Mailing 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] [goals][python3] week 9 update

2018-10-12 Thread Doug Hellmann

This is week 9 of the "Run under Python 3 by default" goal
(https://governance.openstack.org/tc/goals/stein/python3-first.html).

== What we learned last week ==

We have claimed a few names on PyPI, and updated a few sdist names where
we couldn't do that. The one remaining project with a rename is heat,
and I'm working on an upgrade script that will clean up the old metadata
to fix the duplicate plugin issue.

* https://review.openstack.org/#/c/606160/

== Ongoing and Completed Work ==

The zuul migration portion of the goal work is completed! Thanks again
to everyone who assisted with creating and reviewing those patches.

We still have quite a few patches with tox settings and for
documentation build updates left open or unreviewed. Those documentation
updates should be relatively quick to review because they're very
minimal patches. Please take a few minutes to look for them and let's
try to get them merged before the first milestone. The tox patches may
require a bit more work to update pylint and the goal champions could
use your help there (see below).

+-+--+-+--+-++---++
| Team| tox defaults | Docs| 3.6 unit | Failing | 
Unreviewed | Total | Champion   |
+-+--+-+--+-++---++
| adjutant|   1/  1  | -   | +|   0 |  
1 | 2 | Doug Hellmann  |
| barbican| +|   1/  3 | +|   1 |  
1 | 7 | Doug Hellmann  |
| blazar  | +| +   | +|   0 |  
0 | 9 | Nguyen Hai |
| Chef OpenStack  | +| -   | -|   0 |  
0 | 2 | Doug Hellmann  |
| cinder  | +| +   | +|   0 |  
0 |11 | Doug Hellmann  |
| cloudkitty  | +| +   | +|   0 |  
0 | 9 | Doug Hellmann  |
| congress|   1/  3  | +   | +|   0 |  
0 | 9 | Nguyen Hai |
| cyborg  | +| +   | +|   0 |  
0 | 7 | Nguyen Hai |
| designate   |   2/  4  | +   | +|   0 |  
1 | 9 | Nguyen Hai |
| Documentation   | +| +   | +|   0 |  
0 |10 | Doug Hellmann  |
| dragonflow  | -| +   | +|   0 |  
0 | 2 | Nguyen Hai |
| ec2-api |   2/  2  | +   | +|   2 |  
2 | 7 ||
| freezer |   1/  5  | +   | +|   0 |  
1 |11 ||
| glance  |   1/  4  | +   | +|   0 |  
0 |10 | Nguyen Hai |
| heat|   3/  8  | +   |   1/  7  |   0 |  
0 |21 | Doug Hellmann  |
| horizon |   1/ 32  | +   | +|   0 |  
1 |34 | Nguyen Hai |
| I18n|   1/  1  | -   | -|   0 |  
0 | 1 | Doug Hellmann  |
| InteropWG   |   3/  4  | +   |   1/  3  |   1 |  
3 |10 | Doug Hellmann  |
| ironic  |   1/ 10  | +   | +|   0 |  
1 |35 | Doug Hellmann  |
| karbor  | +| +   | +|   0 |  
0 | 7 | Nguyen Hai |
| keystone| +| +   | +|   0 |  
0 |18 | Doug Hellmann  |
| kolla   | +| +   | +|   0 |  
0 | 5 ||
| kuryr   | +| +   | +|   0 |  
0 | 9 | Doug Hellmann  |
| magnum  |   2/  5  | +   | +|   0 |  
1 |10 ||
| manila  |   1/  8  | +   | +|   0 |  
0 |13 | Goutham Pacha Ravi |
| masakari|   3/  5  | +   | -|   0 |  
3 | 6 | Nguyen Hai |
| mistral | +| +   | +|   0 |  
0 |13 | Nguyen Hai |
| monasca |   1/ 17  | +   | +|   1 |  
1 |34 | Doug Hellmann  |
| murano  | +| +   | +|   0 |  
0 |14 ||
| neutron |   8/ 18  |   2/ 14 |   2/ 13  |   5 |  
4 |45 | Doug Hellmann  |
| nova| +| +   | +|   0 |  
0 |14 ||
| octavia | +

Re: [openstack-dev] [tc] assigning new liaisons to projects

2018-10-12 Thread Doug Hellmann
Trinh Nguyen  writes:

> Thank Doug for coordinating this,
>
> Is there any way for us to update the health of the Searchlight project to
> reflect the current state? Right now the status is not good to attract new
> contributors.

When the new liaisons are assigned, please talk to them about the
current status.

Doug

>
> Bests,
>
> On Fri, Oct 12, 2018 at 6:50 AM Doug Hellmann  wrote:
>
>> Doug Hellmann  writes:
>>
>> > TC members,
>> >
>> > Since we are starting a new term, and have several new members, we need
>> > to decide how we want to rotate the liaisons attached to each our
>> > project teams, SIGs, and working groups [1].
>> >
>> > Last term we went through a period of volunteer sign-up and then I
>> > randomly assigned folks to slots to fill out the roster evenly. During
>> > the retrospective we talked a bit about how to ensure we had an
>> > objective perspective for each team by not having PTLs sign up for their
>> > own teams, but I don't think we settled on that as a hard rule.
>> >
>> > I think the easiest and fairest (to new members) way to manage the list
>> > will be to wipe it and follow the same process we did last time. If you
>> > agree, I will update the page this week and we can start collecting
>> > volunteers over the next week or so.
>> >
>> > Doug
>> >
>> > [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> I have cleared out the old assignments. Please go over and edit the wiki
>> page to add yourself to the teams you want to volunteer for. Remember
>> that each member needs to sign up for exactly 10 teams. If you don't
>> volunteer for 10, we'll use the script to make random assignments for
>> the remaining slots.
>>
>> Doug
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> -- 
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [tc] assigning new liaisons to projects

2018-10-11 Thread Doug Hellmann
Doug Hellmann  writes:

> TC members,
>
> Since we are starting a new term, and have several new members, we need
> to decide how we want to rotate the liaisons attached to each our
> project teams, SIGs, and working groups [1].
>
> Last term we went through a period of volunteer sign-up and then I
> randomly assigned folks to slots to fill out the roster evenly. During
> the retrospective we talked a bit about how to ensure we had an
> objective perspective for each team by not having PTLs sign up for their
> own teams, but I don't think we settled on that as a hard rule.
>
> I think the easiest and fairest (to new members) way to manage the list
> will be to wipe it and follow the same process we did last time. If you
> agree, I will update the page this week and we can start collecting
> volunteers over the next week or so.
>
> Doug
>
> [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I have cleared out the old assignments. Please go over and edit the wiki
page to add yourself to the teams you want to volunteer for. Remember
that each member needs to sign up for exactly 10 teams. If you don't
volunteer for 10, we'll use the script to make random assignments for
the remaining slots.

Doug

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


Re: [openstack-dev] [goals][python3][telemetry][barbican][monasca][neutron] having a gerrit admin approve the remaining zuul job settings import patches

2018-10-11 Thread Doug Hellmann
Doug Hellmann  writes:

> We have about 17 remaining patches to import zuul job settings into a
> few repositories. Those are mostly in stable branches and the jobs are
> failing in ways that may take us a long time to fix.
>
> Rather than waiting for those, Andreas and I are proposing that we have
> someone from the infra team approve them, bypassing the test jobs. That
> will allow us to complete the cleanup work in the project-config
> repository, and will not leave the affected repositories in a state that
> is any more (or less) broken than they are today.
>
> If you have any objections to the plan, please speak up quickly. I
> would like to try to proceed before the end of the week.
>
> Doug
>
> +--+-+---++--+-+---+---+
> | Subject  | Repo 
>| Team  | Tests  | Workflow | URL | 
> Branch| Owner |
> +--+-+---++--+-+---+---+
> | import zuul job settings from project-config | openstack/aodh   
>| Telemetry | FAILED | NEW      | https://review.openstack.org/598648 | 
> stable/ocata  | Doug Hellmann |
> | import zuul job settings from project-config | openstack/barbican   
>| barbican  | FAILED | REVIEWED | https://review.openstack.org/599659 | 
> stable/queens | Doug Hellmann |
> | import zuul job settings from project-config | openstack/barbican   
>| barbican  | FAILED | REVIEWED | https://review.openstack.org/599661 | 
> stable/rocky  | Doug Hellmann |
> | import zuul job settings from project-config | openstack/castellan-ui   
>    | barbican  | FAILED | NEW  | https://review.openstack.org/599649 | 
> master| Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/ceilometermiddleware  | Telemetry | FAILED | APPROVED | 
> https://review.openstack.org/598634 | master| Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/ceilometermiddleware  | Telemetry | FAILED | APPROVED | 
> https://review.openstack.org/598655 | stable/pike   | Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/ceilometermiddleware  | Telemetry | PASS   | NEW  | 
> https://review.openstack.org/598661 | stable/queens | Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/ceilometermiddleware  | Telemetry | FAILED | NEW  | 
> https://review.openstack.org/598667 | stable/rocky  | Doug Hellmann |
> | import zuul job settings from project-config | openstack/monasca-analytics  
>| monasca   | FAILED | REVIEWED | https://review.openstack.org/595658 | 
> master| Doug Hellmann |
> | import zuul job settings from project-config | openstack/networking-midonet 
>| neutron   | PASS   | REVIEWED | https://review.openstack.org/597937 | 
> stable/queens | Doug Hellmann |
> | import zuul job settings from project-config | openstack/networking-sfc 
>| neutron   | FAILED | NEW  | https://review.openstack.org/597913 | 
> stable/ocata  | Doug Hellmann |
> | import zuul job settings from project-config | openstack/networking-sfc 
>| neutron   | FAILED | NEW  | https://review.openstack.org/597925 | 
> stable/pike   | Doug Hellmann |
> | import zuul job settings from project-config | openstack/python-aodhclient  
>| Telemetry | FAILED | NEW  | https://review.openstack.org/598652 | 
> stable/ocata  | Doug Hellmann |
> | import zuul job settings from project-config | openstack/python-aodhclient  
>| Telemetry | FAILED | NEW  | https://review.openstack.org/598657 | 
> stable/pike   | Doug Hellmann |
> | import zuul job settings from project-config | openstack/python-aodhclient  
>| Telemetry | FAILED | APPROVED | https://review.openstack.org/598669 | 
> stable/rocky  | Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/python-barbicanclient | barbican  | FAILED | NEW  | 
> https://review.openstack.org/599656 | stable/ocata  | Doug Hellmann |
> | import zuul job settings from project-config | 
> openstack/python-barbicanclient | barbican  | FAILED | NEW  | 
> https://review.openstack.org/599658 | stable/pike   | Doug Hellmann |
> +--+-+---++--+-+---+---+

Clark went ahead and merged 

Re: [openstack-dev] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0

2018-10-09 Thread Doug Hellmann
Ken Giusti  writes:

> On Tue, Oct 9, 2018 at 11:56 AM Doug Hellmann  wrote:
>
>> Matthew Thode  writes:
>>
>> > On 18-10-09 11:12:30, Doug Hellmann wrote:
>> >> Matthew Thode  writes:
>> >>
>> >> > several projects have had problems with the new release, some have
>> ways
>> >> > of working around it, and some do not.  I'm sending this just to raise
>> >> > the issue and allow a place to discuss solutions.
>> >> >
>> >> > Currently there is a review proposed to blacklist 9.0.0, but if this
>> is
>> >> > going to still be an issue somehow in further releases we may need
>> >> > another solution.
>> >> >
>> >> > https://review.openstack.org/#/c/608835/
>> >> >
>> >> > --
>> >> > Matthew Thode (prometheanfire)
>> >> >
>> __
>> >> > OpenStack Development Mailing List (not for usage questions)
>> >> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >> Do you have links to the failure logs or bug reports or something? If I
>> >> wanted to help I wouldn't even know where to start.
>> >>
>> >
>> >
>> http://logs.openstack.org/21/607521/2/check/cross-cinder-py35/e15722e/testr_results.html.gz
>>
>> These failures look like we should add a proper API to oslo.messaging to
>> set the notification and rpc backends for testing. The configuration
>> options are *not* part of the API of the library.
>>
>> There is already an oslo_messaging.conffixture module with a fixture
>> class, but it looks like it defaults to rabbit. Maybe someone wants to
>> propose a patch to make that a parameter to the constructor?
>>
>
> oslo.messaging's conffixture uses whatever the config default for
> transport_url is unless the test
> specifically overrides it by setting the transport_url attribute.
> The o.m. unit tests's base test class sets conffixture.transport_url to
> "fake:/" to use the fake in memory driver.
> That's the existing practice (I believe it's used like that outside of o.m.)

OK, so it sounds like the fixture is relying on the configuration to be
set up in advance, and that's the thing we need to change. We don't want
users outside of the library to set up tests by using the configuration
options, right?

Doug

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


Re: [openstack-dev] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0

2018-10-09 Thread Doug Hellmann
Matthew Thode  writes:

> On 18-10-09 11:12:30, Doug Hellmann wrote:
>> Matthew Thode  writes:
>> 
>> > several projects have had problems with the new release, some have ways
>> > of working around it, and some do not.  I'm sending this just to raise
>> > the issue and allow a place to discuss solutions.
>> >
>> > Currently there is a review proposed to blacklist 9.0.0, but if this is
>> > going to still be an issue somehow in further releases we may need
>> > another solution.
>> >
>> > https://review.openstack.org/#/c/608835/
>> >
>> > -- 
>> > Matthew Thode (prometheanfire)
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> Do you have links to the failure logs or bug reports or something? If I
>> wanted to help I wouldn't even know where to start.
>> 
>
> http://logs.openstack.org/21/607521/2/check/cross-cinder-py35/e15722e/testr_results.html.gz

These failures look like we should add a proper API to oslo.messaging to
set the notification and rpc backends for testing. The configuration
options are *not* part of the API of the library.

There is already an oslo_messaging.conffixture module with a fixture
class, but it looks like it defaults to rabbit. Maybe someone wants to
propose a patch to make that a parameter to the constructor?

> http://logs.openstack.org/21/607521/2/check/cross-glance-py35/e2161d7/testr_results.html.gz

These failures should be fixed by releasing the patch that Mehdi
provided that ensures there is a valid default transport configured.

> http://logs.openstack.org/21/607521/2/check/cross-keystone-py35/908a1c2/testr_results.html.gz

Lance has already described these as mocking implementation details of
the library. I expect we'll need someone with keystone experience to
work out what the best solution is to do there.

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

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


Re: [openstack-dev] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0

2018-10-09 Thread Doug Hellmann
Ben Nemec  writes:

> On 10/9/18 10:19 AM, Doug Hellmann wrote:
>> Brian Rosmaita  writes:
>> 
>>> On 10/8/18 11:59 PM, Matthew Thode wrote:
>>>> several projects have had problems with the new release, some have ways
>>>> of working around it, and some do not.  I'm sending this just to raise
>>>> the issue and allow a place to discuss solutions.
>>>>
>>>> Currently there is a review proposed to blacklist 9.0.0, but if this is
>>>> going to still be an issue somehow in further releases we may need
>>>> another solution.
>>>>
>>>> https://review.openstack.org/#/c/608835/
>>>
>>> As indicated in the commit message on the above patch, 9.0.0 contains a
>>> bug that's been fixed in oslo.messaging master, so I don't think there's
>>> any question that 9.0.0 has to be blacklisted.
>> 
>> I've proposed releasing oslo.messaging 9.0.1 in
>> https://review.openstack.org/609030
>
> I also included it in https://review.openstack.org/#/c/609031/ (which I 
> see you found).

Yeah, I abandoned my separate patch to do the same in favor of your
omnibus patch.

>> If we don't land the constraint update to allow 9.0.1 in, then there's
>> no rush to blacklist anything, is there?
>
> Probably not. We'll want to blacklist it before we allow 9.0.1, but I 
> suspect this is mostly a test problem since in production the transport 
> would have to be set explicitly.
>
>> 
>>> As far as the timing/content of 9.0.1, however, that may require further
>>> discussion.
>>>
>>> (In other words, I'm saying that when you say 'another solution', my
>>> position is that we should take 'another' to mean 'additional', not
>>> 'different'.)
>> 
>> I'm not sure what that means.
>> 
>> Doug
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 

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


Re: [openstack-dev] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0

2018-10-09 Thread Doug Hellmann
Lance Bragstad  writes:

> Keystone is failing because it's missing a fix from oslo.messaging [0].
> That said, keystone is also relying on an internal implementation detail in
> oslo.messaging by mocking it in tests [1]. The notification work has been
> around in keystone for a *long* time, but it's apparent that we should
> revisit these tests to make sure we aren't testing something that is
> already tested by oslo.messaging if we're mocking internal implementation
> details of a library.
>
> Regardless, blacklisting version 9.0.0 will work for keystone, but we can
> work around it another way by either rewriting the tests to not care about
> oslo.messaging specifics, or removing them if they're obsolete.

Yeah, we keep running into these sorts of problems when folks mock past
the public API boundary of a library, so let's eliminate them as we find
them.

If there's a way to add a fixture to oslo.messaging to support the tests
we can do that, too.

Doug

>
> [0] https://review.openstack.org/#/c/608196/
> [1]
> https://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/common/test_notifications.py#n1343
>
> On Mon, Oct 8, 2018 at 10:59 PM Matthew Thode 
> wrote:
>
>> several projects have had problems with the new release, some have ways
>> of working around it, and some do not.  I'm sending this just to raise
>> the issue and allow a place to discuss solutions.
>>
>> Currently there is a review proposed to blacklist 9.0.0, but if this is
>> going to still be an issue somehow in further releases we may need
>> another solution.
>>
>> https://review.openstack.org/#/c/608835/
>>
>> --
>> Matthew Thode (prometheanfire)
>> __
>> OpenStack Development Mailing 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] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0

2018-10-09 Thread Doug Hellmann
Brian Rosmaita  writes:

> On 10/8/18 11:59 PM, Matthew Thode wrote:
>> several projects have had problems with the new release, some have ways
>> of working around it, and some do not.  I'm sending this just to raise
>> the issue and allow a place to discuss solutions.
>> 
>> Currently there is a review proposed to blacklist 9.0.0, but if this is
>> going to still be an issue somehow in further releases we may need
>> another solution.
>> 
>> https://review.openstack.org/#/c/608835/
>
> As indicated in the commit message on the above patch, 9.0.0 contains a
> bug that's been fixed in oslo.messaging master, so I don't think there's
> any question that 9.0.0 has to be blacklisted.

I've proposed releasing oslo.messaging 9.0.1 in
https://review.openstack.org/609030

If we don't land the constraint update to allow 9.0.1 in, then there's
no rush to blacklist anything, is there?

> As far as the timing/content of 9.0.1, however, that may require further
> discussion.
>
> (In other words, I'm saying that when you say 'another solution', my
> position is that we should take 'another' to mean 'additional', not
> 'different'.)

I'm not sure what that means.

Doug

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


Re: [openstack-dev] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0

2018-10-09 Thread Doug Hellmann
Matthew Thode  writes:

> several projects have had problems with the new release, some have ways
> of working around it, and some do not.  I'm sending this just to raise
> the issue and allow a place to discuss solutions.
>
> Currently there is a review proposed to blacklist 9.0.0, but if this is
> going to still be an issue somehow in further releases we may need
> another solution.
>
> https://review.openstack.org/#/c/608835/
>
> -- 
> Matthew Thode (prometheanfire)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Do you have links to the failure logs or bug reports or something? If I
wanted to help I wouldn't even know where to start.

Doug

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


Re: [openstack-dev] [all] Stepping down from Release Management team

2018-10-08 Thread Doug Hellmann
Anne Bertucio  writes:

> Hi all,
>
> I have had a fantastic time getting to work on the Release Management
> team and getting to know you all through the release marketing work,
> however, it is time for me to step down from my role on the Release
> Management team as I am moving on from my role at the Foundation and
> will no longer be working on upstream OpenStack. I cannot thank you
> all enough for how you all welcomed me into the OpenStack community
> and for how much I have learned about open source development in my
> time here.
>
> If you have questions about cycle-highlights, swing by #openstack-release. 
> If you have questions about release marketing, contact lau...@openstack.org.
> For other inquiries, contact alli...@openstack.org. 
> While I won't be working upstream anymore, I'll only be a Tweet or IRC 
> message away. 
>
> Thank you again, and remember that cycle-highlights should be
> submitted by RC1.

Thank you for everything, Anne! The cycle-highlights system you helped
us create is a great example of using decentralization and peer review
at the same time. I'm sure it's going to continue to be an important
communication tool for the community.

Doug

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


Re: [openstack-dev] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs

2018-10-08 Thread Doug Hellmann
Doug Hellmann  writes:

> Doug Hellmann  writes:
>
>> Doug Hellmann  writes:
>>
>>> Doug Hellmann  writes:
>>
>>> I have filed requests with the maintainers of PyPI to claim the names
>>> "keystone" and "congress". That may take some time. Please let me know
>>> if you're willing to simply use "openstack-keystone" and
>>> "openstack-congress" instead. I will take care of configuring PyPI and
>>> proposing the patch to update your setup.cfg (that way you can approve
>>> the change).
>>>
>>> * https://github.com/pypa/warehouse/issues/4770
>>> * https://github.com/pypa/warehouse/issues/4771
>
> We haven't heard back about either of these requests, so I filed changes
> with congress and keystone to change the dist names.
>
> * https://review.openstack.org/608332 (congress)
> * https://review.openstack.org/608331 (keystone)
>
> Doug

Dan Crosta has very graciously given us the name "keystone" so I
abandoned that patch, made openstackci an owner, and uploaded the
previous release.

The patch to rename congress is approved, but sitting on top of one or
two other patches that also need reviews.

The patch to rename heat is failing the grenade tests, and we could use
some help with fixing the problem. I think we need an upgrade script
that removes the old package before installing the new one. Does someone
want to learn how grenade scripts work?

Doug

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


Re: [openstack-dev] [all] Zuul job backlog

2018-10-08 Thread Doug Hellmann
Abhishek Kekane  writes:

> Hi Doug,
>
> Should I use something like SimpleHttpServer to upload a file and download
> the same, or there are other efficient ways to handle it,
> Kindly let me know if you are having any suggestions for the same.

Sure, that would work, especially if your tests are running in the unit
test jobs. If you're running a functional test, it seems like it would
also be OK to just copy a file into the directory Apache is serving from
and then download it from there.

Doug

>
> Thanks & Best Regards,
>
> Abhishek Kekane
>
>
> On Fri, Oct 5, 2018 at 4:57 PM Doug Hellmann  wrote:
>
>> Abhishek Kekane  writes:
>>
>> > Hi Matt,
>> >
>> > Thanks for the input, I guess I should use '
>> > http://git.openstack.org/static/openstack.png' which will definitely
>> work.
>> > Clark, Matt, Kindly let me know your opinion about the same.
>>
>> That URL would not be on the local node running the test, and would
>> eventually exhibit the same problems. In fact we have seen issues
>> cloning git repositories as part of the tests in the past.
>>
>> You need to use a localhost URL to ensure that the download doesn't have
>> to go off of the node. That may mean placing something into the directory
>> where Apache is serving files as part of the test setup.
>>
>> Doug
>>

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


[openstack-dev] [goals][python3][telemetry][barbican][monasca][neutron] having a gerrit admin approve the remaining zuul job settings import patches

2018-10-08 Thread Doug Hellmann
We have about 17 remaining patches to import zuul job settings into a
few repositories. Those are mostly in stable branches and the jobs are
failing in ways that may take us a long time to fix.

Rather than waiting for those, Andreas and I are proposing that we have
someone from the infra team approve them, bypassing the test jobs. That
will allow us to complete the cleanup work in the project-config
repository, and will not leave the affected repositories in a state that
is any more (or less) broken than they are today.

If you have any objections to the plan, please speak up quickly. I
would like to try to proceed before the end of the week.

Doug

+--+-+---++--+-+---+---+
| Subject  | Repo   
 | Team  | Tests  | Workflow | URL | Branch 
   | Owner |
+--+-+---++--+-+---+---+
| import zuul job settings from project-config | openstack/aodh 
 | Telemetry | FAILED | NEW  | https://review.openstack.org/598648 | 
stable/ocata  | Doug Hellmann |
| import zuul job settings from project-config | openstack/barbican 
 | barbican  | FAILED | REVIEWED | https://review.openstack.org/599659 | 
stable/queens | Doug Hellmann |
| import zuul job settings from project-config | openstack/barbican 
 | barbican  | FAILED | REVIEWED | https://review.openstack.org/599661 | 
stable/rocky  | Doug Hellmann |
| import zuul job settings from project-config | openstack/castellan-ui 
 | barbican  | FAILED | NEW  | https://review.openstack.org/599649 | master 
   | Doug Hellmann |
| import zuul job settings from project-config | openstack/ceilometermiddleware 
 | Telemetry | FAILED | APPROVED | https://review.openstack.org/598634 | master 
   | Doug Hellmann |
| import zuul job settings from project-config | openstack/ceilometermiddleware 
 | Telemetry | FAILED | APPROVED | https://review.openstack.org/598655 | 
stable/pike   | Doug Hellmann |
| import zuul job settings from project-config | openstack/ceilometermiddleware 
 | Telemetry | PASS   | NEW  | https://review.openstack.org/598661 | 
stable/queens | Doug Hellmann |
| import zuul job settings from project-config | openstack/ceilometermiddleware 
 | Telemetry | FAILED | NEW  | https://review.openstack.org/598667 | 
stable/rocky  | Doug Hellmann |
| import zuul job settings from project-config | openstack/monasca-analytics
 | monasca   | FAILED | REVIEWED | https://review.openstack.org/595658 | master 
   | Doug Hellmann |
| import zuul job settings from project-config | openstack/networking-midonet   
 | neutron   | PASS   | REVIEWED | https://review.openstack.org/597937 | 
stable/queens | Doug Hellmann |
| import zuul job settings from project-config | openstack/networking-sfc   
 | neutron   | FAILED | NEW  | https://review.openstack.org/597913 | 
stable/ocata  | Doug Hellmann |
| import zuul job settings from project-config | openstack/networking-sfc   
 | neutron   | FAILED | NEW  | https://review.openstack.org/597925 | 
stable/pike   | Doug Hellmann |
| import zuul job settings from project-config | openstack/python-aodhclient
 | Telemetry | FAILED | NEW  | https://review.openstack.org/598652 | 
stable/ocata  | Doug Hellmann |
| import zuul job settings from project-config | openstack/python-aodhclient
 | Telemetry | FAILED | NEW  | https://review.openstack.org/598657 | 
stable/pike   | Doug Hellmann |
| import zuul job settings from project-config | openstack/python-aodhclient
 | Telemetry | FAILED | APPROVED | https://review.openstack.org/598669 | 
stable/rocky  | Doug Hellmann |
| import zuul job settings from project-config | 
openstack/python-barbicanclient | barbican  | FAILED | NEW  | 
https://review.openstack.org/599656 | stable/ocata  | Doug Hellmann |
| import zuul job settings from project-config | 
openstack/python-barbicanclient | barbican  | FAILED | NEW  | 
https://review.openstack.org/599658 | stable/pike   | Doug Hellmann |
+--+-+---++--+-+---+---+

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


[openstack-dev] [tc] Technical Committee status update for 8 October 2018

2018-10-08 Thread Doug Hellmann
This is the weekly summary of work being done by the Technical Committee
members. The full list of active items is managed in the wiki:
https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Since the last update email, we have held another TC election in which 3
returning and 3 new members have been elected. Welcome again to our new
and returning members, and thank you to the former members for their
service!

* http://lists.openstack.org/pipermail/openstack-dev/2018-September/135187.html

If you missed it, I sent the summary of TC discussions at the PTG a
while back.

* http://lists.openstack.org/pipermail/openstack-dev/2018-September/134744.html

Between being busy with the PTG and then the TC elections, I did not
send a status update during September, so there are quite a few project
updates to report.

Project updates:

* Add os-ken to neutron: https://review.openstack.org/#/c/588358/
* Add cookbook-openstack-bare-metal to Chef:
* https://review.openstack.org/#/c/596746/
* Add mistral-extra to Mistral: https://review.openstack.org/#/c/597551/
* Add placement deliverable to Nova:
* https://review.openstack.org/#/c/598380/
* Add metalsmith to Ironic: https://review.openstack.org/#/c/602075/
* Add oslo.upgradecheck to Oslo:
* https://review.openstack.org/#/c/602483/
* Add puppet-placement to Puppet:
* https://review.openstack.org/#/c/602870/
* Add ansible-role-chrony to TripleO:
* https://review.openstack.org/#/c/603516/
* Add octavia-lib to Octavia: https://review.openstack.org/#/c/604890/
* Add neutron-interconnection to neutron:
* https://review.openstack.org/#/c/599428/

Retired repositories:

* Retire the development-proposals repository:
  https://review.openstack.org/#/c/600649/
* Retire fuxi: https://review.openstack.org/#/c/604527/
* Retire charm-ceph: https://review.openstack.org/#/c/604530/

Community Updates:

* Add Jay Faulkner as ATC for Ironic:
  https://review.openstack.org/#/c/597212/
* Begin the T deveiopment cycle naming process:
  https://review.openstack.org/#/c/600354/
* The Operations Guide team adopted the HA Guide:
  https://review.openstack.org/#/c/601321/
* The Interop Working Group adopted the refstack tools:
  https://review.openstack.org/#/c/590179/

== TC Meetings ==

In order to fulfill our obligations under the OpenStack Foundation
bylaws, the TC needs to hold meetings at least once each quarter. We
have decided to schedule monthly meetings on IRC, and retain the
existing office hours times for less formal discussions. See the thread
for details.

* http://lists.openstack.org/pipermail/openstack-dev/2018-October/135521.html

== Ongoing Discussions ==

Tony Breeds is coordinating the poll for names for the T development
cycle and release series.

* http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html

== TC member actions/focus/discussions for the coming week(s) ==

We need to decide how we are going to handle updating the list of
liaisons to projects this cycle. Please follow up on that thread.

* http://lists.openstack.org/pipermail/openstack-dev/2018-October/135523.html

Add the monthly meeting to your calendar.

* http://lists.openstack.org/pipermail/openstack-dev/2018-October/135521.html

The next Foundation board meeting will be held via webex on 25
October. See the wiki for details.

* https://wiki.openstack.org/wiki/Governance/Foundation/25Oct2018BoardMeeting

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

- 09:00 UTC on Tuesdays
- 01:00 UTC on Wednesdays
- 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

You will find channel logs with past conversations at
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.

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

[openstack-dev] [tc] assigning new liaisons to projects

2018-10-08 Thread Doug Hellmann
TC members,

Since we are starting a new term, and have several new members, we need
to decide how we want to rotate the liaisons attached to each our
project teams, SIGs, and working groups [1].

Last term we went through a period of volunteer sign-up and then I
randomly assigned folks to slots to fill out the roster evenly. During
the retrospective we talked a bit about how to ensure we had an
objective perspective for each team by not having PTLs sign up for their
own teams, but I don't think we settled on that as a hard rule.

I think the easiest and fairest (to new members) way to manage the list
will be to wipe it and follow the same process we did last time. If you
agree, I will update the page this week and we can start collecting
volunteers over the next week or so.

Doug

[1] https://wiki.openstack.org/wiki/OpenStack_health_tracker

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


[openstack-dev] [tc] planned absence

2018-10-08 Thread Doug Hellmann
TC members,

I have some PTO planned, so I will be away from 13 Oct - 28 Oct. I
approved the patch appointing Mohammed as vice chair this morning, so he
will be serving as chair during that time.

Doug

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


Re: [openstack-dev] [tc] bringing back formal TC meetings

2018-10-08 Thread Doug Hellmann
Based on the conversation in the other branch of this thread, I have
filed [1] to start monthly meetings on November 1 at 1400 UTC. It may
take a while before that actually shows up on the calendar, because it
required adding a feature to yaml2ical [2].

We talked about using email to add items to the agenda, but I realized
that's going to complicate the coordination between chair and vice
chair, so I would like for us to use the wiki [2] to suggest agenda
items. We will still rely on email to the openstack-dev or
openstack-discuss list to set the formal agenda before the actual
meeting. Let me know if you foresee any issues with that plan.

Doug

[1] https://review.openstack.org/608682
[2] https://review.openstack.org/608680
[3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

__
OpenStack Development Mailing 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] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs

2018-10-05 Thread Doug Hellmann
Doug Hellmann  writes:

> Doug Hellmann  writes:
>
>> Doug Hellmann  writes:
>>
>>> I think we are ready to go ahead and switch all of the python packaging
>>> jobs to the new set defined in the publish-to-pypi-python3 template
>>> [1]. We still have some cleanup patches for projects that have not
>>> completed their zuul migration, but there are only a few and rebasing
>>> those will be easy enough.
>>>
>>> The template adds a new check job that runs when any files related to
>>> packaging are changed (readme, setup, etc.). Otherwise it switches from
>>> the python2-based PyPI job to use python3.
>>>
>>> I have the patch to switch all official projects ready in [2].
>>>
>>> Doug
>>>
>>> [1] 
>>> http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/project-templates.yaml#n218
>>> [2] https://review.openstack.org/#/c/598323/
>>
>> This change is now in place. The Ironic team discovered one issue, and
>> the fix is proposed as https://review.openstack.org/606152
>>
>> This change has also reopened the question of how to publish some of the
>> projects for which we do not own names on PyPI.
>>
>> I registered manila, qinling, and zaqar-ui by uploading Rocky series
>> releases of those projects and then added openstackci as an owner so we
>> can upload new packages this cycle.
>>
>> I asked the owners of the name "heat" to allow us to use it, and they
>> rejected the request. So, I proposed a change to heat to update the
>> sdist name to "openstack-heat".
>>
>> * https://review.openstack.org/606160
>>
>> We don't own "magnum" but there is already an "openstack-magnum" set up
>> with old releases, so I have proposed a change to the magnum repo to
>> change the dist name there, so we can resume using it.
>>
>> * https://review.openstack.org/606162
>
> The owner of the name "magnum" has given us access, so I have set it up
> with permission for the CI system to publish and I have abandoned the
> rename patch.
>
>> I have filed requests with the maintainers of PyPI to claim the names
>> "keystone" and "congress". That may take some time. Please let me know
>> if you're willing to simply use "openstack-keystone" and
>> "openstack-congress" instead. I will take care of configuring PyPI and
>> proposing the patch to update your setup.cfg (that way you can approve
>> the change).
>>
>> * https://github.com/pypa/warehouse/issues/4770
>> * https://github.com/pypa/warehouse/issues/4771

We haven't heard back about either of these requests, so I filed changes
with congress and keystone to change the dist names.

* https://review.openstack.org/608332 (congress)
* https://review.openstack.org/608331 (keystone)

Doug

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


Re: [openstack-dev] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs

2018-10-05 Thread Doug Hellmann
Doug Hellmann  writes:

> Doug Hellmann  writes:
>
>> I think we are ready to go ahead and switch all of the python packaging
>> jobs to the new set defined in the publish-to-pypi-python3 template
>> [1]. We still have some cleanup patches for projects that have not
>> completed their zuul migration, but there are only a few and rebasing
>> those will be easy enough.
>>
>> The template adds a new check job that runs when any files related to
>> packaging are changed (readme, setup, etc.). Otherwise it switches from
>> the python2-based PyPI job to use python3.
>>
>> I have the patch to switch all official projects ready in [2].
>>
>> Doug
>>
>> [1] 
>> http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/project-templates.yaml#n218
>> [2] https://review.openstack.org/#/c/598323/
>
> This change is now in place. The Ironic team discovered one issue, and
> the fix is proposed as https://review.openstack.org/606152
>
> This change has also reopened the question of how to publish some of the
> projects for which we do not own names on PyPI.
>
> I registered manila, qinling, and zaqar-ui by uploading Rocky series
> releases of those projects and then added openstackci as an owner so we
> can upload new packages this cycle.
>
> I asked the owners of the name "heat" to allow us to use it, and they
> rejected the request. So, I proposed a change to heat to update the
> sdist name to "openstack-heat".
>
> * https://review.openstack.org/606160
>
> We don't own "magnum" but there is already an "openstack-magnum" set up
> with old releases, so I have proposed a change to the magnum repo to
> change the dist name there, so we can resume using it.
>
> * https://review.openstack.org/606162

The owner of the name "magnum" has given us access, so I have set it up
with permission for the CI system to publish and I have abandoned the
rename patch.

> I have filed requests with the maintainers of PyPI to claim the names
> "keystone" and "congress". That may take some time. Please let me know
> if you're willing to simply use "openstack-keystone" and
> "openstack-congress" instead. I will take care of configuring PyPI and
> proposing the patch to update your setup.cfg (that way you can approve
> the change).
>
> * https://github.com/pypa/warehouse/issues/4770
> * https://github.com/pypa/warehouse/issues/4771
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [Distutils] pip 18.1 has been released!

2018-10-05 Thread Doug Hellmann

Watch for changes in pip's behavior. - Doug

Pradyun Gedam  writes:

> On behalf of the PyPA, I am pleased to announce that pip 18.1 has just
> been released.
>
> To install pip 18.1, you can run::
>
>   python -m pip install --upgrade pip
>
> or use get-pip as described in
> https://pip.pypa.io/en/latest/installing. Note that
> if you are using a version of pip supplied by your distribution
> vendor, vendor-supplied
> upgrades will be available in due course.
>
> The highlights of this release are:
>
> - Python 3.7 is now supported
> - Dependency Links support is now scheduled for removal in pip 19.0
> (the next pip
>   release, scheduled in January 2019).
> - Plaform specific options can now be used with the --target option,
> to enable certain
>   workflows.
> - Much more helpful error messages on invalid configuration files
> - Many bug fixes and minor improvements
>
> Thanks to everyone who put so much effort into the new release. Many of the
> contributions came from community members, whether in the form of code,
> participation in design discussions and/or bug reports. The pip development
> team is extremely grateful to everyone in the community for their 
> contributions.
>
> Thanks,
> Pradyun
> --
> Distutils-SIG mailing list -- distutils-...@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/mm3/archives/list/distutils-...@python.org/message/YBYAYIXJ2WUUYCJLM7EWMQETJOW5W6ZZ/

__
OpenStack Development Mailing 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][searchlight] What should I do with the missing releases?

2018-10-05 Thread Doug Hellmann
Trinh Nguyen  writes:

> Dear release team,
>
> One thing comes up in my mind when preparing for the stein-1 release of
> Searchlight that is what should we do with the missing releases (i.e.
> Rocky)? Can I just ignore it or do I have to create a branch for it?

There was no rocky release, so I don't really see any reason to create
the branch. There isn't anything to maintain.

Doug

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


Re: [openstack-dev] [tc] bringing back formal TC meetings

2018-10-05 Thread Doug Hellmann
Chris Dent  writes:

> On Thu, 4 Oct 2018, Doug Hellmann wrote:
>
>> TC members, please reply to this thread and indicate if you would find
>> meeting at 1300 UTC on the first Thursday of every month acceptable, and
>> of course include any other comments you might have (including alternate
>> times).
>
> +1
>
> Also, if we're going to set aside a time for a semi-formal meeting, I
> hope we will have some form of agenda and minutes, with a fairly
> clear process for setting that agenda as well as a process for

I had in mind "email the chair your topic suggestion" and then "the
chair emails the agenda to openstack-dev tagged [tc] a bit in advance of
the meeting". There would also probably be some standing topics, like
updates for ongoing projects.

Does that work for everyone?

Doug

> making sure that the fast and/or rude typers do not dominate the
> discussion during the meetings, as they used to back in the day when
> there were weekly meetings.
>
> The "raising hands" thing that came along towards the end sort of
> worked, so a variant on that may be sufficient.
>
> -- 
> Chris Dent   ٩◔̯◔۶   https://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [tc] bringing back formal TC meetings

2018-10-05 Thread Doug Hellmann
Thierry Carrez  writes:

> Ghanshyam Mann wrote:
>>    On Fri, 05 Oct 2018 02:47:53 +0900 Jeremy Stanley  
>> wrote 
>>   > On 2018-10-04 13:40:05 -0400 (-0400), Doug Hellmann wrote:
>>   > [...]
>>   > > TC members, please reply to this thread and indicate if you would
>>   > > find meeting at 1300 UTC on the first Thursday of every month
>>   > > acceptable, and of course include any other comments you might
>>   > > have (including alternate times).
>>   >
>>   > This time is acceptable to me. As long as we ensure that community
>>   > feedback continues more frequently in IRC and on the ML (for example
>>   > by making it clear that this meeting is expressly *not* for that)
>>   > then I'm fine with resuming formal meetings.
>> 
>> +1. Time works fine for me, Thanks for considering the APAC TZ.
>> 
>> I agree that we should keep encouraging the  usual discussion in existing 
>> office hours, IRC or ML. I will be definitely able to attend other 2 office 
>> hours (Tuesday  and Wednesday) which are suitable for my TZ.
>
> 1300 UTC is obviously good for me, but once we are off DST that will 
> mean 5am for our Pacific Time people (do we have any left ?).
>
> Maybe 1400 UTC would be a better trade-off?

Julia is out west, but I think not all the way to PST.

> Regarding frequency, I agree with mnaser that once per month might be 
> too rare. That means only 5-ish meetings for a given a 6-month 
> membership. But that can work if we use the meeting as a formal progress 
> status checkpoint, rather than a way to discuss complex topics.

I think we can definitely manage the agenda to minimize the number of
complex discussions. If that proves to be too hard, I wouldn't mind
meeting more often, but there does seem to be a lot of support for
preferring other venues for those conversations.

Doug

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


Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

2018-10-05 Thread Doug Hellmann
Gilles Dubreuil  writes:

>> About the micro version, we discuss with your team mate dmitry in 
>> another email [1]
>
> Obviously micro version is a point of contention.
> My take on this is because consuming them has been proven harder than 
> developing them.
> The beauty of GraphQL is that there is no need to deal with version at all.
> New fields appears when needed and old one are marked deprecated.

How does someone using GraphQL to use a cloud know when a specific field
is available? How can they differentiate what is supported in one cloud
from what is supported in another, running a different version of the
same service?

Doug

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


Re: [openstack-dev] [all] Zuul job backlog

2018-10-05 Thread Doug Hellmann
Abhishek Kekane  writes:

> Hi Matt,
>
> Thanks for the input, I guess I should use '
> http://git.openstack.org/static/openstack.png' which will definitely work.
> Clark, Matt, Kindly let me know your opinion about the same.

That URL would not be on the local node running the test, and would
eventually exhibit the same problems. In fact we have seen issues
cloning git repositories as part of the tests in the past.

You need to use a localhost URL to ensure that the download doesn't have
to go off of the node. That may mean placing something into the directory
where Apache is serving files as part of the test setup.

Doug

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


Re: [openstack-dev] [all][Searchlight] Always build universal wheels

2018-10-05 Thread Doug Hellmann
Trinh Nguyen  writes:

> Thank Jeremy, Doug for explaining.
>
> On Fri, Oct 5, 2018 at 6:54 AM Doug Hellmann  wrote:
>
>> Jeremy Stanley  writes:
>>
>> > On 2018-10-04 23:11:22 +0900 (+0900), Trinh Nguyen wrote:
>> > [...]
>> >> Please avoid adding universal wheels to the project setup.cfg.
>> > [...]
>> >
>> > Why would you avoid also adding it to the setup.cfg? The change you
>> > cited is merely to be able to continue building universal wheels for
>> > projects while the setup.cfg files are corrected over time, to
>> > reduce the urgency of doing so. Wheel building happens in more
>> > places than just our CI system, so only fixing it in CI is not a
>> > good long-term strategy.
>>
>> I abandoned a couple of dozen patches submitted today by someone who was
>> not coordinating with the goal champions with a message that said those
>> patches were not needed because I didn't want folks to be dealing with
>> this right now.
>>
>> Teams who want to update their setup.cfg can do so, but my intent is to
>> ensure it is not required in order to produce releases with the
>> automation in the short term.

I thought about this some more last night, looking for reasons not to
update all of the setup.cfg files. If this zuul migration project has
shown anything, it's that we need to continue to be creative with
finding ways to avoid touching every branch of every repository when we
have build system changes to make. I support decentralizing the job
management, but I think this is a case where we can avoid doing a bunch
of work, and so we should.

We've been saying we want to update the setup.cfg files to include the
setting to cause a universal wheel to build because we want the local
developer experience when building wheels to be the same as what we get
from the CI system when we publish packages. I don't think that's a real
requirement, though.

The default behavior of bdist_wheel is to create a version-specific
wheel, suitable for use with the version of python used to build it.
The universal flag makes a wheel file that can be used under either
python2 or python3.  Perhaps surprisingly, the contents of a universal
wheel are *exactly* the same as the contents of a version-specific
wheel. Literally the *only* difference is the filename, which includes
both versions so that pip will choose the universal file if no
version-specific file exists.

Therefore, for our CI system, we want to publish universal wheels to
PyPI because they are more usable to consumers installing from there
(including the CI system).

On the other hand, for local builds, there's no particular reason to
prefer a universal wheel over the version-specific format. If someone is
building their own wheels for internal consumption, they can easily
choose to keep the version-specific packages, or add the --universal
flag like we're doing in the CI job.

So, I think this all means we can leave the setup.cfg files as they are
and not worry about updating the wheel format flag.

Doug

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


Re: [openstack-dev] [Release-job-failures] Release of openstack/os-log-merger failed

2018-10-04 Thread Doug Hellmann
Jeremy Stanley  writes:

> On 2018-10-04 17:57:06 -0400 (-0400), Doug Hellmann wrote:
> [...]
>>   HTTPError: 400 Client Error: Invalid value for classifiers. Error:
>>   'Topic:: Utilities' is not a valid choice for this field for url:
>>   https://upload.pypi.org/legacy/
>> 
>> I'm not aware of any way to test those values easily before doing an
>> upload. If someone knows of a way, please let me know.
>
> I started writing a distcheck utility based on some validation code
> flit uses, but now that twine has a check option there is expressed
> intent by Dustin to do it there (see description of
> https://github.com/pypa/twine/pull/395 for details) which seems like
> a more natural solution anyway.

OK, good. The existing check job for packaging already runs 'twine
check' so we should be covered when that feature is merged and released.

Doug

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


Re: [openstack-dev] Sphinx testing fun

2018-10-04 Thread Doug Hellmann
Stephen Finucane  writes:

> On Thu, 2018-10-04 at 07:21 -0400, Doug Hellmann wrote:
>> Stephen Finucane  writes:

[snip]

>> > Anyway, we can go figure out what's changed here and handle it but this
>> > is, at best, going to be a band aid. The fact is 'sphinx_testing' is
>> > unmaintained and has been for some time now. The new hotness is
>> > 'sphinx.testing' [3], which is provided (with zero documentation) as
>> > part of Sphinx. Unfortunately, this uses pytest fixtures [4] which I'm
>> > pretty sure Monty (and a few others?) are vehemently against using in
>> > OpenStack. That leaves us with three options:
>> > 
>> >  * Take over 'sphinx_testing' and bring it up-to-date. Maintain
>> >forever.
>> >  * Start using 'sphinx.testing' and everything it comes with
>> >  * Delete any tests that use 'sphinx_testing' and deal with the lack of
>> >coverage
>> 
>> Could we change our tests to use pathlib to wrap app.outdir and get the
>> same results as before?
>
> That's what I've done [2], which is kind of based on how I fixed this
> in Sphinx. However, this is at best a stopgap. The fact remains that
> 'sphinx_testing' is dead and the large changes that Sphinx is
> undergoing (2.0 will be Python 3 only, with multiple other fixes) will
> make further breakages more likely. Unless we want a repeat of the Mox
> situation, I do think we should start thinking about this sooner rather
> than later.

Yeah, it sounds like we need to deal with the change.

It looks like only the os-api-ref repo uses sphinx-testing. How many
tests are we talking about having to rewrite/update there?

Doug

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


Re: [openstack-dev] [Release-job-failures] Release of openstack/os-log-merger failed

2018-10-04 Thread Doug Hellmann
z...@openstack.org writes:

> Build failed.
>
> - release-openstack-python 
> http://logs.openstack.org/b4/b4553baa59b1f13a57973f2a3cff9b57acf3d522/release/release-openstack-python/68d0da8/
>  : POST_FAILURE in 5m 19s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
>
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

It looks like there is a bad classifier in the os-log-merger setup.cfg
file.

  HTTPError: 400 Client Error: Invalid value for classifiers. Error:
  'Topic:: Utilities' is not a valid choice for this field for url:
  https://upload.pypi.org/legacy/

I'm not aware of any way to test those values easily before doing an
upload. If someone knows of a way, please let me know.

Doug

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


Re: [openstack-dev] [all][Searchlight] Always build universal wheels

2018-10-04 Thread Doug Hellmann
Jeremy Stanley  writes:

> On 2018-10-04 23:11:22 +0900 (+0900), Trinh Nguyen wrote:
> [...]
>> Please avoid adding universal wheels to the project setup.cfg.
> [...]
>
> Why would you avoid also adding it to the setup.cfg? The change you
> cited is merely to be able to continue building universal wheels for
> projects while the setup.cfg files are corrected over time, to
> reduce the urgency of doing so. Wheel building happens in more
> places than just our CI system, so only fixing it in CI is not a
> good long-term strategy.

I abandoned a couple of dozen patches submitted today by someone who was
not coordinating with the goal champions with a message that said those
patches were not needed because I didn't want folks to be dealing with
this right now.

Teams who want to update their setup.cfg can do so, but my intent is to
ensure it is not required in order to produce releases with the
automation in the short term.

Doug

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


[openstack-dev] [tc] bringing back formal TC meetings

2018-10-04 Thread Doug Hellmann
During the TC office hours today [1] we discussed the question of
resuming having formal meetings of the TC to ensure we are in compliance
with the section of the bylaws that says "The Technical Committee shall
meet at least quarterly." [2] As not all TC members were present today,
we decide to move the discussion to the mailing list to ensure all
members have input into the decision.

A bit of background
---

The TC used to hold formal weekly meetings with agendas, roll call,
etc. We stopped doing that in an attempt to encourage more asynchronous
communication and to include folks in all time zones. Those meetings
were replaced with less formal "office hours" where TC members were
encouraged to be present on IRC in case the community had questions or
issues to raise in a synchronous forum.

The bylaws section that describes the membership and some of the
expectations for the Technical Committee specifically requires us to
meet at least once quarter year. We have had meetings at the PTGs and
summits, which while not recorded via a roll call were open and
documented afterwards with summaries to this mailing list.

With the change in event schedule, we will no longer have obvious
opportunities to hold 4 in-person meetings each year.  During the
discussion today, we established the general consensus that our current
informal office hours do not constitute a "meeting" in the sense that
any of us understand this requirement.  As a result, we need to consider
changes to our current meeting policy to ensure we are in compliance
with the foundation bylaws.

Today's discussion
--

A few folks expressed concern that we work to ensure these meetings
*not* be seen as a replacement for asynchronous communication, and that
we continue to encourage ad hoc discussions to continue to happen on the
mailing list or during office hours. I think we agreed we could do that
by managing the agenda carefully (i.e., the chair or vice chair would
need to add topics to the agenda, rather than allowing anyone to add
anything as we have done in the past). We also talked about only
allowing recurring topics on the agenda, but I would prefer that we not
write too many hard rules at the outset.

We discussed how frequently we should meet, and everyone seemed to agree
that weekly was too often and quarterly was not often enough. I proposed
monthly, and there was some general support for that. We also talked
about whether to find a new meeting time or to use one of the office
hour times.

As things stand now, the proposal is to try to find a time a few hours
earlier than office hours on the first Thursday of each month for the
meetings. The earlier time is so that APAC participants (Ghanshyam, in
particular) do not need to stay up until midnight or later to
participate.

Next steps
--

TC members, please reply to this thread and indicate if you would find
meeting at 1300 UTC on the first Thursday of every month acceptable, and
of course include any other comments you might have (including alternate
times).

Thanks,
Doug


[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-10-04.log.html#t2018-10-04T15:02:31
[2] https://www.openstack.org/legal/technical-committee-member-policy/ (item #4)

__
OpenStack Development Mailing 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] Sphinx testing fun

2018-10-04 Thread Doug Hellmann
Stephen Finucane  writes:

> The tests in os-api-ref recently broke:
>
>   
> http://logs.openstack.org/62/606362/1/check/openstack-tox-py35/8b709de/testr_results.html.gz
>
> Specifically, we're seeing errors likes this:
>
>   ft1.1: 
> os_api_ref.tests.test_basic_example.TestBasicExample.test_rest_method_StringException:
>  Traceback (most recent call last):
> File 
> "/home/zuul/src/git.openstack.org/openstack/os-api-ref/.tox/py35/lib/python3.5/site-packages/sphinx_testing/util.py",
>  line 143, in decorator
>func(*(args + (app, status, warning)), **kwargs)
>  File 
> "/home/zuul/src/git.openstack.org/openstack/os-api-ref/os_api_ref/tests/test_basic_example.py",
>  line 41, in setUp
>self.html = (app.outdir / 'index.html').read_text(encoding='utf-8')
>TypeError: unsupported operand type(s) for /: 'str' and 'str'
>
> Which is wrong because 'app.outdir' is not supposed to be an instance
> of 'unicode' but rather 'sphinx_testing.path.path' [1] (which overrides
> the '/' operator to act as concatenation because operator overloading
> is always a good idea 😒) [2].

Is that a change in Sphinx's API? Or sphinx_testing's?

>
> Anyway, we can go figure out what's changed here and handle it but this
> is, at best, going to be a band aid. The fact is 'sphinx_testing' is
> unmaintained and has been for some time now. The new hotness is
> 'sphinx.testing' [3], which is provided (with zero documentation) as
> part of Sphinx. Unfortunately, this uses pytest fixtures [4] which I'm
> pretty sure Monty (and a few others?) are vehemently against using in
> OpenStack. That leaves us with three options:
>
>  * Take over 'sphinx_testing' and bring it up-to-date. Maintain
>    forever.
>  * Start using 'sphinx.testing' and everything it comes with
>  * Delete any tests that use 'sphinx_testing' and deal with the lack of
>coverage

Could we change our tests to use pathlib to wrap app.outdir and get the
same results as before?

Doug

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


Re: [openstack-dev] [goal][python3] week 7 update

2018-10-03 Thread Doug Hellmann
Doug Hellmann  writes:

> Doug Hellmann  writes:
>
>> Doug Hellmann  writes:
>>
>>> == Things We Learned This Week ==
>>>
>>> When we updated the tox.ini settings for jobs like pep8 and release
>>> notes early in the Rocky session we only touched some of the official
>>> repositories. I'll be working on making a list of the ones we missed so
>>> we can update them by the end of Stein.
>>
>> I see quite a few repositories with tox settings out of date (about 350,
>> see below). Given the volume, I'm going to prepare the patches and
>> propose them a few at a time over the next couple of weeks.
>
> Zuul looked bored this morning so I went ahead and proposed a few of the
> larger batches of these changes for the Charms, OpenStack Ansible, and
> Horizon teams. TripleO also has quite a few, but since we know the gate
> is unstable I will hold off on those for now.
>
> There will be more patches when there is CI capacity again.
>
> Doug

All of these patches have now been proposed.

Doug

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


[openstack-dev] [goals][python3][barbican][monasca][neutron][charms][ansible][telemetry][trove][stable] completing zuul settings migration

2018-10-03 Thread Doug Hellmann
We have 7 teams still working on the zuul setting migrations as part of
the python3-first goal [1]. 

Quite a few of the changes are on stable branches, so will need
attention from the stable teams for each project. If you need help
reviewing those stable branch patches, please speak up so we can find
some folks on the stable team to provide +2 votes.

Some of the patches are failing the test jobs, probably because of
bitrot on older stable branches. Those may need extra attention from
project team members to fix, depending on the nature of the problems.

I would like to have this portion of the work done by the first
milestone, and I think we're close enough to do it. Please look through
the list of patches for your project and ensure they are in your review
queues.

Thanks,
Doug

[1] 
https://review.openstack.org/#/q/topic:python3-first+is:open+message:%22import+zuul+job+settings+from+project-config%22

__
OpenStack Development Mailing 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-job-failures][neutron] Release of openstack/networking-bigswitch failed

2018-10-03 Thread Doug Hellmann
AdityaVaja  writes:

> Hello Doug,
>
> I was going to send out an email or drop in on IRC to check how to fix that.
>
> We accidentally pushed 13.0.1 on stable/queens, instead of 12.0.5. (13.x.x
> is rocky and 12.x.x is queens)
> Tried reverting the situation by pushing 12.0.5 for the same commit hash on
> queens, but that didn't work. Releases with commit hash can be compared
> here [1].
>
> Deleting the release from PYPI can be done, but deleting a tag from gerrit
> is not possible without allowing forcePush from project-config - afaik. But
> that seems like an extreme step.
> Not sure how to fix the situation, so I thought checking with
> openstack-release to get an idea.
>
> If your original suggestion of pushing 12.0.6 still stands, I can go ahead
> and do that.

I think that pushing 12.0.6 to a point on that branch after the
12.0.5/13.0.1 commit will produce a new release with version 12.0.6 that
works correctly.

Unfortunately, you're right that we don't have a good way to remove the
old 13.0.1 release and tag. In the past we have just ignored that and
moved on, although I think in some cases we did remove the package from
PyPI to avoid having it installed accidentally. I don't know how many of
your users are using pip to install the packages you build, so I don't
know how important it will be for you to do that.

Doug

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


Re: [openstack-dev] [all] Zuul job backlog

2018-10-03 Thread Doug Hellmann
Wesley Hayutin  writes:

[snip]

> The TripleO project has created a single node container based composable
> OpenStack deployment [2]. It is the projects intention to replace most of
> the TripleO upstream jobs with the Standalone deployment.  We would like to
> reduce our multi-node usage to a total of two or three multinode jobs to
> handle a basic overcloud deployment, updates and upgrades[a]. Currently in
> master we are relying on multiple multi-node scenario jobs to test many of
> the OpenStack services in a single job. Our intention is to move these
> multinode scenario jobs to single node job(s) that tests a smaller subset
> of services. The goal of this would be target the specific areas of the
> TripleO code base that affect these services and only run those there. This
> would replace the existing 2-3 hour two node job(s) with single node job(s)
> for specific services that completes in about half the time.  This
> unfortunately will reduce the overall coverage upstream but still allows us
> a basic smoke test of the supported OpenStack services and their deployment
> upstream.
>
> Ideally projects other than TripleO would make use of the Standalone
> deployment to test their particular service with containers, upgrades or
> for various other reasons.  Additional projects using this deployment would
> help ensure bugs are found quickly and resolved providing additional
> resilience to the upstream gate jobs. The TripleO team will begin review to
> scope out and create estimates for the above work starting on October 18
> 2018.  One should expect to see updates on our progress posted to the
> list.  Below are some details on the proposed changes.

[snip]

Thanks for all of the details, Wes. I know the current situation has
been hurting the TripleO team as well, so I'm glad to see a good plan in
place to address it. I look forward to seeing updates about the
progress.

Doug

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


Re: [openstack-dev] [goals][python3][heat][stable] how should we proceed with ocata branch

2018-10-03 Thread Doug Hellmann
Zane Bitter  writes:

> On 3/10/18 9:42 AM, Matt Riedemann wrote:
>> On 10/3/2018 7:58 AM, Doug Hellmann wrote:
>>> There is one more patch to import the zuul configuration for the
>>> heat-agents repository's stable/ocata branch. That branch is apparently
>>> broken, and Zane suggested on the review [1] that we abandon the patch
>>> and close the branch.
>>>
>>> That patch is the only thing blocking the cleanup patch in
>>> project-config, so I would like to get a definitive answer about what to
>>> do. Should we close the branch, or does someone want to try to fix
>>> things up?
>
> I think we agreed on closing the branch, and Rico was looking into the 
> procedure for how to actually do that.

OK. I am going to abandon the patch to import the zuul settings
then. Abandoning all open patches is one of the early steps anyway, and
doing that now for this 1 patch will allow us to proceed with the
cleanup.

Doug

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


Re: [openstack-dev] [Release-job-failures][neutron] Release of openstack/networking-bigswitch failed

2018-10-03 Thread Doug Hellmann
z...@openstack.org writes:

> Build failed.
>
> - release-openstack-python 
> http://logs.openstack.org/d1/d1df2f75e0e8259ddaaf5136f421567733ba7f5b/release/release-openstack-python/8a89663/
>  : FAILURE in 6m 19s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED

It looks like there's something wrong with the versioning in the
stable/queens branch of the networking-bigswitch repository.

The error I see when I run "python setup.py --name" locally is:

  ValueError: git history requires a target version of
  pbr.version.SemanticVersion(13.0.1), but target version is
  pbr.version.SemanticVersion(12.0.5)

This is being caused by re-tagging the 13.0.1 release as 12.0.5.

I think if we tag a *newer* commit as 12.0.6 that will work (it seems to
work locally).

Doug

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


[openstack-dev] [goals][python3][heat][stable] how should we proceed with ocata branch

2018-10-03 Thread Doug Hellmann
There is one more patch to import the zuul configuration for the
heat-agents repository's stable/ocata branch. That branch is apparently
broken, and Zane suggested on the review [1] that we abandon the patch
and close the branch.

That patch is the only thing blocking the cleanup patch in
project-config, so I would like to get a definitive answer about what to
do. Should we close the branch, or does someone want to try to fix
things up?

Doug

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

__
OpenStack Development Mailing 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] [goal][python3] week 8 update

2018-10-02 Thread Doug Hellmann
This is week 8 of the "Run under Python 3 by default" goal
(https://governance.openstack.org/tc/goals/stein/python3-first.html). 

== Ongoing and Completed Work ==

I proposed a large set of new patches to update the tox settings for
repositories that were still using python2 for doc, release note,
linter, etc. jobs. Quite a few of those were duplicates, so if you find
that someone else has already started that work please vote -1 on my
patch with a link to the other one, and I'll abandon mine.

+-+-+--+-+--+-++---++
| Team| zuul| tox defaults | Docs| 3.6 unit 
| Failing | Unreviewed | Total | Champion   |
+-+-+--+-+--+-++---++
| adjutant| +   |   1/  1  | -   | +
|   0 |      1 | 6 | Doug Hellmann  |
| barbican|   7/ 13 | +|   1/  3 | +
|   6 |      4 |20 | Doug Hellmann  |
| blazar  | +   | +| +   | +
|   0 |  0 |25 | Nguyen Hai |
| Chef OpenStack  | +   |   2/  2  | -   | -
|   1 |      1 | 3 | Doug Hellmann  |
| cinder  | +   |   1/  3  | +   | +
|   0 |      1 |33 | Doug Hellmann  |
| cloudkitty  | +   | +| +   | +
|   0 |      0 |26 | Doug Hellmann  |
| congress| +   |   1/  3  | +   | +
|   1 |  1 |25 | Nguyen Hai |
| cyborg  | +   | +| +   | +
|   0 |  0 |16 | Nguyen Hai |
| designate   | +   |   2/  4  | +   | +
|   0 |  1 |26 | Nguyen Hai |
| Documentation   | +   |   1/  5  | +   | +
|   1 |      1 |23 | Doug Hellmann  |
| dragonflow  | +   | -| +   | +
|   0 |  0 | 6 | Nguyen Hai |
| ec2-api | +   |   2/  2  | +   | +
|   2 |  2 |14 ||
| freezer | waiting for cleanup |   1/  5  | +   | +
|   0 |  1 |34 ||
| glance  | +   |   1/  4  | +   | +
|   0 |  0 |26 | Nguyen Hai |
| heat|   3/ 27 |   4/  8  |   1/  6 |   1/  7  
|   2 |      4 |48 | Doug Hellmann  |
| horizon | +   |   1/ 32  | +   | +
|   0 |  1 |42 | Nguyen Hai |
| I18n| +   |   1/  1  | -   | -
|   0 |      0 | 3 | Doug Hellmann  |
| InteropWG   | +   |   4/  4  | +   |   1/  3  
|   2 |      4 |14 | Doug Hellmann  |
| ironic  | +   |   1/ 10  | +   | +
|   0 |      1 |95 | Doug Hellmann  |
| karbor  | +   | +| +   | +
|   0 |  0 |22 | Nguyen Hai |
| keystone| +   |   1/  7  | +   | +
|   0 |      0 |48 | Doug Hellmann  |
| kolla   | +   |   1/  1  | +   | +
|   1 |  0 |13 ||
| kuryr   | +   | +| +   | +
|   0 |      0 |20 | Doug Hellmann  |
| magnum  | +   |   2/  5  | +   | +
|   0 |  1 |27 ||
| manila  | +   |   4/  8  | +   | +
|   0 |  0 |32 | Goutham Pacha Ravi |
| masakari| +   |   3/  5  | +   | -
|   0 |  3 |24 | Nguyen Hai |
| mistral | +   | +| +   | +
|   0 |  0 |38 | Nguyen Hai |
| monasca |   1/ 66 |   5/ 17  | +   | +
|   3 |      4 |   100 | Doug Hellmann  |
| murano  | +   |   2/  5  | +   | +
|   0 |  2 |39 ||
| neutron |  15/ 73 |  12/ 18  |   2/ 14 |   2/ 13  
|  18 |     18 |   118 | Doug Hellman

Re: [openstack-dev] [Release-job-failures] Release of openstack/os-log-merger failed

2018-10-01 Thread Doug Hellmann
Miguel Angel Ajo Pelayo  writes:

> Thank you for the guidance and ping Doug.
>
> Was this triggered by [1] ? or By the 1.1.0 tag pushed to gerrit?

The release jobs are always triggered by the git tagging event. The
patches in openstack/releases run a job that adds tags, but the patch
you linked to hasn't been merged yet, so it looks like it was caused by
pushing the tag manually.

Doug

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


Re: [openstack-dev] [python3-first] support in stable branches

2018-10-01 Thread Doug Hellmann
Dariusz Krol  writes:

> Hello Doug,
>
> thanks for your explanation. I was a little bit confused by changes to 
> stable branches with python3-first topic as I thought it has to do 
> something with adding new test configuration for python3.
>
> But as you explained this is about moving zuul-related configuration, 
> which is a part of python3-first goal (but it is not related to 
> supporting python3 by projects IMHO :) )
>
> Anyway, it is now clear to me and sorry for making this confusion.

Thanks for asking for clarification!

Doug

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


Re: [openstack-dev] [goal][python3] week 7 update

2018-09-29 Thread Doug Hellmann
Doug Hellmann  writes:

> Doug Hellmann  writes:
>
>> == Things We Learned This Week ==
>>
>> When we updated the tox.ini settings for jobs like pep8 and release
>> notes early in the Rocky session we only touched some of the official
>> repositories. I'll be working on making a list of the ones we missed so
>> we can update them by the end of Stein.
>
> I see quite a few repositories with tox settings out of date (about 350,
> see below). Given the volume, I'm going to prepare the patches and
> propose them a few at a time over the next couple of weeks.

Zuul looked bored this morning so I went ahead and proposed a few of the
larger batches of these changes for the Charms, OpenStack Ansible, and
Horizon teams. TripleO also has quite a few, but since we know the gate
is unstable I will hold off on those for now.

There will be more patches when there is CI capacity again.

Doug

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


Re: [openstack-dev] [goal][python3] week 7 update

2018-09-28 Thread Doug Hellmann
Jeremy Stanley  writes:

> On 2018-09-28 13:58:52 -0400 (-0400), William M Edmonds wrote:
>> Doug Hellmann  wrote on 09/26/2018 06:29:11 PM:
>> 
>> > * We do not want to set the override once in testenv, because that
>> >   breaks the more specific versions used in default environments like
>> >   py35 and py36 (at least under older versions of tox).
>> 
>> 
>> I assume that something like
>> https://git.openstack.org/cgit/openstack/nova-powervm/commit/?id=fa64a93c965e6a6692711962ad6584534da81695
>>  should be a perfectly acceptable alternative in at least some cases.
>> Agreed?
>
> I believe the confusion is that ignore_basepython_conflict didn't
> appear in a release of tox until after we started patching projects
> for this effort (in fact it was added to tox in part because we
> discovered the issue in originally attempting to use basepython
> globally).

Right. The scripted patches work with older versions of tox as
well. They also have the benefit of only changing the environments into
which the new setting is injected, which means if you have a
py27-do-something-random environment it isn't going to suddenly start
using python 3 instead of python 2.7.

The thing we care about for the goal is ensuring that the required jobs
run under python 3.  Teams are, as always, completely free to choose
alternative implementations if they are willing to update the patches
(or write alternative ones).

Doug

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


Re: [openstack-dev] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs

2018-09-28 Thread Doug Hellmann
Doug Hellmann  writes:

> I think we are ready to go ahead and switch all of the python packaging
> jobs to the new set defined in the publish-to-pypi-python3 template
> [1]. We still have some cleanup patches for projects that have not
> completed their zuul migration, but there are only a few and rebasing
> those will be easy enough.
>
> The template adds a new check job that runs when any files related to
> packaging are changed (readme, setup, etc.). Otherwise it switches from
> the python2-based PyPI job to use python3.
>
> I have the patch to switch all official projects ready in [2].
>
> Doug
>
> [1] 
> http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/project-templates.yaml#n218
> [2] https://review.openstack.org/#/c/598323/

This change is now in place. The Ironic team discovered one issue, and
the fix is proposed as https://review.openstack.org/606152

This change has also reopened the question of how to publish some of the
projects for which we do not own names on PyPI.

I registered manila, qinling, and zaqar-ui by uploading Rocky series
releases of those projects and then added openstackci as an owner so we
can upload new packages this cycle.

I asked the owners of the name "heat" to allow us to use it, and they
rejected the request. So, I proposed a change to heat to update the
sdist name to "openstack-heat".

* https://review.openstack.org/606160

We don't own "magnum" but there is already an "openstack-magnum" set up
with old releases, so I have proposed a change to the magnum repo to
change the dist name there, so we can resume using it.

* https://review.openstack.org/606162

I have filed requests with the maintainers of PyPI to claim the names
"keystone" and "congress". That may take some time. Please let me know
if you're willing to simply use "openstack-keystone" and
"openstack-congress" instead. I will take care of configuring PyPI and
proposing the patch to update your setup.cfg (that way you can approve
the change).

* https://github.com/pypa/warehouse/issues/4770
* https://github.com/pypa/warehouse/issues/4771

Doug

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


Re: [openstack-dev] [python3-first] support in stable branches

2018-09-28 Thread Doug Hellmann
Dariusz Krol  writes:

> Hello,
>
>
> I'm specifically referring to branches mentioned in: 
> https://github.com/openstack/goal-tools/blob/4125c31e74776a7dc6a15d2276ab51ff3e73cd16/goal_tools/python3_first/jobs.py#L54
>  

I'm still not entirely sure what you're saying is happening that you do
not expect to have happening, but I'll take a guess.

The zuul migration portion of the goal work needs to move *all* of the
Zuul settings for a repo into the correct branch because after the
migration the job settings will no longer be in project-config at all
and so zuul won't know which jobs to run on the stable branches if we
haven't imported the settings.

The migration script tries to figure out which jobs apply to which
branches of each repo by looking at the branch specifier settings in
project-config, and then it creates an import patch for each branch with
the relevant jobs. Subsequent steps in the script change the
documentation and release notes jobs and then add new python 3.6 testing
jobs. Those steps only apply to the master branch.

So, if you have a patch importing a python 3 job setting to a stable
branch of a repo where you aren't expecting it (and it isn't supported),
that's most likely because project-config has no branch specifiers for
the job (meaning it should run on all branches). We did find several
cases where that was true because projects added jobs without branch
specifiers after the branches were created, and then back-ported no
patches to the stable branch. See
http://lists.openstack.org/pipermail/openstack-dev/2018-August/133594.html
for details.

Doug

> I hope this helps.
>
>
> Best,
>
> Dariusz Krol
>
>
> On 09/27/2018 06:04 PM, Ben Nemec wrote:
>>
>>
>> On 9/27/18 10:36 AM, Doug Hellmann wrote:
>>> Dariusz Krol  writes:
>>>
>>>> Hello Champions :)
>>>>
>>>>
>>>> I work on the Trove project and we are wondering if python3 should be
>>>> supported in previous releases as well?
>>>>
>>>> Actually this question was asked by Alan Pevec from the stable branch
>>>> maintainers list.
>>>>
>>>> I saw you added releases up to ocata to support python3 and there are
>>>> already changes on gerrit waiting to be merged but after reading [1] I
>>>> have my doubts about this.
>>>
>>> I'm not sure what you're referring to when you say "added releases up to
>>> ocata" here. Can you link to the patches that you have questions about?
>>
>> Possibly the zuul migration patches for all the stable branches? If 
>> so, those don't change the status of python 3 support on the stable 
>> branches, they just split the zuul configuration to make it easier to 
>> add new python 3 jobs on master without affecting the stable branches.
>>
>>>
>>>> Could you elaborate why it is necessary to support previous releases ?
>>>>
>>>>
>>>> Best,
>>>>
>>>> Dariusz Krol
>>>>
>>>>
>>>> [1] https://docs.openstack.org/project-team-guide/stable-branches.html
>>>> __ 
>>>>
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: 
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> __ 
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>

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


Re: [openstack-dev] [Release-job-failures] Release of openstack/os-log-merger failed

2018-09-28 Thread Doug Hellmann
z...@openstack.org writes:

> Build failed.
>
> - release-openstack-python 
> http://logs.openstack.org/d4/d445ff62676bc5b2753fba132a3894731a289fb9/release/release-openstack-python/629c35f/
>  : FAILURE in 3m 57s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED

The error here is

  ERROR: unknown environment 'venv'

It looks like os-log-merger is not set up for the
release-openstack-python job, which expects a specific tox setup.

http://logs.openstack.org/d4/d445ff62676bc5b2753fba132a3894731a289fb9/release/release-openstack-python/629c35f/ara-report/result/7c6fd37c-82d8-48f7-b653-5bdba90cbc31/

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


Re: [openstack-dev] [all][tc][elections] Stein TC Election Results

2018-09-28 Thread Doug Hellmann
Emmet Hikory  writes:

> Please join me in congratulating the 6 newly elected members of the
> Technical Committee (TC):
>
>   - Doug Hellmann (dhellmann)
>   - Julia Kreger (TheJulia)
>   - Jeremy Stanley (fungi)
>   - Jean-Philippe Evrard (evrardjp)
>   - Lance Bragstad (lbragstad)
>   - Ghanshyam Mann (gmann)

Congratulations, everyone! I'm looking forward to serving with all of
you for another term.

> Full Results:
> https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_f773fda2d0695864
>
> Election process details and results are also available here:
> https://governance.openstack.org/election/
>
> Thank you to all of the candidates, having a good group of candidates helps
> engage the community in our democratic process.
>
> Thank you to all who voted and who encouraged others to vote.  Voter turnout
> was significantly up from recent cycles.  We need to ensure your voices are
> heard.

It's particularly good to hear that turnout is up, not just in
percentage but in raw numbers, too. Thank you all for voting!

Doug

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


Re: [openstack-dev] [release] Release model for feature-complete OpenStack libraries

2018-09-28 Thread Doug Hellmann
 writes:

> How will we handle which versions of libraries work together?
> And which combinations will be run thru CI?

Dependency management will work the same way it does today.

Each component (server or library) lists the versions of the
dependencies it is compatible with. That information goes into the
packages built for the component, and is used to ensure that a
compatible version of each dependency is installed when the package is
installed.

We control what is actually tested by using the upper constraints list
managed in the requirements repository. There's more detail about how
that list is managed in the project team guide at
https://docs.openstack.org/project-team-guide/dependency-management.html

Doug

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


Re: [openstack-dev] [python3-first] support in stable branches

2018-09-27 Thread Doug Hellmann
Dariusz Krol  writes:

> Hello Champions :)
>
>
> I work on the Trove project and we are wondering if python3 should be 
> supported in previous releases as well?
>
> Actually this question was asked by Alan Pevec from the stable branch 
> maintainers list.
>
> I saw you added releases up to ocata to support python3 and there are 
> already changes on gerrit waiting to be merged but after reading [1] I 
> have my doubts about this.

I'm not sure what you're referring to when you say "added releases up to
ocata" here. Can you link to the patches that you have questions about?

> Could you elaborate why it is necessary to support previous releases ?
>
>
> Best,
>
> Dariusz Krol
>
>
> [1] https://docs.openstack.org/project-team-guide/stable-branches.html
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [goals][python3] switching python package jobs

2018-09-27 Thread Doug Hellmann
I think we are ready to go ahead and switch all of the python packaging
jobs to the new set defined in the publish-to-pypi-python3 template
[1]. We still have some cleanup patches for projects that have not
completed their zuul migration, but there are only a few and rebasing
those will be easy enough.

The template adds a new check job that runs when any files related to
packaging are changed (readme, setup, etc.). Otherwise it switches from
the python2-based PyPI job to use python3.

I have the patch to switch all official projects ready in [2].

Doug

[1] 
http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/project-templates.yaml#n218
[2] https://review.openstack.org/#/c/598323/

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


Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series

2018-09-27 Thread Doug Hellmann
Monty Taylor  writes:

> Main difference is making sure these new deconstructed plugin teams 
> understand the client support lifecycle - which is that we don't drop 
> support for old versions of services in OSC (or SDK). It's a shift from 
> the support lifecycle and POV of python-*client, but it's important and 
> we just need to all be on the same page.

That sounds like a reason to keep the governance of the libraries under
the client tool project.

Doug

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


Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series

2018-09-27 Thread Doug Hellmann
Dean Troyer  writes:

> On Wed, Sep 26, 2018 at 3:44 PM, Matt Riedemann  wrote:
>> I started documenting the compute API gaps in OSC last release [1]. It's a
>> big gap and needs a lot of work, even for existing CLIs (the cold/live
>> migration CLIs in OSC are a mess, and you can't even boot from volume where
>> nova creates the volume for you). That's also why I put something into the
>> etherpad about the OSC core team even being able to handle an onslaught of
>> changes for a goal like this.
>
> The OSC core team is very thin, yes, it seems as though companies
> don't like to spend money on client-facing things...I'll be in the
> hall following this thread should anyone want to talk...
>
> The migration commands are a mess, mostly because I got them wrong to
> start with and we have only tried to patch it up, this is one area I
> think we need to wipe clean and fix properly.  Yay! Major version
> release!

I definitely think having details about the gaps would be a prerequisite
for approving a goal, but I wonder if that's something 1 person could
even do alone. Is this an area where a small team is needed?

>> I thought the same, and we talked about this at the Austin summit, but OSC
>> is inconsistent about this (you can live migrate a server but you can't
>> evacuate it - there is no CLI for evacuation). It also came up at the Stein
>> PTG with Dean in the nova room giving us some direction. [2] I believe the
>> summary of that discussion was:
>
>> a) to deal with the core team sprawl, we could move the compute stuff out of
>> python-openstackclient and into an osc-compute plugin (like the
>> osc-placement plugin for the placement service); then we could create a new
>> core team which would have python-openstackclient-core as a superset
>
> This is not my first choice but is not terrible either...

We built cliff to be based on plugins to support this sort of work
distribution, right?

>> b) Dean suggested that we close the compute API gaps in the SDK first, but
>> that could take a long time as well...but it sounded like we could use the
>> SDK for things that existed in the SDK and use novaclient for things that
>> didn't yet exist in the SDK
>
> Yup, this can be done in parallel.  The unit of decision for use sdk
> vs use XXXclient lib is per-API call.  If the client lib can use an
> SDK adapter/session it becomes even better.  I think the priority for
> what to address first should be guided by complete gaps in coverage
> and the need for microversion-driven changes.
>
>> This might be a candidate for one of these multi-release goals that the TC
>> started talking about at the Stein PTG. I could see something like this
>> being a goal for Stein:
>>
>> "Each project owns its own osc- plugin for OSC CLIs"
>>
>> That deals with the core team and sprawl issue, especially with stevemar
>> being gone and dtroyer being distracted by shiny x-men bird related things.
>> That also seems relatively manageable for all projects to do in a single
>> release. Having a single-release goal of "close all gaps across all service
>> types" is going to be extremely tough for any older projects that had CLIs
>> before OSC was created (nova/cinder/glance/keystone). For newer projects,
>> like placement, it's not a problem because they never created any other CLI
>> outside of OSC.

Yeah, I agree this work is going to need to be split up. I'm still not
sold on the idea of multi-cycle goals, personally.

> I think the major difficulty here is simply how to migrate users from
> today state to future state in a reasonable manner.  If we could teach
> OSC how to handle the same command being defined in multiple plugins
> properly (hello entrypoints!) it could be much simpler as we could
> start creating the new plugins and switch as the new command
> implementations become available rather than having a hard cutover.
>
> Or maybe the definition of OSC v4 is as above and we just work at it
> until complete and cut over at the end.  Note that the current APIs
> that are in-repo (Compute, Identity, Image, Network, Object, Volume)
> are all implemented using the plugin structure, OSC v4 could start as
> the breaking out of those without command changes (except new
> migration commands!) and then the plugins all re-write and update at
> their own tempo.  Dang, did I just deconstruct my project?

It sure sounds like it. Congratulations!

I like the idea of moving the existing code into libraries, having
python-openstackclient depend on them, and then asking project teams for
more help with them.

> One thing I don't like about that is we 

Re: [openstack-dev] [goal][python3] week 7 update

2018-09-26 Thread Doug Hellmann
Doug Hellmann  writes:

> == Things We Learned This Week ==
>
> When we updated the tox.ini settings for jobs like pep8 and release
> notes early in the Rocky session we only touched some of the official
> repositories. I'll be working on making a list of the ones we missed so
> we can update them by the end of Stein.

I see quite a few repositories with tox settings out of date (about 350,
see below). Given the volume, I'm going to prepare the patches and
propose them a few at a time over the next couple of weeks.

As background, each repo needs a patch (to master only) that looks like
[1]. It needs to set the "basepython" parameter in all of the relevant
tox environments to "python3" to force using python 3. It is most
important to set the docs, linters, pep8, releasenotes,
lower-constraints and venv environments, but we also wanted to include
bindep and cover if they are present.

The patches I prepare will update all of those environments.  We should
also include any other environments that run jobs, but teams may want to
duplicate some (and add the relevant jobs) rather than changing all of
the functional test jobs. As with the other functional job changes, I
will leave those up to the project teams.

As the commit message on [1] explains, we are using "python3" on
purpose:

* We do not want to specify a minor version number, because we do not
  want to have to update the file every time we upgrade python.

* We do not want to set the override once in testenv, because that
  breaks the more specific versions used in default environments like
  py35 and py36 (at least under older versions of tox).

In case you want to watch for them, all of the new patches will use "fix
tox python3 overrides" as the first line of the commit message (the
tracking tool looks for that string).

Doug

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

__
OpenStack Development Mailing 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] [goals][tc][ptl][uc] starting goal selection for T series

2018-09-26 Thread Doug Hellmann
Monty Taylor  writes:

> On 09/26/2018 01:55 PM, Tim Bell wrote:
>> 
>> Doug,
>> 
>> Thanks for raising this. I'd like to highlight the goal "Finish moving 
>> legacy python-*client CLIs to python-openstackclient" from the etherpad and 
>> propose this for a T/U series goal.
>> 
>> To give it some context and the motivation:
>> 
>> At CERN, we have more than 3000 users of the OpenStack cloud. We write an 
>> extensive end user facing documentation which explains how to use the 
>> OpenStack along with CERN specific features (such as workflows for 
>> requesting projects/quotas/etc.).
>> 
>> One regular problem we come across is that the end user experience is 
>> inconsistent. In some cases, we find projects which are not covered by the 
>> unified OpenStack client (e.g. Manila). In other cases, there are subsets of 
>> the function which require the native project client.
>> 
>> I would strongly support a goal which targets
>> 
>> - All new projects should have the end user facing functionality fully 
>> exposed via the unified client
>> - Existing projects should aim to close the gap within 'N' cycles (N to be 
>> defined)
>> - Many administrator actions would also benefit from integration (reader 
>> roles are end users too so list and show need to be covered too)
>> - Users should be able to use a single openrc for all interactions with the 
>> cloud (e.g. not switch between password for some CLIs and Kerberos for OSC)
>> 
>> The end user perception of a solution will be greatly enhanced by a single 
>> command line tool with consistent syntax and authentication framework.
>> 
>> It may be a multi-release goal but it would really benefit the cloud 
>> consumers and I feel that goals should include this audience also.
>
> ++
>
> It's also worth noting that we're REALLY close to a 1.0 of openstacksdk 
> (all the patches are in flight, we just need to land them) - and once 
> we've got that we'll be in a position to start shifting 
> python-openstackclient to using openstacksdk instead of python-*client.
>
> This will have the additional benefit that, once we've migrated CLIs to 
> python-openstackclient as per this goal, and once we've migrated 
> openstackclient itself to openstacksdk, the number of different 
> libraries one needs to install to interact with openstack will be 
> _dramatically_ lower.

Would it be useful to have the SDK work in OSC as a prerequisite to the
goal work? I would hate to have folks have to write a bunch of things
twice.

Do we have any sort of list of which projects aren't currently being
handled by OSC? If we could get some help building such a list, that
would help us understand the scope of the work.

As far as admin features, I think we've been hesitant to add those to
OSC in the past, but I can see the value. I wonder if having them in a
separate library makes sense? Or is it better to have commands in the
tool that regular users can't access, and just report the permission
error when they try to run the command?

Doug

>
>> -Original Message-
>> From: Doug Hellmann 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> Date: Wednesday, 26 September 2018 at 18:00
>> To: openstack-dev , openstack-operators 
>> , openstack-sigs 
>> 
>> Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T  
>> series
>> 
>>  It's time to start thinking about community-wide goals for the T series.
>>  
>>  We use community-wide goals to achieve visible common changes, push for
>>  basic levels of consistency and user experience, and efficiently improve
>>  certain areas where technical debt payments have become too high -
>>  across all OpenStack projects. Community input is important to ensure
>>  that the TC makes good decisions about the goals. We need to consider
>>  the timing, cycle length, priority, and feasibility of the suggested
>>  goals.
>>  
>>  If you are interested in proposing a goal, please make sure that before
>>  the summit it is described in the tracking etherpad [1] and that you
>>  have started a mailing list thread on the openstack-dev list about the
>>  proposal so that everyone in the forum session [2] has an opportunity to
>>  consider the details.  The forum session is only one step in the
>>  selection process. See [3] for more details.
>>  
>>  Doug
>>  
>>  [1]

Re: [openstack-dev] [storyboard][oslo] Fewer stories than bugs?

2018-09-26 Thread Doug Hellmann
Ben Nemec  writes:

> Okay, I found a few bugs that are in launchpad but not storyboard:
>
> https://bugs.launchpad.net/python-stevedore/+bug/1784823
> https://bugs.launchpad.net/pbr/+bug/1777625
> https://bugs.launchpad.net/taskflow/+bug/1756520
> https://bugs.launchpad.net/pbr/+bug/1742809
>
> The latter three are all in an incomplete state, so maybe that's being 
> ignored by the migration script? The first appears to be a completely 
> missing project.  None of the stevedore bugs I've spot checked are in 
> storyboard. Maybe it has to do with the fact that the project name is 
> stevedore but the bug link is python-stevedore? I'm not sure why that 
> is, but there may be something a little weird going on with that
> project.

The name "stevedore" was taking on LP when I registered that project, so
I had to use an alternative name.

Doug

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


Re: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables

2018-09-26 Thread Doug Hellmann
Jeremy Stanley  writes:

> On 2018-09-26 09:22:30 -0500 (-0500), Sean McGinnis wrote:
> [...]
>> It tests the release automation machinery to identify problems
>> before the RC and final release crunch time.
> [...]
>
> More to the point, it helped spot changes to projects which made it
> impossible to generate and publish their release artifacts. Coverage
> has improved for finding these issues before merging now, as well as
> in flight tests on proposed releases, making the risk lower than it
> used to be.

The new set of packaging jobs that are part of the
publish-to-pypi-python3 project template also include a check queue job
that runs when any of the packaging files (setup.*, README.rst, etc.)
are modified. That should give us an even earlier warning of any
packaging failures.

Since all python projects will soon use the same release jobs, we will
know that the job is working in general based on other releases
(including more liberal use of our test repository before big
deadlines).

Doug

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


[openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series

2018-09-26 Thread Doug Hellmann
It's time to start thinking about community-wide goals for the T series.

We use community-wide goals to achieve visible common changes, push for
basic levels of consistency and user experience, and efficiently improve
certain areas where technical debt payments have become too high -
across all OpenStack projects. Community input is important to ensure
that the TC makes good decisions about the goals. We need to consider
the timing, cycle length, priority, and feasibility of the suggested
goals.

If you are interested in proposing a goal, please make sure that before
the summit it is described in the tracking etherpad [1] and that you
have started a mailing list thread on the openstack-dev list about the
proposal so that everyone in the forum session [2] has an opportunity to
consider the details.  The forum session is only one step in the
selection process. See [3] for more details.

Doug

[1] https://etherpad.openstack.org/p/community-goals
[2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814
[3] https://governance.openstack.org/tc/goals/index.html

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


[openstack-dev] [goal][python3] week 7 update

2018-09-26 Thread Doug Hellmann

This is week 7 of the "Run under Python 3 by default" goal
(https://governance.openstack.org/tc/goals/stein/python3-first.html).

== Things We Learned This Week ==

When we updated the tox.ini settings for jobs like pep8 and release
notes early in the Rocky session we only touched some of the official
repositories. I'll be working on making a list of the ones we missed so
we can update them by the end of Stein.

== Ongoing and Completed Work ==

Teams are making great progress, but it looks like we have some
lingering changes in branches where the test jobs are failing.

+-+-+--+-+--+-++---++
| Team| zuul| tox defaults | Docs| 3.6 unit | Failing | 
Unreviewed | Total | Champion   |
+-+-+--+-+--+-++---++
| adjutant| +   | -| -   | +|   0 | 
     0 | 5 | Doug Hellmann  |
| barbican|  11/ 13 | +|   1/  3 | +|   6 | 
     4 |20 | Doug Hellmann  |
| blazar  | +   | +| +   | +|   0 | 
 0 |25 | Nguyen Hai |
| Chef OpenStack  | +   | -| -   | -|   0 | 
     0 | 1 | Doug Hellmann  |
| cinder  | +   | +| +   | +|   0 | 
     0 |31 | Doug Hellmann  |
| cloudkitty  | +   | +| +   | +|   0 | 
     0 |24 | Doug Hellmann  |
| congress| +   | +| +   | +|   0 | 
 0 |24 | Nguyen Hai |
| cyborg  | +   | +| +   | +|   0 | 
 0 |16 | Nguyen Hai |
| designate   | +   | +| +   | +|   0 | 
 0 |24 | Nguyen Hai |
| Documentation   | +   | +| +   | +|   0 | 
     0 |22 | Doug Hellmann  |
| dragonflow  | +   | -| +   | +|   0 | 
 0 | 6 | Nguyen Hai |
| ec2-api | +   | -| +   | +|   0 | 
 0 |12 ||
| freezer |   3/ 23 | +| +   |   2/  4  |   2 | 
 0 |33 ||
| glance  | +   |   1/  4  | +   | +|   0 | 
 0 |26 | Nguyen Hai |
| heat|   3/ 27 |   1/  5  |   1/  6 |   1/  7  |   3 | 
     2 |45 | Doug Hellmann  |
| horizon | +   | +| +   | +|   0 | 
 0 |11 | Nguyen Hai |
| I18n| +   | -| -   | -|   0 | 
     0 | 2 | Doug Hellmann  |
| InteropWG   | +   | -| +   |   1/  3  |   0 | 
     0 |10 | Doug Hellmann  |
| ironic  |  12/ 60 | +|   2/ 13 |   1/ 12  |   0 | 
     0 |90 | Doug Hellmann  |
| karbor  | +   | +| +   | +|   0 | 
 0 |22 | Nguyen Hai |
| keystone| +   | +| +   | +|   0 | 
     0 |47 | Doug Hellmann  |
| kolla   | +   | -| +   | +|   0 | 
 0 |12 ||
| kuryr   | +   | +| +   | +|   0 | 
     0 |19 | Doug Hellmann  |
| magnum  | +   | +| +   | +|   0 | 
 0 |24 ||
| manila  |   3/ 19 | +| +   | +|   3 | 
 3 |28 | Goutham Pacha Ravi |
| masakari| +   | +| +   | -|   0 | 
 0 |21 | Nguyen Hai |
| mistral | +   | +| +   | +|   0 | 
 0 |37 | Nguyen Hai |
| monasca |   1/ 66 |   1/  7  | +   | +|   2 | 
     1 |90 | Doug Hellmann  |
| murano  | +   | +| +   | +|   0 | 
 0 |37 ||
| neutron |  21/ 73 | +|   2/ 14 |   2/ 13  |  11 | 
    12 |   106 | Doug Hellmann  |
| nova| +   | +| +   | +|   0 | 
 0 |37 ||
| octavia | +   | +| +   | +|   0 | 
 0 |34 | Nguyen Hai |
| OpenStack Charms|  17/117 | -| -   | -|  14 | 
    17 |   117 

Re: [openstack-dev] [storyboard] Prioritization?

2018-09-25 Thread Doug Hellmann
Adam Coldrick  writes:

> On Mon, 2018-09-24 at 22:47 +, Jeremy Stanley wrote:
>> On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote:
>> [...]
>> > At the PTG there was feedback from at least one team that
>> > consumers of the data in storyboard want a priority setting on
>> > each story. Historically the response to that has been that
>> > different users will have different priorities, so each of them
>> > using worklists is the best way to support those differences of
>> > opinion.
>> > 
>> > I think we need to reconsider that position if it's going to block
>> > adoption. I think Ben's case is an excellent second example of
>> > where having a field to hold some sort of priority value would be
>> > useful.
>
> I'm strongly against reverting to having a single global priority value
> for things in StoryBoard, especially so for stories as opposed to tasks.
> Having a single global priority field for stories at best implies that a
> cross-project story has the same priority in each project, and at worst
> means cross-project discussions need to occur to find an agreement on an
> acceptable priority (or one affected project's opinion overrules the
> others, with the others' priorities becoming harder to understand at a
> glance or just completely lost).

I would be fine with 1 field per task.

> For tasks I am less concerned in that aspect since cross-project support
> isn't hurt, but remain of the opinion that a global field is the wrong
> approach since it means that only one person (or group of people) gets to
> visibly express their opinion on the priority of the task.

While I agree that not everyone attaches the same priority to a given
task, and it's important for everyone to be able to have their own say
in the relative importance of tasks/stories, I think it's more important
than you're crediting for downstream consumers to have a consistent way
to understand the priority attached by the person(s) doing the
implementation work.

> Allowing multiple groups to express opinions on the priority of the same
> tasks allows situations where (to use a real world example I saw recently,
> but not in OpenStack) an upstream project marks a bug as medium priority
> for whatever reason, but a downstream user of that project is completely
> broken by that bug, meaning either providing a fix to it or persuading
> someone else to is of critical importance to them.

This example is excellent, and I think it supports my position.

An important area where using boards or worklists falls short of my own
needs is that, as far as I know, it is not possible to subscribe to
notifications for when a story or task is added to a list or board. So
as a person who submits a story, I have no way of knowing when the
team(s) working on it add it to (or remove it from) a priority list or
change its priority by moving it to a different lane in a board.
Communicating about what we're doing is as important as gathering and
tracking the list of tasks in the first place. Without a notification
that the priority of a story or task has been lowered, how would I know
that I need to go try to persuade the team responsible to raise it back
up?

Even if we add (or there is) some way for me to receive a notification
based on board or list membership, without a real priority field we have
several different ways to express priority (different tag names, a
single worklist that's kept in order, a board with separate columns for
each status, etc.). That means each team could potentially use a
different way, which in turn means downstream consumers have to
discover, understand, and subscribe to all of those various ways, and
use them correctly, for every team they are tracking. I think that's an
unreasonable burden to place on someone who is not working in the
community constantly, as is the case for many of our operators who
report bugs.

> With global priority there is a trade-off, either the bug tracker displays
> priorities with no reference as to who they are important to, downstream
> duplicate the issue elsewhere to track their priority, or their expression
> of how important the issue is is lost in a comment in order to maintain
> the state of "all priorities are determined by the core team".

I suppose that depends on the reason we're using the task tracker.

If we're just throwing data into it without trying to use it to
communicate, then I can see us having lots of different views of
priority with the same level of "official-ness". I don't think that's
what we're doing though. I think we're trying to help teams track what
they've committed to do and *communicate* those commitments to folks
outside of the team. And from that per

Re: [openstack-dev] [storyboard] Prioritization?

2018-09-24 Thread Doug Hellmann
Jeremy Stanley  writes:

> On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote:
> [...]
>> At the PTG there was feedback from at least one team that
>> consumers of the data in storyboard want a priority setting on
>> each story. Historically the response to that has been that
>> different users will have different priorities, so each of them
>> using worklists is the best way to support those differences of
>> opinion.
>> 
>> I think we need to reconsider that position if it's going to block
>> adoption. I think Ben's case is an excellent second example of
>> where having a field to hold some sort of priority value would be
>> useful.
>
> The alternative suggestion, for teams who want to be able to flag
> some sort of bucketed priorities, is to use story tags. We could
> even improve the import tool to accept some sort of
> priority-to-tag-name mapping so that, say, when we import bugs for
> Oslo their oslo-critical tag is applied to any with a critical
> bugtask, oslo-medium to any with medium priority tasks, and so on.
> Not all teams using StoryBoard will want to have a bucketed priority
> scheme, and those who do won't necessarily want to use the same
> number or kinds of priorities.

That came up as a suggestion, too. The challenge there is that we cannot
(as far as I know) sort on tags. So even if we have tags, we can't
create a list of stories that is ordered automatically based on the
priority. Maybe there's a solution to that?

Doug

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


Re: [openstack-dev] [storyboard] Prioritization?

2018-09-24 Thread Doug Hellmann
Ben Nemec  writes:

> Hi,
>
> This came up in the Oslo meeting as a result of my initial look at the 
> test Storyboard import. It appears all of the priority data from 
> launchpad gets lost in the migration, which is going to make organizing 
> hundreds of bugs somewhat difficult. I'm particularly not fond of it 
> after spending last cycle whittling down our untriaged bug list. :-)
>
> Work lists and tags were mentioned as possible priority management tools 
> in Storyboard, so is there some way to migrate launchpad priorities into 
> one of those automatically? If not, are there any plans to add that?
>
> It sounded like a similar conversation is happening with a few other 
> teams so we wanted to bring the discussion to the mailing list for 
> visibility.
>
> Thanks.
>
> -Ben

At the PTG there was feedback from at least one team that consumers of
the data in storyboard want a priority setting on each
story. Historically the response to that has been that different users
will have different priorities, so each of them using worklists is the
best way to support those differences of opinion.

I think we need to reconsider that position if it's going to block
adoption. I think Ben's case is an excellent second example of where
having a field to hold some sort of priority value would be useful.

Doug

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


Re: [openstack-dev] [release][ironic][tripleo][oslo][neutron] recovering from today's release failures

2018-09-24 Thread Doug Hellmann
Doug Hellmann  writes:

> Earlier today a bad version of twine (1.12.0) caused issues with many of
> the release jobs that were trying to publish artifacts to
> pypi.python.org. I didn't notice those failures until after all of the
> releases had been processed, unfortunately, which left us with quite a
> few broken releases to try to recover from.
>
> After working out the cause of the problem, and finding that in fact
> some, but not all, of the release artifacts were published, we started
> making a list of the manual recovery steps we would have to take. And
> that list was really really long.
>
> So, instead of doing all of that, we're going to re-tag the releases,
> using new version numbers, to produce good artifacts. I have prepared
> https://review.openstack.org/#/c/604875/ to do this.
>
> I will also run some tests to ensure the publishing works before
> approving those re-releases.
>
> Sorry for the inconvenience,
> Doug

We've had a few release requests come in since this email, so I want to
make sure everyone understands that we're going to wait to sort out the
issues we already have before releasing anything else. The test release
is waiting in the check queue still, so it's likely to be a while before
we know for sure that things are working.

Doug

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


[openstack-dev] [release][ironic][tripleo][oslo][neutron] recovering from today's release failures

2018-09-24 Thread Doug Hellmann
Earlier today a bad version of twine (1.12.0) caused issues with many of
the release jobs that were trying to publish artifacts to
pypi.python.org. I didn't notice those failures until after all of the
releases had been processed, unfortunately, which left us with quite a
few broken releases to try to recover from.

After working out the cause of the problem, and finding that in fact
some, but not all, of the release artifacts were published, we started
making a list of the manual recovery steps we would have to take. And
that list was really really long.

So, instead of doing all of that, we're going to re-tag the releases,
using new version numbers, to produce good artifacts. I have prepared
https://review.openstack.org/#/c/604875/ to do this.

I will also run some tests to ensure the publishing works before
approving those re-releases.

Sorry for the inconvenience,
Doug

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


Re: [openstack-dev] [Release-job-failures] Release of openstack/group-based-policy failed

2018-09-23 Thread Doug Hellmann
z...@openstack.org writes:

> Build failed.
>
> - release-openstack-python 
> http://logs.openstack.org/7a/7abbf9af380eb236908f4d41d56e4cb1a0c2f135/release/release-openstack-python/ac1d5ab/
>  : FAILURE in 8m 44s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
>
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

The release-openstack-python job keeps failing with an SSL module
error. It is currently running tox under python 2, and SSL support there
has been steadily getting worse over time. I suggest trying to fix the
release job by either updating the tox environment in the repo to use
python 3, or switching to the new publish-to-pypi-python3 template which
runs a job that uses python 3. See [1] for an example.

Doug

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

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


Re: [openstack-dev] [Openstack-sigs] Capturing Feedback/Input

2018-09-21 Thread Doug Hellmann
Melvin Hillsman  writes:

> On Fri, Sep 21, 2018 at 11:16 AM Doug Hellmann 
> wrote:
>
>> Maybe we're overthinking the organization on this. What is special about
>> the items that would be on this list compared to items opened directly
>> against projects?
>>
>
> Yeah unfortunately we do have a tendency to overthink/complicate things.
> Not saying Storyboard is the right tool but suggested rather than having
> something extra to maintain was what I understood. There are at least 3
> things that were to be addressed:
>
> - single pane so folks know where to provide/see updates
> - it is not a catchall/dumpsite
>   - something still needs to be flushed out/prioritized (Public Cloud WG's
> missing features spreadsheet for example)
> - not specific to a single project (i thought this was a given since there
> is already a process/workflow for single project)
>
> I could very well be wrong so I am open to be corrected. From my
> perspective the idea in the room was to not circumvent anything internal
> but rather make it easy for external viewers, passerbys, etc. When feedback
> is gathered from Ops Meetup, OpenStack Days, Local meetups/events, we
> discussed putting that here as well.

Those are all good points. Sorry for making you rehash stuff that was
already discussed.

So I guess the idea is to have a place where several groups can track
their own backlogs, but then a prioritized list can be created from
those separate backlogs?

In the Storyboard data model, that sounds like separate projects for
each SIG or WG, and then 1 worklist that they all manually update with
their priority items. I say "manually" because if we just combine all of
the backlogs we don't have any good way to order the items and select
the top N.

Doug

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


Re: [openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?

2018-09-21 Thread Doug Hellmann
Excerpts from Elõd Illés's message of 2018-09-21 16:08:28 +0200:
> Hi,
> 
> Here is an etherpad with the teams that have stable:follow-policy tag on 
> their repos:
> 
> https://etherpad.openstack.org/p/ocata-final-release-before-em
> 
> On the links you can find reports about the open and unreleased changes, 
> that could be a useful input for the before-EM/final release.
> Please have a look at the report (and review the open patches if there 
> are) so that a release can be made if necessary.
> 
> Thanks,
> 
> Előd

Thanks for pulling all of this information together!

Doug

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


[openstack-dev] [all][tc] please vote

2018-09-21 Thread Doug Hellmann
A few hours ago Emmet reported that we have around 20% participation
in the Technical Committee election, so far. I think we can do
better.

Our community is founded on the idea that the contributors should
decide how the project is run. PTL and TC elections are the most
explicit example of this principle in action. The people elected
to the TC this term will be representing your interests to the Board
as the Foundation continues to evolve and expand its scope with new
focus areas and projects. They also will continue to work on building and
sustaining the community, choosing and organizing series goals, and
making decisions that have long term effects on the project.

Please take a few minutes to look at Kendall's instructions[1],
find your ballot email, and think about which candidates you want
to have on the committee. Then cast your vote, today.

Doug

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134820.html

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


  1   2   3   4   5   6   7   8   9   10   >