16:00:55 <mnaser> #startmeeting openstack_ansible_meeting
16:00:56 <prometheanfire> sup
16:00:56 <openstack> Meeting started Tue Nov  6 16:00:55 2018 UTC and is due to finish in 60 minutes.  The chair is mnaser. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:59 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:01:00 <mnaser> #topic roll call
16:01:02 <mnaser> o/
16:01:08 <arxcruz> o/
16:01:14 <jrosser> o/
16:01:28 <evrardjp> o/
16:01:31 <prometheanfire> o/
16:01:37 <chandankumar> \o/
16:01:48 <mnaser> yay
16:01:48 <hwoarang> o/
16:02:01 <odyssey4me> o/ but in another meeting too
16:02:07 <evrardjp> we definitely have the quorum here.
16:02:12 <mnaser> #topic Last week highlights
16:02:42 <evrardjp> no highlights? Nothing big to share? :(
16:02:52 <mnaser> everyone will be in berlinnnnn
16:03:14 <evrardjp> I was off last week,so i don't know what happened last week
16:03:24 <mnaser> yeah it was just a get boring stuff done type of week
16:03:41 <evrardjp> ok
16:03:44 <jrosser> i poked a bit more at mitogen and got our first AIO to build sucessfully, that was quite cool
16:03:45 <evrardjp> then next? :D
16:03:51 <evrardjp> jrosser: nice!
16:03:57 <mnaser> yes, i think we need to hack around more with that
16:04:22 <mnaser> the speed ups were great
16:04:29 <jrosser> indeed - anyone interested can take a look at my patch and play https://review.openstack.org/#/c/591236/
16:04:51 <mnaser> lets work with dw_ to make it happen, i'd be excited to see the speeds up both in gates and overall deployments
16:05:07 <mnaser> #topic Bug triage
16:05:28 <mnaser> #link https://bugs.launchpad.net/openstack-ansible/+bug/1801657
16:05:28 <openstack> Launchpad bug 1801657 in openstack-ansible "fix tox python3 overrides" [Undecided,New]
16:06:00 <mnaser> does this affect us (i feel like this is a global "add a bug in every project" type of thing
16:06:14 <evrardjp> yup I have the impression
16:06:32 <evrardjp> I think we changed tox.ini for the docs/reno, right?
16:06:34 <mnaser> duplicates too
16:06:56 <mnaser> we did that
16:07:07 <mnaser> and also for linters i think?  i mean the thing that mordred once mentioned was
16:07:14 <evrardjp> yeah
16:07:20 <mnaser> if our project focuses on deploying somewhere where the norm is... python2
16:07:23 <evrardjp> it seems testenv still has 2.7
16:07:29 <mnaser> then we should adapt to that, because we're actually tied to the base OS
16:07:36 <evrardjp> https://github.com/openstack/openstack-ansible/blob/master/tox.ini but I think it's fine until we decide a whole move towards python3
16:07:54 <mnaser> and i kinda agree.. until we decide to do python3 everywhere (which might be in a while with rhel in there :()
16:08:10 <evrardjp> mnaser: remember I had pushed for python3 earlier
16:08:17 <dw_> biggest mitogen blocker for OSA is all the delegate_to bugs, i think
16:08:18 <evrardjp> and at the end, I dropped the ball. So many little things
16:08:29 <dw_> i'm trying to fit a rewrite of delegate_to into 0.2.4 to fix it once and for all
16:08:33 <evrardjp> so we moved to use basic python2 instead
16:08:34 <mnaser> nice dw_ !
16:08:37 <evrardjp> dw_: nice!
16:08:48 <mnaser> evrardjp: it feels like we should stick to python2 maybe once all projects are python3 first of all
16:08:49 <evrardjp> thanks for joining our meeting :D
16:08:58 <evrardjp> mnaser: that was what we decided
16:09:28 <mnaser> and once all supported operating systems are python3 we can look into it
16:09:30 <mnaser> so for now i can say
16:09:32 <evrardjp> we don't own that much code that's python2 only, and it can be moved to python3 quite easily. The rest of the stack where we deploy, that's where the pain is.
16:09:43 <evrardjp> mnaser: agreed there
16:09:43 <mnaser> thats confirmed/medium?
16:09:56 <mnaser> ugh im getting a really big blob of red text
16:09:58 <mnaser> when i try to set it to confirmed
16:10:00 <mnaser> launchpad PLZ
16:10:05 <evrardjp> well I guess it depends... tox.ini just has testenv on python2 the rest is python3 already
16:10:12 <evrardjp> (linters/doc/reno)
16:10:22 <mnaser> <title>Error: Launchpad system error</title>
16:10:23 <evrardjp> mnaser: refresh?
16:10:34 <evrardjp> oh yeah the 5:10 thing.
16:10:40 <evrardjp> refresh in a minute or so
16:10:46 <evrardjp> :D
16:10:49 <mnaser> oh this is common at this time?
16:10:49 <mnaser> lol
16:11:03 <mnaser> ok lets get start triaging next bug
16:11:09 <mnaser> and we can get back when launchpad wakes up
16:11:13 <mnaser> #link https://bugs.launchpad.net/openstack-ansible/+bug/1800837
16:11:14 <openstack> Launchpad bug 1800837 in openstack-ansible "openstack-ansible-nova-lxd test fails due to lxd storage pool not set up on bionic host" [Undecided,New]
16:12:49 <mnaser> this is a bit above my knowledge level
16:13:07 <evrardjp> likewise
16:13:21 <mnaser> evrardjp: who contributed/maintained this initially?
16:13:59 <evrardjp> maybe odyssey4me can refresh my memory there.
16:14:04 <evrardjp> :D
16:14:17 <evrardjp> IIRC jrosser played with it at some point
16:14:38 <evrardjp> but no idea who is using it in production. cloudnull had it in a lab at some point too
16:14:49 <jrosser> not exactly - but I do a ton of LXD outside of OSA
16:15:06 <evrardjp> that's the cause of my confusion :)
16:15:38 <evrardjp> IIRC what cloudnull said in the past, he had a multi-type environment with kvm/LXD/ironic
16:15:39 <jrosser> this is all really to do with the release of lxd 3 as the bug says
16:15:55 <evrardjp> jrosser: the point is to find who will be owning said code
16:16:08 <evrardjp> if nobody cares when it breaks, why should we?
16:17:35 <evrardjp> let me check in code real quick
16:17:58 <mnaser> thanks evrardjp
16:18:05 <nicolasbock> Does lxd bring advantages over lxc?
16:18:11 <jrosser> i dont have any nova-lxd, but have planned to. just not enough time
16:18:41 <evrardjp> jmccrory: are you there?
16:18:47 <mnaser> could this be a labour of love thing if we have to do a very small change?
16:19:00 <evrardjp> nicolasbock: lxd was only used for nova backend
16:19:22 <evrardjp> mnaser: it's probably nothing
16:19:27 <nicolasbock> Ah, sorry, I should have realized from the name `nova-lxd` ;)
16:19:30 <evrardjp> mnaser: we can mark it as confirmed and medium : )
16:19:35 <evrardjp> or low
16:19:54 <evrardjp> and wait for someone to do this labour
16:20:09 <evrardjp> (while we are busy with so many other things)
16:22:01 <evrardjp> should we move to next bug?
16:22:18 <mnaser> Yep. I will mark it in a second
16:23:30 <evrardjp> (you can probably skip the bug talking about the example, as there is no update, except maybe to encourage again someone to contribute?)
16:23:35 <evrardjp> mnaser: still issues with LP?
16:23:53 <mnaser> Sorry, just needed to move actually
16:25:57 <mnaser> apologies for that
16:26:00 <mnaser> just needed to relocate
16:26:03 <mnaser> ok so
16:26:12 <mnaser> confirmed low
16:26:19 <cloudnull> o/ all
16:26:20 <evrardjp> lgtm
16:26:24 * cloudnull super late
16:26:26 <mnaser> hey cloudnull
16:26:44 <evrardjp> cloudnull: just in time for talking about nova-lxd
16:26:53 <mnaser> i still cant change state of https://bugs.launchpad.net/openstack-ansible/+bug/1801656 for some reason
16:26:53 <openstack> Launchpad bug 1801656 in openstack-ansible "fix tox python3 overrides" [Undecided,New]
16:26:54 * mnaser shrugs
16:27:01 <mnaser> #link https://bugs.launchpad.net/openstack-ansible/+bug/1799514
16:27:02 <openstack> Launchpad bug 1799514 in openstack-ansible "Test environment example in openstack-ansible" [Undecided,New]
16:27:05 <evrardjp> cloudnull: were you the one to contribute to it? Or was it jmccrory ?
16:27:11 <evrardjp> I can't seem to remember
16:27:15 <mnaser> ah damn
16:27:22 <mnaser> i think someone fixed this
16:27:28 <cloudnull> I worked on it some
16:27:40 <cloudnull> however I think it was jmccrory and crew that did the original work
16:27:51 <evrardjp> ok
16:28:20 <mnaser> https://review.openstack.org/#/c/614379/ fixed it!
16:28:21 <evrardjp> then the bug we discussed just before this one was about it, if you or jmccrory could have a look that would be great. It's a new LXD issue that needs probably an extra task or so
16:28:29 <evrardjp> mnaser: great you found it :)
16:28:35 <evrardjp> Mark it as fix released then?
16:28:50 <evrardjp> or fix committed
16:28:57 <evrardjp> depending on the situation :)
16:29:12 <mnaser> released cause pushed to master i guess
16:29:18 <mnaser> no closes-bug so it wont ever make it down thechain
16:29:32 <mnaser> #link https://bugs.launchpad.net/openstack-ansible/+bug/1704161
16:29:32 <openstack> Launchpad bug 1704161 in openstack-ansible "open-iscsi post-installation script fails in cinder-api-container" [High,New] - Assigned to Damian Cikowski (dcdamien)
16:30:00 <mnaser> marked as confirmed
16:30:09 <evrardjp> dcdamien: has worked on this, right?
16:30:19 <dcdamien> yep
16:30:20 <evrardjp> it's "related bug" in the commits, so not sure what's missing
16:30:31 <evrardjp> do you think we can close it dcdamien ?
16:30:32 <mnaser> https://review.openstack.org/#/c/614556/ probably needs a rebase right
16:30:37 <mnaser> its not resolved/merged yet
16:30:47 <evrardjp> or there are extra patches that need to happen?
16:30:56 <mnaser> ^ that one probably needs to land
16:31:09 <evrardjp> mnaser: but would it be a "closes-bug" ?
16:31:26 <evrardjp> I haven't followed sorry
16:31:26 <mnaser> i think it would close that bug
16:31:29 <mnaser> barring some wild stuff
16:31:39 <dcdamien> we can close when mentioned change merge
16:31:51 <evrardjp> ok so we probably need to rebase and update the commit message
16:32:01 <dcdamien> Okay, I'll do it
16:32:05 <mnaser> dcdamien: if you cahnge Related-Bug to Closes-Bug it will close bug automatically when done :)
16:32:05 <evrardjp> dcdamien: thanks!
16:32:13 <mnaser> dcdamien: i have some reviews, ill push them shortly for that
16:32:28 <evrardjp> dcdamien: you can ping us for review when you're ready :)
16:32:36 <dcdamien> kk
16:32:46 <evrardjp> thanks dcdamien !
16:33:06 <mnaser> dcdamien: left some comments :D
16:33:16 <mnaser> and thank you so muuch for your contribs :D
16:33:23 <mnaser> they haven't gone unnoticed
16:33:38 <mnaser> that's it for bug triage
16:33:45 <mnaser> changed the last one to confirmed
16:33:52 <mnaser> #topic open discussion
16:34:00 <mnaser> berlin stuff: https://etherpad.openstack.org/p/OSA-berlin-planning as usual
16:34:19 <mnaser> we have a google hangout, if you're not there, ping any of us and we'll add ya to it :) everyone is welcome
16:34:38 <prometheanfire> mnaser: spotz wanted to talk about dinner plans, current proposal is thursday night
16:34:47 <prometheanfire> ~7:30 PM
16:34:49 <evrardjp> mnaser: the project update and project onboarding are not listed there?
16:34:54 <noonedeadpunk> mnaser: I'd probably would like to take part)
16:35:08 <mnaser> evrardjp: oh they're not?! kmaybe there too obvious to us not to have there
16:35:26 <evrardjp> yeah the - "space" thing
16:35:33 <mnaser> pm'd you the link noonedeadpunk
16:35:42 <evrardjp> added a link for the second search :p
16:36:09 <mnaser> ah sillyness
16:36:41 <mnaser> ok make sure y'all go to day 2 keynotes!
16:36:46 <mnaser> something cool happening using an OSA cloud, JUST SAYING
16:36:53 <mnaser> ok, and dinner plans
16:37:01 <arxcruz> mnaser: cool :)
16:37:17 <arxcruz> mnaser: at the end i would like to talk about os_tempest :)
16:37:20 <cloudnull> ^ ++
16:37:38 <mnaser> unfortunately i have to be in rehearsals almost every night and catching up with family who lives in berlin on thursday before leaving friday, so i dont think i'll be able to make much plans :(
16:38:39 <evrardjp> arxcruz: go ahead :0
16:38:41 <mnaser> but yeah, amy wanted opinions on what prometheanfire suggested
16:38:50 <mnaser> but we can hash that out in a hangout
16:38:53 <arxcruz> So...
16:38:59 <prometheanfire> not been to berlin, so no clue what's good, I could ask a friend if you want
16:39:01 <evrardjp> mnaser: agreed, let's put that into hangout :)
16:39:08 <arxcruz> We are about to add python-tempesconf initial patch
16:39:14 <prometheanfire> about how many do we expect?
16:39:14 <evrardjp> arxcruz: woot!
16:39:17 <arxcruz> I would like to propose a job to test it
16:39:24 <arxcruz> Even though it’s non-vote
16:39:37 <mnaser> i support that
16:39:37 <evrardjp> what's the issue ? you can if you want :)
16:39:45 <arxcruz> Just saying :)
16:39:51 <evrardjp> haha great :)
16:40:02 <arxcruz> Also, i would like in the summit we talk about the collaboration between tripleo and os_tempest role
16:40:07 <evrardjp> I support that too, so, here you are with your votes :D
16:40:11 <arxcruz> My manager wants more visibility from other developers
16:40:29 <evrardjp> sounds good -- do you have something in mind?
16:40:44 <arxcruz> Not yet, but we can discuss later
16:40:56 <arxcruz> We just realize that we talked about it in ptg
16:41:03 <arxcruz> But nobody else knows what’s going on
16:41:14 <arxcruz> We plan to have a report weekly with the progress
16:41:21 <arxcruz> Just to let people aware
16:41:38 <evrardjp> thanks for the info
16:41:40 <arxcruz> Since this is the beginning to collaboration between tripleo and osa team
16:42:00 <evrardjp> I think mnaser said it already in the past, we welcome said collaboration :)
16:42:02 <arxcruz> I don’t know who will be presenting osa in the summit, but mention the collaboration would be nice :)
16:42:20 <arxcruz> Yes :) but for my boss, need to be brooding spread
16:42:22 <arxcruz> Hehehehe
16:42:41 <mnaser> yes
16:42:48 <mnaser> ill add that to our project update and project onboarding
16:42:58 * mnaser takes note
16:43:15 <evrardjp> arxcruz: RedHat contributions slowly grow across cycles. I can highlight it in the project update slides
16:43:21 <openstackgerrit> Damian Cikowski (dcdamien) proposed openstack/openstack-ansible-os_cinder master: Make open-iscsi as requirement just for volume and backup services  https://review.openstack.org/614556
16:43:31 <evrardjp> mnaser: good :)
16:44:20 <evrardjp> mnaser: you should write access on said slides btw :p
16:44:43 <mnaser> yes, i just added it now so i dont forget
16:44:45 <evrardjp> arxcruz: redhat is 4th in terms of commits!
16:44:48 <mnaser> and ill emphasize on it later
16:45:16 <evrardjp> yeah I saw the slide change, great!
16:45:18 <arxcruz> evrardjp: cool, but i was looking more for os_tempest, that is our first collaboration on tripleo
16:45:48 <arxcruz> But we can talk about it outside this meeting, i don’t want to go on on this in this meeting
16:45:49 <evrardjp> for other people interested about the slides we are talking about, it's here: https://docs.google.com/presentation/d/1b1sWeYWLFjMbg9b4hWS7ly4iZH6zwwQcLczWf4f1pUo/edit?usp=sharing
16:45:54 <mnaser> yeah i added that as a note as well
16:45:56 <evrardjp> (WIP)
16:46:45 <evrardjp> I have nothing else to add for open discussion.
16:46:45 <arxcruz> Added on my bookmark to see later, it’s almost 6 here and toddler is already asking for attention :P
16:46:47 * prometheanfire copies them down as final slides
16:46:57 <mnaser> hehe
16:47:02 <mnaser> anyone has any other subjects?
16:47:05 <mnaser> oh also
16:47:08 <mnaser> we'll cancel next weeks meeting?
16:47:12 <evrardjp> yup
16:47:17 <prometheanfire> I haven't even started on my project update, but it's going to just be 5 min for me :|
16:47:21 <evrardjp> next week*
16:48:06 <openstackgerrit> Damian Cikowski (dcdamien) proposed openstack/openstack-ansible-os_cinder master: Make open-iscsi as requirement just for volume and backup services  https://review.openstack.org/614556
16:48:49 <jrosser> i put an agenda item on the wiki about coordinaation services
16:49:33 <jrosser> specifically we have deployment tooling for two things which might want one
16:49:57 <jrosser> designate, seems ok without but would benefit, gnocchi seems all a bit broken without
16:50:07 <jrosser> wondered what opinions were on that
16:50:32 <evrardjp> could you clarify a little more?
16:51:08 <mnaser> i think its pretty much something like etcd
16:51:09 <evrardjp> what do you mean by "coordination service" ?
16:51:18 <mnaser> or redis
16:51:22 <mnaser> things to be consumed by tooz
16:51:24 <evrardjp> oh god if we can avoid etcd I'd do it
16:51:28 <jrosser> some openstack things are semi-expecting to hook into this https://docs.openstack.org/tooz/latest/user/index.html
16:51:37 <evrardjp> but I guess etcd is in base services
16:51:46 <evrardjp> I see
16:52:05 <jrosser> and there are many back ends for that, with a whole pile of caveats/warnings that come with those various choices
16:52:18 <evrardjp> can we use memcached?
16:52:37 <mnaser> "The memcached driver is a basic implementation and provides little resiliency, though it’s much simpler to setup. A lot of the features provided in tooz are based on timeout (heartbeats, locks, etc) so are less resilient than other backends."
16:52:46 <mnaser> "Lacks certain primitives (compare and delete) so certain functionality is fragile and/or broken due to this."
16:52:51 <evrardjp> OMG mysql is even scarier: https://docs.openstack.org/tooz/latest/user/drivers.html
16:52:52 <odyssey4me> I think a few folks have already built roles - I can't recall who exactly. Maybe noonedeadpunk ?
16:53:30 <jrosser> yes, some stuff went into the documentation for gnocchi/redis/zookeeper
16:53:52 <noonedeadpunk> I tried to use zookeeper as a coordination service
16:54:17 <odyssey4me> memcached is not about resiliency - it's used as a cache only... there are other options like kafka which ansmith has proposed for messaging that requires more resilience... not sure if kafka fits the bill for this requirement
16:54:29 <openstackgerrit> Damian Cikowski (dcdamien) proposed openstack/openstack-ansible-os_cinder master: Make open-iscsi as requirement just for volume and backup services  https://review.openstack.org/614556
16:54:37 <evrardjp> odyssey4me: doesn't seem to be listed in tooz drivers
16:54:56 <odyssey4me> we don't really have to own the coordination service as a project - but we should recommend it and have a user story for it
16:55:06 <mnaser> well the thing is
16:55:09 <mnaser> we kinda already have etcd there..
16:55:12 <noonedeadpunk> and it works pretty ok. I may place some patches to https://github.com/openstack/ansible-role-zookeeper
16:55:32 <mnaser> i mean for me the thing is we want to avoid making as much out of band things for the user
16:55:39 <jrosser> is it OK that we deploy gnocchi but it pretty much doesnt work as we leave it?
16:55:47 <jrosser> thats really where i started thinking about this
16:55:58 <mnaser> i don't think that's ok.  also, etcd happens to be an openstack base service
16:56:05 <mnaser> (i'm not a fan)
16:56:07 <mnaser> but hey
16:56:10 <odyssey4me> for zookeeper, for nodepool, our team uses https://github.com/AnsibleShipyard/ansible-zookeeper which includes clustering functionality
16:56:35 <odyssey4me> jrosser is it functional for a single node but broken for multi-node?
16:56:43 <mnaser> odyssey4me: yes ^
16:57:00 <odyssey4me> yeah, thought as much
16:57:01 <jrosser> i think that is true yes
16:57:24 <mnaser> i can confirm it
16:57:25 <odyssey4me> the trouble is that we barely have people maintaining those roles and understanding the services... now we want to stretch more?
16:57:57 <mnaser> yeah i'm torn a bit, i'
16:58:00 <mnaser> i'm hoping they're basic
16:58:02 <odyssey4me> if we have folks like jrosser and mnaser owning the service integration and keeping it running, then we can take it on - but I don't have a cooking clue how any of that stuff works
16:58:09 <noonedeadpunk> odyssey4me: it's functional for both, but it's not optiomal
16:58:10 <ansmith> odyssey4me, kafka doesn't really appply
16:58:39 <evrardjp> mnaser: I agree that it's a base service, and we should use it as appropriately, even if I am not a fan either
16:58:59 <cloudnull> ^ evrardjp read my mind :)
16:59:09 <odyssey4me> otherwise the simplest is to add a doc note that it's broken for multi-node and to add a user story for each different back-end and link to those - then deployers can decide for themselves
16:59:39 <mnaser> i feel like we just need to shape up a bit of the etcd stuff
16:59:49 <mnaser> the thing is the etcd role is actually owned by logan- on github
16:59:52 <odyssey4me> given etcd is a base service - we could provide a betteries-included thing for it, and anyone not a fan can add alternative user stories
17:00:07 <evrardjp> that sounds a good approach odyssey4me
17:00:12 <odyssey4me> that etcd role is etcd2 IIRC, and this would need 3 IIRC
17:00:15 <noonedeadpunk> folks, I really don't have any problems with gnocchi multi-node install without coordination service... Yeah, it has some drawbaks, as processing same metrics several times, but all-in-all statistic is correct
17:00:29 <evrardjp> but I think at the end, those stories will not exist, because the general move is towards etcd
17:00:29 <odyssey4me> but logan- does already need 3 for the new calico thing I think :)
17:00:31 <logan-> o/
17:00:38 <noonedeadpunk> we've based our billing on gnocchi
17:00:46 <mnaser> at scale it really hurts you though noonedeadpunk
17:00:47 <evrardjp> well etcd as a base service was meant for etcd3
17:00:58 <logan-> i actually just refreshed the etcd role to do v3 yesterday
17:01:06 <mnaser> oh what perfect timing
17:01:07 <mnaser> :P
17:01:08 <evrardjp> :)
17:01:15 <evrardjp> Oh I have to run for another meeting
17:01:22 <evrardjp> interesting topic though!
17:01:24 <mnaser> i mean it's pretty straightforward, its just dropping in a file
17:01:55 <evrardjp> add etcd nodes in your inventory, run the role, point to it in gnocchi/whatever consumes it, pray.
17:02:09 <evrardjp> haha
17:02:13 <odyssey4me> evrardjp you forgot - hand over to someone else ;)
17:02:15 <logan-> yea
17:02:21 <evrardjp> odyssey4me: hahaha
17:02:44 <mnaser> logan-: can we start by maybe adding the role to openstack gerrit if you're okay with that?
17:02:47 <logan-> the base deployment is no TLS, the main improvement i would like to see is TLS by default in the clustered setup
17:02:56 <logan-> something like we do with rabbitmq I guess
17:03:04 <jrosser> so if noonedeadpunk says that multinode gnocchi works and mnaser and i are having trouble, there is something else that needs attention?
17:03:14 <logan-> yeah I'm fine with importing it
17:03:17 <odyssey4me> logan- should we perhaps import that role into the openstack namespace if this is going to get broader adoption?
17:03:23 <logan-> fine with me
17:03:27 <odyssey4me> I suspect it may be of interest to other projects too.
17:03:28 <logan-> i just switched it to use molecule too btw
17:03:39 <odyssey4me> Excellent. :)
17:03:49 * odyssey4me pens logan- down to rewrite role tests.
17:03:52 <logan-> :P
17:04:14 <jrosser> are we happy that the etc backend for tooz is sufficient, with it only providing distributed locks?
17:04:52 <mnaser> jrosser: i think that's all we need and its an openstack base service?
17:05:03 <mnaser> i think it'll solve the gnocchi use case and others, doubt we need much more
17:05:04 <odyssey4me> As far as I recall, tooz isn't the best library to use - native is better. tooz dumbs down a lot of functionality because it tries to have many back-ends.
17:05:19 <odyssey4me> So if there's a native driver then use it.
17:05:21 <noonedeadpunk> mnaser: I think it's not base service, as I don't heve it in installation
17:06:06 <mnaser> noonedeadpunk: i meant in the openstack technical governance pov
17:06:25 <noonedeadpunk> ah, ok.
17:06:27 <mnaser> odyssey4me: tooz is a library that abstracts locks to different backends
17:06:31 <mnaser> etcd being one of them
17:06:38 <mnaser> i dunno if native lock exist in gnocchi?
17:07:00 <odyssey4me> mnaser yep, I'm aware of that - but I also remember how everyone hated it and wanted etcd to be a base service so that we didn't have to bother with tooz
17:07:01 <noonedeadpunk> not sure about this either
17:07:04 <odyssey4me> maybe the world has changed
17:08:11 <mnaser> it always is .. i think :P
17:08:21 <mnaser> anyways, i think if we can get logan- to import to openstack namespace
17:08:26 <mnaser> and then we can look at using tooz for a coordination driver
17:08:36 <mnaser> using etcd
17:08:47 <mnaser> sound bueno?
17:09:40 <odyssey4me> fine for me
17:10:00 <logan-> ++
17:11:29 <mnaser> sounds good to me
17:11:44 <noonedeadpunk> just to get more acknowledged - what's wrong with zookeeper (except being written in Java and being part of Apache project)? It seems reliable enought and clusterization is also nice. Or maybe I'm just not common with etcd....
17:12:21 <mnaser> noonedeadpunk: one second
17:12:39 <mnaser> ill do this outside meeting
17:12:41 <mnaser> #endmeeting