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

[Akihiro Motoki]

Hi,

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

[1] https://docs.djangoproject.com/en/2.0/topics/logging/
[2]
https://www.simonkrueger.com/2015/05/27/logging-django-apps-to-syslog.html

Thanks,
Akihiro

2018年11月16日(金) 18:47 Tikkanen, Viktor (Nokia - FI/Espoo) <
viktor.tikka...@nokia.com>:

> Hi!
>
> For most openstack parts (e.g. Aodh, Cinder, Glance, Heat, Ironic,
> Keystone, Neutron, Nova) it was easy to get logs to syslog.
>
> For example for Heat something similar to this (into file
> templates/heat.conf.j2):
>
> # Syslog usage
> {% if heat_syslog_enabled %}
> use_syslog = True
> syslog_log_facility = LOG_LOCAL3
> {% else %}
> log_file = /var/log/heat/heat.log
> {% endif %}
>
> But how to get Horizon related logs to syslog?
>
> -V.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] heads up to long time ovs users...

[Akihiro Motoki]

The important point of this notice is that packet drops will happen when
switching of_interface option from ovs-ofctl (which was the default value
in the old releases) to native (which is the current default ).

Once neutron drops the option, if deployers use the legacy value
"ovs-ofctl", they will hit some packet losses when upgrading neutron to
Stein.

We have no actual data on large deployments so far and don't know how this
change impacts real deployments.

Your feedback would be really appreciated.

Best regards,
Akihiro Motoki (irc: amotoki)

2018年9月21日(金) 10:37 IWAMOTO Toshihiro :

> The neutron team is finally removing the ovs-ofctl option.
>
> https://review.openstack.org/#/c/599496/
>
> The ovs-ofctl of_interface option wasn't default since Newton and was
> deprecated in Pike.
>
> So, if you are a long time ovs-agent user and upgrading to a new
> coming release, you must switch from the ovs-ofctl implementation to
> the native implementation and are affected by the following issue.
>
> https://bugs.launchpad.net/neutron/+bug/1793354
>
> The loss of communication mentioned in this bug report would be a few
> seconds to a few minutes depending on the number of network
> interfaces.  It happens when an ovs-agent is restarted with the new
> of_interface (so only once during the upgrade) and persists until the
> network interfaces are set up.
>
> Please speak up if you cannot tolerate this during upgrades.
>
> IIUC, this bug is unfixable and I'd like to move forward as
> maintaining two of_interface implementation is a burden for the
> neutron team.
>
> --
> IWAMOTO Toshihiro
>
>
> __
> OpenStack Development Mailing 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] Core status

[Akihiro Motoki]

Thanks Gary for long years on Neutron.
You are the only core before I became quantum-core. I lose you now
Anyway good luck for your new role.

Thanks,
Akihiro

2018年9月20日(木) 3:20 Gary Kotton :

> Hi,
>
> I have recently transitioned to a new role where I will be working on
> other parts of OpenStack. Sadly I do not have the necessary cycles to
> maintain my core responsibilities in the neutron community. Nonetheless I
> will continue to be involved.
>
> Thanks
>
> Gary
> __
> OpenStack Development Mailing 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] Removing external_bridge_name config option

[Akihiro Motoki]

Hi,

I would like to share some information to help the migration from
external_network_bridge.

The background of the deprecation is described in
https://bugs.launchpad.net/neutron/+bug/1491668

I also shared a slide to explain the detail.
https://www.slideshare.net/ritchey98/neutron-brex-is-now-deprecated-what-is-modern-way
Neutron: br-ex is now deprecated! what is modern way?

I hope these help you to push away the usage of external_network_bridge.

Thanks,
Akihiro Motoki (IRC: amotoki)

2018年9月19日(水) 23:02 Slawomir Kaplonski :
>
> Hi,
>
> Some time ago I proposed patch [1] to remove config option 
> „external_network_bridge”.
> This option was deprecated to removal in Ocata so I think it’s time to get 
> rid of it finally.
>
> There is quite many projects which still uses this option [2]. I will try to 
> propose patches for those projects to remove it also from there but if You 
> are maintainer of such project, it would be great if You can remove it. If 
> You would do it, please use same topic as is in [1] - it will allow me easier 
> track which projects already removed it.
> Thx a lot in advance for any help :)
>
> [1] https://review.openstack.org/#/c/567369
> [2] 
> http://codesearch.openstack.org/?q=external_network_bridge&i=nope&files=&repos=
>
> —
> Slawek Kaplonski
> Senior software engineer
> Red Hat
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [neutron] bug deputy report week Sep 10 - 12

[Akihiro Motoki]

Hi,

I was the bug deputy for neutron last week.

The last week was really quiet, but all of them are gate failures and
need attentions.

grenade-dvr-multinode job fails
https://bugs.launchpad.net/neutron/+bug/1791989
This continuously happens last week with high failure rate.
http://grafana.openstack.org/d/Hj5IHcSmz/neutron-failure-rate?panelId=20&fullscreen&orgId=1

neutron_tempest_plugin: test_floatingip_port_details occasionally fails
https://bugs.launchpad.net/neutron/+bug/1792472

q-dhcp crashes with guru meditation on ironic's grenade
https://bugs.launchpad.net/neutron/+bug/1792925
This was reported this Monday. It continues to occur since at least Sep 10.

Best Regards,
Akihiro Motoki (irc: amotoki)

__
OpenStack Development Mailing List (not for 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-0, August 27 - 31

[Akihiro Motoki]

2018年8月24日(金) 1:12 Sean McGinnis :
>
> This is the final countdown email for the Rocky development cycle. Thanks to
> everyone involved in the Rocky release!
>
> Development Focus
> -
>
> Teams attending the PTG should be preparing for those discussions and 
> capturing
> information in the etherpads:
>
> https://wiki.openstack.org/wiki/PTG/Stein/Etherpads
>
> General Information
> ---
>
> The release team plans on doing the final Rocky release on 29 August. We will
> re-tag the last commit used for the final RC using the final version number.
>
> If you have not already done so, now would be a good time to take a look at 
> the
> Stein schedule and start planning team activities:
>
> https://releases.openstack.org/stein/schedule.html
>
> Actions
> -
>
> PTLs and release liaisons should watch for the final release patch from the
> release team. While not required, we would appreciate having an ack from each
> team before we approve it on the 29th.
>
> We are still missing releases for the following tempest plugins. Some are
> pending getting pypi and release jobs set up, but please try to prioritize
> getting these done as soon as possible.
>
> barbican-tempest-plugin
> blazar-tempest-plugin
> cloudkitty-tempest-plugin
> congress-tempest-plugin
> ec2api-tempest-plugin
> magnum-tempest-plugin
> mistral-tempest-plugin
> monasca-kibana-plugin
> monasca-tempest-plugin
> murano-tempest-plugin
> networking-generic-switch-tempest-plugin
> oswin-tempest-plugin
> senlin-tempest-plugin
> telemetry-tempest-plugin
> tripleo-common-tempest-plugin
> trove-tempest-plugin
> watcher-tempest-plugin
> zaqar-tempest-plugin

tempest-horizon is missing from the list. horizon team needs to
release tempest-horizon.
It does not follow the naming convention so it seems to be missed from the list.

Thanks,
Akihiro Motoki (amotoki)

>
> Upcoming Deadlines & Dates
> --
>
> Final RC deadline: August 23
> Rocky Release: August 29
> Cycle trailing RC deadline: August 30
> Stein PTG: September 10-14
> Cycle trailing Rocky release: November 28
>
> --
> Sean McGinnis (smcginnis)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [requirements][release][osc] FFE osc-lib 1.11.1 release

[Akihiro Motoki]

2018年8月14日(火) 13:38 Matthew Thode :
>
> On 18-08-14 13:19:27, Akihiro Motoki wrote:
> > Hi,
> >
> > I would like to request FFE for osc-lib 1.11.1 release.
> >
> > https://review.openstack.org/591556
> >
> > osc-iib commit e3d772050f3f4de6369b3dd1ba1269e2903666f7 replaced
> > issubclass() with isinstance() unexpectedly.
> > As a result, osc-lib 1.11.0 breaks existing OSC plugins and
> > the neutronclient OSC plugin gate is now broken.
> > To fix the gate, osc-lib 1.11.1 release would be appreciated.
> >
> > upper-constraints is bumped to osc-lib 1.11.1.
> > It is better to block osc-lib 1.11.0 but I am familiar whether we need
> > to block it or not.
> >
>
> What libs (further down the dep tree) would need the exclusion?  They'd
> likely also need a FFE for at least a UC bump.
> You have my (and requirements) ack for a UC only bump at least.

AFAIK all OSC plugins and OSC directly consume osc-lib and there is no
libs to consume osc-lib.
In this case, we don't need to block a specific version of osc-lib, right?
Perhaps it is just because I don't understand the current policy well.

From neutronclient and other OSC plugin perspective, it is fine to bump UC only.

Thanks,
Akihiro Motoki (amotoki)

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

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

[openstack-dev] [requirements][release][osc] FFE osc-lib 1.11.1 release

[Akihiro Motoki]

Hi,

I would like to request FFE for osc-lib 1.11.1 release.

https://review.openstack.org/591556

osc-iib commit e3d772050f3f4de6369b3dd1ba1269e2903666f7 replaced
issubclass() with isinstance() unexpectedly.
As a result, osc-lib 1.11.0 breaks existing OSC plugins and
the neutronclient OSC plugin gate is now broken.
To fix the gate, osc-lib 1.11.1 release would be appreciated.

upper-constraints is bumped to osc-lib 1.11.1.
It is better to block osc-lib 1.11.0 but I am familiar whether we need
to block it or not.

Thanks,
Akihiro Motoki (amotoki)

__
OpenStack Development Mailing 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][api] strict schema validation and microversioning

[Akihiro Motoki]

Hi Cinder and API-SIG folks,

During reviewing a horizon bug [0], I noticed the behavior of Cinder API
3.0 was changed.
Cinder introduced more strict schema validation for creating/updating
volume encryption type
during Rocky and a new micro version 3.53 was introduced[1].

Previously, Cinder API like 3.0 accepts unused fields in POST requests
but after [1] landed unused fields are now rejected even when Cinder API
3.0 is used.
In my understanding on the microversioning, the existing behavior for older
versions should be kept.
Is it correct?

Thanks,
Akihiro

[0] https://bugs.launchpad.net/horizon/+bug/1783467
[1] https://review.openstack.org/#/c/573093/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] Edge and Containers whitepapers ready for translation

[Akihiro Motoki]

Jimmy,

Does it mean translation **publishing** is ready now?

In the first translation of the edge computing whitepaper, translation
publishing was completely a manual process and it takes too long.
If translation publishing support is not ready, it is a bit discouraging
from translator perspective.
We translators would like to have some automated way to publish translated
versions of documents
and it allows translators to improve and/or fix translations after the
initial translation.

I propose an idea of using RST file for the edge computing whitepaper after
the Vancouver summit.
Ildiko said it is being discussed in the edge computing team and the
foundation but I haven't heard nothing since then.
Or can the foundation publish translations more quickly even though the
current publishing process is not changed.
If not, I cannot believe this is the right timing to promote whitepaper
translations.

Thanks,
Akihiro


2018年7月17日(火) 0:27 Jimmy McArthur :

> Sorry, I should have also added... we additionally need permissions so
> that we can add the a new version of the pot file to this project:
>
> https://translate.openstack.org/project/view/edge-computing/versions?dswid=-7835
>
> Thanks!
> Jimmy
>
>
>
> Jimmy McArthur wrote:
> > Hi all -
> >
> > We have both of the current whitepapers up and available for
> > translation.  Can we promote these on the Zanata homepage?
> >
> >
> https://translate.openstack.org/project/view/leveraging-containers-openstack?dswid=5684
> >
> >
> https://translate.openstack.org/iteration/view/edge-computing/master/documents?dswid=5684
> >
> >
> > Thanks all!
> > Jimmy
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Release-job-failures][release][horizon] Release of openstack/xstatic-angular-material failed

[Akihiro Motoki]

First of all, thanks for the release team and Radomir.

Apart from the fix, is there any good way to detect this kind of errors in
individual project reviews?
xstatic-cores have new members and all of them are not necessarily super
familiar with the xstatic process.
In addition, updates in xstatic repos do not happen often, so we
xstatic-cores (including horizon-cores)
tend to forget minor corner cases

I believe this failure is a symptom that we should add more checks in
xstatic repo gates rather than "noop" :(

Akihiro


2018年6月25日(月) 22:37 Radomir Dopieralski :

> A fix for it is in review: https://review.openstack.org/577820
>
> On Mon, Jun 25, 2018 at 3:07 PM, Andreas Jaeger  wrote:
>
>> On 2018-06-25 14:57, Radomir Dopieralski wrote:
>> > Any idea where it took the 1.1.5.0 version from?
>>
>> git grep 1.1.5 shows at least:
>>
>> setup.cfg:description = Angular-Material 1.1.5 (XStatic packaging
>> standard)
>> xstatic/pkg/angular_material/__init__.py:VERSION = '1.1.5'  # version of
>> the packaged files, please use the upstream
>>
>> Not sure whether that's the right place, I suggest you build locally and
>> check the build tarball,
>>
>> Andreas
>>
>> > On Mon, Jun 25, 2018 at 2:38 PM, Doug Hellmann > > > wrote:
>> >
>> > Excerpts from zuul's message of 2018-06-25 12:14:34 +:
>> > > Build failed.
>> > >
>> > > - xstatic-check-version
>> >
>> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/
>> > <
>> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/
>> >
>> > : FAILURE in 1m 31s
>> > > - release-openstack-python release-openstack-python : SKIPPED
>> > > - announce-release announce-release : SKIPPED
>> > > - propose-update-constraints propose-update-constraints : SKIPPED
>> > >
>> >
>> > "git tag version (1.1.5.1) does not match package version (1.1.5.0)"
>> >
>> >
>> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/job-output.txt.gz#_2018-06-25_12_14_11_034599
>> > <
>> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/job-output.txt.gz#_2018-06-25_12_14_11_034599
>> >
>> >
>> >
>>  __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > <
>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> > 
>> >
>> >
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> --
>>  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
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][horizon] Adding Ivan Kolodyazhny to horizon-stable-maint

[Akihiro Motoki]

+1 to add Ivan to the horizon stable maint team.


2018年6月18日(月) 11:04 Tony Breeds :

> Hello folks,
> Recently Ivan became the Horizon PTL and as with past PTLs (Hi Rob)
> isn't a member of the horizon-stable-maint team.  Ivan is a member of
> the Cinder stable team and as such has demonstrated an understanding of
> the stable policy.  Since the Dublin PTG Ivan has been doing consistent
> high quality reviews on Horizon's stable branches.
>
> As such I'm suggesting adding him to the existing stable team.
>
> Without strong objections I'll do that on (my) Monday 25th June.
>
> 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
>
__
OpenStack Development Mailing 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] openstack-tox-validate: python setup.py check --restructuredtext --strict

[Akihiro Motoki]

Hi the release team,

When I prepared neutron Rocky-2 deliverables, I noticed a new metadata
syntax check
which checks README.rst was introduced.

As of now, README.rst in networking-bagpipe and networking-ovn hit this [1].

Although they can be fixed in individual projects, what is the current
recommended solution?

In addition, unfortunately such checks are not run in project gate,
so there is no way to detect in advance.
I think we need a way to check this when a change is made
instead of detecting an error when a release patch is proposed.

Thanks,
Akihiro (amotoki)

[1]
http://logs.openstack.org/66/572666/1/check/openstack-tox-validate/b5dde2f/job-output.txt.gz#_2018-06-06_04_09_16_067790
__
OpenStack Development Mailing List (not for 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] [heat-dashboard] Horizon plugin settings for new xstatic modules

[Akihiro Motoki]

2018年6月6日(水) 11:54 Xinni Ge :

> Hi, akihiro and other guys,
>
> I understand why minified is considered to be non-free, but I was confused
> about the statement
> "At the very least, a non-minified version should be present next to the
> minified version" [1]
> in the documentation.
>
> Actually in existing xstatic repo, I observed several minified files in
> angular_fileupload, jquery-migrate, or bootstrap_scss.
> So, I uploaded those minified files as in the release package of
>  angular/material.
>

Good point. My interpretation is:
- Basically minified files should not be included in xstatic deliverables.
- Even though not suggested, if minified files are included, corresponding
non-minified version must be included.

Considering this, I believe we should not include minified files for new
xstatic deliverables.
Makes sense?


>
> Personally I don't insist on minified files, and I will delete all
> minified files and re-upload the patch.
> Thanks a lot for the advice.
>

Thanks for understanding and your patience.
Let's land pending reviews soon :)

Akihiro


>
> [1]
> https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html#minified-javascript-policy
>
> 
> Ge Xinni
> Email: xinni.ge1...@gmail.com
> 
>
> On Tue, Jun 5, 2018 at 8:59 PM, Akihiro Motoki  wrote:
>
>> Hi,
>>
>> Sorry for re-using the ancient ML thread.
>> Looking at recent xstatic-* repo reviews, I am a bit afraid that
>> xstatic-cores do not have a common understanding on the principle of
>> xstatic packages.
>> I hope all xstatic-cores re-read "Packing Software" in the horizon
>> contributor docs [1], especially "Minified Javascript policy" [2],
>> carefully.
>>
>> Thanks,
>> Akihiro
>>
>> [1]
>> https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html
>> [2]
>> https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html#minified-javascript-policy
>>
>>
>> 2018年4月4日(水) 14:35 Xinni Ge :
>>
>>> Hi Ivan and other Horizon team member,
>>>
>>> Thanks for adding us into xstatic-core group.
>>> But I still need your opinion and help to release the newly-added
>>> xstatic packages to pypi index.
>>>
>>> Current `xstatic-core` group doesn't have the permission to PUSH SIGNED
>>> TAG, and I cannot release the first non-trivial version.
>>>
>>> If I (or maybe Kaz) could be added into xstatic-release group, we can
>>> release all the 8 packages by ourselves.
>>>
>>> Or, we are very appreciate if any member of xstatic-release could help
>>> to do it.
>>>
>>> Just for your quick access, here is the link of access permission page
>>> of one xstatic package.
>>>
>>> https://review.openstack.org/#/admin/projects/openstack/xstatic-angular-material,access
>>>
>>>
>>> --
>>> Best Regards,
>>> Xinni
>>>
>>> On Thu, Mar 29, 2018 at 9:59 AM, Kaz Shinohara 
>>> wrote:
>>>
>>>> Hi Ivan,
>>>>
>>>>
>>>> Thank you very much.
>>>> I've confirmed that all of us have been added to xstatic-core.
>>>>
>>>> As discussed, we will focus on the followings what we added for
>>>> heat-dashboard, will not touch other xstatic repos as core.
>>>>
>>>> xstatic-angular-material
>>>> xstatic-angular-notify
>>>> xstatic-angular-uuid
>>>> xstatic-angular-vis
>>>> xstatic-filesaver
>>>> xstatic-js-yaml
>>>> xstatic-json2yaml
>>>> xstatic-vis
>>>>
>>>> Regards,
>>>> Kaz
>>>>
>>>> 2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny :
>>>> > Hi Kuz,
>>>> >
>>>> > Don't worry, we're on the same page with you. I added both you, Xinni
>>>> and
>>>> > Keichii to the xstatic-core group. Thank you for your contributions!
>>>> >
>>>> > Regards,
>>>> > Ivan Kolodyazhny,
>>>> > http://blog.e0ne.info/
>>>> >
>>>> > On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara 
>>>> wrote:
>>>> >>
>>>> >> Hi Ivan & Horizon folks
>>>> >>
>>>> >>
>>>> >> AFAIK, Horizon team had conclusion that you will add the specific
>>>> >> members to xstatic-core, correct ?
>>&g

Re: [openstack-dev] [horizon][plugins][heat][searchlight][murano][sahara][watcher] Use default Django test runner instead of nose

[Akihiro Motoki]

This is an important step to drop nose and nosehtmloutput :)
We plan to switch the test runner and then re-enable integration tests
(with selenium) for cross project testing.

In addition, we horizon team are trying to minimize gate breakage in
horizon plugins for recent changes (this and django 2.0).
Hopefully pending related patches will land soon.


2018年6月5日(火) 22:52 Doug Hellmann :

> Excerpts from Ivan Kolodyazhny's message of 2018-06-05 16:32:22 +0300:
> > Hi team,
> >
> > In Horizon, we're going to get rid of unsupported Nose and use Django
> Test
> > Runner instead of it [1]. Nose has some issues and limitations which
> blocks
> > us in our testing improvement efforts.
> >
> > Nose has different test discovery mechanism than Django does. So, there
> was
> > a chance to break some Horizon Plugins:(. Unfortunately, we haven't
> > cross-project CI yet (TBH, I'm working on it and it's one of the first
> > steps to get it done), that's why I tested this change [2] against all
> > known plugins [3].
> >
> > Most of the projects don't need any changes. I proposed few changed to
> > plugins repositories [4] and most of them are merged already. Thanks a
> lot
> > to everybody who helped me with it. Patches for heat-dashboard [5] and
> > searchlight-ui [6] are under review.
> >
> > Additional efforts are needed for murano-dashboard, sahara-dashboard, and
> > watcher-dashboard projects. murano-dashboard has Nose test runner enabled
> > in the config, so Horizon change won't affect it.
> >
> > I proposed patches for sahara-dashboard [7] and watcher-dashboard [8] to
> > explicitly enable Nose test runner there until we'll fix all related
> > issues. I hope we'll have a good number of cross-project activities with
> > these teams.
> >
> > Once all patches above will be merged, we'll be ready to the next step to
> > make Horizon and plugins CI better.
> >
> >
> > [1] https://review.openstack.org/#/c/544296/
> > [2]
> >
> https://docs.google.com/spreadsheets/d/17Yiso6JLeRHBSqJhAiQYkqIAvQhvNFM8NgTkrPxovMo/edit?usp=sharing
> > [3]
> https://docs.openstack.org/horizon/latest/install/plugin-registry.html
> > [4]
> >
> https://review.openstack.org/#/q/topic:bp/improve-horizon-testing+(status:open+OR+status:merged)
> > [5] https://review.openstack.org/572095
> > [6] https://review.openstack.org/572124
> > [7] https://review.openstack.org/572390
> > [8] https://review.openstack.org/572391
> >
> >
> >
> > Regards,
> > Ivan Kolodyazhny,
> > http://blog.e0ne.info/
>
> Nice work! Thanks for taking the initiative on updating our tooling.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules

[Akihiro Motoki]

Hi,

Sorry for re-using the ancient ML thread.
Looking at recent xstatic-* repo reviews, I am a bit afraid that
xstatic-cores do not have a common understanding on the principle of
xstatic packages.
I hope all xstatic-cores re-read "Packing Software" in the horizon
contributor docs [1], especially "Minified Javascript policy" [2],
carefully.

Thanks,
Akihiro

[1]
https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html
[2]
https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html#minified-javascript-policy


2018年4月4日(水) 14:35 Xinni Ge :

> Hi Ivan and other Horizon team member,
>
> Thanks for adding us into xstatic-core group.
> But I still need your opinion and help to release the newly-added xstatic
> packages to pypi index.
>
> Current `xstatic-core` group doesn't have the permission to PUSH SIGNED
> TAG, and I cannot release the first non-trivial version.
>
> If I (or maybe Kaz) could be added into xstatic-release group, we can
> release all the 8 packages by ourselves.
>
> Or, we are very appreciate if any member of xstatic-release could help to
> do it.
>
> Just for your quick access, here is the link of access permission page of
> one xstatic package.
>
> https://review.openstack.org/#/admin/projects/openstack/xstatic-angular-material,access
>
>
> --
> Best Regards,
> Xinni
>
> On Thu, Mar 29, 2018 at 9:59 AM, Kaz Shinohara 
> wrote:
>
>> Hi Ivan,
>>
>>
>> Thank you very much.
>> I've confirmed that all of us have been added to xstatic-core.
>>
>> As discussed, we will focus on the followings what we added for
>> heat-dashboard, will not touch other xstatic repos as core.
>>
>> xstatic-angular-material
>> xstatic-angular-notify
>> xstatic-angular-uuid
>> xstatic-angular-vis
>> xstatic-filesaver
>> xstatic-js-yaml
>> xstatic-json2yaml
>> xstatic-vis
>>
>> Regards,
>> Kaz
>>
>> 2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny :
>> > Hi Kuz,
>> >
>> > Don't worry, we're on the same page with you. I added both you, Xinni
>> and
>> > Keichii to the xstatic-core group. Thank you for your contributions!
>> >
>> > Regards,
>> > Ivan Kolodyazhny,
>> > http://blog.e0ne.info/
>> >
>> > On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara 
>> wrote:
>> >>
>> >> Hi Ivan & Horizon folks
>> >>
>> >>
>> >> AFAIK, Horizon team had conclusion that you will add the specific
>> >> members to xstatic-core, correct ?
>> >> Can I ask you to add the following members ?
>> >> # All of tree are heat-dashboard core.
>> >>
>> >> Kazunori Shinohara / ksnhr.t...@gmail.com #myself
>> >> Xinni Ge / xinni.ge1...@gmail.com
>> >> Keiichi Hikita / keiichi.hik...@gmail.com
>> >>
>> >> Please give me a shout, if we are not on same page or any concern.
>> >>
>> >> Regards,
>> >> Kaz
>> >>
>> >>
>> >> 2018-03-21 22:29 GMT+09:00 Kaz Shinohara :
>> >> > Hi Ivan, Akihiro,
>> >> >
>> >> >
>> >> > Thanks for your kind arrangement.
>> >> > Looking forward to hearing your decision soon.
>> >> >
>> >> > Regards,
>> >> > Kaz
>> >> >
>> >> > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
>> >> >> HI Team,
>> >> >>
>> >> >> From my perspective, I'm OK both with #2 and #3 options. I agree
>> that
>> >> >> #4
>> >> >> could be too complicated for us. Anyway, we've got this topic on the
>> >> >> meeting
>> >> >> agenda [1] so we'll discuss it there too. I'll share our decision
>> after
>> >> >> the
>> >> >> meeting.
>> >> >>
>> >> >> [1] https://wiki.openstack.org/wiki/Meetings/Horizon
>> >> >>
>> >> >>
>> >> >>
>> >> >> Regards,
>> >> >> Ivan Kolodyazhny,
>> >> >> http://blog.e0ne.info/
>> >> >>
>> >> >> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki > >
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Kaz and Ivan,
>> >> >>>
>> >> >>> Yeah, it is worth discussed officially in the horizon team meeting
>> or
>>

Re: [openstack-dev] [neutron][api][graphql] Feature branch creation please (PTL/Core)

[Akihiro Motoki]

Hi Gilles,

2018年6月5日(火) 10:46 Gilles Dubreuil :

>
>
> On 04/06/18 22:20, Doug Hellmann wrote:
> >> On Jun 4, 2018, at 7:57 AM, Gilles Dubreuil 
> wrote:
> >>
> >> Hi,
> >>
> >> Can someone from the core team request infra to create a feature branch
> for the Proof of Concept we agreed to do during API SIG forum session [1] a
> Vancouver?
> >>
> >> Thanks,
> >> Gilles
> >>
> >> [1] https://etherpad.openstack.org/p/YVR18-API-SIG-forum
> > You can do this through the releases repo now. See the README for
> instructions.
> >
> > Doug
>
> Great, thanks Doug!
>
> What about the UUID associated? Do I generate one?:
>
> branches:
>- name: feature/graphql
>  location:
>openstack/neutron: 
>

This needs to be a valid commit hash.
You can specify the latest conmit ID of the neutron repo.

Akihiro


>
>
>
> __
> OpenStack Development Mailing 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] [horizon] Scheduling switch to django >= 2.0

