[openstack-dev] [nova]

[Serguei Bezverkhi (sbezverk)]

Hello team,

I came across an issue  in Liberty  where NumaTopology Filter was failing my 
request to launch an instance because I was requesting strict cpu pinning which 
happens to be for socket 1, but at the same time requesting SRIOV ports from 
PCIe device with NUMA affinity to socket 0.  It has been confirmed as behavior 
by design. Now when I tried to figure out which numa socket a specific SRIOV 
port is bound to by using OpenStack commands, I could not. I would like to 
suggest to add Numa affinity field to all physical resources managed by 
OpenStack (at this point I could think of SRIOV PF and VF) and print it when 
show of information for a physical resource is requested..  In this case it 
will be much easier to select right ports or resources based on its numa 
affinity.

Thank you and appreciate your thoughts/comments

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

[openstack-dev] [nova] ram size and huge page number for VM

[Serguei Bezverkhi (sbezverk)]

Hello,

I using the latest Liberty and I am trying to bring up a VM with some numa 
options configured using flavor. Specifically I need to give this VM 16GB of 
RAM and in addition  it will need to use 12x1GB huge pages. What I found out, 
there is no way in a flavor to specify RAM size and separately number of huge 
pages, only size is avaialbe, so to achieve what I needed I had to specify RAM 
size of 30GB. It would not be that bad, but instead of taken 16GB from server's 
RAM and 12 GB from Huge pages it has taken whole 30GB out of the server's total 
huge pages pool. Huge waist!!! 

Anybody hit similar requirement and found a reasonable solution? Greatly 
appreciate any feedback.

Thank you

Serguei

__
OpenStack Development Mailing 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] lvm2 and docker issue

[Serguei Bezverkhi (sbezverk)]

Hi Steven,

As per your suggestion I changed kolla_docker to include -ipc=host and it has 
fixed lvm issue for kola build containers.

Thank you

Serguei

[http://www.cisco.com/c/dam/assets/email-signature-tool/logo_07.png?ct=1423747865775]

Serguei Bezverkhi,
TECHNICAL LEADER.SERVICES
Global SP Services
sbezv...@cisco.com<mailto:sbezv...@cisco.com>
Phone: +1 416 306 7312
Mobile: +1 514 234 7374

CCIE (R&S,SP,Sec) - #9527


Cisco.com<http://www.cisco.com/>



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for 
Company Registration Information.



From: Steven Dake (stdake)
Sent: Wednesday, March 16, 2016 12:35 AM
To: Serguei Bezverkhi (sbezverk) 
Cc: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: lvm2 and docker issue

Ccing mailing list for eveyrone's advantage.

From: "Serguei Bezverkhi (sbezverk)" 
mailto:sbezv...@cisco.com>>
Date: Tuesday, March 15, 2016 at 8:26 PM
To: Steven Dake mailto:std...@cisco.com>>
Subject: lvm2 and docker issue

Hi Steven,

I have run few tests and so far with --ipc=host it looks better, at least I do 
not see that "stuck" issue when lvcreate is executed.

docker inspect 417f53c7ac84 | grep -i IPC
"IpcMode": "host",

Now, how do I specify this option when starting kolla containers?

This one I run manually with this command:

docker run --privileged -t -i --ipc=host --net=host --cap-add=ALL -v /dev:/dev 
-v /run:/run -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v 
/sys/kernel/config:/configfs -v /lib/modules:/lib/modules -v 
/var/lib/cinder:/var/lib/cinder -v /etc/iscsi:/etc/iscsi f4118e59a77a

Thank you

Serguei
You have to extend the kolla_docker module.  An example is here:
https://github.com/openstack/kolla/blob/master/ansible/library/kolla_docker.py#L597

Search the file for the word host - you will probably need stuff wherever that 
is except with pid duplicated with ipc.  I recommend a patch prior to your 
current patch to introduce the feature to kolla_docker.

Regards
-steve


[http://www.cisco.com/c/dam/assets/email-signature-tool/logo_07.png?ct=1423747865775]

Serguei Bezverkhi,
TECHNICAL LEADER.SERVICES
Global SP Services
sbezv...@cisco.com<mailto:sbezv...@cisco.com>
Phone: +1 416 306 7312
Mobile: +1 514 234 7374

CCIE (R&S,SP,Sec) - #9527


Cisco.com<http://www.cisco.com/>



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for 
Company Registration Information.



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

Re: [openstack-dev] [Openstack] Naming polls - and some issues

[Serguei Bezverkhi (sbezverk)]

I had the same problem, could not vote for either of these

Serguei
 

-Original Message-
From: Ian Y. Choi [mailto:ianyrc...@gmail.com] 
Sent: Sunday, July 17, 2016 11:58 PM
To: OpenStack Development Mailing List (not for usage questions) 
; mord...@inaugust.com
Cc: Openstack Users 
Subject: Re: [openstack-dev] [Openstack] Naming polls - and some issues

Hello,

Today I tried to vote the naming polls for P and Q releases, however, 
unfortunately I am experiencing some issues.

I used the link for P release in the e-mail titled "Poll: OpenStack P Release 
Naming" on July 11 22:42 UTC.
When I click my URL, the poll site says:
"Error / Your voter key is invalid. You should have received a correct URL by 
email."
, and the poll is not ended yet. However I have not received any other correct 
URLs by e-mail.

For Q release, I followed the link in the e-mail: "Poll: OpenStack Q Release 
Naming" on July 12 02:15 UTC.
When I go to my vote URL, the site says "Poll already ended".
But strangely, when I see the poll result (
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_06e681ae091ad657 ), all the 
poll candidates are 'tied'.

So my questions are:

1) Does anybody have troubles on voting P and Q release naming like me?

2) Has the Q release naming poll already finished?
I think it can be finished although the original due date is July 20th. 
However It is so strange that the result I am seeing now is "tied".


