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

[zhi]

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 maintain Liberty environment. Maybe
neutron-lbaas added some patches about MQ.

But I also want to know what changes about MQ in Newton version. :)


Thanks
Zhi Chang



2016-11-26 10:49 GMT+08:00 zhi :

> Dear all,
>
> Recently, I built up a " all-in-one " environment about LBaaS v2 by using
> " haproxy " driver and the lbaas code are from master branch. And I met a
> strange problem. LBaaS v2 agent can not consume messages when creating
> loadbalancers in neutron server. I can see some queued messages by using
> rabbitmq command, like this:
>
> [root@server-233 ~]# rabbitmqctl list_queues messages name | grep -v ^0
> Listing queues ...
> 25 n-lbaasv2_agent.server-233
> ...
> ...done.
>
> What should I do? I think that LBaaS v2 agent doesn't subscribe topics in
> RabbitMQ normally. In RabbitMQ, the queue " n-lbaasv2_agent.server-233 " is
> created by lbaasv2 agent. And why agent can't consume messages from
> neutron-server?
>
> Could someone give me some advice to analysis this?
>
>
> Many Thanks!
> Zhi Chang
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Weyl, Alexey (Nokia - IL)]

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: dong.wenj...@zte.com.cn
Cc: OpenStack Development Mailing List (not for usage questions); Hefetz, Idan 
(Nokia - IL); zhang.yuj...@zte.com.cn
Subject: [ALU] 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 way.

BR,
dwj


Yujun Zhang >

2016-11-28 11:23

收件人

"OpenStack Development Mailing List (not for usage questions)" 
>, 
"dong.wenj...@zte.com.cn" 
>

抄送

"Hefetz, Idan (Nokia - IL)" 
>, 
"zhang.yuj...@zte.com.cn" 
>

主题

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

I think it might not be easily accepted since sending only the changes on 
update notification looks more reasonable to me.
2.   We can add a cache in the aodh driver, and call the get_all method in 
the AodhDriver constructor or when the first notification happens and fill the 
cache with the data. Then for each notification that arrives you  will update 
that cache in the aodh notification service, and send then event with all the 
data you need.

I doubt this will degrade the performance for the first notification since 
there will be additional conversation to retrieve the full data.

My proposal is to share a cache between snapshot service and listener service 
and I think it is a common requirements for all datasource using PUSH method.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tony Breeds]

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 at stdout rather then stderr ; or
2) update the glance config files to explictly set "use_stderr = true"

I feel like Option 2 is correct as clearly preserves the existing behaviour the
operators/deployers can opt out if they want.

Let me know which option I should write tomorrow.

As Ceilometer (at least) doesn't use constraints they've already found this and
took Option 1 in [3]


Yours Tony.

[1] https://review.openstack.org/#/c/351283/
[2] 
http://logs.openstack.org/65/388365/5/check/gate-cross-glance-python27-db-ubuntu-xenial/53c9918/console.html.gz#_2016-11-23_10_36_11_765111
[3] https://review.openstack.org/#/c/388896/


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] about aodh alarm notification

[Yujun Zhang]

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

BR,
dwj



*Yujun Zhang >*

2016-11-28 11:23
收件人
"OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>, "dong.wenj...@zte.com.cn" <
dong.wenj...@zte.com.cn>

抄送
"Hefetz, Idan (Nokia - IL)" , "
zhang.yuj...@zte.com.cn" 

主题
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 notifications.

I think it might not be easily accepted since sending only the changes on
update notification looks more reasonable to me.
2.   We can add a cache in the aodh driver, and call the get_all method
in the AodhDriver constructor or when the first notification happens and
fill the cache with the data. Then for each notification that arrives you
will update that cache in the aodh notification service, and send then
event with all the data you need.

I doubt this will degrade the performance for the first notification since
there will be additional conversation to retrieve the full data.

My proposal is to share a cache between snapshot service and listener
service and I think it is a common requirements for all datasource using
PUSH method.
__
OpenStack Development Mailing 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] [new][nimble] New project: Nimble

[Michael Still]

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 our current projects
is a better engineering choice.

That said, there seems to be a repeated meme that splitting our efforts and
having more than one implementation of compute will somehow solve all our
problems, and I embrace that experiment. It seems very unlikely to me that
we'll end up in a happy place at the end, but then again, I've been wrong
before.

So I say have at it, so long as the outcome of the experiment is public.

Michael

-- 
Rackspace Australia
__
OpenStack Development Mailing 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] [new][nimble] New project: Nimble

[Jay Pipes]

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 Nova to expose API to
end users.

Nova focuses on VM management and provides virtualization specific
features, although the ironic driver makes it possible to manage
bare metal via Nova's API, it doesn't work well. It's hard to add bare
metal specific features, as Nova API is for all hypervisors,
especially virtualization hypervisors. And in order to work with Nova,
we have to adapt the way to manage VMs, for example, we only
have one compute host for all bare metal nodes, so all capabilities
based on compute hosts can't apply to bare metals like availability
zones, host aggregates, etc.

Like containers and virutalizations, bare metal is also a different
technology, different resource. I think they don't work better
together within a same nova compute and bounded by Nova unified API. So
we decide to create a new project which decouples the two
technologies by separating baremetal management into it's own set of API.

Another reason is we also want to support RSD bared servers. Then
composing resouces work will be done in Nimble, Ironic only need
to add RedFish driver to support this type of servers.


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.


For the RackScale Architecture stuff, the Valence project seems to be 
doing that and I'm not sure what role Nimble would play.


Best,
-jay

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

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