[Akihiro Motoki]

2018年6月3日(日) 10:56 Chuck Short :

> Hi
>
> On Sat, Jun 2, 2018 at 9:50 PM, Akihiro Motoki  wrote:
>
>> Updates on Django 2.0 support.
>>
>> * 18 of 29 affected repositories now support Django 2.0
>> * 4 repositories have pending patches.
>> * 3 repositories below need help from individual project teams as I don't
>> have actual running environments of them.
>>* heat-dashboard https://review.openstack.org/#/c/567591/
>>* murano-dashboard https://review.openstack.org/#/c/571950/
>>* watcher-dashboard
>> * 4 repositories below needs more help as there seems no python3 support
>> or projects looks inactive.
>>monasca-ui, cloudkitty-dashboard, karbor-dashboard,
>> group-based-policy-ui
>>
>>
> Monasca-ui has python3 support however the CI hasn't been enabled.
>

Considering my bandwidth, it would be nice if monasca-ui team can work on
django2.0 support.


>
>
>> global-requirements and upper-constraints changes are also proposed.
>> Considering good progress in general, I believe we can land requirements
>> changes soon.
>>
>> https://review.openstack.org/#/q/topic:django-version+(status:open+OR+status:merged)
>>
>> Detail progress is found at
>> https://etherpad.openstack.org/p/django20-support
>>
>> Thanks,
>> Akihiro
>>
>> 2018年5月15日(火) 4:21 Ivan Kolodyazhny :
>>
>>> Hi all,
>>>
>>> From the Horizon's perspective, it would be good to support Django 1.11
>>> as long as we can since it's an LTS release [2].
>>> Django 2.0 support is also extremely important because of it's the first
>>> step in a python3-only environment and step forward on supporting
>>> next Django 2.2 LTS release which will be released next April.
>>>
>>> We have to be careful to not break existing plugins and deployments by
>>> introducing new Django version requirement.
>>> We need to work more closely with plugins teams to getting everything
>>> ready for Django 2.0+ before we change our requirements.txt.
>>> I don't want to introduce any breaking changes for current plugins so we
>>> need to to be sure that each plugin supports Django 2.0. It means
>>> plugins have to have voting Django 2.0 jobs on their gates at least.
>>> I'll do my best on this effort and will work with plugins teams to do as
>>> much as we can in Rocky timeframe.
>>>
>>> [2] https://www.djangoproject.com/download/
>>>
>>> Regards,
>>> Ivan Kolodyazhny,
>>> http://blog.e0ne.info/
>>>
>>> On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki 
>>> wrote:
>>>
>>>>
>>>>
>>>> 2018年5月14日(月) 21:42 Doug Hellmann :
>>>>
>>>>> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
>>>>> > 2018年5月12日(土) 3:04 Doug Hellmann :
>>>>> >
>>>>> > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33
>>>>> +0900:
>>>>> > > > Hi zigo and horizon plugin maintainers,
>>>>> > > >
>>>>> > > > Horizon itself already supports Django 2.0 and horizon unit test
>>>>> covers
>>>>> > > > Django 2.0 with Python 3.5.
>>>>> > > >
>>>>> > > > A question to all is whether we change the upper bound of Django
>>>>> from
>>>>> > > <2.0
>>>>> > > > to <2.1.
>>>>> > > > My proposal is to bump the upper bound of Django to <2.1 in
>>>>> Rocky-2.
>>>>> > > > (Note that Django 1.11 will continue to be used for python 2.7
>>>>> > > environment.)
>>>>> > >
>>>>> > > Do we need to cap it at all? We've been trying to express our
>>>>> > > dependencies without caps and rely on the constraints list to
>>>>> > > test using a common version because this offers the most
>>>>> flexibility as
>>>>> > > we move to newer versions over time.
>>>>> > >
>>>>> >
>>>>> > The main reason we cap django version so far is that django minor
>>>>> version
>>>>> > releases
>>>>> > contain some backward incompatible changes and also drop deprecated
>>>>> > features.
>>>>> > A new django minor version release like 1.11 u

Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Akihiro Motoki]

Updates on Django 2.0 support.

* 18 of 29 affected repositories now support Django 2.0
* 4 repositories have pending patches.
* 3 repositories below need help from individual project teams as I don't
have actual running environments of them.
   * heat-dashboard https://review.openstack.org/#/c/567591/
   * murano-dashboard https://review.openstack.org/#/c/571950/
   * watcher-dashboard
* 4 repositories below needs more help as there seems no python3 support or
projects looks inactive.
   monasca-ui, cloudkitty-dashboard, karbor-dashboard, group-based-policy-ui

global-requirements and upper-constraints changes are also proposed.
Considering good progress in general, I believe we can land requirements
changes soon.
https://review.openstack.org/#/q/topic:django-version+(status:open+OR+status:merged)

Detail progress is found at
https://etherpad.openstack.org/p/django20-support

Thanks,
Akihiro

2018年5月15日(火) 4:21 Ivan Kolodyazhny :

> Hi all,
>
> From the Horizon's perspective, it would be good to support Django 1.11 as
> long as we can since it's an LTS release [2].
> Django 2.0 support is also extremely important because of it's the first
> step in a python3-only environment and step forward on supporting
> next Django 2.2 LTS release which will be released next April.
>
> We have to be careful to not break existing plugins and deployments by
> introducing new Django version requirement.
> We need to work more closely with plugins teams to getting everything
> ready for Django 2.0+ before we change our requirements.txt.
> I don't want to introduce any breaking changes for current plugins so we
> need to to be sure that each plugin supports Django 2.0. It means
> plugins have to have voting Django 2.0 jobs on their gates at least. I'll
> do my best on this effort and will work with plugins teams to do as
> much as we can in Rocky timeframe.
>
> [2] https://www.djangoproject.com/download/
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki  wrote:
>
>>
>>
>> 2018年5月14日(月) 21:42 Doug Hellmann :
>>
>>> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
>>> > 2018年5月12日(土) 3:04 Doug Hellmann :
>>> >
>>> > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
>>> > > > Hi zigo and horizon plugin maintainers,
>>> > > >
>>> > > > Horizon itself already supports Django 2.0 and horizon unit test
>>> covers
>>> > > > Django 2.0 with Python 3.5.
>>> > > >
>>> > > > A question to all is whether we change the upper bound of Django
>>> from
>>> > > <2.0
>>> > > > to <2.1.
>>> > > > My proposal is to bump the upper bound of Django to <2.1 in
>>> Rocky-2.
>>> > > > (Note that Django 1.11 will continue to be used for python 2.7
>>> > > environment.)
>>> > >
>>> > > Do we need to cap it at all? We've been trying to express our
>>> > > dependencies without caps and rely on the constraints list to
>>> > > test using a common version because this offers the most flexibility
>>> as
>>> > > we move to newer versions over time.
>>> > >
>>> >
>>> > The main reason we cap django version so far is that django minor
>>> version
>>> > releases
>>> > contain some backward incompatible changes and also drop deprecated
>>> > features.
>>> > A new django minor version release like 1.11 usually breaks horizon and
>>> > plugins
>>> > as horizon developers are not always checking django deprecations.
>>>
>>> OK. Having the cap in place makes it more complicated to test
>>> upgrading, and then upgrade. Because we no longer synchronize
>>> requirements, changing openstack/requirements does not trigger the
>>> bot to propose the same change to all of the projects using the
>>> dependency. Someone will have to do that by hand in the future, as we
>>> are doing with eventlet right now
>>> (https://review.openstack.org/#/q/topic:uncap-eventlet).
>>>
>>> Without the cap, we can test the upgrade by proposing a constraint
>>> update and running the horizon (and/or plugin) unit tests. When those
>>> tests pass, we can then step forward all at once by approving the
>>> constraint change.
>>>
>>
>> Thanks for the detail context.
>>
>> Honestly I am not sure which is better to cap or uncap the djan

Re: [openstack-dev] Vancouver Forum Etherpad List

[Akihiro Motoki]

I would like to re-post this Sean's post on the YVR forum etherpad list as
I believe this is worth shared now again.

2018年5月9日(水) 7:48 Sean McGinnis :

> We are now less than two weeks away from the next Summit/Forum in
> Vancouver.
> Hopefully teams are able to spend some time preparing for their Forum
> sessions
> to make them productive.
>
> I have updated the Forum wiki page to start collecting links to session
> etherpads:
>
> https://wiki.openstack.org/wiki/Forum/Vancouver2018
>
> Please update this page with your etherpads as they are ready to make this
> one
> easy place to go to for all sessions. I have started populating some
> sessions
> so there is a start, but there are many that still need to be filled in.
>
> Looking forward to another week in Vancouver.
>
> Thanks!
> Sean
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for 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] Scheduling switch to django >= 2.0

[Akihiro Motoki]

2018年5月14日(月) 21:42 Doug Hellmann :

> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
> > 2018年5月12日(土) 3:04 Doug Hellmann :
> >
> > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
> > > > Hi zigo and horizon plugin maintainers,
> > > >
> > > > Horizon itself already supports Django 2.0 and horizon unit test
> covers
> > > > Django 2.0 with Python 3.5.
> > > >
> > > > A question to all is whether we change the upper bound of Django from
> > > <2.0
> > > > to <2.1.
> > > > My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
> > > > (Note that Django 1.11 will continue to be used for python 2.7
> > > environment.)
> > >
> > > Do we need to cap it at all? We've been trying to express our
> > > dependencies without caps and rely on the constraints list to
> > > test using a common version because this offers the most flexibility as
> > > we move to newer versions over time.
> > >
> >
> > The main reason we cap django version so far is that django minor version
> > releases
> > contain some backward incompatible changes and also drop deprecated
> > features.
> > A new django minor version release like 1.11 usually breaks horizon and
> > plugins
> > as horizon developers are not always checking django deprecations.
>
> OK. Having the cap in place makes it more complicated to test
> upgrading, and then upgrade. Because we no longer synchronize
> requirements, changing openstack/requirements does not trigger the
> bot to propose the same change to all of the projects using the
> dependency. Someone will have to do that by hand in the future, as we
> are doing with eventlet right now
> (https://review.openstack.org/#/q/topic:uncap-eventlet).
>
> Without the cap, we can test the upgrade by proposing a constraint
> update and running the horizon (and/or plugin) unit tests. When those
> tests pass, we can then step forward all at once by approving the
> constraint change.
>

Thanks for the detail context.

Honestly I am not sure which is better to cap or uncap the django version.
We can try uncapping now and see what happens in the community.

cross-horizon-(py27|py35) jobs of openstack/requirements checks
if horizon works with a new version. it works for horizon, but perhaps it
potentially
break horizon plugins as it takes time to catch up with such changes.
On the other hand, a version bump in upper-constraints.txt would be
a good trigger for horizon plugin maintainers to sync all requirements.

In addition, requirements are not synchronized automatically,
so it seems not feasible to propose requirements changes per django version
change.


>
> >
> > I have a question on uncapping the django version.
> > How can users/operators know which versions are supported?
> > Do they need to check upper-constraints.txt?
>
> We do tell downstream consumers that the upper-constraints.txt file is
> the set of things we test with, and that any other combination of
> packages would need to be tested on their systems separately.
>
> >
> > > > There are several points we should consider:
> > > > - If we change it in global-requirements.txt, it means Django 2.0
> will be
> > > > used for python3.5 environment.
> > > > - Not a small number of horizon plugins still do not support Django
> 2.0,
> > > so
> > > > bumping the upper bound to <2.1 will break their py35 tests.
> > > > - From my experience of Django 2.0 support in some plugins, the
> required
> > > > changes are relatively simple like [1].
> > > >
> > > > I created an etherpad page to track Django 2.0 support in horizon
> > > plugins.
> > > > https://etherpad.openstack.org/p/django20-support
> > > >
> > > > I proposed Django 2.0 support patches to several projects which I
> think
> > > are
> > > > major.
> > > > # Do not blame me if I don't cover your project :)
> > > >
> > > > Thought?
> > >
> > > It seems like a good goal for the horizon-plugin author community
> > > to bring those projects up to date by supporting a current version
> > > of Django (and any other dependencies), especially as we discuss
> > > the impending switch over to python-3-first and then python-3-only.
> > >
> >
> > Yes, python 3 support is an important topic.
> > We also need to switch the default python version in mod_wsgi in DevStack
> > environment sooner or later.
>
> Is Python 3 ever used for mod_wsgi? Does the WSGI setup code honor
> the variable that tells devstack to use Python 3?
>

Ubuntu 16.04 provides py2 and py3 versions of mod_wsgi (libapache2-mod-wsgi
and libapache2-mod-wsgi-py3) and as a quick look the only difference is a
module
specified in LoadModule apache directive.
I haven't tested it yet, but it seems worth explored.

Akihiro


> >
> > > If this is an area where teams need help, updating that etherpad
> > > with notes and requests for assistance will help us split up the
> > > work.
> > >
> >
> > Each team can help testing in Django 2.0 and/or python 3 support.
> > We need to enable corresponding server projects in de

Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Akihiro Motoki]

2018年5月12日(土) 3:04 Doug Hellmann :

> Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
> > Hi zigo and horizon plugin maintainers,
> >
> > Horizon itself already supports Django 2.0 and horizon unit test covers
> > Django 2.0 with Python 3.5.
> >
> > A question to all is whether we change the upper bound of Django from
> <2.0
> > to <2.1.
> > My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
> > (Note that Django 1.11 will continue to be used for python 2.7
> environment.)
>
> Do we need to cap it at all? We've been trying to express our
> dependencies without caps and rely on the constraints list to
> test using a common version because this offers the most flexibility as
> we move to newer versions over time.
>

The main reason we cap django version so far is that django minor version
releases
contain some backward incompatible changes and also drop deprecated
features.
A new django minor version release like 1.11 usually breaks horizon and
plugins
as horizon developers are not always checking django deprecations.

I have a question on uncapping the django version.
How can users/operators know which versions are supported?
Do they need to check upper-constraints.txt?



> > There are several points we should consider:
> > - If we change it in global-requirements.txt, it means Django 2.0 will be
> > used for python3.5 environment.
> > - Not a small number of horizon plugins still do not support Django 2.0,
> so
> > bumping the upper bound to <2.1 will break their py35 tests.
> > - From my experience of Django 2.0 support in some plugins, the required
> > changes are relatively simple like [1].
> >
> > I created an etherpad page to track Django 2.0 support in horizon
> plugins.
> > https://etherpad.openstack.org/p/django20-support
> >
> > I proposed Django 2.0 support patches to several projects which I think
> are
> > major.
> > # Do not blame me if I don't cover your project :)
> >
> > Thought?
>
> It seems like a good goal for the horizon-plugin author community
> to bring those projects up to date by supporting a current version
> of Django (and any other dependencies), especially as we discuss
> the impending switch over to python-3-first and then python-3-only.
>

Yes, python 3 support is an important topic.
We also need to switch the default python version in mod_wsgi in DevStack
environment sooner or later.


> If this is an area where teams need help, updating that etherpad
> with notes and requests for assistance will help us split up the
> work.
>

Each team can help testing in Django 2.0 and/or python 3 support.
We need to enable corresponding server projects in development environments,
but it is not easy to setup all projects by horizon team. Individual
projects must be
more familiar with their own projects.
I sent several patches,  but I actually tested them by unit tests.

Thanks,
Akihiro


>
> Doug
>
> >
> > Thanks,
> > Akihiro
> >
> > [1] https://review.openstack.org/#/c/566476/
> >
> > 2018年5月8日(火) 17:45 Thomas Goirand :
> >
> > > Hi,
> > >
> > > It has been decided that, in Debian, we'll switch to Django 2.0 after
> > > Buster will be released. Buster is to be frozen next February. This
> > > means that we have roughly one more year before Django 1.x goes away.
> > >
> > > Hopefully, Horizon will be ready for it, right?
> > >
> > > Hoping this helps,
> > > Cheers,
> > >
> > > Thomas Goirand (zigo)
> > >
> > >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Akihiro Motoki]

Hi zigo and horizon plugin maintainers,

Horizon itself already supports Django 2.0 and horizon unit test covers
Django 2.0 with Python 3.5.

A question to all is whether we change the upper bound of Django from <2.0
to <2.1.
My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
(Note that Django 1.11 will continue to be used for python 2.7 environment.)

There are several points we should consider:
- If we change it in global-requirements.txt, it means Django 2.0 will be
used for python3.5 environment.
- Not a small number of horizon plugins still do not support Django 2.0, so
bumping the upper bound to <2.1 will break their py35 tests.
- From my experience of Django 2.0 support in some plugins, the required
changes are relatively simple like [1].

I created an etherpad page to track Django 2.0 support in horizon plugins.
https://etherpad.openstack.org/p/django20-support

I proposed Django 2.0 support patches to several projects which I think are
major.
# Do not blame me if I don't cover your project :)

Thought?

Thanks,
Akihiro

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

2018年5月8日(火) 17:45 Thomas Goirand :

> Hi,
>
> It has been decided that, in Debian, we'll switch to Django 2.0 after
> Buster will be released. Buster is to be frozen next February. This
> means that we have roughly one more year before Django 1.x goes away.
>
> Hopefully, Horizon will be ready for it, right?
>
> Hoping this helps,
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing 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][api][grapql] Proof of Concept

[Akihiro Motoki]

Hi,

I am happy to see the effort to explore a new API mechanism.
I would like to see good progress and help effort as API liaison from the
neutron team.

> Neutron has been selected for the PoC because of its specific data model

On the other hand, I am not sure this is the right reason to choose
'neutron' only from this reason. I would like to note "its specific data
model" is not the reason that makes the progress of API versioning slowest
in the OpenStack community. I believe it is worth recognized as I would
like not to block the effort due to the neutron-specific reasons.
The most complicated point in the neutron API is that the neutron API layer
allows neutron plugins to declare which features are supported. The neutron
API is a collection of API extensions defined in the neutron-lib repo and
each neutron plugin can declare which subset(s) of the neutron APIs are
supported. (For more detail, you can check how the neutron API extension
mechanism is implemented). It is not defined only by the neutron API layer.
We need to communicate which API features are supported by communicating
enabled service plugins.

I am afraid that most efforts to explore a new mechanism in neutron will be
spent to address the above points which is not directly related to GraphQL
itself.
Of course, it would be great if you overcome long-standing complicated
topics as part of GraphQL effort :)

I am happy to help the effort and understand how the neutron API is defined.

Thanks,
Akihiro


2018年5月5日(土) 18:16 Gilles Dubreuil :

> Hello,
>
> Few of us recently discussed [1] how GraphQL [2], the next evolution
> from REST, could transform OpenStack APIs for the better.
> Effectively we believe OpenStack APIs provide perfect use cases for
> GraphQL DSL approach, to bring among other advantages, better
> performance and stability, easier developments and consumption, and with
> GraphQL Schema provide automation capabilities never achieved before.
>
> The API SIG suggested to start an API GraphQL Proof of Concept (PoC) to
> demonstrate the capabilities before eventually extend GraphQL to other
> projects.
> Neutron has been selected for the PoC because of its specific data model.
>
> So if you are interested, please join us.
> For those who can make it, we'll also discuss this during the SIG API
> BoF at OpenStack Summit at Vancouver [3]
>
> To learn more about GraphQL, check-out howtographql.com [4].
>
> So let's get started...
>
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-May/130054.html
> [2] http://graphql.org/
> [3]
>
> https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session
> [4] https://www.howtographql.com/
>
> Regards,
> Gilles
>
>
>
> __
> OpenStack Development Mailing 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] [horizon][plugins] mox -> mock migration

[Akihiro Motoki]

Hi horizon plugin developers,

As I announced in the quoted mail, Rocky-1 was released and mox is NOT
prepared in the horizon test helpers by default now [1].
If your horizon plugin still depends on mox, please ensure to set use_mox =
True in your test classes.

> 2) After Rocky-1, use_mox of openstack_dashboard.test.helpers.TestCase will
be changed from True to False.
>  This means your plugin needs to set use_mox to True explicitly if your
unit tests still depends on mox.
>  Our suggestion is to set use_mox=True until Rocky-1 milestone if your
tests depends on mox not to break your gate.

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

Thanks,
Akihiro Motoki (amotoki)

2018-03-18 17:54 GMT+09:00 Akihiro Motoki :

> Hi horizon plugin developers,
>
> As you know, mox-removal is one of the community goal in Rocky and
> horizon team is working on removing usage of mox [1].
>
> This mail announces the plan of dropping mox dependencies in horizon
> test helpers (horizon.test.helpers.TestCase and/or
> openstack_dashboard.test.helpers.TestCase).
>
> 1) The first step is to introduce "use_mox" flag in
> horizon.test.helpers.TestCase. The flag is available now.
> If you set the flag to False, you can run your plugin test without mox.
> The default value of use_mox is False for
> horizon.test.helpers.TestCase [2] and True for
> openstack_dashboard.test.helpers.TestCase [3].
>
> 2) After Rocky-1, use_mox of openstack_dashboard.test.helpers.TestCase
> will be changed from True to False.
>  This means your plugin needs to set use_mox to True explicitly if
> your unit tests still depends on mox.
>  Our suggestion is to set use_mox=True until Rocky-1 milestone if
> your tests depends on mox not to break your gate.
>
> 3) After Rocky RC1 is released, "use_mox" flag in the horizon repo
> will be dropped.
> This means use_mox flag will no longer be in effect.
> If your plugin tests still depends on mox at this stage, your
> plugin test needs to set up mox explicitly.
>
> Thanks,
> Akihiro Motoki (amotoki)
>
> [1] https://blueprints.launchpad.net/horizon/+spec/mock-
> framework-in-unit-tests
> [2] https://github.com/openstack/horizon/blob/
> 6e29fdde1edc67a6797eba2c3f9c557f840d4ea7/horizon/test/helpers.py#L138
> [3] https://github.com/openstack/horizon/blob/
> 6e29fdde1edc67a6797eba2c3f9c557f840d4ea7/openstack_
> dashboard/test/helpers.py#L257
>
__
OpenStack Development Mailing List (not for 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][dynamic routing] RYU Breaks lower constraints

[Akihiro Motoki]

Gary,

I think this is caused by the recent pip change and pip no longer cannot
import pip from code. The right solution seems to bump the minimum version
of ryu.

Thought?

http://lists.openstack.org/pipermail/openstack-dev/2018-March/128939.html

Akihiro

2018/04/15 午後6:06 "Gary Kotton" :

Hi,

It seems like ther RYU import is breaking the project:



2018-04-15 08:41:34.654681