With many thanks,

/Ian

Monty Taylor wrote on 7/18/2016 10:03 AM:
> Any time is a good time.
>
> On 07/17/2016 04:54 PM, Michael Still wrote:
>> So, is now a good time to mention that "Quamby" is the name of a 
>> local prison?
>>
>> Michael
>>
>>
>>
>> On Fri, Jul 15, 2016 at 7:50 PM, Eoghan Glynn > > wrote:
>>
>>
>>
>>  > (top posting on purpose)
>>  >
>>  > I have re-started the Q poll and am slowly adding all of you fine 
>> folks
>>  > to it. Let's keep our fingers crossed that it works this time.
>>  >
>>  > I also removed Quay. Somehow my brain didn't process the "it would be
>>  > like naming the S release "Street"" when reading the original names.
>>  > Based on the naming critera, "Circular Quay" would be a great option 
>> for
>>  > "Circular" - but sadly we already named the C release Cactus. It's
>>  > possible this choice will make someone unhappy, and if it does, I'm
>>  > certainly sorry. On the other hand, there are _so_ many awesome names
>>  > possible in this list, I don't think we'll miss it.
>>
>>  Excellent, thanks Monty for fixing this ... agreed that the remaining
>>  Q* choices are more than enough.
>>
>>  Cheers,
>>  Eoghan
>>
>>  > I'll fire out new emails for P once Q is up and going.
>>  >
>>  > On 07/15/2016 11:02 AM, Jamie Lennox wrote:
>>  > > Partially because its name is Circular Quay, so it would be like
>>  calling
>>  > > the S release Street for  Street.
>>  > >
>>  > > Having said that there are not that many of them and Sydney
>>  people know
>>  > > what you mean when you are going to the Quay.
>>  > >
>>  > >
>>  > > On 14 July 2016 at 21:35, Neil Jerram >  
>>  > > >> wrote:
>>  > >
>>  > > Not sure what the problem would be with 'Quay' or 'Street' -
>>  they
>>  > > both sound like good options to me.
>>  > >
>>  > >
>>  > > On Thu, Jul 14, 2016 at 11:29 AM Eoghan Glynn
>>  mailto:egl...@redhat.com>
>>  > > >> wrote:
>>  > >
>>  > >
>>  > >
>>  > > > >> Hey all!
>>  > > > >>
>>  > > > >> The poll emails for the P and Q naming have started
>>  to go
>>  > > out - and
>>  > > > >> we're experiencing some difficulties. Not sure at the
>>  > > moment what's
>>  > > > >> going on ... but we'll keep working on the issues
>>  and get
>>  > > ballots to
>>  > > > >> everyone as soon as we can.
>>  > > > >
>>  > > > > You'll need to re-send at least some emails, because the
>>  > > link I received
>>  > > > > is wrong - the site just reports
>>  > > > >
>>  > > > >   "Your voter key is invalid. You should have received a
>>  > > correct URL by
>>  > > > >   email."
>>  > > >
>>  > > > Yup. That would be a key symptom of the problems. One
>>  of the
>>  > > others is
>>  > > > that I just uploaded 3000 of the emails to the Q poll
>>  and it
>>  > > shows 0
>>  > > > active voters.
>>  > > >
>>  > > > I think maybe it needs a nap...
>>  > >
>>  > > Any chance we could remove "Quay" from the Q release
>>  

