16:02:53 <b3rnard0> #startmeeting OpenStack Ansible Meeting
16:02:54 <openstack> Meeting started Thu Mar  5 16:02:53 2015 UTC and is due to finish in 60 minutes.  The chair is b3rnard0. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:57 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:03:15 <b3rnard0> #topic Agenda & rollcall
16:03:22 <odyssey4me> o/ :)
16:03:25 <cloudnull> present
16:03:37 <b3rnard0> #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
16:03:49 <b3rnard0> i be present
16:04:05 <Sam-I-Am> yo
16:04:59 <stevelle> present
16:05:51 <sigmavirus24> o/
16:06:00 <sigmavirus24> << "present"
16:06:28 <b3rnard0> #topic Review action items from last week
16:07:13 <b3rnard0> cloudnull continue pinging jhesketh about creating a separate repo and other things -- updates?
16:07:32 <cloudnull> i pinged , i know what to do, i've not done it because i took time off.
16:07:42 <cloudnull> so i failed.
16:07:44 <cloudnull> :)
16:08:10 <b3rnard0> np. i'll keep it open as an action item
16:08:12 <cloudnull> ill try and get everything in by end of week
16:08:16 <sigmavirus24> we must all do the communal dance of shame in a circle around cloudnull
16:08:24 <cloudnull> hahaha
16:08:35 <odyssey4me> haha!
16:08:43 <b3rnard0> #action cloudnull continue pinging jhesketh about creating a separate repo and other things
16:09:11 <b3rnard0> odyssey4me Solicit feedback from the mailing list as to whether os package management should be part of the project? -- updates?
16:09:44 <odyssey4me> My bad - haven't done it. I'll get it done this evening.
16:10:09 <b3rnard0> k, keeping that one open as well
16:10:22 <odyssey4me> I'll join cloudnull in the walk of shame. :p
16:10:26 <Sam-I-Am> slackers
16:10:28 <b3rnard0> #action odyssey4me Solicit feedback from the mailing list as to whether os package management should be part of the project?
16:10:45 * cloudnull joining the dance of shame
16:10:56 <b3rnard0> git-harry help odyssey4me on blueprint https://blueprints.launchpad.net/openstack-ansible/+spec/tunable-openstack-configuration -- updates
16:10:57 <odyssey4me> I did update the blueprint though. :)
16:11:23 <b3rnard0> don't see mister harry on here. did you received aid from him on this task?
16:12:18 <odyssey4me> No update from me - git-harry did do some investigation, but I think got diverted. We'll have to carry it.
16:12:24 <b3rnard0> k
16:12:36 <b3rnard0> #action git-harry help odyssey4me on blueprint https://blueprints.launchpad.net/openstack-ansible/+spec/tunable-openstack-configuration
16:12:54 <b3rnard0> finally
16:13:11 <git-harry> odyssey4me: has left the building.
16:13:15 <b3rnard0> andymccr to fix https://bugs.launchpad.net/openstack-ansible/+bug/1424808 in 10.1.3 -- updates? i'm assuming this is still in your queue
16:13:16 <sigmavirus24> git-harry: just in time to dodge information
16:13:16 <openstack> Launchpad bug 1424808 in openstack-ansible juno "Add nova configuration options image_cache_manager_interval" [Low,Triaged] - Assigned to Andy McCrae (andrew-mccrae)
16:13:30 <andymccr> b3rnard0: its been fixed/pr'd
16:13:31 <sigmavirus24> b3rnard0: there's an open review for that iirc
16:13:43 <andymccr> i think its not merged yet because we had some issues yesterday but its pending merge
16:13:59 <b3rnard0> andymccr: awesome. at least we got one action item resolved!
16:14:08 <andymccr> just doing my job b3rnard0. just doing my job
16:14:16 * b3rnard0 hands andymccr a beer
16:14:20 <odyssey4me> It merged into master within the last half hour I think.
16:14:33 <odyssey4me> It needs a back port now.
16:14:55 <andymccr> juno backport already merged
16:15:03 <cloudnull> #link: https://review.openstack.org/#/c/159929/
16:15:15 <b3rnard0> we don't have a lot on the agenda today so i'm going straight to the bug we were still triaging this Tuesday. any thoughts, cloudnull?
16:15:25 <cloudnull> ^ merged just a few min ago .
16:15:46 <cloudnull> sounds good. then to bps
16:16:18 <b3rnard0> #topic Bugs
16:16:36 <b3rnard0> #link https://bugs.launchpad.net/openstack-ansible/+bug/1426655
16:16:37 <openstack> Launchpad bug 1426655 in openstack-ansible juno "neutron_agents_container GnuTLS recv error" [Undecided,Incomplete]
16:16:47 <b3rnard0> i think we didn't finish triaging this bug
16:16:59 <cloudnull> looks like it was a transient issue
16:17:12 <Sam-I-Am> darn transients
16:17:21 <BjoernT> right we dropped this bug pretty much
16:17:26 <odyssey4me> Transient or a host issue.
16:17:37 <cloudnull> the guy nexus indicated it was resolved on redeploy?
16:17:53 <odyssey4me> The reporter has pretty much indicated as much.
16:18:37 <cloudnull> so i'd say mark it as invalid and leave it as such . thoughts?
16:18:47 <odyssey4me> Agreed.
16:18:49 <stevelle> +1
16:19:04 <cloudnull> done.
16:19:19 <b3rnard0> #chair cloudnull
16:19:20 <openstack> Current chairs: b3rnard0 cloudnull
16:19:35 <b3rnard0> just in case i cut out as my internet has been spotty
16:19:49 <cloudnull> if there are no other bugs that we want to talk about lets move on to blueprints.
16:20:26 <b3rnard0> #topic Blueprints
16:20:44 <cloudnull> we have 4 open bps that are marked for discussion
16:20:54 <cloudnull> so lets talk about those.
16:20:57 <odyssey4me> We could do with more blueprints. :)
16:20:58 <cloudnull> palendae you around ?
16:21:09 <palendae> cloudnull: yep
16:21:13 <cloudnull> hows https://blueprints.launchpad.net/openstack-ansible/+spec/improved-network-generation
16:21:27 <b3rnard0> #link https://blueprints.launchpad.net/openstack-ansible/+spec/improved-network-generation
16:21:37 <palendae> Stalled for now as I work on gating stuff.
16:22:30 <cloudnull> kk . can some of our cores review and comment on it.  I'll set aside some time today to do the same.
16:22:44 <odyssey4me> Will do.
16:23:07 <palendae> I think the blueprint itself is fine from my POV, but no implementation happening right now
16:23:11 <cloudnull> #link https://blueprints.launchpad.net/openstack-ansible/+spec/apt-package-pinning
16:23:19 <stevelle> palendae: do you have an idea of how complete that role is for our needs today?  80%?
16:23:21 <sdake_> o/
16:23:23 <BjoernT> I actually wrote a script to setup the bridges, I don't see it as critical anymore (network-generation)
16:23:26 <cloudnull> odyssey4me hows that coming a long ?
16:23:41 <b3rnard0> #action odyssey4me cloudnull to provide feedback/review on https://blueprints.launchpad.net/openstack-ansible/+spec/improved-network-generation
16:23:53 <cloudnull> hey sdake_
16:23:54 <palendae> BjoernT: Cool. I'd like to do it still, but good to know
16:23:57 <odyssey4me> Waiting for input. The blueprint wash prayed after last week's discussion.
16:24:08 <sdake_> apologies for being late, off by 1 error :(
16:24:20 <odyssey4me> A standing question is whether this even belongs in the project.
16:24:37 <cloudnull> no worries sdake_ , welcome :)
16:24:43 <odyssey4me> The mission of the project needs clarity.
16:24:43 <Apsu> BjoernT: We've got probably 6 scripts/various plays/approaches by different folks for doing network config. I wrote an Ansible module I was trying to upstream called "interfaces" that would allow reconfiguration of the file, for instance
16:25:00 <Apsu> I think palendae's goal was to pick something as a common point to build from
16:25:05 <palendae> Apsu: Correct
16:25:23 <odyssey4me> Is it focused on deploying openstack, or a full environment which is production ready?
16:25:27 <palendae> Apsu: We nuked the interfaces stuff that was in the repo because it was poorly documented and had a bunch of flaws
16:25:29 <BjoernT> palendae: apsu: We are so "lazy" now, not even wanting to specify the interfaces . So I did automate it based on that each node has a fixed offset
16:26:03 <BjoernT> to specify each interface in jason is even too much, we want to keep the configs the same across all deployments so 172.29.236.51 is infra01, 52 infra02 and so on
16:26:08 <BjoernT> then it's easy to automate
16:26:26 <BjoernT> we can talk about this offline
16:26:31 <cloudnull> so BjoernT can you sync up with palendae  on that
16:26:38 <palendae> Yes please :)
16:26:39 <BjoernT> yepp
16:26:40 <odyssey4me> I'm confused. Are we talking about the network configs blueprint now, or apt pinning?
16:26:49 <palendae> odyssey4me: apt pinning, sorry
16:27:05 <cloudnull> and now back to apt pinning :)
16:27:44 <b3rnard0> #action BjoernT to help palendae on apt pinning
16:27:48 <stevelle> odyssey4me: there may be an "it depends" answer on whether this belongs or not.  It would help gating and lets the project find a tempo that matches the larger OpenStack community, but different groups may want a different solution
16:28:05 <BjoernT> b3rnard0: ok
16:28:12 <odyssey4me> I've come to a conclusion that a deployed can do  very good job of solving this problem without pinning an instead using a frozen apt repo. Less moving parts.
16:28:17 <palendae> b3rnard0: Actually BjoernT will be working with me on networks, we hijacked the discussion
16:28:24 <b3rnard0> lol k
16:28:31 <Sam-I-Am> networks, pinnings, its all the same
16:28:33 <BjoernT> I do apt pinning too, lol
16:28:33 <odyssey4me> *deployer
16:28:38 <b3rnard0> #action BjoernT to help palendae on networks
16:29:15 <palendae> odyssey4me: So are you thinking the deployers are taking responsibilities for freezing the repos?
16:29:28 <palendae> Or providing a repo freezer in place of the pinning?
16:29:43 <git-harry> Do we have anything that defines the scope of this project?
16:29:49 <odyssey4me> Yeah. It makes more sense than burdening the project with keeping track of packages to pin.
16:29:51 <sdake_> palendae in our models, we belive that to be the case
16:30:39 <sdake_> our = kolla project models
16:31:26 <odyssey4me> For RPC specifically I have a solution and am soliciting feedback, but that's outside of this project's remit IMO.
16:31:27 <palendae> sdake_: So deployers responsible for freezing in your model?
16:32:16 <sdake_> palendae ya the service providers or their vendors
16:32:22 <odyssey4me> git-harry: not to my knowledge, and I think we need to define it
16:32:51 <git-harry> odyssey4me: yup, it might short circuit some of these conversations
16:33:01 <mattt> sdake_: my personal opinion is that is the correct approach
16:33:54 <odyssey4me> Perhaps it'd be useful to get some help to facilitate a discussion around it?
16:34:37 <cloudnull> yes that'd be helpful.
16:34:46 <odyssey4me> Someone who has helped put together charters for openstack projects, and is also outside of rax.
16:34:55 <palendae> ^
16:35:02 <odyssey4me> Perhaps ttx can assist or recommend?
16:35:09 <git-harry> ?
16:35:15 <git-harry> Not sure that's what we need
16:35:18 <sdake_> openstack calls it a manifesto
16:35:24 <sdake_> but imo you do that after 6 months of open dev
16:35:26 <git-harry> We just need to define the technical scope of the project
16:35:31 <sdake_> otherwise it shuts out contributors
16:35:36 <BjoernT> I think we from support have a  view on apt pinning, can we talk about it in a meeting?
16:35:58 <palendae> I'd like to get alternative views on it, separate from RPC
16:36:14 <palendae> RPC is a deployer, os-ansible-deployment/openstack-ansible is what they deploy
16:36:16 <BjoernT> That's fine
16:36:27 <palendae> But yeah BjoernT, we can have internal meetings
16:36:30 <sdake_> is rpc a repo?
16:36:40 <palendae> sdake_: Rackspace Private Cloud
16:36:40 <sdake_> oh rackspace private cloud right
16:36:46 <sdake_> ya got it sorry duh ;)
16:36:56 <odyssey4me> BjoernT: if we could discuss that separately that'd be great - you have an email from me on the topic
16:37:02 <BjoernT> ye sI do
16:37:42 <cloudnull> so lets put together a an etherpad regarding project scope and solicit feedback on the ml regarding its contents.
16:37:51 <d34dh0r53> +1
16:38:10 <odyssey4me> Good plan. :)
16:38:27 <b3rnard0> anyone in particular who will do that?
16:38:43 <cloudnull> ill put together the draft. but it should be a living doc .
16:38:47 <odyssey4me> I think perhaps that should be done an agreed to before we go further with any blueprint feedback discussions.
16:39:21 <stevelle> I'm concerned that might unnecessarily block other work
16:39:23 <BjoernT> yea I agree
16:40:17 <odyssey4me> It doesn't have to stop anything, but it is a crucial guide for deciding how to approach solving the problems.
16:40:55 <stevelle> I agree, for the pinning blueprint, we need to answer the question of scope.  I am not sure we do for networking or configuration
16:41:22 <odyssey4me> We can still put together ideas and work on them.
16:41:54 <cloudnull> #action cloudnull to create osad project manifesto as public etherpad and solicit feedback from the ML
16:42:32 <odyssey4me> Tunable configs is clearly openstack specific, so yes.
16:42:51 <cloudnull> i agree we can still work on BPs and discus them without having a specific guideline doc in place.
16:43:15 <cloudnull> so lets talk about https://blueprints.launchpad.net/openstack-ansible/+spec/tunable-openstack-configuration
16:43:18 <cloudnull> #link https://blueprints.launchpad.net/openstack-ansible/+spec/tunable-openstack-configuration
16:43:34 <odyssey4me> Network config is a grey area - but if it's implemented in a way that doesn't bind the deployer to using it, then it should be fine.
16:44:02 <cloudnull> odyssey4me have you and git-harry though more about this ?
16:44:17 <cloudnull> he was going to help on that right? or am i remembering incorrectly ?
16:44:55 <git-harry> cloudnull: I've had a look at it
16:45:13 <git-harry> I think we should set hash_behaviour = merge
16:45:23 <cloudnull> why?
16:45:47 <Sam-I-Am> odyssey4me: yeah. different people are going to kick their hosts differently.
16:45:53 <git-harry> so the config can be sorted in the vars and dicts don't get replaced
16:46:07 <git-harry> then we can have simple templates that spit it out
16:47:17 <cloudnull> but that can and will effect the entire stack. so setting that will likely have consequences across the board.
16:47:24 <cloudnull> to quote ansible docs "We generally recommend not using this setting unless you think you have an absolute need for it, and playbooks in the official examples repos do not use this setting"
16:47:41 <Sam-I-Am> odyssey4me: as an open project, we really cant dictate what people do with their networking
16:47:42 <git-harry> Yes, it may
16:47:46 <git-harry> so we would need to test
16:48:43 <cloudnull> do you think you have cycles to go and see if that makes the world explode? and can you put together an example of the hash merge for config?
16:48:57 <odyssey4me> It's either that or we have vars for our defaults and a specific dict for uncatered-for tuna lea.
16:48:57 <odyssey4me> *tunables
16:48:58 <cloudnull> that'd be helpful if we can make that go without major impact.
16:49:05 <git-harry> I have started doing that already
16:50:02 <git-harry> I'll try and finish it by next week. The broken gate was blocking me yesterday
16:50:26 <cloudnull> yes i think the broken gate was blocking all of OS yesterday :)
16:50:53 <git-harry> aye
16:51:27 <cloudnull> ok. so git-harry you are working on a different thread regarding the same functionality as it pertains to that BP?
16:52:11 <cloudnull> so as to not duplicate efforts can you and odyssey4me sync up on that, if you've not already ?
16:52:18 <git-harry> cloudnull: yes, I'm testing a different implementation
16:53:04 <odyssey4me> Yeah, can do.it might actually be useful to have two implementation options to compare.
16:53:19 <cloudnull> i agree.
16:53:38 <odyssey4me> Not full ones, obviously. Just a single service.
16:53:38 <cloudnull> so we have 8 min left. lets open up the discussion to anything.
16:53:53 <sdake_> may I ask a Q
16:53:56 <sdake_> regarding scope
16:53:56 <cloudnull> shoot.
16:53:59 <b3rnard0> #topic Open discussion
16:54:08 <sdake_> I see ansible play books deploy
16:54:21 <sdake_> would the project be open to "maintaining" the deployment
16:54:37 <sdake_> in otherwords, validating the ha and making sure things stay operational
16:55:08 <sdake_> I guess the correct term for this would be orchestration, whereas os-ansible-deploy is workflow
16:55:13 <odyssey4me> I'm not sure I understand.
16:55:20 <sdake_> so have 3 controller nodes
16:55:26 <sdake_> nova dies on controler node
16:55:26 <palendae> sdake_: Are you thinking something like monitoring?
16:55:29 <sdake_> want to validate that
16:55:33 <sdake_> ya all about HA
16:55:44 <sdake_> but I dont want to just monitor I want to take corrective action
16:55:47 <sdake_> is that in or out of scope?
16:55:48 <palendae> Sure
16:55:54 <cloudnull> i think adding in the functionality to operationally maintain the stack makes sense.
16:55:56 <palendae> I think right now that's out of scope
16:56:04 <palendae> In terms of automatically correcting
16:56:15 <odyssey4me> You mean add deeper functional testing?
16:56:19 <palendae> But we also haven't formally laid down a scope
16:56:23 <sdake_> so if someone came along and wrote that code, it would be -2? :)
16:56:34 <palendae> odyssey4me: I think this is around keeping production systems up
16:56:52 <sdake_> right keeping the production system in an operational state via monitroing and corrective ha action
16:57:02 <cloudnull> sdake_ no, I would not automatically -2. but depending on the impact i may ask for a blueprint.
16:57:06 <odyssey4me> Ok, so more of adding stuff like monit to check and auto respond?
16:57:10 <git-harry> I'd say that was out of scope of this project
16:57:20 <sdake_> ok process is fine, just curious if that is like "nah that is someone elses problem" :)
16:57:49 <mattt> sdake_: yeah i'd think that's more in the deployer's realm
16:57:51 <sdake_> ya monit is an option
16:58:19 <sdake_> ok thanks, that was the only scope question I had - actually I have a slew more but we are out of time :)
16:58:25 <odyssey4me> I would say that adding an external Ansible role which does that in an example play or readme would be great.
16:58:37 <cloudnull> +1
16:58:37 <odyssey4me> But not add it in this code tree.
16:58:47 <b3rnard0> sdake_: if you have more agenda items to discuss, feel free to add them to the agenda meeting for next week
16:58:55 <stevelle> sdake_: I'd like to see the other scope questions as they may help with one of the action items
16:58:57 <mattt> yeah i'd love to see that work w/ os-ansible-deployment, but i'd also think it'd be an external component
16:59:12 <Apsu> sdake_: Since most of the project participants are currently the same folks using this for our employer's product, it's definitely a challenge we're tackling. But where we draw the scope line and how we decide inclusion are in definite need of discussion and nailing down.
16:59:15 <sdake_> sure we can follow up in #openstack-ansible channel if you like
16:59:38 <sdake_> ^^ b3rnard0
16:59:44 <Apsu> Definitely do ask those questions in some form so we can get that input
16:59:45 <cloudnull> yup we're out of time.
16:59:58 <mattt> Apsu: yeah nothing at this point is a hard no, that's for sure
17:00:05 <cloudnull> #endmeeting