date:20171204

Re: [openstack-dev] [neutron] [networking-ovn] Non voting jobs for networking-ovn on neutron.

2017-12-04 Thread Takashi Yamamoto

hi,

On Mon, Dec 4, 2017 at 10:20 PM, Miguel Angel Ajo Pelayo
 wrote:
>
> Hi Folks,
>  I wanted to rise this topic, I have been wanting to do it from long
> ago,
> but preferred to wait until the zuulv3 stuff was a little bit more stable,
> may
> be now it's a good time.
>
> We were thinking about the option of having a couple of non-voting jobs
> on
> the neutron check for networking-ovn. It'd be great for us, in terms of
> traceability,
> we re-use a lot of the neutron unit test base clases/etc, and sometimes
> we get hit by surprises.
>
> Sometimes some other changes hit us on the neutron scenario tests.
>
> So it'd be great to have them if you believe it's a reasonable thing.

i can understand why you want it.
but once we allow this kind of jobs, we will soon end up to have a lot
of jobs for
each neutron related projects. i guess it isn't acceptable.
you can still set up 3rd party CI.

>
> Best regards,
> Miguel Ángel.
>
> __
> OpenStack Development Mailing 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] [octavia][tricircle] About enabling automatic installation of octavia with tricircle

2017-12-04 Thread Yipei Niu

Hi, all

Tricircle team has already enabled LBaaS with tricircle. Here is the guide
https://github.com/openstack/tricircle/blob/master/doc/source/install/installation-lbaas.rst
.

However, automatic installation and configuration of Octavia in tricircle
is not implemented yet, since some modifications are needed to adapt
Octavia. The detailed info is presented the section of "Setup &
Installation" in
https://github.com/openstack/tricircle/blob/master/doc/source/install/installation-lbaas.rst#setup--installation

What do you think? Look forward to your comments on automatic installation
of Octavia with tricircle.

Best regards,
Yipei
__
OpenStack Development Mailing 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] [rally]404 on docker rallyforge/rally

2017-12-04 Thread Swapnil Kulkarni

On Tue, Dec 5, 2017 at 5:35 AM,   wrote:
> Hi, sorry for the inconvenience.
>
> docker team removed the rallyforge/rally repo. PTL has contacted them some
> days ago, but did not get the answer.
>
> Let us wait some days, if still not answer, we will create another repo
> (xrally/rally) for this.
>
>
> Best regards
>
> chen
>
>
>
>
>
> Original Mail
> Sender:  ;
> To:  ;
> Date: 2017/12/04 23:18
> Subject: Re: [openstack-dev] [rally]404 on docker rallyforge/rally
>
>
> - Mail original -
>> De: "Swapnil Kulkarni" 
>> À: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Envoyé: Lundi 4 Décembre 2017 12:57:36
>> Objet: Re: [openstack-dev] [rally]404 on docker rallyforge/rally
>>
>> On Mon, Dec 4, 2017 at 4:13 PM, Matthieu Simonin
>>  wrote:
>> > Hi,
>> >
>> > Monday morning and it seems that docker images for rally aren't
>> > reachable
>> > anymore.
>> >
>> > https://hub.docker.com/r/rallyforge/rally/
>> >
>> > Did I miss something ? Is the doc up-to-date[1] ?
>> >
>> > [1]:
>> >
>> > http://rally.readthedocs.io/en/0.10.0/install_and_upgrade/install.html#rally-docker
>> >
>> > Matt
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> I think you need to refer to [1] for updated docs and [2] should be
>> able to help you with rally-docker information which might be useful
>> for you.
>
> Thanks Swapnil, but the namespace rallyforge[1] is now empty
> (or all images are private) on docker hub.
>
> I have no problem building images on my own, but I just wanted to make
> sure this is now the only way I can use the rally images.
>
> If so the doc will need to be updated to remove any reference to
> rallyforge/rally.
>
>
> [1] https://hub.docker.com/r/rallyforge/
>
> Best,
>
> Matthieu
>
>>
>> [1] https://docs.openstack.org/rally/latest/
>> [2]
>>
>> https://docs.openstack.org/rally/latest/install_and_upgrade/install.html#rally-docker
>>
>> __
>> OpenStack Development Mailing 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
>

I was not sure about the defunct rally repo on docker hub. My bad. I
think yeah, till the time the new repo is operational building images
and using them would be a better idea.

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

[openstack-dev] [tacker] [hacking] [requirements] pep8 to pycodestyle

2017-12-04 Thread Swapnil Kulkarni

We have a change [1] out there which will remove pep8 and use
pycodestyle in global requirements. For this change to be merged we
need all dependent projects to use the same and check if they have any
conflicts. We are waiting for [2] for hacking and [3] for tackerclient
to be merged so that we can merge [1] into global requirements.

Requesting the cores in the hacking and tacker group to have a look
into this and help us move further. Feel free to reply or drop by
#openstack-requirements if you have any questions. Thanks in advance.

[1] https://review.openstack.org/#/c/514663/
[2] https://review.openstack.org/#/c/514934/
[3] https://review.openstack.org/#/c/517450/
-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap

__
OpenStack Development Mailing 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] [api] api-sig weekly meeting time change request

2017-12-04 Thread Gilles Dubreuil




On 05/12/17 01:55, michael mccune wrote:

On 12/03/2017 10:26 PM, Gilles Dubreuil wrote:

Hi,

Could we please change the API SIG weekly meeting time from 16pm UTC 
to 19pm UTC  [1]?

To give a chance for those down under to attend?


hey Gilles,

we have proposed adding another meeting time to make things easier for 
folks in the APAC regions. sadly, every time we have brought this up 
the response has been lackluster from people in that region.


i think the group is willing to discuss having a meeting time to 
enable APAC but it would be helpful to have a good indication of who 
the meeting would serve as pushing the time back by 3 hours will 
negatively impact the EMEA folks. i had sent this survey[1] to the 
mailing list but didn't get much response.




Two meetings makes sense to avoid stretching the first one out of normal 
hours (not even talking about business hours).
Although I'm not sure how active is the APAC region on either producer 
or consumer sides. Well there is me at least, +1 for the survey.



Thanks,
Gilles


peace o/

[1]: https://goo.gl/forms/0mVV4TGT7bZGAK323



Cheers,
Gilles

[1] 
https://www.timeanddate.com/worldclock/meetingtime.html?iso=20171204=195=137=240 








__
OpenStack Development Mailing 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] [rally]404 on docker rallyforge/rally

2017-12-04 Thread chen.haibing1

Hi, sorry for the inconvenience.


docker team removed the rallyforge/rally repo. PTL has contacted them some days 
ago, but did not get the answer.


Let us wait some days, if still not answer, we will create another repo 
(xrally/rally) for this.






Best regards


chen



















Original Mail



Sender:  ;
To:  ;
Date: 2017/12/04 23:18
Subject: Re: [openstack-dev] [rally]404 on docker rallyforge/rally




- Mail original -
> De: "Swapnil Kulkarni" 
> À: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Envoyé: Lundi 4 Décembre 2017 12:57:36
> Objet: Re: [openstack-dev] [rally]404 on docker rallyforge/rally
> 
> On Mon, Dec 4, 2017 at 4:13 PM, Matthieu Simonin
>  wrote:
> > Hi,
> >
> > Monday morning and it seems that docker images for rally aren't reachable
> > anymore.
> >
> > https://hub.docker.com/r/rallyforge/rally/
> >
> > Did I miss something ? Is the doc up-to-date[1] ?
> >
> > [1]:
> > http://rally.readthedocs.io/en/0.10.0/install_and_upgrade/install.html#rally-docker
> >
> > Matt
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> I think you need to refer to [1] for updated docs and [2] should be
> able to help you with rally-docker information which might be useful
> for you.

Thanks Swapnil, but the namespace rallyforge[1] is now empty 
(or all images are private) on docker hub.

I have no problem building images on my own, but I just wanted to make
sure this is now the only way I can use the rally images. 

If so the doc will need to be updated to remove any reference to 
rallyforge/rally.


[1] https://hub.docker.com/r/rallyforge/

Best,

Matthieu

> 
> [1] https://docs.openstack.org/rally/latest/
> [2]
> https://docs.openstack.org/rally/latest/install_and_upgrade/install.html#rally-docker
> 
> __
> OpenStack Development Mailing 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] [octavia] API v2 or v1 or both?

2017-12-04 Thread Volodymyr Litovka


Hi colleagues,

when I use in [api_settings] section of octavia.conf

api_v1_enabled = False
api_v2_enabled = True

I'm getting member creation failed:

2017-12-04 22:20:37.326 7199 INFO 
neutron_lbaas.services.loadbalancer.plugin 
[req-2c3d3185-9440-4f3d-90de-dff87de783b9 
e6406606bd9d48aabc413468f9703cf6 c1114776e144400da17d8e060856be8c - 
default default] Calling driver operation LoadBalancerManager.create
2017-12-04 22:20:37.326 7199 DEBUG neutron_lbaas.drivers.octavia.driver 
[req-2c3d3185-9440-4f3d-90de-dff87de783b9 
e6406606bd9d48aabc413468f9703cf6 c1114776e144400da17d8e060856be8c - 
default default] url = http://lagavulin:9876/v1/loadbalancers request 
/usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/octavia/driver.py:138
2017-12-04 22:20:37.327 7199 DEBUG neutron_lbaas.drivers.octavia.driver 
[req-2c3d3185-9440-4f3d-90de-dff87de783b9 
e6406606bd9d48aabc413468f9703cf6 c1114776e144400da17d8e060856be8c - 
default default] args = {"vip": {"subnet_id": 
"1748a90d-25bc-46a0-b623-d8450db83ed1", "port_id": 
"f773321c-eb34-41fa-8434-45358e6232fb", "ip_address": "10.1.1.12"}, 
"name": "nbt-balancer", "project_id": 
"c1114776e144400da17d8e060856be8c", "enabled": true, "id": 
"25604d3c-1714-4837-ad98-8ea2d2f03bc7", "description": ""} request 
/usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/octavia/driver.py:139
2017-12-04 22:20:37.337 7199 DEBUG neutron_lbaas.drivers.octavia.driver 
[req-2c3d3185-9440-4f3d-90de-dff87de783b9 
e6406606bd9d48aabc413468f9703cf6 c1114776e144400da17d8e060856be8c - 
default default] Octavia Response Code: 405 request 
/usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/octavia/driver.py:144
2017-12-04 22:20:37.338 7199 DEBUG neutron_lbaas.drivers.octavia.driver 
[req-2c3d3185-9440-4f3d-90de-dff87de783b9 
e6406606bd9d48aabc413468f9703cf6 c1114776e144400da17d8e060856be8c - 
default default] Octavia Response Body: 

 
  405 Method Not Allowed
 
 
  405 Method Not Allowed
  The method POST is not allowed for this resource. 

 
 request 
/usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/octavia/driver.py:145


when I use both v1 and v2 enabled, I see ALL calls to API like 
http://...:9876/_v1_/... and corresponding log records like


2017-12-04 18:12:01.676 27192 INFO octavia.api._v1_.controllers.*

does "v1" means that neutron use LBaaS API v1 instead of v2 ? Neutron 
itself configured to use LBaaS v2 :


[DEFAULT]
service_plugins = 
router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2

[service_providers]
service_provider = 
LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default


Is it enough or how to configure both neutron and octavia to use API v2 
instead of v1? I'm under Ubuntu 16 and Openstack Pike and there are just 
"python-neutron-lbaas" package installed (no lbaasv2-agent, 
lbaas-common, etc) and octavia itself (using "pip install octavia" in 
_virtual environment_). Thus, endpoints configured unversioned in this way:


+--+---+--++-+---+--+
| ID   | Region    | Service Name | Service 
Type   | Enabled | Interface | URL  |

+--+---+--++-+---+--+
| 18862b1bd4c643aca207f8b2d9066895 | RegionOne | octavia  | 
load-balancer  | True    | internal  | http://lagavulin:9876/   |
| 8cb62ab73fb2431dbc3a0def744852ea | RegionOne | octavia  | 
load-balancer  | True    | public    | http://lagavulin:9876/   |
| 909e9fc434cb4667bb828828bf49f906 | RegionOne | octavia  | 
load-balancer  | True    | admin | http://lagavulin:9876/   |

+--+---+--++-+---+--+

and no neutron lbaas agent in the list of agents (since there is no 
lbaasv2 agent installed and configured in the system).


Seems I'm missing something.

And two related questions:

 * which method to provide API is more preferable - WSGI or standalone
   octavia-api process?
 * how to be sure that Octavia code matches Pike version? I'm using
   "pip install octavia" and it's v1.0.1 at the moment, but not sure it
   matches package "python-neutron-lbaas" version 2:11.0.0-0ubuntu1~cloud0

Thank you.

--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

__
OpenStack Development Mailing 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] Removing Keystoneauth Dependency in Castellan Discussion

2017-12-04 Thread ARORA, ROHAN

I do believe that was something Tin mentioned after I had talked to him after 
our IRC chat last week. Seems like the right way to go. Tin?

Best,
Rohan

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: Monday, December 04, 2017 4:00 PM
To: openstack-dev 
Subject: Re: [openstack-dev] Removing Keystoneauth Dependency in Castellan 
Discussion

Excerpts from ARORA, ROHAN's message of 2017-12-04 21:47:45 +:
> Wanted to start a thread to discuss the potential removal of the Keystoneauth 
> dependency from Castellan. Whether it is needed or not, approaches we might 
> want to take, etc.
> From my understanding, Tin, Gage, and Ade discussed this at the Sydney 
> summit, so we were hoping for some details/clarifications before getting to 
> work on it.
> 
> Best,
> Rohan

My understanding is that keystone is used when the barbican driver
is invoked. So I don't understand how we can remove the dependency
completely. We could possibly make it an "extras" so that it is
only installed if the barbican driver is going to be used. Is that
what you mean?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=HrszLFXMaQd7t9slUzbd4w=FujA9G4eVEAZYg6NIXvhNicVpcBdHJAIW-ZRJ2yeNjs=3x2COEHUcYS41wWEg97O9AmICZre8dUTMw_77FOWpeU=
 
__
OpenStack Development Mailing 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] Removing Keystoneauth Dependency in Castellan Discussion

2017-12-04 Thread Doug Hellmann

Excerpts from ARORA, ROHAN's message of 2017-12-04 21:47:45 +:
> Wanted to start a thread to discuss the potential removal of the Keystoneauth 
> dependency from Castellan. Whether it is needed or not, approaches we might 
> want to take, etc.
> From my understanding, Tin, Gage, and Ade discussed this at the Sydney 
> summit, so we were hoping for some details/clarifications before getting to 
> work on it.
> 
> Best,
> Rohan

My understanding is that keystone is used when the barbican driver
is invoked. So I don't understand how we can remove the dependency
completely. We could possibly make it an "extras" so that it is
only installed if the barbican driver is going to be used. Is that
what you mean?

Doug

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

[openstack-dev] Removing Keystoneauth Dependency in Castellan Discussion

2017-12-04 Thread ARORA, ROHAN

Wanted to start a thread to discuss the potential removal of the Keystoneauth 
dependency from Castellan. Whether it is needed or not, approaches we might 
want to take, etc.
>From my understanding, Tin, Gage, and Ade discussed this at the Sydney summit, 
>so we were hoping for some details/clarifications before getting to work on it.

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

Re: [openstack-dev] [python-openstacksdk][shade] New cores proposed for shade/sdk

2017-12-04 Thread Sławek Kapłoński

Thank You for all Your help and all Your support. I will do my best to help 
develop shade/sdk projects.

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




> Wiadomość napisana przez Monty Taylor  w dniu 
> 04.12.2017, o godz. 22:12:
> 
> On 11/30/2017 10:00 AM, Dean Troyer wrote:
>> On Thu, Nov 30, 2017 at 8:00 AM, Monty Taylor  wrote:
>>> So let's add them to the core team, yeah?
>> +1
>> dt
> 
> Hearing no dissent I've added both. Welcome aboard!
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [python-openstacksdk][shade] New cores proposed for shade/sdk

2017-12-04 Thread Monty Taylor


On 11/30/2017 10:00 AM, Dean Troyer wrote:

On Thu, Nov 30, 2017 at 8:00 AM, Monty Taylor  wrote:

So let's add them to the core team, yeah?


+1

dt



Hearing no dissent I've added both. Welcome aboard!

__
OpenStack Development Mailing 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] [FEMDC] Wed. 6 Dec - IRC Meeting 15:00 UTC

2017-12-04 Thread Alexandre van Kempen

Dear all, 

A gentle reminder for our Wednesday meeting at 15:00 UTC 

A draft agenda is available at line 1547, you are very welcome to add any item.
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 


Best,

Alex__
OpenStack Development Mailing 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] [os-upstream-institute] Meeting reminder

2017-12-04 Thread Ildiko Vancsa

Hi Training Team,

Friendly reminder that we have our next meeting in less than an hour (2000 UTC) 
on #openstack-meeting-3.

You can find the agenda here: 
https://etherpad.openstack.org/p/openstack-upstream-institute-meetings

See you soon! :)

Thanks,
Ildikó
(IRC: ildikov)
__
OpenStack Development Mailing 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] Developer Mailing List Digest November 25 to December 1st

2017-12-04 Thread Mike Perez


Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: 
https://www.openstack.org/blog/2017/12/developer-mailing-list-digest-november-25-to-december-1st/


News

* Project Team Gather (PTG) in Dublin registration is live [0]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124978.html



Community Summaries
===
* TC report by Chris Dent [0]
* Release countdown [1]
* Technical Committee Status updated [2]
* POST /api-sig/news [3]
* Nova notification update [4]
* Nova placement resource providers update [5]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124964.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/125054.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125099.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/125071.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125146.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125117.html



Dublin PTG Format
=
We will continue themes as we did in Denver, but shorter times like half 
days.
Flexibility is added for other groups to book the remaining available 
rooms in

90-min slots on-demand driven by the PTG Bot. So far the split of having
Monday-Tuesday be dedicated to themes and Wednesday-Frday dedicated to 
teams as

we've done in previous PTG's is a winning decision.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124898



First Contact SIG
=
A wiki has been created for the group [0]. The group is looking for 
intersted

