Re: [openstack-dev] [heat][ci][infra][aodh][telemetry] telemetry test broken on oslo.messaging stable/queens

[Rabi Mishra]

On Tue, Jun 12, 2018 at 10:33 AM, Mehdi Abaakouk  wrote:

>
> Hi,
>
> The tempest plugin error remember me something we got in telemetry gate a
> while back.
>
> We fix the telemetry tempest plugin with https://github.com/openstack/t
> elemetry-tempest-plugin/commit/11277a8bee2b0ee0688ed32cc0e836872c24ee4b
>
> So I propose the same for heat tempest plugin:
> https://review.openstack.org/574550
>
> After
https://github.com/cdent/gabbi/pull/243/commits/01993966c179791186977e27c64b9e525a566408
(gabbi === 1.42.0) it just checks for host is not None and we pass empty
string here. So it should not fail.

However, I think the issue is that quuens upper-constraints have
gabbi===1.40.0. Unless we can bump that we've to go with this workaround.

> Hope that helps,
> sileht
>
>
> Le 2018-06-11 21:53, Ken Giusti a écrit :
>
>> Updated subject to include [aodh] and [telemetry]
>>
>> On Tue, Jun 5, 2018 at 11:41 AM, Doug Hellmann 
>> wrote:
>>
>>> Excerpts from Ken Giusti's message of 2018-06-05 10:47:17 -0400:
>>>
 Hi,

 The telemetry integration test for oslo.messaging has started failing
 on the stable/queens branch [0].

 A quick review of the logs points to a change in heat-tempest-plugin
 that is incompatible with the version of gabbi from queens upper
 constraints (1.40.0) [1][2].

 The job definition [3] includes required-projects that do not have
 stable/queens branches - including heat-tempest-plugin.

 My question - how do I prevent this job from breaking when these
 unbranched projects introduce changes that are incompatible with
 upper-constrants for a particular branch?

>>>
>>> Aren't those projects co-gating on the oslo.messaging test job?
>>>
>>> How are the tests working for heat's stable/queens branch? Or telemetry?
>>> (whichever project is pulling in that tempest repo)
>>>
>>>
>> I've run the stable/queens branches of both Aodh[1] and Heat[2] - both
>> failed.
>>
>> Though the heat failure is different from what we're seeing on
>> oslo.messaging [3],
>> the same warning about gabbi versions is there [4].
>>
>> However the Aodh failure is exactly the same as the oslo.messaging one
>> [5] - this makes sense since the oslo.messaging test is basically
>> running the same telemetry-tempest-plugin test.
>>
>> So this isn't something unique to oslo.messaging - the telemetry
>> integration test is busted in stable/queens.
>>
>> I'm going to mark these tests as non-voting on oslo.messaging's queens
>> branch for now so we can land some pending patches.
>>
>>
>> [1] https://review.openstack.org/#/c/574306/
>> [2] https://review.openstack.org/#/c/574311/
>> [3]
>> http://logs.openstack.org/11/574311/1/check/heat-functional-
>> orig-mysql-lbaasv2/21cce1d/job-output.txt.gz#_2018-06-11_17_30_51_106223
>> [4]
>> http://logs.openstack.org/11/574311/1/check/heat-functional-
>> orig-mysql-lbaasv2/21cce1d/logs/devstacklog.txt.gz#_2018-
>> 06-11_17_09_39_691
>> [5]
>> http://logs.openstack.org/06/574306/1/check/telemetry-dsvm-i
>> ntegration/0a9620a/job-output.txt.gz#_2018-06-11_16_53_33_982143
>>
>>
>>
>>
 I've tried to use override-checkout in the job definition, but that
 seems a bit hacky in this case since the tagged versions don't appear
 to work and I've resorted to a hardcoded ref [4].

 Advice appreciated, thanks!

 [0] https://review.openstack.org/#/c/567124/
 [1] http://logs.openstack.org/24/567124/1/check/oslo.messaging-t
 elemetry-dsvm-integration-rabbit/e7fdc7d/logs/devstack-gate-
 post_test_hook.txt.gz#_2018-05-16_05_20_05_624
 [2] http://logs.openstack.org/24/567124/1/check/oslo.messaging-t
 elemetry-dsvm-integration-rabbit/e7fdc7d/logs/devstacklog.
 txt.gz#_2018-05-16_05_19_06_332
 [3] https://git.openstack.org/cgit/openstack/oslo.messaging/tree
 /.zuul.yaml?h=stable/queens#n250
 [4] https://review.openstack.org/#/c/572193/2/.zuul.yaml

>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
> --
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
>
>
> __
> OpenStack Development Mailing 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,
Rabi Mishra
__
OpenStack Development Mailing 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] [heat][ci][infra][aodh][telemetry] telemetry test broken on oslo.messaging stable/queens

[Mehdi Abaakouk]

Hi,

The tempest plugin error remember me something we got in telemetry gate 
a while back.


We fix the telemetry tempest plugin with 
https://github.com/openstack/telemetry-tempest-plugin/commit/11277a8bee2b0ee0688ed32cc0e836872c24ee4b


So I propose the same for heat tempest plugin: 
https://review.openstack.org/574550


Hope that helps,
sileht

Le 2018-06-11 21:53, Ken Giusti a écrit :

Updated subject to include [aodh] and [telemetry]

On Tue, Jun 5, 2018 at 11:41 AM, Doug Hellmann  
wrote:

Excerpts from Ken Giusti's message of 2018-06-05 10:47:17 -0400:

Hi,

The telemetry integration test for oslo.messaging has started failing
on the stable/queens branch [0].

A quick review of the logs points to a change in heat-tempest-plugin
that is incompatible with the version of gabbi from queens upper
constraints (1.40.0) [1][2].

The job definition [3] includes required-projects that do not have
stable/queens branches - including heat-tempest-plugin.

My question - how do I prevent this job from breaking when these
unbranched projects introduce changes that are incompatible with
upper-constrants for a particular branch?


Aren't those projects co-gating on the oslo.messaging test job?

How are the tests working for heat's stable/queens branch? Or 
telemetry?

(whichever project is pulling in that tempest repo)



I've run the stable/queens branches of both Aodh[1] and Heat[2] - both 
failed.


Though the heat failure is different from what we're seeing on
oslo.messaging [3],
the same warning about gabbi versions is there [4].

However the Aodh failure is exactly the same as the oslo.messaging one
[5] - this makes sense since the oslo.messaging test is basically
running the same telemetry-tempest-plugin test.

So this isn't something unique to oslo.messaging - the telemetry
integration test is busted in stable/queens.

I'm going to mark these tests as non-voting on oslo.messaging's queens
branch for now so we can land some pending patches.


[1] https://review.openstack.org/#/c/574306/
[2] https://review.openstack.org/#/c/574311/
[3]
http://logs.openstack.org/11/574311/1/check/heat-functional-orig-mysql-lbaasv2/21cce1d/job-output.txt.gz#_2018-06-11_17_30_51_106223
[4]
http://logs.openstack.org/11/574311/1/check/heat-functional-orig-mysql-lbaasv2/21cce1d/logs/devstacklog.txt.gz#_2018-06-11_17_09_39_691
[5]
http://logs.openstack.org/06/574306/1/check/telemetry-dsvm-integration/0a9620a/job-output.txt.gz#_2018-06-11_16_53_33_982143





I've tried to use override-checkout in the job definition, but that
seems a bit hacky in this case since the tagged versions don't appear
to work and I've resorted to a hardcoded ref [4].

Advice appreciated, thanks!

[0] https://review.openstack.org/#/c/567124/
[1] 
http://logs.openstack.org/24/567124/1/check/oslo.messaging-telemetry-dsvm-integration-rabbit/e7fdc7d/logs/devstack-gate-post_test_hook.txt.gz#_2018-05-16_05_20_05_624
[2] 
http://logs.openstack.org/24/567124/1/check/oslo.messaging-telemetry-dsvm-integration-rabbit/e7fdc7d/logs/devstacklog.txt.gz#_2018-05-16_05_19_06_332
[3] 
https://git.openstack.org/cgit/openstack/oslo.messaging/tree/.zuul.yaml?h=stable/queens#n250

[4] https://review.openstack.org/#/c/572193/2/.zuul.yaml


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
OpenStack Development Mailing 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] [charms] 18.05 OpenStack Charms release

[David Ames]

Announcing the 18.05 release of the OpenStack Charms.

The 18.05 charms have full support for the Bionic Ubuntu series.
Encryption at rest has been implemented in the storage charms.
In addition, the vault and neutron-dynamic-routing charms have been
introduced. 72 bugs have been fixed and released across the OpenStack
charms.

For full details of the release, please refer to the release notes:

  https://docs.openstack.org/charm-guide/latest/18.05.html

Thanks go to the following contributors for this release:

Alex Kavanagh
Andrew McLeod
Ante Karamatić
Billy Olsen
Chris MacNaughton
Chris Sanders
Corey Bryant
Craige McWhirter
David Ames
Drew Freiberger
Edward Hope-Morley
Felipe Reyes
Frode Nordahl
Fulvio Galeazzi
Jakub Rohovsky
James Hebden
James Page
Liam Young
Mario Splivalo
Michael Skalka
Peter Sabaini
Ryan Beisner
Sean Feole
Seyeong Kim
Tamas Erdei
Tytus Kurek
Xav Paice
viswesuwara nathan

__
OpenStack Development Mailing 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] use of storyboard (was [TC] Stein Goal Selection)

[CARVER, PAUL]

Matt Riedemann   wrote:

>The specs thing was mentioned last week in IRC when talking about blueprints 
>in launchpad and I just want to reiterate the specs are
>more about high level designs and reviewing those designs in Gerrit which was 
>/ is a major drawback in the 'whiteboard' in launchpad for 
>working on blueprints - old blueprints that had a design (if they had a design 
>at all) were usually linked from a wiki page.

>Anyway, specs are design documents per release. Blueprints in launchpad, at 
>least for nova, are the project management tracking tool for 
>that release. Not all blueprints require a spec, but all specs require a 
>blueprint since specs are generally for API changes or other major 
>design changes or features. Just FYI.

Matt is saying exactly what I've been saying in OpenContrail/Tungsten Fabric 
TSC meetings for a year. Launchpad Blueprints are very valuable for identifying 
what's likely to be in a given release, unambiguously indicating when the team 
has determined that something is going to miss a release (and therefore get 
bumped out to the future) and capturing the history of what was in a release. 
But they're lousy for reviewing and collaborating on technical details of what 
the thing actually is and how it is planned to work.

On the other hand, spec documents in Gerrit are pretty good for iteratively 
refining a design document and ultimately agreeing to a finalized version, but 
not really all that good at reflecting status and progress to people who are 
not down in the weeds of discussing the implementation details of the feature.

If Storyboard can find a way to improve on one or both of these activities, 
that's great. But abandoning Launchpad series and milestones functionality 
without a good replacement isn't a good idea for projects that are using them 
effectively. And for projects that aren't using them, I have to ask whether 
it's because they have a better way of communicating release plans to their 
user/operator communities or if it's because they simply aren't communicating 
release plans.

Generally somebody somewhere is paying for almost all development, so most 
likely somebody wants to know if and when it is/will-be/was done. The simpler 
and more consistent the tooling for communicating that, the less time everyone 
has to spend answering questions from the people who just want to know if 
whatever thing they're waiting on is in progress, on the backlog, or already 
complete.

__
OpenStack Development Mailing 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] use of storyboard (was [TC] Stein Goal Selection)

[Matt Riedemann]

On 6/11/2018 3:31 PM, Doug Hellmann wrote:

As we shift teams over to Storyboard, we have another opportunity
to review the processes and to decide how to use the new tool. Some
teams with lightweight processes will be able to move directly with
little impact. Other teams who are doing more tracking and planning
will need to think about how to do that. The new tool provides some
flexibility, and as with any other big change in our community,
we're likely to see a bit of divergence before we collectively
discover what works and teams converge back to a more consistent
approach.  That's normal, expected, and desirable.

I recommend that people spend a little time experimenting on their
own before passing judgement or trying to set standards.

Start by looking at the features of the tool itself.  Set up a work
list and add some stories to it. Set up a board and see how the
automatic work lists help keep it up to date as the story or task
states change. Do the same with a manually managed board. If you
need a project to assign a task to because yours hasn't migrated
yet, use openstack/release-test.

Then think about the workflows you actually use -- not just the
ones you've been doing because that's the way the project has always
been managed. Think about how those workflows might translate over
to the new tool, based on its features. If you're not sure, ask and
we can see what other teams are doing or what people more familiar
with the tool suggest trying.


I'm reminded of something we talked about in IRC last week wrt tracking 
blueprint-type changes over a given series / release in storyboard. It 
was mentioned that storyboard has a not-yet-implemented epics feature 
which is really how we'd probably do this (nested stories is another way 
of thinking about this). So nova could, for example, have an epic for 
Stein and then track a story for each blueprint, with the old launchpad 
blueprint 'work items' (which we don't use, but we do have a list of 
work items in our specs template) tracked as tasks - which would also be 
nice since you can track tasks like documentation, CLIs (nova and OSC) 
and tempest testing (if required). One thing people always commit to in 
their spec is adding support for the feature in client libraries, 
tempest and docs, but once the nova server side change is merged those 
commitments end up getting dropped (not always, but more often than I'd 
like).


--

Thanks,

Matt

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

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[Matt Riedemann]

On 6/11/2018 3:23 PM, Jeremy Stanley wrote:

If you recall the "specs" experiment years
ago, a few teams tried mildly different solutions for moving from LP
blueprints with random wiki page links to tracking specifications in
Git repositories, and over time they learned successful patterns
from each other and mostly converged on similar solutions. There
were similar cries back then about "how will users/operators find
out what is being planned?" but I think the end result was far
better than what it replaced.


The specs thing was mentioned last week in IRC when talking about 
blueprints in launchpad and I just want to reiterate the specs are more 
about high level designs and reviewing those designs in Gerrit which was 
/ is a major drawback in the 'whiteboard' in launchpad for working on 
blueprints - old blueprints that had a design (if they had a design at 
all) were usually linked from a wiki page.


Anyway, specs are design documents per release. Blueprints in launchpad, 
at least for nova, are the project management tracking tool for that 
release. Not all blueprints require a spec, but all specs require a 
blueprint since specs are generally for API changes or other major 
design changes or features. Just FYI.


--

Thanks,

Matt

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

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Zane Bitter]

On 04/06/18 10:13, Zane Bitter wrote:

On 31/05/18 14:35, Julia Kreger wrote:

Back to the topic of nitpicking!

