16:00:08 <dhellmann> #startmeeting oslo
16:00:09 <openstack> Meeting started Fri Oct 10 16:00:08 2014 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:12 <openstack> The meeting name has been set to 'oslo'
16:00:20 <dhellmann> who's arround for the oslo meeting?
16:00:33 <jecarey> o/
16:00:44 <ozamiatin> o/
16:00:46 <kgiusti> o/
16:00:47 <harlowja_at_home> \o
16:00:50 <bknudson> hi
16:01:26 <dhellmann> beekneemech, dimsum_, jd__, sileht: ping
16:01:34 <beekneemech> o/
16:01:37 <jd__> pong
16:01:37 <dhellmann> viktors: ping
16:01:42 <i159> o/
16:01:49 <viktors> here, hi all!
16:01:54 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
16:01:56 <dimsum_> o/
16:02:31 <zzzeek> o/
16:02:37 <dhellmann> hi, all
16:02:45 <dhellmann> #topic changing meeting time
16:02:55 <dhellmann> if you haven't already done so, please vote in the doodle poll
16:02:56 <dhellmann> #link http://doodle.com/zv8izg7ymxcank34
16:03:05 <dhellmann> so far it looks like monday is the top contender
16:03:52 <dhellmann> liaisons, please let us know as well, since there's no point in scheduling a meeting for a time when most of you can't come :-)
16:04:11 <dhellmann> #topic review action items from previous meeting
16:04:23 <dhellmann> #info rpodolyaka set up a doodle with proposed times for our weekly meetings - done
16:04:30 <dhellmann> #info dimsum_ review kilo lib plan and resolve open questions that have been answered
16:04:33 <dhellmann> dimsum_: ?
16:04:45 <dhellmann> that's for:
16:04:46 <dhellmann> #link https://etherpad.openstack.org/p/kilo-oslo-library-proposals
16:05:24 <dimsum_> dhellmann: got a bit more clarity, example we can't get rid of crypto
16:05:37 <dimsum_> etherpad is updated
16:05:46 <dhellmann> dimsum_: ok, good progress
16:06:04 <dimsum_> dhellmann: one question i had was do we want to do oslo.io?
16:06:33 <dimsum_> https://bugs.launchpad.net/oslo.concurrency/+bug/1374559
16:06:34 <uvirtbot> Launchpad bug 1374559 in oslo.concurrency "Switch to oslo.io when it graduates" [Low,Triaged]
16:06:41 <dhellmann> #link https://wiki.openstack.org/wiki/Oslo/GraduationStatus#oslo.io
16:07:18 <dhellmann> #link https://wiki.openstack.org/wiki/Oslo/Dependencies
16:07:38 <dhellmann> acoording to that diagram, both oslo.policy and oslo.concurrency depend on oslo.io
16:07:53 <dhellmann> I think the reason oslo.io exists is to make sure that dependency is safe
16:09:09 <dhellmann> the notes in the wiki say that the API needs work to make it easier to mock them
16:09:27 <dhellmann> maybe we can do something with test fixtures?
16:09:50 <dhellmann> dimsum_: are you asking "should we do it in kilo" or "should we do it at all" or "should it be its own library"?
16:10:01 <dimsum_> the latter
16:11:29 <dhellmann> dimsum_: ok, like I said, I think the reason there is to ensure that we have a way to control dependencies. I guess we could just put it into oslo.utils, but we don't want that to be a dumping ground that causes huge dependency bloat for anything that uses it
16:12:13 <dimsum_> ack
16:12:37 <dhellmann> dimsum_: were you blocked on answering any of the other questions?
16:12:44 <dimsum_> dhellmann: nope
16:13:55 <dhellmann> dimsum_: looking at the oslo.utils section of the etherpad, I think the same reasoning applies to imageutils and versionutils
16:14:43 <dhellmann> #info dhellmann schedule a chat with superdan about nova objects -> oslo transition -- done
16:14:45 <dimsum_> dhellmann: ack. will rework
16:14:55 <dhellmann> #undo
16:14:55 <openstack> Removing item from minutes: <ircmeeting.items.Info object at 0x31aa2d0>
16:15:06 <dhellmann> dimsum_: ok, thanks
16:15:09 <dhellmann> #info dhellmann schedule a chat with superdan about nova objects -> oslo transition -- done
16:15:25 <dhellmann> I spoke with dan yesterday, and he's going to write up a spec for kilo.
16:15:32 <superdan> dhellmann: it's up
16:15:47 <superdan> https://review.openstack.org/#/c/127532/
16:16:00 <dhellmann> superdan: cool, thanks!
16:16:01 <superdan> probably has some skimpy sections that people want more detail in
16:16:20 <dhellmann> yeah, we can work through the details
16:17:06 <dhellmann> this was on our list of potential summit topic sessions, but I'm not sure if we need a whole session to discuss it
16:17:16 <dhellmann> does anyone feel strongly that we need to have a f-2-f discussion?
16:18:15 <beekneemech> I don't, but I wasn't the one who had concerns about it.
16:18:57 <dhellmann> I can't tell who that was, "JH"? Is that harlowja_at_home ?
16:19:03 <dhellmann> #link https://etherpad.openstack.org/p/kilo-oslo-summit-topics
16:19:14 <harlowja_at_home> likely me
16:20:05 <dhellmann> ok. This code is already being shared, so we want to get it out of nova and into a better form for sharing.
16:21:02 <harlowja_at_home> fair enough for that, i was just not convinced that the only way to do upgrades was via this
16:21:59 <dhellmann> I'm sure there are other ways to build completely different things to do this. We have this already.
16:22:09 <beekneemech> That ^ :-)
16:22:18 <dhellmann> also, this isn't about the database, it's about the rpc messages
16:22:42 <dhellmann> it's not clear from the comments there whether everyone understood that
16:22:46 <harlowja_at_home> yup, which is why i think having it as a library is fine
16:22:59 <dhellmann> k, just making sure we're all on the same page
16:23:24 <dhellmann> ok, so unless we have a lot of disagreement between now and the summit over that spec, I think we can proceed without a summit session
16:23:38 <dhellmann> #topic summit session planning
16:23:41 <harlowja_at_home> well the comments got into upgrades + objects, which is 2 things, just objects themselves sure seems ok
16:24:12 <dhellmann> our primary purpose for today is to figure out what topics we *do* think we need to discuss more deeply at the summit
16:24:13 <dhellmann> #link https://etherpad.openstack.org/p/kilo-oslo-summit-topics
16:24:38 <dhellmann> we have 7 scheduled session slots, and a "pod" table similar to what we had in atlanta
16:24:56 <dhellmann> we will have the pod all week, but won't have a "meetup room" like some of the other projects on friday
16:25:13 <dhellmann> we'll be able to use the pod instead, but obviously it won't hold as many people
16:25:26 <dhellmann> and also I expect some of us to need to go to those other sessions on friday
16:26:15 <dhellmann> should we go through the list top to bottom?
16:26:29 <beekneemech> Might as well.
16:26:50 <dhellmann> k, for namespace packages, I'm testing some approaches right now
16:27:07 <dhellmann> I have a WIP patch for oslo.i18n to move it to oslo_i18n
16:27:23 <dhellmann> my idea is to *not* rename the lib or package, just the python package directory, if that distinction makes sense
16:27:58 * beekneemech still needs to look at that change
16:28:08 <dhellmann> the consensus *outside* of the team is we should stop using ns packages, I think, so I don't know if we need to schedule time to talk about this when others can participate
16:28:24 <zzzeek> i wish we could just make ns packages work b.c. i do like the concept
16:28:26 <dhellmann> I'm going to try to write up a spec before the summit, if I get a working version
16:28:53 <dhellmann> zzzeek: yeah, I do, too. every time we get it to work, it seems to break in another way, though :-/
16:29:05 <dhellmann> zzzeek: fwiw, it was my idea to use them in the first place
16:30:06 <dhellmann> bknudson, can you give us more info about "Obfuscation / encryption of config options (Maybe called pluggable loader for config"
16:31:00 <dhellmann> that looks to me like something we can handle with a spec
16:31:13 <dhellmann> thoughts?
16:31:28 * dhellmann wonders if there is network lag today
16:31:59 * beekneemech thinking
16:31:59 <jd__> I read you dhellmann
16:32:52 <beekneemech> IIRC, the tough part of the encryption bit was figuring out who is responsible for the keys.
16:33:13 <dhellmann> true
16:33:13 <beekneemech> And I'm still largely opposed to just obfuscating because it's a false sense of security.
16:33:53 <dhellmann> yeah
16:34:13 <dhellmann> maybe we do need to talk about this
16:34:16 <harlowja_at_home> ohhh, pluggable loader for config, y! security folks will be much happier with that
16:34:30 <beekneemech> So my memory is fuzzy, but was barbican being a thing we could use basically the prereq for this?
16:34:46 <dhellmann> that sounds familiar, yeah
16:34:51 <dhellmann> and/or kite?
16:36:32 <dhellmann> #action dhellmann ask bknudson and morganfainberg to provide more detail for config encryption plans
16:36:46 <dhellmann> we've already talked about nova objects
16:36:59 <harlowja_at_home> ya, feel free to add me, i can pull in some yahoo folks that might be interested in this (or giving feedback)
16:37:03 <dhellmann> harlowja_at_home, what did you have in mind for "dive into taskflow"?
16:37:27 <zzzeek> im usually -1 on config encryption, the best you can do is put the sensitive parts of config into a file that is only readable by the application user
16:37:44 <harlowja_at_home> well we can talk about what it is, not sure everyone is aware of that, what it can do, the usage of oslo.db when thats ready and oslo.messaging and such if we want to go there :)
16:38:13 <dhellmann> harlowja_at_home: ok, I don't think we're going to have time/space this summit for "status" or "what it is" type sessions, unfortunately
16:38:21 <dhellmann> we should talk about the other stuff, though
16:38:39 <dhellmann> I'd like to get to a point where taskflow isn't rebuilding parts of other oslo libraries to avoid having dependencies on those libraries
16:39:09 <harlowja_at_home> sure, oslo.db and such i'm fine with using when it's ready for python3.x, its a simple chop off like 100 lines of code
16:39:14 <harlowja_at_home> oslo.messaging is a different story
16:39:16 <harlowja_at_home> but sure
16:40:30 <dhellmann> if we need to talk about additions to oslo.messaging, we can do that
16:40:56 <harlowja_at_home> well its not the additions part, its the question of the concepts of the 2 are different :)
16:41:08 <dhellmann> I think what bothered me was when I saw some changes in taskflow to fix bugs in things that were close to features of oslo.messaging already
16:41:46 <harlowja_at_home> sure, but then u could say the same about any library user of kazoo
16:41:48 <dhellmann> that's what I mean -- the API now supports rpc and notifications so if you need some other pattern we should see about adding that
16:41:50 <harlowja_at_home> *i mean kombu
16:43:13 * dhellmann is looking for his notes on this
16:44:43 <harlowja_at_home> so i can go over the differences at the summit, why taskflow just uses kombu for its worker-engine and why, and what its doing with kombu, and we can all discuss what oslo.messaging might need to do for that model (besides the obvious ones like lack of py3.x support)
16:46:00 <harlowja_at_home> ^ although i'm not a big fan of a layer like oslo.messaging which brings in a bunch of stuff taskflow wouldn't use to save a small amount of common code that it could use
16:46:33 <dhellmann> maybe it was the dispatcher code I was looking at?
16:47:04 <dhellmann> I don't know. I'll look for my  notes and update the etherpad
16:47:10 <harlowja_at_home> possibly, so i think we can have a session to discuss this, ya?
16:47:32 <dhellmann> let's see what else we need to talk about, but yeah, looks like this is probably one
16:47:53 <dhellmann> how about the zeromq issue?
16:48:15 <i159> dhellmann: what the issue?
16:48:20 <beekneemech> Seems to me we need a gap analysis like they did for some of the other projects this cycle.
16:48:50 <dhellmann> we had some people interested in helping with this, but I don't see many patches yet
16:49:18 <beekneemech> So "X, Y, and Z are missing, they need to be done by $TIME or else"
16:49:31 <dhellmann> we could probably roll this into the discussion of moving oslo.messaging drivers out of the tree, too
16:49:42 <dhellmann> if we think we need to discuss both topics
16:49:43 <kgiusti> +1
16:49:46 <beekneemech> Because this has been a problem almost forever - people say they'll fix it, but it doesn't happen.
16:50:01 <dhellmann> beekneemech: agreed
16:50:02 <i159> dhellmann: Are we talking owerall zeromq problems in messaging?
16:50:19 <i159> I have some patches for zmq driver
16:50:22 <dhellmann> i159: zeromq does not, as far as we know, work with oslo.messaging. The version in the incubator did work at some point.
16:51:13 <dhellmann> i159: links? I see a couple in https://review.openstack.org/#/q/project:openstack%2Foslo.messaging+is:open,n,z
16:51:48 <dhellmann> ah, I see, some don't have zeromq in the subject so they weren't obvious at first
16:52:19 <i159> https://review.openstack.org/#/c/124099/ this is the end of chain
16:53:11 <i159> Actually, me and ozamiatin working on messaging now. If you need some help, feel free to ping us
16:53:40 <dhellmann> i159: we can always use help with code reviews
16:54:03 <dhellmann> sileht agreed to manage the library, but he can only do so many reviews himself :-)
16:54:16 <dhellmann> so, does this need a summit session?
16:54:31 <i159> dhellmann: Yep, I'm in it. But I feel some lack of attention to my patches... :(
16:55:18 <beekneemech> We're way short on reviewers who understand oslo.messaging. :-(
16:55:25 <dhellmann> right, that's the issue
16:56:00 <dhellmann> we're almost out of time today, let's finish this one: Do we need a session to discuss zeromq support?
16:56:26 <dhellmann> I hate to burn a session on it if we don't know who's going to be there for it
16:56:27 <dimsum_> not really unless there's anyone to work on it? right?
16:56:33 <dimsum_> ack
16:56:49 <beekneemech> How about a spec detailing what needs to be done to get it working/tested?
16:57:06 <dhellmann> I would love to have someone who understands the driver write that.
16:57:23 <harlowja_at_home> can/should we talk about how to get more reviews for oslo.messaging (this scares me for having taskflow depend on it honestly)
16:57:32 <harlowja_at_home> *reviewers/maintainers...
16:57:50 <beekneemech> This kind of goes with the splitting drivers topic.
16:58:12 <beekneemech> In theory that was supposed to help with the limited reviewer issue.
16:58:18 <dhellmann> I'm reluctant to split the repo up into more pieces if we don't have anyone to review what we have now
16:58:36 <dhellmann> it would be one thing if just one or two drivers were having issues with reviews, but that's not the case
16:59:01 <beekneemech> I would tend to agree, but I thought that was part of the intent behind the suggestion.
16:59:23 <dhellmann> yeah, I just don't know if it will play out that way
16:59:29 <dhellmann> ok, we're out of time for tday
16:59:34 <beekneemech> So maybe we need to have a "what to do about oslo.messaging" session.
16:59:36 <dhellmann> we'll continue this next week
16:59:43 <dhellmann> I won't change the time of the meeting until after the summit
16:59:55 <i159> I can brin couple of our guys to review messaging. but they are not in it
16:59:56 <harlowja_at_home> kk, good to know
16:59:57 <dhellmann> beekneemech: yeah, as harlowja_at_home suggested, maybe we can find more reviewers
17:00:07 <i159> *bring
17:00:48 <i159> the problem is lack of core reviewers attention...
17:01:52 <dhellmann> i159: yep, we need to work that out, but I think if I saw more good reviews happening I would be inclined to add people to the review team
17:01:59 <dhellmann> we should clear the room for the next group
17:02:02 <dhellmann> thank you all!
17:02:33 <dhellmann> #endmeeting