Re: [openstack-dev] [cross-project][nova][cinder][designate][neutron] Common support-matrix.py

[Hayes, Graham]

On 01/03/2017 23:53, Mike Perez wrote:
> Hey all,
>
> I kicked off a thread [1] to start talking about approaches with improving
> vendor discoveribility by improving our Market Place [2]. In order to improve
> our market place, having the projects be more part of the process would allow
> the information to be more accurate of what vendors have good support in the
> respected service.
>
> It was discovered that we have a common solution of using INI files and 
> parsing
> that with a common support-matrix.py script that originated out of nova [3].
> I would like to propose we push this into some common sphinx extension 
> project.
> Are there any suggestions of where that could live?
>
> I've look at how Nova [3][4], Neutron [5][6] and Designate [7][8] are doing
> this today. Nova and Neutron are pretty close, and Designate is a much more
> simplified version. Cinder [9][10] is not using INI files, but instead going
> off the driver classes themselves. Are there any other projects I'm missing?
>
> Cinder and Designate have drivers per row, as oppose to Nova and Neutron
> which have features per row. This makes sense given the difference in drivers
> versus features?
>
> I'm assuming the Designate matrix is saying every driver supports every 
> feature
> in its API? If so, that's so awesome and makes me happy.

yes :) - our drivers are *very* thin and just do zone create / update /
delete, and the rest of the complexity is in Designate.

> I would like to start brainstorming on how we can converge on a common matrix
> table design so things are a bit more consistent and easier for a common
> parsing tool.
>

I think having an os-api-ref for drivers (os-driver-ref ??) is a great
idea. What I would like to see from that is a common data format for
listing drivers, which we could then use for a overall driver "market
place".

What we (designate) store per driver:

Name
Type (Agent vs Zone Transfer)
Status (Which is a dynamic list in the ini file)
Maintainers
Variations (e.g. PowerDNS with MySQL vs pgSQL)
Repo

I want to extend ours to include:

Links to setup / usage docs for that driver.
Links to example pool config snippets.

I understand that ^ may be quite difficult to get right in a generic
way, so if we cannot make it work, we can keep ours separate.

Thanks,

Graham

>
> [1] - 
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html
> [2] - https://www.openstack.org/marketplace/drivers/
> [3] - 
> https://docs.openstack.org/developer/nova/support-matrix.html#operation_maintenance_mode
> [4] - 
> http://git.openstack.org/cgit/openstack/nova/tree/doc/ext/support_matrix.py
> [5] - https://review.openstack.org/#/c/318192/76
> [6] - 
> http://docs-draft.openstack.org/92/318192/76/check/gate-neutron-docs-ubuntu-xenial/48cdeb7//doc/build/html/feature_classification/general_feature_support_matrix.html
> [7] - 
> https://git.openstack.org/cgit/openstack/designate/tree/doc/ext/support_matrix.py
> [8] - https://docs.openstack.org/developer/designate/support-matrix.html
> [9] - https://review.openstack.org/#/c/371169/15
> [10] - 
> http://docs-draft.openstack.org/69/371169/15/check/gate-cinder-docs-ubuntu-xenial/aa1bdb1//doc/build/html/driver_support_matrix.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

Re: [openstack-dev] [all] Small steps for Go

[Hayes, Graham]

On 07/03/2017 13:22, Davanum Srinivas wrote:
> Folks,
>
> Anyone interested? https://etherpad.openstack.org/p/go-and-containers
>
> Thanks,
> Dims
>

The first thing that is required (according to the new guidelines) is
for there to be a technical reason we need to use go, and cannot use
python. [0]

This was the major point thrown at designate when we asked for
permission - if there is now a golang project for the sake of
a golang project, that would seem at odds with these (brand new)
requirements.

The only item in the linked etherpad that would fit that requirement
is the Go Common Lib, which is a requirement for any project who wants
to use go.

Do we want to allow projects innovate, or do we just want Golang in
OpenStack now? I honestly cannot follow what is going on in this area.

0 - 
https://governance.openstack.org/tc/reference/new-language-requirements.html#step-1-use-case-analysis



__
OpenStack Development Mailing 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] Re:add new features in designate-dashboard

[Hayes, Graham]

> From: *Saju M* >
> Date: Tue, Feb 28, 2017 at 11:43 PM
> Subject: add new features in designate-dashboard
> To: gra...@hayes.ie , gra...@managedit.ie
> , graham.ha...@hp.com
> 
> Cc: anu sree >
>
>
> Hi,
>
> We would like to start working on following blueprints. Is it ok to
> create blueprint for this task ?.
> Please approve it, So we can start working on it.
>
> https://blueprints.launchpad.net/designate/+spec/zone-export-support-in-designate-dashboard
> 

Sure, but I would like to personally see a spec about how you intend to 
implement them. We use the specs process in
github.com/openstack/designate-specs - it does not need to very detailed
just an overview of where the panels will be, and what will be on each
form.

I also re-targeted them against the designate-dashboard [0] project.

> https://blueprints.launchpad.net/designate/+spec/zone-import-support-in-designate-dashboard
> 
>
> We care also planing to implement blacklists, Tsigkey, etc-- in dashboard.
> Can I create blueprint for these task ?
> Blueprint or bug, which is suitable for these tasks ?

These would be blueprints, again in the designate-dashboard project.

Thanks!

Graham

In the future, you will get more responses if you email the mailing 
list, and add '[designate]' to the subject - most of the developers have
filters that make sure we see these emails.

0 - https://blueprints.launchpad.net/designate-dashboard

> Thanks,
>
> Regards
> Saju Madhavan
>


__
OpenStack Development Mailing 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] PBR 2.0.0 release *may* cause gate failures

[Hayes, Graham]

On 01/03/2017 13:00, Sean Dague wrote:
> On 03/01/2017 12:26 AM, Tony Breeds wrote:
>> Hi All,
>> Earlier today the release team tagged PBR 2.0.0.  The reason for the 
>> major
>> version bump is because warnerrors has been removed in favor of
>> warning-is-error from sphinx >= 1.5.0.
>>
>> It seems that several projects outside both inside and outside OpenStack have
>> capped pbr <2.0.0 so we can't actually use this release yet.  The 
>> requirements
>> team will work with all projects to remove the cap of pbr in those projects.
>>
>> The good news is that projects using upper-constraints.txt are insulated from
>> this and shouldn't be affected[1].  However upper-constraints.txt isn't 
>> being used
>> by all projects and *those* projects will start seeing
>>
>> ContextualVersionConflicts: (pbr 2.0.0 in gate logs.  It's recommended that
>> those projects add a local ban for pbr and associate it with:
>> https://bugs.launchpad.net/openstack-requirements/+bug/1668848
>>
>> Then once the situation is resolved we can unwind and remove the temporary 
>> caps.
>>
>> Yours Tony.
>>
>> [1] There is at least 1 corner case where the coverage job installed directly
>> from a git URL and therefore that wasn't protected.
>
> So, I feel like we hit a similar issue around Vancouver with a pbr bump.
> Can we stop capping pbr per rule now?
>
> I also wonder if we can grant the release team +2 permissions on
> everything in OpenStack so that fixes like this can be gotten in quickly
> without having to go chase a bunch of teams.

That sounds like a good idea to me.

>   -Sean
>


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

Re: [openstack-dev] [qa] Tempest Stable plugin interface change broke gate

[Hayes, Graham]

On 21/02/2017 15:25, Andrea Frittoli wrote:
> Hi Graham,
>
> sorry about that, and good catch.
> You are right, that's a stable interface so that change should not have
> landed.
>
> andrea
>
> On Tue, Feb 21, 2017 at 2:51 PM Hayes, Graham <graham.ha...@hpe.com
> <mailto:graham.ha...@hpe.com>> wrote:
>
> Hi.
>
> https://review.openstack.org/#/c/434304/ landed yesterday, which was a
> change to the stable interface for tempest plugins.
>
> It also took out the designate gate.
>
> Is this interface stable? - If so, there should have been at least some
> deprecation cycle, notification, or something.
>
> Revert has been proposed - https://review.openstack.org/#/c/436612/
>
> Can someone clarify what the "stable" in "Stable APIs" listed here [1]
> means?
>
> - Graham
>
> 1 -
> 
> https://docs.openstack.org/developer/tempest/plugin.html#stable-tempest-apis-plugins-may-use
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

The revert above still hasn't merged.

The QA team blocked a change that updated HTTP status code, but removed
a stable interface with no deprecation.

The revert needs to land, now, and then the QA team can debate
deprecation / removal.

To stop this happening in the future, can we get tempest to gate on some
tempest plugins?

Just a gate job that runs when any code in the designated stable
sections of tempest change would be incredibly useful.

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] [tc][all][designate] The way forward for Designate

[Hayes, Graham]

For those that are interested, we will have an hour discussion about
how designate can move forward tomorrow (wed 22nd) at the PTG.

We will be in Savannah 3 @ 11:00 for an hour.

Thanks,

Graham

On 09/02/2017 14:22, Hayes, Graham wrote:
> The HTML version of this is here:
> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
>
> I have been asked a few times recently "What is the state of the Designate
> project?", "How is Designate getting on?", and by people who know what is
> happening "What are you going to do about Designate?".
>
> Needless to say, all of this is depressing to me, and the people that I have
> worked with for the last number of years to make Designate a truly useful,
> feature rich project.
>
> *TL;DR;* for this - Designate is not in a sustainable place.
>
> To start out - Designate has always been a small project. DNS does not have
> massive *cool* appeal - its not shiny, pretty, or something you see on the
> front page of HackerNews (unless it breaks - then oh boy do people
> become DNS
> experts).
>
> A line a previous PTL for the project used to use, and I have happily
> robbed is
> "DNS is like plumbing, no one cares about it until it breaks, and then
> you are
> standing knee deep in $expletive". (As an aside, that was the reason we
> chose
> the crocodile as our mascot - its basically a dinosaur, old as dirt, and
> when
> it bites it causes some serious complications).
>
> Unfortunately that comes over into the development of DNS products
> sometimes.
> DNSaaS is a check box on a tender response, an assumption.
>
> We were lucky in the beginning - we had 2 large(ish) public clouds that
> needed
> DNS services, and nothing currently existed in the eco-system, so we got
> funding for a team from a few sources.
>
> We got a ton done in that period - we moved from a v1 API which was
> synchronous to a new v2 async API, we massively increased the amount of DNS
> servers we supported, and added new features.
>
> Unfortunately, this didn't last. Internal priorities within companies
> sponsoring the development changed, and we started to shed contributors,
> which
> happens, however disappointing. Usually when this happens if a project is
> important enough the community will pick up where the previous group
> left off.
>
> We have yet to see many (meaningful) commits from the community though. We
> have some great deployers who will file bugs, and if they can put up patch
> sets - but they are (incredibly valuable and appreciated) tactical
> contributions. A project cannot survive on them, and we are no exception.
>
> So where does that leave us? Let have a look at how many actual commits we
> have had:
>
> Commits per cycle
>
>  +--+-+
>  | Havana   | 172 |
>  +--+-+
>  | Icehouse | 165 |
>  +--+-+
>  | Juno | 254 |
>  +--+-+
>  | Kilo | 340 |
>  +--+-+
>  | Liberty  | 327 |
>  +--+-+
>  | Mitaka   | 246 |
>  +--+-+
>  | Newton   | 299 |
>  +--+-+
>  | Ocata| 98  |
>  +--+-+
>
> Next cycle, we are going to have 2 community goals:
>
> * Control Plane API endpoints deployment via WSGI
> * Python 3.5 functional testing
>
> We would have been actually OK for the tempest one - we were one of the
> first
> external repo based plug-ins with `designate-tempest-plugin`_
>
> For WSGI based APIs, this will be a chunk of work - due to our internal code
> structure splitting out the API is going to be ... an issue. (and I think it
> will be harder than most people expect - anyone using olso.service has
> eventlet imported - I am not sure how that affects running in a WSGI server)
>
> Python 3.5 - I have no idea. We can't even run all our unit tests on python
> 3.5, so I suspect getting functional testing may be an issue. And,
> convincing
> management that re-factoring parts of the code base due to "community goals"
> or a future potential pay-off can be more difficult than it should.
>
>   http://graham.hayes.ie/images/oct-2016-projects-prod.jpg
>
> We now have a situation where the largest "non-core" project [1]_ in the
> tent
> has a tiny number of developers working on it. 42% of deployers are
> evaluating
> Designate, so we should see this start to increase.
>
> How did this happen?
> 
>
> Like most situations, there is no single cause.
>
> Certainly th

[openstack-dev] [qa] Tempest Stable plugin interface change broke gate

[Hayes, Graham]

Hi.

https://review.openstack.org/#/c/434304/ landed yesterday, which was a
change to the stable interface for tempest plugins.

It also took out the designate gate.

Is this interface stable? - If so, there should have been at least some
deprecation cycle, notification, or something.

Revert has been proposed - https://review.openstack.org/#/c/436612/

Can someone clarify what the "stable" in "Stable APIs" listed here [1]
means?

- Graham

1 - 
https://docs.openstack.org/developer/tempest/plugin.html#stable-tempest-apis-plugins-may-use

__
OpenStack Development Mailing 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] [octavia][sdk] service name for octavia

[Hayes, Graham]

On 15/02/2017 15:00, Monty Taylor wrote:
> On 02/14/2017 07:08 PM, Qiming Teng wrote:
>> When reviewing a recent patch that adds openstacksdk support to octavia,
>> I found that octavia is using 'octavia' as its service name instead of
>> 'loadbalancing' or 'loadbalancingv2' or something similar.
>
> Please not loadbalancingv2. As dean says in his email, we should be
> using service_type not service_name for this. And service type should
> not contain a version (please ignore what cinder did for v2 and v3
> entries in the service catalog, it is a pattern that should not happen)

+1000

> All the services should have a version discovery endpoint on their
> unversioned endpoint. If there is a v1 and a v2, then a user looking for
> the loadbalancing service, if they want v2, should be able to get there
> through version discovery.
>
> Also, if you haven't used loadbalancing anywhere yet, can I suggest
> load-balancing instead to match object-store and key-manager?
>
>> The overall suggestion is to use a word/phrase that indicates what a
>> service do instead of the name of the project providing that service.
>>
>> Below is the list of the service types currently supported by
>> openstacksdk:
>>
>> 'alarming',# aodh
>> 'baremetal',   # ironic
>> 'clustering',  # senlin
>> 'compute', # nova
>> 'database',# trove
>> 'identity',# keystone
>> 'image',   # glance
>> 'key-manager', # barbican
>> 'messaging',   # zaqar
>> 'metering',# ceilometer
>> 'network', # neutron
>> 'object-store',   # swift
>> 'octavia',# <--- this is an exception
>> 'orchestration',  # heat
>> 'volume', # cinder
>> 'workflowv2', # mistral
>>
>> While I believe this has been discussed about a year ago, I'm not sure
>> if there are things we missed so I'm brining this issue to a broader
>> audience for discussion.
>>
>> Reference:
>>
>> [1] Patch to python-openstacksdk:
>> https://review.openstack.org/#/c/428414
>> [2] Octavia service naming:
>> http://git.openstack.org/cgit/openstack/octavia/tree/devstack/plugin.sh#n52
>>
>> Regards,
>>  Qiming
>>
>>
>> __
>> OpenStack Development Mailing 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] [all][logos] License for new project mascots

[Hayes, Graham]

Hi,

I did a bit of digging through email, and I *thought* someone had asked
about the license that these logos were being released under. Turns out
it was me, and I don't seem to have gotten a response about it.

So - what license are the new logos / mascots under?

Is the same as the wiki? [1] If not, it could present problems for
people to upload copies of the logo to the wiki, as it assumes all
content is CC-BY.

Thanks

- Graham

1 - https://creativecommons.org/licenses/by/3.0/

__
OpenStack Development Mailing 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] Status of the project

[Hayes, Graham]

On 11/02/17 15:12, Andrea Frittoli wrote:
> 
> 
> On Thu, Feb 9, 2017 at 7:22 PM Hayes, Graham <graham.ha...@hpe.com
> <mailto:graham.ha...@hpe.com>> wrote:
> 
> The HTML version of this is here:
> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
> 
> I have been asked a few times recently "What is the state of the
> Designate
> project?", "How is Designate getting on?", and by people who know
> what is
> happening "What are you going to do about Designate?".



> 
> We also need help from cross project teams - the work done by them is
> brilliant
> but it can be hard for smaller projects to consume. We have had a lot of
> progress since the `Leveller Playing Field`_ debate, but a lot of
> work is
> still optimised for the larger teams who get direct support, or well
> resourced
> teams who can dedicate people to the implementation of plugins / code.
> 
> 
> The QA team is committed to serve every single project in big tent
> community.
> Please reach out to us on IRC in #openstack-qa or add an item to the QA
> meeting agenda.
> We are a rather small team ourselves, so we won't be able to implement
> things on project
> team's behalf, but we'll do our best to help.
> 
> andrea
> 

While this may be the intention, it is definitely not the reality. Some
projects do have the work done for them by the QA team - and as I said,
it is generally the larger teams that could afford to take the load vs
the smaller teams that struggle.

A perfect example happened yesterday.

Grenade was being tested for Ocata -> Pike upgrade, before the jobs on
master was updated. As part of this change Keystone moved from v2 to v3.

This caused an issue in 2 in-tree grenade projects (Nova and Cinder)
due to a behavior difference in the OpenStack CLI [0]

This issue was fixed in tree for these projects, before they knew
there was a problem, but projects that have grenade plugins didn't find
out until our gate failed, and started blocking patches.

This then meant 30-40 mins or so of debugging the logs, finding the bug,
writing a fix, then waiting for the the patch to merge.

I wouldn't even ask for a fix to be coded for us - just an email
with "you need to make sure your grenade plugin adds a role to
the user you create from Pike onwards" would have saved a lot
of time.

I understand that the QA team focuses on the core projects
more - that is just how OpenStack operates, but just being
mindful of projects that use things like devstack, grenade,
tempest etc as plugin may not get the fixes that happen for
the core.

- Graham

0 - https://bugs.launchpad.net/keystone/+bug/1662911


> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://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] [governance][tc][rally] Rally (Re: [rally][release] How rally release version)

[Hayes, Graham]

On 13/02/2017 14:02, Davanum Srinivas wrote:
> Andrey, Rally team,
>
> Do you want Rally to be dropped from Governance and Releases repository?
>
> Thanks,
> Dims
>

While I think the info should be removed from releases if there is no
useful data there, why the removal from governance?

Rally has a single deliverable, with no tags (and as such no expected
release schedule) - I am not sure why governance is mentioned here?

  - Graham

> On Mon, Feb 13, 2017 at 8:17 AM, Jeffrey Zhang  
> wrote:
>> @Andrey, thanks for the explanation.
>>
>> The issue is: how can i know which tag works with certain OpenStack branch?
>> For example, which tag
>> works with OpenStack Ocata release? There is no place recording this.
>>
>> I also found there are some other project do not use "project/releases"
>> project. May they are using
>> the same solution as rally.
>>
>> On Mon, Feb 13, 2017 at 6:14 PM, Andrey Kurilin 
>> wrote:
>>>
>>> Hi Jeffrey,
>>>
>>> Rally team do not use "releases" repo at all, that is why information at
>>> [2] is outdated.
>>> Our release workflow is making a proper tag and pushing it via Gerrit. I
>>> find it more convenient.
>>>
>>>
>>>
>>> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang 
>>> wrote:

 Hey guys,

 I found rally already releases its 0.8.1 tag from[0][1]. But
 I found nothing in openstack/releases project[2]. How rally
 create tag?

 [0] http://tarballs.openstack.org/rally/
 [1] https://github.com/openstack/rally/releases
 [2]
 https://github.com/openstack/releases/blob/master/deliverables/_independent/rally.yaml#L45

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


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

>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Andrey Kurilin.
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>


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

Re: [openstack-dev] [Designate] In what sense is it multi-tenant?

[Hayes, Graham]

On 10/02/17 21:51, Mike Spreitzer wrote:
> In what sense is Designate multi-tenant?  Can it be programmed to give
> different views to different DNS clients?  (If so, how?)
> 
> Thanks,
> Mike

It is multi-tenant as it allows multiple users to use the same
DNS infra, while keeping control of DNS zones limited on a project
by project basis. (think of services like DynECT, Route53, SimpleDNS
etc)

We also have support for "pools" of DNS servers, which could be used to
show different views to different networks, but they are not a per
project thing - they are a global resource (right now).

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

Re: [openstack-dev] [designate] Status of the project

[Hayes, Graham]

On 10/02/17 19:11, Joshua Harlow wrote:
> Fox, Kevin M wrote:
>> I'd say kube-dns and designate are very different technologies.
>>
>> kube-dns is a service discovery mechanism for kubernetes intend to provide 
>> internal k8s resolution. The fact it uses dns to implement service discovery 
>> is kind of an implementation detail, not its primary purpose. There's no 
>> need for private dns management, scaling past the size of the k8s cluster 
>> itself, etc. A much easier problem to solve at the moment.
>>
>> Designate really is a multitenant dns as a service implementation. While it 
>> can be used for service discovery, its not its primary purpose.
>>
>> I see no reason they couldn't share some common pieces, but care should be 
>> given not to just say, lets throw out one for the other, as they really are 
>> different animals.
>>
> 
> Arg, the idea wasn't meant to be that (abandon one for the other), but 
> just to investigate the larger world and maybe we have to adapt our 
> model of `multitenant dns as a service implementation` to be slightly 
> different; so what..., if it means we get to keep contributors and grow 
> a larger community (and partner with others and learn new things and 
> adopt new strategies/designs and push the limits of tech and ...) by 
> doing so then that's IMHO good.
> 

Sure - we are always open to changing out outlook.

There are however huge differences in the problem set between running
authoritative DNS, and service discovery DNS.

In service discovery, you want instant and consistant updates of
records, and is a single user environment - only one user will ever
query those DNS servers. As a result, you are not as resource
constrained when writing the DNS server, and can use slower data
storage systems (like etcd).

Authoritative DNS is accessed by multiple users, and resources per
request really do matter (this is part of the reason we do not have
a user facing DNS server as part of Designate).

The vast majority (all?) of the new DNS projects (especially in the
CNCF) are focused on Service Discovery. It is usually assumed the IaaS
underneath (AWS, Azure etc) have an auth DNS service available to use
(much like VMs are).

Because of this, I do not see a huge amount we can leverage from others,
or a huge amount we can offer others.

>> Thanks,
>> Kevin
>> 
>> From: Jay Pipes [jaypi...@gmail.com]
>> Sent: Friday, February 10, 2017 9:50 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [designate] Status of the project
>>
>> On 02/10/2017 12:21 PM, Joshua Harlow wrote:
>>> Hayes, Graham wrote:
>>>> The HTML version of this is here:
>>>> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
>>>>
>>>> I have been asked a few times recently "What is the state of the
>>>> Designate
>>>> project?", "How is Designate getting on?", and by people who know what is
>>>> happening "What are you going to do about Designate?".
>>>>
>>>> Needless to say, all of this is depressing to me, and the people that
>>>> I have
>>>> worked with for the last number of years to make Designate a truly
>>>> useful,
>>>> feature rich project.
>>>>
>>>> *TL;DR;* for this - Designate is not in a sustainable place.
>>>>
>>>> To start out - Designate has always been a small project. DNS does not
>>>> have
>>>> massive *cool* appeal - its not shiny, pretty, or something you see on
>>>> the
>>>> front page of HackerNews (unless it breaks - then oh boy do people
>>>> become DNS
>>>> experts).
>>>>
>>> Thanks for posting this, I know it was not easy to write...
>>>
>>> Knowing where this is at and the issues. It makes me wonder if it is
>>> worthwhile to start thinking about how we can start to look at 'outside
>>> the openstack' projects for DNS. I believe there is a few that are
>>> similar enough to designate (though I don't know well enough) for
>>> example things like SkyDNS (or others which I believe there are a few).
>>>
>>> Perhaps we need to start thinking outside the openstack 'box' in regards
>>> to NIH syndrome and accept the fact that we as a community may not be
>>> able to recreate the world successfully in all cases (the same could be
>>> said about things like k8s and others).
>>>
>>> If we got out of the mindset of openstack as a thing must have tightly
>>> integrated components (over 

Re: [openstack-dev] [designate] Status of the project

[Hayes, Graham]

On 10/02/17 18:10, Joshua Harlow wrote:
> Jay Pipes wrote:
>> On 02/10/2017 12:21 PM, Joshua Harlow wrote:
>>> Hayes, Graham wrote:
>>>> The HTML version of this is here:
>>>> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
>>>>
>>>> I have been asked a few times recently "What is the state of the
>>>> Designate
>>>> project?", "How is Designate getting on?", and by people who know
>>>> what is
>>>> happening "What are you going to do about Designate?".
>>>>
>>>> Needless to say, all of this is depressing to me, and the people that
>>>> I have
>>>> worked with for the last number of years to make Designate a truly
>>>> useful,
>>>> feature rich project.
>>>>
>>>> *TL;DR;* for this - Designate is not in a sustainable place.
>>>>
>>>> To start out - Designate has always been a small project. DNS does not
>>>> have
>>>> massive *cool* appeal - its not shiny, pretty, or something you see on
>>>> the
>>>> front page of HackerNews (unless it breaks - then oh boy do people
>>>> become DNS
>>>> experts).
>>>>
>>>
>>> Thanks for posting this, I know it was not easy to write...
>>>
>>> Knowing where this is at and the issues. It makes me wonder if it is
>>> worthwhile to start thinking about how we can start to look at 'outside
>>> the openstack' projects for DNS. I believe there is a few that are
>>> similar enough to designate (though I don't know well enough) for
>>> example things like SkyDNS (or others which I believe there are a few).
>>>
>>> Perhaps we need to start thinking outside the openstack 'box' in regards
>>> to NIH syndrome and accept the fact that we as a community may not be
>>> able to recreate the world successfully in all cases (the same could be
>>> said about things like k8s and others).
>>>
>>> If we got out of the mindset of openstack as a thing must have tightly
>>> integrated components (over all else) and started thinking about how we
>>> can be much more loosely coupled (and even say integrating non-python,
>>> non-openstack projects) would that be beneficial (I think it would)?
>>
>> This is already basically what Designate *is today*.
>>
>> http://docs.openstack.org/developer/designate/support-matrix.html
>>
>> Just because something is written in Golang and uses etcd for storage
>> doesn't make it "better" or not NIH.
> 
> Agreed, do those other projects (written in golang, or etcd or other) 
> have communities that are growing; can we ensure better success (and 
> health of our own community) by partnering with them? That was the main 
> point (I don't really care what language they are written in or what 
> storage backend they use).
> 
>>
>> For the record, the equivalent to Designate in k8s land is Kube2Sky, the
>> real difference being that Designate has a whole lot more options when
>> it comes to the DNS drivers and Designate integrates with OpenStack
>> services like Keystone.
>>
> 
> That's cool, thanks; TIL.
> 
>> Also, there's more to cloud DNS services than service discovery, which
>> is what SkyDNS was written for.
> 
> Sure, it was just an example.
> 
> The point was along the lines of if a project in our community is 
> struggling and there is a similar project outside of openstack (that is 
> trying to do similar things) is not struggling; perhaps it's better to 
> partner with that other project and enhance that other project (and then 
> recommend said project as the next-generation of ${whatever_project} was 
> struggling here).

As I said in my reply - there *is* no other project.

> Said evaluation is something that we would likely have to do over time 
> as well (because as from this example, desigate was a larger group once, 
> it is now smaller).
> 
>>
>> 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
> 
> __
> OpenStack Development Mailing 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] Status of the project

[Hayes, Graham]

On 10/02/17 16:39, Alexandra Settle wrote:
> Sorry, I’m top posting to this reply because Outlook is a terrible inline 
> poster.
> 
> Hey Designaters! 
> 
> Have you tried pinging the docs team? (ie: me – Hello! I’m the docs PTL)

Hi - We have in the past, and did not get very far. I know things are
now changing, so expect me to ping you over the next few weeks :)

> Over the last few cycles our team has been able to step in and help with 
> formatting, writing, and organizing documentation. Helping small projects 
> (like OpenStack-Ansible) to fix several of the issues you noted below 
> (install, operations, dev docs). During the Newton cycle I was able to help 
> the OSA team organize their dev docs: 
> http://docs.openstack.org/developer/openstack-ansible/developer-docs/index.html,
>  and as a team we created the Deploy Guide 
> http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/. And 
> for Ocata, we have been working heavily on their operations content: 
> http://docs.openstack.org/developer/openstack-ansible/draft-operations-guide/index.html
>  
> 
> Technical writers do not often have the expertise to provide SME knowledge 
> (that’s your job), but we are experts when it concerns ensuring documentation 
> is in the right place to help new users. And we are the guardians of the 
> Operations Guide.
> 
> I know your conversation is much larger than just fixing documentation, but 
> if we can help, please shout out :) 