I virtually sat down with Doug today and we hammered out the positive
aspects that we feel like are the things that we as a community want
to see as part of reviews coming out of this effort. The principles
change[1] in governance has been updated as a result.

I think we are at a point where we have to state high level
principles, and then also update guidelines or other context providing
documentation to re-enforce some of items covered in this
discussion... not just to educate new contributors, but to serve as a
checkpoint for existing reviewers when making the decision as to how
to vote change set. The question then becomes where would such
guidelines or documentation best fit?


I think the contributor guide is the logical place for it. Kendall 
pointed out this existing section:


https://docs.openstack.org/contributors/code-and-documentation/using-gerrit.html#reviewing-changes 



It could go in there, or perhaps we separate out the parts about when to 
use which review scores into a separate page from the mechanics of how 
to use Gerrit.



Should we explicitly detail the
cause/effect that occurs? Should we convey contributor perceptions, or
maybe even just link to this thread as there has been a massive amount
of feedback raising valid cases, points, and frustrations.

Personally, I'd lean towards a blended approach, but the question of
where is one I'm unsure of. Thoughts?


Let's crowdsource a set of heuristics that reviewers and contributors 
should keep in mind when they're reviewing or having their changes 
reviewed. I made a start on collecting ideas from this and past threads, 
as well as my own reviewing experience, into a document that I've 
presumptuously titled "How to Review Changes the OpenStack Way" (but 
might be more accurately called "The Frank Sinatra Guide to Code Review" 
at the moment):


https://etherpad.openstack.org/p/review-the-openstack-way

It's in an etherpad to make it easier for everyone to add their 
suggestions and comments (folks in #openstack-tc have made some tweaks 
already). After a suitable interval has passed to collect feedback, I'll 
turn this into a contributor guide change.


It's had a week to percolate (and I've seen quite a few people viewing 
the etherpad), so here is the review:


https://review.openstack.org/574479

- ZB


Have at it!

cheers,
Zane.


-Julia

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



__
OpenStack Development Mailing 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] review runway status

[Matt Riedemann]

A few small status updates inline.

On 6/11/2018 4:14 PM, melanie witt wrote:

Hi everybody,

This is just a brief status about the blueprints currently occupying
review runways [0] and an ask for the nova-core team to give these
reviews priority for their code review focus.

* Certificate Validation - 
https://blueprints.launchpad.net/nova/+spec/nova-validate-certificates 
(bpoulos) [END DATE: 2018-06-15] 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-validate-certificates 



I know I need to go back through this series, hopefully can get that 
done tomorrow. I might just start addressing anything I -1 at this point 
to keep it going.




* Neutron new port binding API for live migration: 
https://blueprints.launchpad.net/nova/+spec/neutron-new-port-binding-api 
(mriedem) [END DATE: 2018-06-20] Starts here: 
https://review.openstack.org/#/c/558001/


This already had quite a bit of core review from Eric before it got into 
the runway slot, but since then it hasn't had any reviews since it got 
into the slot. I'd ask Eric and Dan specifically to review the bottom 
change since (1) Eric has been through it already, albeit awhile ago and 
(2) Dan is familiar with the vif plugging callback event code in that 
change.




* XenAPI: improve the image handler 
configure:https://blueprints.launchpad.net/nova/+spec/xenapi-image-handler-option-improvement 
(naichuans) [END DATE: 2018-06-20] Starts here: 
https://review.openstack.org/#/c/486475/


I'm waiting on the xenserver third party CI to pass on this:

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

And then I'll approve the series.



Best,
-melanie

[0] https://etherpad.openstack.org/p/nova-runways-rocky



I also reminded people in the nova-scheduler meeting this morning to put 
stuff in runways since I know there is a lot of placement blueprint work 
that's going on outside of the runways slots, so it would be nice if 
that was also at least formally queued up. Just to remind people that we 
can still review stuff that's not in a slot, but just seeing it in the 
queue is at least an indication / reminder for me personally that those 
changes are ready for review when I'm looking. I've also just started 
adding things into the queue if I know it's ready even if it's not my 
series.


--

Thanks,

Matt

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

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

[Emilien Macchi]

On Tue, Jun 5, 2018 at 9:08 AM, Doug Hellmann  wrote:
[snip]

> When all of this is done, a viable project with real users will be
> open source instead of closed source. Those contributors, and users,
> will be a part of our community instead of looking in from the
> outside. The path is ugly, long, and clearly not ideal. But, I
> consider the result a win, overall.


While I agree with Doug that we assume good faith and hope for the best, I
personally think we should help them (what we're doing now) but also make
sure we DO NOT set a precedent. We could probably learn from this situation
and document in our governance what the TC expects when companies have a
fork and need to contribute back at some point. We all know StarlingX isn't
alone and I'm pretty sure there are a lot of deployments out there who are
in the same situation.

I guess my point is, yes for helping StarlingX now but no for incubating
future forks if that happens. Like Graham, I think these methods shouldn't
be what we encourage in our position.
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] review runway status

[melanie witt]

Hi everybody,

This is just a brief status about the blueprints currently occupying
review runways [0] and an ask for the nova-core team to give these
reviews priority for their code review focus.

* Certificate Validation - 
https://blueprints.launchpad.net/nova/+spec/nova-validate-certificates 
(bpoulos) [END DATE: 2018-06-15] 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-validate-certificates


* Neutron new port binding API for live migration: 
https://blueprints.launchpad.net/nova/+spec/neutron-new-port-binding-api 
(mriedem) [END DATE: 2018-06-20] Starts here: 
https://review.openstack.org/#/c/558001/


* XenAPI: improve the image handler 
configure:https://blueprints.launchpad.net/nova/+spec/xenapi-image-handler-option-improvement 
(naichuans) [END DATE: 2018-06-20] Starts here: 
https://review.openstack.org/#/c/486475/


Best,
-melanie

[0] https://etherpad.openstack.org/p/nova-runways-rocky