| ubuntu-xenial | b'--- import errors ---\nFailed to import test
module: 
neutron_dynamic_routing.tests.unit.services.bgp.driver.ryu.test_driver\nTraceback
(most recent call last):\n  File
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py",
line 456, in _find_test_path\nmodule =
self._get_module_from_name(name)\n  File
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py",
line 395, in _get_module_from_name\n__import__(name)\n  File
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/neutron_dynamic_routing/tests/unit/services/bgp/driver/ryu/test_driver.py",
line 21, in \nfrom ryu.services.protocols.bgp import
bgpspeaker\n  File
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/services/protocols/bgp/bgpspeaker.py",
line 21, in \nfrom ryu.lib.packet.bgp import (\n  File
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/__init__.py",
line 6, in \nfrom . import (ethernet, arp, icmp, icmpv6,
ipv4, ipv6, lldp, mpls, packet,\n  File
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ethernet.py",
line 18, in \nfrom . import vlan\n  File
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/vlan.py",
line 21, in \nfrom . import ipv4\n  File
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ipv4.py",
line 23, in \nfrom . import tcp\n  File
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/tcp.py",
line 24, in \nfrom . import bgp\n  File
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/bgp.py",
line 52, in \nfrom ryu.utils import binary_str\n  File
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/utils.py",
line 23, in \nfrom pip import req as pip_req\nImportError:
cannot import name \'req\'\n'



Any suggestions?

Thanks

Gary
__
OpenStack Development Mailing 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][PTLs] [Community goal] Toggle the debug option at runtime

[Akihiro Motoki]

Hi Slawek,

2018-04-06 17:38 GMT+09:00 Sławek Kapłoński :

> Hi,
>
> One more question about implementation of this goal. Should we take care
> (and add to story board [1]) projects like:
>

In my understanding, tasks in the storyboard story are prepared per project
team listed in the governance.
IMHO, repositories which belong to a project team should be handled as a
single task.

The situations vary across repositories.


> openstack/neutron-lbaas
>

This should be covered by octavia team.


> openstack/networking-cisco
> openstack/networking-dpm
> openstack/networking-infoblox
> openstack/networking-l2gw
> openstack/networking-lagopus
>

The above repos are not official repos.
Maintainers of each repo can follow the community goal, but there is no
need to be tracked as the neutron team.


> openstack/neutron-dynamic-routing
>

This repo is part of the neutron team. We, the neutron team need to cover
this.

FYI: The official repositories covered by the neutron team is available
here.
https://governance.openstack.org/tc/reference/projects/neutron.html

Thanks,
Akihiro


>
> Which looks that should be probably also changed in some way. Or maybe
> list of affected projects in [1] is „closed” and if some project is not
> there it shouldn’t be changed to accomplish this community goal?
>

> [1] https://storyboard.openstack.org/#!/story/2001545
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
> > Wiadomość napisana przez ChangBo Guo  w dniu
> 26.03.2018, o godz. 14:15:
> >
> >
> > 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :
> > Hi,
> >
> > I took care of implementation of [1] in Neutron and I have couple
> questions to about this goal.
> >
> > 1. Should we only change "restart_method" to mutate as is described in
> [2] ? I did already something like that in [3] - is it what is expected?
> >
> >  Yes , let's the only  thing.  we need test if that if it works .
> >
> > 2. How I can check if this change is fine and config option are mutable
> exactly? For now when I change any config option for any of neutron agents
> and send SIGHUP to it it is in fact "restarted" and config is reloaded even
> with this old restart method.
> >
> > good question, we indeed thought this question when we proposal  the
> goal.  But It seems difficult to test  that consuming projects like Neutron
> automatically.
> >
> > 3. Should we add any automatic tests for such change also? Any examples
> of such tests in other projects maybe?
> >  There is no example for tests now, we only have some unit tests  in
> oslo.service .
> >
> > [1] https://governance.openstack.org/tc/goals/rocky/enable-
> mutable-configuration.html
> > [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
> > [3] https://review.openstack.org/#/c/554259/
> >
> > —
> > Best regards
> > Slawek Kaplonski
> > sla...@kaplonski.pl
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > --
> > ChangBo Guo(gcb)
> > Community Director @EasyStack
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules

[Akihiro Motoki]

Hi Xinni,

There is no need that you push a tag manually for official deliverables.
You can propose a patch to openstack/releases repository.
Horizon PTL or release liaison (at now both Ivan) can confirm it and the
release team will approve it.
Once it is approved, a release tag will be added and a deliverable will be
published automatically by the infra script (if you've setup project-config
appropriately).

Akihiro

2018-04-04 14:34 GMT+09:00 Xinni Ge :

> Hi Ivan and other Horizon team member,
>
> Thanks for adding us into xstatic-core group.
> But I still need your opinion and help to release the newly-added xstatic
> packages to pypi index.
>
> Current `xstatic-core` group doesn't have the permission to PUSH SIGNED
> TAG, and I cannot release the first non-trivial version.
>
> If I (or maybe Kaz) could be added into xstatic-release group, we can
> release all the 8 packages by ourselves.
>
> Or, we are very appreciate if any member of xstatic-release could help to
> do it.
>
> Just for your quick access, here is the link of access permission page of
> one xstatic package.
> https://review.openstack.org/#/admin/projects/openstack/
> xstatic-angular-material,access
>
> --
> Best Regards,
> Xinni
>
> On Thu, Mar 29, 2018 at 9:59 AM, Kaz Shinohara 
> wrote:
>
>> Hi Ivan,
>>
>>
>> Thank you very much.
>> I've confirmed that all of us have been added to xstatic-core.
>>
>> As discussed, we will focus on the followings what we added for
>> heat-dashboard, will not touch other xstatic repos as core.
>>
>> xstatic-angular-material
>> xstatic-angular-notify
>> xstatic-angular-uuid
>> xstatic-angular-vis
>> xstatic-filesaver
>> xstatic-js-yaml
>> xstatic-json2yaml
>> xstatic-vis
>>
>> Regards,
>> Kaz
>>
>> 2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny :
>> > Hi Kuz,
>> >
>> > Don't worry, we're on the same page with you. I added both you, Xinni
>> and
>> > Keichii to the xstatic-core group. Thank you for your contributions!
>> >
>> > Regards,
>> > Ivan Kolodyazhny,
>> > http://blog.e0ne.info/
>> >
>> > On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara 
>> wrote:
>> >>
>> >> Hi Ivan & Horizon folks
>> >>
>> >>
>> >> AFAIK, Horizon team had conclusion that you will add the specific
>> >> members to xstatic-core, correct ?
>> >> Can I ask you to add the following members ?
>> >> # All of tree are heat-dashboard core.
>> >>
>> >> Kazunori Shinohara / ksnhr.t...@gmail.com #myself
>> >> Xinni Ge / xinni.ge1...@gmail.com
>> >> Keiichi Hikita / keiichi.hik...@gmail.com
>> >>
>> >> Please give me a shout, if we are not on same page or any concern.
>> >>
>> >> Regards,
>> >> Kaz
>> >>
>> >>
>> >> 2018-03-21 22:29 GMT+09:00 Kaz Shinohara :
>> >> > Hi Ivan, Akihiro,
>> >> >
>> >> >
>> >> > Thanks for your kind arrangement.
>> >> > Looking forward to hearing your decision soon.
>> >> >
>> >> > Regards,
>> >> > Kaz
>> >> >
>> >> > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
>> >> >> HI Team,
>> >> >>
>> >> >> From my perspective, I'm OK both with #2 and #3 options. I agree
>> that
>> >> >> #4
>> >> >> could be too complicated for us. Anyway, we've got this topic on the
>> >> >> meeting
>> >> >> agenda [1] so we'll discuss it there too. I'll share our decision
>> after
>> >> >> the
>> >> >> meeting.
>> >> >>
>> >> >> [1] https://wiki.openstack.org/wiki/Meetings/Horizon
>> >> >>
>> >> >>
>> >> >>
>> >> >> Regards,
>> >> >> Ivan Kolodyazhny,
>> >> >> http://blog.e0ne.info/
>> >> >>
>> >> >> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki > >
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Kaz and Ivan,
>> >> >>>
>> >> >>> Yeah, it is worth discussed officially in the horizon team meeting
>> or
>> >> >>> the
>> >> >>> mailing list thread to get a consensus.
>> >> >>> Hopefully y

Re: [openstack-dev] [sdk] git repo rename and storyboard migration

[Akihiro Motoki]

As we talked in #opensatck-sdks channel yesterday, I can help storyboard
migration on OSC bugs. Dean and Monty looks fine with the migration.
We can migrate OSC bugs to storyboard along with openstack SDK storyboard
migration.

Thanks,
Akihiro


2018-03-23 1:28 GMT+09:00 Kendall Nelson :

> I can run test migrations today for the rest of the OSC launchpad projects
> just to make sure it all goes smoothly and report back.
>
> -Kendall (diablo_rojo)
>
>
> On Thu, 22 Mar 2018, 5:54 am Dean Troyer,  wrote:
>
>> On Thu, Mar 22, 2018 at 7:42 AM, Akihiro Motoki 
>> wrote:
>> > 2018-03-22 21:29 GMT+09:00 Monty Taylor :
>> >> I could see waiting until we move python-openstackclient. However,
>> we've
>> >> got the issue already with shade bugs being in storyboard already and
>> sdk
>> >> bugs being in launchpad. With shade moving to having its
>> implementation be
>> >> in openstacksdk, over this cycle I expect the number of bugs people
>> report
>> >> against shade wind up actually being against openstacksdk to increase
>> quite
>> >> a bit.
>> >>
>> >> Maybe we should see if the python-openstackclient team wants to migrate
>> >> too?
>> >
>> > Although I have limited experience on storyboard, I think it is ready
>> for
>> > our bug tracking.
>> > As Jens mentioned, not a small number of bugs are referred to from both
>> OSC
>> > and SDK.
>> > One good news on OSC launchpad bug is that we do not use tag
>> aggressively.
>> > If Dean is okay, I believe we can migrate to storyboard.
>>
>> I am all in favor of migrating OSC to use to Storyboard, however I am
>> totally unable to give it any time in the near future.  If Akhiro or
>> anyone else wants to take on that task, you will have my support and
>> as much help as I am able to give.
>>
>> dt
>>
>> --
>>
>> Dean Troyer
>> dtro...@gmail.com
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing 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] [sdk] git repo rename and storyboard migration

[Akihiro Motoki]

2018-03-22 21:29 GMT+09:00 Monty Taylor :

> On 03/22/2018 02:51 AM, Jens Harbott wrote:
>
>> 2018-03-21 21:44 GMT+01:00 Monty Taylor :
>>
>>> Hey everybody!
>>>
>>> This upcoming Friday we're scheduled to complete the transition from
>>> python-openstacksdk to openstacksdk. This was started a while back (Tue
>>> Jun
>>> 16 12:05:38 2015 to be exact) by changing the name of what gets
>>> published to
>>> PyPI. Renaming the repo is to get those two back inline (and remove a
>>> hack
>>> in devstack to deal with them not being the same)
>>>
>>> Since this is a repo rename, it means that local git remotes will need
>>> to be
>>> updated. This can be done either via changing urls in .git/config - or by
>>> just re-cloning.
>>>
>>> Once that's done, we'll be in a position to migrate to storyboard. shade
>>> is
>>> already over there, which means we're currently split between storyboard
>>> and
>>> launchpad for the openstacksdk team repos.
>>>
>>> diablo_rojo has done a test migration and we're good to go there - so I'm
>>> thinking either Friday post-repo rename - or sometime early next week.
>>> Any
>>> thoughts or opinions?
>>>
>>> This will migrate bugs from launchpad for python-openstacksdk and
>>> os-client-config.
>>>
>>
>> IMO this list is still much too long [0] and I expect it will make
>> dealing with the long backlog even more tedious if the bugs are moved.
>>
>
> storyboard is certainly not perfect, but there are also great features it
> does have to help deal with backlog. We can set up a board, like we did for
> zuulv3:
>
> https://storyboard.openstack.org/#!/board/41
>
> Jim also wrote 'boartty' which is like gertty but for doing storyboard
> things.
>
> Which is to say - it's got issues, but it's also got a bunch of positives
> too.
>
> Also there are lots of issues that intersect between sdk and
>> python-openstackclient, so moving both at the same time would also
>> sound reasonable.
>>
>
> I could see waiting until we move python-openstackclient. However, we've
> got the issue already with shade bugs being in storyboard already and sdk
> bugs being in launchpad. With shade moving to having its implementation be
> in openstacksdk, over this cycle I expect the number of bugs people report
> against shade wind up actually being against openstacksdk to increase quite
> a bit.
>
> Maybe we should see if the python-openstackclient team wants to migrate
> too?
>

Although I have limited experience on storyboard, I think it is ready for
our bug tracking.
As Jens mentioned, not a small number of bugs are referred to from both OSC
and SDK.
One good news on OSC launchpad bug is that we do not use tag aggressively.
If Dean is okay, I believe we can migrate to storyboard.

Akihiro


>
> What do people think?
>
> Monty
>
>
> __
> OpenStack Development Mailing 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] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules

[Akihiro Motoki]

Hi Kaz and Ivan,

Yeah, it is worth discussed officially in the horizon team meeting or the
mailing list thread to get a consensus.
Hopefully you can add this topic to the horizon meeting agenda.

After sending the previous mail, I noticed anther option. I see there are
several options now.
(1) Keep xstatic-core and horizon-core same.
(2) Add specific members to xstatic-core
(3) Add specific horizon-plugin core to xstatic-core
(4) Split core membership into per-repo basis (perhaps too complicated!!)

My current vote is (2) as xstatic-core needs to understand what is xstatic
and how it is maintained.

Thanks,
Akihiro


2018-03-20 17:17 GMT+09:00 Kaz Shinohara :

> Hi Akihiro,
>
>
> Thanks for your comment.
> The background of my request to add us to xstatic-core comes from
> Ivan's comment in last PTG's etherpad for heat-dashboard discussion.
>
> https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussion
> Line135, "we can share ownership if needed - e0ne"
>
> Just in case, could you guys confirm unified opinion on this matter as
> Horizon team ?
>
> Frankly speaking I'm feeling the benefit to make us xstatic-core
> because it's easier & smoother to manage what we are taking for
> heat-dashboard.
> On the other hand, I can understand what Akihiro you are saying, the
> newly added repos belong to Horizon project & being managed by not
> Horizon core is not consistent.
> Also having exception might make unexpected confusion in near future.
>
> Eventually we will follow your opinion, let me hear Horizon team's
> conclusion.
>
> Regards,
> Kaz
>
>
> 2018-03-20 12:58 GMT+09:00 Akihiro Motoki :
> > Hi Kaz,
> >
> > These repositories are under horizon project. It looks better to keep the
> > current core team.
> > It potentially brings some confusion if we treat some horizon plugin team
> > specially.
> > Reviewing xstatic repos would be a small burden, wo I think it would work
> > without problem even if only horizon-core can approve xstatic reviews.
> >
> >
> > 2018-03-20 10:02 GMT+09:00 Kaz Shinohara :
> >>
> >> Hi Ivan, Horizon folks,
> >>
> >>
> >> Now totally 8 xstatic-** repos for heat-dashboard have been landed.
> >>
> >> In project-config for them, I've set same acl-config as the existing
> >> xstatic repos.
> >> It means only "xstatic-core" can manage the newly created repos on
> gerrit.
> >> Could you kindly add "heat-dashboard-core" into "xstatic-core" like as
> >> what horizon-core is doing ?
> >>
> >> xstatic-core
> >> https://review.openstack.org/#/admin/groups/385,members
> >>
> >> heat-dashboard-core
> >> https://review.openstack.org/#/admin/groups/1844,members
> >>
> >> Of course, we will surely touch only what we made, just would like to
> >> manage them smoothly by ourselves.
> >> In case we need to touch the other ones, will ask Horizon team for help.
> >>
> >> Thanks in advance.
> >>
> >> Regards,
> >> Kaz
> >>
> >>
> >> 2018-03-14 15:12 GMT+09:00 Xinni Ge :
> >> > Hi Horizon Team,
> >> >
> >> > I reported a bug about lack of ``ADD_XSTATIC_MODULES`` plugin option,
> >> >  and submitted a patch for it.
> >> > Could you please help to review the patch.
> >> >
> >> > https://bugs.launchpad.net/horizon/+bug/1755339
> >> > https://review.openstack.org/#/c/552259/
> >> >
> >> > Thank you very much.
> >> >
> >> > Best Regards,
> >> > Xinni
> >> >
> >> > On Tue, Mar 13, 2018 at 6:41 PM, Ivan Kolodyazhny 
> >> > wrote:
> >> >>
> >> >> Hi Kaz,
> >> >>
> >> >> Thanks for cleaning this up. I put +1 on both of these patches
> >> >>
> >> >> Regards,
> >> >> Ivan Kolodyazhny,
> >> >> http://blog.e0ne.info/
> >> >>
> >> >> On Tue, Mar 13, 2018 at 4:48 AM, Kaz Shinohara  >
> >> >> wrote:
> >> >>>
> >> >>> Hi Ivan & Horizon folks,
> >> >>>
> >> >>>
> >> >>> Now we are submitting a couple of patches to have the new xstatic
> >> >>> modules.
> >> >>> Let me request you to have review the following patches.
> >> >>> We need Horizon PTL's +1 to move these forward.
> >> >>>
> >> >&g

Re: [openstack-dev] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules

[Akihiro Motoki]

Hi Kaz,

These repositories are under horizon project. It looks better to keep the
current core team.
It potentially brings some confusion if we treat some horizon plugin team
specially.
Reviewing xstatic repos would be a small burden, wo I think it would work
without problem even if only horizon-core can approve xstatic reviews.


2018-03-20 10:02 GMT+09:00 Kaz Shinohara :

> Hi Ivan, Horizon folks,
>
>
> Now totally 8 xstatic-** repos for heat-dashboard have been landed.
>
> In project-config for them, I've set same acl-config as the existing
> xstatic repos.
> It means only "xstatic-core" can manage the newly created repos on gerrit.
> Could you kindly add "heat-dashboard-core" into "xstatic-core" like as
> what horizon-core is doing ?
>
> xstatic-core
> https://review.openstack.org/#/admin/groups/385,members
>
> heat-dashboard-core
> https://review.openstack.org/#/admin/groups/1844,members
>
> Of course, we will surely touch only what we made, just would like to
> manage them smoothly by ourselves.
> In case we need to touch the other ones, will ask Horizon team for help.
>
> Thanks in advance.
>
> Regards,
> Kaz
>
>
> 2018-03-14 15:12 GMT+09:00 Xinni Ge :
> > Hi Horizon Team,
> >
> > I reported a bug about lack of ``ADD_XSTATIC_MODULES`` plugin option,
> >  and submitted a patch for it.
> > Could you please help to review the patch.
> >
> > https://bugs.launchpad.net/horizon/+bug/1755339
> > https://review.openstack.org/#/c/552259/
> >
> > Thank you very much.
> >
> > Best Regards,
> > Xinni
> >
> > On Tue, Mar 13, 2018 at 6:41 PM, Ivan Kolodyazhny 
> wrote:
> >>
> >> Hi Kaz,
> >>
> >> Thanks for cleaning this up. I put +1 on both of these patches
> >>
> >> Regards,
> >> Ivan Kolodyazhny,
> >> http://blog.e0ne.info/
> >>
> >> On Tue, Mar 13, 2018 at 4:48 AM, Kaz Shinohara 
> >> wrote:
> >>>
> >>> Hi Ivan & Horizon folks,
> >>>
> >>>
> >>> Now we are submitting a couple of patches to have the new xstatic
> >>> modules.
> >>> Let me request you to have review the following patches.
> >>> We need Horizon PTL's +1 to move these forward.
> >>>
> >>> project-config
> >>> https://review.openstack.org/#/c/551978/
> >>>
> >>> governance
> >>> https://review.openstack.org/#/c/551980/
> >>>
> >>> Thanks in advance:)
> >>>
> >>> Regards,
> >>> Kaz
> >>>
> >>>
> >>> 2018-03-12 20:00 GMT+09:00 Radomir Dopieralski  >:
> >>> > Yes, please do that. We can then discuss in the review about
> technical
> >>> > details.
> >>> >
> >>> > On Mon, Mar 12, 2018 at 2:54 AM, Xinni Ge 
> >>> > wrote:
> >>> >>
> >>> >> Hi, Akihiro
> >>> >>
> >>> >> Thanks for the quick reply.
> >>> >>
> >>> >> I agree with your opinion that BASE_XSTATIC_MODULES should not be
> >>> >> modified.
> >>> >> It is much better to enhance horizon plugin settings,
> >>> >>  and I think maybe there could be one option like
> ADD_XSTATIC_MODULES.
> >>> >> This option adds the plugin's xstatic files in STATICFILES_DIRS.
> >>> >> I am considering to add a bug report to describe it at first, and
> give
> >>> >> a
> >>> >> patch later maybe.
> >>> >> Is that ok with the Horizon team?
> >>> >>
> >>> >> Best Regards.
> >>> >> Xinni
> >>> >>
> >>> >> On Fri, Mar 9, 2018 at 11:47 PM, Akihiro Motoki 
> >>> >> wrote:
> >>> >>>
> >>> >>> Hi Xinni,
> >>> >>>
> >>> >>> 2018-03-09 12:05 GMT+09:00 Xinni Ge :
> >>> >>> > Hello Horizon Team,
> >>> >>> >
> >>> >>> > I would like to hear about your opinions about how to add new
> >>> >>> > xstatic
> >>> >>> > modules to horizon settings.
> >>> >>> >
> >>> >>> > As for Heat-dashboard project embedded 3rd-party files issue,
> >>> >>> > thanks
> >>> >>> > for
> >>> >>> > your advices in Dublin

[openstack-dev] [horizon][plugins] mox -> mock migration

[Akihiro Motoki]

Hi horizon plugin developers,

As you know, mox-removal is one of the community goal in Rocky and
horizon team is working on removing usage of mox [1].

This mail announces the plan of dropping mox dependencies in horizon
test helpers (horizon.test.helpers.TestCase and/or
openstack_dashboard.test.helpers.TestCase).

1) The first step is to introduce "use_mox" flag in
horizon.test.helpers.TestCase. The flag is available now.
If you set the flag to False, you can run your plugin test without mox.
The default value of use_mox is False for
horizon.test.helpers.TestCase [2] and True for
openstack_dashboard.test.helpers.TestCase [3].

2) After Rocky-1, use_mox of openstack_dashboard.test.helpers.TestCase
will be changed from True to False.
 This means your plugin needs to set use_mox to True explicitly if
your unit tests still depends on mox.
 Our suggestion is to set use_mox=True until Rocky-1 milestone if
your tests depends on mox not to break your gate.

3) After Rocky RC1 is released, "use_mox" flag in the horizon repo
will be dropped.
This means use_mox flag will no longer be in effect.
If your plugin tests still depends on mox at this stage, your
plugin test needs to set up mox explicitly.

Thanks,
Akihiro Motoki (amotoki)

[1] https://blueprints.launchpad.net/horizon/+spec/mock-framework-in-unit-tests
[2] 
https://github.com/openstack/horizon/blob/6e29fdde1edc67a6797eba2c3f9c557f840d4ea7/horizon/test/helpers.py#L138
[3] 
https://github.com/openstack/horizon/blob/6e29fdde1edc67a6797eba2c3f9c557f840d4ea7/openstack_dashboard/test/helpers.py#L257

__
OpenStack Development Mailing List (not for 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][neutron] tools/tox_install changes - breakage with constraints

[Akihiro Motoki]

The current version of proposed patches which drops tox_install.sh
works in our CI. Even if we have neutron>=12.0.0 (queens) or
horizon>=13.0.0 (queens), if we have "required-projects" in zuul v3
config, tox-sibling role ensures to install the latest master of
neutron/horizon. It is okay in our CI.

On the other hand, this change brings a couple of problems. I think it
is worth discussed broadly here.

(1) it makes difficult to run tests in local environment
We have only released version of neutron/horizon on PyPI. It means
PyPI version (i.e. queens) is installed when we run tox in our local
development. Most neutron stadium projects and horizon plugins depends
on the latest master. Test run in local environment will be broken. We
need to install the latest neutron/horizon manually. This confuses
most developers. We need to ensure that tox can run successfully in a
same manner in our CI and local environments.

(2) neutron/horizon version in requirements.txt is confusing
In the cycle-with-milestone model, a new version of neutron/horizon
will be released only when a release is shipped.
The code depends on the latest master, but requirements.txt says it
depends on queens or later. It sounds confusing.

Thanks,
Akihiro