Thanks for reaching out, I will definitely shout if need it.

- Graham

> On 2/10/17, 3:53 PM, "Hayes, Graham" <graham.ha...@hpe.com> wrote:
> 
> On 10/02/17 02:40, Jay Pipes wrote:
> > On 02/09/2017 02:19 PM, Hayes, Graham wrote:
> > 
> > 
> >> Where too now then?
> >> ===
> >>
> >> Well, this is where I call out to people who actually use the project -
> >> don't
> >> jump ship and use something else because of the picture I have painted.
> >> We are
> >> a dedicated team, how cares about the project. We just need some help.
> >>
> >> I know there are large telcos who use Designate. I am sure there is 
> tooling,
> >> or docs build up in these companies that could be very useful to the
> >> project.
> >>
> >> Nearly every commercial OpenStack distro has Designate. Some have had 
> it
> >> since
> >> the beginning. Again, developers, docs, tooling, testers, anything and
> >> everything is welcome. We don't need a massive amount of resources - we
> >> are a
> >> small ish, stable, project.
> >>
> >> We need developers with upstream time allocated, and the budget to go 
> to
> >> events
> >> like the PTG - for cross project work, and internal designate road map,
> >> these
> >> events form the core of how we work.
> >>
> >> We also need help from cross project teams - the work done by them is
> >> brilliant
> >> but it can be hard for smaller projects to consume. We have had a lot 
> of
> >> progress since the `Leveller Playing Field`_ debate, but a lot of work 
> is
> >> still optimised for the larger teams who get direct support, or well
> >> resourced
> >> teams who can dedicate people to the implementation of plugins / code.
> >>
> >> As someone I was talking to recently said - AWS is not winning public 
> cloud
> >> because of commodity compute (that does help - a lot), but because of 
> the
> >> added services that make using the cloud, well, cloud like. OpenStack
> >> needs to
> >> decide that either it is just compute, or if it wants the eco-system. 
> [5]_
> >> Designate is far from alone in this.
> > 
> > 
> > 
> > Graham, thank you for the heartfelt post. I may not agree with all your 
> > points, but I know you're coming from the right place and truly want to 
> > see Designate (and OpenStack in general) succeed.
> 
> Thanks for reading - it ended up longer than expected.
> 
> > Your point about smaller projects finding it more difficult to 
> "consume" 
> > help from cross-project teams is an interesting one. When the big tent 
> > was being discussed, I remember the TC specifically discussing a change 
> > for cross-project team focus: moving from a "we do this work for you" 
> > role to a "we h

Re: [openstack-dev] [designate] Status of the project

[Hayes, Graham]

On 10/02/17 17:24, Joshua Harlow wrote:
> Hayes, Graham wrote:
>> The HTML version of this is here:
>> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
>>
>> I have been asked a few times recently "What is the state of the Designate
>> project?", "How is Designate getting on?", and by people who know what is
>> happening "What are you going to do about Designate?".
>>
>> Needless to say, all of this is depressing to me, and the people that I have
>> worked with for the last number of years to make Designate a truly useful,
>> feature rich project.
>>
>> *TL;DR;* for this - Designate is not in a sustainable place.
>>
>> To start out - Designate has always been a small project. DNS does not have
>> massive *cool* appeal - its not shiny, pretty, or something you see on the
>> front page of HackerNews (unless it breaks - then oh boy do people
>> become DNS
>> experts).
>>
> 
> Thanks for posting this, I know it was not easy to write...
> 
> Knowing where this is at and the issues. It makes me wonder if it is 
> worthwhile to start thinking about how we can start to look at 'outside 
> the openstack' projects for DNS. I believe there is a few that are 
> similar enough to designate (though I don't know well enough) for 
> example things like SkyDNS (or others which I believe there are a few).

SkyDNS is a mechanism for service discovery, not a DNS API. In reality
there is very few (if any actually - I am struggling to think of even
one) multi tenant DNS management APIs.

The use of DNS in clouds is more than just having an cli to call to
update DNS entries. Integration's between the cloud components are what
make it useful - Heat / CloudFormation / Terraform resources that can
read info from network ports, floating IPs, load balancers, etc is
where the value comes in.

Combined with the integration in neutron that we (finally) merged
recently, I think we have a compelling case to keep Designate.

Ask most AWS users how much they use route53 - this is what we should
be aiming for with Designate.

> Perhaps we need to start thinking outside the openstack 'box' in regards 
> to NIH syndrome and accept the fact that we as a community may not be 
> able to recreate the world successfully in all cases (the same could be 
> said about things like k8s and others).

sure - this comes back to be "base set" of services that the Arch WG
were looking at. however, having coupled services can be useful, and
having a guaranteed API across clouds (one of our goals afaik) for
basic services (which I would count DNS as) is a big deal.

> If we got out of the mindset of openstack as a thing must have tightly 
> integrated components (over all else) and started thinking about how we 
> can be much more loosely coupled (and even say integrating non-python, 
> non-openstack projects) would that be beneficial (I think it would)?
> 
> -Josh
> 
> 
> 
> __
> OpenStack Development Mailing 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] Status of the project

[Hayes, Graham]

On 10/02/17 15:48, Doug Hellmann wrote:
> Excerpts from Jay Pipes's message of 2017-02-09 21:33:03 -0500:
>> On 02/09/2017 02:19 PM, Hayes, Graham wrote:
>> 
>>
>>> Where too now then?
>>> ===
>>>
>>> Well, this is where I call out to people who actually use the project -
>>> don't
>>> jump ship and use something else because of the picture I have painted.
>>> We are
>>> a dedicated team, how cares about the project. We just need some help.
>>>
>>> I know there are large telcos who use Designate. I am sure there is tooling,
>>> or docs build up in these companies that could be very useful to the
>>> project.
>>>
>>> Nearly every commercial OpenStack distro has Designate. Some have had it
>>> since
>>> the beginning. Again, developers, docs, tooling, testers, anything and
>>> everything is welcome. We don't need a massive amount of resources - we
>>> are a
>>> small ish, stable, project.
>>>
>>> We need developers with upstream time allocated, and the budget to go to
>>> events
>>> like the PTG - for cross project work, and internal designate road map,
>>> these
>>> events form the core of how we work.
>>>
>>> We also need help from cross project teams - the work done by them is
>>> brilliant
>>> but it can be hard for smaller projects to consume. We have had a lot of
>>> progress since the `Leveller Playing Field`_ debate, but a lot of work is
>>> still optimised for the larger teams who get direct support, or well
>>> resourced
>>> teams who can dedicate people to the implementation of plugins / code.
>>>
>>> As someone I was talking to recently said - AWS is not winning public cloud
>>> because of commodity compute (that does help - a lot), but because of the
>>> added services that make using the cloud, well, cloud like. OpenStack
>>> needs to
>>> decide that either it is just compute, or if it wants the eco-system. [5]_
>>> Designate is far from alone in this.
>>
>> 
>>
>> Graham, thank you for the heartfelt post. I may not agree with all your 
>> points, but I know you're coming from the right place and truly want to 
>> see Designate (and OpenStack in general) succeed.
>>
>> Your point about smaller projects finding it more difficult to "consume" 
>> help from cross-project teams is an interesting one. When the big tent 
>> was being discussed, I remember the TC specifically discussing a change 
>> for cross-project team focus: moving from a "we do this work for you" 
>> role to a "we help you do this work for yourself" role. You're correct 
>> that the increase in OpenStack projects meant that the cross-project 
>> teams simply would not be able to continue to be a service to other 
>> teams. This was definitely predicted during the big tent discussions.
>>
>> If I had one piece of advice to give Designate, it would be to 
>> prioritize getting documentation (both installation as well as dev-ref 
>> and operational docs) in good shape. I know writing docs sucks, but docs 
>> are a springboard for users and contributors alike and can have a 
>> multiplying effect that's difficult to overstate. Getting those install 
>> and developer docs started would enable the cross-project docs team to 
>> guide Designate contributors in enhancing and cleaning up the docs and 
>> putting some polish on 'em. Your idea above that maybe some users 
>> already wrote some docs is a good one. Maybe reach out personally to 
>> those telcos and see if they can dig something up that can be the basis 
>> for upstream docs.
>>
>> Best,
>> -jay
>>
> 
> Thank you for bringing this into the open, Graham.
> 
> I think we have several projects that would benefit by transitioning
> from relying solely on vendor contributions to building up the
> deployer/user contributor base. That's a relatively new approach
> for some parts of the OpenStack community, but it's common elsewhere
> in open source projects. The shift is likely to mean some changes
> in the way we organize ourselves, because it may not be reasonable
> to assume user-contributors have large amounts of time to focus on
> long review cycles, traveling to sprints, or the other intensive
> activities that are part of our current routine. (That's not to say
> the Designate team has introduced any of those issues, of course.
> We need to be thinking about removing obstacles for contributors
> across the entire commun

Re: [openstack-dev] [designate] Status of the project

[Hayes, Graham]

On 10/02/17 02:40, Jay Pipes wrote:
> On 02/09/2017 02:19 PM, Hayes, Graham wrote:
> 
> 
>> Where too now then?
>> ===
>>
>> Well, this is where I call out to people who actually use the project -
>> don't
>> jump ship and use something else because of the picture I have painted.
>> We are
>> a dedicated team, how cares about the project. We just need some help.
>>
>> I know there are large telcos who use Designate. I am sure there is tooling,
>> or docs build up in these companies that could be very useful to the
>> project.
>>
>> Nearly every commercial OpenStack distro has Designate. Some have had it
>> since
>> the beginning. Again, developers, docs, tooling, testers, anything and
>> everything is welcome. We don't need a massive amount of resources - we
>> are a
>> small ish, stable, project.
>>
>> We need developers with upstream time allocated, and the budget to go to
>> events
>> like the PTG - for cross project work, and internal designate road map,
>> these
>> events form the core of how we work.
>>
>> We also need help from cross project teams - the work done by them is
>> brilliant
>> but it can be hard for smaller projects to consume. We have had a lot of
>> progress since the `Leveller Playing Field`_ debate, but a lot of work is
>> still optimised for the larger teams who get direct support, or well
>> resourced
>> teams who can dedicate people to the implementation of plugins / code.
>>
>> As someone I was talking to recently said - AWS is not winning public cloud
>> because of commodity compute (that does help - a lot), but because of the
>> added services that make using the cloud, well, cloud like. OpenStack
>> needs to
>> decide that either it is just compute, or if it wants the eco-system. [5]_
>> Designate is far from alone in this.
> 
> 
> 
> Graham, thank you for the heartfelt post. I may not agree with all your 
> points, but I know you're coming from the right place and truly want to 
> see Designate (and OpenStack in general) succeed.

Thanks for reading - it ended up longer than expected.

> Your point about smaller projects finding it more difficult to "consume" 
> help from cross-project teams is an interesting one. When the big tent 
> was being discussed, I remember the TC specifically discussing a change 
> for cross-project team focus: moving from a "we do this work for you" 
> role to a "we help you do this work for yourself" role. You're correct 
> that the increase in OpenStack projects meant that the cross-project 
> teams simply would not be able to continue to be a service to other 
> teams. This was definitely predicted during the big tent discussions.

I remember the same things being discussed. However, that is not what
happened, at least not immediately, and it can be very hard to
motivate yourself to work on things when everytime you ask for help
you get nothing, other than a link to the docs page you have read
a 100 times.

> If I had one piece of advice to give Designate, it would be to 
> prioritize getting documentation (both installation as well as dev-ref 
> and operational docs) in good shape. I know writing docs sucks, but docs 
> are a springboard for users and contributors alike and can have a 
> multiplying effect that's difficult to overstate. Getting those install 
> and developer docs started would enable the cross-project docs team to 
> guide Designate contributors in enhancing and cleaning up the docs and 
> putting some polish on 'em. Your idea above that maybe some users 
> already wrote some docs is a good one. Maybe reach out personally to 
> those telcos and see if they can dig something up that can be the basis 
> for upstream docs.

Yeah, writing docs is hard to do right, and honestly, we have been
trying to just keep up with bugs recently.

The problem for us is, where do things like operational docs go?
There is an ops guide, but it is very hard to see where we could
put content. I am also a firm believer that
docs.openstack.org/developer/ is *not* the place for
end user / ops / etc documentation - its why our docs are so
messy right now.

I have pinged a few people for docs, and am waiting for responses.

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


__
OpenStack Development Mailing 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] Status of the project

[Hayes, Graham]

The HTML version of this is here:
http://graham.hayes.ie/posts/openstack-designate-where-we-are/

I have been asked a few times recently "What is the state of the Designate
project?", "How is Designate getting on?", and by people who know what is
happening "What are you going to do about Designate?".

Needless to say, all of this is depressing to me, and the people that I have
worked with for the last number of years to make Designate a truly useful,
feature rich project.

*TL;DR;* for this - Designate is not in a sustainable place.

To start out - Designate has always been a small project. DNS does not have
massive *cool* appeal - its not shiny, pretty, or something you see on the
front page of HackerNews (unless it breaks - then oh boy do people 
become DNS
experts).

A line a previous PTL for the project used to use, and I have happily 
robbed is
"DNS is like plumbing, no one cares about it until it breaks, and then 
you are
standing knee deep in $expletive". (As an aside, that was the reason we 
chose
the crocodile as our mascot - its basically a dinosaur, old as dirt, and 
when
it bites it causes some serious complications).

Unfortunately that comes over into the development of DNS products 
sometimes.
DNSaaS is a check box on a tender response, an assumption.

We were lucky in the beginning - we had 2 large(ish) public clouds that 
needed
DNS services, and nothing currently existed in the eco-system, so we got
funding for a team from a few sources.

We got a ton done in that period - we moved from a v1 API which was
synchronous to a new v2 async API, we massively increased the amount of DNS
servers we supported, and added new features.

Unfortunately, this didn't last. Internal priorities within companies
sponsoring the development changed, and we started to shed contributors, 
which
happens, however disappointing. Usually when this happens if a project is
important enough the community will pick up where the previous group 
left off.

We have yet to see many (meaningful) commits from the community though. We
have some great deployers who will file bugs, and if they can put up patch
sets - but they are (incredibly valuable and appreciated) tactical
contributions. A project cannot survive on them, and we are no exception.

So where does that leave us? Let have a look at how many actual commits we
have had:

Commits per cycle

 +--+-+
 | Havana   | 172 |
 +--+-+
 | Icehouse | 165 |
 +--+-+
 | Juno | 254 |
 +--+-+
 | Kilo | 340 |
 +--+-+
 | Liberty  | 327 |
 +--+-+
 | Mitaka   | 246 |
 +--+-+
 | Newton   | 299 |
 +--+-+
 | Ocata| 98  |
 +--+-+

Next cycle, we are going to have 2 community goals:

* Control Plane API endpoints deployment via WSGI
* Python 3.5 functional testing

We would have been actually OK for the tempest one - we were one of the 
first
external repo based plug-ins with `designate-tempest-plugin`_

For WSGI based APIs, this will be a chunk of work - due to our internal code
structure splitting out the API is going to be ... an issue. (and I think it
will be harder than most people expect - anyone using olso.service has
eventlet imported - I am not sure how that affects running in a WSGI server)

Python 3.5 - I have no idea. We can't even run all our unit tests on python
3.5, so I suspect getting functional testing may be an issue. And, 
convincing
management that re-factoring parts of the code base due to "community goals"
or a future potential pay-off can be more difficult than it should.

  http://graham.hayes.ie/images/oct-2016-projects-prod.jpg

We now have a situation where the largest "non-core" project [1]_ in the 
tent
has a tiny number of developers working on it. 42% of deployers are 
evaluating
Designate, so we should see this start to increase.

How did this happen?


Like most situations, there is no single cause.

Certainly there may have been fault on the side of the Designate leadership.
We had started out as a small team, and had built a huge amount of trust and
respect based on in person interactions over a few years, which meant that
there was a fair bit of "tribal knowledge" in the heads of a few people, and
that new people had a hard time becoming part of the group.

Also, due to volume of work done by this small group, a lot of users / 
distros
were OK leaving us work - some of us were also running a production 
designate
service during this time, so we knew what we needed to develop, and we had
pretty quick feedback when we made a mistake, or caused a bug. All of this
resulted in the major development cost being funded by two companies, which
left us vulnerable to changes in direction from those companies. Then that
shoe 

Re: [Openstack-operators] [LCOO] Intro to Large Contributing

[Hayes, Graham]

On 09/02/2017 16:37, Jeremy Stanley wrote:
> On 2017-02-09 00:59:52 + (+), UKASICK, ANDREW wrote:
> [...]
>> I'm the mysterious "AndyU" who was chatting with you about a year
>> ago in IRC with questions about how to go about donating hosted
>> cloud resources for use by the Infra team. It's nice to bump into
>> you again! ;-) That idea is still stirring btw, but has been much
>> slower moving than I'd hoped.
> [...]
>
> Always appreciated, and happy to pick that back up if and when
> you're ready.
>
>> I've been having a pretty lengthy conversation with jay Pipes
>> regarding similar questions. You can catch up on that in the
>> thread below this one.
>
> I've been following it closely, and tried not to duplicate
> questions/comments as much as possible.
>
>> LCOO is unlike any other working groups that I'm familiar with in
>> some significant ways. You zero'd in on one of those in your
>> statements above about companies joining as opposed to
>> individuals. In that regard, LCOO is similar to an entity like
>> OSIC.org as opposed to a traditional working group.
> [...]
>
> This is probably where some of the confusion comes in for me; I
> expect it's just one of terminology/semantics. The OpenStack User
> Committee has specifically tied "Active members and contributors to
> functional teams and/or working groups" to its electorate in their
> charter, and also defines working groups as "teams" (which to me
> implies they're made up of individuals, not organizations):
>
> https://governance.openstack.org/uc/reference/charter.html
>
> Maybe LCOO is something other than a "working group" in the formal
> UC sense? Or maybe the organizations who participate in the LCOO
> designate representatives (those LCOO "organization coordinators"
> and "governance board" mentioned in your wiki article) who are the
> actual working group as far as the UC is concerned? I'm just
> concerned if, for example, all employees within AT suddenly become
> part of the UC electorate by way of AT as an organization being an
> active "member" of an official UC working group. The only way I can
> really see this working is if the UC insists that its working groups
> are made up of individuals and not whole organizations.
>
>> Jira provides Kanban boards that can serve as a kind of dashboard
>> allowing us to visualize activity and current status of Community
>> activity. But that activity is still happening in Launchpad,
>> Gerrit, etc.
> [...]
>
> Cool, so it sounds like StoryBoard may work out for you in the
> long-run. It already has kanban and worklist support with optional
> automation tied directly to defect/feature tracking and code review.
> As the current effort to move our community from launchpad.net to
> storyboard.openstack.org progresses over the next couple of
> development cycles, I encourage you to check it out and start
> thinking about whether its features address your needs (or consider
> pitching in on further development there).
>
>> Automating the status updating is something I've begun to discuss
>> within the PWG's "Story Tracker" team. We have the same challenge
>> there.
> [...]
>
> Our hope is that once we get further along with the current
> migration blockers for StoryBoard, we'll implement an "epics"
> concept in it which ties individual stories and their tasksets to
> over-arching efforts where their progress can be tracked more
> holistically.
>
>> BTW, Atlassian has always made their tools free for use by open
>> source projects. Also, although they're commercial products they
>> do provide the source code and allow users to modify it freely
>> which makes them much more open-source-ish than most.
> [...]
>
> 
> Yes, I saw you mention it in the other ML thread. "Free as in beer"
> is a somewhat dirty concept in free software development circles,
> and our community infrastructure similarly eschews gratis services
> like GitHub in favor of libre alternatives (we provide read-only
> mirrors there on request, but don't rely on it in any of our
> automation and officially recommend git.openstack.org which runs
> entirely on free software).
>
> As an author of free software myself I prefer when people use and
> help improve OpenStack rather than supporting commercial/proprietary
> solutions to accomplish the same tasks, and so think it hypocritical
> to not extend the same courtesy to other free software communities
> who are attempting to overcome similar hurdles in their respective
> problem spaces. To quote Harry Tuttle, "We're all in it together."
> 
>
> I understand you'll probably end up using whatever tools you're
> familiar/comfortable with and which help you accomplish your goals,
> I just ask that you keep in mind that publicly recommending non-free
> tools in the service of free software development sets an example.
> OpenStack already has a slightly negative reputation as "not really
> free" in the wider community... one which we're desperately trying
> to overcome, bit by bit.
>

I 

Re: [openstack-dev] [All] IRC Mishaps

[Hayes, Graham]

On 09/02/2017 14:42, Jim Rollenhagen wrote:
> On Thu, Feb 9, 2017 at 8:38 AM, Hayes, Graham <graham.ha...@hpe.com
> <mailto:graham.ha...@hpe.com>> wrote:
>
> On 08/02/2017 20:39, Kendall Nelson wrote:
> > Hello All!
> >
> > So I am sure we've all seen it: people writing terminal commands into
> > our project channels, misusing '/' commands, etc. But have any of you
> > actually done it?
> >
> > If any of you cores, ptls or other upstanding members of our wonderful
> > community have had one of these embarrassing experiences please
> reply! I
> > am writing an article for the SuperUser trying to make us all seem a
> > little more human to people new to the community and new to using IRC.
> > It can be scary asking questions to such a large group of smart people
> > and its even more off putting when we make mistakes in front of them.
> >
> > So please share your stories!
> >
> > -Kendall Nelson (diablo_rojo)
>
> not realizing there is a space at the beginning of a line, and
> typing a '/' command.
>
> I am constantly typing ' /win 10' into channels, or more embarrassingly
> ' /whois '
>
>
> Even more embarassing when you leak your IRC addiction with things like:
>
>  /b 119
>
> :D
>
> // jim
>

yeah, '/win  99>' and people start looking at you weird :)



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

[Hayes, Graham]

On 09/02/2017 13:41, Hayes, Graham wrote:
> On 08/02/2017 20:39, Kendall Nelson wrote:
>> Hello All!
>>
>> So I am sure we've all seen it: people writing terminal commands into
>> our project channels, misusing '/' commands, etc. But have any of you
>> actually done it?
>>
>> If any of you cores, ptls or other upstanding members of our wonderful
>> community have had one of these embarrassing experiences please reply! I
>> am writing an article for the SuperUser trying to make us all seem a
>> little more human to people new to the community and new to using IRC.
>> It can be scary asking questions to such a large group of smart people
>> and its even more off putting when we make mistakes in front of them.
>>
>> So please share your stories!
>>
>> -Kendall Nelson (diablo_rojo)
>
> not realizing there is a space at the beginning of a line, and
> typing a '/' command.
>
> I am constantly typing ' /win 10' into channels, or more embarrassingly
> ' /whois '
>
> - 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
>

I have also had some ... unfortunate ... typos over the years. Changing
one letter of some words can really give a message a completely
different meaning :)

Also, I have '/j #openstack-meeting' and then '#startmeeting' while on a
completely different IRC network, and wondered why I was talking to
myself.

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

[Hayes, Graham]

On 08/02/2017 20:39, Kendall Nelson wrote:
> Hello All!
>
> So I am sure we've all seen it: people writing terminal commands into
> our project channels, misusing '/' commands, etc. But have any of you
> actually done it?
>
> If any of you cores, ptls or other upstanding members of our wonderful
> community have had one of these embarrassing experiences please reply! I
> am writing an article for the SuperUser trying to make us all seem a
> little more human to people new to the community and new to using IRC.
> It can be scary asking questions to such a large group of smart people
> and its even more off putting when we make mistakes in front of them.
>
> So please share your stories!
>
> -Kendall Nelson (diablo_rojo)

not realizing there is a space at the beginning of a line, and
typing a '/' command.

I am constantly typing ' /win 10' into channels, or more embarrassingly
' /whois '

- 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

Re: [openstack-dev] [all][tc][swift][designate] New language addition process has been approved

[Hayes, Graham]

On 08/02/2017 14:56, Flavio Percoco wrote:
> On 19/01/17 11:59 +0100, Flavio Percoco wrote:
>> Greetings,
>>
>> The Technical Committe recently approved a new reference document which
>> describes how new programming languages can be proposed for inclusion as
>> supported languages by OpenStack. The new reference document can be found
>> here[0].
>>
>> I'd like to take this chance not only to share this new process - which in my
>> opinion is a good step forward for the entire community - but to invite other
>> teams to take a stab at it and move forward the inclusion of Go, which is the
>> last language that was discussed for inclusion in the community.
>>
>> I hope folks will find this process useful and that it'll help innovating
>> OpenStack. I'm sure the process is not perfect and that we'll have to refine 
>> it
>> as we go so, let's get going.
>>
>> Thanks everyone,
>> Flavio
>>
>> [0] 
>> https://governance.openstack.org/tc/reference/new-language-requirements.html
>
>
> Hey folks,
>
> Sorry for pressing so much on this but, would it be safe to assume that no one
> from the swift and/or designate team are intereted in proposing golang through
> this process?
>
> That's what I'm assuming at least given the silence on this thread.
>
> Thanks,
> Flavio
>
>

Well, from the designate side, most of the TC was pretty clear
about thinking we did not have a technical reason to use golang.

As I said throughout the drafting of the regulation, it is a lot of
work required up front, and combined with the recent shift of (read
'lack of' ) resources assigned to Designate, we do not have enough
people to cut through the red tape.

