19:03:43 <SpamapS> #startmeeting arch_wg
19:03:45 <openstack> Meeting started Thu Oct 13 19:03:43 2016 UTC and is due to finish in 60 minutes.  The chair is SpamapS. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:48 <openstack> The meeting name has been set to 'arch_wg'
19:04:08 <SpamapS> #link https://wiki.openstack.org/wiki/Meetings/Arch-WG#Agenda
19:04:31 <SpamapS> Courtesy ping for nikhil, harlowja, dstanek, kragniz, auggy
19:04:48 <SpamapS> #topic previous meeting action items
19:04:58 <SpamapS> #link http://eavesdrop.openstack.org/meetings/arch_wg/2016/
19:05:23 <dtroyer> o/
19:05:35 <cdent> hola all
19:05:41 <SpamapS> hello helllo all!
19:05:41 <ttx> o/
19:05:42 <rustyl> o/
19:05:59 <rocky_g> o/
19:06:26 <SpamapS> Let's jump right in
19:06:30 <SpamapS> * SpamapS send proposal for APAC friendly time slot to openstack-dev to get feedback from actual APAC dwellers.
19:06:32 <ttx> I had an action item to kickstart the "base service" definition stuff
19:06:34 <SpamapS> DONE
19:06:45 <ttx> #link https://etherpad.openstack.org/p/arch-wg-base-services
19:07:02 <ttx> that would be the first draft, SpamapS will do a pass on it I think
19:07:14 <ttx> and then we'll hopefully have some repo to propose it into
19:07:45 <SpamapS> Indeed, that cover's ttx's side of this one:
19:07:47 <SpamapS> * ttx and SpamapS to statr etherpadding thoughts
19:08:10 <SpamapS> I've read through and mostly think it stands as a good proposal that I'd like to get into our repo and follow that new process on.
19:08:25 <SpamapS> but that brings us to this:
19:08:27 <SpamapS> * nikhil continue to drive forward repo creation
19:08:37 <SpamapS> AFAICT, nikhil is MIA
19:08:52 <SpamapS> so I just submitted a new rev on the repo creation review, which is here:
19:09:13 <SpamapS> #link https://review.openstack.org/375093
19:09:43 <ttx> the reviewing machine already -1ed it
19:10:02 <ttx> twice
19:10:24 <SpamapS> haha yeah.. Ok I'll continue driving that forward and hopefully we'll have a repo by tomorrow
19:10:38 <SpamapS> #action SpamapS continue driving repo creation forward
19:10:53 <SpamapS> ttx: once we have a repo, I'll propose your etherpad contents as the first submission.
19:10:55 <SpamapS> sound good?
19:11:01 <ttx> +1
19:11:21 <SpamapS> #action SpamapS submit base services etherpad contents to arch-wg repo upon its creation.
19:11:22 <cdent> ya
19:11:30 <dtroyer> I'll propose the draft doc too
19:11:35 <SpamapS> sweet
19:11:40 <rocky_g> Cool
19:11:49 <SpamapS> I'll email the architecture tag when the repo is up
19:12:00 <SpamapS> #action SpamapS email openstack-dev architecture tag when the repo is available for submissions
19:12:18 <SpamapS> Do we have any other open action items that we need to discuss?
19:12:26 <ttx> In other news, we'll have a cross-project workshop around the ArchWG
19:12:32 * ttx digs up link
19:12:55 <rocky_g> Really cool.
19:12:58 <ttx> we might want to discuss content for that a bit
19:13:15 <ttx> #link https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16922/cross-project-workshops-architecture-working-group-fishbowl
19:13:56 <SpamapS> #topic Summit Cross-Project workshop
19:14:10 <SpamapS> #link https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16922/cross-project-workshops-architecture-working-group-fishbowl
19:14:36 <SpamapS> Yes I have high hopes for this fishbowl for introducing ourselves as a group, and also for finding all the other groups that feel they overlap with and/or compliment us.
19:15:56 <SpamapS> so..
19:16:03 <SpamapS> we have a link to an abandoned review in that description
19:16:31 <SpamapS> Maybe we can replace that with an etherpad specifically for the session, which we can paste the mission statement into?
19:16:49 <ttx> yes
19:16:51 <SpamapS> ttx: I don't know how to update the text there. I am hoping you do. :)
19:16:57 <ttx> and add it to the etherpads list
19:16:57 <rocky_g> Sounds good
19:17:38 <ttx> SpamapS: just send me an email with the description you want there and I'll make it happen
19:17:41 <SpamapS> How about this:
19:17:44 <SpamapS> #link https://etherpad.openstack.org/p/ocata-summit-arch-wg
19:18:03 <SpamapS> ttx: where's the etherpads list?
19:18:34 <ttx> https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads
19:18:40 <ttx> I'm a link machine
19:19:14 <dtroyer> faster than me and I already had it in a paste buffer
19:20:08 <SpamapS> Ok I'm just adding the etherpad now.
19:20:35 <rocky_g> Should you also put a whole section for cross project etherpads?
19:21:51 <SpamapS> rocky_g: maybe, I just did ours as one section now, but I do think the cross project ones being in one section makes more sense.
19:22:15 <SpamapS> I'll get a header in that etherpad later today or tomorrow
19:22:18 <SpamapS> and email ttx
19:22:36 <SpamapS> #action SpamapS email ttx with update to Fishbowl text and links.
19:22:50 <SpamapS> #action Pre-populate etherpad with mission statement
19:23:50 <SpamapS> #topic Proposals for work
19:24:04 <SpamapS> We have text for base services which ttx has so graciously prepared
19:24:22 <SpamapS> #link https://etherpad.openstack.org/p/arch-wg-base-services
19:25:07 <SpamapS> I'd like to invite everyone to read that. In the future, I think we should try to come to meetings having read all proposals in the current queue.. but for now, shall we pause for say, 5 minutes, so everyone can read that one?
19:25:44 <ttx> yes, would be good to spot major objections/issues early
19:25:47 * cdent reads
19:25:59 <ttx> we can catch details later in the review
19:26:36 <ttx> It's not really changing anything, it's more about setting a number of definitions
19:28:19 <SpamapS> I like the way it reads now as a full analysis, not just a proposal.
19:28:33 <SpamapS> So it feels like the lead-in to a proposal.
19:28:48 * cdent agrees
19:29:27 <ttx> it defines the framework for future additions, if any
19:29:50 <dtroyer> and a path to do that
19:30:10 <SpamapS> So one way that I'd like to see the outputs of our group look is to first produce something exactly like this (a good solid analysis of current state, gathering any supporting historical information if needed), and then recommended changes to improve from there.
19:31:04 <rocky_g> That sounds good.  Question....does swift use oslo.db?
19:31:08 <dtroyer> in two parts?  updating the state-of-the-state doc as things change?
19:31:15 <ttx> I wanted to clearly explain the trade-offs in that question, to frame any future discussion
19:31:38 <ttx> rocky_g: swift doesn't use a global database
19:31:42 <dtroyer> AFAIK swift only uses sqlite, buried deep inside its code
19:31:51 <dtroyer> many, many little sqlite dbs
19:31:51 <ttx> (which is not a bad thing)
19:31:52 <rocky_g> Ah.  Thanks.
19:31:57 <SpamapS> dtroyer: No I think we produce it as "OpenStack was like this as of X" and then we write what amounts to an RFC for how it should look.
19:32:34 <dtroyer> ok.  that also lets us reference back to build later things on top of earlier ones
19:32:49 <SpamapS> and from that RFC/spec/etc we estimate work to get that done, and manage that work in each project as needed.
19:33:14 <SpamapS> I also like the idea of having varying levels of recommendation level.
19:33:26 <SpamapS> Like the RFC process.. you can say you're RFC822 compliant, or RFC2822 compliant.
19:34:00 <SpamapS> so if we recommend projects work together like X, then we can say "We're here to help you implement ARCH-WG-1
19:34:30 <SpamapS> and some of those will never happen, and some will be superseded
19:35:13 <SpamapS> anybody else like that idea?
19:35:59 <ttx> that could work, not sure that could apply to everything though
19:36:00 <dtroyer> its like microversions, just a monotonically increasing number :)
19:36:12 <rocky_g> ++ as long as we do regular maintenance to remove never used/modify to what we did instead of what we proposed, etc
19:36:50 <SpamapS> yeah, some of our recommendations will just not fly, and we'll run out of steam or pivot away from them and not get anywhere, I think that's fine.
19:37:32 <SpamapS> We can have various states.. Proposed, Active, Implemented, Superseded, Deprecated
19:37:54 <ttx> I'm fine making it up as we go
19:38:04 <SpamapS> If we were perfect, everything would go Proposed->Active->Implemented and stay there
19:38:18 <SpamapS> ttx: me too
19:38:26 <dtroyer> where is the fun in that?
19:38:31 <SpamapS> so for now, we're at the state where I think ttx's base services will be proposed.
19:38:49 <SpamapS> dtroyer: <sniff> do I smell java class modeling on you?
19:38:56 <SpamapS> ;)
19:38:59 <rocky_g> we get to have microversions for our proposals then.  that's where the fun is;)
19:39:24 <SpamapS> you're not an openstack project if you don't have some way to microversion your outputs and inputs
19:39:31 <cdent> so I should point out that from the the api-wg experience point of view, this is all sounding very optimistic
19:39:39 <SpamapS> cdent: haha yeah I bet
19:39:43 <cdent> not be a buzzkill, I encourage the optimism
19:39:56 <cdent> just more of a "don't overeach, baby steps, etc"
19:40:01 <SpamapS> cdent: I'd like to encourage you to expand on that.
19:40:08 <SpamapS> If you don't mind
19:40:17 <cdent> here now, or later? (either is fine)
19:40:18 <SpamapS> maybe a quick summary of what your group puts out, and how it is received.
19:40:23 <rocky_g> Yeah.  But you know, the arch group can write the API stuff into its proposals.....
19:40:25 <SpamapS> here if you don't mind
19:40:45 <cdent> So I came into the api-wg some time after it was formed, during a point of transition
19:40:46 <SpamapS> also
19:40:49 <SpamapS> #topic Open Discussion
19:41:12 <cdent> initially it was fairly oriented towards capturing the state of apis in openstack
19:41:16 <cdent> looking for commonality
19:41:21 <cdent> and formalizing that commonality
19:41:39 <cdent> what was discovered was that a lot of the implementations could not be considered "good" use of http
19:41:39 <rocky_g> I put the cross project sessions into the wiki page, just under cinder, and put the link to the session.
19:42:07 <cdent> so there was a phase of recapitulation of the rfcs into guidelines
19:42:14 <cdent> a sort of distillation of best practices
19:42:20 <cdent> that process continues to this day
19:42:34 <rocky_g> cdent, was there at least some sort of consistency within projects?
19:42:42 <SpamapS> rocky_g: thanks for that
19:42:54 <SpamapS> The inconsistency in the API's does not surprise me.
19:43:03 <cdent> rocky_g: basically anything that was derived from nova often felt like nova
19:43:07 <cdent> and other things felt different
19:43:22 <rocky_g> That makes sense
19:43:27 <dtroyer> cdent: that explains soooo much of OpenStack history :)
19:43:33 <cdent> dtroyer: indeed
19:43:50 <SpamapS> So I expect we'll find something similar happens as we start to give people a way to look at the system from outside the project lens.
19:44:00 <cdent> within each project I can't really comment on consistency, I've been more focused on the recapitulation than the analysis
19:44:05 <SpamapS> Like base services I think we'll find are also used differently in each project.
19:44:38 <ttx> yes, although base services is not really prescriptive: we don't force anyone t ouse them
19:44:44 <SpamapS> So at some point we may just decide our next best effort is to double down on base services and define how they're to be used.
19:44:59 <cdent> the api-wg is now entering a phase where newer projects are actively driving the creation and adoption of guidelines
19:45:07 <ttx> it's more of a "if you want to use extra stuff, you should have that around"
19:45:13 <cdent> it used to be that nova was creating a lot of guidelines, but that has slacked off
19:45:15 <SpamapS> Like it's one thing to say "THere's a database" another to say "That database will scale infinitely no matter what schema and query you throw at it"
19:45:44 <cdent> and there is a looming challenge of what to do about a project that has no interest in being "compliant"
19:46:45 <rocky_g> Sounds like the tC might have some interesting challenges shortly
19:47:14 <ttx> I suspect we'll have more issues with more prescriptive recommendations, like overall/cell scaling arch
19:47:40 <SpamapS> Yeah I don't mind if a project rejects all the patches we submit to try and bring them into the fold.
19:48:14 <cdent> api-wg summary: lots of education has been required
19:48:17 <cdent> EOS
19:48:22 <SpamapS> THe point is to make clear recommendations and listen when we try to implement them.
19:48:46 <cdent> +1
19:49:17 <SpamapS> The point must never be to 'should all over' something.
19:49:40 <cdent> but SpamapS people are wrong in the internet!
19:50:07 <SpamapS> When we make good recommendations, I expect we'll not have a hard time landing patches to implement them. When we make bad ones, we'll likely be making an uphill battle for ourselves.
19:50:29 <SpamapS> Ok well I am very excited to get in a room with all of you in 13 days.
19:50:34 <dtroyer> SpamapS: Im afraid that the 'our way is best' projects will not care about good/bad there
19:50:35 <rocky_g> Hahahahaha!  you underestimate inertia!
19:50:51 <dtroyer> rocky_g: that too
19:51:11 <SpamapS> dtroyer: We can't help anyone who doesn't want our help.
19:51:47 <SpamapS> We'll see how it goes the first few times we try to add DLM support to a project. ;)
19:51:54 <SpamapS> Also I'm really interested in more proposals for work.
19:52:03 <SpamapS> I feel like many may be holding back due to the repo creation stumble.
19:52:23 <SpamapS> Hopefully we can get past that shortly.
19:52:28 <dtroyer> it'll come in a couple of weeks
19:52:29 <SpamapS> I think we can end on that.
19:52:47 <SpamapS> Thanks so much everyone. See many of you in Barcelona!
19:52:51 <ttx> yay
19:53:09 <SpamapS> #endmeeting