Re: [openstack-dev] [kolla] our mascot - input needed

[Serguei Bezverkhi (sbezverk)]

Another idea could me Koala  lie down his back and juggling with logo of 
OpenStack, Docker and Kubernetes. 

Serguei
 

-Original Message-
From: Michał Jastrzębski [mailto:inc...@gmail.com] 
Sent: Monday, July 18, 2016 9:12 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla] our mascot - input needed

I refuse to be cut out of this thread. It is my right to freely say what's in 
my mind in this, very important for our glorious project, issue!

So here it is:

Koala that holds openstack square'y logo and makes docker whale jumps through it

See? No glue or any narcotics involved.
Meanwhile I'll keep using my own logo which will be reserved for kolla inner 
circle. Also develop a secret handshake while I'm at it.

On 17 July 2016 at 21:16, Jeffrey Zhang  wrote:
> koala +1
>
> On Mon, Jul 18, 2016 at 9:07 AM, Ryan Hallisey  wrote:
>> koala bear
>>
>> -Ryan
>>
>> - Original Message -
>> From: "Vikram Hosakote (vhosakot)" 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> Sent: Saturday, July 16, 2016 1:24:08 PM
>> Subject: Re: [openstack-dev] [kolla] our mascot - input needed
>>
>> Sorry, I missed the kolla mid-cycle summit as I was at a conference.
>>
>> I will review the mid-cycle etherpad.
>>
>> Yes for the koala bear!! :)
>>
>> Regards,
>> Vikram Hosakote
>> IRC: vhosakot
>>
>> From: "Steven Dake (stdake)" < std...@cisco.com >
>> Reply-To: "OpenStack Development Mailing List (not for usage 
>> questions)" < openstack-dev@lists.openstack.org >
>> Date: Thursday, July 14, 2016 at 1:08 PM
>> To: "OpenStack Development Mailing List (not for usage questions)" < 
>> openstack-dev@lists.openstack.org >
>> Subject: [openstack-dev] [kolla] our mascot - input needed
>>
>> Hey folks,
>>
>> The OpenStack foundation is putting together mascots for every project with 
>> a proper artist doing the work. The cool thing about this is we a) get 
>> stickers b) have consistent look and feel among mascots in OpenStack.
>>
>> The downside is we have to make a decision. The foundation wants 3-5 choices.
>>
>> The mascot must be an animal and it can't involve glue or other 
>> inc007 inspired ideas :)
>>
>> Obviously Koala bear is probably everyone's first choice since we have sort 
>> of been using that as a mascot since day one. Anyone else have anything else 
>> for me to provide the foundation with a choices 2-5?
>>
>> Please respond quickly, the foundation needs the information shortly. I'd 
>> like to offer up two alternatives just in case.
>>
>> Regards
>> -steve
>>
>>
>>
>> _
>> _ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _
>> _ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> 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

__
OpenStack Development Mailing 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] PTG Day #1 Webex remote participation

[Serguei Bezverkhi (sbezverk)]

@Jeremy if you have not tried thelatest webex, then sharing your Havana time 
frame webex experience is not very useful. I think you would agree if Havana 
release had some issues it would not automatically mean that newton has them :-)
Serguei 

-Original Message-
From: Britt Houser (bhouser) 
Sent: Sunday, February 19, 2017 6:43 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla] PTG Day #1 Webex remote participation

I’ve attended two Kolla midcycles remotely everything Steve said here is true.  
But, as long as your expectations are set accordingly, suboptimal is better 
than nothing at all. =)

Thx,
britt

On 2/19/17, 1:09 AM, "Steven Dake (stdake)"  wrote:

Jeremy,

Completely makes sense.  I believe the prior experience the foundation has 
had with remote participation probably won’t be much improved at the Pike PTG 
as there is no dedicated production staff and I’m not sure what type of 
teleconference hardware Michal is bringing to the PTG.  Not to mention the fact 
that the wireless services may be in a DOS state because of the number of 
attendees.

Michal asked the foundation if remote participation was an option, and they 
stated it was.  Michal had then suggested to use zoom.us and promised remote 
participation, however, that didn’t get done until Friday.  Cisco isn’t 
donating the webex services in this case; I am as a community member and Kolla 
core.