people being points of contact for newcomers and what specified timezones.
Resource links like contributor portal, mentoring wiki, Upstream Institute,
outreachy are being collected on the wiki page. A representative from the
operators side to chair and represent would be good.

[0] - https://wiki.openstack.org/wiki/First_Contact_SIG

Policy Goal Queens-2 Update
===
Queens-2 coming to a close, we recap our community wide goal for 
policies [0].

If you want your status changed, contact Lance Bragstad. Use the topic
policy-and-docs-in-code for tracking related code changes.

Not Started
---
* ceilometer
* congress
* networking-bgpvpn
* networking-midonet
* networking-odl
* neutron-dynamic-routing
* neutron-fwaas
* neutron-lib
* solum
* swift


In Progress
---
* barbican
* cinder
* cloudkitty
* glance
* heat
* manila
* mistral
* neutron
* panko
* python-heatclient
* tacker
* tricircle
* trove
* vitrage
* watcher
* zaqar

Completed
-
* designate
* freezer
* ironic
* keystone
* magnum
* murano
* nova
* octavia
* sahara
* searchlight
* senlin
* zun


Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124966



Tempest Plugin Split Goal
=
A list of open reviews [0] is available for the Tempest plugin split 
goal [1].


Not Started
---
* Congress
* ec2-api
* freezer
* mistral
* monasca
* senlin
* tacker
* Telemetry
* Trove
* Vitrage

In Progress
---
* Cinder
* Heat
* Ironic
* magnum
* manila
* Neutron
* murano
* networking-l2gw
* octavia

Completed
-
* Barbican
* CloudKitty
* Designate
* Horizon
* Keystone
* Kuryr
* Sahara
* Solum
* Tripleo
* Watcher
* Winstackers
* Zaqar
* Zun

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125131.html



[0] - 
https://review.openstack.org/#/q/topic:goal-split-tempest-plugins+status:open
[1] - 
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html



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

[openstack-dev] Neutron exception when creating a network using Contrail R4.1 and OpenStack Ocata

2017-12-04 Thread Anda Nicolae

Hi all,

I am struggling with Contrail R4.1 and OpenStack Ocata on Ubuntu 16.04.2.
I managed to install Contrail R4.1 on Ubuntu 16.04 using contrail-installer 
package and to successfully start all Contrail processes.
Then, I installed OpenStack Ocata using devstack. Unfortunately, I am facing 
some errors.

Worth mentioning that I have also installed only OpenStack Ocata without 
Contrail on Ubuntu 16.04 and it worked without any errors.

Some of the errors I have encountered with OpenStack Ocata and Contrail R4.1 
are:
If I issue: 'neutron net-list', works fine but 'neutron --debug net-create 
net1' returns:

DEBUG: keystoneauth.session GET call to None for http:// 
:5000/v2.0 used request id 
req-ee38087e-3167-4e2f-a3c7-05422984e40d
DEBUG: keystoneauth.identity.v2 Making authentication request to http:// 
/identity/v2.0/tokens
DEBUG: keystoneauth.session REQ: curl -g -i -X POST http:// 
:9696/v2.0/networks.json -H "User-Agent: 
python-neutronclient" -H "Content-Type: application/json" -H "Accept: 
application/json" -H "X-Auth-Token: 
{SHA1}07ab629ceba1f5e5eeb0533eccee9dad135910f9" -d '{"network": {"name": 
"net1", "admin_state_up": true}}'
DEBUG: keystoneauth.session RESP: [404] Content-Type: application/json 
Content-Length: 97 X-Openstack-Request-Id: 
req-ea656a0f-f621-43c7-af48-eaff7fd8d97a Date: Tue, 28 Nov 2017 00:52:14 GMT 
Connection: keep-alive
RESP BODY: {"NeutronError": {"message": "An unknown exception occurred.", 
"type": "NotFound", "detail": ""}}

DEBUG: keystoneauth.session POST call to network for 
http://:9696/v2.0/networks.json used request id 
req-ea656a0f-f621-43c7-af48-eaff7fd8d97a
DEBUG: neutronclient.v2_0.client Error message: {"NeutronError": {"message": 
"An unknown exception occurred.", "type": "NotFound", "detail": ""}}
DEBUG: neutronclient.v2_0.client POST call to neutron for http:// 
:9696/v2.0/networks.json used request id 
req-ea656a0f-f621-43c7-af48-eaff7fd8d97a
ERROR: neutronclient.shell An unknown exception occurred.
Neutron server returns request_ids: ['req-ea656a0f-f621-43c7-af48-eaff7fd8d97a']
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/shell.py", line 
877, in run_subcommand
return run_command(cmd, cmd_parser, sub_argv)
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/shell.py", line 
114, in run_command
return cmd.run(known_args)
  File 
"/usr/local/lib/python2.7/dist-packages/neutronclient/neutron/v2_0/__init__.py",
 line 324, in run
return super(NeutronCommand, self).run(parsed_args)
  File "/usr/local/lib/python2.7/dist-packages/cliff/display.py", line 112, in 
run
column_names, data = self.take_action(parsed_args)
  File 
"/usr/local/lib/python2.7/dist-packages/neutronclient/neutron/v2_0/__init__.py",
 line 406, in take_action
data = obj_creator(body)
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", 
line 798, in create_network
return self.post(self.networks_path, body=body)
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", 
line 366, in post
headers=headers, params=params)
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", 
line 301, in do_request
self._handle_fault_response(status_code, replybody, resp)
 File "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", 
line 276, in _handle_fault_response
exception_handler_v20(status_code, error_body)
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", 
line 92, in exception_handler_v20
request_ids=request_ids)
NotFound: An unknown exception occurred.

>From q-svc logs, I've found:
ERROR neutron_plugin_contrail.plugins.opencontrail.contrail_plugin_base 
[req-f7394fbd-c9ee-4468-b050-e0559a39bbfc demo admin] NotFound{u'msg': 
u"Unknown id: Error: oper 2 url /project/1621d377-eb4e-4a44-8470-699a3c14bd2d 
body {'fields': 'security_groups', 'exclude_hrefs': True} response Unknown id: 
1621d377-eb4e-4a44-8470-699a3c14bd2d", u'exception': u'NotFound'}security_group


Also, when I try to create the network using Contrail GUI, I have the following 
error:
Error: Parent project cannot be found: Unknown id: project default-domain:admin


Do you have any idea why this happens?


Thanks,
Anda
__
OpenStack Development Mailing 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] [policy] [rbac] Analyzing other policy systems

2017-12-04 Thread Lance Bragstad

Hey all,

We had a couple sessions over the last month or two analyzing RBAC in
other systems. The notes from the sessions can be found in etherpad [0].
The discussions and outcomes are useful for thinking about how we want
things to work in the near future, specifically highlighting the
importance of the current roadmap [1].

I wanted to give everyone a heads up that we will be continuing these
sessions after the New Year. I'll send out a note for scheduling once
that gets a bit closer. In the meantime, if you have anything you'd like
to go over, please add it to the etherpad [0] and we'll be sure to
pickup there in the next session.

Thanks,

Lance

[0] https://etherpad.openstack.org/p/analyzing-other-policy-systems
[1] https://trello.com/b/bpWycnwa/policy-roadmap




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

Re: [openstack-dev] [keystone] Queens-2 Retrospective

2017-12-04 Thread Lance Bragstad

Just a reminder that this will be happening tomorrow. Since Postfacto is
shutting down [0], I've created a new Trello board with a similar feel
for tomorrow's retrospective [1].

In order to get the most discussion out of the time we have, the board
is open for your input. Please try and take a few minutes to share your
thoughts before tomorrow's meeting. We'll start the meeting by jumping
right into the topics.

Thanks!

[0] https://postfacto.io/retros/openstack-keystone
[1] https://trello.com/b/jrpmDKtf/keystone-retrospective

On 11/29/2017 08:57 AM, Lance Bragstad wrote:
> Hey all,
>
> Just like for Queens-1, we're going to reuse the weekly meeting time [0]
> for the retrospective. That means we'll be holding our retrospective on
> December 12th during normal meeting hours. Some information can be found
> in Trello [1]. We had some issues last time with video conferencing, but
> maybe we can use BlueJeans again instead.
>
> Thanks and let me know if you have questions.
>
> Lance
>
>
> [0] http://eavesdrop.openstack.org/#Keystone_Team_Meeting
> [1] https://trello.com/c/le6Gdalb/61-schedule-queens-2-retrospective
>
>

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

Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

2017-12-04 Thread Afek, Ifat (Nokia - IL/Kfar Sava)

Ok, makes sense.

Regarding the vitrage_alarm_type: it will be usable only if there are a few 
alarm types that are used by most datasources. Otherwise it might be just as 
verbose as the name, IMO.

Anyway, you are welcome to propose a blueprint so we can discuss all details 
there.

Best Regards,
Ifat.

From: "Waines, Greg" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 4 December 2017 at 17:23
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

I am thinking that alarm suppression would be per-tenant.

Yeah i am liking the second suggestion, as well, wrt specification of 
suppressed alarms to be based on { vitrage_type & ‘regexp’ }.

