Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config

[Weyl, Alexey (Nokia - IL)]

Bo problem Dong.

If you have any more questions, don’t be shy, just ask.

BR,
Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
Sent: Thursday, January 05, 2017 3:16 AM
To: Weyl, Alexey (Nokia - IL)
Cc: openstack-dev@lists.openstack.org
Subject: 答复: RE: Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config




Hi Alexey,



Sorry, I saw the configuration. Need to click the 'raw' button in github to see 
the whole layout.yaml file.

Sorry to trouble you again and again.  :-)



BR,

dwj






原始邮件
发件人：Weyl,Alexey(Nokia-IL)
收件人：董文娟00101742;
抄送人：＜openstack-dev@lists.openstack.org＞
日 期 ：2017年01月04日 19:13
主 题 ：RE: Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config


We do write code in the zuul/layout.yaml:

  - name: openstack/puppet-vitrage

template:

  - name: merge-check

  - name: puppet-check-jobs

  - name: puppet-module-unit-jobs

  - name: puppet-beaker-jobs

  - name: puppet-beaker-jobs-xenial

  - name: puppet-branch-tarball-jobs

  - name: openstack-server-release-jobs

  - name: release-notes-jobs

  - name: openstack/python-vitrageclient
template:
  - name: merge-check
  - name: python-jobs
  - name: python35-jobs
  - name: check-requirements
  - name: publish-to-pypi
  - name: osc-plugin-jobs

Alexey

From: dong.wenj...@zte.com.cn 
[mailto:dong.wenj...@zte.com.cn]
Sent: Wednesday, January 04, 2017 10:59 AM
To: Weyl, Alexey (Nokia - IL)
Cc: openstack-dev@lists.openstack.org
Subject: 答复: Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config

Hi Alexey,

As far as i know, every project needs to register in the zuul/layout.yaml[1], 
so zuul can submit the job to jenkins via gearman.
So the jenkins knows which jobs need to run and then run the job which defined 
in the jenkins/jobs/XXX.yaml.
Did i missing something? Or the job registeration moved from zuul/layout.yaml 
to jenkins/jobs/projects.yaml?
If yes, how can zuul know which jobs need to submit to jenkins?Thanks~

[1]https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml

BR,
dwj




原始邮件
发件人：Weyl,Alexey(Nokia-IL)
收件人：OpenStack Development Mailing List (not for usage questions);
日 期 ：2017年01月04日 16:30
主 题 ：Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config

Hi Dong,

All of that data is configured the openstack-infra/project-config in github.

There you can find our changes by searching for vitrage.

The main files that we have pushed our changes are:
jenkins/jobs/vitrage.yaml
gerrit/projects.yaml
jenkins/jobs/projects.yaml

BR,
Alexey

From: dong.wenj...@zte.com.cn 
[mailto:dong.wenj...@zte.com.cn]
Sent: Wednesday, January 04, 2017 9:49 AM
To: openstack-dev@lists.openstack.org
Subject: [ALU] [openstack-dev] [Vitrage] vitrage tempest job config


Hi all,
I didn't find any vitrage project jenkins jobs registered in zuul/layout.yaml.
Where does all the jobs configed?Thanks~
BR,
dwj



__
OpenStack Development Mailing 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] [Monasca] Monasca devstack installation is failing

[Pradeep Singh]

*Hello,*

*I am trying to install Monasca devstack using vagrant file given in
monasca-ui repo.*

*And its failing again and again with below error.*

*Could you please help me, i will really appreciate your help.*


==> default: 2017-01-05 06:28:06.125 | ++
functions-common:start_service:2306  :   sudo /bin/systemctl start
monasca-thresh

==> default: 2017-01-05 06:28:27.440 | Job for monasca-thresh.service
failed because the control process exited with error code. See "systemctl
status monasca-thresh.service" and "journalctl -xe" for details.

==> default: 2017-01-05 06:28:27.444 | ++
/opt/stack/monasca-api/devstack/plugin.sh:start_monasca_services:235 :
restart_service monasca-thresh

==> default: 2017-01-05 06:28:27.447 | ++
functions-common:restart_service:2282:   '[' -x /bin/systemctl ']'

==> default: 2017-01-05 06:28:27.450 | ++
functions-common:restart_service:2283:   sudo /bin/systemctl restart
monasca-thresh

==> default: 2017-01-05 06:28:47.368 | Job for monasca-thresh.service
failed because the control process exited with error code. See "systemctl
status monasca-thresh.service" and "journalctl -xe" for details.

*vagrant@devstack*:*~*$ systemctl status monasca-thresh.service

*●* monasca-thresh.service - LSB: Monitoring threshold engine running under
storm

   Loaded: loaded (/etc/init.d/monasca-thresh; bad; vendor preset: enabled)

   Active: *failed* (Result: exit-code) since Thu 2017-01-05 06:28:47 UTC;
27s ago

 Docs: man:systemd-sysv-generator(8)

  Process: 28638 ExecStart=/etc/init.d/monasca-thresh start *(code=exited,
status=1/FAILURE)*


Jan 05 06:28:47 devstack monasca-thresh[28638]: main()

Jan 05 06:28:47 devstack monasca-thresh[28638]:   File
"/opt/storm/current/bin/storm.py", line 766, in main

Jan 05 06:28:47 devstack monasca-thresh[28638]: (COMMANDS.get(COMMAND,
unknown_command))(*ARGS)

Jan 05 06:28:47 devstack monasca-thresh[28638]:   File
"/opt/storm/current/bin/storm.py", line 248, in jar

Jan 05 06:28:47 devstack monasca-thresh[28638]: os.remove(tmpjar)

Jan 05 06:28:47 devstack monasca-thresh[28638]: OSError: [Errno 2] No such
file or directory: '/tmp/30c1980ed31011e68cd3080027b55b5e.jar'

Jan 05 06:28:47 devstack systemd[1]: *monasca-thresh.service: Control
process exited, code=exited status=1*

Jan 05 06:28:47 devstack systemd[1]: *Failed to start LSB: Monitoring
threshold engine running under storm.*

Jan 05 06:28:47 devstack systemd[1]: *monasca-thresh.service: Unit entered
failed state.*

Jan 05 06:28:47 devstack systemd[1]: *monasca-thresh.service: Failed with
result 'exit-code'.*


*Thanks,*

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

[openstack-dev] [nova] mutate config options on compute service

[Chen CH Ji]

According to http://docs.openstack.org/newton/config-reference/mutable.html
, seems this option is valid to compute service (as it says: Log onto the
compute node. )
but from following test result seems it's not honored by compute service,
is it a bug or wrong usage?

this is a all in one environment, Newton release version
I did change debug options from True to none (default to False) in the node
and tried command 'pkill -HUP nova'

compute logs shows it's still in DEBUG mode (and only service restart will
make the debug logs disappear)

2017-01-05 05:16:46.174 62225 INFO oslo_service.service
[req-de8349f2-ceb7-4eef-94ce-7cb09fd289bf - - - - -] Caught SIGHUP, exiting
2017-01-05 05:16:46.175 62225 DEBUG oslo_concurrency.lockutils
[req-de8349f2-ceb7-4eef-94ce-7cb09fd289bf - - - - -] Acquired semaphore
"singleton_lock"
lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:212
2017-01-05 05:16:46.175 62225 DEBUG oslo_concurrency.lockutils
[req-de8349f2-ceb7-4eef-94ce-7cb09fd289bf - - - - -] Releasing semaphore
"singleton_lock"
lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:225
2017-01-05 05:16:51.287 62225 DEBUG oslo_messaging._drivers.amqpdriver [-]
CALL msg_id: a86b7b1cb66745e485e5ab75a1eb2a83 exchange 'nova' topic
'conductor'
_send /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:448
2017-01-05 05:16:51.295 62225 INFO nova.compute.manager
[req-de8349f2-ceb7-4eef-94ce-7cb09fd289bf - - - - -] Reloading compute RPC
API

api log shows it honored the flag and follow on there is no debug log based
on the 'Option DEFAULT.debug changed from [true] to [None]'

2017-01-05 05:16:46.130 62146 INFO oslo_service.service
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Child caught SIGHUP,
exiting
2017-01-05 05:16:46.130 62146 DEBUG oslo_concurrency.lockutils
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Acquired semaphore
"singleton_lock"
lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:212
2017-01-05 05:16:46.130 62146 DEBUG oslo_concurrency.lockutils
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Releasing semaphore
"singleton_lock"
lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:225
2017-01-05 05:16:46.151 62145 INFO oslo_config.cfg
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Option DEFAULT.debug
changed from [true] to [None]
2017-01-05 05:16:46.151 62145 INFO nova.wsgi
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Stopping WSGI server.
2017-01-05 05:16:46.151 62145 INFO nova.osapi_compute.wsgi.server
[req-3d3dfc79-4c42-460e-8311-7eab381adff3 - - - - -] (62145) wsgi exited,
is_accepting=True
2017-01-05 05:16:46.152 62145 INFO nova.wsgi
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] WSGI server has
stopped.
2017-01-05 05:16:46.154 62146 INFO oslo_config.cfg
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Option DEFAULT.debug
changed from [true] to [None]
2017-01-05 05:16:46.155 62146 INFO nova.wsgi
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Stopping WSGI server.



2017-01-05 05:16:46.164 62146 INFO nova.osapi_compute.wsgi.server
[req-c0aaa8de-b181-4fb0-a3e1-0e4ed201457b - - - - -] (62146) wsgi starting
up on https://0.0.0.0:8774
Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
__
OpenStack Development Mailing 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] Fwd: [Openstack] The Forum: in more detail

[Tom Fifield]

Hi *dev,

Post over on the general ML you might be interested in - please send 
replies there to avoid cross-posting pain ;)



Regards,


Tom


 Forwarded Message 
Subject: [Openstack] The Forum: in more detail
Date: Thu, 5 Jan 2017 11:42:53 +0800
From: Tom Fifield 
To: openst...@lists.openstack.org

Hi all,

working with colleagues, I've just put up a post cobbling together some 
more detail on the Forum. Sorry it took so long!


http://superuser.openstack.org/articles/openstack-forum/


There's now also a wiki page to be the reference for us to follow when 
preparing or participating:


https://wiki.openstack.org/wiki/Forum


Please check them out and reply with any thoughts, ideas or angry rants!


Regards,


Tom

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openst...@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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

Re: [openstack-dev] [neutron][ml2] Mechanism drivers ! OpenvSwich or Linuxbridge or both of them?

[zhi]

Hi, Kevin. If I load openvswitch and linuxbridge mechanism drivers in
neutron server, and running ovs-agent in compute nodes. What does
openvsitch mechanism driver do? What does linuxbridge mechanism do? I think
there must have some differences between the openvswitch and the
linuxbridge mechanism driver. But I can't get the exact point about the two
mechanism drivers when running ovs-agent in compute nodes now.

2017-01-04 16:16 GMT+08:00 Kevin Benton :

> Note that with the openvswitch and linuxbridge mechanism drivers, it will
> be safe to have both loaded on the Neutron server at the same time since
> each driver will only bind a port if it has an agent of that type running
> on the host.
>
> On Fri, Dec 30, 2016 at 1:24 PM, Sławek Kapłoński 
> wrote:
>
>> Hello,
>>
>> I don't know what is hierarchical port binding but about mechanism
>> drivers, You should use this mechanism driver which L2 agent You are
>> using on compute/network nodes. If You have OVS L2 agent then You should
>> have enabled openvswitch mechanism driver.
>> In general both of those drivers are doing similar work on
>> neutron-server side because they are checking if proper agent type is
>> working on host and if other conditions required to bind port are valid.
>> Mechanism drivers can have also some additional informations about
>> backend driver, e.g. there is info about supported QoS rule types for
>> each backend driver (OVS, Linuxbridge and SR-IOV).
>>
>> BTW. IMHO You should send such questions to openst...@lists.openstack.org
>>
>> --
>> Best regards / Pozdrawiam
>> Sławek Kapłoński
>> sla...@kaplonski.pl
>>
>> On Fri, 30 Dec 2016, zhi wrote:
>>
>> > Hi, all
>> >
>> > First of all. Happy New year for everyone!
>> >
>> > I have a question about mechanism drivers when using ML2 driver.
>> >
>> > When should I use openvswitch mechanism driver ?
>> >
>> > When should I use linuxbridge mechanism driver ?
>> >
>> > And, when should I use openvswitch and linuxbridge mechanism drivers ?
>> >
>> > In my opinion, ML2 driver has supported hierarchical port binding. By
>> using
>> > hierarchical port binding,
>> > neutron will know every binding info in network topology, isn't it? If
>> yes,
>> > where I can found the every binding info. And what the relationship
>> between
>> > hierarchical port binding and mechanism drivers?
>> >
>> >
>> > Hope for your reply.
>> >
>> > Thanks
>> > Zhi Chang
>>
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] 答复: RE: Re: [ALU] [Vitrage] vitrage tempest job config

[dong.wenjuan]

Hi Alexey,




Sorry, I saw the configuration. Need to click the 'raw' button in github to see 
the whole layout.yaml file.

Sorry to trouble you again and again.  :-)




BR,

dwj












原始邮件



发件人：Weyl,Alexey(Nokia-IL)
收件人：董文娟00101742
抄送人：＜openstack-dev@lists.openstack.org＞
日 期 ：2017年01月04日 19:13
主 题 ：RE: Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config





We do write code in the zuul/layout.yaml:

  - name: openstack/puppet-vitrage

template:

  - name: merge-check

  - name: puppet-check-jobs

  - name: puppet-module-unit-jobs

  - name: puppet-beaker-jobs

  - name: puppet-beaker-jobs-xenial

  - name: puppet-branch-tarball-jobs

  - name: openstack-server-release-jobs

  - name: release-notes-jobs

  - name: openstack/python-vitrageclient
template:
  - name: merge-check
  - name: python-jobs
  - name: python35-jobs
  - name: check-requirements
  - name: publish-to-pypi
  - name: osc-plugin-jobs

Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Wednesday, January 04, 2017 10:59 AM
To: Weyl, Alexey (Nokia - IL)
Cc: openstack-dev@lists.openstack.org
Subject: 答复: Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config

Hi Alexey,

