14:59:59 <thomasem> #startmeeting craton
14:59:59 <thomasem> #chair sigmavirus sulo jimbaker thomasem
14:59:59 <openstack> Meeting started Mon Mar 20 14:59:59 2017 UTC and is due to finish in 60 minutes.  The chair is thomasem. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <thomasem> #link https://etherpad.openstack.org/p/craton-meetings
15:00:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:01 <thomasem> #topic Roll Call
15:00:03 <openstack> The meeting name has been set to 'craton'
15:00:04 <openstack> Current chairs: jimbaker sigmavirus sulo thomasem
15:00:09 <thomasem> o/
15:00:19 <sulo> o/
15:01:00 <thomasem> jimbaker, sigmavirus, and fsaad said they'll be a little late.
15:01:18 <thomasem> o/ anonymike
15:01:33 <anonymike> \o thomasem
15:01:34 <antonym> o/
15:01:57 <thomasem> #topic Action Items from Last Meeting
15:01:58 <thomasem> #link  http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-03-13-15.00.html
15:02:38 * thomasem thomasem to write BP regarding deployment as a starting point for iterating on a suggested deployment model
15:02:54 <thomasem> Higher priority things in play, will be punting this again. I do think I can get something up this week, though!
15:03:01 <thomasem> #action thomasem to write BP regarding deployment as a starting point for iterating on a suggested deployment model
15:03:11 * thomasem jimbaker to map Dusty's requirements to work or existing features of Craton, especially with respect to short-term deliverable
15:03:30 <thomasem> Not sure how relevant this is anymore, will hear jimbaker's thoughts when he gets in (probably in Open Discussion or prioritizing).
15:03:41 <thomasem> #topic Stand-up
15:03:41 <thomasem> #info each team member briefly describes what they are working on this week, and describes blockers (if there are any)
15:03:49 <thomasem> #topic Stand Up :: thomasem
15:04:14 <tojuvone> hi
15:05:28 <thomasem> Cleaning up MySQL 5.7 patch today by updating documentation according to some testing in Ubuntu 16.04, CentOS 7, and Fedora 25 and being sure the documented install works, and noting the requirement of MySQL 5.7 for nested variable searching. Also have several reviews I want to go through today.
15:06:27 <thomasem> Started work on functional tests for nested variable search... trying to do it in a way that affords for testing all resources the same way, so we're not copy/pasting everywhere and possibly introducing inconsistencies. Working through some snags there.
15:06:54 <thomasem> The patch, however, can be pulled down and run as long as you're using MySQL 5.7
15:07:05 <thomasem> #link https://review.openstack.org/443941
15:07:08 <thomasem> done
15:07:14 <thomasem> #topic Stand Up :: sulo
15:08:05 <sulo> working on a few issues re: users cretion, found some more issues that needs fixing .. after that i might poke that device sharing
15:08:07 <sulo> done
15:08:24 <thomasem> #topic Stand Up :: anonymike
15:09:15 <anonymike> Hello all. My name is Michael, I'm a developer at Rackspace and I just started on the Craton team today. I'm working on transferring some internal accounts  and getting my dev environment setup.
15:09:37 <anonymike> done
15:09:44 <thomasem> #topic Stand Up :: antonym
15:11:08 <antonym> testing out thomasem's patch for searching on a list of mac's which works well after switching to mysql 5.7, also got together a dev playbook for setting up the stack on a server w/o docker, done
15:11:22 <thomasem> (YAY!)
15:11:38 <antonym> it's here for right now: https://github.com/antonym/ecopoiesis/blob/master/roles/ecopoiesis/tasks/craton_install.yml
15:11:48 <antonym> probably need to pull it out into a role
15:11:53 <thomasem> #link https://github.com/antonym/ecopoiesis/blob/master/roles/ecopoiesis/tasks/craton_install.yml
15:12:21 <thomasem> #topic This Week's Priorities
15:12:33 <jimbaker> o/
15:12:59 <sulo> antonym: nice!
15:13:30 <thomasem> Priorities (tentative):
15:13:46 <thomasem> 1. https://review.openstack.org/441644
15:13:50 <thomasem> (Alembic)
15:14:24 <jimbaker> thomasem, thanks, yes, i will be finalizing this. i don't anticipate anything blocking that work
15:14:26 <thomasem> 2. https://review.openstack.org/446972 and https://review.openstack.org/446938 (Issue with creating users)
15:14:52 <thomasem> 3. https://review.openstack.org/440929 (Resolved Variable Search)
15:15:05 <thomasem> 4. https://review.openstack.org/443186 (MySQL 5.7 and SQLAlchemy 1.1.6)
15:15:15 <thomasem> 5. https://review.openstack.org/443941 (Nested variable search)
15:15:36 <thomasem> Do folks agree with those priorities?
15:15:56 <jimbaker> thomasem, these look good as our most important priorities
15:16:08 <thomasem> #2 is how project_id was not being honored in user creation, so it's a big deal.
15:16:30 <jimbaker> agreed about this being a big deal
15:16:41 <jimbaker> it effectively means we are not multitenant until we get this done
15:17:12 <jimbaker> (was hidden until recently because we were using mysql directly. don't do that :)
15:17:14 <thomasem> Other than that, we have some integration test stuff up for craton client, which has been a gap for a while.
15:17:37 <thomasem> and we have some documentation that sigmavirus shored up.. so several in-flight reviews that could use some eyes.
15:17:37 <sigmavirus> sorry for being late. I think some of the leftovers I ate yesterday went bad
15:17:58 <sigmavirus> Yep, I'll be working on more documentation to get some stuff at the least started
15:18:22 <thomasem> Excellent! Thanks for doing that, sigmavirus!
15:18:32 <jimbaker> sigmavirus, thanks! important stuff for the project
15:18:48 <sigmavirus> I'll be working on doing some reveiws too
15:18:51 <jimbaker> much as we saw how getting tox -e functional made a huge diff
15:19:13 <thomasem> Alright, assuming that's smiles all around, let's move into open discussion.
15:19:20 <jimbaker> :) :) :)
15:19:30 <thomasem> #topic Open Discussion
15:19:34 <thomasem> We have several topics today
15:19:47 <thomasem> from sulo: Review process (proposing that we require at least 2 +2 before a +1, so atleast 2 ppl review before merge)
15:20:28 <jimbaker> makes sense
15:20:43 <anonymike> I agree
15:20:46 <jimbaker> let's be clear, there are several valid review processes in open source
15:21:12 <thomasem> s/people/cores/
15:21:13 <jimbaker> but given team size, openstack standards, and current project goals, we should be good
15:21:31 <thomasem> s/people/ppl/
15:21:32 <thomasem> :)
15:21:40 <jimbaker> thomasem, yep, implied by gerrit :)
15:21:50 <thomasem> Haha, indeed
15:22:13 <jimbaker> obviously we were in an expedited mode in 0.1.0
15:22:19 <jimbaker> and that was a good thing
15:22:27 <jimbaker> but we need to go to normal mode now
15:22:34 <thomasem> So, yeah, during the time we needed to move fast and cores were out, we saw a need to afford for cores to self-merge high value things. We tended to favor some +1s at least. But, yeah, now that we're towards the end of that short-term workstream, it definitely makes sense to tighten back up.
15:22:38 <thomasem> Right
15:23:03 <thomasem> sulo: anything to add?
15:24:14 <sulo> thomasem: nothing on the review, process, looks like we all agree
15:24:25 <thomasem> Awesome
15:24:35 <jimbaker> agreement all around
15:24:38 <thomasem> from sulo: Do we want to support, transfer of resouces between projects, see Ian's comment on: https://review.openstack.org/#/c/446938
15:24:52 <jimbaker> thomasem, so sounds like an #agreed item
15:25:03 <thomasem> Oh, sorry. Didn't know that was a command.
15:25:21 <sigmavirus> thomasem:  it s
15:25:26 <sigmavirus> usually happens after a #vote though
15:25:27 <sigmavirus> =P
15:25:35 <jimbaker> sigmavirus, thanks for the process help
15:25:47 <thomasem> #agreed require at least 2 +2 before a +1 workflow, so at least 2 cores review before merge
15:26:14 <thomasem> lol, gotcha
15:26:24 <jimbaker> thanks. we will do a formal vote next time. but we do an informal canvassing
15:26:37 <jimbaker> we *did* do
15:26:52 <thomasem> Either/or. As long as #agreed works the same ultimately.
15:26:54 <thomasem> imo
15:26:57 <jimbaker> just want to doc in minutes appropriately at the very least
15:26:58 <jimbaker> yep
15:27:06 <jimbaker> cool, next topic?
15:27:12 <thomasem> Yep, noted it above ^^
15:27:24 <thomasem> "from sulo: Do we want to support, transfer of resouces between projects, see Ian's comment on: https://review.openstack.org/#/c/446938"
15:27:38 <thomasem> I think sigmavirus and sulo were discussing this earlier
15:27:44 <jimbaker> ahh, this is a very interesting problem
15:27:56 <sigmavirus> Right, I'm not certain we do
15:28:01 <sigmavirus> But I'm also not certain others won't want it
15:28:07 <sigmavirus> So I'm not saying we should support it now
15:28:12 <thomasem> This also has some implications here: https://bugs.launchpad.net/craton/+bug/1666699 (able to create unexpected relationships via API)
15:28:12 <openstack> Launchpad bug 1666699 in craton "able to create unexpected relationships via API" [Undecided,New]
15:28:22 <jimbaker> thomasem, agreed with that
15:28:29 <jimbaker> i think the following should hold
15:28:50 <jimbaker> we should not require the user to work with our denormalized data model
15:28:58 <jimbaker> that to me is an implementation detail
15:29:03 <jimbaker> that should not be exposed
15:29:29 <jimbaker> that it in fact is exposed (poorly) is causing that bug
15:29:39 <jimbaker> mentioned above
15:30:03 <jimbaker> so what does this mean in practice?
15:30:22 <jimbaker> if creating a cell, just specify its region_id
15:30:43 <jimbaker> i think the way it sneaked in here is the optional cell part
15:31:43 <thomasem> I think some audit of the exposure is important here. Does one not need to specify all parents of, say, a device that's being created?
15:32:04 <jimbaker> thomasem, that's the net of it. only specify the parent
15:32:08 <thomasem> Right
15:32:18 <jimbaker> i suppose we could allow for overspecification
15:32:40 <jimbaker> but only the parent counts, and if the overspecification is wrong, then an error is returned
15:32:49 <thomasem> Right, so why have it in the first place?
15:33:03 <jimbaker> thomasem, i think it makes sense from a data model perspective
15:33:13 <jimbaker> denormalization is a valid approach
15:33:26 <jimbaker> but again, impl detail
15:33:35 <jimbaker> that the client should not have to be aware of
15:33:59 <jimbaker> having said that: i'm absolutely fine with us re-opening and looking at consequences
15:34:01 <thomasem> I have some concerns with that being the only approach, but until I have something concrete to suggest, I'd prefer not rabbit hole on it.
15:34:22 <jimbaker> thomasem, yep. this is entirely valid refactoring
15:34:43 <thomasem> Yeah. It's on my to-do list to pull in some data modeling folks and see what options might suit our needs and improve our data integrity constraints at the DB rather than having to code around it.
15:34:59 <jimbaker> thomasem, we can always benefit from a review
15:35:01 <thomasem> But, ultimately the problem is it's exposed to the user as a bug now, so yep.
15:35:39 <thomasem> And, bringing it back to the original topic, if we afford for moving resources between projects, we have to be sure we maintain that integrity along the way.
15:35:53 <jimbaker> right, let's get rid of this bug by 1) requiring only parent; 2) possibly allow overspecification (and that also is backwards compatible...)
15:36:15 <jimbaker> thomasem, agreed
15:36:25 <jimbaker> a database is of little use if it's corrupted
15:36:28 <thomasem> So, the original question was: do we want to allow for that?
15:36:30 <thomasem> Spot on
15:36:58 <thomasem> What are some use-cases for allowing us to move resources between projects? And what resources?
15:37:27 <jimbaker> in principle, i see it as being reasonable. however, it may make the multisource replication more challenging
15:37:47 <thomasem> Oh, yeah... also if we can move between projects, why not clouds, regions, cells, etc.?
15:38:09 <thomasem> I can see a case for, say, rebalancing hosts between cells
15:38:26 <jimbaker> within a project, it makes perfect sense
15:38:32 <thomasem> Right
15:38:49 <thomasem> So, is this a question we want to address now or later? Do we have concrete use-cases?
15:39:02 <jimbaker> across a project, i think this gets more complicated, because we implicitly (!) been assuming that project could be used for partitioning
15:39:40 <jimbaker> (from a sharded perspective, or direct customer placement)
15:40:01 <jimbaker> thomasem, my feeling is that we punt for now
15:40:17 <thomasem> Mine, too.
15:40:23 <thomasem> sulo, sigmavirus?
15:40:51 <sigmavirus> Yeah, like I said, no need to fix this now
15:40:52 <jimbaker> let's look at the standard answer for distributed file systems. we actually copy/delete when we say "move"
15:41:42 <thomasem> Cool, so we'll discuss this again when it comes up as a use-case we wish to support?
15:41:51 <jimbaker> agreed
15:41:58 <thomasem> Excellent. Anything else folks wish to talk about>?
15:41:59 <jimbaker> and again we can support this at least 2 ways
15:42:11 <thomasem> Yeah
15:42:24 <jimbaker> (i think the copy/delete paradigm works best... even if this means IDs are remapped. which is a good thing for multisource)
15:42:41 <thomasem> And it means we need to do nothing to support it. :P
15:42:47 <jimbaker> yes :)
15:43:07 <jimbaker> bulk export out of a project; bulk import into a new project; done
15:43:10 <thomasem> If there's nothing else, we can get a whole 17 minutes of our lives back.
15:43:16 <thomasem> :D
15:43:49 <thomasem> jimbaker: yep!
15:43:58 <thomasem> Alrightyo, closing in..
15:44:00 <thomasem> 3...
15:44:03 <thomasem> 2...
15:44:06 <thomasem> 1...
15:44:08 <thomasem> #endmeeting