2018-03-15 6:56 GMT+09:00 Andreas Jaeger :
> On 2018-03-14 20:46, Andreas Jaeger wrote:
>> On 2018-03-14 20:39, Andreas Jaeger wrote:
>>> We now have neutron and horizon in global-requirements and do not need
>>> to install them anymore with tools/tox_install.sh.
>>>
>>> This allows to simplify our jobs and testing.
>>>
>>> Unfortunately, the merging caused now the projects that install neutron
>>> and horizon via tools/tox_install to break with constraints.
>>>
>>> I'm currently pushing up changes for these using topic tox-siblings [1].
>>>
>>> Please merge those - and if you're pushing up changes yourself, let's
>>> use the same topic.
>>>
>>> Sorry for the breakage ;(
>>> Andreas
>>>
>>> [1] Links
>>> https://review.openstack.org/#/q/topic:tox-siblings+(status:open+OR+status:merged)
>>>
>>
>> Note that thanks to the tox-siblings feature, we really continue to
>> install neutron and horizon from git - and not use the versions in the
>> global-requirements constraints file,
>
> Btw. this work is part of what Monty proposed in
> http://lists.openstack.org/pipermail/openstack-dev/2017-November/124676.html
>
> 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

__
OpenStack Development Mailing List (not for 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] [devstack] horizon 'network create' panel does not distinguished

[Akihiro Motoki]

The detail of this issue is tracked in
https://bugs.launchpad.net/bugs/1755140 and it turned out that it is caused
by the older version of the enabled file of the template generator.

I strongly recommend to cover this in the release notes.

Akihiro

2018/03/13 午前9:45 "Xinni Ge" :

> Hello, Jaewook and everyone
>
> It looks like the error is caused by some angular module of heat-dashboard
> not being loaded correctly.
>
> I tried to reproduce it in my devstack by installing stable/queens
> Horiozn/Heat-dashboard, but couldn't see the same error.
>
> Maybe you want to try the following steps to restart web server and see if
> the issue can be fixed.
> Of course you can also remove the troubled panel in heat-dashboard, I will
> also describe how to do it as follows.
>
> 1. remove heat-dashboard related settings
> rm horizon/openstack_dashboard/local/enabled/_16*   # (particularly try
> to remove _1650_project_template_generator_panel.py to fix it)
> rm horizon/openstack_dashboard/local/local_settings.d/_1699_
> orchestration_settings.py*
> rm horizon/openstack_dashboard/conf/heat_policy.json
>
> 2. let horizon re-collect static files, and compress
> python manage.py collectstatic --clear
> python manage.py compress
>
> 3. restart apache server
> sudo service apache2 restart
>
> Hope the problem can be solved and everything goes well.
> And if anybody see the same error, please share more details about it.
>
> Best Regards,
> Xinni
>
> On Mon, Mar 12, 2018 at 9:55 PM, Jaewook Oh  wrote:
>
>> Thanks for feedback!
>>
>> As you said, I got errors in the JavaScript console.
>>
>> Below is the error log :
>>
>> 3bf910c7ae4c.js:652 JQMIGRATE: Logging is active
>> fddd6f634ef8.js:2299 Uncaught TypeError: Cannot read property 'layout' of
>> undefined
>> at Object.25../arrows (fddd6f634ef8.js:2299)
>> at s (fddd6f634ef8.js:2252)
>> at fddd6f634ef8.js:2252
>> at Object.1../lib/dagre (fddd6f634ef8.js:2252)
>> at s (fddd6f634ef8.js:2252)
>> at e (fddd6f634ef8.js:2252)
>> at fddd6f634ef8.js:2252
>> at fddd6f634ef8.js:2252
>> at fddd6f634ef8.js:2252
>> 25../arrows @ fddd6f634ef8.js:2299
>> s @ fddd6f634ef8.js:2252
>> (anonymous) @ fddd6f634ef8.js:2252
>> 1../lib/dagre @ fddd6f634ef8.js:2252
>> s @ fddd6f634ef8.js:2252
>> e @ fddd6f634ef8.js:2252
>> (anonymous) @ fddd6f634ef8.js:2252
>> (anonymous) @ fddd6f634ef8.js:2252
>> (anonymous) @ fddd6f634ef8.js:2252
>> 3bf910c7ae4c.js:699 Uncaught Error: [$injector:modulerr] Failed to
>> instantiate module horizon.app due to:
>> Error: [$injector:modulerr] Failed to instantiate module
>> horizon.dashboard.project.heat_dashboard.template_generator due to:
>> Error: [$injector:nomod] Module 'horizon.dashboard.project.hea
>> t_dashboard.template_generator' is not available! You either misspelled
>> the module name or forgot to load it. If registering a module ensure that
>> you specify the dependencies as the second argument.
>> http://errors.angularjs.org/1.5.8/$injector/nomod?p0=horizon
>> .dashboard.project.heat_dashboard.template_generator
>> at http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7
>> ae4c.js:699:8
>> at http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7
>> ae4c.js:818:59
>> at ensure (http://192.168.11.187/dashboa
>> rd/static/dashboard/js/3bf910c7ae4c.js:816:320)
>> at module (http://192.168.11.187/dashboa
>> rd/static/dashboard/js/3bf910c7ae4c.js:818:8)
>> at http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7
>> ae4c.js:925:35
>> at forEach (http://192.168.11.187/dashboa
>> rd/static/dashboard/js/3bf910c7ae4c.js:703:400)
>> at loadModules (http://192.168.11.187/dashboa
>> rd/static/dashboard/js/3bf910c7ae4c.js:924:156)
>> at http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7
>> ae4c.js:925:84
>> at forEach (http://192.168.11.187/dashboa
>> rd/static/dashboard/js/3bf910c7ae4c.js:703:400)
>> at loadModules (http://192.168.11.187/dashboa
>> rd/static/dashboard/js/3bf910c7ae4c.js:924:156)
>> http://errors.angularjs.org/1.5.8/$injector/modulerr?p0=hori
>> zon.dashboard.project.heat_dashboard.template_generator&
>> p1=Error%3A%20%5B%24injector%3Anomod%5D%20Module%20'
>> horizon.dashboard.project.heat_dashboard.template_generator'%20is%20not%
>> 20available!%20You%20either%20misspelled%20the%20module%
>> 20name%20or%20forgot%20to%20load%20it.%20If%20registerin
>> g%20a%20module%20ensure%20that%20you%20specify%20the%2
>> 0dependencies%20as%20the%20second%20argument.%0Ahttp%3A%2F%
>> 2Ferrors.angularjs.org%2F1.5.8%2F%24injector%2Fnomod%3Fp0%
>> 3Dhorizon.dashboard.project.heat_dashboard.template_
>> generator%0A%20%20%20%20at%20http%3A%2F%2F192.168.11.187%
>> 2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3bf910c7ae4
>> c.js%3A699%3A8%0A%20%20%20%20at%20http%3A%2F%2F192.168.
>> 11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3bf910c7ae4
>> c.js%3A818%3A59%0A%20%20%20%20at%20ensure%20(http%3A%2F%
>> 2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3b
>> f910c7

Re: [openstack-dev] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules

[Akihiro Motoki]

Hi Xinni,

2018-03-09 12:05 GMT+09:00 Xinni Ge :
> Hello Horizon Team,
>
> I would like to hear about your opinions about how to add new xstatic
> modules to horizon settings.
>
> As for Heat-dashboard project embedded 3rd-party files issue, thanks for
> your advices in Dublin PTG, we are now removing them and referencing as new
> xstatic-* libs.

Thanks for moving this forward.

> So we installed the new xstatic files (not uploaded as openstack official
> repos yet) in our development environment now, but hesitate to decide how to
> add the new installed xstatic lib path to STATICFILES_DIRS in
> openstack_dashboard.settings so that the static files could be automatically
> collected by *collectstatic* process.
>
> Currently Horizon defines BASE_XSTATIC_MODULES in
> openstack_dashboard/utils/settings.py and the relevant static fils are added
> to STATICFILES_DIRS before it updates any Horizon plugin dashboard.
> We may want new plugin setting keywords ( something similar to ADD_JS_FILES)
> to update horizon XSTATIC_MODULES (or directly update STATICFILES_DIRS).

IMHO it is better to allow horizon plugins to add xstatic modules
through horizon plugin settings. I don't think it is a good idea to
add a new entry in BASE_XSTATIC_MODULES based on horizon plugin
usages. It makes difficult to track why and where a xstatic module in
BASE_XSTATIC_MODULES is used.
Multiple horizon plugins can add a same entry, so horizon code to
handle plugin settings should merge multiple entries to a single one
hopefully.
My vote is to enhance the horizon plugin settings.

Akihiro

>
> Looking forward to hearing any suggestions from you guys, and
> Best Regards,
>
> Xinni Ge
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [heat] heat-dashboard is non-free, with broken unit test env

[Akihiro Motoki]

Thanks for clarification.
I was a bit confused with the two things because the patch dropped
some embedded stuffs like font-awesome.
Let's address the "embedded" problem soon :)

Akihiro

2018-03-02 14:27 GMT+00:00 Xinni Ge :
> Hi, Akihiro,
>
> The patch I submitted previously didn't solve the embedded problem.
> I would like to fix out the whole thing in several steps, because the
> current status of static files arrangment is quite messy.
>
> I will upload the javascript and css style files as xstatic-* projects and
> remove them from the code later on.
>
> I wanted to solve the unittest problem ASAP and assumed it will take some
> time to create xstatic repos and get the approval from infra team,
> so I just submitted this patch to let unittest go well at first.
>
> Thanks for asking, I am happy to hear from your all about the js and static
> files issue.
>
> Best regards,
>
> Xinni
>
> On Fri, Mar 2, 2018 at 1:29 PM, Akihiro Motoki  wrote:
>>
>> Hi Xinni,
>>
>> I looked at your patch which drops the vendors stuffs, but I still
>> have a question.
>>
>> The patch introduces some SCSS like:
>> - bootstrap.scss
>> - angular-notify.scss
>> - angular-material.scss
>>
>> Aren't they another type of "vendors" stuffs?
>> I don't understand why switching to SCSS solves the embedded "vendors"
>> problem?
>>
>> I would like to know opinions from zigo and Corey.
>>
>> Thanks,
>> Akihiro
>>
>>
>> 2018-03-01 21:30 GMT+00:00 Xinni Ge :
>> > Hi, there.
>> >
>> > This is a page of a similar unittest issue.
>> > https://bugs.launchpad.net/heat-dashboard/+bug/1752527
>> >
>> > We merged the following patch to fix the issue, and hope it also fix the
>> > trouble described here.
>> >  https://review.openstack.org/#/c/548924/
>> >
>> > As for the minified javascript files, we are working on removing from
>> > the
>> > source code,
>> >  and uploading as xstatic packages.
>> > Just need a little more time to finish it.
>> >
>> >
>> > Best regards,
>> >
>> > Xinni
>> >
>> > On Tue, Feb 27, 2018 at 10:48 AM, Thomas Goirand 
>> > wrote:
>> >>
>> >> On 02/23/2018 09:29 AM, Xinni Ge wrote:
>> >> > Hi there,
>> >> >
>> >> > We are aware of the javascript embedded issue, and working on it now,
>> >> > the patch will be summited later.
>> >> >
>> >> > As for the unittest failure, we are still investigating it. We will
>> >> > contant you as soon as we find out the cause.
>> >> >
>> >> > Sorry to bring troubles to you. We will be grateful if you could wait
>> >> > for a little longer.
>> >> >
>> >> > Best Regards,
>> >> >
>> >> > Xinni
>> >>
>> >> Hi,
>> >>
>> >> Thanks for this message. This lowers the frustration! :)
>> >> Let me know if there's any patch I could review.
>> >>
>> >> Cheers,
>> >>
>> >> Thomas Goirand (zigo)
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > --
>> > 葛馨霓 Xinni Ge
>> >
>> >
>> > __
>> > OpenStack Development Mailing 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
>
>
>
>
> --
> 葛馨霓 Xinni Ge
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [heat] heat-dashboard is non-free, with broken unit test env

[Akihiro Motoki]

Hi Xinni,

I looked at your patch which drops the vendors stuffs, but I still
have a question.

The patch introduces some SCSS like:
- bootstrap.scss
- angular-notify.scss
- angular-material.scss

Aren't they another type of "vendors" stuffs?
I don't understand why switching to SCSS solves the embedded "vendors" problem?

I would like to know opinions from zigo and Corey.

Thanks,
Akihiro


2018-03-01 21:30 GMT+00:00 Xinni Ge :
> Hi, there.
>
> This is a page of a similar unittest issue.
> https://bugs.launchpad.net/heat-dashboard/+bug/1752527
>
> We merged the following patch to fix the issue, and hope it also fix the
> trouble described here.
>  https://review.openstack.org/#/c/548924/
>
> As for the minified javascript files, we are working on removing from the
> source code,
>  and uploading as xstatic packages.
> Just need a little more time to finish it.
>
>
> Best regards,
>
> Xinni
>
> On Tue, Feb 27, 2018 at 10:48 AM, Thomas Goirand  wrote:
>>
>> On 02/23/2018 09:29 AM, Xinni Ge wrote:
>> > Hi there,
>> >
>> > We are aware of the javascript embedded issue, and working on it now,
>> > the patch will be summited later.
>> >
>> > As for the unittest failure, we are still investigating it. We will
>> > contant you as soon as we find out the cause.
>> >
>> > Sorry to bring troubles to you. We will be grateful if you could wait
>> > for a little longer.
>> >
>> > Best Regards,
>> >
>> > Xinni
>>
>> Hi,
>>
>> Thanks for this message. This lowers the frustration! :)
>> Let me know if there's any patch I could review.
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> 葛馨霓 Xinni Ge
>
> __
> OpenStack Development Mailing 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][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Akihiro Motoki]

Hi Gary,

You are talking about vender extension support in OSC, but this is
about python bindings.
I believe this is another topic. Commands implemented in OSC repo
already consumes OpenStack SDK, so the proposed change just increases
the number of python bindings supported in SDK.

Regarding the topic of third-party extension support after OSC
transition, possible options in my mind is to keep "neutron" CLI, or
to add some command which handle general network resources as
neutronclient OSC plugin. It is a compromise considering the current
neutron API. Note that OpenStackSDK proxy object supports
keystoneauth.Adapter, so even after migrating to OpenStackSDK, this
does not block arbitrary attributes immediately even though they are
things we would like to avoid. If you and/or boden are interested in
implementing so-called "generic network resource" commands in Neutron
OSC plugin, I can help the effort (as it speed up neutron CLI
deprecation).

Akihiro

2018-02-26 13:39 GMT+00:00 Gary Kotton :
> One of the concerns here is that the openstack client does not enable one to 
> configure extensions that are not part of the core reference architecture. So 
> any external third part that tries to have any etension added will not be 
> able to leverage the openstack client. This is a major pain point.
>
>
> On 2/26/18, 1:26 PM, "Monty Taylor"  wrote:
>
> On 02/26/2018 10:55 AM, Rabi Mishra wrote:
> > On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor  > <mailto:mord...@inaugust.com>> wrote:
> >
> > On 02/26/2018 09:57 AM, Akihiro Motoki wrote:
> >
> > Hi neutron and openstacksdk team,
> >
> > This mail proposes to change the first priority of 
> neutron-related
> > python binding to OpenStack SDK rather than neutronclient python
> > bindings.
> > I think it is time to start this as OpenStack SDK became a 
> official
> > project in Queens.
> >
> >
> > ++
> >
> >
> > [Current situations and problems]
> >
> > Network OSC commands are categorized into two parts: OSC and
> > neutronclient OSC plugin.
> > Commands implemented in OSC consumes OpenStack SDK
> > and commands implemented as neutronclient OSC plugin consumes
> > neutronclient python bindings.
> > This brings tricky situation that some features are supported
> > only in
> > OpenStack SDK and some features are supported only in 
> neutronclient
> > python bindings.
> >
> > [Proposal]
> >
> > The proposal is to implement all neutron features in OpenStack
> > SDK as
> > the first citizen,
> > and the neutronclient OSC plugin consumes corresponding
> > OpenStack SDK APIs.
> >
> > Once this is achieved, users of OpenStack SDK users can see all
> > network related features.
> >
> > [Migration plan]
> >
> > The migration starts from Rocky (if we agree).
> >
> > New features should be supported in OpenStack SDK and
> > OSC/neutronclient OSC plugin as the first priority. If new 
> feature
> > depends on neutronclient python bindings, it can be implemented 
> in
> > neutornclient python bindings first and they are ported as part 
> of
> > existing feature transition.
> >
> > Existing features only supported in neutronclient python
> > bindings are
> > ported into OpenStack SDK,
> > and neutronclient OSC plugin will consume them once they are
> > implemented in OpenStack SDK.
> >
> >
> > I think this is a great idea. We've got a bunch of good
> > functional/integrations tests in the sdk gate as well that we can
> > start running on neutron patches so that we don't lose cross-gating.
> >
> > [FAQ]
> >
> > 1. Will neutornclient python bindings be removed in future?
> >
> > Different from "neutron" CLI, as of now, there is no plan to
> > drop the
> > neutronclient python bindings.
> > Not a small number of projects consumes it, so it will be
> > maintained as-is.
> > The only change is that new features are im

[openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Akihiro Motoki]

Hi neutron and openstacksdk team,

This mail proposes to change the first priority of neutron-related
python binding to OpenStack SDK rather than neutronclient python
bindings.
I think it is time to start this as OpenStack SDK became a official
project in Queens.

[Current situations and problems]

Network OSC commands are categorized into two parts: OSC and
neutronclient OSC plugin.
Commands implemented in OSC consumes OpenStack SDK
and commands implemented as neutronclient OSC plugin consumes
neutronclient python bindings.
This brings tricky situation that some features are supported only in
OpenStack SDK and some features are supported only in neutronclient
python bindings.

[Proposal]

The proposal is to implement all neutron features in OpenStack SDK as
the first citizen,
and the neutronclient OSC plugin consumes corresponding OpenStack SDK APIs.

Once this is achieved, users of OpenStack SDK users can see all
network related features.

[Migration plan]

The migration starts from Rocky (if we agree).

New features should be supported in OpenStack SDK and
OSC/neutronclient OSC plugin as the first priority. If new feature
depends on neutronclient python bindings, it can be implemented in
neutornclient python bindings first and they are ported as part of
existing feature transition.

Existing features only supported in neutronclient python bindings are
ported into OpenStack SDK,
and neutronclient OSC plugin will consume them once they are
implemented in OpenStack SDK.

[FAQ]

1. Will neutornclient python bindings be removed in future?

Different from "neutron" CLI, as of now, there is no plan to drop the
neutronclient python bindings.
Not a small number of projects consumes it, so it will be maintained as-is.
The only change is that new features are implemented in OpenStack SDK first and
enhancements of neutronclient python bindings will be minimum.

2. Should projects that consume neutronclient python bindings switch
to OpenStack SDK?

Necessarily not. It depends on individual projects.
Projects like nova that consumes small set of neutron features can
continue to use neutronclient python bindings.
Projects like horizon or heat that would like to support a wide range
of features might be better to switch to OpenStack SDK.


3. 

Thanks,
Akihiro

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

Re: [openstack-dev] [heat] heat-dashboard is non-free, with broken unit test env

[Akihiro Motoki]

2018-02-21 23:35 GMT+09:00 Thomas Goirand :
> Hi there!
>
> I'm having big trouble package heat-dashboard for Debian. I hope I can
> get help through this list.
>
> In here:
>
> heat_dashboard/static/dashboard/project/heat_dashboard/template_generator/js/
>
> we have minified *only* versions of Javascript.
>
> 1/ Why is there only minified versions? That's non-free to me, Debian,
> and probably any other distro caring about OpenStack.
> 2/ Why do we even have a folder called "vendors"? Doesn't this sound
> really a bad practice?
> 3/ Why is there so many angular-*.min.js files? Do we need them all?
> 4/ Why isn't the package using xstatic-angular and friends?

IIUC, these javascript files are only used by the template generator
which was newly added after split out from horizon.
If you can provide only the Pike-compatible feature from, horizon,
code related to the template generator can be excluded.
I know it is not ideal and am not sure this is acceptable workaround.

Horizon docs contains a guideline on javascript and it discourages
embedded JS files.
https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html
heat-dashboard choice does not look the right way.

Akihiro

>
> As it stands, I can't upload heat-dashboard to Debian for Queens, and
> it's been removed from Horizon... :(
>
> Oh, and I almost forgot! When running unit tests, I get:
>
> PYTHON=python$i NOSE_WITH_OPENSTACK=1 \
> NOSE_OPENSTACK_COLOR=1 \
> NOSE_OPENSTACK_RED=0.05 \
> NOSE_OPENSTACK_YELLOW=0.025 \
> NOSE_OPENSTACK_SHOW_ELAPSED=1 \
> DJANGO_SETTINGS_MODULE=heat_dashboard.test.settings \
> python$i
> /home/zigo/sources/openstack/queens/services/heat-dashboard/build-area/heat-dashboard-1.0.2/manage.py
> test heat_dashboard.test --settings=heat_dashboard.test.settings
>
> No local_settings file found.
> Traceback (most recent call last):
>   File
> "/home/zigo/sources/openstack/queens/services/heat-dashboard/build-area/heat-dashboard-1.0.2/manage.py",
> line 23, in 
> execute_from_command_line(sys.argv)
>
> [ ... some stack dump ...]
>
>   File "/usr/lib/python3/dist-packages/fasteners/process_lock.py", line
> 147, in acquire
> self._do_open()
>   File "/usr/lib/python3/dist-packages/fasteners/process_lock.py", line
> 119, in _do_open
> self.lockfile = open(self.path, 'a')
> PermissionError: [Errno 13] Permission denied:
> '/usr/lib/python3/dist-packages/openstack_dashboard/local/_usr_lib_python3_dist-packages_openstack_dashboard_local_.secret_key_store.lock'
>
> What thing is attempting to write in my read only /usr, while Horizon is
> correctly installed, and writing its secret key material as it should,
> in /var/lib/openstack-dashboard? It's probably due to me, but here, how
> can I make heat-dashboard unit test behave during package build? What's
> this "No local_settings file found" thing? Other dashboards didn't
> complain in this way...
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing 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][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

[Akihiro Motoki]

I don't think we need to drop translation support NOW (at least for
neutron-lbaas-dashboard).
There might be fixes which affects translation and/or there might be
translation improvements.
I don't think a deprecation means no translation fix any more. It
sounds too aggressive.
Is there any problem to keep translations for them?

Akihiro

2018-02-01 3:28 GMT+09:00 Andreas Jaeger :
> In that case, I suggest to remove translation jobs for these repositories,
>
> 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

__
OpenStack Development Mailing List (not for 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][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

[Akihiro Motoki]

Good to hear that! Thanks for your leadership.

Thanks,
Akihiro Motoki

2018-02-01 2:50 GMT+09:00 Michael Johnson :
> Today we are announcing the start of the deprecation cycle for
> neutron-lbaas and neutron-lbaas-dashboard. As part of the neutron
> stadium evolution [1], neutron-lbaas was identified as a project that
> should spin out of neutron and become its own project. The
> specification detailing this process was approved [2] during the
> newton OpenStack release cycle.
>
> OpenStack load balancing no longer requires deep access into the
> neutron code base and database. All of the required networking
> capabilities are now available via stable APIs. This change de-couples
> the load balancing release versioning from the rest of the OpenStack
> deployment. Since Octavia uses stable APIs when interacting with other
> OpenStack services, you can run a different version of Octavia in
> relation to your OpenStack cloud deployment.
>
> Per OpenStack deprecation policy, both projects will continue to
> receive support and bug fixes during the deprecation cycle, but no new
> features will be added to either project. All future feature
> enhancements will now occur on the Octavia project(s) [3].
>
> We are not announcing the end of the deprecation cycle at this time,
> but it will follow OpenStack policy of at least two release cycles
> prior to retirement. This means that the first release that these
> projects could be retired would be the “T” OpenStack release cycle.
>
> We have created a Frequently Asked Questions (FAQ) wiki page to help
> answer additional questions you may have about this process:
> https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation
>
> For more information or if you have additional questions, please see
> the following resources:
>
> The FAQ: https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation
>
> The Octavia documentation: https://docs.openstack.org/octavia/latest/
>
> Reach out to us via IRC on the Freenode IRC network, channel #openstack-lbaas
>
> Weekly Meeting: 20:00 UTC on Wednesdays in #openstack-lbaas on the
> Freenode IRC network.
>
> Sending email to the OpenStack developer mailing list: openstack-dev
> [at] lists [dot] openstack [dot] org. Please prefix the subject with
> '[openstack-dev][Octavia]'
>
> Thank you for your support and patience during this transition,
>
> Michael Johnson
> Octavia PTL
>
> [1] 
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
> [2] 
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
> [3] https://governance.openstack.org/tc/reference/projects/octavia.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

[Akihiro Motoki]

2018-01-31 17:51 GMT+09:00 Saverio Proto :
> Hello all,
>
> I am again proposing a change due to operations experience. I am
> proposing a clean and simple cherry-pick to Ocata.
>
> "it depends" works pretty bad as policy for accepting patches.
>
> Now I really dont understand what is the issue with the Stable Policy
> and this patch:
>
> https://review.openstack.org/#/c/539439/
>
> This is a UX problem. Horizon is giving the wrong information to the user.
>
> I got this answer:
> Ocata is the second phase of stable branches [1]. Only critical bugfixes
> and security patches are acceptable. I don't think it belongs to the
> category.
>

It is really understandable.

I am the person who put -1 on the horizon backport raised here. In
this specific case, the proposed backport does not import a new
confusion and it will provide a correct error message for a specific
case, so when I put -1 I struggled whether I put +2 or -1. It is
half-and-half. I am okay to remove my -1.

On the other hand, it is important to share some common criteria among
the stable reviewers.
different reviewers can apply different criteria. it is not productive
to define a project specific policy which is a bit different from the
common stable branch policy.
I would like to see some updated stable policy in near future as
output of LTS discussions.

Akihiro

> But merging a patch that changes a log file in Nova back to Newton was
> OKAY few weeks ago.
>
> I will not be able to be in person at the PTG, but please talk about
> this. People just give up upstreaming stuff like this.
>
> thank you
>
> Saverio
>
>
> On 15.11.17 03:37, Matt Riedemann wrote:
>> On 11/14/2017 10:58 AM, Davanum Srinivas wrote:
>>> Let's focus our energy on the etherpad please
>>>
>>> https://etherpad.openstack.org/p/LTS-proposal
>>>
>>> On Wed, Nov 15, 2017 at 3:35 AM, Davanum Srinivas 
>>> wrote:
 Saverio,

 Please see this :
 https://docs.openstack.org/project-team-guide/stable-branches.html for
 current policies.

 On Wed, Nov 15, 2017 at 3:33 AM, Saverio Proto
  wrote:
>> Which stable policy does that patch violate?  It's clearly a bug
>> because the wrong information is being logged.  I suppose it goes
>> against the string freeze rule? Except that we've stopped translating
>> log messages so maybe we don't need to worry about that in this case,
>> since it isn't an exception.
>
> Well, I also would like to understand more about stable policy
> violations.
> When I proposed such patches in the past for the release N-2 I have
> always got the answer: it is not a security issue so it will not be
> merged.
>
> This is a good example of how things have been working so far:
>
> https://review.openstack.org/#/q/677eb1c4160c08cfce2900495741f0ea15f566fa
>
>
> This cinder patch was merged in master. It was then merged in Mitaka.
> But it was not merged in Liberty just because "only security fixes"
> were
> allowed at that point.
>
> You can read that in the comments:
> https://review.openstack.org/#/c/306610/
>
> Is this kind of things going to change after the discussion in Sydney ?
> The discussion is not enough ? what we need to get done then ?
>
> thank you
>
> Saverio
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 Davanum Srinivas :: https://twitter.com/dims
>>>
>>>
>>>
>>
>> Heh, I'm reading this thread after approving all of those patches.
>>
>> The answer as to whether it's appropriate or not, is "it depends".
>> Depends on the patch, depends on the age of the branch, etc.
>>
>> In this case, newton is in phase 3 so normally it's only security or
>> critical fixes allowed, but in this case it's so trivial and so
>> obviously wrong that I was OK with approving it just to get it in before
>> we end of life the branch.
>>
>> So, it depends. And because it depends, that's also why we don't
>> automate the backport of every fix made on master. Because guess what,
>> we also backport "fixes" that introduce regressions, and when you do
>> that to n-1 (Pike at this point) then you still have a lot of time to
>> detect that and fix it upstream, but regressing things on the oldest
>> branch leaves very little time to (1) have it detected and (2) get it
>> fixed before end of life.
>>
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __
> OpenStack Development Maili

Re: [openstack-dev] [horizon] FFE Request for Queens

[Akihiro Motoki]

+1 for FFE. I can support it.

We need a final ack from our PTL.

Akihiro

2018-01-30 5:13 GMT+09:00 Lajos Katona :
> Hi,
>
> I would like to ask for FFE on the neutron-trunk-ui blueprint to let the
> admin panel for trunks be accepted for Queens.
>
> Based on discussion on IRC
> (http://eavesdrop.openstack.org/irclogs/%23openstack-horizon/%23openstack-horizon.2018-01-29.log.html#t2018-01-29T14:36:58
> ) the remaining part of the blueprint neutron-trunk-ui
> (https://blueprints.launchpad.net/horizon/+spec/neutron-trunk-ui) should be
> handled separately:
>
> The admin panel (https://review.openstack.org/516657) should be part of the
> Queens release, as now that is not dependent on the ngDetails patches. With
> this the blueprint should be set to implemented.
> The links (https://review.openstack.org/524619) for the ports details (trunk
> parent and subports) from the trunk panel should be handled in a bug report:
>
> https://bugs.launchpad.net/horizon/+bug/1746082
>
> Regards
> Lajos Katona
>
> __
> OpenStack Development Mailing 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] bug deputy report (week of Jan 22)

[Akihiro Motoki]

Hi neutrinos,

Sorry for a bit late report of the bug deputy of last week.
I think there are several number of interesting bugs reported.



[Needs attention]

https://bugs.launchpad.net/neutron/+bug/1745642 SG hybrid iptables
driver and FWaaS OVS driver create overlapping conntrack zones

MTU topics on ovs-agent
https://bugs.launchpad.net/neutron/+bug/1744101 vxlan interfaces doesn't get MTU
https://bugs.launchpad.net/neutron/+bug/1745150 neutron doesn't set MTU on ovs
I am not sure it depends on deployments or not. We need to evaluate
these carefully, while the priority haven't been decided.

https://bugs.launchpad.net/neutron/+bug/1746000 dnsmasq does not
fallback on SERVFAIL
It is still Undecided status. The solution of dropping strict-order
option sounds reasonable to me, but I haven't understood why
strict-order of dnsmasq is required.

https://bugs.launchpad.net/neutron/+bug/1745468 Conntrack entry
removal can take a long time on large deployments
Brian is working on this, but it is worth attracted for the release.

https://bugs.launchpad.net/neutron/+bug/1745386 Update FloatingIP to
set QoS policy on it fails
It is medium priority, but it is worth fixed as this is one of new
features in queens. The fix is already proposed.

https://bugs.launchpad.net/neutron/+bug/1745443 cannot restrict
/var/lib/neutron permissions
I am not sure we can allow 'dnsmasq' user to access
/var/lib/neutron/dhcp instead of /var/lib/neutron.
More input on SElinux(?) would be appreciated.

[tricky bugs]

https://bugs.launchpad.net/neutron/+bug/1745412
test_l3_agent_scheduler intermittent failures when running locally

[Open question]

Neutron haproxy logs are not being collected
https://bugs.launchpad.net/devstack/+bug/1744359
-> Is there anything remaining? The merged fix looks complete to me.

[Closes Bug]

Many fullstack tests failing because of some error in L3 agent
https://bugs.launchpad.net/neutron/+bug/1745013
-> Nice finding, Slawek. It was eventlet bug.
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126580.html

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

[openstack-dev] [release][requirements][horizon] django-openstack-auth retirement

[Akihiro Motoki]

Hi the release team and the requirements team,

I would like to have on django-openstack-auth (DOA) retirement.
In the thread of the announce of DOA retirement last week, I was
advised to release a transition package which provides no python
module and make horizon depend on it so that the transition can be
smooth.
http://lists.openstack.org/pipermail/openstack-dev/2018-January/thread.html#126428

To achieve this, the horizon team needs:
* to release django-openstack-auth 4.0.0 (the current version is 3.5.0
so 4.0.0 makes sense) https://review.openstack.org/#/c/538709/
* to add django-openstack-auth 4.0.0 to g-r and u-c (for queens)
* to add django-openstack-auth 4.0.0 to horizon queens RC1

I think there are two options in horizon queens:
- to release the transition package of django-openstack-auth 4.0.0 as
described above, or
- to just document the retirement of django-openstack-auth

The requirement release is in 9 hours.
I would like to ask advices from the release and requirements team.

Thanks,
Akihiro

2018-01-27 2:45 GMT+09:00 Jeremy Stanley :
> On 2018-01-24 08:47:30 -0600 (-0600), Monty Taylor wrote:
> [...]
>> Horizon and neutron were updated to start publishing to PyPI
>> already.
>>
>> https://review.openstack.org/#/c/531822/
>>
>> This is so that we can start working on unwinding the neutron and
>> horizon specific versions of jobs for neutron and horizon plugins.
>
> Nice! I somehow missed that merging a couple of weeks back. In that
> case, I suppose we could in theory do one final transitional package
> upload of DOA depending on the conflicting Horizon release if others
> think that's a good idea.
> --
> 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] [horizon][packaging] django-openstack-auth retirement

[Akihiro Motoki]

2018-01-27 2:45 GMT+09:00 Jeremy Stanley :
> On 2018-01-24 08:47:30 -0600 (-0600), Monty Taylor wrote:
> [...]
>> Horizon and neutron were updated to start publishing to PyPI
>> already.
>>
>> https://review.openstack.org/#/c/531822/
>>
>> This is so that we can start working on unwinding the neutron and
>> horizon specific versions of jobs for neutron and horizon plugins.
>
> Nice! I somehow missed that merging a couple of weeks back. In that
> case, I suppose we could in theory do one final transitional package
> upload of DOA depending on the conflicting Horizon release if others
> think that's a good idea.

Thanks for clarification.
Then, does it make sense to release django-openstack-auth 4.0.0 and
require it in horizon queens?
Note that the current latest version is 3.5.0 and older horizon
dependency is django-openstack-auth>=3.5.0.
Luckily enough, the requirement freeze is extended one week.

-- 
Akihiro Motoki

__
OpenStack Development Mailing List (not for 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][packaging] django-openstack-auth retirement

[Akihiro Motoki]

2018-01-22 20:30 GMT+09:00 Jeremy Stanley :
> On 2018-01-22 14:40:49 +0900 (+0900), Akihiro Motoki wrote:
> [...]
>> If you install horizon and django-openstack-auth by using pip (instead
>> of distribution packages), please uninstall django-openstack-auth
>> python package before upgrading horizon.
>> Otherwise, "openstack_auth" module is maintained by both horizon and
>> django-openstack-auth after upgrading horizon and it confuses the pip
>> file management, while horizon works.
> [...]
>
> If we were already publishing Horizon to PyPI, we could have a new
> (and final) major version of DOA as a transitional package to stop
> providing any module itself and depend on the new version of Horizon
> which provides that module instead. I suppose without Horizon on
> PyPI, documentation of the issue is the most we can do for this
> situation.

Horizon usually does not publish its releases to PyPI, so I think what
we can do is to document it.

P.S.
The only exceptions on PyPI horizon are 12.0.2 and 2012.2 releases.
12.0.2 was released last week but I don't know why it is available at
PyPI. In deliverables/pike/horizon.yaml in the openstack/releases
repo, we don't have "include-pypi-link: yes".

Thanks,
Akihiro

__
OpenStack Development Mailing 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] [horizon][packaging] django-openstack-auth retirement

