15:59:56 #startmeeting OpenStack-Ansible 15:59:58 Meeting started Thu Jun 2 15:59:56 2016 UTC and is due to finish in 60 minutes. The chair is mhayden. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:59:59 mhayden: HERE 16:00:02 The meeting name has been set to 'openstack_ansible' 16:00:16 #topic Rollcall & agenda 16:00:19 o/ 16:00:22 \o 16:00:27 \o/ 16:00:35 in case anyone needs a link, the agenda is here -> https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting 16:00:44 o/ 16:00:45 o/ 16:00:48 o/ 16:00:52 o/ 16:00:56 o/ 16:01:09 𝘩𝘰𝘸𝘥𝘺 16:01:28 yo 16:01:34 o/ 16:01:43 Hello 16:02:25 * mhayden gives it one more minute 16:02:49 o/ 16:03:29 okay, so let's do the thing :) 16:03:33 #topic Review action items 16:03:39 \o/ 16:03:40 #link http://eavesdrop.openstack.org/meetings/openstack_ansible/2016/openstack_ansible.2016-05-26-16.00.html 16:03:53 automagically: you were going to think about potential dates for hosting the midcycle? 16:04:29 and odyssey4me was going to talk about possibly hosting at Rackspace's HQ in San Antonio, along with dates 16:04:36 so i guess this is a general midcycle discussion here :) 16:04:52 mhayden my bad, I haven't managed to do the queries for dates and such 16:05:02 Yes, we could host 60 from 8/29-31 if thats of interest 16:05:21 I marked it as an action item for me in the absense of other volunteers - if anyone wants to take over that aciton item I'd be happy to release it 16:05:39 I have the space reserved temporarily, and would like to know if we want to use it in the next two weeks 16:05:46 odyssey4me: we had the security midcycle here last year and may have it here again -- i can ask someone who is working on that one 16:05:54 automagically wow, 60 is a lot... we'd likely only need room for 10-20, max 30 at a push 16:06:02 automagically: and yours is in Pennsylvania? 16:06:15 Yes, downtown Phildelphia in the Comcast HQ 16:06:32 #info automagically has room for 60 people August 29-31 in Philadelphia at Comcast's HQ 16:06:35 it would be nice to have it hosted somewhere that's not SAT :) 16:06:46 for a change 16:06:47 we are having some wild weather as of late ... 16:07:12 should we get some Rackspace options as well and decide on this next week? 16:08:02 well, at the very least each of the core team members and any others who want to attend will need to validate whether they can get budget for a trip 16:08:07 jmccrory automagically cloudnull d34dh0r53 stevelle mattt hughsaunders andymccr mhayden ^ 16:08:11 quite true 16:08:56 so we have a proposed date and venue, so now we get to work on figuring out who can make it and whether that'll be suitable 16:08:58 so it sounds like two actions: 1) get options on space at Rackspace and 2) determine who could travel to Philadelphia and/or San Antonio 16:09:08 yes 16:09:20 #action mhayden and odyssey4me to find out about Rackspace hosting options for midcycles 16:09:22 are we happy with a three day format? 16:09:23 mhayden automagically: ++ 16:09:29 i think 3 days is good. 16:09:36 I’m good with 2 days 16:09:36 #action All community members should determine if they can get budget to travel to San Antonio or Philadelphia 16:09:41 3 days rather 16:09:42 +1 on 3 days 16:09:45 I think i can swing a philly trip 16:09:46 +1 on 3 16:09:55 sounds like we're in agreement on 3 days? any objections? 16:10:04 +1 on 3 and ! SAT 16:10:13 nope, looks good to me - probably worth noting as an info item 16:10:20 #agreed OSA midcycle should be 3 days long 16:10:27 okay, are we good with this topic for now? 16:10:37 AFK for a few 16:10:50 automagically: thanks for checking on space at Comcast! :) 16:10:58 thanks indeed 16:11:00 next item is andymccr's repository -> https://github.com/andymcc/openstack-ansible-testing-core 16:11:15 the action from last week was to review it and ideally test 16:11:42 I didn't test it :/ 16:11:46 I read it 16:11:52 i've looked over it but haven't tested it quite yet 16:11:53 looks a good start 16:12:04 #link https://github.com/andymcc/openstack-ansible-testing-core 16:12:20 i tested it! :D but evrardjp had some additional ideas to try - would be good to get more feedback and ideas to improve/change/scrap 16:12:30 would someone like to volunteer to give it a test (besides andymccr) :) 16:12:31 I'm somewhat uncomfortable with the test vars being in a different repo for each role 16:12:38 that seems like a maintenance headache 16:12:45 I unfortunately haven't had the chance to give it a thorough look through. 16:13:12 stevelle: the vars are the same for each repo - the problem mostly is that we are duplicating the same sets of vars for each repo that uses a set role (e.g. keystone is common, or galera) 16:13:16 stevelle as I understood it from discussions with andymccr the test vars there are just a base which can be overridden by the role tests 16:13:19 this is a first iteration, I guess we could indeed have a more integrated view? 16:13:25 but yeh they can be overridden. 16:13:38 i tested the glance role, worked well. just ran into small issue with clone command of test playbooks in tox.ini 16:14:35 andymccr: my concern is that the test vars are not in the role repo. When the role changes and requires var changes it has an order of operations issue that will cause extra review traffic and challenging coordination of them 16:14:48 so we have the option of doing a full set of transition reviews to switch over to using this method, and trying it out for a while - we can always import the repo later 16:14:51 I fear the same for the tasks 16:14:55 stevelle: thats one of the main benefits though - because the vars are specific to one repo 16:15:10 whereas before if you changed a keystone var (for example) you would have to go into every other repo and change the var there --> 15 changes 16:15:29 * stevelle doesn't think he is being clear 16:16:00 you mean, id have to change the test repo before changing keystone in order to pass it? 16:16:15 you want to set vars in the inventory only in this, this way we can override inside the roles? 16:16:38 andymccr: that is some of the concern yes 16:17:13 back 16:17:20 stevelle: sure i guess its a trade off between that and having to manage 15 repo changes due to 1 change on a common repo. 16:17:35 but if there is a good way to get hte best of both! i'd prefer that. 16:17:40 we already have this coordination issue when we removed db create from the roles into the playbooks, it involves lots of extra steps 16:17:42 I read through it and I like it 16:17:50 I didn’t think I would, but I do. Nice work andymccr 16:18:01 would anyone be able to volunteer to test on it and help andymccr iterate? 16:18:37 fine for me 16:18:43 If we can smooth that one point of friction I would be enthusiastic, other than that friction point this is really good. 16:18:44 lacking time 'though 16:19:06 yeah, I'd ideally like another core at least to spend some quality time testing it out - and as evrardjp has good context with Ansible outside of OSA I think it'd be valuable for him to also test and help iterate 16:19:27 should we get a writeup about this repo along with its purpose out to the ML and ask for volunteers? 16:19:37 that would help me understand the goals 16:19:41 yeah sure odyssey4me I'll help, don't worry :D 16:19:49 That would be good. A specific call out of stevelle concerns would help contextualize 16:19:50 Happy to help with the write-up. IF that's what's needed. 16:20:10 asettle: could you and andymccr work on an email to the ML? 16:20:18 \o/ team ginger on the job 16:20:24 * mhayden chuckles 16:20:32 i'll be out most of next week, but happy to help test as well 16:20:32 Wow I just got massive stink eye from andymccr 16:20:41 ok. will get that done tomorrow 16:20:42 haha ‘team ginger' 16:20:43 #action asettle and andymccr to send out an email to the mailing list about the testing repository 16:20:54 are we good to move on out of action items? 16:20:59 i think so! 16:21:15 andymccr just wants to run from team ginger 16:21:17 asettle requested a little time earlier in the meeting since she needs to leav early, so i'll skip around here a little 16:21:20 #topic OSA Installation Guide restructure 16:21:25 asettle: you're up! 16:21:25 Thanks mhayden 16:21:29 Hey everybody! 16:21:44 As some of you may know, we're focusing our efforts after the summit to rework the installation guide 16:21:56 I've proposed a blueprint, and a subsequent spec with detailed information on how we're goin to do this 16:21:58 * mhayden is really pleased about these efforts :) 16:22:13 I"m working alongside Darren Chan, who was at the summit and many of you met. His IA (information architecture) experience is assisting me in coming up with a new ToC 16:22:21 I'd appreciate a community review of the spec: https://review.openstack.org/#/c/323471/ 16:22:29 #link asettle's spec -> https://review.openstack.org/#/c/323471/ 16:22:31 We're looking to clarify a few points to ensure the community is happy with the output 16:22:48 We need clarification on is whether we are simply documenting installation for a test environment and production environment 16:23:02 And we've had a few conflicting suggestions that we also need to include examples and configs for role based documentation 16:23:15 We're looking to get this spec approved asap, but we want to ensure everyone is on the same page 16:23:18 If this makes sense 16:23:32 The spec is still in WIP stage, but I will be removing that tag shortly and opening it up for full reviews. 16:23:41 I'd like to have this approved within the next two weeks to get started on it 16:23:46 Questions, comments, concerns? 16:23:51 * asettle drops mic 16:23:58 yeah, all agreeing on the end goal is important 16:24:10 thanks for doing this -- it should make it easier for new deployers to get through the manual and use opinionated defaults 16:24:24 My commentary about the role docs is just that as we move a lot of config-specific doc out of the main guide, I want to make sure that it doesn’t just get removed, but rather ends up in the role-specific docs 16:24:33 this is going to be quite disruptive and can be easily misunderstood, so I'd like to ensure we're all agreed on the way it'll look at the end 16:24:33 Very much so. I believe we have so far included everyone's thoughts and opinions from the summit, but please speak up if you feel like something else is required or missing 16:24:33 chapter four of the install guide currently hurts! :) 16:24:35 I’m all for the re-orig 16:24:39 re-org, rather 16:24:44 automagically: yeah absolutely 16:24:54 odyssey4me: yes, definitely. 16:25:03 asettle: Great 16:25:03 Does anyone have any immediate concerns? 16:25:22 none here 16:25:22 none, if all the content is maintained 16:25:26 automagically yeah, I was thinking that step one would quite literally be a lift and shift of chapter 4 into the respective repositories 16:25:32 I'd just echo automagically, making sure anything about roles is kept somewhere 16:25:39 If not, please have a read through and comment. IF you'd prefer to talk directly to me, please just email me at alexandra.settle@rackspace.com 16:25:45 whatever the way it is maintained 16:25:49 sounds good 16:26:05 Will take another read through the proposed spec and add additional comments, but so far, I’m very supportive and happy to help however I can 16:26:09 okay, going back to discussion topics, we've covered the tests repo and the midcycle planning 16:26:13 so we're up to... 16:26:15 palendae and automagically - to answer that properly, I believe there is a plan for it to be moved into a configuration guide, but that's in the future. In the immediate future moving it to the developer docs 16:26:17 #topic Astara 16:26:17 asettle everyone will need edit rights to see the comments and draft bits in https://docs.google.com/document/d/1WdcA7jIp8w1C52pJu4JmympFe8cOvcxi1I2E19Y6XYE/edit 16:26:22 phil_h: you're up 16:26:54 anything new for this week, phil_h? 16:26:54 odyssey4me: I think it's best that that is just open for review at the moment. Otherwise we'll end up with a thousand different voices on a google doc when we should be concentrating our community efforts on the spec 16:26:55 yes, we have a blueprint up and a straw man in an etherpad 16:27:04 https://blueprints.launchpad.net/openstack-ansible/+spec/add-support-for-astara 16:27:11 https://etherpad.openstack.org/p/astara-openstack-ansible 16:27:14 Nice! 16:27:15 Okay, Alex out - tahnks everyone! 16:27:20 thanks, asettle 16:27:29 thanks asettle 16:27:31 this is for adding a "chapter for astara" 16:27:55 We will use PlumGrid as a model 16:28:03 Cool, thanks for the etherpad and blueprint phil_h 16:28:05 would a deployer need to choose Astara *or* neutron's l3 agent? 16:28:06 phil_h: very cool. 16:28:29 I am hoping that they could use astara for the loadbalancer 16:28:41 and neutron l3 or astara for everything 16:28:47 got it 16:29:01 We need some testing on the mixed model 16:29:01 phil_h: what help could you use from the OSA community on your BP/etherpad? 16:29:22 If everyone can have a look and give us feedback 16:29:34 looks like odyssey4me is already on the case :P 16:29:58 thanks, I will have the astara folks on this also 16:30:29 sounds good -- i'd like to compare notes on Astara vs. Octavia for load balancers 16:30:30 +1 for the boolean approach. Mixed referrence L3 + Astara doesn't seem like a good idea (if it's even possible). 16:30:58 #action All to review phil_h's etherpad on Astara and provide comments 16:31:02 cloudnull ++ agreed 16:31:08 The astara folks prefer the boolean approach 16:31:34 Certainly in terms of what we document and recommend it should be a binary approach. If people want to try and mix and match then they're on their own. 16:31:43 mixing sounds scary 16:31:45 We can't afford to stretch the test matrix. 16:32:05 wow, lots of stuff going into the etherpad already 16:32:07 nice 16:32:20 Thanks everyone 16:32:20 anything else on Astara, phil_h ? 16:32:27 not right now 16:32:37 #link phil_h's etherpad for Astara -> https://etherpad.openstack.org/p/astara-openstack-ansible 16:32:48 okay, next up... 16:32:57 #topic Deprecation of pip_lockdown 16:33:00 automagically: you're up! :) 16:33:11 * automagically scrambles to find the starred review 16:33:36 * mhayden plays jeopardy music 16:33:39 :) 16:33:47 #link https://review.openstack.org/#/c/313878/ 16:34:09 That review is what we got proposed following the last meeting 16:34:16 Thanks jmccrory for the quick turn-around on it 16:34:41 I think we just need to get the feedback from odyssey4me resolved 16:34:44 had some thoughts on where to go forward from there 16:35:04 cloudnull: You were missing last week and we though you’d probably have some opinions, now is your chance to weigh in 16:35:13 * automagically hands mic to jmccrory 16:35:23 * cloudnull reading 16:35:31 hard set the lockdown var to true in os playbooks, since pip_links are always to go be defined in group vars 16:36:02 remove pip_lock_down dependency entirely from IRRs and just add the isolated option to pip_options for developer mode 16:36:29 I think https://review.openstack.org/#/c/320216/10/meta/main.yml makes sense if we want to keep the API the same. 16:36:31 I’d like to still test the length of pip_links which would allow a deployer to ignore the internal repo 16:36:45 that way it'll avoid any existing lock down for both independent role use or it's they're deployed as part of integrated release 16:36:53 If we're going to change it, keying off of links makes sense 16:36:58 I agree entirely with the rest of that jmccrory 16:37:08 for the meta, all we need is the role inclusion 16:37:13 as long as the links has a value of >=1 16:37:14 sure length would work then, would be possible for deployment to override and empty it 16:37:14 odyssey4me: ++ 16:37:22 yep jmccrory 16:37:27 it defaults to no lock down, so having the dep on developer mode makes no sense 16:37:43 Consensus reached then it seems 16:37:45 :D 16:38:04 ++ jmccrory typie typie change all the open reviews :) 16:38:12 the only trick here is to cater for automagically's situation where he overrides the links in some builds, so the group_vars are negated 16:38:26 yeah, was only in case someone wanted to set developer mode on a single role while doing an OSA deployment. and that's seems to have happened 16:38:28 I _do_ appreciate being catered to 16:38:35 hah 16:38:42 so we're agree on this one? :) 16:38:49 It seems we are 16:38:49 s/agree/agreed/ :) 16:38:50 we can set that at runtime for a given role 16:38:51 woot 16:38:55 agreed here 16:38:56 jmccrory in that particular case a deployer has other options to negate the lock down 16:38:59 https://bugs.launchpad.net/openstack-ansible/+bug/1585604 16:39:00 Launchpad bug 1585604 in openstack-ansible "horizon_developer_mode does not work" [Undecided,New] 16:39:03 * automagically passes mic back to mhayden 16:39:04 automagically: all good on this topic? 16:39:06 woot 16:39:10 next up... 16:39:17 #topic Support for Xen via libvirt 16:39:20 and antonym is up! 16:39:27 o/ 16:39:34 welcome antonym 16:39:44 how's it going? 16:40:00 was chatting with major a bit yesterday about looking into libvirt and xen and he suggested we mention it here 16:40:21 let's just say that antonym works on a *very* large OpenStack cloud that happens to run on xen :) 16:40:21 good indeed 16:40:26 wanted to see what the thoughts were on adding it as a supported hypervisor to openstack-ansible 16:40:47 Seems like something that might be popular 16:40:50 was probably going to throw together a blueprint if it's something that has interest 16:40:53 since it's just another option in libvirt, it could work well 16:40:55 antonym it should be pretty easy I expect, probably not much more than extending https://github.com/openstack/openstack-ansible-os_nova/blob/master/defaults/main.yml#L93-L126 16:40:57 gate testing could get interesting 16:41:29 odyssey4me: yeah, i had a proof of concept in december in openstack-ansible that built a vm using libvirt, needed to dig into the networking still 16:41:39 but i don't think it should be a major effort 16:41:44 Will this have a larger impact than nova? like a lots of changed due to specific ovs/cinder/glance way of doing things? 16:41:57 just to be informed how it's planned :D 16:42:02 there's some work going in to support powervm too which is extending that and may introduce some more patterns which could be useful 16:42:20 i think it aligns to kvm pretty well right now since it's mostly libvirt 16:42:48 the xen guys have been busy stabilizing it too 16:42:55 cool news 16:43:16 would we need a spec for this work? 16:43:21 i'm on the fence 16:43:23 can’t hurt 16:43:26 anyways just wanted to bring it up, sounds like there is some interest 16:43:35 antonym it would be ideal to have some sort of external CI checks in place to validate that any ongoing work doesn't break xen support, but if that's not possible then it's just going to place more responsibility on anyone using it to test properly before upgrading 16:43:38 antonym: want help building a spec + BP? 16:43:50 mhayden: yeah, i can try and slap one together 16:44:02 yeah, it would be best to put the thoughts into a spec 16:44:03 #action antonym to build a blueprint and spec for Xen+libvirt support 16:44:10 thanks, antonym 16:44:16 odyssey4me: yeah, i'm kinda new on the CI checks but it's something we should look into as well 16:44:18 the powervm spec will be a good one to model from 16:44:26 odyssey4me: cool, i'll take a look at it 16:44:31 mhayden: no prob 16:44:35 many thanks to the IBM folks for coming by and proposing good patches and doing reviews! :) 16:44:48 ++ 16:44:50 indeed 16:44:57 hopefully 16.04 still has some basic xen support :D 16:45:03 antonym: anything else on Xen? 16:45:14 mhayden: nope i'm done :) 16:45:17 sweet 16:45:25 that wraps up the discussion topics... on to... 16:45:32 #topic Release planning and decisions 16:45:35 odyssey4me: you're up! 16:46:09 do we have any blockers for the next tag for Liberty or Mitaka? 16:46:19 * mhayden is not aware of any 16:46:58 * automagically not that I know 16:47:02 as expressed in http://lists.openstack.org/pipermail/openstack-dev/2016-June/096466.html we're waiting for the final kilo-eol tags before we do our own Kilo eol 16:47:26 * mhayden sheds a tear for kilo 16:47:41 I need to request the Newton-1 tags today as well - I'm just trying to finalise a tool to help me simplify my release request process. 16:48:16 ok then 16:48:17 good odyssey4me 16:48:17 does it use ansible? 16:48:31 it's written in perl 16:48:37 :p 16:48:40 #action odyssey4me to request Newton-1 tags, and next tag releases for Liberty & Mitaka 16:49:09 stevelle nope, just python - I'm raging at different opinions about yaml formats 16:49:20 woot 16:49:28 anything else on this odyssey4me? 16:49:29 well, not raging, just trying to make yaml.dump output it the way that the release team wants it 16:49:36 I know that feel 16:49:45 :D 16:49:54 I'll take the problem to the channel. Maybe someone can help. 16:50:02 mhayden no, thanks - all done 16:50:04 do you need help? 16:50:16 okay, we got asettle's update already, so we're on to blueprints! 16:50:19 10 minutes left 16:50:26 #topic Blueprint - Ubuntu 16.04 LTS Support 16:50:33 #link https://etherpad.openstack.org/p/openstack-ansible-newton-ubuntu16-04 16:50:51 lots more strikethroughs there! 16:51:06 I have the gnocchi role in progress right now 16:51:16 pretty close, might submit a review today 16:51:20 my neutron role needs core reviews 16:51:30 its progressing nicely 16:51:34 cent7 support too :) 16:51:37 nova seems to be working locally, I basically just copied and pasted the work from neutron 16:51:40 https://review.openstack.org/#/c/322249/ 16:52:08 it looks like we're actually largely ahead of schedule here 16:52:11 #action Core reviewers can lend a hand on evrardjp's review -> https://review.openstack.org/#/c/322249/ 16:52:18 odyssey4me: don’t jix it 16:52:22 jinx, rather 16:52:25 in the interest of time, i'll keep moving 16:52:38 #topic Blueprint - Install Documentation Update 16:52:39 all we needed to do for Newton-1 was get the vars split out implemented... but we're quite far down the road of getting Xenial working 16:52:48 actually -- i think asettle covered this well 16:53:00 #topic Blueprint - Ansible 2.1 Support 16:53:02 yep, I think we should move to discussion 16:53:10 odyssey4me: you wanna open it up? 16:53:11 considering we have 5 mins left 16:53:17 #topic Open Discussion 16:53:24 I vote 2.1 moves to O cycle 16:53:54 i'd like to thank everyone for helping learn the ways of a core reviewer 16:53:55 would be happy to remove all the non 2.1 supported things for now 16:54:19 nova-lxd driver support will be implemented by my team soon, as soon as I can make them do it 16:54:30 michaelgugino cool :) 16:54:41 yeah cool news michaelgugino 16:54:43 FYI to all https://review.openstack.org/#/q/project:openstack-infra/project-config+branch:master+topic:osa-additional-core-teams 16:55:13 there's another one for the swift role, and I can add any more if anyone wants to propose that we should have more role specific cores 16:55:21 if the discussion is still open, please prepare your opinion on this: https://review.openstack.org/#/c/321582/ 16:55:45 goal is to simplify tox.ini, ansible.cfg ... 16:55:52 I'll also be working on the Watcher project, which has just made it into the big tent. I'll be developing small contribs to that codebase, and acting as a liason between this project and that one 16:55:56 not only for 2.1 16:56:23 They want to have OSA support for watcher, and I am happy to help them/do it 16:56:31 michaelgugino great, I'm happy that someone is - it looks like an interesting one to perhaps instrument into OSA at some point 16:56:32 interesting project 16:57:10 evrardjp I'm not sure that it simplifies anything at all to have the plugins as a role requirement 16:57:29 Very cool michaelgugino 16:57:58 I also need to submit some more openvswitch patches for neutron. Right now, it only supports provider networking AFAIK. I need to patch the config files to support the bridge mappings 16:58:07 br-int and br-ex, for example. 16:58:37 odyssey4me: happy to discuss about your concerns (and everyone's) 16:59:10 ok, we need to clear the room mhayden 16:59:16 sounds good 16:59:18 thanks, everyone! 16:59:19 ty everyone 16:59:21 #endmeeting