17:05:13 <jimbaker> #startmeeting craton
17:05:14 <openstack> Meeting started Thu Feb 23 17:05:13 2017 UTC and is due to finish in 60 minutes.  The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:05:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:05:17 <jimbaker> #chair sigmavirus sulo jimbaker thomasem
17:05:18 <openstack> The meeting name has been set to 'craton'
17:05:19 <jimbaker> #link https://etherpad.openstack.org/p/craton-meetings
17:05:20 <openstack> Current chairs: jimbaker sigmavirus sulo thomasem
17:05:21 <jimbaker> #topic Roll Call
17:05:25 <thomasem> o/
17:05:28 <sigmavirus> o/
17:05:46 <jimbaker> o/
17:05:52 <git-harry> hi
17:06:07 <sigmavirus> Syed__: farid jovon ping
17:06:14 <sulo> o/
17:06:23 <jovon> o/
17:06:26 <Syed__> o/
17:06:54 <farid> o/
17:07:18 <jimbaker> thomasem, i assume you will chair today's meeting...
17:07:21 <thomasem> #topic Action Items from Monday's meeting
17:07:24 <thomasem> yep
17:08:01 <thomasem> #link http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-20-15.00.html
17:08:20 * thomasem thomasem to write BP regarding deployment as a starting point for iterating on a suggested deployment model
17:08:28 <thomasem> Carrying forward. Busy with higher priority items atm.
17:08:41 <thomasem> #action thomasem to write BP regarding deployment as a starting point for iterating on a suggested deployment model
17:08:41 <jimbaker> +1
17:08:50 * thomasem jimbaker to map Dusty's requirements to work or existing features of Craton, especially with respect to short-term deliverable (~2 weeks remaining)
17:09:11 <jimbaker> so this has been in the back of my mind. i think we have been working implicitly against this
17:09:20 <jimbaker> in terms of bugs, but more fomalization needed
17:09:26 <jimbaker> carry forward, please
17:09:34 <jimbaker> (done
17:09:37 <thomasem> #action jimbaker to map Dusty's requirements to work or existing features of Craton, especially with respect to short-term deliverable (~2 weeks remaining)
17:09:45 * thomasem thomasem to review Dusty stories and add notes on concerns or questions
17:10:36 <thomasem> Seems we're going against Björn's use cases more than anything. I asked a few clarification questions, but overall, no discrepancies found from what we're working on overall.
17:11:02 <sigmavirus> thomasem: Bjoern ;)
17:11:09 <thomasem> Will be interested to see what comes out of jimbaker's action item regarding that.
17:11:30 <thomasem> oe = ö does it not? :P
17:11:35 <jimbaker> agreed that bjoern (= björn presumably)
17:11:44 <jimbaker> has the more detailed stories for the time being
17:11:48 * sigmavirus just knows that's how Bjoern tends to spell his name
17:11:57 <thomasem> Cool. I will refrain from being fancy, then.
17:12:06 <thomasem> done on that action item from me.
17:12:12 * thomasem sigmavirus to finish up testing on cli
17:12:35 <sigmavirus> That's in progress
17:12:39 <sigmavirus> Also as part of that, I'm throwing together a minimal pluggable formatter system so we can simply our shell integration tests
17:13:04 <sigmavirus> (That way the tests can use the json formatter for most things and verify the output that way, while also using the pretty-table formatters but not relying on those for the bulk of our tests)
17:13:15 <thomasem> Gotcha
17:13:20 <sigmavirus> #action sigmavirus finish up client/cli testing
17:13:25 <sigmavirus> (Carried that forward for you)
17:13:33 <thomasem> Aww thanks
17:13:39 * sigmavirus is a helper
17:13:39 <jimbaker> sigmavirus, awesome, that's great stuff
17:13:42 <sigmavirus> or something
17:13:49 <thomasem> Okay, cool. That concludes action items.
17:13:56 <thomasem> #topic Stand Up
17:14:04 <thomasem> #info each team member briefly describes what they are working on this week, and describes blockers (if there are any)
17:14:10 <thomasem> #topic Stand Up :: thomasem
17:14:53 <thomasem> Working on clouds some more, turned into quite a bit of nuances that need to be shored up. Found some issues with cloud_id filtering, so in the process of correcting those and will add tests.
17:15:24 <thomasem> Also working on the CLI changes to support the cloud endpoint and support the cloud_id which will be sprinkled throughout the child resources, as is the going pattern for our relational representation in the API at the moment.
17:15:40 <thomasem> Filed some bugs around that specifically to see if we can't clean that up in future iterations of the data model and API.
17:15:55 <thomasem> #link https://bugs.launchpad.net/craton/+bug/1666699
17:15:55 <openstack> Launchpad bug 1666699 in craton "able to create unexpected relationships via API" [Undecided,New]
17:16:00 <thomasem> #link https://bugs.launchpad.net/craton/+bug/1666695
17:16:01 <openstack> Launchpad bug 1666695 in craton "project ID not honored in requests" [Undecided,New]
17:16:38 <thomasem> Other than that, putting my eyes to code reviews as they come in.
17:16:51 <thomasem> Hopefully at the tail of this cloud work and then I'll pick up the next critical thing!
17:16:52 <thomasem> done
17:17:20 <thomasem> #topic Stand Up :: sigmavirus
17:18:23 <sigmavirus> Working on cratonclient tests. Looking at thomasem's cloud review occasionally. Working on a slapdash client formatter system. /fin
17:18:57 <thomasem> #topic Stand Up :: jimbaker
17:19:07 <jimbaker> finalize testing for https://review.openstack.org/#/c/427032/; write alembic script for https://bugs.launchpad.net/craton/+bug/1665066; i might tackle https://bugs.launchpad.net/craton/+bug/1661226, given this should be an important way to look up devices
17:19:07 <openstack> Launchpad bug 1665066 in craton "Alembic script must use named constraints to support future upgrades" [Critical,New] - Assigned to Jim Baker (jimbaker)
17:19:07 <jimbaker> we need to focus on specific imports from openstack and making sure that pwnall1337 is successful (thomasem is point, but this is our most important responsibility, getting this to work as expected for next week!)
17:19:08 <openstack> Launchpad bug 1661226 in craton "Filter by variables lacks resolved variables" [Critical,Confirmed]
17:19:09 <jimbaker> more reviews, especially the cloud support that thomasem has worked on
17:19:11 <jimbaker> done
17:19:27 <thomasem> #topic Stand Up :: git-harry
17:20:19 <git-harry> finishing off /v1/devices today
17:20:20 <git-harry> done
17:20:33 <thomasem> #topic Stand Up :: sulo
17:21:16 <sulo> mostly catching up
17:21:35 <sulo> got a couple of bugs to fix
17:21:43 <sulo> mostly on cross tenant search
17:21:49 <jimbaker> +1
17:21:52 <sulo> and on cleaning up schema for creates
17:22:02 <sulo> other than that just usual stuff reviews etc
17:22:03 <sulo> done
17:22:15 <thomasem> #topic Stand Up :: jovon
17:22:17 <jimbaker> sulo, are we describing json schemas?
17:22:31 <thomasem> #undo
17:22:32 <openstack> Removing item from minutes: #topic Stand Up :: jovon
17:22:49 <sulo> yes
17:22:53 <sigmavirus> let's hold off on questions until after standup
17:22:54 <jimbaker> ok, cool
17:22:57 <thomasem> #topic Stand Up :: jovon
17:23:07 <jovon> experimenting with RAML and ramlfication to develop an easy-to-use implementation strategy with existing craton docs or a minimal manual translation
17:23:29 <jovon> done
17:23:35 <thomasem> #topic Stand Up :: Syed__
17:23:38 <Syed__> As per tuesday meeting, i have been looking into cratonclient, more specifically looking into https://bugs.launchpad.net/python-cratonclient/+bug/1659238 and hoping to get this done https://review.openstack.org/#/c/425463/ .
17:23:38 <openstack> Launchpad bug 1659238 in Craton's Python Client "client is missing user related commands" [Undecided,In progress] - Assigned to Syed Ahsan Shamim Zaidi (ahsanmohsin04)
17:23:40 <Syed__> done
17:23:48 <thomasem> #topic Stand Up :: farid
17:25:05 <farid> got a couple client tickets in and plan on working today with tim on any aio/inventory load questions, tickets are https://bugs.launchpad.net/python-cratonclient/+bug/1667109 and https://bugs.launchpad.net/python-cratonclient/+bug/1667376
17:25:05 <openstack> Launchpad bug 1667109 in Craton's Python Client "Allow environment export from client" [Undecided,New]
17:25:05 <farid> done
17:25:06 <openstack> Launchpad bug 1667376 in Craton's Python Client "Allow loading an Openstack inventory into Craton" [Undecided,New] - Assigned to Tim Pownall (pownalltim)
17:25:48 <thomasem> #topic Open Discussion
17:25:55 <thomasem> Nothing on the etherpad in the way of topics, so.
17:26:14 <thomasem> Think we're all just heads down getting it done.
17:26:22 <jimbaker> sulo, any more discussion on cross-project queries?
17:27:23 <sulo> jimbaker: not really, i veryfiy everyting and we can discuss if anything comes up
17:27:24 <jimbaker> thomasem, looks like we can just assume heads down, and maybe a quick meeting otday
17:27:33 <jimbaker> sulo, +1
17:28:04 <thomasem> Excellent. I did have a quick question that came out of working with pwnall1337 yesterday.
17:28:16 <thomasem> What's the story with UUIDs sans hyphens?
17:28:26 <thomasem> for, like, project_id
17:28:35 <jimbaker> i'm sorry, what's the context here?
17:28:41 <jimbaker> in the database?
17:28:48 <thomasem> Yeah, and in the headers
17:29:03 <thomasem> Is that just an OpenStack thing, or something else?
17:29:16 <jimbaker> so we should be able to support UUID with and without hyphens
17:29:34 <jimbaker> at entry point
17:29:43 <thomasem> Ahhh, it truncates the UUID when you generate one when storing in the DB to the size of a UUID sans hyphens.
17:30:06 <thomasem> Which caused us to chase our tails a bit when using UUID() in MySQL
17:30:09 <jimbaker> and on exit from the api, it would be far better if they are formatted
17:30:21 <thomasem> I think they come back with hyphens just fine.
17:30:41 <thomasem> But, they're forcibly stored according to the length of an improper uuid in the DB.
17:30:43 <jimbaker> so: there's a basic assumption that we are using the uuid type that sqlachemy ext provides us
17:30:49 <thomasem> So, if that's not intended, I can file a bug.
17:31:07 <jimbaker> in the db itself, they are stored as a string without hyphens iirc
17:31:10 <jimbaker> and that's fine
17:31:15 <thomasem> Right, why is that?
17:31:25 <jimbaker> we don't expect people directly using the db :)
17:31:35 <thomasem> To bootstrap one must. :)
17:31:36 <jimbaker> and if they are, they have to play by our rules
17:31:46 <thomasem> Okay, but I'm questioning why that rule exists?
17:31:54 <thomasem> What's the purpose? Why not use proper UUIDs there?
17:32:16 <jimbaker> there are a few ways to stored uuids in the db. we chose the compact string representation
17:32:28 <jimbaker> vs the more compact bytes representation
17:32:40 <jimbaker> this is managed by the model code
17:32:54 <jimbaker> it would be a simple thing to change if we want to do so
17:32:59 <thomasem> So, it's a performance concern?
17:33:35 <jimbaker> hardly not
17:33:44 <thomasem> I don't doubt it's simple to change. I'm really only wondering what the original reasoning was for making that choice.
17:33:47 <jimbaker> but it should be a canonical repr
17:34:01 <jimbaker> so with, or without, we want it the same way
17:34:27 <thomasem> So why not store it the same way and then you never have to worry about expanding/contracting?
17:34:28 <jimbaker> fwiw, when we had all IDs as UUIDs, there may have been more of a perf concern
17:34:43 <thomasem> Haha, yeah. I can see that.
17:34:44 <jimbaker> i think it's just the default for the UUIDType here...
17:34:45 <jimbaker> https://github.com/openstack/craton/blob/master/craton/db/sqlalchemy/models.py#L233
17:34:58 <thomasem> Ohhhh okay
17:35:00 <jimbaker> i'm pretty sure we can make it something else if we want
17:35:20 <sigmavirus> thomasem: jimbaker I'm not sure that's true. I just like being explicit in certain things I do
17:35:21 <jimbaker> tbh, we haven't looked at this for a while
17:35:23 <thomasem> Sure. That's all I was wondering. If it's just what SQLAlchemy does, that's different. I was under the impression that it was a deliberate choice.
17:35:46 <jimbaker> well it is a deliberate choice to use this library: https://github.com/openstack/craton/blob/master/craton/db/sqlalchemy/models.py#L233
17:36:06 <jimbaker> and keep things in types, vs strings, once it entered SA
17:36:40 <jimbaker> but i don't think this usage is controversial
17:36:45 <sigmavirus> related https://github.com/kvesteri/sqlalchemy-utils/issues/261
17:36:52 <sigmavirus> Ah, it does default to binary: https://github.com/kvesteri/sqlalchemy-utils/blob/master/sqlalchemy_utils/types/uuid.py#L31
17:36:52 <jimbaker> it's more of a question, could we opt for a different db repr
17:36:58 <sigmavirus> I suspect I stole that from another openstack project then
17:37:10 <jimbaker> sigmavirus, yeah, it was binary at some point
17:37:26 <jimbaker> and that was much more objectionable, since it was opaque in mysql
17:37:54 <jimbaker> i believe it may adapt itself from the fact that we chose to do the storage as a string in the alembic script
17:38:04 <thomasem> Gotcha
17:38:35 <sigmavirus> these things are all fuzzy to me
17:38:38 <sigmavirus> we didn't do specs back then
17:38:52 <sigmavirus> Also, project UUIDs seems silly now that we won't be doing a horizon plugin
17:38:58 * sigmavirus shrugs
17:38:59 <jimbaker> sigmavirus, yeah, only the code speaks for itself
17:39:16 <thomasem> Lol, it's cool. I didn't mean to spark a bunch about it. I was mostly curious. We can work with it as-is. Something to consider changing later on, if we care.
17:39:43 <jimbaker> well, yeah, lets just keep it the way it is. at least project uuid is unique, in case we ever need to consolidate from multiple projects
17:40:16 <thomasem> Alright. That was all I had!
17:40:17 <jimbaker> that's actually a more interesting question, but fortunately mysql multisource replication can readily handle
17:40:30 <jimbaker> and whatever alt we build
17:40:57 <jimbaker> thomasem, ok, adjourn for now?
17:41:04 <thomasem> Yeppers
17:41:06 <thomasem> #endmeeting