I have also found during Kolla midcycle events we have held since the 
founding of Kolla and prior to the PTG (which is the new midcycle) that every 
midcycle event with remote participation is not very optimal for participants 
for the litany of reasons you mention.

Clearly in-person PTG participation is superior to the hacked-together 
telepresence we may have available at the PTG.  I do think whatever 
teleconference hardware Michal brings to summit is better than looking at the 
output of an Etherpad where all kinds of context is lost.

For folks attending from their office remotely, don’t expect a great 
experience.  Face to face participation is always better as Jeremy has stated.

Regards
-steve

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

Date: Saturday, February 18, 2017 at 5:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] PTG Day #1 Webex remote participation

On 2017-02-18 15:46:19 + (+), Steven Dake (stdake) wrote:
[...]
> In the past the foundation has been wary of enabling remote
> participation.
[...]

Only wary because of prior experience: Cisco donated Webex service
and dedicated remote production staff for us throughout the Havana
design summit in Portland, OR. As one of the volunteers who agreed
to monitor the local systems, I can say that it was a suboptimal
solution at best. Supplied laptops acting as the "presenter"
consoles crashed/hung repeatedly, slight instabilities in conference
networking were a major impediment to streaming, omnidirectional
microphones placed throughout the conference rooms still failed to
pick up much of the conversation, and for those who did attempt to
participate remotely we heard numerous complaints about how they
couldn't follow heated discussions with dozens of participants in a
room together.
-- 
Jeremy Stanley


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


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


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

Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Serguei Bezverkhi (sbezverk)]

The idea is great, no doubt here, meaning mentoring and everything, but it 
should not come with price of reducing quality control. 2 x +2 +w should still 
be required from “regular” cores for PS to merge.

Serguei

From: Richard Wellum [mailto:richwel...@gmail.com]
Sent: Thursday, April 13, 2017 7:02 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

As a relatively new member of the openstack community I think the idea of a 
mentorship program is a good one; I'd like to throw my hat in the ring if the 
kolla community needs a guinea-pig to try this on. :)

Rich

On Wed, Apr 12, 2017 at 7:53 PM Matt Riedemann 
mailto:mriede...@gmail.com>> wrote:
On 4/12/2017 3:40 PM, Steven Dake (stdake) wrote:
> Matt,
>
> Thanks for the response.  It is helpful.
>
> Regards
> -steve
>
> -Original Message-
> From: Matt Riedemann mailto:mriede...@gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> mailto:openstack-dev@lists.openstack.org>>
> Date: Wednesday, April 12, 2017 at 4:36 PM
> To: 
> "openstack-dev@lists.openstack.org" 
> mailto:openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer 
> mentorship program for Kolla deliverables
>
> On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
> > Hey folks,
> >
> >
> >
> > In today’s Kolla team meeting, the idea was proposed of adopting nova’s
> > “protocore” mentorship program for Kolla.  We would like to know what
> > nova has learned from this effort.
> >
> >
> >
> > In today’s Kolla meeting we had broad consensus on the following:
> >
> > 1)   Kolla has participants that want to be core reviewers
> >
> > 2)   These participants don’t know how to become core reviewers
> >
> > 3)   The core reviewers in Kolla should mentor “protocore” reviewers
> > on how to do good reviews
> >
> >
> >
> > From that, we concluded some form of mentorship program for potential
> > core reviewers was in order.  We got into some debate about _/how/_ the
> > program should be rolled out.  Let’s use this thread to discuss how it
> > should be rolled out since that seems to be the sticking point of the
> > discussion.  I saw no dissent in the discussion that the basic concepts
> > were a negative change.
> >
> >
> >
> > I am aware that nova uses a +1 review from a “protocore” and a +2/+w
> > from a core reviewer prior to merge.  Nova cores – would you mind
> > defining your process (on the ml is fine) more thoroughly and your
> > experiences so we can learn from you?
> >
> >
> >
> > All kolla contributors, feel free to debate the **how** such a
> > mentorship program should be rolled out.  I think we have a lot to learn
> > from our peers in the OpenStack community and learning from their
> > experiences may be helpful.
> >
> >
> >
> > Regards
> >
> > -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
> >
>
> Nova has this thing? That's news to me. :)
>
> I don't think Nova has a formal process for something like this. There
> was talk at the BCN summit about giving some people +2 rights on parts
> of the tree but not full core on everything. We never implemented that.
>
> Maybe what you're referring to is how we consider a +1 from a domain
> expert like a +2, or at least something that's good to have before cores
> are looking into the change in more detail? For example, gibi is the
> lead for the versioned notifications effort and we/I generally look for
> his +1 on a change before digging into it, or approving it. We have
> similar unofficial things like this in other parts of Nova, or subteams,
> like Timofey and Pawel with the live migration subteam.
>
> To be sure, someone that is leading a subteam effort and is looked to
> for their opinion on a whole series of changes eventually gets into the
> conversation when we're talking about potential core reviewers, in part
> because, at least I personally, am looking for not only strong code
> review skills but also leadership/ownership within the project, because
> those are also the people that tend to stick around awhile so I'm more
> comfortable investing my time into them (and building a trust
> relationship with them).
>
>  

