16:30:22 <rhallisey> #startmeeting kolla
16:30:23 <openstack> Meeting started Wed Feb  3 16:30:22 2016 UTC and is due to finish in 60 minutes.  The chair is rhallisey. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:30:26 <openstack> The meeting name has been set to 'kolla'
16:30:32 <rhallisey> #topic rollcall
16:30:34 <SamYaple> o/
16:30:35 <rhallisey> hello
16:30:36 <akwasnie> o/
16:30:41 <elemoine> o/
16:30:43 <SamYaple> unicell: ping
16:30:45 <dratushnyy> o/
16:30:45 <Jeffrey4l> \o/
16:30:47 <pbourke_> hi
16:30:47 <nihilifer> o/
16:30:49 <mdnadeem1> o/
16:31:37 <rhallisey> so sdake will be back in ~15 min
16:31:50 <rhallisey> but will continue without him for now
16:31:52 <jpeeler> hi
16:31:57 <rhallisey> hey Jeff
16:32:00 <Guest44587> hi
16:32:16 <SamYaple> jpeeler: o/
16:32:24 <rhallisey> inc0, around?
16:32:33 <Jeffrey4l> hi every one
16:32:39 <sdake> o/
16:32:44 <sdake> i am back now
16:32:49 <sdake> but go ahead and run the agenda rhallisey
16:32:53 <rhallisey> kk
16:32:53 <sdake> been going since 3am and i'm beat
16:33:00 <rhallisey> #topic Announcements
16:33:11 <rhallisey> So midcycle is right around the corner
16:33:23 <rhallisey> just want to remind everyone it's Feb 9th and 10th
16:33:28 <inc0> o/
16:33:31 <inc0> sorry I'm late
16:33:37 <rhallisey> inc0, no worries
16:33:43 <rhallisey> #link https://etherpad.openstack.org/p/kolla-mitaka-midcycle
16:33:48 <ajafo> o/
16:34:01 <rhallisey> just a reminder as to what is likely to be covered
16:34:09 <rhallisey> sdake, did you finalize the schedule?
16:34:50 <sdake> rhallisey no i did not
16:34:55 <sdake> but I will do so today
16:34:57 <rhallisey> kk
16:35:02 <sdake> its part of my work day
16:35:12 <sdake> please register if you haven't
16:35:18 <rhallisey> ^ yes that too
16:35:33 <rhallisey> #topic Kolla-ansible config playbooks
16:35:42 <rhallisey> SamYaple, go ahead
16:35:47 <SamYaple> will do. thanks rhallisey
16:35:48 <rhallisey> I'm excited for this topic
16:35:59 <SamYaple> #link https://review.openstack.org/#/c/271126/
16:36:10 <rhallisey> #link https://review.openstack.org/#/c/271126/
16:36:19 <rhallisey> you might not have perms :)
16:36:28 <SamYaple> ok
16:36:36 <SamYaple> that patchset is a bit discussing the issue
16:36:48 <SamYaple> basically what do we do when a config file _changes_?
16:36:56 <SamYaple> we need to restart services to pull in that change
16:37:23 <SamYaple> the purposed patch does it in line, I dont particularly agree with that approach because then you get service restarts out of the blue
16:37:25 <sdake> SamYaple  agree
16:37:26 <inc0> or call sighup on certain
16:37:35 <SamYaple> inc0: yes on a few we can
16:37:40 <sdake> inc0 the filelsystem is readonly
16:37:45 <SamYaple> but its still a service shutdown (just a much quicker one)
16:37:49 <sdake> once the config is in the container needs to be restarted
16:37:55 <inc0> we would need to copy new conf file tho
16:38:00 <SamYaple> sdake: no, thats for COPY_ONCE only
16:38:09 <sdake> SamYaple yes i know
16:38:13 <sdake> which needs to work :)
16:38:18 <inc0> default is COPY_ALWAYS afair
16:38:27 <SamYaple> no its COPY_ONCE
16:38:32 <sdake> definately coyp once
16:38:35 <inc0> ok
16:38:38 <inc0> my mistake then
16:38:44 <sdake> we made that decision long ago
16:38:49 <SamYaple> but with the changes to allow sighup the community at large is moving to changing configs so well revisit that later
16:38:52 <SamYaple> thats not the point of this
16:39:02 <SamYaple> back on topic
16:39:02 <sdake> that was part of the whole blueprint spec thing for ansible - that was required to get people to approve the spec
16:39:23 <SamYaple> the config playbook would be similiar to what we do with upgrades
16:39:37 <SamYaple> if new config changes are detected it would do a rolling restart to pull in those changes
16:39:40 <inc0> action - reconfigure?
16:39:47 <SamYaple> sure
16:39:52 <SamYaple> thats a reasonable name
16:39:53 <inc0> yeah, I'm cool with that
16:40:07 <SamYaple> so well reuse alot of (not yet written) upgrade code I think
16:40:16 <SamYaple> to maintain uptime and availability
16:40:22 <inc0> althouth I'd say we need to find out if config changes and restart only services we need
16:40:30 <SamYaple> which should be easy inc0
16:40:35 <SamYaple> a quick md5sum compare
16:40:39 <inc0> so if task template == changed then restart corresponding
16:40:40 <SamYaple> we do this in the haproxy container
16:40:47 <SamYaple> no that wont work
16:40:55 <SamYaple> because deploy changes teh files as they are laid down
16:41:00 <SamYaple> reconfigure would need a direct compare
16:41:06 <inc0> ok, makes sense
16:41:21 <SamYaple> so i think we are all on the same page here, just making everyone aware of the issue
16:41:21 <inc0> still, we need to take that into account
16:41:32 <SamYaple> no we dont need to track template == changed at all
16:41:40 <SamYaple> since we compare running vs current config
16:41:57 <sdake> one concern
16:42:00 <SamYaple> ok
16:42:03 <sdake> i want upgrades
16:42:08 <sdake> really really want upgrades
16:42:12 <sdake> i know they are related
16:42:26 <sdake> but i am concerned separating the work will make it harder to implement the ugprades
16:42:26 <SamYaple> config work is going to ride the coatail of upgrades
16:42:32 <sdake> shouldn't htis work come after?
16:42:33 <sdake> ok wfm
16:42:36 <sdake> then i'm good
16:42:42 <sdake> as long as we aren't rollign it all together
16:43:00 <SamYaple> unicell: ^^ when you see this
16:43:12 <SamYaple> oops wrong topic unicell
16:43:16 <SamYaple> ok rhallisey im ready to move on
16:43:27 <rhallisey> #topic Kolla-ansible delegate_to vs run_once
16:43:28 <rhallisey> okie
16:43:40 <SamYaple> ok this one is for unicell
16:43:52 <SamYaple> this is a tricky issue ill try to describe quickly
16:44:10 <SamYaple> #link https://review.openstack.org/#/c/271148/
16:44:13 <SamYaple> thats a related patch
16:44:26 <SamYaple> #link https://bugs.launchpad.net/kolla/+bug/1520728
16:44:27 <openstack> Launchpad bug 1520728 in kolla "fatal: [openstack002] => One or more undefined variables: 'dict object' has no attribute 'stdout'" [Critical,In progress]
16:44:28 <SamYaple> thats the bug
16:44:41 <SamYaple> we have had several bugs on this issue and unicell finally tracked it down
16:45:11 <SamYaple> Ansible 1.9.4 has an issue with multiple host includes and roles and our inventory
16:45:27 <SamYaple> it is fixed in the 2.0 branch, but until 2.0 it will skip certain tasks even if it shouldnt
16:45:42 <SamYaple> this makes certain inventory configs not useable with the bootstrap
16:45:50 <sdake> groan
16:45:51 <SamYaple> essentially its broken for certain deploys
16:45:59 <sdake> any more detail?
16:46:04 <rhallisey> ouch
16:46:15 <SamYaple> yea but its technical and time consuming
16:46:17 <sdake> can we get some docs on this ansible 1.9.4 deploy problem?
16:46:23 <SamYaple> ill go over the options we have t ofix this
16:46:31 <rhallisey> SamYaple, ya that would be good
16:46:32 <SamYaple> details can be provided later
16:46:42 <sdake> ok options then wfm
16:46:45 <SamYaple> two options, in no particular order of preference
16:47:28 <SamYaple> 1) upgrade ansible to 2.0. Lots of software has already made the switch. A 2.0 change is not very painful (ive analyzed the impact) it would just require us to run ansible 2.0
16:47:39 <SamYaple> (we can discuss these options in a minute)
16:47:47 <inc0> 1* affects upgrades
16:47:59 <inc0> but in a way we can handle it I think
16:48:32 <SamYaple> 2) we can force all specific options that encounter this bug to use the first host in the appropriate group. This would fix it! But it would be if the first node is down, you cant run the playbooks at all
16:48:34 <sdake> inc0 plan therei s deploy 1.9.4, then deploy liberty, then deploy 2.0.0 then upgrade to mitaka
16:48:54 <SamYaple> the second option breaks high-availability in my mind
16:49:06 <SamYaple> the first node must always be live or it all breaks
16:49:20 <sdake> maybe i'm an old fuddy duddy but i hate adopting brand new 2.0.0 software for anssible 2 months prior to release when their test cases are very very weak
16:49:32 <inc0> if we upgrade to 2.0...do we still need kolla_docker?
16:49:36 <SamYaple> inc0: yes
16:49:44 <sdake> we are running our own module forever
16:49:47 <SamYaple> ^^
16:49:49 <inc0> ok
16:49:57 <SamYaple> for docker*
16:50:02 <sdake> right
16:50:02 <SamYaple> its just too critical
16:50:11 <sdake> its something we need to own
16:50:16 <SamYaple> ok so those are the options we have
16:50:20 <SamYaple> neither of them are great
16:50:20 <inc0> wfm, but kinda agree with Steve, upgrading to 2.0 will affect upgrades of kolla and we're awfully close to Mitaka
16:50:37 <sdake> ok so lets analyze impact of waiting to 2.0.0 to newton
16:50:38 <SamYaple> we could also ignore the issue and just have that be the issue for mitaka
16:50:41 <rhallisey> how about option 2, then move to 2.0 later?
16:50:42 <sdake> ha is slightly degraded?
16:50:46 <rhallisey> and fix it properly
16:50:57 <SamYaple> sdake: if first node is down, you can't run playbooks at all
16:51:09 <inc0> certain parts of deployment are causing errors
16:51:10 <sdake> ok highly degraded
16:51:12 <sdake> that kind of sucks
16:51:27 <sdake> is there a third option
16:51:33 <SamYaple> not that I know of
16:51:36 <sdake> such as document what types of deploys will expose this bug
16:51:37 <inc0> ignore the issue for now?
16:51:44 <SamYaple> inc0: yea thats the third
16:51:45 <sdake> ignore is not a option inc0
16:51:52 <rhallisey> hehe
16:51:56 <sdake> document and ignore would be ok i think :)
16:51:56 <jpeeler> so is there more background for state of code in ansible 2.0? was it a complete rewrite? (sorry don't know)
16:52:05 <Jeffrey4l> how about use the option 1 and add a pre-check to make sure the first node is up.
16:52:07 <SamYaple> but its really hitting the ebay bugs and Hui (and other)
16:52:08 <sdake> jpeeler pretty much green field rwerite
16:52:14 <dratushnyy> what if use 2.0 for deploys that exposes bug?
16:52:18 <inc0> ignore == document and ignore, I mean let's not fix it right now and get this as priority for N
16:52:32 <jpeeler> ah, that does make the decision tricky then
16:52:34 <SamYaple> dratushnyy: we cant do a 2.0 and 1.9.x compatible structure for kolla
16:52:36 <sdake> dratushnyy our code can onl yrun on 194 or 2.0.0
16:52:43 <sdake> if we could we  would have done that already
16:52:54 <inc0> also I'd really like to have 1 release deprecation for deps...
16:53:07 <SamYaple> personally, i think we should _not_ move to ansible 2.0
16:53:11 <rhallisey> inc0, I'm also thinking door #3 here
16:53:27 <SamYaple> but crippling our multinode is bad too
16:53:28 <sdake> i agree moving to ansible 2.0.0 prior to newton is a bad bad move
16:53:28 <inc0> SamYaple, we'll have to at some point
16:53:43 <inc0> we will only encounter more stuff like that
16:53:45 <SamYaple> inc0: in newton i plan to do it immediately after midcycle
16:53:45 <rhallisey> #1 could ruin upgrades for M #2 is a workaround #3 release with a limiation
16:53:55 <SamYaple> inc0: so it has time to sit
16:54:12 <elemoine> sdake, you mean prior to mitaka (not newton)
16:54:14 <sdake> in newton we could do at start of cycle
16:54:24 <inc0> SamYaple, wait till we pop newton branch plz
16:54:34 <sdake> elemoine yes prior to mitaka sorry
16:54:46 <sdake> ok lets focus guys
16:54:49 <SamYaple> inc0: newton branch means we have released newton ;)
16:54:49 <sdake> and gals
16:54:57 <inc0> SamYaple, can you list situations in which problem occurs?
16:55:04 <inc0> SamYaple, you know what I mean...
16:55:06 <sdake> yes w eneed more details
16:55:12 <sdake> we can dothis on the mailing list if its too time consuming
16:55:14 <SamYaple> let me find unicell bug
16:55:25 <sdake> SamYaple lets do it on the mailing list
16:55:36 <sdake> nad i will schedule 20-30 misn at midcycle for this
16:55:42 <sdake> so we can make a decision then
16:55:49 <sdake> after we understand what situations its fails under
16:56:06 <sdake> because that is a critical critical piece of missing information that is needed to make a decision
16:56:15 <rhallisey> agreed
16:56:18 <SamYaple> ok
16:56:25 <rhallisey> SamYaple, you cool with stating a thread?
16:56:27 <sdake> SamYaple can you take action to start thread?
16:56:40 <SamYaple> yea sure
16:56:44 <sdake> thanks bro
16:56:45 <inc0> SamYaple, will you start thread? (3 times so you can't refuse)
16:56:48 <inc0> ;)
16:56:49 <SamYaple> probably wait for unicell since this is his issue
16:56:54 <rhallisey> :)
16:57:07 <rhallisey> ok moving on
16:57:12 <rhallisey> #topic Logging with Heka (spec and development)
16:57:19 <rhallisey> elemoine, you have the floor
16:57:20 <elemoine> ok, that's me :)
16:57:26 <elemoine> the Heka spec got three +2's
16:57:32 <sdake> SamYaple  quick quesiton
16:57:38 <elemoine> Can I start pushing a patch flow to Gerrit?  Or should I wait for a more official approval?
16:57:39 <sdake> could we somehow make thte code conditional to select the "2nd" node
16:57:40 <rhallisey> elemoine, excellent
16:57:43 <sdake> if the first node was down
16:58:01 <inc0> yeah it's solid imho
16:58:02 <rhallisey> elemoine, I think generally we have all the cores for on specs before we +a
16:58:06 <sdake> like a config option "damnit select this node"
16:58:16 <rhallisey> elemoine, can you link the spec?
16:58:28 <sdake> apprently i'm lagged
16:58:32 <elemoine> https://review.openstack.org/#/c/270906/
16:58:38 <elemoine> #link https://review.openstack.org/#/c/270906/
16:58:45 <sdake> ele yo uwill get a review from me when this meeting concludes
16:58:46 <inc0> how about we run heka in pararell to rsyslog - if you run central logging it's heka
16:58:49 <rhallisey> elemoine, I don't want to delay it too long waiting on all cores, but would like a little more than 3
16:59:16 <rhallisey> so all cores please review https://review.openstack.org/#/c/270906/
16:59:16 <sdake> rhallisey  we require 6 +2 votes
16:59:16 <elemoine> sure, I'm just wondering if can start working on patches
16:59:19 <rhallisey> after the meeting
16:59:24 <elemoine> and push my patch stream to Gerrit
16:59:25 <sdake> specs require simple majority
16:59:48 <elemoine> fyi, this is the sort of patch stream I c
16:59:53 <elemoine> consider pushing:
16:59:55 <elemoine> https://github.com/openstack/kolla/compare/master...elemoine:heka-gerrit
17:00:17 <sdake> elemoine dont put it on github get it in the review queue please
17:00:22 <rhallisey> elemoine, I'm cool with you start pushing them tbh
17:00:23 <sdake> even if its not ready
17:00:27 <sdake> so people dont have to hunt for it
17:00:35 <elemoine> that's exactly my question :)
17:00:45 <sdake> just mark workflow -1
17:00:48 <elemoine> can I push that to Gerrit before the spec is fully approved
17:00:50 <inc0> I'm -1 on removing rsyslog just yet tho
17:00:58 <rhallisey> ya just -1 it
17:00:59 <sdake> elemoine you can push to errit before spec is approved
17:01:17 <elemoine> inc0, why?
17:01:19 <sdake> elemoine i recommend placing a -2 at your top level patch
17:01:26 <sdake> or marking it [wip]
17:01:37 <sdake> so someone doesn't accidentally merge it during review
17:01:41 <inc0> elemoine, backward compatibility (I should change name to Michal "backward compatibility" Jastrzebski)
17:01:44 <sdake> i wnat heka to go in as one big patch stream
17:01:48 <inc0> I want to lessen impact on upgrades
17:01:51 <sdake> inc0 lol
17:01:52 <SamYaple> inc0: that is never a requirement
17:02:03 <SamYaple> we never said anything about backward compatibly
17:02:03 <inc0> however, old version doesn't have central logging
17:02:05 <inc0> Liberty
17:02:07 <sdake> inc0 we roll forward not back
17:02:12 <SamYaple> just like openstack
17:02:19 <sdake> inc0 i think that really isn't a problem
17:02:19 <SamYaple> for rollback of openstack you need DB restore
17:02:31 <inc0> so I'd say if you run central logging, its heka
17:02:39 <sdake> rsyslog didn't work fantastically well in liberty anyway
17:02:49 <inc0> well, I know
17:02:55 <sdake> not criticising
17:03:00 <inc0> but if someone runs it they might build on it
17:03:06 <inc0> that's my point
17:03:14 <sdake> just indicating - if we can just move it to heka and be done thats one less migration our users have to deal with
17:03:15 <inc0> we say "rsyslog will disapear completely in N"
17:03:50 <rhallisey> elemoine, did you have anything else you wanted to go over?
17:04:00 <elemoine> yes, quick thing
17:04:00 <inc0> so my personal preference is to have it as default option, but an option for now
17:04:06 <inc0> for one release
17:04:23 <sdake> inc0 leave feedback to that statement in hte review please
17:04:29 <inc0> sure
17:04:31 <elemoine> inc0, people asked me if Heka could replace Rsyslog entirely,
17:04:32 <sdake> right  after meeting
17:04:33 <inc0> I'm still +2 on spec tho
17:04:38 <sdake> might actuallybe a good idea
17:04:45 <elemoine> and now the request it to keep Rssyslog
17:04:48 <sdake> if we had capacity to pull it off
17:05:10 <inc0> elemoine, just don't change anything with it and put one if statement in configs
17:05:16 <inc0> rest is the same
17:05:20 <elemoine> inc0, oh I see
17:05:29 <inc0> I'm first person to say lets replace rsyslog
17:05:31 <elemoine> it's also compatible with my patches
17:05:37 <elemoine> ok understood
17:05:38 <inc0> let's just have at least some deprecation period
17:05:39 <elemoine> wfm
17:05:51 <elemoine> so
17:05:55 <elemoine> another thing
17:06:05 <elemoine> We will need specific Lua decoders for parsing OpenStack, MySQL and RabbitMQ logs.
17:06:15 <elemoine> We already have these decoders, that we use in other projects (Fuel)
17:06:17 <inc0> I like lua
17:06:26 <elemoine> Our plan to distribute these decoders as deb and rpm packages in the future
17:06:29 <dratushnyy> Lua is nice
17:06:39 <elemoine> But if we don't have time to do that by Mitaka 3 (the 4th of March), will it be ok to have these Lua decoders in Kolla, really as a temporary solution?
17:06:41 <sdake> license is whwat elemoine
17:06:48 <inc0> elemoine, can we do this in our tree?
17:07:09 <sdake> need to know the license on all software
17:07:18 <inc0> I don't want to introduce new repo dependency for what probably will be less than 200 loc
17:07:22 <elemoine> inc0, we have another code base that uses these decoders
17:07:27 <nihilifer> they will be our custom decoders or some apche license compatibility?
17:07:30 <elemoine> so we'd like to share them
17:07:37 <sdake> what license
17:07:37 <nihilifer> compatible*
17:07:42 <ppetit> License of the lua plugins is in Fuel is Apache V2
17:07:48 <sdake> ASL2.0 is what makes my life easy
17:08:02 <sdake> cool
17:08:20 <sdake> i dont mind if they hit the repo - 200 lines of bloat for a cycle isnt' bad as long as it doesn't create an upgrade problem down the road
17:08:28 <sdake> so eval that
17:08:34 <sdake> start a thread on ml elemoine
17:08:37 <elemoine> it won't be a problem
17:08:53 <elemoine> sdake, ok I will
17:08:55 <sdake> upgrade needs to be top of mind when people make new design changes ;)
17:08:56 <elemoine> bottom line is
17:09:04 <sdake> if you can't upgrade it in some way, then dont do it for mitaka please
17:09:09 <sdake> newton wide open
17:09:13 <elemoine> we'd like to have the Lua decoders outside Kolla
17:09:13 <sdake> but mitaka we are super stretched
17:09:20 <elemoine> but maybe not for Mitaka
17:09:32 <sdake> ok i need 10 mins
17:09:39 <inc0> elemoine, let's start by having them in tree as it's simplest and then we'll revisit ok?
17:09:50 <sdake> rhallisey  ^^
17:09:52 <elemoine> inc0, exactly what I'm suggesting
17:09:56 <sdake> maybe 5
17:10:07 <elemoine> Im done
17:10:08 <rhallisey> sdake, roger
17:10:16 <rhallisey> cool thanks elemoine.  Nice job on the spec
17:10:27 <sdake> folks please review that spec
17:10:34 <sdake> lets get er looking sparkling pretty
17:10:37 <rhallisey> #topic sdake's announcement
17:10:42 <sdake> like a diamon instead of lump of coal
17:10:44 <sdake> not announcement
17:10:46 <sdake> just topic
17:10:47 <sdake> but
17:10:50 <rhallisey> idk
17:11:02 <sdake> i wanted to check in on how upgrades are coming along for people
17:11:15 <sdake> can i get a rollcall list of where people are at
17:11:17 <sdake> i'll go first
17:11:38 <sdake> glance -> started implementation, will be complete by midcycle, distracted by remodel
17:11:44 <sdake> heat -> wont be done by midcycle
17:12:06 <inc0> nova -> I'll rebase before midcycle
17:12:13 <inc0> docker -> scares the shit out of me
17:12:21 <rhallisey> lol
17:12:35 <nihilifer> magnum -> just began the work
17:12:37 <SamYaple> neutron -> needs thin containers then upgrade. thin containers done and working, but they required docker 1.10
17:12:39 <sdake> #link https://launchpad.net/kolla/+milestone/mitaka-3
17:12:45 <SamYaple> docker 1.10 is due out next week
17:12:50 <SamYaple> (or tomorrow0
17:12:55 <Jeffrey4l> horizon -> done but need some review.
17:12:56 <nihilifer> rabbitmq -> not started yet, will try to fdo before mid, but without promise
17:13:08 <SamYaple> nihilifer: there is a rabbitmq patch already
17:13:17 <nihilifer> oh...
17:13:21 <nihilifer> i just saw free bp
17:13:24 <SamYaple> ill handle mariadb
17:13:25 <nihilifer> but ok
17:13:31 * rhallisey did not grab an upgrade at devconf this week :(
17:13:31 <SamYaple> nihilifer: likely someone didnt grab it
17:13:33 <inc0> do we upgrade ceph?
17:13:36 <nihilifer> will pick something else from infra
17:13:36 <SamYaple> inc0: yup
17:13:38 <inc0> ceph will be funny
17:13:47 <SamYaple> ceph will be easy
17:13:51 <sdake> inc0 we will talk about infrastructure services at midcycle
17:13:55 <inc0> yeah I don't expect problems there
17:13:57 <sdake> I think we should jsut ugprade those once per cycle
17:14:00 <SamYaple> ive done real --> kolla ceph migration and the kolla --> real!
17:14:03 <sdake> towards the end
17:14:05 <sdake> but that is just my opinion
17:14:18 <sdake> we can have a more thorough discussion
17:14:21 <inc0> yeah, all is good apart from qemu
17:14:23 <sdake> thanks for the roll call folks
17:14:28 <sdake> looks like some progress is being made
17:14:37 <inc0> qemu is so disruptive that I'd like to keep that separated
17:14:41 <sdake> try to get atleast one patch in teh queue (and working)
17:14:55 <sdake> inc0 ok we can talk about upgrades at midcycle
17:15:02 <sdake> I am ging to shcedule copious sessions :)
17:15:06 <sdake> lets not beat dead horses
17:15:16 <sdake> I just want people to be prepapred to discuss it with real-world experiences
17:15:20 <SamYaple> sdake: but thats the thing me and inc0 do best!
17:15:23 <sdake> which it sounds like we are
17:15:32 <sdake> rhallisey all done thanks
17:15:36 <rhallisey> sdake, cool
17:15:36 <pbourke_> swift -> started but slow, hope to have something up before midcycle
17:15:41 <inc0> I don't mind if they're close to dead as well
17:15:41 <sdake> oh wait
17:15:44 <sdake> pbourke_ going
17:15:49 <pbourke_> v. busy this week before I travel for midcycle
17:16:05 <pbourke_> whats that stake?
17:16:13 <rhallisey> pbourke_, cool thanks
17:16:15 <pbourke_> (heh, auto correct)
17:16:21 <sdake> pbourke_ i meant you were speaking now
17:16:32 <sdake> mistake ;)
17:16:33 <pbourke_> ok that's me done :)
17:16:33 <sdake> thats my other nickname :)
17:16:39 <rhallisey> ok moving on
17:16:43 <rhallisey> #topic Open Discussion
17:16:49 <SamYaple> i need to bring somehting up here
17:16:56 <SamYaple> this patch https://review.openstack.org/#/c/274154/ please comment away on it
17:17:02 <SamYaple> its had some convterasy already
17:17:18 <SamYaple> thats all for me (i think)
17:17:42 <sdake> SamYaple 20 second review i am in favor of a rename
17:17:47 <sdake> i'll dig more into it
17:17:54 <rhallisey> ya that wfm
17:17:58 <jpeeler> +1
17:18:03 <inc0> rename is cool if we provide migration plan
17:18:03 <SamYaple> well coment there :P
17:18:08 <inc0> which shouldn't be hard
17:18:17 <sdake> SamYaple let me properly review it buti will do so after this meeting
17:18:18 <SamYaple> inc0: thats discussed in the review
17:18:18 <inc0> just remove old and create new container
17:18:22 <SamYaple> yup
17:18:32 <SamYaple> idempotent remove FTW
17:18:44 <rhallisey> cool, anyone have anything else?
17:18:50 <inc0> this container doesn't do anything anyway, it just sits there after bootstraps and all
17:18:51 <nihilifer> how we'll do that removal/creation? by some playbook or wat?
17:18:56 <nihilifer> what*
17:19:05 <SamYaple> nihilifer: yea in line playbook
17:19:08 <SamYaple> its idempotent
17:19:11 <inc0> nihilifer, upgrade play would be my guess
17:19:17 <SamYaple> not a sperate playbook
17:19:24 <nihilifer> k
17:19:35 <inc0> upgrade will remove old container and add new, easy
17:19:42 <inc0> deploy will just well...deploy
17:19:43 <SamYaple> like sunday morning
17:19:49 <elemoine> should it be part of the patch then?
17:19:56 <SamYaple> no
17:20:00 <inc0> whatever
17:20:09 <inc0> as long as it lands in the cycle
17:20:10 <SamYaple> we dont have common upgrade playbook yet
17:20:16 <SamYaple> but we will
17:20:23 <inc0> well we kinda do
17:20:30 <inc0> I mean we will
17:20:38 <sdake> SamYaple  you mean common between mesos and ansible?
17:20:41 <inc0> and you might as well start;)
17:20:43 <elemoine> ok
17:20:48 <inc0> sdake, common as common role
17:20:50 <SamYaple> sdake: common role
17:20:54 <sdake> got it
17:20:59 <SamYaple> oh hey i do have another topic
17:21:00 <inc0> kolla_ansible, rsyslog
17:21:03 <sdake> ya
17:21:08 <SamYaple> kolla-mesos and kolla-ansible and kolla overlap
17:21:12 <SamYaple> nihilifer: ^
17:21:18 <sdake> fix upgrades
17:21:23 <sdake> then we fix repos
17:21:44 <inc0> yeah lets move repo shuffling for N please
17:21:57 <nihilifer> yes, it's not that urgent for me as well
17:22:40 <rhallisey> I'd like it for M, but upgrades have prio here
17:22:42 <sdake> i am not opposed to moving the repos around for mitaka, it can be done we have the capacity, but i absolutely want upgrades done first before any repo movement takes place
17:23:06 <jpeeler> i don't think anybody can disagree with that
17:23:33 <SamYaple> thats no the overlap i was tlaking about specifically
17:23:36 <SamYaple> but yes to all of that
17:23:46 <SamYaple> i was talkign about the tool and python code overlap
17:23:51 <SamYaple> mesos dups _alot_ of code
17:24:00 <SamYaple> code that exists in the kolla (not kolla-ansible) repo
17:24:03 <sdake> and that is fixed how SamYaple ?
17:24:09 <SamYaple> import kolla
17:24:16 <SamYaple> rather than being its own code
17:24:17 <sdake> right, so repo shuffle?
17:24:22 <SamYaple> no...
17:24:29 <SamYaple> no need to split repo to do what i say
17:24:36 <sdake> ok cool then
17:24:41 <sdake> i'm good with that kind of change
17:24:48 <sdake> as long as it doesn't slow down upgrades :)
17:24:50 <SamYaple> nihilifer: need your thoughts on this
17:24:57 <inc0> yeah, this is clean
17:25:00 <SamYaple> nothing to do with upgrades sdake
17:25:12 <sdake> i understand
17:25:32 <sdake> I just want to be crystal clear on this point folks - if we don't deliver upgrades in mitaka, it won't be pretty for us
17:25:46 <sdake> the community will lose trust in our ability to execute which right now the ythink we are rockstars
17:25:50 <nihilifer> SamYaple: ok, i think we can try with importing kolla
17:25:54 <sdake> the operators wont take us seriously
17:26:03 <sdake> so upgrades, upgrades, upgrades
17:26:03 <nihilifer> and in some fat future think about better way of sharing commons
17:26:08 <SamYaple> nihilifer: cool no rush, i justdon't want to deverge to much
17:26:27 <inc0> sdake, please do talk to your docker people, that's single biggest issue I have with upgrades now
17:26:32 <SamYaple> well if kolla-mesos has a dep on kolla then this should work easy for sharing... no?
17:26:55 <inc0> I'm ok if that will happen in N cycle for us, noone runs Mitaka from day one anyway
17:27:10 <inc0> but we need to be able to upgrade docker without restarting qemu imho
17:27:37 <nihilifer> SamYaple: not exactly - they may be problems with sharing commons between kolla-ansible and ansible just for deploying mesos
17:27:50 <nihilifer> and in deep N development - for k8s probably
17:27:55 <sdake> inc0 i got people working on that
17:27:59 <nihilifer> but that's something to think about in N
17:28:03 <sdake> inc0 but fwiw its out of our control
17:28:10 <SamYaple> nihilifer: yea im not sure about that part, i was refering to scripts and common.py and such
17:28:33 <nihilifer> yep, for strictly pythonic stuff, importing kolla may work
17:28:39 <inc0> sdake, I know that it will be tricky, I moved some string on my end as well
17:28:42 <rhallisey> 2 minutes guys just an fyi
17:28:54 <SamYaple> ok im out! see you in #kolla
17:28:56 <inc0> but if we force people to restart vms for upgrade..that will be bad.
17:29:01 <inc0> imho
17:29:18 <Guest44587> inc0: +1
17:29:20 <sdake> ok folks thanks for coming :)
17:29:20 <inc0> I've been on too many ops summit upgrade sessions to say it won't
17:29:21 <rhallisey> let's spill over to kolla
17:29:27 <sdake> inc0 +0 atm :)
17:29:33 <rhallisey> thank you everyone
17:29:36 <inc0> thanks
17:29:36 <rhallisey> :)
17:29:39 <rhallisey> #endmeeting kolla