As far as i know, every project needs to register in the zuul/layout.yaml[1], 
so zuul can submit the job to jenkins via gearman.
So the jenkins knows which jobs need to run and then run the job which defined 
in the jenkins/jobs/XXX.yaml.
Did i missing something? Or the job registeration moved from zuul/layout.yaml 
to jenkins/jobs/projects.yaml?
If yes, how can zuul know which jobs need to submit to jenkins?Thanks~

[1]https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml
 

BR,
dwj




原始邮件
发件人：Weyl,Alexey(Nokia-IL)
收件人：OpenStack Development Mailing List (not for usage questions)
日 期 ：2017年01月04日 16:30
主 题 ：Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config

Hi Dong,

All of that data is configured the openstack-infra/project-config in github.

There you can find our changes by searching for vitrage.

The main files that we have pushed our changes are:
jenkins/jobs/vitrage.yaml
gerrit/projects.yaml
jenkins/jobs/projects.yaml

BR,
Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Wednesday, January 04, 2017 9:49 AM
To: openstack-dev@lists.openstack.org
Subject: [ALU] [openstack-dev] [Vitrage] vitrage tempest job config


Hi all,
I didn't find any vitrage project jenkins jobs registered in zuul/layout.yaml.
Where does all the jobs configed?Thanks~
BR,
dwj



__
OpenStack Development Mailing 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] 答复: RE: Re: [ALU] [Vitrage] vitrage tempest job config

[Yujun Zhang]

It seems the file is truncated on Github preview. It stops at
openstack/security-specs

If you check the raw file[1], you will find entry of openstack/vitrage

[1]:
https://raw.githubusercontent.com/openstack-infra/project-config/master/zuul/layout.yaml


[image: Screen Shot 2017-01-05 at 9.11.08 AM.png]


On Thu, Jan 5, 2017 at 8:39 AM  wrote:

> Hi,
>
>
> I know. Why only python-vitrageclient and puppet-vitrage register in the
> zuul/layout.yaml? They also register in the jeknins/jobs/projects.yaml.
>
> And other vitrage projects only register in the
> jeknins/jobs/projects.yaml.
>
> I'm confused if i want to add a new jenkins job, which file should i
> register in?
>
>
> BR,
>
> dwj
>
>
>
>
>
> 原始邮件
> *发件人：*Weyl,Alexey(Nokia-IL)
> *收件人：*董文娟00101742;
> *抄送人：*＜openstack-dev@lists.openstack.org＞
> *日 期 ：*2017年01月04日 19:13
> *主 题 ：**RE: Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job
> config*
>
>
> We do write code in the zuul/layout.yaml:
>
>   - name: openstack/puppet-vitrage
>
> template:
>
>   - name: merge-check
>
>   - name: puppet-check-jobs
>
>   - name: puppet-module-unit-jobs
>
>   - name: puppet-beaker-jobs
>
>   - name: puppet-beaker-jobs-xenial
>
>   - name: puppet-branch-tarball-jobs
>
>   - name: openstack-server-release-jobs
>
>   - name: release-notes-jobs
>
>   - name: openstack/python-vitrageclient
> template:
>   - name: merge-check
>   - name: python-jobs
>   - name: python35-jobs
>   - name: check-requirements
>   - name: publish-to-pypi
>   - name: osc-plugin-jobs
>
> Alexey
>
> From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
> Sent: Wednesday, January 04, 2017 10:59 AM
> To: Weyl, Alexey (Nokia - IL)
> Cc: openstack-dev@lists.openstack.org
> Subject: 答复: Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config
>
> Hi Alexey,
>
>
> As far as i know, every project needs to register in the zuul/layout.yaml[1], 
> so zuul can submit the job to jenkins via gearman.
>
> So the jenkins knows which jobs need to run and then run the job which 
> defined in the jenkins/jobs/XXX.yaml.
>
> Did i missing something? Or the job registeration moved from zuul/layout.yaml 
> to jenkins/jobs/projects.yaml?
> If yes, how can zuul know which jobs need to submit to jenkins?Thanks~
>
> [1]
> https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml
>
>
> BR,
> dwj
>
>
>
>
> 原始邮件
> 发件人：Weyl,Alexey(Nokia-IL)
> 收件人：OpenStack Development Mailing List (not for usage questions);
> 日 期 ：2017年01月04日 16:30
> 主 题 ：Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config
>
> Hi Dong,
>
>
> All of that data is configured the openstack-infra/project-config in github.
>
> There you can find our changes by searching for vitrage.
>
> The main files that we have pushed our changes are:
> jenkins/jobs/vitrage.yaml
> gerrit/projects.yaml
> jenkins/jobs/projects.yaml
>
> BR,
> Alexey
>
> From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
> Sent: Wednesday, January 04, 2017 9:49 AM
> To: openstack-dev@lists.openstack.org
> Subject: [ALU] [openstack-dev] [Vitrage] vitrage tempest job config
>
>
> Hi all,
>
> I didn't find any vitrage project jenkins jobs registered in zuul/layout.yaml.
> Where does all the jobs configed?Thanks~
> BR,
> dwj
>
>
>
> __
> OpenStack Development Mailing 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] [oslo] Not running for Oslo PTL for Pike

[Joshua Harlow]

Doug Hellmann wrote:

Excerpts from Joshua Harlow's message of 2017-01-03 12:03:44 -0800:

Hi Oslo folks (and others),

Happy new year!

After serving for about a year I think it's a good opportunity for
myself to let another qualified individual run for Oslo PTL (seems
common to only go for two terms and hand-off to another).

So I just wanted to let folks know that I will be doing this, so that we
can grow others in the community that wish to try out being a PTL.

I don't plan on leaving the Oslo community btw, just want to make sure
we spread the knowledge (and the fun!) of being a PTL.

Hopefully I've been a decent PTL (with  room to improve) during
this time :-)

-Josh



Thanks for your leadership over the past year, Josh! I'm glad to hear
you'll be staying on the team, too.

Doug



Once in (oslo) fight club, one can never leave (oslo) fight club, ha.

-Josh

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

[openstack-dev] 答复: RE: Re: [ALU] [Vitrage] vitrage tempest job config

[dong.wenjuan]

Hi,




I know. Why only python-vitrageclient and puppet-vitrage register in the 
zuul/layout.yaml? They also register in the jeknins/jobs/projects.yaml.

And other vitrage projects only register in the jeknins/jobs/projects.yaml.

I'm confused if i want to add a new jenkins job, which file should i register 
in?




BR,

dwj















原始邮件



发件人：Weyl,Alexey(Nokia-IL)
收件人：董文娟00101742
抄送人：＜openstack-dev@lists.openstack.org＞
日 期 ：2017年01月04日 19:13
主 题 ：RE: Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config





We do write code in the zuul/layout.yaml:

  - name: openstack/puppet-vitrage

template:

  - name: merge-check

  - name: puppet-check-jobs

  - name: puppet-module-unit-jobs

  - name: puppet-beaker-jobs

  - name: puppet-beaker-jobs-xenial

  - name: puppet-branch-tarball-jobs

  - name: openstack-server-release-jobs

  - name: release-notes-jobs

  - name: openstack/python-vitrageclient
template:
  - name: merge-check
  - name: python-jobs
  - name: python35-jobs
  - name: check-requirements
  - name: publish-to-pypi
  - name: osc-plugin-jobs

Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Wednesday, January 04, 2017 10:59 AM
To: Weyl, Alexey (Nokia - IL)
Cc: openstack-dev@lists.openstack.org
Subject: 答复: Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config

Hi Alexey,

As far as i know, every project needs to register in the zuul/layout.yaml[1], 
so zuul can submit the job to jenkins via gearman.
So the jenkins knows which jobs need to run and then run the job which defined 
in the jenkins/jobs/XXX.yaml.
Did i missing something? Or the job registeration moved from zuul/layout.yaml 
to jenkins/jobs/projects.yaml?
If yes, how can zuul know which jobs need to submit to jenkins?Thanks~

[1]https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml
 

BR,
dwj




原始邮件
发件人：Weyl,Alexey(Nokia-IL)
收件人：OpenStack Development Mailing List (not for usage questions)
日 期 ：2017年01月04日 16:30
主 题 ：Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config

Hi Dong,

All of that data is configured the openstack-infra/project-config in github.

There you can find our changes by searching for vitrage.

The main files that we have pushed our changes are:
jenkins/jobs/vitrage.yaml
gerrit/projects.yaml
jenkins/jobs/projects.yaml

BR,
Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Wednesday, January 04, 2017 9:49 AM
To: openstack-dev@lists.openstack.org
Subject: [ALU] [openstack-dev] [Vitrage] vitrage tempest job config


Hi all,
I didn't find any vitrage project jenkins jobs registered in zuul/layout.yaml.
Where does all the jobs configed?Thanks~
BR,
dwj



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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Steven Dake (stdake)]

Michal,

Another option is 2 individuals from each core review team + PTL.  That is 
lighter weight then 3 and 4, yet more constrained then 1 and 2 and would be my 
preferred choice (or alternatively 3 or 4).  Adding a deliverable is serious 
business ☺

FWIW I don’t’ think we are at an impasse, it just requires a policy vote as we 
do today.

Regards
-steve

-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, January 4, 2017 at 3:38 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [tc][kolla] Adding new deliverables

Hello,

New deliverable to Kolla was proposed, and we found ourselves in a bit
of an impasse regarding process of accepting new deliverables. Kolla
community grew a lot since we were singular project, and now we have 3
deliverables already (kolla, kolla-ansible and kolla-kubernetes). 4th
one was proposed, kolla-salt, all of them having separate core teams
today. How to we proceed with this and following deliverables? How to
we accept them to kolla namespace? I can think of several ways.

1) Open door policy - whoever wants to create new deliverable, is just
free to do so.
2) Lightweight agreement - just 2*+2 from Kolla core team to some list
of deliveralbes that will sit in kolla repo, potentially 2*+2 + PTL
vote it would be good for PTL to know what he/she is PTL of;)
3) Majority vote from Kolla core team - much like we do with policy
changes today
4) Majority vote from all Kolla deliverables core teams

My personal favorite is option 2+PTL vote. We want to encourage
experiments and new contributors to use our namespace, for both larger
community and ease of navigation for users.

One caveat to this would be to note that pre-1.0 projects are
considered dev/experimental.

Thoughts?

Cheers,
Michal

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


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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Sam Yaple]

As the person purposing kolla-salt, I would like to weigh in. I like the
idea of option 2, I certainly feel the PTL should always be involved in
these things.

I would also agree with the pre-1.0 as dev/experimental so as to not be
tightly bound by rules for more stable and long term projects (like
backward compatibility) until after 1.0 is tagged. This would give the
flexibility for the project to reinvent itself as it grows.

What I do notice is lack of wording describing who would be committing to
work on the new deliverable, and I think that is important. It could be a
team of people wanting to work on it, or one person putting forth work for
a new deployment tool to use Kolla container and others joining in as they
see the potential of the project themselves. I would prefer to keep it that
way.

Thanks,
SamYaple

Sam Yaple

On Wed, Jan 4, 2017 at 11:38 PM, Michał Jastrzębski 
wrote:

> Hello,
>
> New deliverable to Kolla was proposed, and we found ourselves in a bit
> of an impasse regarding process of accepting new deliverables. Kolla
> community grew a lot since we were singular project, and now we have 3
> deliverables already (kolla, kolla-ansible and kolla-kubernetes). 4th
> one was proposed, kolla-salt, all of them having separate core teams
> today. How to we proceed with this and following deliverables? How to
> we accept them to kolla namespace? I can think of several ways.
>
> 1) Open door policy - whoever wants to create new deliverable, is just
> free to do so.
> 2) Lightweight agreement - just 2*+2 from Kolla core team to some list
> of deliveralbes that will sit in kolla repo, potentially 2*+2 + PTL
> vote it would be good for PTL to know what he/she is PTL of;)
> 3) Majority vote from Kolla core team - much like we do with policy
> changes today
> 4) Majority vote from all Kolla deliverables core teams
>
> My personal favorite is option 2+PTL vote. We want to encourage
> experiments and new contributors to use our namespace, for both larger
> community and ease of navigation for users.
>
> One caveat to this would be to note that pre-1.0 projects are
> considered dev/experimental.
>
> Thoughts?
>
> Cheers,
> Michal
>
> __
> OpenStack Development Mailing 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] [tc][kolla] Adding new deliverables

[Michał Jastrzębski]

Hello,

New deliverable to Kolla was proposed, and we found ourselves in a bit
of an impasse regarding process of accepting new deliverables. Kolla
community grew a lot since we were singular project, and now we have 3
deliverables already (kolla, kolla-ansible and kolla-kubernetes). 4th
one was proposed, kolla-salt, all of them having separate core teams
today. How to we proceed with this and following deliverables? How to
we accept them to kolla namespace? I can think of several ways.

1) Open door policy - whoever wants to create new deliverable, is just
free to do so.
2) Lightweight agreement - just 2*+2 from Kolla core team to some list
of deliveralbes that will sit in kolla repo, potentially 2*+2 + PTL
vote it would be good for PTL to know what he/she is PTL of;)
3) Majority vote from Kolla core team - much like we do with policy
changes today
4) Majority vote from all Kolla deliverables core teams

My personal favorite is option 2+PTL vote. We want to encourage
experiments and new contributors to use our namespace, for both larger
community and ease of navigation for users.

One caveat to this would be to note that pre-1.0 projects are
considered dev/experimental.

Thoughts?

Cheers,
Michal

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

