15:58:12 #startmeeting OpenStack-Ansible 15:58:12 Meeting started Thu Jul 14 15:58:12 2016 UTC and is due to finish in 60 minutes. The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:58:16 The meeting name has been set to 'openstack_ansible' 15:58:23 #topic Agenda & rollcall 15:59:28 o/ 15:59:45 #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting 15:59:47 o/ 15:59:53 \o 15:59:53 o/ 16:00:09 o/ 16:00:11 rromans: you're right I'm not left handed 16:00:16 \o 16:00:17 \o/ 16:00:37 \o? 16:00:42 \o 16:01:00 \o 16:01:08 hello all 16:01:44 o/ 16:03:12 #topic Review action items from last week 16:03:43 the only item we have is related to mhayden and cloudnull reaching out to ansible 16:03:53 did anything happen there? 16:04:42 alright, I'll take that as a no 16:04:54 #topic Mid Cycle Planning 16:04:56 sorry im in meetings my bad 16:05:03 kinda not here. 16:05:07 #link https://etherpad.openstack.org/p/osa-midcycle-newton 16:05:10 but tell me what needs to be done and I will do the needful 16:06:15 A remined to everyone to add any pitches you'd like to do for long term ideas, and to register any major working sessions that are needed to complete work in this cycle. 16:06:47 Any questions or concerns related to the mid cycle? 16:06:50 I've put up a few restaurants, if anyone else has some suggestions add them on 16:07:25 The steak place isn't high end but it's nearby, budget friendly and I know they can do large groups 16:07:25 thanks spotz 16:07:26 awesome, thanks spotz 16:07:28 o/ 16:07:50 it looks like we have a spot for every night we're there :p 16:08:30 ok, moving on 16:08:33 logan- ping? 16:08:36 #topic Removal of venv_enabled switches (bp/only-install-venvs) 16:08:41 o/ 16:09:02 We discussed the effects and you mentioned you'd look into how it affects your environment. 16:09:13 Do you have an update, any thoughts or questions? 16:10:26 sorry, have not done much work on that since last week. have to wrap mitaka upgrade before vacation next week. I will have to circle back on it in August. 16:10:41 ok, no worries 16:10:47 I guess there is time. 16:11:00 moving on 16:11:03 #topic Name for tests repo 16:11:25 Alright, we discussed implementing a testing repo based on andymccr's work - but we haven't decided on a name 16:11:40 my suggestion was simply 'openstack-ansible-tests' 16:11:47 any objections to that? 16:11:59 odyssey4me: ++ 16:12:02 jmccrory automagically cloudnull d34dh0r53 stevelle mattt hughsaunders andymccr mhayden ^ 16:12:06 jmccrory_away ^ 16:12:14 no objection 16:12:22 no objection 16:12:39 ok, I'll go ahead and get that done 16:12:43 no objection 16:13:14 I still think we should use as much as possible these tests in tree, but as a separate repo I don't have an objection 16:13:25 but that's another conversation 16:13:40 evrardjp sure - I think this just gives us some freedom to experiment more while also reducing duplicated workload 16:13:47 ok, I'll action that after the meeting 16:13:51 next up 16:13:53 #topic Project Mascot 16:14:00 #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/099046.html 16:14:06 #link http://www.openstack.org/project-mascots 16:14:31 The short of it is that we've been asked to identify an animal mascot which represents our project. 16:14:50 honeybadger? 16:14:59 ^ +1000 16:15:00 a big hp logo. Parce que openstack-ansible -> OA -> On board administrator (HP) 16:15:01 heh, prometheanfire that's exactly what I thought of :) 16:15:07 I love it too 16:15:13 Mellivora capensis 16:15:28 I believe Ansible team uses the “Ansibull” 16:15:36 yup 16:15:41 A bull everywhere 16:15:45 or a duck-billed platypus 16:15:50 but the honeybadger has the same colors 16:15:51 AND 16:15:58 it can beat the hell out of the cow 16:16:00 https://gist.githubusercontent.com/jpetazzo/bde04c07137b9e122c07/raw/6170e286c2c24121da23b0a4d56c4327e22d55b9/ansibull.png 16:16:16 lol, looks like a cow from hell that one 16:16:21 anyway 16:17:22 The mascot must be generally identifiable for a global audience. 16:17:35 I'm not sure we can use the cow 16:17:35 Well I vote for a bull 16:17:39 https://pbs.twimg.com/media/CMmZ8tkUEAA3D93.jpg 16:17:49 because it's probably already the brand for ansible 16:17:54 yeah that would be the only concern 16:17:58 right, so I think a duck-billed-platypus is perhaps a little difficult to make easily identifiable... so a bull or honeybadger. 16:18:12 we could use a similar animal - e.g. buffalo or something. 16:18:21 "You can select a mascot from the natural world: animals, plants, fish, birds, or natural features such as a mountain or waterfall." 16:18:22 why not a mix of both, like having a honey badger on top of the bull 16:18:22 i think a honeybadger, whilst humourous, sends the wrong message :P 16:18:26 how does one differentiate a badger from a honeybadger? they dont 16:18:27 or something like a mix 16:18:35 badger might be as close as you get 16:18:49 what about a landmark? 16:19:10 rules say not specific places iirc 16:19:32 i.e. not Niagara Falls but a waterfall is ok 16:19:52 buffalo 16:19:53 I'm kinda liking a buffalo. 16:20:02 It relates to a cow, but is not a cow. 16:20:17 how about a gnu 16:20:49 magestic creatures 16:20:50 cici n'est pas une vache 16:20:53 buffolo = bison ? 16:21:01 gnu's taken 16:21:02 rromans: "ceci" 16:21:06 :D 16:21:08 so I'm thinking an African buffalo 16:21:08 s\buffolo\buffalo\g 16:21:12 evrardjp: apologies :p 16:21:17 ie http://www.32battalion.net/African%20Buffalo2a.gif 16:21:18 just fyi 16:21:21 bison is a rather different thing from buffalo 16:21:28 it's distinctive 16:21:41 odyssey4me: So a cape buffalo 16:22:03 why not writing on etherpad our options 16:22:20 then we give +1s, and the 5 with the most +1 will be submitted 16:22:25 we must do 3-5 choices 16:22:26 ya 16:22:36 concordant voting? 16:22:46 condorcet 16:23:07 we don't need a one to one winner 16:23:11 we don't care :p 16:23:38 ok, we need to move on and don't have to decide today 16:23:57 I'll pop out an email to the ML and ask that everyone make a suggestion that's appropriate. 16:25:06 #topic Release Planning and Decisions 16:25:18 as soon as we are working with clouds . closes bull to clouds. i think it is yak 16:25:34 FYI The kilo, icehouse and juno branches are tagged eol and deleted 16:25:51 so Kilo is, finally, EOL 16:26:07 Does anyone know of any blockers for a release of Liberty/Mitaka today? 16:26:38 Today is also the Newton-2 deadline for all services, so I'll bump the master branch SHA's again. 16:27:29 ok, I'll take that as nothing. 16:27:39 #Open Discussion 16:27:46 #topic Open Discussion 16:28:04 Right, so any questions or updates in general with regards to Blueprint work or anything else? 16:28:08 I'm working on my lxd patch set today. I will be pushing the WIP work later today 16:28:26 cool 16:28:29 michaelgugino Excellent. :) 16:28:42 evrardjp how's the Liberty->Mitaka upgrade work going? 16:28:52 logan- What's your experience been there? Found any glaring issues? 16:28:58 I'm not sure if I'll be attending the mid cycle, but it looks like I just might be able to. 16:29:12 really smooth actually. 16:29:25 logan- did you make use of the upgrade scripts/plays at all? 16:29:35 only one minor snag in the memcached clearing and the patch to fix that merged last week 16:29:40 yep 16:29:46 there are still a few quirks 16:29:47 Didn’t get much feedback on the spec for https://blueprints.launchpad.net/openstack-ansible/+spec/multi-rabbitmq-clusters Would appreciate folks chiming in with feedback if they have it 16:30:15 like the agents double reported - the best way for now is cloudnull's way (delete) 16:30:16 #link https://blueprints.launchpad.net/openstack-ansible/+spec/multi-rabbitmq-clusters 16:30:27 one other thing i saw was some quirkiness in the rabbitmq upgrade that seemed to be related to the hostname switch over, but i haven't been able to reproduce it 16:30:36 I'll follow that to use openstack cli's to disable them - that would be an alternative approach 16:30:49 automagically: do you mean multiple clusters to spread the queues around? 16:30:49 yeah double agents happen 16:31:16 We are looking to have neutron use its own cluster and all other services share another cluster 16:31:31 logan-: I'm trying different approaches, to find the best one 16:31:49 then I'll work with vnogin on the quantification of downtime for upgrades 16:31:55 during* 16:31:59 evrardjp did that patch ever merge to add the thing that wipes the old agent names 16:32:05 Not entirely sure its necessary, but we are planning on doing some 300+ compute host testing and want some flexibility to run addl rabbit clusters if perf results suggest it would help 16:32:07 nope it didn't odyssey4me 16:32:20 don't some of the services still require database work to wipe old agents 16:32:30 like cinder or something I think 16:32:34 no api calls for it 16:32:38 logan-: cinder, heat, nova, neutron 16:32:47 evrardjp we should probably let it through because it's *a* solution that works... if a better one comes along we can use it 16:33:13 #link https://review.openstack.org/312274 16:33:16 deleting is really something I'd like to avoid, but it's the best we've got 16:33:29 they could be disabled instead 16:33:35 that's my point 16:33:46 I want to work on disabling them instead 16:33:51 logan- please take a peek at that and provide suggestions for options 16:33:58 or at least let the choice 16:34:26 sure. will do. personally i like deleting them because it is not very impactful, and it is still a lot of unnecessary clutter if they are disabled 16:34:31 evrardjp please provide suggestions in the review - we need to get beyond limbo where the upgrade process is now 16:34:42 automagically: I think that's a novel idea, but it's starting to seem like these types of options and features are adding a great deal to the complexity of the project. Is it a supported use case with other projects? 16:35:00 perhaps we should provide the option of deleting or disabling, and disable by default but allow a var to change that 16:35:27 michaelgugino: Which other projects? 16:36:16 odyssey4me: agreed 16:36:22 I wrote it in the bug 16:36:36 michaelgugino it's an option which doesn't take much change to implement - seeing as every service already has their own vhost the rest of the work is largely to ensure that we're doing the right namespacing discipline and we're not tied to the inventory groups 16:36:43 odyssey4me: https://bugs.launchpad.net/openstack-ansible/+bug/1577245 16:36:43 Launchpad bug 1577245 in openstack-ansible "Duplicate services seen in upgrade from 12.0.10 to 13.0.1" [High,In progress] - Assigned to Jean-Philippe Evrard (jean-philippe-evrard) 16:37:03 evrardjp I think you could safely adjust the patch set. cloudnull has moved on :p 16:37:19 sure, I will, but I'm still testing all of this 16:37:54 by other projects, is this something that nova or neutron, or any other openstack projects are doing or suggesting? Is it a covered use case somewhere? I definitely think it has merits in any case, just curious 16:37:57 configurable group names are nice. ceph-ansible is heavy on that and it is nice to have the playbooks assumptions about the inventory to be customizable 16:38:54 michaelgugino the projects themselves work mostly in isolation 16:39:10 michaelgugino Where you may wish to discuss this sort of thing is in the large deployments working group. 16:39:10 michaelgugino: I’ve not seen it suggested by those projects yet. The general community recommendation for compute host scale 200+ seems to be to try zeromq in place of rabbit, but the oslo.messaging zmq drivers have some bugs yet 16:39:54 LDT seems pretty centered around cells v1 currently, which we’re not looking to try out just yet 16:40:11 #action odyssey4me to mail the ML about the mascots 16:40:12 yeah, not sure if other openstack deployers are doing that particular thing but having configurable group names in plays/roles has favorable parallels with other ansible projects imo 16:40:51 michaelgugino: All that said, I’m making my best efforts not to overly complicate the roles/plays to add this possibility. I welcome reviews on https://review.openstack.org/#/q/topic:bp/multi-rabbitmq-clusters if you all think that the changes are introducing too much complexity 16:41:08 oh yes, I almost forgot 16:41:12 #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/099128.html 16:41:21 Welcome evrardjp to the OSA core team 16:41:27 :) 16:41:34 :) 16:41:36 I'll do the formal group add after the meeting. 16:41:37 :D 16:41:39 automagically does this change implement the entire bp? 16:42:00 logan-: Nope. I expect one or 2 more 16:42:00 I'll take a look. Doesn't look like a large code change at all 16:42:05 thank you all 16:42:13 thanks to you evrardjp! 16:42:25 yes, thanks to you evrardjp ! 16:42:37 logan- and michaelgugino - This is strongly related to that blueprint https://review.openstack.org/#/c/341296/ 16:42:39 awesome evrardjp 16:42:44 I'll continue to be myself, sorry to annonce you that :p 16:43:15 #info evrardjp has been successfully voted in as an OpenStack-Ansible core team member 16:45:28 ok, it look slike we're done for today 16:45:33 thanks to everyone for making the time 16:45:51 #endmeeting