19:03:47 <SpamapS> #startmeeting arch_wg
19:03:48 <openstack> Meeting started Thu Sep  8 19:03:47 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:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:51 <openstack> The meeting name has been set to 'arch_wg'
19:03:53 <SpamapS> ttx: good idea!
19:04:05 <SpamapS> #topic roll call
19:04:21 <ttx> Let's just shout ideas of things the group should try to cover i priority
19:04:23 <ttx> o/
19:04:26 * dtroyer is here but multitasking
19:04:40 * rustyl in his first openstack irc meeting
19:04:47 <SpamapS> Hi! This is the first time we've done this meeting. So I do expect sporadic attendence.
19:05:00 <SpamapS> I have to close my laptop, so there'll be a 5 minute outage
19:05:07 <KrishR> o/
19:05:07 <ttx> I'll take it over
19:05:13 <SpamapS> ttx: thanks!
19:05:17 <SpamapS> #topic open discussion
19:05:25 * SpamapS bbiab
19:05:38 <ttx> So I'd like to discuss immediate priorities. I have 3 on my mind
19:05:46 <ttx> SpamapS already knows about them
19:06:03 <rustyl> seems like we should discuss what is left to merge the proposal
19:06:05 <ttx> 1/ create a solid motivated group
19:06:28 <ttx> 2/ Start discussing the concept of "base services"
19:06:43 <ttx> which are things that can be assumed to be present in an openstack deployment
19:06:56 <ttx> currently keystone, Mysql, and a MQ (Rabbit)
19:07:12 <ttx> but we've been talking of extending that set
19:07:18 <ttx> with a DLM, wiht Barbican
19:07:47 <ttx> Additions need to be as limited as possible to limit the operational burden
19:08:04 <ttx> But we still need to add, to get access to awesome features
19:08:19 <SpamapS> DLM is becoming more common every day, so is easier.
19:08:28 <ttx> 3/ Create an overall sclaing model
19:08:32 <ttx> scaling*
19:08:35 <ttx> This one is harder
19:09:09 <ttx> But we need to define an openstack-wide scaling model. Could be to have each service scale horizontally, could be cells, could be tricircle-like...
19:09:12 <SpamapS> Key management is tougher, because without HSM barbican is kind of just a toy.
19:09:17 <ttx> but we need to have a big picture
19:09:51 <ttx> That would be my 3 initial objectives
19:10:05 <ttx> But I bet you have plenty on your list
19:10:39 <dtroyer> I suspect scaling in one for or another will be on many lists
19:10:53 <rustyl> seems like we need to have something fairly easy to tackle first in order to work out the kinks of how this group works
19:10:56 <dtroyer> what we need to try and do here is be clear on terms like that
19:11:17 <SpamapS> I mostly want to make sure any efforts are transparent, and productive. My list is so long, I need help choosing what to even start talking about
19:11:38 <ttx> rustyl: yes. i think establishing the base service concept could be easy
19:12:00 <rustyl> ttx: so that would just be a document?
19:12:21 <ttx> (before thinking of extending the set, just expressing that openstack deployments can be expected to have a MQ, a DB and keystone
19:12:44 <SpamapS> In addition to "what do we want to change" I want to also answer "what doesn't have a stated architecture?" So we can start to help with understanding of the system at higher levels
19:13:08 <ttx> rustyl: ideally the same document would list the tradeoff we need to make when considering adding stuff
19:13:48 <SpamapS> The base system services effort would be a good one to start with for documenting as well.
19:13:50 <ttx> i.e. balancing adding operational complexity vs. giving developers more efficient features
19:14:22 <ttx> The discussion around triggers is a bit of the same vein
19:14:34 <SpamapS> But here's another thought that throws a wrench into that plan... What if we want to do micro services?
19:14:51 <SpamapS> (which I do)
19:15:15 <ttx> the base services could be the non-openstack microservices :)
19:16:14 <ttx> or maybe I don't get what you mean
19:16:38 <SpamapS> Documenting all the coupling that prevents micro services today will tell us how hard it's going to be too implement. Adding base services might make it harder, since every micro service would in theory need it's own isolated instance of the base services
19:17:11 <SpamapS> What I mean is that I have a hard time just updating cinder.
19:17:18 <rustyl> ok, so picking an item to work on that basically results in a document definitly falls into the easier side of things (for some definition of easy), but... i'm woried about figuring out how work in this group results in a set of patches to multiple projects
19:17:34 <SpamapS> There are interdependencies that have risen from the integrated gate
19:17:34 <ttx> SpamapS: would it ? a microservice could need to talk to a DLM microservice...
19:18:18 <ttx> it's microservices, not micromonoliths :)
19:18:30 <SpamapS> The APIs between cinder and Nova are not well defined and because of that, I have to update them in lock step
19:18:57 <ttx> yes, that kind of work likely needs to be done in all cases
19:19:15 <SpamapS> I want them to be constrained to their public APIs only
19:19:47 <ttx> But the scale-out /microservice question is clearly level 2 boss
19:19:47 <SpamapS> OK going into takeoff now for real
19:19:58 <ttx> I think we need to tackle level 1 first
19:20:22 <ttx> OK, I don't have much more to discuss
19:20:23 <ttx> We could close now
19:20:47 <ttx> rustyl: anythind to add ?
19:20:50 <ttx> +g
19:20:59 <rustyl> quick question.... how to we close on the actual proposal thats under code review?
19:21:25 <rustyl> seems like the conversation on the review is nearing an end, but no +2's yet
19:21:34 <ttx> I'm wondering if we need to close it. The Arch WG can exist without approval of anyone
19:21:58 <ttx> cross-project specs are discussed by the crossproject grop, you can ask thingee for help
19:22:15 <ttx> but frankly I wonder if you should go through that step
19:22:15 <dtroyer> at the least shouldn't the group point at that, or something like it, to define its mission?
19:22:32 <ttx> or just abando nthe review and take the draft to some arch-wg repo or wiki page
19:22:52 <ttx> dtroyer: we should definitely keep the text
19:22:55 <rustyl> dtroyer: thoughts on getting +2's
19:23:20 <ttx> I just don't think we need crossproject team approval to start the group
19:23:23 * rustyl just realized that dtroyer was already talking... damn lag
19:23:44 <ttx> it was useful to iterate on the text
19:24:17 <dtroyer> agreed.  maybe what we need to do is start putting together the structure for this group to put is stiff, and that would be doc #1
19:24:19 <ttx> so option 1/ abandon the review, copy the text to a wiki page or some arch-WG git repo
19:24:31 <dtroyer> I lean toward the repo.
19:24:35 <ttx> option 2/ ask thingee for help to bring it to the approval stage
19:24:53 <dtroyer> I think the API WG=has generally worked well and we can borrow a lot of process from them
19:25:01 <ttx> but I fear people would read too much into the need for approval, like they would fear it gives some authority to the group over them
19:25:30 <ttx> since people those days seem to read too much into any change proposed
19:26:42 <ttx> I'll let the choice between options to SpamapS but my personal advice would be to go with 1
19:26:51 <dtroyer> ++
19:27:15 <rustyl> either way for me
19:28:27 <ttx> The immediate action is to publicize the meeting and get all the people who expressed interest to show up next time
19:29:25 <ttx> then agree on some easy initial target (I'd propose the base services stuff)
19:29:48 <rustyl> sounds reasonable
19:29:56 <ttx> then if all goes well tackle something more ambitious
19:30:10 <dtroyer> yes.  It would be great to have something to talk about in Barcelona, even just informally
19:30:29 <ttx> fwiw we could totally give the Arch Wg a room for two days at the PTG event
19:30:32 <rustyl> the base services should be doable
19:30:42 <ttx> (space permitting)
19:31:00 <ttx> so that we can make in-person progress and use it as a sprint
19:31:08 * dtroyer is afraid it would be like early Neutron rooms ;)
19:31:46 <ttx> yes, I don't want to force it, just let you know there is this option
19:32:13 <dtroyer> A great option, thanks
19:32:15 <ttx> agree it could be more destructive than productive
19:32:33 <ttx> In /theory/ we have extra space on the "horizontal" side of the event
19:32:39 <dtroyer> that and the comemnts in the review are what keep me wanting to keep the focus narrow, at least at first
19:32:44 <ttx> (the monday/tuesday)
19:32:56 <dtroyer> people want to boil the desert
19:33:16 <ttx> SpamapS: are at at 10000ft yet ?
19:33:46 <ttx> should we just end the meeting or wait for him to come back and read scrollback ?
19:33:53 <rustyl> +1
19:34:10 <ttx> +1 to end, or to wait ?
19:34:14 <rustyl> to end
19:34:20 <dtroyer> he started it… but you probably want to find a pillow by now
19:34:29 <dtroyer> I'll hang here for a while either way
19:34:33 * ttx wonders if he can actually end it
19:34:45 <ttx> let's try otherwise we'll wait :)
19:34:47 <anteaya> he didn't make you chair
19:34:50 <anteaya> so no you can't
19:35:02 <ttx> damn SpamapS
19:35:12 <anteaya> anyone can end it after 20:04
19:35:20 <ttx> ok, I'll do some karaoke and dance then
19:35:27 <anteaya> next time he could do #chair ttx and then you are good
19:35:38 <anteaya> oh my goodness, glad I wandered by for this
19:35:47 <dtroyer> I didn' t know that one, thanks anteaya
19:35:49 <ttx> aaaaand Iiiiiiiiii iiiii wiiilll alwayyyyys looooove yooooouuuuuuououououou
19:35:54 <anteaya> dtroyer: welcome
19:36:04 <anteaya> quick fungi please end the meeting
19:36:19 <ttx> llloooooove youououououououo
19:36:44 <ttx> (karaoke usually makes SpamapS reappear)
19:37:14 <dtroyer> like kibo?
19:37:19 <anteaya> apparently you need to keep crooning
19:39:08 <ttx> Neun und neunzig luftballons.. und ihrem weg zum horizon
19:39:36 <anteaya> oh I like that one
19:39:45 <anteaya> haven't heard that one in a long time
19:40:19 <anteaya> much better than celine
19:40:27 <ttx> horizont*
19:40:50 <anteaya> dtroyer: kibo one of the volcanic cones on kilimanjaro?
19:41:16 <ttx> damn, my German doesn't work as well as in 1984
19:41:29 <dtroyer> no, he was a guy in the Usenet days who would pop inot any discussion that mentioned his name
19:41:35 <anteaya> I still got the jist
19:41:46 <anteaya> dtroyer: ha ha ha
19:41:55 <dtroyer> https://en.wikipedia.org/wiki/James_Parry
19:42:24 <dtroyer> I only saw it firsthand once
19:42:29 <anteaya> do tell
19:43:10 <dtroyer> in the original comp.os.linux group, someone mentioned him directly and he replied within 8 hours or so.  I totally forget what the topic actually was
19:45:04 <anteaya> what an interesting pattern of behaviour
19:45:29 <dtroyer> Usenet used to be fun ;)
19:45:34 <anteaya> I bet
19:45:39 <anteaya> so many things used to be fun
19:45:50 <dtroyer> Then came endless September (AOL) and Cantor and Siegel's grene card spam
19:45:53 <anteaya> the fact that such a thing was even possible at one point
19:45:54 <SpamapS> Long taxi
19:45:56 * SpamapS is in the air
19:46:06 * SpamapS reads backscroll
19:46:09 <dtroyer> don't look down
19:46:20 <ttx> SpamapS: yes, you won't be disappointed
19:46:28 <anteaya> ha ha ha
19:47:33 <anteaya> this should be framed: http://www.kibo.com/menu.shtml
19:47:55 <SpamapS> :)
19:47:57 <SpamapS> ok
19:48:06 <SpamapS> so yeah, I'm in favor of a less formal process and more forward progress
19:48:24 <ttx> and of karaoke
19:48:49 * dtroyer not so sure about karaoke
19:48:59 <ttx> alt.religion.kibology, classic
19:49:04 <SpamapS> my original thought in using the process was to make sure we don't step on anyone's toes or bypass parallel efforts, but I think we've shown that we're not doing that.
19:50:02 <SpamapS> So an architecture-specs repo might be a better way to go. I think we should discuss that at next week's meeting.
19:50:20 <SpamapS> I'll try to socialize the time for the meeting between now and then. I recommend everyone do the same. :)
19:50:21 <dtroyer> agreed
19:50:36 <SpamapS> thanks to those of you who came. and to ttx for reminding me it was happening while I was in line to board my flight ;)
19:50:44 <SpamapS> #endmeeting