[Takashi Yamamoto]

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.
>
> What does this mean in practice?
>
> From a visibility point of view, release notes and documentation will no
> longer appear on openstack.org as of Ocata going forward.
> No more releases will be published by the neutron release team.
> The neutron team will stop proposing fixes for the upstream CI, if not
> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>
> How does it affect you, the user or the deployer?
>
> You can continue to use vpnaas and its CLI via the python-neutronclient and
> expect it to work with neutron up until the newton
> release/python-neutronclient 6.0.0. After this point, if you want a release
> that works for Ocata or newer, you need to proactively request a release
> [5], and reach out to a member of the neutron release team [3] for approval.
> Assuming that the vpnaas CI is green, you can expect to have a working
> vpnaas system upon release of its package in the foreseeable future.
> Outstanding bugs and new bug reports will be rejected on the basis of lack
> of engineering resources interested in helping out in the typical OpenStack
> review workflow.
> Since we are freezing the development of the neutron CLI in favor of the
> openstack unified client (OSC), the lack of a plan to make the VPN commands
> available in the OSC CLI means that at some point in the future the neutron
> client CLI support for vpnaas may be dropped (though I don't expect this to
> happen any time soon).
>
> Can this be reversed?
>
> If you are interested in reversing this decision, now it is time to step up.
> That said, we won't be reversing the decision for Ocata. There is quite a
> curve to ramp up to make neutron-vpnaas worthy of being classified as a
> neutron stadium project, and that means addressing all the gaps identified
> in [6]. If you are interested, please reach out, and I will work with you to
> add your account to [4], so that you can drive the neutron-vpnaas agenda
> going forward.
>
> Please do not hesitate to reach out to ask questions and/or clarifications.

hi,

i'm interested in working on the project.
well, at least on the parts which is used by networking-midonet.

>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/392010/
> [2] https://review.openstack.org/#/c/397924/
> [3] https://review.openstack.org/#/admin/groups/150,members
> [4] https://review.openstack.org/#/admin/groups/502,members
> [5] https://github.com/openstack/releases
> [6]
> http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

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

[Tony Breeds]

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 during build time.
> Nova’s python dependencies, not so much.

I'm not certain I follow.  You're using upper-constraints for install time
consistent version selection, and that applies to *all* dependencies no matter
how many levels down they are.  You *could* extract and manipulate the 
upper-constraints
file for each container, and assuming 1 container 1 service that will probably
give you want you want.  The only trick is for data that is passed over the RPC
between services.  For example having different versions of oslo.context in the
nova conductor and nova-compute containers would be a bad thing.

Is that kinda what you're asking?

If not a more concrete example would be very helpful.

> Is there a best practice for doing such in the python ecosystem?

Nope.  in the python eco-system you more or less get what you ask for and it;s
up to you to find a spot on the prescriptive <-> flexible line.

Yours Tony.


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

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

[dong . wenjuan]

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)" 
, "dong.wenj...@zte.com.cn" 

抄送
"Hefetz, Idan (Nokia - IL)" , 
"zhang.yuj...@zte.com.cn" 
主题
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 notifications.
I think it might not be easily accepted since sending only the changes on 
update notification looks more reasonable to me. 
2.   We can add a cache in the aodh driver, and call the get_all 
method in the AodhDriver constructor or when the first notification 
happens and fill the cache with the data. Then for each notification that 
arrives you  will update that cache in the aodh notification service, and 
send then event with all the data you need.
I doubt this will degrade the performance for the first notification since 
there will be additional conversation to retrieve the full data. 

My proposal is to share a cache between snapshot service and listener 
service and I think it is a common requirements for all datasource using 
PUSH method.

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

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

[Jeffrey Zhang]

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

/var/lib/kolla/venv/bin/pip --no-cache-dir install --upgrade -c
requirements/upper-constraints.txt /keystone

[0]
https://github.com/openstack/kolla/blob/master/docker/keystone/keystone-base/Dockerfile.j2#L65



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

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

[joehuang]

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 November 2016 20:26
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata in  
README files

On 25/11/16 13:16 +0100, Flavio Percoco wrote:
>On 25/11/16 12:38 +0100, Flavio Percoco wrote:
>>Greetings,
>>
>>Just a heads up for everyone. The work on this front has moved forward and the
>>badges are now being generated as part of the governance CI[0].
>>
>>You can find the list of badges here[1] and the pattern is quite obvious, the
>>name of the image is based on the project repo name.
>>
>>I've edited the README files for all repositories listed in the projects.yaml
>>file and I've started to submit these patches[2]. I'm not a fan of "viral
>>changes" but I've done my best to explain what's changing, provide references
>>and examples on the commit message. These changes are being submitted using 
>>the
>>tag 'project-badges'[2].
>
>I also wanted to add that these patches are just for projects that are using 
>rst
>for their README files (sorry markdown) and that each commit has a preview link
>that you can go and look at.
>
>If the layout doesn't look perfect and the whitespace under the svg image
>annoyes you, let me tell you that it was improved in the new layout, which is
>under review. Also, Github does some funky things to the svg when it renders 
>the
>README file, hence the whitespace that was added for the first layout.

One last thing. You may/may not like the placement of these badges in the README
file. It's fine if you don't. The reason they are at the top is because they
normally are at the top :) Putting them at the top also made it simple to
automate the process accross all the *very* (trust me VERY) different README
files across the community.

If you don't like the placement of these badges, you're free to move them around
as prefer. I've done the job to help pushing the first patch, you're all free to
take it over, modify it, reject it or just merge it as is.

Hope this helps,
Flavio

>Flavio
>
>>Note that these badges are *JUST* a graphical representation of what's in the
>>governance repo. If you don't want to have them in the README file, I guess 
>>it's
>>fine. I'd, however, encourage everyone to add them to provide consistency and 
>>a
>>more immediate information of what the project is about, what some of the
>>project capabilities are and what its status is.
>>
>>Ideally this should also be added in projects documentation as well but I'll
>>leave that to every team to do.
>>
>>Happy to answer questions,
>>Flavio
>>
>>P.S: The current layout is being improved[3], if you have better ideas please
>>help out.
>>
>>[0] https://review.openstack.org/#/c/391588/
>>[1] http://governance.openstack.org/badges/
>>[2] https://review.openstack.org/#/q/topic:project-badges
>>[3] https://review.openstack.org/#/c/399278/
>>
>>On 12/10/16 14:50 +0200, 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.
>>>
>>>This information is available on the governance website[0]. Each official
>>>project team has a page there containing the information related to the
>>>deliverables managed by that team. Unfortunately, I don't think this page is
>>>checked often enough and I believe it's not known by everyone.
>>>
>>>In the hope that we can make this information clearer to people browsing the
>>>many repos (most likely on github), I'd like to propose that we include the
>>>information of each deliverable in the readme file. This information would be
>>>rendered along with the rest of the readme (at least on Github, which might 
>>>not
>>>be our main repo but it's the place most humans go to to check our projects).
>>>
>>>Rather than duplicating this information, I'd like to find a way to just
>>>"include it" in the Readme file. As far as showing the "official" badge 
>>>goes, I
>>>believe it'd be quite simple. We can do it the same way CI tags are exposed 
>>>when
>>>using travis (just include an image). As for the rest of the tags, it might
>>>require some extra hacking.
>>>
>>>So, before I start digging more into this, I wanted to get other 
>>>opinions/ideas
>>>on this topic and how we can make this information more evident to the rest 
>>>of
>>>the community (and people not as familiar with our processes as some of us 
>>>are).
>>>
>>>Thanks in advance,
>>>Flavio
>>>
>>>[0] http://governance.openstack.org/reference/projects/index.html
>>>
>>>--
>>>@flaper87
>>>Flavio Percoco
>>
>>
>>
>>--
>>@flaper87
>>Flavio Percoco
>
>
>
>--
>@flaper87

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

[Zhenguo Niu]

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 metal computing management.
>
> Has this name been cleared for use? Nimble is the name of a company, so
> like Quantum, this seems to me to be a short lived name.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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] [new][nimble] New project: Nimble