Re: [openstack-dev] [all][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

[Davanum Srinivas]

Sorry for top post: thanks to Tim Burke, we are past this and a few
other problems. Here's the latest work:

Swift - Review from Tim : https://review.openstack.org/#/c/401397/
Swift - My review (WIP) : https://review.openstack.org/#/c/416084/
DevStack - My review : https://review.openstack.org/#/c/416064/

With all these, we get to the point where s-proxy gets "stuck" and the
tls-proxy times out, logs are here:
http://logs.openstack.org/00/412500/9/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/d453c3f/logs/

Happy to turn this over to the swift team from here on.

One more good news, Thanks to the Keystone team for their very first
DevStack+python3.5 based functional test
(gate-keystone-dsvm-py35-functional-v3-only-ubuntu-xenial-nv) with
just a couple of failures left to go:
https://review.openstack.org/#/c/412500/

Thanks,
Dims

On Wed, Jan 4, 2017 at 4:49 PM, Doug Hellmann  wrote:
> Excerpts from John Dickinson's message of 2017-01-03 12:00:07 -0800:
>>
>> On 3 Jan 2017, at 10:38, Doug Hellmann wrote:
>>
>> > Excerpts from John Dickinson's message of 2017-01-03 09:02:19 -0800:
>> >>
>> >> On 2 Jan 2017, at 13:06, Davanum Srinivas wrote:
>> >>
>> >>> Folks,
>> >>>
>> >>> Short Story :
>> >>> [1] has merged in devstack, it adds support for a python 3.5 based
>> >>> up/down devstack test that just starts services and brings them down.
>> >>> see [2] for a test run.
>> >>>
>> >>> Need help from swift folks:
>> >>> Swift still needs work i have gotten as far as [3] UnpicklingError on
>> >>> ring data using [4][5][6][7]. Can someone from the swift team pick
>> >>> this up?
>> >>> Once you get this working, please add "swift" to the white list in [8]
>> >>> and remove the disable_service for swift services in [9]
>> >>
>> >> IIRC the issue is the differences between pickle, json, and arrays in py2 
>> >> vs py3 (short summary: you can't deserialize in py3 stuff that was 
>> >> serialized in py2 without first changing the py2 code).
>> >
>> > Is that right? It seems like it would be the other way around. There
>> > are newer pickle protocols in 3 that aren't available at all for 2.
>> >
>> > There are also some new options to the load() function in 3 to do
>> > things like fix imports for standard library modules that were
>> > renamed and set the right default string encoding to make it possible
>> > to change the *3* code to be able to more easily load a pickle
>> > created by 2 [1].  Is that what you meant?
>>
>> Nah, it's not the pickle protocol. It's the different way (some versions of) 
>> py27 [de]serializes arrays vs how py3 does it. The following breaks for 
>> py2.7.10 and works for py2.7.12 (.11 is untested).
>>
>> python3 -c 'import array, pickle, os, sys; pickle.dump(array.array("I", [0, 
>> 0, 0]), os.fdopen(1, "wb"), protocol=2)' | python -c 'import pickle, os, 
>> sys; print(pickle.load(os.fdopen(0, "rb")))'
>
> o_O
>
> Sigh.
>
>>
>> So maybe there are ways to always ensure doing the right thing through some 
>> combination of try/excepts, "if six.PY3" blocks, plus lots of docs for ops 
>> to make sure upgrades go smoothly, but the real solution is to not use 
>> pickle. This is doubly true when considering that the data structure will be 
>> used by non-python code, too.
>
> "Friends don't let their friends use pickle for portable persistence."
>
>>
>> This is one of the things to put on the list for py3, and it certainly is 
>> not the last.
>
> It would be good to start building up the list in the "Common Pitfalls"
> section of https://wiki.openstack.org/wiki/Python3
>
> Doug
>
>>
>> --John
>>
>> >
>> > Doug
>> >
>> > [1] https://docs.python.org/3.5/library/pickle.html#pickle.load
>> >
>> >>
>> >> We're tracking this at https://bugs.launchpad.net/swift/+bug/1644387 and 
>> >> have a patch at https://review.openstack.org/#/c/401397/, but I can't 
>> >> guarantee that services will start as soon as that patch lands. (i.e. 
>> >> it's necessary, but might not be sufficient)
>> >>
>> >> --John
>> >>
>> >>>
>> >>> Other teams:
>> >>> Please consider adding DSVM jobs with USE_PYTHON3=True for your
>> >>> projects. This will hopefully help us get to our Pike goal for Python
>> >>> 3.x [10]
>> >>>
>> >>> Please stop by #openstack-python3 channel to chat.
>> >>>
>> >>> Thanks,
>> >>> Dims
>> >>>
>> >>> [1] https://review.openstack.org/#/c/414176/
>> >>> [2] 
>> >>> http://logs.openstack.org/76/414176/11/check/gate-devstack-dsvm-py35-updown-ubuntu-xenial-nv/
>> >>> [3] 
>> >>> http://logs.openstack.org/00/412500/7/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/f5a7fe7/logs/screen-s-proxy.txt.gz
>> >>> [4] https://review.openstack.org/#/c/412500/
>> >>> [5] https://review.openstack.org/#/c/414727/
>> >>> [6] https://review.openstack.org/#/c/416064/
>> >>> [7] https://review.openstack.org/#/c/416084/
>> >>> [8] https://review.openstack.org/#/c/414176/11/inc/python
>> >>> [9] 
>> >>> https://review.openstack.org/#/c/413775/5/jenkins/jobs/devstack-gate.yaml
>> >>> [10] 

Re: [openstack-dev] [all][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

[Doug Hellmann]

Excerpts from John Dickinson's message of 2017-01-03 12:00:07 -0800:
> 
> On 3 Jan 2017, at 10:38, Doug Hellmann wrote:
> 
> > Excerpts from John Dickinson's message of 2017-01-03 09:02:19 -0800:
> >>
> >> On 2 Jan 2017, at 13:06, Davanum Srinivas wrote:
> >>
> >>> Folks,
> >>>
> >>> Short Story :
> >>> [1] has merged in devstack, it adds support for a python 3.5 based
> >>> up/down devstack test that just starts services and brings them down.
> >>> see [2] for a test run.
> >>>
> >>> Need help from swift folks:
> >>> Swift still needs work i have gotten as far as [3] UnpicklingError on
> >>> ring data using [4][5][6][7]. Can someone from the swift team pick
> >>> this up?
> >>> Once you get this working, please add "swift" to the white list in [8]
> >>> and remove the disable_service for swift services in [9]
> >>
> >> IIRC the issue is the differences between pickle, json, and arrays in py2 
> >> vs py3 (short summary: you can't deserialize in py3 stuff that was 
> >> serialized in py2 without first changing the py2 code).
> >
> > Is that right? It seems like it would be the other way around. There
> > are newer pickle protocols in 3 that aren't available at all for 2.
> >
> > There are also some new options to the load() function in 3 to do
> > things like fix imports for standard library modules that were
> > renamed and set the right default string encoding to make it possible
> > to change the *3* code to be able to more easily load a pickle
> > created by 2 [1].  Is that what you meant?
> 
> Nah, it's not the pickle protocol. It's the different way (some versions of) 
> py27 [de]serializes arrays vs how py3 does it. The following breaks for 
> py2.7.10 and works for py2.7.12 (.11 is untested).
> 
> python3 -c 'import array, pickle, os, sys; pickle.dump(array.array("I", [0, 
> 0, 0]), os.fdopen(1, "wb"), protocol=2)' | python -c 'import pickle, os, sys; 
> print(pickle.load(os.fdopen(0, "rb")))'

o_O

Sigh.

> 
> So maybe there are ways to always ensure doing the right thing through some 
> combination of try/excepts, "if six.PY3" blocks, plus lots of docs for ops to 
> make sure upgrades go smoothly, but the real solution is to not use pickle. 
> This is doubly true when considering that the data structure will be used by 
> non-python code, too.

"Friends don't let their friends use pickle for portable persistence."

> 
> This is one of the things to put on the list for py3, and it certainly is not 
> the last.

It would be good to start building up the list in the "Common Pitfalls"
section of https://wiki.openstack.org/wiki/Python3

Doug

> 
> --John
> 
> >
> > Doug
> >
> > [1] https://docs.python.org/3.5/library/pickle.html#pickle.load
> >
> >>
> >> We're tracking this at https://bugs.launchpad.net/swift/+bug/1644387 and 
> >> have a patch at https://review.openstack.org/#/c/401397/, but I can't 
> >> guarantee that services will start as soon as that patch lands. (i.e. it's 
> >> necessary, but might not be sufficient)
> >>
> >> --John
> >>
> >>>
> >>> Other teams:
> >>> Please consider adding DSVM jobs with USE_PYTHON3=True for your
> >>> projects. This will hopefully help us get to our Pike goal for Python
> >>> 3.x [10]
> >>>
> >>> Please stop by #openstack-python3 channel to chat.
> >>>
> >>> Thanks,
> >>> Dims
> >>>
> >>> [1] https://review.openstack.org/#/c/414176/
> >>> [2] 
> >>> http://logs.openstack.org/76/414176/11/check/gate-devstack-dsvm-py35-updown-ubuntu-xenial-nv/
> >>> [3] 
> >>> http://logs.openstack.org/00/412500/7/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/f5a7fe7/logs/screen-s-proxy.txt.gz
> >>> [4] https://review.openstack.org/#/c/412500/
> >>> [5] https://review.openstack.org/#/c/414727/
> >>> [6] https://review.openstack.org/#/c/416064/
> >>> [7] https://review.openstack.org/#/c/416084/
> >>> [8] https://review.openstack.org/#/c/414176/11/inc/python
> >>> [9] 
> >>> https://review.openstack.org/#/c/413775/5/jenkins/jobs/devstack-gate.yaml
> >>> [10] https://review.openstack.org/#/c/349069/
> >>>
> >>> -- 
> >>> Davanum Srinivas :: https://twitter.com/dims
> >>>
> >>> __
> >>> OpenStack Development Mailing 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] [oslo] Not running for Oslo PTL for Pike

[Doug Hellmann]

Excerpts from Joshua Harlow's message of 2017-01-03 12:03:44 -0800:
> Hi Oslo folks (and others),
> 
> Happy new year!
> 
> After serving for about a year I think it's a good opportunity for 
> myself to let another qualified individual run for Oslo PTL (seems 
> common to only go for two terms and hand-off to another).
> 
> So I just wanted to let folks know that I will be doing this, so that we 
> can grow others in the community that wish to try out being a PTL.
> 
> I don't plan on leaving the Oslo community btw, just want to make sure 
> we spread the knowledge (and the fun!) of being a PTL.
> 
> Hopefully I've been a decent PTL (with  room to improve) during 
> this time :-)
> 
> -Josh
> 

Thanks for your leadership over the past year, Josh! I'm glad to hear
you'll be staying on the team, too.

Doug

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

Re: [openstack-dev] [Release-job-failures] Release of openstack/glance failed

[Tony Breeds]

On Wed, Jan 04, 2017 at 01:31:42PM -0500, Ian Cordasco wrote:

> I believe you asked in another thread (that I cannot locate) if it was
> acceptable to the Glance team to not have an 11.0.3 tarball on
> openstack.org. With Brian on vacation, I'm hoping the other stable
> maintenance cores will chime in. I, for one, (as Release CPL and a
> Stable branch core reviewer) don't think the tarballs are critical for
> Glance. I'm fairly certain that most of the deployment projects use
> the Git repository directly or Distro provided packages (which are
> built from git tags). With that in mind, I don't think this should
> block Glance being EOL'd.

Sounds good.  We can always generate and manually upload signed tarballs and
wheels, we can't do it with our automated tools.

I'll include glance projects in the next round of EOL requests to infra.

> I'm sorry for the delay in my reply. I took a little over a week of
> time off myself.

No problem.  It's that time of year.

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] [Nova] python 3 tests hate my exception handling

[Michael Still]

Ok, I think at this point I'll propose a tweak to keystoneauth to make this
easier, and then refactor my nova code around that.

Thanks for the help everyone.

Hugs and kisses,
Michael




On Wed, Jan 4, 2017 at 4:52 PM, Morgan Fainberg 
wrote:

>
>
> On Jan 3, 2017 19:29, "Matt Riedemann"  wrote:
>
> On 1/3/2017 8:48 PM, Michael Still wrote:
>
>> So...
>>
>> Our python3 tests hate [1] my exception handling for continued
>> vendordata implementation [2].
>>
>> Basically, it goes a bit like this -- I need to move from using requests
>> to keystoneauth1 for external vendordata requests. This is because we're
>> adding support for sending keystone headers with the request so that the
>> external service can verify that it is nova talking. That bit isn't too
>> hard.
>>
>> However, keystoneauth1 uses different exceptions to report errors.
>> Conveniently, it has variables which list all of the connection and http
>> exceptions which it might raise. Inconveniently, they're listed as
>> strings, so I have to construct a list of them like this:
>>
>> # NOTE(mikal): keystoneauth makes me jump through hoops to get these
>> # exceptions, which are listed as strings. Mutter.
>> KEYSTONEAUTH_EXCEPTIONS = [TypeError, ValueError]
>> for excname in ks_exceptions.connection.__all__ +
>> ks_exceptions.http.__all__:
>> KEYSTONEAUTH_EXCEPTIONS.append(getattr(ks_exceptions, excname))
>>
>> Then when it comes time to catch exceptions from keystoneauth1, we can
>> just do this thing:
>>
>> except tuple(KEYSTONEAUTH_EXCEPTIONS) as e:
>> LOG.warning(_LW('Error from dynamic vendordata service '
>> '%(service_name)s at %(url)s: %(error)s'),
>> {'service_name': service_name,
>>  'url': url,
>>  'error': e},
>> instance=self.instance)
>> return {}
>>
>> Which might be a bit horrible, but is nice in that if keystoneauth1 adds
>> new connection or http exceptions, we get to catch them for free.
>>
>> This all works and is tested. However, it causes the py3 tests to fail
>> with this exception:
>>
>> 'TypeError: catching classes that do not inherit from BaseException is
>> not allowed'
>>
>> Which is bemusing to me because I'm not very smart.
>>
>> So, could someone smarter than me please look at [1] and tell me why I
>> get [2] and how to not get that thing? Answers involving manually
>> listing many exceptions will result in me making a sad face and
>> sarcastic comment in the code, so something more elegant than that would
>> be nice.
>>
>> Discuss.
>>
>> Thanks,
>> Michael
>>
>>
>> 1: http://logs.openstack.org/91/416391/1/check/gate-nova-python
>> 35-db/7835df3/console.html#_2017-01-04_01_10_35_520409
>> 2: https://review.openstack.org/#/c/415597/3/nova/api/metadata/
>> vendordata_dynamic.py
>>
>> --
>> Rackspace Australia
>>
>>
>> 
>> __
>> 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
>>
>>
> My first question is, does the KSA team consider the 'connection' and
> 'http' variables as public / contractual to the KSA API in the library? If
> not, they could change/remove those and break nova which wouldn't be cool.
>
>
> For what it is worth, Keystoneauth has been built very carefully so that
> everything that is public should be public (not prefixed with "_"), short
> of a massive security issue, we will not change/break an interface that is
> public (even not intentionally public); we may deprecated and warn if we
> don't want you to use the interface, but it will remain.
>
> The only time a public interface will be removed from KSA will be if we
> move to "keystoneauth2". In short, connection and HTTP variables are public
> today and will remain so (even if it was unintentional).
>
>
> For what it's worth, this is what we handle when making requests to the
> placement service using KSA:
>
> https://github.com/openstack/nova/blob/34f4b1bd68d6011da76e6
> 8c4ddae9f28e37eed9a/nova/scheduler/client/report.py#L37
>
> If nothing else, maybe that's all you'd need?
>
> Another alternative is building whatever you need into KSA itself with the
> types you need, get that released before 1/19 (non-client library release
> freeze), and then use that in nova with a minimum required version bump in
> global-requirements.
>
> Or try to hack this out some other magical way.
>
>
> I am not opposed to seeing an enhancement to KSA to make your job easier
> when handling exceptions.
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [ironic] User survey question

