19:02:18 <SpamapS> #startmeeting arch_wg
19:02:19 <openstack> Meeting started Thu Sep 22 19:02:18 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:22 <openstack> The meeting name has been set to 'arch_wg'
19:02:33 <nikhil> o/
19:02:35 <rustyl> o/
19:02:41 <SpamapS> #link https://wiki.openstack.org/wiki/Meetings/Arch-WG#Agenda
19:02:47 <rosmaita> o/
19:03:01 <SpamapS> Courtesy ping for arch_wg: nikhil, harlowja, dstanek
19:03:03 <KrishR> o/
19:03:11 <harlowja> oh hi, brb, getting food before
19:03:15 <kragniz> o/
19:03:26 <SpamapS> welcome welcome all
19:03:37 <SpamapS> dtroyer said he'd join us late
19:03:39 <nikhil> reminder: the courtesy ping list on the wiki can be updated for those who need highlight reminders for this meeting
19:03:50 <SpamapS> presumably because he's double-booked on odd weeks
19:04:03 <cdent> o/ I managed to show up for once
19:04:09 <SpamapS> cdent: huzzah!
19:04:12 <dtroyer_zz> o/
19:04:15 <SpamapS> dtroyer_zz: woot
19:04:26 <SpamapS> #topic previous meeting action items
19:04:36 <SpamapS> #link http://eavesdrop.openstack.org/meetings/arch_wg/2016/
19:04:42 <SpamapS> a moment while I scrape them out
19:05:18 <SpamapS> SpamapS fix the agenda cargo cult fail to not say api_wg
19:05:20 <SpamapS> done
19:05:31 <SpamapS> SpamapS find an APAC friendly slot in the odd weeks.
19:06:01 <SpamapS> I have not done this yet. Apologies for that. Since next week is the even week, I hope to have one to propose then so in two weeks we'll have one in an APAC friendly slot
19:06:13 <harlowja> woah cdent who are u
19:06:18 <SpamapS> #action SpamapS find an APAC friendly slot in the odd weeks. [carried over]
19:06:23 <cdent> harlowja: ikr!
19:06:31 <SpamapS> harlowja: I hear he's nothing but trouble
19:06:49 <SpamapS> everyone please review https://etherpad.openstack.org/p/arch-wg-draft to ensure it matches the spirit of https://review.openstack.org/335141
19:06:50 <woodster_> o/
19:06:51 <rocky_g> o/
19:07:01 <rocky_g> dang.  Whaddi miss?
19:07:08 <SpamapS> rocky_g: not much
19:07:09 <harlowja> ha
19:07:49 <SpamapS> This last action item is really just a reminder to look and help edit that etherpad so we can land it in the repo whenever I finally get around to creating the repo.
19:07:59 <SpamapS> SpamapS create architecture-wg-repo
19:08:22 <SpamapS> I was a total slacker this week and did not do any of that. Before I carry it over, did anyone else want to pick that up?
19:08:49 <rustyl> What time of day for APAC were you considering... where is everyone joining from?
19:08:51 * rocky_g takes one step back
19:09:12 <nikhil> SpamapS: you're mising #action prefix to your action items :)
19:09:27 <nikhil> slick
19:10:25 <nikhil> rustyl: I think we will need a doodle and/or review for that. it depends on the availability of the slot too.
19:10:43 <SpamapS> rustyl: we have had at least 2 requests for a time that fits for APAC architecture WG participants, which is enough for me.
19:10:53 <SpamapS> nikhil: I'm not adding new actions, I'm reviewing old ones.
19:11:09 <SpamapS> but, to the point, I think they deserve a * prefix
19:11:09 <nikhil> SpamapS: I can create the repo
19:11:14 <SpamapS> nikhil: sweet
19:11:20 <SpamapS> one less thing
19:11:59 <SpamapS> #action nikhil Create architecture-wg git repository for proposals and general WG documentation.
19:12:25 <SpamapS> nikhil: I believe there's some guidance in dtroyer's email from this past week.
19:12:50 <SpamapS> * dtroyer_zz Add write-up of backlog procedures to etherpad and send to ML for discussion
19:13:05 <SpamapS> I believe that got done
19:13:11 <nikhil> awesome
19:13:24 <SpamapS> #link http://lists.openstack.org/pipermail/openstack-dev/2016-September/104144.html
19:13:54 <SpamapS> Please everybody find that in your inboxes and respond with any feedback. I think the text of that email should probably go in as one of our first documents in the repo
19:14:20 <SpamapS> and a block of actions now:
19:14:22 <SpamapS> SpamapS make dtroyer harlowja ttx Rockyg initial cores of architecture-wg repo
19:14:24 <SpamapS> SpamapS get the arch-core rings ordered
19:14:26 <SpamapS> SpamapS add nikhil to initial cores as well
19:14:37 <SpamapS> nikhil: I think we can just fold that all into the repo creation.
19:14:43 <SpamapS> as implementation details
19:15:00 <dtroyer_zz> SpamapS: that email is a summary of the etherpad, that is what I think should go into the repo
19:15:09 * dtroyer_zz is behind
19:15:12 <SpamapS> dtroyer_zz: good point. :)
19:15:45 <SpamapS> Did we miss any action items from last week?
19:15:45 <harlowja> SpamapS did u get them ordered
19:15:54 <harlowja> platinum right
19:16:00 <nikhil> SpamapS: ack on folding that into the repo
19:16:06 <SpamapS> harlowja: oh, yes, Rose Gold with Hematite faux pearls.
19:16:25 <harlowja> faux?
19:16:35 <rocky_g> gold?
19:16:42 <nikhil> rose?
19:16:46 <nikhil> lol
19:16:57 <harlowja> ah. at least we all got our sense of humor still :)
19:17:24 <SpamapS> #action all BE SERIOUS THIS IS ARCHITECTURE ;)
19:17:59 * rocky_g puts the cheetos down
19:18:06 <SpamapS> Ok so I'm going to skip the next few topics
19:18:17 <SpamapS> because they're all basically hinged on having a repo and proposals to discuss
19:18:25 <harlowja> kk
19:18:36 <SpamapS> we can loop back around for the proposal discussion at the end, but we have some other business I want to make sure we don't miss
19:18:41 * cdent takes the cheetos
19:18:43 <harlowja> ?
19:18:50 <SpamapS> #topic Summit Cross-Project Space Request
19:18:52 <SpamapS> #link https://etherpad.openstack.org/p/ocata-cross-project-sessions
19:19:12 <rocky_g> ++
19:19:31 <SpamapS> I really think we need that space in the cross-project fishbowls
19:19:36 <harlowja> i'd like it
19:19:50 <SpamapS> I know most of you, but I'd like to make sure we have a chance to introduce ourselves to the rest of OpenStack as a group
19:20:01 <harlowja> hi i'm josh
19:20:07 <SpamapS> no you're not
19:20:13 <harlowja> hi i'm not josh
19:20:18 <SpamapS> yes you are
19:20:31 <harlowja> :(
19:20:48 <SpamapS> So, anyway, please review the text in that etherpad before October 1
19:20:58 <harlowja> is there anyway we can split some of those proposals into categories?
19:21:00 <SpamapS> If you want to improve it, either just do it there, or we can discuss here.
19:21:07 <harlowja> like [tech-debt, future-thinking...]
19:21:16 <harlowja> like python3.x is tech-debt
19:21:23 <SpamapS> harlowja: I think that's worthwhile metadata that we can use to make sure we're spending adequate time on each area we want to.
19:21:47 <harlowja> k, i mean nothing wrong with tech-debt (it will always exist)
19:22:19 <SpamapS> harlowja: also, I believe the deciders on that list are the TC, so we can also make sure to influence the TC on the overall makeup of these at the TC meeting
19:23:03 <harlowja> kk
19:23:12 <rocky_g> I think we can also vote, but just as a popularity thing, not like the TCV
19:23:32 <SpamapS> I actually really dislike voting as a consensus mechanism.
19:23:42 <harlowja> whats TCV?
19:23:45 <rocky_g> oops.  I was wrong.  Only TC
19:23:56 <harlowja> kk
19:24:02 <SpamapS> Yeah, TC will be deciding on this list. I think they're trying to rank them by value.
19:24:07 <rocky_g> harlowja, TCV==fat fingers
19:24:18 <harlowja> we have a new TC composed of fat fingers
19:24:19 <harlowja> nice
19:24:19 <SpamapS> oh, TCV is fat fingers? I definitely have that.
19:24:46 <harlowja> (and this is how crazy rumors start, lol)
19:25:19 <SpamapS> So, I'm pausing a bit so everyone can read through the list there
19:26:03 <SpamapS> We'll move on to other business in a minute. Please take that minute now to read the text that is there for our fishbowl session, and then just comment here if you think it should be discussed.
19:26:55 <cdent> blurb++
19:27:14 <SpamapS> Note that I think we could also propose to split a session with the PWG because we're kind of two sides of the same coin (they're more about what end users see at the high level, we're more about what developers work on at a high level)
19:27:55 <SpamapS> But I'd rather have the 40 minutes to work through proposals face to face.
19:28:04 <SpamapS> Ok, let's move on.
19:28:40 <SpamapS> #topic Proposals for work
19:28:57 <SpamapS> we don't have a proposals repo yet, but we do still have 2 things on the agenda if anybody wants to chat about them.
19:28:58 <rocky_g> We should go for a working session with PWG
19:29:25 <harlowja> just a quick question, on the proposals for work, do we want to set expectations for these?
19:29:40 <harlowja> for example, its pretty easy to through out random ideas
19:29:56 <dtroyer_zz> that is one of the reasons for asking for a background doc
19:29:57 <harlowja> but its the real hard work of actually doing it and doing it in a way that involves others that i think is where snags happy
19:30:00 <harlowja> *happen
19:30:10 <SpamapS> #link https://etherpad.openstack.org/p/arch-wg-draft
19:30:11 <rustyl> the first item we work on should be easy to allow the process to tested
19:30:11 <harlowja> dtroyer_zz k, that would be useful
19:30:16 <SpamapS> harlowja: this has a "How to contribute" section
19:30:21 <dtroyer_zz> to raise the bar a bit and get people on the same page of what exactly is being proposed
19:30:32 <dtroyer_zz> rustyl: exactly
19:30:33 <harlowja> dtroyer_zz gotcha, also a 'outreach section?'
19:30:42 <SpamapS> which basically sets the expectations
19:30:59 <harlowja> k
19:31:29 <dtroyer_zz> I think things in that proposal list without a name attached will have a hard time getting int the repo :)
19:32:05 <SpamapS> rustyl: I agree. I think ttx's base services one is a good candidate for that. Because documenting the current situation will be relatively simple (All OpenStack projects can already expect to have wsgi servers to run their code, a SQL database, and a MQ) and then we can build toward what we'd like to add to that (mostly, a DLM fronted by tooz)
19:33:05 <SpamapS> we might also want to add memcached
19:33:09 <SpamapS> since most projects end up using it
19:33:24 <dtroyer_zz> ttx's proposal was actually at the OpenStack services level, ie Barbican, but the DLM ins another one to consider
19:33:46 <SpamapS> right, Keystone is also on the list.
19:33:49 <SpamapS> Barbican.........
19:33:52 <dtroyer_zz> ah, there are two lines in that list, so yeah
19:33:57 <harlowja> DLM is an interesting one, because i also feel there is education that we may also need to help out with also
19:34:10 <harlowja> like most of these (systems) are more than just locks
19:34:40 <dtroyer_zz> and the information on stuff like that is one of the value-adds I think this team can/should provide
19:34:46 <harlowja> locks are just one 'by-product' of the underlying consensus stuff happening inside them
19:35:13 * harlowja just saying
19:35:34 <SpamapS> harlowja: right, the thing is, even with Cinder landing their use of tooz, we want to be able to confidently go around to each project and add DLM dependencies without having to go through the same "but no some people won't have a DLM" discussion.
19:36:10 <harlowja> right, there is more of a spectrum is all i'm saying
19:36:16 <harlowja> DLM is imho like the start of that spectrum
19:36:24 <harlowja> (spectrum of consensus like systems and using them)
19:36:35 <rocky_g> also goes to scaling.
19:36:41 <SpamapS> Yeah, I think the two that ttx wanted to discuss adding, (or probably more important, wanted to develop a process for adding) were DLM and Barbican.
19:36:49 <rocky_g> The bigger the site, the more stuff you need to manage the more stuff
19:36:56 <harlowja> the zuul  v3 folks have an interesting view on this to
19:37:07 <harlowja> they are using zookeeper for some more advanced stuff (farther down the spectrum than just locks)
19:37:20 <harlowja> (thus the education part)
19:37:36 <harlowja> why is monty not in here :-P
19:37:54 <dtroyer_zz> I think he has Stockholm syndrome?
19:37:58 <dtroyer_zz> er, is in Stockholm?
19:38:00 <dtroyer_zz> :)
19:38:09 <nikhil> wat!
19:38:10 <rocky_g> This is where I think upstream university should have sections for all OpenStack developers to learn about current and new conventions.  Like Zookeeper
19:38:28 <nikhil> dtroyer_zz: oh, is in Stockholm!
19:38:41 <harlowja> rocky_g that'd be nice (for people inside and outside of openstack IMHO)
19:38:49 <dtroyer_zz> nikhil: sub-par joke
19:39:30 <rocky_g> Yup.  F2F training to get the folks on the same page as technologies and architecture change
19:39:59 <harlowja> ya, i feel even if we say magically technology/architecture whizbang
19:40:02 <SpamapS> rocky_g: that's a great point actually. Our efforts to create design should flow into upstream U
19:40:12 <harlowja> that unless u know what whizbang means u'll just be like whatever
19:40:17 <SpamapS> also
19:40:19 <SpamapS> http://docs.openstack.org/arch-design/
19:40:22 <Shrews> o/
19:40:23 <SpamapS> #link http://docs.openstack.org/arch-design/
19:40:37 <SpamapS> We should work with the authors of that a lot.
19:40:51 <rocky_g> ++
19:40:57 <SpamapS> That book is about end-user architecture
19:41:00 <harlowja> hi Shrews, just was getting into how your zuul v3 perspective might be a interesting one
19:41:14 <SpamapS> And we're going to be making assertions that flow directly into end-user architecture decisions.
19:41:24 <harlowja> and the spectrum of how a system like zookeeper is more of a spectrum with DLM on one side of it
19:41:28 <SpamapS> So whenever we consider a proposal, we should always make sure to plan doc work on the architecture design guide.
19:41:40 <harlowja> there is a book?
19:41:50 <harlowja> woah
19:41:54 <harlowja> lol
19:41:58 <SpamapS> harlowja: it's for designing your built cloud, not for designing OpenStack. :)
19:42:03 <harlowja> oh
19:42:04 <harlowja> nm then
19:42:04 <rocky_g> There should be an OpenStack Architectural Concepts that is for the Projects' architectural features/philosphies
19:42:42 <SpamapS> anyway
19:42:55 <harlowja> my point heard though, thx :)
19:43:09 <harlowja> (it will imho be the hardest thing of all)
19:43:42 <harlowja> (to teach fishing, lol)
19:43:52 <SpamapS> Shrews: for more context, what we're saying is, we want to let people depend on the existence of DLM as they design openstack projects.
19:44:09 <harlowja> can we also get past calling it a DLM ;)
19:44:14 * harlowja i'd like that :-P
19:44:19 <SpamapS> nope
19:44:23 <harlowja> maybe call it a consenus-enabler, lol
19:44:28 <Shrews> just to be clear, your definition of DLM is distributed lock manager, yes?
19:44:37 <SpamapS> that sounds so hippie
19:45:08 <SpamapS> coordination service?
19:45:19 <harlowja> ah, that'd be nicer
19:45:24 <harlowja> better
19:45:34 <SpamapS> Tooz fronted coordination service?
19:45:36 <harlowja> DLM just to me implies only locks
19:45:43 <harlowja> and these systems are greater than that :-P
19:45:55 <rocky_g> traffic controller
19:46:12 <harlowja> coordination service i think is ok
19:46:14 <rocky_g> like on trains and tracks
19:46:32 <harlowja> unsure the metaphor there, ha
19:47:00 <rocky_g> the system that keeps trains from crashing into each other as they share portions of the same tracks
19:47:41 <harlowja> is there a tron reference we can use, lol
19:47:44 <harlowja> MCP?
19:47:45 <harlowja> lol
19:47:56 <SpamapS> anyway
19:48:12 <SpamapS> I think we have decided we want to at least work on documenting what that is
19:48:20 <SpamapS> and what we want developers to be able to expect, and deployers too
19:48:27 <harlowja> ya, a good thing to reference is the watcher capabilitiy of these systems
19:48:40 <harlowja> such capability goes beyond locks
19:49:09 <SpamapS> what about Barbican?
19:50:15 * SpamapS hears crickets
19:50:19 <woodster_> Regarding Barbican, is the goal to provide a ref arch for utilizing such systems? The barbican team has been trying to figure out the best way to promote integration with other projects
19:50:24 * harlowja doesn't know enough about Barbican
19:50:31 <SpamapS> woodster_: sort of
19:51:03 <SpamapS> woodster_: I'm proxying ttx here, but basically, when you go to write AaaS (Anything as a Service) in OpenStack, you can count on a few things being there implicitly..
19:51:14 <SpamapS> woodster_: DB, Keystone, MQ, wsgi, etc.
19:51:24 <harlowja> so an interesting sorta thing for this, and i don't know the answer, is there is some kind of overlap here with docker and kubernetes, how much interest do folks have in these 2 worlds might be an intersting question
19:51:42 <harlowja> how much out of openstack outreach do we care about (?)
19:51:42 <woodster_> SpamapS: yep, and barbican ain't one of them (yet?) :)
19:51:42 <SpamapS> woodster_: and we're wondering if this group can help do the work to allow a coordination service and/or barbican to be on the same level as DB/MQ/Keystone/etc.
19:52:16 <woodster_> it seems security is one of those deployer-choice gray levels
19:52:32 <SpamapS> woodster_: a ref arch is something I'd expect Barbican to provide for that, but there's also some practical matters that concern me.
19:52:56 <SpamapS> Mostly, my fellow engineers who have evaluated Barbican tell me that it doesn't add much value without HSM's.
19:53:12 <woodster_> some deployers want to talk to crypto resource directly (like KMIPs). So Castellan was introduced as a way to adapt projects to a key manager....barbican is but one plugin for that, but is not required
19:53:27 <SpamapS> But if we make it part of the base services of OpenStack, we expect everybody, even thouse without HSM's, to deploy it.
19:53:44 <dtroyer_zz> SpamapS: correct, but how much value does anything else have without HMS either?  The idea being we need to assume the interfaces are availble and functional
19:53:55 <SpamapS> dtroyer_zz: anything else has less complexity.
19:53:55 * dtroyer_zz types slowly
19:54:07 <woodster_> SpamapS: well, TLS doesn't add much value unless you stop using self-signed certs. Barbican allows you to use a secure backend if you want. Out of the box it doesn't of course.
19:54:48 <dtroyer_zz> the win without the hardware is simply converging OpenStack services to a single solution
19:55:11 <woodster_> I think if you don't ever need secure storage of keys, then barbican isn't needed. But  if you do someday...
19:55:15 <SpamapS> TLS doesn't add _as much_ value w/ self signed certs. However, it offers a ton of value in limited context. You can pre-cache certs without PKI and get a lot of value.
19:55:21 <rocky_g> dtroyer_zz, that's a big win, still
19:55:40 <SpamapS> But Barbican without an HSM is just an audit logger, right?
19:56:06 <SpamapS> Hm
19:56:11 <dtroyer_zz> can it not store keys just as badly as Apache does on disk?
19:56:18 <woodster_> SpamapS: yeah I'd agree with that.
19:56:51 <SpamapS> It can, and maybe having it there, already in the implementation, for those that need the HSM security, is enough to have those not interested in HSM's just use the less secure one.
19:57:42 <SpamapS> But there's a pretty valid argument that adding complexity is adding risk, which would be _the opposite_ of the goal of making Barbican a base service.
19:57:49 <dtroyer_zz> I understood one motivation for doing this now was to help Nova and Cinder head toward the same thing, sooner than later
19:57:57 <SpamapS> We're running low on time, but what's this Castellan thing?
19:58:00 <woodster_> so it seems that the choices are no barbican (store on disk) or spend $$$ for HSM for secure storage. I think those are valid choices for a deployer to make of course, and one solution to both would seem to be the best. I think a combo of Castellan (lightweight) with Barbican might be the best balance
19:58:29 <woodster_> Castellan is a lightweight adapter to a key manager backend that projects can integrate with
19:58:32 <dtroyer_zz> so good, we have the questions that need answering!
19:58:44 <SpamapS> If we can't say Barbican is always going to be around for deployers, but Catellan is, is that a step forward?
19:58:45 <woodster_> barbican is not required if you use that
19:59:01 <SpamapS> But that only solves it for "under the cloud" problems
19:59:09 <SpamapS> For users, they won't have a key manager.
19:59:09 <woodster_> SpamapS: I think this would be great to discuss more in Spain
19:59:18 <SpamapS> And so something like, say, Zaqar, can't depend on it
19:59:23 <SpamapS> woodster_: Agreed
19:59:32 <SpamapS> with 30s left we need to wrap up
19:59:51 <SpamapS> woodster_: I hope you'll join us again next week and we can get your feedback on ttx's proposal
19:59:56 <SpamapS> thanks everyone!
20:00:03 <SpamapS> #endmeeting