Only other reason for introducing vitrage_alarm_type property is perhaps a 
‘usability’ type reason
i.e. it provides perhaps an easier / quicker indication of the general type of 
alarm (e.g. port-failure, host-failure, ntp-server-down, 
remote-log-server-down, ...) when scanning an alarm list, rather than having to 
read the sometimes verbose ‘name’ (description) field of the alarm.
But i realize it would be difficult to enforce / manage the usage of this field.
This is a lower priority item for me.

Greg.


From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Monday, December 4, 2017 at 9:32 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

Hi Greg,

First, I think that supporting alarm suppression in Vitrage is a very good idea.

One question that I have is: I understand that you plan to support it both in 
the UI and in the CLI. Do you want to the suppression to be per-user? 
per-tenant? global?

Regarding adding vitrage_alarm_type, my main concern is how the different 
datasources will fill this information. A monitor like Zabbix can have a lot of 
different alarms, and we will have to find a way to map them to the different 
alarm types. Aodh could also have its own alarm types, etc. I believe that some 
monitors will not use this property at all, which will cause:

· No way to suppress some of the alarms by vitrage_alarm_type

· Empty column in Vitrage alarms list

I think that your second suggestion, of the vitrage_type and regex, could work 
better. Is there any other reason to add the vitrage_alarm_type property, other 
than for suppression purposes?

Best Regards,
Ifat.


From: "Waines, Greg" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 4 December 2017 at 15:34
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

Thinking about this more ...
· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ 
as a mechanism to identify the general type of problem or alarm being reported 
in order to address this ?
o   could be an optional field
o   but we’d display in the alarm list
o   and we’d use it as the mechanism to suppress alarms by ‘type’


Other option:

· wrt specifying which alarms to suppress,

o   could use combination of

§  ‘vitrage_type (enum)’ field - e.g. collectd, nagios, zabbix, vitrage, ...

§  and

§  a regexp on the ‘name (string)’ field

Thoughts ?
Greg.


From: Greg Waines 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Friday, December 1, 2017 at 8:45 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by 
type and/or resource in Vitrage

Hey,

I am interested in getting some feedback on a proposed blueprint for Vitrage.

BLUEPRINT:

TITLE: Add the ability to ‘suppress’ alarms by Alarm Type and/or Resource

When managing a cloud, there are situations where a particular alarm or a set 
of alarms from a particular resource are occurring frequently, however they are 
identifying issues that are not of concern, at least for the time being.  For 
example, new hardware is in the process of being installed and resulting in 
alarms to occur, or remote servers (e.g. NTP Servers) are unreliable and result 
in frequent connectivity alarms.   In these situations, these irrelevant alarms 
are cluttering the alarm displays and it would be helpful to be able to 
suppress these alarms.

Suppressed alarms would not be shown in Active Alarm lists or Historical Alarm

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

2017-12-04 Thread Julien Danjou

On Mon, Dec 04 2017, gordon chung wrote:

> but at the end of the day, are you building for reality or for some 
> personal ideal scenario? :p

Haha, you know that if I was building for an ideal scenario, most of
Ceilometer would probably have never existed in this way.

Half of Ceilometer is already hacking around OpenStack project
limitation for the last 5 years.

> is there a service that offers a stats endpoint?

Outside of OpenStack? Plenty. :)

-- 
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] [ceilometer][cinder]about cinder volume usage

2017-12-04 Thread gordon chung



On 2017-12-04 08:53 AM, Julien Danjou wrote:
> Which is usually a problem because of the APIs, not Ceilometer. They're
> sometimes utterly slow for simple things and other times don't offer a
> way to retrieve what Ceilometer needs in a batch-y way.
> 
>> in general, there's a preference that stats be pushed to ceilometer
>> rather than pulled.
> Yes, but for the wrong reasons. Having a component sending a batch of
> notification every hour without any configuration knob and granularity
> choice is a PITA for the users. Plus it ususally comes from a single
> point (of failure?).

well you can configure it, just at a per service level.. but that's a 
fair point.

> 
> Ceilometer would do a better job than $project at getting this info, if
> said project(s) would offer a proper and performant API to retrieve them
> efficiently.

but at the end of the day, are you building for reality or for some 
personal ideal scenario? :p is there a service that offers a stats endpoint?

-- 
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] [ceilometer][cinder]about cinder volume usage

2017-12-04 Thread Duncan Thomas

Either way step one is to propose the code for a better replacement. I
doubt you'll get much opposition to that.

No need to propose removing the old code immediately, it can live in
parallel for as long as needed.

On 4 December 2017 at 15:14, Jaze Lee  wrote:
> 2017-12-04 19:36 GMT+08:00 Duncan Thomas :
>> Why remove something that works and people are using?
>
> Yes, removing it will make noise.
>
>>
>> If polster can be set up to do the job, then great, but there's no
>> rush to remove the existing infrastructure; this is one case where
>> duplication is very, very cheap.
>
> Yes it is too cheap to refuse. But i think it should be not exists there.
>
>>
>> On 4 December 2017 at 10:30, Jaze Lee  wrote:
>>> Hello,
>>>
>>> Right now,we can get volume from central pollester. Then i think
>>> may be we can drop cinder volume usage.
>>>Cinder volume usage, do not like nova usage which is in nova
>>> compute. It is a cmd.  And should put it in cron. This will cause more
>>> work in devops. If ceilometer
>>> pollester can handle it. I think may be we should remove it?
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 谦谦君子
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Duncan Thomas
>>
>> __
>> OpenStack Development Mailing 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



-- 
Duncan Thomas

__
OpenStack Development Mailing 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] put router in vm rather than namespace

2017-12-04 Thread Miguel Angel Ajo Pelayo

That adds more latency, I believe some vendor plugins do it like that
(service VM).

Have you checked out networking-ovn?, it's all done in openflow, and you
have Ha (A/P) for free without extra namespaces, just flows and bfd
monitoring.

On Dec 4, 2017 4:22 PM, "Jaze Lee"  wrote:

> Hello,
> Can we put router into virtual machine rather than in namespace? Then
> the HA, and devops will be more elegant. You can live mirage, and use
> haproxy.
> The namespace can not be live mirage. It is bind to the host and lose
> flexible.
> Or is there some talks or specs about this?
>
> --
> 谦谦君子
>
> __
> OpenStack Development Mailing 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] [ceilometer] remove gnocchi http interface?

2017-12-04 Thread gordon chung

On 2017-12-04 09:52 AM, Jaze Lee wrote:
> 2017-12-04 20:53 GMT+08:00 gordon chung :
>> i'm curious. how does a "simple tcp socket" protect ou against
> 
> I do not quite understand 'protect ou against'.
> The tcp socket means it is a client to send samples to gnocchi tcp server.
> 

oh sorry, i meant "protect you against". i'm just wondering how this tcp 
server authenticates? and if not, why not just have two APIs where one 
is user facing and authenticates, and internally another that doesn't 
for ceilometer->gnocchi?

cheers,

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

[openstack-dev] [docs][i18n] Planning for Rocky PTG

2017-12-04 Thread Petr Kovar

Hi all,

At the last docs meeting, we agreed to start planning on what
docs and i18n topics to focus on during the docs meetup at the upcoming
Dublin PTG. Apart from reviewing our progress on action items defined at
the previous PTG, we also want to cover other high-priority areas,
infrastructure or content-related.

We have a shared docs+i18n planning etherpad, but for now, keep the
topics for docs and i18n separate. 

If you plan to take part in the docs+i18n sessions, please sign up, state
your preference as to whether you want to meet on the theme days or during
the team days of the PTG week, and finally add your own ideas for
discussion:

https://etherpad.openstack.org/p/docs-i18n-ptg-rocky

Thanks,
pk

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

Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

2017-12-04 Thread Waines, Greg

I am thinking that alarm suppression would be per-tenant.

Yeah i am liking the second suggestion, as well, wrt specification of 
suppressed alarms to be based on { vitrage_type & ‘regexp’ }.

Only other reason for introducing vitrage_alarm_type property is perhaps a 
‘usability’ type reason
i.e. it provides perhaps an easier / quicker indication of the general type of 
alarm (e.g. port-failure, host-failure, ntp-server-down, 
remote-log-server-down, ...) when scanning an alarm list, rather than having to 
read the sometimes verbose ‘name’ (description) field of the alarm.
But i realize it would be difficult to enforce / manage the usage of this field.
This is a lower priority item for me.

Greg.


From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Monday, December 4, 2017 at 9:32 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

Hi Greg,

First, I think that supporting alarm suppression in Vitrage is a very good idea.

One question that I have is: I understand that you plan to support it both in 
the UI and in the CLI. Do you want to the suppression to be per-user? 
per-tenant? global?

Regarding adding vitrage_alarm_type, my main concern is how the different 
datasources will fill this information. A monitor like Zabbix can have a lot of 
different alarms, and we will have to find a way to map them to the different 
alarm types. Aodh could also have its own alarm types, etc. I believe that some 
monitors will not use this property at all, which will cause:

· No way to suppress some of the alarms by vitrage_alarm_type

· Empty column in Vitrage alarms list

I think that your second suggestion, of the vitrage_type and regex, could work 
better. Is there any other reason to add the vitrage_alarm_type property, other 
than for suppression purposes?

Best Regards,
Ifat.


From: "Waines, Greg" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 4 December 2017 at 15:34
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