[Mario Villaplana]

Hi,

Here are some questions I've thought of:

TESTING / INTERESTED

- What is your use case for ironic?
- What, if anything, is preventing you from using ironic in a
production environment?
- What alternatives to ironic have you considered?

USING

- What new features would you like to see added to ironic?
- What are some gaps in ironic's documentation you'd like to see fixed?
- What's been your most frustrating or difficult experience with ironic?
- Does anyone at your organization contribute to ironic software
development upstream? (may want to rephrase "upstream" in case they're
not familiar with the term)
- What parts of your ironic deployment do you monitor, and how do you
monitor it?

Thanks for asking the community for questions.

Mario

On Wed, Jan 4, 2017 at 9:24 AM, Pavlo Shchelokovskyy
 wrote:
> Hi,
>
> from my part, if it would be appropriate, I'd like to use this opportunity
> to estimate the iPXE adoption.
>
> So the question targeting those USING and TESTING ironic would be:
>
> - does the hardware you are managing with ironic support iPXE?
> - do you use ironic with iPXE enabled? ("[pxe]ipxe_enabled = True" in
> ironic.conf)
>
> Another question would be to estimate the base of users that use
> iscsi_deploy feature and also the vendor-specific drivers. So questions for
> those USING and TESTING ironic would be:
>
> - do you rely on iscsi-based deploy method or agent-based one?
> - do you rely on common drivers like agent_ipmotool or pxe_ipmitool, or use
> vendor-specific drivers like ilo_*, drac_* etc? if using vendor specific
> drivers, what features of those are the reason for such choice?
>
> Cheers,
>
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> On Wed, Jan 4, 2017 at 2:07 PM, Jim Rollenhagen 
> wrote:
>>
>> Hey all,
>>
>> We have an opportunity to ask a question on the upcoming User Survey,
>> which will launch by February 1st. We can choose the audience to direct
>> the question to, choosing from those USING, TESTING, or INTERESTED
>> in Ironic (or some combination of these).
>>
>> The hope is that the Foundation folks can get us the raw answers before
>> the PTG.
>>
>> So, Ironicers, what question would you like to ask users, and which group
>> of
>> users would you like to ask?
>>
>> // jim
>>
>> __
>> OpenStack Development Mailing 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] [Release-job-failures] Release of openstack/glance failed

[Ian Cordasco]

-Original Message-
From: Tony Breeds 
Reply: OpenStack Development Mailing List (not for usage questions)
, OpenStack Development Mailing
List (not for usage questions) 
Date: December 14, 2016 at 00:18:38
To: OpenStack Development Mailing List (not for usage questions)

Subject:  Re: [openstack-dev] [Release-job-failures] Release of
openstack/glance failed

> On Mon, Dec 12, 2016 at 09:46:54AM -0600, Ian Cordasco wrote:
> >
> >
> > -Original Message-
> > From: Andreas Jaeger
> > Reply: OpenStack Development Mailing List (not for usage questions)
> > Date: December 12, 2016 at 01:39:17
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [Release-job-failures] Release of 
> > openstack/glance
> failed
> >
> > > On 2016-12-12 08:34, Andreas Jaeger wrote:
> > > > On 2016-12-12 06:20, Tony Breeds wrote:
> > > >> On Mon, Dec 12, 2016 at 04:44:18AM +, jenk...@openstack.org wrote:
> > > >>> Build failed.
> > > >>>
> > > >>> - glance-docs-ubuntu-xenial 
> > > >>> http://logs.openstack.org/38/38f199507aff8bfcaf81ad9ea58ea326224faf5f/release/glance-docs-ubuntu-xenial/de7d73e/
> > > : FAILURE in 1m 44s
> > > >>
> > > >> This boils down to [1] which is a known problem with newer 
> > > >> cryptography (and
> > > >> the interaction with openssl). What I don't understand is how we got 
> > > >> there
> > > >> with constratints working[2]. Perhaps it's the openssl on the release 
> > > >> sigining
> > > >> node is "newer" than general nodepool nodes?
> > > >
> > > > glance does not use constraints in venv environment.
> > > >
> > > > It can be used since a few months. I'll send a change for master,
> > >
> > > I expect this needs backporting to stable branches - stable or glance
> > > team, please review and backport yourself:
> > >
> > > https://review.openstack.org/409642
> >
> >
> > Thank you Andreas!
>
> https://review.openstack.org/#/c/410536 is the backport but it's still failing
> with the same
> issue with cryptography and openssl[1] :(
>
> Yours Tony.
> [1] 
> http://logs.openstack.org/36/410536/1/check/gate-glance-releasenotes/46c2615/console.html#_2016-12-14_05_13_53_002878

Hi Tony,

So if I understand correctly, presently:

- There is no 11.0.3 tag for glance which is what we planned to use to
tag liberty-eol
- There is no 11.0.3 tarball for glance
- There is no good way to generate a 11.0.3 tarball because of the
cryptography & openssl conflict
- There is also no good way to generate a liberty-eol tarsal because
of that issue.

I believe you asked in another thread (that I cannot locate) if it was
acceptable to the Glance team to not have an 11.0.3 tarball on
openstack.org. With Brian on vacation, I'm hoping the other stable
maintenance cores will chime in. I, for one, (as Release CPL and a
Stable branch core reviewer) don't think the tarballs are critical for
Glance. I'm fairly certain that most of the deployment projects use
the Git repository directly or Distro provided packages (which are
built from git tags). With that in mind, I don't think this should
block Glance being EOL'd.

I'm sorry for the delay in my reply. I took a little over a week of
time off myself.

Cheers,
--
Ian Cordasco

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

Re: [openstack-dev] [Telemetry] Asking a question to our users

[gordon chung]

On 04/01/17 12:08 PM, Julien Danjou wrote:
> I _think_ they ask for what "release of OpenStack" is being used, but
> that might be it.

i would probably do something similar to what Mehdi suggested then. i 
don't think we want feedback relating to ceilometer storage/api (because 
it's been dead for a long time) or feedback on polling (because no one 
will have had time to test the nova-free polling stuff we're 
implementing currently)



cheers,
-- 
gord

ps. yes, i used this response to promote work we're doing.

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

[openstack-dev] [keystone] documenting policy guidelines

[Lance Bragstad]

We had another healthy discussion about policy today [0] and most of it
revolved around documenting policy guidelines. The question of the day was
where should these guidelines live? To answer that we highlighted the
following criteria:

- Guidelines should be proposed and reviewed in small changes. We don't
want a single person doing all of the work, so a collaboration-friendly
approach to documenting guidelines would be awesome.
- They should be amendable so that we can make tweaks as we go.
- They should be discoverable such that new projects can use them to
implement policy checks right away, and exiting projects have a reference
to work towards.

 By the end of the meeting, it sounded like we had three options:

1.) Merge a cross-project specification that we can incrementally
contribute guidelines to.
2.) Make policy documentation a community-wide goal, approved by the TC
(possibly a project tag?).
3.) Convert the weekly policy meeting to a working group and document
guidelines using existing working group processes.

Various folks weighed in on each during the meeting, but we didn't reach a
conclusion. Which one should we pursue? Is there a better place for this
type of documentation that we didn't think of?

Thanks!

Lance

[0]
http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-01-04-16.00.log.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Telemetry] Asking a question to our users

[Julien Danjou]

On Wed, Jan 04 2017, gordon chung wrote:

> is there a way to scope our question/responses? feedback is good but it 
> isn't the most useful when we get feedback based on Liberty.

I _think_ they ask for what "release of OpenStack" is being used, but
that might be it.

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


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] [heat] project specific question for the next user survey

[Rico Lin]

Dear Team
Let's put some thoughts here[1] in next 24h.
Any idea/suggestion to this heat adoption question are welcome.
It will be great if we can get some really useful information from users by
given the right question.

[1] https://etherpad.openstack.org/p/ocata-heat-user-survey


2017-01-02 12:18 GMT+08:00 Rabi Mishra :

> Hi All,
>
> We have an opportunity to submit a heat adoption related question (for
> those who are USING, TESTING, or INTERESTED in heat) to be included in the
> User Survey.
>
> Please provide your suggestions/questions.*The deadline for this is 9th
> Jan.*
>
> --
> Regards,
> Rabi Misra
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
May The Force of OpenStack Be With You,



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

Re: [openstack-dev] [ironic] [nova] Ironic virt driver resources reporting

[Vladyslav Drok]

On Wed, Jan 4, 2017 at 5:45 PM, Vladyslav Drok  wrote:

> Thanks all for replies!
>
> On Tue, Jan 3, 2017 at 5:16 PM, Jay Faulkner  wrote:
>
>> Hey Vdrok, some comments inline.
>>
>> > On Dec 30, 2016, at 8:40 AM, Vladyslav Drok  wrote:
>> >
>> > Hi all!
>> >
>> > There is a long standing problem of resources reporting in ironic virt
>> driver. It's described in a couple of bugs I've found - [0], [1]. Switching
>> to placement API will make things better, but still there are some problems
>> there. For example, there are cases when ironic needs to say "this node is
>> not available", and it reports the vcpus=memory_mb=local_gb as 0 in this
>> case. Placement API does not allow 0s, so in [2] it is proposed to remove
>> inventory records in this case.
>> >
>> > But the whole logic here [3] seems not that obvious to me, so I'd like
>> to discuss when do we need to report 0s to placement API. I'm thinking
>> about the following (copy-pasted from my comment on [2]):
>> >
>> >   • If there is an instance_uuid on the node, no matter what
>> provision/power state it's in, consider the resources as used. In case it's
>> an orphan, an admin will need to take some manual action anyway.
>>
>> This won’t work, because of https://bugs.launchpad.net/nova/+bug/1503453
>> — basically the Nova resource tracker checks, decides we’re lying about it
>> being used for an instance because Nova’s records don’t show we do, and it
>> reads the capacity to the pool.
>>
>
> Aha, I see, after looking at code a bit more and discussing with JayF,
> that happens during update_available_resource here
> https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636
> 829759b80f/nova/compute/resource_tracker.py#L921-L934, where "instances"
> are all instances assigned to current host and node. Though, I don't really
> like the fact that _used amount is greater than the 
> amount that is possible here - https://github.com/openstack/nova/blob/
> 372452a1f703115310ea3400f9f636829759b80f/nova/virt/ironic/
> driver.py#L301-L326, as it makes the free values reported to be negative
> (I can't find the place where they are set to 0 if negative). Maybe we
> could at least report 0 for both available and used amounts?
>

OK, I must be blind, it is set to 0 if negative here
https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636829759b80f/nova/compute/resource_tracker.py#L938-L939,
so it should be fine, apart from the fact that used value will be greater
than available.


>
>
>>
>> Generally I agree with Jay Pipes’ comments — we should have available
>> resources for nodes that can be scheduled to, used resources for nodes with
>> with a nova instance, and report no resources whatsoever for nodes in an
>> unschedulable state, such as cleaning, enroll, etc.
>>
>> -
>> Jay Faulkner
>> OSIC
>>
>> >   • If there is no instance_uuid and a node is in cleaning/clean
>> wait after tear down, it is a part of normal node lifecycle, report all
>> resources as used. This means we need a way to determine if it's a manual
>> or automated clean.
>> >   • If there is no instance_uuid, and a node:
>> >   • has a bad power state or
>> >   • is in maintenance
>> >   • or actually in any other case, consider it unavailable,
>> report available resources = used resources = 0. Provision state does not
>> matter in this logic, all cases that we wanted to take into account are
>> described in the first two bullets.
>> >
>> > Any thoughts?
>> >
>> > [0]. https://bugs.launchpad.net/nova/+bug/1402658
>> > [1]. https://bugs.launchpad.net/nova/+bug/1637449
>> > [2]. https://review.openstack.org/414214
>> > [3]. https://github.com/openstack/nova/blob/1506c36b4446f6ba1487a
>> 2d68e4b23cb3fca44cb/nova/virt/ironic/driver.py#L262
>> >
>> > Happy holidays to everyone!
>> > -Vlad
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Telemetry] Asking a question to our users

[gordon chung]

On 26/12/16 05:20 AM, Julien Danjou wrote:
> Hi folks,
>
> The foundation is offering the opportunity to ask a question to users:
>
>   "I wanted to offer you the opportunity to ask a question on the
>   upcoming User Survey, which launches on or before Feb. 1. Each PTL of
>   a project with significant adoption can submit one question. You can
>   decide which audience to serve the question to - those who are USING,
>   TESTING, or INTERESTED in your project (or some combination of these)."
>
> Would anyone have an interesting idea/question to ask our beloved users?
>

is there a way to scope our question/responses? feedback is good but it 
isn't the most useful when we get feedback based on Liberty.


-- 
gord

__
OpenStack Development Mailing List (not for 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] [ci] TripleO-Quickstart Transition to TripleO-CI Update and Invite:

[Attila Darazs]

On 01/04/2017 10:34 AM, Steven Hardy wrote:

Hi Harry,