__
OpenStack Development Mailing 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] [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

[Kristi Nikolla]

Answering here questions related to mixmatch, as I'm the main developer.

- If I understood [[1](https://mixmatch.readthedocs.io/en/latest/)] correctly 
mixmatch can help Nova to attach a remote volume, but it will not help in 
synchronizing the images. is this true?

Correct, it will not synchronize images. What it does is forward API requests 
across OpenStack clouds, allowing Nova to fetch a remote image. It could be 
enhanced to "cache" the image, in which case it would be the PULL model. In 
this architecture, you would have mixmatch acting as a proxy to one or multiple 
Glance API servers (some remote), and you could even potentially forego having 
a Glance at all in the edge cloud.

- Not sure ... but I didn’t think this was the model being used in mixmatch ... 
thought mixmatch was more the PULL model (below)

- [G0]: Yes, this is more or less my understanding. I remove the mixmatch 
reference from this chapter.

Rather than remove it completely you could move it to the correct section. :)

‐‐‐ Original Message ‐‐‐
On June 11, 2018 10:28 AM, Csatari, Gergely (Nokia - HU/Budapest) 
 wrote:

> Hi,
>
> Thanks for the comments.
>
> I’ve updated the wiki: 
> https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend
>
> Br,
>
> Gerg0
>
> [ ]
>
> From: Waines, Greg [mailto:greg.wai...@windriver.com]
> Sent: Friday, June 8, 2018 1:46 PM
> To: Csatari, Gergely (Nokia - HU/Budapest) ; 
> OpenStack Development Mailing List (not for usage questions) 
> ; edge-comput...@lists.openstack.org
> Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible 
> architectures for image synchronisation
>
> Responses in-lined below,
>
> Greg.
>
> From: "Csatari, Gergely (Nokia - HU/Budapest)" 
> Date: Friday, June 8, 2018 at 3:39 AM
> To: Greg Waines , 
> "openstack-dev@lists.openstack.org" , 
> "edge-comput...@lists.openstack.org" 
> Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible 
> architectures for image synchronisation
>
> Hi,
>
> Going inline.
>
> From: Waines, Greg [mailto:greg.wai...@windriver.com]
> Sent: Thursday, June 7, 2018 2:24 PM
>
> I had some additional questions/comments on the Image Synchronization Options 
> ( https://wiki.openstack.org/wiki/Image_handling_in_edge_environment ):
>
> One Glance with multiple backends
>
> - In this scenario, are all Edge Clouds simply configured with the one 
> central glance for its GLANCE ENDPOINT ?
>
> - i.e. GLANCE is a typical shared service in a multi-region environment ?
>
> [G0]: In my understanding yes.
>
> - If so,
> how does this OPTION support the requirement for Edge Cloud Operation when 
> disconnected from Central Location ?
>
> [G0]: This is an open question for me also.
>
> Several Glances with an independent synchronization service(PUSH)
>
> - I refer to this as the PUSH model
>
> - I don’t believe you have to ( or necessarily should) rely on the backend to 
> do the synchronization of the images
>
> - i.e. the ‘Synch Service’ could do this strictly through Glance REST APIs
> (making it independent of the particular Glance backend ... and allowing the 
> Glance Backends at Central and Edge sites to actually be different)
>
> [G0]: Okay, I can update the wiki to reflect this. Should we keep the 
> “synchronization by the backend” option as an other alternative?
> [Greg] Yeah we should keep it as an alternative.
>
> - I think the ‘Synch Service’ MUST be able to support ‘selective/multicast’ 
> distribution of Images from Central to Edge for Image Synchronization
>
> - i.e. you don’t want Central Site pushing ALL images to ALL Edge Sites ... 
> especially for the small Edge Sites
>
> [G0]: Yes, the question is how to define these synchronization policies.
> [Greg] Agreed ... we’ve had some very high-level discussions with end users, 
> but haven’t put together a proposal yet.
>
> - Not sure ... but I didn’t think this was the model being used in mixmatch 
> ... thought mixmatch was more the PULL model (below)
>
> [G0]: Yes, this is more or less my understanding. I remove the mixmatch 
> reference from this chapter.
>
> One Glance and multiple Glance API Servers   (PULL)
>
> - I refer to this as the PULL model
>
> - This is the current model supported in StarlingX’s Distributed Cloud 
> sub-project
>
> - We run glance-api on all Edge Clouds ... that talk to glance-registry on 
> the Central Cloud, and
>
> - We have glance-api setup for caching such that only the first access to an 
> particular image incurs the latency of the image transfer from Central to Edge
>
> [G0]: Do you do image caching in Glance API or do you rely in the image cache 
> in Nova? In the Forum session there were some discussions about this and I 
> think the conclusion was that using the image cache of Nova is enough.
> [Greg] We enabled image caching in the Glance API.
>  I believe that Nova Image Caching caches at the 

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[Jeremy Stanley]

On 2018-06-11 15:09:55 -0500 (-0500), Jay S Bryant wrote:
[...]
> Fair enough. It would help if we had buy-in from all of the
> projects but you are right that nothing prevents us from achieving
> consensus from those are are willing to participate.
[...]

Yes, we started out thinking that was going to be the way forward
and eventually learned from that mistake. It's debilitatingly
depressing to work on a project whose intended users keep saying
they want it to be identical to the also-questionably-designed thing
they're currently using because any change in process is some amount
of effort they can avoid by deferring. Refusing to let anyone use SB
year after year because it's wasn't quite ready enough for everybody
(even if it was plenty useful for somebody) resulted in the people
who had been assigned to work on it rage-quit from the endless
negativity being heaped on them.

It was only when it found other potential users outside the
OpenStack ecosystem entirely that new life was breathed into the
project, because it was getting used by somebody who couldn't be
told they weren't allowed. We resolved soon after that to discard
our prior fear of different projects relying on different tools,
realizing that no progress would ever be made if we required
everyone to agree to use it first.
-- 
Jeremy Stanley


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

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[Doug Hellmann]

Excerpts from CARVER, PAUL's message of 2018-06-11 19:53:47 +:
> Jeremy Stanley  wrote:
> 
> >I'm just going to come out and call bullshit on this one. How many of the 
> >>800 official OpenStack deliverable repos have a view like that with any 
> >actual relevant detail? If it's "standard" then certainly more than half, 
> >right?
> 
> Well, that's a bit rude, so I'm not going to get in a swearing contest over 
> whether Nova, Neutron and Cinder are more "important" than 800+ other 
> projects. I picked a handful of projects that I'm most interested in and 
> which also happened to have really clear, accessible and easy to understand 
> information on what they have delivered in the past and are planning to 
> deliver in the future. If I slighted your favorite projects I apologize.
> 
> So, are you saying the information shown in the examples I gave is not useful?
> 
> Or just that I've been lucky in the past that the projects I'm most 
> interested in do a better than typical job of managing releases but the 
> future is all downhill?
> 
> If you're saying it's not useful info and we're better off without it then 
> I'll just have to disagree. If you're saying that it has been replaced with 
> something better, please share the URLs.
> 
> I'm all for improvements, but saying "only a few people were doing something 
> useful so we should throw it out and nobody do it" isn't a path to 
> improvement. How about we discuss alternate (e.g. better/easier/whatever) 
> ways of making the information available.
> 

This thread isn't going in a very productive direction. Please
consider your tone as you reply.

The release team used to (help) manage the launchpad series data.
We stopped doing that a long time ago, as Jeremy pointed out, because
it was not useful to *the release team* in the way we were managing
the releases. We stopped tracking blueprints and bug fixes to try
to predict which release they would land in and built tools to make
it easier for teams to declare what they had completed through
release notes instead.

OpenStack does not have a bunch of project managers signed up to
help this kind of information, so it was left up to each project
team to track any planning information *they decided was useful*
to do their work.  If that tracking information happens to be useful
to anyone other than contributors, I consider that a bonus.

As we shift teams over to Storyboard, we have another opportunity
to review the processes and to decide how to use the new tool. Some
teams with lightweight processes will be able to move directly with
little impact. Other teams who are doing more tracking and planning
will need to think about how to do that. The new tool provides some
flexibility, and as with any other big change in our community,
we're likely to see a bit of divergence before we collectively
discover what works and teams converge back to a more consistent
approach.  That's normal, expected, and desirable.

I recommend that people spend a little time experimenting on their
own before passing judgement or trying to set standards.

Start by looking at the features of the tool itself.  Set up a work
list and add some stories to it. Set up a board and see how the
automatic work lists help keep it up to date as the story or task
states change. Do the same with a manually managed board. If you
need a project to assign a task to because yours hasn't migrated
yet, use openstack/release-test.

Then think about the workflows you actually use -- not just the
ones you've been doing because that's the way the project has always
been managed. Think about how those workflows might translate over
to the new tool, based on its features. If you're not sure, ask and
we can see what other teams are doing or what people more familiar
with the tool suggest trying.

Doug

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

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[Jeremy Stanley]

On 2018-06-11 19:53:47 + (+), CARVER, PAUL wrote:
[...]
> Well, that's a bit rude
[...]

Apologies for the strong language; I did not intend any offense, and
it was indeed unnecessary for purposes of my point.

> So, are you saying the information shown in the examples I gave is
> not useful?

I'm saying as far as OpenStack is concerned, it's not a "standard"
(which was your original claim). A minority of the 40 official
services (so named by the project navigator anyway) are relying on
it and I'd wager far fewer still of the >800 deliverable
repositories maintained by official OpenStack project teams are
either.

> Or just that I've been lucky in the past that the projects I'm
> most interested in do a better than typical job of managing
> releases but the future is all downhill?

I think you likely care proportionally more about projects which
have been in the OpenStack ecosystem for longer (this is
unsurprising) and of those quite a few are tracking series/milestone
info in LP because it was integrated with release management once
upon a time (up until a couple years ago) so there was a lot of
pressure, perhaps even a requirement, to do so and old habits die
hard.

Matt R. notes in his reply that as PTL he found using it for
tracking cycle work independent of whether the Release Management
team was still expecting/relying on it, so I don't doubt the
usefulness of having some means of continuing to do that (and with
StoryBoard there are a few ways you could do it but we didn't want
to be proscriptive). Some other teams have found that they prefer a
kanban style tool for this sort of effort instead, but have
unfortunately turned to proprietary services like Trello as a
result.

I also don't think that lack of using the series/milestone tracker
in LP is an indication that a project is doing a worse job of
managing releases. We have a lot more useful automation now around
release notes, highlights, release processes scraping references
from commit logs, and so on.

> If you're saying it's not useful info and we're better off without
> it then I'll just have to disagree. If you're saying that it has
> been replaced with something better, please share the URLs.

https://docs.openstack.org/infra/storyboard/gui/theory.html#worklists-and-boards

As I said, we didn't want to start out telling teams how
they should be doing their release tracking so that we could see
what patterns emerged. If you recall the "specs" experiment years
ago, a few teams tried mildly different solutions for moving from LP
blueprints with random wiki page links to tracking specifications in
Git repositories, and over time they learned successful patterns
from each other and mostly converged on similar solutions. There
were similar cries back then about "how will users/operators find
out what is being planned?" but I think the end result was far
better than what it replaced.

> I'm all for improvements, but saying "only a few people were doing
> something useful so we should throw it out and nobody do it" isn't
> a path to improvement. How about we discuss alternate (e.g.
> better/easier/whatever) ways of making the information available.

I'm not saying anything should be thrown out. I personally don't
even feel that teams should be forced to use StoryBoard (or any
particular tool for that matter), but just want to focus on making
sure we provide useful, free and open tools through which and on
which we can collectively collaborate.
-- 
Jeremy Stanley


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

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[Jay S Bryant]

On 6/11/2018 11:54 AM, Doug Hellmann wrote:

Excerpts from Jay S Bryant's message of 2018-06-11 11:42:52 -0500:

On 6/11/2018 11:17 AM, CARVER, PAUL wrote:

Jumping into the general Storyboard topic, but distinct from the previous 
questions about searching, is there any equivalent in Storyboard to the 
Launchpad series and milestones diagrams? e.g.:

https://launchpad.net/nova/+series
https://launchpad.net/neutron/+series
https://launchpad.net/cinder/+series
https://launchpad.net/networking-sfc/+series
https://launchpad.net/bgpvpn/+series

As I understand from what I've read and seen on summit talk recordings, anyone can create 
any view of the data they please and they can share their personalized view with whomever 
they want, but that is basically the complete opposite of standardization. Does 
Storyboard have any plans to provide any standard views that are consistent across 
projects? Or is it focused solely on the "in club" who know what dashboard 
views are custom to each project?

Paul, this is actually one of the big concerns I have with the move to
Storyboard is the fact that there is no longer standardization across
projects.  When I asked about this it was noted that it would be
important for Cinder to document how we use Storyboard so people can
refer to the documentation and know how to use it.  This, however, seems
needlessly complicated. Would have expected how to use Storyboard was
going to be used to be documented/recommended before hand.

I'm not sure what sort of project-specific documentation we think we
need.

Each project team can set up its own board or worklist for a given
series. The "documentation" just needs to point to that thing, right?

Each team may also decide to use a set of tags, and those would need to
be documented, but that's no different from launchpad.
As I understood it, there is no required way to use Storyboard for 
tracking what used to be 'Blueprints'.  So each time will need to 
document how they use Storyboard to record such things.  If I am 
incorrect about this I apologize.

For anyone trying to follow multiple projects at a strategic level (i.e. not 
down in the weeds day to day, but checking in weekly or monthly) to see what's 
planned, what's deferred, and what's completed for either upcoming milestones 
or looking back to see if something did or did not get finished, a consistent 
cross-project UI of some kind is essential.

Agreed.  Wonder if at the next midcycle it would be worth having a cross
project discussion to try and create some consistency.  That, however,
would require buy-in from at least the core projects.

Why? If we have a large number of projects who agree to use the tool a
certain way, that seems good, regardless of whether any specific teams
are included in the group. Let the outliers document their processes, if
they end up being significantly different.
Fair enough.  It would help if we had buy-in from all of the projects 
but you are right that nothing prevents us from achieving consensus from 
those are are willing to participate.

For example, with virtually no insider involvement with Nova, I was able to 
locate this view of what's going on for the Rocky series: 
https://launchpad.net/nova/rocky
How would I locate that same information for a project in Storyboard without 
constructing my own custom worklist or finding an insider to share their 
worklist with 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] [heat][ci][infra][aodh][telemetry] telemetry test broken on oslo.messaging stable/queens

[Ken Giusti]

Updated subject to include [aodh] and [telemetry]

On Tue, Jun 5, 2018 at 11:41 AM, Doug Hellmann  wrote:
> Excerpts from Ken Giusti's message of 2018-06-05 10:47:17 -0400:
>> Hi,
>>
>> The telemetry integration test for oslo.messaging has started failing
>> on the stable/queens branch [0].
>>
>> A quick review of the logs points to a change in heat-tempest-plugin
>> that is incompatible with the version of gabbi from queens upper
>> constraints (1.40.0) [1][2].
>>
>> The job definition [3] includes required-projects that do not have
>> stable/queens branches - including heat-tempest-plugin.
>>
>> My question - how do I prevent this job from breaking when these
>> unbranched projects introduce changes that are incompatible with
>> upper-constrants for a particular branch?
>
> Aren't those projects co-gating on the oslo.messaging test job?
>
> How are the tests working for heat's stable/queens branch? Or telemetry?
> (whichever project is pulling in that tempest repo)
>

I've run the stable/queens branches of both Aodh[1] and Heat[2] - both failed.

Though the heat failure is different from what we're seeing on
oslo.messaging [3],
the same warning about gabbi versions is there [4].

However the Aodh failure is exactly the same as the oslo.messaging one
[5] - this makes sense since the oslo.messaging test is basically
running the same telemetry-tempest-plugin test.

So this isn't something unique to oslo.messaging - the telemetry
integration test is busted in stable/queens.

I'm going to mark these tests as non-voting on oslo.messaging's queens
branch for now so we can land some pending patches.


[1] https://review.openstack.org/#/c/574306/
[2] https://review.openstack.org/#/c/574311/
[3] 
http://logs.openstack.org/11/574311/1/check/heat-functional-orig-mysql-lbaasv2/21cce1d/job-output.txt.gz#_2018-06-11_17_30_51_106223
[4] 
http://logs.openstack.org/11/574311/1/check/heat-functional-orig-mysql-lbaasv2/21cce1d/logs/devstacklog.txt.gz#_2018-06-11_17_09_39_691
[5] 
http://logs.openstack.org/06/574306/1/check/telemetry-dsvm-integration/0a9620a/job-output.txt.gz#_2018-06-11_16_53_33_982143



>>
>> I've tried to use override-checkout in the job definition, but that
>> seems a bit hacky in this case since the tagged versions don't appear
>> to work and I've resorted to a hardcoded ref [4].
>>
>> Advice appreciated, thanks!
>>
>> [0] https://review.openstack.org/#/c/567124/
>> [1] 
>> http://logs.openstack.org/24/567124/1/check/oslo.messaging-telemetry-dsvm-integration-rabbit/e7fdc7d/logs/devstack-gate-post_test_hook.txt.gz#_2018-05-16_05_20_05_624
>> [2] 
>> http://logs.openstack.org/24/567124/1/check/oslo.messaging-telemetry-dsvm-integration-rabbit/e7fdc7d/logs/devstacklog.txt.gz#_2018-05-16_05_19_06_332
>> [3] 
>> https://git.openstack.org/cgit/openstack/oslo.messaging/tree/.zuul.yaml?h=stable/queens#n250
>> [4] https://review.openstack.org/#/c/572193/2/.zuul.yaml
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Ken Giusti  (kgiu...@gmail.com)

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

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[CARVER, PAUL]

Jeremy Stanley  wrote:

>I'm just going to come out and call bullshit on this one. How many of the >800 
>official OpenStack deliverable repos have a view like that with any actual 
>relevant detail? If it's "standard" then certainly more than half, right?

Well, that's a bit rude, so I'm not going to get in a swearing contest over 
whether Nova, Neutron and Cinder are more "important" than 800+ other projects. 
I picked a handful of projects that I'm most interested in and which also 
happened to have really clear, accessible and easy to understand information on 
what they have delivered in the past and are planning to deliver in the future. 
If I slighted your favorite projects I apologize.

So, are you saying the information shown in the examples I gave is not useful?

Or just that I've been lucky in the past that the projects I'm most interested 
in do a better than typical job of managing releases but the future is all 
downhill?

If you're saying it's not useful info and we're better off without it then I'll 
just have to disagree. If you're saying that it has been replaced with 
something better, please share the URLs.

I'm all for improvements, but saying "only a few people were doing something 
useful so we should throw it out and nobody do it" isn't a path to improvement. 
How about we discuss alternate (e.g. better/easier/whatever) ways of making the 
information available.


__
OpenStack Development Mailing 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] use of storyboard (was [TC] Stein Goal Selection)

[Matt Riedemann]

On 6/11/2018 1:57 PM, Jeremy Stanley wrote:

So... of the_minority_  of projects (from that arbitrarily-chosen
but presumably "important" sample) who are actually using that
feature, how many of them are simply doing it because they thought
the release team was still making use of that information? (Hint:
they stopped as of mitaka.)


I never used the series/release/milestone stuff for tracking nova 
blueprint deliverables because of the release team, I did it purely for 
project management reasons while I was PTL since it was a clean and easy 
way to track that information, and allowed me to easily gather stats for 
blueprint levels across nova releases.


Otherwise what you said is correct about that totally being per-project 
and dependent on the level of OCD of the release liaison / PTL of that 
project.


--

Thanks,

Matt

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

[openstack-dev] [tripleo] scenario000-multinode-oooq-container-upgrades

[Wesley Hayutin]

Greetings,

I wanted to let everyone know that we have a keystone only deployment and
upgrade job in check non-voting.  I'm asking everyone in TripleO to be
mindful of this job and to help make sure it continues to pass as we move
it from non-voting check to check and eventually gating.

Upgrade jobs are particularly difficult to keep running successfully
because of the complex workflow itself, job run times and other factors.
Your help to ensure we don't merge w/o a pass on this job will go a long
way in helping the tripleo upgrades team.

There is still work to be done here, however it's much easier to do it with
the check non-voting job in place.

Thanks all
__
OpenStack Development Mailing 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][sdk][heat] Integrating OpenStack and k8s with a service broker

[Zane Bitter]

On 08/06/18 22:28, Rico Lin wrote:



Zane Bitter mailto:zbit...@redhat.com>> 於 2018年6 
月9日 週六 上午9:20寫道：

 >
 > IIUC you're talking about a Heat resource that calls out to a service
 > broker using the Open Service Broker API? (Basically acting like the
 > Kubernetes Service Catalog.) That would be cool, as it would allow us to
 > orchestrate services written for Kubernetes/CloudFoundry using Heat.
 > Although probably not as easy as it sounds at first glance ;)
In my previous glance, I was thought about our new service will also 
wrap up API with Ansible playbooks. A playbook to create a resource, and 
another playbook to control Service Broker API. So we can directly 
use that playbook instead of calling Service broker APIs. No?:)


Oh, call the playbooks directly from Heat? That would work for anything 
else that uses Automation Broker (e.g. the AWS playbook bundles), but 
not for stuff that has its own service broker implementation (e.g. Azure).


That said, it would also be interesting for other reasons if Heat had a 
way to run Ansible playbooks either directly or via AWX, but now we're 
getting even further off-topic ;)


I think we can start trying to build playbooks before we start planning 
on crazy ideas:)

 >
 > It wouldn't rely on _this_ set of playbook bundles though, because this
 > one is only going to expose OpenStack resources, which are already
 > exposed in Heat. (Unless you're suggesting we replace all of the current
 > resource plugins in Heat with Ansible playbooks via the service broker?
 > In which case... that's not gonna happen ;)
Right, we should use OS::Heat::Stackto expose resources from other 
OpenStack, notwith this.


+1


 > So Heat could adopt this at any time to add support for resources
 > exposed by _other_ service brokers, such as the AWS/Azure/GCE service
 > brokers or other playbooks exposed through Automation Broker.
 >

I like the idea to add support for resources exposed by other service 
borkers


I can already see that I'm going to make this same typo at least 3 times 
a week.


https://www.youtube.com/watch?v=sY_Yf4zz-yo

- ZB

__
OpenStack Development Mailing 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] use of storyboard (was [TC] Stein Goal Selection)

[Jeremy Stanley]

Others likely have more detailed answers to some of your other
points, but as for the ones I happen to know off the top of my
head...

On 2018-06-11 12:39:36 -0400 (-0400), Zane Bitter wrote:
[...]
> * There's no help link anywhere. (This appears to be because there's nothing
> to link to.)

It's https://storyboard.openstack.org/#!/page/about (linked as
"About" in the left sidebar of every page on the site) but maybe it
should be renamed and/or given an icon? It's also the default page
view if you go to the site root while not authenticated. It should
probably also link to https://docs.openstack.org/infra/storyboard/ I
guess.

> * There's no way to mark a story as a duplicate of another.

In a twist of irony, this is being tracked in:

https://storyboard.openstack.org/#!/story/2000552
https://storyboard.openstack.org/#!/story/2002136

> * Numeric IDs in URLs instead of project names are a serious barrier to
> usability.
[...]

The change series ending in https://review.openstack.org/548343
implements this, and is basically ready to merge any time now.

