15:00:52 <jimbaker> #startmeeting craton
15:00:53 <openstack> Meeting started Mon Sep 19 15:00:52 2016 UTC and is due to finish in 60 minutes.  The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:57 <openstack> The meeting name has been set to 'craton'
15:01:10 <jimbaker> #topic rollcall
15:01:19 <syed_> o/
15:01:28 <jimbaker> hi everyone, and welcome to this week's meeting on craton
15:01:37 <syed_> Hi jim
15:01:41 <syed_> i hope you are doing well
15:02:04 <jimbaker> syed_, thanks, yes, i had a very good hike yesterday
15:02:20 <jimbaker> so that always is a great way to prepare a solid foundation for the week
15:02:31 <syed_> Good, i am glad
15:03:12 <jimbaker> which is as we know, is actually related to what craton means (in this case, a solid foundation/platform for continents), and should do for the cloud
15:03:57 <jimbaker> syed_, hopefully you had a nice weekend as well, and ready for some good progress on functional testing/container automation
15:04:16 <sulo> hola, o/
15:04:23 <syed_> yeap i went to visit family, and ready for some things to be up
15:04:24 <jimbaker> sulo, hi
15:04:27 <syed_> hey sulo
15:04:51 <jimbaker> syed_, good to hear!
15:05:54 <jimbaker> looks like the core devs for craton are here, so let's proceed
15:06:09 <jimbaker> #topic new meeting schedule
15:06:53 <jimbaker> sigmavirus, what is a good time for you on tuesday? i saw your note about a conflict
15:07:13 <jimbaker> ideally sulo can attend the client meeting, but we need a time that you can attend
15:07:35 <sigmavirus> irc meetings are better for me honestly
15:07:43 <sigmavirus> I can join that and a video call more easily than two video alls
15:08:56 <jimbaker> sigmavirus, understood, but i think the rest of the team benefits from a video call, that's why we started doing them as well
15:09:00 <jimbaker> we can readily do demos, etc
15:09:13 <jimbaker> and there's a training component as well
15:09:33 <sulo> feel free to do meetings without me if thats what is needed
15:09:44 <jimbaker> sigmavirus, would 1600 UTC work for you? otherwise we can push into US afternoon
15:10:01 * sulo is more than happy to not attend meetings
15:10:02 <jimbaker> sulo, agreed - i think i can represent you just fine on the client side
15:10:43 <sigmavirus> jimbaker: can we schedule it outside of this?
15:11:06 <jimbaker> sigmavirus, sounds good - but we need to get this resolved today
15:11:40 <sigmavirus> jimbaker: 1600 utc looks fine on my calendar
15:12:06 <jimbaker> sigmavirus, thanks!
15:12:43 <jimbaker> lcastell, i assume 1600 UTC also works for you. same with jovon and syed_
15:12:53 <jimbaker> moving on
15:13:01 <jovon> works fine
15:13:08 <syed_> +1
15:13:35 <jimbaker> #topic outstanding changes
15:13:45 <jimbaker> #topic outstanding change reviews
15:14:54 <jimbaker> sulo, i know you have a number of reviews i need to do for you. the only one that i have pushed back is query by variables, pending some refactoring work i'm doing on the api
15:15:40 <jimbaker> others here: are you being blocked by reviews, and if so, any prioritization we should be aware of as we start off this week?
15:15:56 <syed_> I am good for now. Thanks
15:16:14 <jimbaker> syed_, sounds good. feel free to ping me about docker-py as it comes up
15:16:32 <syed_> yes i need some clarifications on few things for it
15:16:38 <syed_> i will once the meeting is over
15:16:39 <syed_> thanks
15:16:43 <jimbaker> syed_, cool
15:16:44 <sulo> everyone start doing reivews ... this is one of the most important thing that is getting ignored
15:17:14 <jovon> I currently am blocked by turvey's API change. i
15:17:15 <jimbaker> sulo, i don't think we are ignoring them. but we certainly need to keep them prioritized
15:17:21 <sulo> even if you cant merge, everyone can certainly do +1's
15:17:26 <sulo> -1 etc
15:17:33 <jimbaker> sulo, agreed on that
15:17:34 <jovon> agreed sulo
15:18:06 <jimbaker> even minor nits are important to point out. sometimes what looks minor is also important
15:18:19 <jimbaker> so many eyeballs here
15:18:43 <jimbaker> jovon, details on turvey's API change?
15:18:52 <sulo> if we think we dont have enough reviewers, perhaps we need to send a community email to get some more ppl aware that they can help with this
15:19:07 <jimbaker> sulo, +1
15:19:32 <jimbaker> #action jimbaker what can you do for craton? email the community
15:19:44 <sulo> i have some screencast that i need to share .. so i might add a help note when i send out the vidyo
15:19:57 <jovon> he has submitted an update to the doc. I need his patch to be merged before i can complete mine as it pertains to the same set
15:20:04 <sulo> or video even
15:20:09 <jimbaker> sulo, right, thanks for putting those together
15:20:41 <jimbaker> jovon, got it, we will get turvey's review through
15:20:43 <sulo> jimbaker: you talking about the one i did for JC ?
15:21:05 <jimbaker> sulo, just in general, but yes
15:21:19 <jovon> thank you
15:21:35 <sulo> right, yeah i dont like that one .. the one i intend to send will be better
15:21:43 <jimbaker> sulo, practice makes perfect
15:21:47 <sulo> didnt have enough time on that
15:24:02 <jimbaker> so the net of this is: all of us need to do reviews. these can be great to do when stuck on something else
15:24:25 <jimbaker> also this is a chance to learn what the codebase does
15:24:37 <jimbaker> by trying out functionality
15:24:46 <jovon> +1
15:24:54 <jimbaker> new REST API in a change from sulo? give it a try from curl
15:25:19 <syed_> sounds good !
15:25:53 <jimbaker> btw, i assume everyone knows how to pull in a change from gerrit so they can actually try stuff out locally
15:26:03 <jimbaker> but if not: look at the downloads link
15:26:04 <jimbaker> :)
15:27:04 <jovon> roger that ty!
15:28:01 <jimbaker> time to wrap up this topic, feel free to ask more on #craton - and please demand your reviews get done!
15:28:22 <jimbaker> #topic dev issues
15:28:42 <jimbaker> sulo, do you want to start with the label discussion?
15:28:56 <jimbaker> i assume this is with respect to OSA modeling
15:29:03 <sulo> so, labels - how do we want to use it ?
15:29:27 <jimbaker> sulo, my assumption has been is that labels are used for logical groupings
15:30:09 <jimbaker> they are not part of the network topology (which we just added with networks, netdevices, and interfaces). they are not part of a physical containment (the device tree)
15:30:29 <jimbaker> so we can labels like "service:compute"
15:31:07 <sulo> so whats the benifit of doing this in a separate table vs just puttig lables in device model
15:31:12 <jimbaker> obviously we can do the same with variables on a given device - that's why i was describing labels as duals to variables
15:31:32 <jimbaker> sulo, well i think they are in fact already are
15:31:45 <sulo> ?
15:32:01 <jimbaker> labels have a many-to-many relationship to devices
15:32:48 <jimbaker> so they already are there in the device model. at least in the relational sense
15:33:30 <jimbaker> in craton's inventory model, devices are the central concept
15:33:43 <jimbaker> (we can all agree on that)
15:33:47 <sulo> right, what i am saying is whats the benifit of having this relationship vs just tracking it per device on the devices model
15:34:08 <sulo> it only makes sense to do this if we were doing more with it
15:34:26 <jimbaker> sulo, they are pretty light weight right now
15:34:39 <sulo> i am trying to understand (i forget the discussion) what we were trying to drive with labels
15:34:42 <jimbaker> i think the only complexity is that we let them have variables
15:34:52 <sulo> that too
15:35:02 <jimbaker> if we eliminate that, they become very simple
15:35:29 <jimbaker> sulo, so the idea is that we want to be able to look up various logical groupings efficiently, by using relational queries
15:35:40 <jimbaker> much as we do with cell or region
15:36:25 <sulo> so does that need k:v labels ?
15:36:35 <jimbaker> so i can label a device by how it's grouped with power; or what its function is (it's for storage, or for compute, or whatever)
15:36:59 <jimbaker> sulo, i think that's just a useful convention that we can support
15:37:56 <jimbaker> and let's map to say http://kubernetes.io/docs/user-guide/labels/
15:38:30 <jimbaker> sulo, note they have a similar design concept: "We don’t want to pollute labels with non-identifying, especially large and/or structured, data. Non-identifying information should be recorded using annotations."
15:38:54 <jimbaker> what  they call annotations is definitely close to what we are describing as variables
15:39:31 <sulo> so what i am syaing is i dont see why we couldnt just do this with variables .. it seems like exact the same thing .. we just need to track it differently .. example: label_x
15:39:49 <sulo> but maybe its a good idea to do it separately
15:40:00 <jimbaker> sulo, i absolutely agree that it can be done in this way
15:40:34 <jimbaker> but perhaps many of the things we might do a variable query would be better done with a label. it would certainly be far more efficient
15:40:47 <sulo> like what ?
15:41:01 <jimbaker> just to get in some details: on mysql we are not even mapping json columns to mysql's json type
15:41:19 <jimbaker> this is in part because mariadb doesn't yet have support for mysql's json type
15:42:01 <jimbaker> and the sqlalchemy_utils package currently doesn't look at specific db impl - for mysql, it just does TEXT
15:42:24 <jimbaker> but this will change over time
15:42:52 <jimbaker> at some point, queries that involve json columns will be able to use json indexing
15:43:24 <jimbaker> but we would need to do some work
15:43:28 <sulo> doesnt that apply to everything that uses JSON type ?
15:43:43 <jimbaker> whereas with labels, we get that indexing for free, since it's purely relational
15:44:05 <jimbaker> sulo, right, but we usually are less concerned about this
15:44:11 <sulo> oh, you saying it can only be string:string mapping for labels ?
15:44:29 <jimbaker> sulo, yes
15:44:48 <jimbaker> the label name is currently just a string
15:45:12 <jimbaker> i want to support splitting it into two strings, because the k:v convention is pretty nice as seen in kube
15:45:41 <sulo> yeah, i am thinking about <string>: JSONType
15:45:43 <jimbaker> but yeah, the :v part will not grow to be arbitrary JSON. that would be bad
15:46:17 <jimbaker> then we would just have a more awkward, non relational thing in labels. i wouldn't even know how to model as we have it now :)
15:46:40 <sulo> so how would we represent multiple group memebership in labels ?
15:46:54 <jimbaker> sulo, labels are many to many with devices
15:47:07 <jimbaker> so we get that for free
15:48:06 <jimbaker> the one thing we don't have is any label hierarchy. but i don't see the need for that
15:48:53 <jimbaker> that thinking was mostly inspired by a desire to implement a DAG for network modeling. but instead we came up with a better modeling of that, which is actually quite sweet imho
15:50:16 <sulo> so i am not sure i am on the same page as you here ...
15:50:51 <jimbaker> sulo, i suggest we move this discussion over to #craton
15:51:27 <sulo> yeah, i think this is a much longer discussion .. lets move to #craton after this meeting
15:51:30 <jimbaker> cool
15:52:07 <jimbaker> other dev topics that we should cover?
15:52:53 <sulo> where are we with worker code ?
15:53:14 <jimbaker> i will mention that my goals for this week include: refactoring of the flask api; craton-specific backend for taskflow
15:53:21 <sulo> is that something we are clear with in terms of how to model ...
15:53:38 <jimbaker> sulo, so i put that gist up last week
15:54:00 <jimbaker> i will revisit as a blueprint. today sounds right to me
15:54:15 <sulo> ok cool ... i think we are coming to the point where some sort of worker impl will be required soon
15:54:34 <jimbaker> sulo, the key piece is going to be scheduling the task graph, which we have decided to break into two pieces
15:54:36 <sulo> to drive some of the osa integration etc
15:55:05 <jimbaker> sulo, yeah, so that's really about wrapping the ansible-playbook command and especially using the callback api
15:55:29 <jimbaker> for ansible/OSA specifically
15:55:47 <jimbaker> the general piece is the two level task graph scheduling
15:56:41 <sulo> ok cool. that sounds like you have it under control ;)
15:57:04 <jimbaker> sulo, more that i'm juggling them, but sure :)
15:57:46 <jimbaker> just need to keep everything in the air, not so bad. just remember: if we juggle too much, it all falls to the ground ;)
15:58:04 <sulo> jimbaker: heh, upto 5 pins allowed
15:58:08 <jimbaker> exacty
15:58:33 <jimbaker> time to wrap up this meeting
15:58:49 <jimbaker> #topic questions/goodbyes
15:59:07 <jimbaker> so really this means - take your questions over to  #craton
15:59:19 <jimbaker> because there's no time left
15:59:28 <jimbaker> thanks everyone!
15:59:35 <jovon> thanks
15:59:59 <jimbaker> #endmeeting