[Zhenguo Niu]

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 focuses on VM management and provides virtualization specific
features, although the ironic driver makes it possible to manage
bare metal via Nova's API, it doesn't work well. It's hard to add bare
metal specific features, as Nova API is for all hypervisors,
especially virtualization hypervisors. And in order to work with Nova, we
have to adapt the way to manage VMs, for example, we only
have one compute host for all bare metal nodes, so all capabilities based
on compute hosts can't apply to bare metals like availability
zones, host aggregates, etc.

Like containers and virutalizations, bare metal is also a different
technology, different resource. I think they don't work better
together within a same nova compute and bounded by Nova unified API. So we
decide to create a new project which decouples the two
technologies by separating baremetal management into it's own set of API.

Another reason is we also want to support RSD bared servers. Then composing
resouces work will be done in Nimble, Ironic only need
to add RedFish driver to support this type of servers.

Thanks,


On Mon, Nov 28, 2016 at 8:16 AM, Jay Pipes  wrote:

> 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 Nova's API.
>>
>> As we know, Ironic API should never be exposed to end users, users have
>> to talk to Nova to request a bare metal compute
>> instance even if you're only providing bare metal, even if it's only
>> internally, you still have to talk to nova, Ironic doesn't have
>> a concept of users, tenants, and quotas. Nimble wants to decouple
>> virtualization and baremetal technologies by breaking
>> baremetal computing management into its own set of application program
>> interfaces.
>>
>> Not only does Nimble provide pre-set configuration servers, but it also
>> wants to support RSD(Rack Scale Design) which makes
>> it possible to dynamically compose physical resouces.
>>
>> For more information, including architecture, use cases, etc., are
>> described on the project wiki [0].
>> And please feel free to browse our source code [1][2].
>>
>
> I'm a little confused why you are choosing to create a new RESTful API
> service instead of working to adapt Ironic's existing API, or alternately,
> working with the Nova team to add features that you feel were/are necessary
> for baremetal management.
>
> What were the primary reasons you decided not to work with either (or
> both) of the Ironic or Nova communities?
>
> -jay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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] about aodh alarm notification

[Yujun Zhang]

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 notifications.
>
I think it might not be easily accepted since sending only the changes on
update notification looks more reasonable to me.

> 2.   We can add a cache in the aodh driver, and call the get_all
> method in the AodhDriver constructor or when the first notification happens
> and fill the cache with the data. Then for each notification that arrives
> you  will update that cache in the aodh notification service, and send then
> event with all the data you need.
>
I doubt this will degrade the performance for the first notification since
there will be additional conversation to retrieve the full data.

My proposal is to share a cache between snapshot service and listener
service and I think it is a common requirements for all datasource using
PUSH method.

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

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

[Clark Boylan]

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

> 
> then all python dependencies installed will use a fixed version from
> upper-constrains.txt.

Yup, constraints apply to transitive deps as well. Keep in mind you
don't have to use the published upper-constraints either, but they are
an easy way to use a known tested set that works with upstream gating.

> 
> [0]
> https://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html
> [1]
> https://github.com/openstack/requirements/blob/master/upper-constraints.txt
> 
> On Mon, Nov 28, 2016 at 10:41 AM, 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 during build
> > time.  Nova’s python dependencies, not so much.  Is there a best practice
> > for doing such in the python ecosystem?
> >
> >
> >
> > Binary distributions don’t typically suffer from this problem.  They
> > deliver one version of dependencies, and that is what you get.  That is
> > what a slew of folks are after with from source container builds.  Any
> > advice from the requirements team or release team welcome as the folks on
> > those teams have the most experience with this sort of thing.
> >
> >
> >
> > If this has been asked by someone else in a different context and
> > answered, a pointer to that discussion would work too J

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

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

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

[Jeffrey Zhang]

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]
https://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html
[1]
https://github.com/openstack/requirements/blob/master/upper-constraints.txt

On Mon, Nov 28, 2016 at 10:41 AM, 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 during build
> time.  Nova’s python dependencies, not so much.  Is there a best practice
> for doing such in the python ecosystem?
>
>
>
> Binary distributions don’t typically suffer from this problem.  They
> deliver one version of dependencies, and that is what you get.  That is
> what a slew of folks are after with from source container builds.  Any
> advice from the requirements team or release team welcome as the folks on
> those teams have the most experience with this sort of thing.
>
>
>
> If this has been asked by someone else in a different context and
> answered, a pointer to that discussion would work too J
>
>
>
> Thanks!
>
> -steve
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

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

