19:02:11 <SpamapS> #startmeeting arch_wg
19:02:12 <openstack> Meeting started Thu Sep 15 19:02:11 2016 UTC and is due to finish in 60 minutes.  The chair is SpamapS. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:16 <openstack> The meeting name has been set to 'arch_wg'
19:02:18 <ttx> Back to "Better Call Saul"
19:02:19 <harlowja> oh hi!
19:02:19 <harlowja> lol
19:02:24 <ttx> oh damn
19:02:30 <ttx> o/
19:02:35 <nikhil> :)
19:02:39 <SpamapS> #action SpamapS fix the agenda cargo cult fail to not say api_wg
19:02:42 <ttx> is the plan to make it biweekly with a china-compatible alternate slot ?
19:02:53 * ttx feels like he is in Groundhog Day
19:02:57 <Rockyg> o/
19:02:58 <SpamapS> #topic previous meeting action items
19:03:10 * dtroyer_zz hums "I Got You Babe" in the background
19:03:20 <SpamapS> #link https://wiki.openstack.org/wiki/Meetings/Arch-WG#Agenda
19:03:27 <SpamapS> #link http://eavesdrop.openstack.org/meetings/arch_wg/2016/
19:03:35 <SpamapS> I don't believe we had any firm action items from last meeting
19:03:42 <SpamapS> Does anyone have any that we forgot to note?
19:04:09 <SpamapS> ttx: An alt-time with an APAC-friendly time slot is the next topic. :)
19:04:43 <SpamapS> Ok, no unhandled actions, moving on
19:04:45 <ttx> you are on fire today
19:04:50 <SpamapS> #topic alternative meeting times for TZ coverage
19:05:07 <SpamapS> I have not done the work to look for an alternative time, but I do think it makes a lot of sense.
19:05:29 <ttx> I'm fine with missing the alternate week, so don't try to make the earth flat to solve this one
19:05:43 <dtroyer_zz> I would love it if the odd week was the one that moved…I'm double booked right now...
19:05:51 <SpamapS> Would anyone like to take that as an action? This time slot is also not the greatest for Europe, so if somebody wants to try and find us _two_ better time slots, that's fine with me too.
19:06:01 <maishsk> o/
19:06:19 <docaedo> o/
19:06:26 <SpamapS> maishsk: are you o/'ing to say you're here, or o/ to say you want to find slots?
19:06:30 <ttx> SpamapS: we kind of need someone to span both zones thogh and you're the chair
19:06:47 <maishsk> SpamapS: to say hull to everyone :)
19:06:49 <SpamapS> Yeah I'm in pacific time zone most days, which suits that nicely.
19:06:51 <maishsk> sorry - lag
19:06:53 <ttx> hull!
19:07:02 <SpamapS> US pacific
19:07:03 <maishsk> ;)
19:07:41 <SpamapS> Ok, I'll take it as an action to try and find an APAC friendly slot in the odd weeks.
19:07:43 <harlowja> there are countries besides the US?
19:07:45 <harlowja> :-/
19:07:58 <SpamapS> #action SpamapS find an APAC friendly slot in the odd weeks.
19:08:00 <ttx> harlowja: beyond the wall
19:08:12 * harlowja can't see over the wall
19:08:24 <SpamapS> there's...
19:08:28 <SpamapS> something beyond the wall?!!?
19:08:31 <SpamapS> you're telling me this now?
19:08:43 <maishsk> Winter is coming….
19:09:02 <SpamapS> ok, so unless anyone else has more constraints for odd week times, we'll move on.
19:09:09 <ttx> So far architecting is mostly about interesting jokes
19:09:23 <SpamapS> naturally
19:09:33 <ttx> If all else fails we could rename ourselves the obscure references wg
19:09:41 <SpamapS> #topic Group Creation Spec review
19:09:55 <Rockyg> a time good for UTC+8 or later is good for China
19:10:03 <SpamapS> * Option 1/Abandon and create architecture-wg-specs repo
19:10:04 <SpamapS> * Option 2/Work with cross-project team to land spec
19:10:19 <SpamapS> Rockyg: that's useful intel. :)
19:10:34 <SpamapS> So, I'm hesitant to call any kind of vote
19:10:37 <ttx> I am for Option 1, I don't really want to set precedent that you need permission to do some team work
19:10:46 <dtroyer_zz> agreed
19:11:04 <ttx> It's not as if the group was asking to be granted special powers
19:11:07 <Rockyg> yeah.  #1
19:11:21 <SpamapS> Indeed, I like the idea of self organizing, it also helps clear up that we aren't going to wield power beyond our ability to do actual work.
19:11:44 <SpamapS> #link https://review.openstack.org/335141
19:11:47 <ttx> architecture-wg-specs can be a referenced under the TC repos to avid creating a project team
19:12:25 <harlowja> wfm
19:12:26 <ttx> SpamapS: http://git.openstack.org/cgit/openstack/governance/tree/reference/technical-committee-repos.yaml
19:12:30 <SpamapS> Creating that repo should be a bit less controvertial than the whole charter for the group in the openstack-specs repo.
19:13:08 <SpamapS> Ok, so I'll go ahead and bandon 335141 right now, and we'll create a new patch following ttx's link
19:13:19 <SpamapS> #link http://git.openstack.org/cgit/openstack/governance/tree/reference/technical-committee-repos.yaml
19:13:21 <maishsk> SpamapS: sounds good
19:13:32 <ttx> SpamapS: move the charter to the wiki or somewhere
19:13:47 <ttx> so that we keep it and can reference it
19:14:04 <dtroyer_zz> given that then, I made this as a possible starting point to incorporate the ideas from the spec: https://etherpad.openstack.org/p/arch-wg-draft
19:14:06 <SpamapS> That's worth fleshing out
19:14:32 <SpamapS> I'd like for it to be in git, but to get it in git, we need a team to manage that repo. Yes?
19:14:49 <SpamapS> get it in git -- another fine hand crafted SpamapS phrase
19:15:17 <ttx> SpamapS: not really, we can make it a TC-owned repo (link I posted)
19:15:24 <SpamapS> #link https://etherpad.openstack.org/p/arch-wg-draft
19:15:25 <david-lyle> change to get into git, and it can be self-recursive
19:15:43 <david-lyle> nevermind, I'm an idiot
19:16:11 <ttx> same as the api-wg repo
19:16:15 <SpamapS> so what I think we can do is maintain it there in the etherpad until we have a repo, and then move it into the repo. Sound good?
19:16:28 <ttx> +2
19:16:36 <harlowja> k
19:16:40 <dtroyer_zz> ++
19:17:03 <SpamapS> #action everyone please review https://etherpad.openstack.org/p/arch-wg-draft to ensure it matches the spirit of https://review.openstack.org/335141
19:17:05 <Rockyg> ++
19:17:22 <SpamapS> #action SpamapS create architecture-wg-repo
19:18:04 <SpamapS> Ok, so that handles what I think are the logistics of stating our purpose. Now, about this bikeshed we've all been working on the last 5+ years...
19:18:29 <harlowja> which one is that
19:18:29 <SpamapS> #topic Proposals for work
19:18:29 <harlowja> lol
19:18:41 <SpamapS> * Base Services - ttx
19:18:42 <maishsk> :)
19:19:35 <SpamapS> Perhaps this is premature
19:19:38 <Rockyg> so can anyone jump in and suggest stuff here?
19:19:46 <Rockyg> I've got a kinda easy one.
19:19:51 <SpamapS> I don't know if we can talk about these things without a firm base statement about what they are.
19:20:37 <SpamapS> In the interest of keeping our process as lightweight as possible.. I wonder if we can have people create etherpads for topics they'd like discussed.
19:21:01 <ttx> SpamapS: I think stating the current state is easy
19:21:44 <SpamapS> I'm more concerned about the lack of process the WG has for discussing these topics than this specific work proposal btw.
19:22:01 <SpamapS> We can just bring them up one by one in IRC, if that's what people want.
19:22:07 <ttx> I's like us to define the concept of base services and then fold MySQL, Rabbit and Keystone in it
19:22:13 <SpamapS> But I worry that we'll never get through them in the IRC format.
19:22:17 <harlowja> ya, its a tough question
19:22:23 <harlowja> requires lots and lots of context
19:22:59 <ttx> Agree that while we know what to discuss, we don't know how to discuss it and the result we produce
19:23:06 <dtroyer_zz> Having some background documentation is a good idea, and puts a bit of a threshhold on proposals to not just be drive-bys
19:23:10 <ttx> A set of recommendations and concepts ?
19:23:27 <Rockyg> Well, if it's not IRC, it's either specs/docs or F2F with lots of etherpad notes....
19:23:59 <SpamapS> Right, actually maybe that's the thing to do.. let drive-by's have their 1 - 2 minutes here, and then if they seem worth the group's time, have the proposer present a more complete idea that we can digest in between meetings and discuss in detail. Thoughts?
19:24:15 <Rockyg> Background documentaation is very good.  It helps everywhere.
19:24:42 <SpamapS> The whole reason for this group's existence is that we have no shortage of overarching topics we all feel aren't getting enough attention.
19:25:09 <SpamapS> So what I think we may need to focus on is a way to prioritize and promote the best ideas.
19:25:14 <Rockyg> So, either present driveby's here and/or proposals on the mailing list?
19:25:30 <ttx> and find some low hanging fruit to start
19:25:43 <Rockyg> I've got that one rady for the group
19:25:55 <Rockyg> a DefCore uncoverd issue.
19:26:10 <SpamapS> Yeah, I want to start with work we can complete quickly, to get feedback and confidence in the group's purpose.
19:26:22 <Rockyg> ++
19:26:30 <ttx> SpamapS: we can maintain a number of "open topics" that the group is working on
19:26:36 <Rockyg> ++
19:26:40 <dtroyer_zz> also, limit the number at first
19:26:42 <Rockyg> a backlog
19:26:47 <ttx> + a backlog
19:26:54 <SpamapS> So, backing up from the core services specific topic, let's hash out a quick process that we can apply _today_ for prioritizing and promoting each topic.
19:26:55 <dtroyer_zz> until we get what process we do want sorted
19:27:09 <SpamapS> backlog, yes ok
19:27:14 <ttx> SpamapS: I'd do a 3-tier system
19:27:14 <Rockyg> Also, with a backlog, lage issues can be broken down to manageable tasks
19:27:29 <ttx> SpamapS: proposals, backlog, active
19:27:47 <ttx> anyone can put something in proposals and get 2 minutes of fame in the meeting
19:28:00 <ttx> if accepted we can put it in backlog
19:28:01 <Rockyg> someone's been doing this a while
19:28:10 <SpamapS> yes I'm liking this
19:28:15 <ttx> then we pick a couple from the backlog to be active at any moment
19:28:30 <SpamapS> Did I see or hear somewhere that storyboard has grown card stacks?
19:28:37 <ttx> and try to focus our attention on those
19:28:38 <SpamapS> aka "Trello boards" ?
19:28:47 <Rockyg> I know it's grown, but not sure how.
19:29:13 <ttx> I'm not worried about tooling, could be a wiki page, etherpad, or something fancy with cards
19:29:20 <SpamapS> Yeah let's start with an etherpad
19:29:27 <SpamapS> I'm going to create it right now.. standby
19:29:28 <Rockyg> ++
19:29:58 <SpamapS> https://etherpad.openstack.org/p/arch-wg-status-board
19:30:01 <ttx> Then let's dump ideas in the proposal section, once done we can review them in meeting and give the proposer 5 min to pitch it
19:30:38 <SpamapS> #link https://etherpad.openstack.org/p/arch-wg-status-board
19:30:42 <Rockyg> I'll stick the one on I've got after the meeting.
19:30:52 <SpamapS> You can add it now Rocky, we have a little bit of time :)
19:32:01 <SpamapS> So, the process we can use is simple. Each proposal gets 2 - 3 minutes of IRC time. Should we vote on moves to backlog after?
19:32:37 <dtroyer_zz> given the time zone issue, doing it only in real-time might be a problem for some
19:32:49 <SpamapS> Or more of a consensus process.. anybody disagrees to move it to backlog and we table it for end of meeting?
19:32:52 <ttx> kid emergency, brb
19:33:17 <SpamapS> dtroyer_zz: agreed, so maybe we ask proposers to put their elevator pitch there in the etherpad with the title.
19:33:33 <SpamapS> We can then just have absentee discussion on the ML
19:33:59 <SpamapS> and then maybe by the time we do a meeting, it's just a formality to move items to backlog
19:34:07 <dtroyer_zz> something similar to the lazy concensus used for other things like core nominations would work, wait a time for objections, then do it
19:34:15 <SpamapS> +1
19:34:26 <ttx> basically discuss if the topic is in scope for the group
19:34:35 <SpamapS> Yeah, in scope is the bar for proposal -> backlog
19:34:40 <dtroyer_zz> that allows reading meeting logs and then having a place to go for follow-up
19:35:02 <SpamapS> Priority and opportunity will then drive any moves from backlog to active.
19:35:28 <ttx> ++
19:35:35 <SpamapS> dtroyer_zz: you've been crushing it writing things down. Can you add a write-up of this to your etherpad?
19:35:42 <dtroyer_zz> sure
19:35:51 <ttx> dtroyer_zz: run while you can
19:36:00 <SpamapS> #action dtroyer Add write-up of backlog procedures to etherpad and send to ML for discussion
19:36:29 <SpamapS> so what I see forming here is we have a discussion of our scope, and then a discussion of what to do with our scope. :)
19:37:02 <SpamapS> Given those two things, I don't know that we should dive into scoping the proposals listed there just yet.
19:37:13 <harlowja> makes sense to me
19:37:41 <SpamapS> we kind of do agree on scope
19:37:55 <ttx> the trick will be the bar between what's arch-wg territory (research & design) vs. what's cross-project spec territory (implementation)
19:37:55 <Rockyg> Yeah.  I agree with that.
19:38:24 <dtroyer_zz> I hope that bar isn't a thing to throw work over,…
19:38:35 <SpamapS> Yeah
19:38:42 <SpamapS> I want us to do implementation too...
19:38:55 <ttx> we can and should
19:39:01 <SpamapS> In lock-step with those who are just working on cross-project.
19:39:07 <Rockyg> I think the bar might be both throw, but also implement.  Get buy in, then implement.
19:39:09 <ttx> but I think we'd go with existing process to implement stuff
19:39:24 <dtroyer_zz> I'm expecing those who bring things here will be helping provide some of the the resources required
19:39:24 <Rockyg> ttx, ++
19:39:35 <SpamapS> Yeah, so this group might design something, and then go stick it into a cross project repo and do the implementation with that team.
19:39:56 <Rockyg> ++
19:39:58 <ttx> that would be ideal yes
19:40:08 <SpamapS> The only difference here is that we're going to tackle the design in a methodical way.
19:40:21 <SpamapS> Rather than just hallway-track it.
19:40:36 <SpamapS> Or be pushed to evolve the design while implementing.
19:40:43 <ttx> and that in some cases there is no implementation really
19:40:56 <SpamapS> Ok, so given that, are all of the proposals on the list "things that need to be designed" ?
19:41:07 <Rockyg> I think the key is, getting a good, solid, consistnent design such that implementation doesn't  take as long because the detaails are already mostly there.
19:41:09 <SpamapS> Is that the bar?
19:41:29 <ttx> SpamapS: some of it is cost/benefit ratio resarch. Like teh DLM stuff
19:41:36 <dtroyer_zz> maybe 'defined' in some cases rather than 'designed'
19:41:47 <Rockyg> dtroyer_zz, ++
19:42:40 <SpamapS> Ok, so if it is something that we think needs a strong definition written up, then it should go in our backlog.
19:42:52 <SpamapS> Agreed?
19:42:58 <Rockyg> ++
19:43:01 <ttx> yes
19:43:04 <dtroyer_zz> ++
19:43:39 <Rockyg> Also, if a cost/benefit POC is needed,  backlog?
19:43:41 <SpamapS> So let's take a minute and just move all the proposals into the backlog (or reject them if they're not in need of a definition)
19:43:51 <SpamapS> Rockyg: I'd say that's part of a strong definition.
19:43:59 <Rockyg> thanks
19:45:19 <SpamapS> So, I suggest that we leave the etherpad as it is, and let dtroyer_zz send out the process we've discussed, including this bar, to the ML
19:45:28 <Rockyg> ++
19:45:34 <harlowja> cool
19:45:43 <ttx> I'd love to hear the pitch on some of those
19:45:52 <ttx> because I'm not sure they fit :)
19:46:16 <SpamapS> Agreed, and I think we want that pitch to come on the ML
19:46:18 <ttx> or at least, i'm not sure what they are about
19:46:28 <ttx> oh sure
19:46:34 <SpamapS> And then if it's not obviously +1 to backlog, "please attend a meeting and we'll discuss in realtime"
19:46:46 <harlowja> micro service architecture could explode into a big thing :-P
19:47:06 <Rockyg> real big
19:47:09 <dtroyer_zz> philosophical question: would we want to house those pitch docs in our repo to facillitate discussion on them liek we do specs?
19:47:14 <SpamapS> Yes Micro Service architecture is something that would need a set of design tenets first, and then a discussion of the benefits, and then it might turn into 20 implementations.
19:47:24 <dtroyer_zz> or keep that outside in wiki/eitherpad/whatever?
19:47:39 <ttx> well, the pitch is not to solve the problem in one thread, just to introduce it as a potential topic for the arch WG
19:47:54 <SpamapS> But I think that's the sort of thing we all want to work out. We may at some point throw up our hands and say it's going to be too big and throw it to the bottom of the backlog, but I want to _stop_ having people hoping and praying for it.
19:47:57 <Rockyg> I think we should put the docs in a repo.  Good for concept docs.
19:48:14 <ttx> like if we pitch scaling approaches and we get stuck in a tricircle vs. Nova Cellsv2 argument, we lost
19:48:30 <dtroyer_zz> right, but I don't want to lose that discussion, it'll happen again
19:48:40 <SpamapS> I see what dtroyer_zz is saying
19:48:44 <Rockyg> unless we find a way to abstract both approaches to one api...
19:48:58 <SpamapS> spec reviews tend to stay quite a bit more civil and focused than ML threads
19:49:16 <ttx> maybe we should do pitches in review form
19:49:38 <SpamapS> Yeah, so if we set it up as a specs repo, and ask people to submit specs, they'll be used to that process.
19:49:39 <ttx> no strong opinion on that
19:49:49 <Rockyg> If we do them in review form, we'd need the weekly email summary like the api wg does
19:49:57 <SpamapS> But then that begs the question, why not use openstack-specs for that?
19:50:05 <dtroyer_zz> so the repo would have proposals/ backlog/ and active/, plus whatever we call finished docs
19:50:29 <harlowja> same as ttx , no strong opinion from me either
19:50:30 <dtroyer_zz> I think we want to seep idea-like things out of openstack-specs, that is for planned work
19:50:40 <SpamapS> Ah ok
19:50:41 <dtroyer_zz> *to keep
19:50:43 <SpamapS> makes sense
19:51:15 <SpamapS> I like the idea of the repo being the card list.. except, proposals basically has to be almost auto-approve-if-well-formatted.
19:51:34 <SpamapS> I want proposing to be only slightly more heavyweight than hallway-track-topic-shifting
19:51:44 <ttx> it's not a spec, it's just a topic pitch
19:52:03 <ttx> I'd keep the format pretty basic
19:52:07 <SpamapS> We could just have pending reviews to backlog == prposals
19:52:20 <SpamapS> Which makes a lot of sense to me.
19:52:37 <SpamapS> Since we want anyone who wants to participate to be able to propose.
19:52:43 <ttx> oh, yes good idea
19:52:47 <dtroyer_zz> yeah, proposal approval would be mostly a sanity check I'd think
19:52:49 <SpamapS> dtroyer_zz: what do yu think about that? just have a backlog and active dir
19:52:59 <dtroyer_zz> sure
19:53:10 <SpamapS> that way we can always be working the proposals as a review queue
19:53:15 <SpamapS> and then meetings are just for check-ins on that
19:53:15 <Rockyg> Should there be a template for proposals?
19:53:24 <dtroyer_zz> we may want an attic for things removed, or just dump them
19:53:25 <SpamapS> yeah we can use a spec-like template
19:53:30 <SpamapS> with less structure than the usual spec
19:53:33 <ttx> we could even do one directory per active topic so that we can produce multiple docs
19:53:45 <SpamapS> dtroyer_zz: +1, we can attic things when we get there. :)
19:53:58 <SpamapS> and we can make the structure deeper as needed
19:54:00 <ttx> I expect some of those to end up quite complex
19:54:14 <SpamapS> dtroyer_zz: ok, so are you still good with writing _this_ up as the process?
19:54:20 <SpamapS> to summarize:
19:54:22 <dtroyer_zz> I am
19:54:41 <SpamapS> * propose against {repo name}/backlog
19:54:58 <SpamapS> * approved to backlog == in scope
19:55:29 <SpamapS> * backlog items moved to {repo name}/active once group agrees to work on things.
19:55:46 <SpamapS> I already have the action to create a repo
19:55:48 <SpamapS> who wants to be core?
19:56:08 <dtroyer_zz> o/
19:56:18 <ttx> who doesn't want to be a "core architect"
19:56:29 <harlowja> i'll take core, lol
19:56:36 <SpamapS> I'd propose that it be more than just myself, dtroyer, and ttx .. moar coars
19:56:44 <ttx> I'm fine being just a spectator, fwiw
19:56:53 <SpamapS> ttx: k, but I want you to have +2 powers :)
19:56:54 <harlowja> do i get a ring if i'm core?
19:56:56 <Rockyg> Yeah, I would too, but I'm on cusistncy, etc, not implementation
19:57:05 <SpamapS> so if you're spectating and you agree with the presenter, you can express it fully :)
19:57:06 <ttx> But can core until the thing flies by itself
19:57:07 <Rockyg> consistnecy
19:57:12 <Rockyg> consistency
19:57:29 <SpamapS> I also think we might want to tinker with 2*+2
19:57:33 <SpamapS> But we're out of time
19:57:36 * dtroyer_zz makes note of alternate spellings of his favorite word
19:57:52 <Rockyg> yeah.  We've got some details to get too once we get tharger framework
19:57:57 <SpamapS> #action SpamapS make dtroyer harlowja ttx Rockyg initial cores of architecture-wg repo
19:58:01 <harlowja> wfm
19:58:10 <harlowja> ring to right?
19:58:11 <nikhil> ohai!
19:58:20 <SpamapS> nikhil: ohhaaaaaaai
19:58:27 <nikhil> how can I get into the inner circle :P
19:58:29 <harlowja> #action SpamapS get the arch-core rings ordered
19:58:30 <nikhil> ?
19:58:30 <SpamapS> 1 minute left
19:58:37 <nikhil> SpamapS: ^
19:58:39 <SpamapS> rings? We're getting tattoos
19:58:41 <Rockyg> hey, nihkil
19:58:47 <harlowja> :-/
19:58:47 <nikhil> Rockyg: hi
19:58:53 <harlowja> ok , tattoos if we must
19:59:04 <nikhil> SpamapS: I was busy writing release notes for glance for rc1
19:59:09 <SpamapS> #action SpamapS add nikhil to initial cores as well
19:59:10 <Rockyg> No tats for me., but I'll take a cool ring
19:59:18 <nikhil> but I am in this whole new effort!
19:59:22 <SpamapS> Basically to start, if you show up, you get the ring of power
19:59:24 <SpamapS> ok
19:59:28 <SpamapS> that's all the time we have everyone
19:59:28 <nikhil> ha
19:59:39 <ttx> my precious
19:59:42 <SpamapS> thanks so much for showing up! See you all on the mailing list in the [architecture] topic. :)
19:59:45 <Rockyg> just under the wire, nihkil
19:59:48 <SpamapS> #endmeeting