Re: [openstack-dev] [neutron][lbaas-v2] LBaaS v2 can't consume messages

Hi, all. I found the issue about the question which I met. I installed the Liberty OpenStack environment by packstack. And I downloaded the master branch of neutron-lbaas. Then I checkout the Newton tag. Finally, I met the issue which I mentioned in previous mail. Newton neutron-lbaas doesn't

Re: [openstack-dev] [ALU] Re: [vitrage] about aodh alarm notification

I also thought that my second proposal is the more reasonable one, calling the get_all in the AodhDriver contructor. Looking forward to see the updated code, and push it upstream ☺ From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] Sent: Monday, November 28, 2016 8:10 AM To:

[openstack-dev] [glance][oslo] oslo.log 3.17.0 use_stderr default change

Hello Glance team! About a month ago the oslo team released 3.17.0 of oslo.log which contains [1] which switches the default for use_stderr from True to False. It hasn't made it into upper-constraints.txt because glance is failing[2]. There are 2 easy fixes: 1) switch the glance test to look

Re: [openstack-dev] [vitrage] about aodh alarm notification

Agree. It seems I missed the first clause in Alexeys 2nd proposal. `get_all` in constructor could be a good solution. On Mon, Nov 28, 2016 at 12:18 PM wrote: Hi all, Maybe call the get_all method in the AodhDriver constructor and cache all the alarms is a simple

Re: [openstack-dev] [new][nimble] New project: Nimble

On Mon, Nov 28, 2016 at 4:37 PM, Jay Pipes wrote: [Snip] > > I don't see any compelling reason not to work with the Nova and Ironic > projects and add the functionality you wish to see in those respective > projects. > Jay, I agree and I don't. First off, I think improving

Re: [openstack-dev] [new][nimble] New project: Nimble

On 11/27/2016 10:27 PM, Zhenguo Niu wrote: hi Jay, Ironic's existing API is admin only, which should not be exposed to end users, it is best thought of as a bare metal hypervisor API. And Ironic lacks the ability of scheduling, quotas management and multi-tenancy support, it heavily depends on

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

On Wed, Nov 16, 2016 at 11:02 AM, Armando M. wrote: > Hi > > As of today, the project neutron-vpnaas is no longer part of the neutron > governance. This was a decision reached after the project saw a dramatic > drop in active development over a prolonged period of time. > >

Re: [openstack-dev] [kolla][release][requirements] providing constraints for transitive dependencies

On Mon, Nov 28, 2016 at 02:41:08AM +, Steven Dake (stdake) wrote: > Hey folks, > > I get a lot of requests for variance reduction of transitive dependencies in > Kolla’s containers. As an example, we build from source nova. Nova itself > we can specify a version to install in the containers

[openstack-dev] 答复: Re: [vitrage] about aodh alarm notification

Hi all, Maybe call the get_all method in the AodhDriver constructor and cache all the alarms is a simple way. BR, dwj Yujun Zhang 2016-11-28 11:23 收件人 "OpenStack Development Mailing List (not for usage questions)" ,

Re: [openstack-dev] [kolla][release][requirements] providing constraints for transitive dependencies

On Mon, Nov 28, 2016 at 11:02 AM, Clark Boylan wrote: > > pip install -u /requirements/upper-constrains.txt /nova > > I think you need a to use the -c option to set the constraints file. > Sorry, i made a mistake here. Kolla is using `-c` option, right now[0].

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

Hello, Flavio, Thank you to move this forward. Is it possible to put the badges at the bottom of README.rst file? Just from the code contributors point of view. Best Regards Chaoyi Huang (joehuang) From: Flavio Percoco [fla...@redhat.com] Sent: 25

Re: [openstack-dev] [new][nimble] New project: Nimble

Thanks Sean McGinnis for pointing it out! On Sat, Nov 26, 2016 at 12:40 AM, Sean McGinnis wrote: > On Fri, Nov 25, 2016 at 05:41:28PM +0800, Zhenguo Niu wrote: > > hi all, > > > > We are pleased to introduce Nimble, a new OpenStack project which aims to > > provide bare

Re: [openstack-dev] [new][nimble] New project: Nimble

hi Jay, Ironic's existing API is admin only, which should not be exposed to end users, it is best thought of as a bare metal hypervisor API. And Ironic lacks the ability of scheduling, quotas management and multi-tenancy support, it heavily depends on Nova to expose API to end users. Nova

Re: [openstack-dev] [vitrage] about aodh alarm notification

Hi, Alexey My comments inline. On Mon, Nov 28, 2016 at 1:52 AM Weyl, Alexey (Nokia - IL) < alexey.w...@nokia.com> wrote: > Hi Dong, > > > > I can think of 2 solutions for this problem: > > 1. We can talk with the AODH developers and check if they can add > additional data for the aodh

Re: [openstack-dev] [kolla][release][requirements] providing constraints for transitive dependencies

On Sun, Nov 27, 2016, at 06:53 PM, Jeffrey Zhang wrote: > FWIW, python dependencies are fixed. > Kolla is using the following command in Dockerfile for source code > installation. > > pip install -u /requirements/upper-constrains.txt /nova I think you need a to use the -c option to set the

Re: [openstack-dev] [kolla][release][requirements] providing constraints for transitive dependencies

FWIW, python dependencies are fixed. Kolla is using the following command in Dockerfile for source code installation. pip install -u /requirements/upper-constrains.txt /nova then all python dependencies installed will use a fixed version from upper-constrains.txt. [0]