[Jeffrey Zhang]

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 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 private does not sound reliable. We use it in kolla kubernetes and
> so far we could share only positive feedback.
>
>
>
> Serguei
>
>
>
> *From:* Steven Dake (stdake)
> *Sent:* Sunday, November 27, 2016 3:46 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* 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 IMO.  Not sure if fluentd also does log
> processing.  I think its crucial to pick a component that just does log
> forwarding since that is the part that was deprecated.
>
>
>
> Our system has no log stash at all in it, and I’d like to keep it that
> way.  Logstash is unnecessary for our use case.  What we want is
> forwarder->es->cabana.  Whatever forwarder is chosen, recommend picking the
> best of the two choices.  I’d start with defining best as “does it solve
> the same problem as Heka does in our current implementation” then sprinkle
> throughput and minimal cpu and network utilization on top.  If we can’t
> make a decision from there, not sure I have any further suggestions as I am
> not writing the code.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> *From: *Jeffrey Zhang 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Sunday, November 27, 2016 at 9:40 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *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 
> wrote:
>
> 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]. And Now we have
> a
>
> blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.
>
>
>
> For Filebeat, it is just a replacement of logstash-forward[2]. It is not
> intent
>
> to replace the Logstash at all.
>
>
>
> > Filebeat is based on the Logstash Forwarder source code and replaces
> Logstash
>
> > Forwarder as the method to use for tailing log files and forwarding them
> to
>
> > Logstash.
>
>
>
> Fillebeat is a log transport tool rather than log processing too. I do not
>
> treat it as an alternative at all.
>
>
>
> To be honest, I'd like back to Logstash, and Logstash 5.x is released with
> high
>
> performance improvement[4].
>
>
>
> >  In our performance testing, we've seen consistent throughput increases
>
> >  across multiple configurations. In some cases, we observed up to 75%
>
> >  increase in events processed through Logstash.
>
>
>
> another benefit to using Logstash is the whole ELK stack is maintained by
> one
>
> community/company. It is well tested and easy to upgrade the whole stack
> at the
>
> same time. Using other tools may force us on certain elasticsearch release.
>
>
>
> So, I think we have to alternative tools.
>
>
>
> * Fluentd
>
> * Logstash
>
>
>
> IMO, we need to make the decision and at least prepare the migration
> solution now.
>
>
>
> [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
>
> [2] https://www.elastic.co/guide/en/beats/filebeat/current/
> migrating-from-logstash-forwarder.html
>
> [3] http://www.fluentd.org/
>
> [4] https://www.elastic.co/blog/logstash-5-0-0-released
>
>
>
> --
>
> Regards,
>
> Jeffrey Zhang
>
> Blog: http://xcodest.me
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> 

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

[Jeffrey Zhang]

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 need is:

* listen on syslog like socket to collect logs
* processing plugin, like logstash grok does.

I do not think fielbeat meet this requirement. So finally, we need

 -> filebeat ( maybe, log forward ) -> Logstash/heka/Fluentd ( log
processing ) -> ES ( log storage ) -> grafana ( log ui )



On Mon, Nov 28, 2016 at 4:45 AM, Steven Dake (stdake) 
wrote:

> 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 IMO.  Not sure if fluentd also does log
> processing.  I think its crucial to pick a component that just does log
> forwarding since that is the part that was deprecated.
>
> Our system has no log stash at all in it, and I’d like to keep it that
> way.  Logstash is unnecessary for our use case.  What we want is
> forwarder->es->cabana.  Whatever forwarder is chosen, recommend picking the
> best of the two choices.  I’d start with defining best as “does it solve
> the same problem as Heka does in our current implementation” then sprinkle
> throughput and minimal cpu and network utilization on top.  If we can’t
> make a decision from there, not sure I have any further suggestions as I am
> not writing the code.
>
> Regards
> -steve
>
>
> From: Jeffrey Zhang 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Sunday, November 27, 2016 at 9:40 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: 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 
> wrote:
>
>> 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]. And Now we
>>> have a
>>> blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.
>>>
>>> For Filebeat, it is just a replacement of logstash-forward[2]. It is not
>>> intent
>>> to replace the Logstash at all.
>>>
>>> > Filebeat is based on the Logstash Forwarder source code and replaces
>>> Logstash
>>> > Forwarder as the method to use for tailing log files and forwarding
>>> them to
>>> > Logstash.
>>>
>>> Fillebeat is a log transport tool rather than log processing too. I do
>>> not
>>> treat it as an alternative at all.
>>>
>>> To be honest, I'd like back to Logstash, and Logstash 5.x is released
>>> with high
>>> performance improvement[4].
>>>
>>> >  In our performance testing, we've seen consistent throughput increases
>>> >  across multiple configurations. In some cases, we observed up to 75%
>>> >  increase in events processed through Logstash.
>>>
>>> another benefit to using Logstash is the whole ELK stack is maintained
>>> by one
>>> community/company. It is well tested and easy to upgrade the whole stack
>>> at the
>>> same time. Using other tools may force us on certain elasticsearch
>>> release.
>>>
>>> So, I think we have to alternative tools.
>>>
>>> * Fluentd
>>> * Logstash
>>>
>>> IMO, we need to make the decision and at least prepare the migration
>>> solution now.
>>>
>>> [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
>>> [2] https://www.elastic.co/guide/en/beats/filebeat/current/migra
>>> ting-from-logstash-forwarder.html
>>> [3] http://www.fluentd.org/
>>> [4] https://www.elastic.co/blog/logstash-5-0-0-released
>>>
>>> --
>>> Regards,
>>> Jeffrey Zhang
>>> Blog: http://xcodest.me
>>>
>>> 
>>> __
>>> 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
>> 

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

[Steven Dake (stdake)]

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 best practice for doing such in 
the python ecosystem?

Binary distributions don’t typically suffer from this problem.  They deliver 
one version of dependencies, and that is what you get.  That is what a slew of 
folks are after with from source container builds.  Any advice from the 
requirements team or release team welcome as the folks on those teams have the 
most experience with this sort of thing.

If this has been asked by someone else in a different context and answered, a 
pointer to that discussion would work too ☺

Thanks!
-steve

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

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

[Serguei Bezverkhi (sbezverk)]

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 
private does not sound reliable. We use it in kolla kubernetes and so far we 
could share only positive feedback.

Serguei

From: Steven Dake (stdake)
Sent: Sunday, November 27, 2016 3:46 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: 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 IMO.  Not sure if fluentd also does log 
processing.  I think its crucial to pick a component that just does log 
forwarding since that is the part that was deprecated.

Our system has no log stash at all in it, and I’d like to keep it that way.  
Logstash is unnecessary for our use case.  What we want is 
forwarder->es->cabana.  Whatever forwarder is chosen, recommend picking the 
best of the two choices.  I’d start with defining best as “does it solve the 
same problem as Heka does in our current implementation” then sprinkle 
throughput and minimal cpu and network utilization on top.  If we can’t make a 
decision from there, not sure I have any further suggestions as I am not 
writing the code.

Regards
-steve


From: Jeffrey Zhang >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Sunday, November 27, 2016 at 9:40 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: 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 
> wrote:

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]. And Now we have a
blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.