[Akihiro Motoki]

Hi, packaging teams and operators

This mail is the announcement of retirement of django-openstack-auth
python package in the Queens release. Horizon team merged the code of
django-openstack-auth into the horizon repo mainly from the
maintenance reason. For more detail, see the blueprint
https://blueprints.launchpad.net/horizon/+spec/merge-openstack-auth.

[To packaging teams]
Ensure not to install django-openstack-auth in Queens horizon package.
"openstack_auth" python module is now provided by horizon instead of
django_openstack_auth.

[To operators]
If you install horizon and django-openstack-auth by using pip (instead
of distribution packages), please uninstall django-openstack-auth
python package before upgrading horizon.
Otherwise, "openstack_auth" module is maintained by both horizon and
django-openstack-auth after upgrading horizon and it confuses the pip
file management, while horizon works.

If you have questions, feel to reach the horizon team.

Thanks,
Akihiro

__
OpenStack Development Mailing List (not for 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] Bug deputy report

[Akihiro Motoki]

Gary,

> I need to drop off bug duty on Thursday night so if someone can please swap 
> me for Friday.

I am a bug deputy of the next week. I can start my coverage from this Friday.

Thanks,
Akihiro

2018-01-16 21:51 GMT+09:00 Gary Kotton :
> Hi,
>
> Things have been relatively quiet. There are two bugs:
>
> 1. https://bugs.launchpad.net/neutron/+bug/1743480 - I think that we can
> leverage tags here so that should address the issue. Would be interesting to
> know what others thing.
>
> 2. https://bugs.launchpad.net/neutron/+bug/1743552 - patch in review
> https://review.openstack.org/#/c/534263/
>
> I need to drop off bug duty on Thursday night so if someone can please swap
> me for Friday.
>
> Thanks
>
> Gary
>
>
> __
> OpenStack Development Mailing 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] Help with fixing python-pint fixing failed tests with last python-numpy

[Akihiro Motoki]

btw, python-pint is used in horizon.utils.units but the module is
actually not used anywhere.
It was used in the metering panel (ceilometer support) but the panel
was dropped long ago.
In addition, there seems no horizon plugins that consume the module [1]
(daisycloud-core import the module but it has a copy of horizon code
in its repo, so it looks unrelated)

I guess horizon can drop horizon.utils.units.
Any objection?

[1] http://codesearch.openstack.org/?q=import%20units&i=nope&files=&repos=

2017-12-20 22:28 GMT+09:00 Thomas Goirand :
> Hi list!
>
> Pint is a (test) dependency for horizon (and therefore, an indirect
> dependency for all Horizon plugins).
>
> Since the update of python-numpy in Debian Sid, pint fails to build. The
> issue was reported to the Debian BTS:
>
> https://bugs.debian.org/876921
>
> and to the upstream github:
> https://github.com/hgrecco/pint/issues/577
>
> None of these bug entries received patches. I attempted to understand
> myself, though it is above my skills.
>
> Could anyone help and provide a patch?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing 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] [horizon] Adding Ivan Kolodyazhny to the Horizon Core team

[Akihiro Motoki]

Welcome Ivan to the team!

Akihiro

2017-12-16 1:52 GMT+09:00 Ying Zuo (yinzuo) :
> Hi everyone,
>
>
>
> After some discussion with the Horizon Core team, I am pleased to announce
> that we are adding Ivan Kolodyazhny to the team. Ivan has been actively
> contributing to Horizon since the beginning of the Pike release. He has
> worked on many bug fixes, blueprints, and performed thorough code reviews.
> You may have known him by his IRC nickname e0ne since he's one of the most
> active members on #openstack-horizon. Please join me in welcoming Ivan to
> the Horizon Core team :)
>
>
>
>
>
> Regards,
>
> Ying
>
>
>
>
> __
> OpenStack Development Mailing 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] [horizon][heat] heat-dashboard is ready for Horizon team's review

[Akihiro Motoki]

I have another announcement on heat-dashboard split out.

I moved the horizon bugs related to heat to heat-dashboard launchpad
project last week.
IIRC about 25 bugs were forwarded. I hope heat-dashboard team can
investigate them.

Akihiro

2017-12-06 15:46 GMT+09:00 Akihiro Motoki :
> Hi Kaz,
>
> 2017-12-05 18:45 GMT+09:00 Kaz Shinohara :
>> Hi Akihiro, Horizon & Heat team,
>>
>>
>> We've slightly updated your change for the split out, please check
>> https://review.openstack.org/#/c/523402/
>
> Thanks for updating the horizon patch. Is it ready to merge from the
> perspective of heat dashboard team?
>
>> One non-voting job failed but hopefully not related to this change.
>
> The failing non-voting job is not related to the patch.
> It is for Django 2.0 support but horizon has not support Django 2.0,
> so it always fails now.
>
>> In parallel, we could confirm that heat-dashboard works without any
>> issue along with this change.
>>
>> Also resolved the points what Akihiro kindly commented.
>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>
>> The thing we should discuss going forward is how to handle admin info
>> panel for Heat.
>> Personally information we can see from the panel is really limited,
>> just a list of heat engine services, so might be ok to be removed.
>> https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/info/tables.py#L256
>> I've never seen other dashboards supporting admin functions, better to
>> follow others & keep simplicity.
>> Any opinion will be welcome :)
>
> Yeah, it makes sense.
>
> Perhaps the system panel needs to be pluggable.
> As of now, it sounds no problem to remove the list of head services 
> temporarily.
>
> Thanks,
> Akihiro
>
>>
>> Regards,
>> Kaz
>>
>>
>> 2017-11-29 12:39 GMT+09:00 Kaz Shinohara :
>>> Hi Akihiro,
>>>
>>>
>>> Thanks for your quick response!
>>>
>>> As you requested, we will check & update your patch to slit out heat
>>> support from Horizon repo.
>>> https://review.openstack.org/#/c/523402/
>>>
>>> Also replied for your comment in our etherpad, please kindly check.
>>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>>
>>> Regards,
>>> Kaz
>>>
>>> 2017-11-28 21:08 GMT+09:00 Akihiro Motoki :
>>>> Hi Kaz,
>>>>
>>>> Good hear the good progress of heat-dashboard. Thanks.
>>>>
>>>> I created a blueprint in horizon to track the effort (mainly in
>>>> horizon side) and assign it to you:
>>>> https://blueprints.launchpad.net/horizon/+spec/heat-dashboard-split-out
>>>> I also left comments in your etherpad.
>>>>
>>>> I think it is time to prepare a patch which drops heat-dashboard code
>>>> from horizon and test the new dashboard with it. Could you propose the
>>>> patch?
>>>>
>>>> Thanks,
>>>> Akihiro
>>>>
>>>>
>>>> 2017-11-28 16:32 GMT+09:00 Kaz Shinohara :
>>>>> Hi Horizon team,
>>>>>
>>>>>
>>>>> As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
>>>>> ready, please kindly review it.
>>>>>
>>>>> http://git.openstack.org/cgit/openstack/heat-dashboard
>>>>>
>>>>> Also we described points to be clarified in this review, if you find
>>>>> anything to be noted/fixed, please feel free to put your comment on
>>>>> this etherpad, we will respond to them.
>>>>>
>>>>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>>>>
>>>>> We are planning to land heat-dashboard in queens-2, hopefully we will
>>>>> fix any issue until then.
>>>>>
>>>>> Your cooperation will be highly appreciated.
>>>>>
>>>>> Regards,
>>>>> Kaz Shinohara
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [horizon][heat] heat-dashboard is ready for Horizon team's review

[Akihiro Motoki]

Hi Kaz,

2017-12-05 18:45 GMT+09:00 Kaz Shinohara :
> Hi Akihiro, Horizon & Heat team,
>
>
> We've slightly updated your change for the split out, please check
> https://review.openstack.org/#/c/523402/

Thanks for updating the horizon patch. Is it ready to merge from the
perspective of heat dashboard team?

> One non-voting job failed but hopefully not related to this change.

The failing non-voting job is not related to the patch.
It is for Django 2.0 support but horizon has not support Django 2.0,
so it always fails now.

> In parallel, we could confirm that heat-dashboard works without any
> issue along with this change.
>
> Also resolved the points what Akihiro kindly commented.
> https://etherpad.openstack.org/p/heat-dashboard-review-point
>
> The thing we should discuss going forward is how to handle admin info
> panel for Heat.
> Personally information we can see from the panel is really limited,
> just a list of heat engine services, so might be ok to be removed.
> https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/info/tables.py#L256
> I've never seen other dashboards supporting admin functions, better to
> follow others & keep simplicity.
> Any opinion will be welcome :)

Yeah, it makes sense.

Perhaps the system panel needs to be pluggable.
As of now, it sounds no problem to remove the list of head services temporarily.

Thanks,
Akihiro

>
> Regards,
> Kaz
>
>
> 2017-11-29 12:39 GMT+09:00 Kaz Shinohara :
>> Hi Akihiro,
>>
>>
>> Thanks for your quick response!
>>
>> As you requested, we will check & update your patch to slit out heat
>> support from Horizon repo.
>> https://review.openstack.org/#/c/523402/
>>
>> Also replied for your comment in our etherpad, please kindly check.
>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>
>> Regards,
>> Kaz
>>
>> 2017-11-28 21:08 GMT+09:00 Akihiro Motoki :
>>> Hi Kaz,
>>>
>>> Good hear the good progress of heat-dashboard. Thanks.
>>>
>>> I created a blueprint in horizon to track the effort (mainly in
>>> horizon side) and assign it to you:
>>> https://blueprints.launchpad.net/horizon/+spec/heat-dashboard-split-out
>>> I also left comments in your etherpad.
>>>
>>> I think it is time to prepare a patch which drops heat-dashboard code
>>> from horizon and test the new dashboard with it. Could you propose the
>>> patch?
>>>
>>> Thanks,
>>> Akihiro
>>>
>>>
>>> 2017-11-28 16:32 GMT+09:00 Kaz Shinohara :
>>>> Hi Horizon team,
>>>>
>>>>
>>>> As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
>>>> ready, please kindly review it.
>>>>
>>>> http://git.openstack.org/cgit/openstack/heat-dashboard
>>>>
>>>> Also we described points to be clarified in this review, if you find
>>>> anything to be noted/fixed, please feel free to put your comment on
>>>> this etherpad, we will respond to them.
>>>>
>>>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>>>
>>>> We are planning to land heat-dashboard in queens-2, hopefully we will
>>>> fix any issue until then.
>>>>
>>>> Your cooperation will be highly appreciated.
>>>>
>>>> Regards,
>>>> Kaz Shinohara
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

[Akihiro Motoki]

+1 from me!

2017-11-30 4:21 GMT+09:00 Miguel Lavalle :
> Hi Neutron Team,
>
> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
> has been an active contributor to the project since the Mitaka cycle. He has
> been instrumental in the development of the QoS capabilities in Neutron,
> becoming the lead of the sub-team focused on that set of features. More
> recently, he has collaborated in the implementation of OVO and is an active
> participant in the CI sub-team. His number of code reviews during the Queens
> cycle is on par with the leading core members of the team:
> http://stackalytics.com/?module=neutron
>
> In my opinion, his efforts are highly valuable to the team and we will be
> very lucky to have him as a fully voting core.
>
> I will keep this nomination open for a week as customary,
>
> Thank you,
>
> Miguel
>
> __
> OpenStack Development Mailing 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] [horizon][heat] heat-dashboard is ready for Horizon team's review

[Akihiro Motoki]

Hi Kaz,

Good hear the good progress of heat-dashboard. Thanks.

I created a blueprint in horizon to track the effort (mainly in
horizon side) and assign it to you:
https://blueprints.launchpad.net/horizon/+spec/heat-dashboard-split-out
I also left comments in your etherpad.

I think it is time to prepare a patch which drops heat-dashboard code
from horizon and test the new dashboard with it. Could you propose the
patch?

Thanks,
Akihiro


2017-11-28 16:32 GMT+09:00 Kaz Shinohara :
> Hi Horizon team,
>
>
> As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
> ready, please kindly review it.
>
> http://git.openstack.org/cgit/openstack/heat-dashboard
>
> Also we described points to be clarified in this review, if you find
> anything to be noted/fixed, please feel free to put your comment on
> this etherpad, we will respond to them.
>
> https://etherpad.openstack.org/p/heat-dashboard-review-point
>
> We are planning to land heat-dashboard in queens-2, hopefully we will
> fix any issue until then.
>
> Your cooperation will be highly appreciated.
>
> Regards,
> Kaz Shinohara
>
> __
> OpenStack Development Mailing 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] Debug tool

[Akihiro Motoki]

Forwarding the mail to openstack-operator ML.
I believe the operator list is a better to place to discuss this topic.

This is about 'neutron-debug' command.
https://github.com/openstack/neutron/blob/master/setup.cfg#L48

Thanks,
Akihiro

2017-11-19 21:24 GMT+09:00 Gary Kotton :
> Hi,
>
> Out of interest is anyone using this tool? If so can you please let us know.
> This was marked as deprecated in about 18months ago in favor of a tool that
> was an idea that never actually materialized.
>
> Thanks
>
> Gary
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Release-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

[Akihiro Motoki]

2017-11-16 19:33 GMT+09:00 Andreas Jaeger :
> On 2017-11-16 11:27, Akihiro Motoki wrote:
>> 2017-11-16 18:59 GMT+09:00 Andreas Jaeger :
>>> On 2017-11-15 19:07, Doug Hellmann wrote:
>>>> [...]
>>>> Someone needs to figure that out. Unfortunately, I don't have the
>>>> bandwidth right now. Maybe you, or someone else from one of the affected 
>>>> projects, can work on it?
>>>>
>>>> Two options have been discussed so far:
>>>>
>>>> 1. Create special jobs for neutron and horizon projects that install
>>>>neutron or horizon, like we do for the release jobs.
>>>>
>>>> 2. Redefine the release notes job so that it doesn't use tox
>>>>but installs only the pieces it needs to run a sphinx build. The
>>>>CTI is already defined in a way to support that [1].
>>>>
>>>> My current preference is for option 2. There may be other options
>>>> that we haven't explored, though.
>>> I gave it a try in https://review.openstack.org/520362. Note that this
>>> is only the building part, publishing part is separate - let's first
>>> iterate on this one,
>> I noticed most projects require to install themselves now to set
>> 'version' and 'release' variables in releasenotes/source/conf.py.
>> For example, 
>> http://git.openstack.org/cgit/openstack/nova/tree/releasenotes/source/conf.py#n51
>> I think we cannot build release notes without installing a project itself.
>
> That's really sad ;(
>
> But why would we need to set version and release for the releasenotes at
> all? We only have one - unversioned - document.
>
> I suggest to just get rid of it,

Totally agree.

I think when we migrated to openstckdocstheme version info was shown
in the rendered text
so we started to use version info in conf.py. Some projects started it
and most projects followed it.
After migrating openstckdocstheme there is no visible version info in
the rendered relnotes,
so I think we can drop it.

Looking at  the openstackdocstheme document [1], PDF generation
expects 'release' variable
but AFAIK we only generate HTML version of release notes and I think
we can drop 'release'
and 'version' variables from conf.py.

[1] https://docs.openstack.org/openstackdocstheme/latest/

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

Re: [openstack-dev] [Release-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

[Akihiro Motoki]

2017-11-16 18:59 GMT+09:00 Andreas Jaeger :
> On 2017-11-15 19:07, Doug Hellmann wrote:
>> Excerpts from Akihiro Motoki's message of 2017-11-16 01:32:00 +0900:
>>> 2017-11-15 1:06 GMT+09:00 Andreas Jaeger :
 On 2017-11-14 17:03, Doug Hellmann wrote:
> Excerpts from Andreas Jaeger's message of 2017-11-14 09:31:48 +0100:
>> On 2017-11-13 22:09, Doug Hellmann wrote:
>>> Excerpts from zuul's message of 2017-11-13 20:37:18 +:
 Unable to freeze job graph: Unable to modify final job >>> publish-openstack-releasenotes branches: None source: 
 openstack-infra/project-config/zuul.d/jobs.yaml@master#26> attribute 
 required_projects={'openstack/horizon': >>> at 0x7ff848d06b70>} with variant >>> branches: None source: 
 openstack-infra/openstack-zuul-jobs/zuul.d/project-templates.yaml@master#285>

>>>
>>> It looks like there is a configuration issue with
>>> neutron-fwaas-dashboard.
>>
>> Yes, we marked  publish-openstack-releasenotes as final - and then the
>> job added requirements to it.
>>
>> I see at least these two different fixes:
>> - remove the final: true from the job
>> - add neutron and horizon to the job like we done for release job. But
>> there are other projects that have even more requirements.
>>
>> Infra team, what's the best approach here?
>>
>> Andreas
>
> No projects should even need to install *themselves* much less their
> other dependencies to build release notes. It should be possible to
> build release notes just with sphinx and reno (and their dependencies).

 It should - but that's not how those projects seem to be set up ;(
>>>
>>> The current setup is what most horizon plugins do. It is not special.
>>>
>>> The release notes of neutron-fwaas-dashboard can be built with sphinx,
>>> openstackdocstheme, reno and neutron-fwaas-dashboard itself.
>>> I am fine to change this appropriately, but what is the right thing to do?
>>> Do we need to change 'releasenotes' env to depend on only sphinx,
>>> openstackdocstheme and reno?
>>>
>>> Akihiro
>>
>> Someone needs to figure that out. Unfortunately, I don't have the
>> bandwidth right now. Maybe you, or someone else from one of the affected 
>> projects, can work on it?
>>
>> Two options have been discussed so far:
>>
>> 1. Create special jobs for neutron and horizon projects that install
>>neutron or horizon, like we do for the release jobs.
>>
>> 2. Redefine the release notes job so that it doesn't use tox
>>but installs only the pieces it needs to run a sphinx build. The
>>CTI is already defined in a way to support that [1].
>>
>> My current preference is for option 2. There may be other options
>> that we haven't explored, though.
>
> I gave it a try in https://review.openstack.org/520362. Note that this
> is only the building part, publishing part is separate - let's first
> iterate on this one,

I noticed most projects require to install themselves now to set
'version' and 'release' variables in releasenotes/source/conf.py.
For example, 
http://git.openstack.org/cgit/openstack/nova/tree/releasenotes/source/conf.py#n51
I think we cannot build release notes without installing a project itself.

>
> Andreas
>
>> Doug
>>
>> [1] 
>> https://governance.openstack.org/tc/reference/project-testing-interface.html#release-notes
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
>  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

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

Re: [openstack-dev] [Release-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

[Akihiro Motoki]

2017-11-15 1:06 GMT+09:00 Andreas Jaeger :
> On 2017-11-14 17:03, Doug Hellmann wrote:
>> Excerpts from Andreas Jaeger's message of 2017-11-14 09:31:48 +0100:
>>> On 2017-11-13 22:09, Doug Hellmann wrote:
 Excerpts from zuul's message of 2017-11-13 20:37:18 +:
> Unable to freeze job graph: Unable to modify final job  publish-openstack-releasenotes branches: None source: 
> openstack-infra/project-config/zuul.d/jobs.yaml@master#26> attribute 
> required_projects={'openstack/horizon':  0x7ff848d06b70>} with variant  branches: None source: 
> openstack-infra/openstack-zuul-jobs/zuul.d/project-templates.yaml@master#285>
>

 It looks like there is a configuration issue with
 neutron-fwaas-dashboard.
>>>
>>> Yes, we marked  publish-openstack-releasenotes as final - and then the
>>> job added requirements to it.
>>>
>>> I see at least these two different fixes:
>>> - remove the final: true from the job
>>> - add neutron and horizon to the job like we done for release job. But
>>> there are other projects that have even more requirements.
>>>
>>> Infra team, what's the best approach here?
>>>
>>> Andreas
>>
>> No projects should even need to install *themselves* much less their
>> other dependencies to build release notes. It should be possible to
>> build release notes just with sphinx and reno (and their dependencies).
>
> It should - but that's not how those projects seem to be set up ;(

The current setup is what most horizon plugins do. It is not special.

The release notes of neutron-fwaas-dashboard can be built with sphinx,
openstackdocstheme, reno and neutron-fwaas-dashboard itself.
I am fine to change this appropriately, but what is the right thing to do?
Do we need to change 'releasenotes' env to depend on only sphinx,
openstackdocstheme and reno?

Akihiro

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

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

Re: [openstack-dev] [heat][horizon] Migration to heat-dashboard: how can we move this forward?

[Akihiro Motoki]

Hi Kaz,

Thanks for sharing the current status of heat-dashboard.
Queens-2 sounds a reasonable milestone.

I summarize the near-future below. Right?

- heat-dashboard team is preparing for heat dashboard split-out.
  The horizon parity (including stability) is the current focus.
- Heat related bugs filed to horizon can be hold until the
heat-dashboard is ready (around Q-2)
  After it is ready, they will be forwarded to heat-dashboard from
horizon launchpad
  and we can fix them in the heat-dashboard repository.
- Horizon team tries not to approve heat-related patches without strong reasons.

> Of course we will keep looking at what's going on in Horizon side &
> will cherry-pick the leftovers if needed in the end.

AFAIK, the only patch which landed after the heat-dashboard repo was created is
https://review.openstack.org/#/c/498838/

Thanks,
Akihiro

2017-10-25 13:11 GMT+09:00 Kaz Shinohara :
>  Hi Akihiro,
>
>
> Thanks for your kind following up :)
>
>> (1) Patch reviews and approvals in horizon
> Could you please stop to accept heat-dashboard related patches without
> critical ones ?
> According to our discussion in the last PTG, we made heat-dashboard
> repo taking horizon repo as upstream & now trying to land it in
> queens-2.
> Of course we will keep looking at what's going on in Horizon side &
> will cherry-pick the leftovers if needed in the end.
>
>> (2) Bug Management
> Yes we can take over those bugs, but now we are focusing to stabilize
> heat-dashboard-self.
> We would like to fix them after we will safely land heat-dashboard in 
> queens-2.
>
> Regards,
> Kaz Shinohara
>
> 2017-10-25 11:47 GMT+09:00 Akihiro Motoki :
>> Hi Heat dashboard team,
>>
>> I noticed heat-dashboard repository was created.
>> I have several questions from horizon side.
>>
>> A big question is "When does the switch happen?"
>>
>> This mainly affects two things:
>>
>> (1) Patch reviews and approvals in horizon
>>
>> Should the horizon team stop to accept heat-dashboard related patches
>> into the horizon repo now?
>> If you want to migrate in parallel, you need to take care of what
>> happens in the horizon repo continuously.
>> The simplest way is to stop any activities in horizon side.
>>
>> Note that one patch landed yesterday into the horizon repo.
>> Perhaps the heat-dashboard team will cherry-pick it into your repository.
>>
>> (2) Bug Management
>>
>> Is it okay to forward heat-related bugs into heat-dashboard launchpad?
>> When do we start?
>> There are several number of existing bugs related to the heat dashboard.
>> The horizon team now just adds 'heat' tag and is waiting for heat-dashboard.
>> https://bugs.launchpad.net/horizon/+bugs?field.tag=heat
>>
>> Thanks,
>> Akihiro
>>
>> __
>> OpenStack Development Mailing 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] [heat][horizon] Migration to heat-dashboard: how can we move this forward?

