date:20170803

On Thu, Aug 03, 2017 at 11:10:49AM -0400, Doug Hellmann wrote:
> Excerpts from Tony Breeds's message of 2017-08-03 12:20:24 +1000:
> > On Thu, Jul 27, 2017 at 07:05:16PM -0400, Doug Hellmann wrote:
> >  
> > > That content will now live in the project trees. Perhaps part of marking
> > > branches in those repos EOL needs to include deleting the install tree
> > > from the docs? Now that the docs are in a standard location, that could
> > > be part of an EOL script (although it means 2 phases, since we have to
> > > land the patch and let the docs rebuild before we remove the branch).
> > 
> > That can be done.  It's a bit of a pain but for the most part the gate
> > is pretty stable at EOL time.  I do worry about what we do if $projects
> > gate is broken and can't generate/publish the docs.
> >  
> > > We could also update the openstack-manuals tree to not publish links
> > > to the install guides (either removing the page or replacing it
> > > with a placeholder that explains they should be trying to use a
> > > newer version).
> > 
> > That'd work too.  I kinda like that option better.
> 
> Yes, that's easy to do with 1 patch to the openstack-manuals repo.

We can work that into the EOL process if everyone is okay with
that approach.

Yours Tony.


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

Re: [openstack-dev] Tracing (all the places)

2017-08-03 Thread Joshua Harlow


vin...@vn.fujitsu.com wrote:

Hello harlowja,

I'm really happy to see that you are back in this `tracing` topic [and 
@boris-42 (too)].


We never left, haha, but ya, I can say (and probably boris would agree) 
that trying to get OSprofiler started and integrated somewhat 'burned' 
both of us (it involved a ton of convincing people of the value of it, 
when I had more hoped that the value of it was obvious). But I'm glad 
that people are starting to realize its value (even if they have to be 
told and educated by google or other companies that have been doing this 
for a long time).




Last week, we saw that Rajul proposed 02 new blueprint in OSprofiler [1] and 
[2].
Besides, some other blueprints are being implemented in OSprofiler
such as overhead control [3] and OpenTracing compatible [4] [5]
(Uber Jaeger [6] is one of OpenTracing compatible tracer out there).

For OpenTracing part, I have a PoC to make OSprofiler compatible with
OpenTracing specification at [5]. You can take a look at it this time too.
However, this time, I focus on reporting span/trace to other destinations
(rather than current drivers for OSprofiler[7]).

OpenTracing API is changing a little bit fast for now, therefore, some APIs 
will be deprecated soon.
I had some discussions with OpenTracing community about some trouble when 
making OSprofiler
compatible with OpenTracing API.


Ya I expected this, opentracing also I think has a python 
client/wrapper(?), have you looked at what this offers (last time I 
checked most of opentracing was just a bunch of wrappers actually, and 
not much actually code that did anything unique)?




For OpenStack part, last cycle, Performance team and other OpenStack developers 
added
OSprofiler support for many other projects (Nova, Magnum, Ironic, Zun ...)
and Panko, Aodh, Swift are on the way.


Yippe, now the bigger questions is where are all the UIs visualizing the 
traces (I know boris had https://boris-42.github.io/ngk.html but there 
has to be something nicer that perhaps the OpenTracing community has for 
a UI, ideally not a java monster like Zipkin, ha). Any thoughts there?




At last, hope you will join us (again) in OpenStack `tracing` things.


We shall see :-P



[1] 
https://blueprints.launchpad.net/osprofiler/+spec/asynchronous-trace-collection
[2] 
https://blueprints.launchpad.net/osprofiler/+spec/tail-based-coherent-sampling
[3] 
https://blueprints.launchpad.net/osprofiler/+spec/osprofiler-overhead-control
[4] https://blueprints.launchpad.net/osprofiler/+spec/opentracing-compatible
[5] https://review.openstack.org/#/c/480018/
[6] http://jaeger.readthedocs.io/en/latest/architecture/
[7] https://github.com/openstack/osprofiler/tree/master/osprofiler/drivers

Best regards,

Vinh Nguyen Trong
PODC – Fujitsu Vietnam Ltd.


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

Re: [openstack-dev] [neutron] - FFE for neutron-fwaas v2 requested

2017-08-03 Thread Akihiro Motoki

2017-08-04 12:05 GMT+09:00 Furukawa, Yushiro :
> Hi PTL/all,
>
> So sorry for late request.  As I discussed in driver's meeting, I would like 
> to
> request an exception for 'Firewall as a Service v2' (neutron-fwaas) and
> 'FWaaS v2 dashboard' (neutron-fwaas-dashboard) for Pike.  Following patches 
> are
> ready for review.
>
> SPEC:
>   
>
> [neutron-fwaas]
>  -  - L2 agent extension for fwaas v2
>  -  - OVSFW driver for fwaas v2
>  -  - Default firewall group for 
> fwaas v2
>  -  - Configurable default fwg
>
> [neutron-fwaas-dashboard]
>  -  - FWaaS V2 Horizon Dashboard

One thing to note on fwaas dashboard.
neutron-fwaas-dashboard adopts the cycle-with-intermediary release
model for Pike release
as it was split out late in the Pike cycle, so precisely speaking
there is no FFE and
the final deadline is around R-1 week (Aug 21) [1].
(Note that we will cut a release earlier, so it is nice to try to
follow neutron milestone of course)

[1] https://releases.openstack.org/pike/schedule.html

>
> Best regards,
> --
> Yushiro FURUKAWA
>
>
> __
> OpenStack Development Mailing 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] VMWare Type Snapshot for Openstack 4.3

2017-08-03 Thread Matt Riedemann


On 8/3/2017 3:16 PM, Tom Kennedy wrote:
I see that this is implemented in 
nova(nova/api/openstack/compute/contrib/server_snapshot.py) , but is not 
available in Horizon.


I think you're looking at some forked code because that doesn't exist in 
upstream Nova:


https://github.com/openstack/nova/tree/master/nova/api/openstack/compute

I seem to remember a team in China at IBM working on VMware snapshots 
years ago, or something like this, for a product, so maybe you stumbled 
upon that.


--

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] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

On Thu, Aug 03, 2017 at 11:39:47AM +, witold.be...@est.fujitsu.com wrote:
> Hello everyone,
> 
> I would like to ask for the FFE for python-monascaclient version in global 
> requirements.
> 
> The current version in Pike (1.7.0) is not fully backward compatible. The 
> monasca exception classes were replaced with keystoneauth exceptions, which 
> affects heat and watcher projects if they use current upper constraints. The 
> fixes for these projects have been submitted [1, 2].
> 
> Also, monasca projects (monasca-agent, monasca-ui, monasca-api) rely on 
> python-monascaclient 1.7.0 and don't work with older versions.
> 
> The change for bumping the minimum version of python-monascaclient is here:
> 
> https://review.openstack.org/489173

Okay I said on that review that I was confused and wasn't ready to grant
an FFE.  In trying to "articulate my confusion"  I worked out why I was
confused #winning \o/

So for me it boils down to the affected projects:

Package  : python-monascaclient [python-monascaclient>=1.1.0] (used
by 4 projects)
Also affects : 4 projects
openstack/congress[]
openstack/heat[tc:approved-release]
openstack/monasca-ui  []
openstack/watcher []

Congres, and heat have said they're eaither not affected or are willing
to accept the impacts.  That leaves watcher.

But each of them is using constraints and the gates are passing, so the
overall risk/impact seems much lower to me that I estimated yesterday.

I think I just talked myself round.

Yours Tony.


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

[openstack-dev] [neutron] - FFE for neutron-fwaas v2 requested

2017-08-03 Thread Furukawa, Yushiro

Hi PTL/all,

So sorry for late request.  As I discussed in driver's meeting, I would like to
request an exception for 'Firewall as a Service v2' (neutron-fwaas) and
'FWaaS v2 dashboard' (neutron-fwaas-dashboard) for Pike.  Following patches are
ready for review.

SPEC:
  

[neutron-fwaas]
 -  - L2 agent extension for fwaas v2
 -  - OVSFW driver for fwaas v2
 -  - Default firewall group for fwaas 
v2
 -  - Configurable default fwg

[neutron-fwaas-dashboard]
 -  - FWaaS V2 Horizon Dashboard

Best regards,
--
Yushiro FURUKAWA


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

Re: [openstack-dev] [watcher] nominate Aditi Sharma to Watcher Core group

2017-08-03 Thread yumeng bao

+1
Good job Aditi! Let's keep it up__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Tacker] remove Sripriya Seetharam from core reviewer team

2017-08-03 Thread gongys2017


Hi,   First,  thank Sripriya Seetharam for her great contribution to Tacker 
project. Howeverfor a long time, she cannot be reached via registered email and 
does not join the projectmeeting and has no review activities.
  So I propose to remove Sripriya from tacker core reviewer team. And also hope 
she cancome back to join the project. If she can keep active contribution, the 
team will considerher core reviewer membership again.
Tacker cores, please respond with your opinion. If no reason is given to do
otherwise, I will remove Sripriya from Tacker core group in one week.
Thank Sripriya again.
Yong sheng gong
Tacker PTL
__
OpenStack Development Mailing 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] [tricircle]pike-3 released

2017-08-03 Thread joehuang

Hello,

Tricircle 3.4.0 (pike-3) released[1], it's time to do regression test and fix 
bugs, next milestone is pike-rc.

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

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

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

2017-08-03 Thread vin...@vn.fujitsu.com

Hi Rajul,

For the `agent idea`, I think it is very good.
However, in OpenStack, that idea may be really hard for us.
The reason is the same with what Boris think.

For the sampling part, head-based sampling can be implemented in OSprofiler.
For tail-based and adaptive sampling, it is another story.
However, in naïve way, we can use sampling abilities from other OpenTracing 
compatible tracers
such as Uber Jaeger, Appdash, Zipkin (has an open pull request), LighStep … by 
making OSprofiler
compatible with OpenTracing API.

ICYMI, Boris is father of OSprofiler in OpenStack [1]

[1] 
https://specs.openstack.org/openstack/oslo-specs/specs/mitaka/osprofiler-cross-service-project-profiling.html

Best regards,

Vinh Nguyen Trong
PODC – Fujitsu Vietnam Ltd.

From: Rajul Kumar [mailto:kumar.r...@husky.neu.edu]
Sent: Friday, 04 August, 2017 03:49
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling 
in OSProfiler

Hi Boris

That is a point of concern.
Can you please direct to any of those?

Anyways, we don't have anything in place for OpenStack yet.
Now, either we pick another tracing solution like Zipkin, Jaeger etc. which 
have their own limitations OR enhance OSProfiler.
We pick the later as it's most native and better coupled with OpenStack as of 
now.
I understand that we may be blocked by these issues. However, I feel it'll be 
better to fight with OSProfiler than anything else till we come up with 
something better :)

Thanks
Rajul



On Thu, Aug 3, 2017 at 4:01 PM, Boris Pavlovic 
mailto:bo...@pavlovic.me>> wrote:
Rajul,

May I ask why you think so?

Exposed by OSprofiler issues are going to be really hard to fix in current 
OpenStack architecture.

Best regards,
Boris Pavlovic

On Thu, Aug 3, 2017 at 12:56 PM, Rajul Kumar 
mailto:kumar.r...@husky.neu.edu>> wrote:
Hi Boris

Good to hear from you.
May I ask why you think so?

We do see some potential with OSProfiler for this and further objectives.

Thanks
Rajul

On Thu, Aug 3, 2017 at 3:48 PM, Boris Pavlovic 
mailto:bo...@pavlovic.me>> wrote:
Rajul,

It makes sense! However, maybe it's a bit too late... ;)

Best regards,
Boris Pavlovic

On Thu, Aug 3, 2017 at 12:16 PM, Rajul Kumar 
mailto:kumar.r...@husky.neu.edu>> wrote:
Hello everyone

I have added a blueprint on having tail-based sampling as a sampling option for 
continuous tracing in OSProfiler. It would be really helpful to have some 
thoughts, ideas, comments on this from the community.

Continuous tracing provides a good insight on how various transactions behave 
across in a distributed system. Currently, OpenStack doesn't have a defined 
solution for continuous tracing. Though, it has OSProfiler that does generates 
selective traces, it may not capture the occurrence. Even if we have OSProfiler 
running continuously [1], we need to sample the traces so as to cut down the 
data generated and still keep the useful info.

Head based sampling can be applied that decides initially whether a trace 
should be saved or not. However, it may miss out on some useful traces. I 
propose to have tail-based sampling [2] mechanism that makes the decision at 
the end of the transaction and tends to keep all the useful traces. This may 
require a lot of changes depending on what all type of info is required and the 
solution that we pick to implement it [2]. This may not affect the current 
working of any of the services on OpenStack as it will be off the critical path 
[3].

Please share your thoughts on this and what solution should be preferred in a 
broader OpenStack's perspective.
This is a step in the process of having an automated diagnostic solution for 
OpenStack cluster.

[1] 
https://blueprints.launchpad.net/osprofiler/+spec/osprofiler-overhead-control
[2] 
https://blueprints.launchpad.net/osprofiler/+spec/tail-based-coherent-sampling
[3] 
https://blueprints.launchpad.net/osprofiler/+spec/asynchronous-trace-collection

Thanks
Rajul Kumar


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

Re: [openstack-dev] [release] Release countdown for week R-3, Aug 4 - Aug 11

On Thu, Aug 03, 2017 at 09:07:54AM -0400, Doug Hellmann wrote:
> Excerpts from Thierry Carrez's message of 2017-08-03 15:03:59 +0200:
> 
> > Actions
> > ---
> > 
> > Deliverables following the cycle-with-milestones model should post a RC1
> > openstack/releases request during the week (X.0.0.0rc1), together with a
> > stable/pike branch request. It should include something like this:
> > 
> > ...
> >   - projects:
> >   - hash: YOURHASH
> > repo: openstack/YOURPROJECT
> > version: YOURVERSION.0.0.0rc1
> > branches:
> >   - location: YOURVERSION.0.0.0rc1
> > name: stable/pike
> > 
> > Deliverables following the cycle-with-intermediary model should also
> > create their Pike release branch next week. That means potentially
> > making a last Pike release, and in all cases posting the stable/pike
> > branch creation request:
> > 
> > ...
> > branches:
> >   - location: YOUR.PIKE.VERSION
> > name: stable/pike
> 
> It would be really REALLY good for project teams to finish landing the
> doc-migration patches before branching. Otherwise, you will have to
> backport all of the doc changes to the stable branch in order for them
> to show up in the Pike documentation.

It's very important that any requirements updates have been merged
before tagging the branch.  It isn't impossible to do it later but it's
just extra work.

We're still processing some late release/requirements FFEs to I'd expect
the bot to generate one or two this weekend / early next week.

https://review.openstack.org/#/q/is:open+branch:master+owner:proposal-bot+topic:openstack/requirements

