20:00:37 <SpamapS> #startmeeting arch_wg
20:00:38 <openstack> Meeting started Thu Jan 12 20:00:37 2017 UTC and is due to finish in 60 minutes.  The chair is SpamapS. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:41 <openstack> The meeting name has been set to 'arch_wg'
20:00:56 <SpamapS> Courtesy ping for nikhil, harlowja, dstanek, kragniz, auggy, rockyg, rocky_g, kgiusti
20:01:01 <ttx> hello hello
20:01:12 <SpamapS> #link https://wiki.openstack.org/wiki/Meetings/Arch-WG#Agenda
20:01:18 <SpamapS> ttx: thanks for coming!
20:02:05 <SpamapS> I was hoping more would o/ given that we're kicking off 2017 :)
20:02:25 <cdent> o/
20:02:32 <ttx> ah
20:02:35 <harlowja> yo
20:02:37 <SpamapS> huzzah, we've 4
20:02:53 <SpamapS> #topic previous meeting action items
20:03:06 <SpamapS> #link http://eavesdrop.openstack.org/meetings/arch_wg/2016/arch_wg.2016-12-15-20.03.html
20:03:08 <cdent> even with that "we're gonna gossip about nova" invite
20:03:10 <ttx> FWIW I pushed https://review.openstack.org/#/c/419402/ so that arch_wg changes are mentioned on channel
20:03:12 * cdent is disappoint
20:03:28 * SpamapS SpamapS email proposed arch-wg repo process to openstack-dev
20:03:33 <SpamapS> ttx: SWEET thanks
20:03:50 <SpamapS> cdent: right? I figured we'd at least get some haters. :)
20:04:07 <ttx> we need "container" in every title
20:04:12 <SpamapS> I did in fact email openstack-dev and I think at this point we're more in the "let's try the process out" phase.
20:04:18 <SpamapS> ttx: *ding ding*
20:04:29 * cdent drinks
20:04:30 * SpamapS SpamapS write up nova-compute rant as a proposal to arch-wg repo
20:04:41 <SpamapS> I did that, and it's in the repo now yay
20:04:50 <cdent> got some nice responses
20:05:13 <SpamapS> Indeed, I think with the two proposals we have we'll be kept quite busy through Q1
20:05:14 <harlowja> SpamapS there is a nova-compute rant?
20:05:16 <harlowja> where where
20:05:16 * SpamapS Rockyg to write up implementation bleed-through thoughts and submit to arch-wg repo
20:05:34 <SpamapS> harlowja: http://git.openstack.org/cgit/openstack/arch-wg/tree/proposals/nova-compute-api.rst
20:05:45 <harlowja> kk, thx
20:05:48 <SpamapS> I don't see a rockyg, so we'll have to carry that one
20:06:16 <SpamapS> #action Rockyg to write up implementation bleed-through thoughts and submit to arch-wg repo (carried from December 2016)
20:06:44 <SpamapS> and finally
20:06:46 * SpamapS SpamapS send message to openstack-dev cancelling further 2016 meetings.
20:06:48 <SpamapS> did that one.
20:06:51 <harlowja> woot
20:06:52 <harlowja> ha
20:06:59 <SpamapS> #topic Proposal Process Review
20:07:24 <SpamapS> So, what do people think? Do we have a well defined process that is working? Any tweaks needed?
20:07:55 <ttx> I've been wondering how to move forward on base services and here is what I came up with
20:07:58 <SpamapS> I feel like we're still in the alpha test phase so it's a bit of a moving target anyway
20:08:22 <ttx> I added a "proposed implementation" to the proposal so that people know what that would trigger in practice
20:08:23 <cdent> I think the "how to make a proposal for discussion" part it is pretty clear (because we've done it) but happens next less so (because we haven't)
20:08:28 <ttx> then will star ta ML thread on it
20:08:39 <harlowja> i'd like my bikeshed red
20:08:42 <harlowja> lol
20:08:48 * harlowja runs away
20:08:51 <ttx> and after that we can amend and approve or throwaway
20:09:07 <ttx> since that one is pretty basic we can use it to test the process
20:09:30 <ttx> the only thing that is bikesheddable would be the narrow/wide approach
20:09:40 <ttx> but arguably not directly ties to the proposal
20:09:44 <ttx> tied*
20:10:31 <ttx> (a bit orthogonal)
20:11:19 <SpamapS> so, the way I've envisioned it, the proposal is just for "do we have a basic idea of what needs to be understood, and enough people who think they could work on it?"
20:11:43 <SpamapS> Once we agree on that, we rename it into active, and we start to add action items and assigned people.
20:12:03 <ttx> ah, ok. I guess we should move it to active first then
20:12:12 <ttx> Frankly, it's a 1.1 person job
20:12:19 <ttx> 0.1 being +2A on reviews
20:12:29 <SpamapS> Hah yeah
20:12:43 <SpamapS> well I think the actions will be some openstack specs, and maybe a community goal.
20:12:45 <ttx> the main work being to push the thing through the TC washing machine
20:13:01 <ttx> in that case it's just a definition
20:13:27 <SpamapS> but before we go deep on that (which I htink we should!) .. does that process sound good? ANd if we do that, do we want to try and land all supporting documentation in not-arch-wg specs, or do we also want to publish our own findings?
20:13:32 <ttx> we just name the thing that already exists
20:13:57 <ttx> process sounds ok. I just think I skipped a step
20:14:12 <cdent> I think for most important things that we want to do the critical piece is publishing why the status quo is not good enough. Without that, nothing will happen.
20:14:40 <ttx> cdent: yes, we probably need some template of the answer the proposal must answer
20:14:56 <ttx> including why the status quo is not satisfactory
20:15:16 <ttx> "why the change"
20:15:28 <cdent> sadly I think that's also the part that will be most contentious and subject to mystical thinking
20:15:32 <SpamapS> Right, so the basic sequence I want to see is "Raise a topic (base-services), agree it's important enough to track, document the current state of things, including problem statements, and then propose specs for addressing said problems, once specs are complete, proposal is considered "done"
20:16:19 <SpamapS> and the idea is that we keep checking in on status and raising awareness and finding resources to help complete each stage.
20:16:23 <cdent> do you imagine a timetable on those things?
20:16:42 <cdent> sort of three cycles, or something like that?
20:16:44 <cdent> 2 months
20:16:47 <cdent> 5 years
20:16:47 <cdent> etc
20:16:51 <cdent> :)
20:16:56 <ttx> SpamapS: while the proposal can be free-form, I think active topics will have to follow some templates, which we'll have t odefine
20:16:58 <SpamapS> I think it's going to be like any other EPIC story.. the pieces will have time tables, but the whole thing will be murky until late in the story.
20:17:29 <SpamapS> ttx: +1 for that. Do you want to define it by morphing base-services into an active workstream?
20:17:49 <SpamapS> (workstream sounds really weak.. what do we call them? We could still keep them as "proposals".. RFC?)
20:18:01 <ttx> SpamapS: my fear is that base-srevices is a bit of a corner case. A siple one, but still not a classic example
20:18:06 <ttx> simple*
20:18:21 <SpamapS> ttx: we can both take a stab at it, you with base-services and me with nova-compute-api
20:18:34 <ttx> ack, let's come up with somethig more detailed and then regroup
20:18:36 <SpamapS> then try and converge on a template from what we learn trying to structure those
20:18:43 <ttx> exactly
20:19:12 <SpamapS> #action ttx and SpamapS to transform their proposals into active {somethings}
20:19:23 <SpamapS> with that...
20:19:31 <SpamapS> #topic Proposals for work
20:19:39 <SpamapS> * Base Services - ttx
20:20:03 <ttx> Waiting for it to be active to move to next step
20:20:26 <ttx> unless people want more details
20:20:41 <SpamapS> #info base-services is approved for active work
20:20:45 <ttx> woohoo
20:20:45 <SpamapS> how about that?
20:21:01 <ttx> well, we need to move it physically to active/
20:21:04 <SpamapS> since you already have an action to convert it, we won't assign more redundant items
20:21:07 <ttx> but I can propose that
20:21:12 <SpamapS> but typically I think here we'd assign somebody to do the conversion
20:21:32 <SpamapS> Yeah I think approved things can sit in proposal until the assigned person/team/etc. converts it to active
20:21:48 <ttx> #action ttx to move base-services to active and complete the details
20:22:04 <SpamapS> git kinda sucks for rename tracking though.. so we might want to do a rename-only commit just to keep the breadcrumbs.
20:22:17 <ttx> will do
20:22:21 <SpamapS> kk
20:22:29 <SpamapS> * nova-compute-api - SpamapS
20:22:29 <ttx> what I meant by "move"
20:22:34 <SpamapS> ttx: indeed
20:22:58 <SpamapS> hang on I'm going to just squawk in #openstack-dev about the fact that we're talking about this now
20:23:19 <ttx> so this one represents more work, not sure one person can rnu wit hit
20:23:24 <ttx> run with it
20:23:47 <SpamapS> Agreed
20:23:55 <ttx> while we are waiting, small reminder that the Arch WG day at the PTG will be on the Tuesday
20:24:10 <SpamapS> The interest level on this one tells me it is worth it to at _least_ go through the act of documenting how it works now.
20:24:38 <SpamapS> ttx: thanks. I just got my travel approval today, so I'll book soon. :)
20:24:41 * cdent is sad to miss the ptg
20:24:43 <ttx> the way I see it, we can discuss the active proposals, then pump the backlog
20:25:20 <ttx> cdent: miss by choice or necessity ?
20:25:23 <SpamapS> ttx: I also think we should get matching Architecture-COP hats and ticket people for discussing deep new ideas in the hallways. (The ticket will be an invite to this meeting) ;)
20:25:36 <cdent> ttx funding/timing
20:25:53 <SpamapS> ok nobody's biting I think. :)
20:26:32 <SpamapS> so this proposal.. the way I see it, the first action would be to go through all of the ways that compute hosts _currently_ interact with the rest of OpenStack, and document them with diagrams and basic descriptions.
20:26:37 <ttx> SpamapS: the appropriate way is to drop the bomb on the keynote stage
20:26:48 <cdent> I think I can play a fun role in this discussion: a regular nova contributor and a guy who thinks nova-compute should be its own repo
20:27:02 <SpamapS> cdent: YES you are my best friend now.
20:27:33 <cdent> the first person thinks: when in the universe will anyone ever find the time to do this
20:27:47 <cdent> the second person thinks: more better faster sooner yes please now
20:28:00 <SpamapS> so, once that documentation is completed, I would expect some problems to be readily apparent, including race conditions and circular dependencies in the system that make it hard to refactor anything.
20:30:27 <cdent> I recall from BCN that some of the detractors suggested that this was all a lot harder than anyone was imagining so the documentation will definitely be interesting
20:30:47 <SpamapS> Well yeah, we could just get 50% done and then give up. ;)
20:30:56 <SpamapS> Though that, IMO, _is the problem_
20:31:05 <SpamapS> that it's so twisty and fraught with danger
20:31:17 <SpamapS> I'm perfectly comfortable with this taking half a year to document.
20:31:38 <SpamapS> Because I'd like to include interviewing folks from each project that has agents on the compute node
20:31:49 <cdent> that's a good idea
20:31:52 <SpamapS> so, Neutron, Cinder, drivers, Ironic, etc.
20:32:36 <SpamapS> so I'll take the action to convert it into an active {thing} and in so doing I'll have this action item to begin with, and many more will spring from it:
20:32:37 <cdent> btw, apparently ceilometer has given up on interacting with nova for its polling and now is going to do its own thing. I haven't got any details on that though, just heard about it couple days ago
20:33:12 <cdent> (re "agents on the compute node")
20:33:26 * SpamapS enumerate every agent that runs on compute hosts.
20:33:43 <SpamapS> cdent: good point about ceilometer
20:33:45 <SpamapS> ok
20:34:05 <SpamapS> #info nova-compute-api is approved for a move to active status
20:34:07 <SpamapS> Agreed?
20:34:13 <SpamapS> I should learn the bot
20:34:17 <SpamapS> I think there's an #agree
20:34:37 <ttx> there is
20:34:42 <SpamapS> #action SpamapS to move nova-compute-api to active status and add structure
20:35:02 <cdent> \o/
20:35:10 <SpamapS> #topic Open Discussion
20:35:33 <SpamapS> One thing I also wonder about is how people feel about my email where I admonish people to please start these discussions on the mailing list.
20:35:51 <harlowja> a general question (maybe resolves into a proposal) but something i don't quite understand, is that if openstack has more private cloud usage now (vs public clouds), why would most of those private clouds want the complexity that neutron offers
20:35:58 <ttx> Re: PTG, we could set up an etherpad, although the content will likely be pretty simple
20:36:07 <SpamapS> My thinking there is that a 1 hour meeting every two weeks isn't going to be enough to fully discuss some of these things, and review comments are too pragmatic to allow free thought.
20:36:36 <SpamapS> harlowja: Funny, I'd have put Neutron in the "things only private clouds would want" category. :)
20:36:37 <ttx> SpamapS: could do some ad-hoc meetings for specific active topics
20:36:42 <cdent> I agree that more email discussion would be grand, but there seem to be forces working against that
20:36:59 <harlowja> SpamapS maybe it goes into the question of 'who would want this in private or public'
20:36:59 <cdent> the lack of free thought email has been my number one complaint about the openstack community from when I started (and remained so)
20:36:59 <harlowja> lol
20:37:09 <ttx> SpamapS: I see the regular meeting as a checkpoint for progress, not where the work gets done so much
20:37:26 <SpamapS> cdent: I believe the summits have contributed to that somewhat.
20:37:42 <ttx> each group working on each active problem should schedule their own time on #openstack-architecture to make progress
20:38:02 <ttx> I'll meet all day tomorrow with my 1.1-person team on base-services :)
20:38:06 <SpamapS> ttx: Agreed, and that's a good idea, as a topic grows, we would definitely be served by saying "if you're working on this effort go to just this meeting"
20:38:13 <harlowja> SpamapS cdent i can ask the "who would want the complexity of neutron on the ML" though i'm not sure it will be helpful, lol
20:38:28 <harlowja> i don't mind getting flamed, lol
20:38:31 <SpamapS> harlowja: no you SHOULD ask it
20:38:39 <SpamapS> I actually think flames are part of the free thought
20:38:49 <SpamapS> Neutron was conceived of a _long_ time ago.
20:38:58 <SpamapS> With a different set of market forces.
20:38:59 <cdent> harlowja: I think cloud like you have and want it is _much_ different from cloud how telcos want it?
20:39:11 <SpamapS> It's entirely possible nobody will stand up and say they love it.
20:39:18 <cdent> "I actually think flames are part of the free thought" <- /me saves that for later
20:39:28 <harlowja> fair nuff
20:39:37 <harlowja> i shall put on my flame suit and send something, lol
20:39:47 <clarkb> fwiw infra has seen a lot of resistsance around the idea that compute instances should just get IPs and talk to the internet
20:40:09 <SpamapS> clarkb: well, that's like, the extreme conservative stance
20:40:11 <clarkb> so there are definitely people out there that want to micromanage every little networking detail, hopefully they chime in should you raise the question
20:40:56 <SpamapS> Well I think most will be in that NFV space.
20:41:01 <clarkb> no
20:41:03 <clarkb> thats my point
20:41:13 <clarkb> infra isn't trying to do anything NFV we just want compute hosts with networking
20:41:21 <clarkb> and that is suprisingly difficult to accomplish
20:41:26 <harlowja> ya infra is like a good example imho
20:41:30 <SpamapS> Right, I mean, most who want to micro-manage their L2's will be in NFV.
20:41:40 <SpamapS> As in "not the kind of thing infra does at all"
20:41:55 <clarkb> SpamapS: right, but when we go to a cloud interested in contributing we say this is what we want l3 that works
20:42:00 <clarkb> they run away screaming half the time
20:42:12 <clarkb> because what they want to give are managed l2s with little holes punched
20:42:22 <clarkb> and we see that often outside of nfv
20:42:33 <clarkb> (just trying to point out its not an nfv specific thing)
20:43:06 <SpamapS> Yeah, enterprises are probably equally weird for equally confusing compliance reasons. :-P
20:43:06 <clarkb> and hopefully they will talk about it publicly if asked
20:43:49 <SpamapS> I also think Neutron isn't actually that complex, ml2 just conflates with Neutron and you get a double whammy of moderate complexity.
20:44:35 <harlowja> ya, i guess i just don't understand who would want to manage there own networks, there own subnets, there own ports ...
20:44:42 <SpamapS> their
20:44:44 <SpamapS> theirrrrrr
20:44:46 <SpamapS> sorry
20:44:48 <harlowja> ther
20:44:48 <SpamapS> twitch
20:44:49 <harlowja> lol
20:44:53 <SpamapS> thur? ;)
20:44:55 <ttx> le theire
20:44:56 <harlowja> thar
20:45:26 <ttx> le lol
20:45:32 <SpamapS> I think most of it boils down to legacy methods of isolation.
20:45:41 <harlowja> i mean, idk, maybe i'm just not normal person and most normal people want to manage all that, lol
20:46:14 <SpamapS> By making the chatter between two things isolated at L2, they can believe that the traffic is "safe".
20:46:45 <SpamapS> It's the soft-squishy-core of security model, but it has some merit over other legacy methods.
20:47:10 <SpamapS> harlowja: well think about pre-cloud architecture of apps.
20:47:15 <ttx> I think it's a bit of compromise with legacy networking teams.
20:47:32 <ttx> "You can do cloud but I want l2 isolation"
20:47:42 <ttx> or $feature
20:47:45 <SpamapS> It was pretty common to have a public IPv4 on your load balancers, a separate L2 for frontend app servers, and yet another separate L2 for database servers and file storage.
20:47:47 <harlowja> SpamapS do i have to think pre-cloud, lol
20:48:36 <SpamapS> so while we know you should secure all of those end-to-end, folks forklifting their apps out of datacenters onto cloud don't necessarily want to do both at the same time.
20:49:05 <harlowja> so should we start to advocate for all those things that really modernize peoples clouds ?
20:49:18 <SpamapS> (which is why I see it as a primarily private cloud thing, because public clouds can be a little more pushy and homogenous)
20:49:24 <harlowja> and start to say ya this project will help u get there, but reallyyyy its a stop-gap
20:49:33 <harlowja> and ...?? is the better way going forward
20:49:42 <SpamapS> harlowja: no, I think we should just accept Neutron and make it better.
20:50:30 <harlowja> but why not push for `secure all of those end-to-end` (for example)
20:50:31 <SpamapS> and in 10 years when everybody has clouded everything, we can finally factor out L2 isolation.
20:50:44 <SpamapS> the point is the cloud won't help you do that
20:51:18 <SpamapS> You have an address, and it's reachable, and you shouldn't trust the source address alone of anything that reaches you. You should demand cryptographic proof.
20:52:13 <SpamapS> and usually that's happening up in layer 7.. or _sometimes_ at layer 3.
20:52:28 <SpamapS> anyway
20:52:30 <SpamapS> fun topic
20:52:34 <SpamapS> harlowja: worth a ML thread for sure
20:52:37 <harlowja> :-p
20:52:39 <SpamapS> if you so desire
20:53:00 <harlowja> 22.2% desire
20:53:04 <cdent> it would be fun to watch if nothing else
20:53:07 <harlowja> :)
20:53:08 <cdent> I'll give you a dollar if you do it
20:53:11 <SpamapS> just to re-state ttx's point: Tuesday a the PTG is Arch-WG day.. please come join us for the fu-n. ;)
20:53:15 <harlowja> i aim to please cdent
20:53:22 <SpamapS> a dollar
20:53:24 <SpamapS> dooooo it
20:53:27 <harlowja> oh man
20:53:28 <SpamapS> you can get a drink with that in ATL
20:53:35 <harlowja> peer pressure
20:53:50 <SpamapS> Ok, see you all back here in two weeks
20:53:54 <SpamapS> #endmeeting