15:00:00 <jimbaker> #startmeeting craton
15:00:01 <openstack> Meeting started Mon Feb  6 15:00:00 2017 UTC and is due to finish in 60 minutes.  The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:03 <jimbaker> #chair sigmavirus sulo jimbaker
15:00:04 <openstack> The meeting name has been set to 'craton'
15:00:05 <openstack> Current chairs: jimbaker sigmavirus sulo
15:00:35 <sigmavirus> o/
15:00:45 <jimbaker> #link https://etherpad.openstack.org/p/craton-meetings
15:00:53 <jimbaker> sigmavirus, please take the chair
15:01:15 <sigmavirus> So I'm editing the agenda now =<
15:01:21 <sigmavirus> #topic Roll Call
15:01:40 <jimbaker> o/
15:02:06 <thomasem> o/
15:02:11 <git-harry> hi
15:02:16 <sigmavirus> hi errybody
15:02:54 <sigmavirus> #topic Action Items from Last Meeting
15:02:56 <sigmavirus> #link http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-01-30-15.00.html
15:03:23 <sigmavirus> #note There were no action items apparently
15:03:29 <jimbaker> indeed
15:03:44 <sigmavirus> #topic Stand-Up
15:04:01 <sigmavirus> #note I'll go round the channel asking folks for their updates
15:04:12 <sigmavirus> #topic Stand-Up thomasem
15:04:24 <thomasem> Got my dev environment up and working cleanly
15:04:37 <thomasem> familiarized myself a bit with the project through patches for a couple of bugs
15:05:06 <thomasem> I added variables support for /projects which is in review (and I believe close to ready to merge): https://review.openstack.org/#/c/427777
15:05:28 <thomasem> I added CLI support for the existing /projects functionality in master, which is in review and has one +2: https://review.openstack.org/#/c/428996/
15:05:45 <thomasem> I threw up a quick fix for a little logic bug I found this morning: https://review.openstack.org/#/c/429725/
15:06:24 <sigmavirus> Sounds like a productive 1st week thomasem
15:06:29 <jimbaker> thomasem, thanks for that work, and sounds like some reviews to prioritize
15:06:38 <thomasem> Yep! Thanks!
15:06:46 <thomasem> As of today, wondering what I want to work on next
15:06:51 <thomasem> I filed 6 bugs over the past week
15:07:22 <thomasem> One I could quickly attack is the project admin permissions that sulo and I chatted about this morning https://bugs.launchpad.net/craton/+bug/1662199
15:07:22 <openstack> Launchpad bug 1662199 in craton "incorrect permissions for Projects CRUD" [Undecided,New]
15:07:36 <thomasem> And there are several others here https://bugs.launchpad.net/craton/+bugs?search=Search&field.bug_reporter=thomas-maddox
15:07:50 <jimbaker> good to look at the project with fresh eyes
15:07:51 <sigmavirus> Cool, let's discuss that later in the meeting?
15:07:54 <jimbaker> yes
15:08:06 <thomasem> Blocked by this patch https://review.openstack.org/#/c/427032/3 for adding support for projects variables
15:08:22 <thomasem> done. :)
15:08:24 <jimbaker> thomasem, ack
15:08:24 <sigmavirus> #topic Stand-Up git-harry
15:09:53 <git-harry> Related to the spec I put up about documenting/improving the variable API, I'm refactoring that part of the code to strip out all the duplication. This should simplify any work identified by that spec.
15:10:36 <git-harry> Currently sorting out the tests for it and then it should be done.
15:10:51 <git-harry> done
15:11:13 <sigmavirus> #topic Stand-Up jimbaker
15:11:49 <jimbaker> complete  https://review.openstack.org/#/c/427032 (variable support in the CLI for regions, cells, hosts; demoed last week)
15:12:30 <jimbaker> minor refactoring plan for the alembic migration to better support FK, PK constraint setup, in support of
15:12:36 <jimbaker> RBAC WIP posted
15:12:41 <jimbaker> done
15:12:50 <sigmavirus> #topic Stand-Up sulo
15:12:57 * sigmavirus thinks sulo is here
15:13:09 <sulo> yes o/
15:13:14 <sulo> if i missed that earler
15:13:26 <sulo> have a few outstanding patches that i need to finish
15:13:41 <sulo> on cli and and need to cleanup the spec (needs more reviews)
15:13:53 <sulo> but right now looking at exposing parent/child relational data
15:13:56 <sulo> in resources
15:14:06 <sulo> and in the mean time looking at making
15:14:13 <jimbaker> +1, this is very important work that toan has expressly asked for ASAP
15:14:20 <sulo> network-x related resouces more robust as well
15:14:34 <sigmavirus> jimbaker: the parent/child relational data?
15:14:35 <sulo> right now it looks like sellotaped stuff a litte
15:14:39 <sulo> all my fault ofcourse
15:14:41 <sulo> done
15:14:54 <sigmavirus> jimbaker: let's discuss that when we prioritize reviews
15:15:00 <sulo> sigmavirus: so each device can have a parent device
15:15:02 <jimbaker> sigmavirus, yes, the parent-child data
15:15:07 <sigmavirus> #topic Stand-Up sigmavirus
15:15:08 <jimbaker> sulo, let's wait
15:15:08 <sulo> we are not exposing it in the rest api
15:15:18 <git-harry> jimbaker: is that requirement captured anywhere/
15:15:43 <jimbaker> git-harry, yes, in dusty's doc
15:15:46 <sigmavirus> I'm finishing up the client related work for pagination as well as testing it. Still trying to decide how to display pagination to the cli
15:16:38 <sigmavirus> I need to investigate how other OS clients do it and what makes sense for us
15:17:01 <sigmavirus> I don't see Syed or Jovon in here
15:17:07 <sigmavirus> (or in #craton for that matter)
15:17:24 <sigmavirus> #topic This Week's Priorities
15:17:45 <sigmavirus> It seems we will want to prioritize the parent/child relationship work. It would be good to get that into a spec
15:17:51 <sulo> jimbaker: can you link the WIP for rbac ?
15:17:53 <jimbaker> sigmavirus, do any such tools support some cleverness like exporting their markers to the shell, such as via eval?
15:17:54 <sigmavirus> Perhaps we should work on turning Dusty's doc into a set of specs
15:18:10 <sulo> sigmavirus: +1
15:18:13 <jimbaker> sigmavirus, first: let's put it up in an etherpad
15:18:18 <jimbaker> so it's public
15:18:23 <jimbaker> i can take as an action item
15:18:36 <sigmavirus> #action jimbaker to turn dusty's doc into an etherpad
15:18:37 <sulo> its very difficutl to look at 10 different places to see req's so let just put it in LP
15:18:38 <jimbaker> then usual breakdown into blueprints
15:18:40 <jimbaker> et
15:18:42 <jimbaker> etc
15:18:49 <thomasem> +1!
15:18:53 <sulo> dont have to be specs .. lets make LP issues that can turn into specs later ?
15:19:05 <sigmavirus> sulo: blueprints or issues work
15:19:12 <sigmavirus> blueprints would be better if we plan to turn them into specs
15:19:20 <jimbaker> sulo, it's not directly actionable in that way - there's some overlap with completed work for example
15:19:25 <sigmavirus> we can then break down work items into individual issues like I did for pagination
15:19:35 <sulo> yeah i agree, just saying it would be nice to have it all in one place
15:19:45 <jimbaker> but we could put in as a bug or something
15:20:01 <sigmavirus> sulo: understood
15:20:02 <jimbaker> the resolution of which is a check off - there's a spec for each req
15:20:12 <jimbaker> or it's already done, just needs demoing
15:20:14 <jimbaker> that sort of thing
15:20:56 <jimbaker> that might be a blueprint that links to other blueprints. but in lp somehow
15:20:57 <sigmavirus> #action jimbaker once the etherpad is created, add reviewing it as a standing item to our meeting template
15:21:02 <sigmavirus> jimbaker: that's possible
15:21:46 <jimbaker> sigmavirus, +1 to doing this review
15:21:49 <sigmavirus> Okay, so after the parent/child prioritized work, what else is a priority
15:21:58 <sigmavirus> thomasem: can you #link the review blocking you?
15:22:22 <thomasem> #link https://review.openstack.org/#/c/427032/3
15:22:33 <jimbaker> antonym asked us about bulk set/get of resources and their variables last week
15:22:35 <sulo> jimbaker: is the rabc sutff posted, the wip patch ?
15:22:39 <jimbaker> sulo, no
15:22:42 <sulo> ah
15:22:51 <jimbaker> as i said, that's what i will be doing
15:22:56 <sulo> gotcha
15:23:02 <jimbaker> awesome
15:23:08 <sulo> i thought you meant you posted it to review as wip
15:23:10 <jimbaker> so back to bulk support
15:23:18 <jimbaker> sulo, i wish
15:23:28 <jimbaker> but it will be there soon enough!
15:23:52 <git-harry> bulk set == cell/region variables?
15:23:55 <jimbaker> so antonym asked us about why no update to the ansible-inventory endpoint
15:23:59 <sigmavirus> antonym: you need a batch API? do we have a user story for that? I advocated for it early on, but I assume you need it sooner rather than later
15:24:28 <jimbaker> sigmavirus, right now it's up to work that story out
15:24:32 <jimbaker> up to us
15:24:49 <antonym> yeah, ideally if we want to load up all of the information about a host up and keep it updated periodically it would be nice to batch it up
15:25:09 <jimbaker> or all of the hosts in a given project, that sort of thing
15:26:02 <jimbaker> we can update a host in just a couple of ops at this time, it would be straightforward to make this one op if we wanted
15:27:18 <git-harry> So who's going to pick up the spec for this?
15:27:20 <jimbaker> so i suggested a scheme of a payload that is a list of resources to be updated/set, with json data for each
15:27:37 <jimbaker> git-harry, might be something you are interesting in working on?
15:27:43 <sigmavirus> git-harry: I can since I have some ideas around batch APIs but after pagination work is done
15:27:55 <sigmavirus> or thomasem can work on this
15:28:00 <jimbaker> ok, so at least one volunteer. or three
15:28:02 <jimbaker> :)
15:28:14 <thomasem> Happy to
15:28:19 <jimbaker> some stepping up, others being volunteered :)
15:28:41 <sigmavirus> As meeting chair, it's my job to voluntell
15:28:44 <thomasem> Oh. Well, either way. It'd be exploratory and educational for me.
15:28:47 <jimbaker> sigmavirus, +1
15:29:21 <sigmavirus> #action git-harry and thomasem should decide who will write the spec
15:29:29 <thomasem> Hahahaha
15:29:40 <sigmavirus> hashtag helping
15:30:09 <thomasem> I propose a Sicilian battle of wits.
15:30:11 <sigmavirus> Okay, with thomasem's blocking review, what else do we have?
15:30:28 <sigmavirus> thomasem: never go up against a Sicilian when death is on the line
15:30:35 <jimbaker> git-harry, thomasem, should be straightforward for say PUT. i assume it gets more interested once we bring in pagination and presumably JSON PATCH
15:30:47 <thomasem> Yeah
15:31:05 <sigmavirus> Also a batch API will need the ability to check the status since it will be an async create
15:31:21 <sigmavirus> Having a response held up while we create 700 devices would be ridiculous
15:31:31 <thomasem> Very much so
15:32:02 <sigmavirus> #action sigmavirus to update pagination API work to add functional tests now that sulo's work has landed
15:32:04 <jimbaker> sigmavirus, ahh, interesting detail. we have pushed async out of the craton api server until now
15:32:17 <jimbaker> eg using something like taskflow for workflow support
15:32:19 <sigmavirus> #action sigmavirus to finish up testing on cli
15:32:50 <sigmavirus> jimbaker: well the server (especially given how we're "deploying" it in our docker container) will not be able to handle this synchronously
15:33:01 <sigmavirus> Nor would anyone expect a batch API to return anything other than a 202
15:33:20 <jimbaker> sigmavirus, i would assume that no one would deploy the api server as it is in that docker container
15:33:28 <jimbaker> or Dockerfile setup to be precise
15:33:39 <sigmavirus> jimbaker: that's a mighty big assumption
15:33:46 <thomasem> Yeah. Actually, when did we want me to start working on, like, docker-compose and such for that?
15:33:55 <sigmavirus> thomasem: that won't belong in craton itself
15:34:02 <jimbaker> sigmavirus, that's why thomasem has been looking at the right deployment scheme
15:34:14 <jimbaker> code is fine. it's just a matter of proper deployment
15:34:19 <git-harry> wouldn't that live in openstack-ansible?
15:34:30 <sigmavirus> git-harry: so openstack-ansible is going to deploy its own dependency?
15:34:38 <thomasem> sigmavirus: I had this: https://blueprints.launchpad.net/craton/+spec/docker-compose-dev-environment
15:34:51 <jimbaker> exactly. it's going to be a recommended setup, maybe using docker compose. but something robust
15:35:02 <thomasem> as well
15:35:03 <jimbaker> and no dependency on ansible
15:35:12 <jimbaker> or at least not OSA
15:35:21 <sigmavirus> thomasem: if we're only using compose for dev that's fine
15:35:28 <git-harry> sigmavirus: in terms of the way it's deployed I would expect support to want it consistent.
15:35:34 <sigmavirus> That said, I'd expect actual priorities to.. y'know.. take priority
15:35:41 <thomasem> Right
15:36:16 <sigmavirus> git-harry: it's a chicken and egg problem
15:36:43 <thomasem> Alright, so, if I'm supposed to be looking at deployment schemes, where do we really want to start with that? A spec?
15:36:57 <sigmavirus> thomasem: production deployment schemes? That should be docs only
15:37:06 <git-harry> sigmavirus: an OSA role can stand alone so not really.
15:37:09 <sigmavirus> craton itself shouldn't also have the code to deploy it, just the documented architecture
15:37:45 <thomasem> sigmavirus: okay, cool. I'll throw together a BP (if one doesn't exist) to address that and get us something to iterate on as a suggested deployment.
15:38:07 <sulo> so whats the priority list again ? I missed what priority items we decided to work on now
15:38:19 <sigmavirus> sulo: I don't think we've decided on much honestly
15:38:23 <thomasem> #action thomasem to create BP, with initial thoughts, regarding suggested production deployment documentation
15:38:24 <sigmavirus> We keep getting bogged down in details
15:38:44 <sulo> lets decide that ... i think that becoming more and more important and pressing
15:38:58 <jimbaker> +100
15:39:15 <jimbaker> cannot go production unless we finalize these details. but
15:39:23 <jimbaker> we have a very simple architecture
15:39:34 <sigmavirus> (Until we add the workflow engine)
15:39:35 <jimbaker> from what needs to be deployed
15:39:38 <sigmavirus> =P
15:39:50 <thomasem> hah, yeah. workflow is going to be the meaty part
15:40:03 <jimbaker> sigmavirus, yes, but even then, we have had discussions of simplifying that deployment as well
15:40:17 <thomasem> Can anyone point me to this discussion?
15:40:35 <jimbaker> thomasem, over on #craton presumably
15:41:03 <jimbaker> but in a nutshell, this is having workers take advantage of containers
15:41:06 <sigmavirus> So for *this week*
15:41:15 <git-harry> there is a spec
15:41:16 <sigmavirus> Parent/child relation work?
15:41:47 <jimbaker> sulo, want to elaborate
15:41:48 <jimbaker> ?
15:41:56 <sulo> parent/child ?
15:42:06 <jimbaker> so the schema captures
15:42:20 <sigmavirus> I'm asking if we want to prioritize that for *this week* (sorry for the ambiguity)
15:42:33 <jimbaker> sigmavirus, it is the highest priority item for this week
15:42:48 <sulo> yes, i am looking at it this week, will create appropriate spec
15:42:53 <sigmavirus> #info Parent/Child Relationship work is the highest priority work for this week
15:43:10 <sigmavirus> After that then, we have ... what?
15:43:22 <sulo> the whole thing depends on how involved we want this for networking deivices
15:43:28 <sulo> thats what i am looking at today
15:43:34 <jimbaker> sigmavirus, that would be finishing up the WIP for resource setters we demoed
15:43:40 <sulo> for devices its pretty simple each device has parent_id
15:43:48 <sulo> but if we want to draw "cab view"
15:43:55 <sulo> then it goes into networking devices
15:43:58 <jimbaker> and then RBAC published as WIP
15:44:04 <sigmavirus> #info After Parent/Child Relationship work, finishing up resource setters work is the highest priority
15:44:05 <sulo> how netwoks connect to devices ot interfaces etc
15:44:11 <sulo> anyway will create spec accordingly
15:44:15 <jimbaker> sulo, thanks
15:44:35 <jimbaker> even something simple that shows this working will be helpful for being demoable this week
15:45:58 <sigmavirus> Okay, then what?
15:47:09 <jimbaker> in terms of being demoable? it will allow us to better understand the problem, and to see if that would work for toan, antonym, and others
15:47:34 <git-harry> jimbaker: do you have to give another demo soon?
15:47:46 <git-harry> is there a deadline you are working towards for these tasks?
15:47:50 <sigmavirus> jimbaker: I'm talking this week's priorities still
15:47:59 <jimbaker> git-harry, toan asked for parent/child for this week
15:48:06 <sulo> wait, that just one priority item, what are other items
15:48:20 <sigmavirus> sulo: we have two so far
15:48:26 <sigmavirus> Parent/Child & The setters work from the demo
15:48:27 <sulo> and RBAC ?
15:48:40 <sulo> there is demo ?
15:48:43 <jimbaker> yes, but only parent/child is necessary for the week
15:48:50 <sigmavirus> Okay
15:48:53 <sigmavirus> So we're done with priorities then
15:48:56 <sigmavirus> Great
15:49:00 <jimbaker> that's the only thing we were explicitly asked to do. cool!
15:49:05 <sigmavirus> #topic Open Discussion
15:49:06 <git-harry> We need a better way of tracking this stuff
15:49:14 <sulo> i am not following this ...
15:49:23 <sulo> what demo is this now ?
15:49:36 <thomasem> Better way of tracking... priorities? Upcoming demos?
15:49:46 <thomasem> Both?
15:49:49 <jimbaker> hah! just tracking it seems
15:49:57 <thomasem> Yep. Agreed wholeheartedly.
15:50:00 <sigmavirus> sulo: the last demo, jimbaker demo'd some setters work?
15:50:03 <jimbaker> so farid is joining us tomorrow
15:50:05 <thomasem> It's a huge mental burden to try and glean it from re-reading scrollback.
15:50:14 <sigmavirus> thomasem: that's what meeting minutes are for
15:50:16 <git-harry> thomasem: everything.
15:50:57 <sigmavirus> Well we have LaunchPad for blueprints/bugs that people don't use consistently for tracking that information
15:51:05 <sigmavirus> We have Gerrit for tracking in progress reviews
15:51:14 <thomasem> I suppose I meant more for the state of things point-in-time.
15:51:15 <sulo> ok let me suggest, we track this priority items somewhere, i prefer LP .. one palce for all things
15:51:21 <sigmavirus> We don't have much for tracking what is a priority though besides the meeting minutes
15:51:24 <git-harry> sigmavirus: non of that tracks Rackspace priorities/deadlines etc
15:51:36 <jimbaker> farid will be working as the dev manager for the project, to help do things like rollups, and make sure that everyone has the info they need
15:51:40 <sigmavirus> git-harry: this is an OpenStack project. Rackspace priorities should be tracked elsewhere
15:52:16 <git-harry> sigmavirus: agreed, but given the way we are currently blurring that boundary I'm raising it here.
15:53:18 <jimbaker> it's good to track what our users expect
15:53:31 <jimbaker> rackspace, nokia, whomever
15:53:50 <git-harry> our users are Rackspace
15:53:56 <sigmavirus> And presently the only people we have who are bold enough to call themselves users are Rackspace
15:54:01 <git-harry> everyone here works for Rackspace
15:54:03 <sigmavirus> git-harry: other organizations have expressed interest
15:54:16 <git-harry> sigmavirus: sure but we're not making that distinction
15:54:18 <jimbaker> yes, and so if we start with a user-centered focus, we are good
15:54:32 <git-harry> sigmavirus: all the talk about demos, priorities etc relates to Rackspace
15:54:34 <sigmavirus> git-harry: well we're also not making it easy for them to collaborate
15:55:09 <jimbaker> git-harry, demos for rackspace only came up recently. but since they are users, there's no conflict
15:56:07 <jimbaker> everything we have been asked to do, we have already intended to work on
15:56:35 <jimbaker> it's just a question of how our users have helped us with prioritization, that's all
15:56:55 <jimbaker> and better understanding the problem
15:57:17 <jimbaker> i see no conflict here
15:57:52 <sigmavirus> jimbaker: git-harry isn't claiming conflict, he's claiming we should call this "Rackspace Craton" not "OpenStack Craton"
15:58:03 <sigmavirus> (if I understand correctly)
15:58:05 <git-harry> yes
15:58:33 <jimbaker> i hope we can ensure it's openstack craton. that's certainly our mission here
15:59:01 <jimbaker> i heard that repeatedly stressed from all stakeholders in rackspace, fwiw
15:59:16 <jimbaker> but it's up to us to deliver! :)
15:59:20 <git-harry> It's not that Rackspace shouldn't be represented it just seems that we are using OpenStack systems to manage the Rackspace side of it.
15:59:44 <jimbaker> let's move this discussion over to #craton
15:59:53 <jimbaker> #endmeeting