For Filebeat, it is just a replacement of logstash-forward[2]. It is not intent
to replace the Logstash at all.

> Filebeat is based on the Logstash Forwarder source code and replaces Logstash
> Forwarder as the method to use for tailing log files and forwarding them to
> Logstash.

Fillebeat is a log transport tool rather than log processing too. I do not
treat it as an alternative at all.

To be honest, I'd like back to Logstash, and Logstash 5.x is released with high
performance improvement[4].

>  In our performance testing, we've seen consistent throughput increases
>  across multiple configurations. In some cases, we observed up to 75%
>  increase in events processed through Logstash.

another benefit to using Logstash is the whole ELK stack is maintained by one
community/company. It is well tested and easy to upgrade the whole stack at the
same time. Using other tools may force us on certain elasticsearch release.

So, I think we have to alternative tools.

* Fluentd
* Logstash

IMO, we need to make the decision and at least prepare the migration solution 
now.

[1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
[2] 
https://www.elastic.co/guide/en/beats/filebeat/current/migrating-from-logstash-forwarder.html
[3] http://www.fluentd.org/
[4] https://www.elastic.co/blog/logstash-5-0-0-released

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

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

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

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

[Jay Pipes]

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 Nova's API.

As we know, Ironic API should never be exposed to end users, users have
to talk to Nova to request a bare metal compute
instance even if you're only providing bare metal, even if it's only
internally, you still have to talk to nova, Ironic doesn't have
a concept of users, tenants, and quotas. Nimble wants to decouple
virtualization and baremetal technologies by breaking
baremetal computing management into its own set of application program
interfaces.

Not only does Nimble provide pre-set configuration servers, but it also
wants to support RSD(Rack Scale Design) which makes
it possible to dynamically compose physical resouces.

For more information, including architecture, use cases, etc., are
described on the project wiki [0].
And please feel free to browse our source code [1][2].


I'm a little confused why you are choosing to create a new RESTful API 
service instead of working to adapt Ironic's existing API, or 
alternately, working with the Nova team to add features that you feel 
were/are necessary for baremetal management.


What were the primary reasons you decided not to work with either (or 
both) of the Ironic or Nova communities?


-jay

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

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

[Thomas Goirand]

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.
> 
> This information is available on the governance website[0]. Each official
> project team has a page there containing the information related to the
> deliverables managed by that team. Unfortunately, I don't think this
> page is
> checked often enough and I believe it's not known by everyone.
> 
> In the hope that we can make this information clearer to people browsing
> the
> many repos (most likely on github), I'd like to propose that we include the
> information of each deliverable in the readme file. This information
> would be
> rendered along with the rest of the readme (at least on Github, which
> might not
> be our main repo but it's the place most humans go to to check our
> projects).
> 
> Rather than duplicating this information, I'd like to find a way to just
> "include it" in the Readme file. As far as showing the "official" badge
> goes, I
> believe it'd be quite simple. We can do it the same way CI tags are
> exposed when
> using travis (just include an image). As for the rest of the tags, it might
> require some extra hacking.
> 
> So, before I start digging more into this, I wanted to get other
> opinions/ideas
> on this topic and how we can make this information more evident to the
> rest of
> the community (and people not as familiar with our processes as some of
> us are).
> 
> Thanks in advance,
> Flavio

Flavio,

While your work seem a good idea to me, you may have been a bit too
quick editing the deb-* repos. Let me explain.

You've opened hundreds of change requests on the openstack/deb-* Gerrit
repository. They are all failing the gate, which is expected.

1/ These changes have nothing to do there, they are to be done on
upstream code.

2/ Never one should touch the master branch of these repositories (only
debian/* are to be edited).

Please abandon all of your changes for the deb-* Gerrit repos.

Thanks for that work anyway,
Cheers,

Thomas Goirand (zigo)


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

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

[Steven Dake (stdake)]

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 IMO.  Not sure if fluentd also does log 
processing.  I think its crucial to pick a component that just does log 
forwarding since that is the part that was deprecated.

Our system has no log stash at all in it, and I’d like to keep it that way.  
Logstash is unnecessary for our use case.  What we want is 
forwarder->es->cabana.  Whatever forwarder is chosen, recommend picking the 
best of the two choices.  I’d start with defining best as “does it solve the 
same problem as Heka does in our current implementation” then sprinkle 
throughput and minimal cpu and network utilization on top.  If we can’t make a 
decision from there, not sure I have any further suggestions as I am not 
writing the code.

Regards
-steve


From: Jeffrey Zhang >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Sunday, November 27, 2016 at 9:40 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: 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 
> wrote:

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]. And Now we have a
blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.

For Filebeat, it is just a replacement of logstash-forward[2]. It is not intent
to replace the Logstash at all.

> Filebeat is based on the Logstash Forwarder source code and replaces Logstash
> Forwarder as the method to use for tailing log files and forwarding them to
> Logstash.

Fillebeat is a log transport tool rather than log processing too. I do not
treat it as an alternative at all.

To be honest, I'd like back to Logstash, and Logstash 5.x is released with high
performance improvement[4].

>  In our performance testing, we've seen consistent throughput increases
>  across multiple configurations. In some cases, we observed up to 75%
>  increase in events processed through Logstash.

another benefit to using Logstash is the whole ELK stack is maintained by one
community/company. It is well tested and easy to upgrade the whole stack at the
same time. Using other tools may force us on certain elasticsearch release.

So, I think we have to alternative tools.

* Fluentd
* Logstash

IMO, we need to make the decision and at least prepare the migration solution 
now.

[1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
[2] 
https://www.elastic.co/guide/en/beats/filebeat/current/migrating-from-logstash-forwarder.html
[3] http://www.fluentd.org/
[4] https://www.elastic.co/blog/logstash-5-0-0-released

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

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


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




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

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

[Henry Gessau]

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 commit and base on top of
> that. That may make the process a little more efficient.

The problem is that the ExtensionDescriptor change has its own specific order
in which the patches must be done, as explained in
http://lists.openstack.org/pipermail/openstack-dev/2016-November/108005.html

My recommendation is that ExtensionDescriptor be done first. Then we could
stage the PLURALS and _FIELD_SIZES as you suggest, but the PLURALS change is
quite independent, so it could be done in parallel with ExtensionDescriptor.

Once ExtensionDescriptor, PLURALS and _FIELD_SIZES are done, then we will be
in a position to remove attributes.py from core neutron. That is the aim of
this little dance.

> Thanks
> Gary
>  
>
> 
> 
> On 11/26/16, 9:03 AM, "Henry Gessau"  wrote:
> 
> The following _MAX_LEN constants are being removed from
> neutron/api/v2/attributes.py in [1]. The corresponding DB field size
> constants from neutron_lib.db.constants should be used instead.
> 
> All subproject maintainers should update their code to use the
> the db *_FIELD_SIZE constants from neutron-lib.
> 
> I have submitted patches [2] for most subprojects.
> 
>  NAME_MAX_LEN  -->  NAME_FIELD_SIZE
>  TENANT_ID_MAX_LEN -->  PROJECT_ID_FIELD_SIZE
>  DESCRIPTION_MAX_LEN   -->  DESCRIPTION_FIELD_SIZE
>  LONG_DESCRIPTION_MAX_LEN  -->  LONG_DESCRIPTION_FIELD_SIZE
>  DEVICE_ID_MAX_LEN -->  DEVICE_ID_FIELD_SIZE
>  DEVICE_OWNER_MAX_LEN  -->  DEVICE_NAME_FIELD_SIZE
> 
> In alembic migration scripts, the raw numerical value shall be used.
> 
> For more information, see [3].
> 
> [1] https://review.openstack.org/399891
> [2] https://review.openstack.org/#/q/status:open+topic:use-db-field-sizes
> [3] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105789.html
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing 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] about aodh alarm notification

[Weyl, Alexey (Nokia - IL)]

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 notification happens and fill the 
cache with the data. Then for each notification that arrives you  will update 
that cache in the aodh notification service, and send then event with all the 
data you need.

BR,
Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
Sent: Friday, November 25, 2016 2:28 AM
To: Weyl, Alexey (Nokia - IL)
Cc: Hefetz, Idan (Nokia - IL); Afek, Ifat (Nokia - IL); 
openstack-dev@lists.openstack.org; zhang.yuj...@zte.com.cn
Subject: 答复: RE: RE: [openstack-dev] [vitrage] about aodh alarm notification


EmThe solution goes back to my first question.
Snapshot service calls get_all, and caches all the alarms.
But listener service can't get the cache because there are two services and 
can't share the cache.


BR,
dwj





"Weyl, Alexey (Nokia - IL)" 
>

2016-11-24 23:50

收件人

"dong.wenj...@zte.com.cn" 
>

抄送

"Hefetz, Idan (Nokia - IL)" 
>, "Afek, Ifat (Nokia - 
IL)" >, 
"openstack-dev@lists.openstack.org" 
>, 
"zhang.yuj...@zte.com.cn" 
>

主题

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







It seems that you will need to have a cache for that issue.
Due to the fact that AODH alarms aren’t deleted, and stay alive (in AODH) when 
their state is changed to ok (but in this case aren’t supposed to appear in 
Vitrage), and then when the state is changed back to error (‘alarm’) they are 
supposed to appear in Vitrage with all the data, the most simple way to do that 
(without touching the core processor and architecture) is by saving those 
alarms of AODH in cache in the AODH driver, update its data every change that 
arrive to the driver, and then when a notification arrives and if the state 
that arrived is different than OK and the state that was in the cache is OK 
then send an event with all the data updated in the cache to the queue, 
otherwise send only the data received from the oslo bus to the queue (don’t 
forget of course to update the cache each time an event received, and each time 
we call the get_all of aodh (every snapshot_interval time) we can update the 
data in the cache as well.

Alexey

From: dong.wenj...@zte.com.cn 
[mailto:dong.wenj...@zte.com.cn]
Sent: Thursday, November 24, 2016 11:24 AM
To: Weyl, Alexey (Nokia - IL)
Cc: Hefetz, Idan (Nokia - IL); Afek, Ifat (Nokia - IL); 
openstack-dev@lists.openstack.org; 
zhang.yuj...@zte.com.cn
Subject: 答复: RE: [openstack-dev] [vitrage] about aodh alarm notification


Hi Weyl Alexey,

Another question:
If we received the alarm.creation notification with the 'ok' state, we filter 
it and don't create vertex in the Graph.
The next received the alarm state_change notification, all the other alarm 
details are missing in the vertex.
How can I handle this? Thanks~


BR,
dwj



"Weyl, Alexey (Nokia - IL)" 
>

2016-11-24 16:25


收件人

"dong.wenj...@zte.com.cn" 
>, "Afek, Ifat (Nokia - 
IL)" >, "Hefetz, Idan (Nokia - 
IL)" >, 
"zhang.yuj...@zte.com.cn" 
>

抄送

"openstack-dev@lists.openstack.org" 
>

主题

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











Hi Dong,

Good question, I will explain how you can handle this problem in Vitrage.

You don't need the cache mechanism here, it is much more simplier.

When you get a new alarm with get_all or by notification of 'alarm.creation' 
you will create the alarm with its correct data \ properties.
Then when you receive a notification of 'alarm.rule_change', 
'alarm.state_transition', 'alarm.deletion' all you need to do is only to update 
the correct property that has changed in the aodh vertex.
Thus, When you create the Vertex in the transformer, you know the aodh uuid so 
you know the vitrage_id, and you can pass only the properties that you have 
received 

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

[Jeffrey Zhang]

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 logs?.
I do
not think we have enough time and energy to waiting until Snap fix it.



It may be a cool tool. But it is not mature, imo. Why not use a well used
and
mature software, even though it may be slower than others? But it works very
well and lots of guys are familiar with it.
​​



[0] https://github.com/intelsdi-x/snap/issues/1117

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 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 not throw away this idea just yet.
>
> Cheers,
> Michal
>
> [1] https://github.com/intelsdi-x/snap
>
> On 26 November 2016 at 23:55, Jeffrey Zhang 
> wrote:
> > Heka is marked deprecated in Kolla during Newton cycle[0]. And Now we
> have a
> > blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.
> >
> > For Filebeat, it is just a replacement of logstash-forward[2]. It is not
> > intent
> > to replace the Logstash at all.
> >
> >> Filebeat is based on the Logstash Forwarder source code and replaces
> >> Logstash
> >> Forwarder as the method to use for tailing log files and forwarding them
> >> to
> >> Logstash.
> >
> > Fillebeat is a log transport tool rather than log processing too. I do
> not
> > treat it as an alternative at all.
> >
> > To be honest, I'd like back to Logstash, and Logstash 5.x is released
> with
> > high
> > performance improvement[4].
> >
> >>  In our performance testing, we've seen consistent throughput increases
> >>  across multiple configurations. In some cases, we observed up to 75%
> >>  increase in events processed through Logstash.
> >
> > another benefit to using Logstash is the whole ELK stack is maintained by
> > one
> > community/company. It is well tested and easy to upgrade the whole stack
> at
> > the
> > same time. Using other tools may force us on certain elasticsearch
> release.
> >
> > So, I think we have to alternative tools.
> >
> > * Fluentd
> > * Logstash
> >
> > IMO, we need to make the decision and at least prepare the migration
> > solution now.
> >
> > [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
> > [2]
> > https://www.elastic.co/guide/en/beats/filebeat/current/
> migrating-from-logstash-forwarder.html
> > [3] http://www.fluentd.org/
> > [4] https://www.elastic.co/blog/logstash-5-0-0-released
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

[Jeffrey Zhang]

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

> 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]. And Now we
>> have a
>> blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.
>>
>> For Filebeat, it is just a replacement of logstash-forward[2]. It is not
>> intent
>> to replace the Logstash at all.
>>
>> > Filebeat is based on the Logstash Forwarder source code and replaces
>> Logstash
>> > Forwarder as the method to use for tailing log files and forwarding
>> them to
>> > Logstash.
>>
>> Fillebeat is a log transport tool rather than log processing too. I do not
>> treat it as an alternative at all.
>>
>> To be honest, I'd like back to Logstash, and Logstash 5.x is released
>> with high
>> performance improvement[4].
>>
>> >  In our performance testing, we've seen consistent throughput increases
>> >  across multiple configurations. In some cases, we observed up to 75%
>> >  increase in events processed through Logstash.
>>
>> another benefit to using Logstash is the whole ELK stack is maintained by
>> one
>> community/company. It is well tested and easy to upgrade the whole stack
>> at the
>> same time. Using other tools may force us on certain elasticsearch
>> release.
>>
>> So, I think we have to alternative tools.
>>
>> * Fluentd
>> * Logstash
>>
>> IMO, we need to make the decision and at least prepare the migration
>> solution now.
>>
>> [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
>> [2] https://www.elastic.co/guide/en/beats/filebeat/current/migra
>> ting-from-logstash-forwarder.html
>> [3] http://www.fluentd.org/
>> [4] https://www.elastic.co/blog/logstash-5-0-0-released
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> 
>> __
>> 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
>
>


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

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

[Shake Chen]

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.


http://lists.openstack.org/pipermail/openstack-dev/2016-January/083974.html






On Sun, Nov 27, 2016 at 11:09 PM, Michał Jastrzębski 
wrote:

> 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 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 not throw away this idea just yet.
> >>
> >> Cheers,
> >> Michal
> >>
> >> [1] https://github.com/intelsdi-x/snap
> >>
> >> On 26 November 2016 at 23:55, Jeffrey Zhang 
> >> wrote:
> >> > Heka is marked deprecated in Kolla during Newton cycle[0]. And Now we
> >> > have a
> >> > blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.
> >> >
> >> > For Filebeat, it is just a replacement of logstash-forward[2]. It is
> not
> >> > intent
> >> > to replace the Logstash at all.
> >> >
> >> >> Filebeat is based on the Logstash Forwarder source code and replaces
> >> >> Logstash
> >> >> Forwarder as the method to use for tailing log files and forwarding
> >> >> them
> >> >> to
> >> >> Logstash.
> >> >
> >> > Fillebeat is a log transport tool rather than log processing too. I do
> >> > not
> >> > treat it as an alternative at all.
> >> >
> >> > To be honest, I'd like back to Logstash, and Logstash 5.x is released
> >> > with
> >> > high
> >> > performance improvement[4].
> >> >
> >> >>  In our performance testing, we've seen consistent throughput
> increases
> >> >>  across multiple configurations. In some cases, we observed up to 75%
> >> >>  increase in events processed through Logstash.
> >> >
> >> > another benefit to using Logstash is the whole ELK stack is maintained
> >> > by
> >> > one
> >> > community/company. It is well tested and easy to upgrade the whole
> stack
> >> > at
> >> > the
> >> > same time. Using other tools may force us on certain elasticsearch
> >> > release.
> >> >
> >> > So, I think we have to alternative tools.
> >> >
> >> > * Fluentd
> >> > * Logstash
> >> >
> >> > IMO, we need to make the decision and at least prepare the migration
> >> > solution now.
> >> >
> >> > [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
> >> > [2]
> >> >
> >> > https://www.elastic.co/guide/en/beats/filebeat/current/
> migrating-from-logstash-forwarder.html
> >> > [3] http://www.fluentd.org/
> >> > [4] https://www.elastic.co/blog/logstash-5-0-0-released
> >> >
> >> > --
> >> > Regards,
> >> > Jeffrey Zhang
> >> > Blog: http://xcodest.me
> >> >
> >> >
> >> > 
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Shake Chen
> >
> >
> > 
> __
> > OpenStack Development Mailing 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
>



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

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

[Ian Cordasco]

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]. And Now we have
> a
> blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.
>
> For Filebeat, it is just a replacement of logstash-forward[2]. It is not
> intent
> to replace the Logstash at all.
>
> > Filebeat is based on the Logstash Forwarder source code and replaces
> Logstash
> > Forwarder as the method to use for tailing log files and forwarding them
> to
> > Logstash.
>
> Fillebeat is a log transport tool rather than log processing too. I do not
> treat it as an alternative at all.
>
> To be honest, I'd like back to Logstash, and Logstash 5.x is released with
> high
> performance improvement[4].
>
> >  In our performance testing, we've seen consistent throughput increases
> >  across multiple configurations. In some cases, we observed up to 75%
> >  increase in events processed through Logstash.
>
> another benefit to using Logstash is the whole ELK stack is maintained by
> one
> community/company. It is well tested and easy to upgrade the whole stack
> at the
> same time. Using other tools may force us on certain elasticsearch release.
>
> So, I think we have to alternative tools.
>
> * Fluentd
> * Logstash
>
> IMO, we need to make the decision and at least prepare the migration
> solution now.
>
> [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
> [2] https://www.elastic.co/guide/en/beats/filebeat/current/
> migrating-from-logstash-forwarder.html
> [3] http://www.fluentd.org/
> [4] https://www.elastic.co/blog/logstash-5-0-0-released
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Michał Jastrzębski]

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 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 not throw away this idea just yet.
>>
>> Cheers,
>> Michal
>>
>> [1] https://github.com/intelsdi-x/snap
>>
>> On 26 November 2016 at 23:55, Jeffrey Zhang 
>> wrote:
>> > Heka is marked deprecated in Kolla during Newton cycle[0]. And Now we
>> > have a
>> > blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.
>> >
>> > For Filebeat, it is just a replacement of logstash-forward[2]. It is not
>> > intent
>> > to replace the Logstash at all.
>> >
>> >> Filebeat is based on the Logstash Forwarder source code and replaces
>> >> Logstash
>> >> Forwarder as the method to use for tailing log files and forwarding
>> >> them
>> >> to
>> >> Logstash.
>> >
>> > Fillebeat is a log transport tool rather than log processing too. I do
>> > not
>> > treat it as an alternative at all.
>> >
>> > To be honest, I'd like back to Logstash, and Logstash 5.x is released
>> > with
>> > high
>> > performance improvement[4].
>> >
>> >>  In our performance testing, we've seen consistent throughput increases
>> >>  across multiple configurations. In some cases, we observed up to 75%
>> >>  increase in events processed through Logstash.
>> >
>> > another benefit to using Logstash is the whole ELK stack is maintained
>> > by
>> > one
>> > community/company. It is well tested and easy to upgrade the whole stack
>> > at
>> > the
>> > same time. Using other tools may force us on certain elasticsearch
>> > release.
>> >
>> > So, I think we have to alternative tools.
>> >
>> > * Fluentd
>> > * Logstash
>> >
>> > IMO, we need to make the decision and at least prepare the migration
>> > solution now.
>> >
>> > [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
>> > [2]
>> >
>> > https://www.elastic.co/guide/en/beats/filebeat/current/migrating-from-logstash-forwarder.html
>> > [3] http://www.fluentd.org/
>> > [4] https://www.elastic.co/blog/logstash-5-0-0-released
>> >
>> > --
>> > Regards,
>> > Jeffrey Zhang
>> > Blog: http://xcodest.me
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Shake Chen
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

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

[Shake Chen]

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 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 not throw away this idea just yet.
>
> Cheers,
> Michal
>
> [1] https://github.com/intelsdi-x/snap
>
> On 26 November 2016 at 23:55, Jeffrey Zhang 
> wrote:
> > Heka is marked deprecated in Kolla during Newton cycle[0]. And Now we
> have a
> > blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.
> >
> > For Filebeat, it is just a replacement of logstash-forward[2]. It is not
> > intent
> > to replace the Logstash at all.
> >
> >> Filebeat is based on the Logstash Forwarder source code and replaces
> >> Logstash
> >> Forwarder as the method to use for tailing log files and forwarding them
> >> to
> >> Logstash.
> >
> > Fillebeat is a log transport tool rather than log processing too. I do
> not
> > treat it as an alternative at all.
> >
> > To be honest, I'd like back to Logstash, and Logstash 5.x is released
> with
> > high
> > performance improvement[4].
> >
> >>  In our performance testing, we've seen consistent throughput increases
> >>  across multiple configurations. In some cases, we observed up to 75%
> >>  increase in events processed through Logstash.
> >
> > another benefit to using Logstash is the whole ELK stack is maintained by
> > one
> > community/company. It is well tested and easy to upgrade the whole stack
> at
> > the
> > same time. Using other tools may force us on certain elasticsearch
> release.
> >
> > So, I think we have to alternative tools.
> >
> > * Fluentd
> > * Logstash
> >
> > IMO, we need to make the decision and at least prepare the migration
> > solution now.
> >
> > [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
> > [2]
> > https://www.elastic.co/guide/en/beats/filebeat/current/
> migrating-from-logstash-forwarder.html
> > [3] http://www.fluentd.org/
> > [4] https://www.elastic.co/blog/logstash-5-0-0-released
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

[Michał Jastrzębski]

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 not throw away this idea just yet.

Cheers,
Michal

[1] https://github.com/intelsdi-x/snap

On 26 November 2016 at 23:55, Jeffrey Zhang  wrote:
> Heka is marked deprecated in Kolla during Newton cycle[0]. And Now we have a
> blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.
>
> For Filebeat, it is just a replacement of logstash-forward[2]. It is not
> intent
> to replace the Logstash at all.
>
>> Filebeat is based on the Logstash Forwarder source code and replaces
>> Logstash
>> Forwarder as the method to use for tailing log files and forwarding them
>> to
>> Logstash.
>
> Fillebeat is a log transport tool rather than log processing too. I do not
> treat it as an alternative at all.
>
> To be honest, I'd like back to Logstash, and Logstash 5.x is released with
> high
> performance improvement[4].
>
>>  In our performance testing, we've seen consistent throughput increases
>>  across multiple configurations. In some cases, we observed up to 75%
>>  increase in events processed through Logstash.
>
> another benefit to using Logstash is the whole ELK stack is maintained by
> one
> community/company. It is well tested and easy to upgrade the whole stack at
> the
> same time. Using other tools may force us on certain elasticsearch release.
>
> So, I think we have to alternative tools.
>
> * Fluentd
> * Logstash
>
> IMO, we need to make the decision and at least prepare the migration
> solution now.
>
> [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
> [2]
> https://www.elastic.co/guide/en/beats/filebeat/current/migrating-from-logstash-forwarder.html
> [3] http://www.fluentd.org/
> [4] https://www.elastic.co/blog/logstash-5-0-0-released
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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