[Akihiro Motoki]

Hi Heat dashboard team,

I noticed heat-dashboard repository was created.
I have several questions from horizon side.

A big question is "When does the switch happen?"

This mainly affects two things:

(1) Patch reviews and approvals in horizon

Should the horizon team stop to accept heat-dashboard related patches
into the horizon repo now?
If you want to migrate in parallel, you need to take care of what
happens in the horizon repo continuously.
The simplest way is to stop any activities in horizon side.

Note that one patch landed yesterday into the horizon repo.
Perhaps the heat-dashboard team will cherry-pick it into your repository.

(2) Bug Management

Is it okay to forward heat-related bugs into heat-dashboard launchpad?
When do we start?
There are several number of existing bugs related to the heat dashboard.
The horizon team now just adds 'heat' tag and is waiting for heat-dashboard.
https://bugs.launchpad.net/horizon/+bugs?field.tag=heat

Thanks,
Akihiro

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

Re: [openstack-dev] Regarding Horizon panel of Gnoochi/Adoh Services

[Akihiro Motoki]

2017-10-12 18:09 GMT+09:00 Sudheer Kalla :
> Hello All,
>
> I have some queries regarding horizon support for gnoochi/adoh services, As
> you may all already aware that Resource Usage panel which displays
> ceilometer service is no longer available from ocata cycle. So i would like
> to know if there is any plan/blue print to create a new panel/plugin in
> order to display gnoochi/adoh in horizon.
>
> Although i came across this blue print
> https://blueprints.launchpad.net/horizon/+spec/horizon-gnocchi-graphs which
> basically targets of creation of new panels, But it got completed without
> proper information

The definition of the blueprint is "Obsolete" and you can see the
reason in the whiteboard.
"This content should be developed in a Horizon plugin rather
integrated into Horizon".
This describes all the reason.

Horizon supports plugin mechanism and the horizon team encourage
individual project teams
to develop their GUI support under the governance of their project teams.
There are many examples of horizon plugins [1]

So, the future of "Horizon panel of Gnoochi/Adoh Services" completely
relies on the telemetry team.
Gnocchi is now a separate project from OpenStack, but the situation is
totally same.

Akihiro

[1] https://docs.openstack.org/horizon/latest/install/plugin-registry.html

>
> Can any one please point me in the right direction where i can check the
> necessary details of horizon support for Gnoochi/Aodh services as i was very
> much interested
>
> Thanks in Advance.
>
> Regards
> Sudheer Kumar Kalla
>
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Neutron] Denver Team Dinner

[Akihiro Motoki]

+1 thanks for organizing this

2017-09-12 17:23 GMT-06:00 Miguel Lavalle :
> Dear Neutrinos,
>
> Our social event will take place on Thursday September 12th at 7:30pm. The
> venue is going to be https://www.famousdaves.com/Denver-Stapleton. It is
> located 0.4 miles from the Renaissance Hotel, which translates to an easy 9
> minutes walk.
>
> I have a reservation for a group of 30 people under my name. Please respond
> to this message with your attendance confirmation by Wednesday night, so I
> can get a more accurate head count.
>
> Looking forward to see y'all Thursday night
>
> Best regards
>
> Miguel
>
> __
> OpenStack Development Mailing 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] [doc] help for new URL after doc-migration

[Akihiro Motoki]

Hi docs team,

I am checking URLs in the horizon documentation after doc-migration and
am struggling to find new URLs corresponding to the below.
If we fail to find corresponding URLs, it seems to mean we need to
drop the URLs.

- https://docs.openstack.org/admin-guide/cli-admin-manage-stacks.html
  (linked from horizon admin/admin-manage-stacks.rst)

  I checked https://etherpad.openstack.org/p/doc-migration-tracking
  but there is no corresponding review and there seems no
corresponding heat doc.
  Has the document gone?

- https://docs.openstack.org/admin-guide/cli-set-quotas.html
  (linked from horizon admin/set-quotas.rst)

  According to the etherpad, this will be split into three project
(nova, cinder, neutron)
  but I failed to find corresponding documents in these projects.
  What is the current status of the migration?
  (the document has been dropped from openstack-manuals and I failed
to track the current status.)

- https://docs.openstack.org/admin-guide/compute-admin-password-injection.html
  (linked from horizon user/launch-instances.rst)

  I checked https://etherpad.openstack.org/p/doc-migration-tracking
  but I cannot find any information on
compute-admin-password-injection on the etherpad.
  Was this just dropped without migration?


BTW, As my hat of individual project members, in general, it is really tough to
find corresponding new URLs. Is there any good way to find new ones?
What is the suggested way if we fail to find new corresponding links?
Just drop them?

Thanks,
Akihiro

__
OpenStack Development Mailing List (not for 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-fwaas]Why fwaas v1 plugin automatically inserts a rule to the head of a policy if people haven't set its position manually?

[Akihiro Motoki]

See the Networking API definition
https://developer.openstack.org/api-ref/networking/v2/index.html?expanded=insert-rule-into-a-firewall-policy-detail#insert-rule-into-a-firewall-policy
It says "If both insert_before and insert_after are not set, the new
firewall_rule_id is inserted at the top of the policy."
I think this is the intended behavior.

2017-08-22 18:50 GMT+09:00 田明明 :
> Has this referenced any firewall production or it is a bug because it will 
> cause original rules re-ordered every time?
>
> 发自我的 iPhone
>
>
> __
> OpenStack Development Mailing 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] Secrets of edit-constraints

[Akihiro Motoki]

Thanks Tony for the confirmation.

We have various variants of tox_install.sh. I just wondered we need to
fix it globally
or it depends on someone's development environment.

Anyway we can improve tox_install.sh for more general way :)

Thanks,
Akihiro

2017-08-16 18:14 GMT+09:00 Tony Breeds :
> On Mon, Aug 14, 2017 at 08:36:33AM +, Csatari, Gergely (Nokia - 
> HU/Budapest) wrote:
>> Hi,
>>
>> I have an interesting situation with the parametrization of edit-constraints 
>> in tools/tox_install.sh. This happens at the moment in neutron-lib, but as 
>> amotoki pointed out in [1] the same should happen in any projects (and 
>> actually was happening with me in Vitrage and Mistral).
>>
>> Here is what I experience:
>> With the current parameters of edit-constraints (edit-constraints $localfile 
>> -- $LIB_NAME "-e file://$PWD#egg=$LIB_NAME") the library itself (neutron-lib 
>> in this case) is added to upper-constraints.txt and the installation fails 
>> with "Could not satisfy constraints for 'neutron-lib': installation from 
>> path or url cannot be constrained to a version".
>> If I modify the parameters of edit-constraints in a way that it removes the 
>> library (neutron-lib in this case) instead of adding (edit-constraints 
>> $localfile $LIB_NAME --) it my build succeeds (as I'm playing with api-ref I 
>> use tox -r -e api-ref, but the same also happens with tox -r -e pep8).
>>
>> Is this happening with only me?
>
> No using edit-constraints to remove an item from the constrained set so
> you can use the current developement (git SHA) is the right things to
> do.
>
> Many of the project in the scenario you're describing do just that.
>
> 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
>

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

Re: [openstack-dev] [python-openstackclient][python-openstacksdk][neutron] supporting resource extensions with our CLI

[Akihiro Motoki]

I think this discussion has several aspects from general direction to
implementation details.

TL;DR
My suggestion as a main maintainer of python-neutronclient is to
upstream all out-of-tree APIs, support all features in OSC and push
away 'neutron' CLI.

The long version;

In my basic understanding, OpenStack in general has chosen the way
that we don't accept vendor extensions in API from the POV of inter
operability. neutron still supports to load out-of-tree API
definitions but I think neutron is just behind it. Nova drops
out-of-tree extension support in the API in Pike as Matt mentioned,
and if we move the (micro-)versioning forward out-of-tree API
definition will have more difficulties. IMHO I would like to see all
APIs are upstreamed as others commented. I believe this point is most
important and we all needs to be in a same page. Hopefully all
out-of-tree APIs will be upstreamed.

My understanding is the current OSC and openstacksdk (in addition to
shade) adopts this position.

On the other hand, we also need to take care of existing users on the
'neutron' CLI side.
I think there are several options on python-neutronclient.
(a) keep the current deprecation and recommend out-of-tree API to be upstreamed
(b) no deprecation warning from neutron CLI but keep the deprecation
policy on 'neutron' CLI (which means no new feature and positive
maintenance is provided)
(c) changing the current deprecation policy and continue to add new
features to 'neutron' CLI

I think (a) or (b) is realistic.
(c) needs more developers and reviewers. (I personally supports OSC,
openstacksdk and shade.)

The deprecation means no features will be coming for 'neutron' CLI and
all new features are suggested to go to OSC. I believe this is the
future we agreed. We can keep 'neutron' CLI only for existing
features, even though no neutron (and stadium projects) need to
implement new features in 'neutron' CLI. neutron CLI will be gone even
if there is no deprecation notice. At some point, we can split out
*CLI* part of neutronclient to a hosted project if someone wants to
keep 'neutron' CLI.

There is another background which makes neutron CLI difficult to keep
backward compatibility. The neutron option parsing is ugly enough and
it is hard to be maintained. It breaks backward compatibility so
easily and prevents from changing option formats or introducing new
options which are considered better. Thus, as a main maintainer of
python-neutronclient, I would like to push away this feature
completely, but perhaps this is the feature which out-of-tree API
would like to leverage. Does anyone want to support the extra argument
mechanism in neutron CLI ([1] and [2] for more detail)?

[1] 
https://docs.openstack.org/python-neutronclient/latest/cli/neutron.html#extra-arguments-for-create-update-operation
[2] 
https://docs.openstack.org/python-neutronclient/latest/contributor/cli_option_guideline.html

Thanks,
Akihiro

2017-08-09 2:46 GMT+09:00 Boden Russell :
>
> On 8/8/17 10:29 AM, Akihiro Motoki wrote:
>> My reply applies to 'resource' extension but does not apply to
>> 'attribute extension'
>
> My apologies for using confusing terminology; as you pointed out we
> don't currently have a good solution for attribute extensions with OSC
> and I've tried to outline the technicals in the RFE style bug [1] where
> I hope we can continue this discussion.
>
> python-neutronclient does support these attribute extensions, but as of
> today neutronclient gives deprecation warnings when used; so users are
> "concerned" when they see this and we don't have a complete story for
> OSC. Perhaps we can suppress those deprecations until we figure out a
> path forward?
>
> Thanks
>
>
> [1] https://bugs.launchpad.net/neutron/+bug/1705755
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Akihiro Motoki]

Tony,

Thanks for taking care.

> The following repos don't seem to use the openstack/releases repo so I
> have less information there.

Most of them are projects not under the governance (so-called "hosted"
or "unofficial" projects),
so I am not sure there is a good way to handle them.

I can comment some of them which I am involved in deeply.

> i18n   I18n

At now, i18n repo is a part of governance but this is a project which
has no need to cut a release,
so it always follows the master branch of the requirements repo.
It is not a blocker for opening the master branch in the requirements repo.

> neutron-vpnaas
> neutron-vpnaas-dashboard

These projects are neutron related and horizon plugin.
We will do same things for other neutron stadium and horizon plugin projects.

IMHO we don't need to take care of them much.

> python-openstacksdk

python-openstackclient depends on this, so we need to cut stable/branch
from the latest release. The status of the project is being discussed
in the ML thread,
but I believe we need to cut a stable branch. On the other hand, I
think it does not
block the opening of the master of the requirements repo as the latest
release of
python-openstacksdk is enough for Pike release of OSC.

> It'd be great to get some of these repos represented in
> openstack/releases.  Having a confirmed release-model would go a long
> way to clearing up the list. An alternate approach would be to remove
> redundant items from projects.txt

I am not sure that projects not under the TC governance can use
openstack/releases repo.
Is the openstack/release repo for projects under the governance?

Thanks,
Akihiro

2017-08-10 14:46 GMT+09:00 Tony Breeds :
>
> Hi All,
> In an effort to qualify which projects are likley to be affected if
> when we open the requirements repo I generated a list of all repos that:
>
> 1. Subscribe to requirements management
> 2. Do not already have a stable/pike branch
> 3. Do not follow the cycle-with-milestones, cycle-trailing or
>independent release models
> 4. Are not a 'branchless' project (tempest or tempest-plugin)
>
> These repos I believe *should* have a stable/pike branch or will see
> problems when we open openstack/requirements.  Those issues were
> described in [1]
>
> It turns out close to 1/3rd of projects that subscribe to requirements
> management are not ready for us to re-open for master.  So we need you
> help to get that number down to a much more acceptable number.
>
> The good news is it's pretty easy to fix this with the cool tools and
> workflow in the releases repo[2].  I suspect that the 'service' will
> take care of themselves, and the horizon-plugins are waiting to horizon
> to cut RC1.
>
> Repos with type: horizon-plugin
> ironic-ui  ironic
> manila-ui  manila
> monasca-ui monasca
> neutron-fwaas-dashboardneutron
> solum-dashboardsolum
> tacker-horizon tacker
> watcher-dashboard  watcher
> zun-ui zun
>
> Repos with type: other
> python-openstackclient OpenStackClient
> patroleQuality Assurance
> heat-agentsheat
> ironic-inspector   ironic
> ironic-python-agentironic
> kuryr-kubernetes   kuryr
> monasca-common monasca
> monasca-notification   monasca
> monasca-persister  monasca
> monasca-transform  monasca
>
> Repos with type: service
> ironic ironic
> monasca-apimonasca
> monasca-log-apimonasca
> swift  swift
> tricircle  tricircle
> vitragevitrage
> watcherwatcher
> zunzun
>
> Those are the easy items.
>
> The following repos don't seem to use the openstack/releases repo so I
> have less information there.
>
> i18n   I18n
> almanach
> blazar
> blazar-nova
> compute-hyperv
> ekko
> gce-api
> glare
> ironic-staging-drivers
> kosmos
> masakari
> masakari-monitors
> mixmatch
> mogan
> nemesis
> networking-dpm
> networking-fujitsu
> networking-generic-switch
> networking-l2gw
> networking-powervm
> neutron-vpnaas
> neutron-vpnaas-dashboard
> nova-dpm
> nova-lxd
> nova-powervm
> os-xenapi
> python-bl

Re: [openstack-dev] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

[Akihiro Motoki]

2017-08-08 23:12 GMT+09:00 Akihiro Motoki :
> 2017-08-08 22:41 GMT+09:00 Boden Russell :
>> On 8/7/17 10:39 PM, Clint Byrum wrote:
>>> If the thing you're doing doesn't fit in the mainline API, then what
>>> you're doing is making a new API. Extensions just bypass the important
>>> part where that API gets designed and thought through.
>>
>> Irrespective of opinions as to if API extensions are good or not, the
>> fact of the matter is we support them in neutron today and as a result
>> we have users that rely on them as well as the ability to interface
>> (CLI) with such extensions via python-neutronclient. That said, I think
>> this concern has been heard [1] and we will work to address it
>> short-to-mid term.
>
> I totally agree with other comments that all API features should be 
> upstreamed.
>
> Replying to Boden's question on the short-term solution.
> If you need CLI support, you can implement OSC plugin to support your
> API extensions
> rather than extending OSC or OSC plugin provided by python-neutronclient.
> If you need SDK support, you can provide your own python bindings
> (perhaps it will be most stable)
> or continue to use the python-neutronclient CLI extension mechanism
> (which extends methods
> based on "neutronclient.extension" entry points.
>
> Does it answer to you, Boden?

My above reply does not answer the original question.
The subject of the thread says "resource extension" but this is
actually on attribute extension.
My reply applies to 'resource' extension but does not apply to
'attribute extension'

>
> Akihiro
>
>> As to neutron's longer-term goals W/R/T API extensions; I can't speak to
>> that.
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-August/120759.html
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

[Akihiro Motoki]

2017-08-08 22:41 GMT+09:00 Boden Russell :
> On 8/7/17 10:39 PM, Clint Byrum wrote:
>> If the thing you're doing doesn't fit in the mainline API, then what
>> you're doing is making a new API. Extensions just bypass the important
>> part where that API gets designed and thought through.
>
> Irrespective of opinions as to if API extensions are good or not, the
> fact of the matter is we support them in neutron today and as a result
> we have users that rely on them as well as the ability to interface
> (CLI) with such extensions via python-neutronclient. That said, I think
> this concern has been heard [1] and we will work to address it
> short-to-mid term.

I totally agree with other comments that all API features should be upstreamed.

Replying to Boden's question on the short-term solution.
If you need CLI support, you can implement OSC plugin to support your
API extensions
rather than extending OSC or OSC plugin provided by python-neutronclient.
If you need SDK support, you can provide your own python bindings
(perhaps it will be most stable)
or continue to use the python-neutronclient CLI extension mechanism
(which extends methods
based on "neutronclient.extension" entry points.

Does it answer to you, Boden?

Akihiro

> As to neutron's longer-term goals W/R/T API extensions; I can't speak to
> that.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2017-August/120759.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron][vpnaas] pike rc

[Akihiro Motoki]

I proposed a project-config patch to allow us to release neutron-vpnaas.
https://review.openstack.org/#/c/491670/
There is a missing configuration when neutron-vpnaas was pushed out
from the neutron stadium.
Once the patch is merged and -release group are setup, we can release
neutron-vpnaas by ourselves.

Akihiro

2017-08-08 10:46 GMT+09:00 Takashi Yamamoto :
> hi,
>
> can anyone with an appropriate permission create a stable/pike
> and pike rc1 for neutron-vpnaas?
>
> stable/pike
> 11.0.0.0rc1
> openstack/neutron-vpnaas
> 8278615c1f35f98447a3f9692a78ab45e90ee8c6
>
> thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [requirements][ptls] HELP! Thawing the requirements repo

[Akihiro Motoki]

2017-08-07 11:59 GMT+09:00 Tony Breeds :
> Hi All,
> So as you all know we've frozen the requirements repo and it will
> stay frozen until after all the cycle-with-milestones projects have
> stable/pike branches.  That's pretty normal.
>
> The last couple of cycles we've seen issues with projects that crate
> stable/pike branches *after* we've thawed/re-opened requirements repo
> for $next_release.
>
> What happens is those projects are still stabilising for pike but
> getting requirements updates for queens.  When they *do* branch for pike
> they quickly get a proposal-bot change which seems to take things
> backwards.  This bad for (at least) a couple of reasons.
>
> 1. Those projects are testing against the wrong requirements
> 2. You end up with a patch release for $project that radically changes
> the requirements for $project.

Yeah, totally agree the above.

>
> So I need some help identifying which projects are going to fall into
> this scenario.  The easy to identify ones are cycle-trailing and we can
> easily cope with that by as there are only 4 of them.  My instinct tells
> me that many of the neutron (stadium?) and horizon-plugin projects will
> fall into this boat.

I think neutron stadium and horizon plugin projects with
cycle-with-intermediary are potentially affected.
They tends to ship a final release (and cut a stable branch if necessary).

I think we can easily list such projects for official projects.
It is not easy to do it for hosted projects as we don't know their
release models.
Do we want to take care of hosted projects?


The following is about official projects.

According to the release repo, there is no *official* neutron stadium
projects with cycle-with-intermediary release model.
networking-hyperv (of the winstackers project) adopts
cycle-with-intermediary model and it looks affected.

Grepping the release deliverables, *official* horizon plugin projects
with cycle-with-intermediary models are:

$ grep release-model `grep -l horizon-plugin deliverables/pike/*.yaml`
| grep -v cycle-with-milestones | cut -d : -f 1
deliverables/pike/cloudkitty-dashboard.yaml
deliverables/pike/ironic-ui.yaml
deliverables/pike/karbor-dashboard.yaml
deliverables/pike/magnum-ui.yaml
deliverables/pike/manila-ui.yaml
deliverables/pike/monasca-ui.yaml
deliverables/pike/senlin-dashboard.yaml
deliverables/pike/solum-dashboard.yaml
deliverables/pike/tacker-horizon.yaml
deliverables/pike/vitrage-dashboard.yaml
deliverables/pike/watcher-dashboard.yaml
deliverables/pike/zun-ui.yaml


In addition, regarding neutron stadium projects and horizon plugin projects,
they also need to update the branch (from master to stable/pike) of
neutron or horizon repo
as they installs neutron or horizon using tox_install.sh
(in addition to the branch of requirements repo).
This needs to happen just after stable/pike branch of neutron or
horizon is created.

Thanks,
Akihiro

> Once we know the scope of the affected projects we can work out how to
> thaw the requirements repo with minimum impact.  The alternative is to
> have the requirements repo frozen for > 1 month which no one wants.
>
> 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
>

__
OpenStack Development Mailing List (not for 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

[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] string freeze exception for VMAX driver

[Akihiro Motoki]

I am not sure who is responsible to respond to string freeze
exception, but I will comment it as my hat of the i18n team.

Looking at "cinder" translation status [1], the best progress is ~73%
and 718 of 2932 message are remaining. In other languages the progress
is lower. Adding two new messages does not matter. Removing messages
has no problem. I see no blocking issue in this request.

In addition, I think the i18n team focuses on dashboard translations
and server projects are less focused for translations. IIRC the I18n
team discussed an idea to announce the i18n team focus on translation
to let server projects be free from string freeze around the beginning
of the Pike cycle but I am not sure it is announced or not.

Thanks,
Akihiro

[1] 
https://translate.openstack.org/iteration/view/cinder/master/documents?docId=cinder%2Flocale%2Fcinder&dswid=5769

2017-08-03 3:14 GMT+09:00 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
>

__
OpenStack Development Mailing List (not for 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

[Akihiro Motoki]

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

Akihiro

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

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

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

[Akihiro Motoki]

Thanks for summarizing the concerns. It is really helpful for all projects!

2017-08-02 23:55 GMT+09:00 Matt Riedemann :
> Now that Stephen Finucane is back from enjoying his youth and gallivanting
> all over Europe, and we talked about a few things in IRC this morning on the
> docs migration for Nova, I wanted to dump my concerns here for broader
> consumption.
>
> 1. We know we have to fix a bunch of broken links by adding in redirects [1]
> which sdague started here [2]. However, that apparently didn't catch
> everything, e.g. [3], so I'm concerned we're missing other broken links. Is
> there a way to find out?
>
> 2. The bottom change in the docs migration series for Nova is a massive
> refactor of the layout of the Nova devref [4]. That's something I don't want
> to do in Pike for two reasons:
>
> a) It's a huge change and we simply don't have the time to invest in
> properly assessing and reviewing it before Pike RC1.
>
> 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.

Totally agree for PTG topics. we need some guideline on what the top pages of
individual projects should be and what are expected for top pages of
sub directories.
When the doc-migration started, I chatted on this a bit with asettle.
The top page of each subdirectory (like admin, install and so on) are
expected to link
from a landing page on docs.openstack.org. On the other hand, we also need to
take care of the top page of individual projects. In neutron case, we
basically try to
accommodate all documents in the standard directory structure and keep
the top page as much as simple.
It is really nice to have a consistent guideline on this.

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

Perhaps what we need are pages which explains how to use and configure
a specific feature using on CLI and/or some. It might be beyond the
scope of cli-nova-*.
I think the end-user and admin guides can be refactored per topic.

> 4. Similar to #3, but we don't have a patch yet for importing the user guide
> and there are several docs in the user guide that are Nova specific so I'd
> like to make sure we include those, like [11][12].
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2017-August/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/
> [8] https://review.openstack.org/#/c/477497/
> [9]
> https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/admin-guide/source/cli-nova-specify-host.rst
> [10]
> https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/admin-guide/source/compute-flavors.rst
> [11]
> https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-guide/source/cli-launch-instances.rst
> [12]
> https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-guide/source/cli-delete-an-instance.rst
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for 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][neutron] doc-migration status

[Akihiro Motoki]

2017-07-24 23:44 GMT+09:00 Doug Hellmann :
> Excerpts from Kevin Benton's message of 2017-07-23 14:19:51 -0700:
>> Yeah, the networking guide does include configuration for some of the
>> sub-projects (e.g. BGP is at [1]). For the remaining ones there is work
>> that needs to be done because their docs live in wiki pages.
>>
>> 1.
>> https://docs.openstack.org/ocata/networking-guide/config-bgp-dynamic-routing.html
>
> OK, that's good to know. It would be good to be consistent with the
> approach to the stadium projects, so we can either eliminate the list of
> projects from landing pages that show things like "all of the admin
> guides" or we can add the projects so users can find the docs. If
> they're all covered in the networking guide, we could include that
> information on the admin landing page, for example.

Thanks for the advise.

Yeah, we need some consistency across the stadium projects.
The installation and/or config guide can be covered by the networking
guide (admin guide).
Regarding the configuration reference, I think it is better to have
them in individual projects
as they are generated automatically from the code.

The stadium projects are roughly categorized into two:
service project (like FWaaS, BGP, SFC...) and back-end project
(networking-ovn/odl/midonet...).
Around the service projects, the networking guide looks the best place
to cover various things.
A single place will help readers.
Regarding back-end projects, individual projects have their own
contents in their repository
and I am not sure which is better.
Anyway we can discuss and get consensus in the neutron team.

> In the mean time, if someone from the neutron project will review
> the list of "Missing URLs" on https://doughellmann.com/doc-migration/
> and let me know which ones represent content included in other
> documents, I can update the burndown chart generator to reflect
> that.

I am usually checking the doc-migration burndown chart including missing URLs
on the neutron stadium projects.
The progress is generally good and the remaining things are as follows:
- Configuration reference for all listed projects are under review
  (all have been proposed and I am taking care of them).
- The installation guide of networking-odl is also under review and I
believe will land soon.
All progresses are tracked on the doc-migration etherpad (neutron section).

Akihiro

>
> Doug
>
>>
>>
>> On Sun, Jul 23, 2017 at 1:32 PM, Doug Hellmann 
>> wrote:
>>
>> > Excerpts from Kevin Benton's message of 2017-07-23 01:31:25 -0700:
>> > > Yeah, I was just thinking it makes it more explicit that we haven't just
>> > > skipped doing an admin guide for a particular project.
>> >
>> > Sure, you can do that. I don't think we want to link to all of those
>> > pages from the list of admin guides, though.
>> >
>> > I've updated the burndown chart generator to ignore the missing
>> > admin guide URLs for networking subprojects.
>> >
>> > I don't see configuration or installation guides for quite a few
>> > of those, either. Are those also handled within the neutron main
>> > tree docs?
>> >
>> > Doug
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for 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][neutron] doc-migration status