On Tue, Jan 03, 2017 at 04:04:51PM -0500, Harry Rybacki wrote:

Greetings All,

Folks have been diligently working on the blueprint[1] to prepare
TripleO-Quickstart (OOOQ)[2] and TripleO-Quickstart-Extras[3] for
their transition into TripleO-CI. Presently, our aim is to begin the
actual transition to OOOQ on 4-Feb-2017. We are tracking our work on
the RDO-Infra Trello board[4] and holding public discussion of key
blockers on the team’s scrum etherpad[5].


Thanks for the update - can you please describe what "transition into
TripleO-CI" means?


Hello Steve,

This means we're trying to run all the gate jobs with Quickstart and 
make sure we have the same features enabled and results for each 
existing gate jobs.



I'm happy to see this work proceeding, but we have to be mindful that the
end of the development cycle (around the time you're proposing) is always
a crazy-busy time where folks are trying to land features and fixes.

So, we absolutely must avoid any CI outages around this time, thus I get
nervous talking about major CI transitions around the Release-candate
weeks ;)

https://releases.openstack.org/ocata/schedule.html

If we're talking about getting the jobs ready, then switching over to
primarily oooq jobs in early pike, that's great, but please lets ensure we
don't may any disruptive changes before the end of this (very short and
really busy) cycle.


As I see the early pike is only 2 week away from our planned switch, it 
might be wiser to delay it indeed. The end-of-cycle stability might be 
even useful for us to run some new jobs parallel for a while if we have 
enough resources.



We are hosting weekly transition update meetings (1600-1700 UTC) and
would like to invite folks to participate. Specifically, we are
looking for at least one stakeholder in the existing TripleO-CI to
join us as we prepare to migrate OOOQ. Attend and map out job/feature
coverage to identify any holes so we can begin plugging them. Please
reply off-list or reach out to me (hrybacki) on IRC to be added to the
transition meeting calendar invite.


Why can't we discuss this in the weekly TripleO IRC meeting?

I think folks would be fine with having a standing item where we dicscuss
this transition (there is already a CI item, but I've rarely seen this
topic raised there).


I agree that we should have a standing item about this in the TripleO 
meeting, however this transition meeting usually takes an hour a week in 
itself, so we cannot really fit it into the TripleO meeting.


Also why we ask somebody well versed in the TripleO CI to join us is 
that we might get answers to questions we didn't even know we had. There 
are probably shortcuts and known workarounds to what we're trying to 
achieve in the upstream system that we're not familiar with.


Also the discussion is focused on Quickstart (for example how to develop 
some roles that unify different workloads like OVB and nodepool), so it 
wouldn't be relevant for the TripleO meeting entirely.


Thus the request still stands, I think we could get a big help with 
somebody familiar with the CI system. This should be a once a week 
meeting for only the following 3-6 weeks.


We will make a short status from now on about the current state of the 
transition on the TripleO meetings though.


Thank you for your thoughts,
Attila


https://wiki.openstack.org/wiki/Meetings/TripleO

Thanks!

Steve

__
OpenStack Development Mailing 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] [acceleration]Team Bi-weekly Meeting 2017.1.4 Agenda

[Zhipeng Huang]

Hi Team,

Thanks for a great discussion at today's meeting, please find the minutes
at https://wiki.openstack.org/wiki/Cyborg/MeetingLogs#2017-01-04

On Wed, Jan 4, 2017 at 10:40 PM, Miroslav Halas  wrote:

> Howard and team,
>
>
>
> I have usually conflict at this time,  but I am trying to keep up with
> meeting logs and etherpads J. Either Scott or I will be at PTG
> representing Lenovo so we would be happy to participate.
>
>
>
> From last meeting I have added TODO to Nasca etherpard to link the design
> document and the code being discussed. I cannot seem to locate the original
> files Mellanox team shared with us. Would somebody who know where these are
> shared be able to insert the links to the etherpad
> https://etherpad.openstack.org/p/cyborg-nasca-design
>
>
>
> Thank you,
>
>
>
> Miro Halas
>
>
>
> *From:* Harm Sluiman [mailto:harm.slui...@gmail.com]
> *Sent:* Wednesday, January 04, 2017 9:22 AM
> *To:* Zhipeng Huang
> *Cc:* OpenStack Development Mailing List (not for usage questions);
> Miroslav Halas; rodolfo.alonso.hernan...@intel.com; Michele Paolino;
> Scott Kelso; Roman Dobosz; Jim Golden; pradeep.jagade...@huawei.com;
> michael.ro...@nokia.com; jian-feng.d...@intel.com; martial.mic...@nist.gov;
> Moshe Levi; Edan David; Francois Ozog; Fei K Chen; jack...@huawei.com;
> li.l...@huawei.com
> *Subject:* Re: [acceleration]Team Bi-weekly Meeting 2017.1.4 Agenda
>
>
>
> Happy New Year everyone.
>
> I won't be able participate in the IRC today due to a conflict, but I will
> try to connect and monitor.
>
> I will also put more comments in the etherpads that are linked
>
>
>
>
>
> On Wed, Jan 4, 2017 at 6:28 AM, Zhipeng Huang 
> wrote:
>
> Hi Team,
>
>
>
> Please find the agenda at https://wiki.openstack.org/wiki/Meetings/
> CyborgTeamMeeting#Agenda_for_next_meeting
>
>
>
> our IRC channel is #openstack-cyborg
>
>
>
> --
>
> Zhipeng (Howard) Huang
>
>
>
> Standard Engineer
>
> IT Standard & Patent/IT Prooduct 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
>
>
>
>
>
> --
>
> 宋慢
> Harm Sluiman
>
>
>
>


-- 
Zhipeng (Howard) Huang

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

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

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

Re: [openstack-dev] [tripleo] [ci] TripleO-Quickstart Transition to TripleO-CI Update and Invite:

[Wesley Hayutin]

Greetings Steve

On Wed, Jan 4, 2017 at 4:34 AM, Steven Hardy  wrote:

> Hi Harry,
>
> On Tue, Jan 03, 2017 at 04:04:51PM -0500, Harry Rybacki wrote:
> > Greetings All,
> >
> > Folks have been diligently working on the blueprint[1] to prepare
> > TripleO-Quickstart (OOOQ)[2] and TripleO-Quickstart-Extras[3] for
> > their transition into TripleO-CI. Presently, our aim is to begin the
> > actual transition to OOOQ on 4-Feb-2017. We are tracking our work on
> > the RDO-Infra Trello board[4] and holding public discussion of key
> > blockers on the team’s scrum etherpad[5].
>
> Thanks for the update - can you please describe what "transition into
> TripleO-CI" means?
>

Hey Steve,
This includes items like the following.

* Move all oooq-extras roles upstream
* Ensure check gates are all working.
* Ensure oooq works with multinode nodepool
* Ensure the logging of jobs upstream with oooq is equivilant to the
current logs and familiar to devs
* Ensure the existing tripleo-ci can co-exist with oooq
* Ensure the documentation is clear for developers
* Ensure oooq-extras roles are composable and consistent across various
infrastructure like upstream,
rdo, internal, local builds.


> I'm happy to see this work proceeding, but we have to be mindful that the
> end of the development cycle (around the time you're proposing) is always
> a crazy-busy time where folks are trying to land features and fixes.
>
> So, we absolutely must avoid any CI outages around this time, thus I get
> nervous talking about major CI transitions around the Release-candate
> weeks ;)
>
> https://releases.openstack.org/ocata/schedule.html
>
> If we're talking about getting the jobs ready, then switching over to
> primarily oooq jobs in early pike, that's great, but please lets ensure we
> don't may any disruptive changes before the end of this (very short and
> really busy) cycle.
>

That sounds fair to me, would pushing out the transition a couple weeks be
a reasonable change?
Looking at the calendar, Feb 27 is after the release of Ocata also March
6th could also be an option.


>
> > We are hosting weekly transition update meetings (1600-1700 UTC) and
> > would like to invite folks to participate. Specifically, we are
> > looking for at least one stakeholder in the existing TripleO-CI to
> > join us as we prepare to migrate OOOQ. Attend and map out job/feature
> > coverage to identify any holes so we can begin plugging them. Please
> > reply off-list or reach out to me (hrybacki) on IRC to be added to the
> > transition meeting calendar invite.
>
> Why can't we discuss this in the weekly TripleO IRC meeting?
>

I've added to the agenda for next week.  Harry and I will fill in details.


>
> I think folks would be fine with having a standing item where we dicscuss
> this transition (there is already a CI item, but I've rarely seen this
> topic raised there).
>
> https://wiki.openstack.org/wiki/Meetings/TripleO
>
> Thanks!
>
> Steve
>

Thank you for the feedback!


>
> __
> OpenStack Development Mailing 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] Feedback for upcoming user survey questionnaire

[Steve Martinelli]

I quite like Boris' last suggestion, with a minor tweak:

"In your opinion, what keystone feature(s) requires more attention (select
all that apply): "federation", "performance", "policy", "scaling out",
"backend support", "ldap"."

Unless someone has another suggestion I'll stick to the above.

On Wed, Jan 4, 2017 at 9:18 AM, Lance Bragstad  wrote:

> ++ to the suggestions Boris threw out. Answers to any of those would be
> valuable. In addition to that, I'd find any information about policy
> useful. Maybe something along the lines of "what changes to the policy
> files are you making, if any". This could be something that is asked
> OpenStack-wide (which I'm sure we've done at some point in the past) but it
> would also be interesting on a per-project basis.
>
> On Tue, Jan 3, 2017 at 3:05 PM, Boris Bobrov  wrote:
>
>> "What were you trying to accomplish with keystone but failed"
>> "What functionality in keystone did you try to use but it wasn't good
>> enough"
>> "In your opinion, what in keystone requires most attention"
>> with choices "federation", "performance", "policy", "backend support"
>> and some other options.
>>
>> On 12/30/2016 11:54 PM, Steve Martinelli wrote:
>> > We have the opportunity to ask one question on the
>> > upcoming user survey and we get to decide the audience to which we serve
>> > the question.
>> >
>> > __ __
>> >
>> > Our audience options are: USING, TESTING, or INTERESTED in Keystone (I
>> > think we should aim for USING or TESTING)
>> >
>> > __ __
>> >
>> > The question can take one of several forms; multiple choice (select one
>> > or more), or short answer.
>> >
>> > __ __
>> >
>> > Post your suggestions here or email them to me privately ASAP so I can
>> > respond to the team assembling the survey in sufficient time.
>> >
>> >
>> >
>> > stevemar
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca]Monasca event handling capabilities

[Brandt, Ryan]

Hello,

Monasca events handling is an early work in progress, see 
https://wiki.openstack.org/wiki/Monasca/Events for some information.

Information on what metrics are available from each plugin can be found at 
https://github.com/openstack/monasca-agent/blob/master/docs/Plugins.md

Custom checks are at 
https://github.com/openstack/monasca-agent/tree/master/monasca_agent/collector/checks_d
Detection plugins are at 
https://github.com/openstack/monasca-agent/tree/master/monasca_setup/detection/plugins

For reference, detection plugins are used to configure check plugins which 
actually collect the metrics. Neutron doesn't have a check plugin, instead it's 
detection plugin configures some standard check plugins to monitor processes 
and http health.

Ryan

From: Pradeep Singh >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, January 3, 2017 at 11:01 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [monasca]Monasca event handling capabilities

Hello,

Please excuse  me if i asked this question on wrong mailing list.

I have few queries related to Monasca.

1) How do Monasca collects events releases by other openstack services like 
Nova and Cinder?
2) Can monasca collects the metrics from Neutron and other SDN controllers?

please guide me for any documentation if available.

I will be really thankful to you.

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] [Performance] PTG?

[Andrey Kurilin]

Hi, Joe!

It is not a mistake. After a talk with Dina B., we decided to extend Rally
session for the wider
audience and I requested "Rally & Performance team" session.

On Wed, Jan 4, 2017 at 5:29 PM, Joe Talerico  wrote:

> When I signed up to attend the PTG, Performance was not listed as a
> option, however on the website it clearly shows Performance is
> Monday-Tuesday.
>
> Is this just a mistake in the event website?
>
> Joe
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [Trove] Trove Meeting on 4 Jan canceled

[Nikhil Manchanda]

Hey folks:

There's not much to discuss on the Agenda for this week [1] and most
folks are still getting back from the Holidays, so let's cancel the
Trove meeting for this week.

We will have the Trove meeting next week on Wednesday, January 11th.

Thanks,
Nikhil

[1] https://wiki.openstack.org/wiki/Meetings/TroveMeeting
__
OpenStack Development Mailing List (not for 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] [nova] Ironic virt driver resources reporting

[Vladyslav Drok]

Thanks all for replies!

On Tue, Jan 3, 2017 at 5:16 PM, Jay Faulkner  wrote:

> Hey Vdrok, some comments inline.
>
> > On Dec 30, 2016, at 8:40 AM, Vladyslav Drok  wrote:
> >
> > Hi all!
> >
> > There is a long standing problem of resources reporting in ironic virt
> driver. It's described in a couple of bugs I've found - [0], [1]. Switching
> to placement API will make things better, but still there are some problems
> there. For example, there are cases when ironic needs to say "this node is
> not available", and it reports the vcpus=memory_mb=local_gb as 0 in this
> case. Placement API does not allow 0s, so in [2] it is proposed to remove
> inventory records in this case.
> >
> > But the whole logic here [3] seems not that obvious to me, so I'd like
> to discuss when do we need to report 0s to placement API. I'm thinking
> about the following (copy-pasted from my comment on [2]):
> >
> >   • If there is an instance_uuid on the node, no matter what
> provision/power state it's in, consider the resources as used. In case it's
> an orphan, an admin will need to take some manual action anyway.
>
> This won’t work, because of https://bugs.launchpad.net/nova/+bug/1503453
> — basically the Nova resource tracker checks, decides we’re lying about it
> being used for an instance because Nova’s records don’t show we do, and it
> reads the capacity to the pool.
>