Thinking about this more ...
· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ 
as a mechanism to identify the general type of problem or alarm being reported 
in order to address this ?
o   could be an optional field
o   but we’d display in the alarm list
o   and we’d use it as the mechanism to suppress alarms by ‘type’


Other option:

· wrt specifying which alarms to suppress,

o   could use combination of

§  ‘vitrage_type (enum)’ field - e.g. collectd, nagios, zabbix, vitrage, ...

§  and

§  a regexp on the ‘name (string)’ field

Thoughts ?
Greg.


From: Greg Waines 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Friday, December 1, 2017 at 8:45 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by 
type and/or resource in Vitrage

Hey,

I am interested in getting some feedback on a proposed blueprint for Vitrage.

BLUEPRINT:

TITLE: Add the ability to ‘suppress’ alarms by Alarm Type and/or Resource

When managing a cloud, there are situations where a particular alarm or a set 
of alarms from a particular resource are occurring frequently, however they are 
identifying issues that are not of concern, at least for the time being.  For 
example, new hardware is in the process of being installed and resulting in 
alarms to occur, or remote servers (e.g. NTP Servers) are unreliable and result 
in frequent connectivity alarms.   In these situations, these irrelevant alarms 
are cluttering the alarm displays and it would be helpful to be able to 
suppress these alarms.

Suppressed alarms would not be shown in Active Alarm lists or Historical Alarm 
lists, and would not be included in alarm counts.
There would be a CLI Option / Horizon Button, to enable looking at Alarms that 
are currently suppressed.
( i.e. the idea would be that suppressed alarms would still be tracked, they 
just would not be displayed by default)

Thoughts on usefulness ?



Questions on how to implement this in Vitrage

· from an end user’s point of view, alarms have the following fields

o   vitrage_id (uuid) - unique identifier of an instance of an alarm

o   vitrage_type (enum) - e.g. collectd, nagios, zabbix, vitrage, ...
  - really an identifier of the general 
entity reporting the alarm

o   name (string) - the alarm description

o

[openstack-dev] [neutron] put router in vm rather than namespace

2017-12-04 Thread Jaze Lee

Hello,
Can we put router into virtual machine rather than in namespace? Then
the HA, and devops will be more elegant. You can live mirage, and use haproxy.
The namespace can not be live mirage. It is bind to the host and lose flexible.
Or is there some talks or specs about this?

-- 
谦谦君子

__
OpenStack Development Mailing 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] [rally]404 on docker rallyforge/rally

2017-12-04 Thread Matthieu Simonin



- Mail original -
> De: "Swapnil Kulkarni" 
> À: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Envoyé: Lundi 4 Décembre 2017 12:57:36
> Objet: Re: [openstack-dev] [rally]404 on docker rallyforge/rally
> 
> On Mon, Dec 4, 2017 at 4:13 PM, Matthieu Simonin
>  wrote:
> > Hi,
> >
> > Monday morning and it seems that docker images for rally aren't reachable
> > anymore.
> >
> > https://hub.docker.com/r/rallyforge/rally/
> >
> > Did I miss something ? Is the doc up-to-date[1] ?
> >
> > [1]:
> > http://rally.readthedocs.io/en/0.10.0/install_and_upgrade/install.html#rally-docker
> >
> > Matt
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> I think you need to refer to [1] for updated docs and [2] should be
> able to help you with rally-docker information which might be useful
> for you.

Thanks Swapnil, but the namespace rallyforge[1] is now empty 
(or all images are private) on docker hub.

I have no problem building images on my own, but I just wanted to make
sure this is now the only way I can use the rally images. 

If so the doc will need to be updated to remove any reference to 
rallyforge/rally.


[1] https://hub.docker.com/r/rallyforge/

Best,

Matthieu

> 
> [1] https://docs.openstack.org/rally/latest/
> [2]
> https://docs.openstack.org/rally/latest/install_and_upgrade/install.html#rally-docker
> 
> __
> OpenStack Development Mailing 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] [ceilometer][cinder]about cinder volume usage

2017-12-04 Thread Jaze Lee

2017-12-04 19:36 GMT+08:00 Duncan Thomas :
> Why remove something that works and people are using?

Yes, removing it will make noise.

>
> If polster can be set up to do the job, then great, but there's no
> rush to remove the existing infrastructure; this is one case where
> duplication is very, very cheap.

Yes it is too cheap to refuse. But i think it should be not exists there.

>
> On 4 December 2017 at 10:30, Jaze Lee  wrote:
>> Hello,
>>
>> Right now,we can get volume from central pollester. Then i think
>> may be we can drop cinder volume usage.
>>Cinder volume usage, do not like nova usage which is in nova
>> compute. It is a cmd.  And should put it in cron. This will cause more
>> work in devops. If ceilometer
>> pollester can handle it. I think may be we should remove it?
>>
>>
>>
>>
>>
>> --
>> 谦谦君子
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Duncan Thomas
>
> __
> OpenStack Development Mailing 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] [ceilometer][cinder]about cinder volume usage

2017-12-04 Thread Jaze Lee

2017-12-04 20:57 GMT+08:00 gordon chung :
>
>
> On 2017-12-04 05:30 AM, Jaze Lee wrote:
>>  Right now,we can get volume from central pollester. Then i think
>> may be we can drop cinder volume usage.
>
> which metrics are you referring to? just for the record, except for
> libvirt stats, the polling done by ceilometer is against the API which
> may create additional load.

I mean volume.exists snapshot.exists, and backup.exists

>
> in general, there's a preference that stats be pushed to ceilometer
> rather than pulled.

The cinder volume usage cmd is too difficult to use in production. I
do not know
why don't learn from nova?  Put it in a periodic task, and can be configurable.


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



-- 
谦谦君子

__
OpenStack Development Mailing 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] [api] api-sig weekly meeting time change request

2017-12-04 Thread michael mccune


On 12/03/2017 10:26 PM, Gilles Dubreuil wrote:

Hi,

Could we please change the API SIG weekly meeting time from 16pm UTC to 
19pm UTC  [1]?

To give a chance for those down under to attend?


hey Gilles,

we have proposed adding another meeting time to make things easier for 
folks in the APAC regions. sadly, every time we have brought this up the 
response has been lackluster from people in that region.


i think the group is willing to discuss having a meeting time to enable 
APAC but it would be helpful to have a good indication of who the 
meeting would serve as pushing the time back by 3 hours will negatively 
impact the EMEA folks. i had sent this survey[1] to the mailing list but 
didn't get much response.


peace o/

[1]: https://goo.gl/forms/0mVV4TGT7bZGAK323



Cheers,
Gilles

[1] 
https://www.timeanddate.com/worldclock/meetingtime.html?iso=20171204=195=137=240 






__
OpenStack Development Mailing 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] [ceilometer] remove gnocchi http interface?

2017-12-04 Thread Jaze Lee

2017-12-04 20:53 GMT+08:00 gordon chung :
>
>
> On 2017-12-03 10:41 PM, Jaze Lee wrote:
>> So what about to remove gnocchi http, and add a simple tcp socket, which
>>   will send to gnocchi tcp server(which will also be created.).
>
> i'm curious. how does a "simple tcp socket" protect ou against

I do not quite understand 'protect ou against'.
The tcp socket means it is a client to send samples to gnocchi tcp server.


>
>  > anyone can update gnocchi database which is not we want
>
> --
> 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



-- 
谦谦君子

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

Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

2017-12-04 Thread Afek, Ifat (Nokia - IL/Kfar Sava)

Hi Greg,

First, I think that supporting alarm suppression in Vitrage is a very good idea.

One question that I have is: I understand that you plan to support it both in 
the UI and in the CLI. Do you want to the suppression to be per-user? 
per-tenant? global?

Regarding adding vitrage_alarm_type, my main concern is how the different 
datasources will fill this information. A monitor like Zabbix can have a lot of 
different alarms, and we will have to find a way to map them to the different 
alarm types. Aodh could also have its own alarm types, etc. I believe that some 
monitors will not use this property at all, which will cause:

· No way to suppress some of the alarms by vitrage_alarm_type

· Empty column in Vitrage alarms list

I think that your second suggestion, of the vitrage_type and regex, could work 
better. Is there any other reason to add the vitrage_alarm_type property, other 
than for suppression purposes?

Best Regards,
Ifat.


From: "Waines, Greg" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 4 December 2017 at 15:34
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

Thinking about this more ...
· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ 
as a mechanism to identify the general type of problem or alarm being reported 
in order to address this ?
o   could be an optional field
o   but we’d display in the alarm list
o   and we’d use it as the mechanism to suppress alarms by ‘type’


Other option:

· wrt specifying which alarms to suppress,

o   could use combination of

§  ‘vitrage_type (enum)’ field - e.g. collectd, nagios, zabbix, vitrage, ...

§  and

§  a regexp on the ‘name (string)’ field

Thoughts ?
Greg.


From: Greg Waines 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Friday, December 1, 2017 at 8:45 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by 
type and/or resource in Vitrage

Hey,

I am interested in getting some feedback on a proposed blueprint for Vitrage.

BLUEPRINT:

TITLE: Add the ability to ‘suppress’ alarms by Alarm Type and/or Resource