Re: [openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to core team

[Serguei Bezverkhi (sbezverk)]

+1
well deserved
Serguei
From: "Vikram Hosakote (vhosakot)" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, August 11, 2017 at 7:31 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to core 
team

Rich? Well, um ;)

Although I’m not a kolla-kubernetes core and my vote does not matter at all, 
I’ll still give
my +1 to Rich ☺.

Amazing work in kolla-kubernetes Rich especially your recent contribution of 
the Python
tool to automate the deployment of kolla-kubernetes.

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

Regards,
Vikram Hosakote
IRC: vhosakot

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

Date: Friday, August 11, 2017 at 12:01 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to core team

Hello,

It's my pleasure to start another core team vote. This time for our
colleague rwellum. I propose that he joins kolla-kubernetes team.

This is my +1 vote. Every kolla-kubernetes core has a vote and it can
be veto'ed.

Voting will last 2 weeks and will end at 25th of August.

Cheers,
Michal

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

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

Re: [openstack-dev] [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 mailto:zhang.lei@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, November 27, 2016 at 9:40 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto:sigmaviru...@gmail.com>> 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" 
mailto:zhang.lei@gmail.com>> 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
__

Re: [openstack-dev] [kolla] Kolla-k8s core nominations

[Serguei Bezverkhi (sbezverk)]

portdirect +1
srwilkers +1

Great to have these gents on the team.

Serguei

-Original Message-
From: Fox, Kevin M [mailto:kevin@pnnl.gov] 
Sent: Wednesday, December 14, 2016 2:49 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla] Kolla-k8s core nominations

+1 to portdirect and srwilkers. both are doing a great job!

Thanks,
Kevin

From: Steven Dake (stdake) [std...@cisco.com]
Sent: Wednesday, December 14, 2016 10:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Kolla-k8s core nominations

portdirect +1
srwilkers +1

Doing a fantastic job reviewing and writing code and participating in team 
meetings/irc conversations.

Regards
-steve


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

Date: Wednesday, December 14, 2016 at 10:06 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla] Kolla-k8s core nominations

I'm happy to start nomination process for our 2 colleagues:

srwilkers and portdirect

to kolla-k8s core team!
This nomination will is open for 1 week. Kolla-k8s core team, please vote:)
Consider this email as vote +1 from me.

Regards,
Michal

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


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

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

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

[openstack-dev] [kolla] helm-repository container

[Serguei Bezverkhi (sbezverk)]

Hello team,

While researching for an operator, piece of code which runs as a container and 
launches microservice in correct order to bring up a specific service, I came 
across a need to have helm charts/packages be stored and served from a 
centralized location. Since I could not find a ready-to-go solution I am 
proposing to introduce an internal helm-repository container along with 
helm-repository-service and persistent storage.
It should behave something similar to Docker private registry.  In this case 
operator, can rely on service object to locate helm-repository and fetch 
microservice packages it requires to bring up its service.

Here is in general overview of bringing up helm-repository:

1. Init container of helm-repository POD is responsible of initializing and 
populating persistent storage with charts/packages.
 1.1 Init container retrieves charts/packages bits via: (some ideas, 
new/better ideas are welcome). All these methods could be passed as a parameter.
 1.1.1 using git clone of kolla-kubernetes
 1.1.2 using tar file stored on some internal web server
 1.1.3 from the configmap where tar file is attached
 1.2 Init container generates required packages information
2. Main container starts serving packages to operators or other entities.

Here is the reason for using persistent storage:
1. In case container gets restarted/killed, when it comes back up it has to use 
exactly the same set of packages as before to preserve consistency. It will go 
through init process only if persistent storage is empty.
2. Possibility in future to update the repo with new version of packages and 
then not going through the replay of all past updates from the original version 
baked into the image.

Appreciate your comments suggestions and critic ;-)

Thank you

Serguei

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