[Akihiro Motoki]

Hi,

I have a question on admin/ document related to the networking guide
and would like to have advices from the documentation experts.

It seems the check site by Doug expect all project have admin/ page.
In the case of neutron the situation is a bit special. We have the
networking guide as admin/ document
in the neutron repo and it covers not only neutron itself but also
neutron stadium projects.
It means the neutron stadium projects sometimes (often?) have no
admin/ directory in their own repos
in favor of adding contents to the networking guide in neutron.

Should Individual neutron stadium projects have their own admin guide
in their repositories,
or is it better to keep the networking guide which covers all
networking stuff in a single guide?

What is the suggested way on the networking guide as the document expert?

Thanks,
Akihiro

2017-07-22 3:26 GMT+09:00 Doug Hellmann :
> We've made huge progress, and are launching the updated landing
> pages for docs.openstack.org as I write this. Thanks to all of the
> contributors who have stepped up to write nearly 1,000 patches to
> improve the health of our documentation!
>
> We still have around 70 URLs we expected to see after the migration
> was complete but that produce a 404. I know some of the patches to
> produce those pages are in progress, but please check the list at
> https://doughellmann.com/doc-migration/ if your team is listed below
> to ensure that nothing has been missed.
>
>   cinder
>   cloudkitty
>   congress
>   designate
>   heat
>   ironic
>   karbor
>   keystone
>   magnum
>   manila
>   murano
>   neutron
>   nova
>   sahara
>   senlin
>   swift
>   tacker
>   telementry
>   tricircle
>   trove
>   vitrage
>   watcher
>   zaqar
>   zun
>
> Reply here or ping me in #openstack-docs if you have questions or need a
> hand.
>
> Doug
>
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs

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

Re: [openstack-dev] Idea of adding the language index to individual release notes

[Akihiro Motoki]

# moving from personal emails to openstack-dev ML

Thanks Doug for the advise.

openstackdocstheme looks a better place to support the language index
for individual release note pages.
I will look into how we can support it in openstackdocstheme.

At now, the releasenote is built as a separate sphinx project, so the
openstackdocstheme support would be straight-forward just by checking
the availability of PO files for individual languages.
Once we move the doc build to more unified way, we might need more
fine-grained way to control the language index.
We can start some simple approach and then enhance it gradually.

2017-07-11 23:35 GMT+09:00 Doug Hellmann :
>
> On Jul 11, 2017, at 9:18 AM, Andreas Jaeger  wrote:
>
> On 2017-07-11 14:43, Akihiro Motoki wrote:
>
> Hi Doug, Ian, Andreas,
>
> I proposed a patch to add the language index to all release notes files.
> https://review.openstack.org/#/c/481850/
>
> Your feedback would be appreciated.
> Thanks Andreas for the initial feedback too.
>
> Release notes files are usually not accessed through index.html
> and release notes of individual releases are accessed directly as they
> are linked from releases.openstack.org.
> I think it is useful to have the language list for all release notes files
> so that readers can easily find translated versions.
>
> The similar approach is being proposed to the i18n guide.
> https://review.openstack.org/#/c/479472/
> Sample output is like this:
> http://docs-draft.openstack.org/72/479472/6/check/gate-i18n-tox-doc-publish-docs/91e920e//publish-docs/i18n/latest/
>
>
> Doug,
>
> here's one thing to look into when moving release-notes into main build
> - how to translate them. Do we translate the release notes separately
> (we can do that since each file is a separate translatable target) or
> only the full guide ?
>
> 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
>
>
> I replied on the review, but in case you didn’t see that message:
>
> I like the idea of doing this, but I'm not sure this is the right
> implementation, for 2 reasons:
>
> 1. We are going to have to solve a similar problem for content in the
> doc/source directories for projects (installation guides, especially).
> 2. The special releasenotes build job will go away when we merge it into
> doc/source and use the single unified job.
>
> Do you think it would be possible to do something in the openstackdocstheme
> to add the necessary links?
>
> Perhaps we can continue this discussion on openstack-dev?
>
> Doug
>

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

Re: [openstack-dev] [keystone] office hours report 2017-7-7

[Akihiro Motoki]

2017-07-12 10:35 GMT+09:00 Lance Bragstad :
> Hey all,
>
> This is a summary of what was worked on today during office hours. Full logs
> of the meeting can be found below:
>
> http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-07-11-19.00.log.html

It is not specific to keystone.

I think it is better to use keystone-office-hours instead of
office-hours as a meeting name.
If we use the same meeting names, we will have office-hours logs of
multiple projects
in a same directory in eavesdrop.openstack.org.

Thanks,
Akihiro

>
> The future of the templated catalog backend
>
> Some issues were uncovered, or just resurfaced, with the templated catalog
> backend. The net of the discussion boiled down to - do we fix it or remove
> it? The answer actually ended up being both. It was determined that instead
> of trying to maintain and fix the existing templated backend, we should
> deprecate it for removal [0]. Since it does provide some value, it was
> suggested that we can start implementing a new backend based on YAML to fill
> the purpose instead. The advantage here is that the approach is directed
> towards a specific format (YAML). This should hopefully make things easier
> for both developers and users.
>
> [0] https://review.openstack.org/#/c/482714/
>
> Policy fixes
>
> All the policy-in-code work has exposed several issues with policy defaults
> in keystone. We spent time as a group going through several of the bugs [0]
> [1] [2] [3], the corresponding fixes, and impact. One of which will be
> backported specifically for the importance of communicating a release note
> to stable users [0].
>
> [0] https://bugs.launchpad.net/keystone/+bug/1703369
> [1] https://bugs.launchpad.net/keystone/+bug/1703392
> [2] https://bugs.launchpad.net/keystone/+bug/1703467
> [3] https://bugs.launchpad.net/keystone/+bug/1133435
>
> Additional bugs worked
>
> Transient bug with security compliance or PCI-DSS:
> https://bugs.launchpad.net/keystone/+bug/1702211
> Request header issues: https://bugs.launchpad.net/keystone/+bug/1689468
>
>
> I hope to find ways to automate most of what is communicated in this
> summary. Until then I'm happy to hear feedback if you find the report
> lacking in a specific area.
>
>
> Thanks,
>
> Lance
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [heat][ironic][telemetry][dragonflow][freezer][kuryr][manila][mistral][monasca][neutron][ansible][congress][rally][senlin][storlets][zun][docs] repos without signs of migration sta

[Akihiro Motoki]

Thanks for update the status!

> openstack/networking-midonet

The doc-migration work networking-midonet has almost completed.
Unfortunately they do not use 'doc-migration' topic as it seems they
already started
the document overhaul before the doc-migration starts.
https://review.openstack.org/#/q/topic:bug/1692788
Hopefully midonet folks use 'doc-migration' tag for at least one patch.

> openstack/networking-vsphere

This is not a project under the TC governance.

Akihiro

2017-07-11 2:26 GMT+09:00 Doug Hellmann :
> According to the dashboard, it looks like we still have almost 100
> repositories with documentation that have no patches with the
> doc-migration topic, indicating that they have not started moving
> content or updating the theme. I have tried to tag those teams in the
> subject, but I may have missed some. Please check the list below for a
> repo owned by your team.
>
> If you have completed the work and the dasbhoard script didn't pick
> it up, please let me know so I can fix up the data.
>
> Doug
>
> openstack-dev/heat-cfnclient
> openstack/bifrost
> openstack/ceilometer-powervm
> openstack/ceilometermiddleware
> openstack/diskimage-builder
> openstack/dragonflow
> openstack/freezer-api
> openstack/freezer-dr
> openstack/freezer-web-ui
> openstack/fuxi
> openstack/fuxi-kubernetes
> openstack/heat
> openstack/heat-cfntools
> openstack/heat-translator
> openstack/instack
> openstack/ironic-lib
> openstack/karbor-dashboard
> openstack/kolla-kubernetes
> openstack/manila
> openstack/manila-image-elements
> openstack/manila-ui
> openstack/mistral-dashboard
> openstack/mistral-extra
> openstack/mistral-lib
> openstack/molteniron
> openstack/monasca-statsd
> openstack/monasca-transform
> openstack/networking-hyperv
> openstack/networking-midonet
> openstack/networking-vsphere
> openstack/neutron-lbaas
> openstack/neutron-lbaas-dashboard
> openstack/octavia-dashboard
> openstack/openstack-ansible-apt_package_pinning
> openstack/openstack-ansible-ceph_client
> openstack/openstack-ansible-galera_client
> openstack/openstack-ansible-galera_server
> openstack/openstack-ansible-haproxy_server
> openstack/openstack-ansible-lxc_container_create
> openstack/openstack-ansible-lxc_hosts
> openstack/openstack-ansible-memcached_server
> openstack/openstack-ansible-openstack_hosts
> openstack/openstack-ansible-openstack_openrc
> openstack/openstack-ansible-os_aodh
> openstack/openstack-ansible-os_barbican
> openstack/openstack-ansible-os_ceilometer
> openstack/openstack-ansible-os_cinder
> openstack/openstack-ansible-os_designate
> openstack/openstack-ansible-os_glance
> openstack/openstack-ansible-os_gnocchi
> openstack/openstack-ansible-os_heat
> openstack/openstack-ansible-os_horizon
> openstack/openstack-ansible-os_ironic
> openstack/openstack-ansible-os_keystone
> openstack/openstack-ansible-os_magnum
> openstack/openstack-ansible-os_molteniron
> openstack/openstack-ansible-os_neutron
> openstack/openstack-ansible-os_nova
> openstack/openstack-ansible-os_octavia
> openstack/openstack-ansible-os_rally
> openstack/openstack-ansible-os_sahara
> openstack/openstack-ansible-os_swift
> openstack/openstack-ansible-os_tempest
> openstack/openstack-ansible-os_trove
> openstack/openstack-ansible-pip_install
> openstack/openstack-ansible-plugins
> openstack/openstack-ansible-rabbitmq_server
> openstack/openstack-ansible-repo_build
> openstack/openstack-ansible-repo_server
> openstack/openstack-ansible-rsyslog_client
> openstack/openstack-ansible-rsyslog_server
> openstack/openstack-ansible-security
> openstack/os-net-config
> openstack/os-win
> openstack/osc-placement
> openstack/oslosphinx
> openstack/pycadf
> openstack/python-congressclient
> openstack/python-ironic-inspector-client
> openstack/python-manilaclient
> openstack/python-octaviaclient
> openstack/python-saharaclient
> openstack/python-tricircleclient
> openstack/python-tripleoclient
> openstack/python-vitrageclient
> openstack/python-zaqarclient
> openstack/python-zunclient
> openstack/rally
> openstack/searchlight-ui
> openstack/senlin
> openstack/storlets
> openstack/sushy
> openstack/sushy-tools
> openstack/tosca-parser
> openstack/virtualbmc
> openstack/watcher-dashboard
> openstack/yaql
> openstack/zun
>
> __
> OpenStack Development Mailing 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] [OpenStack-Dev][OpenStackClient] - Running functional tests

[Akihiro Motoki]

As Steve mentioned, you need to import OS_* envvars.
A user with admin role is required to pass all functional tests.
What I usually do is "export OS_CLOUD=devstack-admin" (if you use DevStack).


2017-07-04 22:01 GMT+09:00 Steve Martinelli :
> Looks like running tox will pass along any environment variables with the
> prefix "OS_" from the shell to tox, see
> https://github.com/openstack/python-openstackclient/blob/master/tox.ini#L55
>
> So as long as you've sourced or exported a bunch of env. variables, you
> should be ready to run tests. You don't and shouldn't run it with sudo
> either.
>
> On Tue, Jul 4, 2017 at 2:25 AM, nidhi.h...@wipro.com 
> wrote:
>>
>> Hello all,
>>
>>
>>
>> I am running functional tests for openstackclient.
>>
>> By using this command sudo tox -efunctional
>>
>>
>>
>> It gives me this error
>>
>>
>>
>> setUpClass
>> (openstackclient.tests.functional.volume.v3.test_snapshot.VolumeSnapshotTests)
>>
>>
>> -
>>
>>
>>
>> Captured traceback:
>>
>> ~~~
>>
>> Traceback (most recent call last):
>>
>>   File "openstackclient/tests/functional/volume/v3/test_snapshot.py",
>> line 22, in setUpClass
>>
>> super(VolumeSnapshotTests, cls).setUpClass()
>>
>>   File "openstackclient/tests/functional/volume/v2/test_snapshot.py",
>> line 31, in setUpClass
>>
>> cls.VOLLY
>>
>>   File "openstackclient/tests/functional/base.py", line 64, in
>> openstack
>>
>> return execute('openstack ' + cmd, fail_ok=fail_ok)
>>
>>   File "openstackclient/tests/functional/base.py", line 41, in execute
>>
>> result_err)
>>
>> tempest.lib.exceptions.CommandFailed: Command 'openstack volume create
>> -f json --size 1 ee1a858057464f15b6488ec4f3c1da5d' returned non-zero exit
>> status 1.
>>
>> stdout:
>>
>>
>>
>> stderr:
>>
>> Missing value auth-url required for auth plugin password
>>
>>
>>
>>
>>
>> Can someone tell me where do I need to configure environment variables
>>
>> So that functional tests run well?
>>
>>
>>
>> Any doc /url also will be helpful.
>>
>>
>>
>> Thanks
>>
>> Nidhi
>>
>>
>>
>> The information contained in this electronic message and any attachments
>> to this message are intended for the exclusive use of the addressee(s) and
>> may contain proprietary, confidential or privileged information. If you are
>> not the intended recipient, you should not disseminate, distribute or copy
>> this e-mail. Please notify the sender immediately and destroy all copies of
>> this message and any attachments. WARNING: Computer viruses can be
>> transmitted via email. The recipient should check this email and any
>> attachments for the presence of viruses. The company accepts no liability
>> for any damage caused by any virus transmitted by this email. www.wipro.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing 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][horizon][fwaas][vpnaas] fwaas/vpnaas dashboard split out

[Akihiro Motoki]

First of all, IMHO this approach is not a requirement.
Each project can choose their preferred way.

# Hopefully all dashboards are listed in the horizon plugin registry
if you have a dashboard support.
# https://docs.openstack.org/developer/horizon/install/plugin-registry.html

The following is my thought and reason I chose a separate project for
fwaas/vpnaas dashboards. We just follow what most horizon plugins do.

I believe translation support in the dashboard is one of
important aspects. As my hat of I18 team, our rough user survey shows us
that the dashboard is the area users need translations most.
The translation script in our infra supports only a separate project model
(I am one of the author of the current script) and at now we have no plan to
enhance it unless some new volunteer who wants to explore it.
In case of the FWaaS/VPNaaS dashboard, we already support translation now
and would like to keep it without exploring a new way.

I don't talk about testing much here. It is a straight forward topic.

Another point is from the deployment perspective.
Deployers might want not to install unnecessary things. Neutron and horizon may
deploy different servers and they may not install unrelated stuff.
It also affect distro packaging. Packages may need to create a separate package
from one source: one for neutron plugin and the other for horizon plugin.

This is my view I personally prefer to a separate repository.

Thanks,
Akihiro

2017-06-21 19:07 GMT+09:00 Thomas Morin :
> Kevin Benton :
>> Some context here:
>> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115200.html
>>
>
> Thanks, I had missed this one.
>
> So, what I gather is that the only drawback noted for "(b) dashboard code in
> individual project" is "Requires extra efforts to support neutron and
> horizon codes in a single repository for testing and translation supports.
> Each project needs to explore the way.".   While I won't disagree, my
> question would be the following: since we have something that works (except
> dashboard translation, which we haven't explored), should we move to the
> model agreed on for new work (given that there is also overhead in creating
> and maintaining a new repo) ?
>
> Best,
>
> -Thomas
>
>
> On Wed, Jun 21, 2017 at 2:33 AM, Thomas Morin 
> wrote:
>>
>> Hi Akihiro,
>>
>> While I understand the motivation to move these dashboards from
>> openstack/horizon, what is the reason to prefer a distinct repo for the
>> dashboard rather than hosting it in the main repo of these projects ?
>>
>> (networking-bgpvpn has had a dashboard for some time already, it is hosted
>> under networking-bgpvpn/bgpvpn_dashboard and we haven't heard about any
>> drawback)
>>
>> Thanks,
>>
>> -Thomas
>>
>>
>>
>> Akihiro Motoki :
>>
>> Hi neutron and horizon teams (especially fwaas and vpnaas folks),
>>
>> As we discussed so far, I prepared separate git repositories for FWaaS
>> and VPNaaS dashboards.
>> http://git.openstack.org/cgit/openstack/neutron-fwaas-dashboard/
>> http://git.openstack.org/cgit/openstack/neutron-vpnaas-dashboard/
>>
>> All new features will be implemented in the new repositories, for
>> example, FWaaS v2 support.
>> The initial core members consist of neutron-fwaas/vpnaas-core
>> (respectively) + horizon-core.
>>
>> There are several things to do to complete the split out.
>> I gathered a list of work items at the etherpad and we will track the
>> progress here.
>> https://etherpad.openstack.org/p/horizon-fwaas-vpnaas-splitout
>> If you are interested in helping the efforts, sign up on the etherpad
>> or contact me.
>>
>> I would like to release the initial release which is compatible with
>> the current horizon
>> FWaaS/VPNaaS dashboard (with no new features).
>> I hope we can release it around R-8 week (Jul 3) or R-7 (Jul 10).
>>
>> It also will be good examples for neutron stadium/related projects
>> which are interested in
>> adding dashboard support. AFAIK, networking-sfc, tap-as-a-service are
>> interested in it.
>>
>> Thanks,
>> Akihiro
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>&g

[openstack-dev] [neutron][horizon][fwaas][vpnaas] fwaas/vpnaas dashboard split out

[Akihiro Motoki]

Hi neutron and horizon teams (especially fwaas and vpnaas folks),

As we discussed so far, I prepared separate git repositories for FWaaS
and VPNaaS dashboards.
http://git.openstack.org/cgit/openstack/neutron-fwaas-dashboard/
http://git.openstack.org/cgit/openstack/neutron-vpnaas-dashboard/

All new features will be implemented in the new repositories, for
example, FWaaS v2 support.
The initial core members consist of neutron-fwaas/vpnaas-core
(respectively) + horizon-core.

There are several things to do to complete the split out.
I gathered a list of work items at the etherpad and we will track the
progress here.
https://etherpad.openstack.org/p/horizon-fwaas-vpnaas-splitout
If you are interested in helping the efforts, sign up on the etherpad
or contact me.

I would like to release the initial release which is compatible with
the current horizon
FWaaS/VPNaaS dashboard (with no new features).
I hope we can release it around R-8 week (Jul 3) or R-7 (Jul 10).

It also will be good examples for neutron stadium/related projects
which are interested in
adding dashboard support. AFAIK, networking-sfc, tap-as-a-service are
interested in it.

Thanks,
Akihiro

__
OpenStack Development Mailing 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] Call for check: is your project ready for pylint 1.7.1?

[Akihiro Motoki]

Hi all,

Is your project ready for pylint 1.7.1?
If you use pylint in your pep8 job, it is worth checked.

Our current version of pylint is 1.4.5 but it is not safe in python 3.5.
The global-requirements update was merged once [1],
However, some projects (at least neutron) are not ready for pylint
1.7.1 and it was reverted [2].
it is reasonable to give individual projects time to cope with pylint 1.7.1.

I believe bumping pylint version to 1.7.1 (or later) is the right
direction in long term.
I would suggest to make your project ready for pylint 1.7.1 soon (two
weeks or some?)
You can disable new rules in pylint 1.7.1 temporarily and clean up
your code later
as neutron does [3]. As far as I checked, most rules are reasonable
and worth enabled.

Thanks,
Akihiro Motoki

[1] https://review.openstack.org/#/c/470800/
[2] https://review.openstack.org/#/c/471756/
[3] https://review.openstack.org/#/c/471763/

__
OpenStack Development Mailing List (not for 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] pep8 breakage

[Akihiro Motoki]

Six 1.10.0 is not the root cause. The root cause is the version bump
of pylint (and astroid).
Regarding pylint and astroid, I think the issue will go once
https://review.openstack.org/#/c/469491/ is merged.
However, even after the global requirement is merged, neutron pylint will fail
because pylint 1.7.1 has a bit different syntax check compared to pylint 1.4.3.

I wonder pylint version bump should be announced because it
potentially breaks individual project gate.

Is it better to revert pylint version bump in global-requirements, or
just to ignore some pylint rules temporarily in neutron?

Akihiro


2017-06-07 20:43 GMT+09:00 Gary Kotton :
> Hi,
>
> Please see bug https://bugs.launchpad.net/neutron/+bug/1696403. Seems like
> six 1.10.0 has broken us.
>
> I have posted a patch in the requirements project. Not 100% sure that this
> is the right way to go. At least that will enable us to address this in
> neutron.
>
> Thanks
>
> Gary
>
>
> __
> OpenStack Development Mailing 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][horizon] FWaaS/VPNaaS dashboard split out from horizon

[Akihiro Motoki]

Hi all,

As discussed last month [1], we agree that each neutron-related
dashboard has its own repository.
I would like to move this forward on FWaaS and VPNaaS
as the horizon team plans to split them out as horizon plugins.

A couple of questions hit me.

(1) launchpad project
Do we create a new launchpad project for each dashboard?
At now, FWaaS and VPNaaS projects use 'neutron' for their bug tracking
from the historical reason, it sometimes There are two choices: the
one is to accept dashboard bugs in 'neutron' launchpad,
and the other is to have a separate launchpad project.

My vote is to create a separate launchpad project.
It allows users to search and file bugs easily.

(2) repository name

Are neutron-fwaas-dashboard / neutron-vpnaas-dashboard good repository
names for you?
Most horizon related projects use -dashboard or -ui as their repo names.
I personally prefers to -dashboard as it is consistent with the
OpenStack dashboard
(the official name of horizon). On the other hand, I know some folks
prefer to -ui
as the name is shorter enough.
Any preference?

(3) governance
neutron-fwaas project is under the neutron project.
Does it sound okay to have neutron-fwaas-dashboard under the neutron project?
This is what the neutron team does for neutron-lbaas-dashboard before
and this model is adopted in most horizon plugins (like trove, sahara
or others).

(4) initial core team

My thought is to have neutron-fwaas/vpnaas-core and horizon-core as
the initial core team.
The release team and the stable team follow what we have for
neutron-fwaas/vpnaas projects.
Sounds reasonable?


Finally, I already prepare the split out version of FWaaS and VPNaaS
dashboards in my personal github repos.
Once we agree in the questions above, I will create the repositories
under git.openstack.org.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-April/thread.html#115200