When managing a cloud, there are situations where a particular alarm or a set 
of alarms from a particular resource are occurring frequently, however they are 
identifying issues that are not of concern, at least for the time being.  For 
example, new hardware is in the process of being installed and resulting in 
alarms to occur, or remote servers (e.g. NTP Servers) are unreliable and result 
in frequent connectivity alarms.   In these situations, these irrelevant alarms 
are cluttering the alarm displays and it would be helpful to be able to 
suppress these alarms.

Suppressed alarms would not be shown in Active Alarm lists or Historical Alarm 
lists, and would not be included in alarm counts.
There would be a CLI Option / Horizon Button, to enable looking at Alarms that 
are currently suppressed.
( i.e. the idea would be that suppressed alarms would still be tracked, they 
just would not be displayed by default)

Thoughts on usefulness ?



Questions on how to implement this in Vitrage

· from an end user’s point of view, alarms have the following fields

o   vitrage_id (uuid) - unique identifier of an instance of an alarm

o   vitrage_type (enum) - e.g. collectd, nagios, zabbix, vitrage, ...
  - really an identifier of the general 
entity reporting the alarm

o   name (string) - the alarm description

o   vitrage_resource_type (enum) - e.g. nova.instance, nova.host, port, ...

o   vitrage_resource_id (uuid) - resource instance

o   vitrage_aggregated_severity

o   vitrage_operational_severity

o   update_timestamp

·

· there definitely is a specific resource identifier in order to be 
able to suppress alarms from a particular resource

·

· BUT there doesn’t seem like there is a general alarm type field
i.e. that would classify the type of problem that’s occurring
e.g.

o   communication failure with compute host

o   loss-of-signal on port of compute host

o   loss of connectivity with NTP Server

o   CPU Threshold exceeded on compute host

o   Memory Threshold exceeded on compute host

o   File System Threshold exceeded on compute host

o   etc.

· ... which would be type/granularity of ‘Alarm Type’ that i would 
think the user would want to suppress alarms based on.

· i.e. it seems like the ‘name’ field is a combination of this general 
Alarm Type and details on the particular alarm.

·

· Any thoughts on adding a ‘vitrage_alarm_type (enum

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

2017-12-04 Thread Loo, Ruby

Please ignore this; we didn't have a weekly meeting (because we had our 
midcycle virtual meet up instead).

--ruby

From: "Yeleswarapu, Ramamani" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, November 27, 2017 at 5:29 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [ironic] this week's priorities and subteam reports

Hi,

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

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

1. Midcycle planning: https://etherpad.openstack.org/p/ironic-queens-midcycle
2. Use adapters for cinderclient: https://review.openstack.org/#/c/476171/ 
MERGED
2.1. then also for inspector client: 
https://review.openstack.org/#/c/476172/ MERGED
3. install guide update for hw types: https://review.openstack.org/#/c/517290/
3.1. before that, separate pages for deploy and boot interfaces: 
https://review.openstack.org/#/c/517632/
4. BIOS interface spec: https://review.openstack.org/#/c/496481/
5. Rescue:
5.1. driver interface https://review.openstack.org/#/c/509335/
5.2. RPC https://review.openstack.org/#/c/509336/
5.3. rescuewait timeout https://review.openstack.org/#/c/353156

Vendor priorities
-
cisco-ucs:
Patchs in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:

ilo:
https://review.openstack.org/207337 - Out-of-band Boot from UEFI iSCSI 
volume for HPE Proliant server
irmc:
SPEC to add a new hardware type for another FUJITSU server: PRIMEQUEST MMB:
  https://review.openstack.org/#/c/515717/ MERGED

oneview:
Add validations for OneView ML2 driver -  
https://review.openstack.org/#/c/508946/

Subproject priorities
-
bifrost:
ironic-inspector (or its client):
  - dnsmasq-based inspector PXE filter driver: 
https://review.openstack.org/#/c/466448/ TL;DR: replaces iptables with a 
dynamic configuration of dnsmasq (pretty cool thing too ;)
- folks might consider trying the test patch to experiment manually with 
this https://review.openstack.org/#/c/468712/54
networking-baremetal:
neutron baremetal agent https://review.openstack.org/#/c/456235/
sushy and the redfish driver:
(dtantsur) implement redfish sessions: 
https://review.openstack.org/#/c/471942/

Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 13 Nov 2017 and 20 Nov 2017)
- Ironic: 219 bugs (-4) + 254 wishlist items (+7). 11 new (-2), 153 in progress 
(+2), 0 critical, 31 high and 35 incomplete (+1)
- Inspector: 16 bugs + 31 wishlist items. 0 new (-2), 16 in progress, 0 
critical, 4 high and 5 incomplete (+2)
- Nova bugs with Ironic tag: 14 (+1). 2 new (+1), 0 critical, 1 high
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix to return 'root_uuid' as part of command status 
https://review.openstack.org/#/c/500719/4
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- If provisioning network is changed, Ironic conductor does not behave 
correctly https://bugs.launchpad.net/ironic/+bug/1679260: Ironic conductor 
works correctly on changes of networks: https://review.openstack.org/#/c/462931/
- (rloo) needs some direction

CI refactoring and missing test coverage

- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- localboot with partitioned image patches:
- IPA - build tinycore based partitioned image with grub 
https://review.openstack.org/#/c/504888/
- Ironic - add localboot partitioned image test: 
https://review.openstack.org/#/c/502886/
- when previous are merged TODO (vsaienko)
- Upload tinycore partitioned image to tarbals.openstack.org
- Switch ironic to use tinyipa partitioned image by default
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- adoption: https://review.openstack.org/#/c/344975/
- should probably be changed to use standalone tests
- root device hints: TODO
- node take over
- resource classes integration tests: 
https://review.openstack.org/#/c/443628/

Essential Priorities


Ironic

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

2017-12-04 Thread Julien Danjou

On Mon, Dec 04 2017, gordon chung wrote:

> On 2017-12-04 05:30 AM, Jaze Lee wrote:
>>  Right now,we can get volume from central pollester. Then i think
>> may be we can drop cinder volume usage.
>
> which metrics are you referring to? just for the record, except for 
> libvirt stats, the polling done by ceilometer is against the API which 
> may create additional load.

Which is usually a problem because of the APIs, not Ceilometer. They're
sometimes utterly slow for simple things and other times don't offer a
way to retrieve what Ceilometer needs in a batch-y way.

> in general, there's a preference that stats be pushed to ceilometer 
> rather than pulled.

Yes, but for the wrong reasons. Having a component sending a batch of
notification every hour without any configuration knob and granularity
choice is a PITA for the users. Plus it ususally comes from a single
point (of failure?).

Ceilometer would do a better job than $project at getting this info, if
said project(s) would offer a proper and performant API to retrieve them
efficiently.

-- 
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] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

2017-12-04 Thread Waines, Greg

Thinking about this more ...
· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ 
as a mechanism to identify the general type of problem or alarm being reported 
in order to address this ?
ocould be an optional field
obut we’d display in the alarm list
oand we’d use it as the mechanism to suppress alarms by ‘type’


Other option:

· wrt specifying which alarms to suppress,

ocould use combination of

§  ‘vitrage_type (enum)’ field - e.g. collectd, nagios, zabbix, vitrage, ...

§  and

§  a regexp on the ‘name (string)’ field

Thoughts ?
Greg.


From: Greg Waines 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Friday, December 1, 2017 at 8:45 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by 
type and/or resource in Vitrage

Hey,

I am interested in getting some feedback on a proposed blueprint for Vitrage.

BLUEPRINT:

TITLE: Add the ability to ‘suppress’ alarms by Alarm Type and/or Resource

When managing a cloud, there are situations where a particular alarm or a set 
of alarms from a particular resource are occurring frequently, however they are 
identifying issues that are not of concern, at least for the time being.  For 
example, new hardware is in the process of being installed and resulting in 
alarms to occur, or remote servers (e.g. NTP Servers) are unreliable and result 
in frequent connectivity alarms.   In these situations, these irrelevant alarms 
are cluttering the alarm displays and it would be helpful to be able to 
suppress these alarms.

Suppressed alarms would not be shown in Active Alarm lists or Historical Alarm 
lists, and would not be included in alarm counts.
There would be a CLI Option / Horizon Button, to enable looking at Alarms that 
are currently suppressed.
( i.e. the idea would be that suppressed alarms would still be tracked, they 
just would not be displayed by default)

Thoughts on usefulness ?



Questions on how to implement this in Vitrage

· from an end user’s point of view, alarms have the following fields

o   vitrage_id (uuid) - unique identifier of an instance of an alarm

o   vitrage_type (enum) - e.g. collectd, nagios, zabbix, vitrage, ...
  - really an identifier of the general 
entity reporting the alarm

o   name (string) - the alarm description

o   vitrage_resource_type (enum) - e.g. nova.instance, nova.host, port, ...

o   vitrage_resource_id (uuid) - resource instance

o   vitrage_aggregated_severity

o   vitrage_operational_severity

o   update_timestamp

·

· there definitely is a specific resource identifier in order to be 
able to suppress alarms from a particular resource

·

· BUT there doesn’t seem like there is a general alarm type field
i.e. that would classify the type of problem that’s occurring
e.g.

o   communication failure with compute host

o   loss-of-signal on port of compute host

o   loss of connectivity with NTP Server

o   CPU Threshold exceeded on compute host