Is scary long :(

Yours Tony.


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

Re: [openstack-dev] [release][requirements][barbican][octavia][LBaaS][heat] FFE Request for python-barbicanclient library

On Thu, Aug 03, 2017 at 04:26:12PM +, Dave McCowan (dmccowan) wrote:
> 
> 
> On 8/1/17, 8:02 PM, "Tony Breeds"  wrote:
> 
> >On Tue, Aug 01, 2017 at 04:58:22PM -0400, Doug Hellmann wrote:
> >> Excerpts from Dave McCowan (dmccowan)'s message of 2017-08-01 20:48:12
> >>+:
> >> > This note is to request a Feature Freeze Exemption (FFE) for the
> >>python-barbicanclient library in Pike.
> >> > 
> >> > Python-barbicanclient 4.5.0 was intended to be the Pike release.
> >>However, after it was released, testing with the Heat and Octavia
> >>projects found that it contained an incompatible change resulting in
> >>Tracebacks for those projects.
> >> > 
> >> > The issue was reported in this bug.
> >> > https://bugs.launchpad.net/python-barbicanclient/+bug/1706841
> >> > 
> >> > A first, and partial, attempt to fix this was merged in this patch.
> >> > https://review.openstack.org/487721
> >> > This patch is included in release 4.5.1.
> >> > 
> >> > A second, and successful, fix was merged in this patch.
> >> > https://review.openstack.org/489518
> >> > This patch is included in release 4.5.2.
> >> > 
> >> > The Barbican team requests a feature freeze exemption for
> >>python-barbicanclient release 4.5.2 to be the release for Pike.
> >>Releases 4.5.0 and 4.5.1 should be blocked in global requirements.
> >> > 
> >> > Thanks,
> >> > Dave
> >> > IRC:dave-mccowan
> >> 
> >> This sounds reasonable. It's a critical problem but only affects a small
> >> number of projects, so the risk is fairly small.
> >
> >The current users of python-barbicanclient are:
> >Package  : python-barbicanclient
> >[python-barbicanclient!=4.5.0,>=4.0.0] (used by 16 projects)
> >Also affects : 16 projects
> >openstack/castellan   []
> >openstack/cinder  [tc:approved-release]
> >openstack/compute-hyperv  []
> >openstack/heat[tc:approved-release]
> >openstack/kolla   []
> >openstack/magnum  []
> >openstack/mistral []
> >openstack/neutron-lbaas   []
> >openstack/neutron-lbaas-dashboard []
> >openstack/nova[tc:approved-release]
> >openstack/octavia []
> >openstack/octavia-dashboard   []
> >openstack/openstackclient []
> >openstack/python-openstackclient  []
> >openstack/solum   []
> >openstack/tacker  []
> >
> >But IIUC it's really only octavia and heat that don't work with 4.5.x
> >
> >Looking at the change logs:
> >
> >[tony@thor python-barbicanclient]$ git log --decorate --oneline
> >--no-merges 4.4.0^..HEAD
> >714fce2 (HEAD -> master, origin/master, origin/HEAD, gerrit/master)
> >Support import modules from barbicanclient.client module
> >49505b9 (tag: 4.5.1) Workaround for importing objects from old path
> >ea509a5 Update api references according to refactor result
> >e0e3703 Add secret_type filter to CLI
> >f844a0e Updated from global requirements
> >a95c1a1 Update the documentation link for doc migration
> >51d8bfa Updated from global requirements
> >c497189 fix default version
> >3c7d909 Updated from global requirements
> >e599dfd Update doc references
> >2479529 import content from cli-reference in openstack-manuals
> >9af9169 rearrange the existing docs into the new standard layout
> >4eed5c8 Switch from oslosphinx to openstackdocstheme
> >439ee25 (tag: 4.4.0) Updated from global requirements
> >97906c8 Refactor barbicanclient
> >
> >So all the changes look okay to me, assuming the 4.5.1 and 4.5.2 patches
> >work.
> >
> >> I assume you've done enough testing to feel comfortable that 4.5.2 will
> >> work better than 4.5.0 and 4.5.1?
> >
> >Once we have the release I'll create no-op changes in all the affected
> >projects that depend on the u-c bump.
> >
> >What concerns me a little is that we can't test this without a release
> >and once we do the release we're committed to some form of g-r
> >alteration with the impacts associated with it.
> >
> >Would it be terrible to branch stable/pike @ 4.4.0 and leav all the
> >4.5.x stuff for queens?
> 
> I'm feeling good with the testing now done on 4.5.2 and would prefer to
> make that the Pike release.  If we were to revert to 4.4.0 for Pike, we
> would be missing at least one feature and the doc changes that were
> planned for Pike.

Not revert, stick with.  We're still using 4.4.0 on master and pike as
all the 4.5.x releases have been broken.

The docs changes could easily be backported to pike with close to zero
risk without a release needed before pike is released it can easily be
done as a zero-day release.

This is all a little moot as 4.5.2 is out and we're testing it.  The
projects in the first will have a g-r update coming before they can
create RC1 and pike branches.

Yours Tony.


signature.asc
Desc

Re: [openstack-dev] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

2017-08-03 Thread Rico Lin

Bumping min version to 1.7.0 would not be a problem for Heat.
There might be a few minutes breaking (to merge
https://review.openstack.org/#/c/490016) but won't affect much.

2017-08-04 2:20 GMT+08:00 Eric K :

> As far as I can tell, bumping min version to 1.7.0 would not be a problem
> for Congress.
>
> Eric Kao
>
> On 8/3/17, 4:39 AM, "witold.be...@est.fujitsu.com"
>  wrote:
>
> >Hello everyone,
> >
> >I would like to ask for the FFE for python-monascaclient version in
> >global requirements.
> >
> >The current version in Pike (1.7.0) is not fully backward compatible. The
> >monasca exception classes were replaced with keystoneauth exceptions,
> >which affects heat and watcher projects if they use current upper
> >constraints. The fixes for these projects have been submitted [1, 2].
> >
> >Also, monasca projects (monasca-agent, monasca-ui, monasca-api) rely on
> >python-monascaclient 1.7.0 and don't work with older versions.
> >
> >The change for bumping the minimum version of python-monascaclient is
> >here:
> >
> >https://review.openstack.org/489173
> >
> >
> >Best greetings
> >Witek Bedyk
> >
> >
> >[1] https://review.openstack.org/490016
> >[2] https://review.openstack.org/490018
> >
> >___
> ___
> >OpenStack Development Mailing 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
>



-- 
May The Force of OpenStack Be With You,

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

Re: [openstack-dev] Tracing (all the places)

2017-08-03 Thread vin...@vn.fujitsu.com

Hello harlowja,

I'm really happy to see that you are back in this `tracing` topic [and 
@boris-42 (too)].

Last week, we saw that Rajul proposed 02 new blueprint in OSprofiler [1] and 
[2].
Besides, some other blueprints are being implemented in OSprofiler
such as overhead control [3] and OpenTracing compatible [4] [5]
(Uber Jaeger [6] is one of OpenTracing compatible tracer out there).

For OpenTracing part, I have a PoC to make OSprofiler compatible with
OpenTracing specification at [5]. You can take a look at it this time too.
However, this time, I focus on reporting span/trace to other destinations
(rather than current drivers for OSprofiler[7]).

OpenTracing API is changing a little bit fast for now, therefore, some APIs 
will be deprecated soon.
I had some discussions with OpenTracing community about some trouble when 
making OSprofiler
compatible with OpenTracing API.

For OpenStack part, last cycle, Performance team and other OpenStack developers 
added
OSprofiler support for many other projects (Nova, Magnum, Ironic, Zun ...)
and Panko, Aodh, Swift are on the way.

At last, hope you will join us (again) in OpenStack `tracing` things.

[1] 
https://blueprints.launchpad.net/osprofiler/+spec/asynchronous-trace-collection
[2] 
https://blueprints.launchpad.net/osprofiler/+spec/tail-based-coherent-sampling
[3] 
https://blueprints.launchpad.net/osprofiler/+spec/osprofiler-overhead-control
[4] https://blueprints.launchpad.net/osprofiler/+spec/opentracing-compatible
[5] https://review.openstack.org/#/c/480018/
[6] http://jaeger.readthedocs.io/en/latest/architecture/
[7] https://github.com/openstack/osprofiler/tree/master/osprofiler/drivers

Best regards,

Vinh Nguyen Trong
PODC – Fujitsu Vietnam Ltd. 

> -Original Message-
> From: Joshua Harlow [mailto:harlo...@fastmail.com]
> Sent: Friday, 04 August, 2017 02:52
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: [openstack-dev] Tracing (all the places)
> 
> Since I think there was another thread out there around tracing I'd
> thought I'd send out a few others for folks that show tracing being
> added to multiple other popular project (interesting to read over the
> proposals and such).
> 
> -
> https://github.com/grpc/grpc/blob/master/src/core/ext/census/README.md#census---a-
> resource-measurement-and-tracing-system
> 
> - https://github.com/kubernetes/kubernetes/issues/26507 (k8s tracing
> addition/proposal)
> 
> - http://jaeger.readthedocs.io/en/latest/architecture/
> 
> It'd be real nice to finally get some kind of tracing support integrated
> into openstack; osprofiler was started a long time ago and I think it's
> due time for it to actually be used and integrated :)
> 
> -Josh
> 
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ffe][release][requirements][tripleo] FFE for python-paunch-1.5.0

On Fri, Aug 04, 2017 at 11:41:21AM +1200, Steve Baker wrote:
> Adding a subject ^^
> 
> On Fri, Aug 4, 2017 at 11:21 AM, Emilien Macchi  wrote:
> 
> > On Thu, Aug 3, 2017 at 4:05 PM, Steve Baker  wrote:
> > > I would like to request a Feature Freeze Exemption (FFE) for the upper
> > > constraints of the python-paunch library/tool in Pike.
> > >
> > > https://review.openstack.org/#/c/490287/
> > >
> > > TripleO recently switched from using paunch as a library via heat-agents
> > to
> > > using the paunch CLI tool directly using ansible. This lead to a high
> > impact
> > > regression bug [1] where failed operations don't raise an error, fixed by
> > > [2]. This leads to false positives in TripleO CI, and later deployment
> > > failures which are more difficult to debug.
> > >
> > > Release 1.5.0 contains a fix for this. It also contains the new "paunch
> > > debug" command[3] which makes developing and debugging containers in
> > TripleO
> > > much easier. This feature has a low risk of causing regressions in
> > paunch's
> > > core function and is also desirable for the Pike release.
> >
> > +1 from me.
> >
> > > [1] https://bugs.launchpad.net/paunch/+bug/1707997
> > > [2] https://review.openstack.org/#/c/489722/
> > > [3] https://review.openstack.org/#/c/476654/

So the only user in OpenStack is heat-agents and that isn't affected by
the cli bug that has been fixed because it uses it as a library.  As
such we don't need a global-requirements bump (and re-release of
heat-agents)

heat-agents doesn't use constraints so it's already using 1.5.0.

So the upper-constraints bump is a no-op for OpenStack hosted projects.

With that in mind it's a very low risk operation to grant the FFE.

The only reason we want this in u-c is because RDO uses u-c and until
this lands there it's broken?

Yours Tony.


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

Re: [openstack-dev] [watcher] nominate Aditi Sharma to Watcher Core group

2017-08-03 Thread Hidekazu Nakamura

+1

> -Original Message-
> From: Чадин Александр (Alexander Chadin)
> [mailto:a.cha...@servionica.ru]
> Sent: Wednesday, August 02, 2017 9:48 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [watcher] nominate Aditi Sharma to Watcher Core
> group
> 
> Aditi Sharma (adisky in IRC) has been working on OpenStack Watcher since
> this March
> and has done some valuable patches[1] along with Action Plan cancelling
> blueprint (spec and
> implementation have been merged).
> I’d like to nominate Aditi Sharma to Watcher Core group and waiting for
> your vote.
> Please, give +1/-1 in reply to this message.
> 
> [1] :
> https://review.openstack.org/#/q/owner:%22aditi+sharma+%253Caditi.s%25
> 40nectechnologies.in%253E%22
> 
> Best Regards,
> __
> Alexander Chadin

__
OpenStack Development Mailing 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] [ffe][release][requirements][tripleo] FFE for python-paunch-1.5.0

2017-08-03 Thread Steve Baker

Adding a subject ^^

On Fri, Aug 4, 2017 at 11:21 AM, Emilien Macchi  wrote:

> On Thu, Aug 3, 2017 at 4:05 PM, Steve Baker  wrote:
> > I would like to request a Feature Freeze Exemption (FFE) for the upper
> > constraints of the python-paunch library/tool in Pike.
> >
> > https://review.openstack.org/#/c/490287/
> >
> > TripleO recently switched from using paunch as a library via heat-agents
> to
> > using the paunch CLI tool directly using ansible. This lead to a high
> impact
> > regression bug [1] where failed operations don't raise an error, fixed by
> > [2]. This leads to false positives in TripleO CI, and later deployment
> > failures which are more difficult to debug.
> >
> > Release 1.5.0 contains a fix for this. It also contains the new "paunch
> > debug" command[3] which makes developing and debugging containers in
> TripleO
> > much easier. This feature has a low risk of causing regressions in
> paunch's
> > core function and is also desirable for the Pike release.
>
> +1 from me.
>
> > [1] https://bugs.launchpad.net/paunch/+bug/1707997
> > [2] https://review.openstack.org/#/c/489722/
> > [3] https://review.openstack.org/#/c/476654/
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> 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 Development Mailing List (not for 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][ptl][stable][release] stable/pike branches created for most libraries

On Thu, Aug 03, 2017 at 07:22:15PM -0400, Doug Hellmann wrote:

> OK, I see. I was assuming we would just tie it to series name, and
> that series name could be taken from the .gitreview file or something.
> So the URL calculation would always be done locally, and we wouldn't
> need any sort of redirects.

If that works then so much better.  I thought we couldn't use that as
.gitreview isn't part of an sdist but then again neither is tox.ini and
at the point we're dealing with an sdist then the admin/user/installer
will have had to pass the constraints URL (or not) so it isn't our
problem.

Perhaps all the dynamic stuff is just over-engineering and we can just
do the url calculation locally.

> We still need some sort of wrapper for pip, because you're right I
> don't think we can use $() syntax to set the variable in tox.ini.
> Unless maybe we can do some of this with a tox plugin/extension?
> But it seems better to do it by putting a script or something in
> the repo, so a user has fewer things to install to run the tests.

> Which things do we have that don't use the releases repo but do use
> constraints?

I don't know of any right now, and I'm struggling to come up with a good
way to check.  I was mostly pointing out a scenario that would fail in
that scheme in the hopes that someone could say "Oh that isn't problem
just do $x"  or "Yup that's a deal breaker"

Tony.

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

Re: [openstack-dev] [neutron][FFE]Allow DVR for E/W while leaving N/S centralized Edit

2017-08-03 Thread Swaminathan Vasudevan



Hi PTL/all,
I would like to request an exception for inclusion of 
https://bugs.launchpad.net/neutron/+bug/1667877.
This fix addresses providing option for the customers to configure a new 
agent-type for centralizing the 
floatingip in the absence of external network connectivity.


The RFE: https://bugs.launchpad.net/neutron/+bug/1667877
Patch under review: https://review.openstack.org/#/c/485333/

Best regards,
Swaminathan Vasudevan



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

Re: [openstack-dev] [neutron][FFE] DVR support for Allowed_address_pair port that are bound to multiple ACTIVE VM ports

2017-08-03 Thread Swaminathan Vasudevan


Hi PTL/all,I would like to request an exception for inclusion of 
https://bugs.launchpad.net/neutron/+bug/1583694for Pike.
This fix contained two patches one for server side and the other for the 
agent side.

The server side patch had already merged, but the agent side patch is yet to 
merge but gone through
multiple reviews.
I would request to consider the agent side patch for the Feature Freeze 
Exception.

The RFE: https://bugs.launchpad.net/neutron/+bug/1583694
The agent side patch: https://review.openstack.org/#/c/437986/  (FFE required)

The server side patch that already merged: 
https://review.openstack.org/#/c/466434/  (Patch already merged).
Best regards,
Swaminathan Vasudevan


__
OpenStack Development Mailing List (not for 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][ptl][stable][release] stable/pike branches created for most libraries

On Thu, Aug 03, 2017 at 05:33:46PM +0200, Andreas Jaeger wrote:

> this would mean that depends-on does not work anymore - if you update
> the upper-constraint file and want to test, you can use depends-on today.
> 
> with uploading to tarballs, this will not work,

As Jeremy pointed out this would just replaces the existing defult URL
in tox.ini the goal would be for everything else to continue as it does
today just with fewer issues.

Yours Tony.


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

Re: [openstack-dev] [all][ptl][stable][release] stable/pike branches created for most libraries

Excerpts from Tony Breeds's message of 2017-08-04 08:56:17 +1000:
> On Thu, Aug 03, 2017 at 11:04:52AM -0400, Doug Hellmann wrote:
> > Excerpts from Tony Breeds's message of 2017-08-03 12:43:04 +1000:
> > > On Mon, Jul 31, 2017 at 08:00:22AM -0400, Doug Hellmann wrote:
> > > > Excerpts from Dmitry Tantsur's message of 2017-07-29 20:06:18 +0200:
> > > > > Just to clarify: we cannot land the tox.ini change until the 
> > > > > requirements repo 
> > > > > is actually branched, right?
> > > > 
> > > > Good point. The tests for those patches are passing for some projects in
> > > > CI, but when the patches are landed it will make it a little harder for
> > > > anyone to run the tests for the branch elsewhere because the
> > > > requirements repo has not yet been branched.
> > > > 
> > > > So, yes, hold off on landing the constraint URL changes.
> > > 
> > > I wonder if we should look at publishing the upper-constraints.txt file
> > > somewhere (other than cgit).  If we did something like:
> > > 
> > > tarballs.o.o/constraints/$series.txt
> > > 
> > > We wouldn't have an issue when we EOL a branch and the url's hard-coded
> > > in tox.ini breaking.  queens.txt wouldn't exist until we branch
> > > requirements but we could work around that with a redirect if needed.
> > 
> > I like the idea of publishing to a branch-specific file that always
> > stays on the server. We could make the job on master publish both
> > to a master.txt and a $series.txt file if we need both to exist at the
> > same time.
> > 
> > > Later we could get really crazy and make a version that took a package
> > > name and version perhaps like:
> > > 
> > > tarballs.o.o/constraints/$(python setup.py --name)/$(python setup.py 
> > > --version)
> > > 
> > > Which would redirect to the appropriate series file.  I think we have
> > > enough data in openstack/releases to generate those redirects.  We'd
> > > need to think about projects / repos that don't use the release
> > > infrastructure.
> > 
> > How would that redirect be used?
> 
> So I admit I typed that email and hit send without a huge amount of
> thought and even though I use a web browser a lot I don't really
> understand how http works but I was thinking about something like:
> 
> on $server probably releases.o.o but that's a detail we can sort out
> later.
> 
> /constraints contains a .htaccess file generated from the data in
> openstack relases that says something like:
> 
> redirect /constratints/nova/14.* to /constrataints/newton.txt
> redirect /constratints/nova/15.* to /constrataints/ocata.txt
> 
> Any unknown versions get  /constratints/master.txt (or queens.txt
> depending on what we do)
> 
> It could be a redirect or a rewrite rule whatever works best
> 
> then the nova tox.ini does something like:
> ${ENV:UPPER_CONSTRAINTS_FILE:https://server/constratins/nova/$(python
> setup.py --version)}
> 
> Now it is probably that direct shell output can't be used like that and
> then the whole thing fails but I hope we can do something like that ...
> even if in the short term we need to use a helper script like we do to
> work around other constraints issues.

OK, I see. I was assuming we would just tie it to series name, and
that series name could be taken from the .gitreview file or something.
So the URL calculation would always be done locally, and we wouldn't
need any sort of redirects.

We still need some sort of wrapper for pip, because you're right I
don't think we can use $() syntax to set the variable in tox.ini.
Unless maybe we can do some of this with a tox plugin/extension?
But it seems better to do it by putting a script or something in
the repo, so a user has fewer things to install to run the tests.

> If that doesn't work /constraints could become a script that looks and
> the path_element and does the same logic.
> 
> Now it's herder with libraries but now that much harder.
> 
> The trick would be for repos that don't use releases and perhaps for
> them in the first instance they need to hard code the serries.

Which things do we have that don't use the releases repo but do use
constraints?

Doug

> 
> > 
> > > 
> > > That'd mean we could get way from hard-coding the URLs in tox.ini and
> > > therefore not need to update them at branch time.
> > > 
> > > I've either had too much coffee or not enough.  y'all decide.
> > > 
> > > Yours Tony.
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Yours Tony.

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

Re: [openstack-dev] [ffe][release][requirements][tripleo]

2017-08-03 Thread Emilien Macchi

On Thu, Aug 3, 2017 at 4:05 PM, Steve Baker  wrote:
> I would like to request a Feature Freeze Exemption (FFE) for the upper
> constraints of the python-paunch library/tool in Pike.
>
> https://review.openstack.org/#/c/490287/
>
> TripleO recently switched from using paunch as a library via heat-agents to
> using the paunch CLI tool directly using ansible. This lead to a high impact
> regression bug [1] where failed operations don't raise an error, fixed by
> [2]. This leads to false positives in TripleO CI, and later deployment
> failures which are more difficult to debug.
>
> Release 1.5.0 contains a fix for this. It also contains the new "paunch
> debug" command[3] which makes developing and debugging containers in TripleO
> much easier. This feature has a low risk of causing regressions in paunch's
> core function and is also desirable for the Pike release.

