15:00:52 <rhochmuth> #startmeeting monasca
15:00:52 <openstack> Meeting started Wed Nov 16 15:00:52 2016 UTC and is due to finish in 60 minutes.  The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:56 <openstack> The meeting name has been set to 'monasca'
15:00:56 <slaweq> bye
15:00:57 <davidsha> thanks, cya
15:01:06 <rhochmuth> o/
15:01:11 <koji> o/
15:01:14 <arturbasiak> o/
15:01:15 <witek> hello
15:01:16 <shinya_kwbt> o/
15:01:17 <rhochmuth> Agenda has been posted at, https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:01:19 <hosanai> o/
15:01:19 <rhochmuth> OMG
15:01:28 <witek> :)
15:01:36 <rhochmuth> Agenda for Wednesday November 16, 2016 (15:00 UTC)
15:01:36 <rhochmuth> 1.	Ocata-1 milestone
15:01:36 <rhochmuth> 2.	Ocata Community Goals Acknowledgement
15:01:36 <rhochmuth> 1.	http://governance.openstack.org/goals/ocata/remove-incubated-oslo-code.html
15:01:36 <rhochmuth> 3.	confluent-kafka-python for monasca-common (next to kafka-python)
15:01:53 <rhochmuth> And the award for the longest agenda every goes to team Monasca
15:01:58 <tomasztrebski> o/
15:02:12 <tomasztrebski> flowers, fame and glory ... :D
15:02:32 <rhochmuth> We might as well get started
15:02:43 <rhochmuth> #topic Ocata-1 milestone
15:02:59 <witek> tomorrow is Ocata 1st milestone
15:03:07 <witek> should we tag the repos?
15:03:20 <rhochmuth> Sure, sounds like a good idea
15:03:31 <witek> ok, I'll take care
15:03:42 <rhochmuth> There are already features, like the dimension names/values that are not in the python-monascaclient
15:04:01 <rhochmuth> which we should get tagged so when devstack builds at least they show up
15:04:07 <rhochmuth> thanks witek
15:04:49 <rhochmuth> i guess that is it on that topic
15:04:55 <rhochmuth> #topic Ocata Community Goals Acknowledgement
15:05:17 <witek> we should acknowledge community-wide goals for Ocata
15:05:24 <witek> there is one actually
15:05:32 <tomasztrebski> ?
15:05:33 <witek> Remove Copies of Incubated Oslo Code
15:05:42 <tomasztrebski> I guess that was a problem only for client
15:05:46 <tomasztrebski> which was already mergde
15:05:48 <tomasztrebski> *merged
15:06:13 <rhochmuth> so, i'm not aware of any copies of oslo code anymore
15:06:23 <rhochmuth> so, are we good on that one?
15:06:32 <rhochmuth> is there a link i should be referring too?
15:06:42 <witek> ok, I'll update the wiki page then
15:06:47 <tomasztrebski> AFAIK we are, according to announcement only client was listed by OS as sth we need to fix
15:08:25 <witek> yes, it seems we're ok on that one
15:08:54 <rhochmuth> is there something we need to address with the announcemtn
15:08:57 <rhochmuth> i didnt' see it
15:09:13 <witek> http://governance.openstack.org/goals/ocata/remove-incubated-oslo-code.html
15:09:18 <witek> there is that wiki page
15:09:52 <witek> monasca  Planning Artifacts:  Completion Artifacts:
15:10:25 <rhochmuth> i don't see anythign listed
15:10:32 <rhochmuth> for monasca
15:11:38 <rhochmuth> is there anything to do, should a completion artificat be listed
15:11:48 <rhochmuth> or are we basically done
15:11:56 <witek> I'm not sure
15:12:14 <witek> we could put links to completed reviews
15:12:24 <tomasztrebski> +1
15:12:24 <rhochmuth> sounds like busy work
15:12:38 <witek> there were just 3, right?
15:12:43 <tomasztrebski> yeah
15:13:04 <tomasztrebski> https://review.openstack.org/#/q/status:merged+project:openstack/python-monascaclient+branch:master+topic:goal-remove-incubated-oslo-code
15:15:17 <rhochmuth> ok, i could update that page, unless you want to witek
15:15:33 <witek> you decide :)
15:16:09 <rhochmuth> i'll look into it
15:16:14 <witek> thanks
15:16:15 <rhochmuth> see what is involved
15:16:34 <rhochmuth> #topic confluent-kafka-python
15:16:55 <rhochmuth> is it really like 10X faster?
15:17:04 <tomasztrebski> according to the document
15:17:33 <rhochmuth> i would be all for an upgrade
15:17:34 <witek> at least in single node conf
15:17:35 <tomasztrebski> we did not move with investigating/writing any code, we wanted to clarify if monasca would be interested in this
15:17:45 <rhochmuth> yes interested
15:18:00 <rhochmuth> need to have joe look at this
15:18:11 <witek> it is not listed in global-requirements
15:18:19 <rhochmuth> he's been measuring and followign the client that we are using
15:18:33 <tomasztrebski> we don't have that much time to work on this, but code is WIP to make monasca-common using that library next to exisiting kafka-python
15:18:35 <rhochmuth> the main reason for not upgrading is that they had some issues
15:18:46 <tomasztrebski> everything would depend on actual kafka library installed
15:19:00 <tomasztrebski> so the transition if any would be smooth and not enforced
15:19:18 <tomasztrebski> plus all would end with new gate job for monasca plugin that would stack up everything with confluent-kafka
15:19:20 <rhochmuth> so, could back out if there were issues?
15:19:27 <tomasztrebski> that's the rough plan for this
15:19:44 <tomasztrebski> actually you wouldn't need to back up
15:19:54 <rhochmuth> have you don't any analysis of the api or persister
15:20:04 <tomasztrebski> no, not yet
15:20:05 <rhochmuth> i'm assuming you want this for both metrics and logging
15:20:18 <witek> python persister is 3x slowlier than java
15:20:38 <tomasztrebski> doing this in monasca-common would have potential impact (good one) on every project using that
15:21:03 <rhochmuth> so, are we using monasca-common for kafka everywhere at this point?
15:21:37 <tomasztrebski> ehm...I thought so, actually now that you asked I am not really sure
15:21:48 <tomasztrebski> log-api is using that for sure
15:22:09 <rhochmuth> joe was running into crashes with the latest kafka client
15:22:15 <rhochmuth> not sure if those have been resovled
15:22:21 <rhochmuth> but this would obviousely bypass that
15:22:56 <rhochmuth> would you want to update global requirements?
15:23:06 <rhochmuth> we might run into problems there
15:23:08 <tomasztrebski> with confluent-kafka ?
15:23:13 <rhochmuth> correct
15:23:25 <tomasztrebski> that might be problematic, because it requires compiling one C-library
15:23:28 <rhochmuth> my assumption is that they won't want two kafka libraries
15:23:28 <tomasztrebski> rdkafka
15:23:32 <witek> what are the requirements to get added to global-requirements?
15:24:02 <tomasztrebski> add change to one infra projet and see how it goes ? :D
15:24:21 <rhochmuth> usually nice well supported python code which is properly licenses
15:24:28 <rhochmuth> and doesnt' compete with an existing library
15:24:49 <rhochmuth> industry adoption
15:24:49 <witek> the second one is not the case here
15:25:00 <rhochmuth> performance would be another criteria
15:25:10 <rhochmuth> so, we got ujson in
15:25:12 <witek> it is also relatively new
15:25:21 <rhochmuth> which compete with json and simplejson
15:25:34 <tomasztrebski> both are based on Apache, but I would not go that far right now, I mean first we should clarify if the API of the confluent-kafka-python meets all the requirements that monasca presents
15:25:36 <rhochmuth> so, it might be accepted based on the performance analysis
15:25:44 <rhochmuth> but i expect it will be questioned
15:25:44 <tomasztrebski> performance on one side, but the capabilities on the other
15:25:57 <rhochmuth> right
15:26:25 <rhochmuth> so, i'll let you guys drive that
15:26:39 <rhochmuth> i wasnt' looking at reviews for a few days
15:26:45 <rhochmuth> so, little behind
15:26:56 <tomasztrebski> ok, guess now we will need to discuss that internally and give feedback from your feedback and plan that somehow
15:27:20 <rhochmuth> sure
15:27:26 <rhochmuth> shoudl we move on
15:27:30 <tomasztrebski> +1
15:27:39 <rhochmuth> #topic https://review.openstack.org/#/c/366024/
15:27:52 <rhochmuth> migrate devstack to xenial
15:28:25 <shinya_kwbt> there are vagrant problem.
15:28:28 <tomasztrebski> one of our (mine, Witek) folks tested this recently for both Java&Python
15:28:38 <tomasztrebski> it stacks up with workaround
15:28:52 <rhochmuth> what was the work-around?
15:29:16 <tomasztrebski> shinya_kwbt: problem you have can be solved with starting up machine without provision and than creating one snapshot
15:30:09 <shinya_kwbt> I solved with that
15:30:11 <shinya_kwbt> 1. vagrant up --no-provision && vagrant halt 2. open virtualbox gui 3. open target vm settings and change storage controller from SCSI to SATA 4. vagrant up
15:30:11 <tomasztrebski> so instead of vagrant destroy -f ; vagrant up for clean install, you would do vagrant sandbox rollback ; vagrant provision
15:30:33 <witek> I have also tested with bento box, but it exited on smoke tests
15:30:38 <tomasztrebski> assuming using vagrant-sahara
15:30:56 <shinya_kwbt> witek: me either
15:31:53 <shinya_kwbt> not vagrant environment works fine so I think tempest-gate may work
15:32:16 <tomasztrebski> I assume so too, looking at other projects that already moved to xenial
15:32:38 <tomasztrebski> @witek actually created a change that would result in NV gate for ubuntu-xenial
15:33:06 <tomasztrebski> we would see any issues with that prior to merging shinya_kwbt change
15:33:37 <tomasztrebski> https://review.openstack.org/#/c/397789/
15:35:00 <rhochmuth> so, that review looks like is should be merged
15:35:09 <rhochmuth> as it is experimental
15:35:14 <witek> yes
15:35:23 <witek> for agent, non-voting
15:35:29 <rhochmuth> then we can see if shinya's merge works
15:35:31 <witek> the rest experimental
15:35:45 <witek> I hope it works this way :)
15:35:46 <shinya_kwbt> rhochmuth: thanks
15:35:48 <rhochmuth> then we can see if shinya's review works
15:35:58 <rhochmuth> and if it does, it can be merged
15:36:12 <rhochmuth> then can change from experimental
15:36:20 <witek> correct
15:36:31 <rhochmuth> although Vagrant will still be partly broken
15:36:38 <rhochmuth> with xenial
15:37:02 <rhochmuth> after shinya's change merges if i understand correctly
15:37:13 <shinya_kwbt> Yes virtual box SCSI controller has problem. Trusty image has SATA controller but xenial has SCSI.
15:37:32 <rhochmuth> those bastards
15:37:40 <witek> vagrant is still an issue, but I think we can merge it if gate tests pass
15:37:45 <tomasztrebski> well we could try and try to solve that to make vagrant work on trusty still, I have at least one idea for that
15:37:48 <tomasztrebski> or two
15:37:49 <rhochmuth> :-)
15:37:50 <tomasztrebski> ;-)
15:38:15 <rhochmuth> thanks tomasz
15:38:35 <rhochmuth> so, i'm going to put a +1 on your experimental review witek
15:38:45 <rhochmuth> then we can watch what happens next
15:38:50 <tomasztrebski> don't thank me now...not really sure if I will find any time to devote any time to that
15:38:52 <witek> thank you
15:39:05 <rhochmuth> welcome
15:39:07 <rhochmuth> done
15:39:29 <rhochmuth> thanks witek and shinya!
15:39:37 <rhochmuth> adn tomasz and everyone
15:40:24 <shinya_kwbt> thanks tomasz witek
15:40:27 <rhochmuth> #topic https://review.openstack.org/#/c/384128/
15:41:09 <rhochmuth> tomasz, that is you
15:41:22 <rhochmuth> Granular logging control
15:41:26 <tomasztrebski> it just to remind to take a look, already have monasca-api and monasca-log-api working with new logging configuration, so it would just supplement what has been already done in that topic
15:42:04 <tomasztrebski> agent and notification components are not that easy to refactor it to work with oslo.log
15:42:21 <rhochmuth> ok, looks fine to me
15:42:29 <tomasztrebski> not to mention that it would be like revolution there instead of simple refactor
15:42:32 <rhochmuth> but i should look at it a little closer
15:42:37 <tomasztrebski> np
15:42:55 <rhochmuth> #topic https://review.openstack.org/#/c/391576/
15:43:18 <tomasztrebski> also me
15:43:28 <rhochmuth> it is failing
15:43:39 <rhochmuth> but, i think it is a good idea
15:43:43 <tomasztrebski> yeah and it will, because it requires gate change
15:43:55 <tomasztrebski> this is not like zookeeper change I posted sometime ago
15:44:02 <tomasztrebski> zookeeper is builtin inside the devstack
15:44:09 <tomasztrebski> kafka is a yet another plugin
15:44:22 <tomasztrebski> but if you find it a good idea, I will work on this in my free time
15:44:53 <rhochmuth> the only issue i have is that we might want to consdier upgradign to the newest kafka
15:45:15 <rhochmuth> 0.10.1 or later
15:45:39 <tomasztrebski> we might go with another gate with would be NV and use newer kafka
15:46:08 <tomasztrebski> luckily version of kafka is part of plugin/settings so can be overidden in gate setup
15:46:21 <tomasztrebski> plugin also specify such variables AFAIK
15:46:43 <rhochmuth> well, in general then i think it is a good idea
15:46:50 <rhochmuth> what other projects are using kafka?
15:46:53 <rhochmuth> do you know
15:47:02 <tomasztrebski> no idea
15:47:04 <tomasztrebski> :(
15:47:17 <rhochmuth> the problem is that the kafka releases are incompatible
15:48:33 <rhochmuth> so, i think  you are approved tomasz to proceed if you want to
15:48:38 <rhochmuth> i can't see any problems
15:48:46 <rhochmuth> seems like we are covered
15:48:56 <rhochmuth> if we want to upgrade
15:49:21 <tomasztrebski> i will figure sth out ;), at least working on using plugin in monasca and/or new gate
15:49:34 <rhochmuth> ok, thanks
15:49:49 <rhochmuth> #topic https://review.openstack.org/#/c/395246/
15:49:57 <rbak> These two are mine
15:50:01 <tomasztrebski> witek: the same gate should be done also to the log-api devstack jobs
15:50:05 <rbak> Just trying to get some attention on them
15:50:31 <rbak> We're trying to backfill data, but we're blocked by lacking these abilities
15:51:59 <rhochmuth> so, does anyone have any opinions on those two reviews
15:52:08 <tomasztrebski> yeah, just posted one ;d
15:52:09 <rhochmuth> i thought about the backfill problem
15:52:33 <rhochmuth> wasn't sure if this should just be a admin feature
15:53:00 <rbak> It's not something we would want to expose to customers
15:53:04 <rhochmuth> was wondering since it isn't in python, if it shoudl be added
15:53:11 <rbak> Although we could tie it to a brand new role
15:53:32 <rhochmuth> "backfill" role
15:53:45 <rhochmuth> sounds a bit combersome
15:53:55 <rhochmuth> complicated
15:53:56 <rbak> tomasztrebski: I'm not sure I follow your comment on that patch, can you elaborate?
15:54:08 <tomasztrebski> AFAIK, we should not go into role mores, I would consider moving to policies...I know that is a lot of work but there is a reason why there's a dedicated oslo library for that
15:54:19 <rbak> rhochmuth: Yeah, we just went with the cleanest solution for the moment.
15:54:50 <rhochmuth> yeah, the problem is that java code doesn't support oslo
15:55:06 <tomasztrebski> ahhh....java ;/
15:55:34 <rhochmuth> but getting the python code to implement the rbac like the rest of openstack would be good
15:55:37 <rhochmuth> been on the list forever
15:55:52 <tomasztrebski> so in case of +1 for policies that would require extra work for java
15:56:09 <rhochmuth> anyway, i thought about this a bit
15:56:13 <rhochmuth> whether the right direction
15:56:25 <rhochmuth> i can't see any problems with what is being proposed in the review
15:56:48 <rhochmuth> and, it sounds like we don't want to do anything with the python code for this case
15:56:53 <rhochmuth> right?
15:57:32 <rbak> Not for the moment anyway.
15:59:28 <rhochmuth> should we move to #openstack-monasca?
15:59:43 <rhochmuth> we are at the end of the hour slot
15:59:57 <witek> I would prefer to move the rest to next week
15:59:58 <tomasztrebski> uh...I won't be able to join, got to go out
16:00:02 <tomasztrebski> me too
16:00:10 <rhochmuth> i won't be around next week
16:00:11 <tomasztrebski> what can be covered in gerrit, let's cover it there
16:00:24 <rhochmuth> ok, see you in two weeks
16:00:33 <tomasztrebski> bye
16:00:37 <rhochmuth> #endmeeting