> * You can't even use Google to search it, I suspect because only issues that
> are linked to from other sites are visible to the crawler due to there being
> no sitemap.xml.
[...]

There's in-progress work to update storyboard-webclient to newer
AngularJS and as a result the situation related to Web search
engines will get significantly better. Adding a sitemap or similar
index for the benefit of search engines should likely come with or
shortly after that.
-- 
Jeremy Stanley


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

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[Jeremy Stanley]

On 2018-06-11 17:17:23 + (+), CARVER, PAUL wrote:
[...]
> Perhaps none if there is a standard, but is there a standard? Can
> you give me examples in Storyboard of "standard" views that
> present information even vaguely similar to
> https://launchpad.net/nova/+series and
> https://launchpad.net/nova/rocky ? Or is every project on their
> own to invent the views that they will use, independent of what
> any other project is doing?
[...]

I'm just going to come out and call bullshit on this one. How many
of the >800 official OpenStack deliverable repos have a view like
that with any actual relevant detail? If it's "standard" then
certainly more than half, right?

Picking through just the set of 40 "services" listed at
https://www.openstack.org/software/project-navigator I see that:

  * swift seems to stop in mitaka
  * murano in pike
  * freezer in queens
  * solum in liberty
  * aodh in newton
  * senlin in pike
  * ironic in queens (but not really as the series just exist with
no releases after newton)
  * octavia in pike
  * karbor in queens (but not really any detail even then)
  * searchlight in pike
  * barbican in queens (but not really since they stopped showing
releases in pike)
  * panko never used it at all
  * ceilometer stopped in mitaka
  * monasca never used it
  * rally has nonstandard series names but stopped sometime in 2017
  * congress stopped in queens
  * watcher in queens
  * vitrage in queens (but actually stopped milestoning in ocata)
  * cloudkitty has nonstandard series names ending in 2017
  * tricircle stopped using milestones in pike
  * openstack-ansible ended in newton
  * kuryr never used it

So... of the _minority_ of projects (from that arbitrarily-chosen
but presumably "important" sample) who are actually using that
feature, how many of them are simply doing it because they thought
the release team was still making use of that information? (Hint:
they stopped as of mitaka.)
-- 
Jeremy Stanley


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

[openstack-dev] [neutron] Bug deputy report june 5 - June 10

[Bhatia, Manjeet S]

Hi,

There were total of 15 new bugs reported I categorized below depending on if 
they are related to CI or neutron-client or RFE. Only one
Was critical bug 1775183 for which fixed is released. There's one high priority 
 bug 1775220 confirmed. Some bugs were marked invalid
and incomplete and also listed at the bottom. Some of bugs are still not marked 
confirmed need further confirmation from related members of
Neutron community.

Bugs !


1.  https://bugs.launchpad.net/neutron/+bug/1775146 found some flow tables 
of br-int will be missing After I restarted neutron-openvswitch-agent.

2.  https://bugs.launchpad.net/neutron/+bug/1775183 Fullstack test 
neutron.tests.fullstack.test_l3_agent.TestHAL3Agent. 
test_ha_router_restart_agents_no_packet_lost fails often

3.  https://bugs.launchpad.net/neutron/+bug/1775382 
neutron-openvswitch-agent cannot start on Windows

4.  https://bugs.launchpad.net/neutron/+bug/1775496 agentschedulers: 
concurrent port delete on unscheduling may cause unscheduling to fail.

5.  https://bugs.launchpad.net/neutron/+bug/1775644 Neutron fwaas v2 group 
port binding failed

6.  https://bugs.launchpad.net/bugs/1775797 The mac table size of neutron 
bridges (br-tun, br-int, br-*) is too small by default and eventually makes 
openvswitch explode

7.  https://bugs.launchpad.net/neutron/+bug/1776160 'burst' does not take 
effect for neutron egress  qos bindlimit by ovs

RFE reported as Bug

8.  https://bugs.launchpad.net/neutron/+bug/1775250 Implement DVR-aware 
announcement of fixed IP's in neutron-dynamic-routing


Neutron CI related bugs !

9.  https://bugs.launchpad.net/neutron/+bug/1775947 
tempest.api.compute.servers.test_device_tagging.TaggedAttachmentsTest failing.

10.   https://bugs.launchpad.net/neutron/+bug/1775220 Unit test 
neutron.tests.unit.objects.test_ports.PortBindingLevelDbObjectTestCase. 
test_get_objects_queries_constant fails often.

Neutron-client

11.   https://bugs.launchpad.net/python-neutronclient/+bug/1775922 neutron 
net-list with pagination fails on too many subnets

Bugs marked Invalid or Incomplete

12.   https://bugs.launchpad.net/neutron/+bug/1775310 Unused namespace is 
appeared.

13.   https://bugs.launchpad.net/neutron/+bug/1775415 pagination for list 
operations behaves inconsistently

14.   https://bugs.launchpad.net/bugs/1775580 Networking Option 2: Self-service 
networks in Neutron

15.   https://bugs.launchpad.net/neutron/+bug/1775758 Deprecated auth_url 
entries in Neutron Queen's install guide


Regards !
Manjeet Singh Bhatia
__
OpenStack Development Mailing 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] [vitrage] matching webhook vs alarm list

[Eric K]

Thank you for the explanation!

Eric

From:  "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Monday, June 11, 2018 at 1:34 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [vitrage] matching webhook vs alarm list

> Hi Eric,
>  
> The format of the vitrage_id was changed to UUID in Pike release. It appears
> that the API documentation [1] is outdated. I¹ll fix it.
> The vitrage_id that you get in the webhook notification should match the one
> coming from Œvitrage alarm list¹. The Œid¹ field is determined by the external
> monitor, so it might be different.
>  
> Best Regards,
> Ifat
>  
> 
> -- Forwarded message -
> From: Eric K 
> Date: Sat, 9 Jun 2018 at 01:40
> Subject: [openstack-dev] [vitrage] matching webhook vs alarm list
> To: OpenStack Development Mailing List (not for usage questions)
> 
> 
> 
> Hi I'm building integration with Vitrage webhook and looking for some
> clarification on what ID to use for matching a webhook notification to
> the specific alarm from the alarm list. In the sample alarm list
> response, there is an 'id' field and a 'vitrage_id' field [1], where
> as in the sample webhook notification payload, there is a 'vitrage_id'
> field [2]. I'd assume we can match by the 'vitrage_id', but the
> samples have very different formats for 'vitrage_id', so I just want
> to confirm. Thank you!
> 
> [1] 
> https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html#id22
> [2]
> {
>   "notification": "vitrage.alarm.activate",
>   "payload": {
> "vitrage_id": "2def31e9-6d9f-4c16-b007-893caa806cd4",
> "resource": {
>   "vitrage_id": "437f1f4c-ccce-40a4-ac62-1c2f1fd9f6ac",
>   "name": "app-1-server-1-jz6qvznkmnif",
>   "update_timestamp": "2018-01-22 10:00:34.327142+00:00",
>   "vitrage_category": "RESOURCE",
>   "vitrage_operational_state": "OK",
>   "vitrage_type": "nova.instance",
>   "project_id": "8f007e5ba0944e84baa6f2a4f2b5d03a",
>   "id": "9b7d93b9-94ec-41e1-9cec-f28d4f8d702c"
> },
> "update_timestamp": "2018-01-22T10:00:34Z",
> "vitrage_category": "ALARM",
> "state": "Active",
> "vitrage_type": "vitrage",
> "vitrage_operational_severity": "WARNING",
> "name": "Instance memory performance degraded"
>   }
> }
> https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plugin.
> html
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions) Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [vitrage] update_timestamp precision

[Eric K]

Thank you, Ifat!
From:  "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Monday, June 11, 2018 at 2:12 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [vitrage] update_timestamp precision

> Hi Eric,
>  
> Apparently we have inconsistent behavior between the different datasources.
> The format of the timestamp should be '%Y-%m-%dT%H:%M:%SZ' as defined in [1].
> We need to go over the code and make sure all datasources are aligned. I
> created a bug for it [2].
>  
> [1] 
> https://github.com/openstack/vitrage/blob/master/vitrage/datasources/transform
> er_base.py
> 
> [2] https://bugs.launchpad.net/vitrage/+bug/1776181
> Best regards,
> Ifat
>  
> 
> -- Forwarded message -
> From: Eric K 
> Date: Sat, 9 Jun 2018 at 00:20
> Subject: [openstack-dev] [vitrage] update_timestamp precision
> To: OpenStack Development Mailing List (not for usage questions)
> 
> 
> 
> Hi I'm building integration with Vitrage webhook and looking for some
> clarification on the timestamp precision to expect.
> 
> In the sample webhook payload found in doc the resource and the alarm
> shows different time stamp precisions:
> https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plug
> in.html 
>  .html> 
> 
> 
> Thank you!
> 
> 
> 
> __
> OpenStack Development Mailing 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] use of storyboard (was [TC] Stein Goal Selection)

[CARVER, PAUL]

Doug Hellmann   wrote:


>I'm not sure what sort of project-specific documentation we think we need.
Perhaps none if there is a standard, but is there a standard? Can you give me 
examples in Storyboard of "standard" views that present information even 
vaguely similar to https://launchpad.net/nova/+series and 
https://launchpad.net/nova/rocky ? Or is every project on their own to invent 
the views that they will use, independent of what any other project is doing?

>Each project team can set up its own board or worklist for a given series. The 
>"documentation" just needs to point to that thing, right?
If we're relying on each team to set up its own board or worklist then it 
sounds like there is not a standard. In which case, we're back to the need for 
each project to document (at a minimum) where to find its view and perhaps also 
how to interpret it.

>Each team may also decide to use a set of tags, and those would need to be 
>documented, but that's no different from launchpad.
I agree, use of tags is likely to be team specific, but where can someone find 
those tags without mind-melding with an experienced member of the project?

E.g. If I navigate to the fairly obvious URL: 
https://bugs.launchpad.net/neutron I can see a list of tags on the right side 
of the page, sorted in descending order by frequency of use. On the other hand, 
if I follow the intuitive process of going to https://storyboard.openstack.org 
and clicking on "Project Groups" and then clicking "heat" and then clicking 
"openstack/heat" I reach the somewhat less obvious URL 
https://storyboard.openstack.org/#!/project/989 and no indication at all of 
what tags might be useful in this project.


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

[openstack-dev] [neutron] Neutron CI meeting 12.06.2018 cancelled

[Slawomir Kaplonski]

Hi,

I will be traveling tomorrow so I can’t chair CI meeting on 12.06.2018 so it is 
cancelled.
Next meeting will be normally at 19.06.2018.

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
OpenStack Development Mailing 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] use of storyboard (was [TC] Stein Goal Selection)

[Doug Hellmann]

Excerpts from Jay S Bryant's message of 2018-06-11 11:42:52 -0500:
> 
> On 6/11/2018 11:17 AM, CARVER, PAUL wrote:
> > Jumping into the general Storyboard topic, but distinct from the previous 
> > questions about searching, is there any equivalent in Storyboard to the 
> > Launchpad series and milestones diagrams? e.g.:
> >
> > https://launchpad.net/nova/+series
> > https://launchpad.net/neutron/+series
> > https://launchpad.net/cinder/+series
> > https://launchpad.net/networking-sfc/+series
> > https://launchpad.net/bgpvpn/+series
> >
> > As I understand from what I've read and seen on summit talk recordings, 
> > anyone can create any view of the data they please and they can share their 
> > personalized view with whomever they want, but that is basically the 
> > complete opposite of standardization. Does Storyboard have any plans to 
> > provide any standard views that are consistent across projects? Or is it 
> > focused solely on the "in club" who know what dashboard views are custom to 
> > each project?
> Paul, this is actually one of the big concerns I have with the move to 
> Storyboard is the fact that there is no longer standardization across 
> projects.  When I asked about this it was noted that it would be 
> important for Cinder to document how we use Storyboard so people can 
> refer to the documentation and know how to use it.  This, however, seems 
> needlessly complicated. Would have expected how to use Storyboard was 
> going to be used to be documented/recommended before hand.

I'm not sure what sort of project-specific documentation we think we
need.

Each project team can set up its own board or worklist for a given
series. The "documentation" just needs to point to that thing, right?

Each team may also decide to use a set of tags, and those would need to
be documented, but that's no different from launchpad.

> > For anyone trying to follow multiple projects at a strategic level (i.e. 
> > not down in the weeds day to day, but checking in weekly or monthly) to see 
> > what's planned, what's deferred, and what's completed for either upcoming 
> > milestones or looking back to see if something did or did not get finished, 
> > a consistent cross-project UI of some kind is essential.
> Agreed.  Wonder if at the next midcycle it would be worth having a cross 
> project discussion to try and create some consistency.  That, however, 
> would require buy-in from at least the core projects.

Why? If we have a large number of projects who agree to use the tool a
certain way, that seems good, regardless of whether any specific teams
are included in the group. Let the outliers document their processes, if
they end up being significantly different.

> > For example, with virtually no insider involvement with Nova, I was able to 
> > locate this view of what's going on for the Rocky series: 
> > https://launchpad.net/nova/rocky
> > How would I locate that same information for a project in Storyboard 
> > without constructing my own custom worklist or finding an insider to share 
> > their worklist with 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

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[Jay S Bryant]

On 6/11/2018 11:17 AM, CARVER, PAUL wrote:

Jumping into the general Storyboard topic, but distinct from the previous 
questions about searching, is there any equivalent in Storyboard to the 
Launchpad series and milestones diagrams? e.g.:

https://launchpad.net/nova/+series
https://launchpad.net/neutron/+series
https://launchpad.net/cinder/+series
https://launchpad.net/networking-sfc/+series
https://launchpad.net/bgpvpn/+series

As I understand from what I've read and seen on summit talk recordings, anyone can create 
any view of the data they please and they can share their personalized view with whomever 
they want, but that is basically the complete opposite of standardization. Does 
Storyboard have any plans to provide any standard views that are consistent across 
projects? Or is it focused solely on the "in club" who know what dashboard 
views are custom to each project?
Paul, this is actually one of the big concerns I have with the move to 
Storyboard is the fact that there is no longer standardization across 
projects.  When I asked about this it was noted that it would be 
important for Cinder to document how we use Storyboard so people can 
refer to the documentation and know how to use it.  This, however, seems 
needlessly complicated. Would have expected how to use Storyboard was 
going to be used to be documented/recommended before hand.

For anyone trying to follow multiple projects at a strategic level (i.e. not 
down in the weeds day to day, but checking in weekly or monthly) to see what's 
planned, what's deferred, and what's completed for either upcoming milestones 
or looking back to see if something did or did not get finished, a consistent 
cross-project UI of some kind is essential.
Agreed.  Wonder if at the next midcycle it would be worth having a cross 
project discussion to try and create some consistency.  That, however, 
would require buy-in from at least the core projects.