+1 from me.

> [1] https://bugs.launchpad.net/paunch/+bug/1707997
> [2] https://review.openstack.org/#/c/489722/
> [3] https://review.openstack.org/#/c/476654/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [neutron] FFE for net-mtu-enh api extension requested

Granted:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-08-03-22.02.log.html

On Fri, Jul 28, 2017 at 11:50 AM, Ihar Hrachyshka 
wrote:

> Hi PTL/all,
>
> I would like to request an exception for inclusion of net-mtu-enh API
> extension (with ML2 implementation) for Pike.
>
> The patch is ready for review, it includes tempest tests and docs
> update. There are several things in the patch that we will need to
> follow up in the next release (hence a lot of TODOs), but those are
> not because the patch is not complete, but because we need to
> accommodate for rolling upgrades of controllers.
>
> The RFE: https://launchpad.net/bugs/1671634
> The patch: https://review.openstack.org/#/c/483518/
>
> Best regards,
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] - FFE for security-group logging requested

Granted:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-08-03-22.02.log.html

On Mon, Jul 31, 2017 at 3:19 AM, Furukawa, Yushiro <
y.furukaw...@jp.fujitsu.com> wrote:

> Hi Kevin(PTL)/all,
>
> I would like to request an exception for 'Logging feature' for Pike.
> Following patches are ready for review, it includes functional tests and
> docs
> update.  In next cycle, we need to add more tests.
>
> The RFE:
>   
> The Patches:
> 01. - Driver manager for
> logging plugin
> 02. - Validator for logging
> plugin
> 03. - Logging agent
> extension
> 04. - RPC stuff
> 05. - OVS firewall logging
> driver
> 06. - OSC plugin
> 07. - Networking guide
> 08. - Functional test
> 09. - API test
> 10. - Devstack plugin
>
> Best regards,
>
> 
> Yushiro FURUKAWA
>
> From: Kevin Benton [mailto:ke...@benton.pub]
> Sent: Monday, July 31, 2017 3:53 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [neutron] - FFE requests for Pike
>
> Hi all,
>
> If you have any Neutron-related FFE requests for Pike please send an email
> to the dev list with [neutron] in the tag and FFE in the subject like in
> [1]. We will discuss them in the drivers meetings.
>
>
> 1. http://lists.openstack.org/pipermail/openstack-dev/2017-
> July/120310.html
>
> Thanks,
> Kevin Benton
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] FFE for midonet v2 plugin removal

Granted:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-08-03-22.02.log.html

On Tue, Aug 1, 2017 at 12:19 AM, Takashi Yamamoto 
wrote:

> On Tue, Aug 1, 2017 at 8:01 AM, Takashi Yamamoto 
> wrote:
> > hi,
> >
> > I'm not sure if changes like this requires an FFE, but just in case.
> > I'd like to request an FFE for midonet v2 plugin removal.
> >
> > - patches are ready for review: https://review.openstack.org/#/c/486790/
> > - https://bugs.launchpad.net/networking-midonet/
>
> oops, bad copy and paste.
> https://bugs.launchpad.net/networking-midonet/+bug/1680347
>
> > - this is a removal of an already-deprecated plugin
> > - the replacement code (midonet drivers for ml2) covers the most or
> > probably all functionalities provided by the plugin being removed
> > - the change is local to networking-midonet
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] FFE for dns_domain for ports extension

Granted:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-08-03-22.02.log.html

On Tue, Aug 1, 2017 at 12:44 PM, Miguel Lavalle  wrote:

> Hi PTL/all
>
> I want to request an exception to include the dns_domain for ports
> extension in the Pike release.
>
> The extension is implemented by 3 patchsets, out of which [1] and [2] have
> already merged. The third patchset [3] is ready for reviews. The RFE can be
> found in [4].
>
> Best regards
> Miguel
>
>
> [1] https://review.openstack.org/#/c/457101/
> [2] https://review.openstack.org/#/c/457035/
> [3] https://review.openstack.org/#/c/468697/
> [4] https://bugs.launchpad.net/neutron/+bug/1650678
>
> __
> OpenStack Development Mailing 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] [ffe][release][requirements][tripleo]

2017-08-03 Thread Steve Baker

I would like to request a Feature Freeze Exemption (FFE) for the upper
constraints of the python-paunch library/tool in Pike.

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

TripleO recently switched from using paunch as a library via heat-agents to
using the paunch CLI tool directly using ansible. This lead to a high
impact regression bug [1] where failed operations don't raise an error,
fixed by [2]. This leads to false positives in TripleO CI, and later
deployment failures which are more difficult to debug.

Release 1.5.0 contains a fix for this. It also contains the new "paunch
debug" command[3] which makes developing and debugging containers in
TripleO much easier. This feature has a low risk of causing regressions in
paunch's core function and is also desirable for the Pike release.

[1] https://bugs.launchpad.net/paunch/+bug/1707997
[2] https://review.openstack.org/#/c/489722/
[3] https://review.openstack.org/#/c/476654/
__
OpenStack Development Mailing List (not for 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][ptl][stable][release] stable/pike branches created for most libraries

On Thu, Aug 03, 2017 at 11:04:52AM -0400, Doug Hellmann wrote:
> Excerpts from Tony Breeds's message of 2017-08-03 12:43:04 +1000:
> > On Mon, Jul 31, 2017 at 08:00:22AM -0400, Doug Hellmann wrote:
> > > Excerpts from Dmitry Tantsur's message of 2017-07-29 20:06:18 +0200:
> > > > Just to clarify: we cannot land the tox.ini change until the 
> > > > requirements repo 
> > > > is actually branched, right?
> > > 
> > > Good point. The tests for those patches are passing for some projects in
> > > CI, but when the patches are landed it will make it a little harder for
> > > anyone to run the tests for the branch elsewhere because the
> > > requirements repo has not yet been branched.
> > > 
> > > So, yes, hold off on landing the constraint URL changes.
> > 
> > I wonder if we should look at publishing the upper-constraints.txt file
> > somewhere (other than cgit).  If we did something like:
> > 
> > tarballs.o.o/constraints/$series.txt
> > 
> > We wouldn't have an issue when we EOL a branch and the url's hard-coded
> > in tox.ini breaking.  queens.txt wouldn't exist until we branch
> > requirements but we could work around that with a redirect if needed.
> 
> I like the idea of publishing to a branch-specific file that always
> stays on the server. We could make the job on master publish both
> to a master.txt and a $series.txt file if we need both to exist at the
> same time.
> 
> > Later we could get really crazy and make a version that took a package
> > name and version perhaps like:
> > 
> > tarballs.o.o/constraints/$(python setup.py --name)/$(python setup.py 
> > --version)
> > 
> > Which would redirect to the appropriate series file.  I think we have
> > enough data in openstack/releases to generate those redirects.  We'd
> > need to think about projects / repos that don't use the release
> > infrastructure.
> 
> How would that redirect be used?

So I admit I typed that email and hit send without a huge amount of
thought and even though I use a web browser a lot I don't really
understand how http works but I was thinking about something like:

on $server probably releases.o.o but that's a detail we can sort out
later.

/constraints contains a .htaccess file generated from the data in
openstack relases that says something like:

redirect /constratints/nova/14.* to /constrataints/newton.txt
redirect /constratints/nova/15.* to /constrataints/ocata.txt

Any unknown versions get  /constratints/master.txt (or queens.txt
depending on what we do)

It could be a redirect or a rewrite rule whatever works best

then the nova tox.ini does something like:
${ENV:UPPER_CONSTRAINTS_FILE:https://server/constratins/nova/$(python
setup.py --version)}

Now it is probably that direct shell output can't be used like that and
then the whole thing fails but I hope we can do something like that ...
even if in the short term we need to use a helper script like we do to
work around other constraints issues.

If that doesn't work /constraints could become a script that looks and
the path_element and does the same logic.

Now it's herder with libraries but now that much harder.

The trick would be for repos that don't use releases and perhaps for
them in the first instance they need to hard code the serries.

> 
> > 
> > That'd mean we could get way from hard-coding the URLs in tox.ini and
> > therefore not need to update them at branch time.
> > 
> > I've either had too much coffee or not enough.  y'all decide.
> > 
> > Yours Tony.
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Yours Tony.


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

Re: [openstack-dev] [ironic][bifrost] Unable to Enroll Inventory

2017-08-03 Thread Aimee Ukasick

Thanks Mark for pointing me in the right direction! It turned out to
be a permissions issue with the local Ansible installation.

I started over with a new user (stack, passwordless sudo) and decided
to use the bifrost's env-setup script, which I was not able to run
unless prefaced with sudo.

stack@ubuntu-jumphost:~/bifrost$ sudo bash ./scripts/env-setup.sh

stack@ubuntu-jumphost:~/bifrost$ source env-vars

stack@ubuntu-jumphost:~/bifrost$ echo $PATH
/home/stack/.local/bin:/home/stack/bin:/home/stack/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

stack@ubuntu-jumphost:~/bifrost/playbooks$ which ansible
/home/stack/.local/bin/ansible
stack@ubuntu-jumphost:~/bifrost/playbooks$ ansible-playbook - -i
inventory/target install.yaml -e staging_drivers_include=true
Traceback (most recent call last):
File "/home/stack/.local/bin/ansible-playbook", line 44, in
import ansible.constants as C
ImportError: No module named ansible.constants

stack@ubuntu-jumphost:~/bifrost/playbooks$ ansible --version
Traceback (most recent call last):
File "/home/stack/.local/bin/ansible", line 44, in
import ansible.constants as C
ImportError: No module named ansible.constants

The ~/.local/bin/ansible folder was owned by root:root as was
~/.ansible. Once I changed the ownership to stack:stack, ansible
worked as expected. I was able to run the ansible-playbook command
without prefacing it with sudo. So I had a successful installation. Do
you know why the bifrost env-setup.sh installed ansible with root
ownership in my ~/.local directory? Is that the default Ansible
behavior? Is the expectation that I switch to root to install/run
bifrost?

I was able to enroll my servers without a hitch.

Friday I plan to deploy - hopefully I've identified and fixed all the
kinks on my system.

Thanks again for your help!

aimee
irc:aimeeu

On Thu, Aug 3, 2017 at 3:27 AM, Mark Goddard wrote:
> Hi Aimee,
>
> My guess is that your error is due to your use of sudo when running
> ansible-playbook.

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

Re: [openstack-dev] [neutron] Call for help with in-tree tempest scenario test failures

2017-08-03 Thread Ihar Hrachyshka

Thanks for those who stepped in (Armando and Slawek).

We still have quite some failures that would benefit from initial log
triage and fixes. If you feel like in this feature freeze time you
have less things to do, helping with those scenario failures would be
a good way to contribute to the project.

Thanks,
Ihar

On Fri, Jul 28, 2017 at 6:02 AM, Sławek Kapłoński  wrote:
> Hello,
>
> I will try to check QoS tests in this job.
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
>> Wiadomość napisana przez Jakub Libosvar  w dniu 
>> 28.07.2017, o godz. 14:49:
>>
>> Hi all,
>>
>> as sending out a call for help with our precious jobs was very
>> successful last time and we swept all Python 3 functional from Neutron
>> pretty fast (kudos the the team!), here comes a new round of failures.
>>
>> This time I'm asking for your help > poster here> with gate-tempest-dsvm-neutron-dvr-multinode-scenario
>> non-voting job. This job has been part of check queue for a while and is
>> very very unstable. Such job covers scenarios like router dvr/ha/legacy
>> migrations, qos, trunk and dvr. I went through current failures and
>> created an etherpad [1] with categorized failures and logstash queries
>> that give you latest failures with given particular tests.
>>
>> If you feel like doing troubleshooting and sending fixes for gates,
>> please pick one test and write down your name to the test.
>>
>> Thanks to all who are willing to participate.
>>
>> Have a great weekend.
>> Jakub
>>
>>
>> [1]
>> https://etherpad.openstack.org/p/neutron-dvr-multinode-scenario-gate-failures
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [neutron] PTL Nomination

Hello!

I would like to nominate myself as PTL for the Neutron project for the
Queens cycle.

I served as the Neutron PTL for the Pike cycle, have been a core reviewer
since Kilo, and have been contributing since Havana.

I have a few new goals I would like to focus on during the Queens cycle.

* New bug triaging process. We've had a lot of trouble finding volunteers
for bug deputy duty. We need to come up with another way to share the load
of triaging reported bugs.

* Finish the multiple port-binding work. As OVSFW and other ML2 drivers
that require different VIF wiring gain popularity, we need to solve the
migration between VIF types in a generic way so operators can reasonably
switch between backends.

* Expand the routed networks work to cover the external network and
floating IPs. This will solve the issue of scaling a single broadcast
domain to every compute node that is a blocker for many large operators
with L3 fabrics.


Additionally, I would like to continue on several of the goals I suggested
during the last cycle.

* Cleanup and simplification of the existing code. Quite a bit of this has
happened server-side by leveraging the callback system to decouple things.
We merged a significant amount of OVO code to stop working with models
directly and there are a few major objects left like Ports that I would
like to see completed in Queens.

* VPNaaS: it didn't quite make it back into the stadium during Pike. There
is one remaining item to decouple their agent code and then we should be
able to make VPNaaS part of the stadium again.

* We completed the switch to Pecan and we've been running on it most of the
Pike cycle. In Queens we can pull out all of the old API code.

* Supporting stable interfaces for external projects. We have made quite a
bit of progress moving externally referenced items to neutron-lib. One of
the last items to solve is OVO definitions and then it will be feasible for
projects to stop depending on the neutron core code directly.

Goals that didn't see much progress:

* More core reviewers. Unfortunately do the change in focus for many
companies we haven't seen a lot of new contributors with enough time for a
core reviewer load.

* Tooling for review backlog. I did adjust the auto-abandon script a bit
but there is no automated process yet to help keep this under control.


Cheers,
Kevin Benton
__
OpenStack Development Mailing List (not for 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][packaging][deb] retiring Packaging Deb project

2017-08-03 Thread Paul Belanger

On Thu, Aug 03, 2017 at 10:09:59AM -0400, Allison Randal wrote:
> Hi all,
> 
> The Debian OpenStack packagers are gathered at the annual Debian
> developer event, and discussing the future of OpenStack packaging for
> Debian. There's general agreement that we'd like to go ahead and package
> Pike, but also agreement that we'd like to move back to the Debian
> infrastructure for doing packaging work. There are a variety of reasons,
> including that:
> 
> - Using the familiar Debian workflows and infrastructure is a better way
> to attract experienced Debian developers to the work, and
> 
> - The way we set up the Debian packaging workflow on OpenStack Infra was
> a temporary compromise, and not really a good fit for OpenStack Infra
> (or for Debian).
> 
> As a result of the change, we'd like to retire the Packaging Deb
> project in OpenStack, and there will be no candidate running for Queens
> PTL for the project. There will be some cleanup work to do, around
> deb-* repos and other aspects of the Debian packaging workflow we set up
> with OpenStack Infra, following the standard retirement procedures:
> 
> https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
> 
> The OpenStack installation tutorial for Debian will remain in OpenStack,
> and we'll update it for Pike.
> 
> If you have any concerns about the retirement, please let us know
> (especially other distros that use .deb format packages), we'll wait a
> bit for feedback before moving ahead with the cleanup.
> 
++ I've already gone a head a few weeks ago and stop the usptream-repo sync that
was setup when packaging first started, that will make retiring projects easier.

Feel free to ping in #openstack-infra when ready, because the amount of projects
that will be retired, the incoming patch will be a magnet for merge conflicts.

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

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

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

2017-08-03 Thread Rajul Kumar

Hi Boris

That is a point of concern.
Can you please direct to any of those?

Anyways, we don't have anything in place for OpenStack yet.
Now, either we pick another tracing solution like Zipkin, Jaeger etc. which
have their own limitations OR enhance OSProfiler.
We pick the later as it's most native and better coupled with OpenStack as
of now.
I understand that we may be blocked by these issues. However, I feel it'll
be better to fight with OSProfiler than anything else till we come up with
something better :)

Thanks
Rajul

On Thu, Aug 3, 2017 at 4:01 PM, Boris Pavlovic  wrote:

> Rajul,
>
> May I ask why you think so?
>
>
> Exposed by OSprofiler issues are going to be really hard to fix in current
> OpenStack architecture.
>
> Best regards,
> Boris Pavlovic
>
> On Thu, Aug 3, 2017 at 12:56 PM, Rajul Kumar 
> wrote:
>
>> Hi Boris
>>
>> Good to hear from you.
>> May I ask why you think so?
>>
>> We do see some potential with OSProfiler for this and further objectives.
>>
>> Thanks
>> Rajul
>>
>> On Thu, Aug 3, 2017 at 3:48 PM, Boris Pavlovic  wrote:
>>
>>> Rajul,
>>>
>>> It makes sense! However, maybe it's a bit too late... ;)
>>>
>>> Best regards,
>>> Boris Pavlovic
>>>
>>> On Thu, Aug 3, 2017 at 12:16 PM, Rajul Kumar 
>>> wrote:
>>>
 Hello everyone

 I have added a blueprint on having tail-based sampling as a sampling
 option for continuous tracing in OSProfiler. It would be really helpful to
 have some thoughts, ideas, comments on this from the community.

 Continuous tracing provides a good insight on how various transactions
 behave across in a distributed system. Currently, OpenStack doesn't have a
 defined solution for continuous tracing. Though, it has OSProfiler that
 does generates selective traces, it may not capture the occurrence. Even if
 we have OSProfiler running continuously [1], we need to sample the traces
 so as to cut down the data generated and still keep the useful info.

 Head based sampling can be applied that decides initially whether a
 trace should be saved or not. However, it may miss out on some useful
 traces. I propose to have tail-based sampling [2] mechanism that makes the
 decision at the end of the transaction and tends to keep all the useful
 traces. This may require a lot of changes depending on what all type of
 info is required and the solution that we pick to implement it [2]. This
 may not affect the current working of any of the services on OpenStack as
 it will be off the critical path [3].

 Please share your thoughts on this and what solution should be
 preferred in a broader OpenStack's perspective.
 This is a step in the process of having an automated diagnostic
 solution for OpenStack cluster.

 [1] https://blueprints.launchpad.net/osprofiler/+spec/osprof
 iler-overhead-control
 [2] https://blueprints.launchpad.net/osprofiler/+spec/tail-b
 ased-coherent-sampling
 [3] https://blueprints.launchpad.net/osprofiler/+spec/asynch
 ronous-trace-collection

 Thanks
 Rajul Kumar

 __
 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