Aha, I see, after looking at code a bit more and discussing with JayF, that
happens during update_available_resource here
https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636829759b80f/nova/compute/resource_tracker.py#L921-L934,
where "instances" are all instances assigned to current host and node.
Though, I don't really like the fact that _used amount is greater
than the  amount that is possible here -
https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636829759b80f/nova/virt/ironic/driver.py#L301-L326,
as it makes the free values reported to be negative (I can't find the place
where they are set to 0 if negative). Maybe we could at least report 0 for
both available and used amounts?


>
> Generally I agree with Jay Pipes’ comments — we should have available
> resources for nodes that can be scheduled to, used resources for nodes with
> with a nova instance, and report no resources whatsoever for nodes in an
> unschedulable state, such as cleaning, enroll, etc.
>
> -
> Jay Faulkner
> OSIC
>
> >   • If there is no instance_uuid and a node is in cleaning/clean
> wait after tear down, it is a part of normal node lifecycle, report all
> resources as used. This means we need a way to determine if it's a manual
> or automated clean.
> >   • If there is no instance_uuid, and a node:
> >   • has a bad power state or
> >   • is in maintenance
> >   • or actually in any other case, consider it unavailable,
> report available resources = used resources = 0. Provision state does not
> matter in this logic, all cases that we wanted to take into account are
> described in the first two bullets.
> >
> > Any thoughts?
> >
> > [0]. https://bugs.launchpad.net/nova/+bug/1402658
> > [1]. https://bugs.launchpad.net/nova/+bug/1637449
> > [2]. https://review.openstack.org/414214
> > [3]. https://github.com/openstack/nova/blob/
> 1506c36b4446f6ba1487a2d68e4b23cb3fca44cb/nova/virt/ironic/driver.py#L262
> >
> > Happy holidays to everyone!
> > -Vlad
> > 
> __
> > OpenStack Development Mailing 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] [all][ptls][tc][goals] community goals for Pike

[Emilien Macchi]

On Mon, Dec 19, 2016 at 2:09 PM, Doug Hellmann  wrote:
> Excerpts from Emilien Macchi's message of 2016-11-29 19:39:03 -0500:
>
>> 3) Choose Goals for Pike.
>> Some of us already did, but we might want to start looking at what
>> Goals we would like to achieve during Pike cycle.
>> I was thinking at giving a score to the Goals, that could be
>> calculated by its priority (I know it's vague but we know what is
>> really urgent for us versus what can wait 6 months); but also the
>> number of people who are interested to contribute on a Goal (if this
>> Goal doesn't have a team yet).
>> For now, openstack/governance is the repository for Goals, please
>> propose them here.
>
> I have updated the Python 3 goal, previously discussed for Ocata, to
> reflect some of the feedback and prepare it for discussion for Pike.

Thanks, it seems we have 2 good candidates for Pike:

- https://review.openstack.org/#/c/369749/ - split out tempest plugins
(still under review)
- https://review.openstack.org/349069 - Python 3 (seems ready to be merged)

During the TC meeting, we agreed on:
- 2 goals might be enough for Pike cycle.
- the deadline to define Pike goals would be Ocata-3 (Jan 23-27 week).

Looking at the etherpad: https://etherpad.openstack.org/p/community-goals
We can see some goals require some discussion, about goal scope,
implementation, etc. I would suggest Goal "owners" to communicate over
the mailing-list so we can have pro-active discussion and make
progress on the goals for future cycles.
I'm also adding product-wg list in CC, so they're aware about our efforts again.
Last but not least, we might want to split some goals, that seem to be
"too big" and might want to take baby-steps approach (eg: rolling
upgrades).

Any feedback is welcome,

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



-- 
Emilien Macchi

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

Re: [openstack-dev] [Monasca]

[Brandt, Ryan]

Apologies for the delay in response, just returning from the holidays.

>From the trace, it would appear the monasca API is unable to authenticate with 
>keystone. The API’s admin credentials may not be valid (either they do not 
>exist in keystone or are configured incorrectly for the API) which would cause 
>the API to be unable to validate tokens on incoming requests. The admin 
>credentials for the python monasca API are under [keystone_authtoken] in 
>‘/etc/monasca/api-config.conf’.

Ryan

From: Sanjana Pai Nagarmat >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, January 2, 2017 at 1:48 AM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [Monasca]

Hello,


I have a clean install of monasca-api and monasca-log-management plugins with 
devstack on ubuntu 14.04.
However when I try using the monasca CLI, I get HTTP 503:Service Unavailable 
error.
I tried accessing the monasca dashboard in Horizon, but that also throws error.

ubuntu@monasca:~$ monasca metric-list
ERROR (exc:80) exception: {"message": "The server is currently unavailable. 
Please try again at a later time.\n\n\n", "code": "503 Service 
Unavailable", "title": "Service Unavailable"}
HTTPException code=503 message={"message": "The server is currently 
unavailable. Please try again at a later time.\n\n\n", "code": "503 
Service Unavailable", "title": "Service Unavailable"}
ubuntu@monasca:~$


The monasca-api log file has the following contents:
2017-01-02 08:15:20,158 DEBUG [gunicorn.error][GreenThread-2] Closing 
connection.
2017-01-02 08:15:24,952 DEBUG [gunicorn.error][GreenThread-5] GET /v2.0/metrics
2017-01-02 08:15:24,954 DEBUG [keystonemiddleware.auth_token][GreenThread-5] 
Authenticating user token
2017-01-02 08:15:24,957 DEBUG [keystoneauth.identity.v2][GreenThread-5] Making 
authentication request to http://127.0.0.1:35357/v2.0/tokens
2017-01-02 08:15:24,964 INFO 
[requests.packages.urllib3.connectionpool][GreenThread-5] Resetting dropped 
connection: 127.0.0.1
2017-01-02 08:15:27,342 DEBUG 
[requests.packages.urllib3.connectionpool][GreenThread-5] "POST /v2.0/tokens 
HTTP/1.1" 401 114
2017-01-02 08:15:27,343 DEBUG [keystoneauth.session][GreenThread-5] Request 
returned failure status: 401
2017-01-02 08:15:27,345 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Identity server rejected authorization
2017-01-02 08:15:27,346 WARNING [keystonemiddleware.auth_token][GreenThread-5] 
Identity response: {"error": {"message": "The request you have made requires 
authentication.", "code": 401, "title": "Unauthorized"}}
2017-01-02 08:15:27,346 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Retrying validation
2017-01-02 08:15:27,347 DEBUG [keystoneauth.identity.v2][GreenThread-5] Making 
authentication request to http://127.0.0.1:35357/v2.0/tokens
2017-01-02 08:15:27,535 DEBUG 
[requests.packages.urllib3.connectionpool][GreenThread-5] "POST /v2.0/tokens 
HTTP/1.1" 401 114
2017-01-02 08:15:27,536 DEBUG [keystoneauth.session][GreenThread-5] Request 
returned failure status: 401
2017-01-02 08:15:27,536 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Identity server rejected authorization
2017-01-02 08:15:27,536 WARNING [keystonemiddleware.auth_token][GreenThread-5] 
Identity response: {"error": {"message": "The request you have made requires 
authentication.", "code": 401, "title": "Unauthorized"}}
2017-01-02 08:15:27,536 CRITICAL [keystonemiddleware.auth_token][GreenThread-5] 
Unable to validate token: Identity server rejected authorization necessary to 
fetch token data
2017-01-02 08:15:27,539 DEBUG [gunicorn.error][GreenThread-5] Closing 
connection.


Further the AUTH_URL is set
ubuntu@monasca:/var/log/monasca/api$ echo $OS_AUTH_URL
http://127.0.0.1:35357/v3/

I would like to mention the status of services:
ubuntu@monasca:~$ sudo service monasca-log-api status
monasca-log-api start/running, process 7938

ubuntu@monasca:~$ sudo service monasca-api status
monasca-api start/running, process 21465

ubuntu@monasca:~/devstack$ keystone service list
Ignoring domain related config project_domain_name because identity API version 
is 2.0
Ignoring domain related config user_domain_name because identity API version is 
2.0
Ignoring domain related config project_domain_name because identity API version 
is 2.0
Ignoring domain related config user_domain_name because identity API version is 
2.0
Ignoring domain related config project_domain_name because identity API version 
is 2.0
Ignoring domain related config user_domain_name because identity API version is 
2.0
+--+-++
| ID   | Name| Type   |

[openstack-dev] [Performance] PTG?

[Joe Talerico]

When I signed up to attend the PTG, Performance was not listed as a
option, however on the website it clearly shows Performance is
Monday-Tuesday.

Is this just a mistake in the event website?

Joe

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

Re: [openstack-dev] [nova] Outlook on Ocata blueprints

[Matt Riedemann]

On 1/4/2017 12:07 AM, Shiina, Hironori wrote:

Hi Matt,

In Not started / blocked group in 
https://etherpad.openstack.org/p/nova-ocata-feature-freeze :
  https://blueprints.launchpad.net/nova/+spec/inject-nmi-ironic (Tang Chen)
No Nova code changes yet, several Ironic patches outstanding, so probably 
not going to happen for Nova in Ocata.
Nova code change for this blueprint was already posted.
  https://review.openstack.org/#/c/376548/

Thanks,
Hironori Shiina



Thanks for pointing that out, I've updated the status in the etherpad. 
The nova change is up, but is dependent on the python-ironicclient 
change which is dependent on the Ironic API change, and none of those 
are merged yet. The client change would have to be merged and released 
by January 19th so it's getting pretty tight for that series which is 
why I marked the nova blueprint as blocked.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [ux] Future of the OpenStack UX team

[Thierry Carrez]

Hi everyone,

Piet recently reached out to me to explain that he won't be able to
continue in his role as OpenStack UX team's PTL. Since he created the
team and spent a lot of time coordinating its activities, that raises
the question of the future of the OpenStack UX team.

The situation was discussed at the TC meeting yesterday[1] and the
general feeling was that there was a lot of value in a separate team
centralizing things like Persona definition and facilitating
properly-conducted UX surveys. That said, if nobody is able to dedicate
the time that effort needs, we could also disband the centralized team
and encourage every project to adopt the tools and techniques that were
built and introduced by the UX team in the past years.

So... What are your thoughts on those options ? Do we have a volunteer
(or more than one) to take over UX PTLship ?

[1]
http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-03-20.00.log.html#l-404

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [acceleration]Team Bi-weekly Meeting 2017.1.4 Agenda

[Miroslav Halas]

Howard and team,

I have usually conflict at this time,  but I am trying to keep up with meeting 
logs and etherpads ☺. Either Scott or I will be at PTG representing Lenovo so 
we would be happy to participate.

From last meeting I have added TODO to Nasca etherpard to link the design 
document and the code being discussed. I cannot seem to locate the original 
files Mellanox team shared with us. Would somebody who know where these are 
shared be able to insert the links to the etherpad 
https://etherpad.openstack.org/p/cyborg-nasca-design

Thank you,

Miro Halas

From: Harm Sluiman [mailto:harm.slui...@gmail.com]
Sent: Wednesday, January 04, 2017 9:22 AM
To: Zhipeng Huang
Cc: OpenStack Development Mailing List (not for usage questions); Miroslav 
Halas; rodolfo.alonso.hernan...@intel.com; Michele Paolino; Scott Kelso; Roman 
Dobosz; Jim Golden; pradeep.jagade...@huawei.com; michael.ro...@nokia.com; 
jian-feng.d...@intel.com; martial.mic...@nist.gov; Moshe Levi; Edan David; 
Francois Ozog; Fei K Chen; jack...@huawei.com; li.l...@huawei.com
Subject: Re: [acceleration]Team Bi-weekly Meeting 2017.1.4 Agenda

Happy New Year everyone.
I won't be able participate in the IRC today due to a conflict, but I will try 
to connect and monitor.
I will also put more comments in the etherpads that are linked


On Wed, Jan 4, 2017 at 6:28 AM, Zhipeng Huang 
> wrote:
Hi Team,

Please find the agenda at 
https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting

our IRC channel is #openstack-cyborg

--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct 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



--
宋慢
Harm Sluiman



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

Re: [openstack-dev] [Telemetry] Asking a question to our users

[Mehdi Abaakouk]

I haven't answer before because that just one question, and I'm not sure
about what is really interesting for us. But what about something like:

Which backend/dispatcher/publusher their use ? Do their switch to Gnocchi ?

On Wed, Jan 04, 2017 at 03:31:04PM +0100, Julien Danjou wrote:

On Mon, Dec 26 2016, Julien Danjou wrote:

Nothing? :)


Hi folks,

The foundation is offering the opportunity to ask a question to users:

  "I wanted to offer you the opportunity to ask a question on the
  upcoming User Survey, which launches on or before Feb. 1. Each PTL of
  a project with significant adoption can submit one question. You can
  decide which audience to serve the question to - those who are USING,
  TESTING, or INTERESTED in your project (or some combination of these)."

Would anyone have an interesting idea/question to ask our beloved users?

Cheers,


--
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info





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



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

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

Re: [openstack-dev] [Telemetry] Asking a question to our users

[Julien Danjou]

On Mon, Dec 26 2016, Julien Danjou wrote:

Nothing? :)

> Hi folks,
>
> The foundation is offering the opportunity to ask a question to users:
>
>   "I wanted to offer you the opportunity to ask a question on the
>   upcoming User Survey, which launches on or before Feb. 1. Each PTL of
>   a project with significant adoption can submit one question. You can
>   decide which audience to serve the question to - those who are USING,
>   TESTING, or INTERESTED in your project (or some combination of these)."
>
> Would anyone have an interesting idea/question to ask our beloved users?
>
> Cheers,

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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

Re: [openstack-dev] [ironic] User survey question

[Pavlo Shchelokovskyy]

Hi,

from my part, if it would be appropriate, I'd like to use this opportunity
to estimate the iPXE adoption.

So the question targeting those USING and TESTING ironic would be:

- does the hardware you are managing with ironic support iPXE?
- do you use ironic with iPXE enabled? ("[pxe]ipxe_enabled = True" in
ironic.conf)

Another question would be to estimate the base of users that use
iscsi_deploy feature and also the vendor-specific drivers. So questions for
those USING and TESTING ironic would be:

- do you rely on iscsi-based deploy method or agent-based one?
- do you rely on common drivers like agent_ipmotool or pxe_ipmitool, or use
vendor-specific drivers like ilo_*, drac_* etc? if using vendor specific
drivers, what features of those are the reason for such choice?

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Jan 4, 2017 at 2:07 PM, Jim Rollenhagen 
wrote:

> Hey all,
>
> We have an opportunity to ask a question on the upcoming User Survey,
> which will launch by February 1st. We can choose the audience to direct
> the question to, choosing from those USING, TESTING, or INTERESTED
> in Ironic (or some combination of these).
>
> The hope is that the Foundation folks can get us the raw answers before
> the PTG.
>
> So, Ironicers, what question would you like to ask users, and which group
> of
> users would you like to ask?
>
> // jim
>
> __
> OpenStack Development Mailing 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] [acceleration]Team Bi-weekly Meeting 2017.1.4 Agenda

[Harm Sluiman]

Happy New Year everyone.
I won't be able participate in the IRC today due to a conflict, but I will
try to connect and monitor.
I will also put more comments in the etherpads that are linked


On Wed, Jan 4, 2017 at 6:28 AM, Zhipeng Huang  wrote:

> Hi Team,
>
> Please find the agenda at https://wiki.openstack.org/wiki/Meetings/
> CyborgTeamMeeting#Agenda_for_next_meeting
>
> our IRC channel is #openstack-cyborg
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct 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
>



-- 
宋慢
Harm Sluiman
__
OpenStack Development Mailing List (not for 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] Feedback for upcoming user survey questionnaire

[Lance Bragstad]

++ to the suggestions Boris threw out. Answers to any of those would be
valuable. In addition to that, I'd find any information about policy
useful. Maybe something along the lines of "what changes to the policy
files are you making, if any". This could be something that is asked
OpenStack-wide (which I'm sure we've done at some point in the past) but it
would also be interesting on a per-project basis.

On Tue, Jan 3, 2017 at 3:05 PM, Boris Bobrov  wrote:

> "What were you trying to accomplish with keystone but failed"
> "What functionality in keystone did you try to use but it wasn't good
> enough"
> "In your opinion, what in keystone requires most attention"
> with choices "federation", "performance", "policy", "backend support"
> and some other options.
>
> On 12/30/2016 11:54 PM, Steve Martinelli wrote:
> > We have the opportunity to ask one question on the
> > upcoming user survey and we get to decide the audience to which we serve
> > the question.
> >
> > __ __
> >
> > Our audience options are: USING, TESTING, or INTERESTED in Keystone (I
> > think we should aim for USING or TESTING)
> >
> > __ __
> >
> > The question can take one of several forms; multiple choice (select one
> > or more), or short answer.
> >
> > __ __
> >
> > Post your suggestions here or email them to me privately ASAP so I can
> > respond to the team assembling the survey in sufficient time.
> >
> >
> >
> > stevemar
> >
> >
> > 
> __
> > OpenStack Development Mailing 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] [tripleo] quick reminder on review policy

[John Trowbridge]

On 01/03/2017 07:30 PM, Emilien Macchi wrote:
> I've noticed some TripleO core reviewers self approving patch without
> respecting our review policy, specially in tripleo-quickstart.
> 

This is slightly misleading. To me, self-approving is +2/+A on your own
patch.

What has been going in tripleo-quickstart is different though. We have
allowed cores to +A a patch from another core with only a single +2.
That is against the policies laid out in tripleo-specs[1,2]. However,
following those policies will effectively make it impossible for cores
of tripleo-quickstart to get their own work merged in anything
approaching a reasonable amount of time.

This is because there are currently only 3 cores reviewing
tripleo-quickstart with any regularity. So the policies below mean that
any patch submitted by a core must be reviewed by every other core. I
think it has actually been a full month since we even had all 3 cores
working at the same time due to holidays and PTO (currently we only have 2).

If we want to apply the policies below to quickstart, I get it... they
are after all the agreed on policies. I think this puts moving CI to
quickstart this cycle at a very high risk to complete though, which also
means getting container CI is also at risk.

[1]
http://specs.openstack.org/openstack/tripleo-specs/specs/policy/expedited-approvals.html#single-2-approvals
[2]
http://specs.openstack.org/openstack/tripleo-specs/specs/policy/expedited-approvals.html#self-approval

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

[openstack-dev] [horizon] Timeout issue

[Gary Kotton]

Hi,
Maybe someone can help or give me some pointers. On horizon I am trying to 
attach a network interface to a router. When I do this I get the following 
error on horizon:
“Danger: There was an error submitting the form. Please try again.” When I 
refresh the page I see that the operation has completed successfully.
The neutron logs also indicate that the operation has completed successfully. 
The issue seems to be related to a timeout. It always happens 2 minutes after 
the start of the operation.
Any idea or pointers to debug?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Atlanta PTG

[Emilien Macchi]

I would like to bring this topic up on your inbox, so we can continue
to make progress on the agenda. Feel free to follow existing examples
in the etherpad and propose a design dession.

Thanks,

On Wed, Dec 21, 2016 at 9:06 AM, Emilien Macchi  wrote:
> General infos about PTG: https://www.openstack.org/ptg/
>
> Some useful informations about PTG/TripleO:
>
> * When? We have a room between Wednesday and Friday included.
> Important sessions will happen on Wednesday and Thursday. We'll
> probably have sessions on Friday, but it might be more hands-on and
> hackfest, where people can enjoy the day to work together.
>
> * Let's start to brainstorm our topics:
> https://etherpad.openstack.org/p/tripleo-ptg-pike
>   Feel free to add any topic, as soon as you can. We need to know asap
> which sessions will be share with other projects (eg: tripleo/mistral,
> tripleo/ironic, tripleo/heat, etc).
>
>
> Please let us know any question or feedback,
> Looking forward to seeing you there!
> --
> Emilien Macchi



-- 
Emilien Macchi

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

[openstack-dev] [ironic] User survey question

[Jim Rollenhagen]

Hey all,

We have an opportunity to ask a question on the upcoming User Survey,
which will launch by February 1st. We can choose the audience to direct
the question to, choosing from those USING, TESTING, or INTERESTED
in Ironic (or some combination of these).

The hope is that the Foundation folks can get us the raw answers before
the PTG.

So, Ironicers, what question would you like to ask users, and which group of
users would you like to ask?

// jim
__
OpenStack Development Mailing 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] [acceleration]Team Bi-weekly Meeting 2017.1.4 Agenda

[Zhipeng Huang]

Hi Team,

Please find the agenda at
https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting


our IRC channel is #openstack-cyborg

-- 
Zhipeng (Howard) Huang

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

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

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

Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config

[Weyl, Alexey (Nokia - IL)]

We do write code in the zuul/layout.yaml:

  - name: openstack/puppet-vitrage

template:

  - name: merge-check

  - name: puppet-check-jobs

  - name: puppet-module-unit-jobs

  - name: puppet-beaker-jobs

  - name: puppet-beaker-jobs-xenial

  - name: puppet-branch-tarball-jobs

  - name: openstack-server-release-jobs

  - name: release-notes-jobs

  - name: openstack/python-vitrageclient
template:
  - name: merge-check
  - name: python-jobs
  - name: python35-jobs
  - name: check-requirements
  - name: publish-to-pypi
  - name: osc-plugin-jobs

Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Wednesday, January 04, 2017 10:59 AM
To: Weyl, Alexey (Nokia - IL)
Cc: openstack-dev@lists.openstack.org
Subject: 答复: Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config

Hi Alexey,

As far as i know, every project needs to register in the zuul/layout.yaml[1], 
so zuul can submit the job to jenkins via gearman.
So the jenkins knows which jobs need to run and then run the job which defined 
in the jenkins/jobs/XXX.yaml.
Did i missing something? Or the job registeration moved from zuul/layout.yaml 
to jenkins/jobs/projects.yaml?
If yes, how can zuul know which jobs need to submit to jenkins?Thanks~

[1]https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml
 

BR,
dwj




原始邮件
发件人：Weyl,Alexey(Nokia-IL)
收件人：OpenStack Development Mailing List (not for usage questions);
日 期 ：2017年01月04日 16:30
主 题 ：Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config

Hi Dong,

All of that data is configured the openstack-infra/project-config in github.

There you can find our changes by searching for vitrage.

The main files that we have pushed our changes are:
jenkins/jobs/vitrage.yaml
gerrit/projects.yaml
jenkins/jobs/projects.yaml

BR,
Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Wednesday, January 04, 2017 9:49 AM
To: openstack-dev@lists.openstack.org
Subject: [ALU] [openstack-dev] [Vitrage] vitrage tempest job config


Hi all,
I didn't find any vitrage project jenkins jobs registered in zuul/layout.yaml.
Where does all the jobs configed?Thanks~
BR,
dwj



__
OpenStack Development Mailing 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] [os-ansible-deployment] Periodic job in infra to test upgrades?

[Andy McCrae]

>
>
> OK - is there any way that I can assist?
>
> What about the challenges I discussed in my initial mail related to
> long AIO build times etc..?
>
>
I think there are some options, but the idea we're going with at the moment
is to look into setting this up as a periodical - we're at about 1hr per
full AIO build, so i don't think we'll be able to (reliably) keep the gate
to under 1hr30 if we include an upgrade scenario - unless we have some
ideas around how we build the initial AIO build - that could cut down the
time.

That's mostly conjecture at this point though - since we don't have a test
scenario setup.

The work we can do now, which if you're able to help with would be really
great, is:

Plan how we execute the actual job - at the moment the aio is run through a
script (scripts/gate-check-commit.sh) - the upgrade test would have to hook
into this (using the SCENARIO=upgrade) var, or we'd need to look into
changing this method up entirely (role gates all use tox for example).

If the current method is sufficient we need to set the job up. Once we have
a working scenario (regardless of time taken for the test), we can look
into ways we can ensure this gets run, and what options we have.

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

Re: [openstack-dev] Planning for the Pike PTG

[Thierry Carrez]

Matt Riedemann wrote:
> I haven't been living under a rock but I'm not aware of any major
> announcements regarding session planning for the PTG - has that happened
> somewhere and I'm just in the dark?
> 
> I'm mostly wondering about the Monday and Tuesday cross-project sessions
> - are those time-boxed sessions like at the summit and will have a
> schedule? Or are we just playing fast and loose and hoping someone will
> lead us out of a hallway and into a room for Major Synergy (tm)?

There are no "cross-project sessions" on Monday-Tuesday. There are a
number of horizontal team meetings (Infrastructure, QA, Documentation,
Security, Oslo...), transverse team meetings (Horizon, Kolla,
OpenStackClient, AppCatalog, RPM packaging...), and workgroup meetings
(Architecture WG, Stewardship WG, Interop WG...). All of those are full
days (or full 2-days) in a room owned by a given team (and PTL or chair)
and they are free to organize in whatever way they see fit (there are no
time-boxed sessions, so we expect most teams to use an etherpad-based
open agenda).

We'll also have a room (or two) dedicated to the Pike goals (currently
under discussion) -- whoever wants to meet and make quick progress on
the Pike goals during the PTG should be able to find facilitators there.
We are still waiting on the final list of goals to formally make
progress on that front.