For example, with virtually no insider involvement with Nova, I was able to 
locate this view of what's going on for the Rocky series: 
https://launchpad.net/nova/rocky
How would I locate that same information for a project in Storyboard without 
constructing my own custom worklist or finding an insider to share their 
worklist with 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

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[Zane Bitter]

On 11/06/18 10:23, Doug Hellmann wrote:

Excerpts from Dmitry Tantsur's message of 2018-06-11 16:00:41 +0200:

Hi,

On 06/11/2018 03:53 PM, Ruby Loo wrote:

Hi,

I don't want to hijack the initial thread, but am now feeling somewhat guilty
about not being vocal wrt Storyboard. Yes, ironic migrated to Storyboard in the
beginning of this cycle. To date, I have not been pleased with replacing
Launchpad with Storyboard. I believe that Storyboard is somewhat
still-in-progress, and that there were/are some features (stories) that are
outstanding that would make its use better.

  From my point of view (as a developer and core, not a project manager or PTL)
using Storyboard has made my day-to-day work worse. Granted, any migration is
without headaches. But some of the main things, like searching for our RFEs
(that we had tagged in Launchpad) wasn't possible. I haven't yet figured out how
to limit a search to only the 'ironic' project using that 'search' like GUI, so
I have been frustrated trying to find particular bugs that I *knew* existed but
had not memorized the bug number.


Yeah, I cannot fully understand the search. I would expect something explicit
like Launchpad or better something command-based like "project:openstack/ironic
pxe". This does not seem to work, so I also wonder how to filter all stories
affecting a project.



Searching tripped me up for the first couple of weeks, too.
Storyboard's search field is a lot "smarter" than expected. Or maybe
you'd call it "magic". Either way, it was confusing, but you don't have
to use any special syntax in the UI.

To search for a project, type the name of the project in the search
field and then *wait* for the list of drop-down options to appear.
The first item in the list will be a "raw" search for the term. The
others will have little icons indicating their type. The project
icon looks like a little cube, for example.  If I go to
https://storyboard.openstack.org/#!/search and type "openstack/ironic"
I get a list that includes openstack/ironic, openstack/ironic-inspector,
etc.

Select the project you want from the list and hit enter, and you'll
get a list of all of the stories with tasks attached to the project.


Yeah, it's actually pretty powerful, but the UX is a pain. For a 
workflow as common as searching within a project, there should never be 
a step that involves *waiting*. This could be easily fixed: if the user 
is on the page for a project (or project group) and clicks on the search 
tab, the search field should be autopopulated with the project so they 
only have to opt out when they want to search something else, rather 
than opt in every time by typing the project's name again... waiting... 
clicking on one of the inscrutable icons. (Prepopulating in this way 
would also help teach people how the search field works and what the 
little icons mean, so that it wouldn't take weeks to figure out how to 
search within a project even when you have to start from scratch.)


There are a lot of rough edges like this. An issue tracker is an 
incredibly complicated class of application, and projects like Launchpad 
have literally millions of issues tracked, so basically everything that 
could come up has. Storyboard is not at that stage yet.


Some other bugbears:

* There's no help link anywhere. (This appears to be because there's 
nothing to link to.)


* There's no way to mark a story as a duplicate of another.

* Numeric IDs in URLs instead of project names are a serious barrier to 
usability.


* Default query size of 10 unless you (a) are logged in, and (b) 
increased it to something sane in your Profile (pro tip: do this now!) 
makes it really painful to use, especially since the full text search is 
not very accurate, the prev/next arrows appear to be part of a 
competition to make UI elements as tiny as possible(4 pixels wide, and 
even the click target is only 16), and moving between pages is kinda 
slow. Also I changed the setting in my profile the other day, and when I 
logged in again today it had been reset to 10.


* Actually, I just tried scrolling through the project list after 
setting the query size back to 100, and the ranges I got were:

  - 1 to 100 of 344 ok so far
  - 101 to 200 of 344 good good
  - 100101 to 344 of 344 wat

* Actually, *is* there any full-text search? The search page says only 
that you can search for "Keyword in a story or task title". That would 
explain why it's impossible to find most things you're looking for.


* You can't even use Google to search it, I suspect because only issues 
that are linked to from other sites are visible to the crawler due to 
there being no sitemap.xml.


* Showing project groups in reverse chronological order of their 
creation instead of alphabetical order is bizarre.


* Launchpad fields always display in fixed-width fonts with linebreaks 
preserved. Storyboard uses Markdown. The migration process makes no 
attempt to preserve the formatting, so a lot of the 

[openstack-dev] [cinder] Recordings from the Vancouver Summit Uploaded

[Jay S Bryant]

All,

I have gotten the Vancouver Summit Forum session recordings uploaded to 
YouTube.  You can see the links in our wiki here: 
https://wiki.openstack.org/wiki/VancouverSummit2018Summary


Let me know if you have any questions.

Thanks!

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

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[CARVER, PAUL]

Jumping into the general Storyboard topic, but distinct from the previous 
questions about searching, is there any equivalent in Storyboard to the 
Launchpad series and milestones diagrams? e.g.:

https://launchpad.net/nova/+series
https://launchpad.net/neutron/+series
https://launchpad.net/cinder/+series
https://launchpad.net/networking-sfc/+series
https://launchpad.net/bgpvpn/+series

As I understand from what I've read and seen on summit talk recordings, anyone 
can create any view of the data they please and they can share their 
personalized view with whomever they want, but that is basically the complete 
opposite of standardization. Does Storyboard have any plans to provide any 
standard views that are consistent across projects? Or is it focused solely on 
the "in club" who know what dashboard views are custom to each project?

For anyone trying to follow multiple projects at a strategic level (i.e. not 
down in the weeds day to day, but checking in weekly or monthly) to see what's 
planned, what's deferred, and what's completed for either upcoming milestones 
or looking back to see if something did or did not get finished, a consistent 
cross-project UI of some kind is essential.

For example, with virtually no insider involvement with Nova, I was able to 
locate this view of what's going on for the Rocky series: 
https://launchpad.net/nova/rocky
How would I locate that same information for a project in Storyboard without 
constructing my own custom worklist or finding an insider to share their 
worklist with me?

-- 
Paul Carver
VoIP: 732-545-7377
Cell: 908-803-1656
E: pcar...@att.com
Q Instant Message
If you look closely enough at the present you can find loose bits of the future 
just lying around.



__
OpenStack Development Mailing 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] increasing the number of allowed volumes attached per instance > 26

[Eric Fried]

I thought we were leaning toward the option where nova itself doesn't
impose a limit, but lets the virt driver decide.

I would really like NOT to see logic like this in any nova code:

> if kvm|qemu:
> return 256
> elif POWER:
> return 4000
> elif:
> ...

On 06/11/2018 10:06 AM, Kashyap Chamarthy wrote:
> On Mon, Jun 11, 2018 at 11:55:29AM +0200, Sahid Orentino Ferdjaoui wrote:
>> On Fri, Jun 08, 2018 at 11:35:45AM +0200, Kashyap Chamarthy wrote:
>>> On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote:
> 
> [...]
> 
 The 26 volumes thing is a libvirt driver restriction.
>>>
>>> The original limitation of 26 disks was because at that time there was
>>> no 'virtio-scsi'.  
>>>
>>> (With 'virtio-scsi', each of its controller allows upto 256 targets, and
>>> each target can use any LUN (Logical Unit Number) from 0 to 16383
>>> (inclusive).  Therefore, the maxium allowable disks on a single
>>> 'virtio-scsi' controller is 256 * 16384 == 4194304.)  Source[1].
>>
>> Not totally true for Nova. Nova handles one virtio-scsi controller per
>> guest and plug all the volumes in one target so in theory that would
>> be 16384 LUN (only).
> 
> Yeah, I could've been clearer that I was only talking the maximum
> allowable disks regardless of how Nova handles it.
> 
>> But you made a good point the 26 volumes thing is not a libvirt driver
>> restriction. For example the QEMU SCSI native implementation handles
>> 256 disks.
>>
>> About the virtio-blk limitation I made the same finding but Tsuyoshi
>> Nagata shared an interesting point saying that virtio-blk is not longer
>> limited by the number of PCI slot available. That in recent kernel and
>> QEMU version [0].
>>
>> I could join what you are suggesting at the bottom and fix the limit
>> to 256 disks.
> 
> Right, that's for KVM-based hypervisors.  
> 
> Eric Fried on IRC said the other day that for IBM POWER hypervisor they
> have tested (not with OpenStack) upto 4000 disks.  But I am yet to see
> any more concrete details from POWER hypervisor users on this thread.
> 
> If people can't seem to reach an agreement on the limits, we may have to
> settle with conditionals:
> 
> if kvm|qemu:
> return 256
> elif POWER:
> return 4000
> elif:
> ...
> 
> Before that we need concrete data that it is a _reasonble_ limit for
> POWER hypervisor (and possibly others).
> 
>> [0] 
>> https://review.openstack.org/#/c/567472/16/nova/virt/libvirt/blockinfo.py@162
> 
> [...]
> 

__
OpenStack Development Mailing 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] increasing the number of allowed volumes attached per instance > 26

[Kashyap Chamarthy]

On Mon, Jun 11, 2018 at 11:55:29AM +0200, Sahid Orentino Ferdjaoui wrote:
> On Fri, Jun 08, 2018 at 11:35:45AM +0200, Kashyap Chamarthy wrote:
> > On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote:

[...]

> > > The 26 volumes thing is a libvirt driver restriction.
> > 
> > The original limitation of 26 disks was because at that time there was
> > no 'virtio-scsi'.  
> > 
> > (With 'virtio-scsi', each of its controller allows upto 256 targets, and
> > each target can use any LUN (Logical Unit Number) from 0 to 16383
> > (inclusive).  Therefore, the maxium allowable disks on a single
> > 'virtio-scsi' controller is 256 * 16384 == 4194304.)  Source[1].
> 
> Not totally true for Nova. Nova handles one virtio-scsi controller per
> guest and plug all the volumes in one target so in theory that would
> be 16384 LUN (only).

Yeah, I could've been clearer that I was only talking the maximum
allowable disks regardless of how Nova handles it.

> But you made a good point the 26 volumes thing is not a libvirt driver
> restriction. For example the QEMU SCSI native implementation handles
> 256 disks.
> 
> About the virtio-blk limitation I made the same finding but Tsuyoshi
> Nagata shared an interesting point saying that virtio-blk is not longer
> limited by the number of PCI slot available. That in recent kernel and
> QEMU version [0].
> 
> I could join what you are suggesting at the bottom and fix the limit
> to 256 disks.

Right, that's for KVM-based hypervisors.  

Eric Fried on IRC said the other day that for IBM POWER hypervisor they
have tested (not with OpenStack) upto 4000 disks.  But I am yet to see
any more concrete details from POWER hypervisor users on this thread.

If people can't seem to reach an agreement on the limits, we may have to
settle with conditionals:

if kvm|qemu:
return 256
elif POWER:
return 4000
elif:
...

Before that we need concrete data that it is a _reasonble_ limit for
POWER hypervisor (and possibly others).

> [0] 
> https://review.openstack.org/#/c/567472/16/nova/virt/libvirt/blockinfo.py@162

[...]

-- 
/kashyap

__
OpenStack Development Mailing 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] proposing changes to the project-team-guide-core review team

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-06-05 12:14:19 -0400:
> The review team [1] for the project-team-guide repository (managed
> by the TC) hasn't been updated for a while. I would like to propose
> removing a few reviewers who are no longer active, and adding one
> new reviewer.
> 
> My understanding is that Kyle Mestery and Nikhil Komawar have both
> moved on from OpenStack to other projects, so I propose that we
> remove them from the core team.
> 
> Chris Dent has been active with reviews lately and has expressed
> willingness to help manage the guide. I propose that we add him to
> the team.
> 
> Please let me know what you think,
> Doug
> 
> [1] https://review.openstack.org/#/admin/groups/953,members

After a week with no objections, I have added Chris to the review team
for the project-team-guide repository.

Thank you again, Chris, for offering to help!

Doug

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

[openstack-dev] [tc] technically committee status for 11 June

[Doug Hellmann]

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

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

== Recent Activity ==

Project updates:

* PowerVMStackers following stable policy 
https://review.openstack.org/#/c/562591
* Add openstackclient to Chef OpenStack https://review.openstack.org/#/c/571504

Other approved changes:

* provide more detail about the expectations we place on goal champions 
https://review.openstack.org/564060

Office hour logs from last week:

* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-05-09.00.html
* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-06-01.00.html
* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-07-15.00.html

I posted my summary of the joint leadership meeting held between the
Foundation Board, User Committee, and TC at the summit:
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131115.html

== Ongoing Discussions ==

The TC has started planning for more active tracking of the work of
project teams and SIGs, to identify inter-group issues earlier and to
help work through them as needed. The first step in the process is to
have TC members attached as liaisons to all of the groups. When all TC
members have had a chance to sign up as liaisons for teams where they
are already active, I will make assignments to fill out the roster so
that all teams are covered.

* http://lists.openstack.org/pipermail/openstack-dev/2018-June/131293.html
* https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Liaisons

The resolution laying out the Python 2 deprecation timeline and deadline
for supporting Python 3 has enough votes to be approved, but we had
several TC members traveling last week so I am going to hold it open
until 12 June in case anyone else has comments.

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

The governance change to add a "Castellan-compatible key store" to the
base services list is up for review.

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

The first batch of git repositories for StarlingX, containing only
projects that are not forks of anything else, have been imported.

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

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

I have proposed a small change to the house-rules clarifying how typo
fixes proposed by the chair should be handled.

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

TC members, please sign up as a liaison to project teams and SIGs (see
above).

== Contacting the TC ==

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

Office hour times in #openstack-tc:

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

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

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

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


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