>>>
>>> 
>>> __
>>> 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
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] VMWare Type Snapshot for Openstack 4.3

2017-08-03 Thread Tom Kennedy

All

I would like to add an a new tab the the instance panel in Horizon that 
will allow me to  manage VMWare type snapshots (take a snapshots, revert 
to a snapshot and delete a snapshot) .I see that this is implemented 
in nova(nova/api/openstack/compute/contrib/server_snapshot.py) , but is 
not available in Horizon.  

Has someone done that an can share the procedure for doing this? Or is 
there a guide that shows how to implement something like this.  


Note, a VMWare snapshot is not the same as an Openstack snapshot.


 Tom Kennedy
 kenne...@us.ibm.com
 Infrastructure Engineer


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

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

2017-08-03 Thread Boris Pavlovic

Rajul,

May I ask why you think so?


Exposed by OSprofiler issues are going to be really hard to fix in current
OpenStack architecture.

Best regards,
Boris Pavlovic

On Thu, Aug 3, 2017 at 12:56 PM, Rajul Kumar 
wrote:

> Hi Boris
>
> Good to hear from you.
> May I ask why you think so?
>
> We do see some potential with OSProfiler for this and further objectives.
>
> Thanks
> Rajul
>
> On Thu, Aug 3, 2017 at 3:48 PM, Boris Pavlovic  wrote:
>
>> Rajul,
>>
>> It makes sense! However, maybe it's a bit too late... ;)
>>
>> Best regards,
>> Boris Pavlovic
>>
>> On Thu, Aug 3, 2017 at 12:16 PM, Rajul Kumar 
>> wrote:
>>
>>> Hello everyone
>>>
>>> I have added a blueprint on having tail-based sampling as a sampling
>>> option for continuous tracing in OSProfiler. It would be really helpful to
>>> have some thoughts, ideas, comments on this from the community.
>>>
>>> Continuous tracing provides a good insight on how various transactions
>>> behave across in a distributed system. Currently, OpenStack doesn't have a
>>> defined solution for continuous tracing. Though, it has OSProfiler that
>>> does generates selective traces, it may not capture the occurrence. Even if
>>> we have OSProfiler running continuously [1], we need to sample the traces
>>> so as to cut down the data generated and still keep the useful info.
>>>
>>> Head based sampling can be applied that decides initially whether a
>>> trace should be saved or not. However, it may miss out on some useful
>>> traces. I propose to have tail-based sampling [2] mechanism that makes the
>>> decision at the end of the transaction and tends to keep all the useful
>>> traces. This may require a lot of changes depending on what all type of
>>> info is required and the solution that we pick to implement it [2]. This
>>> may not affect the current working of any of the services on OpenStack as
>>> it will be off the critical path [3].
>>>
>>> Please share your thoughts on this and what solution should be preferred
>>> in a broader OpenStack's perspective.
>>> This is a step in the process of having an automated diagnostic solution
>>> for OpenStack cluster.
>>>
>>> [1] https://blueprints.launchpad.net/osprofiler/+spec/osprof
>>> iler-overhead-control
>>> [2] https://blueprints.launchpad.net/osprofiler/+spec/tail-b
>>> ased-coherent-sampling
>>> [3] https://blueprints.launchpad.net/osprofiler/+spec/asynch
>>> ronous-trace-collection
>>>
>>> Thanks
>>> Rajul Kumar
>>>
>>>
>>> 
>>> __
>>> 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
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [python-openstacksdk] Status of python-openstacksdk project

2017-08-03 Thread Michael Johnson


Hi OpenStack developers,

I was wondering what is the current status of the python-openstacksdk
project.  The Octavia team has posted some patches implementing our new
Octavia v2 API [1] in the SDK, but we have not had any reviews.  I have also
asked some questions in #openstack-sdks with no responses.
I see that there are some maintenance patches getting merged and a pypi
release was made 6/14/17 (though not through releases project).  I'm not
seeing any mailing list traffic and the IRC meetings seem to have ended in
2016.

With all the recent contributor changes, I want to make sure the project
isn't adrift in the sea of OpenStack before we continue to spend development
time implementing the SDK for Octavia. We were also planning to use it as
the backing for our dashboard project.

Since it's not in the governance projects list I couldn't determine who the
PTL to ping would be, so I decided to ping the dev mailing list.

My questions:
1. Is this project abandoned?
2. Is there a plan to make it an official project?
3. Should we continue to develop for it?

Thanks,
Michael (johnsom)

[1]
https://review.openstack.org/#/q/project:openstack/python-openstacksdk+statu
s:open+topic:%255Eoctavia.*


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

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

2017-08-03 Thread Rajul Kumar

Hi Boris

Good to hear from you.
May I ask why you think so?

We do see some potential with OSProfiler for this and further objectives.

Thanks
Rajul

On Thu, Aug 3, 2017 at 3:48 PM, Boris Pavlovic  wrote:

> Rajul,
>
> It makes sense! However, maybe it's a bit too late... ;)
>
> Best regards,
> Boris Pavlovic
>
> On Thu, Aug 3, 2017 at 12:16 PM, Rajul Kumar 
> wrote:
>
>> Hello everyone
>>
>> I have added a blueprint on having tail-based sampling as a sampling
>> option for continuous tracing in OSProfiler. It would be really helpful to
>> have some thoughts, ideas, comments on this from the community.
>>
>> Continuous tracing provides a good insight on how various transactions
>> behave across in a distributed system. Currently, OpenStack doesn't have a
>> defined solution for continuous tracing. Though, it has OSProfiler that
>> does generates selective traces, it may not capture the occurrence. Even if
>> we have OSProfiler running continuously [1], we need to sample the traces
>> so as to cut down the data generated and still keep the useful info.
>>
>> Head based sampling can be applied that decides initially whether a trace
>> should be saved or not. However, it may miss out on some useful traces. I
>> propose to have tail-based sampling [2] mechanism that makes the decision
>> at the end of the transaction and tends to keep all the useful traces. This
>> may require a lot of changes depending on what all type of info is required
>> and the solution that we pick to implement it [2]. This may not affect the
>> current working of any of the services on OpenStack as it will be off the
>> critical path [3].
>>
>> Please share your thoughts on this and what solution should be preferred
>> in a broader OpenStack's perspective.
>> This is a step in the process of having an automated diagnostic solution
>> for OpenStack cluster.
>>
>> [1] https://blueprints.launchpad.net/osprofiler/+spec/
>> osprofiler-overhead-control
>> [2] https://blueprints.launchpad.net/osprofiler/+spec/tail-
>> based-coherent-sampling
>> [3] https://blueprints.launchpad.net/osprofiler/+spec/
>> asynchronous-trace-collection
>>
>> Thanks
>> Rajul Kumar
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Tracing (all the places)

2017-08-03 Thread Joshua Harlow

Since I think there was another thread out there around tracing I'd 
thought I'd send out a few others for folks that show tracing being 
added to multiple other popular project (interesting to read over the 
proposals and such).


- 
https://github.com/grpc/grpc/blob/master/src/core/ext/census/README.md#census---a-resource-measurement-and-tracing-system


- https://github.com/kubernetes/kubernetes/issues/26507 (k8s tracing 
addition/proposal)


- http://jaeger.readthedocs.io/en/latest/architecture/

It'd be real nice to finally get some kind of tracing support integrated 
into openstack; osprofiler was started a long time ago and I think it's 
due time for it to actually be used and integrated :)


-Josh

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

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

2017-08-03 Thread Boris Pavlovic

Rajul,

It makes sense! However, maybe it's a bit too late... ;)

Best regards,
Boris Pavlovic

On Thu, Aug 3, 2017 at 12:16 PM, Rajul Kumar 
wrote:

> Hello everyone
>
> I have added a blueprint on having tail-based sampling as a sampling
> option for continuous tracing in OSProfiler. It would be really helpful to
> have some thoughts, ideas, comments on this from the community.
>
> Continuous tracing provides a good insight on how various transactions
> behave across in a distributed system. Currently, OpenStack doesn't have a
> defined solution for continuous tracing. Though, it has OSProfiler that
> does generates selective traces, it may not capture the occurrence. Even if
> we have OSProfiler running continuously [1], we need to sample the traces
> so as to cut down the data generated and still keep the useful info.
>
> Head based sampling can be applied that decides initially whether a trace
> should be saved or not. However, it may miss out on some useful traces. I
> propose to have tail-based sampling [2] mechanism that makes the decision
> at the end of the transaction and tends to keep all the useful traces. This
> may require a lot of changes depending on what all type of info is required
> and the solution that we pick to implement it [2]. This may not affect the
> current working of any of the services on OpenStack as it will be off the
> critical path [3].
>
> Please share your thoughts on this and what solution should be preferred
> in a broader OpenStack's perspective.
> This is a step in the process of having an automated diagnostic solution
> for OpenStack cluster.
>
> [1] https://blueprints.launchpad.net/osprofiler/+spec/osprofiler-overhead-
> control
> [2] https://blueprints.launchpad.net/osprofiler/+spec/tail-based-coherent-
> sampling
> [3] https://blueprints.launchpad.net/osprofiler/+spec/asynchronous-trace-
> collection
>
> Thanks
> Rajul Kumar
>
>
> __
> OpenStack Development Mailing 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] [oslo][performance] Proposing tail-based sampling in OSProfiler

2017-08-03 Thread Rajul Kumar

Hello everyone

I have added a blueprint on having tail-based sampling as a sampling option
for continuous tracing in OSProfiler. It would be really helpful to have
some thoughts, ideas, comments on this from the community.

Continuous tracing provides a good insight on how various transactions
behave across in a distributed system. Currently, OpenStack doesn't have a
defined solution for continuous tracing. Though, it has OSProfiler that
does generates selective traces, it may not capture the occurrence. Even if
we have OSProfiler running continuously [1], we need to sample the traces
so as to cut down the data generated and still keep the useful info.

Head based sampling can be applied that decides initially whether a trace
should be saved or not. However, it may miss out on some useful traces. I
propose to have tail-based sampling [2] mechanism that makes the decision
at the end of the transaction and tends to keep all the useful traces. This
may require a lot of changes depending on what all type of info is required
and the solution that we pick to implement it [2]. This may not affect the
current working of any of the services on OpenStack as it will be off the
critical path [3].

Please share your thoughts on this and what solution should be preferred in
a broader OpenStack's perspective.
This is a step in the process of having an automated diagnostic solution
for OpenStack cluster.

[1]
https://blueprints.launchpad.net/osprofiler/+spec/osprofiler-overhead-control
[2]
https://blueprints.launchpad.net/osprofiler/+spec/tail-based-coherent-sampling
[3]
https://blueprints.launchpad.net/osprofiler/+spec/asynchronous-trace-collection

Thanks
Rajul Kumar
__
OpenStack Development Mailing 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] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

2017-08-03 Thread Boden Russell

I think we have a gap in our OSC CLI for non-stadium plugin/driver
projects (neutron plugin projects, nova driver projects) that implement
RESTful resource API attribute extensions.

For details, go directly to [1].
For a summary read on...


For OpenStack APIs that support extensions (ex [2]), the classic
python-client CLIs worked "out of the box" for extensions
adding attributes to existing RESTful resources.

For example, your project has a neutron plugin that adds a 'my_bool'
boolean attribute to 'network' resources that can be set via POST/PUT
and is returned with GET. This just works with the python-neutronclient
CLI without any client-side code changes.


However, with OSC resource attributes must be added directly/statically
to the sdk's resource and then consumed in the client; the support does
not come "for free" in the CLI. While this is fine for stadium projects
(they can contribute directly to the sdk/client), non-stadium projects
have no viable option to plugin/extend the CLI today for this type of
API extension mechanism.

With the phasing out of the python clients, a number of our users will
be left without a CLI to interface with these extensions.

I'd like to try and close this gap in Queens and welcome discussion in [1].

Thanks


[1] https://bugs.launchpad.net/python-openstacksdk/+bug/1705755
[2] https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions

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

Re: [openstack-dev] [OpenStack-docs] [docs] [training-guides] Moving from Hieroglyph for rendering slides

2017-08-03 Thread Jeremy Stanley

On 2017-08-03 16:18:31 + (+), Pančur, Matjaž wrote:
[...]
> We were leaning towards adopting a widely popular Reveal.js [2].
> On the downside, that probably also means that we will have to
> convert slide material from RST to MD, as RST is not directly
> supported. With a shrinking (Docs&Training guides) contributors,
> that could be a problem.
[...]

===
 Have your cake and eat it too
===

rst2html5_ usage example to generate a set of slides using
*reveal.js*::

rst2html5 --jquery --reveal-js --pretty-print-code \
examples/slides.rst > reveal.html

.. _rst2html5: https://pypi.org/project/rst2html5-tools/

-- 
Jeremy Stanley


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

Re: [openstack-dev] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

2017-08-03 Thread Eric K

As far as I can tell, bumping min version to 1.7.0 would not be a problem
for Congress.

Eric Kao

On 8/3/17, 4:39 AM, "witold.be...@est.fujitsu.com"
 wrote:

>Hello everyone,
>
>I would like to ask for the FFE for python-monascaclient version in
>global requirements.
>
>The current version in Pike (1.7.0) is not fully backward compatible. The
>monasca exception classes were replaced with keystoneauth exceptions,
>which affects heat and watcher projects if they use current upper
>constraints. The fixes for these projects have been submitted [1, 2].
>
>Also, monasca projects (monasca-agent, monasca-ui, monasca-api) rely on
>python-monascaclient 1.7.0 and don't work with older versions.
>
>The change for bumping the minimum version of python-monascaclient is
>here:
>
>https://review.openstack.org/489173
>
>
>Best greetings
>Witek Bedyk
>
>
>[1] https://review.openstack.org/490016
>[2] https://review.openstack.org/490018
>
>__
>OpenStack Development Mailing 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][docs] Concerns with docs migration

2017-08-03 Thread Ruby Loo

On Wed, Aug 2, 2017 at 10:55 AM, Matt Riedemann  wrote:

> ...
>
> b) I think that if we're going to refactor the Nova devref home page to be
> a certain format, then we should really consider doing the same thing in
> the other projects, because today they are all different formats [5][6][7].
> This is likely a cross-project discussion for the Queens PTG to determine
> if the home page for the projects should look similar. It seems they should
> given the uniformity that the Foundation has been working toward lately.
> ...

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-Augu
> st/120418.html
> [2] https://review.openstack.org/#/c/489650/
> [3] https://review.openstack.org/#/c/489641/
> [4] https://review.openstack.org/#/c/478485/
> [5] https://docs.openstack.org/cinder/latest/
> [6] https://docs.openstack.org/glance/latest/
> [7] https://docs.openstack.org/neutron/latest/
>
>
We had this discussion in ironic-land as well. I don't even consider it a
devref home page any more; it seems more like a landing page for 'all
things '. I may be opinionated sometimes ;), but if
some people could come to an agreement on how we could make these landing
pages consistent amongst most, if not all, of the openstack projects, I'll
follow :)

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

Re: [openstack-dev] [infra] redo gate jobs only

2017-08-03 Thread Eric K

Thanks a lot Jeremy and Andreas for the reference and the added context!

On 8/3/17, 10:49 AM, "Jeremy Stanley"  wrote:

>On 2017-08-03 08:15:36 +0200 (+0200), Andreas Jaeger wrote:
>[...]
>> "A patchset has to be approved to run tests in the gate pipeline. If the
>> patchset has failed in the gate pipeline (it will have been approved to
>> get into the gate pipeline) a recheck will first run the check jobs and
>> if those pass, it will again run the gate jobs. There is no way to only
>> run the gate jobs, the check jobs will first be run again."
>
>The reasons being:
>
>1. There's no good way to decide how long is too long to wait
>between passing jobs in check and running jobs in the gate. We used
>to not enforce this "clean check" policy and developers would
>repeatedly reverify broken changes back into the gate pipeline over
>and over creating a significant amount of additional disruption
>because their change had passed check jobs once (perhaps many months
>earlier). Now they at least only get to disrupt the gate once when
>that change gets approved, but after that it won't be able to make
>it back into the gate until a fixed revision is uploaded and so
>doesn't further slow down the merging of unrelated changes.
>
>2. If a change passes jobs once (in check) and then fails later (in
>the gate) then there's a fair chance it's introducing a
>nondeterministic bug (one which only manifests sometimes but not on
>every run). Back when we used to allow reverification directly in
>the gate pipeline for changes which passed check, we had people
>rechecking flaky changes until they passed and then reverifying them
>over and over after approval until they made them through the gate.
>Under these conditions a recheck followed by a reverify could merge
>changes which failed jobs 50% of the time; 9 rechecks and 9
>reverifies could merge a change which failed jobs 90% of the time on
>average. With the current requirements to pass both check and gate
>in series, it takes on average 3 rechecks to merge a 50% failing
>change and 99 rechecks to merge a 90% failing change.
>
>So basically if a change fails in the gate pipeline, there's good
>reason for it to get increased scrutiny at least in the form of
>trying the jobs again in the check pipeline before going back to the
>gate once more.
>-- 
>Jeremy Stanley
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [infra] redo gate jobs only

2017-08-03 Thread Jeremy Stanley

On 2017-08-03 08:15:36 +0200 (+0200), Andreas Jaeger wrote:
[...]
> "A patchset has to be approved to run tests in the gate pipeline. If the
> patchset has failed in the gate pipeline (it will have been approved to
> get into the gate pipeline) a recheck will first run the check jobs and
> if those pass, it will again run the gate jobs. There is no way to only
> run the gate jobs, the check jobs will first be run again."