o   Memory Threshold exceeded on compute host

o   File System Threshold exceeded on compute host

o   etc.

· ... which would be type/granularity of ‘Alarm Type’ that i would 
think the user would want to suppress alarms based on.

· i.e. it seems like the ‘name’ field is a combination of this general 
Alarm Type and details on the particular alarm.

·

· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ 
as a mechanism to identify the general type of problem or alarm being reported 
in order to address this ?

o   could be an optional field

o   but we’d display in the alarm list

o   and we’d use it as the mechanism to suppress alarms by ‘type’

 Let me know what you think ?


Greg.







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

[openstack-dev] [neutron] [networking-ovn] Non voting jobs for networking-ovn on neutron.

2017-12-04 Thread Miguel Angel Ajo Pelayo

Hi Folks,
 I wanted to rise this topic, I have been wanting to do it from long
ago,
but preferred to wait until the zuulv3 stuff was a little bit more stable,
may
be now it's a good time.

We were thinking about the option of having a couple of non-voting jobs
on
the neutron check for networking-ovn. It'd be great for us, in terms of
traceability,
we re-use a lot of the neutron unit test base clases/etc, and sometimes
we get hit by surprises.

Sometimes some other changes hit us on the neutron scenario tests.

So it'd be great to have them if you believe it's a reasonable thing.

Best regards,
Miguel Ángel.
__
OpenStack Development Mailing 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] Neutron L3 agent/Keepalived

2017-12-04 Thread Anna Taraday

Please, file a bug about that on https://bugs.launchpad.net/neutron/+bugs
with tag "l3-ha".

On Thu, Nov 30, 2017 at 6:00 AM Ajay Kalambur (akalambu) 
wrote:

> I noticed that this happens when the router HA interface shows status:
> Down what can cause the ha interface to do down
>
> Ajay
>
>
> From: Ajay Kalambur 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, November 29, 2017 at 4:14 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [neutron] Neutron L3 agent/Keepalived
>
> Hi
> I have a case where after running the system for a while I see that
> floating ip association API gets accepted and no Errors in neutron l3 logs
> But when I go into the qrouter namespace and check the qg- interface the
> floating ip is not added
> Also the keepalived.conf is not updated and SIGUP of the keepalived
> process is not done
>
> So whats the place to look in this case.  What is the flow in neutron l3
> agent who adds the floating ip to the qg- interface
> I see the router update notification received
> Key log snippet attached. As you can see SIGUP of keepalived is missing
> and also I confirmed keepalived configs are not updated
>
>
> 2017-11-29 14:32:08.883 78 DEBUG oslo_messaging._drivers.amqpdriver [-]
> received message with unique_id: b3886b998c3049e799170bb5351300d1 __call__
> /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:269
> 2017-11-29 14:32:08.885 78 DEBUG neutron.agent.l3.agent
> [req-6c505d32-2d1a-4392-8ea3-0bb888397b9e e759eebecc4648b4964d4ecf439dc0ff
> 13b4f6fb188048ba9bbf211344e3342f - - -] Got routers updated notification
> :[u'a1a59e5f-d74e-404d-a3aa-1667c4442aed'] routers_updated
> /usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py:413
> 2017-11-29 14:32:08.886 78 DEBUG neutron.agent.l3.agent [-] Starting
> router update for a1a59e5f-d74e-404d-a3aa-1667c4442aed, action None,
> priority 0 _process_router_update
> /usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py:487
> 2017-11-29 14:32:08.886 78 DEBUG oslo_messaging._drivers.amqpdriver [-]
> CALL msg_id: 92eb015c8c84489681b1efbe949fab8b exchange 'neutron' topic
> 'q-l3-plugin' _send
> /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:568
>
> 2017-11-29 14:32:09.571 78 DEBUG oslo_messaging._drivers.amqpdriver [-]
> received reply msg_id: 92eb015c8c84489681b1efbe949fab8b __call__
> /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:416
> 2017-11-29 14:32:09.571 78 DEBUG neutron.callbacks.manager [-] Notify
> callbacks [] for router, before_update _notify_loop
> /usr/lib/python2.7/site-packages/neutron/callbacks/manager.py:142
> 2017-11-29 14:32:09.572 78 DEBUG neutron.agent.l3.router_info [-] process
> router updates process
> /usr/lib/python2.7/site-packages/neutron/agent/l3/router_info.py:1105
> 2017-11-29 14:32:09.572 78 DEBUG neutron.agent.linux.utils [-] Running
> command (rootwrap daemon): ['ip', 'netns', 'exec',
> 'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'find', '/sys/class/net',
> '-maxdepth', '1', '-type', 'l', '-printf', '%f '] execute_rootwrap_daemon
> /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
> 2017-11-29 14:32:09.709 78 DEBUG neutron.agent.linux.utils [-] Exit code:
> 0 execute /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:150
> 2017-11-29 14:32:09.710 78 DEBUG oslo_concurrency.lockutils [-] Lock
> "l3-agent-pd" acquired by "neutron.agent.linux.pd.sync_router" :: waited
> 0.000s inner
> /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270
> 2017-11-29 14:32:09.710 78 DEBUG oslo_concurrency.lockutils [-] Lock
> "l3-agent-pd" released by "neutron.agent.linux.pd.sync_router" :: held
> 0.000s inner
> /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282
> 2017-11-29 14:32:09.710 78 DEBUG neutron.agent.linux.utils [-] Running
> command (rootwrap daemon): ['ip', 'netns', 'exec',
> 'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'find', '/sys/class/net',
> '-maxdepth', '1', '-type', 'l', '-printf', '%f '] execute_rootwrap_daemon
> /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
> 2017-11-29 14:32:09.845 78 DEBUG neutron.agent.linux.utils [-] Exit code:
> 0 execute /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:150
> 2017-11-29 14:32:09.846 78 DEBUG oslo_concurrency.lockutils [-] Acquired
> semaphore "iptables-qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed" lock
> /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:212
> 2017-11-29 14:32:09.846 78 DEBUG neutron.agent.linux.utils [-] Running
> command (rootwrap daemon): ['ip', 'netns', 'exec',
> 'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'iptables-save']
> execute_rootwrap_daemon
> /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
> 2017-11-29 14:32:09.983 78 DEBUG

Re: [openstack-dev] [ceilometer] about workload partition

2017-12-04 Thread gordon chung



On 2017-12-03 10:30 PM, 李田清 wrote:
> 
> 
> On 2017-12-01 05:03 AM, 李田清 wrote:
>  >> Hello,
>  >>       we test workload partition, and find it's much slower than not
>  >> using it.
>  >>       After some review, we find that, after get samples from
>  >> notifications.sample
>  >>       ceilometer unpacks them and sends them one by one to the pipe
>  >>       ceilometer.pipe.*, this will make the consumer slow. Right now,
>  >> the rabbit_qos_prefetch_count to 1. If we sent it to 10, the connection
>  >> will be reset
> 
>  > currently, i believe rabbit_qos_prefetch_count will be set to whatever
>  > value you set batch_size to.
> You mean in the past, it can not be set to whatever?
> We test newton, and find under 1k vm, if we open workload partition,
> it will be reset regularly.
> 
>  >i'll give a two part answer but first i'll start with a question: what
>  >version of oslo.messaging do you have?
> 
> newton 5.10.2
> 

i just checked, oslo.messaging==5.10.2 has the offending patch that 
decreases performance significantly. as newton is EOL, it seems you have 
a few choices:
- revert to 5.10.1 but i'm not sure if that reintroduces old bugs
- manually patch your oslo.messaging with: 
https://review.openstack.org/#/c/524099
- pull in a newer oslo.messaging from another branch (fix is unreleased 
currently)
- manually patch notification agent to use multiple threads[1] (but this 
will possibly add some instability to your transforms)
- disable workload_partitioning

option 2 or 5 are probably the safest choices depending on your load.

[1] 
https://github.com/openstack/ceilometer/blob/newton-eol/ceilometer/notification.py#L305-L307

cheers,

-- 
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] [Neutron] Propose Slawek Kaplonski for Neutron core

2017-12-04 Thread Anna Taraday

+1 !
Well deserved!

On Sun, Dec 3, 2017 at 1:03 PM Gary Kotton  wrote:

> +1
>
>
>
> Welcome to the team!
>
>
>
> *From: *Miguel Lavalle 
> *Reply-To: *OpenStack List 
> *Date: *Wednesday, November 29, 2017 at 9:21 PM
> *To: *OpenStack List 
> *Subject: *[openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron
> core
>
>
>
> Hi Neutron Team,
>
>
>
> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
> has been an active contributor to the project since the Mitaka cycle. He
> has been instrumental in the development of the QoS capabilities in
> Neutron, becoming the lead of the sub-team focused on that set of features.
> More recently, he has collaborated in the implementation of OVO and is an
> active participant in the CI sub-team. His number of code reviews during
> the Queens cycle is on par with the leading core members of the team:
> http://stackalytics.com/?module=neutron
> 
>
>
>
> In my opinion, his efforts are highly valuable to the team and we will be
> very lucky to have him as a fully voting core.
>
>
>
> I will keep this nomination open for a week as customary,
>
>
>
> Thank you,
>
>
>
> Miguel
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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] [ceilometer][cinder]about cinder volume usage