Additionally from Monday to Thursday we'll have one openly-scheduled
fishbowl room, in case we need to have specific discussions. Think a
Cinder/Nova/os-brick discussion outside of the Nova and Cinder-specific
rooms, but for which you'd rather not all stand in the hallway. For that
room I thought we could set up an etherpad with time slots and let
people schedule topics there on the spot... But I'm happy to take
suggestions.

> I see project teams are working on getting etherpads together for
> topics, including myself, which got me thinking about how to plan the
> Wed-Friday sessions which for a midcycle meetup would normally be a list
> of topics that we'd go through in order (or by priority) but not
> time-boxed or scheduled. But then I got thinking about how the PTG is
> right before we start working on Pike, so I'm now thinking we need more
> structure than what we did at the midcycles, and more like what we do at
> the design summit with respect to scheduled discussions about things
> that are going to be worked on in the upcoming release, figuring out
> goals, determining review priorities, etc - which is actually a lot more
> work to plan and schedule ahead of time, especially when we consider
> (vertical) cross-project sessions like between nova/cinder or nova/neutron.

One of the goals of splitting the Design Summit into PTG & Forum is to
separate the "feedback/requirements gathering" phase (at the Forum) from
the "let's plan and bootstrap the actual work" phase (at the PTG). The
Pike PTG is arguably a transition PTG, since we won't have had a "Forum"
in the months before. The PTG is still happening at a point where most
people already started working on Pike though (rather than "right before
we start working on Pike"), and ideally should be focused on
implementation plans, review priorities and getting things done, without
the constraints of time-boxed slots.

That said, you should definitely take advantage of having everyone
around (and with less scheduling constraints compared to Summit) to
discuss inter-project questions (think Nova/Neutron or Nova/Cinder). You
can hold those within your room if you think all team members should
follow them, or take advantage of the aforementioned extra fishbowl room
to hold those.

> In other words, the fact I haven't had anxiety yet about planning the
> PTG makes me anxious that I'm falling way behind already.

I don't think you are way behind. Now is a good time to brainstorm on an
etherpad what your team needs to discuss and do during those days. If
you identify inter-project discussions, there is still time to reach out
to those other teams to make sure it's on their radar as well, and
arrange a common time for the discussion. I like to think we can achieve
that without the stress and constraints of strict centralized
scheduling, using a more peer-to-peer/unconference approach to magically
make the best use of our time there. If the feedback at the end of the
week is that it was a big bowl of mess, we'll revisit for the next one :)

Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tripleo] Adding a LateServices ResourceChain

[Steven Hardy]

