Re: [openstack-dev] [horizon] [devstack] horizon 'network create' panel does not distinguished

[Xinni Ge]

Hello Jaewook and everyone,

I tried to install upstream/master Horizon+Heat-dashboard, still could not
see the error.
Maybe a clean installation of devstack could fix the issue.

If you want to enable heat-dashboard in current working environment, you
can try to install it manually.
I share my manual installation steps here, and you could also use it to
switch to any version or apply a patch.

1. update heat-dashboard
cd ~/heat-dashboard;
# Choose the version wanted
# download a particular patch by:
# git review -d ;
# or switch to any branch e.g. master by:
# git checkout master;

2. install heat-dashboard
# not necessarily needed, check if heat-dashboard is installed with `pip
list`
sudo pip install -e .

2. copy heat-dashboard settings to horizon
cp -rv ~/heat-dashboard/heat_dashboard/enabled
~/horizon/openstack_dashboard/local/
cp ~/heat-dashboard/heat_dashboard/local_settings.d/_1699_
orchestration_settings.py
 ~/horizon/openstack_dashboard/local/local_settings.d/
cp ~/heat-dashboard/heat_dashboard/conf/heat_policy.json
 ~/horizon/openstack_dashboard/conf/

3. let horizon re-collect static files, and compress
python manage.py collectstatic --clear
python manage.py compress

4. restart apache server
sudo service apache2 restart


Best Regards,
Xinni


On Tue, Mar 13, 2018 at 10:40 AM, Xinni Ge  wrote:

> Hello Jaewook,
>
> Very glad to know it.
> I will add comments to the bug report, and continue to find a better
> solution to prevent the issue from happening.
>
> Best Regards!
> Xinni
>
> On Tue, Mar 13, 2018 at 10:34 AM, Jaewook Oh  wrote:
>
>> Hello, Xinni.
>>
>> I followed your description, and it worked properly :)
>>
>> Can you comment your description in the bug report?
>>
>> https://bugs.launchpad.net/bugs/1755140
>>
>> It would be very helpful for me or somebody else who doesn't know how to
>> restart the horizon independently!
>>
>> Best Regards,
>> Jaewook.
>>
>> 2018-03-13 9:45 GMT+09:00 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_orc
>>> hestration_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 

Re: [openstack-dev] [murano][Openstack-stable-maint] Stable check of openstack/murano failed

[Tony Breeds]

On Fri, Mar 09, 2018 at 03:32:02PM +1100, Tony Breeds wrote:
> On Thu, Mar 08, 2018 at 06:16:27AM +, A mailing list for the OpenStack 
> Stable Branch test reports. wrote:
> > Build failed.
> > 
> > - build-openstack-sphinx-docs 
> > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/murano/stable/pike/build-openstack-sphinx-docs/8b023b7/html/
> >  : SUCCESS in 4m 44s
> > - openstack-tox-py27 
> > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/murano/stable/pike/openstack-tox-py27/82d0dae/
> >  : FAILURE in 5m 48s
> 
> The job is failing on the periodic-stable pipeline which indicates that
> all changes on pike will hit this same issue.
> 
> There is fix on master[1] but it's wrong so rather than back porting
> that pike it'd be great if someone from the murano team could own fixing
> this properly.
> 
> Based on my 5mins of poking it seems that reading the test yaml file is
> generating a list of unicode values rather than the expected list of
> string_type().   I think the answer is a simple as iterating over the
> list and using six.string_type to massage the value.  I don't knwo what
> else that will break and I also don't know the details of the contract
> that allowed pattern is describing.
> 
> For example making it a simple string value would probably also fix it
> but that isn't a backwards compatible change.
> 
> Yours Tony.
> 
> [1] 
> https://review.openstack.org/#/c/523829/4/murano/tests/unit/packages/hot_package/test_hot_package.py@114


I see that this has been fixed on pike but without fixing it on master
and queens.  I've proposed the forward-ports of the fix.

Can you verify that they're correct and then apply them, as currently
murano has/is violating the stable policy.

Yours Tony.


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

Re: [openstack-dev] [requirements][zun][karbor][magnum][tacker][kolla][tripleo][zaqar][networking-odl] update websocket-client and kubernetes libraries

[Tony Breeds]

On Mon, Mar 12, 2018 at 06:47:14PM -0500, Matthew Thode wrote:
> Requirements plans to update both versions, removing the current cap on
> websocket-cient.  The plan to do so is as follows.
> 
> a. Remove the cap on websocket-client

This is being done in: https://review.openstack.org/#/c/549664/

> b. merge the gr-update into python-zunclient
> c. make release of python-zunclient
> d. Alter the constrained versions of websocket-client and kubernetes
>- to be co-installable with openstack libs (python-zunclient)
> e. Raise the minimum acceptable version for kubernetes
>raise the minimum version of websocket-client
>- raise to above the versions kubernetes had problems with

The process above will impact the following projects:

$ get-all-requirements.py --pkgs kubernetes websocket-client
Package  : kubernetes [kubernetes>=4.0.0] (used by 5 projects)
Included in  : 3 projects
openstack/karbor  [cycle-with-intermediary]
openstack/magnum  [cycle-with-intermediary]
openstack/tacker  [cycle-with-intermediary]
Also affects : 2 projects
openstack/kolla-kubernetes[None]
openstack/kuryr-tempest-plugin[None]
Package  : websocket-client [websocket-client<=0.40.0,>=0.33.0] (used by 5 
projects)
Re-Release   : 2 projects
openstack/python-tripleoclient[cycle-trailing]
openstack/python-zunclient[cycle-with-intermediary]
Included in  : 2 projects
openstack/zaqar   [cycle-with-milestones]
openstack/zun [cycle-with-intermediary]
Also affects : 1 projects
openstack/networking-odl  [cycle-with-milestones]

So I've updated the subject to reflect that.

Yours Tony.


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

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

[Kaz Shinohara]

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 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
>>
>>
>>
>>
>> --
>> 葛馨霓 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
>

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

[Xinni Ge]

Hello Jaewook,

Very glad to know it.
I will add comments to the bug report, and continue to find a better
solution to prevent the issue from happening.

Best Regards!
Xinni

On Tue, Mar 13, 2018 at 10:34 AM, Jaewook Oh  wrote:

> Hello, Xinni.
>
> I followed your description, and it worked properly :)
>
> Can you comment your description in the bug report?
>
> https://bugs.launchpad.net/bugs/1755140
>
> It would be very helpful for me or somebody else who doesn't know how to
> restart the horizon independently!
>
> Best Regards,
> Jaewook.
>
> 2018-03-13 9:45 GMT+09:00 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_orc
>> hestration_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=
>>> 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%
>>> 20registering%20a%20module%20ensure%20that%20you%
>>> 20specify%20the%20dependencies%20as%20the%20second%
>>> 

Re: [openstack-dev] [horizon] [devstack] horizon 'network create' panel does not distinguished

[Jaewook Oh]

Hello, Xinni.

I followed your description, and it worked properly :)

Can you comment your description in the bug report?

https://bugs.launchpad.net/bugs/1755140

It would be very helpful for me or somebody else who doesn't know how to
restart the horizon independently!

Best Regards,
Jaewook.

2018-03-13 9:45 GMT+09:00 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
>> 

Re: [openstack-dev] [horizon] [devstack] horizon 'network create' panel does not distinguished

[Jaewook Oh]

Hello Xinni, 
Thanks for your kind help and information.

I'll try what you said soon :)

By the way, I reported this issue in the bug report,
if anybody interested in it, please visit

https://bugs.launchpad.net/bugs/1755140 


Best Regards,
Jaewook.

Jaewook Oh (오재욱)
IISTRC - Internet Infra System Technology Research Center
369 Sangdo-ro, Dongjak-gu,
06978, Seoul, Republic of Korea

> 2018. 3. 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.heat_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/3bf910c7ae4c.js:699:8 
> 
> at 
> http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:818:59 
> 
> at ensure 
> (http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:816:320 
> )
> at module 
> (http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:818:8 
> )
> at 
> http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:925:35 
> 
> at forEach 
> (http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:703:400 
> )
> at loadModules 
> (http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:924:156 
> )
> at 
> http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:925:84 
> 
> at forEach 
> (http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:703:400 
> 

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

Re: [openstack-dev] [horizon] [devstack] horizon 'network create' panel does not distinguished

[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.
> heat_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/
> 3bf910c7ae4c.js:699:8
> at http://192.168.11.187/dashboard/static/dashboard/js/
> 3bf910c7ae4c.js:818:59
> at ensure (http://192.168.11.187/dashboard/static/dashboard/js/
> 3bf910c7ae4c.js:816:320)
> at module (http://192.168.11.187/dashboard/static/dashboard/js/
> 3bf910c7ae4c.js:818:8)
> at http://192.168.11.187/dashboard/static/dashboard/js/
> 3bf910c7ae4c.js:925:35
> at forEach (http://192.168.11.187/dashboard/static/dashboard/js/
> 3bf910c7ae4c.js:703:400)
> at loadModules (http://192.168.11.187/dashboard/static/dashboard/js/
> 3bf910c7ae4c.js:924:156)
> at http://192.168.11.187/dashboard/static/dashboard/js/
> 3bf910c7ae4c.js:925:84
> at forEach (http://192.168.11.187/dashboard/static/dashboard/js/
> 3bf910c7ae4c.js:703:400)
> at loadModules (http://192.168.11.187/dashboard/static/dashboard/js/
> 3bf910c7ae4c.js:924:156)
> http://errors.angularjs.org/1.5.8/$injector/modulerr?p0=
> horizon.dashboard.project.heat_dashboard.template_
> generator=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%20registering%20a%20module%20ensure%20that%20you%
> 20specify%20the%20dependencies%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%
> 2F3bf910c7ae4c.js%3A699%3A8%0A%20%20%20%20at%20http%3A%2F%
> 2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%
> 2F3bf910c7ae4c.js%3A818%3A59%0A%20%20%20%20at%20ensure%20(
> http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%
> 2F3bf910c7ae4c.js%3A816%3A320)%0A%20%20%20%20at%20module%20(
> http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%
> 2F3bf910c7ae4c.js%3A818%3A8)%0A%20%20%20%20at%20http%3A%2F%
> 2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%
> 2F3bf910c7ae4c.js%3A925%3A35%0A%20%20%20%20at%20forEach%20(
> http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%
> 

[openstack-dev] [requirements][zun] update websocket-client and kubernetes libraries

[Matthew Thode]

Requirements plans to update both versions, removing the current cap on
websocket-cient.  The plan to do so is as follows.

a. Remove the cap on websocket-client
b. merge the gr-update into python-zunclient
c. make release of python-zunclient
d. Alter the constrained versions of websocket-client and kubernetes
   - to be co-installable with openstack libs (python-zunclient)
e. Raise the minimum acceptable version for kubernetes
   raise the minimum version of websocket-client
   - raise to above the versions kubernetes had problems with

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [keystone] [oslo] new unified limit library

[Joshua Harlow]

The following may give u some more insight into delimiter,

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

-Josh

Lance Bragstad wrote:

I missed the document describing the process for this sort of thing [0].
So I'm back tracking a bit to go through a more formal process.

[0]
http://specs.openstack.org/openstack/oslo-specs/specs/policy/new-libraries.html

# Proposed new library oslo.limit

This is a proposal to create a new library dedicated to enabling more
consistent quota and limit enforcement across OpenStack.

## Proposed library mission

Enforcing quotas and limits across OpenStack has traditionally been a
tough problem to solve. Determining enforcement requires quota knowledge
from the service along with information about the project owning the
resource. Up until the Queens release, quota calculation and enforcement
has been left to the services to implement, forcing them to understand
complexities of keystone project structure. During the Pike and Queens
PTG, there were several productive discussions towards redesigning the
current approach to quota enforcement. Because keystone is the authority
of project structure, it makes sense to allow keystone to hold the
association between a resource limit and a project. This means services
still need to calculate quota and usage, but the problem should be
easier for services to implement since developers shouldn't need to
re-implement possible hierarchies of projects and their associated
limits. Instead, we can offload some of that work to a common library
for services to consume that handles enforcing quota calculation based
on limits associated to projects in keystone. This proposal is to have a
new library called oslo.limit that fills that need.

## Consuming projects

The services consuming this work will be any service that currently
implements a quota system, or plans to implement one. Since keystone
already supports unified limits and association of limits to projects,
the implementation for consuming projects is easier. instead of having
to re-write that implementation, developers need to ensure quota
calculation to passed to the oslo.limit library somewhere in the API's
validation layer. The pattern described here is very similar to the
pattern currently used by services that leverage oslo.policy for
authorization decisions.

## Alternative libraries

It looks like there was an existing library that attempted to solve some
of these problems, called delimiter [1]. It looks like delimiter could
be used to talk to keystone about quota enforcement, where as the
existing approach with oslo.limit would be to use keystone directly.
Someone more familiar with the library (harlowja?) can probably shed
more light on it's intended uses (I couldn't find much documentation),
but the presentation linked in a previous note was helpful.

[1] https://github.com/openstack/delimiter

## Proposed adoption model/plan

The unified limit API [2] in keystone is currently marked as
experimental, but the keystone team is actively collecting and
addressing feedback that will result in stabilizing the API.
Stabilization changes that effect the oslo.limit library will also be
addressed before version 1.0.0 is released. From there, we can look to
incorporate the library into various services that either have an
existing quota implementation, or services that have a quota requirement
but no implementation.

This should help us refine the interfaces between services and
oslo.limit, while providing a facade to handle complexities of project
hierarchies. This should enable adoption by simplifying the process and
making it easier for quota to be implemented in a consistent way across
services.

[2]
https://docs.openstack.org/keystone/latest/admin/identity-unified-limits.html

## Reviewer activity

At first thought, it makes sense to model the reviewer structure after
the oslo.policy library, where the core team consists of people not only
interested in limits and quota, but also people familiar with the
keystone implementation of the unified limits API.

## Implementation

### Primary Authors:

   Lance Bragstad (lbrags...@gmail.com) lbragstad
   You?

### Other contributors:

   You?

## Work Items

* Create a new library called oslo.limit
* Create a core group for the project
* Define the minimum we need to enforce quota calculations in oslo.limit
* Propose an implementation that allows services to test out quota
enforcement via unified limits

## References

Rocky PTG Etherpad for unified limits:
https://etherpad.openstack.org/p/unified-limits-rocky-ptg

## Revision History

Introduced in Rocky


On 03/07/2018 11:55 PM, Joshua Harlow wrote:

So the following was a prior effort:

https://github.com/openstack/delimiter

Maybe just continue down the path of that and/or take that whole repo
over and iterate (or adjust the prior code, or ...)?? Or if not that's
ok to, ya'll get to decide.

https://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal

Re: [openstack-dev] [Neutron] Dublin PTG Summary

[fumihiko kakuma]

Hi Miguel,

> * As part of the neutron-lib effort, we have found networking projects that
> are very inactive. Examples are networking-brocade (no updates since May of
> 2016) and networking-ofagent (no updates since March of 2017). Miguel
> Lavalle will contact these projects leads to ascertain their situation. If
> they are indeed inactive, we will not support them as part of neutron-lib
> updates and will also try to remove them from code search

networking-ofagent has been removed in the Newton release.
So it will not be necessary to support it as part of neutron-lib updates.

Thanks
kakuma.


On Mon, 12 Mar 2018 13:45:27 -0500
Miguel Lavalle  wrote:

> Hi All!
> 
> First of all, I want to thank you the team for the productive week we had
> in Dublin. Following below is a high level summary of the discussions we
> had. If there is something I left out, please reply to this email thread to
> add it. However, if you want to continue the discussion on any of the
> individual points summarized below, please start a new thread, so we don't
> have a lot of conversations going on attached to this update.
> 
> You can find the etherpad we used during the PTG meetings here:
> https://etherpad.openstack.org/p/neutron-ptg-rocky
> 
> 
> Retrospective
> ==
> 
> * The team missed one community goal in the Pike cycle (
> https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html) and
> one in the Queens cycle (https://governance.openstack.
> org/tc/goals/queens/policy-in-code.html)
> 
>- Akihiro Motoki will work on https://governance.openstack.o
> rg/tc/goals/queens/policy-in-code.html during Rocky
> 
>   - We need volunteers to complete https://governance.op
> enstack.org/tc/goals/pike/deploy-api-in-wsgi.html) and the two new goals
> for the Rocky cycle: https://governance.openstack.o
> rg/tc/goals/rocky/enable-mutable-configuration.html and
> https://governance.openstack.org/tc/goals/rocky/mox_removal.html. Akihiro
> Motoki will lead the effort for mox removal
> 
>   - We decided to add a section to our weekly meeting agenda where we are
> going to track the progress towards catching up with the community goals
> during the Rocky cycle
> 
> * As part of the neutron-lib effort, we have found networking projects that
> are very inactive. Examples are networking-brocade (no updates since May of
> 2016) and networking-ofagent (no updates since March of 2017). Miguel
> Lavalle will contact these projects leads to ascertain their situation. If
> they are indeed inactive, we will not support them as part of neutron-lib
> updates and will also try to remove them from code search
> 
> * We will continue our efforts to recruit new contributors and develop core
> reviewers. During the conversation on this topic, Nikolai de Figueiredo and
> Pawel Suder announced that they will become active in Neutron. Both of
> them, along with Hongbin Lu, indicated that are interested in working
> towards becoming core reviewers.
> 
> * The team went through the blueprints in the backlog. Here is the status
> for those blueprints that are not discussed in other sections of this
> summary:
> 
>- Adopt oslo.versionedobjects for database interactions. This is a
> continuing effort. The contact is Ihar Hrachyshka  (ihrachys). Contributors
> are wanted. There is a weekly meeting led by Ihar where this topic is
> covered: http://eavesdrop.openstack.org/#Neutron_Upgrades_Meeting
> 
>- Enable adoption of an existing subnet into a subnetpool. The final
> patch in the series to implement this feature is:
> https://review.openstack.org/#/c/348080. Pawel Suder will drive this patch
> to completion
> 
>- Neutron in-tree API reference (https://blueprints.launchpad.
> net/neutron/+spec/neutron-in-tree-api-ref). There are two remaining TODOs
> to complete this blueprint: https://bugs.launchpad.net/neutron/+bug/1752274
> and https://bugs.launchpad.net/neutron/+bug/1752275. We need volunteers for
> these two work items
> 
>- Add TCP/UDP port forwarding extension to L3. The spec was merged
> recently: https://specs.openstack.org/openstack/neutron-specs/specs/qu
> eens/port-forwarding.html. Implementation effort is in progress:
> https://review.openstack.org/#/c/533850/ and  https://review.openstack.org/#
> /c/535647/
> 
>- Pure Python driven Linux network configuration (
> https://bugs.launchpad.net/neutron/+bug/1492714). This effort has been
> going on for several cycles gradually adopting pyroute2. Slawek Kaplonski
> is continuing it with https://review.openstack.org/#/c/545355 and
> https://review.openstack.org/#/c/548267
> 
> 
> Port behind port API proposal
> ==
> 
> * Omer Anson proposed to extend the Trunk Port API to generalize the
> support for port behind port use cases such as containers nested as
> MACVLANs within a VM or HA proxy port behind amphora VM port:
> https://bugs.launchpad.net/bugs/1730845
> 
>- After discussing the proposed use cases, the agreement 

Re: [openstack-dev] [cinder] [oslo] cinder.conf generation is broken for my_ip, building non-reproducibly

[Jay S Bryant]

Thomas,

Thanks for finding this.  I have opened a bug and submitted a patch.

Patch:  https://review.openstack.org/552134

Bug:  https://bugs.launchpad.net/cinder/+bug/1755282

Jay

(jungleboyj)


On 3/12/2018 3:17 AM, Thomas Goirand wrote:

Hi,

When inspecting Cinder's (Queens release) cinder.conf, I can see:

# Warning: Failed to format sample for my_ip
# unhashable type: 'HostAddress'

So it seems there's an issue in either Cinder or Oslo. How can I
investigate and fix this?

It's very likely that I'm once more the only person in the OpenStack
community that is really checking config file generation (it used to be
like that for past releases), and therefore the only one who noticed it.

Also, looking at the code, this seems to be yet-another-instance of
"package cannot be built reproducible" [1] with the build host config
leaking in the configuration (well, once that's fixed...). Indeed, in
the code I can read:

 cfg.HostAddressOpt('my_ip',
default=netutils.get_my_ipv4(),
help='IP address of this host'),

This means that, when that's repaired, build Cinder will write something
like this:

#my_ip = 1.2.3.4

With 1.2.3.4 being the value of netutils.get_my_ipv4(). This is easily
fixed by adding something like this:

sample-default=''

I'm writing this here for Cinder, but there's been numerous cases like
this already. The most common mistake being the hostname of the build
host leaking in the configuration. While this is easily fixed at the
packaging level fixing the config file after generating it with
oslo.config, often that config file is also built with the sphinx doc,
and then that file isn't built reproducibly. That's harder to detect,
and easier fixed upstream.

Cheers,

Thomas Goirand (zigo)

[1] https://reproducible-builds.org/

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



__
OpenStack Development Mailing List (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] [manila] [summit] Forum topic proposal etherpad

[Tom Barron]

Please add proposed topics for manila to this etherpad [1] for the 
Vancouver Forum.  In a couple weeks we'll use this list to submit 
abstracts for the next stage of the process [2]


As a reminder, the Forum is the part of the Summit conference 
dedicated to open discourse among operators, developers, users -- all 
who have a vested interest in design and planning of the future of
OpenStack [3]. I've added a few topics to prime the pump.   



[1] https://etherpad.openstack.org/p/YVR-manila-brainstorming
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/127944.html

[3] quoting 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128180.html



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

Re: [openstack-dev] [TripleO] Proposal for quickstart devmode replacement

[Wesley Hayutin]

On Mon, Mar 12, 2018 at 2:18 PM, Gabriele Cerami  wrote:

> Hi,
>
> we recently changed our set of scripts to uniform the users workflow
> with the CI workflow.
> One of the results of this change was the reproducer script, that is now
> the official way to spawn a live environment to debug a set of changes.
> One of the negative results of this changes was the deprecation of
> devmode. How to spawn a live environment with no set of changes as a
> base ?
> We are trying to fill this gap with this proposal
>
> https://review.openstack.org/548005
>
> The well-known quickstart.sh script called with the proper set of
> arguments will use the reproducer script, but with a set of option that
> will not actually use any upstream change to test.
>
> For example, the command
>
> quickstart.sh --generate-reproducer --jobtype 
> ovb-1ctlr_1comp_1ceph-featureset024
> --credentials-file myrdocreds.sh
>
> Will spawn a live environment with the exact set of features described
> in the job periodic-tripleo-ci-ovb-1ctlr_1comp_1ceph-featureset024
>
> Other combinations that don't follow upstream jobs configurations are
> possible by modifying environment variables, but are not our primary
> focus at the moment.
>
> We are trying to gather as much feedback as possible to make this
> proposal a worthy successor of the devmode script, so please point out
> what of the old functionality you think is missing, and what new would
> you really like to see in it.
>
> Thanks.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Many folks in the community have requested this feature, so looking for
feedback please.

Basically it's taking the tooling found in
http://tripleo.org/contributor/reproduce-ci.html
and allowing you to create a plain old vanilla deployment for your
development.

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

Re: [openstack-dev] [quotas] [cyborg]Dublin Rocky PTG Summary

[Tom Barron]

Just a remark below w.r.t. quota support in some other projects fwiw.

On 09/03/18 15:46 +0800, Zhipeng Huang wrote:

Hi Team,

Thanks to our topic leads' efforts, below is the aggregated summary from
our dublin ptg session discussion. Please check it out and feel free to
feedback any concerns you might have.



< -- snip -- >


Quota and Multi-tenancy Support
Etherpad: https://etherpad.openstack.org/p/cyborg-ptg-rocky-quota
Slide:
https://docs.google.com/presentation/d/1DUKWW2vgqUI3Udl4UDvxgJ53Ve5LmyaBpX4u--rVrCc/edit?usp=sharing

1. Provide project and user level quota support
2. Treat all resources as the reserved resource type
3. Add quota engine and quota driver for the quota support
4. Tables: quotas, quota_usage, reservation
5. Transactions operation: reserve, commit, rollback

  - Concerns on rollback


  - Implement a two-stage resevation and rollback


  - reserve - commit - rollback (if failed)



Note that cinder and manila followed the nova implementation of a two-stage
reservation/commit/rollback model but the resulting system has been buggy.
Over time, the quota system's notion of resource usage gets out of sync with
actual resource usage.

Nova has since dropped the reserve/commit/rollback model [0] and cinder and
manila are considering making a similar change.

Currently we create reservation records and update quota usage in
the API service and then remove the reservation records and update
quota usage in another service at commit or rollback time, or on reservation
timeout. Nova now avoids the double bookkeeping of resource usage and 
the need to update these records correctly across separate services by 
directly checking resource counts in the api at the time requests are 
received. If we can do the same thing in cinder and manila a whole 
class of tough, recurrent bugs can be eliminated.


The main concern expressed thus far with this "resource counting"
approach is that there may be some negative performance impact since
the current approach provides cached usage information to the api
service.  As you can see here [1] there probably is not yet agreement on the
degree of performance impact but there does seem to be agreement that we need
first to get a quota system that is correct and reliable, then 
optimize for performance as needed.


Best regards,

-- Tom Barron

[0] 
https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/cells-count-resources-to-check-quota-in-api.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128108.html


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

[openstack-dev] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)


Weekly priorities
-
- Rocky Priorities - https://review.openstack.org/#/c/550174/
- Remaining Rescue patches
- https://review.openstack.org/#/c/546919/ - Fix a bug for unrescuing with 
whole disk image
- https://review.openstack.org/#/c/524118/  - Devstack changes to enable 
testing add support for rescue mode
- https://review.openstack.org/#/c/538119/ - Rescue mode standalone tests
- BIOS interface specification
- https://review.openstack.org/#/c/496481/

Old priorities list that needs to be reconciled
--
- Fix the multitenant grenade - https://bugs.launchpad.net/ironic/+bug/1744139 
- Testing another possibility
- Disable .pyc file creation https://review.openstack.org/544750 MERGED
- Avoids library incompatibility issue by disabling .pyc files from 
being written to disk in the scenario.
- backport to stable/queens: https://review.openstack.org/#/c/545089/ 
MERGED
- The nova issue noted under critical bugs is also needed to make 
multitenant grenade reliable again.
- Required Backports/Nice to haves below
- CRITICAL bugs (must be fixed and backported to queens before the release)
- Nova
- Placement has issues after upgrade if ironic is unreachable for too 
long - Current WIP: https://review.openstack.org/#/c/545479/
- https://bugs.launchpad.net/nova/+bug/1750450

Required Queens Backports
-
- detached VIF reappearing: https://bugs.launchpad.net/ironic/+bug/1750785
- workaround: https://review.openstack.org/546584 abandoned
- decided to revert the original patch: https://review.openstack.org/546705 
MERGED
- backport to stable/queens: https://review.openstack.org/546719 
APPROVED

Nice to have backports
--
- Ansible docs - https://review.openstack.org/#/c/525501/ MERGED
- backport https://review.openstack.org/#/c/546079/ MERGED
- inspector: do not try passing non-MACs as switch_id: 
https://review.openstack.org/542214 APPROVED
- stable/queens - https://review.openstack.org/543961 MERGED
- Fix for CLEANING on conductor restart: https://review.openstack.org/349971 
MERGED
- backport: https://review.openstack.org/#/c/545893/ MERGED
- Reset reservations on take over: https://review.openstack.org/546273

Vendor priorities
-
cisco-ucs:
Patches in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:
RFE and first several patches for adding UEFI support will be posted by 
Tuesday, 1/9
ilo:
https://review.openstack.org/#/c/530838/ - OOB Raid spec for iLO5
irmc:
https://review.openstack.org/#/c/543883/ - rescue support for 
irmc-virtual-media boot

oneview:

Subproject priorities
-
bifrost:

ironic-inspector (or its client):

networking-baremetal:

networking-generic-switch:

sushy and the redfish driver:


Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between  19 Feb 2018 and 12 Mar 2018)
- Ironic: 211 bugs (+3) + 248 wishlist items (+5). 5 new (+2), 152 in progress 
(-3), 1 critical, 33 high and 24 incomplete (+1)
- Inspector: 14 bugs (+1) + 26 wishlist items. 0 new, 14 in progress (+2), 0 
critical, 3 high (+1) and 4 incomplete
- Nova bugs with Ironic tag: 15 (-1). 1 new (-1), 0 critical, 0 high
- via http://dashboard-ironic.7e14.starter-us-west-2.openshiftapps.com/
- the dashboard was abruptly deleted and needs a new home :(
- use it locally with `tox -erun` if you need to
- critical:
- sushy: https://bugs.launchpad.net/sushy/+bug/1754514 (basic auth broken 
when SessionService is not present)
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Needs to be reproposed to the ironic tempest plugin repository.
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- (TheJulia) Currently WF-1, as revision is required for deprecation.

CI refactoring and missing test coverage

- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- localboot with partitioned image patches:
- Ironic - add localboot partitioned image test: 

[openstack-dev] [neutron] Bug deputy report

[Brian Haley]

Hi,

I was Neutron bug deputy last week. Below is a short summary about 
reported bugs.



Critical bugs
-
None

High bugs
-

* https://bugs.launchpad.net/bugs/1753504 - Remove mox/mox3 usage from 
testing

Multiple people have taken ownership of fixing this

* https://bugs.launchpad.net/bugs/1754062 - openstack client does not 
pass prefixlen when creating subnet

Looks like both a bug in the api-ref and in the openstacksdk

* https://bugs.launchpad.net/bugs/1754327 - Tempest scenario jobs 
failing due to no FIP connectivity

https://review.openstack.org/#/c/550832/ proposed to try and track
down reason for failure (thanks Slawek!)

* https://bugs.launchpad.net/bugs/1755243 - AttributeError when updating 
DvrEdgeRouter objects running on network nodes

Bug submitter has already posted a patch

* https://bugs.launchpad.net/bugs/1754563 - Arp_responder function has 
failed since Ocata

Looks like there is maybe a missing setup_privsep() call in the L2
agent code?  Yes, and Slawek just fixed it in master, so we'll need
to backport just the change in one file.  haleyb pushed a change.

Medium bugs
---

* https://bugs.launchpad.net/bugs/1753540 - When isolated/force metadata 
is enabled, metadata proxy doesn't get automatically started/stopped 
when needed

Daniel Alvarez sent patch for master and backports (thanks!)

* https://bugs.launchpad.net/bugs/1754770 - Duplicate iptables rule 
detected in Linuxbridge agent logs

Slawek took ownership as messages started after another change

Low bugs


* https://bugs.launchpad.net/bugs/1753384 - The old QoS policy ID is 
returned when updating the QoS policy ID, when the revision plugin is 
enabled

Guoshuai Li took ownership

Bugs that need further triage
-

* https://bugs.launchpad.net/bugs/1753434 - Unbound ports floating ip 
not working with address scopes in DVR HA

Found on Pike, need to determine if already fixed in master

* https://bugs.launchpad.net/bugs/1754695 - Incorrect state of the 
Openflow table

Restarting neutron_openvswitch_agent container fixed issue

* https://bugs.launchpad.net/bugs/1754600 - the detail for openstack 
quota show is not supported
Probably duplicate of 
https://bugs.launchpad.net/neutron/+bug/1716043 since that was opened to 
track CLI quota change


RFE bugs for drivers team
-

* https://bugs.launchpad.net/bugs/1753466 - [RFE] Support stateless 
security groups


* https://bugs.launchpad.net/bugs/1754123 - [RFE] Support filter with 
floating IP address substring



Thanks,
-Brian

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

[openstack-dev] [TripleO] Proposal for quickstart devmode replacement

[Gabriele Cerami]

Hi,

we recently changed our set of scripts to uniform the users workflow
with the CI workflow.
One of the results of this change was the reproducer script, that is now
the official way to spawn a live environment to debug a set of changes.
One of the negative results of this changes was the deprecation of
devmode. How to spawn a live environment with no set of changes as a
base ?
We are trying to fill this gap with this proposal

https://review.openstack.org/548005

The well-known quickstart.sh script called with the proper set of
arguments will use the reproducer script, but with a set of option that
will not actually use any upstream change to test.

For example, the command

quickstart.sh --generate-reproducer --jobtype 
ovb-1ctlr_1comp_1ceph-featureset024 --credentials-file myrdocreds.sh

Will spawn a live environment with the exact set of features described
in the job periodic-tripleo-ci-ovb-1ctlr_1comp_1ceph-featureset024

Other combinations that don't follow upstream jobs configurations are
possible by modifying environment variables, but are not our primary
focus at the moment.

We are trying to gather as much feedback as possible to make this
proposal a worthy successor of the devmode script, so please point out
what of the old functionality you think is missing, and what new would
you really like to see in it.

Thanks.

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

Re: [openstack-dev] [cinder][summit] Forum topic proposal etherpad created ...

[Jeremy Stanley]

On 2018-03-12 13:46:30 -0300 (-0300), Erlon Cruz wrote:
> I think I missed something about this. By Forum you mean Summit?  Will that
> happen during the Vancouver Summit right? Will the forum be something
> similar to PTG? What is the target public? Operators, users admin?

Yes, the Forum takes place at the Summit conference. It is the term
we've been using for open discourse replacing the planning activity
which went on at the "Design Summit" before we split out the Project
Team Gathering as a separate event. See
https://wiki.openstack.org/wiki/Forum for a more in-depth
description, but it's targeted at all who have a vested interest in
design and planning for the future of OpenStack
(devsopsusersadminseveryone).
-- 
Jeremy Stanley


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

Re: [openstack-dev] [keystone] [oslo] new unified limit library

[Ben Nemec]

Huge +1 from me on bringing sanity to the various quota implementations 
in OpenStack.  This is something we discussed back in Paris, but the 
conclusion at the time was that it wasn't practical for it to live in 
Oslo because there was no place for Oslo to store the data (Oslo libs 
dictating db schemas to consuming projects would get messy fast).  Now 
that Keystone is providing a central storage location we should be able 
to make more progress.


On 03/12/2018 11:45 AM, Lance Bragstad wrote:

I missed the document describing the process for this sort of thing [0].
So I'm back tracking a bit to go through a more formal process.

[0]
http://specs.openstack.org/openstack/oslo-specs/specs/policy/new-libraries.html

# Proposed new library oslo.limit

This is a proposal to create a new library dedicated to enabling more
consistent quota and limit enforcement across OpenStack.

## Proposed library mission

Enforcing quotas and limits across OpenStack has traditionally been a
tough problem to solve. Determining enforcement requires quota knowledge
from the service along with information about the project owning the
resource. Up until the Queens release, quota calculation and enforcement
has been left to the services to implement, forcing them to understand
complexities of keystone project structure. During the Pike and Queens
PTG, there were several productive discussions towards redesigning the
current approach to quota enforcement. Because keystone is the authority
of project structure, it makes sense to allow keystone to hold the
association between a resource limit and a project. This means services
still need to calculate quota and usage, but the problem should be
easier for services to implement since developers shouldn't need to
re-implement possible hierarchies of projects and their associated
limits. Instead, we can offload some of that work to a common library
for services to consume that handles enforcing quota calculation based
on limits associated to projects in keystone. This proposal is to have a
new library called oslo.limit that fills that need.

## Consuming projects

The services consuming this work will be any service that currently
implements a quota system, or plans to implement one. Since keystone
already supports unified limits and association of limits to projects,
the implementation for consuming projects is easier. instead of having
to re-write that implementation, developers need to ensure quota
calculation to passed to the oslo.limit library somewhere in the API's
validation layer. The pattern described here is very similar to the
pattern currently used by services that leverage oslo.policy for
authorization decisions.

## Alternative libraries

It looks like there was an existing library that attempted to solve some
of these problems, called delimiter [1]. It looks like delimiter could
be used to talk to keystone about quota enforcement, where as the
existing approach with oslo.limit would be to use keystone directly.
Someone more familiar with the library (harlowja?) can probably shed
more light on it's intended uses (I couldn't find much documentation),
but the presentation linked in a previous note was helpful.

[1] https://github.com/openstack/delimiter


I took a look at delimiter as well.  There are a couple of points that I 
think justify a new library:


1) Delimiter appears to implement a pluggable backend strategy, which 
isn't what we're planning for oslo.limit.  We'll only be targeting 
Keystone as the storage backend.


2) Given that, it makes sense for the library to live in the oslo 
namespace.  Projects like Delimiter that live outside the oslo namespace 
are generally supposed to be usable without OpenStack, but a hard 
dependency on Keystone makes that impossible.  Given that we aren't 
overstocked with developers these days, I'd rather not try to solve 
quota problems for the whole world.  If at some point we get oslo.limit 
to a good place and can factor some bits out to delimiter then great, 
but I'd rather solve quota for just OpenStack first at this point.


3) It doesn't look like delimiter ever got to the point where it had 
adoption in OpenStack.  It isn't present in global-requirements that I 
can see and it's not clear to me from looking at the repo whether it 
even could be used in its current state.  In the end I think it might be 
just as much work to get delimiter to a point where it could be used and 
we'd still be left with some less-than-ideal design points.




## Proposed adoption model/plan

The unified limit API [2] in keystone is currently marked as
experimental, but the keystone team is actively collecting and
addressing feedback that will result in stabilizing the API.
Stabilization changes that effect the oslo.limit library will also be
addressed before version 1.0.0 is released. From there, we can look to
incorporate the library into various services that either have an
existing quota implementation, or services that have a quota 

Re: [openstack-dev] [kolla][vote] core nomination for caoyuan

[Steven Dake (stdake)]

+1

From: Jeffrey Zhang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Sunday, March 11, 2018 at 7:13 PM
To: OpenStack Development Mailing List 
Subject: Re: [openstack-dev] [kolla][vote] core nomination for caoyuan

sorry for a typo.

The vote is open for 7 days until Mar 19th.

On Mon, Mar 12, 2018 at 10:06 AM, Jeffrey Zhang 
> wrote:
​​Kolla core reviewer team,

It is my pleasure to nominate caoyuan for kolla core team.

caoyuan's output is fantastic over the last cycle. And he is the most
active non-core contributor on Kolla project for last 180 days[1]. He
focuses on configuration optimize and improve the pre-checks feature.

Consider this nomination a +1 vote from me.

A +1 vote indicates you are in favor of caoyuan as a candidate, a -1
is a veto. Voting is open for 7 days until Mar 12th, or a unanimous
response is reached or a veto vote occurs.

[1] http://stackalytics.com/report/contribution/kolla-group/180
--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me



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

Re: [openstack-dev] [cinder][ptg] PTG Summary Now Available ...

[Erlon Cruz]

Thanks Jay, that helps a lot!

2018-03-06 18:46 GMT-03:00 Ivan Kolodyazhny :

> Jay, thanks a lot for this great summary!
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Tue, Mar 6, 2018 at 10:02 PM, Jay S Bryant 
> wrote:
>
>> Team,
>>
>> I have collected all of our actions and agreements out of the three days
>> of etherpads into the following summary page:  [1] . The etherpad includes
>> links to the original etherpads and video clips.
>>
>> I am planning to use the wiki to help guide our development during Rocky.
>>
>> Let me know if you have any questions or concerns over the content.
>>
>> Thanks!
>>
>> Jay
>>
>> (jungleboyj)
>>
>> [1] https://wiki.openstack.org/wiki/CinderRockyPTGSummary
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][summit] Forum topic proposal etherpad created ...

[Erlon Cruz]

I think I missed something about this. By Forum you mean Summit?  Will that
happen during the Vancouver Summit right? Will the forum be something
similar to PTG? What is the target public? Operators, users admin?

Erlon

2018-03-08 14:52 GMT-03:00 Jay S Bryant :

> All,
>
> I just wanted to share the fact that I have created the etherpad for
> proposing topics for the Vancouver Forum.  [1]
>
> Please take a few moments to add topics there.  I will need to propose the
> topics we have in the next two weeks so this will need attention before
> that point in time.
>
> Thanks!
>
> Jay
>
> (jungleboyj)
>
> [1] https://etherpad.openstack.org/p/YVR-cinder-brainstorming
>
>
> __
> OpenStack Development Mailing List (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] [keystone] [oslo] new unified limit library

[Lance Bragstad]

I missed the document describing the process for this sort of thing [0].
So I'm back tracking a bit to go through a more formal process.

[0]
http://specs.openstack.org/openstack/oslo-specs/specs/policy/new-libraries.html

# Proposed new library oslo.limit

This is a proposal to create a new library dedicated to enabling more
consistent quota and limit enforcement across OpenStack.

## Proposed library mission

Enforcing quotas and limits across OpenStack has traditionally been a
tough problem to solve. Determining enforcement requires quota knowledge
from the service along with information about the project owning the
resource. Up until the Queens release, quota calculation and enforcement
has been left to the services to implement, forcing them to understand
complexities of keystone project structure. During the Pike and Queens
PTG, there were several productive discussions towards redesigning the
current approach to quota enforcement. Because keystone is the authority
of project structure, it makes sense to allow keystone to hold the
association between a resource limit and a project. This means services
still need to calculate quota and usage, but the problem should be
easier for services to implement since developers shouldn't need to
re-implement possible hierarchies of projects and their associated
limits. Instead, we can offload some of that work to a common library
for services to consume that handles enforcing quota calculation based
on limits associated to projects in keystone. This proposal is to have a
new library called oslo.limit that fills that need.

## Consuming projects

The services consuming this work will be any service that currently
implements a quota system, or plans to implement one. Since keystone
already supports unified limits and association of limits to projects,
the implementation for consuming projects is easier. instead of having
to re-write that implementation, developers need to ensure quota
calculation to passed to the oslo.limit library somewhere in the API's
validation layer. The pattern described here is very similar to the
pattern currently used by services that leverage oslo.policy for
authorization decisions.

## Alternative libraries

It looks like there was an existing library that attempted to solve some
of these problems, called delimiter [1]. It looks like delimiter could
be used to talk to keystone about quota enforcement, where as the
existing approach with oslo.limit would be to use keystone directly.
Someone more familiar with the library (harlowja?) can probably shed
more light on it's intended uses (I couldn't find much documentation),
but the presentation linked in a previous note was helpful.

[1] https://github.com/openstack/delimiter

## Proposed adoption model/plan

The unified limit API [2] in keystone is currently marked as
experimental, but the keystone team is actively collecting and
addressing feedback that will result in stabilizing the API.
Stabilization changes that effect the oslo.limit library will also be
addressed before version 1.0.0 is released. From there, we can look to
incorporate the library into various services that either have an
existing quota implementation, or services that have a quota requirement
but no implementation.

This should help us refine the interfaces between services and
oslo.limit, while providing a facade to handle complexities of project
hierarchies. This should enable adoption by simplifying the process and
making it easier for quota to be implemented in a consistent way across
services.

[2]
https://docs.openstack.org/keystone/latest/admin/identity-unified-limits.html

## Reviewer activity

At first thought, it makes sense to model the reviewer structure after
the oslo.policy library, where the core team consists of people not only
interested in limits and quota, but also people familiar with the
keystone implementation of the unified limits API.

## Implementation

### Primary Authors:

  Lance Bragstad (lbrags...@gmail.com) lbragstad
  You?

### Other contributors:

  You?

## Work Items

* Create a new library called oslo.limit
* Create a core group for the project
* Define the minimum we need to enforce quota calculations in oslo.limit
* Propose an implementation that allows services to test out quota
enforcement via unified limits

## References

Rocky PTG Etherpad for unified limits:
https://etherpad.openstack.org/p/unified-limits-rocky-ptg

## Revision History

Introduced in Rocky


On 03/07/2018 11:55 PM, Joshua Harlow wrote:
> So the following was a prior effort:
>
> https://github.com/openstack/delimiter
>
> Maybe just continue down the path of that and/or take that whole repo
> over and iterate (or adjust the prior code, or ...)?? Or if not that's
> ok to, ya'll get to decide.
>
> https://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal
>
>
> Lance Bragstad wrote:
>> Hi all,
>>
>> Per the identity-integration track at the PTG [0], I proposed a new oslo
>> 

[openstack-dev] [Neutron] [FWaaS] Stateless Security Groups or Firewalls Discussion

[Nikolai de Figueiredo]

Hi all

I have just discovered an RFE [1] that was submitted on the 5th of March (a
few days ago) proposing an extension to Neutron and specifically security
groups to enable stateless filtering. The topic of stateless firewalls was
discussed at the Rocky PTG with the FWaaS sub-team but we didn't discuss
the feature from the perspective of security groups [2].

>From the sound of the RFE Nokia is volunteering resources to implement this
extension for similar reasons as were discussed by the firewall team. I
would like to firstly bring this to the attention of the team and secondly
begin the discussions around the inevitable need for a specification.

My initial question is as in the subject line: should this be a security
group extension or a firewall extension or both?

Further discussion may continue in the shared Google document [3].

Regards
Nikolai

[1] https://bugs.launchpad.net/neutron/+bug/1753466
[2] https://etherpad.openstack.org/p/fwaas-rocky-planning
[3] https://docs.google.com/document/d/1pWU5wSIlba7oixpKT8CS
xpJnFCJt8zJj18c-mVE9uUM/edit?usp=sharing
-- 
*Nikolai de Figueiredo*
*Software Engineer*

*Netronome* | Unit 7, Corporate Corner, 2 Marco Polo St, Centurion, 0157
Phone: +27 12 665 4427 <+27%2012%20665%204427> | Skype: live:sphvengaurd |
www.netronome.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara][all] Sahara Rocky Virtual PTG scheduling

[Telles Nobrega]

Thanks for putting this together Jeremy.

On Mon, Mar 12, 2018 at 12:44 PM Jeremy Freudberg 
wrote:

> Hi all,
>
> Due to my unexpected absence from Dublin we have decided that a
> virtual PTG is a good idea. Let's try to find 90-120 minutes somewhere
> in our busy schedules to convene remotely.
>
> https://www.when2meet.com/?6755109-XpWjd
>
> Please use the poll linked above to choose some times which work for
> you. I've already started it with times that potentially work for me,
> but I can become even more flexible if needed.
>
> (Be warned that the poll site is a bit glitchy... make sure that you
> are seeing the right times. Whatever time zone you are viewing it in
> should show the first slot on Monday as equivalent to 1300 UTC. Also
> be warned that depending on what time zone you are viewing in, the
> date may "roll over" mid-column.)
>
> All interested parties are welcome.
>
> We will decide the exact medium of communication based on what media
> the confirmed participants are able to use. In any case the outcomes
> will be logged to the mailing list.
>
> Best,
> Jeremy
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat Brasil  

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
 Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo Great Place to Work.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara] PTG Summary

[Jeremy Freudberg]

Thanks Luigi and Telles for striving to work hard, even in my absence. :)
Some notes inline.

On Mon, Mar 12, 2018 at 10:39 AM, Telles Nobrega 
wrote:

> Hello Saharans and interested folks,
>
> This PTG was a very interesting experience, for those not familiar with
> what happened there, here goes a quick summary.
>
> The event became known as SnowOpenStack PTG due to some snow that got in
> the way of event. But that didn't get in the way of determined people that
> wanted to do good work anyways.
> This PTG for Sahara was different, we only had 2 people present so a few
> topics couldn't be fully discussed.
>
> We started our week as Sahara joining the Storyboard room in order to
> understand better their status and what are the needed steps for us to
> migrate from launchpad to storyboard.
> The outcome of that meeting was better than expected. There are only a few
> things needed from our side to fully migrate. Tosky got ahead on this and
> already updated the migration script to support sahara and other projects
> needs and tested the migration with success. Now we only need to wait on
> the storyboard team to test it as well and then we need to document that we
> are migrating to storyboard.
> Action item on this for all involved in the project: Take some time to
> read on Storyboard and get familiar with it.
>
> Than we started Sahara meetings:
>
> We started with the traditional retrospective, we looked over the work
> list from Queens, marking them with Done, Partially Done and Unstarted.
> Please all take a look at that and let me know if anything not prioritized
> from that list is necessary.
>
> Now to specific discussion topics.
>
> Plugins upgrades, deprecation and removals
> 
>
> CDH:
>
>- Upgrade to 5.12, 5.13 and 5.14
>- Deprecate 5.7, 5.9 if we are able to upgrade all three version or
>two of them
>- Remove 5.5.0
>
> MapR:
>
>- Upgrade to 6.0 and update latest packages for 5.2
>
> Looks like MapR 6 offers some new management services which we should
acknowledge and add.

>
>-
>- Remove all references to 5.1
>
> Ambari:
>
>- Upgrade Ambari to 2.6 and HDP to 2.6 as well
>- Use the Ambari 2.6 image with both HDP 2.6 and 2.5 and 2.4
>- Deprecate HDP version 2.3 and work the removal of ambari 2.4 for S
>
> Spark:
>
>- Upgrade to 2.3.0 and check 2.2.1 as subversion as 2.2.0
>- Deprecate 1.6, 2.1 (see move out of trusty discussion)
>- Remove 1.3
>
> Storm:
>
>- Upgrade to 1.2.1 and 1.2.0 (under the same tag 1.2)
>- Deprecate 1.0.1
>- Remove 0.9.2
>
> Vanilla:
>
>- Upgrade to vanilla 3.0.0 and check if we can add 2.7.5
>
> 2.7.5 seems much lower priority to me. Even 2.8.3 or the eventual 2.8.4
seems more important. But I'm not sure.


>
> Sahara CI
> -
> We are still facing issues with our third-party CI. We plan to have
> nightly jobs running each day for a plugin so we won't need too much
> resources, that seems possible with zuulv3.
> Also there is an issue with experimental queue, now we run all
> experimental jobs even when not necessary, we plan to split this in
> separate queues so we can run specific tests.
>

It looks like the wheels of progress are starting to turn on my end...


>
> Python 3 support
> ---
> Python 2 support is closing and we need to fully migrate to Python 3.
> Right now we have unit tests in place, tempest should be easily resolved;
> Scenarios jobs are there but failing with swift issues. Once we have all of
> those we will have a better grasp of what we need to do and how much work
> will be. In any case, we need to get a jump on these soon.
>
> SSL/TLS everywhere
> 
> We need to check our status of secure communication with other projects as
> well as between Sahara and its clusters. Right now Sahara should be able to
> communicate with CDH using SSL but it is hard coded and we need to change
> that and test how it goes. Also we need to check certificate management.
> For Ambari, CA is generated but not reconized on RHEL/CentOS>=7.4, we need
> to make sure this works.
>
> Move out of trusty
> 
> Trusty support will be dropped soon and we need to make sure we don't have
> any dependencies on our side. For that we need to work on removing plugins
> versions that are only supported on trusty.
>
> Plugins outside Sahara
> ---
> After discussion with Doug Hellman, seems like we have a good plan to have
> this finally done. The goal is the have a new project (sahara-plugins) that
> will require stuff from sahara and sahara itself will load plugins from
> sahara-plugins project dinamically with stevedore, this way we don't have a
> circular dependency.
> The bulk of the work is done, spec should be on its way soon.
>

+1


>

> APIv2
> 
> We have it available as experimental, but we miss CLI, tempest 

Re: [openstack-dev] [oslo] Oslo PTG Summary

[Doug Hellmann]

I can’t see 

https://docs.google.com/presentation/d/e/2PACX-1vQpaSSm7Amk9q4sBEAUi_IpyJ4l07qd3t5T_BPZkdLWfYbtSpSmF7obSB1qRGA65wjiiq2Sb7H2ylJo/pub?start=false=false=3000=id.p
 




> On Mar 12, 2018, at 11:39 AM, Ken Giusti  wrote:
> 
> Hi Josh - I'm able to view all of them, but I probably have special
> google powers ;)
> 
> Which links are broken for you?
> 
> thanks,
> 
> On Thu, Mar 8, 2018 at 3:53 PM, Joshua Harlow  wrote:
>> 
>> Can we get some of those doc links opened.
>> 
>> 'You need permission to access this published document.' I am getting for a
>> few of them :(
>> 
>> 
>> Ben Nemec wrote:
>>> 
>>> Hi,
>>> 
>>> Here's my summary of the discussions we had in the Oslo room at the PTG.
>>> Please feel free to reply with any additions if I missed something or
>>> correct anything I've misrepresented.
>>> 
>>> oslo.config drivers for secret management
>>> -
>>> 
>>> The oslo.config implementation is in progress, while the Castellan
>>> driver still needs to be written. We want to land this early in Rocky as
>>> it is a significant change in architecture for oslo.config and we want
>>> it to be well-exercised before release.
>>> 
>>> There are discussions with the TripleO team around adding support for
>>> this feature to its deployment tooling and there will be a functional
>>> test job for the Castellan driver with Custodia.
>>> 
>>> There is a weekly meeting in #openstack-meeting-3 on Tuesdays at 1600
>>> UTC for discussion of this feature.
>>> 
>>> oslo.config driver implementation: https://review.openstack.org/#/c/513844
>>> spec:
>>> 
>>> https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
>>> 
>>> Custodia key management support for Castellan:
>>> https://review.openstack.org/#/c/515190/
>>> 
>>> "stable" libraries
>>> --
>>> 
>>> Some of the Oslo libraries are in a mature state where there are very
>>> few, if any, meaningful changes to them. With the removal of the
>>> requirements sync process in Rocky, we may need to change the release
>>> process for these libraries. My understanding was that there were no
>>> immediate action items for this, but it was something we need to be
>>> aware of.
>>> 
>>> dropping support for mox3
>>> -
>>> 
>>> There was some concern that no one from the Oslo team is actually in a
>>> position to support mox3 if something were to break (such as happened in
>>> some libraries with Python 3.6). Since there is a community goal to
>>> remove mox from all OpenStack projects in Rocky this will hopefully not
>>> be a long-term problem, but there was some discussion that if projects
>>> needed to keep mox for some reason that they would be asked to provide a
>>> maintainer for mox3. This topic is kind of on hold pending the outcome
>>> of the community goal this cycle.
>>> 
>>> automatic configuration migration on upgrade
>>> 
>>> 
>>> There is a desire for oslo.config to provide a mechanism to
>>> automatically migrate deprecated options to their new location on
>>> version upgrades. This is a fairly complex topic that I can't cover
>>> adequately in a summary email, but there is a spec proposed at
>>> https://review.openstack.org/#/c/520043/ and POC changes at
>>> https://review.openstack.org/#/c/526314/ and
>>> https://review.openstack.org/#/c/526261/
>>> 
>>> One outcome of the discussion was that in the initial version we would
>>> not try to handle complex migrations, such as the one that happened when
>>> we combined all of the separate rabbit connection opts into a single
>>> connection string. To start with we will just raise a warning to the
>>> user that they need to handle those manually, but a templated or
>>> hook-based method of automating those migrations could be added as a
>>> follow-up if there is sufficient demand.
>>> 
>>> oslo.messaging plans
>>> 
>>> 
>>> There was quite a bit discussed under this topic. I'm going to break it
>>> down into sub-topics for clarity.
>>> 
>>> oslo.messaging heartbeats
>>> =
>>> 
>>> Everyone seemed to be in favor of this feature, so we anticipate
>>> development moving forward in Rocky. There is an initial patch proposed
>>> at https://review.openstack.org/546763
>>> 
>>> We felt that it should be possible to opt in and out of the feature, and
>>> that the configuration should be done at the application level. This
>>> should _not_ be an operator decision as they do not have the knowledge
>>> to make it sanely.
>>> 
>>> There was also a desire to have a TTL for messages.
>>> 
>>> bug cleanup
>>> ===
>>> 
>>> There are quite a few launchpad bugs open against oslo.messaging that
>>> were reported against old, 

[openstack-dev] [sahara][all] Sahara Rocky Virtual PTG scheduling

[Jeremy Freudberg]

Hi all,

Due to my unexpected absence from Dublin we have decided that a
virtual PTG is a good idea. Let's try to find 90-120 minutes somewhere
in our busy schedules to convene remotely.

https://www.when2meet.com/?6755109-XpWjd

Please use the poll linked above to choose some times which work for
you. I've already started it with times that potentially work for me,
but I can become even more flexible if needed.

(Be warned that the poll site is a bit glitchy... make sure that you
are seeing the right times. Whatever time zone you are viewing it in
should show the first slot on Monday as equivalent to 1300 UTC. Also
be warned that depending on what time zone you are viewing in, the
date may "roll over" mid-column.)

All interested parties are welcome.

We will decide the exact medium of communication based on what media
the confirmed participants are able to use. In any case the outcomes
will be logged to the mailing list.

Best,
Jeremy

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

Re: [openstack-dev] [oslo] Oslo PTG Summary

[Ken Giusti]

Hi Josh - I'm able to view all of them, but I probably have special
google powers ;)

Which links are broken for you?

thanks,

On Thu, Mar 8, 2018 at 3:53 PM, Joshua Harlow  wrote:
>
> Can we get some of those doc links opened.
>
> 'You need permission to access this published document.' I am getting for a
> few of them :(
>
>
> Ben Nemec wrote:
>>
>> Hi,
>>
>> Here's my summary of the discussions we had in the Oslo room at the PTG.
>> Please feel free to reply with any additions if I missed something or
>> correct anything I've misrepresented.
>>
>> oslo.config drivers for secret management
>> -
>>
>> The oslo.config implementation is in progress, while the Castellan
>> driver still needs to be written. We want to land this early in Rocky as
>> it is a significant change in architecture for oslo.config and we want
>> it to be well-exercised before release.
>>
>> There are discussions with the TripleO team around adding support for
>> this feature to its deployment tooling and there will be a functional
>> test job for the Castellan driver with Custodia.
>>
>> There is a weekly meeting in #openstack-meeting-3 on Tuesdays at 1600
>> UTC for discussion of this feature.
>>
>> oslo.config driver implementation: https://review.openstack.org/#/c/513844
>> spec:
>>
>> https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
>>
>> Custodia key management support for Castellan:
>> https://review.openstack.org/#/c/515190/
>>
>> "stable" libraries
>> --
>>
>> Some of the Oslo libraries are in a mature state where there are very
>> few, if any, meaningful changes to them. With the removal of the
>> requirements sync process in Rocky, we may need to change the release
>> process for these libraries. My understanding was that there were no
>> immediate action items for this, but it was something we need to be
>> aware of.
>>
>> dropping support for mox3
>> -
>>
>> There was some concern that no one from the Oslo team is actually in a
>> position to support mox3 if something were to break (such as happened in
>> some libraries with Python 3.6). Since there is a community goal to
>> remove mox from all OpenStack projects in Rocky this will hopefully not
>> be a long-term problem, but there was some discussion that if projects
>> needed to keep mox for some reason that they would be asked to provide a
>> maintainer for mox3. This topic is kind of on hold pending the outcome
>> of the community goal this cycle.
>>
>> automatic configuration migration on upgrade
>> 
>>
>> There is a desire for oslo.config to provide a mechanism to
>> automatically migrate deprecated options to their new location on
>> version upgrades. This is a fairly complex topic that I can't cover
>> adequately in a summary email, but there is a spec proposed at
>> https://review.openstack.org/#/c/520043/ and POC changes at
>> https://review.openstack.org/#/c/526314/ and
>> https://review.openstack.org/#/c/526261/
>>
>> One outcome of the discussion was that in the initial version we would
>> not try to handle complex migrations, such as the one that happened when
>> we combined all of the separate rabbit connection opts into a single
>> connection string. To start with we will just raise a warning to the
>> user that they need to handle those manually, but a templated or
>> hook-based method of automating those migrations could be added as a
>> follow-up if there is sufficient demand.
>>
>> oslo.messaging plans
>> 
>>
>> There was quite a bit discussed under this topic. I'm going to break it
>> down into sub-topics for clarity.
>>
>> oslo.messaging heartbeats
>> =
>>
>> Everyone seemed to be in favor of this feature, so we anticipate
>> development moving forward in Rocky. There is an initial patch proposed
>> at https://review.openstack.org/546763
>>
>> We felt that it should be possible to opt in and out of the feature, and
>> that the configuration should be done at the application level. This
>> should _not_ be an operator decision as they do not have the knowledge
>> to make it sanely.
>>
>> There was also a desire to have a TTL for messages.
>>
>> bug cleanup
>> ===
>>
>> There are quite a few launchpad bugs open against oslo.messaging that
>> were reported against old, now unsupported versions. Since we have the
>> launchpad bug expirer enabled in Oslo the action item proposed for such
>> bugs was to mark them incomplete and ask the reporter to confirm that
>> they still occur against a supported version. This way bugs that don't
>> reproduce or where the reporter has lost interest will eventually be
>> closed automatically, but bugs that do still exist can be updated with
>> more current information.
>>
>> deprecations
>> 
>>
>> The Pika driver will be deprecated in Rocky. To our knowledge, no one
>> has 

[openstack-dev] [sahara] PTG Summary

[Telles Nobrega]

Hello Saharans and interested folks,

This PTG was a very interesting experience, for those not familiar with
what happened there, here goes a quick summary.

The event became known as SnowOpenStack PTG due to some snow that got in
the way of event. But that didn't get in the way of determined people that
wanted to do good work anyways.
This PTG for Sahara was different, we only had 2 people present so a few
topics couldn't be fully discussed.

We started our week as Sahara joining the Storyboard room in order to
understand better their status and what are the needed steps for us to
migrate from launchpad to storyboard.
The outcome of that meeting was better than expected. There are only a few
things needed from our side to fully migrate. Tosky got ahead on this and
already updated the migration script to support sahara and other projects
needs and tested the migration with success. Now we only need to wait on
the storyboard team to test it as well and then we need to document that we
are migrating to storyboard.
Action item on this for all involved in the project: Take some time to read
on Storyboard and get familiar with it.

Than we started Sahara meetings:

We started with the traditional retrospective, we looked over the work list
from Queens, marking them with Done, Partially Done and Unstarted.
Please all take a look at that and let me know if anything not prioritized
from that list is necessary.

Now to specific discussion topics.

Plugins upgrades, deprecation and removals


CDH:

   - Upgrade to 5.12, 5.13 and 5.14
   - Deprecate 5.7, 5.9 if we are able to upgrade all three version or two
   of them
   - Remove 5.5.0

MapR:

   - Upgrade to 6.0 and update latest packages for 5.2
   - Remove all references to 5.1

Ambari:

   - Upgrade Ambari to 2.6 and HDP to 2.6 as well
   - Use the Ambari 2.6 image with both HDP 2.6 and 2.5 and 2.4
   - Deprecate HDP version 2.3 and work the removal of ambari 2.4 for S

Spark:

   - Upgrade to 2.3.0 and check 2.2.1 as subversion as 2.2.0
   - Deprecate 1.6, 2.1 (see move out of trusty discussion)
   - Remove 1.3

Storm:

   - Upgrade to 1.2.1 and 1.2.0 (under the same tag 1.2)
   - Deprecate 1.0.1
   - Remove 0.9.2

Vanilla:

   - Upgrade to vanilla 3.0.0 and check if we can add 2.7.5


Sahara CI
-
We are still facing issues with our third-party CI. We plan to have nightly
jobs running each day for a plugin so we won't need too much resources,
that seems possible with zuulv3.
Also there is an issue with experimental queue, now we run all experimental
jobs even when not necessary, we plan to split this in separate queues so
we can run specific tests.

Python 3 support
---
Python 2 support is closing and we need to fully migrate to Python 3. Right
now we have unit tests in place, tempest should be easily resolved;
Scenarios jobs are there but failing with swift issues. Once we have all of
those we will have a better grasp of what we need to do and how much work
will be. In any case, we need to get a jump on these soon.

SSL/TLS everywhere

We need to check our status of secure communication with other projects as
well as between Sahara and its clusters. Right now Sahara should be able to
communicate with CDH using SSL but it is hard coded and we need to change
that and test how it goes. Also we need to check certificate management.
For Ambari, CA is generated but not reconized on RHEL/CentOS>=7.4, we need
to make sure this works.

Move out of trusty

Trusty support will be dropped soon and we need to make sure we don't have
any dependencies on our side. For that we need to work on removing plugins
versions that are only supported on trusty.

Plugins outside Sahara
---
After discussion with Doug Hellman, seems like we have a good plan to have
this finally done. The goal is the have a new project (sahara-plugins) that
will require stuff from sahara and sahara itself will load plugins from
sahara-plugins project dinamically with stevedore, this way we don't have a
circular dependency.
The bulk of the work is done, spec should be on its way soon.

APIv2

We have it available as experimental, but we miss CLI, tempest client,
tempest tests and scenarios tests.

Boot from volume
---
This spec has been standing there for a long time and we need to get this
done.

Bugs
---
Spark amount of resources:

   - We need to check if we can define on config file
   - Set the default to 50% of flavor capacity
   - If we can get this info from args we won't need to change much, just
   add some conditions to make sure we get this info and it makes into command
   line

File copy time out when file is too big:

   - Paramiko PUT is not the ideal solution because it will need to write
   file locally
   - Pipelined + buffer also proved an inefficient solution
   - We will test now 

Re: [openstack-dev] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

[Andrea Frittoli]

Dear all,

post-PTG updates:

- the devstack patches for multinode support are now merged on master. You
can now build your multinode zuulv3 native devstack/tempest test jobs using
the same base jobs as for single node, and setting a multinode nodeset.
Documentation landed as well, so you can now find docs on roles [0], jobs
[1] and a migration guide [2] which will show you which base jobs to start
with and how to migrate those devstack-gate flags from legacy jobs to the
zuul v3 jobs.

- the multinode patches including switching of test-matrix (on master) and
start including the list of devstack services in the base jobs. In doing so
I used the new neutron service names. That may be causing issues to
devstack-plugins looking for old service names, so if you encounter an
issue please reach out in the openstack-qa / openstack-infra rooms. We
could still roll back to the old names, however the beginning of the cycle
is probably the best time to sort out issues related to the new names and
new logic in the neutron - devstack code.

Coming up next:

- backport of devstack patches to stable (queens and pike), so we can
switch the Tempest job devstack multinode mode and develop grenade zuulv3
native jobs. I do not plan on backporting the new neutron names to any
stable branch, let me know if there is any reason to do otherwise.
- work on grenade is at very early stages [3], so far I got devstack
running successfully on stable/queens from the /opt/stack/old folder using
the zuulv3 roles. Next up is actually doing the migration and running all
relevant checks.

Andrea Frittoli (andreaf)

[0] https://docs.openstack.org/devstack/latest/zuul_roles.html
[1] https://docs.openstack.org/devstack/latest/zuul_jobs.html
[2] https://docs.openstack.org/devstack/latest/zuul_ci_jobs_migration.html
[3]
https://review.openstack.org/#/q/status:open+branch:master+topic:grenade_zuulv3



On Tue, Feb 20, 2018 at 9:22 PM Andrea Frittoli 
wrote:

> Dear all,
>
> updates:
>
> - host/group vars: zuul now supports declaring host and group vars in the
> job definition [0][1] - thanks corvus and infra team!
>   This is a great help towards writing the devstack and tempest base
> multinode jobs [2][3]
>   * NOTE: zuul merges dict variables through job inheritance. Variables in
> host/group_vars override global ones. I will write some examples further
> clarify this.
>
> - stable/pike: devstack ansible changes have been backported to
> stable/pike, so we can now run zuulv3 jobs against stable/pike too - thank
> you tosky!
>   next change in progress related to pike is to provide tempest-full-pike
> for branchless repositories [4]
>
> - documentation: devstack now publishes documentation on its ansible roles
> [5].
>   More devstack documentation patches are in progress to provide jobs
> reference, examples and a job migration how-to [6].
>
>
> Andrea Frittoli (andreaf)
>
> [0]
> https://docs.openstack.org/infra/zuul/user/config.html#attr-job.host_vars
> [1]
> https://docs.openstack.org/infra/zuul/user/config.html#attr-job.group_vars
>
> [2] https://review.openstack.org/#/c/545696/
> [3] https://review.openstack.org/#/c/545724/
> [4] https://review.openstack.org/#/c/546196/
> [5] https://docs.openstack.org/devstack/latest/roles.html
> [6] https://review.openstack.org/#/c/545992/
>
>
> On Mon, Feb 19, 2018 at 2:46 PM Andrea Frittoli 
> wrote:
>
>> Dear all,
>>
>> updates:
>> - tempest-full-queens and tempest-full-py3-queens are now available for
>> testing of branchless repositories [0]. They are used for tempest and
>> devstack-gate. If you own a tempest plugin in a branchless repo, you may
>> consider adding similar jobs to your plugin if you use it for tests on
>> stable/queen as well.
>> - if you have migrated jobs based on devstack-tempest please let me know,
>> I'm building reference docs and I'd like to include as many examples as
>> possible
>> - work on multi-node is in progress, but not ready still - you can follow
>> the patches in the multinode branch [1]
>> - updates on some of the points from my previous email are inline below
>>
>> Andrea Frittoli (andreaf)
>>
>> [0] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n73
>> [1]
>> https://review.openstack.org/#/q/status:open++branch:master+topic:multinode
>>
>>
>>
>> On Thu, Feb 15, 2018 at 11:31 PM Andrea Frittoli <
>> andrea.fritt...@gmail.com> wrote:
>>
>>> Dear all,
>>>
>>> this is the first or a series of ~regular updates on the migration of
>>> Tempest / Grenade jobs to  Zuul v3 native.
>>>
>>> The QA team together with the infra team are working on providing the
>>> OpenStack community with a set of base Tempest / Grenade jobs that can be
>>> used as a basis to write new CI jobs / migrate existing legacy ones with a
>>> minimal effort and very little or no Ansible knowledge as a precondition.
>>>
>>> The effort is tracked in an etherpad [0]; I'm trying to keep the
>>> etherpad up to date but it may not 

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

[Balázs Gibizer]

Hi,

Here is the status update / focus settings mail for w11.


Bugs

No new bug and no changes in the existing bugs from last week report 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/127992.html



Versioned notification transformation
-
We already have some patches proposed to the rock bp. Let's go and 
review them.

https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-rocky+status:open


Introduce instance.lock and instance.unlock notifications
-
The bp
https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances
is approved. Implementation patch exists but still needs work 
https://review.openstack.org/#/c/526251/



Add the user id and project id of the user initiated the instance
action to the notification
-
The bp
https://blueprints.launchpad.net/nova/+spec/add-action-initiator-to-instance-action-notifications
is approved. Implementation patch exists but still needs work 
https://review.openstack.org/#/c/536243/



Add request_id to the InstanceAction versioned notifications

The bp 
https://blueprints.launchpad.net/nova/+spec/add-request-id-to-instance-action-notifications 
is approved and assigned to Keving_Zheng. Patch has been proposed 
https://review.openstack.org/#/c/551982/ and needs review.



Sending full traceback in versioned notifications
-
Based on a short investigation it seems that it was a conscious 
decision not to include the full traceback. See details in the ML post 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128105.html
I will file a specless bp to add the full traceback if nobody objects 
in the ML thread.



Add versioned notifications for removing a member from a server group
-
The specless bp 
https://blueprints.launchpad.net/nova/+spec/add-server-group-remove-member-notifications 
is proposed and it looks good to me.



Factor out duplicated notification sample
-
https://review.openstack.org/#/q/topic:refactor-notification-samples+status:open
No open patches, but I would like to progress with this through the 
Rocky cycle.



Weekly meeting
--
The next meeting will be held on 13th of Marc on #openstack-meeting-4
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180313T17

Cheers,
gibi


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

Re: [openstack-dev] [keystone] Keystone failing with error 104 (connection reset by peer) if using uwsgi

[Lance Bragstad]

On 03/11/2018 06:09 PM, Thomas Goirand wrote:
> On 03/11/2018 08:12 PM, Lance Bragstad wrote:
>> Hey Thomas, 
>>
>> Outside of the uwsgi config, are you following a specific guide for your
>> install?
> Under the packages that I maintain in Debian, there's nothing more to do
> than "apt-get install keystone", reply to a few Debconf questions, and
> you get a working installation. That is to say, I don't think I did any
> mistake here.
Yeah, that's kind of what I figured, but thought I should ask in the
event there was anything suspect in our installation guide.
>
>> I'd like to try and recreate the issue.
> If you wish, I can build a package for you to try, if you're ok with
> that. Would that be ok? Would you prefer to use Sid or Stretch? It's
> rather easy to do, as the revert to Apache is just a single git commit.
If you have a package for Stretch, that'd be great.
>
>> Do you happen to have any more logging information?
> That's what was really frustrating: no log at all on the server side,
> just the client...
>
> Cheers,
>
> Thomas Goirand (zigo)




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

Re: [openstack-dev] [horizon] [devstack] horizon 'network create' panel does not distinguished

[Jaewook Oh]

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.heat_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/3bf910c7ae4c.js:699:8
at 
http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:818:59
at ensure 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:816:320)
at module 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:818:8)
at 
http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:925:35
at forEach 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:703:400)
at loadModules 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:924:156)
at 
http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:925:84
at forEach 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:703:400)
at loadModules 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:924:156)
http://errors.angularjs.org/1.5.8/$injector/modulerr?p0=horizon.dashboard.project.heat_dashboard.template_generator=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%20registering%20a%20module%20ensure%20that%20you%20specify%20the%20dependencies%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%2F3bf910c7ae4c.js%3A699%3A8%0A%20%20%20%20at%20http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3bf910c7ae4c.js%3A818%3A59%0A%20%20%20%20at%20ensure%20(http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3bf910c7ae4c.js%3A816%3A320)%0A%20%20%20%20at%20module%20(http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3bf910c7ae4c.js%3A818%3A8)%0A%20%20%20%20at%20http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3bf910c7ae4c.js%3A925%3A35%0A%20%20%20%20at%20forEach%20(http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3bf910c7ae4c.js%3A703%3A400)%0A%20%20%20%20at%20loadModules%20(http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3bf910c7ae4c.js%3A924%3A156)%0A%20%20%20%20at%20http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3bf910c7ae4c.js%3A925%3A84%0A%20%20%20%20at%20forEach%20(http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3bf910c7ae4c.js%3A703%3A400)%0A%20%20%20%20at%20loadModules%20(http%3A%2F%2F192.168.11.187%2Fdashboard%2Fstatic%2Fdashboard%2Fjs%2F3bf910c7ae4c.js%3A924%3A156)
at http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:699:8
at http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:927:7
at forEach 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:703:400)
at loadModules 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:924:156)
at 
http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:925:84
at forEach 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:703:400)
at loadModules 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:924:156)
at createInjector 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:913:464)
at doBootstrap 
(http://192.168.11.187/dashboard/static/dashboard/js/3bf910c7ae4c.js:792:36)
at bootstrap 

Re: [openstack-dev] [cinder] [oslo] cinder.conf generation is broken for my_ip, building non-reproducibly

[Doug Hellmann]

Excerpts from Thomas Goirand's message of 2018-03-12 09:17:19 +0100:
> Hi,
> 
> When inspecting Cinder's (Queens release) cinder.conf, I can see:
> 
> # Warning: Failed to format sample for my_ip
> # unhashable type: 'HostAddress'

This part sounds like it might be a bug in oslo.config, which
does define a HostAddress class, but that class appears to have the
needed method. Please file a bug.

> 
> So it seems there's an issue in either Cinder or Oslo. How can I
> investigate and fix this?
> 
> It's very likely that I'm once more the only person in the OpenStack
> community that is really checking config file generation (it used to be
> like that for past releases), and therefore the only one who noticed it.
> 
> Also, looking at the code, this seems to be yet-another-instance of
> "package cannot be built reproducible" [1] with the build host config
> leaking in the configuration (well, once that's fixed...). Indeed, in
> the code I can read:
> 
> cfg.HostAddressOpt('my_ip',
>default=netutils.get_my_ipv4(),
>help='IP address of this host'),
> 
> This means that, when that's repaired, build Cinder will write something
> like this:
> 
> #my_ip = 1.2.3.4
> 
> With 1.2.3.4 being the value of netutils.get_my_ipv4(). This is easily
> fixed by adding something like this:
> 
> sample-default=''
> 
> I'm writing this here for Cinder, but there's been numerous cases like
> this already. The most common mistake being the hostname of the build
> host leaking in the configuration. While this is easily fixed at the
> packaging level fixing the config file after generating it with
> oslo.config, often that config file is also built with the sphinx doc,
> and then that file isn't built reproducibly. That's harder to detect,
> and easier fixed upstream.

These sorts of issues are bugs in the consumers of oslo.config, and
should be filed there, since the library can't choose reasonable default
values.

Doug

> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> [1] https://reproducible-builds.org/
> 

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

Re: [openstack-dev] [kolla][vote] core nomination for caoyuan

[Paul Bourke]

+1

On 12/03/18 02:06, Jeffrey Zhang wrote:

​​Kolla core reviewer team,

It is my pleasure to nominate caoyuan for kolla core team.

caoyuan's output is fantastic over the last cycle. And he is the most
active non-core contributor on Kolla project for last 180 days[1]. He
focuses on configuration optimize and improve the pre-checks feature.

Consider this nomination a +1 vote from me.

A +1 vote indicates you are in favor of caoyuan as a candidate, a -1
is a veto. Voting is open for 7 days until Mar 12th, or a unanimous
response is reached or a veto vote occurs.

[1] http://stackalytics.com/report/contribution/kolla-group/180 


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


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



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

Re: [openstack-dev] [ironic] PTG Summary

[Dmitry Tantsur]

Inline.

On 03/12/2018 01:00 PM, Tim Bell wrote:

My worry with re-running the burn-in every time we do cleaning is for resource 
utilisation. When the machines are running the burn-in, they're not doing 
useful physics so I would want to minimise the number of times this is run over 
the life time of a machine.


You only have to run it every time if you put the step into automated cleaning. 
However, we also have manual cleaning, which is run explicitly.




It may be possible to do something like the burn in with a dedicated set of 
steps but still use the cleaning state machine.


Yep, this is what manual cleaning is about: an operator explicitly requests it 
with a given set of steps. See 
https://docs.openstack.org/ironic/latest/admin/cleaning.html#manual-cleaning




Having a cleaning step set (i.e. burn-in means 
cpuburn,memtest,badblocks,benchmark) would make it more friendly for the 
administrator. Similarly, retirement could be done with additional steps such 
as reset2factory.


++

We may even add a reference set of clean steps to IPA, but we'll need your help 
implementing them. I am personally not familiar with how to do burn-in right 
(though IIRC Julia is).




Tim

-Original Message-
From: Dmitry Tantsur 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 12 March 2018 at 12:47
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [ironic] PTG Summary

 Hi Tim,
 
 Thanks for the information.
 
 I personally don't see problems with cleaning running weeks, when needed. What

 I'd avoid is replicating the same cleaning machinery but with a different 
name.
 I think we should try to make cleaning work for this case instead.
 
 Dmitry
 
 On 03/12/2018 12:33 PM, Tim Bell wrote:

 > Julia,
 >
 > A basic summary of CERN does burn-in is at 
http://openstack-in-production.blogspot.ch/2018/03/hardware-burn-in-in-cern-datacenter.html
 >
 > Given that the burn in takes weeks to run, we'd see it as a different 
step to cleaning (with some parts in common such as firmware upgrades to latest 
levels)
 >
 > Tim
 >
 > -Original Message-
 > From: Julia Kreger 
 > Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

 > Date: Thursday, 8 March 2018 at 22:10
 > To: "OpenStack Development Mailing List (not for usage questions)" 

 > Subject: [openstack-dev] [ironic] PTG Summary
 >
 > ...
 >  Cleaning - Burn-in
 >
 >  As part of discussing cleaning changes, we discussed supporting a
 >  "burn-in" mode where hardware could be left to run load, memory, or
 >  other tests for a period of time. We did not have consensus on a
 >  generic solution, other than that this should likely involve
 >  clean-steps that we already have, and maybe another entry point into
 >  cleaning. Since we didn't really have consensus on use cases, we
 >  decided the logical thing was to write them down, and then go from
 >  there.
 >
 >  Action Items:
 >  * Community members to document varying burn-in use cases for
 >  hardware, as they may vary based upon industry.
 >  * Community to try and come up with a couple example clean-steps.
 >
 >
 >
 > 
__
 > OpenStack Development Mailing List (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] [ironic] PTG Summary

[Tim Bell]

My worry with re-running the burn-in every time we do cleaning is for resource 
utilisation. When the machines are running the burn-in, they're not doing 
useful physics so I would want to minimise the number of times this is run over 
the life time of a machine.

It may be possible to do something like the burn in with a dedicated set of 
steps but still use the cleaning state machine.  

Having a cleaning step set (i.e. burn-in means 
cpuburn,memtest,badblocks,benchmark) would make it more friendly for the 
administrator. Similarly, retirement could be done with additional steps such 
as reset2factory.

Tim

-Original Message-
From: Dmitry Tantsur 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 12 March 2018 at 12:47
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [ironic] PTG Summary

Hi Tim,

Thanks for the information.

I personally don't see problems with cleaning running weeks, when needed. 
What 
I'd avoid is replicating the same cleaning machinery but with a different 
name. 
I think we should try to make cleaning work for this case instead.

Dmitry

On 03/12/2018 12:33 PM, Tim Bell wrote:
> Julia,
> 
> A basic summary of CERN does burn-in is at 
http://openstack-in-production.blogspot.ch/2018/03/hardware-burn-in-in-cern-datacenter.html
> 
> Given that the burn in takes weeks to run, we'd see it as a different 
step to cleaning (with some parts in common such as firmware upgrades to latest 
levels)
> 
> Tim
> 
> -Original Message-
> From: Julia Kreger 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

> Date: Thursday, 8 March 2018 at 22:10
> To: "OpenStack Development Mailing List (not for usage questions)" 

> Subject: [openstack-dev] [ironic] PTG Summary
> 
> ...
>  Cleaning - Burn-in
>  
>  As part of discussing cleaning changes, we discussed supporting a
>  "burn-in" mode where hardware could be left to run load, memory, or
>  other tests for a period of time. We did not have consensus on a
>  generic solution, other than that this should likely involve
>  clean-steps that we already have, and maybe another entry point into
>  cleaning. Since we didn't really have consensus on use cases, we
>  decided the logical thing was to write them down, and then go from
>  there.
>  
>  Action Items:
>  * Community members to document varying burn-in use cases for
>  hardware, as they may vary based upon industry.
>  * Community to try and come up with a couple example clean-steps.
>  
>  
> 
> __
> OpenStack Development Mailing List (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] [ironic] PTG Summary

[Dmitry Tantsur]

Hi Tim,

Thanks for the information.

I personally don't see problems with cleaning running weeks, when needed. What 
I'd avoid is replicating the same cleaning machinery but with a different name. 
I think we should try to make cleaning work for this case instead.


Dmitry

On 03/12/2018 12:33 PM, Tim Bell wrote:

Julia,

A basic summary of CERN does burn-in is at 
http://openstack-in-production.blogspot.ch/2018/03/hardware-burn-in-in-cern-datacenter.html

Given that the burn in takes weeks to run, we'd see it as a different step to 
cleaning (with some parts in common such as firmware upgrades to latest levels)

Tim

-Original Message-
From: Julia Kreger 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 8 March 2018 at 22:10
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [ironic] PTG Summary

...
 Cleaning - Burn-in
 
 As part of discussing cleaning changes, we discussed supporting a

 "burn-in" mode where hardware could be left to run load, memory, or
 other tests for a period of time. We did not have consensus on a
 generic solution, other than that this should likely involve
 clean-steps that we already have, and maybe another entry point into
 cleaning. Since we didn't really have consensus on use cases, we
 decided the logical thing was to write them down, and then go from
 there.
 
 Action Items:

 * Community members to document varying burn-in use cases for
 hardware, as they may vary based upon industry.
 * Community to try and come up with a couple example clean-steps.
 
 


__
OpenStack Development Mailing List (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] [ironic] PTG Summary

[Tim Bell]

Julia,

A basic summary of CERN does burn-in is at 
http://openstack-in-production.blogspot.ch/2018/03/hardware-burn-in-in-cern-datacenter.html

Given that the burn in takes weeks to run, we'd see it as a different step to 
cleaning (with some parts in common such as firmware upgrades to latest levels)

Tim

-Original Message-
From: Julia Kreger 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 8 March 2018 at 22:10
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [ironic] PTG Summary

...
Cleaning - Burn-in

As part of discussing cleaning changes, we discussed supporting a
"burn-in" mode where hardware could be left to run load, memory, or
other tests for a period of time. We did not have consensus on a
generic solution, other than that this should likely involve
clean-steps that we already have, and maybe another entry point into
cleaning. Since we didn't really have consensus on use cases, we
decided the logical thing was to write them down, and then go from
there.

Action Items:
* Community members to document varying burn-in use cases for
hardware, as they may vary based upon industry.
* Community to try and come up with a couple example clean-steps.



__
OpenStack Development Mailing List (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] [glance] Priorities for WC 12th of March

[Erno Kuvaja]

Hi all,

Queens is released, we had good and productive PTG so lets get the
ball rolling and start working through our Rocky priorities.

This week I'd like the focus to be, as discussed in our weekly meeting
at Thu, on python-glanceclient for 'web-download' import method and
any specs that still would needs review on the PTG topic list [0]. You
can review the topic etherpads for your convenience. Lets get those
nailed down so the people committed to those features can start
working on the implementation.

Another announcement for Glance (Core) reviewers so that you are
aware. We've had unenforced (to keep other changes to spec repo being
not depending on one person) policy in Glance that only PTL +W's any
specs so we can ensure that all our cores and invested parties are
aware and on board. This is clearly something that was forgotten and
we failed to communicate to our new cores so we did change the repo
acl accordingly [1]

[0] https://etherpad.openstack.org/p/glance-rocky-ptg
[1]https://review.openstack.org/#/c/551268/

I wish you all great and productive week!

Best,
Erno jokke Kuvaja

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

[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 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.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> 葛馨霓 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] [kolla][vote] core nomination for caoyuan

[Christian Berendt]

+1

> On 12. Mar 2018, at 03:06, Jeffrey Zhang  wrote:
> 
> It is my pleasure to nominate caoyuan for kolla core team.

-- 
Christian Berendt
Chief Executive Officer (CEO)

Mail: bere...@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139


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

Re: [openstack-dev] [kolla][vote] core nomination for caoyuan

[Flint WALRUS]

+1
Le lun. 12 mars 2018 à 10:09, Marcin Juszkiewicz <
marcin.juszkiew...@linaro.org> a écrit :

> W dniu 12.03.2018 o 03:06, Jeffrey Zhang pisze:
> > It is my pleasure to nominate caoyuan for kolla core team.
>
> +1
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][vote] core nomination for caoyuan

[Marcin Juszkiewicz]

W dniu 12.03.2018 o 03:06, Jeffrey Zhang pisze:
> It is my pleasure to nominate caoyuan for kolla core team.

+1

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

Re: [openstack-dev] [openstack][charms] Openstack + OVN

[James Page]

Hi Aakash

On Sun, 11 Mar 2018 at 19:01 Aakash Kt  wrote:

> Hi,
>
> I had previously put in a mail about the development for openstack-ovn
> charm. Sorry it took me this long to get back, was involved in other
> projects.
>
> I have submitted a charm spec for the above charm.
> Here is the review link : https://review.openstack.org/#/c/551800/
>
> Please look in to it and we can further discuss how to proceed.
>

I'll feedback directly on the review.

Thanks!

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

[openstack-dev] [cyborg]Weekly Team Meeting 2018.03.14 Agenda (No Time Change For US)

[Zhipeng Huang]

Hi Team,

We will resume the team meeting this week. The meeting starting time is
still ET 10:00am/PT 7:00am, whereas in China it is moved one hour early to
10:00pm. For Europe please refer to UTC1400 as the baseline.

This week we will have a special 2 hour meeting. In the first one hour we
will have Shaohe demo the PoC Intel dev team had conducted, and in the
second half we will confirm the task and milestones for Rocky based upon
the PTG discussion (summary sent out last Friday).

ZOOM link will be provided before the meeting :)

If there are any other topics anyone would like to propose, feel free to
reply to this email thread.

-- 
Zhipeng (Howard) Huang

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

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

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

[openstack-dev] [cinder] [oslo] cinder.conf generation is broken for my_ip, building non-reproducibly

[Thomas Goirand]

Hi,

When inspecting Cinder's (Queens release) cinder.conf, I can see:

# Warning: Failed to format sample for my_ip
# unhashable type: 'HostAddress'

So it seems there's an issue in either Cinder or Oslo. How can I
investigate and fix this?

It's very likely that I'm once more the only person in the OpenStack
community that is really checking config file generation (it used to be
like that for past releases), and therefore the only one who noticed it.

Also, looking at the code, this seems to be yet-another-instance of
"package cannot be built reproducible" [1] with the build host config
leaking in the configuration (well, once that's fixed...). Indeed, in
the code I can read:

cfg.HostAddressOpt('my_ip',
   default=netutils.get_my_ipv4(),
   help='IP address of this host'),

This means that, when that's repaired, build Cinder will write something
like this:

#my_ip = 1.2.3.4

With 1.2.3.4 being the value of netutils.get_my_ipv4(). This is easily
fixed by adding something like this:

sample-default=''

I'm writing this here for Cinder, but there's been numerous cases like
this already. The most common mistake being the hostname of the build
host leaking in the configuration. While this is easily fixed at the
packaging level fixing the config file after generating it with
oslo.config, often that config file is also built with the sphinx doc,
and then that file isn't built reproducibly. That's harder to detect,
and easier fixed upstream.

Cheers,

Thomas Goirand (zigo)

[1] https://reproducible-builds.org/

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