16:01:08 <rhallisey> #startmeeting kolla
16:01:09 <openstack> Meeting started Wed Jun 10 16:01:08 2015 UTC and is due to finish in 60 minutes.  The chair is rhallisey. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:13 <openstack> The meeting name has been set to 'kolla'
16:01:21 <rhallisey> #topic rollcall
16:01:26 <rhallisey> hello
16:01:28 <pdb> hi
16:01:29 <Kupo24z> hi
16:01:31 <jpeeler> hi!
16:01:34 <mstachow> hi :) !
16:01:35 <SamYaple> here i am
16:01:46 <juggler> o/ [visiting..]
16:01:48 <Slower> o/
16:01:51 <sdake> yar folks o/
16:02:01 <sdake> hey juggler visiting :)
16:02:14 <juggler> yello sdake!
16:02:33 <rhallisey> hey hall
16:02:35 <rhallisey> hey all
16:02:41 <kevsi_> hi
16:02:54 <loth> hey
16:03:29 <rhallisey> #topic Announcements
16:03:50 <rhallisey> Ok so we are looking to do a mid cycle meetup
16:03:59 <rhallisey> #link http://doodle.com/su62amktdrp5mrez
16:04:14 <rhallisey> lets take ~2min to check that out
16:04:26 <rhallisey> it will be help in San Jose
16:04:37 <sdake> help is the right word :)
16:04:38 <rhallisey> held*
16:04:45 <rhallisey> ha
16:05:27 <jasonsb> are you interested in having new people attend or is it more of a working session?
16:05:28 <rhallisey> any Kolla dev is welcome, it looks like we will have good participation
16:05:31 <sdake> jpeeler around?
16:05:36 <sdake> i also invited the operators
16:05:47 <sdake> i get mandre can't make it from europe
16:05:50 <jpeeler> i'm here
16:06:01 <sdake> curious what your conflicts are for the second two weeks
16:06:03 <sdake> is it like a pto thing?
16:06:12 <pdb> it would be cool if you could do some hangouts as part of it
16:06:24 <rhallisey> jasonsb, I would say it's a working session, but there are lots of new people so I would say anyone is welcome
16:06:27 <pdb> for us who can't make it across the water
16:06:34 <jasonsb> rhallisey: awesome
16:06:36 <jpeeler> sdake: i'm going to be on my honeymoon!
16:06:47 <jpeeler> but i doubt there's travel funds for me anyway
16:06:50 <sdake> jasonb absolutely midcycles are open to the public
16:06:57 <sdake> oh no shit
16:07:00 <sdake> well grats to ya !
16:07:01 <rhallisey> daneyon, hey
16:07:31 <daneyon> hey
16:07:31 <sdake> jpeeler I may have to schedule you out of the meeting looking at the current poll stats unfortunately
16:07:33 <bmace> +1 pdb.  not sure if you are having this stuff in a room that has video-conf tech for remote folks.
16:07:36 <sdake> hey dnayeon
16:07:52 <sdake> we will likely have full telepresence via webex
16:08:01 <sdake> but I can't confirm until I have dates
16:08:04 <sdake> that is why it wasn't in the announcement post
16:08:11 <rhallisey> I'm sure we can accommodate
16:08:20 <jmccarthy> Did I miss rollcall ?
16:08:21 <jpeeler> sdake: thanks! it's ok - not sure about funding like i said
16:08:33 <rhallisey> jmccarthy, yes, that's ok :)
16:08:36 <jmccarthy> I'm here =)
16:08:48 <juggler> I think the bot recorded you jmcc :)
16:09:00 <rhallisey> ok next, there has been a suggestion to change the time of this meeting from 1600 UTC to 1700 UTC
16:09:14 * jpeeler just saw the telepresence comment
16:09:28 <SamYaple> no
16:09:31 <rhallisey> if you have an issue with that or you like that idea please respond on the email thread with a +1 or a -1
16:09:37 <SamYaple> i can barely stay up for this one
16:09:54 <pdb> yeah I already replied on the mailing list but it would be a -1 from me
16:10:04 <sdake> samyaple do you usually make the 2200 meeting?
16:10:08 <SamYaple> no
16:10:24 <juggler> SamY curious, what is the localtime for you?
16:10:29 <rhallisey> express your concern via mailing list and we will address that time in two weeks
16:10:35 <SamYaple> Central/US, but im thirdshift juggler
16:10:38 <SamYaple> rhallisey: will do
16:10:43 <rhallisey> SamYaple, thanks
16:11:01 <rhallisey> #topic Manifesto Definition Finalization
16:11:12 <rhallisey> #link https://etherpad.openstack.org/p/kolla-manifesto
16:11:18 <juggler> SamY ouch, thanks for being here then :)
16:11:30 <SamYaple> no thank YOU juggler
16:11:35 <rhallisey> last week we voted on this
16:11:55 <rhallisey> I just wanted to see if we can come to a final consensus
16:12:11 <juggler> may i make two observations of feedback?
16:12:25 <sdake> juggler no
16:12:32 <juggler> ok :)
16:12:39 <sdake> you mean on the manifesto?
16:12:47 <juggler> sure
16:12:49 <juggler> actually 3
16:13:01 <sdake> which feedback, if its the stuf we did last week no
16:13:10 <sdake> if its the stuff in lines 5-20 yes :)
16:13:24 <juggler> the stuff in line 5
16:13:31 <sdake> ok feel free :)
16:13:33 <juggler> and line 1
16:14:05 <juggler> line 5: I think the "is" should be an "are"
16:14:10 <rhallisey> anyone who hasn't approved/disapproved leave a +1/-1 below line 5
16:14:23 <juggler> line 5: I think "production ready" should be "production-ready"
16:14:41 <rhallisey> juggler, leave your feedback as a comment
16:14:50 <sdake> juggler this is what he voting is for :)
16:15:22 <rhallisey> I think most of the community is voted, but anyone who hasn't yet you have 2 min
16:15:52 <juggler> line 1: Although Manifesto is a valid word, it does weigh some possibly controversial connotations. Perhaps considering a different word, such as "framework" or "action plan" might be suitable considering the open source community experience
16:16:12 <inc0> community's manifesto...
16:16:23 <juggler> just some outside observations :)
16:16:42 <bmace> manifesto is fine.  just because some people have had some odd / questionable ones doesn't make the word invalid :)
16:17:06 <sdake> bmace+1 voice of reason ;)
16:18:06 <rhallisey> It seem like the general idea and most of the wording is in agreement
16:18:22 <rhallisey> that is good progress
16:18:31 <sdake> can we finalize the wording ? :)
16:18:34 <pdb> when do we get the tshirts?
16:18:35 <SamYaple> pop the champange
16:18:49 <juggler> pdb lol
16:18:59 <bmace> how do you want to do that sdake?  have folks write out the full thing with final wording and then vote on those?
16:19:03 <juggler> rhallisey indeed
16:19:10 <sdake> bmace seems to heavyweight
16:19:28 <rhallisey> sdake, yes, but we need to make another draft
16:19:31 <sdake> bmace there is one bone of conflict, the use of is vs are
16:19:32 <bmace> or come up with a summary of the micro-changes to the existing one and then people vote on those?  the is vs. are thing is a common one.
16:19:36 <SamYaple> i say git commit and let the patches decide
16:19:51 <sdake> both is and are are wrong here imo
16:19:57 <bmace> sure, i think there are several suggestions to yank or re-order a couple of words, some for the sake of minimum verbosity.
16:20:04 <sdake> what would be best is which, which removes the plurality
16:20:05 <pdb> danehans suggestion is perfect imo
16:20:22 <rhallisey> I agree with danehans suggestion also
16:20:27 <pdb> I think that part came from my original suggestion, my intention was it was the OpenStack that results from kolla that is fast/stable etc.
16:20:31 <sdake> danehans suggestion sovles problem
16:21:07 <sdake> can someone make a new draft above the old draft (rhallisey?) with the suggested change so we can read i t in full glory
16:21:12 <rhallisey> ya I got it
16:22:06 <sdake> ok quick check for errors
16:22:22 <sdake> i dont think we need to revote or anything since the wording doesn't materially change the mission
16:22:33 <rhallisey> fine with me
16:22:41 <SamYaple> yup
16:22:48 <rhallisey> any objections.. let me look at other comments
16:23:02 <juggler> how about production-ready ?
16:23:19 <sdake> juggler that is probably better
16:23:27 <rhallisey> I'm fine with that
16:23:54 <rhallisey> jmccarthy, you had another comment?
16:24:12 <rhallisey> anyone else?
16:24:14 <juggler> just from what i've seen in industry :)
16:24:18 <jmccarthy> Not intentionally - just the one
16:24:42 <rhallisey> jmccarthy, I like having fast as an adjective for kolla
16:25:07 <jmccarthy> Ok I have no major gripe with it, I was just trying to find something to chop
16:25:08 <sdake> agree i like fast
16:25:11 <pdb> +1 on fast
16:25:16 <rhallisey> ok cool
16:25:22 <bmace> +1 for trying to be fast at least :)
16:25:24 <rhallisey> good work on that
16:25:27 <rhallisey> lots of community input
16:25:31 <sdake> trying to be fast lol :)
16:25:32 <rhallisey> moving on
16:25:41 <sdake> ya brain melt making that one happen ;)
16:25:44 <rhallisey> #topic Continuous integration
16:25:47 <sdake> I'll update the wiki with it soon
16:25:55 <rhallisey> SamYaple, jpeeler any updates?
16:26:30 <SamYaple> i have not been able to provice jpeeler with an aio networking deal yet
16:26:33 <jpeeler> no, i've been waiting on the networking changes ow baremetal installs to communicate properly
16:26:43 <SamYaple> linux-bridge agent is messing with the l2 stuff
16:26:49 <SamYaple> i can get ovs to work
16:26:54 <rhallisey> SamYaple, any idea for a time frame?
16:27:16 <SamYaple> honestly i dont know if linux bridge can work with a single nic
16:27:29 * sdake groans
16:27:41 <SamYaple> yea my reaction too
16:27:46 <rhallisey> :(
16:27:48 <sdake> samyaple what about with that mosnterof a script i pasted using bridges
16:27:59 * SamYaple groans
16:28:01 <sdake> could that be in some way used even  if it were hacky
16:28:14 <SamYaple> if it can be hacky, then creating a few vlxan interfaces hsould work
16:28:28 <SamYaple> but it will be hacky for sure
16:28:31 <sdake> i think we are good with hacky
16:28:35 <jpeeler> really just want signle nic solution
16:28:38 <bmace> hacky > impossible
16:28:38 <SamYaple> i cant get floating ips to work is the issue here
16:28:39 <sdake> what does it take teo create vxlan interfaces
16:28:51 <juggler> bmace +1
16:28:54 <SamYaple> i mean with a single interface, im not sure about vxlan
16:29:42 <rhallisey> ok needs further investigation.. noted
16:29:46 <sdake> well dont care how its done, but needs to be done - if you can't do it, I'm not really sure what the next step is
16:30:04 <sdake> because I tried andfailed, fang tried and failed, you tried and resultspending :)
16:30:08 <sdake> your our last great hope :)
16:30:16 <harmw> hi guys!
16:30:19 <SamYaple> why can we not use two or more interfaces again?
16:30:22 <rhallisey> harmw, hey
16:30:26 <SamYaple> o/
16:30:33 <sdake> samyaple the gate machine only has one interface I think
16:30:37 <SamYaple> ok
16:30:48 <sdake> its not like we get to say "hey I want 4 routed interfaces" to infra
16:30:52 <sdake> jpeeler, can you double check that tho
16:31:00 <jpeeler> and i'm sure others only have one nic too
16:31:01 <sdake> it maybe we get two interfaces
16:31:11 <harmw> my coreos dockervm has only 1 nic, and that 'just works' so I'm interested in what the issue is
16:31:14 <sdake> beyond the gate problem alot of ofolks want to quickly run kolla
16:31:18 <jpeeler> right
16:31:20 <sdake> and quikcly and neutron don't go hand in hand
16:31:22 <rhallisey> indeed
16:31:30 <SamYaple> i mean, if neutron is using infra, then they have to either have multiple interfaces or solved this issue
16:31:36 <jpeeler> devstack works with just one nic. surely docker can
16:31:40 <pdb> SamYaple: thats what I was thinking
16:31:45 <sdake> devstack uses ovs jpeeler
16:31:46 <SamYaple> jpeeler: right, but with linuxbridge?
16:31:53 <SamYaple> ovs i can do in my sleep
16:32:00 <pdb> and we cant use ovs because?
16:32:02 <jpeeler> i missed why we must use linux bridge (not a networking guy)
16:32:12 <sdake> that is all we got atm jpeeler
16:32:15 <SamYaple> OVS container doesnt exist yet
16:32:16 <harmw> we don't have ovs yet
16:32:25 <sdake> but ideally we should have ovs and linuxbridge as options
16:32:27 <SamYaple> Im going to submit on top of fang to get that finished
16:32:28 <rhallisey> ya OVS is WIP
16:32:31 <sdake> those are the two that peope lwant
16:32:34 <jpeeler> so maybe we have a new pre-req?
16:32:44 <inc0> by the way...whats up with ovs? this one is kinda critical...
16:33:05 <SamYaple> inc0: i was waiting on fang, but i see no progress for a while. ill check with fang and patch ontop
16:33:11 <pdb> its blocked waiting for docker 1.7 afaik
16:33:13 <rhallisey> inc0, feng has been working on it, I believe he said it works
16:33:13 <SamYaple> he is 90% done
16:33:19 <rhallisey> or close to
16:33:20 <SamYaple> pdb: it is not
16:33:27 <pdb> oh, disregard then :)
16:33:34 <harmw> docker 1.6 was neutron magic, 1.7 cinder magic
16:33:36 <harmw> or something :)
16:33:41 <sdake> we are not blocked on docker 1.7 for anything atm but cinder and we are good there with the dev versions
16:33:44 <rhallisey> ya 1.7 is required for cinder :)
16:33:58 <SamYaple> cinder/neutron namespace propogation
16:34:04 <harmw> yep
16:34:16 <rhallisey> ok we're getting a little off topic, let's move on
16:34:18 <sdake> if ovs sovles this gating problem
16:34:23 <sdake> I guess I would be good with it
16:34:24 <rhallisey> carry over the discussion
16:34:29 <rhallisey> #topic Liberty Priority Review
16:34:30 <SamYaple> aye aye
16:34:41 <sdake> would be nice to gate on linuxbridge tho ;)
16:34:47 <rhallisey> sdake, agreed
16:34:56 <rhallisey> first BP:  	Add a HA container for RabbitMQ
16:35:12 <SamYaple> rhallisey: that souldnt be a seperate container
16:35:13 <rhallisey> was someone working on this?
16:35:19 <inc0> mstachow will, correct Michal?
16:35:25 <inc0> after Galera
16:35:30 <mstachow> That's correct
16:35:33 <SamYaple> rabbitmq _is_ HA, it just needs configuration
16:35:40 <harmw> mirroring, right?
16:35:55 <rhallisey> just an fyi, we're going to go through these BP's quickly
16:35:56 <SamYaple> you have to tell the other nodes how to join the cluster, thats it really
16:35:59 <rhallisey> 30sec ea
16:36:01 <mstachow> That means we will have updated rabbitmq container ;)
16:36:27 <rhallisey> SamYaple, next you have two
16:36:28 <rhallisey> Generate ini-type configuration files dynamically
16:36:32 <rhallisey> Run with one Interface with Neutron
16:36:46 <rhallisey> can you update the status of those? If anything has changed
16:37:10 <SamYaple> generate ini waiting on the spec sdake wrote
16:37:17 <rhallisey> jpeeler,  	Use tempest to gate our built infrastructure same to you
16:37:30 <SamYaple> it will tweak how its finally commited as
16:37:37 <rhallisey> ok thanks
16:37:43 <rhallisey> inc0,  	Turn galera into a container
16:37:53 <sdake> rhallisey was that gating thing a milestone 1 blueprint?
16:37:54 <rhallisey> I saw your review is up
16:38:03 <mstachow> That's me - not inc0
16:38:04 <inc0> its mstachow's , but yeah
16:38:11 <rhallisey> oh woops
16:38:14 <rhallisey> sdake, ya
16:38:21 <sdake> imo we should move that out
16:38:28 <rhallisey> sdake, ok
16:38:31 <inc0> (he is also Michal, be careful!)
16:38:31 <sdake> too much blockage
16:38:42 <rhallisey> mstachow, change you status as needed
16:38:56 <rhallisey> lets see I have a few Cinder BPs
16:39:09 <rhallisey> they just need reviews, which would be greatly welcomed
16:39:14 <sdake> reminder: date is June 25th
16:39:19 <sdake> for deadline
16:39:27 <harmw> rhallisey: again? guess I missed that
16:39:38 <rhallisey> harmw, I haven't updated yet I'm on pto
16:39:40 <rhallisey> next week
16:39:43 <harmw> ok, cool
16:39:52 <jpeeler> i need to write on up for ironic, will do that today
16:40:00 <rhallisey> the final BP's look good they all have code reviews up
16:40:12 <sdake> jpeeler write up what a blueprint?
16:40:12 <rhallisey> so folks keep up on the code reviews as best as you can
16:40:17 <rhallisey> there's lots to look at
16:40:19 <jpeeler> sdake: yeah
16:40:31 <sdake> jpeeler there is already a blueprint
16:40:34 <rhallisey> jpeeler, I thought there was one
16:40:39 <jpeeler> oh my bad
16:40:52 <sdake> jpeeler if you want to take it over feel free :)
16:41:01 <sdake> I'm not sure whos working on it
16:41:01 <sdake> or if its being worked on
16:41:18 <rhallisey> I don't think anyone has worked on it yet
16:41:19 <inc0> ironic will be required for contenerizing tripleo's undercloud, so I'd opt for bumping priority up
16:41:28 <jpeeler> yeah i'll take it over if nobody is...
16:41:30 <rhallisey> inc0, it would be yes
16:41:37 <rhallisey> jpeeler, cool thanks
16:41:45 <sdake> so quick thing about these priorities
16:41:46 <jpeeler> inc0: that's why :)
16:41:51 * sdake gets on soapbox
16:42:01 <sdake> there are a million containers we could produce
16:42:11 <sdake> well not really, more like another 20 or so for various services
16:42:21 <sdake> this would require packaging the big tent
16:42:29 <sdake> I think we have a solid kset of serivces to start with
16:42:40 <sdake> if there are some gaps for things like tripleo, lets get those done
16:42:52 <sdake> but i'd like to see us focus more on the deploy side of things in the short term
16:43:01 <sdake> rather then packaging the big tent
16:43:01 <sdake> that is a job for RDO
16:43:08 <sdake> or source base installs when we get to it
16:43:13 * sdake gets off soapbox ;)
16:43:20 <harmw> +1 on deployment for starters
16:43:23 <jpeeler> agreed
16:43:27 <pdb> +1
16:43:44 <harmw> plus multihost
16:44:05 <rhallisey> ok cool
16:44:11 <rhallisey> on that note..
16:44:17 <rhallisey> #topic Ansible Deployment Tooling
16:44:19 <sdake> anyway something to thing about re why things are prioritized the wayt hey are and organized into various liberty-xyz
16:44:37 <rhallisey> #link https://review.openstack.org/#/c/189157/
16:45:03 <sdake> nice 30 comments!
16:45:05 <rhallisey> this is the current spec for ansible
16:45:28 <inc0> there is quite a discussion about external configs
16:45:46 <SamYaple> enough so i believe it warrants existing as an option
16:45:49 <rhallisey> thanks for the comments everyone... If we want to have any further discussion about the spec we can do that now
16:45:50 <sdake> external configs and 56-57 seem to be the hot areas on the config
16:45:53 <sdake> on teh spec
16:46:19 <rhallisey> sdake, I think external config is a great feature
16:46:21 <sdake> lines 56-57
16:46:43 <inc0> SamYaple, thing is, I'm reluctant on having 2 methods of configs
16:46:46 <sdake> for lines 56-57 should we just tell people to piss off :)
16:46:47 <rhallisey> anyone want to voice their opinion?
16:46:54 <SamYaple> inc0: were going to have 2 period
16:46:57 <pdb> the thing to note here is that SamYaple has come up with a way that may satisfy both sides
16:47:00 <SamYaple> crudini is one of them
16:47:19 <SamYaple> the bind/env methods are very simliar, enough to count as one in my opinion
16:47:21 <pdb> it essentially allows external configs while maintaining the idempotency requirement
16:47:39 <sdake> pdb you mean immutability requirement
16:47:39 <SamYaple> the lines of code bind ands would be 10-20, maybe
16:47:44 <pdb> SamYaple: yes sorry
16:48:04 <pdb> so my current vote is to support that + crudini
16:48:09 <sdake> so re two sources of truth
16:48:30 <harmw> will we be pushing full cfg files with this? or just the bits that apply to a shipped config-dist?
16:48:31 <sdake> samyaple your proposal doesn't solve that problem?
16:48:42 <sdake> harmw that is covered inthe spec
16:48:46 <harmw> ok
16:49:02 <pdb> hmm it does not :(
16:49:08 <rhallisey> one bonus of having 2 configs is when we get to deploying the many setups of neutron/cinder, it will be easier to generate those containers from a config file someone has already created
16:49:23 <bmace> i think there is an option that we discussed, i don't know if it is in the spec yet.. but there would be a flag that controls if kolla pushes out configs at all.. after the initial set up the user can just manage all their configs however they want, puppet, chef... vi + rsync, whatever.
16:49:28 <SamYaple> sdake: i dont know if it solves that since i dont fully understand "two sources of truth", but it is a very big deal to most people and _not_ a required method
16:49:51 <bmace> i believe sdake is concerned about having multiple places "in charge" of the config data.
16:49:54 <rhallisey> bmace, exactly
16:50:04 <bmace> which is why it needs to be clearly either a) kolla control or b) user control.
16:50:31 <sdake> samyaple reading your 7:09 proposal atm
16:50:40 <SamYaple> i believe I can tie env/bind/users own config all together
16:50:46 <inc0> rhallisey, at some point we might want to have different configs on several nodes, so you'd need to use different containers with just one option that differs?
16:51:09 <SamYaple> it dont believe it will add that much extra work, it certianly wont be dokcer start commands
16:51:20 <SamYaple> extra* docker start commands
16:52:24 <rhallisey> inc0, kolla as a tool can be used to build and run containers
16:52:25 <pdb> out of interest, am I the only one who is not a fan of the env method regardless of the internal/external debate?
16:52:31 <SamYaple> the 3 cases as I see them
16:52:31 <SamYaple> 1 env variables as spec describes
16:52:31 <SamYaple> 2 ansible lays out configs and the get bind mounted into the container, local changes persist to config until ansible runs again
16:52:34 <SamYaple> 3 user managed configs
16:52:43 <rhallisey> so we can allow users to build their own or we can build them and they can run them
16:53:06 <SamYaple> pdb: no, im not a fan. but i understand the argument
16:53:18 <inc0> my suggestion: just expose /etc/myproject from host to container and have config there
16:53:38 <sdake> this breaks immutability!
16:53:41 <inc0> I don't see why kolla should even care about config management? this is muddy place
16:53:53 <SamYaple> sdake: i dont think anyone cares at that level
16:54:04 <SamYaple> but you can keep immutability with the env option
16:54:21 <sdake> is the env option you mean the docker moduels you created?
16:54:25 <bmace> sdake at least it doesn't allow for the modification of the config file while the container is actually running, so better than a straight up bind / direct-read.
16:54:27 <SamYaple> yes sdake
16:54:37 <sdake> bmace agreed
16:54:49 <sdake> so as I red your 7:08 proposal have 3 models
16:54:59 <sdake> 1 is crudini
16:55:08 <sdake> 2 is bindmount with immutability brekage
16:55:18 <sdake> 3 is docker env without immutabilitybreakage
16:55:36 <SamYaple> yes. all user managed configs can be lumped in with 2
16:55:38 <sdake> 2 results in two sources of truth as well
16:55:38 <pdb> there's a variation on 2) that gives mutability
16:55:55 <pdb> *immutability
16:55:57 <pdb> :/
16:56:00 <SamYaple> pdb: there really isnt
16:56:04 <sdake> i want to hear variation of 2 that gives immutability
16:56:05 <harmw> immutability is something we shouldn't throw away easily..
16:56:22 <pdb> container copies configs into itself on start
16:56:40 <inc0> pdb, changes of configs will be small pit in hell
16:56:53 <SamYaple> pdb: yea but thats the same as doign it the env way, since ansible starts it
16:56:59 <bmace> with 2, either kolla blows down new config files and wipes out any local changes, or they configure an option to control all configs themselves.. so there is only one master, that is the intent at least.
16:57:21 <pdb> SamYaple: you can drop your own configs on there for it to grab though
16:57:24 <rhallisey> why can't we do 1 and 3 ( as optional)?
16:57:29 <inc0> also, we'll want services to be able to reread configs without restarting, and all these makes this impossible
16:57:35 <SamYaple> rhallisey: would be my vote
16:57:43 <rhallisey> 1 is our primary and 3 as optional
16:57:47 <SamYaple> inc0: thats not possible anyway
16:57:49 <harmw> should we move in complete configs, we'll be tasked with keeping those up2date as well... we shouldn't be bottered with that
16:57:55 <inc0> SamYaple, actually it is
16:57:59 <inc0> using oslo.config
16:58:24 <inc0> but what is lacking is way to call it inside service, but that's not that hard
16:58:27 <SamYaple> inc0: are you saying sevices reread thier configs on the fly right now?
16:58:32 <rhallisey> hey guys keep in mind we have 2min left
16:58:39 <SamYaple> table that inc0
16:58:39 <harmw> (was about to say just that)
16:58:50 <sdake> oslo.config is web scale
16:59:12 <SamYaple> all of the users and admins I have spoken with want option 2 to exist
16:59:18 <SamYaple> it doesnt need to be default, but it needs to be there
16:59:31 <sdake> ok i would relaly like to get to the bottom of the config strategy, so can we overflow for a bit into #kolla since our time is out :)
16:59:40 <rhallisey> SamYaple, why do they care about option 2 if you can offer 3?
16:59:43 <inc0> I come from ops background and yeah, ops will want it, immutability or not
17:00:02 <SamYaple> rhallisey: #kolla
17:00:07 <rhallisey> option 2 makes me think of devstack
17:00:15 <rhallisey> ok out of time
17:00:23 <rhallisey> we will move over to #kolla
17:00:27 <rhallisey> thanks all!
17:00:40 <rhallisey> #endmeeting kolla