[openstack-dev] [requirements][ffe] FFE for python-designateclient 2.10.0

[Graham Hayes]

Hi all,

I would like to ask for a FFE to release python-designateclient 2.10.0
[1]

We did not do a release at all during the rocky cycle, and this allows
us to create a stable/rocky branch

It just requires a U-C bump, and contains a few bug fixes from 2.9.0.

Thanks,

Graham

1 - https://review.openstack.org/590776



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

Re: [openstack-dev] [nova][searchlight][designate][telemetry][mistral][blazar][watcher][masakari]Possible deprecation of Nova's legacy notification interface

[Graham Hayes]

On 09/08/2018 15:27, Matt Riedemann wrote:
> On 8/9/2018 8:44 AM, Graham Hayes wrote:
>> Designate has no plans to swap or add support for the new interface in
>> the near or medium term - we are more than willing to take patches, but
>> we do not have the people power to do it ourselves.
>>
>> Some of our users do use the old interface a lot - designate-sink
>> is quite heavily embeded in some workflows.
> 
> This is what I suspected would be the answer from most projects.
> 
> I was very half-assedly wondering if we could write some kind of
> translation middleware library that allows your service to listen for
> versioned notifications and translate them to legacy notifications. Then
> we could apply that generically across projects that don't have time for
> a big re-write while allowing nova to drop the legacy compat code (after
> some period of deprecation, I was thinking at least a year).
> 
> It should be pretty simple to write a dumb versioned->unversioned
> payload mapping for each legacy notification, but there might be more
> sophisticated ways of doing that using some kind of schema or template
> instead. Just thinking out loud.
> 

I have no objection to that - and I wish we had the people to move to
the new formats - I know maintaining legacy features like this is
extra work no-one needs.

Thinking out loud 

You could just send the deprecation notice, and we could deprecate
designate-sink if no one came forward to update it - that seems fairer
to push the burden on to the people who actually use the feature, not
other teams maintaining legacy stuff. Does that seem overly harsh?

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

Re: [openstack-dev] [nova][searchlight][designate][telemetry][mistral][blazar][watcher][masakari]Possible deprecation of Nova's legacy notification interface

[Graham Hayes]

Designate has no plans to swap or add support for the new interface in
the near or medium term - we are more than willing to take patches, but
we do not have the people power to do it ourselves.

Some of our users do use the old interface a lot - designate-sink
is quite heavily embeded in some workflows.

Thanks,

- Graham

On 09/08/2018 10:41, Balázs Gibizer wrote:
> Dear Nova notification consumers!
> 
> 
> The Nova team made progress with the new versioned notification
> interface [1] and it is almost reached feature parity [2] with the
> legacy, unversioned one. So Nova team will discuss on the upcoming PTG
> the deprecation of the legacy interface. There is a list of projects (we
> know of) consuming the legacy interface and we would like to know if any
> of these projects plan to switch over to the new interface in the
> foreseeable future so we can make a well informed decision about the
> deprecation.
> 
> 
> * Searchlight [3] - it is in maintenance mode so I guess the answer is no
> * Designate [4]
> * Telemetry [5]
> * Mistral [6]
> * Blazar [7]
> * Watcher [8] - it seems Watcher uses both legacy and versioned nova
> notifications
> * Masakari - I'm not sure Masakari depends on nova notifications or not
> 
> Cheers,
> gibi
> 
> [1] https://docs.openstack.org/nova/latest/reference/notifications.html
> [2] http://burndown.peermore.com/nova-notification/
> 
> [3]
> https://github.com/openstack/searchlight/blob/master/searchlight/elasticsearch/plugins/nova/notification_handler.py
> 
> [4]
> https://github.com/openstack/designate/blob/master/designate/notification_handler/nova.py
> 
> [5]
> https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline/data/event_definitions.yaml#L2
> 
> [6]
> https://github.com/openstack/mistral/blob/master/etc/event_definitions.yml.sample#L2
> 
> [7]
> https://github.com/openstack/blazar/blob/5526ed1f9b74d23b5881a5f73b70776ba9732da4/doc/source/user/compute-host-monitor.rst
> 
> [8]
> https://github.com/openstack/watcher/blob/master/watcher/decision_engine/model/notification/nova.py#L335
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

[Graham Hayes]

On 01/08/2018 13:21, Andrey Kurilin wrote:
> 



> 
> The second link from google search gives an opensource client written in
> python https://github.com/raelgc/scudcloud . Also, there is something
> which is written in golang.
>  
> 
> complete lack of any console clients (ditto),
> 
> 
> Again, google gives several ones as first results -
> https://github.com/evanyeung/terminal-slack
> https://github.com/erroneousboat/slack-term
> 



Any unoffical slack client needs to use "Legacy Tokens"[1]

> You're reading this because you're looking for info on legacy
> custom integrations - an outdated way for teams to integrate with
> Slack. These integrations lack newer features and they will be
> deprecated and possibly removed in the future. *We do not recommend
> their use.*

Legacy tokens can go away (just like the XMPP and IRC gateway did) at
any point, and we will be back in the same situation.

1 - https://api.slack.com/custom-integrations/legacy-tokens



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

[openstack-dev] [designate][stable] Stable Core Team Updates

[Graham Hayes]

Hi Stable Team,

I would like to nominate 2 new stable core reviewers for Designate.

* Erik Olof Gunnar Andersson 
* Jens Harbott (frickler) 

Erik has been doing a lot of stable reviews recently, and Jens has shown
that he understands the policy in other reviews (and has stable rights
on other repositories (like DevStack) already).

Thanks,

Graham Hayes

1 -
https://review.openstack.org/#/q/(project:openstack/designate+OR+project:openstack/python-designateclient+OR+project:openstack/designate-specs+OR+project:openstack/designate-dashboard+OR+project:openstack/designate-tempest-plugin)+branch:%255Estable/.*+reviewedby:%22Erik+Olof+Gunnar+Andersson+%253Ceandersson%2540blizzard.com%253E%22

2 -
https://review.openstack.org/#/q/(project:openstack/designate+OR+project:openstack/python-designateclient+OR+project:openstack/designate-specs+OR+project:openstack/designate-dashboard+OR+project:openstack/designate-tempest-plugin)+branch:%255Estable/.*+reviewedby:%22Jens+Harbott+(frickler)+%253Cj.harbott%2540x-ion.de%253E%22



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

Re: [openstack-dev] [qa] [tempest] [patrole] Service client duplication between Tempest and Tempest plugins

[Graham Hayes]

On 23/07/2018 20:22, MONTEIRO, FELIPE C wrote:

Hi,

** Intention **

Intention is to expand Patrole testing to some service clients that 
already exist in some Tempest plugins, for core services only.


What exact projects does Patrole consider "core", and how are you making
that decision? Is it a tag, InterOp, or some other criteria?



__
OpenStack Development Mailing 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] [designate] Meeting tomorrow

[Graham Hayes]

Unfortunately something has come up and I have an appointment I have to
be at for our scheduled slot (11:00 UTC).

Can someone else chair, or we can post pone the meeting for 1 week.

Does anyone have any preferences?

Thanks,

- Graham

__
OpenStack Development Mailing 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] [designate] Meeting Times update

[Graham Hayes]

Hi All,

We had talked about moving to a bi-weekly meeting, with alternating
times, and I have updated the meetings repo [0] with some suggested
times.

Please speak up if these do not suit!

- Graham

0 - https://review.openstack.org/#/c/573204/



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

Re: [openstack-dev] [tc] StarlingX project status update

[Graham Hayes]

On 30/05/18 21:23, Mohammed Naser wrote:
> Hi everyone:
> 
> Over the past week in the summit, there was a lot of discussion
> regarding StarlingX
> and members of the technical commitee had a few productive discussions 
> regarding
> the best approach to deal with a proposed new pilot project for
> incubation in the OSF's Edge
> Computing strategic focus area: StarlingX.
> 
> If you're not aware, StarlingX includes forks of some OpenStack
> components and other open source software
> which contain certain features that are specific to edge and
> industrial IoT computing use cases.  The code
> behind the project is from Wind River (and is used to build a product
> called "Titanium
> Cloud").
> 
> At the moment, the goal of StarlingX hosting their projects on the
> community infrastructure
> is to get the developers used to the Gerrit workflow.  The intention
> is to evenutally
> work with upstream teams in order to bring the features and bug fixes which 
> are
> specific to the fork back upstream, with an ideal goal of bringing all
> the differences
> upstream.
> 
> We've discussed around all the different ways that we can approach
> this and how to
> help the StarlingX team be part of our community.  If we can
> succesfully do this, it would
> be a big success for our community as well as our community gaining
> contributors from
> the Wind River team.  In an ideal world, it's a win-win.
> 
> The plan at the moment is the following:
> - StarlingX will have the first import of code that is not forked,
> simply other software that
>   they've developed to help deliver their product.  This code can be
> hosted with no problems.
> - StarlingX will generate a list of patches to be brought upstream and
> the StarlingX team
>   will work together with upstream teams in order to start backporting
> and upstreaming the
>   codebase.  Emilien Macchi (EmilienM) and I have volunteered to take
> on the responsibility of
>   monitoring the progress upstreaming these patches.
> - StarlingX contains a few forks of other non-OpenStack software. The
> StarlingX team will work
>   with the authors of the original projects to ensure that they do not
> mind us hosting a fork
>   of their software.  If they don't, we'll proceed to host those
> projects. If they prefer
>   something else (hosting it themselves, placing it on another hosting
> service, etc.),
>   the StarlingX team will work with them in that way.
> 
> We discussed approaches for cases where patches aren't acceptable
> upstream, because they
> diverge from the project mission or aren't comprehensive. Ideally all
> of those could be turned
> into acceptable changes that meet both team's criteria. In some cases,
> adding plugin interfaces
> or driver interfaces may be the best alternative. Only as a last
> resort would we retain the
> forks for a long period of time.

I honestly think that these forks should never be inside the foundation.
If there is a big enough disagreement between project teams and the
fork, we (as the TC of the OpenStack project) and the board (of
*OpenStack* Foundation) should support our current teams, who have
been working in the open.

There is plenty of companies who would have loved certain features in
OpenStack over the years that an extra driver extension point would
have enabled, but when the upstream team pushed back, they redesigned
the feature to work with the community vision. We should not reward
companies that didn't.

> From what was brought up, the team from Wind River is hoping to
> on-board roughly 50 new full
> time contributors.  In combination with the features that they've
> built that we can hopefully
> upstream, I am hopeful that we can come to a win-win situation for
> everyone in this.
> 
> Regards,
> Mohammed
> 
> __
> OpenStack Development Mailing 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] summary of joint leadership meeting from 20 May

[Graham Hayes]

On 05/06/18 16:22, Jay S Bryant wrote:
> 
> 
> On 6/5/2018 7:31 AM, Sean McGinnis wrote:
>> On Tue, Jun 05, 2018 at 11:21:16AM +0200, Thierry Carrez wrote:
>>> Jay Pipes wrote:
 On 06/04/2018 05:02 PM, Doug Hellmann wrote:
> [...]>
 Personally, I've very much enjoyed the separate PTGs because I've
 actually
 been able to get work done at them; something that was much harder
 when the
 design summits were part of the overall conference.
>>> Right, the trick is to try to preserve that productivity while making it
>>> easier to travel to... One way would be to make sure the PTG remains a
>>> separate event (separate days, separate venues, separate registration),
>>> just co-located in same city and week.
>>>
 [...]
> There are a few plans under consideration, and no firm decisions
> have been made, yet. We discussed a strawman proposal to combine
> the summit and PTG in April, in Denver, that would look much like
> our older Summit events (from the Folsom/Grizzly time frame) with
> a few days of conference and a few days of design summit, with some
> overlap in the middle of the week.  The dates, overlap, and
> arrangements will depend on venue availability.
 Has the option of doing a single conference a year been addressed?
 Seems
 to me that we (the collective we) could save a lot of money not having
 to put on multiple giant events per year and instead have one.
>>> Yes, the same strawman proposal included the idea of leveraging an
>>> existing international "OpenStack Day" event and raising its profile
>>> rather than organizing a full second summit every year. The second PTG
>>> of the year could then be kept as a separate event, or put next to that
>>> "upgraded" OpenStack Day.
>>>
>> I actually really like this idea. As things slow down, there just
>> aren't enough
>> of big splashy new things to announce every 6 months. I think it could
>> work
>> well to have one Summit a year, while using the OSD events as a way to
>> reach
>> those folks that can't make it to the one big event for the year due
>> to timing
>> or location.
>>
>> It could help concentrate efforts to have bigger goals ready by the
>> Summit and
>> keep things on a better cadence. And if we can still do a PTG-like
>> event along
>> side one of the OSD events, it would allow development to still get the
>> valuable face-to-face time that we've come to expect.
> I think going to one large summit event a year could be good with a
> co-located PTG type event.  I think, however, that we would still need
> to have a Separate PTG type event at some other point in the year.  I
> think it is going to be hard to keep development momentum going in the
> projects without a couple of face-to-face meetings a year.
> 

I personally think a single summit (with a PTG / Ops Mid Cycle before or
after) + a separate PTG / Ops Mid Cycle would be the best solution.

We don't need to rotate locations - while my airmiles balance has really
appreciated places like Tokyo / Sydney - we can just reuse locations.

For example saying that the week of May 20 something every year in
Vancouver[1] (or $NORTH_AMERICAN_CITY) is the OpenStack Summit + Kata +
OpenDev + Edge conference massively reduces planning / scouting.

Then having the PTG (or OpenStack Foundation Developer & Ops Team
Gathering to make any new groups feel as welcomed, and not "tacked on")
in Denver + $NON_NORTH_AMERICAN_CITY[2] (again, as static locations to
reduce planning / scouting) seems like a good idea.

1 - But lets just say Vancouver please :)

2 - not sure if this is actually a good idea, but I don't the same
visa problems that some of our contributors do, or have knowledge
of how tax write off work so if I am wrong please tell me.

>>> Thinking on this is still very much work in progress.
>>>
>>> -- 
>>> Thierry Carrez (ttx)
>>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Graham Hayes]