Re: [openstack-dev] [all] [release] How to handle "stable" deliverables releases

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2018-06-11 11:53:52 +0200:
> Hi everyone,
> 
> As some of the OpenStack deliverables get more mature, we need to adjust 
> our release policies to best handle the case of deliverables that do not 
> need to be updated that much. This discussion started with how to handle 
> those "stable" libraries, but is actually also relevant for "stable" 
> services.
> 
> Our current models include cycle-tied models (with-intermediary, 
> with-milestones, trailing) and a purely cycle-independent model. Main 
> OpenStack deliverables (the service components that you can deploy to 
> build an OpenStack cloud) are all "released" on a cycle. Libraries are 
> typically maintained per-cycle as well. What happens if no change is 
> pushed to a service or library during a full cycle ? What should we do 
> then ?
> 
> Options include:
> 
> 1/ Force artificial releases, even if there are no changes
> 
> This is the current state. It allows to reuse the exact same process, 
> but creates useless churn and version number confusion.
> 
> 2/ Do not force releases, but still create branches from latest releases
> 
> In this variant we would not force an artificial re-release, but we 
> would still create a branch from the last available release, in order to 
> be able to land future patches and do bugfix or security releases as needed.
> 
> 2bis/ Like 2, but only create the branch when needed
> 
> Same as the previous one, except that rather than proactively create the 
> stable branch around release time, we'd wait until the branch is 
> actually needed to create it.
> 
> 3/ Do not force releases, and reuse stable branches from cycle to cycle
> 
> In this model, if there is no change in a library in Rocky, stable/rocky 
> would never be created, and stable/queens would be used instead. Only 
> one branch would get maintained for the 2 cycles. While this reduces the 
> churn, it's a bit complex to wrap your head around the consequences, and 
> measure how confusing this could be in practice...
> 
> 4/ Stop worrying about stable branches at all for those "stable" things
> 
> The idea here would be to stop doing stable branches for those things 
> that do not release that much anymore. This could be done by switching 
> them to the "independent" release model, or to a newly-created model. 
> While good for "finished" deliverables, this option could create issues 
> for things that are inactive for a couple cycles and then pick up 
> activity again -- switching back to being cycle-tied would likely be 
> confusing.
> 
> 
> My current preference is option 2.
> 
> It's a good trade-off which reduces churn while keeping a compatibility 
> with the system used for more active components. Compared to 2bis, it's 
> a bit more work (although done in one patch during the release process), 
> but creating the branches in advance means they are ready to be used 
> when someone wants to backport something there, likely reducing process 
> pain.
> 
> One caveat with this model is that we need to be careful with version 
> numbers. Imagine a library that did a 1.18.0 release for queens (which 
> stable/queens is created from). Nothing happens in Rocky, so we create 
> stable/rocky from the same 1.18.0 release. Same in Stein, so we create 
> stable/stein from the same 1.18.0 release. During the Telluride[1] cycle 
> some patches land and we want to release that. In order to leave room 
> for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0, 
> and go directly to 1.20.0. I think we can build release checks to ensure 
> that, but that's something to keep in mind.
> 
> Thoughts ?
> 
> [1] It's never too early to campaign for your favorite T name

Although I originally considered it separate, reviewing your summary
I suspect option 2bis is most likely to turn into option 3, in
practice.

I think having the choice between options 2 and switching to an
independent release model (maybe only for libraries) is going to
be best, at least to start out.

Stein will be the first series where we have to actually deal with
this, so we can see how it goes and discuss alternatives if we run
into issues.

Doug

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

[openstack-dev] [nova] Notification update week 24

[Balázs Gibizer]

Hi,

Here is the latest notification subteam update.

Bugs


[Medium] https://bugs.launchpad.net/nova/+bug/1739325 Server operations 
fail to complete with versioned notifications if payload contains unset 
non-nullable fields
This is also visible in tssurya's environment. I'm wondering if we can 
implement a nova-manage heal-instance-flavor command for these 
environment as I'm not sure I will be able to find the root cause why 
the disable field is missing from these flavors.


No update on other bugs and we have no new bugs tagged with 
notifications.



Features


Sending full traceback in versioned notifications
~
https://blueprints.launchpad.net/nova/+spec/add-full-traceback-to-error-notifications
We are iterating with Kevin on the implementation and sample test in 
https://review.openstack.org/#/c/564092/ .


Add notification support for trusted_certs
~~
This is part of the bp nova-validate-certificates implementation series
to extend some of the instance notifications.
I'm +2 on the notification impact in
https://review.openstack.org/#/c/563269 waiting for the rest of the
series to merge.

Introduce Pending VM state
~~
The spec https://review.openstack.org/#/c/554212 still not exactly 
define what will be in the select_destination notification payload.


Add the user id and project id of the user initiated the instance 
action to the notification


https://blueprints.launchpad.net/nova/+spec/add-action-initiator-to-instance-action-notifications
We are iterating on the implementation in 
https://review.openstack.org/#/c/536243



No progress:

* Versioned notification transformation
https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-rocky+status:open
* Introduce instance.lock and instance.unlock notifications
https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances


Blocked:

* Add versioned notifications for removing a member from a server group
https://blueprints.launchpad.net/nova/+spec/add-server-group-remove-member-notifications


Weekly meeting
--
We skip the meeting this week (week 24). The next meeting will be held 
on 19th of June on #openstack-meeting-4

https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180619T17

Cheers,
gibi


__
OpenStack Development Mailing 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] [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

Thanks for the comments.
I’ve updated the wiki: 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend

Br,
Gerg0

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Friday, June 8, 2018 1:46 PM
To: Csatari, Gergely (Nokia - HU/Budapest) ; 
OpenStack Development Mailing List (not for usage questions) 
; edge-comput...@lists.openstack.org
Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible 
architectures for image synchronisation

Responses in-lined below,
Greg.

From: "Csatari, Gergely (Nokia - HU/Budapest)" 
mailto:gergely.csat...@nokia.com>>
Date: Friday, June 8, 2018 at 3:39 AM
To: Greg Waines mailto:greg.wai...@windriver.com>>, 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>, 
"edge-comput...@lists.openstack.org" 
mailto:edge-comput...@lists.openstack.org>>
Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible 
architectures for image synchronisation

Hi,

Going inline.

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Thursday, June 7, 2018 2:24 PM

I had some additional questions/comments on the Image Synchronization Options ( 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment ):


One Glance with multiple backends

  *   In this scenario, are all Edge Clouds simply configured with the one 
central glance for its GLANCE ENDPOINT ?
 *   i.e. GLANCE is a typical shared service in a multi-region environment ?

[G0]: In my understanding yes.


  *   If so,
how does this OPTION support the requirement for Edge Cloud Operation when 
disconnected from Central Location ?

[G0]: This is an open question for me also.


Several Glances with an independent synchronization service(PUSH)

  *   I refer to this as the PUSH model
  *   I don’t believe you have to ( or necessarily should) rely on the backend 
to do the synchronization of the images
 *   i.e. the ‘Synch Service’ could do this strictly through Glance REST 
APIs
(making it independent of the particular Glance backend ... and allowing the 
Glance Backends at Central and Edge sites to actually be different)
[G0]: Okay, I can update the wiki to reflect this. Should we keep the 
“synchronization by the backend” option as an other alternative?
[Greg] Yeah we should keep it as an alternative.

  *   I think the ‘Synch Service’ MUST be able to support ‘selective/multicast’ 
distribution of Images from Central to Edge for Image Synchronization
 *   i.e. you don’t want Central Site pushing ALL images to ALL Edge Sites 
... especially for the small Edge Sites
[G0]: Yes, the question is how to define these synchronization policies.
[Greg] Agreed ... we’ve had some very high-level discussions with end users, 
but haven’t put together a proposal yet.

  *   Not sure ... but I didn’t think this was the model being used in mixmatch 
... thought mixmatch was more the PULL model (below)

[G0]: Yes, this is more or less my understanding. I remove the mixmatch 
reference from this chapter.

One Glance and multiple Glance API Servers   (PULL)

  *   I refer to this as the PULL model
  *   This is the current model supported in StarlingX’s Distributed Cloud 
sub-project
 *   We run glance-api on all Edge Clouds ... that talk to glance-registry 
on the Central Cloud, and
 *   We have glance-api setup for caching such that only the first access 
to an particular image incurs the latency of the image transfer from Central to 
Edge
[G0]: Do you do image caching in Glance API or do you rely in the image cache 
in Nova? In the Forum session there were some discussions about this and I 
think the conclusion was that using the image cache of Nova is enough.
[Greg] We enabled image caching in the Glance API.
 I believe that Nova Image Caching caches at the compute node ... 
this would work ok for all-in-one edge clouds or small edge clouds.
 But glance-api caching caches at the edge cloud level, so works 
better for large edge clouds with lots of compute nodes.

  *
  *   this PULL model affectively implements the location aware synchronization 
you talk about below,  (i.e. synchronise images only to those cloud instances 
where they are needed)?


In StarlingX Distributed Cloud,
We plan on supporting both the PUSH and PULL model ... suspect there are use 
cases for both.

[G0]: This means that you need an architecture supporting both.
Just for my curiosity what is the use case for the pull model once you have the 
push model in place?
[Greg] The PULL model certainly results in the most efficient distribution of 
images ... basically images are distributed ONLY to edge clouds that explicitly 
use the image.
Also if the use case is NOT concerned about incurring the latency of the image 
transfer from Central to Edge on the FIRST use 

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2018-06-11 16:00:41 +0200:
> Hi,
> 
> On 06/11/2018 03:53 PM, Ruby Loo wrote:
> > Hi,
> > 
> > I don't want to hijack the initial thread, but am now feeling somewhat 
> > guilty 
> > about not being vocal wrt Storyboard. Yes, ironic migrated to Storyboard in 
> > the 
> > beginning of this cycle. To date, I have not been pleased with replacing 
> > Launchpad with Storyboard. I believe that Storyboard is somewhat 
> > still-in-progress, and that there were/are some features (stories) that are 
> > outstanding that would make its use better.
> > 
> >  From my point of view (as a developer and core, not a project manager or 
> > PTL) 
> > using Storyboard has made my day-to-day work worse. Granted, any migration 
> > is 
> > without headaches. But some of the main things, like searching for our RFEs 
> > (that we had tagged in Launchpad) wasn't possible. I haven't yet figured 
> > out how 
> > to limit a search to only the 'ironic' project using that 'search' like 
> > GUI, so 
> > I have been frustrated trying to find particular bugs that I *knew* existed 
> > but 
> > had not memorized the bug number.
> 
> Yeah, I cannot fully understand the search. I would expect something explicit 
> like Launchpad or better something command-based like 
> "project:openstack/ironic 
> pxe". This does not seem to work, so I also wonder how to filter all stories 
> affecting a project.
> 

Searching tripped me up for the first couple of weeks, too.
Storyboard's search field is a lot "smarter" than expected. Or maybe
you'd call it "magic". Either way, it was confusing, but you don't have
to use any special syntax in the UI.

To search for a project, type the name of the project in the search
field and then *wait* for the list of drop-down options to appear.
The first item in the list will be a "raw" search for the term. The
others will have little icons indicating their type. The project
icon looks like a little cube, for example.  If I go to
https://storyboard.openstack.org/#!/search and type "openstack/ironic"
I get a list that includes openstack/ironic, openstack/ironic-inspector,
etc.

Select the project you want from the list and hit enter, and you'll
get a list of all of the stories with tasks attached to the project.

To search based on words in the title or body of the story or task,
just type those and then select the item with the magnifying glass
icon for the "raw" search.

It's not necessary to use search to get a list of open items, though.
You can also navigate directly to a project or group of projects.
For example, by clicking the "Project Groups" icon on the left you
end up at https://storyboard.openstack.org/#!/project_group/list
and by entering "ironic" in the search field there you'll see that
there are 23 projects in the ironic group (wow!). Clicking the name
of the project group will take you to a view showing the current
open items.

I strongly encourage teams to set up worklists or dashboards with
saved searches or manually curated lists of stories or tasks. For
example, the release team uses
https://storyboard.openstack.org/#!/board/64 to keep track of our work
within the cycle.

Doug

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

[openstack-dev] [keystone] Keystone Team Update - Week of 4 June 2018

[Lance Bragstad]

# Keystone Team Update - Week of 4 June 2018

## News

Sorry this didn't make it out last week.

This week we were busy wrapping up specification discussion before spec
freeze. Most of which revolved around unified limits [0]. We're also
starting to see implementations for MFA receipts [1] and application
credentials capability lists [2].

[0] https://review.openstack.org/#/c/540803/
[1] 
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:spec/auth_receipts
[2] 
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/whitelist-extension-for-app-creds

## Open Specs

Search query: https://bit.ly/2G8Ai5q

With the last few bits for hierarchical limits addressed and the
specification merged, we don't expect to accept any more specifications
for the Rocky release.

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 28 changes last week. Most of which were to move keystone off
its homegrown WSGI implementation. Converting to Flask is a pretty big
move for keystone and the team, but it reduces technical dept and will
help with maintenance costs in the future since it's one less wheel we
have to look after.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 50 changes that are passing CI, not in merge conflict, have no
negative reviews and aren't proposed by bots. Please take it look if you
have time to do a review or two.

## Bugs

This week we opened 7 new bugs, closed 5, and fixed 5.

Bugs opened (7)
Bug #1775094 (keystone:Medium) opened by Lance Bragstad
https://bugs.launchpad.net/keystone/+bug/1775094
Bug #1774654 (keystone:Undecided) opened by Wyllys Ingersoll
https://bugs.launchpad.net/keystone/+bug/1774654
Bug #1774688 (keystone:Undecided) opened by Lance Bragstad
https://bugs.launchpad.net/keystone/+bug/1774688
  

Bug #1775140 (keystone:Undecided) opened by Andras Kovi
https://bugs.launchpad.net/keystone/+bug/1775140
 

Bug #1775207 (keystone:Undecided) opened by Pavlo Shchelokovskyy
https://bugs.launchpad.net/keystone/+bug/1775207


Bug #1775295 (keystone:Undecided) opened by johnpham
https://bugs.launchpad.net/keystone/+bug/1775295


Bug #1774722 (oslo.config:Low) opened by Kent Wu
https://bugs.launchpad.net/oslo.config/+bug/1774722 




 

Bugs closed
(5) 

 

Bug #1578466 (keystone:Medium)
https://bugs.launchpad.net/keystone/+bug/1578466

  

Bug #1578401 (keystone:Low)
https://bugs.launchpad.net/keystone/+bug/1578401

 

Bug #1775140 (keystone:Undecided)
https://bugs.launchpad.net/keystone/+bug/1775140

   

Bug #1775295 (keystone:Undecided)
https://bugs.launchpad.net/keystone/+bug/1775295

   

Bug #1774722 (oslo.config:Low)
https://bugs.launchpad.net/oslo.config/+bug/1774722 

  



 

Bugs fixed
(5) 

  

Bug #1728907 (keystone:Low) fixed by Gage Hugo
https://bugs.launchpad.net/keystone/+bug/1728907

  

Bug #1673859 (oslo.policy:Undecided) 

Re: [openstack-dev] [kolla] cinder-api image doesn't run as a cinder user.

[Erlon Cruz]

Thanks!

Em seg, 11 de jun de 2018 às 11:07, Eduardo Gonzalez 
escreveu:

> Hi,
>
> See a global openstack goal to move into wsgi
> https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
> And spec for cinder
>
>
> https://review.openstack.org/#/c/192683/6/specs/liberty/non-eventlet-wsgi-app.rst
>
> Regards
>
> 2018-06-11 14:36 GMT+02:00 Erlon Cruz :
>
>> Hi Eduardo,
>>
>> Just for curiosity, do you know the motivation why many OS services were
>> moved to run on apache instead of just listen? Any reference about that?
>>
>> Erlon
>>
>> Em seg, 11 de jun de 2018 às 06:02, Eduardo Gonzalez 
>> escreveu:
>>
>>> Hi,
>>>
>>> From Pike cinder-api only runs as a wsgi process and container has been
>>> migrated into an apache process, currenty we run apache as root user and
>>> not as service's user.
>>>
>>> Regards
>>>
>>>
>>>
>>> 2018-06-11 10:46 GMT+02:00 Jae Sang Lee :
>>>
 Hi, stackers.

 We are distributing OpenStack to kubernetes using the docker image
 generated by kolla. I recently upgraded from ocata to pike and found
 that the cinder-api container does not run as a cinder user.
 So it does not pass our unit test.

 This seems to have been fixed in the following code,

 https://review.openstack.org/#/c/463535/2/docker/cinder/cinder-api/Dockerfile.j2,unified

 Is there a reason why it should not be run as a cinder user? Other
 services except cinder-api (cinder-scheduler, cinder-volume,
 cinder-backup) are all running as cinder user. If this is a simple bug, try
 to fix it.

 Thanks.

>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing 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] [kolla] cinder-api image doesn't run as a cinder user.