__
OpenStack Development Mailing List (not for 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][Neutron]Why we use secuirity group which only support dispatching whiltelist rules?

[Akihiro Motoki]

2017-04-28 7:03 GMT+09:00 Monty Taylor :
> On 04/25/2017 10:32 AM, Gary Kotton wrote:
>>
>> Hi,
>> I would like us to think of considering enabling an API that would allow
>> ‘deny’, for example an admin could overwrite a tenant’s security groups. For
>> example, and admin may not want a specific source range to access the
>> tenants VM’s. The guys working on FWaaS say that this may happen in V2, but
>> that looks very far away. Making this change in Neutron would be pretty
>> simple and give us a nice feature add.
>> If you would like to work on this I would be happy to develop this with
>> you. It could be added an extension.
>> Thanks
>> Gary
>>
>> On 4/24/17, 6:37 AM, "Ihar Hrachyshka"  wrote:
>>
>> All traffic is denied by default. OpenStack security groups API is
>> modeled to reflect what AWS does. You may find your needs better
>> served by fwaas plugin for neutron that is not constrained by AWS
>> compatibility.
>
>
> OpenStack does not claim to have or strive for AWS compatibility.
>
> It is not a goal. It may have been one for someone during the writing of the
> security-groups code, and thus may be a good description of why the
> security-groups are structured and behave the way they do. Moving forward,
> AWS compatibility should really never be a reason we do or don't do
> something if that thing is beneficial to our users.

I think one good reason that neutron security group only supports
whitelist rules
is to keep rule management simple.
If we support black list rules (i.e., deny/reject rules), users need
to consider the order of rules.
If blacklist rules and whitelist rules have overlapped areas, we need
priority of rules.
Supporting whitelist rules only makes rule management really simple and
I believe this is what is the security group API.

The rough consensus of the neutron community is that more complicated rules
like blacklist rules or rule priorities should go to FWaaS.

This topic was discussed several times in the neutron history and as of now
the above and what Gary and Ihar commented is our consensus.
The main background of the consensus is not just because of AWS compatibility.
In my understanding it is because what current users expect on the
security group.
Isn't it confusing that blacklist or rule priority is introduced at
some point from user perspective?

There are still gray zones. For example, a request we received multiple times
is "can neutron provide a way to define a set of default rules for a
new security group?".
It happened several months ago and at that time the proposal was rejected
because it changes what users have even though a feature is discoverable.


>
>
>> On Sun, Apr 23, 2017 at 8:33 PM, 田明明  wrote:
>> > Can we add an "action" to security group rule api, so that we could
>> dispatch
>> > rules with "deny" action? Until now， security group only supports
>> add
>> > white-list rules but this couldn't satisfy many people's needs.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for 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][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Akihiro Motoki]

Thanks for your feedback, all!
It seems we have a consensus and the route is "(a) dashboard
repository per project".
I would suggest -dashboard as a repository name where  is your
main repo name.


2017-04-11 0:09 GMT+09:00 Akihiro Motoki :
> Hi neutrinos (and horizoners),
>
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
>
> I would like to raise this topic again. No dashboard support lands since then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
>
> Possible approaches
> 
>
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
>
> Which one sounds better?
>
> Pros and Cons
> 
>
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
>
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
>
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another 
> implementation.
>
>
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).
>
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months ago.
> As an example, trunk support is being development in the horizon repo.
>
> Thanks,
> Akihiro

__
OpenStack Development Mailing List (not for 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][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Akihiro Motoki]

Hi TIm,

I think no user-visible changes happen for users.
Do you have any example in your mind?

I understand horizon lacks supports of some hooks (such as adding a
menu to an existing table).
If there are missing things,

2017-04-12 2:24 GMT+09:00 Tim Bell :
> Are there any implications for the end user experience by going to different
> repos (such as requiring dedicated menu items)?
>
>
>
> Tim
>
>
>
> From: "Sridar Kandaswamy (skandasw)" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Tuesday, 11 April 2017 at 17:01
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
>
>
> Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where
> would we like to have horizon dashboard for neutron stadium projects?
>
>
>
> Hi All:
>
>
>
> From and FWaaS perspective – we also think (a)  would be ideal.
>
>
>
> Thanks
>
>
>
> Sridar
>
>
>
> From: Kevin Benton 
> Reply-To: OpenStack List 
> Date: Monday, April 10, 2017 at 4:20 PM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where
> would we like to have horizon dashboard for neutron stadium projects?
>
>
>
> I think 'a' is probably the way to go since we can mainly rely on existing
> horizon guides for creating new dashboard repos.
>
>
>
> On Apr 10, 2017 08:11, "Akihiro Motoki"  wrote:
>
> Hi neutrinos (and horizoners),
>
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
>
> I would like to raise this topic again. No dashboard support lands since
> then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
>
> Possible approaches
> 
>
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
>
> Which one sounds better?
>
> Pros and Cons
> 
>
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
>
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
>
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium
> inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another
> implementation.
>
>
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a
> repo).
>
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months
> ago.
> As an example, trunk support is being development in the horizon repo.
>
> Thanks,
> Akihiro
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Tacker][OSC] Command naming specs

[Akihiro Motoki]

2017-04-15 12:44 GMT+09:00 Trinath Somanchi :
> Hi Jay-
>
> Thanks for the suggestions, we have improved this to an extent [1].
>
> For  'openstack vnf service function chain create' we agreed to go with,
> 'openstack nfv chain create' or 'openstack vnf chain create'

I agree with Jay that NFV sounds too broad.
Even though tacker's scope can cover VNF-M and NFV-O, 'nfv' still
sound too broad to me.
If a command belongs to VNF area, I would suggest to use 'vnf'.
If you have 'nfvo' related commands, you can explore an appropriate word.

VNFM and NFVO are different layers in ETSI and
for example I am not sure 'VNF' forwarding graph can be called as
'NFV' forwarding graph.

> For ' openstack vnf forwardinggraph create' , you suggestion sounds good. We
> are thinking on 'openstack vnffg create' in simple terms.

I don't think 'fg' is a common word. It is a bit long but 'forwarding
graph' is much easier to understand.
'vnffg' is difficult to understand even though I think I know NFV to
some extent.
Command line completion helps you. You should not think from the
developer perspective.

Thanks,
Akihiro

> We have come up with a rule for certain commands which conflict with other
> OpenStack projects,'nfv' is prefixed to differentiate the commands.
>
> The commands that may conflict include ``network-service``, ``classifier``,
> ``nfp``, ``chain`` and ``event``.
>
> [1]
> https://review.openstack.org/#/c/455188/14/specs/pike/python-openstackclient.rst
>
> Thanks,
>
> Trinath Somanchi.
>
>
>
> Digital Networking | NXP – Hyderabad – INDIA.
>
> Email: trinath.soman...@nxp.com
>
> Mobile: +91 9866235130 | Off: +91 4033504051
>
>
>
>
>
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Saturday, April 15, 2017 12:55 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs
>
>
>
> On 04/12/2017 03:08 AM, Trinath Somanchi wrote:
>
>> Hi OSC team-
>
>>
>
>> While  implementing tacker-cli commands as OSC plugins [1], We are
>
>> struck in command naming specifications.
>
>>
>
>> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
>
>> prefix.
>
>
>
> It's not *all* of NFV, though.
>
>
>
> This problem, by the way, is an indication that Tacker might have too big a
> scope...and a scope that is very much tailored/purpose-built for Telcos/NFV.
> But whatever, I raised this concern during the project application as a
> member of the TC and folks ignored me, so it is what it is I guess.
>
>
>
>> We were struck in naming the below commands while aligning with the
>
>> OSC naming specs.
>
>>
>
>> For the below commands, for readability, we have added ‘-‘ within the
>
>> command names.
>
>>
>
>> Like,
>
>>
>
>>   network-service,  vnf-forwarding-graph,
>
>> service-function-chain,
>
>>
>
>> network-flow-classifier, network-forwarding-path.
>
>
>
> I think what Dean and Akihiro were suggesting is to use "vnf" as the first
> "word" in the command list and then use space-delimited commands like so:
>
>
>
> openstack vnf network service create
>
>
>
> Or just leave off the "network" above, because, well, Tacker doesn't create
> any other type of service..., so:
>
>
>
> openstack vnf service create
>
>
>
> and then
>
>
>
> openstack vnf forwardinggraph create
>
>
>
> and
>
>
>
> openstack vnf service function chain create
>
>
>
>
>
> but then, you'll hit on the obvious overlap with networking-sfc, which will
> bring in the obvious question of "what's the difference between Tacker's SFC
> and networking-sfc's SFC?" which again should lead folks to question the
> scope of Tacker in relation to other OpenStack projects...
>
>
>
> Best,
>
> -jay
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Tacker][OSC] Command naming specs

[Akihiro Motoki]

networking-sfc has many overlapping areas with tacker and the command names
can conflict, so I believe it is worth shared in this thread.

networking-sfc team is now implementing OSC commands (as neutronclient OSC
plugin).
Their command name proposal can be found at
https://review.openstack.org/#/c/409759/
and command names are like
https://review.openstack.org/#/c/409759/30/doc/source/usage/osc/v2/networking-sfc.rst

As of now, networking-sfc commands are like:
  openstack sfc port chain create
  openstack sfc port pair group create
  openstack sfc port pair create
  openstack sfc flow classifier create

We would like to use 'sfc' (or 'network sfc') and
hope the tacker team avoid conflicts and confusions between tacker and
networking-sfc commands.

Personally, 'sfc' is not a well-known abbreviation, but the full spelling
'service function chaining' looks too long.
I don't think users want to type 'openstack service function chaining port
chain group create' :-(  It loses usability significantly.

Thanks,
Akihiro

2017-04-13 8:23 GMT+09:00 Trinath Somanchi :

> But if we don’t prefix, then we are afraid we might confuse users with
> command names and conflict with other projects.
>
>
>
> Example, ‘network-service’ if we follow the existing way, then
>
>
>
> $> openstack network service create
>
>
>
> might confuse the user in context that it’s a neutron/networking command.
> Is that not True?
>
>
>
> Also, for some other commands, like sfc, we might end up conflict with
> networking-sfc.
>
>
>
> Like, $> openstack  sfc show  (or) openstack service function chain show
>
>
>
> With some of the other commands, there are abbreviations like
>
>
>
> $> openstack vnffgd create
>
>
>
> If the above command must be split to words, it spells like,
>
>
>
> $> openstack virtual network function forwarding graph descriptor create
>  
>
>
>
> If we elaborate this way the command itself will be a lengthy string where
> user has a very lengthy command.
>
>
>
> Any suggestions for these?
>
> Thanks,
>
> *Trinath Somanchi.*
>
>
>
> Digital Networking | NXP – Hyderabad – INDIA.
>
> Email: *trinath.soman...@nxp.com *
>
> Mobile: +91 9866235130 <+91%2098662%2035130> | Off: +91 4033504051
> <+91%2040%203350%204051>
>
> [image: cid:image001.png@01D28854.B7934C80]
>
>
>
> *From:* Dean Troyer [mailto:dtro...@gmail.com]
> *Sent:* Wednesday, April 12, 2017 10:17 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Tacker][OSC] Command naming specs
>
>
>
> On Wed, Apr 12, 2017 at 2:08 AM, Trinath Somanchi <
> trinath.soman...@nxp.com> wrote:
>
> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
> prefix.
>
>
>
> Note that OSC itself does not use 'command prefixes', it names resources
> with enough specificity to make them unique.  Sometimes that looks like a
> proefix, but it is not.
>
>
>
>
>
> For the below commands, for readability, we have added ‘-‘ within the
> command names.
>
> Like,
>
>   network-service,  vnf-forwarding-graph, service-function-chain,
>
> network-flow-classifier, network-forwarding-path.
>
>
>
> But the existing OSC commands don’t have a ‘-‘ in between the command
> names.
>
>
>
> The OSC command structure specifically does not use dashes or underscores
> as separators, it uses spaces.  We want commands to be words.  Dashes are
> only used in option names due to option parsing rules.
>
>
>
> Specifically in networking there are a large number of resources that are
> hard to concisely name.  Plugins are of course free to do what they want
> but we encourage them to use the OSC guidelines, and we know that users
> _really_ appreciate staying consistent.
>
>
>
> There are places where you may feel forced to use abbreviations ('vnf' in
> your example above).  Those are discouraged, but we also recognize that
> they are often the most common usage ('IP' in IP address for example) and
> where that usage is common is fine.  Again, networking is an area where
> many things are commonly known only by their abbreviation, and this usage
> is in fact expected by users.  In the end, picking commands that are what
> users would expect to search for is what they appreciate the most.
>
>
>
> dt
>
>
>
> --
>
>
> Dean Troyer
> dtro...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for 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][tc] nova-network deprecation in horizon

[Akihiro Motoki]

2017-04-10 23:19 GMT+09:00 Dean Troyer :
> On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki  wrote:
>> (question not directly related to this topic)
>> I am not sure there is a case where users still use API 2.36 for
>> network management
>> and newer API versions for other compute operation.
>
> This is probably true for Horizon, where the app install likely
> matches the cloud it is configured to use.  However, many other use
> cases for the Python libraries are meant to talk to multiple versions
> of clouds and the 8.0 release of novaclient causes problems there.
>
> Even after nova-net support is EOL officially OSC plans to support the
> use of nova-net for some time.  We are re-implementing the removed
> functionality locally.  And anticipating some of the questions why,
> consider an operator working on the long migration/upgrade from a
> deployed nova-net cloud to a Neutron cloud, and needing to keep at
> least one foot in both worlds.  There are other similar uses.

This topic on novaclient 8.0.0 raised me a question on our python
binding support policy.
I see two points:

- The one is which API version should be supported by a python binding
from a same release.
For example, Pike novaclient supports >2.36 of Nova API while Nova
still supports <=2.35 API.
Python bindings should support a whole set of supported API or a
subset of supported API
(of course including 'latest' version of API).

- The other is about multi cloud use cases. Different OpenStack clouds
may use different releases
and client libraries need to support

The latter covers broader range of use cases.

Akihiro

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

__
OpenStack Development Mailing 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][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Akihiro Motoki]

Hi neutrinos (and horizoners),

As the title says, where would we like to have horizon dashboard for
neutron stadium projects?
There are several projects under neutron stadium and they are trying
to add dashboard support.

I would like to raise this topic again. No dashboard support lands since then.
Also Horizon team would like to move in-tree neutron stadium dashboard
(VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.

Possible approaches


Several possible options in my mind:
(a) dashboard repository per project
(b) dashboard code in individual project
(c) a single dashboard repository for all neutron stadium projects

Which one sounds better?

Pros and Cons


(a) dashboard repository per project
  example, networking-sfc-dashboard repository for networking-sfc
  Pros
   - Can use existing horizon related project convention and knowledge
 (directory structure, testing, translation support)
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons
   - An additional repository is needed.

(b) dashboard code in individual project
  example, dashboard module for networking-sfc
  Pros:
   - No additional repository
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons:
   - Requires extra efforts to support neutron and horizon codes in a
single repository
 for testing and translation supports. Each project needs to
explore the way.

(c) a single dashboard repository for all neutron stadium projects
   (something like neutron-advanced-dashboard)
  Pros:
- No additional repository per project
  Each project do not need a basic setup for dashboard and
possible makes things simple.
  Cons:
- Inclusion criteria depending on the neutron stadium inclusion/exclusion
  (Similar discussion happens as for neutronclient OSC plugin)
  Project before neutron stadium inclusion may need another implementation.


My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).

Note that as dashboard supports for feature in the main neutron repository
are implemented in the horizon repository as we discussed several months ago.
As an example, trunk support is being development in the horizon repo.

Thanks,
Akihiro

__
OpenStack Development Mailing List (not for 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][tc] nova-network deprecation in horizon

[Akihiro Motoki]

I am okay to drop nova-network feature in Pike.

More generally, can we horizon team say the following?

 A feature deprecated in a back-end project is automatically
deprecated in Horizon
 and a feature in horizon will be dropped if a corresponding support
is dropped in
 a back-end project and/or its support library (like python bindings)
 even though horizon may provide an extended supports.

Akihiro

2017-03-29 7:02 GMT+09:00 Rob Cresswell :
> Frankly, it sounds like we can pretty comfortably drop support for nova-net
> in Pike. I'm fine with that, from a Horizon point of view.
>
> Rob
>
> On 28 March 2017 at 21:06, Matt Riedemann  wrote:
>>
>> On 3/28/2017 9:04 AM, Akihiro Motoki wrote:
>> > Hi,
>> >
>> > I would like to raise a topic when horizon nova-network support can be
>> > dropped.
>> > I added [tc] tag as it is related to
>> > "assert:follows-standard-deprecation" tag in the governance.
>> >
>> > Can horizon drop nova-network support based on the deprecation of
>> > nova-network
>> > from the nova team?
>> > or does horizon need to deprecate nova-network support in horizon
>> > explicitly?
>> >
>> > Let me summarize the current situation:
>> > - nova team deprecated nova-network in Newton release. [1]
>> > - horizon team has not deprecated it so far (just forgot to do it).
>> > - nova-network security group and floating IP support has been dropped
>> > from novaclient few days ago [2].
>> > - When a new release of novaclient comes, horizon security group
>> > support will be broken (if neutron is not used)
>> > - Nova microversion also allows to use nova-network but old version of
>> > novaclient is required for horizon to
>> >   support it and it is not realistic.
>>
>> This is the tricky part. You can specify a microversion to use
>> novaclient with the nova-network behavior. If you're using the python
>> API bindings in novaclient, which I think Horizon is, then you have to
>> specify a microversion anyway. The nova-network API bindings in
>> novaclient will work up until 2.35.
>>
>> The messy part about this is when we release novaclient 8.0 then that
>> code is gone and microversions don't matter. So you'd have to use an
>> older version, 7.1.0 at this point. To do that, we have to essentially
>> cap novaclient to 7.1.0 in upper-constraints in the requirements repo
>> for the rest of Pike since Horizon won't work with 8.0.
>>
>> I don't want to cap novaclient in upper-constraints for the rest of
>> Pike, but at the same time, it's not great to just drop features out of
>> a UI without first telling users they are deprecated first. However,
>> having said that, isn't Horizon really the portal for the tenant user? I
>> know admins use it also, but the admin/operator should already know
>> about the nova-network deprecation. If they are just finding out about
>> this because their Horizon features all of a sudden don't work in Pike,
>> that's pretty bad on their part, in my opinion anyway. In this
>> perspective, I think it might be OK to drop nova-network support without
>> a deprecation period in Horizon for the things we've removed from
>> novaclient.
>>
>> >
>> > It would be nice that horizon team is allowed to drop some feature
>> > aligning with feature deprecation
>> > and drop in backend project(s) (without explicit deprecation notices
>> > in horizon side).
>> >
>> > It is not easy that horizon team is aware of all feature deprecations
>> > in other projects
>> > and the horizon team tends to be aware of them when the deprecated
>> > features are
>> > actually dropped.
>> >
>> > Thought?
>> >
>> > There may be things and solutions I am not aware of. Any feedback
>> > would be appreciated.
>>
>> Me too. :)
>>
>> >
>> > Best Regards,
>> > Akihiro
>> >
>> > [1]
>> > https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes
>> > [2] https://review.openstack.org/#/c/447707/
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> --
>>
&g

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

[Akihiro Motoki]

2017-03-29 5:06 GMT+09:00 Matt Riedemann :
> On 3/28/2017 9:04 AM, Akihiro Motoki wrote:
>>
>> Hi,
>>
>> I would like to raise a topic when horizon nova-network support can be
>> dropped.
>> I added [tc] tag as it is related to
>> "assert:follows-standard-deprecation" tag in the governance.
>>
>> Can horizon drop nova-network support based on the deprecation of
>> nova-network
>> from the nova team?
>> or does horizon need to deprecate nova-network support in horizon
>> explicitly?
>>
>> Let me summarize the current situation:
>> - nova team deprecated nova-network in Newton release. [1]
>> - horizon team has not deprecated it so far (just forgot to do it).
>> - nova-network security group and floating IP support has been dropped
>> from novaclient few days ago [2].
>> - When a new release of novaclient comes, horizon security group
>> support will be broken (if neutron is not used)
>> - Nova microversion also allows to use nova-network but old version of
>> novaclient is required for horizon to
>>   support it and it is not realistic.
>
>
> This is the tricky part. You can specify a microversion to use novaclient
> with the nova-network behavior. If you're using the python API bindings in
> novaclient, which I think Horizon is, then you have to specify a
> microversion anyway. The nova-network API bindings in novaclient will work
> up until 2.35.

Sorry for my late.

Yes, nova supports nova-network API in API version up to 2.35.
Horizon now consumes python bindings from novaclient with version 2
(not latest API version) unless we need to use more recent version.
Horizon just started micro versioning support in Pile and most work is
under development.

> The messy part about this is when we release novaclient 8.0 then that code
> is gone and microversions don't matter. So you'd have to use an older
> version, 7.1.0 at this point. To do that, we have to essentially cap
> novaclient to 7.1.0 in upper-constraints in the requirements repo for the
> rest of Pike since Horizon won't work with 8.0.

Yeah, this is the most tricky part.

Is there any deprecation policy in novaclient python binding?
I was not aware of deprecation warnings.
If novaclient follows nova deprecation, it sounds reasonable to me.

> I don't want to cap novaclient in upper-constraints for the rest of Pike,
> but at the same time, it's not great to just drop features out of a UI
> without first telling users they are deprecated first. However, having said
> that, isn't Horizon really the portal for the tenant user? I know admins use
> it also, but the admin/operator should already know about the nova-network
> deprecation. If they are just finding out about this because their Horizon
> features all of a sudden don't work in Pike, that's pretty bad on their
> part, in my opinion anyway. In this perspective, I think it might be OK to
> drop nova-network support without a deprecation period in Horizon for the
> things we've removed from novaclient.

Horizon is both for tenant users and admin/operators.
In my understanding, operators need to know deprecation notices of various
projects and decide which version they should provide.
This applies to horizon too. If they want to provide nova-network
support in horizon,
they can choose a way not to upgrade horizon to Pike.
Nova already deprecated nova-network after Nova API 2.36 and this means
users cannot use newer features anymore as if a newer API version is used
nova-network is not take into account. What is the merit of upgrading
nova and horizon?

Considering the above, it looks okay to me to drop nova-network support
from horizon in Pike based on nova-team deprecation of nova-network in Newton.

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.

Akihiro

>
>>
>> It would be nice that horizon team is allowed to drop some feature
>> aligning with feature deprecation
>> and drop in backend project(s) (without explicit deprecation notices
>> in horizon side).
>>
>> It is not easy that horizon team is aware of all feature deprecations
>> in other projects
>> and the horizon team tends to be aware of them when the deprecated
>> features are
>> actually dropped.
>>
>> Thought?
>>
>> There may be things and solutions I am not aware of. Any feedback
>> would be appreciated.
>
>
> Me too. :)
>
>>
>> Best Regards,
>> Akihiro
>>
>> [1]
>> https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes
>> [2] https://review.openstack.org/#

Re: [openstack-dev] How to get all detail RPC message and detail context in neutron docs?

[Akihiro Motoki]

Hi Sam,

'context' is an object of neutron.context.Context which inherits
oslo_context.RequestContext.
When you see 'context' as a method signature like
router_added_to_agent(self, context, payload),
'context' is Context object.

oslo_messaging serializes the context object and sends to RPC consumer(s).
The serialization conveys the object content to a receiver.

In neutron case, the 'context' object is usually created from keystone
context [1]
or get_admin_context(_without_session) [2].

Does this answer to your question?

[1] https://github.com/openstack/neutron/blob/master/neutron/auth.py#L30
[2] 
https://github.com/openstack/neutron-lib/blob/master/neutron_lib/context.py#L161


2017-04-05 19:09 GMT+09:00 Sam :
> Hi all,
>
> I'm working on neutron L3 Agent and some other Agent. I found that there are
> lots of RPCs including RPC call and notification and lots of 'context' as
> bellow. But I don't know its detail context, can I get these from some docs?
>
> If there are no docs, could I get these using some debug method? Like
> '--debug' option or using pdb or something?
>
> RPC: like 'agent_updated' in neutron/neutron/agent/l3/agent.py Line759.
>
> context: it's param in some function like 'def router_added_to_agent(self,
> context, payload):' in neutron/neutron/agent/l3/agent.py.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [all][TripleO][release][deployment] Packaging problems due to branch/release ordering

[Akihiro Motoki]

I see Emilien proposed a number of patches to individual projects with
"Sem-Ver: api-break" in the commit message.
As far as I understand the pbr documentation [1] correctly (see the
forth paragraph in the section) which is pointed by Emilien,
the change looks reasonable.

Honestly it would be great if we have a green signal for the similar
change as a community
as not all developers are familiar with this kind of changes.

Can all developers get the green signal for the similar change?

Akihiro

[1] https://docs.openstack.org/developer/pbr/#version


2017-04-05 10:36 GMT+09:00 Emilien Macchi :
> adding [all] for more visibility... See comments inline:
>
> On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi  wrote:
>> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec  wrote:
>>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
 In the past we addressed this by automatically merging the release
 tag back into master, but we stopped doing that a cycle ago because
 it complicated release note generation.
>>>
>>> Also this was including RC >= 2 and final tags so as soon as the first
>>> stable maintenance version was released, master was again lower
>>> version.
>>
>> topic sounds staled.
>> Alan,  do we have an ETA on the RDO workaround?
>
> Without progress on RDO tooling and the difficulty of implementing it,
> I went ahead and proposed a semver bump for some projects:
>
> https://review.openstack.org/#/q/topic:sem-ver/pike
>
> Except for Swift where I don't know if they'll bump X, I proposed to bump Y.
> For all other projects, I bumped X as they did from Newton to Ocata.
> (where version is X.Y.Z).
>
> Please give any feedback on the reviews if you prefer another kind of bump.
> Thanks for reviewing that asap, so TripleO CI can test upgrades from
> Ocata to Pike soon.
>
> Thanks,
>
>> Thanks,
>>
>>> Cheers,
>>> Alan
>>>
>>> __
>>> OpenStack Development Mailing 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
>
>
>
> --
> 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