16:00:30 <b3rnard0> #startmeeting OpenStack Ansible Meeting
16:00:31 <openstack> Meeting started Thu Mar 12 16:00:30 2015 UTC and is due to finish in 60 minutes.  The chair is b3rnard0. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:35 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:00:41 <b3rnard0> #topic Agenda & rollcall
16:00:53 <b3rnard0> #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
16:01:05 <b3rnard0> hello
16:01:09 <daneyon_> hi
16:01:21 <stevelle> hello
16:01:28 <sdake> o/
16:01:36 <sigmavirus24> hello
16:02:09 <cloudnull> damn. DST has me all jacked up. . .
16:02:11 <alextricity> hey :)
16:02:24 <cloudnull> hows it
16:02:32 <alextricity> it good
16:02:40 <daneyon_> DST usually gives me a 1 week hangover
16:02:48 <sdake> cloudnull no dst in arizona - recommend moving ;-)
16:02:51 <Apsu> Roll Call, signing in
16:03:02 <cloudnull> yea DST is a mess.
16:03:06 <cloudnull> UTC for the win
16:03:12 <cloudnull> present
16:03:16 <b3rnard0> presente
16:03:17 <rackertom> o/
16:03:21 <Apsu> presentah
16:03:37 <b3rnard0> #topic Review action items from last week
16:03:38 <BjoernT> lol, we all should get rid of dst
16:03:44 <cloudnull> +9000
16:03:55 <cloudnull> cloudnull continue pinging jhesketh about creating a separate repo and other things <- yes should be in review today
16:04:22 <cloudnull> next: odyssey4me Solicit feedback from the mailing list as to whether os package management should be part of the project?
16:04:22 <b3rnard0> #info cloudnull continue pinging jhesketh about creating a separate repo and other things <- yes should be in review today
16:05:06 <b3rnard0> don't see jesse. next!
16:05:13 <cloudnull> odyssey4me
16:05:39 <odyssey4me> o/
16:05:40 <cloudnull> next: odyssey4me Solicit feedback from the mailing list as to whether os package management should be part of the project?
16:05:45 <cloudnull> :)
16:06:15 <odyssey4me> as I recall we agreed to wait until the 'manifesto' was compiled and agreed to before we went back to that
16:06:38 <cloudnull> okiedokie.
16:06:53 <cloudnull> b3rnard0 carry that.
16:06:57 <b3rnard0> i'll keep that one open
16:06:59 <cloudnull> next: git-harry help odyssey4me on blueprint https://blueprints.launchpad.net/openstack-ansible/+spec/tunable-openstack-configuration
16:07:04 <palendae> Maybe with the manifesto note
16:07:04 <b3rnard0> #action odyssey4me Solicit feedback from the mailing list as to whether os package management should be part of the project?
16:07:11 <odyssey4me> I would suggest that we take it off the agenda, actually
16:07:56 <b3rnard0> odyssey4me: your action item or the manifesto?
16:08:02 <odyssey4me> my action item
16:08:25 <odyssey4me> the manifesto needs to happen first, before we discuss ancillary items that fit into the grey area
16:08:29 <b3rnard0> k
16:08:34 <Apsu> One does not simply not manifesto.
16:08:52 <Apsu> First rule of manifesto club: write one.
16:09:10 <sdake> which action item - the os package management?
16:09:43 <Apsu> Soliciting feedback from the mailing list.
16:09:48 <cloudnull> sdake its a topic about specific package pinning as it pertains to the OS
16:09:54 <sdake> oh right
16:09:59 <sdake> im familiar with that blueprint nm then :)
16:10:22 <cloudnull> so "git-harry help odyssey4me on blueprint https://blueprints.launchpad.net/openstack-ansible/+spec/tunable-openstack-configuration" <- what say you git-harry and odyssey4me
16:10:40 <odyssey4me> ah, so I've updated the blueprint for that
16:11:00 <odyssey4me> I'm working on putting together a PoC using one of the roles to test the concept for review.
16:11:22 <cloudnull> so i wanted to chat about that a bit.
16:11:26 <odyssey4me> I've discovered a way to do selective merging which I think will work quite nicely for our needs.
16:11:42 <cloudnull> i know that git-harry  has a review regarding the testing of hash merging in ansible
16:11:53 <daneyon_> odyssey4me the #link https://blueprints.launchpad.net/openstack-ansible/+spec/tunable-openstack-configuration seems a lot like what tripleo uses for config file mgt.
16:12:04 <odyssey4me> yeah, that's a comparitive WIP so that we can review both options to compare
16:12:24 <b3rnard0> #info odyssey4me I'm working on putting together a PoC using one of the roles to test the concept for review. related to https://blueprints.launchpad.net/openstack-ansible/+spec/tunable-openstack-configuration
16:12:29 <cloudnull> but we may be able to do something similar to whats spec'd here for config diff https://blueprints.launchpad.net/openstack-ansible/+spec/dynamically-manage-policy.json
16:12:41 <git-harry> cloudnull: so it doesn't break the check with hash_behaviour = merge
16:12:42 <cloudnull> without implementing hash merging in ansible
16:13:09 <cloudnull> yea it shouldn't break most of our data structures are lists and strings
16:13:30 <stevelle> I had some concerns about upgrades to configurations that contain lists
16:13:37 <cloudnull> but im kinda against the idea of hash merging as it adds additional "smoke and mirrors" to the deployment process
16:13:50 <stevelle> such as middleware lists
16:14:00 <git-harry> Not really, the vars just have to be considered differently
16:14:15 <Apsu> We went down this road before, when we did the first early round of playbook/role variable reorganization and layout redesign.
16:14:21 <git-harry> and if we don't currently have any affected by the change it's not an issue
16:14:27 <Apsu> Because it was difficult to follow or figure out variable priorities and scopes.
16:14:30 <cloudnull> git-harry right, but that specifically goes against stated ansible best practices
16:15:00 <odyssey4me> my concern with a blanket ansible hash merge is that it affects all plays, including any others a deployer may add to the base we're providing... this is why I prefer a selective merge
16:15:01 <git-harry> cloudnull: yes, but it's still configurable
16:15:04 <Apsu> Hash merging with multiple data sources merged at different scopes sounds like a great way to get back in that position.
16:15:41 <cloudnull> git-harry i think configurable comes at a cost of not adhering to best practices
16:15:41 <Apsu> I for one would much prefer a more transparent strategy, even if it's dumber, has more steps, and requires more effort to design flexibly.
16:16:25 <git-harry> best practise is no more that a guide
16:16:55 <cloudnull> this is true
16:17:13 <cloudnull> but its a well stated guide
16:17:31 <b3rnard0> do we want to get through the rest of the action items?
16:17:43 <odyssey4me> stevelle the basic view that I'm aiming for is that we don't set anything in a conf file if that's the value already set in the code as a default... we only implement the bare minimum we need to put in for the system to work, and we only add stuff that we consider a best practise
16:17:52 <Apsu> I don't think anyone's suggesting that the best practices are commandments from on high. However, they are expectations that others who interact with us will have. And if we don't adhere to them, we're increasing the cost of participating in our project.
16:17:56 <odyssey4me> anything else a deployer wants to add, they can do in the tunables
16:17:59 <cloudnull> as Apsu said in early icehouse we had a similar system which was abandoned due to multiple scopes
16:18:15 <Apsu> Plus our own cost of understanding our code.
16:18:19 <Apsu> ^
16:18:59 <odyssey4me> agreed Apsu cloudnull but the method I'm proposing actually simplifies that dramatically - the icehouse method was implementing too much
16:18:59 <stevelle> odyssey4me: middlewares are particularly tricky as they would include extensions that specific deployments will want, but the defaults have been a bit volatile between releases
16:19:20 <Apsu> odyssey4me: Well then we'll dig into it and see what we can all agree to.
16:19:52 <cloudnull> just to state my position, if its similar to the icehouse method and implements hash merging then I'm kind of against it.
16:19:56 <odyssey4me> so for now, we're working on a PoC to review - I just haven't had much time to get it done
16:20:04 <cloudnull> but ill wait and see from the PoC
16:20:23 <cloudnull> next: BjoernT to help palendae on apt pinning
16:20:37 <palendae> Pretty sure that was BjoernT and odyssey4me
16:21:00 <odyssey4me> ah yes, that discussion has been had
16:21:11 <odyssey4me> whether that becomes part of the project goes back to the manifesto
16:21:19 <cloudnull> ah , thanks for the superb note taking b3rnard0 :)
16:21:25 <sdake> middleware does what?
16:21:32 <sdake> (re naifesto)
16:21:47 <sdake> nano-festo :)
16:21:53 <cloudnull> hahah
16:22:06 <palendae> cloudnull: Part of that was my fault for doing some networking cross-chatter during the meeting
16:22:11 <sdake> would that maintain the ha state of the deployment?
16:22:18 <b3rnard0> #info odyssey4me: whether that becomes part of the project goes back to the manifesto
16:22:25 <cloudnull> palendae dont take blame from b3rnard0
16:22:26 <b3rnard0> palendae: thanks for making me look bad
16:22:37 <Apsu> +1
16:22:38 <palendae> wut
16:22:42 <palendae> You do that yourself
16:22:51 <Apsu> +2, approved
16:22:56 <rackertom> We're a team. We do it to each other.
16:22:58 <cloudnull> next: BjoernT to help palendae on networks
16:23:28 <odyssey4me> we have some success: https://review.openstack.org/163544
16:23:50 <b3rnard0> #info odyssey4me: we have some success: https://review.openstack.org/163544
16:23:59 <odyssey4me> next steps would be to get that (and any accompanying fixes) backported
16:24:02 <cloudnull> sounds good.
16:24:03 <palendae> Ok, that one - Bjoern and I have had some small discussions via email to look at different implenmentations, but I was mostly focused on gating this last week
16:24:07 <BjoernT> Yes he did get my script what we do, but I think it has nothing to do with aio or so
16:24:08 <odyssey4me> thanks to palendae for getting that done :)
16:24:39 <cloudnull> next:  cloudnull to create osad project manifesto as public etherpad and solicit feedback from the ML
16:24:46 <palendae> BjoernT: Yeah, I don't think that script is applicable to AIOs
16:25:29 <odyssey4me> hang on, palendae BjoernT you guys are discussing https://blueprints.launchpad.net/openstack-ansible/+spec/improved-network-generation are you?
16:25:35 <cloudnull> I've created a rough draft and I need to add some other bits post a few discussions i've had with some folks and I will have it on an etherpad and on the ML later today.
16:25:59 <palendae> odyssey4me: I was looking at what BjoernT has created for his environments to see if the blueprint would be of use to him
16:26:08 <cloudnull> #topic Blueprints
16:26:24 <b3rnard0> #chair cloudnull
16:26:24 <openstack> Current chairs: b3rnard0 cloudnull
16:26:26 <cloudnull> #topic Blueprints
16:26:36 <cloudnull> lets go right into that .
16:27:07 <b3rnard0> #info cloudnull: I've created a rough draft and I need to add some other bits post a few discussions i've had with some folks and I will have it on an etherpad and on the ML later today.
16:27:23 <cloudnull> back to > https://blueprints.launchpad.net/openstack-ansible/+spec/improved-network-generation
16:28:19 <cloudnull> palendae do we think we have something that we can work on that can help facilitate networking hosts configurations that can be put together within a poc?
16:28:29 <b3rnard0> #link https://blueprints.launchpad.net/openstack-ansible/+spec/improved-network-generation
16:28:42 <palendae> cloudnull: Right now I'm not quite there, again, gating. Maybe I can look at that during the hackathon
16:28:48 <BjoernT> Is this print targeted for aio?
16:29:05 <Apsu> I should probably mention that we have network generation Ansible written and in-use for our dev Jenkins jobs.
16:29:05 <palendae> BjoernT: Not necessarily
16:29:14 <cloudnull> is that something that, with the help from BjoernT, can be worked on?
16:29:18 <Apsu> So we should definitely compare.
16:29:25 <palendae> Apsu: You should, and IMO, I think we should be using an upstream one
16:29:26 <cloudnull> Apsu BjoernT palendae
16:29:27 <Apsu> And perhaps Jenkins is a good place to test the galaxy bits
16:29:42 <palendae> Whether we move ours out or use debops's
16:29:46 <Apsu> yeah
16:30:38 <palendae> Apsu: One motivation was that we had not just the Ansible jenkins stuff
16:30:41 <odyssey4me> while I acknowledge that there is value in having this - I don't feel that this belongs in-repo for os-ansible-deployment - this comes back to the manifesto
16:30:55 <palendae> But another in-branch one in os-a-d, too
16:30:59 <Apsu> odyssey4me: I tend to agree.
16:31:03 <Apsu> palendae: Yeah
16:31:15 <Apsu> It's provisioning, not deployment per se.
16:31:16 <odyssey4me> I do think there's value in having a PoC done - and perhaps some sort of documentation guide on how one could use it.
16:31:18 <palendae> odyssey4me: That's fair. It may just be a thing to test
16:31:25 <BjoernT> As I said, in ops we just roll out templates for all the bridges. Having the need of configuring each interfaces inside the rpc_user_config is actually too time consuming for us. That's why I wrote this tiny script which just enumerates through the hosts and just assigns a host ip to each bridge
16:31:38 <palendae> Yeah, that's another reason, IMO, having an upstream ansible galaxy role would be good
16:31:50 <odyssey4me> palendae agreed
16:32:00 <palendae> BjoernT: Fair point. I'll try to talk to you a little bit more offline this afternoon. Your script seems to solve your problem well
16:32:08 <BjoernT> yeah
16:32:37 <cloudnull> ok. so manifesto coming soon and this BP may be mancdaz'd post that release .
16:32:47 <palendae> Sure thing
16:32:50 <odyssey4me> in that case, it only makes the case for the removal of any current bits we have in ansible plays/roles that deal with configuring host networking
16:32:53 <mancdaz> wait what?
16:33:08 <mancdaz> what did I not yet do?
16:33:26 <cloudnull> we might pitch a bp
16:33:42 <cloudnull> for which i used the verb, mancdaz'd .
16:33:42 <b3rnard0> mancdaz: thanks for making my action items look bad
16:33:58 <Apsu> haha
16:35:02 <cloudnull> so next BP, odyssey4me can you go into a bit more about what your working on with regard to "https://blueprints.launchpad.net/openstack-ansible/+spec/tunable-openstack-configuration" ? any blockers and can we get someone else to help out on that, if applicable ?
16:35:13 <cloudnull> i know that we talked about it already
16:35:43 <odyssey4me> hmm, at this stage I just need to peg myself down for a few hours to convert the configurations from one method to the other
16:35:53 <cloudnull> ok
16:35:59 <b3rnard0> #link https://blueprints.launchpad.net/openstack-ansible/+spec/tunable-openstack-configuration
16:36:05 <odyssey4me> there are an awful lot of config entries to convert, so it takes time
16:36:13 <odyssey4me> the actual implementation is almost trivial
16:36:35 <odyssey4me> so yeah, I'll try to find some time before next week to get this PoC done
16:36:53 <cloudnull> so along those lines we have "https://blueprints.launchpad.net/openstack-ansible/+spec/dynamically-manage-policy.json"
16:37:15 <cloudnull> this was coming out of alextricity team
16:37:31 <cloudnull> which is looking to create a configurable policy json system
16:37:41 <cloudnull> and doing it via an ansible module
16:37:53 <cloudnull> alextricity is Daniel Curran around ?
16:38:10 <b3rnard0> #link https://blueprints.launchpad.net/openstack-ansible/+spec/dynamically-manage-policy.json
16:38:32 <alextricity> Not in IRC, no. I don't know what there thought was there. Sorry :/
16:38:38 <alextricity> He's in the office though
16:40:17 <cloudnull> From what I understand the intent is, they want to use the base template module and allow users to provide key=value as an additional option to override and or deploy additional config within the default policy file as an option.
16:41:21 <cloudnull> IMO that seems like the most ansible centric approach to deploying extra config on templated files. additionally it seems like a module that could make its way upstream
16:41:58 <cloudnull> i like the intent of the bp and would love to see that in Kilo. but would also like to get some folks to review it whenever possible.
16:42:06 <odyssey4me> sounds good - if the module can get built, then it'd be a far better way of handling tunable configurations
16:42:42 <cloudnull> i believe Daniel Curran is already working on it, but he's not here to ask .
16:43:01 <cloudnull> alextricity can you circle up with him on that whenever possible?
16:43:02 <stevelle> the policy files are a bit different but a similar approach could be applied to configurations
16:43:09 <alextricity> sure
16:43:30 <cloudnull> stevelle for sure. i think that we can handle most of that within the configparse module in the py stdlib .
16:44:00 <cloudnull> the trick will be having that done in transport.
16:44:05 <b3rnard0> #info odyssey4me: sounds good - if the module can get built, then it'd be a far better way of handling tunable configurations
16:44:38 <cloudnull> i'd imagine something like stringIO can make that go , but i've not looked at it quite yet
16:44:57 <Apsu> I have a fair bit of experience with that variety of python
16:45:02 <Apsu> Maybe I could lend a hand
16:45:17 <cloudnull> sure. you want to get together with alextricity ?
16:46:09 <bgmccollum> config files that allow multiple options of the same name, but different values...how will that be accommodated in the dict?
16:46:11 <Apsu> Sure.
16:46:27 <palendae> MultiDict?
16:47:18 <Apsu> There's a few data structure options that can accomodate such.
16:47:18 <bgmccollum> neutron.conf / service_provider as an example
16:48:37 <cloudnull> ok so moving on .
16:48:56 <cloudnull> i'd like to go to "Open discussion"
16:49:14 <b3rnard0> #topic Open discussion
16:49:15 <cloudnull> unless theres something else regarding bugs / reviews
16:49:22 <sdake> quick Q
16:49:25 <palendae> I have a question - do we have a document stating our criteria for core contributors?
16:49:39 <palendae> I found https://wiki.openstack.org/wiki/TC_Membership_Models, but not sure that's generally applicable
16:49:46 <sdake> trying to organize us some design summit space for VC ODS
16:49:50 <b3rnard0> oh, BjoernT wanted us to discuss a bug
16:49:53 <cloudnull> shoot sdake
16:49:56 <sdake> it looks like Monday is our only option, will the core team be present monday?
16:50:03 <BjoernT> yes https://bugs.launchpad.net/openstack-ansible/+bug/1399383
16:50:04 <openstack> Launchpad bug 1399383 in openstack-ansible juno "General SSL support for all public endpoints including spice" [High,Confirmed]
16:50:31 <BjoernT> I added a proposal for have a quick fix around public URLs that those are finally SSL
16:50:31 <palendae> sdake: I think most of the cores will be in San Antonio, TX, not sure if available
16:50:39 <mattt> palendae: vancouver summit
16:50:43 <cloudnull> i will be
16:50:44 <palendae> Next week?
16:50:49 <palendae> mattt: ^
16:50:55 <palendae> Ohhh
16:50:56 <palendae> nm
16:51:00 <sdake> the monday of VC ODS palendae?
16:51:04 <palendae> My bad :)
16:51:09 <sdake> I think May 15th
16:51:16 <palendae> sdake: Yeah, my mistake
16:51:20 <palendae> Thought you meant next week
16:51:29 <sdake> that would be a bit short notice ;)
16:51:34 <mattt> sdake: we haven't locked down travel plans but i can't see people not being there monday if they are going to attend
16:51:37 <andymccr> we're highly agile ;P
16:52:04 <sdake> once a manager said "You need to be in china in 2 days - go"
16:52:05 <b3rnard0> yeah, last time i checked we were agile 1.78
16:52:16 <sdake> figuring out a visa was - an expensive expensive challenge
16:52:50 <sdake> ok thanks that was all I had :)
16:53:08 <cloudnull> sweet! thanks sdake
16:53:15 <sdake> no guarantees yet
16:54:33 <BjoernT> yes https://bugs.launchpad.net/openstack-ansible/+bug/1399383
16:54:34 <openstack> Launchpad bug 1399383 in openstack-ansible juno "General SSL support for all public endpoints including spice" [High,Confirmed]
16:54:41 <BjoernT> ^^ back to real stuff
16:54:42 <BjoernT> :-)
16:55:15 <BjoernT> We need to get some traction around SSL and novnc .... and start tackling those bugs
16:55:38 <stevelle> I feel like this may need a blueprint under our guidelines due to number of moving parts
16:56:56 <BjoernT> maybe but fixing the public endpoints, where we need ssl shouldn't be that difficult. I change the endpoints manually now
16:57:23 <odyssey4me> it's not going to be that simple
16:57:45 <BjoernT> If we assume ssl offloading on the F5 yes, what else ?
16:57:57 <odyssey4me> and from experience I know that implementing SSL and trying to direct internal clients to internal endpoints (non SSL) ends up finding pretty obscure bugs in the clients
16:58:15 <odyssey4me> BjoernT the project doesn't assume SSL offloading - it can't
16:58:26 <Apsu> ^ that last part is the key point here
16:58:37 <Apsu> We can't assume an F5, or SSL offloading. But
16:58:39 <odyssey4me> rax may, but os-ansible-deployment needs to consider the approach more broadly
16:58:44 <BjoernT> the whole design is build on F5
16:58:46 <Apsu> That doesn't mean we can't allow for the configuration flexibility.
16:58:49 <Apsu> BjoernT: No it's not.
16:58:57 <Apsu> The RAX *product* is.
16:59:08 <Apsu> OS-A-D the project is not.
16:59:24 <Apsu> But I still agree we need to be able to set the endpoints more flexibly.
16:59:32 <BjoernT> well the project doesn't even include a load balancing component ....
16:59:34 <Apsu> That part is reasonable, an easy win, and solves our product deployment needs.
16:59:39 <odyssey4me> I would recommend that a workaround be used for now, unless someone steps up to work on this soon.
16:59:54 <cloudnull> so we're out of time.
17:00:10 <cloudnull> lets bring this convo into the channel
17:00:10 <b3rnard0> BjoernT: we need to continue discussing this at the bug triage
17:00:20 <palendae> b3rnard0: Or in #openstack-ansible
17:00:27 <cloudnull> lets do it today if you guys have time.
17:00:28 <b3rnard0> yeah
17:00:29 <Apsu> Moving to #o-a
17:00:30 <palendae> No need to wait 4 days
17:00:31 <b3rnard0> #endmeeting