The reasons being:

1. There's no good way to decide how long is too long to wait
between passing jobs in check and running jobs in the gate. We used
to not enforce this "clean check" policy and developers would
repeatedly reverify broken changes back into the gate pipeline over
and over creating a significant amount of additional disruption
because their change had passed check jobs once (perhaps many months
earlier). Now they at least only get to disrupt the gate once when
that change gets approved, but after that it won't be able to make
it back into the gate until a fixed revision is uploaded and so
doesn't further slow down the merging of unrelated changes.

2. If a change passes jobs once (in check) and then fails later (in
the gate) then there's a fair chance it's introducing a
nondeterministic bug (one which only manifests sometimes but not on
every run). Back when we used to allow reverification directly in
the gate pipeline for changes which passed check, we had people
rechecking flaky changes until they passed and then reverifying them
over and over after approval until they made them through the gate.
Under these conditions a recheck followed by a reverify could merge
changes which failed jobs 50% of the time; 9 rechecks and 9
reverifies could merge a change which failed jobs 90% of the time on
average. With the current requirements to pass both check and gate
in series, it takes on average 3 rechecks to merge a 50% failing
change and 99 rechecks to merge a 90% failing change.

So basically if a change fails in the gate pipeline, there's good
reason for it to get increased scrutiny at least in the form of
trying the jobs again in the check pipeline before going back to the
gate once more.
-- 
Jeremy Stanley

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

[openstack-dev] [all] [ptg] Policy Sessions

2017-08-03 Thread Lance Bragstad

One of the community goals for Queens is to move all policy into code
and document it [0]. I'd like to make myself available to work with
projects face-to-face if they need help at the PTG. In order to
successfully plan that, we need to have an estimate of how many projects
are interested in leveraging time at the PTG to get this kind of work
done. I've generalized an etherpad for all policy topics. The topic with
most priority is policy-in-code and policy-documentation since it's a
community-wide goal. I think it would be useful to fill gaps talking
about future policy work and our long term vision if we have free time.

*If you're interested in consolidating your project's policy into code
and documenting it at the PTG, please add your name to the etherpad.*
Likewise, if you're interested in discussing any of the items at the
bottom of the etherpad, please add your name to the etherpad. This
should help us determine what size room we need. As the PTG gets closer,
I'll parsing the content and topics into a formal agenda.

Thanks,

Lance


[0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
[1] https://etherpad.openstack.org/p/policy-queens-ptg


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

[openstack-dev] [octavia] PTL nomination

2017-08-03 Thread Michael Johnson

My fellow OpenStack community,

I would like to nominate myself for Octavia PTL for Queens. I am currently
the PTL for the Pike release series and would like to continue helping our
team provide network load balancing services for OpenStack.

For those of you that do not know me, I work for Rackspace. Prior to joining
Rackspace I worked for Hewlett-Packard for fifteen years on data center
automation, distributed network systems, embedded system design, and big
data.

During Pike, the Octavia team made huge progress by implementing the Octavia
v2 API, adding a new and up to date API reference, implementing a OpenStack
client plugin, new health monitoring capabilities, and many more
enhancements.

As we start to plan for Queens, I expect we will have a focus on adding the
provider interface to the Octavia v2 API, flavors, Active/Active load
balancer
support, and implement a new tempest plugin for Octavia.  I also want to
maintain our priority on providing onboarding support for new contributors
to
get involved with Octavia.

Thank you for your support of Octavia during Pike and your consideration for
Queens,

Michael Johnson (johnsom)


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

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

2017-08-03 Thread Ed Leafe

Greetings OpenStack community,

Today's meeting started off with continued discussion about the Guided Review 
process that we are trying to create ahead of the Denver PTG, where we would 
like to incorporate such a process as part of our sessions. This has been 
crystallized into a document [0] by elmiko. One point that is still to be added 
is how we record discussions after the fact, so that they can be preserved and 
referenced in the future.

The bulk of the meeting was taken up in discussing the proposed change from a 
Working Group (WG) to a Special Interest Group (SIG). This is in response to 
Thierry Carrez's email [4] on the subject. No one had any particularly strong 
feelings either way; I mean, we want to be as useful as possible to as many 
people as possible, but it's simply not clear whether the change to being a SIG 
would a) make that easier, or b) make that more difficult, or c) have no 
effect. In our case, this is also complicated by the fact that we are small, 
and expanding to a wider audience might be too much. Or it may bring in lots of 
new people to help out. We really don't know. We will continue to discuss this 
on the mailing list and future meetings.

There are no new guidelines for this week, but a small update to an existing 
document [5] was merged.


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

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

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

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

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] https://review.openstack.org/#/c/487847/
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] http://lists.openstack.org/pipermail/openstack-sigs/2017-July/22.html
[5] https://review.openstack.org/#/c/487504/

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

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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] Facilitating automation testing in TripleO UI

2017-08-03 Thread Ana Krivokapic

Hi TripleO devs,

In our effort to make the TripleO UI code friendlier to automation
testing[1], there is an open review[2] for which we seem to have some
difficulty reaching the consensus on how best to proceed. There is already
a discussion happening on the review itself, and I'd like to move it here,
rather than having it in a Gerrit review.

The tricky part is around adding HTML element ids to the Nodes page. This
page is generated by looping through the list of registered nodes and
displaying complete information about each of them. Because of this, many
of the elements are repeating on the page (CPU info, BIOS, power state,
etc, for each node). We need to figure out how to make these elements easy
for the automation testing code to access, both in terms of locating a
single group within the page, as well as distinguishing the individual
elements of a group from each other. There are several approaches that
we've come up so far:

1) Add unique IDs to all the elements. Generate unique `id` html attributes
by including the node UUID in the value of the `id` attribute. Do this for
both the higher level elements (divs that hold all the information about a
single node), as well as the lower level (the ones that hold info about
BIOS, CPU, etc). The disadvantage of this approach is cluttering the UI
codebase with many `id` attributes that would otherwise not be needed.

2) Add CSS classes instead of IDs. Pros for this approach: no need to
generate the clumsy ids containing the node UUID, since the CSS classes
don't need to be unique. Cons: we would be adding even more classes to HTML
elements, many of which are already cluttered with many classes. Also,
these classes would not exist anywhere in CSS or serve any other purpose.

3) Add custom HTML attributes. These usually start with the 'data-' prefix,
and would not need to be unique either. Pros: avoids the problems described
with both approaches above. Cons: AFAIU, the React framework could have
problems with custom attributes (Jirka can probably explain this better).
Also, casual readers of the code could be confused about the purpose of
these attributes, since no other code present in the UI codebase is using
them in any way.


It seems that a perfectly optimal solution does not exist here and we will
have to compromise on some level. Let's try and figure out what the best
course of action here is.

[1] https://blueprints.launchpad.net/tripleo/+spec/testing-ids
[2] https://review.openstack.org/#/c/483039/

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

Excerpts from witold.be...@est.fujitsu.com's message of 2017-08-03 16:07:45 
+:
> > -Original Message-
> > From: Doug Hellmann [mailto:d...@doughellmann.com]
> > Sent: Donnerstag, 3. August 2017 15:45
> > To: openstack-dev 
> > Subject: Re: [openstack-dev]
> > [ffe][requirements][monasca][heat][watcher][congress] FFE for python-
> > monascaclient minimum version in g-r
> > 
> > Excerpts from witold.be...@est.fujitsu.com's message of 2017-08-03
> > 11:39:47 +:
> > > Hello everyone,
> > >
> > > I would like to ask for the FFE for python-monascaclient version in global
> > requirements.
> > >
> > > The current version in Pike (1.7.0) is not fully backward compatible. The
> > monasca exception classes were replaced with keystoneauth exceptions,
> > which affects heat and watcher projects if they use current upper
> > constraints. The fixes for these projects have been submitted [1, 2].
> > >
> > > Also, monasca projects (monasca-agent, monasca-ui, monasca-api) rely on
> > python-monascaclient 1.7.0 and don't work with older versions.
> > >
> > > The change for bumping the minimum version of python-monascaclient is
> > here:
> > >
> > > https://review.openstack.org/489173
> > >
> > >
> > > Best greetings
> > > Witek Bedyk
> > >
> > >
> > > [1] https://review.openstack.org/490016
> > > [2] https://review.openstack.org/490018
> > >
> > 
> > It is rather late to be raising the minimum allowed version of a library 
> > due to
> > backwards incompatibilities. Can you provide more details about which
> > projects will be impacted (both by updating, and by not updating)?
> 
> 
> Hi Doug,
> 
> I know it's very unfortunate to raise it so late. We haven't paid enough 
> attention when merging the osc-lib integration to monascaclient. I'm sorry 
> for that.
> 
> If we update g-r impacted projects are:
> * Congress
> * Heat
> * Watcher
> For Heat and Watcher we have provided above referenced changes. Congress 
> should work with both, old and new versions, from what we've checked.
> Rally and Freezer-dr do not follow g-r. Fix for Rally has already been merged 
> [1]. Freezer-dr should not be impacted.
> 
> If we don't update g-r the impacted projects are again:
> * Heat
> * Watcher
> The teams don't want to merge compatibility fixes until requirements are 
> raised. Please refer to the reviews from the first message. Without these 
> fixes monascaclient from upper-constraints does not work for them.
> 
> The change in g-r does not alter u-c.
> 
> 
> [1] https://review.openstack.org/486015
> 
> > 
> > How can it be that the Monasca services already rely on the features of this
> > version? Are they not following the constraints process, so they use the
> > same versions of the libraries all of the other projects use?
> > 
> > Doug
> 
> 
> I'm not sure if I know what you mean. We do use upper-constraints for 
> installation and testing. The new version is in u-c.

OK, I think the thing that I misunderstood was that this
backwards-incompatible release is already out. The version number 1.7.0
doesn't follow the SemVer policies if it is incompatible. It should have
been 2.0.0.

> 
> Could you please advise how to proceed?

A good start would be to get all of the PTLs for the projects you listed
to express their opinion here on this thread. Part of the point of
freezing is to force coordination when we do need to make exceptions.

Doug

> 
> 
> Thanks
> Witek
> 

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

Re: [openstack-dev] [release] Release countdown for week R-3, Aug 4 - Aug 11

2017-08-03 Thread Dmitry Tantsur


On 08/03/2017 04:50 PM, Doug Hellmann wrote:

Excerpts from Dmitry Tantsur's message of 2017-08-03 16:16:12 +0200:

Hi!

On 08/03/2017 03:03 PM, Thierry Carrez wrote:

Welcome to our regular release countdown email!






Actions
---

Deliverables following the cycle-with-milestones model should post a RC1
openstack/releases request during the week (X.0.0.0rc1), together with a
stable/pike branch request. It should include something like this:

...
- projects:
- hash: YOURHASH
  repo: openstack/YOURPROJECT
  version: YOURVERSION.0.0.0rc1
branches:
- location: YOURVERSION.0.0.0rc1
  name: stable/pike

Deliverables following the cycle-with-intermediary model should also
create their Pike release branch next week. That means potentially
making a last Pike release, and in all cases posting the stable/pike
branch creation request:

...
branches:
- location: YOUR.PIKE.VERSION
  name: stable/pike


https://releases.openstack.org/pike/schedule.html mentions the week after next
(starting Aug 21) to be the last week for cycle-with-intermediary releases. Are
we expected to branch before that? Could you please clarify the hard deadline?


Stable branches are always created from tagged releases. So, you
need to prepare a release to serve as the base of the branch.

Milestone-based projects use an 0rc1 tag for that release, indicating
that it is a release candidate. Those are scheduled for 10 Aug this
cycle.

cycle-with-intermediary projects like Monasca should use a full
regular release as the base of the branch. Those should be created
some time between the RC1 week and that final deadline on 24 Aug.
By selecting the cycle-with-intermediary model, you've indicated
that you want more control over the release process and understand
the risks, so you'll have to decide how to balance the timing of
the branch on your own. Branching too early means you may have to
backport more fixes and may have to make more patch releases.
Branching later means your users have less time to test the released
version that will ship as part of Pike.


Ok, this matches my current expectations.



After 24 Aug, we freeze the release repo for a week to give folks
time to test the last release candidates for milestone-based projects.
Only really critical fixes (installation deletes the entire database,
or infects servers, or whatever) for any project will be released
between 24 Aug and 30 Aug. Normal patch releasing usually resumes the
following week, after we open the requirements repository again.

Releases from master after 24 Aug will be considered part of Queens, not
Pike.

Does that help?


Yes, thanks!



Doug






Upcoming Deadlines & Dates
--

RC1 target deadline (and HardStringFreeze): August 10
Final Pike release: August 30
Queens PTG in Denver: Sept 11-15

As usual come find us on #openstack-release IRC channel if you have any
questions or concerns.





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




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

[openstack-dev] [Designate] PTL Nomination

2017-08-03 Thread Graham Hayes

Hi All,

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

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

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

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

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

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

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

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

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

- Graham Hayes


0x23BA8E2E.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [docs] [training-guides] Moving from Hieroglyph for rendering slides

2017-08-03 Thread Luigi Toscano

On Thursday, 3 August 2017 18:18:31 CEST Pančur, Matjaž wrote:
> Hi all,
> 
> Andreas filed a bug report [1] that can impact what will we use to render
> slides for Upstream University and other training related slide material in
> the future. We’ve already had many discussions at Training guides meetings
> about moving to some other more actively maintained/developed framework for
> slides.
 
> We were leaning towards adopting a widely popular Reveal.js [2]. On the
> downside, that probably also means that we will have to convert slide
> material from RST to MD, as RST is not directly supported. With a shrinking
> (Docs&Training guides) contributors, that could be a problem. 

Maybe you already discussed it, but can't you use pandoc to convert from rst 
to reveal.js?

Ciao
-- 
Luigi


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

Re: [openstack-dev] [release][requirements][barbican][octavia][LBaaS][heat] FFE Request for python-barbicanclient library

2017-08-03 Thread Dave McCowan (dmccowan)



On 8/1/17, 8:02 PM, "Tony Breeds"  wrote:

>On Tue, Aug 01, 2017 at 04:58:22PM -0400, Doug Hellmann wrote:
>> Excerpts from Dave McCowan (dmccowan)'s message of 2017-08-01 20:48:12
>>+:
>> > This note is to request a Feature Freeze Exemption (FFE) for the
>>python-barbicanclient library in Pike.
>> > 
>> > Python-barbicanclient 4.5.0 was intended to be the Pike release.
>>However, after it was released, testing with the Heat and Octavia
>>projects found that it contained an incompatible change resulting in
>>Tracebacks for those projects.
>> > 
>> > The issue was reported in this bug.
>> > https://bugs.launchpad.net/python-barbicanclient/+bug/1706841
>> > 
>> > A first, and partial, attempt to fix this was merged in this patch.
>> > https://review.openstack.org/487721
>> > This patch is included in release 4.5.1.
>> > 
>> > A second, and successful, fix was merged in this patch.
>> > https://review.openstack.org/489518
>> > This patch is included in release 4.5.2.
>> > 
>> > The Barbican team requests a feature freeze exemption for
>>python-barbicanclient release 4.5.2 to be the release for Pike.
>>Releases 4.5.0 and 4.5.1 should be blocked in global requirements.
>> > 
>> > Thanks,
>> > Dave
>> > IRC:dave-mccowan
>> 
>> This sounds reasonable. It's a critical problem but only affects a small
>> number of projects, so the risk is fairly small.
>
>The current users of python-barbicanclient are:
>Package  : python-barbicanclient
>[python-barbicanclient!=4.5.0,>=4.0.0] (used by 16 projects)
>Also affects : 16 projects
>openstack/castellan   []
>openstack/cinder  [tc:approved-release]
>openstack/compute-hyperv  []
>openstack/heat[tc:approved-release]
>openstack/kolla   []
>openstack/magnum  []
>openstack/mistral []
>openstack/neutron-lbaas   []
>openstack/neutron-lbaas-dashboard []
>openstack/nova[tc:approved-release]
>openstack/octavia []
>openstack/octavia-dashboard   []
>openstack/openstackclient []
>openstack/python-openstackclient  []
>openstack/solum   []
>openstack/tacker  []
>
>But IIUC it's really only octavia and heat that don't work with 4.5.x
>
>Looking at the change logs:
>
>[tony@thor python-barbicanclient]$ git log --decorate --oneline
>--no-merges 4.4.0^..HEAD
>714fce2 (HEAD -> master, origin/master, origin/HEAD, gerrit/master)
>Support import modules from barbicanclient.client module
>49505b9 (tag: 4.5.1) Workaround for importing objects from old path
>ea509a5 Update api references according to refactor result
>e0e3703 Add secret_type filter to CLI
>f844a0e Updated from global requirements
>a95c1a1 Update the documentation link for doc migration
>51d8bfa Updated from global requirements
>c497189 fix default version
>3c7d909 Updated from global requirements
>e599dfd Update doc references
>2479529 import content from cli-reference in openstack-manuals
>9af9169 rearrange the existing docs into the new standard layout
>4eed5c8 Switch from oslosphinx to openstackdocstheme
>439ee25 (tag: 4.4.0) Updated from global requirements
>97906c8 Refactor barbicanclient
>
>So all the changes look okay to me, assuming the 4.5.1 and 4.5.2 patches
>work.
>
>> I assume you've done enough testing to feel comfortable that 4.5.2 will
>> work better than 4.5.0 and 4.5.1?
>
>Once we have the release I'll create no-op changes in all the affected
>projects that depend on the u-c bump.
>
>What concerns me a little is that we can't test this without a release
>and once we do the release we're committed to some form of g-r
>alteration with the impacts associated with it.
>
>Would it be terrible to branch stable/pike @ 4.4.0 and leav all the
>4.5.x stuff for queens?

I'm feeling good with the testing now done on 4.5.2 and would prefer to
make that the Pike release.  If we were to revert to 4.4.0 for Pike, we
would be missing at least one feature and the doc changes that were
planned for Pike.

--Dave


__
OpenStack Development Mailing 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] [docs] [training-guides] Moving from Hieroglyph for rendering slides