On Tue, Jan 03, 2017 at 03:20:37PM -0500, Lars Kellogg-Stedman wrote:
> On Fri, Dec 23, 2016 at 02:21:00PM +, Steven Hardy wrote:
> > I commented on the bug, I'm not sure about this as it seems to overlap with
> > our service_config_settings interface, which IIRC landed slightly after
> > your previous patches for opstools things, and potentially provides a
> > cleaner way to approach this.
> 
> I'm not sure I see how to apply that, but let me further describe the
> use case and you can perhaps point me in the right direction.
> 
> > Perhaps you can point to some examples of this usage, then we can compare
> > with the service_config_settings approach?
> > 
> > I suspect the main difference is you need to append data for each service
> > to e.g the collectd configuration?
> 
> Let's take the existing Fluentd support as an example.  We want the
> ability for every service to provide a logging source configuation for
> Fluentd, which will get aggregated into a logging_sources
> list and then ultimately used in puppet-tripleo to populate a series
> of ::fluentd::config resources.
> 
> Currently, the aggregation happens in a combination of
> puppet/services/services.yaml (which aggregates the logging_source
> attribute from all the services in the service chain) and in
> overcloud.j2.yaml (which actually instantiates the hiera data).
> 
> With the LateServiceChain I've proposed, this could all be isolated
> inside the fluentd composable service: it would not be necessary to
> expose any of this logic in either services.yaml or overcloud.j2.yaml,
> leading.  Additionally, it would not require the fluentd service to
> have any a priori knowledge of what services were in use; it would
> simply aggregate any configuration information that is provided in the
> primary service chain.  It would also allow us to get rid of the
> "LoggingConfiguration" resource, which only exists as a way to expose
> certain parameter_defaults inside services.yaml.

Ok, so it's very similar to service_config_settings, except you need to
append to a list of settings for all services?

The problem I have with your current solution (as just mentioned on the
review) is it makes operators have to care about service ordering, because
it duplicates the per-role *Services parameters.

A key part of the custom roles work was to provide a simple interface that
enables operators to select specific services for each role, without having
to care at all about ordering (this is handled by the deployment steps in
the puppet profiles).

Thinking of ways around this, a couple of options come to mind:

1. Add a new "append" version of service_config_settings

(example based on https://review.openstack.org/#/c/411048)

  # In services/nova-compute.yaml
  service_config_settings_list:
  collectd:
tripleo::profile::base::metrics::collectd::collectd_plugins:
  - virt

  # In services/foo.yaml
  service_config_settings_list:
  collectd:
tripleo::profile::base::metrics::collectd::collectd_plugins:
  - foo

  Then in on the role running collectd, you'd get the hieradata key set
with a list containing "virt" and "foo" ?

This would require some data mangling in services.yaml, and a new interface
to the services templates, but it would leave the operator interfaces
unchanged?

2. Do the list manipulation in puppet, like we do for firewall rules

E.g see:

https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/ceilometer-api.yaml#L62

https://github.com/openstack/puppet-tripleo/blob/master/manifests/firewall/service_rules.pp#L32

This achieves the same logical result as the above, but it does the list
manipulation in the puppet profile instead of t-h-t.

I think either approach would be fine, but I've got a slight preference for
(1) as I think it may be more reusable in a future non-puppet world, e.g
for container deployments etc where we may not always want to use puppet.

Open to other suggestions, but would either of the above solve your
problem?

Thanks,

Steve

__
OpenStack Development Mailing List (not for 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] [ci] TripleO-Quickstart Transition to TripleO-CI Update and Invite:

[Steven Hardy]

Hi Harry,

On Tue, Jan 03, 2017 at 04:04:51PM -0500, Harry Rybacki wrote:
> Greetings All,
> 
> Folks have been diligently working on the blueprint[1] to prepare
> TripleO-Quickstart (OOOQ)[2] and TripleO-Quickstart-Extras[3] for
> their transition into TripleO-CI. Presently, our aim is to begin the
> actual transition to OOOQ on 4-Feb-2017. We are tracking our work on
> the RDO-Infra Trello board[4] and holding public discussion of key
> blockers on the team’s scrum etherpad[5].

Thanks for the update - can you please describe what "transition into
TripleO-CI" means?

I'm happy to see this work proceeding, but we have to be mindful that the
end of the development cycle (around the time you're proposing) is always
a crazy-busy time where folks are trying to land features and fixes.

So, we absolutely must avoid any CI outages around this time, thus I get
nervous talking about major CI transitions around the Release-candate
weeks ;)

https://releases.openstack.org/ocata/schedule.html

If we're talking about getting the jobs ready, then switching over to
primarily oooq jobs in early pike, that's great, but please lets ensure we
don't may any disruptive changes before the end of this (very short and
really busy) cycle.

> We are hosting weekly transition update meetings (1600-1700 UTC) and
> would like to invite folks to participate. Specifically, we are
> looking for at least one stakeholder in the existing TripleO-CI to
> join us as we prepare to migrate OOOQ. Attend and map out job/feature
> coverage to identify any holes so we can begin plugging them. Please
> reply off-list or reach out to me (hrybacki) on IRC to be added to the
> transition meeting calendar invite.

Why can't we discuss this in the weekly TripleO IRC meeting?

I think folks would be fine with having a standing item where we dicscuss
this transition (there is already a CI item, but I've rarely seen this
topic raised there).

https://wiki.openstack.org/wiki/Meetings/TripleO

Thanks!

Steve

__
OpenStack Development Mailing 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] 答复: Re: [ALU] [Vitrage] vitrage tempest job config

[dong.wenjuan]

Hi Alexey,





As far as i know, every project needs to register in the zuul/layout.yaml[1], 
so zuul can submit the job to jenkins via gearman.

So the jenkins knows which jobs need to run and then run the job which defined 
in the jenkins/jobs/XXX.yaml.

Did i missing something? Or the job registeration moved from zuul/layout.yaml 
to jenkins/jobs/projects.yaml?

If yes, how can zuul know which jobs need to submit to jenkins?Thanks~




[1]https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml
 




BR,

dwj















原始邮件



发件人：Weyl,Alexey(Nokia-IL)
收件人：OpenStack Development Mailing List (not for usage questions)
日 期 ：2017年01月04日 16:30
主 题 ：Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config





Hi Dong,

All of that data is configured the openstack-infra/project-config in github.

There you can find our changes by searching for vitrage.

The main files that we have pushed our changes are:
jenkins/jobs/vitrage.yaml
gerrit/projects.yaml
jenkins/jobs/projects.yaml

BR,
Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Wednesday, January 04, 2017 9:49 AM
To: openstack-dev@lists.openstack.org
Subject: [ALU] [openstack-dev] [Vitrage] vitrage tempest job config


Hi all,
I didn't find any vitrage project jenkins jobs registered in zuul/layout.yaml.
Where does all the jobs configed?Thanks~
BR,
dwj



__
OpenStack Development Mailing 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] [tricircle]weekly meeting of Jan.4

[joehuang]

Hello, team,

Welcome to the year 2017.

Agenda of Jan.4 weekly meeting:

  1.  shadow_agent for VxLAN L2 networking/L3 DVR issue
  2.  db migration version
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

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

Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config

[Weyl, Alexey (Nokia - IL)]

Hi Dong,

All of that data is configured the openstack-infra/project-config in github.

There you can find our changes by searching for vitrage.

The main files that we have pushed our changes are:
jenkins/jobs/vitrage.yaml
gerrit/projects.yaml
jenkins/jobs/projects.yaml

BR,
Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Wednesday, January 04, 2017 9:49 AM
To: openstack-dev@lists.openstack.org
Subject: [ALU] [openstack-dev] [Vitrage] vitrage tempest job config


Hi all,
I didn't find any vitrage project jenkins jobs registered in zuul/layout.yaml.
Where does all the jobs configed?Thanks~
BR,
dwj



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

Re: [openstack-dev] [Neutron][networking-*] Attention for upcoming refactoring

[Kevin Benton]

If you wanted one compatible with both you could have a line like this.

session = ctx.session if isinstance(ctx, neutron.context.Context) else ctx

On Tue, Jan 3, 2017 at 2:52 PM, Ian Wells  wrote:

> I see this changes a function's argument types without changing the
> function's name - for instance, in the proposed networking-cisco change,
> https://review.openstack.org/#/c/409045/ .  This makes it hard to detect
> that there's been a change and react accordingly.  What's the recommended
> way to write a mechanism driver that is compatible with both pre- and
> post-change Neutron versions?
> --
> Ian.
>
> On 27 December 2016 at 02:29, Anna Taraday 
> wrote:
>
>> Hello everyone!
>>
>> Please, note that all changes to Neutron merged.
>>
>> Changes that needs to be merged for external repos:
>> segments db refactor - https://review.openstack.org/#
>> /q/status:open+branch:master+topic:segmentsdb
>> ml2 db refactor - https://review.openstack.org
>> /#/q/status:open+branch:master+topic:refactor_ml2db
>>
>> Happy holidays for everyone!
>>
>>
>> On Thu, Dec 22, 2016 at 7:36 AM Russell Bryant 
>> wrote:
>>
>>>
>>> On Wed, Dec 21, 2016 at 10:50 AM, Anna Taraday <
>>> akamyshnik...@mirantis.com> wrote:
>>>
>>> Hello everyone!
>>>
>>> I've got two changes with refactor of TypeDriver [1] and segments db [2]
>>> which is needed for implementation new engine facade [3].
>>>
>>> Reviewers of networking-cisco, networking-arista, networking-nec
>>> 
>>> , networking-midonet
>>> 
>>> , networking-edge-vpn, networking-bagpipe,
>>> tricircle, group-based-policy - pay attention for [4].
>>>
>>> Also recently merged refactor of ml2/db.py [5]. Fixes
>>> for networking-cisco, networking-cisco, networking-cisco - are on
>>> review [6]
>>>
>>> [1] - https://review.openstack.org/#/c/398873/
>>> [2] - https://review.openstack.org/#/c/406275/
>>> [3] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
>>> [4] - https://review.openstack.org/#/q/topic:segmentsdb
>>> [5] - https://review.openstack.org/#/c/404714/
>>> [6] - https://review.openstack.org/#/q/status:open++branch:maste
>>> r+topic:refactor_ml2db
>>>
>>>
>>> ​Thanks a lot for looking out for the various networking-* projects when
>>> working on changes like this.  It's really great to see.
>>>
>>> --
>>> Russell Bryant
>>> 
>>> __
>>> 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
>>>
>> --
>> Regards,
>> Ann Taraday
>>
>> 
>> __
>> 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] [neutron][ml2] Mechanism drivers ! OpenvSwich or Linuxbridge or both of them?

[Kevin Benton]

Note that with the openvswitch and linuxbridge mechanism drivers, it will
be safe to have both loaded on the Neutron server at the same time since
each driver will only bind a port if it has an agent of that type running
on the host.

On Fri, Dec 30, 2016 at 1:24 PM, Sławek Kapłoński 
wrote:

> Hello,
>
> I don't know what is hierarchical port binding but about mechanism
> drivers, You should use this mechanism driver which L2 agent You are
> using on compute/network nodes. If You have OVS L2 agent then You should
> have enabled openvswitch mechanism driver.
> In general both of those drivers are doing similar work on
> neutron-server side because they are checking if proper agent type is
> working on host and if other conditions required to bind port are valid.
> Mechanism drivers can have also some additional informations about
> backend driver, e.g. there is info about supported QoS rule types for
> each backend driver (OVS, Linuxbridge and SR-IOV).
>
> BTW. IMHO You should send such questions to openst...@lists.openstack.org
>
> --
> Best regards / Pozdrawiam
> Sławek Kapłoński
> sla...@kaplonski.pl
>
> On Fri, 30 Dec 2016, zhi wrote:
>
> > Hi, all
> >
> > First of all. Happy New year for everyone!
> >
> > I have a question about mechanism drivers when using ML2 driver.
> >
> > When should I use openvswitch mechanism driver ?
> >
> > When should I use linuxbridge mechanism driver ?
> >
> > And, when should I use openvswitch and linuxbridge mechanism drivers ?
> >
> > In my opinion, ML2 driver has supported hierarchical port binding. By
> using
> > hierarchical port binding,
> > neutron will know every binding info in network topology, isn't it? If
> yes,
> > where I can found the every binding info. And what the relationship
> between
> > hierarchical port binding and mechanism drivers?
> >
> >
> > Hope for your reply.
> >
> > Thanks
> > Zhi Chang
>
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Mistral Workflow for deriving THT parameters

[Saravanan KR]

Hello,

The aim of this mail is to ease the DPDK deployment with TripleO. I
would like to see if the approach of deriving THT parameter based on
introspection data, with a high level input would be feasible.

Let me brief on the complexity of certain parameters, which are
related to DPDK. Following parameters should be configured for a good
performing DPDK cluster:
* NeutronDpdkCoreList (puppet-vswitch)
* ComputeHostCpusList (PreNetworkConfig [4], puppet-vswitch) (under review)
* NovaVcpuPinset (puppet-nova)

* NeutronDpdkSocketMemory (puppet-vswitch)
* NeutronDpdkMemoryChannels (puppet-vswitch)
* ComputeKernelArgs (PreNetworkConfig [4]) (under review)
* Interface to bind DPDK driver (network config templates)

The complexity of deciding some of these parameters is explained in
the blog [1], where the CPUs has to be chosen in accordance with the
NUMA node associated with the interface. We are working a spec [2], to
collect the required details from the baremetal via the introspection.
The proposal is to create mistral workbook and actions
(tripleo-common), which will take minimal inputs and decide the actual
value of parameters based on the introspection data. I have created
simple workbook [3] with what I have in mind (not final, only
wireframe). The expected output of this workflow is to return the list
of inputs for "parameter_defaults",  which will be used for the
deployment. I would like to hear from the experts, if there is any
drawbacks with this approach or any other better approach.

This workflow will ease the TripleO UI need to integrate DPDK, as UI
(user) has to choose only the interface for DPDK [and optionally, the
number for CPUs required for PMD and Host]. Of-course, the
introspection should be completed, with which, it will be easy to
deploy a DPDK cluster.

There is a complexity if the cluster contains heterogeneous nodes, for
example a cluster having HP and DELL machines with different CPU
layout, we need to enhance the workflow to take actions based on
roles/nodes, which brings in a requirement of localizing the above
mentioned variables per role. For now, consider this proposal for
homogeneous cluster, if there is a value in this, I will work towards
heterogeneous clusters too.

Please share your thoughts.

Regards,
Saravanan KR


[1] https://krsacme.github.io/blog/post/dpdk-pmd-cpu-list/
[2] https://review.openstack.org/#/c/396147/
[3] https://gist.github.com/krsacme/c5be089d6fa216232d49c85082478419
[4] 
https://review.openstack.org/#/c/411797/6/extraconfig/pre_network/host_config_and_reboot.role.j2.yaml

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