20:03:51 <SpamapS> #startmeeting arch_wg
20:03:52 <openstack> Meeting started Thu Apr  6 20:03:51 2017 UTC and is due to finish in 60 minutes.  The chair is SpamapS. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:56 <openstack> The meeting name has been set to 'arch_wg'
20:04:01 <SpamapS> ttx: we should wrap up the loose ends
20:04:22 <SpamapS> #link https://wiki.openstack.org/wiki/Meetings/ArchWG
20:04:44 <SpamapS> whoa, somebody already deleted it?
20:05:07 <SpamapS> #link https://wiki.openstack.org/wiki/Meetings/Arch-WG
20:05:09 <SpamapS> thats what I meant
20:05:22 <ttx> heh
20:05:25 <SpamapS> #topic Arch-WG EOL
20:05:30 <SpamapS> So, thanks for showing up
20:05:45 <SpamapS> It's been fun, but I just don't think this WG has enough momentum to continue.
20:06:09 <cdent> is there any sense/possibility in rolling some of the concept back into the TC?
20:06:33 <SpamapS> cdent: I believe that the TC works well enough, and members should continue to work across project lines
20:06:42 <ttx> I'll definitely push base services stuff directly at TC level
20:06:43 <dtroyer> maybe the creation of the process is the useful output of this group, to be used as necessary?
20:07:00 <dtroyer> at least to use as expectations and guildelines
20:07:12 <SpamapS> The process we were working in was a bit heavy.
20:07:31 <dtroyer> it did anticipate more activity
20:07:32 <ttx> yeah
20:07:38 <SpamapS> I was building it up hoping for a mroe broad base of proposals.
20:07:46 <ttx> we could retreat back to using openstack-specs
20:07:59 <ttx> as a way to build up proposals when needed
20:08:11 <SpamapS> if it's going to be 2 - 5 people working on 1 - 2 proposals, I think the TC can just foster that activity and specs can be filed in openstack-specs, governance, or as community goals
20:08:12 <rockyg> o/
20:10:36 <cdent> I think it is sad but true that finding the real time to make this go in the way originally defined is too hard for most people (the interested ones are almost always already overspent)
20:10:48 <dtroyer> if that is the message to come out of here, we should make it clear (again) that it is not limited to the TC to be involved
20:11:07 <dtroyer> cdent: ++
20:11:34 <SpamapS> There's another message to come out of here.
20:11:48 <SpamapS> Which is that I don't believe OpenStack _wants_ a shared architecture that is well defined.
20:12:02 <SpamapS> I do believe they want leadership and consensus from the TC.
20:12:09 <dtroyer> I actually think they do, but they want "them" to do it
20:12:11 <cdent> SpamapS I know it feels that way, but I don't think that's entirely true
20:12:17 <SpamapS> and I think we all want some uniformity
20:12:44 <SpamapS> I'll try to make it sound less cynical.
20:13:18 <SpamapS> I believe that if we have well defined APIs that don't leak implementation details, we don't need to care about how things happen behind those APIs.
20:13:35 <cdent> dtroyer: I'm not sure what you say is true either. I think there are loads of people who love to do it, if they just had the time.
20:13:41 <cdent> So many of us are doing 5 or 6 jobs.
20:13:55 <ttx> some do, but the majority just goes after more urgent problems
20:13:56 <SpamapS> So we should put in guidelines for what to do behind those APIs, but we also should let projects innovate there and not worry too much if one goes a little bit off the reservation, because they might just set the tone for everyone else's next refactor.
20:13:56 <dtroyer> I'm thinking more at a company level here
20:14:12 <cdent> dtroyer: oh. that. yeah.
20:14:12 <rockyg> boy +1000 to all of this
20:14:18 <dtroyer> I know that this was a good thing in my managemern circle until they realized it wasn't an emterprise-like architecture thing
20:14:35 <dtroyer> look at how things have been adopted by many projects that are less than 4 years old… when encouraged to look at something that exists as a pattern it is often adopted without NIH or re-work concerns
20:15:21 <dtroyer> what I've heard a lot about is the really hard problem of fixing the 'original projects'  which just isn't going to happen
20:15:39 <dtroyer> for everyone's own personal value of 'fixing'
20:15:56 <SpamapS> dtroyer: indeed! What I learned was that it wasn't even possible to get agreement on the existence of problems within Nova.
20:16:18 <SpamapS> To Nova's credit, they have carried a massive burden and are working hard to make things better for everyone.
20:17:02 <SpamapS> But nobody would agree on what, if anything was "broken", so there wasn't much for me to try and facilitate "fixing"
20:17:14 <dtroyer> funny thing is I recall Jesse & Joshua lamenting that about the time Vish joined… it set in early
20:17:49 <dtroyer> actually, it was probably later than that, but still at Ames
20:18:11 * dtroyer shuts up now
20:19:01 <rockyg> Yeah.  but, maybe if we could provide them cover, some of the more egreious issues can be addressed.
20:19:10 <cdent> "cover"?
20:19:26 <rockyg> Oh, yeah.
20:19:34 <SpamapS> rockyg: that's exactly what I was hoping to do. Give people a safe place to air their grievances. The silence was deafening.
20:20:15 <dtroyer> I think it is going to take a dedicated group of people with first-hand knowledge and history with multiple projects to do anything approaching major
20:20:22 <rockyg> So, here's a question: once scheduler and placement is modularized out, what would you consider the next functionality to pull out into its own module?
20:21:07 <SpamapS> rockyg: I believe all of the agents that run on compute nodes should be combined into a compute service that has its own API.
20:21:15 <dtroyer> there's a group that has long wanted to pull out the hypervisor drivers
20:21:25 <dtroyer> team-wise
20:21:37 <cdent> i'm pro that
20:21:41 <rockyg> I think if we look at nova that way, we might be able to provide it as the pluggable platform for data plane services
20:22:04 <SpamapS> Because the problem as I see it, which I couldn't get any agreement on, is that the way things are arranged leads to fear of refactoring.
20:22:10 <rockyg> And I'm blocked......
20:22:26 <rockyg> IRC has been giving me hell the past few days.  Sorry.
20:22:55 <SpamapS> rockyg: I see your words. :)
20:22:59 <dtroyer> rockyg: it may be more useful to pull out the useful bits into reusable things then build the more generic framework
20:23:02 <dtroyer> I do too
20:23:35 <SpamapS> Anyway, I also have reduced my focus on OpenStack to basically "power user" so I'm also just not developing anything on OpenStack ATM.
20:23:54 <SpamapS> so on a personal level, my Arch-WG work was feeling less and less connected to reality.
20:24:44 <dtroyer> so there's a thing that is repeating itself all over...
20:25:58 <SpamapS> yes?
20:26:06 <cdent> reducing focus?
20:26:11 <cdent> or disconnection from reality?
20:26:17 <dtroyer> sorry… not just the corporate restructuring but it happening on more personal levels too
20:26:23 <SpamapS> I think we've said basically all the things. I want to quickly reiterate the past action items and then we'll wrap it up.
20:26:36 <cdent> I've been complaining to myself of late that my openstack development is disconnected from reality becaue I don't have any opporunities to use openstack
20:26:40 <ttx> SAY ALL THE THINGS
20:26:49 <SpamapS> hah
20:26:53 <SpamapS> I use OpenStack every day now. It's fine.
20:26:55 <rockyg> Yeah.  Let's use openstack!
20:27:01 <dtroyer> cdent: that is a hude deal for a lot of devs
20:27:13 <dtroyer> s/hude/huge/
20:27:13 <ttx> huder
20:27:13 <rockyg> take a dev to work day!
20:27:15 * cdent nods
20:27:37 <SpamapS> also worth noting every time you 'git review' you use the largest multi-cloud application in the world.. which runs entirely on openstack. ;)
20:28:02 <dtroyer> I know that was one of the original things that OSIC was planning to do internally, to get devs into managing the real deployments fro a time to see it firsthand
20:28:05 <rockyg> So, hypothetically, if we could get an open lab up, that would allow for longer term experiments, what would it look like and what would it need.  Essentially a community lab
20:28:22 <SpamapS> yeah that's exactly what OSIC was going to do
20:28:27 <SpamapS> then they gave 1000 servers to CNCF ;-)
20:28:28 <rockyg> That allows for longer than two week projects (OSIC style is 2 wks)
20:28:37 <clarkb> SpamapS: is that where my capacity went? nice
20:28:48 <SpamapS> youbetchya
20:28:53 <clarkb> (also we run two clouds in the open if anyone is interested)
20:29:00 <clarkb> vanilla and chocolate
20:29:00 <SpamapS> And yes, you can help run infra-cloud :)
20:29:07 <SpamapS> anyway, lingering actions:
20:29:09 <SpamapS> rocky_g Send email regarding implementation bleed-through (stretch: submit as raw proposal) (Carried since Feb 9 2017)
20:29:09 <rockyg> Yeah, but Huawei has proposed its follow-on labs and one of our architects says he needs more than two weeks.
20:29:11 <SpamapS> rocky_g Resurrect Error Codes and Logging Improvements spec and socialize appropriately before PTG (Carried since Feb 9 2017)
20:29:13 <SpamapS> ttx to change expand/contract concept to default first to picking the best if possible
20:29:15 <SpamapS> harlowja to spin up some attention to memory usage in projects
20:29:41 <SpamapS> I don't think any of those are leaving any unresolved commitments. Just arch-wg business that can continue as individual devs/tc/etc.
20:29:54 <rockyg> SpamapS, I actually sent a backchannel email to mreidem about that just yesterday....
20:30:13 <rockyg> He seems to be wanting to get interop and testing for it in better shape
20:30:35 <SpamapS> I also think implementation bleed-thru is a joint problem for interop and api-wg
20:31:00 <rockyg> And, the error codes are on the Forum schedule.  I've got a session and a BoF.  Just no time to do this.  I should get the etherpad for ccollaborating on speccs up today or tomorrow.
20:31:04 * cdent nods
20:31:52 <SpamapS> Cool
20:31:54 <rockyg> I'm trying to redefine my job to let me focus deeply on cross project implementations -- push down from users to a form that is understandable and actionable by devs
20:31:57 <cdent> so in the sense of stepping back for a moment: everyone keeps saying "just no time". This is a huge fundamental problem that is the roadblock for, well, everything. Can we do anything about it?
20:32:13 <SpamapS> cdent: time is money is time.
20:32:29 <rockyg> Yah.
20:32:51 <rockyg> Another thing to think about:  committer vs maintainer in Linux.
20:33:02 <SpamapS> Peoples priorities are driven by their sponsors for the most part. Which is the right thing. If we want longer term, less concrete work to happen, we need corporate sponsors to ask their people to work that way.
20:33:17 <rockyg> Committers tend to do the bleeding edge features.  Maintainers tend to make the code base higher quality
20:33:51 <rockyg> But the maintainers are the systems folks.  cross project, integrated system thinkers
20:34:10 <rockyg> We need a way to promote maintainers and make their positions important.
20:34:30 <rockyg> If they are considered important, they would get the time to do this stuff they (we) need to do.
20:34:36 <SpamapS> we have plenty of maintainer types
20:34:41 <SpamapS> well not plenty
20:34:43 <SpamapS> we have some
20:34:47 <rockyg> With no time to do the system level.
20:35:22 <rockyg> We talk about bugfixing as strategic, but not architecture consistency as strategic
20:35:27 <SpamapS> As the hype curve continues to fall back to reality, maintainers will be more valued.
20:35:37 <rockyg> Very true.
20:35:57 <SpamapS> rockyg: architecture consistency is a direct assault on bug creation rates.
20:36:20 <rockyg> You know that, I know that, but it's amazing how many devs don't know that.
20:36:46 <SpamapS> Go read Phoenix project. Unplanned work must be cut off at the roots, not continuously mowed down only to pop back up.
20:37:14 <cdent> I think you guys are underestimating at least some devs. A lot of them know that. They simply don't have the time. The backlog is years deep.
20:37:22 <SpamapS> I believe _most_ know that.
20:37:32 <SpamapS> And I believe most are simply tasked with other things.
20:38:06 <rockyg> Do we have the backlogs defined and categorized?  Can we go and look at them any time we want to refer a new developer to some needed work?
20:38:26 <rockyg> Maybe that's what we should start with, then.  Making sure the backlog is known and accessible.
20:38:33 <SpamapS> I do not begrudge their employers' desire to quickly get features and integration work done at the expense of quality.
20:38:48 <cdent> rockyg: that's a good question. for me a lot of it is half-assed: things I know I would work on if I had the headspace.
20:38:57 <SpamapS> rockyg: in theory, it's in Launchpad. In reality, it's probably in peoples' heads.
20:39:51 <rockyg> Right, cdent. Maybe this is where we get TC help to do a backlog documentation sprint.  Get all teams to figure out their backlogs and categorize and prioritize them over the course of a couple/few days.
20:40:17 <rockyg> Launchpad is a bug/artifact repository.  What goes in seldom moves out.
20:40:20 <SpamapS> I believe that was Pike, wasn't it?
20:40:23 <cdent> rockyg: vote for me and I'll put that on the list ;)
20:40:40 <SpamapS> Teams were encouraged to pay down debt for the shorter cycle, IIRC.
20:40:49 <rockyg> It's really unmanageable.  that's why everyone has been trying for something better for *years*
20:40:53 <clarkb> SpamapS: ocata, and i really didn't get much sense that that happened
20:41:17 <clarkb> (gate stability rates were pretty bad as one measure of whether or not that was a thing)
20:41:19 <rockyg> Actually, clarkb SpamapS I thinka fair amount did happen.
20:41:44 <SpamapS> Ocata right, not Pike.
20:41:48 <rockyg> There really were fewer specs/bps and more care taken when code went in
20:42:16 <SpamapS> Anyway, thanks again for everything.
20:42:24 <rockyg> ++
20:42:39 <SpamapS> I'll submit patches to remove the meetings from the calendar.
20:42:49 <rockyg> Dang.
20:43:00 <SpamapS> If anybody wants to resurrect it, by all means, do it, and don't wait for me. ;-)
20:43:09 <rockyg> I missed the first shoe dropping by missing the start of the meeting, didn't I?
20:43:27 <SpamapS> rockyg: I sent an email a few hours ago too.
20:43:40 * SpamapS pours one out for Arch-WG and calls it.
20:43:43 <SpamapS> #endmeeting