2017-08-03 Thread Pančur , Matjaž

Hi all,

Andreas filed a bug report [1] that can impact what will we use to render 
slides for Upstream University and other training related slide material in the 
future. We’ve already had many discussions at Training guides meetings about 
moving to some other more actively maintained/developed framework for slides.

We were leaning towards adopting a widely popular Reveal.js [2]. On the 
downside, that probably also means that we will have to convert slide material 
from RST to MD, as RST is not directly supported. With a shrinking 
(Docs&Training guides) contributors, that could be a problem. 

Any other ideas or preferences?

Cheers,
Matjaz


[1] https://bugs.launchpad.net/openstack-training-guides/+bug/1708240
[2] https://github.com/hakimel/reveal.js/
__
OpenStack Development Mailing List (not for 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][ptl][stable][release] stable/pike branches created for most libraries

2017-08-03 Thread Andreas Jaeger

On 2017-08-03 18:03, Jeremy Stanley wrote:
> On 2017-08-03 17:33:46 +0200 (+0200), Andreas Jaeger wrote:
> [...]
>> this would mean that depends-on does not work anymore - if you update
>> the upper-constraint file and want to test, you can use depends-on today.
>>
>> with uploading to tarballs, this will not work,
> 
> I think this is more about the fallback a lot of projects have to
> retrieve constraints files from git.openstack.org directly when not
> already supplied, as a workaround for being able to use constraints
> locally on developers' systems or when deploying software from
> source. Jobs in our CI system would still continue to rely on
> zuul-cloner to place the constraints file where tox is expecting it
> and so Depends-On would remain working the same way it does
> presently.

Indeed, if the CI system continues to use zuul-cloner, everything is fine,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for 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] review.openstack.org downtime and Gerrit upgrade

2017-08-03 Thread Clark Boylan

On Thu, Aug 3, 2017, at 09:11 AM, Markus Zoeller wrote:
> On 03.08.2017 00:57, Clark Boylan wrote:
> > Hello,
> > 
> > The Infra team is planning to upgrade review.openstack.org from Gerrit
> > 2.11 to Gerrit 2.13 on September 18, 2017. 
> > [...]
> > 
> > If you have any concerns or feedback please let the Infra team know.
> > 
> > Thank you,
> > Clark
> 
> Does this maybe include the "hashtag" feature [1] to assign a custom
> taxonomy to changes? We talked about that back in 2015 [2].
> After reading [3] I was still a little clueless, TBH.
> 
> [1] https://en.wikipedia.org/wiki/Tag_(metadata)
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/079835.html
> [3] https://phabricator.wikimedia.org/T37534
> 

My understanding is that the Gerrit hashtag feature requires notedb
which is part of the 2.14 release not the 2.13 release. We won't have it
after this upgrade but should have it once we get to 2.14.

Clark

__
OpenStack Development Mailing List (not for 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] review.openstack.org downtime and Gerrit upgrade

2017-08-03 Thread Clark Boylan

On Thu, Aug 3, 2017, at 03:04 AM, Andrey Kurilin wrote:
> hi Clark,
> 
> Do you have any plans to update to 2.14 release which has a new polymer
> based user interface?
>

We decided to not try and go straight to 2.14 because it requires newer
java and introduces the notedb which is a fairly large change in how
Gerrit stores information. The hope is that by going to 2.13 we can get
an upgrade done more quickly which can then hopefully snowball into an
easier upgrade to 2.14 in the not too distant future.

Once 2.13 is done my goal is to upgrade the database behind Gerrit and
the base operating system which will put us in good position to upgrade
to 2.14. But it is still too early to know how quickly that can all
happen.

Clark

__
OpenStack Development Mailing List (not for 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] review.openstack.org downtime and Gerrit upgrade

2017-08-03 Thread Markus Zoeller

On 03.08.2017 00:57, Clark Boylan wrote:
> Hello,
> 
> The Infra team is planning to upgrade review.openstack.org from Gerrit
> 2.11 to Gerrit 2.13 on September 18, 2017. 
> [...]
> 
> If you have any concerns or feedback please let the Infra team know.
> 
> Thank you,
> Clark

Does this maybe include the "hashtag" feature [1] to assign a custom
taxonomy to changes? We talked about that back in 2015 [2].
After reading [3] I was still a little clueless, TBH.

[1] https://en.wikipedia.org/wiki/Tag_(metadata)
[2]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/079835.html
[3] https://phabricator.wikimedia.org/T37534

-- 
Regards, Markus Zoeller (markus_z)


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

Re: [openstack-dev] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

2017-08-03 Thread witold.be...@est.fujitsu.com

> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: Donnerstag, 3. August 2017 15:45
> To: openstack-dev 
> Subject: Re: [openstack-dev]
> [ffe][requirements][monasca][heat][watcher][congress] FFE for python-
> monascaclient minimum version in g-r
> 
> Excerpts from witold.be...@est.fujitsu.com's message of 2017-08-03
> 11:39:47 +:
> > Hello everyone,
> >
> > I would like to ask for the FFE for python-monascaclient version in global
> requirements.
> >
> > The current version in Pike (1.7.0) is not fully backward compatible. The
> monasca exception classes were replaced with keystoneauth exceptions,
> which affects heat and watcher projects if they use current upper
> constraints. The fixes for these projects have been submitted [1, 2].
> >
> > Also, monasca projects (monasca-agent, monasca-ui, monasca-api) rely on
> python-monascaclient 1.7.0 and don't work with older versions.
> >
> > The change for bumping the minimum version of python-monascaclient is
> here:
> >
> > https://review.openstack.org/489173
> >
> >
> > Best greetings
> > Witek Bedyk
> >
> >
> > [1] https://review.openstack.org/490016
> > [2] https://review.openstack.org/490018
> >
> 
> It is rather late to be raising the minimum allowed version of a library due 
> to
> backwards incompatibilities. Can you provide more details about which
> projects will be impacted (both by updating, and by not updating)?


Hi Doug,

I know it's very unfortunate to raise it so late. We haven't paid enough 
attention when merging the osc-lib integration to monascaclient. I'm sorry for 
that.

If we update g-r impacted projects are:
* Congress
* Heat
* Watcher
For Heat and Watcher we have provided above referenced changes. Congress should 
work with both, old and new versions, from what we've checked.
Rally and Freezer-dr do not follow g-r. Fix for Rally has already been merged 
[1]. Freezer-dr should not be impacted.

If we don't update g-r the impacted projects are again:
* Heat
* Watcher
The teams don't want to merge compatibility fixes until requirements are 
raised. Please refer to the reviews from the first message. Without these fixes 
monascaclient from upper-constraints does not work for them.

The change in g-r does not alter u-c.


[1] https://review.openstack.org/486015


> 
> How can it be that the Monasca services already rely on the features of this
> version? Are they not following the constraints process, so they use the
> same versions of the libraries all of the other projects use?
> 
> Doug


I'm not sure if I know what you mean. We do use upper-constraints for 
installation and testing. The new version is in u-c.

Could you please advise how to proceed?


Thanks
Witek




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

Re: [openstack-dev] [openstack-ansible][security] To firewalld, or not to firewalld

2017-08-03 Thread Logan V.

Ferm DSL is nice and featureful. There's a pretty sophisticated debops
ferm role at [1] allowing for pretty sophisticated rule definitions
[2]. Structurally I think the most important thing is having the
ability to define rules in layers based on host_vars, group_vars, etc.
and have them blended together by the firewall role using a weighting
system. You can get really fancy with the rules definitions as shown
by the rules.d template in debops-ferm [3].

My question now is what does ferm give us that iptables-save
templating does not? Writing ferm configuration can differ pretty
substantially from iptables-save syntax, and we add another language
dependency (perl) in the process. I think for ferm to make sense, we
should be able to argue pretty convincingly that there's some major
advantages over laying down a consolidated templated iptables-save
file. IMO we can have all of the same sophistication this way and
expose it in a very nice interface through ansible vars.

[1] https://github.com/debops/ansible-ferm
[2] https://docs.debops.org/en/latest/ansible/roles/ansible-ferm/docs/
[3] https://github.com/debops/ansible-ferm/tree/master/templates/etc/ferm

On Wed, Aug 2, 2017 at 3:47 PM, Major Hayden  wrote:
> On 08/02/2017 03:57 AM, Mark Goddard wrote:
>> The solution we built used a conf.d/ mechanism layered on top of iptables. 
>> An advantage of this approach is that operators or co-resident software 
>> stacks could add their own rules to the firewall. AFAIK, this is not 
>> generally possible when using iptables-save/restore as it relies on a single 
>> configuration file which must be 'owned' by something - in this case 
>> presumably OSA.
>>
>> I'm not suggesting that you reimplement the solution I've described, but it 
>> does outline one benefit of firewalld - OSA would not need to entirely own 
>> the firewall configuration.
>
> Thanks for the feedback!  I'm leaning away from firewalld now and looking at 
> something a little simpler with iptables.
>
> During a recent IRC meeting someone brought up ferm[0]. They have several 
> examples, but the workstation[1] one makes some sense. It would be fairly 
> easy to template the ferm DSL files.
>
> [0] http://ferm.foo-projects.org/
> [1] http://ferm.foo-projects.org/download/examples/webserver.ferm
>
> --
> Major Hayden
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all][ptl][stable][release] stable/pike branches created for most libraries

2017-08-03 Thread Jeremy Stanley

On 2017-08-03 17:33:46 +0200 (+0200), Andreas Jaeger wrote:
[...]
> this would mean that depends-on does not work anymore - if you update
> the upper-constraint file and want to test, you can use depends-on today.
> 
> with uploading to tarballs, this will not work,

I think this is more about the fallback a lot of projects have to
retrieve constraints files from git.openstack.org directly when not
already supplied, as a workaround for being able to use constraints
locally on developers' systems or when deploying software from
source. Jobs in our CI system would still continue to rely on
zuul-cloner to place the constraints file where tox is expecting it
and so Depends-On would remain working the same way it does
presently.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [all][ptl][stable][release] stable/pike branches created for most libraries

2017-08-03 Thread Andreas Jaeger

On 2017-08-03 17:04, Doug Hellmann wrote:
> Excerpts from Tony Breeds's message of 2017-08-03 12:43:04 +1000:
>> On Mon, Jul 31, 2017 at 08:00:22AM -0400, Doug Hellmann wrote:
>>> Excerpts from Dmitry Tantsur's message of 2017-07-29 20:06:18 +0200:
 Just to clarify: we cannot land the tox.ini change until the requirements 
 repo 
 is actually branched, right?
>>>
>>> Good point. The tests for those patches are passing for some projects in
>>> CI, but when the patches are landed it will make it a little harder for
>>> anyone to run the tests for the branch elsewhere because the
>>> requirements repo has not yet been branched.
>>>
>>> So, yes, hold off on landing the constraint URL changes.
>>
>> I wonder if we should look at publishing the upper-constraints.txt file
>> somewhere (other than cgit).  If we did something like:
>>
>> tarballs.o.o/constraints/$series.txt
>>
>> We wouldn't have an issue when we EOL a branch and the url's hard-coded
>> in tox.ini breaking.  queens.txt wouldn't exist until we branch
>> requirements but we could work around that with a redirect if needed.
> 
> I like the idea of publishing to a branch-specific file that always
> stays on the server. We could make the job on master publish both
> to a master.txt and a $series.txt file if we need both to exist at the
> same time.

this would mean that depends-on does not work anymore - if you update
the upper-constraint file and want to test, you can use depends-on today.

with uploading to tarballs, this will not work,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

Excerpts from Tony Breeds's message of 2017-08-03 12:20:24 +1000:
> On Thu, Jul 27, 2017 at 07:05:16PM -0400, Doug Hellmann wrote:
>  
> > That content will now live in the project trees. Perhaps part of marking
> > branches in those repos EOL needs to include deleting the install tree
> > from the docs? Now that the docs are in a standard location, that could
> > be part of an EOL script (although it means 2 phases, since we have to
> > land the patch and let the docs rebuild before we remove the branch).
> 
> That can be done.  It's a bit of a pain but for the most part the gate
> is pretty stable at EOL time.  I do worry about what we do if $projects
> gate is broken and can't generate/publish the docs.
>  
> > We could also update the openstack-manuals tree to not publish links
> > to the install guides (either removing the page or replacing it
> > with a placeholder that explains they should be trying to use a
> > newer version).
> 
> That'd work too.  I kinda like that option better.

Yes, that's easy to do with 1 patch to the openstack-manuals repo.

Doug

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

Re: [openstack-dev] [all][ptl][tc] IMPORTANT upcoming change to technical elections


> On Aug 2, 2017, at 10:53 PM, Jeremy Stanley  wrote:
> 
> On 2017-07-17 16:17:00 + (+), Jeremy Stanley wrote:
>> If you want to run or vote in upcoming elections for PTL and TC,
>> make sure your Foundation Individual Membership is active and has at
>> least one Email address which matches an Email address in your
>> Gerrit account: log in at https://www.openstack.org/profile/ and
>> check that it says "Current Member Level: Foundation Member" near
>> the top and that at least one of the Primary, Second or Third Email
>> Address fields contains an address which matches at least one of the
>> entries available in the Preferred Email drop-down at
>> https://review.openstack.org/#/settings/contact (case sensitivity
>> doesn't matter but they at least need to be spelled the same).
>> 
>> If you're an "extra-ATC" and don't have a Gerrit account (this is
>> common for translators on the I18n team) then you still need to be a
>> Foundation Member to participate in technical elections and should
>> make sure your member profile includes the Email address listed for
>> you on your team's page at
>> https://governance.openstack.org/tc/reference/projects/ .
> [...]
> 
> For those who haven't double-checked their memberships, I am
> attaching a list of OpenStack Foundation Individual Member IDs and
> names for contributors to official deliverable repositories between
> 2016-09-17 and the present (members.txt.gz, 2315 entries in total,
> these should be eligible to vote in elections for projects to which
> they contributed if a runoff is held). I'm also attaching a list of
> the names of contributors over the same time period who could not be
> automatically matched up to foundation membership profiles
> (nonmembers.txt.gz, 291 entries in total).
> 
> If you want to vote in upcoming elections and your membership isn't
> lining up with your contributor account/addresses (that is to say,
> your name is in the attached nonmembers.txt.gz file) then please
> follow the quoted instructions above from my earlier message as soon
> as possible.
> 
> Should you have any trouble reading the attached compressed lists,
> you can also view them in a browser at the following URLs:
> 
>members.txt - http://paste.openstack.org/raw/617357/
> 
>nonmembers.txt - http://paste.openstack.org/raw/617358/
> 

I had a quick look at that nonmembers.txt list and noticed several 
long-standing members of our community are included. PLEASE EVERYONE go check 
your settings so you are not left out of this election.

Doug

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



signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for 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][ptl][stable][release] stable/pike branches created for most libraries

Excerpts from Tony Breeds's message of 2017-08-03 12:43:04 +1000:
> On Mon, Jul 31, 2017 at 08:00:22AM -0400, Doug Hellmann wrote:
> > Excerpts from Dmitry Tantsur's message of 2017-07-29 20:06:18 +0200:
> > > Just to clarify: we cannot land the tox.ini change until the requirements 
> > > repo 
> > > is actually branched, right?
> > 
> > Good point. The tests for those patches are passing for some projects in
> > CI, but when the patches are landed it will make it a little harder for
> > anyone to run the tests for the branch elsewhere because the
> > requirements repo has not yet been branched.
> > 
> > So, yes, hold off on landing the constraint URL changes.
> 
> I wonder if we should look at publishing the upper-constraints.txt file
> somewhere (other than cgit).  If we did something like:
> 
> tarballs.o.o/constraints/$series.txt
> 
> We wouldn't have an issue when we EOL a branch and the url's hard-coded
> in tox.ini breaking.  queens.txt wouldn't exist until we branch
> requirements but we could work around that with a redirect if needed.

I like the idea of publishing to a branch-specific file that always
stays on the server. We could make the job on master publish both
to a master.txt and a $series.txt file if we need both to exist at the
same time.

> Later we could get really crazy and make a version that took a package
> name and version perhaps like:
> 
> tarballs.o.o/constraints/$(python setup.py --name)/$(python setup.py 
> --version)
> 
> Which would redirect to the appropriate series file.  I think we have
> enough data in openstack/releases to generate those redirects.  We'd
> need to think about projects / repos that don't use the release
> infrastructure.

How would that redirect be used?

> 
> That'd mean we could get way from hard-coding the URLs in tox.ini and
> therefore not need to update them at branch time.
> 
> I've either had too much coffee or not enough.  y'all decide.
> 
> Yours Tony.

__
OpenStack Development Mailing List (not for 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][packaging][deb] retiring Packaging Deb project

Excerpts from Allison Randal's message of 2017-08-03 10:09:59 -0400:
> Hi all,
> 
> The Debian OpenStack packagers are gathered at the annual Debian
> developer event, and discussing the future of OpenStack packaging for
> Debian. There's general agreement that we'd like to go ahead and package
> Pike, but also agreement that we'd like to move back to the Debian
> infrastructure for doing packaging work. There are a variety of reasons,
> including that:
> 
> - Using the familiar Debian workflows and infrastructure is a better way
> to attract experienced Debian developers to the work, and
> 
> - The way we set up the Debian packaging workflow on OpenStack Infra was
> a temporary compromise, and not really a good fit for OpenStack Infra
> (or for Debian).

Moving to more standard Debian workflows and infrastructure make a lot
of sense. If there are tools to be shared, those don't necessarily have
to live on an openstack.org git repo to be useful.

> As a result of the change, we'd like to retire the Packaging Deb
> project in OpenStack, and there will be no candidate running for Queens
> PTL for the project. There will be some cleanup work to do, around
> deb-* repos and other aspects of the Debian packaging workflow we set up
> with OpenStack Infra, following the standard retirement procedures:
> 
> https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
> 
> The OpenStack installation tutorial for Debian will remain in OpenStack,
> and we'll update it for Pike.

To be clear, there is no longer one installation guide. As part of
the doc-migration project, most of the content has moved into project
trees. Some is still being moved, and some shared content related
to tasks such as installing foundation services like rabbit is in
the openstack-manuals repository.