[Eduardo Gonzalez]

Hi,

See a global openstack goal to move into wsgi
https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
And spec for cinder

https://review.openstack.org/#/c/192683/6/specs/liberty/non-eventlet-wsgi-app.rst

Regards

2018-06-11 14:36 GMT+02:00 Erlon Cruz :

> Hi Eduardo,
>
> Just for curiosity, do you know the motivation why many OS services were
> moved to run on apache instead of just listen? Any reference about that?
>
> Erlon
>
> Em seg, 11 de jun de 2018 às 06:02, Eduardo Gonzalez 
> escreveu:
>
>> Hi,
>>
>> From Pike cinder-api only runs as a wsgi process and container has been
>> migrated into an apache process, currenty we run apache as root user and
>> not as service's user.
>>
>> Regards
>>
>>
>>
>> 2018-06-11 10:46 GMT+02:00 Jae Sang Lee :
>>
>>> Hi, stackers.
>>>
>>> We are distributing OpenStack to kubernetes using the docker image
>>> generated by kolla. I recently upgraded from ocata to pike and found
>>> that the cinder-api container does not run as a cinder user.
>>> So it does not pass our unit test.
>>>
>>> This seems to have been fixed in the following code,
>>> https://review.openstack.org/#/c/463535/2/docker/cinder/
>>> cinder-api/Dockerfile.j2,unified
>>>
>>> Is there a reason why it should not be run as a cinder user? Other
>>> services except cinder-api (cinder-scheduler, cinder-volume,
>>> cinder-backup) are all running as cinder user. If this is a simple bug, try
>>> to fix it.
>>>
>>> Thanks.
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing 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] use of storyboard (was [TC] Stein Goal Selection)

[Dmitry Tantsur]

Hi,

On 06/11/2018 03:53 PM, Ruby Loo wrote:

Hi,

I don't want to hijack the initial thread, but am now feeling somewhat guilty 
about not being vocal wrt Storyboard. Yes, ironic migrated to Storyboard in the 
beginning of this cycle. To date, I have not been pleased with replacing 
Launchpad with Storyboard. I believe that Storyboard is somewhat 
still-in-progress, and that there were/are some features (stories) that are 
outstanding that would make its use better.


 From my point of view (as a developer and core, not a project manager or PTL) 
using Storyboard has made my day-to-day work worse. Granted, any migration is 
without headaches. But some of the main things, like searching for our RFEs 
(that we had tagged in Launchpad) wasn't possible. I haven't yet figured out how 
to limit a search to only the 'ironic' project using that 'search' like GUI, so 
I have been frustrated trying to find particular bugs that I *knew* existed but 
had not memorized the bug number.


Yeah, I cannot fully understand the search. I would expect something explicit 
like Launchpad or better something command-based like "project:openstack/ironic 
pxe". This does not seem to work, so I also wonder how to filter all stories 
affecting a project.


Bonus point for giving stories names. They don't even have to be unique, but I 
have something like


 https://storyboard.openstack.org/#!/story/100500-some-readable-slug/

(where 100500 is an actual story ID) it would help my browser locate them in my 
history.




I haven't been as involved upstream this cycle, so perhaps I have missed other 
emails that have mentioned how to get around or do things with Storyboard. I 
would caution folks that are thinking about migrating; I wish we had delayed it 
until there was better support/features/stories implemented with Storyboard. At 
the time, I was also negligent about actually trying out Storyboard before we 
pushed the button (because I assumed it would be ok, others were using it, why 
wouldn't it suffice?) Perhaps Storyboard can address most of my issues now? 
Maybe updated documentation would help? (I believe the last time I tried to use 
Storyboard was 2 weeks ago, when I was 'search'ing for an old bug in Storyboard. 
I gave up.)


I apologize for not writing a detailed email with specific examples of what is 
lacking (for me) and in hindsight should have sent out email at the time I 
encountered issues/had questions. I guess I am hoping that others can 
fill-in-the-blanks and ask for things that would make Storyboard (more) usable.


No, I didn't watch any videos about using Storyboard, just like I've never 
watched any video about using Launchpad, Trello, jira, . I did try 
looking for documentation at some point though and I don't recall finding what I 
was looking for.


--ruby


On Thu, Jun 7, 2018 at 4:25 PM, Kendall Nelson > wrote:


Hello :)

I think that these two goals definitely fit the criteria we discussed in
Vancouver during the S Release Goal Forum Session. I know Storyboard
Migration was also mentioned after I had to dip out to another session so I
wanted to follow up on that.

I know it doesn't fit the shiny user facing docket that was discussed at the
Forum, but I do think its time we make migration official in some capacity
as a release goal or some other way. Having migrated Ironic and having
TripleO on the schedule for migration (as requested during the last goal
discussion) in addition to having migrated Heat, Barbican and several others
in the last few months we have reached the point that I think migration of
the rest of the projects is attainable by the end of Stein.

Thoughts?

-Kendall (diablo_rojo)



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




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

[openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

[Ruby Loo]

Hi,

I don't want to hijack the initial thread, but am now feeling somewhat
guilty about not being vocal wrt Storyboard. Yes, ironic migrated to
Storyboard in the beginning of this cycle. To date, I have not been pleased
with replacing Launchpad with Storyboard. I believe that Storyboard is
somewhat still-in-progress, and that there were/are some features (stories)
that are outstanding that would make its use better.

>From my point of view (as a developer and core, not a project manager or
PTL) using Storyboard has made my day-to-day work worse. Granted, any
migration is without headaches. But some of the main things, like searching
for our RFEs (that we had tagged in Launchpad) wasn't possible. I haven't
yet figured out how to limit a search to only the 'ironic' project using
that 'search' like GUI, so I have been frustrated trying to find particular
bugs that I *knew* existed but had not memorized the bug number.

I haven't been as involved upstream this cycle, so perhaps I have missed
other emails that have mentioned how to get around or do things with
Storyboard. I would caution folks that are thinking about migrating; I wish
we had delayed it until there was better support/features/stories
implemented with Storyboard. At the time, I was also negligent about
actually trying out Storyboard before we pushed the button (because I
assumed it would be ok, others were using it, why wouldn't it suffice?)
Perhaps Storyboard can address most of my issues now? Maybe updated
documentation would help? (I believe the last time I tried to use
Storyboard was 2 weeks ago, when I was 'search'ing for an old bug in
Storyboard. I gave up.)

I apologize for not writing a detailed email with specific examples of what
is lacking (for me) and in hindsight should have sent out email at the time
I encountered issues/had questions. I guess I am hoping that others can
fill-in-the-blanks and ask for things that would make Storyboard (more)
usable.

No, I didn't watch any videos about using Storyboard, just like I've never
watched any video about using Launchpad, Trello, jira, . I did
try looking for documentation at some point though and I don't recall
finding what I was looking for.

--ruby


On Thu, Jun 7, 2018 at 4:25 PM, Kendall Nelson 
wrote:

> Hello :)
>
> I think that these two goals definitely fit the criteria we discussed in
> Vancouver during the S Release Goal Forum Session. I know Storyboard
> Migration was also mentioned after I had to dip out to another session so I
> wanted to follow up on that.
>
> I know it doesn't fit the shiny user facing docket that was discussed at
> the Forum, but I do think its time we make migration official in some
> capacity as a release goal or some other way. Having migrated Ironic and
> having TripleO on the schedule for migration (as requested during the last
> goal discussion) in addition to having migrated Heat, Barbican and several
> others in the last few months we have reached the point that I think
> migration of the rest of the projects is attainable by the end of Stein.
>
> Thoughts?
>
> -Kendall (diablo_rojo)
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ovs] [neutron] openvswitch flows firewall driver

[Slawomir Kaplonski]

Hi,

I’m not sure about Queens but recently with [1] we switched default security 
group driver in devstack to „openvswitch”.
Since at least month we have scenario gate job with this SG driver running as 
voting and gating.
Currently, after switch devstack default driver to openvswitch it’s tested in 
many jobs in Neutron.

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

> Wiadomość napisana przez Tobias Urdin  w dniu 
> 11.06.2018, o godz. 05:20:
> 
> Hello everybody,
> I'm cross-posting this with operators list.
> 
> The openvswitch flows-based stateful firewall driver which uses the
> conntrack support in Linux kernel >= 4.3 (iirc) has been
> marked as experimental for several releases now, is there any
> information about flaws in this and why it should not be used in production?
> 
> It's still marked as experimental or missing documentation in the
> networking guide [1].
> 
> And to operators; is anybody running the OVS stateful firewall in
> production? (firewall_driver = openvswitch)
> 
> Appreciate any feedback :)
> Best regards
> 
> [1] https://docs.openstack.org/neutron/queens/admin/config-ovsfwdriver.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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


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

[openstack-dev] [neutron] neutron-lib 1.15.0 syntax error in LOG.debug

[Boden Russell]

The 1.15.0 release of neutron-lib contains a syntax error in a LOG debug
call that was fixed with [1].

We are working to release the fix with 1.16.0 [2].

If you are running into this error [3], it maybe necessary to exclude
neutron-lib 1.15.0 and pickup 1.16.0 once we get it released.

Feel free to reach out on #openstack-neutron if you have questions.

Thanks


[1] https://review.openstack.org/#/c/574068/
[2] https://review.openstack.org/#/c/573826/
[3]
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22from%20file%20runtime.py%2C%20line%2062%5C%22

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

Re: [openstack-dev] [all] [release] How to handle "stable" deliverables releases

[Chris Dent]

On Mon, 11 Jun 2018, Thierry Carrez wrote:


2/ Do not force releases, but still create branches from latest releases

In this variant we would not force an artificial re-release, but we would 
still create a branch from the last available release, in order to be able to 
land future patches and do bugfix or security releases as needed.


This one seems best because of:

creating 
the branches in advance means they are ready to be used when someone wants to 
backport something there, likely reducing process pain.


Really glad to see this happening. We need to make sure that we
don't accidentally make low-activity because mature and stable look
the same as low-activity because dead.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] nova API meeting schedule

[Chris Dent]

On Mon, 11 Jun 2018, Ghanshyam wrote:


2. If no member from USA/Europe TZ then, myself and Alex will
conduct the API meeting as office hour on Nova channel during our
day time (something between UTC+1 to  UTC + 9). There is not much
activity on Nova channel during our TZ so it will be ok to use
Nova channel.  In this case, we will release the current occupied
meeting channel.


I think this is the better option since it works well for the people
who are already actively interested. If that situation changes, you
can always do something different. And if you do some kind of
summary of anything important at the meeting (whenever the time)
then people who can't attend can be in the loop.

I was trying to attend the API meeting for a while (back when it was
happening) but had to cut it out as its impossible to pay attention
to everything and something had to give.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Reminder: UC Meeting Today 1400UTC / 0900CST

[Melvin Hillsman]

Hey everyone,

Please see https://wiki.openstack.org/wiki/Governance/Foundation/
UserCommittee for UC meeting info and add additional agenda items if needed.


-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] cinder-api image doesn't run as a cinder user.

[Erlon Cruz]

Hi Eduardo,

Just for curiosity, do you know the motivation why many OS services were
moved to run on apache instead of just listen? Any reference about that?

Erlon

Em seg, 11 de jun de 2018 às 06:02, Eduardo Gonzalez 
escreveu:

> Hi,
>
> From Pike cinder-api only runs as a wsgi process and container has been
> migrated into an apache process, currenty we run apache as root user and
> not as service's user.
>
> Regards
>
>
>
> 2018-06-11 10:46 GMT+02:00 Jae Sang Lee :
>
>> Hi, stackers.
>>
>> We are distributing OpenStack to kubernetes using the docker image
>> generated by kolla. I recently upgraded from ocata to pike and found
>> that the cinder-api container does not run as a cinder user.
>> So it does not pass our unit test.
>>
>> This seems to have been fixed in the following code,
>>
>> https://review.openstack.org/#/c/463535/2/docker/cinder/cinder-api/Dockerfile.j2,unified
>>
>> Is there a reason why it should not be run as a cinder user? Other
>> services except cinder-api (cinder-scheduler, cinder-volume,
>> cinder-backup) are all running as cinder user. If this is a simple bug, try
>> to fix it.
>>
>> Thanks.
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi, 

Going inline. 

-Original Message-
From: Erno Kuvaja [mailto:ekuv...@redhat.com] 
Sent: Friday, June 8, 2018 3:18 PM

Hi,

Answering inline.

Best,
Erno "jokke" Kuvaja

On Thu, Jun 7, 2018 at 11:49 AM, Csatari, Gergely (Nokia -
HU/Budapest)  wrote:
> Hi,
>
>
>
> I did some work ont he figures and realised, that I have some 
> questions related to the alternative options:
>
>
>
> Multiple backends option:
>
> What is the API between Glance and the Glance backends?
glance_store library
> How is it possible to implement location aware synchronisation 
> (synchronise images only to those cloud instances where they are needed)?
This needs bit of hooking. We need to update the locations into Glance once the 
replication has happened.
[G0]: Okay, but how to avoid the replication to sites where the image is not 
needed?