2017-12-04 Thread gordon chung

On 2017-12-04 05:30 AM, Jaze Lee wrote:
>  Right now,we can get volume from central pollester. Then i think
> may be we can drop cinder volume usage.

which metrics are you referring to? just for the record, except for 
libvirt stats, the polling done by ceilometer is against the API which 
may create additional load.

in general, there's a preference that stats be pushed to ceilometer 
rather than pulled.

cheers,

-- 
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] [ceilometer] remove gnocchi http interface?

2017-12-04 Thread gordon chung



On 2017-12-03 10:41 PM, Jaze Lee wrote:
> So what about to remove gnocchi http, and add a simple tcp socket, which
>   will send to gnocchi tcp server(which will also be created.).

i'm curious. how does a "simple tcp socket" protect ou against

 > anyone can update gnocchi database which is not we want

-- 
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] [rally]404 on docker rallyforge/rally

2017-12-04 Thread Swapnil Kulkarni

On Mon, Dec 4, 2017 at 4:13 PM, Matthieu Simonin
 wrote:
> Hi,
>
> Monday morning and it seems that docker images for rally aren't reachable 
> anymore.
>
> https://hub.docker.com/r/rallyforge/rally/
>
> Did I miss something ? Is the doc up-to-date[1] ?
>
> [1]: 
> http://rally.readthedocs.io/en/0.10.0/install_and_upgrade/install.html#rally-docker
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


I think you need to refer to [1] for updated docs and [2] should be
able to help you with rally-docker information which might be useful
for you.

[1] https://docs.openstack.org/rally/latest/
[2] 
https://docs.openstack.org/rally/latest/install_and_upgrade/install.html#rally-docker

__
OpenStack Development Mailing 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][ovn] networking-ovn core team update

2017-12-04 Thread Numan Siddique

Congratulations Daniel. Welcome :)

Thanks
Numan


On Fri, Dec 1, 2017 at 10:27 PM, Anil Venkata 
wrote:

> Congrats Daniel
>
> On 01-Dec-2017 10:22 PM, "Jakub Libosvar"  wrote:
>
>> Congratulations! Very well deserved! :)
>>
>> On 01/12/2017 17:45, Lucas Alvares Gomes wrote:
>> > Hi all,
>> >
>> > I would like to welcome Daniel Alvarez to the networking-ovn core team!
>> >
>> > Daniel has been contributing with the project for a good time already
>> > and helping *a lot* with reviews and code.
>> >
>> > Welcome onboard man!
>> >
>> > Cheers,
>> > Lucas
>> >
>> > 
>> __
>> > 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] [ceilometer][cinder]about cinder volume usage

2017-12-04 Thread Duncan Thomas

Why remove something that works and people are using?

If polster can be set up to do the job, then great, but there's no
rush to remove the existing infrastructure; this is one case where
duplication is very, very cheap.

On 4 December 2017 at 10:30, Jaze Lee  wrote:
> Hello,
>
> Right now,we can get volume from central pollester. Then i think
> may be we can drop cinder volume usage.
>Cinder volume usage, do not like nova usage which is in nova
> compute. It is a cmd.  And should put it in cron. This will cause more
> work in devops. If ceilometer
> pollester can handle it. I think may be we should remove it?
>
>
>
>
>
> --
> 谦谦君子
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Duncan Thomas

__
OpenStack Development Mailing 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] [ceilometer] remove gnocchi http interface?

2017-12-04 Thread Jaze Lee

2017-12-04 18:41 GMT+08:00 Julien Danjou :
> On Mon, Dec 04 2017, Jaze Lee wrote:
>
>> Right now, the dispatch will cost much time in http request. And
>> keystone auth token cost much time. Although we can configure it to
>> noauth, then anyone can update gnocchi database which is not we want.
>
>
>>  So what about to remove gnocchi http, and add a simple tcp socket, which
>>  will send to gnocchi tcp server(which will also be created.). At
>> first, we think udp,
>
> … and then "anyone can update gnocchi database which is not you want."
>
> I'm not saying it's not a good idea, but your arguments don't sound
> right. :)
>
> There's already an issue here
>   https://github.com/gnocchixyz/gnocchi/issues/496
> that you opened.
>
> At that point, you need more than "suggesting", you need to provide plan
> and code if you want that to happen "soon". :)

OK. it will be soon, wait for a little moment.. :}
>
> --
> 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

Re: [openstack-dev] [nova] [placement] resource providers update 43

2017-12-04 Thread Balazs Gibizer

On Sat, Dec 2, 2017 at 3:26 AM, Matt Riedemann  
wrote:

On 12/1/2017 10:42 AM, Chris Dent wrote:
>
> December? Wherever does the time go? This is resource providers and
> placement update 43. The first one of these was more than a year ago
>
>
> 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107171.html

>
>
> I like to think they've been pretty useful. I know they've helped me
> keep track of stuff, and have a bit of focus. I'll carry on doing 
them
> but I'm starting to worry that they are getting too big, both to 
read

> and to create, and that this means something, not sure what, for the
> volume of work we're trying to accomplish. There's so much work 
going
> on all the time related to placement, writing it down in one place 
is

> rather challenging, so surely creating and reviewing it all is also
> challenging? And that's not taking into consideration the vast 
volume

> of all the other stuff within the nova umbrella. Not sure what to do
> about it, but something to start thinking about.
>

Thanks for continuing to do these. I don't read every one, but when I
do, like tonight (read the whole damn thing), I end up clicking on a 
lot
of the review links and going through a lot of them which moves the 
ball

forward on some simple but important patches.

I really like these placement summary mails. It gives me a weekly 
reminder to look at patches in series I'm not actively following. Also 
even if it is long it is in priority order. So If somebody starts at 
the top and do some review but never reach the end of the mail (like me 
most of the time); the mail still helps moving the important things 
forward.

Thank you Chris for the effort!

Cheers,
gibi

--

Thanks,

Matt

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

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

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

[openstack-dev] [rally]404 on docker rallyforge/rally

2017-12-04 Thread Matthieu Simonin

Hi,

Monday morning and it seems that docker images for rally aren't reachable 
anymore.

https://hub.docker.com/r/rallyforge/rally/

Did I miss something ? Is the doc up-to-date[1] ?

[1]: 
http://rally.readthedocs.io/en/0.10.0/install_and_upgrade/install.html#rally-docker

Matt

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

Re: [openstack-dev] [ceilometer] remove gnocchi http interface?

2017-12-04 Thread Julien Danjou

On Mon, Dec 04 2017, Jaze Lee wrote:

> Right now, the dispatch will cost much time in http request. And
> keystone auth token cost much time. Although we can configure it to
> noauth, then anyone can update gnocchi database which is not we want.


>  So what about to remove gnocchi http, and add a simple tcp socket, which
>  will send to gnocchi tcp server(which will also be created.). At
> first, we think udp,

… and then "anyone can update gnocchi database which is not you want."

I'm not saying it's not a good idea, but your arguments don't sound
right. :)

There's already an issue here
  https://github.com/gnocchixyz/gnocchi/issues/496
that you opened.

At that point, you need more than "suggesting", you need to provide plan
and code if you want that to happen "soon". :)

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

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

2017-12-04 Thread Balazs Gibizer


Hi,

Here is the status update / focus settings mail for w49

Bugs

[Undecided] https://bugs.launchpad.net/nova/+bug/1535254 illustration
of 'notify_on_state_change' are different from implementation
The fix merged to the master and backports has been proposed to the
stable branches https://review.openstack.org/#/q/topic:bug/1535254


Versioned notification transformation
-
The following transformation patches are ready:
* https://review.openstack.org/#/c/396811 Transform 
instance.resize_revert notification

This only needs a second +2
* https://review.openstack.org/#/c/410297 Transform missing delete
notifications
* https://review.openstack.org/#/c/476459 Send soft_delete from context
manager


Service create and destroy notifications

https://blueprints.launchpad.net/nova/+spec/service-create-destroy-notification
Implementation has been merged. One follow up patch fixing nits needs a 
second core to look at: https://review.openstack.org/#/c/523162



Factor out duplicated notification sample
-
https://review.openstack.org/#/q/topic:refactor-notification-samples

There are two patches on the branch, one of them only need a second 
core to look at.



Weekly meeting
--
This week's subteam meeting has been cancelled. Next subteam meeting 
will be held on 12th of December, Tuesday 17:00 UTC on 
openstack-meeting-4.

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


Cheers,
gibi




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

[openstack-dev] [ceilometer][cinder]about cinder volume usage

2017-12-04 Thread Jaze Lee

Hello,

Right now,we can get volume from central pollester. Then i think
may be we can drop cinder volume usage.
   Cinder volume usage, do not like nova usage which is in nova
compute. It is a cmd.  And should put it in cron. This will cause more
work in devops. If ceilometer
pollester can handle it. I think may be we should remove it?





-- 
谦谦君子

__
OpenStack Development Mailing 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] Newton promotion job now handled by rdo-phase1

2017-12-04 Thread Arx Cruz

Hello,

Just a reminder that tripleo upstream newton promotion job is now handled
by rdo-phase1 until the EOL. We are also uploading uploading the overcloud
images manually to the upstream mirror server.

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

52 matches

Mail list logo