I personally still think it is the right direction for us, but it will
not be an ongoing priority for me to get implemented - I will leave the
project priority to the new PTL, but I suspect Tim will be of the same
opinion.

- 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

Re: [openstack-dev] Large Contributing OpenStack Operators working group?

[Hayes, Graham]

On 02/02/2017 20:17, Jay Pipes wrote:
> Hi,
>
> I was told about this group today. I have a few questions. Hopefully
> someone from this team can illuminate me with some answers.
>
> 1) What is the purpose of this group? The wiki states that the team
> "aims to define the use cases and identify and prioritise the
> requirements which are needed to deploy, manage, and run services on top
> of OpenStack. This work includes identifying functional gaps, creating
> blueprints, submitting and reviewing patches to the relevant OpenStack
> projects, contributing to working those items, tracking their completion."
>
> What is the difference between the LCOO and the following existing
> working groups?
>
>   * Large Deployment Team
>   * Massively Distributed Team
>   * Product Working Group
>   * Telco/NFV Working Group
>
> 2) According to the wiki page, only companies that are "Multi-Cloud
> Operator[s] and/or Network Service Provider[s]" are welcome in this
> team. Why is the team called "Large Contributing OpenStack Operators" if
> it's only for Telcos? Further, if this is truly only for Telcos, why
> isn't the Telco/NFV working group appropriate?
>
> 3) Under the "Guiding principles" section of the above wiki, the top
> principle is "Align with the OpenStack Foundation". If this is the case,
> why did the group move its content to the closed Atlassian Confuence
> platform? Why does the group have a set of separate Slack channels
> instead of using the OpenStack mailing lists and IRC channels? Why is
> the OPNFV Jira used for tracking work items for the LCOO agenda?
>
> See https://wiki.openstack.org/wiki/Gluon/Tasks-Ocata for examples.
>
> 4) I see a lot of agenda items around projects like Gluon, Craton,
> Watcher, and Blazar. I don't see any concrete ideas about talking with
> the developers of the key infrastructure services that OpenStack is
> built around. How does the LCOO plan on reaching out to the developers
> of the long-standing OpenStack projects like Nova, Neutron, Cinder, and
> Keystone to drive their shared agenda?
>
> Thanks for reading and (hopefully) answering.
>
> -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
>

The entire wiki page [0] for this group is  worrying.

For example:

 > If a member should fail to continue to meet these minimum criteria 
after joining, their membership may be revoked through an action of the 
board.

and no, that is not the OpenStack board.

 From the etherpad [1] -

 > Reminder that our etherpad documents should document what was 
discussed and our decisions but should not contain organizational 
sensitive information or similar in process items.


It does seem to be not fully "open" by our 4 opens. It says it is under
the user committee - but I do not see it listed on their page [2]


0 - https://wiki.openstack.org/wiki/LCOO
1 - 
https://etherpad.openstack.org/p/Large_Contributing_OpenStack_Operators_Master
2 - https://governance.openstack.org/uc/#working-groups

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

Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests

[Hayes, Graham]

On 29/01/2017 15:45, Davanum Srinivas wrote:
> Graham, Sławek, Joshua,
>
> Please take a look at my attempt:
> https://review.openstack.org/#/c/426576/
>
> Thanks,
> Dims
>

At this point, a full revert seems like the right idea.

There is a few problem with the warning, not just the amount of them.

Previously we have gone out of our way to avoid these issues in
libraries. (e.g. [1])

The stack level also seems wrong to me - it is pointing at the
consuming project not the oslo.context library.

1 - https://review.openstack.org/#/c/275914/ specifically
https://review.openstack.org/#/c/275914/3/oslo_versionedobjects/fields.py 
L311.

> On Sun, Jan 29, 2017 at 7:56 AM, Hayes, Graham <graham.ha...@hpe.com> wrote:
>> On 29/01/17 00:53, Davanum Srinivas wrote:
>>> Graham, Sławek,
>>>
>>> Have you seen this?
>>>
>>> Neutron has/uses a WarningFixture:
>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161
>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70
>>>
>>> Which uses filterwarnings:
>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80
>>>
>>> Where "always" is being used:
>>> https://docs.python.org/2/library/warnings.html
>>>
>>> Which prints warnings every single time.
>>>
>>> So, can we please "fix" it in there quickly?
>>>
>>> Thanks,
>>> Dims
>>
>> This is still a broken release - previously in oslo libraries we have
>> been careful with issuing multiple warnings for a deprecation.
>>
>> This is still an issue, with glance-api [0] and I assume others (e.g. we
>> have not had a designate CI run with the new oslo.context yet)
>>
>> Seen as we are going into RC week, it seems very risky to keep it.
>>
>> 0 -
>> http://logstash.openstack.org/#dashboard/file/logstash.json?query=_id%3A%5C%22AVnnYuy3QVJYkPlRPEJH%5C%22
>>
>>> On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński <sla...@kaplonski.pl> 
>>> wrote:
>>>> Hello,
>>>>
>>>> Thanks. I just filled bug report to oslo project:
>>>> https://bugs.launchpad.net/oslo.context/+bug/1660088
>>>>
>>>> --
>>>> Best regards / Pozdrawiam
>>>> Sławek Kapłoński
>>>> sla...@kaplonski.pl
>>>>
>>>> On Sat, 28 Jan 2017, Hayes, Graham wrote:
>>>>
>>>>> On 28/01/17 20:54, Sławek Kapłoński wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I pushed today patch in Neutron to gerrit [1] and I noticed that 
>>>>>> functional
>>>>>> tests are failing. In logs there is huge number of deprecation warnings
>>>>>> displayed [2]. Tests are failing because of global timeout is reached 
>>>>>> and IMO
>>>>>> reason of this timeout is this huge amount of deprecation warnings.
>>>>>> I checked that those warnings are disaplyed when oslo.context==2.12.0 is
>>>>>> installed. With oslo.context==2.11.0 all is fine.
>>>>>> Should it be reported as bug in Neutron or in Oslo project? Or maybe You
>>>>>> already know about it and there is some patch to fix it but I couldn't 
>>>>>> find it?
>>>>>
>>>>> Its an oslo.context bug - I can't see one filed for it yet.
>>>>>>
>>>>>> [1] https://review.openstack.org/#/c/426429/
>>>>>> [2] 
>>>>>> http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html
>>>>>>
>>>>>
>>>>> It looks like the warnings function was miss used - this should be set
>>>>> as a once only message. The stack trace level seems suspect, as it
>>>>> points as neutron/context.py as the one sending out the notice, not
>>>>> oslo.contexts base class.
>>>>>
>>>>> [3] seems to the cause - I would suggest reverting this commit and
>>>>> doing a 2.13.0 release. This is going to be *really* noisy. (logstash
>>>>> has 2.5 million items for this string in the last 24 hours)
>>>>>
>>>>> 3 -
>>>>> https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>


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

Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests

[Hayes, Graham]

On 29/01/17 00:53, Davanum Srinivas wrote:
> Graham, Sławek,
> 
> Have you seen this?
> 
> Neutron has/uses a WarningFixture:
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70
> 
> Which uses filterwarnings:
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80
> 
> Where "always" is being used:
> https://docs.python.org/2/library/warnings.html
> 
> Which prints warnings every single time.
> 
> So, can we please "fix" it in there quickly?
> 
> Thanks,
> Dims

This is still a broken release - previously in oslo libraries we have
been careful with issuing multiple warnings for a deprecation.

This is still an issue, with glance-api [0] and I assume others (e.g. we
have not had a designate CI run with the new oslo.context yet)

Seen as we are going into RC week, it seems very risky to keep it.

0 -
http://logstash.openstack.org/#dashboard/file/logstash.json?query=_id%3A%5C%22AVnnYuy3QVJYkPlRPEJH%5C%22

> On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński <sla...@kaplonski.pl> wrote:
>> Hello,
>>
>> Thanks. I just filled bug report to oslo project:
>> https://bugs.launchpad.net/oslo.context/+bug/1660088
>>
>> --
>> Best regards / Pozdrawiam
>> Sławek Kapłoński
>> sla...@kaplonski.pl
>>
>> On Sat, 28 Jan 2017, Hayes, Graham wrote:
>>
>>> On 28/01/17 20:54, Sławek Kapłoński wrote:
>>>> Hello,
>>>>
>>>> I pushed today patch in Neutron to gerrit [1] and I noticed that functional
>>>> tests are failing. In logs there is huge number of deprecation warnings
>>>> displayed [2]. Tests are failing because of global timeout is reached and 
>>>> IMO
>>>> reason of this timeout is this huge amount of deprecation warnings.
>>>> I checked that those warnings are disaplyed when oslo.context==2.12.0 is
>>>> installed. With oslo.context==2.11.0 all is fine.
>>>> Should it be reported as bug in Neutron or in Oslo project? Or maybe You
>>>> already know about it and there is some patch to fix it but I couldn't 
>>>> find it?
>>>
>>> Its an oslo.context bug - I can't see one filed for it yet.
>>>>
>>>> [1] https://review.openstack.org/#/c/426429/
>>>> [2] 
>>>> http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html
>>>>
>>>
>>> It looks like the warnings function was miss used - this should be set
>>> as a once only message. The stack trace level seems suspect, as it
>>> points as neutron/context.py as the one sending out the notice, not
>>> oslo.contexts base class.
>>>
>>> [3] seems to the cause - I would suggest reverting this commit and
>>> doing a 2.13.0 release. This is going to be *really* noisy. (logstash
>>> has 2.5 million items for this string in the last 24 hours)
>>>
>>> 3 -
>>> https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 


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

Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests

[Hayes, Graham]

On 28/01/17 20:54, Sławek Kapłoński wrote:
> Hello,
> 
> I pushed today patch in Neutron to gerrit [1] and I noticed that functional 
> tests are failing. In logs there is huge number of deprecation warnings 
> displayed [2]. Tests are failing because of global timeout is reached and IMO 
> reason of this timeout is this huge amount of deprecation warnings.
> I checked that those warnings are disaplyed when oslo.context==2.12.0 is 
> installed. With oslo.context==2.11.0 all is fine.
> Should it be reported as bug in Neutron or in Oslo project? Or maybe You 
> already know about it and there is some patch to fix it but I couldn't find 
> it?

Its an oslo.context bug - I can't see one filed for it yet.
> 
> [1] https://review.openstack.org/#/c/426429/
> [2] 
> http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html
> 

It looks like the warnings function was miss used - this should be set
as a once only message. The stack trace level seems suspect, as it
points as neutron/context.py as the one sending out the notice, not
oslo.contexts base class.

[3] seems to the cause - I would suggest reverting this commit and
doing a 2.13.0 release. This is going to be *really* noisy. (logstash
has 2.5 million items for this string in the last 24 hours)

3 -
https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea

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

Re: [openstack-dev] [neutron] PTL candidacy

[Hayes, Graham]

On 25/01/2017 01:08, Kevin Benton wrote:
>>I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so
> that vendors do not run around trying to figure out alternative
> solutions
>
> The Neutron API is already very extensible and that's problematic. Right
> now a vendor can write an out-of-tree service plugin or driver that adds
> arbitrary fields and endpoints to the API that results in whatever
> behavior they want. This is great for vendors because they can directly
> expose features without having to make them vendor agnostic. However,
> it's terrible for operators because it leads to lock-in and terrible for
> the users because it leads to cross-cloud compatibility issues.
>
> For a concrete example of what I mean, take a look at this extension
> here: [1]. This is directly exposing vendor-specific things onto Neutron
> network API payloads. Nobody can build any tooling that depends on those
> fields without being locked into a specific vendor.
>
> So what I would like to encourage is bringing API extension work into
> Neutron-lib where we can ensure that the relevant abstractions are in
> place and it's not just a pass-through to a bunch of vendor-specific
> features. I would rather relax our constraint around requiring a
> reference implementation for new extensions in neutron-lib than continue
> to encourage developers to do expose whatever they want with the the
> existing extension framework.
>
> So I'm all for developing new APIs *as a community* to enable NFV use
> cases not supported by the current APIs. However, I don't want to
> encourage or make it easier for vendors to just build arbitrary
> extensions on top of Neutron that expose backend details.
>
> In my view, Neutron should provide a unified API for networking across
> OpenStack clouds, not a platform for writing deployment-specific
> networking APIs.

How does this tie in with the removal of some of the networking *aaS
projects from the stadium? I know LBaaS is doing a shim API layer in
the short term, but long term that will have to move to a separate API.

How do you think this will impact inter service bugs (e.g. Octavia HA +
Neutron DVR issues that have been around for cycles)

>
> 1. 
> https://github.com/Juniper/contrail-neutron-plugin/blob/19ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contrail/extensions/contrail.py#L9-L22
>
> Cheers,
> Kevin Benton
>
> On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur  > wrote:
>
>
> Ihar and Kevin,
>
> As our potential future PTLs, I would like to draw your attention to
> one of the critical issue regarding Neutron as "the" networking
> service in OpenStack.
>
> I keep hearing off and on that Neutron is not flexible to address
> many networking use cases and hence a new (or additional) networking
> project is needed. For example, to address the use cases around NFV
> (rigid resource inter-dependencies).  Another one keeps popping up
> is that it is very hard/difficult to add/enhance Neutron API -
> hence, I picked this one goal called out in Ihar's candidacy.
>
> I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible
> so that vendors do not run around trying to figure out alternative
> solutions
>
> cheers..
> -Sukhdev
>
>
>
>
> * Explore alternative ways to evolve Neutron API.  Piling up
> extensions and allowing third parties to completely change core
> resource behaviour is not ideal, and now that api-ref and API
> consolidation effort in neutron-lib are closer to completion, we may
> have better answers to outstanding questions than during previous
> attempts to crack the nut. I would like to restart the
> discussion some
> time during Pike.
>
>
>
>
>
>
> Thanks for attention,
> Ihar
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
>
>
>
> __
> OpenStack Development Mailing 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] Improving Vendor Driver Discoverability

[Hayes, Graham]

On 20/01/17 01:40, Mike Perez wrote:
> On 17:38 Jan 18, Morales, Victor wrote:
>> Just a FYI, Ankur have been working on have a Feature Classification Matrix
>> in Neutron[1] which collects some of this information
>>
>> [1] https://review.openstack.org/#/c/318192/
> 
> I actually didn't know Nova also generated this with a script and ini file.
> Perhaps this would be a better approach than a giant JSON file like driver log
> is today. I could then have the marketplace parse these ini files using the
> common script. What do others think?
> 

FWIW Designate also does this - [0] is generated by [1] and a modified
version of the Nova script.

If there is a common way, we will use that, but I like our current
implementation.

0 - http://docs.openstack.org/developer/designate/support-matrix.html
1 -
https://git.openstack.org/cgit/openstack/designate/tree/doc/source/support-matrix.ini


__
OpenStack Development Mailing 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] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Hayes, Graham]

On 16/01/2017 13:38, Ian Cordasco wrote:
> Hi everyone,
>
> I've seen a few nascent projects wanting to implement their own secret
> storage to either replace Barbican or avoid adding a dependency on it.
> When I've pressed the developers on this point, the only answer I've
> received is to make the operator's lives simpler.
>
> I've been struggling to understand the reasoning behind this and I'm
> wondering if there are more people around who can help me understand.
>
> To help others help me, let me provide my point of view. Barbican's
> been around for a few years already and has been deployed by several
> companies which have probably audited it for security purposes. Most
> of the technology involved in Barbican is proven to be secure and the
> way the project has strung those pieces together has been analyzed by
> the OSSP (OpenStack's own security group). It doesn't have a
> requirement on a hardware TPM which means there's no hardware upgrade
> cost. Furthermore, several services already provide the option of
> using Barbican (but won't place a hard requirement on it). It stands
> to reason (in my opinion) that if new services have a need for secrets
> and other services already support using Barbican as secret storage,
> then those new services should be using Barbican. It seems a bit
> short-sighted of its developers to say that their users are definitely
> not deploying Barbican when projects like Magnum have soft
> dependencies on it.
>
> Is the problem perhaps that no one is aware of other projects using
> Barbican? Is the status on the project navigator alarming (it looks
> like some of this information is potentially out of date)? Has
> Barbican been deemed too hard to deploy?

I know that historically it was considered hard to do a HA deploy of
Barbican. When we initially evaluated DNSSEC in Designate (many years
ago now) it was one of the sticking points.

This may have (and most likely has) changed, but we seem to have long
memories.

It could be a side effect of the Big Tent - there are so many projects
doing so many different things that projects don't want deployers to
have deploy everything.

> I really want to understand why so many projects feel the need to
> implement their own secrets storage. This seems a bit short-sighted
> and foolish. While these projects are making themselves easier to
> deploy, if not done properly they are potentially endangering their
> users and that seems like a bigger problem than deploying Barbican to
> me.

+100 - One of the reasons we didn't just write our own signing was I
am allergic to writing crypto code - I am not very good at it, and there
is a project that people that either are, or know how to use the libs
correctly.


__
OpenStack Development Mailing 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] [barbican] Project Navigator Out of Date?

[Hayes, Graham]

On 16/01/2017 14:33, Julien Danjou wrote:
> On Mon, Jan 16 2017, Ian Cordasco wrote:
>
>> Related to the other thread I just started, I was looking at the
>> project navigator [1] for Barbican and found some things that look
>> wrong (to an outsider) and was hoping could be cleared up.
>
> Don't worry, we (Telemetry) have already asked for that to be updated
> but nothing happened. I don't even recall that we had an answer about
> how the page is managed. See this thread from October 2016:
>
>   http://lists.openstack.org/pipermail/openstack-dev/2016-October/105617.html
>

I have filed bugs on the foundation website launchpad [0] to get these
fixed in the past.

That said, there is problems with the navigator (like what levels are
considered "mature", the choice of tags, etc) that make me just ignore
it. It even considers our Juno release as "not deprecated" (in the API 
version history?)

> The page misses components for us also. I feel bad that the foundation
> Web site reflects bad data. It actually harms small projects that made
> good progress achieving better at what is called "maturity" being still
> wrongly noted 1/8.

Yup. As a small project it is hard enough to keep up without losing out
in such a public way.

> Sigh.
>
> Cheers,
>

0 - https://launchpad.net/openstack-org

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

[openstack-dev] [designate] Non Candidacy for PTL - Pike

[Hayes, Graham]

Happy new year!

As you may have guessed from the subject, I have decided that the time
has come to step aside as PTL
for the upcoming cycle. It is unfortunate, but my work has pivoted in a
different direction over the last
year (containers all the way down man - but hey, I got part of my wish
to write Golang, just not on the
project I envisaged :) ).

As a result, I have been trying to PTL out of hours for the last cycle
and a half. Unfortunatly, this has had a
bad impact on this cycle, and I don't think we should repeat the pattern.

We have done some great work over the last year or so - Worker Model,
the s/Domain/Zone work,
the new dashboard, being one of the first projects to have an external
tempest plugin and getting lost in
the west of Ireland in the aftermath of the flooding.

I can honestly say, I have enjoyed my entire time with this team, from
our first meeting in Austin, back in
the beginning of 2014, the whole way through to today. We have always
been a small team, but when I think back
to what we have produced over the last few years, I am incredibly proud.

Change is healthy, and I have been in a leadership position in Designate
longer than most, and no project should
rely on a person or persons to continue to exist.

I will stick around on IRC, and still remain a member of the core review
team, as a lot of the roadmap is still in
the heads of myself and 2 or 3 others, but my main aim will be to
document the roadmap in a single place, and not
just in thousands of etherpads.

It has been a fun journey - I have gotten to work with some great
people, see some amazing places, work on really
interesting problems and contribute to a project that was close to my heart.

This is not an easy thing to do, but I think the time is right for the
project and me to let someone else make
their stamp on the project, and bring it to the next level.

Nominations close soon [0] so please start thinking about if you would
like to run or not. If anyone has any questions
about the role, please drop me an email or ping me [1] on IRC [2]

Thank you for this opportunity to serve the community for so long, it is
not something I will forget.

- Graham

0 - https://governance.openstack.org/election/
1 - mugsie
2 - #openstack-dns


__
OpenStack Development Mailing 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] Next IRC meeting in 2017

[Hayes, Graham]

Hi All,

As a lot of people are now going on vacation for the holiday season, we
decided to pick up IRC meetings in 2017.

So, our first meeting will be 4th Jan 2017 @ 17:00 UTC

See everyone after the break

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

Re: [openstack-dev] [neutron] Changes to DNS integration behavior?

[Hayes, Graham]

On 12/12/2016 19:52, Kimball, Conrad wrote:
> We are in the early phases of a project to deploy OpenStack and we face
> the question of DNS integration when launching a VM instance.
>
>
>
> We have found the DNS Integration documentation at
> http://docs.openstack.org/mitaka/networking-guide/config-dns-int.html,
> but to our understanding it doesn’t do what we want to do.
>
>
>
> Where is the best forum for discussing possible changes in this behavior?
>
>

This would be a change to neutron, so it would their bugs / RFE
process [0]

I added [neutron] to the subject to grab their attention.

0 - http://docs.openstack.org/developer/neutron/policies/blueprints.html

>
> - - -
>
>
>
> Specifically, we do not tie DNS domains to networks – any particular
> network may have VM ports with a variety of DNS domains, with the choice
> of DNS domain left to the person deploying the VM instance (we use DNS
> domains to indicate business unit association, infrastructure function,
> and so forth).
>
>
>
> So we would want the DNS integration to allow specifying both a dns_name
> and a dns_domain when creating a port.  The documentation link above
> says this is allowed for floating IPs, but not for ports – ports can
> specify only a dns_name and always inherit the dns_domain from the network.
>
>
>
> /Conrad Kimball/
>
> Associate Technical Fellow
>
> Chief Architect, Enterprise Cloud Services
>
> Engineering, Operations & Technology / Information Technology / Core
> Infrastructure Engineering
>
> conrad.kimb...@boeing.com 
>
> P.O. Box 3707, Mail Code 7M-TE
>
> Seattle, WA  98124-2207
>
> Bellevue 33-11 bldg, office 3A6-3.9
>
> Mobile:  425-591-7802
>
>
>


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

[Hayes, Graham]

Hi All,

There is an unexpected internal meeting today that conflicts with the 
IRC meeting.

As a result, I will not be available to chair, and I think that the
other HPE team members will also be unavailable.

I suggest that we postpone for this week?

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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Hayes, Graham]

On 08/11/2016 16:39, Flavio Percoco wrote:
> On 08/11/16 16:20 +0000, Hayes, Graham wrote:
>> On 08/11/2016 15:55, Doug Hellmann wrote:
>>> Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:
>>>> On 08/11/2016 10:30, Thierry Carrez wrote:
>>>>> Ash wrote:
>>>>>> [...]
>>>>>> Here's another take on the situation. If there are people who genuinely
>>>>>> wish to see a CI pipeline that can support something like Go, perhaps
>>>>>> you can establish a prerequisite of working with the Infra team on
>>>>>> establishing the new pipeline. In my opinion, this seems to be the major
>>>>>> gate. So, if there's a clear path identified, resources provided, and
>>>>>> the Infra team is ultimately benefitted, then I'm not sure why there
>>>>>> should be another rejection. Just a thought. I know this proposal
>>>>>> continues to come up and I'm a big fan of seeing other languages
>>>>>> supported, especially Go. But I also understand that it can break
>>>>>> things. Personally, I would even volunteer to work on such an Infra 
>>>>>> effort.
>>>>>>
>>>>>> BTW, it is quite possible that another group might feel the same
>>>>>> constraints. It's perfectly reasonable. But if we can overcome such
>>>>>> obstacles, would the TC still have a concern?
>>>>>
>>>>> The TC isn't just one person. In complex situations like this where you
>>>>> have to weigh the trade-off between opening up more choices and our
>>>>> community's ability to digest/survive the change, there will always be a
>>>>> wide variety of opinions. I won't claim to be able to predict how the
>>>>> current membership would vote.
>>>>
>>>> Yup - and the TC could possibly change half, (or even all) its members
>>>> during time it takes to get this work done.
>>>>
>>>>> That said, I think that if we can have more confidence that our
>>>>> structure can handle it (from infra to release/stable/dep management)
>>>>> and that the OpenStack community will share expertise and best practices
>>>>> on Go and avoid reinventing the wheel in every project, I expect a
>>>>> majority of TC members to take that leap of faith.
>>>>
>>>> There was a bit of work done for the previous proposal, but the main
>>>> objections were not to do with any of points raised in this email /
>>>> blog. The objections were mainly cultural - about how it would impact
>>>> the community (which *is* very important), and the exactly why it was
>>>> needed for the projects who were asking.
>>>>
>>>>> To me, the important part is that introducing Go should not be another
>>>>> way for some of our community to be different, but another way for our
>>>>> community to be one. It should do more to bind our community together
>>>>> than to split it into more factions and silos.
>>>>>
>>>>
>>>> I would agree - but I would ask that we find a way forward that does not
>>>> require huge amounts of up front work, for a gamble at the end of the
>>>> process, where the work could be written off for any number of other
>>>> reasons.
>>>>
>>>
>>> I agree that we need to be careful about how much up-front work is
>>> required. A plan to address some of these concerns seems like a
>>> minimum level, with commitment to handle the immediate items like
>>> infra resources for managing those changes. But it's hard to specify
>>> the right levels in the abstract, because so much depends on the
>>> situation, language, and teams involved.
>>>
>>> Doug
>>
>> This. I think trying to define objective rules, procedures, and
>> checklists for what is at the end of the a subjective decision is
>> not a great idea.
>>
>> Should the policy just be "If you want to add a new language, add an
>> item to the TC agenda. They will the discuss the overall proposal, and
>> may ask for more details in the following areas, the use case, or decide
>> that this is not a direction that the community should proceed towards."
>>
>> Or, you know, a well written version of ^.
>
> This feels a lot like what we have today. I think the set of requirements must
> be written down and clear. The evaluati

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Hayes, Graham]

On 08/11/2016 15:55, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:
>> On 08/11/2016 10:30, Thierry Carrez wrote:
>>> Ash wrote:
 [...]
 Here's another take on the situation. If there are people who genuinely
 wish to see a CI pipeline that can support something like Go, perhaps
 you can establish a prerequisite of working with the Infra team on
 establishing the new pipeline. In my opinion, this seems to be the major
 gate. So, if there's a clear path identified, resources provided, and
 the Infra team is ultimately benefitted, then I'm not sure why there
 should be another rejection. Just a thought. I know this proposal
 continues to come up and I'm a big fan of seeing other languages
 supported, especially Go. But I also understand that it can break
 things. Personally, I would even volunteer to work on such an Infra effort.

 BTW, it is quite possible that another group might feel the same
 constraints. It's perfectly reasonable. But if we can overcome such
 obstacles, would the TC still have a concern?