> Is it possible to have different OpenStack versions in the different 
> cloud instances?
In my understanding it's not supported to mix versions within OpenStack cloud 
apart from during upgrade.
[G0]: Understood. This might be a problem ont he long run. With lots of edge 
cloud instance it can not be guaranteed, that all of them are upgraded in one 
go. 

> Can a cloud instance use the locally synchronised images in case of a 
> network connection break?
That depends a lot of the implementation. If there is local glance node with 
replicated db and store, yes.
[G0]: So we need a replicated Glance DB, a store and a backend in every edge 
cloud instance for this?
How the database would be syncronised in this case?

> Is it possible to implement this without storing database credentials 
> ont he edge cloud instances?
Again depending of the deployment. You definitely cannot have both, access 
during network outage and access without db credentials. if one needs to have 
local access of images without db credentials, there is always possibility for 
the local Ceph back-end with remote glance-api node. In this case Nova can talk 
directly to the local Ceph back-end and communicate with centralized glance-api 
that has the credentials to the db. The problem with loosing the network in 
this scenario is that Nova will have no idea if the user has rights to use the 
image or not and it will not know the path to that image's data.
[G0]: Okay

> Independent synchronisation service:
>
> If I understood [1] correctly mixmatch can help Nova to attach a 
> remote volume, but it will not help in synchronizing the images. is this true?
>
> As I promised in the Edge Compute Group call I plan to organize an IRC 
> review meeting to check the wiki. Please indicate your availability in [2].
>
> [1]: https://mixmatch.readthedocs.io/en/latest/
>
> [2]: https://doodle.com/poll/bddg65vyh4qwxpk5
[G0]: Please add your availability here.

Thanks, 
Gerg0 

>
>
>
> Br,
>
> Gerg0
>
>
>
> From: Csatari, Gergely (Nokia - HU/Budapest)
> Sent: Wednesday, May 23, 2018 8:59 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> ; 
> edge-comput...@lists.openstack.org
> Subject: [edge][glance]: Wiki of the possible architectures for image 
> synchronisation
>
>
>
> Hi,
>
>
>
> Here I send the wiki page [1] where I summarize what I understood from 
> the Forum session about image synchronisation in edge environment [2], [3].
>
>
>
> Please check and correct/comment.
>
>
>
> Thanks,
>
> Gerg0
>
>
>
>
>
> [1]: 
> https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
>
> [2]: https://etherpad.openstack.org/p/yvr-edge-cloud-images
>
> [3]:
> https://www.openstack.org/summit/vancouver-2018/summit-schedule/events
> /21768/image-handling-in-an-edge-cloud-infrastructure
>
>
> ___
> Edge-computing mailing list
> edge-comput...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>
__
OpenStack Development Mailing 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] increasing the number of allowed volumes attached per instance > 26

[Sahid Orentino Ferdjaoui]

On Fri, Jun 08, 2018 at 11:35:45AM +0200, Kashyap Chamarthy wrote:
> On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote:
> > On 6/7/2018 12:56 PM, melanie witt wrote:
> > > Recently, we've received interest about increasing the maximum number of
> > > allowed volumes to attach to a single instance > 26. The limit of 26 is
> > > because of a historical limitation in libvirt (if I remember correctly)
> > > and is no longer limited at the libvirt level in the present day. So,
> > > we're looking at providing a way to attach more than 26 volumes to a
> > > single instance and we want your feedback.
> > 
> > The 26 volumes thing is a libvirt driver restriction.
> 
> The original limitation of 26 disks was because at that time there was
> no 'virtio-scsi'.  
> 
> (With 'virtio-scsi', each of its controller allows upto 256 targets, and
> each target can use any LUN (Logical Unit Number) from 0 to 16383
> (inclusive).  Therefore, the maxium allowable disks on a single
> 'virtio-scsi' controller is 256 * 16384 == 4194304.)  Source[1].

Not totally true for Nova. Nova handles one virtio-scsi controller per
guest and plug all the volumes in one target so in theory that would
be 16384 LUN (only).

But you made a good point the 26 volumes thing is not a libvirt driver
restriction. For example the QEMU SCSI native implementation handles
256 disks.

About the virtio-blk limitation I made the same finding but Tsuyoshi
Nagata shared an interesting point saying that virtio-blk is not longer
limited by the number of PCI slot available. That in recent kernel and
QEMU version [0].

I could join what you are suggesting at the bottom and fix the limit
to 256 disks.

[0] 
https://review.openstack.org/#/c/567472/16/nova/virt/libvirt/blockinfo.py@162

> [...]
> 
> > > Some ideas that have been discussed so far include:
> > > 
> > > A) Selecting a new, higher maximum that still yields reasonable
> > > performance on a single compute host (64 or 128, for example). Pros:
> > > helps prevent the potential for poor performance on a compute host from
> > > attaching too many volumes. Cons: doesn't let anyone opt-in to a higher
> > > maximum if their environment can handle it.
> 
> Option (A) can still be considered: We can limit it to 256 disks.  Why?
> 
> FWIW, I did some digging here:
> 
> The upstream libguestfs project after some thorough testing, arrived at
> a limit of 256 disks, and suggest the same for Nova.  And if anyone
> wants to increase that limit, the proposer should come up with a fully
> worked through test plan. :-) (Try doing any meaningful I/O to so many
> disks at once, and see how well that works out.)
> 
> What more, the libguestfs upstream tests 256 disks, and even _that_
> fails sometimes:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1478201 -- "kernel runs
> out of memory with 256 virtio-scsi disks"
> 
> The above bug is fixed now in kernel-4.17.0-0.rc3.git1.2. (And also
> required a corresponding fix in QEMU[2], which is available from version
> v2.11.0 onwards.)
> 
> [...]
> 
> 
> [1] https://lists.nongnu.org/archive/html/qemu-devel/2017-04/msg02823.html
> -- virtio-scsi limits
> [2] https://git.qemu.org/?p=qemu.git;a=commit;h=5c0919d 
> 
> -- 
> /kashyap
> 
> __
> OpenStack Development Mailing 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] [release] How to handle "stable" deliverables releases

[Thierry Carrez]

Hi everyone,

As some of the OpenStack deliverables get more mature, we need to adjust 
our release policies to best handle the case of deliverables that do not 
need to be updated that much. This discussion started with how to handle 
those "stable" libraries, but is actually also relevant for "stable" 
services.


Our current models include cycle-tied models (with-intermediary, 
with-milestones, trailing) and a purely cycle-independent model. Main 
OpenStack deliverables (the service components that you can deploy to 
build an OpenStack cloud) are all "released" on a cycle. Libraries are 
typically maintained per-cycle as well. What happens if no change is 
pushed to a service or library during a full cycle ? What should we do 
then ?


Options include:

1/ Force artificial releases, even if there are no changes

This is the current state. It allows to reuse the exact same process, 
but creates useless churn and version number confusion.


2/ Do not force releases, but still create branches from latest releases

In this variant we would not force an artificial re-release, but we 
would still create a branch from the last available release, in order to 
be able to land future patches and do bugfix or security releases as needed.


2bis/ Like 2, but only create the branch when needed

Same as the previous one, except that rather than proactively create the 
stable branch around release time, we'd wait until the branch is 
actually needed to create it.


3/ Do not force releases, and reuse stable branches from cycle to cycle

In this model, if there is no change in a library in Rocky, stable/rocky 
would never be created, and stable/queens would be used instead. Only 
one branch would get maintained for the 2 cycles. While this reduces the 
churn, it's a bit complex to wrap your head around the consequences, and 
measure how confusing this could be in practice...


4/ Stop worrying about stable branches at all for those "stable" things

The idea here would be to stop doing stable branches for those things 
that do not release that much anymore. This could be done by switching 
them to the "independent" release model, or to a newly-created model. 
While good for "finished" deliverables, this option could create issues 
for things that are inactive for a couple cycles and then pick up 
activity again -- switching back to being cycle-tied would likely be 
confusing.



My current preference is option 2.

It's a good trade-off which reduces churn while keeping a compatibility 
with the system used for more active components. Compared to 2bis, it's 
a bit more work (although done in one patch during the release process), 
but creating the branches in advance means they are ready to be used 
when someone wants to backport something there, likely reducing process 
pain.


One caveat with this model is that we need to be careful with version 
numbers. Imagine a library that did a 1.18.0 release for queens (which 
stable/queens is created from). Nothing happens in Rocky, so we create 
stable/rocky from the same 1.18.0 release. Same in Stein, so we create 
stable/stein from the same 1.18.0 release. During the Telluride[1] cycle 
some patches land and we want to release that. In order to leave room 
for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0, 
and go directly to 1.20.0. I think we can build release checks to ensure 
that, but that's something to keep in mind.


Thoughts ?

[1] It's never too early to campaign for your favorite T name

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [vitrage] update_timestamp precision

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Eric,

Apparently we have inconsistent behavior between the different datasources. The 
format of the timestamp should be '%Y-%m-%dT%H:%M:%SZ' as defined in [1]. We 
need to go over the code and make sure all datasources are aligned. I created a 
bug for it [2].

[1] 
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/transformer_base.py
[2] https://bugs.launchpad.net/vitrage/+bug/1776181
Best regards,
Ifat

-- Forwarded message -
From: Eric K mailto:ekcs.openst...@gmail.com>>
Date: Sat, 9 Jun 2018 at 00:20
Subject: [openstack-dev] [vitrage] update_timestamp precision
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>


Hi I'm building integration with Vitrage webhook and looking for some
clarification on the timestamp precision to expect.

In the sample webhook payload found in doc the resource and the alarm
shows different time stamp precisions:
https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plug
in.html


Thank you!



__
OpenStack Development Mailing 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] [kolla] cinder-api image doesn't run as a cinder user.

[Eduardo Gonzalez]

Hi,

>From Pike cinder-api only runs as a wsgi process and container has been
migrated into an apache process, currenty we run apache as root user and
not as service's user.

Regards



2018-06-11 10:46 GMT+02:00 Jae Sang Lee :

> Hi, stackers.
>
> We are distributing OpenStack to kubernetes using the docker image
> generated by kolla. I recently upgraded from ocata to pike and found that
> the cinder-api container does not run as a cinder user.
> So it does not pass our unit test.
>
> This seems to have been fixed in the following code,
> https://review.openstack.org/#/c/463535/2/docker/cinder/
> cinder-api/Dockerfile.j2,unified
>
> Is there a reason why it should not be run as a cinder user? Other services
>  except cinder-api (cinder-scheduler, cinder-volume, cinder-backup) are
> all running as cinder user. If this is a simple bug, try to fix it.
>
> Thanks.
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] cinder-api image doesn't run as a cinder user.

[Jae Sang Lee]

Hi, stackers.

We are distributing OpenStack to kubernetes using the docker image
generated by kolla. I recently upgraded from ocata to pike and found that
the cinder-api container does not run as a cinder user.
So it does not pass our unit test.

This seems to have been fixed in the following code,
https://review.openstack.org/#/c/463535/2/docker/cinder/cinder-api/Dockerfile.j2,unified

Is there a reason why it should not be run as a cinder user? Other services
except cinder-api (cinder-scheduler, cinder-volume, cinder-backup) are all
running as cinder user. If this is a simple bug, try to fix it.

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

Re: [openstack-dev] [vitrage] matching webhook vs alarm list

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Eric,

The format of the vitrage_id was changed to UUID in Pike release. It appears 
that the API documentation [1] is outdated. I’ll fix it.
The vitrage_id that you get in the webhook notification should match the one 
coming from ‘vitrage alarm list’. The ‘id’ field is determined by the external 
monitor, so it might be different.

Best Regards,
Ifat

-- Forwarded message -
From: Eric K mailto:ekcs.openst...@gmail.com>>
Date: Sat, 9 Jun 2018 at 01:40
Subject: [openstack-dev] [vitrage] matching webhook vs alarm list
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>


Hi I'm building integration with Vitrage webhook and looking for some
clarification on what ID to use for matching a webhook notification to
the specific alarm from the alarm list. In the sample alarm list
response, there is an 'id' field and a 'vitrage_id' field [1], where
as in the sample webhook notification payload, there is a 'vitrage_id'
field [2]. I'd assume we can match by the 'vitrage_id', but the
samples have very different formats for 'vitrage_id', so I just want
to confirm. Thank you!

[1] https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html#id22
[2]
{
  "notification": "vitrage.alarm.activate",
  "payload": {
"vitrage_id": "2def31e9-6d9f-4c16-b007-893caa806cd4",
"resource": {
  "vitrage_id": "437f1f4c-ccce-40a4-ac62-1c2f1fd9f6ac",
  "name": "app-1-server-1-jz6qvznkmnif",
  "update_timestamp": "2018-01-22 10:00:34.327142+00:00",
  "vitrage_category": "RESOURCE",
  "vitrage_operational_state": "OK",
  "vitrage_type": "nova.instance",
  "project_id": "8f007e5ba0944e84baa6f2a4f2b5d03a",
  "id": "9b7d93b9-94ec-41e1-9cec-f28d4f8d702c"
},
"update_timestamp": "2018-01-22T10:00:34Z",
"vitrage_category": "ALARM",
"state": "Active",
"vitrage_type": "vitrage",
"vitrage_operational_severity": "WARNING",
"name": "Instance memory performance degraded"
  }
}
https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plugin.html

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

Re: [openstack-dev] [nova] nova API meeting schedule

[Zhenyu Zheng]

Glad to hear that the API meeting is happening again, I would also love to
join.

On Mon, Jun 11, 2018 at 10:49 AM Ghanshyam  wrote:

> Hi All,
>
> As you might know, we used to have Nova API subteam meeting on Wed [1] but
> we did not continue that this year due to unavailability of members.
>
> As per discussion with melanie , we would like to continue the API meeting
> either on meeting channel (openstack-meeting-4) or as office hour on Nova
> channel. We have 2 options for that:
>
> 1. If there are members from USA/Europe TZ would like to join API meeting
> regularly then, we will continue the meeting on meeting channel with more
> suitable time considering Asia TZ also. I will initiate the doodle vote to
> select the time suitable for all interested members.
>
> 2. If no member from USA/Europe TZ then, myself and Alex will conduct the
> API meeting as office hour on Nova channel during our day time (something
> between UTC+1 to  UTC + 9). There is not much activity on Nova channel
> during our TZ so it will be ok to use Nova channel.  In this case, we will
> release the current occupied meeting channel.
>
> Please let us know who all would like to join API meeting so that we can
> pursue accordingly.
>
> [1] https://wiki.openstack.org/wiki/Meetings/NovaAPI
>
> -Nova API Subteam
>
>
>
>
>
> __
> OpenStack Development Mailing 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