https://docs.openstack.org/pike/install/ links to all the published
installation guides. We do not currently have separate pages that link
to the relevant sections for a given OS.

Doug

> If you have any concerns about the retirement, please let us know
> (especially other distros that use .deb format packages), we'll wait a
> bit for feedback before moving ahead with the cleanup.
> 
> Thanks,
> Allison
> 

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

Re: [openstack-dev] [release] Release countdown for week R-3, Aug 4 - Aug 11

Excerpts from Dmitry Tantsur's message of 2017-08-03 16:16:12 +0200:
> Hi!
> 
> On 08/03/2017 03:03 PM, Thierry Carrez wrote:
> > Welcome to our regular release countdown email!
> > 
> 
> > 
> > 
> > Actions
> > ---
> > 
> > Deliverables following the cycle-with-milestones model should post a RC1
> > openstack/releases request during the week (X.0.0.0rc1), together with a
> > stable/pike branch request. It should include something like this:
> > 
> > ...
> >- projects:
> >- hash: YOURHASH
> >  repo: openstack/YOURPROJECT
> >  version: YOURVERSION.0.0.0rc1
> > branches:
> >- location: YOURVERSION.0.0.0rc1
> >  name: stable/pike
> > 
> > Deliverables following the cycle-with-intermediary model should also
> > create their Pike release branch next week. That means potentially
> > making a last Pike release, and in all cases posting the stable/pike
> > branch creation request:
> > 
> > ...
> > branches:
> >- location: YOUR.PIKE.VERSION
> >  name: stable/pike
> 
> https://releases.openstack.org/pike/schedule.html mentions the week after 
> next 
> (starting Aug 21) to be the last week for cycle-with-intermediary releases. 
> Are 
> we expected to branch before that? Could you please clarify the hard deadline?

Stable branches are always created from tagged releases. So, you
need to prepare a release to serve as the base of the branch.

Milestone-based projects use an 0rc1 tag for that release, indicating
that it is a release candidate. Those are scheduled for 10 Aug this
cycle.

cycle-with-intermediary projects like Monasca should use a full
regular release as the base of the branch. Those should be created
some time between the RC1 week and that final deadline on 24 Aug.
By selecting the cycle-with-intermediary model, you've indicated
that you want more control over the release process and understand
the risks, so you'll have to decide how to balance the timing of
the branch on your own. Branching too early means you may have to
backport more fixes and may have to make more patch releases.
Branching later means your users have less time to test the released
version that will ship as part of Pike.

After 24 Aug, we freeze the release repo for a week to give folks
time to test the last release candidates for milestone-based projects.
Only really critical fixes (installation deletes the entire database,
or infects servers, or whatever) for any project will be released
between 24 Aug and 30 Aug. Normal patch releasing usually resumes the
following week, after we open the requirements repository again.

Releases from master after 24 Aug will be considered part of Queens, not
Pike.

Does that help?

Doug

> 
> > 
> > 
> > Upcoming Deadlines & Dates
> > --
> > 
> > RC1 target deadline (and HardStringFreeze): August 10
> > Final Pike release: August 30
> > Queens PTG in Denver: Sept 11-15
> > 
> > As usual come find us on #openstack-release IRC channel if you have any
> > questions or concerns.
> > 
> 

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

Re: [openstack-dev] [Horizon][Nova] Editing flavor causing instance flavor display error

2017-08-03 Thread Chris Friesen


On 08/03/2017 04:21 AM, Sean Dague wrote:

On 08/03/2017 06:13 AM, Zhenyu Zheng wrote:

I was thinking, the current "edit" in Horizon is delete-and-create, and
it is there maybe just because
flavor has many fields, user may want to have a new flavor but just
modify one of the old flavor, so
they don't want to manually copy all other fields. And it is the
automatic delete action that causes
all the problem. Maybe horizon can provide a copy-and-modify action and
leave the deletion of
the flavor to the admin.


For what it is worth, it is already an admin level permission.

I do think that "Copy and Modify" is a better paradigm. Or "New Flavor
based on X" which will prefill based on an existing one.

The Delete flavor button should come with a giant warning of "This will
make a lot of information in your environment confusing, you should
never do this".


The same could also be said for flavor extra-specs (which can be modified 
in-place).  Once they're configured and the flavor is made public it would be 
best to leave them untouched otherwise you could end up confusing people if the 
behaviour of the "same" flavor changes due to extra-specs changes.


Chris


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

Re: [openstack-dev] [refstack][interop-wg] Non-candidacy for RefStack PTL

2017-08-03 Thread David.Paterson

Dell - Internal Use - Confidential

You've done a great job Catherine, thank you!
dp

From: Catherine Cuong Diep [mailto:cd...@us.ibm.com]
Sent: Wednesday, August 2, 2017 3:15 PM
To: 
openstack-dev@lists.openstack.org; 
interop...@lists.openstack.org
Subject: [openstack-dev] [refstack][interop-wg] Non-candidacy for RefStack PTL

Hi Everyone,

As I had announced in the RefStack IRC meeting a few weeks ago, I will not run 
for RefStack PTL in the upcoming cycle. I have been PTL for the last 2 years 
and it is time to pass the torch to a new leader.

I would like to thanks everyone for your support and contribution to make the 
RefStack project and interoperability testing a reality. We would not be where 
we are today without your
commitment and dedication.

I will still be around to help the project and to work with the next PTL for a 
smooth transition.

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

Re: [openstack-dev] [release] Release countdown for week R-3, Aug 4 - Aug 11

2017-08-03 Thread Dmitry Tantsur


Hi!

On 08/03/2017 03:03 PM, Thierry Carrez wrote:

Welcome to our regular release countdown email!






Actions
---

Deliverables following the cycle-with-milestones model should post a RC1
openstack/releases request during the week (X.0.0.0rc1), together with a
stable/pike branch request. It should include something like this:

...
   - projects:
   - hash: YOURHASH
 repo: openstack/YOURPROJECT
 version: YOURVERSION.0.0.0rc1
branches:
   - location: YOURVERSION.0.0.0rc1
 name: stable/pike

Deliverables following the cycle-with-intermediary model should also
create their Pike release branch next week. That means potentially
making a last Pike release, and in all cases posting the stable/pike
branch creation request:

...
branches:
   - location: YOUR.PIKE.VERSION
 name: stable/pike


https://releases.openstack.org/pike/schedule.html mentions the week after next 
(starting Aug 21) to be the last week for cycle-with-intermediary releases. Are 
we expected to branch before that? Could you please clarify the hard deadline?





Upcoming Deadlines & Dates
--

RC1 target deadline (and HardStringFreeze): August 10
Final Pike release: August 30
Queens PTG in Denver: Sept 11-15

As usual come find us on #openstack-release IRC channel if you have any
questions or concerns.




__
OpenStack Development Mailing 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][packaging][deb] retiring Packaging Deb project

2017-08-03 Thread Allison Randal

Hi all,

The Debian OpenStack packagers are gathered at the annual Debian
developer event, and discussing the future of OpenStack packaging for
Debian. There's general agreement that we'd like to go ahead and package
Pike, but also agreement that we'd like to move back to the Debian
infrastructure for doing packaging work. There are a variety of reasons,
including that:

- Using the familiar Debian workflows and infrastructure is a better way
to attract experienced Debian developers to the work, and

- The way we set up the Debian packaging workflow on OpenStack Infra was
a temporary compromise, and not really a good fit for OpenStack Infra
(or for Debian).

As a result of the change, we'd like to retire the Packaging Deb
project in OpenStack, and there will be no candidate running for Queens
PTL for the project. There will be some cleanup work to do, around
deb-* repos and other aspects of the Debian packaging workflow we set up
with OpenStack Infra, following the standard retirement procedures:

https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

The OpenStack installation tutorial for Debian will remain in OpenStack,
and we'll update it for Pike.

If you have any concerns about the retirement, please let us know
(especially other distros that use .deb format packages), we'll wait a
bit for feedback before moving ahead with the cleanup.

Thanks,
Allison

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

[openstack-dev] [QA] Queens PTL candidacy

2017-08-03 Thread Andrea Frittoli

Dear all,

I’d like to announce my candidacy for PTL of the QA Program for the Queens
cycle [0].

I served as PTL for QA during the Pike cycle, and I would be honoured to
continue to do so in the next six months.

After a few years working with the OpenStack community, I continue to find
it an exceptional experience and great opportunity for meeting and working
with great people, learning and innovating.

My priority is to provide, as a QA team, an excellent service to the
OpenStack community: stable gates (based on the great infrastructure
maintained by the infra team); easy to use and well documented tools to
enable project teams to achieve their quality goals; support and attention
to the community needs.

We have limited resources to achieve all that and I would like to counter
that by:
- mentorning new and existing contributors
- investing in automation to make the day to day maintainence less onerous
- making QA tools beneficial beyond OpenStack to attract contributors from
  other communities

Thank you!

Andrea Frittoli (andreaf)

[0] https://review.openstack.org/#/c/490477/
__
OpenStack Development Mailing 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] [Kuryr] Queens PTL candidacy

2017-08-03 Thread Antoni Segura Puimedon

Hi fellow kuryrs!

I present my PTL candidacy for the Queens Cycle.

We've done well in this past cycle getting close to our first release
adding things like:
- Kubernetes service support,
- Token authentication support,
- A lot of devstack improvements like multinode
- pod-in-VM neutron trunk and macvlan support
- Resource pooling
- Octavia support

Also some things that are in-flight and that may still make it in this
cycle or early next:
- CNI split
- Containerized deployment with daemonsets
- SR-IOV support

In this new upcoming cycle I would like to bring the following things:
- Full multi-network support consistent with upstream design
- High Availability (active - active) controllers
- Controller Health and Readiness checks
- SR-IOV support
- Network Policy
- Ingress controllers

I am very thankful for all the people and organizations that have
contributed not only in code, but also in reviews, documentation,
blueprints, bugs and discussion. Serving as PTL this last cycle has
been a great pleasure and I would love to serve again.

Regards,

Toni

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

Re: [openstack-dev] [monasca] Stable branch for Pike

Excerpts from witold.be...@est.fujitsu.com's message of 2017-08-03 13:27:14 
+:
> Hello Monasca team,
> 
> Following the Pike release schedule I would like to cut the stable branch for 
> Pike release early next week. We will use it to create the final release at 
> the end of August.
> 
> Please let me know of release-critical bugs which should be merged before.
> 
> 
> Cheers
> Witek
> 

Please coordinate with the release team to create the stable branches
based on your release candidates.

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] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

Excerpts from witold.be...@est.fujitsu.com's message of 2017-08-03 11:39:47 
+:
> Hello everyone,
> 
> I would like to ask for the FFE for python-monascaclient version in global 
> requirements.
> 
> The current version in Pike (1.7.0) is not fully backward compatible. The 
> monasca exception classes were replaced with keystoneauth exceptions, which 
> affects heat and watcher projects if they use current upper constraints. The 
> fixes for these projects have been submitted [1, 2].
> 
> Also, monasca projects (monasca-agent, monasca-ui, monasca-api) rely on 
> python-monascaclient 1.7.0 and don't work with older versions.
> 
> The change for bumping the minimum version of python-monascaclient is here:
> 
> https://review.openstack.org/489173
> 
> 
> Best greetings
> Witek Bedyk
> 
> 
> [1] https://review.openstack.org/490016
> [2] https://review.openstack.org/490018
> 

It is rather late to be raising the minimum allowed version of a
library due to backwards incompatibilities. Can you provide more
details about which projects will be impacted (both by updating,
and by not updating)?

How can it be that the Monasca services already rely on the features
of this version? Are they not following the constraints process,
so they use the same versions of the libraries all of the other
projects use?

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] [monasca] Stable branch for Pike

2017-08-03 Thread witold.be...@est.fujitsu.com

Hello Monasca team,

Following the Pike release schedule I would like to cut the stable branch for 
Pike release early next week. We will use it to create the final release at the 
end of August.

Please let me know of release-critical bugs which should be merged before.


Cheers
Witek

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

Re: [openstack-dev] [release] Release countdown for week R-3, Aug 4 - Aug 11

Excerpts from Thierry Carrez's message of 2017-08-03 15:03:59 +0200:

> Actions
> ---
> 
> Deliverables following the cycle-with-milestones model should post a RC1
> openstack/releases request during the week (X.0.0.0rc1), together with a
> stable/pike branch request. It should include something like this:
> 
> ...
>   - projects:
>   - hash: YOURHASH
> repo: openstack/YOURPROJECT
> version: YOURVERSION.0.0.0rc1
> branches:
>   - location: YOURVERSION.0.0.0rc1
> name: stable/pike
> 
> Deliverables following the cycle-with-intermediary model should also
> create their Pike release branch next week. That means potentially
> making a last Pike release, and in all cases posting the stable/pike
> branch creation request:
> 
> ...
> branches:
>   - location: YOUR.PIKE.VERSION
> name: stable/pike

It would be really REALLY good for project teams to finish landing the
doc-migration patches before branching. Otherwise, you will have to
backport all of the doc changes to the stable branch in order for them
to show up in the Pike documentation.

Doug

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

[openstack-dev] [release] Release countdown for week R-3, Aug 4 - Aug 11

2017-08-03 Thread Thierry Carrez

Welcome to our regular release countdown email!

Development Focus
-

Focus should be on the last Pike release-critical bugs, in order to
produce the first Pike release candidates sometimes during the week.


General Information
---

We are at the point in the cycle where release branches should be cut.
The stable/pike branch will track the Pike release, while the master
branch will switch to Queens development (and no longer be feature-frozen).

Future release candidates (or last-minute point releases fixing critical
issues) will be cut from those release branches. Fixes first need to
land in the master branch (so that we don't inadvertantly create a
regression in Queens), then be backported to stable/pike before the new
release candidate is tagged.


Actions
---

Deliverables following the cycle-with-milestones model should post a RC1
openstack/releases request during the week (X.0.0.0rc1), together with a
stable/pike branch request. It should include something like this:

...
  - projects:
  - hash: YOURHASH
repo: openstack/YOURPROJECT
version: YOURVERSION.0.0.0rc1
branches:
  - location: YOURVERSION.0.0.0rc1
name: stable/pike

Deliverables following the cycle-with-intermediary model should also
create their Pike release branch next week. That means potentially
making a last Pike release, and in all cases posting the stable/pike
branch creation request:

...
branches:
  - location: YOUR.PIKE.VERSION
name: stable/pike


Upcoming Deadlines & Dates
--

RC1 target deadline (and HardStringFreeze): August 10
Final Pike release: August 30
Queens PTG in Denver: Sept 11-15

As usual come find us on #openstack-release IRC channel if you have any
questions or concerns.

-- 
Thierry Carrez (ttx)




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

[openstack-dev] [magnum] spec for cluster federation

2017-08-03 Thread Ricardo Rocha

Hi.

We've recently started looking at federating kubernetes clusters,
using some of our internal Magnum clusters and others deployed in
external clouds. With kubernetes 1.7 most of the functionality we need
is already available.

Looking forward we submitted a spec to integrate this into Magnum:
https://review.openstack.org/#/c/489609/

We will work on this once it gets approved, but please review the spec
and provide feedback.

Regards,
  Ricardo

__
OpenStack Development Mailing 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] [Mogan] Queens PTL candidacy

2017-08-03 Thread Zhenguo Niu

Hi all,

I would like to announce my candidacy for the Mogan PTL for the Queens
cycle. Although Mogan is not an official project yet, we seek to complete
the PTL election with everyone’s consensus like others.



I have been the elected PTL since Mogan was an idea. I think that Mogan
serves an important role in current OpenStack ecosystem and solve problems
that many users are facing. Mogan is relatively new project but I am proud
to say that we already have a diverse community and feel that we operate
openly and advancing in the right direction.



If I’m getting an opportunity to continue serving the team for the Queens
cycle, I’d strive to work with the team on the following items:



- Support RAID at deploy time

- Boot from volume and Migrate/Resize support for such diskless servers

- Change to use nested resources model for bare metals in placement to
track NICs and DISKs as well.

- Improve bare metal node aggregates support by leveraging Placement service

- Add more policies for bare metal server groups

- Valence integration to support composing hardware



We will follow the official procedure. Any self nominations need be in
within a week from now. If there are more than one candidate we will create
a poll on http://civs.cs.cornell.edu/ .


-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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] [elections][vitrage] Queens PTL candidacy

2017-08-03 Thread Afek, Ifat (Nokia - IL/Kfar Sava)

Hi All,

I would like to announce my candidacy for the Vitrage PTL for the Queens 
release.

I've been leading the Vitrage project development from the day it started, two
years ago. During this time we have made a tremendous progress, and now we have
a stable, well-known project that is running in production. We have an amazing
group of contributors and a growing community. I'm proud to say that we managed
to achieve most of our goals so far, and I hope we will continue achieving our
goals in Queens release as well.

The Pike cycle has been very productive. We added some important features like
the integration with Mistral, SNMP notifications, enhancements in the evaluator
templates (entity equivalence and 'not' operator), resource query API, and more.

As for the Queens cycle, I think we should focus on the Vitrage productization,
stability and use cases.

- Alarm History. The work on this feature has started in Pike cycle, and should
  be finished in Queens.
- Vitrage notifications. Add a REST API for registering to notifications from 
Vitrage.
- Integrate with more projects, OpenStack and external. We should enrich our
  topology with more information, so we can provide more meaningful insights on
  the status of the cloud.
- Enhance the Vitrage UI and improve its usability.
- Enrich the evaluator template language (add regular expressions, etc.), and
  support templates CRUD.
- Continue our efforts in the area of Machine Learning. Develop more algorithms
  that will provide insights about alarm correlation and causation.
- Extend the Vitrage community. I'll be happy to see more contributors joining
  our effort.

Looking forward to working with you during the Queens cycle!

Thanks,
Ifat.




__
OpenStack Development Mailing 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] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

2017-08-03 Thread witold.be...@est.fujitsu.com

Hello everyone,

I would like to ask for the FFE for python-monascaclient version in global 
requirements.