>>>
>>> The TC isn't just one person. In complex situations like this where you
>>> have to weigh the trade-off between opening up more choices and our
>>> community's ability to digest/survive the change, there will always be a
>>> wide variety of opinions. I won't claim to be able to predict how the
>>> current membership would vote.
>>
>> Yup - and the TC could possibly change half, (or even all) its members
>> during time it takes to get this work done.
>>
>>> That said, I think that if we can have more confidence that our
>>> structure can handle it (from infra to release/stable/dep management)
>>> and that the OpenStack community will share expertise and best practices
>>> on Go and avoid reinventing the wheel in every project, I expect a
>>> majority of TC members to take that leap of faith.
>>
>> There was a bit of work done for the previous proposal, but the main
>> objections were not to do with any of points raised in this email /
>> blog. The objections were mainly cultural - about how it would impact
>> the community (which *is* very important), and the exactly why it was
>> needed for the projects who were asking.
>>
>>> To me, the important part is that introducing Go should not be another
>>> way for some of our community to be different, but another way for our
>>> community to be one. It should do more to bind our community together
>>> than to split it into more factions and silos.
>>>
>>
>> I would agree - but I would ask that we find a way forward that does not
>> require huge amounts of up front work, for a gamble at the end of the
>> process, where the work could be written off for any number of other
>> reasons.
>>
>
> I agree that we need to be careful about how much up-front work is
> required. A plan to address some of these concerns seems like a
> minimum level, with commitment to handle the immediate items like
> infra resources for managing those changes. But it's hard to specify
> the right levels in the abstract, because so much depends on the
> situation, language, and teams involved.
>
> Doug

This. I think trying to define objective rules, procedures, and
checklists for what is at the end of the a subjective decision is
not a great idea.

Should the policy just be "If you want to add a new language, add an
item to the TC agenda. They will the discuss the overall proposal, and
may ask for more details in the following areas, the use case, or decide
that this is not a direction that the community should proceed towards."

Or, you know, a well written version of ^.



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


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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Hayes, Graham]

On 08/11/2016 10:30, Thierry Carrez wrote:
> Ash wrote:
>> [...]
>> Here's another take on the situation. If there are people who genuinely
>> wish to see a CI pipeline that can support something like Go, perhaps
>> you can establish a prerequisite of working with the Infra team on
>> establishing the new pipeline. In my opinion, this seems to be the major
>> gate. So, if there's a clear path identified, resources provided, and
>> the Infra team is ultimately benefitted, then I'm not sure why there
>> should be another rejection. Just a thought. I know this proposal
>> continues to come up and I'm a big fan of seeing other languages
>> supported, especially Go. But I also understand that it can break
>> things. Personally, I would even volunteer to work on such an Infra effort.
>>
>> BTW, it is quite possible that another group might feel the same
>> constraints. It's perfectly reasonable. But if we can overcome such
>> obstacles, would the TC still have a concern?
>
> The TC isn't just one person. In complex situations like this where you
> have to weigh the trade-off between opening up more choices and our
> community's ability to digest/survive the change, there will always be a
> wide variety of opinions. I won't claim to be able to predict how the
> current membership would vote.

Yup - and the TC could possibly change half, (or even all) its members
during time it takes to get this work done.

> That said, I think that if we can have more confidence that our
> structure can handle it (from infra to release/stable/dep management)
> and that the OpenStack community will share expertise and best practices
> on Go and avoid reinventing the wheel in every project, I expect a
> majority of TC members to take that leap of faith.

There was a bit of work done for the previous proposal, but the main
objections were not to do with any of points raised in this email /
blog. The objections were mainly cultural - about how it would impact
the community (which *is* very important), and the exactly why it was
needed for the projects who were asking.

> To me, the important part is that introducing Go should not be another
> way for some of our community to be different, but another way for our
> community to be one. It should do more to bind our community together
> than to split it into more factions and silos.
>

I would agree - but I would ask that we find a way forward that does not
require huge amounts of up front work, for a gamble at the end of the
process, where the work could be written off for any number of other
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Hayes, Graham]

On 07/11/2016 17:14, Flavio Percoco wrote:
> Greetings,
>
> I literally just posted a thing on my blog with some thoughts of what I'd 
> expect
> any new language being proposed for OpenStack to cover before it can be
> accepted.
>
> The goal is to set the expectations right for what's needed for new languages 
> to
> be accepted in the community. During the last evaluation of the Go proposal I
> raised some concerns but I also said I was not closed to discussing this again
> in the future. It's clear we've not documented expectations yet and this is a
> first step to get that going before a new proposal comes up and we start
> discussing this topic again.
>
> I don't think a blog post is the "way we should do this" but it was my way to
> dump what's in my brain before working on something official (which I'll do
> this/next week).
>
> I also don't think this list is perfect. It could either be too restrictive or
> too open but it's a first step. I won't paste the content of my post in this
> email but I'll provide a tl;dr and eventually come back with the actual
> reference document patch. I thought I'd drop this here in case people read my
> post and were confused about what's going on there.
>
> Ok, here's the TL;DR of what I believe we should know/do before accepting a 
> new
> language into the community:

Its a great starting point, but there is one issue:

This is a *huge* amount of work to get into place, for the TC to still
potentially refuse the language. (I know you covered this in your blog
post, but I think there is a level of underestimation there.)


> - Define a way to share code/libraries for projects using the language

++ - Definitely needed

> - Work on a basic set of libraries for OpenStack base services

What do we include here? You called out these:

keystoneauth / keystone-client
oslo.config
oslo.db
oslo.messaging

We need to also include

oslo.log

Do they *all* need to be implemented? Just some? Do they need feature
parity?

For example the previous discussion about Go had 2 components that would
have required at most 2 of these base libraries (and I think that was
mainly on the Designate side - the swift implementation did not need
any (I think - I am open to correction)

> - Define how the deliverables are distributed

++ - but this needs to be done with the release management teams input.
What I think is reasonable may not be something that they are interested
in supporting.

> - Define how stable maintenance will work

++

> - Setup the CI pipelines for the new language

This requires the -infra team dedicate (what are already stretched)
resources to a theoretical situation, doing work that may be thrown
away if the TC rejects a language.

I foresee these requirements as a whole being overly onerous, and
having the same result as saying "no new languages".

I think that there should be base research into all of these, but the
requirements for some of these to be fully completed could be basically
impossible.

>
> The longer and more detailed version is here:
>
> https://blog.flaper87.com/embracing-other-languages-openstack.html
>
> Stay tuned,
> Flavio
>


__
OpenStack Development Mailing 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] Global changes to CI jobs using neutron

[Hayes, Graham]

On 02/11/16 19:53, Matt Riedemann wrote:
> nova-network was deprecated in newton. Nova is working on moving the CI
> jobs that run against it to use Neutron only in Ocata. I'm tracking that
> work here:
>
> https://etherpad.openstack.org/p/removing-nova-network
>
> In an effort to make this more of a global switch in Ocata, clarkb has
> proposed a change to devstack-gate to change the default value of
> DEVSTACK_GATE_NEUTRON from 0 (nova-net) to 1 (neutron):
>
> https://review.openstack.org/#/c/392934/
>
> There are conditions on that which are:
>
> 1. If a job definition in project-confg sets DEVSTACK_GATE_NEUTRON
> explicitly, that's honored.
>
> 2. If not explicitly defined and the job is running against a stable
> branch, then nova-network is still the default.
>
> There are a few jobs which are definitely nova-network specific, like
> some of the nova-net specific grenade jobs and the cells v1 job. Those
> are being explicitly handled in a series here:
>
> https://review.openstack.org/#/c/392942/
>
> So why should you care, you ask? First, thanks for asking. Second, as
> noted in the commit message to ^ there are several grenade jobs which
> don't explicitly define DEVSTACK_GATE_NEUTRON, like for designate and
> trove. With that change those grenade jobs will now start using neutron
> when upgrading from newton to ocata. This might work, it might not. If
> it does not work, and you know it won't work, please speak up now.
> Otherwise if things break we'll have to either (a) explicitly set
> DEVSTACK_GATE_NEUTRON=0 in those jobs or (b) cap them at stable/newton -
> either way those affected projects would have to sort out a path forward
> for continued upgrade testing in Ocata.
>

I don't know of any reason that this should not work for the Designate
jobs, as we do not make use of any of the other resources in the cloud.

I will try a manual test in the next couple of days to confirm though.

__
OpenStack Development Mailing 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] [Horizon] Rework Access & Security panel

[Hayes, Graham]

On 27/10/2016 04:15, Adrian Turjak wrote:
> Hello OpenstackDevs,
>
> In our deployment we keep running into a problem where customers forget
> about the existence of floating ips once disassociated from an instance,
> and when they then need to release them they often can't find where
> because expecting them to be in 'Access & Security' is odd.
>
> Why don't we move Floating ips out to their own panel either at the
> compute or network layer on the dashboard so they are easy to find. They
> are their own resource and having them in a shared panel like Access &
> Security seems usual and rather confusing UX. All the remaining
> resources in Access & Security make sense, but floating ips really
> shouldn't be there.
>
> If there aren't any arguments against it, I can put together a
> blueprint/patch for this myself, but would like to know people are happy
> with the change.
>
> Any alternate ideas? Vehement opposition to the change?

I think it is a great idea :)

We should also move the security groups out to the networking section,
the API access to somewhere else, and just leave SSH keys where they
are.

Having these things under the compute section has always irked me. :)

> Cheers,
> Adrian Turjak
>
>
> __
> OpenStack Development Mailing 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] [trove][octavia][tacker][designate][manila][sahara][magnum][infra] servicevm working group meetup

[Hayes, Graham]

On 24/10/2016 20:35, Adam Harwell wrote:
> I'll be there.

I will be there as well.

- Graham
>
>
> On Mon, Oct 24, 2016, 20:29 Doug Wiegley  > wrote:
>
>
>> On Oct 24, 2016, at 8:23 PM, Doug Wiegley
>> > > wrote:
>>
>> As part of a requirements mailing list thread [1], the idea of a
>> servicevm working group, or a common framework for reference
>> openstack service VMs, came up. It's too late to get onto the
>> official schedule, but unofficially, let's meet here:
>>
>> When: Tuesday, 1:30pm-2:10pm
>> Where: CCIB P1 Room 128
>>
>> If this is too short notice, then we can retry on Friday.
>>
>> Thanks,
>> doug
>>
>> [1]
>> 
>> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105861.html
>>
>
> And an etherpad:
>
> https://etherpad.openstack.org/p/ocata-summit-servicevm
>
>
> __
> OpenStack Development Mailing 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] [designate] Draft Logo - Please have a look, and give feedback

[Hayes, Graham]

Hi team,
I just received a draft version of our project logo, using the mascot we 
selected together. A final version (and some cool swag) will be ready for us 
before the Project Team Gathering in February. Before they make our logo final, 
they want to be sure we're happy with our mascot.

We can discuss any concerns in Barcelona and you can also provide direct 
feedback to the designers: http://tinyurl.com/OSmascot  Logo feedback is due 
Friday, Nov. 11. To get a sense of how ours stacks up to others, check out this 
sneak preview of several dozen draft logos from our community: 
https://youtu.be/JmMTCWyY8Y4

[cid:image001.png@01D22E9C.CAD3A6D0]


__
OpenStack Development Mailing 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] IRC Meetings - Canceled for the next 2 weeks

[Hayes, Graham]

Hi All,

With the Design Summit a week away, and having no agenda items,
I suggest we skip the meeting this week, and as we will be in Spain
next week, we will also be skipping that meeting.

See you all in Barcelona, or at the meeting on the 2nd of November.

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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Hayes, Graham]

On 18/10/2016 19:57, Doug Wiegley wrote:
>
>> On Oct 18, 2016, at 12:42 PM, Doug Hellmann  wrote:
>>
>> Excerpts from Doug Wiegley's message of 2016-10-18 12:21:20 -0600:
>>>
 On Oct 18, 2016, at 12:10 PM, Doug Hellmann  wrote:

 Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
>
>> On Oct 18, 2016, at 11:30 AM, Doug Hellmann > > wrote:
>>
>> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
>>>
 On Oct 18, 2016, at 5:14 AM, Ian Cordasco  >> wrote:



 -Original Message-
 From: Thierry Carrez  >   
 > 
  
  
 > 
  
 >> 
 > 
  
  Doug Wiegley wrote:
>> [...] Paths forward:
>>
>> 1. Add gunicorn to global requirements.
>>
>> 2. Create a project specific “amphora-requirements.txt” file for the
>> service VM packages (this is actually my preference.) It has been
>> pointed out that this wouldn’t be kept up-to-date by the bot. We 
>> could
>> modify the bot to include it in some way, or do it manually, or with 
>> a
>> project specific job.
>>
>> 3. Split our service VM builds into another repo, to keep a clean
>> separation between API services and the backend. But, even this new
>> repo’s standlone requirements.txt file will have the g-r issue from 
>> #1.
>>
>> 4. Boot the backend out of OpenStack entirely.
>
> All those options sound valid to me, so the requirements team should
> pick what they are the most comfortable with.
>
> My 2c: yes g-r is mostly about runtime dependencies and ensuring
> co-installability. However it also includes test/build-time deps, and
> generally converging dependencies overall sounds like a valid goal. Is
> there any drawback in adding gunicorn to g-r (option 1) ?

 The drawback (in my mind) is that new projects might start using it 
 giving operators yet another thing to learn about when deploying a new 
 component (eventlet, gevent, gunicorn, ...).

 On the flip, what's the benefit of adding it to g-r?
>>>
>>> The positive benefit is the same as Octavia’s use case: it provides an 
>>> alternative for any non-frontline-api service to run a lightweight 
>>> http/wsgi service as needed (service VMs, health monitor agents, etc). 
>>> And something better than the built-in debug servers in most of the 
>>> frameworks.
>>>
>>> On the proliferation point, it is certainly a risk, though I’ve 
>>> personally heard pretty strong guidance that all main API services in 
>>> our community should be trending towards pecan.
>>
>> Pecan is a way to build WSGI applications. Gunicorn is a way to deploy
>> them. So they're not mutually exclusive.
>
> Right, agreed.
>
> What we’re trying to convey here is:
>
> - The normal way of making a 

Re: [openstack-dev] [tripleo] PTG space request

[Hayes, Graham]

On 12/10/2016 10:31, Thierry Carrez wrote:
> Emilien Macchi wrote:
>> I would like to request for some space dedicated to TripleO project
>> for the first OpenStack PTG.
>>
>> https://www.openstack.org/ptg/
>>
>> The event will happen in February 2017 during the next PTG in Atlanta.
>> Any feedback is welcome,
>
> Just a quick note: as you can imagine we have finite space at the event,
> and the OpenStack Foundation wants to give priority to teams which have
> a diverse affiliation (or which are not tagged "single-vendor").
> Depending on which teams decide to take advantage of the event and which
> don't, we may or may not be able to offer space to single-vendor
> projects -- and TripleO is currently tagged single-vendor.
>
> The rationale is, the more organizations are involved in a given project
> team, the more value there is to offer common meeting space to that team
> for them to sync on priorities and get stuff done. If more than 90% of
> contributions / reviews / core reviewers come from a single
> organization, there is less coordination needs and less value in having
> all those people from a single org to travel to a distant place to have
> a team meeting. And as far as recruitment of new team members go (to
> increase that diversity), the OpenStack Summit will be a better venue to
> do that.
>
> I hope we'll be able to accommodate you, though. And in all cases
> TripleO people are more than welcome to join the event to coordinate
> with other teams. It's just not 100% sure we'll be able to give you a
> dedicated room for multiple days. We should know better in a week or so,
> once we get a good idea of who plans to meet at the event and who doesn't.
>

For me, this is somewhat concerning. When the PTG was proposed, It was
suggested as a replacement for Mid Cycles, with a design summit at the
right point.

I thought it was a good idea, but I never thought that we would have a
situation where there was a possibility to turn away projects that:

a) Traditionally had mid cycles
b) Was an active user of design summit space.

What I am getting from this is a very real chance that some projects
will now have 3 things in a 6 month cycle they need to do.

PTG - to do cross project work (If I had to fly transatlantic for 2
days of cross project, with no room for my project after that, I would
not be happy)

Mid Cycle / Self Hosted design summit - as we do not have space anymore
at the traditional summit, or the PTG

Traditional Summit - close the loop with users / Ops / employer tasks.

If I proposed this I might get 2 of 3, and I know what I would be
dropping (hint - its the one with 24 hours of traveling for maybe 16
hours of face to face).

I foresee quite a lot of cross project disengagement from smaller teams
if this is how we are going to proceed.

We are also getting back to the old catch-22 issue we had in the
incubation / integration days - its harder to get diversity of
contributors up, if a project are not at the PTG, but the project
won't be guaranteed space, due to the lack of diversity.


__
OpenStack Development Mailing 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] Exposing project team's metadata in README files

[Hayes, Graham]

On 12/10/2016 16:08, Doug Hellmann wrote:
> Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
>> Greetings,
>>
>> One of the common complains about the existing project organization in the 
>> big
>> tent is that it's difficult to wrap our heads around the many projects there
>> are, their current state (in/out the big tent), their tags, etc.
>>
>> This information is available on the governance website[0]. Each official
>> project team has a page there containing the information related to the
>> deliverables managed by that team. Unfortunately, I don't think this page is
>> checked often enough and I believe it's not known by everyone.
>>
>> In the hope that we can make this information clearer to people browsing the
>> many repos (most likely on github), I'd like to propose that we include the
>> information of each deliverable in the readme file. This information would be
>> rendered along with the rest of the readme (at least on Github, which might 
>> not
>> be our main repo but it's the place most humans go to to check our projects).
>>
>> Rather than duplicating this information, I'd like to find a way to just
>> "include it" in the Readme file. As far as showing the "official" badge 
>> goes, I
>> believe it'd be quite simple. We can do it the same way CI tags are exposed 
>> when
>> using travis (just include an image). As for the rest of the tags, it might
>> require some extra hacking.
>>
>> So, before I start digging more into this, I wanted to get other 
>> opinions/ideas
>> on this topic and how we can make this information more evident to the rest 
>> of
>> the community (and people not as familiar with our processes as some of us 
>> are).
>>
>> Thanks in advance,
>> Flavio
>>
>> [0] http://governance.openstack.org/reference/projects/index.html
>>
>
> Is your proposal that a tag like release:cycle-with-milestones would
> result in a badge being added when the README.rst is rendered on
> github.com? Would that work for git.openstack.org, too?
>
> I agree that the governance site is not the best place to put the
> info to make it discoverable. Do users look first at the source
> repository, or at some other documentation?
>
> Doug

I like this idea.

I know when I am looking at software, I look at the source repo
initially.

We could do it in the readme, and maybe re-use it in the docs as well?

I would be willing to dig in and help if needed.

- 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] [elections][tc]Thoughts on the TC election process

[Hayes, Graham]

On 03/10/2016 17:49, Edward Leafe wrote:
> So the period of self-nominations for the Technical Committee seats has 
> ended, and the voting has begun. I've been a very close observer of this 
> process for several cycles, and I have some ideas I'd like to share. Full 
> disclosure: I am a current candidate for the TC, and have been a candidate 
> several times in the past, all of which were unsuccessful.
>
> When deciding to run, candidates write a long, thoughtful essay on their 
> reasons for wanting to serve on the TC, and those essays are typically the 
> last you hear from them until the election. It has been rare for anyone to 
> ask follow-up questions, or to challenge the candidates to explain their 
> positions more definitively. I have spoken with many people at the Summits, 
> which always closely followed the TC election (warning: unscientific samples 
> ahead!), and what their selection process mostly boils down to is: they pick 
> the names they are most familiar with. Many people don't read those long 
> candidacy posts, and nearly all couldn't remember a single point that any of 
> the candidates had put forth.
>
> We are fortunate in that all of the candidates are exceptionally 
> well-qualified, and those elected have put in excellent service while on the 
> TC. But one thing I'm afraid of is that we tend to get into a situation where 
> groupthink [0] is very likely. There are many excellent candidates running in 
> every election, but it is rare for someone who hasn't been a PTL of a large 
> project, and thus very visible, has been selected. Is this really the best 
> approach?
>
> I wrote a blog post about implicit bias [1], and in that post used the 
> example of blind auditions for musical orchestras radically changing the 
> selection results. Before the introduction of blind auditions, men 
> overwhelmingly comprised orchestras, but once the people judging the 
> auditions had no clue as to whether the musician was male or female, women 
> began to be selected much more in proportion to their numbers in the audition 
> pools. So I'd like to propose something for the next election: have 
> candidates self-nominate as in the past, but instead of writing a big 
> candidacy letter, just state their interest in serving. After the nominations 
> close, the election officials will assign each candidate a non-identifying 
> label, such as a random number, and those officials will be the only ones who 
> know which candidate is associated with which number. The nomination period 
> can be much, much shorter, and then followed by a week of campaigning (the 
> part that's really missing in the current p
 ro
>  cess). Candidates will post their thoughts and positions, and respond to 
> questions from people, and this is how the voters will know who best 
> represents what they want to see in their TC.

On the topic of implicit bias - I am open to correction on this, but I
do not think we have had a TC member who was not heavily involved in
either Cross Project teams, or one of the projects that spun out of
Nova in the early years.

Now, is this bias, or a side effect of people on smaller projects not
necessarily having dedicated upstream time.

Is this something we are worried about (or should be worried about)?

> The current candidacy essay would now be posted in the campaign period, 
> rather than at the time of nomination, and should exclude the sort of 
> biographical information that is currently the most important piece for many 
> people. Keeping anonymity will be difficult, and will preclude the use of 
> email for posting positions and responses, since email identifies the sender. 
> So perhaps candidates could forward their posts to the election officials, 
> who will post them for the candidates, identifying them by number only. The 
> voting form will only list the candidate numbers, so the end result will be 
> people casting votes for the candidates whose platform most matches what they 
> want to see in the TC, and who have best answered any questions raised by 
> others.
>
> My feeling is that the result would be very different than the current 
> process. My question, then, is whether that would be a good thing? It would 
> require more work from the candidates and especially the election officials, 
> so we should make sure that the goal is worth it. Do we want everyone to have 
> an equal chance to serve on the TC, or should those who have earned name 
> recognition by their excellent work in other parts of OpenStack continue to 
> have an advantage?
>
> [0] https://en.wikipedia.org/wiki/Groupthink
> [1] http://blog.leafe.com/bias/
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

[Hayes, Graham]

Added a test commit for Designate -

https://review.openstack.org/#/c/381084/

On 03/10/2016 13:31, Amrith Kumar wrote:
> FWIW, this does not appear to work for Trove. To confirm I've pushed up a 
> trial balloon (https://review.openstack.org/#/c/381075/2).
>
> At least on a local sandbox it does not work ...
>
> -amrith
>
>> -Original Message-
>> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
>> Sent: Monday, October 03, 2016 8:17 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] FYI - gate completely borked on master and
>> newton dsvm/grenade jobs
>>
>> Ihar Hrachyshka  wrote:
>>
>>> Long story short, this topic should get us back to normal:
>>>
>>> https://review.openstack.org/#/q/topic:bug/1629830
>>>
>>> We could probably also ban the version in global-requirements.txt, but I
>>> am bad at foresight. I will let others to clean it up if needed.
>>
>> Oh well, I am now contradicting myself-an-hour-ago who said that the
>> library is not in global-requirements.txt at all, so no need for a
>> cleanup.
>>
>> Ihar
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing 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] FYI - gate completely borked on master and newton dsvm/grenade jobs

[Hayes, Graham]

Also impacts designate, our dashboard, and our tempest plugin. It will
probably hit our client library as well.

-- Graham


On 03/10/2016 12:49, Amrith Kumar wrote:
> Also impacts Trove, see (for example)
>
>
>
> http://logs.openstack.org/85/380985/1/check/gate-trove-functional-dsvm-mysql/48ae79c/logs/devstacklog.txt.gz#_2016-10-03_09_04_15_199
>
>
>
> I have updated https://bugs.launchpad.net/trove/+bug/1629726 and marked
> it as impacting Trove.
>
>
>
> -amrith
>
>
>
> *From:*Steven Dake (stdake) [mailto:std...@cisco.com]
> *Sent:* Monday, October 03, 2016 1:57 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> 
> *Subject:* Re: [openstack-dev] FYI - gate completely borked on master
> and newton dsvm/grenade jobs
>
>
>
> Also impacts Kolla (as in our gates are blocked).  At present we are
> using the proposed workaround until the pycparser 2.14 wheel and package
> are synced up.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> *From: *Matt Riedemann  >
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)"  >
> *Date: *Sunday, October 2, 2016 at 5:54 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)"
>  >
> *Subject: *[openstack-dev] FYI - gate completely borked on master
> and newton dsvm/grenade jobs
>
>
>
> There was a pycparser 2.14 package update on pypi today which is making
>
> cinder-manager db sync fail. This is making all dsvm/grenade jobs fail
>
> in master and stable/newton.
>
>
>
> The upstream issue being tracked is:
>
>
>
> https://github.com/eliben/pycparser/issues/147
>
>
>
> --
>
>
>
> Thanks,
>
>
>
> Matt Riedemann
>
>
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org
> ?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>


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

Re: [openstack-dev] Pecan Version 1.2

[Hayes, Graham]

On 27/09/2016 01:36, Ryan Petrello wrote:
> Apologies for the trouble this caused.  As Dave mentioned, this change
> warranted a new major version of pecan, and I missed it.  I've reverted the
> offending commit and re-released a new version of pecan (1.2.1) to PyPI:
>
> https://github.com/pecan/pecan/commit/4cfe319738304ca5dcc97694e12b3d2b2e24b1bb
> https://github.com/pecan/pecan/commit/b3699aeae1f70b223a84308894523a64ede2b083
> https://pypi.python.org/pypi/pecan/1.2.1
>
> Once the dust settles in a few days, I'll re-release the new functionality in
> a major point release of pecan.
>
> On 09/26/16 09:21 PM, Dave McCowan (dmccowan) wrote:
>>
>> The Barbican project uses Pecan as our web framework.
>>
>> At some point recently, OpenStack started picking up their new version 1.2.  
>> This version [1] changed one of their APIs such that certain calls that used 
>> to return 200 now return 204.  This has caused immediate problems for 
>> Barbican (our gates for /master, stable/newton, and stable/mitaka all fail) 
>> and a potential larger impact (changing the return code of REST calls is not 
>> acceptable for a stable API).
>>
>> Before I start hacking three releases of Barbican to work around Pecan's 
>> change, I'd like to ask:  are any other projects having trouble with
>> Pecan Version 1.2?  Would it be possible/appropriate to block this version 
>> as not working for OpenStack?
>>
>> Thanks,
>> Dave McCowan
>>
>>
>> [1]
>> http://pecan.readthedocs.io/en/latest/changes.html
>> https://github.com/pecan/pecan/issues/72
>>
>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

Thanks Ryan

Designate hit a small issue as well, so I proposed
https://review.openstack.org/377702 to allow 1.2.1
be installed, and block 1.2.

Its been approved, so it should be working its way to a
repo near you soon.

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

Re: [openstack-dev] [openstack-de] [DNSaaS] [designate] jenkins is failing for all latest patches

[Hayes, Graham]