On 15/05/18 17:33, Tim Bell wrote:
> From my memory, the LCOO was started in 2015 or 2016. The UC was started at 
> the end of 2012, start of 2013 (https://www.openstack.org/blog/?p=3777) with 
> Ryan, JC and I.
> 
> Tim

Yeap - I miss read what mrhillsman said [0].

The point still stands - I think this does need to be discussed, and the
outcome published to the list.

Any additional background on why we allowed LCOO to operate like this
would help a lot.

- Graham

0 -
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T15:03:54

> -Original Message-----
> From: Graham Hayes <g...@ham.ie>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Date: Tuesday, 15 May 2018 at 18:22
> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [tc] [all] TC Report 18-20
> 
> ..
> 
> > # LCOO
> > 
> > There's been some concern expressed about the The Large Contributing
> > OpenStack Operators (LCOO) group and the way they operate. They use
> > an [Atlassian Wiki](https://openstack-lcoo.atlassian.net/) and
> > Slack, and have restricted membership. These things tend to not
> > align with the norms for tool usage and collaboration in OpenStack.
> > This topic came up in [late
> > 
> April](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T14:39:36)
> > 
> > but is worth revisiting in Vancouver.
> 
> From what I understand, this group came into being before the UC was
> created - a joint UC/TC/LCOO sync up in Vancouver is probably a good
> idea.
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



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

Re: [openstack-dev] [tc] [all] TC Report 18-20

[Graham Hayes]

On 15/05/18 16:31, Chris Dent wrote:
> 
> HTML: https://anticdent.org/tc-report-18-20.html
> 
> Trying to write a TC report after a gap of 3 weeks is hard enough,
> but when that gap involves some time off, the TC elections, and the
> run up to summit (next week in
> [Vancouver](https://www.openstack.org/summit/vancouver-2018/)) then
> it gets bewildering. Rather than trying to give anything like a full
> summary, I'll go for some highlights.
> 
> Be aware that since next week is summit and I'll be travelling the
> week after, there will be another gap in reports.
> 
> # Elections
> 
> The elections were for seven positions. Of those, three are new to
> the TC: Graham Hayes, Mohammed Naser, Zane Bitter. Having new people
> is _great_. There's a growing sense that the TC needs to take a more
> active role in helping adapt the culture of OpenStack to its
> changing place in the world (see some of the comments below). Having
> new people helps with that greatly.
> 
> Doug Hellman has become the chair of the TC, taking the seat long
> held by Thierry. This is the first time (that I'm aware of) that a
> non-Foundation-staff individual has been the chair.
> 
> One of the most interesting parts of the election process were the
> email threads started by Doug. There's hope that existing TC
> members that were not elected in this cycle, those that have
> departed, and anyone else will provide their answers to them too. An
> [email
> reminder](http://lists.openstack.org/pipermail/openstack-dev/2018-May/130382.html)
> 
> exists.
> 
> # Summit
> 
> Is next week, in Vancouver. The TC has several
> [Forum](https://wiki.openstack.org/wiki/Forum/Vancouver2018)
> sessions planned including:
> 
> * [S release
>   goals](https://etherpad.openstack.org/p/YVR-S-release-goals)
> * [Project boundaries and what is
>  
> OpenStack](https://etherpad.openstack.org/p/YVR-forum-TC-project-boundaries)
> 
> * [TC
>   Retrospective](https://etherpad.openstack.org/p/YVR-tc-retrospective)
> * [Cross Community
>  
> Governance](https://etherpad.openstack.org/p/YVR-cross-osf-tech-governance)
> 
> # Corporate Foundation Contributions
> 
> There's ongoing discussion about how [to
> measure](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-24.log.html#t2018-04-24T15:43:59)
> 
> upstream contribution from corporate Foundation members and what to
> do if contribution seems lacking. Part of the reason this came up
> was because the mode of contribution from new platinum member,
> Tencent, is not clear. For a platinum member, it should be
> _obvious_.

This is a very important point. By adding a company (especially at this
level) we grant them a certain amount of our credibility. We need to
be sure that this is earned by the new member.

> # LCOO
> 
> There's been some concern expressed about the The Large Contributing
> OpenStack Operators (LCOO) group and the way they operate. They use
> an [Atlassian Wiki](https://openstack-lcoo.atlassian.net/) and
> Slack, and have restricted membership. These things tend to not
> align with the norms for tool usage and collaboration in OpenStack.
> This topic came up in [late
> April](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T14:39:36)
> 
> but is worth revisiting in Vancouver.

From what I understand, this group came into being before the UC was
created - a joint UC/TC/LCOO sync up in Vancouver is probably a good
idea.

> # Constellations
> 
> One of the things that came out in election campaigning is that
> OpenStack needs to be more clear about the many ways that OpenStack
> can be used, in part as a way of being more clear about what
> OpenStack _is_. Constellations are one way to do this and work has
> begun on one for [Scientific
> Computing](https://review.openstack.org/#/c/565466/). There's some
> discussion there on what a constellation is supposed to accomplish.
> If you have an opinion, you should comment.
> 
> # Board Meeting
> 
> The day before summit there is a "combined leadership" meeting with
> the Foundation Board, the User Committee and the Technical
> Committee. Doug has posted a [review of the
> agenda](http://lists.openstack.org/pipermail/openstack-dev/2018-May/130336.html).
> 
> These meetings are open to any Foundation members and often involve
> a lot of insight into the future of OpenStack. And snacks.
> 
> # Feedback, Leadership and Dictatorship of the Projects
> 
> Zane started [an email
> thread](http://lists.openstack.org/pipermail/openstack-dev/2018-May/130375.html)
> 
> about ways to replace or augment the once large and positive
> feedback loop that was present in earlier days 

Re: [openstack-dev] [all][tc][ptls] final stages of python 3 transition

[Graham Hayes]

On 08/05/18 16:53, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-05-08 16:28:46 +0100:
>> On 08/05/18 16:09, Zane Bitter wrote:
>>> On 30/04/18 17:16, Ben Nemec wrote:
> Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:
>> 1. Fix oslo.service functional tests -- the Oslo team needs help
>>     maintaining this library. Alternatively, we could move all
>>     services to use cotyledon (https://pypi.org/project/cotyledon/).
>>>
>>> I submitted a patch that fixes the py35 gate (which was broken due to
>>> changes between CPython 3.4 and 3.5), so once that merges we can flip
>>> the gate back to voting:
>>>
>>> https://review.openstack.org/566714
>>>
 For everyone's awareness, we discussed this in the Oslo meeting today
 and our first step is to see how many, if any, services are actually
 relying on the oslo.service functionality that doesn't work in Python
 3 today.  From there we will come up with a plan for how to move forward.

 https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.
>>>
>>> These tests are currently skipped in both oslo_service and nova.
>>> (Equivalent tests were removed from Neutron and Manila on the principle
>>> that they're now oslo_service's responsibility.)
>>>
>>> This appears to be a series of long-standing bugs in eventlet:
>>>
>>> Python 3.5 failure mode:
>>> https://github.com/eventlet/eventlet/issues/308
>>> https://github.com/eventlet/eventlet/issues/189
>>>
>>> Python 3.4 failure mode:
>>> https://github.com/eventlet/eventlet/issues/476
>>> https://github.com/eventlet/eventlet/issues/145
>>>
>>> There are also more problems coming down the pipeline in Python 3.6:
>>>
>>> https://github.com/eventlet/eventlet/issues/371
>>>
>>> That one is resolved in eventlet 0.21, but we have that blocked by
>>> upper-constraints:
>>> http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt#n135
>>>
>>>
>>> Given that the code in question relates solely to standalone WSGI
>>> servers with SSL and everything should have already migrated to Apache,
>>> and that the upstream is clearly overworked and unlikely to merge fixes
>>> any time soon (plus we would have to deal with the fallout of moving the
>>> upper constraint), I agree that it would be preferable if we could just
>>> ditch this functionality.
>>
>> There are a few projects that have not migrated, and some that have
>> issues running in non standalone WSGI mode (due, ironically to eventlet)
>>
>> We should probably get people to run these projects behind an reverse
>> proxy, and terminate SSL there, but right now we don't have that
>> documented.
> 
> Do you know which projects?

I know of 2:

Designate - mainly due to the major lack of resources available during
the uwsgi goal period, and the level of work needed to unravel our
tooling to support it.

Glance - Has issues with image upload + uwsgi + eventlet [1]

I am sure there are probably others, but I know of these 2.

[1] https://docs.openstack.org/releasenotes/glance/unreleased.html#b1

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



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

Re: [openstack-dev] [all][tc][ptls] final stages of python 3 transition

[Graham Hayes]

On 08/05/18 16:09, Zane Bitter wrote:
> On 30/04/18 17:16, Ben Nemec wrote:
>>> Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:
 1. Fix oslo.service functional tests -- the Oslo team needs help
     maintaining this library. Alternatively, we could move all
     services to use cotyledon (https://pypi.org/project/cotyledon/).
> 
> I submitted a patch that fixes the py35 gate (which was broken due to
> changes between CPython 3.4 and 3.5), so once that merges we can flip
> the gate back to voting:
> 
> https://review.openstack.org/566714
> 
>> For everyone's awareness, we discussed this in the Oslo meeting today
>> and our first step is to see how many, if any, services are actually
>> relying on the oslo.service functionality that doesn't work in Python
>> 3 today.  From there we will come up with a plan for how to move forward.
>>
>> https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.
> 
> These tests are currently skipped in both oslo_service and nova.
> (Equivalent tests were removed from Neutron and Manila on the principle
> that they're now oslo_service's responsibility.)
> 
> This appears to be a series of long-standing bugs in eventlet:
> 
> Python 3.5 failure mode:
> https://github.com/eventlet/eventlet/issues/308
> https://github.com/eventlet/eventlet/issues/189
> 
> Python 3.4 failure mode:
> https://github.com/eventlet/eventlet/issues/476
> https://github.com/eventlet/eventlet/issues/145
> 
> There are also more problems coming down the pipeline in Python 3.6:
> 
> https://github.com/eventlet/eventlet/issues/371
> 
> That one is resolved in eventlet 0.21, but we have that blocked by
> upper-constraints:
> http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt#n135
> 
> 
> Given that the code in question relates solely to standalone WSGI
> servers with SSL and everything should have already migrated to Apache,
> and that the upstream is clearly overworked and unlikely to merge fixes
> any time soon (plus we would have to deal with the fallout of moving the
> upper constraint), I agree that it would be preferable if we could just
> ditch this functionality.

There are a few projects that have not migrated, and some that have
issues running in non standalone WSGI mode (due, ironically to eventlet)

We should probably get people to run these projects behind an reverse
proxy, and terminate SSL there, but right now we don't have that
documented.

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



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

Re: [openstack-dev] [tc][docs] documenting openstack "constellations"

[Graham Hayes]

On 02/05/18 20:11, Doug Hellmann wrote:
> Excerpts from Zane Bitter's message of 2018-05-02 11:38:55 -0400:
>> On 01/05/18 16:21, Doug Hellmann wrote:
>>> Excerpts from Andreas Jaeger's message of 2018-05-01 21:51:19 +0200:
 On 05/01/2018 04:08 PM, Doug Hellmann wrote:
> The TC has had an item on our backlog for a while (a year?) to
> document "constellations" of OpenStack components to make it easier
> for deployers and users to understand which parts they need to have
> the features they want [1].
>
> John Garbutt has started writing the first such document [2], but
> as we talked about the content we agreed the TC governance repository
> is not the best home for it, so I have proposed creating a new
> repository [3].
>
> In order to set up the publishing jobs for that repo so the content
> goes to docs.openstack.org, we need to settle the ownership of the
> repository.
>
> I think it makes sense for the documentation team to "own" it, but
> I also think it makes sense for it to have its own review team
> because it's a bit different from the rest of the docs and we may
> be able to recruit folks to help who might not want to commit to
> being core reviewers for all of the documentation repositories. The
> TC members would also like to be reviewers, to get things going.
>
> So, is the documentation team willing to add the new "constellations"
> repository under their umbrella? Or should we keep it as a TC-owned
> repository for now?

 I'm fine having it as parts of the docs team. The docs PTL should be
 part of the review team for sure,

 Andreas
>>>
>>> Yeah, I wasn't really clear there: I intend to set up the documentation
>>> and TC teams as members of the new team, so that all members of both
>>> groups can be reviewers of the new repository.
>>
>> +1. What would be the reviewer criteria? Majority vote for adding new 
>> constellations and 2x +2 for changes maybe? Or just 2x +2 for 
>> everything? Just to clarify, since the TC reviews usually operate pretty 
>> differently to other code reviews.
>>
>> thanks,
>> ZB
>>
> 
> This is just documentation, so 2x +2 is what I had in mind.
> 
> Doug
> 

Is it just docs though? I thought the the point of constellations
was for a curated set of projects per use case?



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

Re: [openstack-dev] [designate] Meeting Times - change to office hours?

[Graham Hayes]

On 24/04/18 16:55, Ben Nemec wrote:
> I prefer 14:00 to 22:00 UTC, although depending on the time of year I
> may have some flexibility on that.
> 
> On 04/24/2018 01:37 AM, Erik Olof Gunnar Andersson wrote:
>> I can do anytime ranging from 16:00 UTC to 03:00 UTC, Mon-Fri, maybe
>> up to 07:00 UTC assuming that it's once bi-weekly.
>>
>> 
>> *From:* Jens Harbott <j.harb...@x-ion.de>
>> *Sent:* Monday, April 23, 2018 10:49:25 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [designate] Meeting Times - change to
>> office hours?
>> 2018-04-23 13:11 GMT+02:00 Graham Hayes <g...@ham.ie>:
>>> Hi All,
>>>
>>> We moved our meeting time to 14:00UTC on Wednesdays, but attendance
>>> has been low, and it is also the middle of the night for one of our
>>> cores.
>>>
>>> I would like to suggest we have an office hours style meeting, with
>>> one in the UTC evening and one in the UTC morning.
>>>
>>> If this seems reasonable - when and what frequency should we do
>>> them? What times suit the current set of contributors?
>>
>> My preferred range would be 06:00UTC-14:00UTC, Mon-Thu, though
>> extending a couple of hours in either direction might be possible for
>> me, too.
>>
>> If we do alternating times, with the current amount of work happening
>> we maybe could make each of them monthly, so we end up with a roughly
>> bi-weekly schedule.
>>
>> I also have a slight preference for continuing to use one of the
>> meeting channels as opposed to meeting in the designate channel, if
>> that is what "office hours style meeting" is meant to imply.
>>

I think a bi-weekly meeting, alternating between UTC morning and evening
is a good idea.

I do like the meeting channels, so I think we should keep them.

Thanks,

Graham



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

Re: [openstack-dev] [tc] campaign question: How "active" should the TC be?

[Graham Hayes]

On 23/04/18 14:27, Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
> 
> We frequently have discussions about whether the TC is active enough,
> in terms of driving new policies, technology choices, and other
> issues that affect the entire community.
> 
> Please describe one case where we were either active or reactive
> and how that was shown to be the right choice over time.

I think the best example of the TC being proactive and it being the
right choice is the Visioning document and exercise.

> Please describe another case where the choice to be active or
> reactive ended up being the wrong choice.

The InterOp testing and Tempest situation is the most vivid in my mind
(after being in the centre of it for months). Members of the TC were
proactive, but the TC as a whole was passive on it.

The TC reacted 3 or 4 days after the board had approved the program -
when we should have had an answer months before.

> If you think the TC should tend to be more active in driving change
> than it is today, please describe the changes (policy, culture,
> etc.) you think would need to be made to do that effectively (not
> which policies you want us to be more active on, but *how* to
> organize the TC to be more active and have that work within the
> community culture).

I do think the TC should be more active in driving OpenStack forward.
I think the TC has a role in listening to the developers who are driving
the projects forward, and connecting them with other project developers
where appropriate, while also co-ordinating with the User Committee, to
see where commonalities are, and then using its voice to drive change
in the foundation, and member companies (via the Board, foundation staff
and other potentially more informal avenues).

But for that, the TC will need to find a collective voice, that is
pro-active, as trying to drive a project in the manner above cannot
be reactive - by the time we develop a position that we are reacting
with it, it will be too late.

I think introducing more formal in-person blocks of time as a group is
important, with a time blocked agenda, and enforced chairing could help
us do that.

I know it is not a popular opinion, but a 1/2 day every 6 months where
all TC members can be available and attend the meeting can really help
a group find a mutual voice.

> If you think the TC should tend to be less active in driving change
> overall, please describe what policies you think the TC should be
> taking an active role in implementing.
> 
> 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
> 



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

Re: [openstack-dev] [tc] campaign question related to new projects

[Graham Hayes]

On 23/04/18 18:14, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-04-23 17:23:20 +0100:
>> On 23/04/18 17:14, Doug Hellmann wrote:
>>> Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100:
 On 23/04/18 16:04, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
>> 7On 20/04/18 22:26, Doug Hellmann wrote:
>> 
>>> Without letting the conversation devolve too much into a discussion
>>> of Adjutant's case, please talk a little about how you would evaluate
>>> a project's application in general.  What sorts of things do you
>>> consider when deciding whether a project "aligns with the OpenStack
>>> Mission," for example?
>>>
>>> Doug
>>>
>>
>> For me, the most important thing for a project that wants to join is
>> that they act like "one of us" - what I think ttx refered to as "culture
>> fit".
>>
>> This is fairly wide ranging, but includes things like:
>>
>> * Do they use the PTIs[0]
>> * Do they use gerrit, or if they use something else, do they follow
>>   the same review styles and mechanisms?
>> * Are they on IRC?
>> * Do they use the mailing list for long running discussion?
>>   ** If a project doesn't have long running discussions and as a result
>>  does not have ML activity, I would see that as OK - my problem
>>  would be with a team that ran their own list.
>> * Do they use standard devstack / -infra jobs for testing?
>> * Do they use the standard common libraries (where appropriate)?
>>
>> If a project fails this test (and would have been accepted as something
>> that drives the mission), I see no issue with the TC trying to bring
>> them into the fold by helping them work like one of us, and accepting
>> them when they have shown that they are willing to change how they
>> do things.
>>
>> For the "product" fit, it is a lot more subjective. We used to have a
>> system (pre Big Tent) where the TC picked "winners" in a space and
>> blessed one project as the way to do $thing. Then, in big tent we
>> started to not pick winners, and allow anyone who was one of us, and
>> had a "cloud" application.
>>
>> Recently, we have moved back to seeing if a project overlaps with
>> another. The real test for this (from my viewpoint) is if the
>> perceived overlap is an area that the team that is currently in
>> OpenStack is interested in pursuing - if not we should default to
>> adding the project.
>
> We've always considered overlap to some degree, but it has come up
> more explicitly in a few recent discussions because of the nature
> of the projects.  Please see the other thread on this topic [1].
>
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
>
>> Personally, if the project adds something that we currently lack,
>> and have lacked for a long time (not to get too close to the current
>> discussion), or tries to reduce the amount of extra tooling that
>> deployers currently write in house, we should welcome them.
>>
>> The acid test for me is "How would I use this?" or "Have I written
>> tooling or worked somewhere that wrote tooling to do this?"
>>
>> If the answer is yes, it is a good indication that they fit with the
>> mission.
>
> This feels like the ideal open source approach, in which contributors
> are "scratching their own itch." How can we encourage more deployers
> and users of OpenStack to consider contributing their customization
> and integration projects? Should we?

 I think a lot of our major users are good citizens and are doing some or
 all of this work in the open - we just have a discoverability issue.

 A lot of the benefit of joining the foundation as a project, is the
 increased visibility gained from it, so that others who are deploying
 OpenStack in a similar layout can find a project and use it.

 I think at the very least we should find a way to promote them (this
 is where constellations could really help, as we could add non member
 projects to constellations where they are appropriate.
>>>
>>> Do you foresee any issues with adding unofficial projects to the
>>> constellations?
>>>
>>> Doug
>>
>> No (from my viewpoint anyway) - I think they will be important to
>> include in any true collection of use cases - for example we definitely
>> will want to have a "PaaS" Constellation that includes things like
>> Kubernetes, Cloud Foundry and / or OpenShift. We need to show how
>> OpenStack works in the entire open source infrastructure community
>> and not just how it works internally - and showing how you can use other
>> open source software components *with* OpenStack is vital for that.
> 
> Would you make a distinction between things that have 

Re: [openstack-dev] [tc] campaign question related to new projects

[Graham Hayes]

On 23/04/18 17:14, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100:
>> On 23/04/18 16:04, Doug Hellmann wrote:
>>> Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
 7On 20/04/18 22:26, Doug Hellmann wrote:
 
> Without letting the conversation devolve too much into a discussion
> of Adjutant's case, please talk a little about how you would evaluate
> a project's application in general.  What sorts of things do you
> consider when deciding whether a project "aligns with the OpenStack
> Mission," for example?
>
> Doug
>

 For me, the most important thing for a project that wants to join is
 that they act like "one of us" - what I think ttx refered to as "culture
 fit".

 This is fairly wide ranging, but includes things like:

 * Do they use the PTIs[0]
 * Do they use gerrit, or if they use something else, do they follow
   the same review styles and mechanisms?
 * Are they on IRC?
 * Do they use the mailing list for long running discussion?
   ** If a project doesn't have long running discussions and as a result
  does not have ML activity, I would see that as OK - my problem
  would be with a team that ran their own list.
 * Do they use standard devstack / -infra jobs for testing?
 * Do they use the standard common libraries (where appropriate)?

 If a project fails this test (and would have been accepted as something
 that drives the mission), I see no issue with the TC trying to bring
 them into the fold by helping them work like one of us, and accepting
 them when they have shown that they are willing to change how they
 do things.

 For the "product" fit, it is a lot more subjective. We used to have a
 system (pre Big Tent) where the TC picked "winners" in a space and
 blessed one project as the way to do $thing. Then, in big tent we
 started to not pick winners, and allow anyone who was one of us, and
 had a "cloud" application.

 Recently, we have moved back to seeing if a project overlaps with
 another. The real test for this (from my viewpoint) is if the
 perceived overlap is an area that the team that is currently in
 OpenStack is interested in pursuing - if not we should default to
 adding the project.
>>>
>>> We've always considered overlap to some degree, but it has come up
>>> more explicitly in a few recent discussions because of the nature
>>> of the projects.  Please see the other thread on this topic [1].
>>>
>>> [1] 
>>> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
>>>
 Personally, if the project adds something that we currently lack,
 and have lacked for a long time (not to get too close to the current
 discussion), or tries to reduce the amount of extra tooling that
 deployers currently write in house, we should welcome them.

 The acid test for me is "How would I use this?" or "Have I written
 tooling or worked somewhere that wrote tooling to do this?"

 If the answer is yes, it is a good indication that they fit with the
 mission.
>>>
>>> This feels like the ideal open source approach, in which contributors
>>> are "scratching their own itch." How can we encourage more deployers
>>> and users of OpenStack to consider contributing their customization
>>> and integration projects? Should we?
>>
>> I think a lot of our major users are good citizens and are doing some or
>> all of this work in the open - we just have a discoverability issue.
>>
>> A lot of the benefit of joining the foundation as a project, is the
>> increased visibility gained from it, so that others who are deploying
>> OpenStack in a similar layout can find a project and use it.
>>
>> I think at the very least we should find a way to promote them (this
>> is where constellations could really help, as we could add non member
>> projects to constellations where they are appropriate.
> 
> Do you foresee any issues with adding unofficial projects to the
> constellations?
> 
> Doug

No (from my viewpoint anyway) - I think they will be important to
include in any true collection of use cases - for example we definitely
will want to have a "PaaS" Constellation that includes things like
Kubernetes, Cloud Foundry and / or OpenShift. We need to show how
OpenStack works in the entire open source infrastructure community
and not just how it works internally - and showing how you can use other
open source software components *with* OpenStack is vital for that.

- Graham

>>
>>> Doug
>>>

 - Graham

 0 -
 https://governance.openstack.org/tc/reference/project-testing-interface.html
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [tc] campaign question: How should we handle projects with overlapping feature sets?

[Graham Hayes]

On 23/04/18 14:50, Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
> 
> In the course of evaluating new projects that have asked to join
> as official members of the OpenStack community, we often discuss
> whether the feature set of the project overlaps too much with other
> existing projects. This came up within the last year during Glare's
> application, and more recently as part of the Adjutant application.
> 
> Our current policy regarding Open Development is that a project
> should cooperate with existing projects "rather than gratuitously
> competing or reinventing the wheel." [1] The flexibility provided
> by the use of the term "gratuitously" has allowed us to support
> multiple solutions in the deployment and telemetry problem spaces.
> At the same time it has left us with questions about how (and
> whether) the community would be able to replace the implementation
> of any given component with a new set of technologies by "starting
> from scratch".
> 
> Where do you draw the line at "gratuitous"?

Does the project basically promise "$OTHER_PROJECT but better"?
For example, for me, if a project re-created another projects API - I
would call that gratuitous.

> What benefits and drawbacks do you see in supporting multiple tools
> with similar features?

It depends on the context - for example with deployment tooling,
companies may have pre existing DC orchestration tools, and having
and OpenStack deployment tool in $CONFIGMGMT can help people run
quicker.

Having 2 image stores, not so much, as there is then confusion about
what tool to deploy, or deploy both, and any issues may need to have 2
different solutions, or at least 2 patches.

There may be circumstances where 2 tools make sense (e.g. Messaging as a
Service did have 2 projects, but they served 2 different use cases, so
it made sense)

> How would our community be different, in positive and negative ways,
> if we were more strict about avoiding such overlap?

For deployment tooling - having the one true way to deploy OpenStack
would have made a lot of the work I have done in the last 4 or 5 years
redundant :) - We would probably be using bash scripts, but not having
people re-create the flow of installing OpenStack in $CFGMGMT_TOOL
de-jour in OpenStack may have focused resource. Or just forced
deployment teams out of OpenStack to somewhere else.

OS packing is definitely a good thing for duplication.

I don't think we have many service project areas that we have
duplication that would not have failed some of the stricter "culture
fit" discussions we have now had in the post Big Tent OpenStack.

We would have probably blocked things like Octavia (as Neutron LBaaS
existed), Designate (as Nova DNS was a thing back then), Monasca,
Neutron itself (as Nova Network was a thing).

> Doug
> 
> [1] 
> https://governance.openstack.org/tc/reference/new-projects-requirements.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
> 



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

Re: [openstack-dev] [tc] campaign question related to new projects

[Graham Hayes]

On 23/04/18 16:04, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
>> 7On 20/04/18 22:26, Doug Hellmann wrote:
>> 
>>> Without letting the conversation devolve too much into a discussion
>>> of Adjutant's case, please talk a little about how you would evaluate
>>> a project's application in general.  What sorts of things do you
>>> consider when deciding whether a project "aligns with the OpenStack
>>> Mission," for example?
>>>
>>> Doug
>>>
>>
>> For me, the most important thing for a project that wants to join is
>> that they act like "one of us" - what I think ttx refered to as "culture
>> fit".
>>
>> This is fairly wide ranging, but includes things like:
>>
>> * Do they use the PTIs[0]
>> * Do they use gerrit, or if they use something else, do they follow
>>   the same review styles and mechanisms?
>> * Are they on IRC?
>> * Do they use the mailing list for long running discussion?
>>   ** If a project doesn't have long running discussions and as a result
>>  does not have ML activity, I would see that as OK - my problem
>>  would be with a team that ran their own list.
>> * Do they use standard devstack / -infra jobs for testing?
>> * Do they use the standard common libraries (where appropriate)?
>>
>> If a project fails this test (and would have been accepted as something
>> that drives the mission), I see no issue with the TC trying to bring
>> them into the fold by helping them work like one of us, and accepting
>> them when they have shown that they are willing to change how they
>> do things.
>>
>> For the "product" fit, it is a lot more subjective. We used to have a
>> system (pre Big Tent) where the TC picked "winners" in a space and
>> blessed one project as the way to do $thing. Then, in big tent we
>> started to not pick winners, and allow anyone who was one of us, and
>> had a "cloud" application.
>>
>> Recently, we have moved back to seeing if a project overlaps with
>> another. The real test for this (from my viewpoint) is if the
>> perceived overlap is an area that the team that is currently in
>> OpenStack is interested in pursuing - if not we should default to
>> adding the project.
> 
> We've always considered overlap to some degree, but it has come up
> more explicitly in a few recent discussions because of the nature
> of the projects.  Please see the other thread on this topic [1].
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
> 
>> Personally, if the project adds something that we currently lack,
>> and have lacked for a long time (not to get too close to the current
>> discussion), or tries to reduce the amount of extra tooling that
>> deployers currently write in house, we should welcome them.
>>
>> The acid test for me is "How would I use this?" or "Have I written
>> tooling or worked somewhere that wrote tooling to do this?"
>>
>> If the answer is yes, it is a good indication that they fit with the
>> mission.
> 
> This feels like the ideal open source approach, in which contributors
> are "scratching their own itch." How can we encourage more deployers
> and users of OpenStack to consider contributing their customization
> and integration projects? Should we?

I think a lot of our major users are good citizens and are doing some or
all of this work in the open - we just have a discoverability issue.

A lot of the benefit of joining the foundation as a project, is the
increased visibility gained from it, so that others who are deploying
OpenStack in a similar layout can find a project and use it.

I think at the very least we should find a way to promote them (this
is where constellations could really help, as we could add non member
projects to constellations where they are appropriate.

> Doug
> 
>>
>> - Graham
>>
>> 0 -
>> https://governance.openstack.org/tc/reference/project-testing-interface.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
> 



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

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Graham Hayes]

On 23/04/18 15:06, Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
> 
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
> 
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?

Our scale.

To get a large feature merged can require get code
prioritised by 2 or 3 different teams, and merged into any number of
repositories.

To get a small feature merged on some projects can take some time as
well, purely from the amount of code that is submitted for review to
these projects.

> Which of those would you change, and how?

Well, I definitely wouldn't change our scale. What I think we need to is
start breaking down some of the gigantic mono repos we have, so that
reviewing a small feature does not need large amounts of contextual
knowledge. I think this is happening organically in some teams already
with a few teams completely plugin based and distributed (like the docs
team).

When code can be reviewed in isolation without the fear of breaking
something 2 projects away, it helps both review time, and new
contributor experience.

> Where else should we be looking for contributors?

Honestly, I don't know. The kind of work that our contributors do, does
require a certain level of equipment, and "upstream time" that makes any
serious feature development hard for a casual weekend contributor.

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



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

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Graham Hayes]

On 18/04/18 11:38, Chris Dent wrote:
> On Tue, 17 Apr 2018, Thierry Carrez wrote:
> 
>> So... Is there any specific topic you think we should cover in that
>> meeting ?
> 
> The topics:
> 
> 1. What are we to do, as a community, when external pressures for
> results are not matched by contribution of resources to produce
> those results? There are probably several examples of this, but one
> that I'm particularly familiar with is the drive to be able to
> satisfy complex hardware topologies demanded by virtual network
> functions and related NFV use cases. Within nova, and I suspect other
> projects, there is intense pressure to make progress and intense
> effort that is removing resources from other areas. But the amount
> of daily, visible contribution from the interest companies [1] is
> _sometimes_ limited. There are many factors in this, and obviously
> "throw more people at it" is not a silver bullet, but there are
> things to talk about here that need the input from all the segments.
> 
> 2. We've made progress of late with acknowledging the concepts
> and importance of casual contribution and "drive-by bug fixing" in
> our changing environment. But we've not yet made enough progress in
> changing the way we do work. Corporate foundation members need to be
> more aware and more accepting that the people they provide to work
> "mostly upstream" need to be focused on making other people capable
> of contribution. Not on getting features done. And those of us who
> do have the privilege of being "mostly upstream" need to adjust our
> priorities.
> 
> Somewhere in that screed are, I think, some things worth talking
> about, but they need to be distilled out.
> 
> [1] http://superuser.openstack.org/articles/5g-open-source-att/


I think as an add on to this, would to ask the board to talk to members
and see what contributions they have made to the technical side of
OpenStack.

This should not just be Number of commits / reviews / bugs etc but
also the motivation for the work, e.g. - Feature for a product, bug fix
found in a product, cross project work or upstream project maintenance.

I don't necessarily want to shame corporate members of the foundation,
but I think it is important to understand where our contributor base
comes from, and what each member brings to the community table.

We should also ask the board to try and formulate a plan for growing
new cross project leaders (not just TC / PTLs). We need to grow more
technical contributors in the horizontal teams, which requires more
than assigning a contributor to the QA / Infra / Olso / Docs teams
for a year or so - the people should be allowed a certain amount
of stability in a role, while not necessarily driving business 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
> 



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

Re: [openstack-dev] [tc] campaign question related to new projects

[Graham Hayes]

7On 20/04/18 22:26, Doug Hellmann wrote:

> Without letting the conversation devolve too much into a discussion
> of Adjutant's case, please talk a little about how you would evaluate
> a project's application in general.  What sorts of things do you
> consider when deciding whether a project "aligns with the OpenStack
> Mission," for example?
> 
> Doug
> 

For me, the most important thing for a project that wants to join is
that they act like "one of us" - what I think ttx refered to as "culture
fit".

This is fairly wide ranging, but includes things like:

* Do they use the PTIs[0]
* Do they use gerrit, or if they use something else, do they follow
  the same review styles and mechanisms?
* Are they on IRC?
* Do they use the mailing list for long running discussion?
  ** If a project doesn't have long running discussions and as a result
 does not have ML activity, I would see that as OK - my problem
 would be with a team that ran their own list.
* Do they use standard devstack / -infra jobs for testing?
* Do they use the standard common libraries (where appropriate)?

If a project fails this test (and would have been accepted as something
that drives the mission), I see no issue with the TC trying to bring
them into the fold by helping them work like one of us, and accepting
them when they have shown that they are willing to change how they
do things.

For the "product" fit, it is a lot more subjective. We used to have a
system (pre Big Tent) where the TC picked "winners" in a space and
blessed one project as the way to do $thing. Then, in big tent we
started to not pick winners, and allow anyone who was one of us, and
had a "cloud" application.

Recently, we have moved back to seeing if a project overlaps with
another. The real test for this (from my viewpoint) is if the
perceived overlap is an area that the team that is currently in
OpenStack is interested in pursuing - if not we should default to
adding the project.

Personally, if the project adds something that we currently lack,
and have lacked for a long time (not to get too close to the current
discussion), or tries to reduce the amount of extra tooling that
deployers currently write in house, we should welcome them.

The acid test for me is "How would I use this?" or "Have I written
tooling or worked somewhere that wrote tooling to do this?"

If the answer is yes, it is a good indication that they fit with the
mission.

- Graham

0 -
https://governance.openstack.org/tc/reference/project-testing-interface.html



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

[openstack-dev] [designate] Meeting Times - change to office hours?

[Graham Hayes]

Hi All,

We moved our meeting time to 14:00UTC on Wednesdays, but attendance
has been low, and it is also the middle of the night for one of our
cores.

I would like to suggest we have an office hours style meeting, with
one in the UTC evening and one in the UTC morning.

If this seems reasonable - when and what frequency should we do
them? What times suit the current set of contributors?

Thanks,

Graham



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

Re: [openstack-dev] [all] How to handle python3 only projects

[Graham Hayes]

On 17/04/18 07:10, Adrian Turjak wrote:
> Hello devs,
> 
> The python27 clock of doom ticks closer to zero
> (https://pythonclock.org/) and officially dropping python27 support is
> going to have to happen eventually, that though is a bigger topic.
> 
> Before we get there outright what we should think about is what place
> python3 only projects have in OpenStack alongside ones that support both.
> 
> Given that python27's life is nearing the end, we should probably
> support a project either transitioning to only python3 or new projects
> that are only python3. Not to mention the potential inclusion of python3
> only libraries in global-requirements.
> 
> Potentially we should even encourage python3 only projects, and
> encourage deployers and distro providers to focus on python3 only (do
> we?). Python3 only projects are now a reality, python3 only libraries
> are now a reality, and most of OpenStack already supports python3. Major
> libraries are dropping python27 support in newer versions, and we should
> think about how we want to do it too.
> 
> So where do projects that want to stop supporting python27 fit in the
> OpenStack ecosystem? Or given the impending end of python27, why should
> new projects be required to support it at all, or should we heavily
> encourage new projects to be python3 only (if not require it)?
> 
> It's not an easy topic, and there are likely lots of opinions on the
> matter, but it's something to start considering.
> 
> Cheers!
> 
> - Adrian Turjak

I think the time has definitely come to allow projects be py3 only.

https://review.openstack.org/#/c/561922/ should allow that from a
governance perspective.

- Graham



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

[openstack-dev] [election][tc] TC Candidacy for Graham Hayes

[Graham Hayes]

Hi,

I am submitting my candidacy for the OpenStack Technical Committee.

I have been contributing to OpenStack since the Havana cycle [1][2],
mainly in
Designate. I have also been involved with the TC, and its meetings since
Designate applied for incubation all the way back in Atlanta (the first time
we were there).

Over the last 6 months I have become more involved in the TC, and have been
an active contributor to TC discussions (both on IRC and in person) and
governance [3].

I have been PTL for Designate for Mitaka, Newton, Ocata, Queens and Rocky
cycles, and a core for a longer period. I believe my experience working in a
younger, smaller project within OpenStack is a benefit. Along with the
experience of working on software as an end user of OpenStack I can help us
ensure the Technical Committee is mindful of the unique challenges these
projects and users can face.

With the broadening of the scope of the OpenStack Foundation, I believe that
it is an important part of the TC's role to have robust, and frank
discussions
with the Board of Directors and I believe that I have done a reasonable
job of
summarizing [4][5] what happens at the Board of Directors meetings to the
community over the last 6 months.

The need for the candid discussions is not restricted to the Foundation
and the
board - the new strategic focus areas that the foundation is expanding into
need our technical leadership to engage with them and ensure that we are all
working towards the overall goal of the foundation and promoting open
infrastructure. We need to make collaborating, and sharing resources and
expertise where it makes sense a priority.

What it does not mean is changing what OpenStack is nor changing
OpenStack to
cater for a single use case. This is a situation where better education
of how
OpenStack and it components can be used and orchestrated is needed, and
a lot
of this work should be directed by the TC. I don't think the TC will
always (or
even most of the time) be the correct people to engage, but I think we
should
lead the way by finding the correct people with the knowledge and
experience,
and helping support them and provide them with a platform to provide
guidance
to these groups.

When it comes to pushing forward the TC vision[6] I think the community has
made great steps forward to realizing it, on all but one section. We engage
with groups like the CNCF, and specifically Kubernetes and help drive
OpenStack
adoption with first class support for the OpenStack Cloud Provider, the
Cinder
Container Storage Interface and other projects. We still need to find a
way to
show the world what a top tier private open source infrastructure of
components
like OpenStack, Kubernetes, Cloud Foundry or OpenShift looks like, and
helping
companies understand why this is the way forward for their infrastructure.

Unfortunately, helping users, deployers and C(T|I)Os understand this
would be
easier with well written and and clearly documented "constellations" - I
have
always found talking in the abstract is a lot more difficult than discussing
something tangible. For the last 5 years I have worked on product teams
building products based on OpenStack, Kubernetes and Cloud Foundry, and
I think
this experience will be a great asset in developing our first generation of
constellations, which is something I think we need to focus on for the next
term of the TC.

I think that having constellations will also help us solve the perennial
question of what OpenStack is. By having sets of projects, we can show that
OpenStack is extremely flexible - and that there are projects for
different use
cases. Far too much time is spent circling back to the "What is OpenStack" -
which I foresee getting even more complex as the OpenStack Foundation grows
beyond the OpenStack Project, and having a solid, stable answer to what
we are
is going to be vital.

I would like to thank you for taking the time to read my thoughts - and ask
you to consider me for your vote. If elected I will strive to be vocal
for the
community that I have gotten so much from. I want to give some more back to
them ensure that the OpenStack Project continues to be the go to
software for
Infrastructure as a Service.

Thanks again,

 - Graham


1 - http://stackalytics.com/?release=all=commits_id=grahamhayes
2 - https://www.openstack.org/community/members/profile/12766/graham-hayes
3 -
https://review.openstack.org/#/q/project:openstack/governance+(commentby:%22Graham+Hayes+%253Cgr%2540ham.ie%253E%22+OR+reviewedby:%22Graham+Hayes+%253Cgr%2540ham.ie%253E%22++OR+owner:%22Graham+Hayes+%253Cgr%2540ham.ie%253E%22)
4 -
http://graham.hayes.ie/posts/dublin-ptg-summary/#board-of-directors-meeting
5 -
http://graham.hayes.ie/posts/sydney-openstack-summit/#sunday-board-joint-leadership-meeting
6 -
https://governance.openstack.org/tc/resolutions/20170404-vision-2019.html



signature.asc
Description: OpenP

Re: [openstack-dev] [all][requirements] uncapping eventlet

[Graham Hayes]

On 05/04/18 16:47, Matthew Thode wrote:
> eventlet-0.22.1 has been out for a while now, we should try and use it.
> Going to be fun times.
> 
> I have a review projects can depend upon if they wish to test.
> https://review.openstack.org/533021

It looks like we may have an issue with oslo.service -
https://review.openstack.org/#/c/559144/ is failing gates.

Also - what is the dance for this to get merged? It doesn't look like we
can merge this while oslo.service has the old requirement restrictions.

> 
> 
> __
> OpenStack Development Mailing 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] [stable][release] Remove complex ACL changes around releases

[Graham Hayes]

On 26/03/2018 14:33, Thierry Carrez wrote:
> Hi!
> 
> TL;DR:
> We used to do complex things with ACLs for stable/* branches around
> releases. Let's stop doing that as it's not really useful anyway, and
> just trust the $project-stable-maint teams to do the right thing.
> 
> 
> Current situation:
> 
> As we get close to the end of a release cycle, we start creating
> stable/$series branches to refine what is likely to become a part of the
> coordinated release at the end of the cycle. After release, that same
> stable/$series branch is used to backport fixes and issue further point
> releases.
> 
> The rules to apply for approving changes to stable/$series differ
> slightly depending on whether you are pre-release or post-release. To
> reflect that, we use two different groups. Pre-release the branch is
> controlled by the $project-release group (and Release Managers) and
> post-release the branch is controlled by the $project-stable-maint group
> (and stable-maint-core).
> 
> To switch between the two without blocking on an infra ACL change, the
> release team enters a complex dance where we initially create an ACL for
> stable/$series, giving control of it to a $project-release-branch group,
> whose membership is reset at every cycle to contain $project-release. At
> release time, we update $project-release-branch Gerrit group membership
> to contain $project-stable-maint instead. Then we get rid of the
> stable/$series ACL altogether.
> 
> This process is a bit complex and error-prone (and we tend to have to
> re-learn it every cycle). It's also designed for a time when we expected
> completely-different people to be in -release and -stable-maint groups,
> while those are actually, most of the time, the same people.
> Furthermore, with more and more deliverables being released under the
> cycle-with-intermediary model, pre-release and post-release approval
> rules are actually more and more of the same.
> 
> Proposal:
> 
> By default, let's just have $project-stable-maint control stable/*. We
> no longer create new ACLs for stable/$series every cycle, we no longer
> switch from $project-release control to $project-stable-maint control.
> The release team no longer does anything around stable branch ACLs or
> groups during the release cycle.
> 
> That way, the same group ends up being used to control stable/*
> pre-release and post-release. They were mostly the same people already:
> Release managers are a part of stable-maint-core, which is included in
> every $project-stable-maint anyway, so they retain control.
> 
> What that changes for you:
> 
> If you are part of $project-release but not part of
> $project-stable-maint, you'll probably want to join that team. If you
> review pre-release changes on a stable branch for a
> cycle-with-milestones deliverable, you will have to remember that the
> rules there are slightly different from stable branch approval rules. In
> doubt, do not approve, and ask.

It is more complex than just "joining that team" if the project follows
stable policy. the stable team have to approve the additions, and do
reject people trying to join them. I don't want to have a release where
someone has to self approve / ninja approve patches due to cores *not*
having the access rights that they previously had.

> But I don't like that! I prefer tight ACLs!
> 
> While we do not recommend it, every team can still specify more complex
> ACLs to control their stable branches. As long as the "Release Managers"
> group retains ability to approve changes pre-release (and
> stable-maint-core retains ability to approve changes post-release), more
> specific ACLs are fine.
> 
> Let me know if you have any comment, otherwise we'll start using that
> new process for the Rocky cycle (stable/rocky branch).
> 
> Thanks !
> 

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

Re: [openstack-dev] Pros and Cons of face-to-face meetings

[Graham Hayes]

On 08/03/18 18:06, Jeremy Stanley wrote:
> On 2018-03-08 17:49:35 + (+), Flint WALRUS wrote:
>> Pretty easy, put the PTG online with a livestream on
>> YouTube/Hangout/whatever platform that will then be saved and could even be
>> watched later on!
>>
>> It’s just a matter of some hardware and a decent internet bandwidth that’s
>> already available to almost every places where a PTG took place.
>>
>> Problem solved.
> [...]
> 
> Have you ever actually tried it? I know this seems simple to "solve"
> with technology, but put 50 people in a room having a heated
> conversation (or sometimes several conversations at once) and then
> try to bridge some people in via phone, video conference, whatever
> and see how it works out in reality.
> 
> The times it's been tried, either the remote participants get
> frustrated because nobody is paying attention to them/speaking into
> microphones/keeping discussion to one thread at a time, or the
> in-person participants get frustrated because they have to start
> acting like they're all on separate telephones and drag down the
> bandwidth of the conversation to the point where it may as well be
> 100% remote/separate participation anyway.
> 
> We've made it work to varying degrees in the past, but it's not so
> simple as you would seem to imply no matter how good the technology.

I would echo ^.

As a remote employee for ~ 5 years, I have a large amount of experience
being the person at the far end of a laptop / phone / etc.

Some of the VC systems work well, but they are expensive, complex
systems, with multiple mics, speakers, and cameras.

I am not saying we shouldn't try it, but lets not get our hopes up.

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



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

Re: [openstack-dev] [tc] [all] TC Report 18-10

[Graham Hayes]

On 07/03/18 20:24, Lance Bragstad wrote:
> 
> 
> On 03/07/2018 06:12 AM, Chris Dent wrote:
>>
>> HTML: https://anticdent.org/tc-report-18-10.html
>>
>> This is a TC Report, but since everything that happened in its window
>> of observation is preparing for the
>> [PTG](https://www.openstack.org/ptg), being at the PTG, trying to get
>> home from the PTG, and recovering from the PTG, perhaps think of this
>> as "What the TC talked about [at] the PTG". As it is impossible to be
>> everywhere at once (especially when the board meeting overlaps with
>> other responsibilities) this will miss a lot of important stuff.  I
>> hope there are other summaries.
>>
>> As you may be aware, it [snowed in
>> Dublin](https://twitter.com/search?q=%23snowpenstack) causing plenty
>> of disruption to the
>> [PTG](https://twitter.com/search?q=%23openstackptg) but everyone
>> (foundation staff, venue staff, hotel staff, attendees, uisce beatha)
>> worked together to make a good week.
>>
>> # Talking about the PTG at the PTG
>>
>> At the [board
>> meeting](http://lists.openstack.org/pipermail/foundation/2018-March/002570.html),
>>
>> the future of the PTG was a big topic. As currently constituted it
>> presents some challenges:
>>
>> * It is difficult for some people to attend because of visa and other
>>   travel related issues.
>> * It is expensive to run and not everyone is convinced of the return
>>   on investment.
>> * Some people don't like it (they either miss the old way of doing the
>>   design summit, or midcycles, or $OTHER).
>> * Plenty of other reasons that I'm probably not aware of.
>>
>> This same topic was reviewed at [yesterday's office
>> hours](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-06.log.html#t2018-03-06T09:19:32).
>>
>>
>> For now, the next 2018 PTG is going to happen (destination unknown) but
>> plans for 2019 are still being discussed.
>>
>> If you have opinions about the PTG, there will be an opportunity to
>> express them in a forthcoming survey. Beyond that, however, it is
>> important [that management at contributing
>> companies](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-06.log.html#t2018-03-06T22:29:24)
>>
>> hear from more people (notably their employees) than the foundation
>> about the value of the PTG.
>>
>> My own position is that of the three different styles of in-person
>> events for technical contributors to OpenStack that I've experienced
>> (design summit, mid-cycles, PTG), the PTG is the best yet. It minimizes
>> distractions from other obligations (customer meetings, presentations,
>> marketing requirements) while maximizing cross-project interaction.
>>
>> One idea, discussed
>> [yesterday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-06.log.html#t2018-03-06T22:02:24)
>>
>> and [earlier
>> today](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-07.log.html#t2018-03-07T05:07:20)
>>
>> was to have the PTG be open to technical participants of any sort, not
>> just so-called "OpenStack developers". Make it more of a place for
>> people who hack on and with OpenStack to hack and talk. Leave the
>> summit (without a forum) for presentations, marketing, pre-sales, etc.
>>
>> An issue raised with conflating the PTG and the Forum is that it would
>> remove the
>> [inward/outward
>> focus](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-07.log.html#t2018-03-07T08:20:17)
>> concept that is supposed to distinguish the two events.
>>
>> I guess it depends on how we define "we" but I've always assumed that
>> both events were for outward focus and that for any inward focussing
>> effort we ought to be able use asynchronous tools more.
> I tried bringing this up during the PTG feedback session last Thursday,
> but figured I would highlight it here (it also kinda resonates with
> Matt's note, too).
> 
> Several projects have suffered from aggressive attrition, where there
> are only a few developers from a few companies. I fear going back to
> midcycles will be extremely tough with less corporate sponsorship. The
> PTGs are really where smaller teams can sit down with developers from
> other projects and work on cross-project issues.

This ^ . If we go back to the Design Summits, where these small projects
would get 3 or 4 40min slots, and very little chance of a mid-cycle,
it will cause teams issues.

>>
>> # Foundation and OCI
>>
>> Thierry mentioned
>> [yesterday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-06.log.html#t2018-03-06T09:08:04)
>>
>> that it is likely that the OpenStack Foundation will join the [Open
>> Container Initiative](https://www.opencontainers.org/) because of
>> [Kata](https://katacontainers.io/) and
>> [LOCI](https://governance.openstack.org/tc/reference/projects/loci.html).
>>
>> This segued into some brief concerns about the [attentions and
>> intentions of the
>> 

[openstack-dev] [designate] V1 API is now fully removed

[Graham Hayes]

I saw [1] and realised that we should be more explicit about the
upcoming release.

As highlighted in [2], this email is a reminder that the long awaited
removal of the DNS V1 API is now complete with [3].

This means from Queens onwards it will not be possible to re-enable
the V1 API (we have had it off by default for a long period of time).

Horizon, Heat and the OpenStack CLI all have v2 usable resources, and
have been deprecating the v1 resources for some time.

Any deployment tooling, custom dashboards, and internal tools should
all ensure they do not require the v1 API, and do not try to enable it.

- Graham

1 -
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127366.html
2 -
https://docs.openstack.org/releasenotes/designate/queens.html#critical-issues
3 -
https://github.com/openstack/designate/commit/c318106c01b2b3976049f2c3ba0c8502a874242b



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

Re: [openstack-dev] [osc][python-openstackclient] Consistency of option name

[Graham Hayes]

On 12/02/18 16:04, William M Edmonds wrote:
> keystone may have taken "domain", but it didn't take "dns-domain"

No, but the advice at the time was to move to zone, and match DNS
RFCs, and not namespace objects with the service type.

We moved from "domain" -> "zone" and "records" -> "recordsets" in
both the CLI and in our V2 API (in Aug 2013, so the time for change
has long passed).

The point of my initial email was that if we were moving some of the
inconsistent naming for availability zones to something, that
moving it to "availability-zone" would be better than "zone". I think
that point has been made, so lets leave it at that.

- Graham

> 
> Dean Troyer <dtro...@gmail.com> wrote on 02/12/2018 10:24:05 AM:
>>
>> On Mon, Feb 12, 2018 at 9:13 AM, Graham Hayes <g...@ham.ie> wrote:
>> > OSC only predates Designate by 5 months ...
>>
>> My bad, I didn't check dates.
>>
>> > "Zone" was what we were recommend to use by the OSC devs at the time we
>> > wrote our OSC plugin, and at the time we were also *not* supposed to
>> > name space commands inside service parent (e.g. openstack zone create vs
>> > openstack dns zone create).
>>
>> Namespacing commands and naming options are totally separate things.
>> It is likely I suggested --zone at the time, and in the context of DNS
>> commands it is very clear.  Also, in the context of Compute commands,
>> --zone meaning availability zone is also clear.
>>
>> > For command flags --dns-zone seems like a good idea - but having a plain
>> > --zone is confusing when we have a top level "zone" object in the CLI,
>> > when the type of object that "--zone" refers to is different to
>> > "openstack zone "
>>
>> Again, if there is confusion, things should be more specifically named
>> to remove the confusion.  Maybe allowing "zone" to be assumed to be a
>> DNS zone was a mistake, I've made plenty of those in OSC already, so
>> there is precedent, but it seemed reasonable at the time and we (OSC
>> team) do not control what external plugins do.
>>
>> For example, I really resist using abbreviations in OSC, but in some
>> places to not do so is to buck trends that any semi-experienced user
>> in the field would expect.  The last discussion of this was last week
>> regarding "MTU" in Network commands.
>>
>> These are not hard rules, but strong guidelines that can and should be
>> interpreted in the context that they will be applied.  And in the end,
>> the result should be one that is understandable, clear and even
>> expected by the users.
>>
>> dt
>>
>> --
>>
>> Dean Troyer
>> dtro...@gmail.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> https://urldefense.proofpoint.com/v2/url?
>>
> u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-
>>
> siA1ZOg=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg=Fr9TF_mDZVJgACWKoyXcnphs-6rMDWufyRhpQEtUask=m5wXNx8okCgs7CbNoMhHEQev0xJCFIq61pcmnWBugSs=
>>
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



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

Re: [openstack-dev] [osc][python-openstackclient] Consistency of option name

[Graham Hayes]

On 12/02/18 14:51, Dean Troyer wrote:
> On Mon, Feb 12, 2018 at 7:50 AM, Graham Hayes <g...@ham.ie> wrote:
>> Please please move to `availability-zone` - zone is a DNS zone (seen as
>> Keystone took Domain :) ) within OSC.
> 
> As stated in another message, changing the Compute usage of --zone
> makes sense for OSC 4.  Two additional things here:
> 
> * Command option names have a lesser bar to clear (compared to
> resource names which must be unique) for uniqueness, as they are by
> definition context-sensitive.  Like trademarks, the primary objective
> is to reduce user confusion.
> 
> * --zone is really generic and I would suggest that DNS should also be
> using something to qualify it.  The use of --zone in the Compute
> commands pre-dates the existence of Designate by at least a coupe of
> years.

OSC only predates Designate by 5 months ...

> Also, the Network commands use "--dns-*" to refer to anything
> specifically DNS related, so for consistency, "--dns-zone" is a better
> fit.

"Zone" was what we were recommend to use by the OSC devs at the time we
wrote our OSC plugin, and at the time we were also *not* supposed to
name space commands inside service parent (e.g. openstack zone create vs
openstack dns zone create).

For command flags --dns-zone seems like a good idea - but having a plain
--zone is confusing when we have a top level "zone" object in the CLI,
when the type of object that "--zone" refers to is different to
"openstack zone "

- Graham

> 
> dt
> 



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

Re: [openstack-dev] [osc][python-openstackclient] Consistency of option name

[Graham Hayes]

On 12/02/18 04:18, Hongbin Lu wrote:
> Hi all,
> 
> I was working on the OSC plugin of my project and trying to choose a CLI
> option to represent the availability zone of the container. When I came
> across the existing commands, I saw some inconsistencies on the naming.
> Some commands use the syntax '--zone ', while others use the syntax
> '--availability-zone '. For example:
> 
> * openstack host list ... [--zone ]
> * openstack aggregate create ... [--zone ]
> * openstack volume create ... [--availability-zone ]
> * openstack consistency group create ... [--availability-zone
> ]
> 
> I wonder if it makes sense to address this inconsistency. Is it possible
> have all commands using one syntax?
> 
> Best regards,
> Hongbin
> 

Please please move to `availability-zone` - zone is a DNS zone (seen as
Keystone took Domain :) ) within OSC.

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



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

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

[Graham Hayes]

On 31/01/18 17:22, Dmitry Tantsur wrote:
> On 01/31/2018 06:15 PM, Matt Riedemann wrote:
>> On 1/30/2018 9:33 AM, Colleen Murphy wrote:
>>> At the last PTG we had some time on Monday and Tuesday for
>>> cross-project discussions related to baremetal and VM management. We
>>> don't currently have that on the schedule for this PTG. There is still
>>> some free time available that we can ask for[1]. Should we try to
>>> schedule some time for this?
>>>
>>>  From a keystone perspective, some things we'd like to talk about with
>>> the BM/VM teams are:
>>>
>>> - Unified limits[2]: we now have a basic REST API for registering
>>> limits in keystone. Next steps are building out libraries that can
>>> consume this API and calculate quota usage and limit allocation, and
>>> developing models for quotas in project hierarchies. Input from other
>>> projects is essential here.
>>> - RBAC: we've introduced "system scope"[3] to fix the admin-ness
>>> problem, and we'd like to guide other projects through the migration.
>>> - Application credentials[4]: this main part of this work is largely
>>> done, next steps are implementing better access control for it, which
>>> is largely just a keystone team problem but we could also use this
>>> time for feedback on the implementation so far
>>>
>>> There's likely some non-keystone-related things that might be at home
>>> in a dedicated BM/VM room too. Do we want to have a dedicated day or
>>> two for these projects? Or perhaps not dedicated days, but
>>> planned-in-advance meeting time? Or should we wait and schedule it
>>> ad-hoc if we feel like we need it?
>>>
>>> Colleen
>>>
>>> [1]
>>> https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307=true
>>>
>>> [2]
>>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
>>>
>>> [3]
>>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
>>>
>>> [4]
>>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.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
>>>
>>
>> These all seem like good topics for big cross-project issues.
>>
>> I've never liked the "BM/VM" platform naming thing, it seems to imply
>> that the only things one needs to care about for these discussions is
>> if they work on or use nova and ironic, and that's generally not the
>> case.
> 
> ++ can we please rename it? I think people (myself included) will expect
> specifically something related to bare metal instances co-existing with
> virtual ones (e.g. scheduling or networking concerns). Which is also a
> great topic, but it does not seem to be present on the list.
> 

Yeah - both of these topic apply to all projects. If we could do
scheduled time for both of these, and then separate time for Ironic /
Nova issues it would be good.

>>
>> So if you do have a session about this really cross-project
>> platform-specific stuff, can we at least not call it "BM/VM"? Plus,
>> "BM" always makes me think of something I'd rather not see in a room
>> with other people.
>>
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [tc] [all] TC Report 18-05

[Graham Hayes]

On 30/01/18 18:34, Chris Dent wrote:
> 
> Linkified: https://anticdent.org/tc-report-18-05.html
> 
> Your author has been rather ill, so this week's TC Report will be a
> bit abridged and mostly links. I'll try to return with more robust
> commentary next week.
> 
> ## RDO Test Days
> 
> dmsimard showed up in `#openstack-tc` channel to [provide some
> details](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-24.log.html#t2018-01-24T16:32:11)
> 
> on forthcoming RDO Test Days.
> 
> ## More on the Goals
> 
> [Conversations](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-25.log.html#t2018-01-25T15:48:50)
> 
> [continue](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-30.log.html#t2018-01-30T09:03:31)
> 
> about choosing OpenStack goals. One issue raised is whether we have
> sufficient insight into how people are really using and deploying
> OpenStack to be able to prioritize goals.
> 
> ## Project Inception
> 
> smcginnis [pointed
> out](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-29.log.html#t2018-01-29T17:25:25)
> 
> a governance discussion in the CNCF about [project
> inception](https://github.com/cncf/toc/issues/85) that he thought
> might be of interest to the TC. Discussion ensued around how the
> OpenStack ecosystem differs from the CNCF and as a result the need, or
> lack thereof, for help to bootstrap projects is different.
> 
> ## PTG Scheduling
> 
> The PTG is coming and with it
> [discussion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-30.log.html#t2018-01-30T09:22:44)
> 
> of how best to make room for all the conversations that need to
> happen, including things that come up at the last minute. New this
> time will be a more formal structuring of [post-lunch
> presentations](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-30.log.html#t2018-01-30T09:38:17)
> 
> to do theme-setting and information sharing.
> 
> ## Board Meeting at the PTG
> 
> Monday there was
> [discussion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-29.log.html#t2018-01-29T16:06:18)
> 
> about the OpenStack Foundation [Board
> Meeting](https://wiki.openstack.org/wiki/Governance/Foundation/26Feb2018BoardMeeting)
> 
> overlapping with the first day of the PTG. This follows [discussion in
> email](http://lists.openstack.org/pipermail/foundation/2018-January/002558.html).

There was also a suggestion [2] that the community / TC put an item on
the F2F meeting agenda, with an associated etherpad [2]:

1-
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-29.log.html#t2018-01-29T16:34:43
2 - https://etherpad.openstack.org/p/tc-message-to-board-dublin-2018

> 
> ## Today's Board Meeting
> 
> I attended [today's Board
> Meeting](https://wiki.openstack.org/wiki/Governance/Foundation/30Jan2018BoardMeeting)
> 
> but it seems that according to the [transparency
> policy](http://www.openstack.org/legal/transparency-policy/) I can't
> comment:
> 
>>  No commenting on Board meeting contents and decisions until
>>  Executive Director publishes a meeting summary
> 
> That doesn't sound like transparency to me, but I assume there must be
> reasons.
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



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

Re: [openstack-dev] [tc] [all] TC Report 18-05

[Graham Hayes]

On 30/01/18 18:34, Chris Dent wrote:

> 
> ## Today's Board Meeting
> 
> I attended [today's Board
> Meeting](https://wiki.openstack.org/wiki/Governance/Foundation/30Jan2018BoardMeeting)
> 
> but it seems that according to the [transparency
> policy](http://www.openstack.org/legal/transparency-policy/) I can't
> comment:
> 
>>  No commenting on Board meeting contents and decisions until
>>  Executive Director publishes a meeting summary
> 
> That doesn't sound like transparency to me, but I assume there must be
> reasons.

I was under the assumption that this only applied to board members, but
I am open to correction.

Can someone on legal-discuss clarify?

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



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

[openstack-dev] [designate] designate-core updates

[Graham Hayes]

Another update to the designate-core team:

+ eandersson
- timsim
- kiall

eandersson has been a long term reviewer and end user of designate who
has consistently performed good, and detail orientated reviews.

Unfortunately both Kiall and Tim have moved on to other areas, and as
such have not had the time to be consistent with their reviews.

I would like to thank Kiall (the projects original founder) and Tim
for the help they have provided over the years, and for taking the
time to do reviews even after they were working on other areas.

If anyone thinks that they, or someone else would be a good core
reviewer for Designate, please let me know, on this email,
or on IRC (mugsie on freenode).

Thanks

- Graham



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

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Graham Hayes]

On 19/01/18 16:27, Andrea Frittoli wrote:
> 
> Thanks for the summary!
> 
> To be honest I don't see why this decision has to be difficult to take.

I think the confusion comes from one thing being decided already, and
now conflicting direction is being given to teams, without anyone
updating the Governance repo.

(It is not as if there was not plenty of warning, I have been raising it
as an issue for over a year)

> Nothing we decide today is written in stone and the main risk ahead of
> us is to take
> a decision that requires a lot of upfront work and that it ends up
> providing no
> significant benefit, or even making things worst in some aspect. So we
> may try one way
> today and if we hit some significant issue we can still change.
> 
> TL;DR my preferred option would be number (2) - it's the least initial
> effort, so the
> least risk, and deciding for (2) now won't make it any difficult in the
> future to switch
> to option (1) or option (3). I'm not pushing back on (2), I just think
> (1) is more convenient.
> Details below each option.
>  
> 
> 
> So far the patch proposes three options:
> 
> 1) All trademark-related tests should go in the tempest repo, in
> accordance
>    with the original resolution. This would mean that even projects
> that have
>    never had tests in tempest would now have to add at least some of
> their
>    black-box tests to tempest.
> 
> 
> This option is a valid one, but I think it introduces too much extra
> work and
> testing complications for too little benefit.

What it does do is *guarantee* that the InterOp suite will work, as it
will be CI'd. I see these programs as important enough that we should CI
the tooling used for them, but I seem to be in a minority.

>  
> 
> The value of this option is that centralizes tests used for the
> Interop program
> in a location where interop-minded folks from the QA team can
> control them. 
> 
> 
> There are other ways this can be achieved - it is possible to mark tests
> so that
> team may require a +1 from interop/qa when specific tests are modified.

Is there? AFAIK gerrit does not do per file path permissions, so unless
we have a job that just checks the votes on a patch, and passes or fails
if a test changes (which would be awful for the teams) we cannot do
that.

>  
> 
> The
> downside is that projects that so far have avoided having a
> dependency on
> tempest will now lose some control over the black-box tests that
> they use for
> functional and integration that would now also be used for trademark
> certification.
> There's also concern for the review bandwidth of the QA team - we
> can't expect
> the QA team to be continually responsible for an ever-growing list
> of projects
> and their trademark tests.
> 
> 
> If we restrict to interop tests, the review bandwidth issue is probably
> not so bad.
> The QA team would have to request the domain knowledge required for proper
> review from the respective teams anyways.
> 
> There are other complications introduced though:
> 
> - service clients and other common bits (config and so) would have to
> move to
>   Tempest since we cannot have tempest depend on plugins. But then modifying
>   those common bits on Tempest side would risk to break non-interop tests.
>   Solution for that is to make all those bits stable interfaces for plugins

Is this not already the case? e.g. the neutron plugin uses the nova
service client already.

This would also help for the neutron plugin which is currently importing
DNS service clients from the designate-tempest-plugin repo - having them
in the tempest repo would allow them to to be more stable, and remove
the extra dependency.

>  
> - tempest would have to add new CI jobs to run the interop tests from add-on
>   program on every tempest change so that the new code is tested on a
> regular
>   basis.

That is a good thing, and we should probably do that for the other 2
options as well...

> 
> - heat tests are wrapped in a Tempest plugin but actually written in
> Gabbi so we
>   would need to add Gabbi as a dependency to Tempest
> 
> Nothing too terrible really, but I think it might not be worth the extra
> effort, especially
> now that teams available resources are getting thinner and thinner.
> 
> 
> 2) All trademark-related tests for *add-on projects* should be
> sourced from
>    plugins external to tempest.
> 
> I wouldn't go as far as saying they "should" be sourced. I think saying
> that they
> *may* be sourced from a plugin is enough. Apart from that this is my
> favourite
> option. The only thing required really is updating the resolution and we are
> ready to go.
> 
> With all the plugins no in own branchless repositories, the usability
> concern is
> not so strong anymore really.
>  
> 
> The value of this option is it allows project teams to retain
> control over
> these tests. 
> 
> 
> Other value 

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Graham Hayes]

On 19/01/18 00:52, Ken'ichi Ohmichi wrote:
> 2018-01-18 12:36 GMT-08:00 Doug Hellmann :
>> Excerpts from Doug Hellmann's message of 2018-01-18 15:21:12 -0500:
>>> Excerpts from Graham Hayes's message of 2018-01-18 19:25:02 +:

 On 18/01/18 18:52, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-01-18 17:52:39 +:
>> On 18/01/18 16:25, Doug Hellmann wrote:
>>> Excerpts from Graham Hayes's message of 2018-01-18 15:33:12 +:
>>
>> 
>>
>>>
>>> In the past the QA team agreed to accept trademark-related tests from
>>> all projects in the tempest repo. Has that changed?
>>>
>>
>> There has not been an explict rejection but in all conversations the
>> response has been "non core projects are outside the scope of tempest".
>>
>> Honestly, everytime we have tried to do something to core tempest
>> we have had major pushback, and I want to clarify this before I or
>> someone else put in the work of porting the base clients, getting CI
>> configured*, and proposing the tests to tempest.
>
> OK.
>
> The current policy doesn't say anything about "core" or different
> trademark programs or any other criteria.
>
>   The TC therefore encourages the DefCore committee to consider it an
>   indication of future technical direction that we do not want tests
>   outside of the Tempest repository used for trademark enforcement, and
>   that any new or existing tests that cover capabilities they want to
>   consider for trademark enforcement should be placed in Tempest.
>
> That all seems very clear to me (setting aside some specific word
> choices like "future technical direction" that tie the resolution
> to language in the bylaws).  Regardless of technical reasons why
> it may not be necessary, we still have many social justifications
> for doing it the way we originally set out to do it.  Tests related
> to trademark enforcement need to go into the tempest repository.
>
> The way I think this should work (and the way I remember us describing
> it at the time the policy was established) is the Interop WG
> (previously DefCore) should identify capabilities and tests, then
> ask project teams to reproduce those tests in the tempest repo.
> When the tests land, they can be used by the trademark program.
> Teams can also, at their leisure, decide whether to remove the
> original versions of the tests from whatever repo they existed in
> to begin with.
>
> Graham, you've proposed a new resolution with several options for
> where to put tests for "add-on programs." I don't think we need
> that resolution if we want the tests to continue to live in tempest.
> The existing resolution doesn't qualify which tests, beyond "for
> trademark enforcement" and more words won't make that more clear,
> IMO.
>
> Now if you *do* want to change the policy, we should talk about
> that.  But I can't tell whether you want to change it, you're worried
> the policy is unclear, or it is not being followed.  Can you clarify
> which it is?

 It is not being followed.

 I have brought this up at every forum session on these programs, and the
 people in the room from QA have *always* pushed back on it.
>>>
>>> OK, so that's a problem. I need to hear from the QA team why they've
>>> reversed that decision.
>>>

 And, for clarity (I saw this in a few logs) QA have *never* said that
 they will take the interop designated tests for the DNS project into
 openstack/tempest.
>>>
>>> When we approved the resolution that describes the current policy, the
>>> QA team agreed that they would take tests for trademark. There was no
>>> stipulation about which projects those apply to.
>>
>> I feel pretty sure that was discussed in a TC meeting, but I can't
>> find that. I do find Matt and Ken'ichi voting +1 on the resolution
>> itself.  https://review.openstack.org/#/c/312718/. If I remember
>> correctly, Ken'ichi was the PTL at the time.
> 
> Yeah, I have still agreed with the resolution.
> When I voted +1 on that, core projects were defined as 6 projects like
> Nova, Cinder, Glance, Keystone, Neutron and Swift.
> And the project navigator also showed these 6 projects as core projects.
> Now I cannot find such definition on the project navigator[1], the
> definition has been changed?
> I just want to clarify "is it true that designate and heat become core
> projects?"
> If there is a concrete decision, I don't have any objections against
> that we have these projects tests in Tempest as the resolution.

This seems to be the problem - there is not now, or ever been a "core"
project definition that was decided by TC / community. We have a set of
projects that most people will refer to as "core", but there is no way
to add projects to that.

What was 

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Graham Hayes]

On 19/01/18 03:28, Ghanshyam Mann wrote:
> On Thu, Jan 11, 2018 at 10:06 PM, Colleen Murphy  wrote:
>> Hi everyone,
>>
>> We have governance review under debate[1] that we need the community's help 
>> on.
>> The debate is over what recommendation the TC should make to the Interop team
>> on where the tests it uses for the OpenStack trademark program should be
>> located, specifically those for the new add-on program being introduced. Let 
>> me
>> badly summarize:
>>
>> A couple of years ago we issued a resolution[2] officially recommending that
>> the Interop team use solely tempest as its source of tests for capability
>> verification. The Interop team has always had the view that the developers,
>> being the people closest to the project they're creating, are the best people
>> to write tests verifying correct functionality, and so the Interop team 
>> doesn't
>> maintain its own test suite, instead selecting tests from those written in
>> coordination between the QA team and the other project teams. These tests are
>> used to validate clouds applying for the OpenStack Powered tag, and since all
>> of the projects included in the OpenStack Powered program already had tests 
>> in
>> tempest, this was a natural fit. When we consider adding new trademark 
>> programs
>> comprising of other projects, the test source is less obvious. Two examples 
>> are
>> designate, which has never had tests in the tempest repo, and heat, which
>> recently had its tests removed from the tempest repo.
>>
>> So far the patch proposes three options:
>>
>> 1) All trademark-related tests should go in the tempest repo, in accordance
>>with the original resolution. This would mean that even projects that have
>>never had tests in tempest would now have to add at least some of their
>>black-box tests to tempest.
>>
>> The value of this option is that centralizes tests used for the Interop 
>> program
>> in a location where interop-minded folks from the QA team can control them. 
>> The
>> downside is that projects that so far have avoided having a dependency on
>> tempest will now lose some control over the black-box tests that they use for
>> functional and integration that would now also be used for trademark
>> certification.
>> There's also concern for the review bandwidth of the QA team - we can't 
>> expect
>> the QA team to be continually responsible for an ever-growing list of 
>> projects
>> and their trademark tests.
>>
>> 2) All trademark-related tests for *add-on projects* should be sourced from
>>plugins external to tempest.
>>
>> The value of this option is it allows project teams to retain control over
>> these tests. The potential problem with it is that individual project teams 
>> are
>> not necessarily reviewing test changes with an eye for interop concerns and 
>> so
>> could inadvertently change the behavior of the trademark-verification tools.
>>
>> 3) All trademark-related tests should go in a single separate tempest plugin.
>>
>> This has the value of giving the QA and Interop teams control over
>> interop-related tests while also making clear the distinction between tests
>> used for trademark verification and tests used for CI. Matt's argument 
>> against
>> this is that there actually is very little distinction between those two 
>> cases,
>> and that a given test could have many different applications.
> 
> options#3 can solve centralize test location issue but there is
> another issue it leads. If we start moving all interop test to
> separate interop repo then, many of exiting tempest test (used by
> interop) also falls under this category. Which means those existing
> tempest tests need to stay in 2 location one in new interop plugin and
> second in tempest also as tempest is being used for lot other purpose
> also, gate, production Cloud testing & stability etc. Duplication
> tests in 2 location is not good option.

We could just install the interop plugin into all the gates, and ensure
it is ran, which would mean the tests are only ever in one place.


>>
>> Other ideas that have been thrown around are:
>>
>> * Maintaining a branch in the tempest repo that Interop tests are pulled 
>> from.
>>
>> * Tagging Interop-related tests with decorators to make it clear that they 
>> need
>>   to be handled carefully.
> 
> Nice and imp point. This is been take care very carefully in Tempest
> till now . While changing tests or removing test, we have a very clear
> and strict  process [4] to not affect any interop tests and i think it
> is 100% success till now, i have not heard any complained that we have
> changed any test which has broken interop. Adding new decorator etc
> has different issues to we did not accepted but main problem is solved
> by defining process..

Out of interest, what is the issue with a new test tag? it seems like it
would be a good way to highlight to people what tests need extra care.

> 
>>
>> At the heart of the issue is the perception 

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Graham Hayes]

On 19/01/18 04:10, Ghanshyam Mann wrote:
> On Thu, Jan 18, 2018 at 11:22 PM, Graham Hayes <g...@ham.ie> wrote:
>> On 18/01/18 16:25, Doug Hellmann wrote:
>>> Excerpts from Graham Hayes's message of 2018-01-18 15:33:12 +:
>>
>> 
>>
>>>
>>> In the past the QA team agreed to accept trademark-related tests from
>>> all projects in the tempest repo. Has that changed?
>>>
>>
>> There has not been an explict rejection but in all conversations the
>> response has been "non core projects are outside the scope of tempest".
>>
>> Honestly, everytime we have tried to do something to core tempest
>> we have had major pushback, and I want to clarify this before I or
>> someone else put in the work of porting the base clients, getting CI
>> configured*, and proposing the tests to tempest.
> 
> Yes, i do not remember that we have rejected the actual proposal or
> patches or ever said that "QA team not going to accept interop needed
> test inside Tempest even those are for other project than tempest
> scope". Rather its been discussed that we need to check the situation
> when new project going to be make in interop program. At least i
> remember the discussion during Barcelona summit where there talked
> about heat tests. We discussed we can check that based on when heat is
> going to make in interop program.

The decision seems to have been made already - people from the QA team
have been pushing for Option 2 since Boston.

> Anyways let's analysts the current situation and work on best possible
> solution than past things. I agree with Doug point about previous
> resolution was passed and then why this new resolution ? and what is
> not clear in previous resolution?. I think main issue is in
> understanding the difference between  'trademark' program and 'adds-on
> trademark' program.  Let me add the things point by point.

They are both trademark programs under the By-Laws.

> 1. What is difference between "Trademark" program and "Adds-on
> Trademark" program from interop certification? Can new projects go
> under "Trademark" program.
> This will be helpful to understand the situation of keeping all
> "Trademark" program tests and "Adds-on" program tests together or
> separate. For example: any difference of doing their certification,
> logo etc.

The only difference is that an Add On needs a cloud to pass an OpenStack
Powered program first. (e.g. you cannot have OpenStack DNS /
Orchestration on its own)

> 2.  As per previous resolution, and with all point of centralized test
> location, expertise review, project independent ownership etc etc i
> agree with option#1 and no "NO" to that now also. Now question comes
> to practice implementation of that resolution which depends on 2
> factor:
> 
> 1. scale and number of program going to be in interop:
> As per current proposal, (i think its heat and designate and
> around 20-30 tests as total) there is no issue for tempest team to
> add/review/maintain them. But if that grows in number of program (than
> number tests for e.x. having 50 tests of designate than 10 is not much
> different things) and say 10 more program then it is difficult for QA
> team to maintain those.
> 
> 2. QA team review bandwidth.
> This is one of the big obstacle to extend the tempest scope. Like
> other project, QA team face less contributors issues. Since 1-2 years,
> I have been trying to attract new contributor in QA during upstream
> training, mentorship program etc but people gets disappear after month
> or so. Even all QA members are trying their best in this area but
> unfortunately no success.
> 
> With both these factor i feel we can go with current resolution
> (option#1- below solution) and help QA team also if situation gets
> worst (QA team also human beings and need time to sleep :)).
> 
> 1. QA team accept all interop defined program tests (tests only needed
> by interop ).
> 2. Define a very clear process for collaboration between Interop, QA,
> project team to help on adding/maintaining tests. Something like clear
> guidelines of test req from interop,  MUST +1 from interop and project
> PTL.
> 3. If interop program grows more which become difficult to maintain by
> QA team then accept the necessary change to resolution.

This sounds like a great way forward.

> -gmann
> 
>>
>> - Graham
>>
>>
>> * With zuulv3 this is *much* easier, so not as big a deal as it once was
>>
>> 
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for us

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Graham Hayes]

On 18/01/18 18:52, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-01-18 17:52:39 +:
>> On 18/01/18 16:25, Doug Hellmann wrote:
>>> Excerpts from Graham Hayes's message of 2018-01-18 15:33:12 +:
>>
>> 
>>
>>>
>>> In the past the QA team agreed to accept trademark-related tests from
>>> all projects in the tempest repo. Has that changed?
>>>
>>
>> There has not been an explict rejection but in all conversations the
>> response has been "non core projects are outside the scope of tempest".
>>
>> Honestly, everytime we have tried to do something to core tempest
>> we have had major pushback, and I want to clarify this before I or
>> someone else put in the work of porting the base clients, getting CI
>> configured*, and proposing the tests to tempest.
> 
> OK.
> 
> The current policy doesn't say anything about "core" or different
> trademark programs or any other criteria.
> 
>   The TC therefore encourages the DefCore committee to consider it an
>   indication of future technical direction that we do not want tests
>   outside of the Tempest repository used for trademark enforcement, and
>   that any new or existing tests that cover capabilities they want to
>   consider for trademark enforcement should be placed in Tempest.
> 
> That all seems very clear to me (setting aside some specific word
> choices like "future technical direction" that tie the resolution
> to language in the bylaws).  Regardless of technical reasons why
> it may not be necessary, we still have many social justifications
> for doing it the way we originally set out to do it.  Tests related
> to trademark enforcement need to go into the tempest repository.
> 
> The way I think this should work (and the way I remember us describing
> it at the time the policy was established) is the Interop WG
> (previously DefCore) should identify capabilities and tests, then
> ask project teams to reproduce those tests in the tempest repo.
> When the tests land, they can be used by the trademark program.
> Teams can also, at their leisure, decide whether to remove the
> original versions of the tests from whatever repo they existed in
> to begin with.
> 
> Graham, you've proposed a new resolution with several options for
> where to put tests for "add-on programs." I don't think we need
> that resolution if we want the tests to continue to live in tempest.
> The existing resolution doesn't qualify which tests, beyond "for
> trademark enforcement" and more words won't make that more clear,
> IMO.
> 
> Now if you *do* want to change the policy, we should talk about
> that.  But I can't tell whether you want to change it, you're worried
> the policy is unclear, or it is not being followed.  Can you clarify
> which it is?

It is not being followed.

I have brought this up at every forum session on these programs, and the
people in the room from QA have *always* pushed back on it.

And, for clarity (I saw this in a few logs) QA have *never* said that
they will take the interop designated tests for the DNS project into
openstack/tempest.

To the point that the interop tooling was developed to support plugins
(which would seem to be in breach of this resolution, but I am sure
there is reasons for this.)

I do want to have option 3 (interop-tempest-plugin), but right now I
will settle for us either:

A: Doing what we planned on before (Option 1) (Prefered)
B: Documenting the fact that things have changed (Option 2), and
   articulate and record the reasoning for the change.

I think Add Ons are going to the Board in Dublin for the change from
Advisory, in the 2018.02 standard so we need to get clarity on this.

- Graham

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



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

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Graham Hayes]

On 18/01/18 16:25, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-01-18 15:33:12 +:



> 
> In the past the QA team agreed to accept trademark-related tests from
> all projects in the tempest repo. Has that changed?
> 

There has not been an explict rejection but in all conversations the
response has been "non core projects are outside the scope of tempest".

Honestly, everytime we have tried to do something to core tempest
we have had major pushback, and I want to clarify this before I or
someone else put in the work of porting the base clients, getting CI
configured*, and proposing the tests to tempest.

- Graham


* With zuulv3 this is *much* easier, so not as big a deal as it once was






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

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Graham Hayes]

On 11/01/18 16:36, Colleen Murphy wrote:
> Hi everyone,
> 
> We have governance review under debate[1] that we need the community's help 
> on.
> The debate is over what recommendation the TC should make to the Interop team
> on where the tests it uses for the OpenStack trademark program should be
> located, specifically those for the new add-on program being introduced. Let 
> me
> badly summarize:
> 
> A couple of years ago we issued a resolution[2] officially recommending that
> the Interop team use solely tempest as its source of tests for capability
> verification. The Interop team has always had the view that the developers,
> being the people closest to the project they're creating, are the best people
> to write tests verifying correct functionality, and so the Interop team 
> doesn't
> maintain its own test suite, instead selecting tests from those written in
> coordination between the QA team and the other project teams. These tests are
> used to validate clouds applying for the OpenStack Powered tag, and since all
> of the projects included in the OpenStack Powered program already had tests in
> tempest, this was a natural fit. When we consider adding new trademark 
> programs
> comprising of other projects, the test source is less obvious. Two examples 
> are
> designate, which has never had tests in the tempest repo, and heat, which
> recently had its tests removed from the tempest repo.
> 



> 
> As I'm not deeply steeped in the history of either the Interop or QA teams I 
> am
> sure I've misrepresented some details here, I'm sorry about that. But we'd 
> like
> to get this resolution moving forward and we're currently stuck, so this 
> thread
> is intended to gather enough community input to get unstuck and avoid letting
> this proposal become stale. Please respond to this thread or comment on the
> resolution proposal[1] if you have any thoughts.
> 
> Colleen
> 
> [1] https://review.openstack.org/#/c/521602
> [2] 
> https://governance.openstack.org/tc/resolutions/20160504-defcore-test-location.html
> [3] 
> https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
> 

I had hoped for more of a discussion on this before I jumped back into
this debate  - but it seams to be stalled still, so here it goes.

I proposed this initially as we were unclear on where the tests should
go - we had a resolution that said all tests go into openstack/tempest
(with a list of reasons why), and the guidance and discussion that been
had in various summits was that "add-ons" should stay in plugins.

So right now, we (by the governance rules) should be pushing tests to
tempest for the new programs.

In the resolution that placed the tests in tempest there was a few
reasons proposed:

  For example, API and behavioral changes must be carefully managed, as
  must mundane aspects such as test and module naming and location
  within the test suite. Even changes that leave tests functionally
  equivalent may cause unexpected consequences for their use in DefCore
  processes and validation. Placing the tests in a central repository
  will make it easier to maintain consistency and avoid breaking the
  trademark enforcement tool.

This still applies, and even more so for teams that traditionally do not
have a strong QE contributor / reviewer base (aka projects not in
"core").

  Centralizing the tests also makes it easier for anyone running the
  validation tool against their cloud or cloud distribution to use the
  tests. It is easier to install the test suite and its dependencies,
  and it is easier to read and understand a set of tests following a
  consistent implementation pattern.

Apparently users do not need central tests anymore, feedback from
RefStack is that people who run these tests are comfortable dealing
with extra python packages.

The point about a single set of tests, in a single location and style
still stands.

  Finally, having the tests in a central location makes it easier to
  ensure that all members of the community have equal input into what
  the tests do and how they are implemented and maintained.

Seems like a good value to strive for.

One of the items that has been used to push back against adding
"add-ons" to tempest has been that tempest has a defined scope, and
neither of the current add-ons fit in that scope.

Can someone clarify what the set of criteria is? I think it will help
this discussion.

Another push back is the "scaling" issue - adding more tests will
overload the QA team.

Right now, DNS adds 10 tests, Orchestration adds 22, to a current suite
of 353.

I do not think there is many other add-ons proposed yet, and the new
Vertical programs will probably mainly be re-using tests in the
openstack/tempest repos as is.

This is not a big tent-esque influx of programs - the only projects
that can be added to the trademarks are programs in tc-approved-release
[4], so I do not see scaling as a big issue, especially as these tests
are such base concepts that 

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Graham Hayes]

On 12/01/18 09:49, Luigi Toscano wrote:
> On Thursday, 11 January 2018 23:52:00 CET Matt Riedemann wrote:
>> On 1/11/2018 10:36 AM, Colleen Murphy wrote:
>>> 1) All trademark-related tests should go in the tempest repo, in
>>> accordance
>>>
>>> with the original resolution. This would mean that even projects that
>>> have
>>> never had tests in tempest would now have to add at least some of
>>> their
>>> black-box tests to tempest.
>>>
>>> The value of this option is that centralizes tests used for the Interop
>>> program in a location where interop-minded folks from the QA team can
>>> control them. The downside is that projects that so far have avoided
>>> having a dependency on tempest will now lose some control over the
>>> black-box tests that they use for functional and integration that would
>>> now also be used for trademark certification.
>>> There's also concern for the review bandwidth of the QA team - we can't
>>> expect the QA team to be continually responsible for an ever-growing list
>>> of projects and their trademark tests.
>>
>> How many tests are we talking about for designate and heat? Half a
>> dozen? A dozen? More?
>>
>> If it's just a couple of tests per project it doesn't seem terrible to
>> have them live in Tempest so you get the "interop eye" on reviews, as
>> noted in your email. If it's a considerable amount, then option 2 seems
>> the best for the majority of parties.
> 
> I would argue that it does not scale; what if some test is taken out from the 
> interoperability, and others are added? It would mean moving tests from one 
> repository to another, with change of paths. I think that the solution 2, 
> where the repository where a test belong and the functionality of a test are 
> not linked, is better.
> 
> Ciao
> 

How is this different from the 6 programs already in tempest?



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

[openstack-dev] [designate] Meeting Next Week + Other Highlights

[Graham Hayes]

Hi All,

I am going to be on vacation next week, and will not be able to run
the weekly IRC meeting. We can either skip, or if someone steps up to
run it we can go ahead.

I will be around enough to do the q3 release.

Also a reminder that the etherpad for planning the PTG in Dublin is
available [1]. We have 2 full days + I am sure we can find a free room /
hallway for the Friday if we run over, so please fill ideas.

Thanks!

- Graham


1 - https://etherpad.openstack.org/p/DUB-designate-PTG-planning




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

Re: [openstack-dev] [designate] state of pdns4 backend

[Graham Hayes]

Hi Ritesh, see in line:

On 08/01/18 23:02, Ritesh Anand wrote:
> Hi Stackers,
> 
> I see that we moved from PowerDNS Backend to PDNS4 backend, I have a few
> questions in that regard:
> 
> 1. Should powerdns 3.4 (with PowerDNS backend) continue to work fine on
> Pike OpenStack?

Yes - as long as powerdns 3.x does not change the DB schema, it should
work fine.

> 2. Why did we change the default backend to BIND9?

There is a mix of pdns packages available across distros - e.g. trusty
had 3.x and xenial had 4.x

The only common backend was bind9 - so we swapped the devstack default
to bind9.

> 3. How feasible is moving from one backend to other? Say if we move from
> PowerDNS to BIND9 backend, if I generate BIND zone files from PowerDNS
> mysql backed, and make necessary designate config changes, is that
> sufficient?

Moving from one to another is not that simple unfortunately. We
currently do not have a way, other than adding a new target with the
new driver type, forcing things to sync on to it (may require some
additional tooling right now), and removing the old target.

> Thanks again for your help!
> 

Any other questions, please ask, here or in #openstack-dns :)

Thanks,

Graham

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




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

Re: [openstack-dev] [api] APIs schema consumption discussion

[Graham Hayes]

On 22/11/17 20:04, Graham Hayes wrote:



> When I was talking to Gil about it, I suggested writing a new sphinx /
> docutils formatter. I am not sure how feasible it would be, but it could
> be possible (as sphinx has the whole page tree in memory when writing it
> out, we may be able to output it in some sort of structured format.
> 
> I would be hesitant to change how we write docs - this change took long
> enough to get in place, and the ability to add / remove bits to suit
> different projects is a good thing. Pages like [1] would be hard to do
> in a standard machine readable format, and I think they definitely make
> the docs better.
> 
> - Graham
> 
> 1 - https://developer.openstack.org/api-ref/compute/#servers-servers
> 
> 

Ok, I have done a quick (read: very rough and hacky) prototype of the
formatter here [1]

It uses the sphinx formatter plugin system, and reads from what we
already have in the api-ref/* folder.

It outputs [2] yaml that describes each endpoint, and the fields in the
request / response.

If there is interest, I can clean up the patch, and look at supporting
microversions.

1 - https://review.openstack.org/#/c/528801/
2 - http://paste.openstack.org/show/629241/

- Graham

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



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

Re: [openstack-dev] [os-api-ref][doc] Adding openstack-doc-core to os-api-ref

[Graham Hayes]

On 04/01/18 15:39, Stephen Finucane wrote:
> I'm not sure what the procedure for this is but here goes.
> 
> I've noticed that the 'os-api-ref' project seems to have its own group
> of cores [1], many of whom are no longer working on OpenStack (at
> least, not full-time), and has a handful of open patches against it
> [2]. Since the doc team has recently changed its scope from writing
> documentation to enabling individual projects to maintain their own
> docs, we've become mainly responsible for projects like 'openstack-doc-
> theme'. Given that the 'os-api-ref' project is a Sphinx thing required
> for multiple OpenStack projects, it seems like something that
> could/should fall into the doc team's remit.
> 
> I'd like to move this project into the remit of the 'openstack-doc-
> core' team, by way of removing the 'os-api-ref-core' group or adding
> 'openstack-doc-core' to the list of included groups. In both cases,
> existing active cores will be retained. Do any of the existing 'os-api-
> ref' cores have any objections to this?

No objection from me

> Stephen
> 
> PS: I'm not sure how this affects things from a release management
> perspective. Are there PTLs for these sorts of projects?

It does seem like a docs tooling thing, so maybe moving it to the docs
project umbrella might be an idea?

> [1] https://review.openstack.org/#/admin/groups/1391,members
> [2] https://review.openstack.org/#/q/project:openstack/os-api-ref+statu
> s:open
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



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

Re: [openstack-dev] [designate] need help with managed resource tenant ID

[Graham Hayes]

On 03/01/18 17:50, Ritesh Anand wrote:
> Hi Stackers,
> 
> Happy new year!!
> 
> I am working around Designate service and have been seeing this warning
> in designate-central.log:
> 2017-12-12 06:25:47.022 31171 WARNING designate.central.service [-]
> Managed Resource Tenant ID is not properly configured
> 
> Looks like the config options:
> [service:central]/managed_resource_tenant_id = "" and
> managed_resource_email = ""
> are being used to hold resources internally created by Designate (namely
> PTR records for FIPs, etc.).
> 
> I need your help in finding a good value for these configurations to
> support in our deployments.
> What are you using?

We have previously used the project ID for the designate service
project. As long as it is an actual unique project, it is fine.

The email is used in the SOA record for reverse DNS zones, and as a
temporary email while we import secondary zones. This means that it
should be a per customer thing, and usually would be the email for the
team running the DNS service.

Thanks,

Graham

> Any suggestions welcome!
> 
> Thanks,
> Ritesh
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



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

Re: [openstack-dev] [tc] [all] TC Report 49

[Graham Hayes]

On 06/12/17 23:33, James E. Blair wrote:
> Chris Dent  writes:
> 
>> The expansion of the Foundation was talked about at the summit in
>> Sydney, but having something happen this quickly was a bit of a
>> surprise, leading to some [questions in
>> IRC](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-05.log.html#t2017-12-05T14:11:33)
>> today. Jonathan Bryce showed up to help answer them.
> 
> I'd like to address a misconception in that IRC log:
> 
> 2017-12-05T14:20:56   it does not take long to create a repo on 
> our infrastructure
> 2017-12-05T14:21:14   though I guess without the name flattening, 
> it would have been an "openstack" repository
> 
> While there's still some work to be done on flattening the namespace for
> existing repos, I think it would be quite straightforward to create a
> repository for a non-openstack project in gerrit with no prefix (or, of
> course, a different prefix).  I don't think that would have been an
> obstacle.
> 
> And regarding this:
> 
> 2017-12-05T15:05:30   i'm not sure how much of infra's ci they could 
> make use of given https://github.com/kata-containers/tests
> 
> I don't see an obstacle to using Zuul right now either -- even before
> they have tests.

It is worth remembering that this is a completely separate project to
OpenStack, with its own governance. They are free not to use our tooling
(and considering a lot of containers work is on github, they may never
use it).

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



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

Re: [openstack-dev] [qa] [patrole] Question regarding Patrole API coverage

[Graham Hayes]

On 29/11/17 15:11, Andrea Frittoli wrote:
> 
> 
> On Wed, Nov 29, 2017 at 2:28 PM Peng Liu  > wrote:
> 
> Hi Team,
> 
> Hi Peng
>  
> 
> I have a question regarding to the API coverage of Patrole.
> Currently, Patrole as a Tempest plugin heavily relys on the Tempest
> code. However, Tempest only contains the API tests for the most
> common APIs of the most common projects(Nova, Neutron, Cinder,
> Glance, Swift, Keystone). 
> 
> So I want to know if it is possible to extend Patrole to:
> 1) test the APIs of the common projects which was not yet covered in
> Tempest.  
> 
> 2) test projects which was not covered in Tempest?
> 
> 
> You can use the Patrole framework to test services not covered by
> Tempest by taking advantage of Tempest plugin mechanism.
> Patrole itself is a Tempest plugin. If you install the plugin of a
> service that includes a service client, you should be able to use it to
> write Patrole tests for that service.
> I believe this has not been done yet by any project though, so there may
> be a few technical bits to be sorted out.

There has been a start with Designate + Neutron [1], it is just underway
now though.

It could cause an issue as all of a sudden the internals of a project's
plugin may need to be a stable interface, which may not be something
they expect.

1 - https://review.openstack.org/#/c/520237/
  
> I don't think Patrole itself will have to be extended, however Patrole
> does not yet include stable APIs.
> If you're going to use Patrole APIs in your project you need to be aware
> that there may be backward incompatible changes happening without a
> deprecation period.
> 
> There are several options on where to host such tests: in a dedicated
> plugin, in the Tempest plugin for the service or in Patrole itself.
> The latter would probably suffer from the same scalability issues that
> lead us to create the plugin mechanism to begin with.
> 
> Andrea Frittoli (andreaf)
>  
> 
> 
> Thanks,
> -- 
> Peng Liu 
> __
> OpenStack Development Mailing 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
> 



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

Re: [openstack-dev] [designate] Meeting Time

[Graham Hayes]

On 22/11/17 17:16, Graham Hayes wrote:
> So, after looking at the responses, we have a winning
> meeting time.
> 
> 14:00 UTC (I propose staying on Wednesday) [1].
> 
> If there is no objections by the end of the week, I will
> update the meeting time on eavesdrop.openstack.org
> 
> Thanks,
> 
> Graham
> 
> 1 -
> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20171129T14=1440
> 

I have submitted [1] to change our meeting time - it will now be

14:00 UTC on Wednesdays in #openstack-meeting

Thanks,

Graham

1 - https://review.openstack.org/#/c/523177/



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

Re: [openstack-dev] [api] APIs schema consumption discussion

[Graham Hayes]

On 16/11/17 01:56, Gilles Dubreuil wrote:
> 
> On 15/11/17 03:07, Doug Hellmann wrote:
>> Excerpts from Gilles Dubreuil's message of 2017-11-14 10:15:02 +1100:
>>> Hi,
>>>
>>> Follow-up conversation from our last "API SIG feedback and discussion
>>> session" at Sydney Summit [1], about APIs schema consumption.
>>>
>>> Let's summarize the current situation.
>>>
>>> Each OpenStack project has an "API-source" folder containing RST files
>>> describing its API structure ([2] for example). Those files are in turn
>>> consumed by the Sphinx library to generate each project's API reference
>>> manual which are then available in the API guide documentation [3]. Such
>>> effort has made the APIs harmoniously consistent across all OpenStack
>>> projects and has also created a "de-facto" API schema.
>>>
>>> While the RST files are used by the documentation, they are not readily
>>> consumable by SDKs. Of course the APIs schema can be extracted by web
>>> crawling the Reference guides, which in turn can be used by any
>>> language. Such approach works [4] and help the Misty project [5] (Ruby
>>> SDK) started with more languages to exploit the same approach.
>>>
>>> Therefore to allow better automation, the next step would be to have the
>>> APIs schema stored directly into each project's repo so the SDKs could
>>> consume them straight from the source. This is why we've started
>>> discussing how to have the schema either extracted from the RST files or
>>> alternatively having the API described directly into its own file. The
>>> latter would provide a different work flow: "Yaml -> RST -> Reference
>>> doco" instead of "RST -> Reference doco -> Yaml".
>>>
>>> So the question at this stage is: "Which of the work flow to choose
>>> from?".
>>>
>>> To clarify the needs, it's important to note that we found out that none
>>> of the SDKs project, besides OSC (OpenStack Client, thanks to Dean),
>>> have full time working teams to maintain each SDK, which besides the
>>> natural structural complexity inherent to the cloud context, makes the
>>> task of keeping a SDK up to date very difficult. Especially as projects
>>> moves forward. Automatically managing Openstack APIs is inevitable for
>>> consumers. Another example/feedback was provided by the presenters of
>>> "AT’s Strategy for Implementing a Next Generation OpenStack Cloud"
>>> session during Sydney Keynotes, as they don't handle the Openstack API
>>> manually!
>>>
>>> APIs consumers and providers, any thoughts?
>>>
>>> [1]
>>> https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20442/api-sig-feedback-and-discussion-session
>>>
>>> [2] https://github.com/openstack/nova/tree/master/api-guide/source
>>> [3] https://developer.openstack.org/api-guide/quick-start/index.html
>>> [4] https://github.com/flystack/openstack-APIs
>>> [5] https://github.com/flystack/misty
>>>
>>> Regards,
>>> Gilles
>> Please do not build something that looks like SOAP based on parsing RST
>> files. Surely we can at least work directly from JSONSchema inputs?
> 
> I'm glad you said that :).
> Working directly from YAML or JSON files (format to be discussed) to
> maintain the schema seems (to me too) the natural approach.
> 
> Meaning every project to change current practice: maintain the schema
> files instead of maintaining RST files.
> I suppose there has been suggestion to do it the other way (parse the
> RST files) because of the latter impact on the current practice, but it
> shouldn't be a blocker.
> 
> Gil
> 

When I was talking to Gil about it, I suggested writing a new sphinx /
docutils formatter. I am not sure how feasible it would be, but it could
be possible (as sphinx has the whole page tree in memory when writing it
out, we may be able to output it in some sort of structured format.

I would be hesitant to change how we write docs - this change took long
enough to get in place, and the ability to add / remove bits to suit
different projects is a good thing. Pages like [1] would be hard to do
in a standard machine readable format, and I think they definitely make
the docs better.

- Graham

1 - https://developer.openstack.org/api-ref/compute/#servers-servers



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

[openstack-dev] [designate] Core Reviewers

[Graham Hayes]

I have decided to start cycling out old core reviewers
who are not as active with new, more active reviewers.

The first change is

- Eric Larson (elarson)
+ Jens Harbott (frickler)

Unfortunately elarson has moved companies, and frickler has been
consistently providing good, regular reviews.

Please welcome Jens to the team, and if Eric can rejoin us in the
future, we can fast track him back to core.

Thanks,

Graham



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

[openstack-dev] [designate] Meeting Time

[Graham Hayes]

So, after looking at the responses, we have a winning
meeting time.

14:00 UTC (I propose staying on Wednesday) [1].

If there is no objections by the end of the week, I will
update the meeting time on eavesdrop.openstack.org

Thanks,

Graham

1 -
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20171129T14=1440



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

[openstack-dev] [all] ujson "drop in" replacement

[Graham Hayes]

Hey all,

There seems to be a lot of "replace oslo.serization / native python json
with UltraJSON (otherwise known as ujson) patches over the last few
weeks.

We should be careful - it is not a drop in replacement. e.g. -

Normal python JSON:

>>> import json
>>> json.dumps({"url":"https://google.com"})
'{"url": "https://google.com"}'

ujson:

>>> import ujson as json
>>> json.dumps({"url":"https://google.com"})
'{"url":"https:\\/\\/google.com"}'

It is not currently in use in many projects:

curl -X POST http://codesearch.openstack.org/api/v1/search -F
q=ujson -F repos='*' -F files="requirements\.txt" -f  -s | jq '.Results
| keys'
[
  "ceilometer",
  "kiloeyes",
  "monasca-common",
  "requirements",
  "rpm-packaging"
]

I personally do not see the point in adding another dependency that has
weird behaviour for an as yet unmeasured performance increase.

- Graham



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

[openstack-dev] [designate] Skipping this weeks meeting

[Graham Hayes]

Hi,

I have a conflict this week with a different meeting.

I would suggest we skip this week unless there is someone who can chair
it in my absence?

Thanks,

Graham



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

Re: [openstack-dev] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Graham Hayes]

On 13/10/17 13:45, Flavio Percoco wrote:
> Greetings,
> 
> Some of you, TC candidates, expressed concerns about diversity and
> inclusiveness
> (or inclusivity, depending on your taste) in your candidacy. I believe
> this is a
> broad, and some times ill-used, topic so, I'd like to know, from y'all,
> how you
> think we could make our community more inclusive. What areas would you
> improve
> first?
> 
> Thank you,
> Flavio
> 
> -- 
> @flaper87
> Flavio Percoco
> 

Honestly, short of the the (already in progress) work to help new
contributors getting on board I do not know what the best way is.

But - that is down to me matching the "stereotypical" software engineer
image people have - I did not have to work as hard to become part of the
community as the people we are trying to encourage to join us will have
to, and have had to already to get to a point where they want to join
us.

So - how could we make our community more inclusive?

Ask, and listen to the problems people joining us in the past have had.
Then use that information to find a solution.
Iterate, find the next problem.
Try to solve it.
Repeat.
Profit?

OK ^ is a bit glib. But, this is not something we are going to solve in
a cycle, or even a year - it will be a long term project, and someone
like me, speaking from a position of privilege, about how to fix it is
*not* how we should try to improve our situation.

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



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

Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

[Graham Hayes]

On 12/10/17 17:51, Zane Bitter wrote:
> (Reminder: we are in the TC election campaigning period, and we all have
> the opportunity to question the candidates. The campaigning period ends
> on Saturday, so make with the questions.)
> 
> 
> In my head, I have a mental picture of who I'm building OpenStack for.
> When I'm making design decisions I try to think about how it will affect
> these hypothetical near-future users. By 'users' here I mean end-users,
> the actual consumers of OpenStack APIs. What will it enable them to do?
> What will they have to work around? I think we probably all do this, at
> least subconsciously. (Free tip: try doing it consciously.)
> 
> So my question to the TC candidates (and incumbent TC members, or anyone
> else, if they want to answer) is: what does the hypothetical OpenStack
> user that is top-of-mind in your head look like? Who are _you_ building
> OpenStack for?
> 
> There's a description of mine in this email, as an example:
> http://lists.openstack.org/pipermail/openstack-dev/2017-October/123312.html
> 
> To be clear, for me at least there's only one wrong answer ("person who
> needs somewhere to run their IRC bouncer"). What's important in my
> opinion is that we have a bunch of people with *different* answers on
> the TC, because I think that will lead to better discussion and
> hopefully better decisions.
> 
> Discuss.
> 
> cheers,
> Zane.
> 

Personally I do not think there is a single "user" persona we can use.

We have users that vary from "I used to use ESXi to get a server, now I
go to https://cloud.example.com/horizon and click "Create" to "I am
deploying a Kubernetes cluster, and I need a base IaaS for network,
compute and storage."

Because of how I have spent most of my time in OpenStack, I think I tend
to be biased towards "integrators" - people writing software that needs
to be generic, to work on a lot of different OpenStack clouds (e.g.
Kubernetes OpenStack Cloud Provider, installers for products that run in
different versions of OpenStack (in cloud) or tools like Terraform /
Ansible that interact with the APIs).

There is no one size / shape fits all OpenStack topology, and that
flexibility is why I can have OpenStack run reliably on a couple of
workstations, and others can scale it to hundreds of thousands of cores.
This unfortunately makes life difficult for people who try to be
generic, or write tools that manage "OpenStack" as a thing, instead of a
style / distro / implementation of OpenStack.


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



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

Re: [openstack-dev] [tc][election] Question for the candidates

[Graham Hayes]

There is one topic I have been pretty vocal about wanting the TC to deal
with - encouraging cross project teams (Docs / QA etc) to start
migrating to providing tooling, rather than direct services to projects.

I am aware I am (re)opening a can of worms, but I think as a community
we have started to move in this direction already (see: Docs, Zuul v3).


On 12/10/17 19:38, Ed Leafe wrote:
> In the past year or so, has there been anything that made you think “I wish 
> the TC would do something about that!” ? If so, what was it, and what would 
> you have wanted the TC to do about it?
> 
> -- Ed Leafe
> 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



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

Re: [openstack-dev] [tc][election] Question for the candidates

[Graham Hayes]

For me "Write down OpenStack principles" [1] signaled the start of an
more open TC. It was writing down principles that I had been told about
verbally when I started working on OpenStack, and had been part of a
"shared understanding" for some people who had been in the community for
a while.

This change solidified them, and put them somewhere we could reference
and highlight new community members.

The follow up patchsets of [2],[3],[4],[5] started to let the community
principles evolve based on things like the Leadership training.

[6] made me happy, as it had been such a long time in the making, and it
represented a community decision, not a TC top down one.

Great question!

- Graham


1 -
https://github.com/openstack/governance/commit/f019d697c6b26a00f4693331b00db9124d91f92e

2 -
https://github.com/openstack/governance/commit/c55816bde73d5085aba70d370577074fbae3016a

3 -
https://github.com/openstack/governance/commit/21041fe8c638e5af4387a5f40184f5f73717e506

4 -
https://github.com/openstack/governance/commit/ec481cb3e1ff88e2d36f72fd9b282e4cc0f015c7

5 -
https://github.com/openstack/governance/commit/ebcfcb6609629967b9e515b9615d8998efd6cbd4


6 -
https://github.com/openstack/governance/commit/9ad8f55ce8c8556fd702059fc8ad90d3b8b0de3f

On 12/10/17 20:42, Clay Gerrard wrote:
> I like a representative democracy.  It mostly means I get a say in which
> other people I have to trust to think deeply about issues which effect
> me and make decisions which I agree (more or less) are of benefit to the
> social groups in which I participate.  When I vote IRL I like to
> consider voting records.  Actions speak louder blah blah.
> 
> To candidates:
> 
> Would you please self select a change (or changes) from
> https://github.com/openstack/governance/ in the past ~12 mo or so where
> they thought the outcome or the discussion/process was particular good
> and explain why you think so?
> 
> It'd be super helpful to me, thanks!
> 
> -Clay
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



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

Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms

[Graham Hayes]

Can I add designate? I will be there to look after the room.

Thanks,

Graham


On Tue, 10 Oct 2017, at 20:20, Kendall Nelson wrote:
> Added :) 
> -Kendall (diablo_rojo)
> 
> On Tue, Oct 10, 2017 at 2:11 AM Spyros Trigazis
>  wrote:>> Magnum - Spyros Trigazis - 
>> 
>>  Thanks!
>> 
>>  On 9 October 2017 at 23:24, Kendall Nelson 
>>  wrote:>>  > Wanted to keep this thread towards the top of inboxes for those 
>> I
>>  > haven't>>  > heard from yet.
>>  >
>>  > About a 1/4 of the way booked, so there are still slots available!>>  >
>>  > -Kendall (diablo_rojo)
>>  >
>>  >
>>  > On Thu, Oct 5, 2017 at 8:50 AM Kendall Nelson
>>  >  wrote:>>  >>
>>  >> Hello :)
>>  >>
>>  >> We have a little over 40 slots available so we should be able to>>  >> 
>> accommodate almost everyone, but it will be a first response
>>  >> first serve>>  >> basis.
>>  >>
>>  >> Logistics: Slots are 40 min long and will have projection set up
>>  >> in them.>>  >> The rooms have a capacity of about 40 people and will be 
>> set up
>>  >> classroom>>  >> style.
>>  >>
>>  >> If you are interested in reserving a spot, just reply directly to
>>  >> me and I>>  >> will put your project on the list. Please let me know if 
>> you want
>>  >> one and>>  >> also include the names and emails anyone that will be 
>> speaking
>>  >> with you.>>  >>
>>  >> When slots run out, they run out.
>>  >>
>>  >> Thanks!
>>  >>
>>  >> -Kendall Nelson (diablo_rojo)
>>  >
>>  >
>>  > _-
>>  > _>>  > OpenStack Development Mailing List (not for usage 
>> questions)
>>  > Unsubscribe: OpenStack-dev-
>>  > requ...@lists.openstack.org?subject:unsubscribe>>  > 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>  >
>> 
>>  ___-
>>  ___>>  OpenStack Development Mailing List (not for usage questions)
>>  Unsubscribe: OpenStack-dev-
>>  requ...@lists.openstack.org?subject:unsubscribe>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> -
> > OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc][election] TC Candidacy

[Graham Hayes]

I would like to submit my candidacy for the Technical Committee for the
upcoming election.

I have been contributing to OpenStack since the Havana cycle [1], mainly in
Designate. I have also sporadically gotten involved with the TC, and its
meetings since Designate applied for incubation all the way back in Atlanta.

I have been PTL for Designate for Mitaka, Newton, Ocata and the Queens
cycle,
and a core for a longer period. I was also PTL for the Global Load Balancing
before it was an unfortunate early casualty of the recent reshuffling within
sponsoring organizations in the community.

As part of previous projects, I was both a developer and a heavy user of
OpenStack. As part of contributing to the Kubernetes OpenStack integration
we ran into a lot of the problems that impact our users, and people who
try to integrate with us.

I believe that we all ready have a great base structure in place to help
OpenStack evolve, and part of that is too have a group of people from
different
companies, backgrounds, genders and cultures to drive the project in the
Technical Committee.

I believe my experience working in a younger, smaller project within
OpenStack is a benefit, along with the experience of working on software
as an
end user of OpenStack I can help us ensure the Technical Committee is
mindful
of the unique challenges these projects and users can face.

I have not traditionally been shy about broaching these topics in the
past [2]
[3][4], but I feel it is time I started follow through, and help guide the
resolution for these questions, and I now have an employeer who is
supportive
of me spending more time in the community.

I do really like this community, and I want us to grow, expand and
evolve the
software we write, without changing what we stand for.

Thank you for taking the time to read this,
Graham Hayes (mugsie)

1 - http://stackalytics.com/?release=all=commits_id=grahamhayes
2 - http://lists.openstack.org/pipermail/openstack-dev/2016-July/099285.html
3 - http://graham.hayes.ie/posts/openstack-designate-where-we-are/
4 - https://review.openstack.org/#/c/312267/ (and related discussion)


0x23BA8E2E.asc
Description: application/pgp-keys


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

[openstack-dev] [Designate] Meeting time

[Graham Hayes]

Hi All,

With a change of contributors, we now have a meeting at a time that is
inconvenient for most people.

I have a new survey for us to try and find a more suitable time here:

https://docs.google.com/forms/d/e/1FAIpQLSeF3P4545zBIxL_PnQnm8GshG2kjgRUylNTNjJCxLUhlDKCDA/viewform

If you are interested in attending the meetings, please fill in the
survey!

Thanks,

Graham



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

Re: [openstack-dev] [Oslo][Designate][Congress] Problem with from_dict overrides and new oslo.context release

[Graham Hayes]

On 09/10/17 18:03, Ben Nemec wrote:
> Hi,
> 
> I brought up the fix[1] I proposed for [2] in the Oslo meeting today,
> and it led to some good discussion that we wanted to take to a broader
> audience.  In particular, the projects that are affected by the bug.
> 
> The oslo.context change I proposed would essentially obsolete the
> from_dict function in the Context object since it would obligate us to
> support all the keys in to_dict in the constructor.  This unfortunately
> implies some rather rigid constraints on the Context object.  We could
> essentially never remove any parameters from the constructor (which at
> some point we want to do for things like "tenant" that are deprecated
> but still present) or risk breaking if someone passed in parameters from
> an old to_dict call.
> 
> The other proposal was to rewrite the existing naive from_dict overrides
> in the affected projects to function more like the from_dict in the base
> class where it explicitly handles only the keys that the constructor
> will recognize.[3]  One benefit of this approach is that it would allow
> the removal of some previous workarounds[4].  This is also cleaner from
> an API perspective as it doesn't impose any new requirements on the
> oslo.context API.  The obvious drawback is that it requires
> project-specific fixes in the affected projects.  We would, of course,
> be happy to help with those fixes though.
> 
> So those are the options we've discussed and my thoughts on them. Please
> feel free to weigh in with any other input you may have.  Thanks.
> 
> -Ben
> 
> 1: https://review.openstack.org/509919
> 2: https://launchpad.net/bugs/1721432
> 3:
> https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L371
> 
> 4:
> https://github.com/openstack/designate/blob/46de766e513cfb97cbfc50b001734e02711517e4/designate/context.py#L42
> 
> 

I am happy to do whatever work is needed on the Designate side for a
good generic solution. We keep running into issues with our custom
`from_dict` so anything I can do to help avoid it would be great.

I put up a change to block 2.19.1 until we can pass the gate [1] with
the new solution

- Graham

1 - https://review.openstack.org/510857

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


0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [ptl][tc] Accessible upgrade support

[Graham Hayes]

On Thu, 5 Oct 2017, at 09:50, Thierry Carrez wrote:
> Matt Riedemann wrote:
> > What's the difference between this tag and the zero-impact-upgrades tag?
> > I guess the accessible one is, can a user still ssh into their VM while
> > the nova compute service is being upgraded. The zero-impact-upgrade one
> > is more to do with performance degradation during an upgrade. I'm not
> > entirely sure what that might look like, probably need operator input.
> > For example, while upgrading, you're live migrating VMs all over the
> > place which is putting extra strain on the network.
> 
> The zero-impact-upgrade tag means no API downtime and no measurable
> impact on performance, while the accessible-upgrade means that while
> there can be API downtime, the resources provisioned are still
> accessible (you can use the VM even if nova-api is down).
> 
> I still think we have too many of those upgrade tags, and amount of
> information they provide does not compensate the confusion they create.
> If you're not clear on what they mean, imagine a new user looking at the
> Software Navigator...
> 
> In particular, we created two paths in the graph:
> * upgrade < accessible-upgrade
> * upgrade < rolling-upgrade < zero-downtime < zero-impact
> 
> I personally would get rid of zero-impact (not sure there is that much
> additional information it conveys beyond zero-downtime).
> 
> If we could make the requirements of accessible-upgrade a part of
> rolling-upgrade, that would also help (single path in the graph, only 3
> "levels"). Is there any of the current rolling-upgrade things (cinder,
> neutron, nova, swift) that would not qualify for accessible-upgrade as
> well ?

Well, there is projects (like designate) that qualify for accessible
upgrade, but not rolling upgrade.

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

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

Re: [openstack-dev] [designate] multi domain usage for handlers

[Graham Hayes]

On 29/09/17 11:39, Kim-Norman Sahm wrote:
> Hi Graham,
> 
> thanks for your answer.
> I want try to extent the nova_fixed handler for our requirements.
> 
> how can i enable a new handler in designate?
> I've defined a new handler section in designate.conf and copied my
> handlername.py file to
> /usr/lib/python2.7/dist-packages/designate/notification_handler but
> designate sink should not use it:
> 
> 2017-09-29 12:19:26.180 12177 WARNING designate.sink.service [-] No
> designate-sink handlers enabled or loaded
> 
> regards
> Kim
> 

If you look at this folder:
https://github.com/openstack/designate/tree/master/contrib/designate-ext-samplehandler


it has an example handler.

You would need to copy that folder, and then write your custom handler.

Then update
https://github.com/openstack/designate/blob/master/contrib/designate-ext-samplehandler/setup.cfg
with the new details, and `pip install` the handler.

Then you can set the enabled handlers to be what ever you set:

https://github.com/openstack/designate/blob/master/contrib/designate-ext-samplehandler/setup.cfg#L28


to be.

Thanks,

Graham
> 
> 
> Kim-Norman Sahm
> Cloud & Infrastructure(OCI)
> 
> noris network AG
> Thomas-Mann-Straße 16-20
> 90471 Nürnberg
> Deutschland
> 
> Tel +49 911 9352 1433
> Fax +49 911 9352 100
> 
> kim-norman.s...@noris.de
> 
> https://www.noris.de - Mehr Leistung als Standard
> Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel
> Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Am 28.09.2017 um 18:54 schrieb Graham Hayes:
>>
>> On 28/09/17 17:06, Kim-Norman Sahm wrote:
>>> Hi,
>>>
>>> i'm currently testing designate and i have a question about the
>>> architecture.
>>> We're using openstack newton with keystone v3 and thus the keystone
>>> domain/project structure.
>>>
>>> I've tried the global nova_fixed and neutron_floating_ip handlers but
>>> all dns records (for each domains/projects) are stored in the same dns
>>> domain (instance1.novafixed.example.com and
>>> anotherinstance.neutronfloatingip.example.com).
>>> is is possible to define a seperate DNS domain for each keystone
>>> domain/project and auto-assign the instances to this domain?
>>> example: openstack domain "customerA.com" with projects "prod" and
>>> "dev". instance1 starts in project "dev" and the dns record is
>>> instance1.dev.customerA.com
>>>
>>> Best regards
>>> Kim
>> Hi Kim,
>>
>> Unfortunately, with the default handlers, there is no way of assigning
>> them to different projects.
>>
>> We also mark any recordsets created by designate-sink as "managed" -
>> this means that normal users cannot modify them, an admin has to update
>> them, with the `--all-projects` and `--edit-managed` flags.
>>
>> The modules provided are only designed to be examples. We expected any
>> users would end up writing their own handlers [0].
>>
>> You should also look at the neutron / designate integration [1] as it
>> may do what you need.
>>
>> Thanks,
>>
>> Graham
>>
>> 0 
>> -https://github.com/openstack/designate/tree/master/contrib/designate-ext-samplehandler
>>
>> 1 
>> -https://docs.openstack.org/ocata/networking-guide/config-dns-int.html#integration-with-an-external-dns-service
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [designate] multi domain usage for handlers

[Graham Hayes]

On 28/09/17 17:06, Kim-Norman Sahm wrote:
> Hi,
> 
> i'm currently testing designate and i have a question about the
> architecture.
> We're using openstack newton with keystone v3 and thus the keystone
> domain/project structure.
> 
> I've tried the global nova_fixed and neutron_floating_ip handlers but
> all dns records (for each domains/projects) are stored in the same dns
> domain (instance1.novafixed.example.com and
> anotherinstance.neutronfloatingip.example.com).
> is is possible to define a seperate DNS domain for each keystone
> domain/project and auto-assign the instances to this domain?
> example: openstack domain "customerA.com" with projects "prod" and
> "dev". instance1 starts in project "dev" and the dns record is
> instance1.dev.customerA.com
> 
> Best regards
> Kim
> 

Hi Kim,

Unfortunately, with the default handlers, there is no way of assigning
them to different projects.

We also mark any recordsets created by designate-sink as "managed" -
this means that normal users cannot modify them, an admin has to update
them, with the `--all-projects` and `--edit-managed` flags.

The modules provided are only designed to be examples. We expected any
users would end up writing their own handlers [0].

You should also look at the neutron / designate integration [1] as it
may do what you need.

Thanks,

Graham

0 -
https://github.com/openstack/designate/tree/master/contrib/designate-ext-samplehandler

1 -
https://docs.openstack.org/ocata/networking-guide/config-dns-int.html#integration-with-an-external-dns-service

> 
> Kim-Norman Sahm
> Cloud & Infrastructure(OCI)
> 
> noris network AG
> Thomas-Mann-Straße 16-20
> 90471 Nürnberg
> Deutschland
> 
> Tel +49 911 9352 1433
> Fax +49 911 9352 100
> 
> kim-norman.s...@noris.de
> 
> https://www.noris.de - Mehr Leistung als Standard
> Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel
> Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


0x23BA8E2E.asc
Description: application/pgp-keys


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

[openstack-dev] [designate] Skip meeting this week

[Graham Hayes]

Hi All,

I have just realised I am double booked for the meeting time this week.

We are in a quiet persiod, so I suggest skipping this weeks meeting.

Thanks,

Graham


0x23BA8E2E.asc
Description: application/pgp-keys


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

[openstack-dev] [Designate] PTL Nomination

[Graham Hayes]

Hi All,

I would like to nominate myself as PTL for the Designate project for the
Queens Cycle.

I have been a developer on the project since Grizzly and served as PTL
for the
Mitaka, Newton and Ocata cycles.

My main aim will be to build up contributors to the project,
while keeping the project stable.

We missed the WSGI App goal, and barely got the python 3.5 goal
complete, so
as we already have all our tempest code in an external repo, I intend to
add
that as a priority.

With the advent of Zuul v3, we have an opportunity to expand our
testing, and
as part of that, we should aim to add more complex scenarios to our testing
like:

1. Mixed Driver environments (one pool using powerDNS, one using Bind)
2. Multi DNS Server environments
3. Upgrade testing

We also need to expand the number of tested drivers, and ensure non free
drivers
have a clear owner, and are tested. We also need to add clear install /
configuration documentation per driver.

Finally, I want to ensure that the optional OpenStack DNS InterOp
program is
implemented, and complete for the next InterOp version.

Thank you for taking the time to read this, and your interest in the
project.

- Graham Hayes


0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [release][monasca][designate][requirements] late library release for monasca-statsd

[Graham Hayes]

On 25/07/17 12:12, Doug Hellmann wrote:
> The monasca team has requested a late release of monasca-statsd.
> As far as I can tell, only other team using the library is designate:
> 
> $ whatuses monasca-statsd
> deb-designate requirements.txt   monasca-statsd>=1.1.0 # 
> Apache-2.0
> designate requirements.txt   monasca-statsd>=1.1.0 # 
> Apache-2.0
> monasca-log-api   requirements.txt   monasca-statsd>=1.1.0 # 
> Apache-2.0
> monasca-notification  requirements.txt   monasca-statsd>=1.1.0 # 
> Apache-2.0
> requirements  global-requirements.txtmonasca-statsd>=1.1.0 # 
> Apache-2.0
> requirements  upper-constraints.txt  monasca-statsd===1.7.0
> rpm-packaging global-requirements.txtmonasca-statsd>=1.1.0 # 
> Apache-2.0
> 
> Can someone from the designate team take a look at the list of changes
> in the proposed release (https://review.openstack.org/#/c/486035) and
> give us some idea of the risk involved in releasing?
> 
> Doug

The difference is just some requirements updates and changing how
the docs display the version.

The requirements match ours, and the docs won't affect us - so
I would say it is a low risk for designate.

➜  monasca-statsd git:(master) git diff
1.7.0..6d416dd8be06587f9d8cf9f5455fd5616294f418
diff --git a/doc/source/conf.py b/doc/source/conf.py
index 20d22e9..9468074 100644
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -176,8 +176,7 @@ html_static_path = ['_static']
 git_cmd = ["git", "log", "--pretty=format:'%ad, commit %h'",
"--date=local",
 "-n1"]
 try:
-html_last_updated_fmt = subprocess.Popen(
-git_cmd, stdout=subprocess.PIPE).communicate()[0].decode()
+html_last_updated_fmt =
subprocess.check_output(git_cmd).decode('utf-8')
 except Exception:
 warnings.warn('Cannot get last updated time from git repository. '
   'Not setting "html_last_updated_fmt".')
diff --git a/test-requirements.txt b/test-requirements.txt
index bec732c..1ad4d50 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -5,9 +5,9 @@ hacking!=0.13.0,<0.14,>=0.12.0 # Apache-2.0
 bandit>=1.1.0 # Apache-2.0
 coverage!=4.4,>=4.0 # Apache-2.0
 mock>=2.0 # BSD
-sphinx!=1.6.1,>=1.5.1 # BSD
+sphinx>=1.6.2 # BSD
 oslosphinx>=4.7.0 # Apache-2.0
 oslotest>=1.10.0 # Apache-2.0
 os-testr>=0.8.0 # Apache-2.0
 testrepository>=0.0.18 # Apache-2.0/BSD
-openstackdocstheme>=1.5.0 # Apache-2.0
+openstackdocstheme>=1.11.0 # Apache-2.0


- Graham

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



0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [oslo.db] [ndb] ndb namespace throughout openstack projects

[Graham Hayes]

On 24/07/17 20:37, Octave J. Orgeron wrote:



>>
>> Rather than having all the projects make use of
>> oslo_db.sqlalchemy.ndb.AutoStringTinyText / AutoStringSize, we add new
>> generic types to oslo.db :
>>
>> oslo_db.sqlalchemy.types.SmallString
>> oslo_db.sqlalchemy.types.String
>>
>> (or similar )
>>
>> Internally, the ndb module would be mapping its implementation for
>> AutoStringTinyText and AutoStringSize to these types.   Functionality
>> would be identical, just the naming convention exported to downstream
>> consuming projects would no longer refer to "ndb." for
>> datatypes.
> 
> I think this would make sense.
> 
>>
> 

> 
> AutoStringSize, you pass two parameters, one being the non-NDB size and
> the second being the NDB size. The point here is where you need to
> reduce the size of the column to fit within the NDB limits, but you want
> to preserve the String varchar type because it might be used in a key,
> index, etc. I only use these in cases where the impacts are very low..
> for example where a column is used for keeping track of status (up,
> down, active, inactive, etc.) that don't require 255 varchars.
> 
> In many cases, the use of these could be removed by simply changing the
> columns to more appropriate types and sizes. There is a tremendous
> amount of wasted space in many of the databases. I'm more than willing
> to help out with this if teams decide they would rather do that instead
> as the long-term solution. Until then, these functions enable the use of
> both with minimal impact.
> 
> Another thing to keep in mind is that the only services that I've had to
> adjust column sizes for are:
> 
> Cinder
> Neutron
> Nova
> Magnum
> 
> The other services that I'm working on like Keystone, Barbican, Murano,
> Glance, etc. only need changes to:
> 
> 1. Ensure that foreign keys are dropped and created in the correct order
> when changing things like indexes, constraints, etc. Many services do
> these proper steps already, there are just cases where this has been
> missed because InnoDB is very forgiving on this. But other databases are
> not.
> 2. Fixing the database migration and sync operations to use oslo.db,
> pass the right parameters, etc. Something that should have been done in
> the first place, but hasn't. So this more of a house cleaning step to
> insure that services are using oslo.db correctly.
> 
> The only other oddball use case is deal with disabling nested
> transactions, where Neutron is the only one that does this.
> 
> On the flip side, here is a short list of services that I haven't had to
> make ANY changes for other than having oslo.db 4.24 or above:
> 
> aodh
> gnocchi
> heat
> ironic
> manila

Which projects are you looking at?

>>
>> 3. it's not clear (I don't even know right now by looking at these
>> reviews) when one would use "AutoStringTinyText" or "AutoStringSize".
>> For example in
>> https://review.openstack.org/#/c/446643/10/nova/db/sqlalchemy/migrate_repo/versions/216_havana.py
>>
>> I see a list of String(255)'s changed to one type or the other without
>> any clear notion why one would use one or the other.  Having names
>> that define simply the declared nature of the type would be most
>> appropriate.
> 
> One has to look at what the column is being used for and decide what
> appropriate remediation steps are. This takes time and one must research
> what kind of data goes in the column, what puts it there, what consumes
> it, and what remediation would have the least amount of impact.
> 

I have been out of the loop for a while - but I thought we were
settling on one database, (MySQL over pgSQL) to ensure that we
no longer had to have weird conditionals in our database layers and
migrations?

Is this something that someone is willing to commit to maintaining for
all projects?

I am just concerned we are adding in more custom code just as we are
trying to indicate that we moving to MySQL (which I understand as MySQL
like DB using an InnoDB based engine e.g. Maria, MySQL, Percona)[1]

- Graham

1 - Thinking about it - should https://review.openstack.org/#/c/427880
refer to InnoDB vs just MySQL ?


0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [all] Cleaning up inactive meetbot channels

[Graham Hayes]

On 19/07/17 20:24, Jeremy Stanley wrote:
> For those who are unaware, Freenode doesn't allow any one user to
> /join more than 120 channels concurrently. This has become a
> challenge for some of the community's IRC bots in the past year,
> most recently the "openstack" meetbot (which not only handles
> meetings but also takes care of channel logging to
> eavesdrop.openstack.org and does the nifty bug number resolution
> some people seem to like).
> 
> I have run some rudimentary analysis and come up with the following
> list of channels which have had fewer than 10 lines said by anyone
> besides a bot over the past three months:
> 
> #craton
> #openstack-api
> #openstack-app-catalog
> #openstack-bareon
> #openstack-cloudpulse
> #openstack-community
> #openstack-cue
> #openstack-diversity
> #openstack-gluon
> #openstack-gslb

This should have been gone a while ago

https://review.openstack.org/#/q/topic:remove-openstack-gslb-irc

> #openstack-ko
> #openstack-kubernetes
> #openstack-networking-cisco
> #openstack-neutron-release
> #openstack-opw
> #openstack-pkg
> #openstack-product
> #openstack-python3
> #openstack-quota
> #openstack-rating
> #openstack-solar
> #openstack-swauth
> #openstack-ux
> #openstack-vmware-nsx
> #openstack-zephyr
> 
> I have a feeling many of these are either no longer needed, or what
> little and infrequent conversation they get used for could just as
> easily happen in a general channel like #openstack-dev or #openstack
> or maybe in the more active channel of their parent team for some
> subteams. Who would miss these if we ceased logging/using them? Does
> anyone want to help by asking around to people who might not see
> this thread, maybe by popping into those channels and seeing if any
> of the sleeping denizens awaken and say they still want to keep it
> around?
> 
> Ultimately we should improve our meetbot deployment to support
> sharding channels across multiple bots, but that will take some time
> to implement and needs volunteers willing to work on it. In the
> meantime we're running with the meetbot present in 120 channels and
> have at least one new channel that desires logging and can't get it
> until we whittle that number down.
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [openstack-ansible][neutron][designate][dns] dns plugin suppressed in neutron.conf.j2 template

[Graham Hayes]

On 30/06/17 13:29, Lawrence J. Albinson wrote:
> Good Afternoon Colleagues,
> 
> I've been working to incorporate dynamic dns/designate updating from
> neutron and nova within an OpenStack-Ansible built environment.
> 
> I note that the dns plugin is explicitly suppressed in the
> openstack-ansible-os_neutron role here:
> 
> https://github.com/openstack/openstack-ansible-os_neutron/blob/master/templates/neutron.conf.j2#L5
> 
> I'm curious to know why this is.

So am I - I filed
https://bugs.launchpad.net/openstack-ansible/+bug/1701609 with them, so
we can follow up.

- Graham

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



0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [openstack-ansible][neutron][designate] Failure trying to set dns_domain from command line

[Graham Hayes]

On 27/06/17 23:53, Lawrence J. Albinson wrote:
> Hi Graham,
> 
> As ever, many thanks for clarifying that. And I shall put in a feature
> request as you suggest.
> 
> In the meantime, presumably the missing pieces that I need are those
> described in:
> 
> https://docs.openstack.org/ocata/networking-guide/config-dns-int.html
> 
> under
> 
> 'Configuring OpenStack Networking for integration with an external
> DNS service'.
> 
> and covering:
> 
> [default]
> external_dns_driver = designate
> 
> [designate]
> url =  etc 
> 
> Kind regards, Lawrence

Yes, that is the right section.

- Graham

> 
> On 27/06/17 16:57, Graham Hayes wrote:
>> On 27/06/17 16:36, Lawrence J. Albinson wrote:
>>> Hi Graham,
>>>
>>> Many thanks for the pointer. I hadn't added dns to the plugin list.
>>>
>>> I did, however, set the following:
>>>
>>> neutron_designate_enabled:  True
>> Ah - unfortunately there is two ways of integrating Neutron + Designate
>>
>> The external DNS plug, which allows you to use "--dns-domain" on a per
>> network basis, and "designate-sink"
>>
>> designate-sink was written before Designate was an official project, and
>> uses notifications. It is very powerful, but requires deployers to
>> write custom plugins for it to work well.
>>
>> What OSA is missing is "neutron external DNS integration" - which is the
>> code that we use for "--dns-domain"
>>
>> If you file a request here it will go on to the to do list:
>>
>> https://blueprints.launchpad.net/openstack-ansible
>>
>> - Graham
>>
>>> I'm wondering if the two together will fix things. I shall know by the 
>>> morning.
>>>
>>> Again, many thanks.
>>>
>>> Kind regards, Lawrence
>>> 
>>> From: Graham Hayes
>>> Sent: 27 June 2017 16:14
>>> To: openstack-dev@lists.openstack.org
>>> Subject: Re: [openstack-dev] [openstack-ansible][neutron][designate] 
>>> Failure trying to set dns_domain from command line
>>>
>>> On 27/06/17 15:01, Lawrence J. Albinson wrote:
>>>> Hello Colleagues,
>>>>
>>>> I am trying to enable dynamic updating of DNSaaS when a port or VM is
>>>> created/deleted.
>>>>
>>>> I have DNSaaS working with Bind9 as the back-end and I am able to
>>>> manually create/update/delete entries with the openstack client and/or
>>>> the designate client and see Bind9 reflect those changes.
>>>>
>>>> However, I am unable to set a dns_domain name for a network from the
>>>> openstack CLI and/or the neutron CLI.
>>>>
>>>> I have tried the following:
>>>>
>>>> neutron net-update --dns-domain example.com
>>>> 64b50baa-acd8-4269-8a3a-767b70c7d18d
>>>> neutron net-update --dns-domain example.com public
>>>> neutron net-update --dns-domain example.com.
>>>> 64b50baa-acd8-4269-8a3a-767b70c7d18d
>>>> neutron net-update --dns-domain example.com. public
>>>>
>>>> The response is always the same, namely:
>>>>
>>>> Unrecognized attribute(s) 'dns_domain'
>>>> Neutron server returns request_ids:
>>>> ['req-be15e08a-b3b0-458c-a045-ffac7ce3ebbd']
>>>>
>>>> Before I go searching through the Neutron source, does anyone know if
>>>> this is a 'hole' in the Neutron API and, if so, has it been fixed after
>>>> the commit point being used by openstack-ansible tag 15.1.3.
>>>>
>>>> Kind regards, Lawrence
>>> Hi Lawrence,
>>>
>>> Did you enable the DNS plugin in neutron?
>>>
>>> Adding "dns" to the list here [0] should enable the --dns-domain
>>> attribute.
>>>
>>> 0 -
>>> https://github.com/openstack/openstack-ansible-os_neutron/blob/15.1.3/defaults/main.yml#L133
>>>
>>> However, it does not look like OpenStack Ansible code supports Neutron
>>> calling Designate to update DNS Recordsets yet.
>>>
>>> It looks like a missing feature - I am not sure how OSA deals with
>>> feature requests, but if you are on IRC they use #openstack-ansible
>>>
>>> Thanks
>>>
>>> - Graham
>>>
>>>
>>>> Lawrence J Albinson
&g

Re: [openstack-dev] [openstack-ansible][neutron][designate] Failure trying to set dns_domain from command line

[Graham Hayes]

On 27/06/17 16:36, Lawrence J. Albinson wrote:
> Hi Graham,
> 
> Many thanks for the pointer. I hadn't added dns to the plugin list.
> 
> I did, however, set the following:
> 
> neutron_designate_enabled:  True

Ah - unfortunately there is two ways of integrating Neutron + Designate

The external DNS plug, which allows you to use "--dns-domain" on a per
network basis, and "designate-sink"

designate-sink was written before Designate was an official project, and
uses notifications. It is very powerful, but requires deployers to
write custom plugins for it to work well.

What OSA is missing is "neutron external DNS integration" - which is the
code that we use for "--dns-domain"

If you file a request here it will go on to the to do list:

https://blueprints.launchpad.net/openstack-ansible

- Graham

> I'm wondering if the two together will fix things. I shall know by the 
> morning.
> 
> Again, many thanks.
> 
> Kind regards, Lawrence
> 
> From: Graham Hayes
> Sent: 27 June 2017 16:14
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [openstack-ansible][neutron][designate] Failure 
> trying to set dns_domain from command line
> 
> On 27/06/17 15:01, Lawrence J. Albinson wrote:
>> Hello Colleagues,
>>
>> I am trying to enable dynamic updating of DNSaaS when a port or VM is
>> created/deleted.
>>
>> I have DNSaaS working with Bind9 as the back-end and I am able to
>> manually create/update/delete entries with the openstack client and/or
>> the designate client and see Bind9 reflect those changes.
>>
>> However, I am unable to set a dns_domain name for a network from the
>> openstack CLI and/or the neutron CLI.
>>
>> I have tried the following:
>>
>> neutron net-update --dns-domain example.com
>> 64b50baa-acd8-4269-8a3a-767b70c7d18d
>> neutron net-update --dns-domain example.com public
>> neutron net-update --dns-domain example.com.
>> 64b50baa-acd8-4269-8a3a-767b70c7d18d
>> neutron net-update --dns-domain example.com. public
>>
>> The response is always the same, namely:
>>
>> Unrecognized attribute(s) 'dns_domain'
>> Neutron server returns request_ids:
>> ['req-be15e08a-b3b0-458c-a045-ffac7ce3ebbd']
>>
>> Before I go searching through the Neutron source, does anyone know if
>> this is a 'hole' in the Neutron API and, if so, has it been fixed after
>> the commit point being used by openstack-ansible tag 15.1.3.
>>
>> Kind regards, Lawrence
> 
> Hi Lawrence,
> 
> Did you enable the DNS plugin in neutron?
> 
> Adding "dns" to the list here [0] should enable the --dns-domain
> attribute.
> 
> 0 -
> https://github.com/openstack/openstack-ansible-os_neutron/blob/15.1.3/defaults/main.yml#L133
> 
> However, it does not look like OpenStack Ansible code supports Neutron
> calling Designate to update DNS Recordsets yet.
> 
> It looks like a missing feature - I am not sure how OSA deals with
> feature requests, but if you are on IRC they use #openstack-ansible
> 
> Thanks
> 
> - Graham
> 
> 
>>
>> Lawrence J Albinson
>>
>>
>>
>> __
>> OpenStack Development Mailing 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
> 



0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [openstack-ansible][neutron][designate] Failure trying to set dns_domain from command line

[Graham Hayes]

On 27/06/17 15:01, Lawrence J. Albinson wrote:
> Hello Colleagues,
> 
> I am trying to enable dynamic updating of DNSaaS when a port or VM is
> created/deleted.
> 
> I have DNSaaS working with Bind9 as the back-end and I am able to
> manually create/update/delete entries with the openstack client and/or
> the designate client and see Bind9 reflect those changes.
> 
> However, I am unable to set a dns_domain name for a network from the
> openstack CLI and/or the neutron CLI.
> 
> I have tried the following:
> 
> neutron net-update --dns-domain example.com
> 64b50baa-acd8-4269-8a3a-767b70c7d18d
> neutron net-update --dns-domain example.com public
> neutron net-update --dns-domain example.com.
> 64b50baa-acd8-4269-8a3a-767b70c7d18d
> neutron net-update --dns-domain example.com. public
> 
> The response is always the same, namely:
> 
> Unrecognized attribute(s) 'dns_domain'
> Neutron server returns request_ids:
> ['req-be15e08a-b3b0-458c-a045-ffac7ce3ebbd']
> 
> Before I go searching through the Neutron source, does anyone know if
> this is a 'hole' in the Neutron API and, if so, has it been fixed after
> the commit point being used by openstack-ansible tag 15.1.3.
> 
> Kind regards, Lawrence

Hi Lawrence,

Did you enable the DNS plugin in neutron?

Adding "dns" to the list here [0] should enable the --dns-domain
attribute.

0 -
https://github.com/openstack/openstack-ansible-os_neutron/blob/15.1.3/defaults/main.yml#L133

However, it does not look like OpenStack Ansible code supports Neutron
calling Designate to update DNS Recordsets yet.

It looks like a missing feature - I am not sure how OSA deals with
feature requests, but if you are on IRC they use #openstack-ansible

Thanks

- Graham


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



0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [openstack-ansible][designate][bind9] Looking for ways to limit users to adding hosts within fixed personal domain

[Graham Hayes]

On 21/06/17 13:26, Lawrence J. Albinson wrote:
> Hi Graham,
> 
> Many thank for your prompt reply; your suggestion is spot on for my current 
> use case. Again, thanks.
> 
> On another note, I see that designate has zone blacklisting that could be 
> used to limit the names of newly created zones using a negative regex. But 
> there is no zone whitelisting. Is there a reason for this?

No particular reason - the use case for blacklists was when we were
running it in a public cloud - we wanted to stop users from creating
zones that could be interpreted as "offical".

We have a "tld" feature which could be used as a sudo whitelist - as
long as you want to restrict users to subdomains of a few pre-decided
zones.

e.g. setting tlds of "cloud.example.com." and "internal.example.com."
will mean that users can only create *.(cloud|internal).example.com.

Thanks,

- Graham


> Kind regards, Lawrence
> 
> Lawrence J Albinson
> 
> From: Graham Hayes
> Sent: 20 June 2017 13:01
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [openstack-ansible][designate][bind9] Looking 
> for ways to limit users to adding hosts within fixed personal domain
> 
> On 20/06/17 12:37, Lawrence J. Albinson wrote:
>> I am trying to find pointers to how I might limit non-privileged users
>> to a single domain when adding hosts to Designate.
>>
>> It is a private OpenStack cloud and each user will have a personal
>> sub-domain of a common organisational domain, like so:
>> fred.organisation.com. and will be able to add hosts such as:
>> www.fred.organisation.com. <http://www.fred.organisation.com.> .
>>
>> (The designate back-end is Bind9.)
>>
>> Any pointers about how to do this would be very gratefully received.
>>
>> Kind regards, Lawrence
>>
>> Lawrence J Albinson
> 
> Sure - there are a few ways to do this, but the simplest would be the
> following:
> 
> (I am assuming the zone is pre-created by the admin when provisioning
> the project)
> 
> In the policy.json file we have controls for what users can do to zones
> [1]
> 
> I would suggest changing
> 
> `create_zone`, `delete_zone`, and `update_zone` to `rule:admin`
> 
> then the admin can create the zone by running
> 
> `openstack zone create --sudo-project-id  --email
> t...@example.com subdomain.example.com.`
> 
> And the zone should be created in the project, and they will have full
> control of the recordsets inside that zone.
> 
> If that does not work, we support "zone transfers"[2] (its a terrible
> name) where the admin can create the new sub zone in the admin project
> and then transfer ownership to the new project.
> 
> 1 -
> https://github.com/openstack/designate/blob/master/etc/designate/policy.json#L43-L56
> 
> 2 -
> https://docs.openstack.org/developer/python-designateclient/shell-v2-examples.html#working-with-zone-transfer
>>
>> __
>> OpenStack Development Mailing 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
> 



0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [openstack-ansible][designate][bind9] Looking for ways to limit users to adding hosts within fixed personal domain

[Graham Hayes]

On 20/06/17 12:37, Lawrence J. Albinson wrote:
> I am trying to find pointers to how I might limit non-privileged users
> to a single domain when adding hosts to Designate.
> 
> It is a private OpenStack cloud and each user will have a personal
> sub-domain of a common organisational domain, like so:
> fred.organisation.com. and will be able to add hosts such as:
> www.fred.organisation.com.  .
> 
> (The designate back-end is Bind9.)
> 
> Any pointers about how to do this would be very gratefully received.
> 
> Kind regards, Lawrence
> 
> Lawrence J Albinson

Sure - there are a few ways to do this, but the simplest would be the
following:

(I am assuming the zone is pre-created by the admin when provisioning
the project)

In the policy.json file we have controls for what users can do to zones
[1]

I would suggest changing

`create_zone`, `delete_zone`, and `update_zone` to `rule:admin`

then the admin can create the zone by running

`openstack zone create --sudo-project-id  --email
t...@example.com subdomain.example.com.`

And the zone should be created in the project, and they will have full
control of the recordsets inside that zone.

If that does not work, we support "zone transfers"[2] (its a terrible
name) where the admin can create the new sub zone in the admin project
and then transfer ownership to the new project.

1 -
https://github.com/openstack/designate/blob/master/etc/designate/policy.json#L43-L56

2 -
https://docs.openstack.org/developer/python-designateclient/shell-v2-examples.html#working-with-zone-transfer
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

[Graham Hayes]

On 19/06/17 16:11, Jay Pipes wrote:
> On 06/16/2017 05:18 AM, Graham Hayes wrote:
>> On 15/06/17 22:35, Ed Leafe wrote:
>>> On Jun 15, 2017, at 3:35 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:
>>>
>>>> For me it's one of the most annoying yet challenging/interesting
>>>> aspects: free software development is as much about community and
>>>> politics as it is actual software development (perhaps more so).
>>>
>>> Another way to look at it is how we see ourselves (as a community)
>>> and how people on the outside see OpenStack. I would imagine that
>>> someone looking at OpenStack for the first time would not care a whit
>>> about governance, repo locations, etc. They would certainly care
>>> about "what do I need to do to use this thing?"
>>>
>>> What we call things isn't confusing to those of us in the community -
>>> well, at least to those of us who take the time to read big long
>>> email threads like this. We need to be clearer in how we represent
>>> OpenStack to outsiders. To that end, I think that limiting the term
>>> "OpenStack" to a handful of the core projects would make things a
>>> whole lot clearer. We can continue to present everything else as a
>>> marketplace, or an ecosystem, or however the more marketing-minded
>>> want to label it, but we should *not* call those projects "OpenStack".
>>>
>>> Now I know, I work on Nova, so I'm expecting responses that "of
>>> course you don't care", or "OpenStack is people, and you're hurting
>>> our feelings!". So flame away!
>>
>> Where to start.
>>
>> Most of the small projects are not complaining about "hurt feelings".
>>
>> If the community want to follow advice from a certain tweet, and limit
>> OpenStack to Nova + its spinouts, we should do that. Just let the rest
>> of us know, so we can either start shutting down the projects, or look
>> at moving the projects to another foundation.
>>
>> Of course we should probably change the OpenStack mission statement,
>> and give the board a heads up that all these project teams they talk
>> about publicly will be going away.
>>
>> And, yes, coming from different project teams does mean that we will
>> have differing views on what should be in OpenStack, and its level of
>> priority - but (in my personal, biased opinion) we should not throw the
>> baby out with the bath water because we cannot find two names to
>> describe things.
> 
> How about Designate become a standalone DNSaaS project that more than
> OpenStack can use? Kubernetes could use Designate as a DNS provider,
> then, in the same way that it can currently use Cinder as a
> PersistenVolume provider.

We already have that. Designate is usable without anything else
(although I would recommend keystone to make it manageable).

Designate is at its core an API that maintains DNS servers. Nearly all
of our current advanced integrations are from other projects to
Designate, and they just use this API.

Kubernetes just doesn't have the concept of external DNS providers
build in yet (there is a incubator project, but it seems new).

> 
> Then there'd be no need to fret about a particular tweet.

Its not just one tweet. (See the parent of my email)

There are already repercussions of not being part of OpenStack for
project teams, and pending on the outcome of this discussion,
potentially more.

Also, Designate was not what I was thinking of when I wrote this,
I am working under the assumption that DNS is a core bit of
infrastructure, and hence would be in any "core". I am thinking
of the myriad of other projects that would then have to start hosting
docs, re-writing functional tests, potentially start building CI
systems.



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




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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

[Graham Hayes]

On 15/06/17 22:35, Ed Leafe wrote:
> On Jun 15, 2017, at 3:35 PM, Jeremy Stanley  wrote:
> 
>> For me it's one of the most annoying yet challenging/interesting
>> aspects: free software development is as much about community and
>> politics as it is actual software development (perhaps more so).
> 
> Another way to look at it is how we see ourselves (as a community) and how 
> people on the outside see OpenStack. I would imagine that someone looking at 
> OpenStack for the first time would not care a whit about governance, repo 
> locations, etc. They would certainly care about "what do I need to do to use 
> this thing?"
> 
> What we call things isn't confusing to those of us in the community - well, 
> at least to those of us who take the time to read big long email threads like 
> this. We need to be clearer in how we represent OpenStack to outsiders. To 
> that end, I think that limiting the term "OpenStack" to a handful of the core 
> projects would make things a whole lot clearer. We can continue to present 
> everything else as a marketplace, or an ecosystem, or however the more 
> marketing-minded want to label it, but we should *not* call those projects 
> "OpenStack".
> 
> Now I know, I work on Nova, so I'm expecting responses that "of course you 
> don't care", or "OpenStack is people, and you're hurting our feelings!". So 
> flame away!

Where to start.

Most of the small projects are not complaining about "hurt feelings".

If the community want to follow advice from a certain tweet, and limit
OpenStack to Nova + its spinouts, we should do that. Just let the rest
of us know, so we can either start shutting down the projects, or look
at moving the projects to another foundation.

Of course we should probably change the OpenStack mission statement,
and give the board a heads up that all these project teams they talk
about publicly will be going away.

And, yes, coming from different project teams does mean that we will
have differing views on what should be in OpenStack, and its level of
priority - but (in my personal, biased opinion) we should not throw the
baby out with the bath water because we cannot find two names to
describe things.

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




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

Re: [openstack-dev] [qa][tc][all] Tempest to reject trademark tests

[Graham Hayes]

On 01/06/17 01:30, Matthew Treinish wrote:
> On Wed, May 31, 2017 at 03:45:52PM +, Jeremy Stanley wrote:
>> On 2017-05-31 15:22:59 + (+), Jeremy Stanley wrote:
>>> On 2017-05-31 09:43:11 -0400 (-0400), Doug Hellmann wrote:
>>> [...]
 it's news to me that they're considering reversing course. If the
 QA team isn't going to continue, we'll need to figure out what
 that means and potentially find another group to do it.
>>>
>>> I wasn't there for the discussion, but it sounds likely to be a
>>> mischaracterization. I'm going to assume it's not true (or much more
>>> nuanced) at least until someone responds on behalf of the QA team.
>>> This particular subthread is only going to go further into the weeds
>>> until it is grounded in some authoritative details.
>>
>> Apologies for replying to myself, but per discussion[*] with Chris
>> in #openstack-dev I'm adjusting the subject header to make it more
>> clear which particular line of speculation I consider weedy.
>>
>> Also in that brief discussion, Graham made it slightly clearer that
>> he was talking about pushback on the tempest repo getting tests for
>> new trademark programs beyond "OpenStack Powered Platform,"
>> "OpenStack Powered Compute" and "OpenStack Powered Object Storage."
> 
> TBH, it's a bit premature to have the discussion. These additional programs do
> not exist yet, and there is a governance road block around this. Right now the
> set of projects that can be used defcore/interopWG is limited to the set of 
> projects in:
> 
> https://governance.openstack.org/tc/reference/tags/tc_approved-release.html

Sure - but that is a solved problem, when the interop committee is
ready to propose them, they can add projects into that tag. Or am I
misunderstanding [1] (again)?

This *is* the time to discuss it, as these programs are aimed as
advisory for the 2018 spec - which means we need to solve these
problems, and soon.

> We had a forum session on it (I can't find the etherpad for the session) which
> was pretty speculative because it was about planning the new programs. Part of
> that discussion was around the feasibility of using tests in plugins and 
> whether
> that would be desirable. Personally, I was in favor of doing that for some of
> the proposed programs because of the way they were organized it was a good 
> fit.
> This is because the proposed new programs were extra additions on top of the
> base existing interop program. But it was hardly a definitive discussion.

Which will create 2 classes of testing for interop programs.

> We will have to have discussions about how we're going to actually implement
> the additional programs when we start to create them, but that's not happening
> yet.
> 

Except it is - at least one team has submitted capabilities, and others
are doing so at the moment.

1 - https://review.openstack.org/#/c/368240/

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




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

Re: [openstack-dev] [qa][tc][all] Tempest to reject trademark tests

[Graham Hayes]

On 31/05/17 16:45, Jeremy Stanley wrote:
> On 2017-05-31 15:22:59 + (+), Jeremy Stanley wrote:
>> On 2017-05-31 09:43:11 -0400 (-0400), Doug Hellmann wrote:
>> [...]
>>> it's news to me that they're considering reversing course. If the
>>> QA team isn't going to continue, we'll need to figure out what
>>> that means and potentially find another group to do it.
>>
>> I wasn't there for the discussion, but it sounds likely to be a
>> mischaracterization. I'm going to assume it's not true (or much more
>> nuanced) at least until someone responds on behalf of the QA team.
>> This particular subthread is only going to go further into the weeds
>> until it is grounded in some authoritative details.
> 
> Apologies for replying to myself, but per discussion[*] with Chris
> in #openstack-dev I'm adjusting the subject header to make it more
> clear which particular line of speculation I consider weedy.
> 
> Also in that brief discussion, Graham made it slightly clearer that
> he was talking about pushback on the tempest repo getting tests for
> new trademark programs beyond "OpenStack Powered Platform,"
> "OpenStack Powered Compute" and "OpenStack Powered Object Storage."

Trademark programs are trademark programs - we should have a unified
process for all of them. Let's not make the same mistakes again by
creating classes of projects / programs. I do not want this to be
a distinction as we move forward.

> [*]  http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-05-31.log.html#t2017-05-31T15:28:07
>  >
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




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

Re: [openstack-dev] [qa] [tc] [all] more tempest plugins (was Re: [tc] [all] TC Report 22)

[Graham Hayes]

On 31/05/17 11:22, Chris Dent wrote:
> On Wed, 31 May 2017, Graham Hayes wrote:
>> On 30/05/17 19:09, Doug Hellmann wrote:
>>> Excerpts from Chris Dent's message of 2017-05-30 18:16:25 +0100:
>>>> Note that this goal only applies to tempest _plugins_. Projects
>>>> which have their tests in the core of tempest have nothing to do. I
>>>> wonder if it wouldn't be more fair for all projects to use plugins
>>>> for their tempest tests?
>>>
>>> All projects may have plugins, but all projects with tests used by
>>> the Interop WG (formerly DefCore) for trademark certification must
>>> place at least those tests in the tempest repo, to be managed by
>>> the QA team [1]. As new projects are added to those trademark
>>> programs, the tests are supposed to move to the central repo to
>>> ensure the additional review criteria are applied properly.
> 
> Thanks for the clarification, Doug. I don't think it changes the
> main thrust of what I was trying to say (more below).
> 
>>> [1]
>>> https://governance.openstack.org/tc/resolutions/20160504-defcore-test-location.html
>>>
>>
>> In the InterOp discussions in Boston, it was indicated that some people
>> on the QA team were not comfortable with "non core" project (even in
>> the InterOp program) having tests in core tempest.
>>
>> I do think that may be a bigger discussion though.
> 
> I'm not suggesting we change everything (because that would take a
> lot of time and energy we probably don't have), but I had some
> thoughts in reaction to this and sharing is caring:
> 
> The way in which the tempest _repo_ is a combination of smoke,
> integration, validation and trademark enforcement testing is very
> confusing to me. If we then lay on top of that the concept of "core"
> and "not core" with regard to who is supposed to put their tests in
> a plugin and who isn't (except when it is trademark related!) it all
> gets quite bewildering.
> 
> The resolution above says: "the OpenStack community will benefit
> from having the interoperability tests used by DefCore in a central
> location". Findability is a good goal so this a reasonable
> assertion, but then the directive to lump those tests in with a
> bunch of other stuff seems off if the goal is to "easier to read and
> understand a set of tests".
> 
> If, instead, Tempest is a framework and all tests are in plugins
> that each have their own repo then it is much easier to look for a
> repo (if there is a common pattern) and know "these are the interop
> tests for openstack" and "these are the integration tests for nova"
> and even "these are the integration tests for the thing we are
> currently describing as 'core'[1]".
> 
> An area where this probably falls down is with validation. How do
> you know which plugins to assemble in order to validate this cloud
> you've just built? Except that we already have this problem now that
> we are requiring most projects to manage their tempest tests as
> plugins. Does it become worse by everything being a plugin?

No - this was the gist of my point last year when I proposed the
plugins first (or plugins for all as I called it at the time).

It actually gets better - for a few reasons.

1. We can have a interop-tempest-plugin (under QA control) where all
   interop tests can go, and be tagged for each standard.
   This is good for many reasons, mainly that the tests are curated,
   and projects cannot change tests without someone from QA-core team
   checking it to make sure it does not break backwards compatibility.

2. With the some interop tests being out of the tempest tree, there is
   a very real possibility of a change in tempest blocking someone
   getting certification - tempest does not gate against plugins
   and has broken interfaces in the past.

3. With the new interop programs, the old definition of "core" is more
   murky - and it is looking more and more like the criteria for
   inclusion in openstack/tempest is "be there from the beginning".

> [1] We really need a better name for this.
100% - but I have tried and failed to find a better descriptor, that
everyone understands.

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

[Graham Hayes]

On 30/05/17 19:09, Doug Hellmann wrote:
> Excerpts from Chris Dent's message of 2017-05-30 18:16:25 +0100:
>>
>> There's no TC meeting this week. Thierry did a second weekly status
>> report[^1]. There will be a TC meeting next week (Tuesday, 6th June
>> at 20:00 UTC) with the intention of discussing the proposals about
>> postgreSQL (of which more below). Here are my comments on pending TC
>> activity that either seems relevant or needs additional input.
>>
>> [^1]: 
>> 
>>
>> # Pending Stuff
>>
>> ## Queens Community Goals
>>
>> Proposals for community-wide goals[^2] for the Queens cycle have started
>> coming in. These are changes which, if approved, all projects are
>> expected to satisfy. In Pike the goals are:
>>
>> * [all control plane APIs deployable as WSGI 
>> apps](https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html)
>> * [supporting Python 
>> 3.5](https://governance.openstack.org/tc/goals/pike/python35.html)
>>
>> The full suite of goals for Queens has not yet been decided.
>> Identifying goals is a community-wide process. Your ideas are
>> wanted.
>>
>> ### Split Tempest Plugins into Separate Repos
>>
>> This goal for Queens is already approved. Any project which manages
>> its tempest tests as a plugin should move those tests into a
>> separate repo. The goal is at[^3]. The review for it[^4] has further
>> discussion on why it is a good idea.
>>
>> The original goal did not provide instructions on how to do it.
>> There is a proposal in progress[^5] to add a link to an etherpad[^6]
>> with instructions.
>>
>> Note that this goal only applies to tempest _plugins_. Projects
>> which have their tests in the core of tempest have nothing to do. I
>> wonder if it wouldn't be more fair for all projects to use plugins
>> for their tempest tests?
> 
> All projects may have plugins, but all projects with tests used by
> the Interop WG (formerly DefCore) for trademark certification must
> place at least those tests in the tempest repo, to be managed by
> the QA team [1]. As new projects are added to those trademark
> programs, the tests are supposed to move to the central repo to
> ensure the additional review criteria are applied properly.
> 
> [1] 
> https://governance.openstack.org/tc/resolutions/20160504-defcore-test-location.html

In the InterOp discussions in Boston, it was indicated that some people
on the QA team were not comfortable with "non core" project (even in
the InterOp program) having tests in core tempest.

I do think that may be a bigger discussion though.

> 
>>
>> ### Two Proposals on Improving Version Discovery
>>
>> Monty has been writing API-WG guidelines about how to properly use
>> the service catalog and do version discovery[^7]. Building from that
>> he's proposed two new goals:
>>
>> * [Add Queens goal to add collection 
>> links](https://review.openstack.org/#/c/468436/)
>> * [Add Queens goal for full discovery 
>> alignment](https://review.openstack.org/#/c/468437/)
>>
>> The first is a small step in the direction of improving version
>> discovery, the second is all the steps to getting all projects
>> supporting proper version discovery, in case we are feeling extra
>> capable.
>>
>> Both of these need review from project contributors, first to see if there
>> is agreement on the strategies, second to see if they are
>> achievable.
>>
>> [^2]: 
>> [^3]: 
>> 
>> [^4]: 
>> [^5]: 
>> [^6]: 
>> [^7]: 
>>
>> ## etcd as a base service
>>
>> etcd has been proposed as a base service[^8]. A "base" service is
>> one that that can be expected to be present in any OpenStack
>> deployment. The hope is that by declaring this we can finally
>> bootstrap the distributed locking, group membership and service
>> liveness functionality that we've been talking about for years. If
>> you want this please say so on the review. You want this.
>>
>> If for some reason you _don't_ want this, then you'll want to
>> register your reasons as soon as possible. The review will merge
>> soon.
>>
>> [^8]: 
>>
>> ## openstack-tc IRC channel
>>
>> With the decrease in the number of TC meetings on IRC there's a plan
>> to have [office hours](https://review.openstack.org/#/c/467256/)
>> where some significant chunk of the TC will be available. Initially
>> this was going to be in the `#openstack-dev` channel but in the
>> hopes of making the logs readable after the fact, a [new channel is
>> proposed](https://review.openstack.org/#/c/467386/).
>>
>> This is likely to pass soon, unless objections are raised. If you
>> have some, please raise them on the review.
>>

Re: [openstack-dev] [tc] [all] TC Report 22

[Graham Hayes]

On 30/05/17 18:16, Chris Dent wrote:
> 
> There's no TC meeting this week. Thierry did a second weekly status
> report[^1]. There will be a TC meeting next week (Tuesday, 6th June
> at 20:00 UTC) with the intention of discussing the proposals about
> postgreSQL (of which more below). Here are my comments on pending TC
> activity that either seems relevant or needs additional input.
> 
> [^1]:
> 
> 
> # Pending Stuff
> 
> ## Queens Community Goals
> 
> Proposals for community-wide goals[^2] for the Queens cycle have started
> coming in. These are changes which, if approved, all projects are
> expected to satisfy. In Pike the goals are:
> 
> * [all control plane APIs deployable as WSGI
> apps](https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html)
> 
> * [supporting Python
> 3.5](https://governance.openstack.org/tc/goals/pike/python35.html)
> 
> The full suite of goals for Queens has not yet been decided.
> Identifying goals is a community-wide process. Your ideas are
> wanted.
> 
> ### Split Tempest Plugins into Separate Repos
> 
> This goal for Queens is already approved. Any project which manages
> its tempest tests as a plugin should move those tests into a
> separate repo. The goal is at[^3]. The review for it[^4] has further
> discussion on why it is a good idea.
> 
> The original goal did not provide instructions on how to do it.
> There is a proposal in progress[^5] to add a link to an etherpad[^6]
> with instructions.
> 
> Note that this goal only applies to tempest _plugins_. Projects
> which have their tests in the core of tempest have nothing to do. I
> wonder if it wouldn't be more fair for all projects to use plugins
> for their tempest tests?

+ 1000. But apparently I am wrong on this.

> 
> ### Two Proposals on Improving Version Discovery
> 
> Monty has been writing API-WG guidelines about how to properly use
> the service catalog and do version discovery[^7]. Building from that
> he's proposed two new goals:
> 
> * [Add Queens goal to add collection
> links](https://review.openstack.org/#/c/468436/)
> * [Add Queens goal for full discovery
> alignment](https://review.openstack.org/#/c/468437/)
> 
> The first is a small step in the direction of improving version
> discovery, the second is all the steps to getting all projects
> supporting proper version discovery, in case we are feeling extra
> capable.
> 
> Both of these need review from project contributors, first to see if there
> is agreement on the strategies, second to see if they are
> achievable.
> 
> [^2]: 
> [^3]:
> 
> 
> [^4]: 
> [^5]: 
> [^6]: 
> [^7]: 
> 
> ## etcd as a base service
> 
> etcd has been proposed as a base service[^8]. A "base" service is
> one that that can be expected to be present in any OpenStack
> deployment. The hope is that by declaring this we can finally
> bootstrap the distributed locking, group membership and service
> liveness functionality that we've been talking about for years. If
> you want this please say so on the review. You want this.
> 
> If for some reason you _don't_ want this, then you'll want to
> register your reasons as soon as possible. The review will merge
> soon.
> 
> [^8]: 
> 
> ## openstack-tc IRC channel
> 
> With the decrease in the number of TC meetings on IRC there's a plan
> to have [office hours](https://review.openstack.org/#/c/467256/)
> where some significant chunk of the TC will be available. Initially
> this was going to be in the `#openstack-dev` channel but in the
> hopes of making the logs readable after the fact, a [new channel is
> proposed](https://review.openstack.org/#/c/467386/).
> 
> This is likely to pass soon, unless objections are raised. If you
> have some, please raise them on the review.
> 
> ## postgreSQL
> 
> The discussions around postgreSQL have yet to resolve. See [last week's
> report](https://anticdent.org/tc-report-21.html) for additional
> information. Because things are blocked and there have been some
> expressions of review fatigue there will be, as mentioned above, a
> TC meeting next week on 6th June, 20:00 UTC. Show up if you have an
> opinion if or how postgreSQL should or should not have a continuing
> presence in OpenStack. Some links:
> 
> * [original proposal documenting the lack of community attention to
>   postgreSQL](https://review.openstack.org/#/c/427880/)
> * [a shorter, less MySQL-oriented
> version](https://review.openstack.org/#/c/465589/)
> * [related email
>  
> thread](http://lists.openstack.org/pipermail/openstack-dev/2017-May/116642.html)
> 
> * [active vs external approaches to RDBMS

Re: [openstack-dev] [Openstack-dev] [Designate]

[Graham Hayes]

On 26/05/17 13:35, Andrea Frittoli wrote:
> On Thu, May 25, 2017 at 5:27 PM Carmine Annunziata
> >
> wrote:
> 
> Hi everyone,
> I integrated Designate in Openstack by devstack, now i'm using the
> new default commands like zone create/delete, etc. I got this problem:
> 
> 
> +--+---+-++++
> | id   | name  | type   
> | serial | status | action |
> 
> +--+---+-++++
> | fd80ab02-c8d7-4b06-9a4a-6026c3ca7a1c | example1.net
> . | PRIMARY | 1495725108 | ERROR  | DELETE |
> | bfd19d7d-b259-4f88-afe0-b56d21d09ebe | example2.net
> . | PRIMARY | 1495726327 | ERROR  | DELETE |
> | a33bf1fc-0112-48de-8f43-51c34845f011 | example1.com
> . | PRIMARY | 1495727006 | ERROR  | CREATE |
> 
> +--+---+-++++
> 
> 
> Hello Carmine,
> 
> I'm not an expect in Designate, but I can recommend you try to have a
> look in designate logs to see why your zone creation fails.
> If you don't find your answer there you could post relevant cli
> commands, log fragments and configuration to a publicly available place
> (e.g. [1]) and ask the ML again.
> 
> andrea

Hi Carmine,

The issue will probably be in the designate-central log, or depending on
what version of designate you are using, the designate-pool-manager or
designate-worker logs.

Thanks,

Graham


> [1] https://paste.openstack.org
> 
> 
> Same on dashboard.
> 
> Cheers,
> -- 
> Carmine
> __
> OpenStack Development Mailing 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
> 



0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [oslo][requirements][designate][cinder] Reverting eventlet version bump

[Graham Hayes]

On 04/04/17 11:11 -0700, Clint Byrum wrote:

Excerpts from Monty Taylor's message of 2017-04-04 12:19:36 -0500:

On 04/04/2017 09:19 AM, Jay S Bryant wrote:
> Monty,
>
> I agree with your approach.  Think we should not break other projects
> with a change like this and the answer thus far has been to just patch
> each project individually to work around the issues introduced by
> eventlet.  So, I support this approach and think Sean would as well.

To follow up with everyone - dims and I spent a bit of time this morning
testing combinations of things, and it seems that master of eventlet
actually also does not fix things - there are some issues that will just
need to be figured out.

The suggested path forward at the moment is to pull designate out of the
requirements-sync process so it can stay pinned at 0.19 while the issues
are sorted out. A patch to bump designate back to 0.20.1 can accompany
the patch to fix it for 0.20.1 - and can be done as people have time,
rather than in a rush.



Has anyone made any attempt to eliminate eventlet from Designate? The
less places it's used, the less problems OpenStack seems to have, IMO.
But I can see on cursory examination it has quite a few services so
perhaps it's just too entrenched?



We looked at this previously, but due to a lack of developer time, we
were did not have the resources.

Personally, I would love to see it gone, but the replacement would need
to be writen, and maintained long term - which we are not in the
position to do right now.

- Graham


__
OpenStack Development Mailing 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] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

[Graham Hayes]

On 24/03/17 08:46 -0700, Antoni Segura Puimedon wrote:



On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:

   On 24/03/17 10:27 -0400, Davanum Srinivas wrote:
   >Folks,
   >
   >As discussed in the etherpad:
   >https://etherpad.openstack.org/p/go-and-containers
   >
   >Here's a request for a repo in OpenStack:
   >https://review.openstack.org/#/c/449641/
   >
   >This request pulls in the existing code from kubernetes/kubernetes
   >repo and preserves the git history too
   >https://github.com/dims/k8s-cloud-provider
   >
   >Anyone interested? please ping me on Slack or IRC and we can continue this
   work.

   Yeah - I would love to continue the provider work on gerrit :)

   Is there a way for us to make sure changes in the k8 master don't
   break our plugin? Or do we need to periodic jobs on the provider repo
   to catch breakages in the plugin interface?


I suppose the options are either:

ask k8s to add select external cloud providers in the CI
Have a webhook in the k8s repo that triggered CI on the OSt infra 
 


Yup - I just want to have us get our ducks in a row before we make a
move.


From our side, we should look at the support matrix of what OpenStack

versions we support, and how we plan on testing them in -infra.



   Thanks, Graham

   >__
   >OpenStack Development Mailing 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] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

[Graham Hayes]

On 24/03/17 10:27 -0400, Davanum Srinivas wrote:

Folks,

As discussed in the etherpad:
https://etherpad.openstack.org/p/go-and-containers

Here's a request for a repo in OpenStack:
https://review.openstack.org/#/c/449641/

This request pulls in the existing code from kubernetes/kubernetes
repo and preserves the git history too
https://github.com/dims/k8s-cloud-provider

Anyone interested? please ping me on Slack or IRC and we can continue this work.


Yeah - I would love to continue the provider work on gerrit :)

Is there a way for us to make sure changes in the k8 master don't
break our plugin? Or do we need to periodic jobs on the provider repo
to catch breakages in the plugin interface?

Thanks, Graham


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