The current version in Pike (1.7.0) is not fully backward compatible. The 
monasca exception classes were replaced with keystoneauth exceptions, which 
affects heat and watcher projects if they use current upper constraints. The 
fixes for these projects have been submitted [1, 2].

Also, monasca projects (monasca-agent, monasca-ui, monasca-api) rely on 
python-monascaclient 1.7.0 and don't work with older versions.

The change for bumping the minimum version of python-monascaclient is here:

https://review.openstack.org/489173


Best greetings
Witek Bedyk


[1] https://review.openstack.org/490016
[2] https://review.openstack.org/490018

__
OpenStack Development Mailing 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] ptl for queens

2017-08-03 Thread James Page

Hi All

I would like to announce my candidacy for PTL of the OpenStack Charms
project
for the Queens development cycle.

We've made some good progress during the Pike cycle in terms of improving
documentation, with a new deployment guide in the works which should make
things
much easier for new users of the OpenStack Charms going forwards; There is
still
work todo here and that's something I want to make sure we focus on during
the
next development cycle.

We also have a number of cleanups that need to be completed; ZeroMQ and
PostgreSQL
support in the charms are obsolete and not covered by any testing so should
be
dropped during Queens.  We also need to make the jump to Python 3 by default
across all charms.

I look forward to steering the helm for another cycle!

Cheers

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

Re: [openstack-dev] [cinder] Apply for exception to having Storwize cinder Tiramisu replication patch reviewed and merged

2017-08-03 Thread Xiao Qin SH Li

Hi Sean
 
Thanks a lot for your response.  And we will make it in Q release.
Regards
Xiao Qin Li
Cloud Storage Solutions DevelopmentIBM China Systems & Technology Laboratory in ShanghaiEmail: lix...@cn.ibm.comTel: 86-21-609289553/F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New District, Shanghai 201203
 
 
- Original message -From: Sean McGinnis To: "OpenStack Development Mailing List (not for usage questions)" Cc: Yi Ming YZ Zhang Subject: Re: [openstack-dev] [cinder] Apply for exception to having Storwize cinder Tiramisu replication patch reviewed and mergedDate: Wed, Aug 2, 2017 10:58 PM 
This patch was Workflow-1 until after the feature freeze date.At this point I think we will need to wait until Queens opensup to get this through.SeanOn Wed, Aug 02, 2017 at 12:07:06PM +, Xiao Qin SH Li wrote:>  > Hi all,>  > There is a Tiramisu replication patch for IBM storwize cinder https://review.openstack.org/#/c/469394. Since it is already passed Pike-3, the deadline for new features. We would like to check if there's a chance to get an exception to have it reviewed and merged?>  > Thanks a lot!> Regards> Xiao Qin Li> Cloud Storage Solutions DevelopmentIBM China Systems & Technology Laboratory in ShanghaiEmail: lix...@cn.ibm.comTel: 86-21-609289553/F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New District, Shanghai 201203>>> __> OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

Re: [openstack-dev] [Horizon][Nova] Editing flavor causing instance flavor display error

On 08/03/2017 06:13 AM, Zhenyu Zheng wrote:
> I was thinking, the current "edit" in Horizon is delete-and-create, and
> it is there maybe just because
> flavor has many fields, user may want to have a new flavor but just
> modify one of the old flavor, so
> they don't want to manually copy all other fields. And it is the
> automatic delete action that causes
> all the problem. Maybe horizon can provide a copy-and-modify action and
> leave the deletion of
> the flavor to the admin.

For what it is worth, it is already an admin level permission.

I do think that "Copy and Modify" is a better paradigm. Or "New Flavor
based on X" which will prefill based on an existing one.

The Delete flavor button should come with a giant warning of "This will
make a lot of information in your environment confusing, you should
never do this".

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Horizon][Nova] Editing flavor causing instance flavor display error

2017-08-03 Thread Zhenyu Zheng

I was thinking, the current "edit" in Horizon is delete-and-create, and it
is there maybe just because
flavor has many fields, user may want to have a new flavor but just modify
one of the old flavor, so
they don't want to manually copy all other fields. And it is the automatic
delete action that causes
all the problem. Maybe horizon can provide a copy-and-modify action and
leave the deletion of
the flavor to the admin.

On Thu, Aug 3, 2017 at 5:59 PM, Sean Dague  wrote:

> On 08/02/2017 10:12 PM, Zhenyu Zheng wrote:
> > Hi All,
> >
> > Horizon provided the feature to allow user edit existing flavors, no
> > matter it is currently used by any instances or not. While Nova doesn't
> > provide this kind of ability, Horizon achieved this by deleting the old
> > flavor first and create a new flavor with the requested properties. And
> > the flavor ID will be changed to a new UUID.
> >
> > This causes problem when display instances with latest Nova, Horizon
> > display flavor name by request flavor details using the flavor id
> > returned by get_instance request, because Nova now moved flavor to
> > api_db, and when a flavor got deleted, it will be directly removed from
> > the DB, and when displaying, the field will be "Not Available".
> >
> > Should we stop support editing existing flavors? It is actually
> > deleting-and-create.
>
> Yes, it should not be a feature in Horizon, because it's extremely
> misleading what it does. It's actually really breaking their
> environment. It's unfortunate that it was implemented there at all. :(
>
> > Maybe we should  at least add WARNING notes about  this when editing
> > flavors, about how it is actually done and what kind of influence will
> > be to the existing instances.
> >
> > Nova now(> microversion 2.47) can reply embedded flavor details
> > including ram, vcpus, original_name etc.
> >
> > Since we provided this flavor editing feature and we displayed "name" as
> > a identifier, after we done some flavor edit, even we fix the above
> > mentioned problem and displayed the correct flavor name, the flavor
> > details will be different than the actual instance type.
>
> There was an extremely long an heated discussion in the Nova room in
> Atlanta about including that name in server document because of this
> Horizon behavior. I came down on the side of showing it, because people
> that use the flavor "rename" function are actually basically breaking
> their environment (in many ways). Lots of people don't do that, so this
> is useful to them so that they can create new instances like the ones
> there.
>
> The only way to change the flavor of an instance is to resize it.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing 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] [watcher] nominate Aditi Sharma to Watcher Core group

2017-08-03 Thread Vincent FRANCOISE

+1


--


Vincent
FRANCOISE

{P} R&D Engineer
Network & Security
{T} +33 (0) 2 56 35 88 53
{W} www.b-com.com

From: ? ? (Alexander Chadin) 
Sent: 02 August 2017 14:47
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [watcher] nominate Aditi Sharma to Watcher Core group

Aditi Sharma (adisky in IRC) has been working on OpenStack Watcher since this 
March
and has done some valuable patches[1] along with Action Plan cancelling 
blueprint (spec and
implementation have been merged).
I'd like to nominate Aditi Sharma to Watcher Core group and waiting for your 
vote.
Please, give +1/-1 in reply to this message.

[1] : 
https://review.openstack.org/#/q/owner:%22aditi+sharma+%253Caditi.s%2540nectechnologies.in%253E%22

Best Regards,
__
Alexander Chadin
__
OpenStack Development Mailing List (not for 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] review.openstack.org downtime and Gerrit upgrade

2017-08-03 Thread Andrey Kurilin

hi Clark,

Do you have any plans to update to 2.14 release which has a new polymer
based user interface?


2017-08-03 1:57 GMT+03:00 Clark Boylan :

> Hello,
>
> The Infra team is planning to upgrade review.openstack.org from Gerrit
> 2.11 to Gerrit 2.13 on September 18, 2017. This downtime will begin at
> 1500UTC and is expected to take many hours as we have to perform an
> offline update of Gerrit's secondary indexes. The outage should be
> complete by 2359UTC.
>
> This upgrade is a relatively minor one for users. You'll find that
> mobile use of Gerrit is slightly better (though still not great). The
> bug that forces us to reapply Approval votes rather than just rechecking
> has also been addressed. If you'd like to test out Gerrit 2.13 you can
> do so at https://review-dev.openstack.org.
>
> The date we have chosen is the Monday after the PTG. The
> expectation/hope is that many people will still be traveling or
> otherwise recovering from the PTG so demand for Gerrit will be low. By
> doing it on Monday we also hope that there will be load on the service
> the following day which should help shake out any issues quickly (in the
> past we've done it on weekends then had to wait a couple days before
> problems are noticed).
>
> If you have any concerns or feedback please let the Infra team know.
>
> Thank you,
> Clark
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [Horizon][Nova] Editing flavor causing instance flavor display error

On 08/02/2017 10:12 PM, Zhenyu Zheng wrote:
> Hi All,
> 
> Horizon provided the feature to allow user edit existing flavors, no
> matter it is currently used by any instances or not. While Nova doesn't
> provide this kind of ability, Horizon achieved this by deleting the old
> flavor first and create a new flavor with the requested properties. And
> the flavor ID will be changed to a new UUID.
> 
> This causes problem when display instances with latest Nova, Horizon
> display flavor name by request flavor details using the flavor id
> returned by get_instance request, because Nova now moved flavor to
> api_db, and when a flavor got deleted, it will be directly removed from
> the DB, and when displaying, the field will be "Not Available".
> 
> Should we stop support editing existing flavors? It is actually
> deleting-and-create.

Yes, it should not be a feature in Horizon, because it's extremely
misleading what it does. It's actually really breaking their
environment. It's unfortunate that it was implemented there at all. :(

> Maybe we should  at least add WARNING notes about  this when editing
> flavors, about how it is actually done and what kind of influence will
> be to the existing instances. 
> 
> Nova now(> microversion 2.47) can reply embedded flavor details
> including ram, vcpus, original_name etc.
> 
> Since we provided this flavor editing feature and we displayed "name" as
> a identifier, after we done some flavor edit, even we fix the above
> mentioned problem and displayed the correct flavor name, the flavor
> details will be different than the actual instance type.

There was an extremely long an heated discussion in the Nova room in
Atlanta about including that name in server document because of this
Horizon behavior. I came down on the side of showing it, because people
that use the flavor "rename" function are actually basically breaking
their environment (in many ways). Lots of people don't do that, so this
is useful to them so that they can create new instances like the ones there.

The only way to change the flavor of an instance is to resize it.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for 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][docs] Concerns with docs migration

On 08/02/2017 08:53 PM, Ghanshyam Mann wrote:
> On Thu, Aug 3, 2017 at 1:20 AM, Doug Hellmann  wrote:
>> Excerpts from Akihiro Motoki's message of 2017-08-03 01:02:59 +0900:
>>> 2017-08-03 0:52 GMT+09:00 Doug Hellmann :
 Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:
> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:
>> On 08/02/2017 09:22 AM, Stephen Finucane wrote:
>>> On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
 3. The patch for the import of the admin guide [8] is missing some CLI
 specific pages which are pretty useful given they aren't documented
 anywhere else, like the forced_host part of the compute API [9].
 Basically anything that's cli-nova-* in the admin guide should be in 
 the
 Nova docs. It's also missing the compute-flavors page [10] which is
 pretty important for using OpenStack at all.
>>>
>>> This is a tricky one. Based on previous discussions with dhellmann, the
>>> plan
>>> seems to be to replace any references to 'nova xxx' or 'openstack xxx'
>>> commands
>>> (i.e. commands using python-novaclient or python-openstackclient) in 
>>> favour
>>> of
>>> 'curl'-based requests. The idea here is that the Python clients are not 
>>> the
>>> only clients available, and we shouldn't be "mandating" their use by
>>> referencing them in the docs. I get this, though I don't fully agree 
>>> with
>>> it
>>> (who really uses curl?)
>>
>> Are we going to document the python clients elsewhere then?
>
> I think the docs would go into the respective python clients docs?

 Right. I don't remember the details of the curl discussion, but I
 think what I was trying to say there was that the "nova" command
 line tool installed via python-novaclient should be documented as
 part of the openstack/python-novaclient repo rather than openstack/nova.
 A CLI reference for nova-manage, which I think is in openstack/nova,
 could be documented in openstack/nova.

 Basically, put the docs with the code, which is the whole point of this
 migration.
>>>
>>> It is true for CLI reference.
>>> The gray zone is CLI stuffs in the admin guide and/or end-user guide.
>>> I think this is the point Matt raised.
>>> cli-nova-* stuffs in the admin guide was per topic like launching instance,
>>> migrating instances and so on. It is actually beyond the CLI reference to 
>>> me.
>>> It is about how to use specific features of nova.
>>> IMHO this kind of stuffs can be covered by the admin guide or user guide,
>>> so it fits into openstack/nova (or other server projects).
>>
>> Yeah, I don't know.
>>
>> My gut response is to say that if the example uses nova-manage or
>> one of the nova service executables, then that makes sense to leave
>> in the nova tree, but otherwise it should go into either the
>> python-novaclient or python-openstackclient repositories (depending
>> on which command line tool is used in the example).
>>
>> On the other hand, I can see that being somewhat confusing for
>> someone who lands at the nova docs and can't find instructions for
>> how to use it. Maybe less confusing, though, than if I am not
>> *running* nova but am trying to use a nova deployed by someone else
>> and I start from the python-novaclient or python-openstackclient
>> docs because I installed one of those in order to talk to nova.
> 
> This is nice point. If nova going to have those doc(using cli), it
> could be confusing for new folks about using novaclient/osc commands.
> They might have installed python-novaclient and try to use "openstack
> server create" because Nova doc says. Or it can be other client over
> nova APIs.
> 
> Also there is chance that Nova might have some obsolete doc (till
> someone use those and report bug)  if any command changed (very rare)
> or some param going to remove with deprecated process.
> 
> IMO, Nova doc should talk about more conceptual or operation things
> and then give reference to CLI doc as example.
> For example:
> "Launch VM doc in Nova" tells about all precondition to launch VM and
> APIs (it can be API name or API ref or Curl example) to get required
> data and launch VM and at the end give reference to CLI (novaclient or
> osc) doc where set of CLI are shown for that operation. If no CLI doc
> exist for particular operation, then nova doc still holds good
> information of doing that using APIs.

This is about audience and usage. We have the following audience and users:

* CLI users (nova cli or openstack client)
* Horizon users
* API users (possibly using python APIs, possibly others)

When a person shows up at our site from where ever, we should assume
they are a CLI user. It's universal, and easy to show examples. It's
also just simpler to integrate these examples then it is to integrate
Horizon usage.

API users aren't going to be reading the using nova guide, the

Re: [openstack-dev] [nova][docs] Concerns with docs migration

On 08/02/2017 03:32 PM, Dean Troyer wrote:
> On Wed, Aug 2, 2017 at 11:20 AM, Doug Hellmann  wrote:
>> My gut response is to say that if the example uses nova-manage or
>> one of the nova service executables, then that makes sense to leave
>> in the nova tree, but otherwise it should go into either the
>> python-novaclient or python-openstackclient repositories (depending
>> on which command line tool is used in the example).
> 
> I don't think this is a good rule of thumb...
> 
>> On the other hand, I can see that being somewhat confusing for
>> someone who lands at the nova docs and can't find instructions for
>> how to use it. Maybe less confusing, though, than if I am not
>> *running* nova but am trying to use a nova deployed by someone else
>> and I start from the python-novaclient or python-openstackclient
>> docs because I installed one of those in order to talk to nova.
> 
> When the point of the example is to illustrate configuring nova, the
> example should stay with the nova code, even if it uses novaclient or
> osc.  The examples that are about _using_ novaclient or osc belong in
> those repos, but where they are just a means to configuring something
> in nova, they should remain with nova and use the tools that users are
> expected to be familiar with (novaclient and/or osc in this example).
> 
>> I thought "put the docs with the code" would be a simple enough
>> rule that we wouldn't have to think too hard about where to put
>> individual example files, which would speed up the migration.
> 
> If I find a doc that tells me how to set up a VM with a Neutron
> network and ports and subnets and floating IPs that uses curl, I'm not
> reading farther.

++ that is actually kind of a punch in the face to our users

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [watcher] nominate Aditi Sharma to Watcher Core group

2017-08-03 Thread bao.yumeng

+1__
OpenStack Development Mailing 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] Recall: [Cinder] string freeze exception for VMAX driver

2017-08-03 Thread Walsh, Helen

Walsh, Helen would like to recall the message, "[openstack-dev] [Cinder]  
string freeze exception for VMAX driver".
__
OpenStack Development Mailing 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] [Cinder] string freeze exception for VMAX driver

2017-08-03 Thread Walsh, Helen


To whom it may concern,

I would like to request a string freeze exception for 2 patches that are on the 
merge queue for Pike.



1. VMAX driver - align VMAX QOS settings with front end  (CI Passed)
https://review.openstack.org/#/c/484885/7/cinder/volume/drivers/dell_emc/vmax/rest.py
  line 800 (removal of exception message)

Although it's primary aim is to align QoS with front end setting it indirectly 
fixes a lazy loading error we were seeing around QoS which occasionally
Broke CI on previous patches.



2.   VMAX driver - seamless upgrade from SMI-S to REST (CI Pending)
https://review.openstack.org/#/c/482138/19/cinder/volume/drivers/dell_emc/vmax/common.py
   line 1400 ,1455 (message changes)

This is vital for as reuse of volumes from Ocata to Pike.  In Ocata we used 
SMIS to interface with the VMAX, in Pike we are using REST.  A few changes 
needed to be made to make this transition as seamless as possible.

Thank you,
Helen


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

Re: [openstack-dev] [Cyborg]Queens PTL candidacy

2017-08-03 Thread Zhipeng Huang

Yes tony I was intended to refer to the official procedure for the
self-nomination period, which would be 5 buiz days.

Thx for the offer to help with the civs poll :)

On Thu, Aug 3, 2017 at 3:11 PM, Tony Breeds  wrote:

> On Thu, Aug 03, 2017 at 11:59:55AM +0800, Zhipeng Huang wrote:
> > Hi Team,
> >
> > Even though Cyborg is not an official project yet, however with an
> ultimate
> > goal of becoming one it is necessary to conduct our project governance
> with
> > compliance of OpenStack community general requirements/culture.
>
> You didn't specify how long the self-nomination period is.  I assume
> you're going for 5 business days?
>
> So any self nominations need to be in within a week from now
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

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

Re: [openstack-dev] [Cyborg]Queens PTL candidacy