On 27/09/2016 08:42, Kelam, Koteswara Rao wrote:
> Jenkins for openstack/designate is failing for latest patches. Py27,
> py34 and py35 are failing continuously.
>
> gate-designate-python27-db-ubuntu-xenial
> 
>
>   
>
> FAILURE in 3m 58s
>
> gate-designate-python34-db
> 
>
>   
>
> FAILURE in 5m 16s
>
> gate-designate-python35-db
> 
>
>   
>
> FAILURE in 3m 41s
>
>
>
> Recent patches:
>
> https://review.openstack.org/#/c/376436/
> https://review.openstack.org/#/c/377050/
> https://review.openstack.org/#/c/376170/
>
> etc
>
>
>
> */Regards,/*
>
> */Koteswara/*//
>
>
>

Yeah, I spotted that.

Seems a combination of pecan 1.2 (the py27 tests) and dnspython 1.14
(py3x tests).

Both hit over the weekend.

I am looking at a fix, but the behavior between py27 + py3(4|5) for
dnspython 1.14 is an issue.

I proposed https://review.openstack.org/#/c/377702/ for the pecan issue, 
but it might take a while for the dnspython fixes.

- 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] PTL Candidacy

[Hayes, Graham]

Hi Everyone,

I would like to my intention to continue as PTL of the Designate
project for another cycle.

We have made great steps forward in Designate over the last few cycles,
not just with features, but integrating with the community as a whole.

For Ocata, I have previously proposed, and now am completely behind
making this cycle a non feature cycle. We have built up some large amount
of technical debt, and are in need of some time to just do hardening, bug
fixes, and performance improvements.

With Ocata being such a short cycle, I think we have a prime opportunity
to do that, and with the recent merge of Worker Model, we should not need
any other major refactors.

I think we have made major progress over the previous 3 or 4 years,
and have done amazing work, despite (or maybe because of) being a small
team.

Thanks for reading, and your consideration for PTL.

- 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

Re: [openstack-dev] [cue][qa] Status of OpenStack CI jobs

[Hayes, Graham]

On 15/09/2016 00:12, Ken'ichi Ohmichi wrote:
> Hi Cue-team,
>
> As http://status.openstack.org/openstack-health/#/ , the cue gate jobs
> continues failing 100%.
> What is current status of the development?
> Hopefully the  job will become stable for smooth development.
>
> Thanks
> Ken Ohmichi

I am not sure what the status of development is, but it looks like they 
hit the same issue some of us did with olso.context 2.6.0 (when the
output of to_dict() changed).



> __
> OpenStack Development Mailing 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] venting -- OpenStack wiki reCAPTCHA

[Hayes, Graham]

On 09/09/2016 08:44, Tom Fifield wrote:
>
>
> On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:
>> On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:
>>> Is it just me who likes to hit the save button often?
>>> It gets tedious proving often that you are not a robot. Wiki
>>> reCAPTCHA likes proof even if saves are spaced less than a minute
>>> apart!
>>> Wiki Gods, hear my plea!
>>
>> I sympathize. That captcha addition is one of several tools we're
>> leveraging currently to combat the ongoing spam/scammer/vandalism
>> problems on wiki.openstack.org, as an alternative to shutting it
>> down completely. Unfortunately even now I still spend a chunk of
>> every day blocking new accounts created by abusers and cleaning up
>> all their modifications, but am hoping that with other improvements
>> we have pending the onslaught will lessen and we can revisit some of
>> the more intrusive mechanisms on which we've been forced to rely
>> (for example, I think we should be able to configure it so that
>> users whose previous edits have been confirmed by a wiki admin are
>> added to a group that bypasses the captcha, and then get a team of
>> wiki groomers in the habit of adding known good accounts to that
>> group).
>>
>
> Indeed - fungi has been doing amazing work :(
>
> I have been adding "known good" accounts to such a group - there's about
> 64 so far:
>
> https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol

How would someone get in said list?

>
> Is it possible to disable CAPTCHA for users in group "autopatrol"?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] [all] governance proposal worth a visit: Write down OpenStack principles

[Hayes, Graham]

On 08/09/2016 06:17, Chris Dent wrote:
> On Thu, 8 Sep 2016, Flavio Percoco wrote:
>
>> To be honest, I think you're expressing in a negative way something
>> that was thought in a positive way. The motivation to write the
>> principles down is to help the community with the help from the
>> community. No one is pushing anyone's beliefs on anyone. The idea to
>> write these principles down came out of a retrospective and someone
>> actually signed up for the work.
>
> I don't dispute that writing things down is a positive. It is a _huge_
> positive. What I'm disputing is the process with which it is happening.

Definitely - I am happy to see this put somewhere permanent.

> The writing is starting from a detailed proposal which, as txx said in
> his response to me above, presents itself as a document that is "meant
> to document *existing* principles that we operate under but never
> documented properly. It's not really about a new set of rules, or really
> changing anything".
>
> That is, it thinks of iself as an existing truth to be ratified.
>
> That would be great except that it is clear from the comments on the
> review and comments we've seen on this list and elsewhere that the
> truths are not universally held. If that's indeed the case, then we need
> to make adjustments to the process and the document to be inclusive and
> make greater progress on putting to bed some of the arguments we
> continually have, but fail to resolve.

This is my issue with the review. It states that these are the *current*
rules we live by. While these may be the rules we currently aspire to,
they are not what we live by, and this needs to be reflected.

>> I do not think the process is trying to push few ppl beliefs on the
>> community. Someone had to write something down first, right? Someone
>> had to kick this off somehow, right? I hardly believe we could have
>> collected a list of principles to reason about out of a mailing list
>> thread. These list is just a starting point for us to add/remove stuff
>> to it either on follow-up patches or the same one.
>
> As I said in my original posting, again above, and supported by ttx's
> response, the current proposal and its mode of presentation
> presuppose the principles. That starting point biases any future
> discussions. That's problematic if the end goal are principles that
> everyone actually understands and agrees.
>
>> As everything else we do in this community, this work is meant to
>> evolve and progress but again, we have to start somewhere. With what's
>> in that review, I believe it'll be easier for everyone to reason about
>> the document and the expectations of it.
>
> I hope we can agree to disagree, cordially. We seem to want the same
> positive things to happen, we are disagreeing on the process. I
> merely wish there had been more public engagement, sooner, and a
> greater sense of doubt and request for assistance in the document.

I would second the need for sooner engagement - my missing it may be my
own fault as I missed the Stewardship WG meeting this week due to
travelling, but I think a bigger cross section, earlier, is important.

When I look at the TC, there is a lot of people who have come from
larger or horizontal projects. These projects get a different point
of view to smaller projects. Only allowing these views after the draft
is finished makes getting their point of view more difficult, as the
document is more solid.

> The truth, for me, is that I agree with most of the things in the
> document. What is problematic for me is that I know a lot of people
> who will not. Because of the ordering of the process and the
> presumption of the document they will simply choose to ignore it and
> carry on with whatever other important things they've got going on.
>

This. The only reason I saw this review was I saw a tweet.

__
OpenStack Development Mailing 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-docs] [api-ref][ceilometer][nova][senlin][swift][zaqar] OpenStack Docs theme migration

[Hayes, Graham]

Hi All,

We are nearly ready to release the new version of os-api-ref.

This required a temporary section of code to allow the docs to build
with both oslosphinx and openstackdocstheme.

Currently only Nova, Ceilometer, Zaqar, Senlin and Swift are
outstanding.

We will be releasing the new version of the library pretty soon.

It will not be before 16:00 UTC tomorrow afternoon, but could be
any time after that. Any of the projects above that have not merged
their "os-api-ref-1.0.0-prep" change will have a broken api-ref site.

When we have released the library, and confirmed projects are using it,
I will submit a new round of reviews to remove the temp code.

Thanks!

Graham

On 19/08/2016 17:16, Hayes, Graham wrote:
> Hi All,
>
> I have just pushed reviews to all the repos using os-api-ref, to allow
> us to migrate to the new sphinx theme gracefully.
>
> I have pushed reviews to the following repos:
>
> openstack/networking-sfc
> openstack/ceilometer
> openstack/glance
> openstack/heat
> openstack/ironic
> openstack/keystone
> openstack/manila
> openstack/designate
> openstack/trove
> openstack/neutron-lib
> openstack/nova
> openstack/sahara
> openstack/searchlight
> openstack/senlin (*)
> openstack/swift
> openstack/zaqar
>
> with the topic "os-api-ref-1.0.0-prep" [0]
>
> If I have missed anyone, please let me know.
>
> The next step would be to merge all of these, and then [1], and then do
> a release of the os-api-ref library.
>
> * Senlin looked like it was using the new theme already - so if they
> want to continue they can. just be warned that the visual styling will
> change at some point.
>
> Thanks,
>
> Graham
>
>
> 0 - https://review.openstack.org/#/q/topic:os-api-ref-1.0.0-prep
> 1 - https://review.openstack.org/#/c/322430/
>
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>


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

[Hayes, Graham]

Hi All,

As we are in the middle of our midcycle, we are going to skip the
meeting this week.

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] [api-ref][networking-sfc][ceilometer][glance][heat][ironic][keystone][manila][designate][trove][neutron][nova][sahara][searchlight][senlin][swift][zaqar] OpenStack Docs theme migration

[Hayes, Graham]

Hi All,

I have just pushed reviews to all the repos using os-api-ref, to allow
us to migrate to the new sphinx theme gracefully.

I have pushed reviews to the following repos:

openstack/networking-sfc
openstack/ceilometer
openstack/glance
openstack/heat
openstack/ironic
openstack/keystone
openstack/manila
openstack/designate
openstack/trove
openstack/neutron-lib
openstack/nova
openstack/sahara
openstack/searchlight
openstack/senlin (*)
openstack/swift
openstack/zaqar

with the topic "os-api-ref-1.0.0-prep" [0]

If I have missed anyone, please let me know.

The next step would be to merge all of these, and then [1], and then do
a release of the os-api-ref library.

* Senlin looked like it was using the new theme already - so if they 
want to continue they can. just be warned that the visual styling will
change at some point.

Thanks,

Graham


0 - https://review.openstack.org/#/q/topic:os-api-ref-1.0.0-prep
1 - https://review.openstack.org/#/c/322430/

__
OpenStack Development Mailing 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][cinder] tag:follows-standard-deprecation should be removed

[Hayes, Graham]

On 11/08/2016 15:35, John Griffith wrote:
>
>
> On Thu, Aug 11, 2016 at 7:14 AM, Erno Kuvaja  > wrote:
>
> On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis
> > wrote:
> >> >>
> >> >> As follow up on the mailing list discussion [0], gerrit activity
> >> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
> >> >> discussion how Cinder follows, or rather does not follow, the
> standard
> >> >> deprecation policy [4] as the project has been tagged on the
> assert
> >> >> page [5].
> >> >>
> > 
> >> >>
> >> >> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
> 
> 
> >> >> [1] https://review.openstack.org/#/c/348032/
> 
> >> >> [2] https://review.openstack.org/#/c/348042/
> 
> >> >> [3]
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
> 
> >> >> [4]
> 
> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
> 
> 
> >> >> [5]
> 
> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects
> 
> 
> >> >>
> >> >
> >> > Can you be more specific about what you mean? Are you saying that
> >> > the policy isn't being followed because the drivers were removed
> >> > without a deprecation period, or is there something else to it?
> >> >
> >> > Doug
> >> >
> >>
> >> Yes, that's how I see it. Cinder's own policy is that the drivers can
> >> be removed without any warning to the consumers while the standard
> >> deprecation policy defines quite strict lines about informing the
> >> consumer of the functionality deprecation before it gets removed.
> >>
> >> - Erno
> >
> > It is a good point. I think it highlights a common thread though with
> > the other discussion that, at least so far, third party drivers are
> > treated differently than the rest of the code.
> >
> > For any other functionality we certainly follow the deprecation
> policy.
> > Even in existing drivers we try to enforce that any driver renames,
> > config setting changes, and similar non-backwards compatible
> changes go
> > through the normal deprecation cycle before being removed.
> >
> > Ideally I would love it if we could comply with the deprecation policy
> > with regards to driver removal. But the reality is, if we don't
> see that
> > a driver is being supported and maintained by its vendor, then that
> > burden can't fall on the wider OpenStack and Cinder community that has
> > no way of validating against physical hardware.
> >
> > I think third party drivers need to be treated differently when it
> comes
> > to the deprecation policy. If that is not acceptable, then I
> suppose we
> > do need to remove that tag. Tag removal would be the lesser of the two
> > versus keeping around drivers that we know aren't really being
> > maintained.
> >
> > If it came to that, I would also consider creating a new
> cinder-drivers
> > project under the Cinder umbrella and move all of the drivers not
> tested
> > by Jenkins over to that. That wouldn't be a trivial undertaking, so I
> > would try to avoid that if possible. But it would at least allow us to
> > still get code reviews and all of the benefits of being in tree. Just
> > some thoughts.
> >
> > Sean
> >
>
> Sean,
>
> As said on my initial opening, I do understand and agree with the
> reasoning/treatment of the 3rd party drivers. My request for that tag
> removal is out of the remains of my ops hat.
>
> Lets say I was ops evaluating different options as storage vendor for
> my cloud and I get told that "Here is the list of supported drivers
> for different OpenStack Cinder back ends delivered by Cinder team", I
> start looking what the support level of those drivers are and see that
> Cinder follows standard deprecation which is fairly user/ops friendly
> with decent warning etc. I'm happy with that, not knowing OpenStack I
> would not even look if different subcomponents of Cinder happens to
> follow different policy. Now I buy storage vendor X HW and at Oct I
> realize that the vendor's driver is not shipped, nor any 

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

[Hayes, Graham]

On 10/08/2016 16:04, Ihar Hrachyshka wrote:
> Luigi Toscano  wrote:
>
>> On Wednesday, 10 August 2016 10:42:41 CEST Ben Swartzlander wrote:
>>> On 08/10/2016 04:33 AM, Duncan Thomas wrote:
 So I tried to get into helping with the cinder stable tree for a while,
 and while I wasn't very successful (lack of time and an inability to
 convince my employer it should be a priority), one thing I did notice it
 that much of the breakage seemed to come from outside cinder - many of
 the libraries we depend on make backwards incompatible changes by
 accident, for example. Would it be possible to have a long-term-support
 branch where we pinned the max version of everything for the gate, pips
 and devtstack? I'd have thought (and I'm very willing to be corrected)
 that would make the stable gate, well, stable, such that it required far
 less work to keep it able to run a basic devstack test plus unit tests.

 Does that sound at all sane?
>>>
>>> A big source of problems IMO is that tempest doesn't have stable
>>> branches. We use the master branch of tempest to test stable branches of
>>> other projects, and tempest regularly adds new features. This guarantees
>>> instability if you rely on tempest anywhere in your gate (and cinder
>>> does).
>>
>> Orthogonal to the discussion, but: this is not due to the lack of stable
>> branch, but that part of the Tempest API are not stable yet. This is being
>> addressed right now (in scope for Newton).
>> Once the Tempest stable API are used, no breakages should happen.
>
> Well, it’s only partially true. But what happens when you add a new test to
> tempest/master? It gets executed on all branches, and maybe some of them
> are failing it. We can argue that it’s probably a bug revealed, but it
> nevertheless requires attention from stable maintainers to solve.

And would a lot of bugs that a new test could expose be non
back-portable? AS they could cause API changes, which is banned in
the back-port policy.

Def-Core faced similar issues with new tests failing previously
validated clouds.

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


__
OpenStack Development Mailing 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] [Cinder] [stable] [all] Changing stable policy for drivers

[Hayes, Graham]

On 09/08/2016 19:58, Ihar Hrachyshka wrote:
> Walter A. Boring IV  wrote:
>
>> On 08/08/2016 02:28 PM, Ihar Hrachyshka wrote:
>>> Duncan Thomas  wrote:
>>>
 On 8 August 2016 at 21:12, Matthew Treinish  wrote:
 Ignoring all that, this is also contrary to how we perform testing in
 OpenStack.
 We don't turn off entire classes of testing we have so we can land
 patches,
 that's just a recipe for disaster.

 But is it more of a disaster (for the consumers) than zero testing,
 zero review, scattered around the internet
 if-you're-lucky-with-a-good-wind you'll maybe get the right patch set?
 Because that's where we are right now, and vendors, distributors and
 the cinder core team are all saying it's a disaster.
>>>
>>> If consumers rely on upstream releases, then they are expected to
>>> migrate to newer releases after EOL, not switch to a random branch on
>>> the internet. If they rely on some commercial product, then they usually
>>> have an extended period of support and certification for their drivers,
>>> so it’s not a problem for them.
>>>
>>> Ihar
>> This is entirely unrealistic.  Force customers to upgrade.   Good luck
>> explaining to a bank that in order to get their cinder driver fix in,
>> they have to upgrade their entire OpenStack deployment. Real world
>> customers simply will balk at this all day long.
>
> Real world customers will pay for engineering to support their software,
> either their own or of one of OpenStack vendors. There is no free lunch
> from upstream here.

Sure - that may well be the case.

But if a few OpenStack vendors are willing to collaborate on the work,
would it not be better to centralise it, instead of each vendor forking
and doing the same fixes?

No so much a free lunch, as a spreading the cost of a lunch.

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


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

Re: [openstack-dev] [requirements] History lesson please

[Hayes, Graham]

On 09/08/2016 19:41, John Dickinson wrote:
>
>
> On 9 Aug 2016, at 11:33, Ian Cordasco wrote:
>
>>
>>
>> -Original Message-
>> From: John Dickinson 
>> Reply: OpenStack Development Mailing List (not for usage questions) 
>> 
>> Date: August 9, 2016 at 13:17:08
>> To: OpenStack Development Mailing List 
>> Subject:  Re: [openstack-dev] [requirements] History lesson please
>>
>>> I'd like to advocate for *not* raising minimum versions very often. Every 
>>> time some OpenStack
>>> project raises minimum versions, this change is propagated to all projects, 
>>> and that
>>> puts extra burden on anyone who is maintaining packages and dependencies in 
>>> their own
>>> deployment. If one project needs a new feature introduced in version 32, 
>>> but another
>>> project claims compatibility with >=28, that's ok. There's no need for the 
>>> second project
>>> to raise the minimum version when there isn't a conflict. (This is the 
>>> position I advocated
>>> for at the Austin summit.)
>>>
>>> Yes, I know that currently we don't test every possible version 
>>> permutation. Yes, I know
>>> that doing that is hard. I'm not ignoring that.
>>
>> Right. So with the current set-up, where these requirements are propogated 
>> to every project, how do projects express their own minimum version 
>> requirement?
>>
>> Let's assume someone is maintaining their own packages and dependencies. If 
>> (for example) Glance requires a minimum version of Routes and Nova has a 
>> minimum requirement newer than Glance's, they're not coinstallable (which 
>> was the original goal of the requirements team). What you're asking for ends 
>> up being "Don't rely on new features in a dependency". If OpenStack drops 
>> the illusion of coinstallability that ends up being fine. I don't think 
>> anyone wants to drop that though.
>
> In that case, they are still co-installable, because the nova minimum 
> satisfies both.

But then packagers are going to have to do the work anyway, as it will
have in effect raised the minimum version of routes for Glance, and thus
need a new package.

It might not make a difference to deployers / packagers who only deploy
one project from OpenStack, but they are in the minority - having a
known good minimum for requirements helps deployers who have multiple
services to deploy.

>
>>
>> --
>> Ian Cordasco


__
OpenStack Development Mailing 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][os-api-ref] openstackdocstheme integration

[Hayes, Graham]

On 08/08/2016 13:47, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-08-08 11:28:35 +:
>> On 05/08/2016 19:15, Doug Hellmann wrote:
>>> Excerpts from Hayes, Graham's message of 2016-08-05 17:04:35 +:
 Hey,

 We look like we are getting close to merging the os-api-ref integration
 with openstackdocstheme.

 Unfortunately, there is no "phased" approach available - the version
 released with compatibility for openstackdocstheme will not work
 with oslo.sphinx.
>>>
>>> In what way doesn't it work? Is one of the themes missing something?
>>>
>>> Doug
>>
>> Both themes are laid out differently. One uses bootstrap and the other
>> doesn't, one has a different view on what should be hidden, and where
>> TOCs belong.
>>
>> The end result was that for the oslosphinx integration we included extra
>> CSS / JS, but that code can cause conflicts with openstackdocstheme.
>
> Would putting that extra stuff into oslosphinx, as an optional part of
> the them, make the transition any easier?
>
> Doug

I don't think so - with the changes to the structure of the HTML things
will be broken anyway.

It is unfortunate, but I think we have a better chance of doing the cut
over now, before more projects start using the library.

If everyone agrees with the patch for the phased roll over, I can submit
the patches to all the required repos, and help them get merged.

Graham

>>
>> As one theme already uses bootstrap, the css (and the classes applied
>> to the HTML elements) has to be modified, and is incompatible with the
>> old theme, as it was only using the sideloaded bootstrap css in a
>> section of the page.
>>
>> The review for the integration is here:
>>
>> https://review.openstack.org/#/c/322430/
>>
>> - Graham
>>
>>>
 So, we need a way to use oslosphinx until it is released, and the new
 theme after it is released.


 I suggest we put a temporary section of code in the `conf.py` of each
 project using os-api-ref - I have a WIP preview for designate up for
 review [0]

 Can I get some feedback, if people think this is a good way forward?

 The list of repos I have using os-api-ref is (from [1]:

 openstack/networking-sfc
 openstack/ceilometer
 openstack/glance
 openstack/heat
 openstack/ironic
 openstack/keystone
 openstack/manila
 openstack/designate
 openstack/neutron-lib
 openstack/nova
 openstack/sahara
 openstack/searchlight
 openstack/senlin
 openstack/swift
 openstack/zaqar

 Thanks,

 Graham

 0 - https://review.openstack.org/#/c/351800/
 1 -
 http://codesearch.openstack.org/?q=os_api_ref=nope=api-ref%2Fsource%2Fconf.py=

>>>
>>> __
>>> OpenStack Development Mailing 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] [api][os-api-ref] openstackdocstheme integration

[Hayes, Graham]

On 05/08/2016 19:15, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-08-05 17:04:35 +:
>> Hey,
>>
>> We look like we are getting close to merging the os-api-ref integration
>> with openstackdocstheme.
>>
>> Unfortunately, there is no "phased" approach available - the version
>> released with compatibility for openstackdocstheme will not work
>> with oslo.sphinx.
>
> In what way doesn't it work? Is one of the themes missing something?
>
> Doug

Both themes are laid out differently. One uses bootstrap and the other
doesn't, one has a different view on what should be hidden, and where
TOCs belong.

The end result was that for the oslosphinx integration we included extra
CSS / JS, but that code can cause conflicts with openstackdocstheme.

As one theme already uses bootstrap, the css (and the classes applied
to the HTML elements) has to be modified, and is incompatible with the
old theme, as it was only using the sideloaded bootstrap css in a
section of the page.

The review for the integration is here:

https://review.openstack.org/#/c/322430/

- Graham


>
>> So, we need a way to use oslosphinx until it is released, and the new
>> theme after it is released.
>>
>>
>> I suggest we put a temporary section of code in the `conf.py` of each
>> project using os-api-ref - I have a WIP preview for designate up for
>> review [0]
>>
>> Can I get some feedback, if people think this is a good way forward?
>>
>> The list of repos I have using os-api-ref is (from [1]:
>>
>> openstack/networking-sfc
>> openstack/ceilometer
>> openstack/glance
>> openstack/heat
>> openstack/ironic
>> openstack/keystone
>> openstack/manila
>> openstack/designate
>> openstack/neutron-lib
>> openstack/nova
>> openstack/sahara
>> openstack/searchlight
>> openstack/senlin
>> openstack/swift
>> openstack/zaqar
>>
>> Thanks,
>>
>> Graham
>>
>> 0 - https://review.openstack.org/#/c/351800/
>> 1 -
>> http://codesearch.openstack.org/?q=os_api_ref=nope=api-ref%2Fsource%2Fconf.py=
>>
>
> __
> OpenStack Development Mailing 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] [api][os-api-ref] openstackdocstheme integration

[Hayes, Graham]

Hey,

We look like we are getting close to merging the os-api-ref integration
with openstackdocstheme.

Unfortunately, there is no "phased" approach available - the version
released with compatibility for openstackdocstheme will not work
with oslo.sphinx.

So, we need a way to use oslosphinx until it is released, and the new
theme after it is released.

I suggest we put a temporary section of code in the `conf.py` of each
project using os-api-ref - I have a WIP preview for designate up for
review [0]

Can I get some feedback, if people think this is a good way forward?

The list of repos I have using os-api-ref is (from [1]:

openstack/networking-sfc
openstack/ceilometer
openstack/glance
openstack/heat
openstack/ironic
openstack/keystone
openstack/manila
openstack/designate
openstack/neutron-lib
openstack/nova
openstack/sahara
openstack/searchlight
openstack/senlin
openstack/swift
openstack/zaqar

Thanks,

Graham

0 - https://review.openstack.org/#/c/351800/
1 -
http://codesearch.openstack.org/?q=os_api_ref=nope=api-ref%2Fsource%2Fconf.py=

__
OpenStack Development Mailing 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] Project mascots update

[Hayes, Graham]

On 05/08/2016 16:04, James Bottomley wrote:
> On Thu, 2016-08-04 at 17:09 +1000, Mike Carden wrote:
>> On Thu, Aug 4, 2016 at 4:26 PM, Antoni Segura Puimedon <
>> toni+openstac...@midokura.com> wrote:
>>
>>>
>>> It would be really awesome if, in true OSt and OSS spirit this work
>>> happened in an OpenStack repository with an open, text based format
>>> like SVG. This way people could contribute and review.
>>>
>>>
>> I am strongly in favour of images being stored in open formats. Right
>> now the most widely supported open formats are PNG and SVG. Let's
>> make sure that as often as possible, we all store non-photographic
>> images in formats like these.
>
> As someone who acts as web monkey for various conference websites,
> could I just say please use SVG.  Scalable formats are so much easier
> for website designers to work with and pngs have a habit of looking
> ugly when you're forced to scale them (which inevitably happens when
> you have a bunch and you're trying to get them to look uniform).
>
> James
>

Yeah - Can I echo that. When working on using them for other uses
(t-shirts / USB Keys / presentations / printed docs) having a vector
format makes it *much* easier.

On that note - I may have missed it, but what licence are these logos
being released under? Is there any restrictions on their usage like
there is on the main OpenStack logo?

- 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] [all][tc] establishing project-wide goals

[Hayes, Graham]

On 02/08/2016 16:37, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-08-02 13:49:06 +:
>> On 02/08/2016 14:37, Doug Hellmann wrote:
>>> Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +:
 On 29/07/2016 21:59, Doug Hellmann wrote:
> One of the outcomes of the discussion at the leadership training
> session earlier this year was the idea that the TC should set some
> community-wide goals for accomplishing specific technical tasks to
> get the projects synced up and moving in the same direction.
>
> After several drafts via etherpad and input from other TC and SWG
> members, I've prepared the change for the governance repo [1] and
> am ready to open this discussion up to the broader community. Please
> read through the patch carefully, especially the "goals/index.rst"
> document which tries to lay out the expectations for what makes a
> good goal for this purpose and for how teams are meant to approach
> working on these goals.
>
> I've also prepared two patches proposing specific goals for Ocata
> [2][3].  I've tried to keep these suggested goals for the first
> iteration limited to "finish what we've started" type items, so
> they are small and straightforward enough to be able to be completed.
> That will let us experiment with the process of managing goals this
> time around, and set us up for discussions that may need to happen
> at the Ocata summit about implementation.
>
> For future cycles, we can iterate on making the goals "harder", and
> collecting suggestions for goals from the community during the forum
> discussions that will happen at summits starting in Boston.
>
> Doug
>
> [1] https://review.openstack.org/349068 describe a process for managing 
> community-wide goals
> [2] https://review.openstack.org/349069 add ocata goal "support python 
> 3.5"
> [3] https://review.openstack.org/349070 add ocata goal "switch to oslo 
> libraries"

 I am confused. When I proposed my patch for doing something very similar
 (Equal Chances for all projects is basically a multiple release goal) I
 got the following rebuttals:

  > "and it would be
  > a mistake to try to require that because the issue is almost always
  > lack of resources and not lack of desire. Volunteers to contribute
  > to the work that's needed will do more to help than a
  > one-size-fits-all policy."

  > This isn't a thing that gets fixed with policy. It gets fixed with
  > people.

  > I am reading through the thread, and it puzzles me that I see a lot
  > of right words about goals but not enough hints on who is going to
  > implement that.

  > I think the right solutions here are human ones. Talk with people.
  > Figure out how you can help lighten their load so that they have
  > breathing space. I think hiding behind policy becomes a way to make
  > us more separate rather than engaging folks more directly.

  > Coming at this with top down declarations of how things should work
  > not only ignores reality of the ecosystem and the current state of
  > these projects, but is also going about things backwards.

  > This entirely ignores that these are all open source projects,
  > which are often very sparsely contributed to. If you have an issue
  > with a project or the interface it provides, then contribute to it.
  > Don't make grandiose resolutions trying to force things into what you
  > see as an ideal state, instead contribute to help fix the problems
  > you've identified.

 And yet, we are currently suggesting a system that will actively (in an
 undefined way) penalise projects who do not comply with a different set
 of proposals, done in a top down manner.

 I may be missing the point, but the two proposals seem to have
 similarities - what is the difference?

 When I see comments like:

  > Project teams who join the big tent sign up to the rights and
  > responsibilities that go along with membership. Those responsibilities
  > include taking some direction from the TC, including regarding work
  > they may not give the same priority as the broader community.

 It sounds like top down is OK, but previous ML thread / TC feedback
 has been different.
>>>
>>> One difference is that these goals are not things like "the
>>> documentation team must include every service project in the
>>> installation guide" but rather would be phrased like "every project
>>> must provide an installation guide". The work is distributed to the
>>> vertical teams, and not focused in the horizontal teams.
>>
>> Well, the wording was actually "the documentation team must provide a
>> way for all projects to be included in the documentation guide". The
>> work was on the 

Re: [openstack-dev] [tc] persistently single-vendor projects

[Hayes, Graham]

On 02/08/2016 16:48, Steven Dake (stdake) wrote:
> Responses inline:
>
> On 8/2/16, 8:13 AM, "Hayes, Graham" <graham.ha...@hpe.com> wrote:
>
>> On 02/08/2016 15:42, Flavio Percoco wrote:
>>> On 01/08/16 10:19 -0400, Sean Dague wrote:
>>>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
>>>>> Thierry, Ben, Doug,
>>>>>
>>>>> How can we distinguish between. "Project is doing the right thing, but
>>>>> others are not joining" vs "Project is actively trying to keep people
>>>>> out"?
>>>>
>>>> I think at some level, it's not really that different. If we treat them
>>>> as different, everyone will always believe they did all the right
>>>> things, but got no results. 3 cycles should be plenty of time to drop
>>>> single entity contributions below 90%. That means prioritizing bugs /
>>>> patches from outside groups (to drop below 90% on code commits),
>>>> mentoring every outside member that provides feedback (to drop below
>>>> 90%
>>>> on reviews), shifting development resources towards mentoring / docs /
>>>> on ramp exercises for others in the community (to drop below 90% on
>>>> core
>>>> team).
>>>>
>>>> Digging out of a single vendor status is hard, and requires making that
>>>> your top priority. If teams aren't interested in putting that ahead of
>>>> development work, that's fine, but that doesn't make it a sustainable
>>>> OpenStack project.
>>>
>>>
>>> ++ to the above! I don't think they are that different either and we
>>> might not
>>> need to differentiate them after all.
>>>
>>> Flavio
>>>
>>
>> I do have one question - how are teams getting out of
>> "team:single-vendor" and towards "team:diverse-affiliation" ?
>>
>> We have tried to get more people involved with Designate using the ways
>> we know how - doing integrations with other projects, pushing designate
>> at conferences, helping DNS Server vendors to add drivers, adding
>> drivers for DNS Servers and service providers ourselves, adding
>> features - the lot.
>>
>> We have a lot of user interest (41% of users were interested in using
>> us), and are quite widely deployed for a non tc-approved-release
>> project (17% - 5% in production). We are actually the most deployed
>> non tc-approved-release project.
>>
>> We still have 81% of the reviews done by 2 companies, and 83% by 3
>> companies.
>
> By the objective criteria of team:single-vendor Designate isn't a single
> vendor project.  By the objective criteria of team:diverse-affiliation
> your not a diversely affiliated project either.  This is why I had
> suggested we need a third tag which accurately represents where Designate
> is in its community building journey.
>>
>> I know our project is not "cool", and DNS is probably one of the most
>> boring topics, but I honestly believe that it has a place in the
>> majority of OpenStack clouds - both public and private. We are a small
>> team of people dedicated to making Designate the best we can, but are
>> still one company deciding to drop OpenStack / DNS development from
>> joining the single-vendor party.
>
> Agree Designate is important to OpenStack.  But IMO it is not a single
> vendor project as defined by the criteria given the objective statistics
> you mentioned above.

My point is that we are close to being single vendor - it is a real
possibility over then next few months, if a big contributor was to
leave the project, which may happen.

The obvious solution to avoid this is to increase participation - which
is what we are struggling with.

>>
>> We are definitely interested in putting community development ahead of
>> development work - but what that actual work is seems to difficult to
>> nail down. I do feel sometimes that I am flailing in the dark trying to
>> improve this.
>
> Fantastic its a high-prioiirty goal.  Sad to hear your struggling but
> struggling is part of the activity.
>>
>> If projects could share how that got out of single-vendor or into
>> diverse-affiliation this could really help teams progress in the
>> community, and avoid being removed.
>
> You bring up a fantastic point here - and that is that teams need to share
> techniques for becoming multi-vendor and some day diversely affiliated.  I
> am a super busy atm, or I would volunteer to lead a cross-project effort
> with PTLs to coordinate community bu

Re: [openstack-dev] [tc] persistently single-vendor projects

[Hayes, Graham]

On 02/08/2016 15:42, Flavio Percoco wrote:
> On 01/08/16 10:19 -0400, Sean Dague wrote:
>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
>>> Thierry, Ben, Doug,
>>>
>>> How can we distinguish between. "Project is doing the right thing, but
>>> others are not joining" vs "Project is actively trying to keep people
>>> out"?
>>
>> I think at some level, it's not really that different. If we treat them
>> as different, everyone will always believe they did all the right
>> things, but got no results. 3 cycles should be plenty of time to drop
>> single entity contributions below 90%. That means prioritizing bugs /
>> patches from outside groups (to drop below 90% on code commits),
>> mentoring every outside member that provides feedback (to drop below 90%
>> on reviews), shifting development resources towards mentoring / docs /
>> on ramp exercises for others in the community (to drop below 90% on core
>> team).
>>
>> Digging out of a single vendor status is hard, and requires making that
>> your top priority. If teams aren't interested in putting that ahead of
>> development work, that's fine, but that doesn't make it a sustainable
>> OpenStack project.
>
>
> ++ to the above! I don't think they are that different either and we might not
> need to differentiate them after all.
>
> Flavio
>

I do have one question - how are teams getting out of
"team:single-vendor" and towards "team:diverse-affiliation" ?

We have tried to get more people involved with Designate using the ways
we know how - doing integrations with other projects, pushing designate
at conferences, helping DNS Server vendors to add drivers, adding
drivers for DNS Servers and service providers ourselves, adding
features - the lot.

We have a lot of user interest (41% of users were interested in using
us), and are quite widely deployed for a non tc-approved-release
project (17% - 5% in production). We are actually the most deployed
non tc-approved-release project.

We still have 81% of the reviews done by 2 companies, and 83% by 3
companies.

I know our project is not "cool", and DNS is probably one of the most
boring topics, but I honestly believe that it has a place in the
majority of OpenStack clouds - both public and private. We are a small
team of people dedicated to making Designate the best we can, but are
still one company deciding to drop OpenStack / DNS development from
joining the single-vendor party.

We are definitely interested in putting community development ahead of
development work - but what that actual work is seems to difficult to
nail down. I do feel sometimes that I am flailing in the dark trying to
improve this.

If projects could share how that got out of single-vendor or into 
diverse-affiliation this could really help teams progress in the
community, and avoid being removed.

Making grand statements about "work harder on community" without any
guidance about what we need to work on do not help the community.

- 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

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Hayes, Graham]

On 02/08/2016 14:37, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +:
>> On 29/07/2016 21:59, Doug Hellmann wrote:
>>> One of the outcomes of the discussion at the leadership training
>>> session earlier this year was the idea that the TC should set some
>>> community-wide goals for accomplishing specific technical tasks to
>>> get the projects synced up and moving in the same direction.
>>>
>>> After several drafts via etherpad and input from other TC and SWG
>>> members, I've prepared the change for the governance repo [1] and
>>> am ready to open this discussion up to the broader community. Please
>>> read through the patch carefully, especially the "goals/index.rst"
>>> document which tries to lay out the expectations for what makes a
>>> good goal for this purpose and for how teams are meant to approach
>>> working on these goals.
>>>
>>> I've also prepared two patches proposing specific goals for Ocata
>>> [2][3].  I've tried to keep these suggested goals for the first
>>> iteration limited to "finish what we've started" type items, so
>>> they are small and straightforward enough to be able to be completed.
>>> That will let us experiment with the process of managing goals this
>>> time around, and set us up for discussions that may need to happen
>>> at the Ocata summit about implementation.
>>>
>>> For future cycles, we can iterate on making the goals "harder", and
>>> collecting suggestions for goals from the community during the forum
>>> discussions that will happen at summits starting in Boston.
>>>
>>> Doug
>>>
>>> [1] https://review.openstack.org/349068 describe a process for managing 
>>> community-wide goals
>>> [2] https://review.openstack.org/349069 add ocata goal "support python 3.5"
>>> [3] https://review.openstack.org/349070 add ocata goal "switch to oslo 
>>> libraries"
>>
>> I am confused. When I proposed my patch for doing something very similar
>> (Equal Chances for all projects is basically a multiple release goal) I
>> got the following rebuttals:
>>
>>  > "and it would be
>>  > a mistake to try to require that because the issue is almost always
>>  > lack of resources and not lack of desire. Volunteers to contribute
>>  > to the work that's needed will do more to help than a
>>  > one-size-fits-all policy."
>>
>>  > This isn't a thing that gets fixed with policy. It gets fixed with
>>  > people.
>>
>>  > I am reading through the thread, and it puzzles me that I see a lot
>>  > of right words about goals but not enough hints on who is going to
>>  > implement that.
>>
>>  > I think the right solutions here are human ones. Talk with people.
>>  > Figure out how you can help lighten their load so that they have
>>  > breathing space. I think hiding behind policy becomes a way to make
>>  > us more separate rather than engaging folks more directly.
>>
>>  > Coming at this with top down declarations of how things should work
>>  > not only ignores reality of the ecosystem and the current state of
>>  > these projects, but is also going about things backwards.
>>
>>  > This entirely ignores that these are all open source projects,
>>  > which are often very sparsely contributed to. If you have an issue
>>  > with a project or the interface it provides, then contribute to it.
>>  > Don't make grandiose resolutions trying to force things into what you
>>  > see as an ideal state, instead contribute to help fix the problems
>>  > you've identified.
>>
>> And yet, we are currently suggesting a system that will actively (in an
>> undefined way) penalise projects who do not comply with a different set
>> of proposals, done in a top down manner.
>>
>> I may be missing the point, but the two proposals seem to have
>> similarities - what is the difference?
>>
>> When I see comments like:
>>
>>  > Project teams who join the big tent sign up to the rights and
>>  > responsibilities that go along with membership. Those responsibilities
>>  > include taking some direction from the TC, including regarding work
>>  > they may not give the same priority as the broader community.
>>
>> It sounds like top down is OK, but previous ML thread / TC feedback
>> has been different.
>
> One difference is that these goals are not things like "the
> documentation team must include every service project in the
> installation guide" but rather would be phrased like "every project
> must provide an installation guide". The work is distributed to the
> vertical teams, and not focused in the horizontal teams.

Well, the wording was actually "the documentation team must provide a
way for all projects to be included in the documentation guide". The
work was on the horizontal teams to provide a method, and the vertical
teams to do the actual writing, as an example (that is actually
underway, so it is a bad example.)

A better example would be OSC / Horizon has to provide a way for plugins
to set quotas - it is up to the project teams to actually implement the
code the sets 

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Hayes, Graham]

On 29/07/2016 21:59, Doug Hellmann wrote:
> One of the outcomes of the discussion at the leadership training
> session earlier this year was the idea that the TC should set some
> community-wide goals for accomplishing specific technical tasks to
> get the projects synced up and moving in the same direction.
>
> After several drafts via etherpad and input from other TC and SWG
> members, I've prepared the change for the governance repo [1] and
> am ready to open this discussion up to the broader community. Please
> read through the patch carefully, especially the "goals/index.rst"
> document which tries to lay out the expectations for what makes a
> good goal for this purpose and for how teams are meant to approach
> working on these goals.
>
> I've also prepared two patches proposing specific goals for Ocata
> [2][3].  I've tried to keep these suggested goals for the first
> iteration limited to "finish what we've started" type items, so
> they are small and straightforward enough to be able to be completed.
> That will let us experiment with the process of managing goals this
> time around, and set us up for discussions that may need to happen
> at the Ocata summit about implementation.
>
> For future cycles, we can iterate on making the goals "harder", and
> collecting suggestions for goals from the community during the forum
> discussions that will happen at summits starting in Boston.
>
> Doug
>
> [1] https://review.openstack.org/349068 describe a process for managing 
> community-wide goals
> [2] https://review.openstack.org/349069 add ocata goal "support python 3.5"
> [3] https://review.openstack.org/349070 add ocata goal "switch to oslo 
> libraries"

I am confused. When I proposed my patch for doing something very similar
(Equal Chances for all projects is basically a multiple release goal) I
got the following rebuttals:

 > "and it would be
 > a mistake to try to require that because the issue is almost always
 > lack of resources and not lack of desire. Volunteers to contribute
 > to the work that's needed will do more to help than a
 > one-size-fits-all policy."

 > This isn't a thing that gets fixed with policy. It gets fixed with
 > people.

 > I am reading through the thread, and it puzzles me that I see a lot
 > of right words about goals but not enough hints on who is going to
 > implement that.

 > I think the right solutions here are human ones. Talk with people.
 > Figure out how you can help lighten their load so that they have
 > breathing space. I think hiding behind policy becomes a way to make
 > us more separate rather than engaging folks more directly.

 > Coming at this with top down declarations of how things should work
 > not only ignores reality of the ecosystem and the current state of
 > these projects, but is also going about things backwards.

 > This entirely ignores that these are all open source projects,
 > which are often very sparsely contributed to. If you have an issue
 > with a project or the interface it provides, then contribute to it.
 > Don't make grandiose resolutions trying to force things into what you
 > see as an ideal state, instead contribute to help fix the problems
 > you've identified.

And yet, we are currently suggesting a system that will actively (in an
undefined way) penalise projects who do not comply with a different set
of proposals, done in a top down manner.

I may be missing the point, but the two proposals seem to have 
similarities - what is the difference?

When I see comments like:

 > Project teams who join the big tent sign up to the rights and
 > responsibilities that go along with membership. Those responsibilities
 > include taking some direction from the TC, including regarding work
 > they may not give the same priority as the broader community.

It sounds like top down is OK, but previous ML thread / TC feedback
has been different.

- 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] [oslo][nova][requirements] Getting oslo.context 2.6.0 into the gate

[Hayes, Graham]

On 28/07/2016 01:14, Tony Breeds wrote:
> On Mon, Jul 18, 2016 at 04:09:54PM +0200, Markus Zoeller wrote:
>> Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
>> change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
>> Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
>> Portland and won't be available for the next 2h or so.
>> If you can have a look at it and merge it, that would be great.
>>
>> References:
>> [1]
>> https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1
>> [2] https://review.openstack.org/#/c/342604/1
>> [3] https://bugs.launchpad.net/nova/+bug/1603979
>> [4] logstash: http://goo.gl/79yFb9
>
> I feel like we need to make a plan to more forward and that's going to require
> some coordination.
>
> The requirements team saw this coming in that nova's tests failed when 2.6.0
> was added to the upper-constraints.txt.  We had a plan[1] but then failed to
> execute.  The requirements team has a couple of TODOs from there but the
> biggest one is to add actual cross-project gate checks so that we have *very
> strong* signals that things will break.
>
> So the state we're in is
> oslo.context 2.6.0 is out and used in all projects that *do not* honor 
> upper-constraints.txt
> oslo.context 2.5.0 is being used by all projects that *do* honor 
> upper-constraints.txt
>
> The Path forward IMO is
>
> a) Unblock oslo.context 2.6.0
> - But leave upper-constraints.txt pointing to 2.5.0
> - https://review.openstack.org/#/c/347608/
> * We can test shims/fixes against this.
> b) Identify projects that break with > 2.5.0
> - Seems like this is (at least)
> - Trove
> - Nova
> - Designate

Designate should now work with 2.6.0 with
https://review.openstack.org/#/c/342107/ merged.

> - Others?
> c) Add shims to them to work with 2.5.0 and newer
> - Nova: https://review.openstack.org/#/c/342604/ and 
> https://review.openstack.org/#/c/348057/
> d) Bump u-c to point at "the latest"
> e) Bump the minium in g-r to 2.6.0
> f) Remove items from 'c'
>
> Notes:
>  - The requirements team will not be able to merge any change that bumps
>oslo.context in u-c until step 'd'.  The reality here is due to our
>tooling/gating that probably means that all u-c changes will be paused
>  - As stated in my pre-amble we're working on testing to make this better.
>  - We almost certainly need a corss-project session during the design summit 
> to
>discuss the API boundry for the context and how projects are
>expected/allowed to use it.
>
> Yours Tony.
>
> [1] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-requirements/%23openstack-requirements.2016-07-15.log.html#t2016-07-15T03:42:24
>


__
OpenStack Development Mailing 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] Equal Chances for all projects (was Plugins for all)

[Hayes, Graham]

On 26/07/2016 18:47, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-07-26 13:48:35 +:
>> On 26/07/2016 14:15, Sean Dague wrote:
>>> On 07/26/2016 08:51 AM, Doug Hellmann wrote:
>>> 

 Given the amount of in-progress work to address the issue you've
 raised, I'm not convinced we need a global rule or policy. All of
 the teams mentioned are working toward the goal of providing stable
 APIs already, and no one seems to be arguing against that goal. The
 teams doing the work are not dragging their feet, and a rule or
 policy wouldn't make the work go any faster.

 The directions for cross-project teams were given when the bit tent
 change went into effect were to "support all official teams" and
 definitely not "do the work for all official teams." There was also
 no requirement that the support be exactly equal, and it would be
 a mistake to try to require that because the issue is almost always
 lack of resources and not lack of desire.  Volunteers to contribute
 to the work that's needed will do more to help than a one-size-fits-all
 policy.
>>>
>>> Yes, exactly.
>>>
>>> Like Ihar said earlier, we get all kinds of breaks across out system all
>>> the time. It's a complex system. If you look hard what you'll notice is
>>> that project interactions where there are team members in common break a
>>> bit less. For instance Grenade breaks Nova less than other projects.
>>> oslo.versionedobjects breaks Nova less than oslo.messaging does. Why?
>>> Because even with stable interfaces and tests, a lot of behavior remains
>>> in flux given the patch rate on all projects. And when people understand
>>> both sides of a problem, they are more likely to anticipate a problem
>>> during review that no tests caught and didn't seem to change an interface.
>>>
>>> This isn't a thing that gets fixed with policy. It gets fixed with people.
>>>
>>> -Sean
>>>
>>
>> If this is where all these projects are going, is a policy not a good
>> way to indicate that this is how we want to work in the future?
>>
>> So when the next project starts, or a team wants to move in a different
>> direction we have a piece of policy that shows we feel that this is the
>> way we work as a community?
>>
>> I don't understand the objection to stating "this is how we should work"
>> when teams are moving that way anyway.
>>
>> If to do that we need to dilute the policy, so be it.
>>
>
> I do agree that writing down our expectations is a good thing.  In
> this case, I think the policy that the TC has agreed to is accurately
> and sufficiently documented in the existing resolution under the
> "Impact for horizontal teams" section [1].  The stewardship working
> group is actively working on a set of general principles for the
> TC to consider, and it may make sense to incorporate the existing
> policy into that list of principles to make it easier to find.

Sure, I know the work they are doing - this has been bouncing around
my PC for a bit before I had any knowledge of what the plans were there.

> I personally don't agree with changing the policy, or making it
> "stronger" in some way, right now because I'm not convinced that
> we need to treat all projects exactly the same in all cases.  It

This is the crux of the debate.

Are all projects equal?

If they are not, I will be disappointed, but we should then move to
define this in-equality, and state who is in, and who is out.

In some ways we are back to the stackforge vs integrated situation,
but unlike then we have no frame of reference for how a project would
become more equal.

If projects have difficulty getting into top level docs (for example)
it is more difficult to grow adoption, which would let them into
top level docs, which would help adoption ...

> seems like a relatively benign assumption to make, but until we
> actually have an issue that would be solved by formalizing it in

I think that we have one. I could be wrong (it happens), but I think
this is a problem, and waiting for something bigger to happen, then
having the existential debate about what OpenStack is (again) causes
issues that could be dealt with to grow. (See Golang discussion).

> policy I would prefer to avoid introducing unintended consequences
> in implementations of projects brought on by layers of rules.  We
> don't want any projects discriminated against, but I don't think
> that's what is happening in these cases, and I think the existing
> policy addresses that case.

And I disagree - I think we need it to be more explicit.

> Doug
>
> [1] 
> http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html#impact-for-horizontal-teams
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

[Hayes, Graham]

On 26/07/2016 14:15, Sean Dague wrote:
> On 07/26/2016 08:51 AM, Doug Hellmann wrote:
> 
>>
>> Given the amount of in-progress work to address the issue you've
>> raised, I'm not convinced we need a global rule or policy. All of
>> the teams mentioned are working toward the goal of providing stable
>> APIs already, and no one seems to be arguing against that goal. The
>> teams doing the work are not dragging their feet, and a rule or
>> policy wouldn't make the work go any faster.
>>
>> The directions for cross-project teams were given when the bit tent
>> change went into effect were to "support all official teams" and
>> definitely not "do the work for all official teams." There was also
>> no requirement that the support be exactly equal, and it would be
>> a mistake to try to require that because the issue is almost always
>> lack of resources and not lack of desire.  Volunteers to contribute
>> to the work that's needed will do more to help than a one-size-fits-all
>> policy.
>
> Yes, exactly.
>
> Like Ihar said earlier, we get all kinds of breaks across out system all
> the time. It's a complex system. If you look hard what you'll notice is
> that project interactions where there are team members in common break a
> bit less. For instance Grenade breaks Nova less than other projects.
> oslo.versionedobjects breaks Nova less than oslo.messaging does. Why?
> Because even with stable interfaces and tests, a lot of behavior remains
> in flux given the patch rate on all projects. And when people understand
> both sides of a problem, they are more likely to anticipate a problem
> during review that no tests caught and didn't seem to change an interface.
>
> This isn't a thing that gets fixed with policy. It gets fixed with people.
>
>   -Sean
>

If this is where all these projects are going, is a policy not a good
way to indicate that this is how we want to work in the future?

So when the next project starts, or a team wants to move in a different
direction we have a piece of policy that shows we feel that this is the
way we work as a community?

I don't understand the objection to stating "this is how we should work"
when teams are moving that way anyway.

If to do that we need to dilute the policy, so be it.

__
OpenStack Development Mailing 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] Equal Chances for all projects (was Plugins for all)

[Hayes, Graham]

On 26/07/2016 14:18, Doug Hellmann wrote:
> Excerpts from Luigi Toscano's message of 2016-07-26 15:02:28 +0200:
>> On Tuesday, 26 July 2016 08:34:27 CEST Doug Hellmann wrote:
>>> Excerpts from Andrea Frittoli's message of 2016-07-26 10:24:07 +:

 What still requires work in Tempest is the stable interface. Because
 plugins are not in the Tempest tree, the QA team recommend that they use
 only tempest stable interfaces. Increasing the surface of stable
 interfaces
 is what keeps a lot of the QA folks busy.

 There's a lot of code in tempest that was written under the assumption
 that
 all tests would always live in the tempest tree; evolving that code into a
 stable publicly consumable interface is simply a lot of work, which the QA
 team is prioritising based on the input from plugins.

 Tempest plugins are for all right now. Keystone, Cinder and Neutron
 already
 have a plugin today. We don't want tests which are not relevant for
 integration or defcore to be added to Tempest, and that is true for *all*
 services.
>>>
>>> Thank you for those details, and for confirming that the situation
>>> is more or less what I expected (it's in progress, creating a stable
>>> API takes work, etc.). Where would someone who wanted to contribute
>>> look for details? Are there specs or an etherpad with a task list
>>> or something like that?
>> Andrea can share more details as he is driving the Client Manager refactors,
>> but for example:
>>
>> http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager-refactor.html
>> https://etherpad.openstack.org/p/newton-tempest-service-clients
>
> Good.
>
>>
>>>
>>> And just to satisfy my own curiosity, how does someone looking at the
>>> internals of tempest know what's on the stable API and what's not
>>> considered stable? Are the parts of the API documented separately
>>> somehow or is there a different part of the code tree to look at?
>>
>> tempest.lib is the stable part (previously split in a separate tempest-lib
>> repository, which is now deprecated as the code was put back into the main
>> tempest repository):
>> http://docs.openstack.org/developer/tempest/overview.html#library
>
> That seems quite clear, thanks.

it is actually a bit more -

http://docs.openstack.org/developer/tempest/plugin.html

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


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

[openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

[Hayes, Graham]

Top posting - this is a recap of what has been said, and some
clarifications

I realise that I was not very clear at the beginning of this process, so
here is my effort to clarify things, from the ML thread, and the review.

 >   ... does this also include plugins within projects, like storage
 >   backends in cinder and hypervisor drivers in nova?

No - this was not clear enough. This change is aimed at projects that are
points of significant cross project interaction. While, in the future 
there may
come a point where Nova Compute Drivers are developed out of tree (though
I doubt it), that is not happening today. As a result, there is no 
projects in
the list of projects that would need to integrate with Nova.

 >   Could you please clarify: do you advocate for a generic plugin 
interface for
 >   every project, or that each project should expose a plugin 
interface that
 >   allows plugin to behave as in-tree components? Because the latter 
is what
 >   happens with Tempest, and I see the former a bit complicated.

For every project that has cross project interaction - tempest is a good
example.

For these projects, they should allow all projects in tree (like Nova,
Neutron, Cinder etc are today), or they should have a plugin interface
(like they currently do), but all projects *must* use it, and not use
parts of tempest that are not exposed in that interface.

This would mean that tempest would move the nova, neutron, etc tests to
use the plugin interface.

Now, that plugin could be kept in the tempest repo, and still maintained
by the QA team, but should use the same interface as the other plugins
that are not in that repository.

Of course, it is not just tempest - an incomplete list looks like:

* Tempest
* Devstack
* Grende
* Horizon
* OpenStack Client
* OpenStack SDK
* Searchlight
* Heat
* Mistral
* Celiometer
* Rally
* Documentation

And I am sure I have missed some obvious ones. (if you see a project missing
let me know on the review)


 >   I think I disagree here. The root cause is being addressed: 
external tests can
 >   use the Tempest plugin interface, and use the API, which is being 
stabilized.
 >   The fact that the Tempest API is partially unstable is a temporary 
things, due
 >   to the origin of the project and the way the scope was redefined, 
but again
 >   it's temporary.

This seems to be the core of a lot of the disagreement - this is only 
temporary,
it will all be fixed in the future, and it should stay this way.

Unfortunately the discrepancy between projects is not temporary. The 
specific
problems I have highlighted in the thread for one of the projects is 
temporary,
but I beleive the only long-term solution is to remove the difference 
between
projects.

 >   Before we start making lots of specific rules about how teams
 >   coordinate, I would like to understand the problem those rules are 
meant
 >   to solve, so thank you for providing that example.
 >   ...
 >   It's not clear yet whether there needs to be a new policy to change the
 >   existing intent, or if a discussion just hasn't happened, or if someone
 >   simply needs to edit some code.

Unfortunately there is a big push back on editing code to help plugins from
some of the projects. Again, having the differing access between 
projects will
continue to exacerbate the problem.


 >   "Change the name of the resolution"

That was done in the last patchset. I think the Level Playing Field title
bounced around my head from the other resolution that was titled Level 
Playing
Field. It may have been confusing alright.

I feel like I have been using tempest as an example a little too much, 
as it captures
the current issues perfectly, and a large number of the community have some
knowledge of it, and how it works.

There is other areas across OpenStack where plugins need attention as well:

Horizon
---

Horizon privileged projects have access to much more panels than
plugins (service status, quotas, overviews etc).
Plugins have to rely on tarballs of horizon

OpenStack Client


OpenStack CLI privileged projects have access to more commands, as
plugins cannot hook in to them (e.g. quotas)

Grenade
---

Plugins may or may not have tempest tests ran (I think that patch
merged), they have to use parts of tempest I was told explicitly
plugins should not use to get the tests to run at that point.

Docs


We can now add install guides and hook into the API Reference, and API
guides. This is great - and I am really happy about it. We still have
issues trying to integrate with other areas in docs, and most non docs
privileged projects end up with massive amounts of users docs in
docs.openstack.org/developer/ , which is not ideal.


Thanks,

Graham

On 14/07/2016 20:25, Hayes, Graham wrote:
> I just proposed a review to openstack/governance repo [0] that aims
> to have everything across OpenStack be plugin based for all cross

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 21/07/2016 16:49, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-07-19 16:59:20 +:
>> On 19/07/2016 16:39, Doug Hellmann wrote:
>>> Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
>>>> On 18/07/2016 17:57, Thierry Carrez wrote:
>>>>> Hayes, Graham wrote:
>>>>>> [...]
>>>>>> The point is that we were supposed to be a level field as a community
>>>>>> but if we have examples like this, there is not a level playing field.
>>>>>
>>>>> While I generally agree on your goals here (avoid special-casing some
>>>>> projects in generic support projects like Tempest), I want to clarify
>>>>> what we meant by "level playing field" in a recent resolution.
>>>>
>>>>
>>>> Yes - it has been pointed out the title is probably overloading a term
>>>> just used for a different purpose - I am more than willing to change it.
>>>>
>>>> I wasn't sure where I got the name, and I realised that was probably in
>>>> my head from that resolution.
>>>>
>>>>> This was meant as a level playing field for contributors within a
>>>>> project, not a level playing field between projects. The idea is that
>>>>> any contributor joining any OpenStack project should not be technically
>>>>> limited compared to other contributors on the same project. So, no
>>>>> "secret sauce" that only a subset of developers on a project have access 
>>>>> to.
>>>>
>>>> There is a correlation here - "special sauce" (not secret obviously)
>>>> that only a subset of projects have access to.
>>>>
>>>>> I think I understand where you're gong when you say that all projects
>>>>> should have equal chances, but keep in mind that (1) projects should not
>>>>> really "compete" against each other (but rather all projects should
>>>>> contribute to the success of OpenStack as a whole) and (2) some
>>>>> OpenStack projects will always be more equal than others (for example we
>>>>> require that every project integrates with Keystone, and I don't see
>>>>> that changing).
>>>>
>>>> Yes, I agree we should not be competing. But was should not be asking
>>>> the smaller projects to re-implement functionality, just because they
>>>> did not get integrated in time.
>>>>
>>>> We require all projects to integrate with keystone for auth, as we
>>>> require all projects to integrate with neutron for network operations
>>>> and designate for DNS, I just see it as a requirement for using the
>>>> other components of OpenStack for their defined purpose.
>>>>
>>>
>>> It would be useful to have some specific information from the QA/Tempest
>>> team (and any others with a similar situation) about whether the current
>>> situation about how differences between in-tree tests and plugin tests
>>> are allowed to use various APIs. For example, are there APIs only
>>> available to in-tree tests that are going to stay that way? Or is this
>>> just a matter of not having had time to "harden" or "certify" or
>>> otherwise prepare those APIs for plugins to use them?
>>
>> "Staying that way" is certainly the impression given to users from
>> other projects.
>
> OK, but is that an "impression" or is it a stated "policy"?
>
>> In any case tempest is just an example. From my viewpoint, we need to
>> make this a community default, to avoid even the short (which really
>> ends up a long) term discrepancy between projects.
>
> Before we start making lots of specific rules about how teams
> coordinate, I would like to understand the problem those rules are meant
> to solve, so thank you for providing that example. I still haven't heard
> from the QA team, though. Ken'ichi?
>
>> If the standard in the community is equal access, this means when the
>> next testing tool, CLI, SDK, $cross_project_tool comes along, it is
>> available to all projects equally.
>>
>> If everyone uses the interfaces, they get better for all users of them,
>> "big tent projects" and "tc-approved-release" alike. Having two
>> way of doing the same thing means that there will always be
>> discrepancies between people who are in the club, and those who are not.
>
> I think I understand y

Re: [openstack-dev] [horizon] Plugin stability, failing tests etc.

[Hayes, Graham]

On 20/07/2016 15:13, Rob Cresswell wrote:
> Yes, it would mean changing your requirements after a release. So, for
> example you might run two gate tests:
>
> - A voting Horizon-stable/milestone test, (or both)
> - A non-voting Horizon-master test
>
> That gives you a lot of control over making your tests passing (multiple
> patches to make the Horizon-master test pass, or all in one patch set
> alongside the horizon-milestone test bump), rather than random failures
> each week. You'd still be able to track the failures as they come in,
> but they won't break your gate each time.

I don't want control, I want to consume a library in a standard way -
the way we consume libraries from the rest of openstack.

> I don't think where horizon (the library) lives would change how you
> version against it. We don't currently have any plans to separate the
> two; while we realise its a desirable change, weighing the work and risk
> involved in the split architecture vs the end result, we've chosen to
> work on other higher priority items for now (performance, filtering
> improvements, angular work etc.)

Well, if would stop us having a reference to git branch in our
requirements, and allow to use the standard global requirements
process to manage the dependency.

It also means that as a plugin I know that the released version of
my plugin has been tested in my gate with the exact version of the
code that the horizon team release.

We can still do multiple patches to fix any changes in the horizon
library, and in the tip of the chain update the version in requirements.

The risk has just been moved to the plugins, which is not ideal.

It also makes downstream consumption *a lot* easier.

>
>
> On 20 July 2016 at 13:38, Hayes, Graham <graham.ha...@hpe.com
> <mailto:graham.ha...@hpe.com>> wrote:
>
> On 20/07/2016 10:16, Rob Cresswell wrote:
> > Hey all,
> >
> > So we've had a few issues with plugin stability recently, and its
> > apparent that many plugins are building off Horizon master as a
> > dependency. I would really advise against this. A more manageable
> > development process may be to:
> >
> > - Base stable plugins against a stable release of Horizon
> > - Base WIP versions/new plugins off the last Horizon milestone, b2 in
> > this case, and then bump the version and capture issues within the same
> > patch. This should prevent random breakages, and should allow you to
> > just look at the release notes for that milestone.
>
> So this would mean changing tox.ini or requirements files after each
> horizon release?
>
> This dovetails nicely with the other thread about how we should be doing
> cross project interactions.
>
> What would be best, would be having horizon released as a separate
> library on pypi like the clients and oslo libs.
>
> Then openstack-dashboard, and all the plugins could rely on the same
> base library, without hacks like:
>
>deps =
>  -r{toxinidir}/requirements.txt
>  -r{toxinidir}/test-requirements.txt
>  http://tarballs.openstack.org/horizon/horizon-master.tar.gz
>
> in tox.ini or
>
># Testing Requirements
>
>  http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon
>
> in (test-)requirements.txt
>
> Is that on roadmap?
>
> > On the Horizon side, we've moved our FF a week earlier, so I think that
> > week combined with the usual RC period should be enough time to fix
> > bugs. We'll aim to make sure our release notes are complete with regards
> > to breaking issues for plugins, and deprecate appropriately.
> >
> > Rob
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://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] [horizon] Plugin stability, failing tests etc.

[Hayes, Graham]

On 20/07/2016 10:16, Rob Cresswell wrote:
> Hey all,
>
> So we've had a few issues with plugin stability recently, and its
> apparent that many plugins are building off Horizon master as a
> dependency. I would really advise against this. A more manageable
> development process may be to:
>
> - Base stable plugins against a stable release of Horizon
> - Base WIP versions/new plugins off the last Horizon milestone, b2 in
> this case, and then bump the version and capture issues within the same
> patch. This should prevent random breakages, and should allow you to
> just look at the release notes for that milestone.

So this would mean changing tox.ini or requirements files after each
horizon release?

This dovetails nicely with the other thread about how we should be doing
cross project interactions.

What would be best, would be having horizon released as a separate
library on pypi like the clients and oslo libs.

Then openstack-dashboard, and all the plugins could rely on the same
base library, without hacks like:

   deps =
 -r{toxinidir}/requirements.txt
 -r{toxinidir}/test-requirements.txt
 http://tarballs.openstack.org/horizon/horizon-master.tar.gz

in tox.ini or

   # Testing Requirements
   http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon

in (test-)requirements.txt

Is that on roadmap?

> On the Horizon side, we've moved our FF a week earlier, so I think that
> week combined with the usual RC period should be enough time to fix
> bugs. We'll aim to make sure our release notes are complete with regards
> to breaking issues for plugins, and deprecate appropriately.
>
> Rob


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

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 19/07/2016 16:39, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
>> On 18/07/2016 17:57, Thierry Carrez wrote:
>>> Hayes, Graham wrote:
>>>> [...]
>>>> The point is that we were supposed to be a level field as a community
>>>> but if we have examples like this, there is not a level playing field.
>>>
>>> While I generally agree on your goals here (avoid special-casing some
>>> projects in generic support projects like Tempest), I want to clarify
>>> what we meant by "level playing field" in a recent resolution.
>>
>>
>> Yes - it has been pointed out the title is probably overloading a term
>> just used for a different purpose - I am more than willing to change it.
>>
>> I wasn't sure where I got the name, and I realised that was probably in
>> my head from that resolution.
>>
>>> This was meant as a level playing field for contributors within a
>>> project, not a level playing field between projects. The idea is that
>>> any contributor joining any OpenStack project should not be technically
>>> limited compared to other contributors on the same project. So, no
>>> "secret sauce" that only a subset of developers on a project have access to.
>>
>> There is a correlation here - "special sauce" (not secret obviously)
>> that only a subset of projects have access to.
>>
>>> I think I understand where you're gong when you say that all projects
>>> should have equal chances, but keep in mind that (1) projects should not
>>> really "compete" against each other (but rather all projects should
>>> contribute to the success of OpenStack as a whole) and (2) some
>>> OpenStack projects will always be more equal than others (for example we
>>> require that every project integrates with Keystone, and I don't see
>>> that changing).
>>
>> Yes, I agree we should not be competing. But was should not be asking
>> the smaller projects to re-implement functionality, just because they
>> did not get integrated in time.
>>
>> We require all projects to integrate with keystone for auth, as we
>> require all projects to integrate with neutron for network operations
>> and designate for DNS, I just see it as a requirement for using the
>> other components of OpenStack for their defined purpose.
>>
>
> It would be useful to have some specific information from the QA/Tempest
> team (and any others with a similar situation) about whether the current
> situation about how differences between in-tree tests and plugin tests
> are allowed to use various APIs. For example, are there APIs only
> available to in-tree tests that are going to stay that way? Or is this
> just a matter of not having had time to "harden" or "certify" or
> otherwise prepare those APIs for plugins to use them?

"Staying that way" is certainly the impression given to users from
other projects.

In any case tempest is just an example. From my viewpoint, we need to
make this a community default, to avoid even the short (which really
ends up a long) term discrepancy between projects.

If the standard in the community is equal access, this means when the
next testing tool, CLI, SDK, $cross_project_tool comes along, it is
available to all projects equally.

If everyone uses the interfaces, they get better for all users of them,
"big tent projects" and "tc-approved-release" alike. Having two
way of doing the same thing means that there will always be
discrepancies between people who are in the club, and those who are not.

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


__
OpenStack Development Mailing 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] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

[Hayes, Graham]

On 19/07/2016 15:11, Joshua Harlow wrote:
> Hayes, Graham wrote:
>> On 18/07/16 22:27, Ronald Bradford wrote:
>>> Hi All,
>>>
>>> For Oslo libraries we ensure that API's are backward compatible for 1+ 
>>> releases.
>>> When an Oslo API adds a new class attribute (as in this example of
>>> is_admin_project and 4 other attributes) added to Oslo Context in
>>> 2.6.0,  these are added to ensure this API is also forward compatible
>>> with existing project code for any contract with the base class
>>> instantiation or manipulation.
>>
>> Which projects is this run against?
>>
>>> The issue seen is presently Nova specific (as other projects can
>>> utilize 2.6.0) and it is related to projects that sub-class
>>> oslo.context, and how unit tests are written for using class
>>> parameters.  Ideally, to implement using oslo.context correctly
>>> OpenStack projects should:
>>
>> Designate also had to make a quick change to support 2.6.0.
>>
>> We were lucky as it was noticed by the RDO builds, which had pulled in
>> 2.6.0 before the requirements update was proposed, so it did not break
>> our gate.
>>
>> I just did a quick search and there is a few projects that hardcoded
>> this, like we did.
>
> Ya, that's bad, nothing in the docs of the to_dict API say what to even
> compare against (or the keys produced), so I'm pretty sure anyone doing
> this is setting themselves up for future failure and fragile software.
>
>>
>>> * Not perform direct dictionary to dictionary comparisons with the
>>> to_dict() method as this does not support when new attributes at
>>> added. Two patches (one to nova) address this in offending projects
>>> [5][6]
>>> * Unit tests should focus on attributes specific to the sub-classed
>>> signature, e.g. [7].  Oslo context provides an extensive set of unit
>>> tests for base class functionality. This is a wish list item for
>>> projects to implement.
>>>
>>> The to_dict() method exists as a convenience method only and is not an
>>> API contract. The resulting set of keys should be used accordingly.
>>> This is why there is no major release version.
>>
>> How are developers supposed to know that?
>
> So we (in oslo) can (and ideally will) make this better but when the API
> doesn't itself tell you what keys are produced or what the values of
> those keys are then it should be pretty obvious to u (the library user)
> that u can not reliably do dictionary comparisons (because how do u know
> what to compare against when the docs don't state that?). I suppose
> people are 'reverse engineering the dict' by just looking at the code
> but that's also not so great...

Its worth noting we took what we had from the context in olso incubator
and moved to oslo.context in 2014. (at that point is was a straight
swap of the import, and a single rename.)

We haven't had to change it since then - so I would have considered it
a stable interface.

>>
>> This kind of feels like semantics. This was an external API that changed
>> and as a result should have been a major version.
>
> I think this is where it gets a little bit into as u said, semantics,
> but the semantics IMHO are important here because it affects the ability
> of oslo.context to move forward & change.
>
> I suppose we should/could just put a warning on this method like I did
> in taskflow (for something similar) @
> https://github.com/openstack/taskflow/blob/master/taskflow/engines/base.py#L71
> to denote that nothing in the dict that is returned can be guaranteed to
> always be the same.

Or even in the usage section of the docs, show how you should use it
properly, and explain that the keys can (and will over time) change.

>>
>>> There is a note from our discussion in Oslo to improve our
>>> documentation to describe the API use of to_dict() better and state we
>>> will not remove to_dict() keys within a release, but that may happen
>>> between releases.
>>>
>>> There is a subsequent problem with how Nova performs a warning test
>>> [8]. Additional reviews are looking at addressing this sub-class usage
>>> of from_dict() and to_dict().
>>>
>>> Regards
>>>
>>> Ronald
>>>
>>>
>>> [5] https://review.openstack.org/#/c/343694/,
>>> [6] https://review.openstack.org/#/c/342367/
>>> [7] https://review.openstack.org/#/c/342869/
>>> [8] 
>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/test_context.py#n144
>>>
>>> On Mon, Jul

Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

[Hayes, Graham]

On 18/07/16 22:27, Ronald Bradford wrote:
> Hi All,
>
> For Oslo libraries we ensure that API's are backward compatible for 1+ 
> releases.
> When an Oslo API adds a new class attribute (as in this example of
> is_admin_project and 4 other attributes) added to Oslo Context in
> 2.6.0,  these are added to ensure this API is also forward compatible
> with existing project code for any contract with the base class
> instantiation or manipulation.

Which projects is this run against?

> The issue seen is presently Nova specific (as other projects can
> utilize 2.6.0) and it is related to projects that sub-class
> oslo.context, and how unit tests are written for using class
> parameters.  Ideally, to implement using oslo.context correctly
> OpenStack projects should:

Designate also had to make a quick change to support 2.6.0.

We were lucky as it was noticed by the RDO builds, which had pulled in
2.6.0 before the requirements update was proposed, so it did not break
our gate.

I just did a quick search and there is a few projects that hardcoded
this, like we did.

> * Not perform direct dictionary to dictionary comparisons with the
> to_dict() method as this does not support when new attributes at
> added. Two patches (one to nova) address this in offending projects
> [5][6]
> * Unit tests should focus on attributes specific to the sub-classed
> signature, e.g. [7].  Oslo context provides an extensive set of unit
> tests for base class functionality. This is a wish list item for
> projects to implement.
>
> The to_dict() method exists as a convenience method only and is not an
> API contract. The resulting set of keys should be used accordingly.
> This is why there is no major release version.

How are developers supposed to know that?

This kind of feels like semantics. This was an external API that changed
and as a result should have been a major version.

> There is a note from our discussion in Oslo to improve our
> documentation to describe the API use of to_dict() better and state we
> will not remove to_dict() keys within a release, but that may happen
> between releases.
>
> There is a subsequent problem with how Nova performs a warning test
> [8]. Additional reviews are looking at addressing this sub-class usage
> of from_dict() and to_dict().
>
> Regards
>
> Ronald
>
>
> [5] https://review.openstack.org/#/c/343694/,
> [6] https://review.openstack.org/#/c/342367/
> [7] https://review.openstack.org/#/c/342869/
> [8] 
> http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/test_context.py#n144
>
> On Mon, Jul 18, 2016 at 10:50 AM, Matt Riedemann
>  wrote:
>> On 7/18/2016 9:42 AM, Matt Riedemann wrote:
>>>
>>> On 7/18/2016 9:09 AM, Markus Zoeller wrote:

 Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
 change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
 Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
 Portland and won't be available for the next 2h or so.
 If you can have a look at it and merge it, that would be great.

 References:
 [1]

 https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1

 [2] https://review.openstack.org/#/c/342604/1
 [3] https://bugs.launchpad.net/nova/+bug/1603979
 [4] logstash: http://goo.gl/79yFb9

>>>
>>> This is an API change for oslo.context, why wasn't it released as 3.0.0?
>>>
>>> Seems we should revert the upper-constraints bump and blacklist 2.6.0,
>>> then get that released as 3.0.0.
>>>
>>
>> Here is the blacklist:
>>
>> https://review.openstack.org/#/c/343683/
>>
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 18/07/2016 17:57, Thierry Carrez wrote:
> Hayes, Graham wrote:
>> [...]
>> The point is that we were supposed to be a level field as a community
>> but if we have examples like this, there is not a level playing field.
>
> While I generally agree on your goals here (avoid special-casing some
> projects in generic support projects like Tempest), I want to clarify
> what we meant by "level playing field" in a recent resolution.


Yes - it has been pointed out the title is probably overloading a term
just used for a different purpose - I am more than willing to change it.

I wasn't sure where I got the name, and I realised that was probably in
my head from that resolution.

> This was meant as a level playing field for contributors within a
> project, not a level playing field between projects. The idea is that
> any contributor joining any OpenStack project should not be technically
> limited compared to other contributors on the same project. So, no
> "secret sauce" that only a subset of developers on a project have access to.

There is a correlation here - "special sauce" (not secret obviously)
that only a subset of projects have access to.

> I think I understand where you're gong when you say that all projects
> should have equal chances, but keep in mind that (1) projects should not
> really "compete" against each other (but rather all projects should
> contribute to the success of OpenStack as a whole) and (2) some
> OpenStack projects will always be more equal than others (for example we
> require that every project integrates with Keystone, and I don't see
> that changing).

Yes, I agree we should not be competing. But was should not be asking
the smaller projects to re-implement functionality, just because they
did not get integrated in time.

We require all projects to integrate with keystone for auth, as we
require all projects to integrate with neutron for network operations
and designate for DNS, I just see it as a requirement for using the
other components of OpenStack for their defined purpose.




__
OpenStack Development Mailing 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] Plugins for all

[Hayes, Graham]

On 17/07/2016 22:08, Jay Pipes wrote:
> On 07/14/2016 12:21 PM, Hayes, Graham wrote:
>> A lot of the effects are hard to see, and are not insurmountable, but
>> do cause projects to re-invent the wheel.
>>
>> For example, quotas - there is no way for a project that is not nova,
>> neutron, cinder to hook into the standard CLI, or UI for setting
>> quotas.
>
> There *is* no standard CLI or UI for setting quotas.

Well if you are nova, neutron or cinder there is.

http://docs.openstack.org/admin-guide/cli_set_quotas.html
http://docs.openstack.org/admin-guide/dashboard_set_quotas.html


>  > They can be done as either extra commands
>> (openstack dns quota set --foo bar) or as custom panels, but not
>> the way other quotas get set.
>
> This has nothing to do with the big tent and everything to do with the
> fact that the community at large has conflated quotas -- i.e. the limit
> of a particular class of resource that a user or tenant can consume --
> with the usage of a particular class of resource. The two things are not
> the same nor do they need to be handled by the same service, IMHO.
>
> I've proposed before that quotas -- i.e. the *limits* for different
> resource classes that a consumer of those resources has -- be handled by
> the Keystone API. This is the endpoint that I personally think makes the
> most sense to house this information.

As have I, but the reality is that *currently* limits are set by quotas.

(As a side note, keystone is the only place that this makes any sense,
but we needed quotas a few years ago, and we had to do what everyone
else had done at the time)

> Usage information is necessarily the domain of the individual service
> projects who must control allocation/consumption of resources under
> their control. It would be *helpful* to have a set of best-practice
> guidelines for projects to follow in safely accounting for consumption
> of resources, but "the big tent" has nothing to do with our community
> failing to do this. We've failed to do this from the beginning of
> OpenStack, well before the big tent was just a spark in the minds of the TC.
>
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface.
>
> What "resources" are you referring to above? What is the "unstable
> interface" you are referring to? Tempest should only ever be validating
> public REST APIs.

The resources in tempest - thinks like setting up users / projects for
running the tests, cleaning up resources post testing, checking if
services are enabled / disabled in the cloud being tested, tagging tests
(smoke, slow, etc)

The are all used by projects using tempest for testing, and all of the
above are only available to projects not using the plugin interface
(the in tree tempest tests, in the openstack/tempest repository)

>> Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>
> An example here would be super-useful, since as mentioned above, Tempest
> should only be validating public HTTP/REST APIs.
>
>> None of this is meant to single out projects, or teams. A lot
>> of the projects that are in this situation have inordinate amounts of
>> work placed on them by the big-tent, and I can emphasize with why things
>> are this way. These were the examples that currently stick out
>> in my mind, and I think we have come to a point where we need to make
>> a change as a community.
>>
>> By moving to a "plugins for all" model, these issues are reduced.
>
> I guess I don't understand what you are referring to as a "plugin"
> above. Are you referring to devstack libXXX things? Or are you referring
> to *drivers* for things like the hypervisor in Nova or the ML2 mech
> drivers in Neutron? Or something else entirely?
>
> 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
>


__
OpenStack Development Mailing 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] testing openstackdocstheme and os-api-ref for API reference info

[Hayes, Graham]

On 15/07/2016 22:58, Anne Gentle wrote:
> Hi -dev and -doc lists, and awesome devs Karen and Graham specifically -
>
> I want to figure out the best way to coordinate a release of both the
> theme and the sphinx extension so that we can test and publish and
> iterate on the new API reference information display and navigation.
>
> I think these patches are relevant and need to be merged:
>
> openstackdocstheme
> https://review.openstack.org/326668 (Actually include custom JS files)

This one is very important.

This would need to be merged, and then a release created so we could
use it

> https://review.openstack.org/329508 (API References dropdown menu)

I have not fully testes this one yet - I will do that this week

> os-api-ref
> https://review.openstack.org/324805 (Tests for invalid parameter files)
> https://review.openstack.org/327309 (microversion selector - dropdown)

There seems to be some rendering problems on Chrome for this one - I 
need to investigate it.

> https://review.openstack.org/318281 (HTTP Response Code Table)

Good to go, afaik.

> https://review.openstack.org/#/c/322430/ (openstackdocstheme integration)

When this merges, and is part of an os-api-ref release, all the api-ref
jobs will break. We need to find a way of putting a section in the
conf.py of each api-ref code base to flip to openstackdocstheme when it
is at the right version.

>
> I think these patches are irrelevant or will keep us from the priority
> task at hand, and it would be best not to merge them until we have
> merged and then test these after getting the above patches released:
> openstackdocstheme
> https://review.openstack.org/269297 (Remove duplicate search field
> from left sidebar)
> https://review.openstack.org/339747 (Removed more reliance on CDNs)
> https://review.openstack.org/333573 (Removed minimized files)
> https://review.openstack.org/339314 (Fix the incorrect CSS values,
> does something to headings I want more testing on)
>
> I'm asking about timing and next steps. Are these the basic steps, and
> am I missing any?

https://review.openstack.org/#/c/322453/ (Change Layout of Path + Sub
Title) needs to merge before https://review.openstack.org/#/c/322430/

This is to allow for longer URLs that Nova and Keystone have.


> 1. Review and merge the relevant patches in both os-api-ref and
> openstackdocstheme.
> 2. Release new versions of  os-api-ref and openstackdocstheme.
> 3. Publish test content with the new versions.
> 4. Update relevant tox.ini and requirements.txt files.
> 5. Rebuild all api-ref source to implement the new navigation.
>
> What I need to know:
> Is there an order we should follow in merging so that testing across
> browsers makes sense?
>
> What is the scope of testing: is testing with the Compute content
> enough or should we also test with Identity and other projects?

I *think* the URLs in identity are longer, we should use that as well.

> What timing should we attempt for steps 1 and 2 above? I'd like to aim
> for August for 1 and 2, is that do-able?

It should be, if we can get quick reviewer feedback on the patches.
For the changes to the projects conf.py, we might need to ping PTLs /
doc liaisons to make sure it gets the required attention.

> Do we need to wait for all the migrated content to be ready for steps
> 4 and 5 above? I think the answer is no, but I might be missing
> relevant info about how the navigation will work. I can also set up a
> meeting for next week if that's easier than email, let me know.
>
> Thanks,
> Anne
>


__
OpenStack Development Mailing 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] Plugins for all

[Hayes, Graham]

On 18/07/2016 01:59, Matt Riedemann wrote:
> On 7/17/2016 4:13 PM, Jay Pipes wrote:
>> On 07/15/2016 08:36 AM, Hayes, Graham wrote:
>>> On 14/07/2016 21:20, Matt Riedemann wrote:
>>>> And does this also include plugins within projects, like storage
>>>> backends in cinder and hypervisor drivers in nova?
>>>
>>> This is aimed at cross project interaction. So, if there is a project in
>>> projects.yaml that is a backend, or a hypervisor driver, it should.
>>>
>>> However, in the proposal, there is a choice that projects can make -
>>> all in tree, or all plugins. The point of the proposal is equality of
>>> access for the community.
>>>
>>> What would that mean in practice for Nova? Nothing would really change
>>> - they have decided to do in tree.
>>>
>>> 99% of deliverables tagged type:service will have no impact from this,
>>> the change will be in projects that are used by  teams across the
>>> community (CLI, Docs, UI etc), and provide a way for these projects
>>> to integrate with them.
>>>
>>> These integration points should be the same for *all* projects.
>>
>> What integration points exactly are you referring to? Can you provide a
>> specific example that Designate has run into issues with?
>>
>>>> Nova has been pushing for a few releases now on getting rid of plug
>>>> points since they are barriers to interoperability.
>>>
>>> Well, nova's plugins were barriers to interoperability, for other
>>> projects they are the only mechanism for interoperability.
>>
>> Perhaps there is some terminology problem here, but plugins absolutely
>> do NOT enable interoperability between clouds. They are the antithesis
>> of interoperability points.
>>
>> The REST APIs (and for projects that support it, the versioned
>> notifications payloads) should be the *only* interoperability and
>> integration points that projects should rely on.
>>
>> 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
>>
>
> I think I'm getting the point. Rather than devstack, tempest,
> openstack-manuals and horizon have stuff baked in for certain projects,
> e.g. nova, cinder, keystone, neutron, etc, every project has to plug in
> the same way, which would force all projects to experience any pain
> associated with dealing with plugging into those projects - and help
> drive making the plugin API better for everyone.
>

That is it - put much more concisely than I managed to.


__
OpenStack Development Mailing 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] Plugins for all

[Hayes, Graham]

On 15/07/2016 18:24, Luigi Toscano wrote:
> On Friday, 15 July 2016 17:05:41 CEST Hayes, Graham wrote:
>> On 15/07/2016 17:52, Luigi Toscano wrote:
>>> On Friday, 15 July 2016 16:42:22 CEST Hayes, Graham wrote:
>>>> On 15/07/2016 17:10, Andrew Laski wrote:
>>>>>> Tempest plugins are another example. Approximately 30 of the 36
>>>>>> current plugins are using resources that are not supposed to be
>>>>>> used, and are an unstable interface. Projects in tree in tempest
>>>>>> are at a much better position, as any change to the internal
>>>>>> API will have to be fixed before the gate merges, but other
>>>>>> out of tree plugins are in a place where they can be broken at any
>>>>>> point.
>>>>>
>>>>> Has there been an attempt to elevate these internal interfaces into
>>>>> stable and publicly consumable interfaces? Was there resistance to such
>>>>> an effort?
>>>>
>>>> When we have asked previously, we have been told that certain parts
>>>> of tempest "are not really meant for plugins".
>>>>
>>>> The main part that is used that is not part of the tempest stable
>>>> interface is the base test class.
>>>>
>>>> This is the bit that sets up credentials, clients, and other useful
>>>> things.
>>>>
>>>> There is a base test class in the tempest lib - but it is very sparse -
>>>> meaning any project using it would have to re-invent creating users,
>>>> resources, and clients.
>>>>
>>>> https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
>>>> vs
>>>> https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22
>>>
>>> This is a known situation, but it is being addressed right now. It's not
>>> like no one wants to have a stable Tempest interface, but it had to be
>>> cleanly built.
>>> There is a spec and work in progress to make the client manager interface
>>> stable:
>>>
>>> http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager
>>> -refactor.html
>>>
>>> So yes, almost existing plugins are using unstable interfaces right now,
>>> but again this is not meant to be the long term scenario.
>>>
>>> Ciao
>>
>> Yeap - I have seen the spec.
>>
>> My point is that if all projects had to use the same plugin interface,
>> this would not be a problem.
>
> Could you please clarify: do you advocate for a generic plugin interface for
> every project, or that each project should expose a plugin interface that
> allows plugin to behave as in-tree components? Because the latter is what
> happens with Tempest, and I see the former a bit complicated.

For every project that has cross project interaction - tempest is a good 
example.

For these projects, they should allow all projects in tree (like Nova, 
Neutron, Cinder etc are today), or they should have a plugin interface 
(like they currently do), but all projects *must* use it, and not use
parts of tempest that are not exposed in that interface.

This would mean that tempest would move the nova, neutron, etc tests to
use the plugin interface.

Now, that plugin could be kept in the tempest repo, and still maintained
by the QA team, but should use the same interface as the other plugins
that are not in that repository.

The point is that we were supposed to be a level field as a community
but if we have examples like this, there is not a level playing field.

>>
>> If we have this as our default position as the community continues to
>> build more and more things like tempest, OSC, devstack, grenade we
>> should build it so there is not a discrepancy between projects.
>>
>> The root cause is not being addressed, as features can still land in
>> tempest, but not tempest.lib, and then can only be used by the projects
>> that tempest keeps as built in.
>
>
> I think I disagree here. The root cause is being addressed: external tests can
> use the Tempest plugin interface, and use the API, which is being stabilized.
> The fact that the Tempest API is partially unstable is a temporary things, due
> to the origin of the project and the way the scope was redefined, but again
> it's temporary.
>

But the situation could very easily re-occur. If there is a new feature
that is added to tempest, but not tempest.lib plugins will have a choice
of re implementing it, or relying on an unstable interface.


__
OpenStack Development Mailing 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] Plugins for all

[Hayes, Graham]

On 15/07/2016 17:52, Luigi Toscano wrote:
> On Friday, 15 July 2016 16:42:22 CEST Hayes, Graham wrote:
>> On 15/07/2016 17:10, Andrew Laski wrote:
>
>>>> Tempest plugins are another example. Approximately 30 of the 36
>>>> current plugins are using resources that are not supposed to be
>>>> used, and are an unstable interface. Projects in tree in tempest
>>>> are at a much better position, as any change to the internal
>>>> API will have to be fixed before the gate merges, but other
>>>> out of tree plugins are in a place where they can be broken at any
>>>> point.
>>>
>>> Has there been an attempt to elevate these internal interfaces into
>>> stable and publicly consumable interfaces? Was there resistance to such
>>> an effort?
>>
>> When we have asked previously, we have been told that certain parts
>> of tempest "are not really meant for plugins".
>>
>> The main part that is used that is not part of the tempest stable
>> interface is the base test class.
>>
>> This is the bit that sets up credentials, clients, and other useful
>> things.
>>
>> There is a base test class in the tempest lib - but it is very sparse -
>> meaning any project using it would have to re-invent creating users,
>> resources, and clients.
>>
>> https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
>> vs
>> https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22
>
>
> This is a known situation, but it is being addressed right now. It's not like
> no one wants to have a stable Tempest interface, but it had to be cleanly
> built.
> There is a spec and work in progress to make the client manager interface
> stable:
>
> http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager-refactor.html
>
> So yes, almost existing plugins are using unstable interfaces right now, but
> again this is not meant to be the long term scenario.
>
> Ciao
>

Yeap - I have seen the spec.

My point is that if all projects had to use the same plugin interface,
this would not be a problem.

If we have this as our default position as the community continues to
build more and more things like tempest, OSC, devstack, grenade we
should build it so there is not a discrepancy between projects.

The root cause is not being addressed, as features can still land in
tempest, but not tempest.lib, and then can only be used by the projects
that tempest keeps as built in.

__
OpenStack Development Mailing 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] Plugins for all

[Hayes, Graham]

On 15/07/2016 17:10, Andrew Laski wrote:
>
>
> On Thu, Jul 14, 2016, at 03:21 PM, Hayes, Graham wrote:
>> I just proposed a review to openstack/governance repo [0] that aims
>> to have everything across OpenStack be plugin based for all cross
>> project interaction, or allow all projects access to the same internal
>> APIs and I wanted to give a bit of background on my motivation, and how
>> it came about.
>
> Which internal APIs are you referring to here? Are you limiting this to
> internal APIs within Tempest/Devstack that projects can use for
> testing/deployment, or are you referring to things like the nova-compute
> service which has an internal RPC API?

Any APIs that are used by other projects. So, an RPC API will probably
be out of scope.

> I feel like I'm missing some context when reading this email because
> there are a lot of references to plugins with no clear definition, that
> I can see, of what exactly you mean by that.

It is for any project that has cross project code. If a project has
ways for other projects to hook in, this interface should be the same.

This means that a project cannot say the Nova can have code that calls
internal code but Glance has to use a plugin that only has access to
certain calls.

>>
>> Coming from a smaller project, I can see issues for new projects,
>> smaller projects, and projects that may not be seen as "important".
>>
>> As a smaller project trying to fit into cross project initiatives,
>> (and yes, make sure our software looks at least OK in the
>> Project Navigator) the process can be difficult.
>>
>> A lot of projects / repositories have plugin interfaces, but also
>> have project integrations in tree, that do not follow the plugin
>> interface. This makes it difficult to see what a plugin can, and
>> should do.
>>
>> When we moved to the big tent, we wanted as a community to move to
>> a flatter model, removing the old integrated status.
>>
>> Unfortunately we still have areas when some projects are more equal -
>> there is a lingering set of projects who were integrated at the point
>> in time that we moved, and have preferential status.
>>
>> A lot of the effects are hard to see, and are not insurmountable, but
>> do cause projects to re-invent the wheel.
>>
>> For example, quotas - there is no way for a project that is not nova,
>> neutron, cinder to hook into the standard CLI, or UI for setting
>> quotas. They can be done as either extra commands
>> (openstack dns quota set --foo bar) or as custom panels, but not
>> the way other quotas get set.
>
> Can you provide more clarity on how "openstack dns quota set --foo bar"
> differs from setting a quota on Nova/Neutron/Cinder?

Sure - nearly all other quotas are set either in the "admin" -> "quotas" 
panel in Horizon (which plugins cannot add their quotas
there.

For the cli - quotas are set as `openstack quota set --instances 10`

I realise it is a small difference, but each of these makes it more
complex for end users, and means that Designate had to re-invent the
quotas command, and keep it in their plugin.

>>
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface. Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>
> Has there been an attempt to elevate these internal interfaces into
> stable and publicly consumable interfaces? Was there resistance to such
> an effort?

When we have asked previously, we have been told that certain parts
of tempest "are not really meant for plugins".

The main part that is used that is not part of the tempest stable
interface is the base test class.

This is the bit that sets up credentials, clients, and other useful
things.

There is a base test class in the tempest lib - but it is very sparse -
meaning any project using it would have to re-invent creating users,
resources, and clients.

https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
vs
https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22

>>
>> None of this is meant to single out projects, or teams. A lot
>> of the projects that are in this situation have inordinate amounts of
>> work placed on them by the big-tent, and I can emphasize with why things
>> are this way. These were the examples that currently stick out
>> in my mind, and I think we have come to a point where we need to

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

[Hayes, Graham]

On 14/07/2016 21:33, Fox, Kevin M wrote:
> I'm going to go ahead and ask the difficult question now as the answer is 
> relevant to the attached proposal...
>
> Should we reconsider whether the big tent is the right approach going forward?
>
> There have been some major downsides I think to the Big Tent approach, such 
> as:
>  * Projects not working together because of fear of adding extra dependencies 
> Ops don't already have
>  * Reimplementing features, badly, over and over again in different projects 
> instead of standardizing something.
>  * More projects being created due to politics and not technical reasons.
>  * Less cross project communication
>  * Greater Operator pain at trying to assemble a more loose confederation of 
> projects into something useful.
>  * General pushing off more and more work to Operators/Users to deal with.
>  * Worse User experience as cross project issues aren't being addressed.
>  * Previously incubated projects such as Nova, Swift, etc getting a 
> disproportionate say in things as they have a greater current user base, and 
> its increasingly hard now for new projects to gain any traction.
>  * Much less community pressure on projects to work together to elevate 
> everyone. Architectural decisions are now made at individual project level 
> with little done at the OpenStack level.
>  * etc...
>
> The overall goal of the Big Tent was to make the community more inclusive. 
> That I think has mostly happened. Which is good. But It also seems to have 
> fractured the community more into insular islands and made the system harder 
> for our operators/users. Which is bad.
>
> Maybe the benefits outweigh the drawbacks. I'm not sure. But I think its 
> probably time to consider if it has been a net positive and should be further 
> refined to try and address some of these problems, or a net negative and 
> different approaches be explored.
>
> Thanks,
> Kevin

Sure - having a review of a major governance change like the big-tent
is a good idea, and pretty good practice.

I personally don't think we have reached the end of the transition yet,
and proposals like mine will start to come along and deal with issues
outlined above. We should be sure that we have gone as far as we can
before we claim defeat.

That said, there is serious issues - with cross project fairness being
one of the big ones (from my perspective anyway). I think getting
concrete examples of problems and tackling them is a good road forward.

- Graham

> 
> From: Hayes, Graham [graham.ha...@hpe.com]
> Sent: Thursday, July 14, 2016 12:21 PM
> To: OpenStack Development Mailing List (not for usage questions); 
> openstack...@lists.openstack.org
> Subject: [openstack-dev] [tc][all] Plugins for all
>
> I just proposed a review to openstack/governance repo [0] that aims
> to have everything across OpenStack be plugin based for all cross
> project interaction, or allow all projects access to the same internal
> APIs and I wanted to give a bit of background on my motivation, and how
> it came about.
>
> Coming from a smaller project, I can see issues for new projects,
> smaller projects, and projects that may not be seen as "important".
>
> As a smaller project trying to fit into cross project initiatives,
> (and yes, make sure our software looks at least OK in the
> Project Navigator) the process can be difficult.
>
> A lot of projects / repositories have plugin interfaces, but also
> have project integrations in tree, that do not follow the plugin
> interface. This makes it difficult to see what a plugin can, and
> should do.
>
> When we moved to the big tent, we wanted as a community to move to
> a flatter model, removing the old integrated status.
>
> Unfortunately we still have areas when some projects are more equal -
> there is a lingering set of projects who were integrated at the point
> in time that we moved, and have preferential status.
>
> A lot of the effects are hard to see, and are not insurmountable, but
> do cause projects to re-invent the wheel.
>
> For example, quotas - there is no way for a project that is not nova,
> neutron, cinder to hook into the standard CLI, or UI for setting
> quotas. They can be done as either extra commands
> (openstack dns quota set --foo bar) or as custom panels, but not
> the way other quotas get set.
>
> Tempest plugins are another example. Approximately 30 of the 36
> current plugins are using resources that are not supposed to be
> used, and are an unstable interface. Projects in tree in tempest
> are at a much better position, as any change to the internal
> API will have to be fixed before the gate merges, but other
> out of tree plugins are in a place where 

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 14/07/2016 21:20, Matt Riedemann wrote:
> On 7/14/2016 2:21 PM, Hayes, Graham wrote:
>> I just proposed a review to openstack/governance repo [0] that aims
>> to have everything across OpenStack be plugin based for all cross
>> project interaction, or allow all projects access to the same internal
>> APIs and I wanted to give a bit of background on my motivation, and how
>> it came about.
>>
>> Coming from a smaller project, I can see issues for new projects,
>> smaller projects, and projects that may not be seen as "important".
>>
>> As a smaller project trying to fit into cross project initiatives,
>> (and yes, make sure our software looks at least OK in the
>> Project Navigator) the process can be difficult.
>>
>> A lot of projects / repositories have plugin interfaces, but also
>> have project integrations in tree, that do not follow the plugin
>> interface. This makes it difficult to see what a plugin can, and
>> should do.
>>
>> When we moved to the big tent, we wanted as a community to move to
>> a flatter model, removing the old integrated status.
>>
>> Unfortunately we still have areas when some projects are more equal -
>> there is a lingering set of projects who were integrated at the point
>> in time that we moved, and have preferential status.
>>
>> A lot of the effects are hard to see, and are not insurmountable, but
>> do cause projects to re-invent the wheel.
>>
>> For example, quotas - there is no way for a project that is not nova,
>> neutron, cinder to hook into the standard CLI, or UI for setting
>> quotas. They can be done as either extra commands
>> (openstack dns quota set --foo bar) or as custom panels, but not
>> the way other quotas get set.
>>
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface. Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>>
>> None of this is meant to single out projects, or teams. A lot
>> of the projects that are in this situation have inordinate amounts of
>> work placed on them by the big-tent, and I can emphasize with why things
>> are this way. These were the examples that currently stick out
>> in my mind, and I think we have come to a point where we need to make
>> a change as a community.
>>
>> By moving to a "plugins for all" model, these issues are reduced.
>> It undoubtedly will cause more, but it is closer to our goal
>> of Recognizing all our community is part of OpenStack, and
>> differentiate projects by tags.
>>
>> This won't be a change that happens tomorrow, next week, or even next
>> cycle, but think as a goal, we should start moving in this direction
>> as soon as we can, and start building momentum.
>>
>> Thanks,
>>
>> Graham
>>
>> 0 - https://review.openstack.org/342366
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> Just for my own understanding, are you suggesting that something like
> nova, cinder or neutron become optional for an openstack cloud?

Not in this proposal. (but that is an interesting idea we should follow
up on at a later date)

> And does this also include plugins within projects, like storage
> backends in cinder and hypervisor drivers in nova?

This is aimed at cross project interaction. So, if there is a project in
projects.yaml that is a backend, or a hypervisor driver, it should.

However, in the proposal, there is a choice that projects can make -
all in tree, or all plugins. The point of the proposal is equality of
access for the community.

What would that mean in practice for Nova? Nothing would really change
- they have decided to do in tree.

99% of deliverables tagged type:service will have no impact from this,
the change will be in projects that are used by  teams across the
community (CLI, Docs, UI etc), and provide a way for these projects
to integrate with them.

These integration points should be the same for *all* projects.

> Nova has been pushing for a few releases now on getting rid of plug
> points since they are barriers to interoperability.

Well, nova's plugins were barriers to interoperability, for other
projects they are the only mechanism for interoperability.


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

[openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

I just proposed a review to openstack/governance repo [0] that aims
to have everything across OpenStack be plugin based for all cross
project interaction, or allow all projects access to the same internal
APIs and I wanted to give a bit of background on my motivation, and how
it came about.

Coming from a smaller project, I can see issues for new projects,
smaller projects, and projects that may not be seen as "important".

As a smaller project trying to fit into cross project initiatives,
(and yes, make sure our software looks at least OK in the
Project Navigator) the process can be difficult.

A lot of projects / repositories have plugin interfaces, but also
have project integrations in tree, that do not follow the plugin
interface. This makes it difficult to see what a plugin can, and
should do.

When we moved to the big tent, we wanted as a community to move to
a flatter model, removing the old integrated status.

Unfortunately we still have areas when some projects are more equal -
there is a lingering set of projects who were integrated at the point
in time that we moved, and have preferential status.

A lot of the effects are hard to see, and are not insurmountable, but
do cause projects to re-invent the wheel.

For example, quotas - there is no way for a project that is not nova, 
neutron, cinder to hook into the standard CLI, or UI for setting
quotas. They can be done as either extra commands
(openstack dns quota set --foo bar) or as custom panels, but not
the way other quotas get set.

Tempest plugins are another example. Approximately 30 of the 36
current plugins are using resources that are not supposed to be
used, and are an unstable interface. Projects in tree in tempest
are at a much better position, as any change to the internal
API will have to be fixed before the gate merges, but other
out of tree plugins are in a place where they can be broken at any
point.

None of this is meant to single out projects, or teams. A lot
of the projects that are in this situation have inordinate amounts of
work placed on them by the big-tent, and I can emphasize with why things 
are this way. These were the examples that currently stick out
in my mind, and I think we have come to a point where we need to make
a change as a community.

By moving to a "plugins for all" model, these issues are reduced.
It undoubtedly will cause more, but it is closer to our goal
of Recognizing all our community is part of OpenStack, and
differentiate projects by tags.

This won't be a change that happens tomorrow, next week, or even next
cycle, but think as a goal, we should start moving in this direction
as soon as we can, and start building momentum.

Thanks,

Graham

0 - https://review.openstack.org/342366

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

[Hayes, Graham]

Hi All,

Just a quick update on a few things!

Mid Cycle
=

The Mid Cycle is confirmed for 22-26th of August.

It will be in Dublin, in the city center.

The address is

64 Mount Street Lower,
Dublin 2.
D02 TH77
Ireland

I will be updating the page on the wiki with local hotels
over the next day or so, so keep an eye on

https://wiki.openstack.org/wiki/Sprints/DesignateNewtonSprint

This is a shared office space, so we will need to let people in
as they arrive - my phone number is +353 87 377 8315

Docs Sprint
===

Today's docs sprint went well, we have a few reviews outstanding, so if
everyone could have a look at the following:

# https://review.openstack.org/#/c/341622/
# https://review.openstack.org/#/c/341614/
# https://review.openstack.org/#/c/341583/
# https://review.openstack.org/#/c/341672/


Project Mascot
==

The foundation has kindly offered to create mascots for each project.

Can everyone put ideas in the etherpad:

https://etherpad.openstack.org/p/designate-mascot

And if you see an idea you like, stick a "+" beside it.

We will take the top few ideas and pass them to the foundation.

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] Mid Cycle Dates - 22-26th August in Dublin, Ireland

[Hayes, Graham]

At the IRC meeting yesterday we (finally) got some dates
in place for the Mid Cycle.

22-26th August in Dublin, Ireland.

Final location to be confirmed - this mid cycle is not being sponsored
by anyone, so I need rough numbers before I go beg, borrow and / or
steal a room, but it will be the city centre (Dublin 1 or 2).

Can everyone let me know if this is OK, and if they would be interested
in attending?

If no one shouts at me by Monday, I will start booking a room, for 8
to 10 people, which should give us a little room for expansion, but not
too much, so if you are interested, please let me know.

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] Doc Smash - 13th July 2016 @ 14:30 UTC

[Hayes, Graham]

Hi All,

As we have seen over the last cycle or so, our docs need a bit of a refresh.

We decided at the last IRC meeting that we should have a Doc Smash on 
the 13th July 2016 @ 14:30 UTC.

The place holder bug is here - 
https://bugs.launchpad.net/designate/+bug/1590937 and I will break it 
out into smaller bugs for the day itself.

So - if you are interested in helping us give the docs a bit of TLC,
please pop along to #openstack-dns on 13th July 2016 @ 14:30 UTC.

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

Re: [openstack-dev] [designate][charms] Synchronising domains with new bind9 server

[Hayes, Graham]

On 01/07/2016 18:04, Liam Young wrote:
> Hi,
>
> I'm trying to add a new bind9 pool_target to an existing pool. The
> problem is that the new bind server has no knowledge of the existing
> zones as it missed the addzone commands when the domains where created.
> It seems to me I have 3 options:
>
> 1) To sync the zone + nzf files from an existing bind9 pool_target

This is what we recommend for scaling bind.

We have a periodic task that will clean up zones that have been updated
in a certain time, so as long as the time it takes to sync the files
is less than that window (set in the config as `periodic_sync_seconds`
in the [service:pool_manager] section) there should be no issue - the
new server will just not have all the zones + records up to date.


> 2) Write a script to extract a list of domains for all tenants from
> designate and convert those into  "rndc addzone" commands targeted at
> the new unit
> 3) Some builtin designate method I've yet to discover?

`periodic_sync_seconds` is set to `None` by default, which means it will
check all zones, but this should be set lower for busy installs.

> What would you recommend?
>
> I'm writing a designate and designate bind Juju charm and testing
> scaleout which is what caused me to trip over this issue. So for option
> 1 I'll need to synchronise a directory between Juju units of an
> application does anyone have a neat way of doing this?
> Thanks
> Liam


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

Re: [openstack-dev] Designate issue

[Hayes, Graham]

On 27/06/2016 12:24, sonali.pra...@accenture.com wrote:
> Hi team,
>
>
>
> I have a doubt ..can we have designate and mysql in two different nodes??
>
> And even the rabbitmq
>
> Will they communicate with each other like the normal openstack components.

Hi Sonali,

Yes, Designate can talk to MySQL and RabbitMQ on different nodes.
We use the standard openstack libraries to talk to both MySQL and RMQ,
so as long as the Designate nodes have network access, they can use
them.

Thanks,

Graham

> Regards,
>
> Sonali
>
>
> 
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you
> have received it in error, please notify the sender immediately and
> delete the original. Any other use of the e-mail by you is prohibited.
> Where allowed by local law, electronic communications with Accenture and
> its affiliates, including e-mail and instant messaging (including
> content), may be scanned by our systems for the purposes of information
> security and assessment of internal compliance with Accenture policy.
> __
>
> www.accenture.com


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

[openstack-dev] [designate] IRC Meeting today

[Hayes, Graham]

Hi,

Myself, Kiall and Federico are going to be caught up in some meetings 
today during the IRC meeting.

Can someone chair the meeting?

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