Re: [openstack-dev] [kolla] the alternative of log processing tool

sbezverk, yep. Event though I prefer to use Logstash. But fluentd is OK to me. On Mon, Nov 28, 2016 at 8:31 AM, Serguei Bezverkhi (sbezverk) < sbezv...@cisco.com> wrote: > I would vote for fluentd because: 1 – it has been around since 2011 so it > is hard to call it green. 2 – There is constant

Re: [openstack-dev] [kolla] the alternative of log processing tool

Logstash-forward/Filebeat just cut logs in preparation for processing elsewhere. It doesn't process logs just forward it to another processor ( Logstash / Heka / Fluentd ). It do not have any processing filter like Logstash. At least, we need some thing tool like grok, syslog intput etc. what we

[openstack-dev] [kolla][release][requirements] providing constraints for transitive dependencies

Hey folks, I get a lot of requests for variance reduction of transitive dependencies in Kolla’s containers. As an example, we build from source nova. Nova itself we can specify a version to install in the containers during build time. Nova’s python dependencies, not so much. Is there a

Re: [openstack-dev] [kolla] the alternative of log processing tool

I would vote for fluentd because: 1 – it has been around since 2011 so it is hard to call it green. 2 – There is constant development of new features/filters, 3 – As it was mentioned at Kubecon by fluentd people, they are deeply committed to Open Source community so rumors that they would go

Re: [openstack-dev] [new][nimble] New project: Nimble

On 11/25/2016 04:41 AM, Zhenguo Niu wrote: hi all, We are pleased to introduce Nimble, a new OpenStack project which aims to provide bare metal computing management. Compared with Nova, it's more bare metal specific and with more advanced features that VM users don't need, it's not bounded by

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 10/12/2016 02:50 PM, Flavio Percoco wrote: > Greetings, > > One of the common complains about the existing project organization in > the big > tent is that it's difficult to wrap our heads around the many projects > there > are, their current state (in/out the big tent), their tags, etc. > >

Re: [openstack-dev] [kolla] the alternative of log processing tool

Jeffrey, Logstash-forwarder is deprecated upstream, so we can’t rely on that. Elastic's replacement is filebeat. I’m not sure which one meets the requirements – filebeat or fluentd. In kolla-kubernetes fluentd is being used, and is well maintained. Both implementations are pretty green

Re: [openstack-dev] [neutron] NeutronLibImpact: Adoption of db *_FIELD_SIZE constants from neutron-lib

Gary Kotton wrote: > Would it be worth considering have the three patches: > https://review.openstack.org/399891, https://review.openstack.org/398113 > and https://review.openstack.org/398489 based one on top of the other. > Then all sub projects could take the top of the

Re: [openstack-dev] [vitrage] about aodh alarm notification

Hi Dong, I can think of 2 solutions for this problem: 1. We can talk with the AODH developers and check if they can add additional data for the aodh notifications. 2. We can add a cache in the aodh driver, and call the get_all method in the AodhDriver constructor or when the first

Re: [openstack-dev] [kolla] the alternative of log processing tool

After reading the docs in github, i do not think Snap can handle logs very well. Snap introduce itself as "The open telemetry framework". I think it is more like ceilometer/collectd/zabbix. I also can not find how to create a mock syslog socket to collect logs[0], how to use regexp to split the

Re: [openstack-dev] [kolla] the alternative of log processing tool

So filebeat is working with Logstash right? We need split the logs into pieces by using logstash. IMU, Filebeat do not a variety of processing plugins, like Logstash[0]. [0] https://www.elastic.co/guide/en/logstash/current/filter-plugins.html On Sun, Nov 27, 2016 at 11:30 PM, Ian Cordasco

Re: [openstack-dev] [kolla] the alternative of log processing tool

Thanks for quick reply. so I think the snap is not good choice。 For end user, hope the solustion is mature and easy maintain. as discuss before, I'll put on my operator hat and would like to give my +1 to keep ELK instead of Heka.

Re: [openstack-dev] [kolla] the alternative of log processing tool

File beat is maintained be elastic and a part of their product line just like ELK. It's a fantastic tool and quite flexible given its age and size of codebase On Nov 26, 2016 11:59 PM, "Jeffrey Zhang" wrote: > Heka is marked deprecated in Kolla during Newton cycle[0].

Re: [openstack-dev] [kolla] the alternative of log processing tool

It's in development On 27 November 2016 at 08:50, Shake Chen wrote: > Hi Michal > > the snap seem not support log forward now, I can not find any infomation in > google . > > On Sun, Nov 27, 2016 at 9:46 PM, Michał Jastrzębski > wrote: >> >> Hey, >> >> I

Re: [openstack-dev] [kolla] the alternative of log processing tool

Hi Michal the snap seem not support log forward now, I can not find any infomation in google . On Sun, Nov 27, 2016 at 9:46 PM, Michał Jastrzębski wrote: > Hey, > > I am also working with Snap community to enable log forwarding with it [1]. > Snap is super lightweight and

Re: [openstack-dev] [kolla] the alternative of log processing tool

Hey, I am also working with Snap community to enable log forwarding with it [1]. Snap is super lightweight and additional benefit of this solution would be that it can also handle monitoring, which was it's initial role. One service to handle both would be elegant. I'll keep you posted but let's