16:59:59 <jimbaker> #startmeeting craton
16:59:59 <openstack> Meeting started Thu Jan 26 16:59:59 2017 UTC and is due to finish in 60 minutes.  The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:03 <openstack> The meeting name has been set to 'craton'
17:00:06 <jimbaker> #chair sigmavirus sulo jimbaker
17:00:07 <openstack> Current chairs: jimbaker sigmavirus sulo
17:00:13 <jimbaker> #link https://etherpad.openstack.org/p/craton-meetings
17:00:29 <jimbaker> #topic Roll Call
17:00:33 <jimbaker> o/
17:00:40 <Syed__> o/
17:00:56 <jovon> o/
17:01:30 <jimbaker> i have posted a short agenda in the meeting notes
17:01:35 <tojuvone> hi
17:01:56 <jimbaker> tojuvone, thanks for joining!
17:02:47 <jimbaker> we will wait a couple more minutes for git-harry, sigmavirus, sulo to join us
17:02:59 <sigmavirus> o/
17:03:05 <git-harry> here
17:04:42 <jimbaker> ok, let's get started
17:05:00 <jimbaker> #topic upcoming demos
17:05:24 <Syed__> when is the demo ?
17:05:29 <jimbaker> so we have been asked to prepare two demos for next week, on tues jan 31 and thur feb 2
17:05:35 <Syed__> cool
17:05:42 <sigmavirus> Who is "we"?
17:05:43 <sigmavirus> =P
17:06:08 <sigmavirus> o/ antonym in case you want to participate in our meeting/sync
17:06:10 <jimbaker> sigmavirus, well i have been asked, and by extension, all of us have been asked ;)
17:06:20 <sigmavirus> jimbaker: even tojuvone ? =P
17:06:42 <jimbaker> sigmavirus, no i mean to universally quantify all intelligences
17:06:44 <Syed__> by whom ? where will it be presented?
17:06:55 <jimbaker> ;)
17:07:06 <tojuvone> sigmavirus, :D
17:07:09 <jimbaker> Syed__, in due time
17:07:45 <jimbaker> so we (the craton dev team) have been asked by toan and dusty to do a demo next tues during our regular vidyo call
17:08:42 <jimbaker> this will then be prep for a larger demo one week from today, with time/place to be set. but likely in craton vidyo room, possibly at this time
17:09:00 <jimbaker> by larger demo, i meant to say, in front of a larger audience
17:10:15 <sulo> jimbaker: whats the expections from the demo ?
17:10:21 <jimbaker> so this is sort of crunch time. we need to ensure everything that is necessary for basic inventory is working. we got the basics
17:10:24 <antonym> o/
17:10:32 <jimbaker> sulo, basic crud ops, with variables
17:10:42 <sulo> k
17:11:31 <jimbaker> antonym, thanks for joining
17:11:53 <antonym> no prob
17:12:01 <jimbaker> so for antonym: we should show off the python client, since he's going to need this for his tooling work
17:12:15 <Syed__> So later on down the road specially for boston summit, do we have a set of goals infront of us which we are looking to be done by that
17:12:27 <Syed__> like having UI for Craton etc.
17:13:17 <jimbaker> Syed__, sorry, but that's a different topic. let me suggest we discuss later in today's meeting. can you add to the agenda please?
17:13:28 <Syed__> sure
17:13:32 <jimbaker> current topic is demos :)
17:13:35 <git-harry> jimbaker: do you have a specific list of things that will be done in the demo?
17:13:39 <antonym> we were kicking around the idea of starting to use the maas agent to populate the database with server info: https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/pull/950
17:13:56 <git-harry> It will make it easier to identify problems
17:14:05 <jimbaker> git-harry, very good question! thanks
17:14:46 <jimbaker> so it turns on crud ops, variables, and access via python client and CLI
17:14:47 <sulo> antonym: i had a chat with maas team about using the agent for audit work few months back
17:14:56 <sulo> by extending the agent
17:15:22 <git-harry> jimbaker: so are you going to go through every single one of those options?
17:15:22 <antonym> yep, i think that would be a really quick way to funnel data in from environments where we don't have a lot of access to scan things
17:15:25 <jimbaker> git-harry, right now for crud ops we have host deletion failing. which requires me to get some basic changes in i made to alembic setup
17:15:54 <jimbaker> git-harry, i'm going to go against dusty's doc
17:15:59 <jimbaker> req doc
17:15:59 <sulo> antonym: only problem is navigating around rax agent vs its opensource version
17:16:10 <sulo> at least for us
17:16:16 <Syed__> jimbaker: please share that doc
17:16:48 <antonym> i'd imagine the data we'd need would work in either version?  we could probably keep the implementation pretty generic
17:16:53 <jimbaker> Syed__, you should have access to that doc, but if not i will pm you privately
17:16:59 <Syed__> cool
17:17:23 <jimbaker> sorry tojuvone, we need to get that req doc that rackspace private cloud cleaned up for public distribu
17:17:38 <sulo> antonym: yeah i think sould
17:17:39 <tojuvone> jimbaker, np
17:17:39 <jimbaker> but there's nothing in there that's not in our bugs/blueprints
17:18:04 <git-harry> jimbaker: I guess I'm suggesting something more explicit, like if you take that doc and write the list of things you want to do to show the state then that can be broken down to verify.
17:18:05 <jimbaker> just helpful for specific data elements that would be useful for a demo
17:18:11 <sulo> i was thinking making this an option so 1) we have the generic ssh way of doing audits and gathering data
17:18:18 <sulo> and 2) using the agent to do the same
17:18:58 <antonym> yeah, getting into some of these environments can be difficult so having a push from the host would be nice
17:19:01 <jimbaker> git-harry, they want to be able to see how we could capture hardware and software inventory aspects
17:19:16 <sulo> given the agent is already doing much of what we want to gather .. it might make sense to focus on that .. given audit though ssh will be acheieved regardless when we work on remediation stuff
17:19:49 <jimbaker> pretty much the same conversation that antonym and sulo are having, except framing it in a specific usage
17:20:33 <antonym> sulo: but yeah, i'm plus one on those 2 options
17:21:06 <jimbaker> so the big missing piece here on crud ops is simple - we need to have updating variables work with the python client; and general variable support in the CLI
17:22:09 <jimbaker> git-harry, to return to your point, i see the reqs doc as a script for the desired demo. because this is what rackspace support wants from a CMDB - it was explicitly gathered from them
17:23:00 <jimbaker> since we are in the business of generalization/abstraction, we haven't thought about the specific desired data elements so much. but that's what we will do in the demo itself
17:24:08 <jimbaker> hope that makes sense!
17:24:32 <sulo> jimbaker: the cli is also missing networks network-interface and net-devices
17:24:36 <git-harry> jimbaker: I might just need to take another look at the doc.
17:24:54 <jimbaker> git-harry, just pm'ed you the link
17:25:35 <jimbaker> again we will share this publicly asap. i will ask dusty what we need to do to make it public
17:26:20 <jimbaker> sulo, yeah, we should get that support in. but i don't see that as critical for tues and probably not even thurs demo
17:27:10 <jimbaker> in my discussion with john wood from FAWS (= fanatical AWS support), this is something you thought would be helpful for their needs
17:27:36 <jimbaker> i'm not certain if we discussed network modeling support with antonym or not...
17:28:33 <jimbaker> sulo, so really the important stuff here would presumably be variables to the CLI; and json support so we can show off with jq
17:30:27 <sulo> ok
17:30:33 <Syed__> jimbaker: tried logging but unable to connect, will talk with you on pm once the meeting is over
17:31:04 <jimbaker> Syed__, np
17:33:07 <jimbaker> let's briefly switch topics here before we get back in some of these details
17:33:10 <jimbaker> #topic functional testing
17:33:47 <sulo> i need to update my patch with pymysql requirement
17:34:11 <jimbaker> sulo, that would be awesome, since we are almost there on the functional testing changes
17:34:12 <sulo> but i want to add db clenup for user/project as well .. which i havent done yet
17:34:31 <sulo> yea, other than that .. my local branch works well
17:34:31 <jimbaker> can we do that separately?
17:34:42 <sulo> i have hosts tests that needs to be updated as well
17:34:54 <sulo> i am still witing on that sqlalchemy change for that
17:35:04 <sulo> host deletes to be exact
17:35:11 <jimbaker> ahh, so we are in deadlock in each other :)
17:35:17 <jimbaker> i've been waiting on you
17:35:21 <sulo> ?
17:35:32 <sulo> for what ?
17:35:33 <jimbaker> so i can have something to test against
17:35:46 <jimbaker> i like fixes to have corresponding tests
17:36:08 <jimbaker> sulo, let me give you the alembic diff
17:36:12 <sulo> i can upload the test if you want to test with it
17:37:33 <jimbaker> one of these two options works... let's discuss later
17:37:53 <jimbaker> (immediately after meeting)
17:38:31 <jimbaker> overall, sounds like we are in good shape with the functional testing updates
17:38:59 <jimbaker> #topic variable support
17:42:17 <jimbaker> so we were discussing this before the meeting on #craton
17:43:02 <jimbaker> the net of it is, the python client when accessing /v1/hosts/$host will get the variables and populate in the host object on the client
17:43:44 <jimbaker> eg usage like host = craton.hosts.get(item_id=8) will result in host.variables being populated
17:44:53 <jimbaker> because we do not support PUT with variables against /v1/hosts/$host, this is not symmetric, so the current simple crud model the python client uses will not work. example: craton.hosts.update(item_id=8, variables={'foo': 42, 'bar': [1,2,3,4]}) to replace the variables for this host
17:47:43 <jimbaker> so some choices here, but the simplest to me would be to keep the symmetry and have the python client use PUT /v1/hosts/$host/variables
17:47:58 <jimbaker> when using the above update method
17:48:16 <jimbaker> (the client would hide this distinction)
17:48:27 <jimbaker> git-harry, sigmavirus, sulo, what say you?
17:49:35 <sigmavirus> jimbaker: that works for me
17:49:36 <sulo> did we just decide to do host-vars-for --host=xxx and host-vars-update --host=xxx
17:49:38 <jimbaker> this doesn't change the CLI aspects we were discussing earlier, which was craton variables-for-RESOURCE or something like that
17:49:59 <sulo> so that makes cli and python api different
17:50:03 <sigmavirus> but if we're going to do /v1/hosts/:host_id/variables I'd expect a user to be able to do `host = host.get(id); host.variables.update(...)`
17:50:20 <sulo> right
17:50:25 <sigmavirus> sulo: why do people think the cli and python api need to reflect each other?
17:50:28 <jimbaker> sigmavirus, sulo, i'm good with that
17:50:30 <sigmavirus> the CLI should be what's most ergonomic
17:50:32 <jimbaker> sigmavirus, +1
17:50:39 <sigmavirus> The Python API should be ergnomic as well
17:50:48 <sigmavirus> What's ergonomic in bash may not be true in Python and vice-versa
17:51:06 <sulo> ok, if the vote is thats cool, then i am fine with it
17:51:09 <jimbaker> and nested objects are a good example
17:52:01 <jimbaker> yes, we can do jq, but not every usage of say craton host-show should require it :)
17:52:13 <jimbaker> ok, enough. we have agreed
17:52:33 <jimbaker> sigmavirus, so yeah, host.variables.update(...) sounds good to me
17:52:54 <jimbaker> right now if i'm not mistaken host.variables is a simple dict, but making it an object sounds far better
17:53:06 <jimbaker> given that there's stuff like blame, history, etc, that we want to attach to it
17:53:20 <jimbaker> in the python client
17:54:07 <sigmavirus> right
17:55:19 <thomasem> o/
17:55:37 <jimbaker> thomasem, thanks for stopping by
17:55:42 <thomasem> You bet!
17:55:45 <sulo> thomasem: o/
17:55:57 <jimbaker> thomasem will be joining us to help develop craton!
17:56:10 <thomasem> That I will. Starting next Tuesday, :)
17:56:23 <jimbaker> so welcome to the team. and timing sounds excellent!
17:56:29 <thomasem> Thanks!!
17:56:36 <sulo> jimbaker: sigmavirus: so whats the net here ? who is done what to get this going for the demo ?
17:56:37 <sigmavirus> just in time to help us burn craton to the ground for our demo ;)
17:56:53 <jimbaker> sigmavirus, yep, construct the pyre higher
17:56:54 <sigmavirus> sulo: I have zero visibility into any of this demo nonsense
17:56:59 <thomasem> Lol
17:57:01 <tojuvone> great :) and good stuff the demo and variables for host
17:57:15 <sigmavirus> No one has included me in craton conversations in over a month
17:57:22 <sigmavirus> So I just assume I'm succeeding at not being seen
17:57:32 <sigmavirus> Or in other words "Not it"
17:57:39 <Syed__> Same with me sigmavirus
17:57:53 <Syed__> i haven't been upto date at all on whats been happening
17:58:57 <sulo> i dont think other than what we are talking abou there has been much
17:59:52 <sulo> the demo thing is ... i guess something we are expected to do to show progress
18:00:02 <jimbaker> right, we are just being asked to demo something. the only thing that is not really negotiable are the dates
18:00:18 <jimbaker> so we have to figure something out, and dusty's req doc seems to be the best starting point
18:00:46 <jimbaker> sulo, +1 on progress
18:01:18 <sulo> might also be a good time to record it and send to the community
18:01:31 <jimbaker> sulo, also +1
18:01:32 <sulo> i've been meanign to post vidyo to the ops and dev lists
18:01:45 <sulo> but just havent made a scrrencast nice enough to do so
18:01:57 <jimbaker> and sulo is a true master of the impromptu demo
18:02:17 <jimbaker> so we are in good shape there. just want to make sure that we show all the good dev progress we have made
18:02:18 <sulo> wait a sec, you expecting me to do this demo ?
18:02:24 <sulo> :D
18:02:25 <jimbaker> sulo, ;)
18:04:02 <jimbaker> so far it has worked well for us. i'm good for the impromptu commentary/comedy bits
18:04:24 <sigmavirus> jimbaker: you shouldn't have said that until Tuesday
18:04:25 <jimbaker> sulo, but we can always reverse roles if you want
18:04:34 <sigmavirus> jimbaker: wait, you do comedy?
18:04:43 <jimbaker> yep, of the pratfall kind
18:04:54 * sigmavirus is teasing
18:04:56 <jimbaker> demo goes down into a burning heap
18:05:51 <sigmavirus> okay, well we're over time
18:05:52 <jimbaker> anyway, we will figure this out. really i think the key piece is get some key code committed that has been written
18:06:04 <jimbaker> and finalize variables
18:06:06 <jimbaker> DONE
18:06:09 <jimbaker> and we are done
18:06:11 <jimbaker> #endmeeting