15:00:20 <jimbaker> #startmeeting craton
15:00:20 <openstack> Meeting started Mon Jul 25 15:00:20 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:24 <openstack> The meeting name has been set to 'craton'
15:00:33 <jimbaker> #topic roll call
15:02:06 <sigmavirus> o/
15:02:08 <cmspence> o/
15:02:19 <jimbaker> sigmavirus, cmspence o/
15:02:56 <mrhillsman> o/
15:03:02 <jimbaker> mrhillsman, o/
15:03:09 <sulo> o/
15:03:20 <Mitschke> o/
15:03:32 <jimbaker> sulo, Mitschke o/
15:04:01 <jimbaker> today's agenda can be found here: https://etherpad.openstack.org/p/craton-meetings
15:04:12 <izaakk> o/
15:04:28 <jimbaker> also feel free to take any notes above and beyond the minutes in that etherpad
15:04:58 <jimbaker> let's get started
15:05:11 <jimbaker> #topic action items from last week
15:06:06 <jimbaker> perhaps most importantly, the action item to move to openstack infra, which sarob helped to drive, is now completed
15:06:52 <jimbaker> at least in terms of gerrit; gates; reviewers
15:07:05 <sulo> still one to merge
15:07:12 <jimbaker> sulo, ?
15:07:13 <sulo> for tests
15:07:29 <jimbaker> ahhh, ok, i am head of this then
15:07:42 <jimbaker> ahead
15:07:56 <sulo> It already has a +2 so just a matter of time really
15:08:26 <sulo> I'll poke around to get it going today
15:08:34 <jimbaker> sulo, thanks
15:09:11 <rainya_> o/
15:09:22 <jimbaker> so initial core reviewers for #craton are jimbaker, sarob, sigmavirus, sulo
15:09:44 <jimbaker> we hope to see more join this team over time
15:09:59 <jimbaker> izaakk, rainya_ o/
15:10:10 <sulo> hi rainya_
15:10:52 <jimbaker> another interesting aspect of the gate is that we have dropped python 2.7 and 3.4 testing of craton core
15:11:09 <jimbaker> the implication: we are only supporting 3.5 going forward
15:11:58 <jimbaker> this should simplify our code base and deployment, while allowing us to take full advantage of the most recent aspects of python
15:12:09 <cmspence> jimbaker:  we are still planning on supporting 2.7+ for client, correct?
15:12:15 <jimbaker> cmspence, in fact we must
15:12:35 <cmspence> I know we had talked about that last week, just wanted to make sure nothing changed
15:12:39 <rainya> o/ (for the record) mostly just lurking again today all
15:12:52 <jimbaker> that was a crucial distinction we got in operator feedback
15:13:27 <jimbaker> this also applies presumably to horizon plugins
15:13:48 <jimbaker> anything that is client side is 2.7 or higher; but craton core is 3.5
15:14:48 <jimbaker> next question i have related to openstack infra - presumably we should move from #craton to #openstack-craton
15:15:38 <jimbaker> cmspence, sulo - any thoughts here?
15:16:03 <jimbaker> rainya, btw, we are trying to capture all of our meetings here https://etherpad.openstack.org/p/craton-meetings
15:16:14 <cmspence> jimbaker: I think that sounds good
15:16:29 <rainya> jimbaker, looks good
15:17:40 <jimbaker> sulo, do you know any registration details we need to go through for #openstack-craton ?
15:17:42 <sulo> unless it's a problem for openstack, I don't mind keeping just #craton
15:18:13 <sulo> but cool if we need to move
15:18:13 <jimbaker> sulo, it does have the advantage of being shorter...
15:18:41 <jimbaker> sulo, ;et
15:18:52 <jimbaker> let's research details
15:19:31 <jimbaker> but i would think it's a net positive, despite minor disruption
15:20:06 <jimbaker> sarob is not here today, so we will have to table the oneops discussion
15:20:23 <jimbaker> i will follow up with him on email re getting that work kicked of
15:20:49 <jimbaker> #action jimbaker discuss oneops integration kickoff with sarob
15:21:40 <jimbaker> cmspence, one last action item from last week re horizon storyboards
15:21:54 <jimbaker> any progress? do you need help?
15:23:08 <cmspence> no, I've had a couple meetings with the horizon folks and we have a meeting setup with sulo to see how the current rackspace UI looks to get an idea of functionality and flow.  The Horizon team with tamayo will be digging in after that to create us some mockups
15:23:35 <jimbaker> cmspence, sounds like good progress to me, thanks!
15:24:22 <jimbaker> #action development highlights
15:24:30 <jimbaker> sorry, wrong command
15:24:44 <jimbaker> #topic development highlights
15:25:59 <jimbaker> one topic we discussed this past week in our dev meeting, based on discussion with product owners around the fleet management user stories, is the focus on FLT005
15:26:12 <jimbaker> (https://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/fleet-management.html)
15:27:05 <jimbaker> i believe we made good progress on how to use FLT005 to better define the craton product
15:27:26 <jimbaker> specifically in outlining the need to focus in doing so with respect to the craton client
15:28:02 <jimbaker> eg an operator should be able to use the craton client to define/configure an audit workflow, such as against the OSA security role
15:28:28 <jimbaker> an operator should be able to use the craton client to apply a workflow against some queried inventory
15:29:04 <jimbaker> this in turn can be done equivalently in the horizon dashboard that we are building out for craton
15:30:06 <jimbaker> cmspence, sigmavirus, sulo - we should start defining the specifics of this craton client api around workflow support
15:30:35 <sulo> yeah that would help me to get the api side going quicker
15:30:38 <sulo> so +1
15:30:48 <jimbaker> so that this can drive dev there, much as we used the REST API (more directly) earlier against inventory
15:31:16 <cmspence> +1
15:31:56 <sigmavirus> Sounds good
15:32:29 <jimbaker> cool, i'm hopeful we can start working on some gists/etherpads/etc to prototype this api this week
15:32:43 <jimbaker> and discuss in thurs dev meeting
15:33:45 <jimbaker> we can then work out the corresponding CLI aspects, which i expect to be an important focus of the barcelona demo (assuming talk acceptance etc)
15:33:59 <jimbaker> perhaps the most important
15:34:59 <jimbaker> sigmavirus, you mentioned github3 as one possible source of api inspiration - i think it looks like a good approach
15:35:30 <sulo> api inspiration ?
15:35:41 <jimbaker> sulo, what the client api would look like
15:36:07 <jimbaker> https://github3.readthedocs.io/en/develop/
15:36:25 <jimbaker> obviously github is a much larger api surface
15:37:05 <jimbaker> but if we focus on making our resources behave in a similar fashion with respect to that api, this seems like a nice approach
15:37:14 <cmspence> maybe this is a topic we can discuss in #craton, but what aspects are we expecting to be similar?
15:38:01 <sulo> so we want to model the client like github3 ?
15:38:27 <jimbaker> cmspence, sulo - i think in terms of session mgmt; simple usage
15:38:40 <jimbaker> we don't have repos, of course
15:39:03 <jimbaker> but https://github3.readthedocs.io/en/develop/repos.html represents a simple way of interacting with this type of resource
15:39:23 <jimbaker> we do have workflows and inventory. what can we do to get similar simple usage?
15:39:30 <jimbaker> that's just the question i'm posing here
15:39:43 <jimbaker> cmspence, and yes, it's a perfect topic for more discussion on #craton
15:39:56 <jimbaker> hence my attempt to kick off everyone's thought processes
15:41:04 <jimbaker> before i go to far off in this topic: consider what it means to define a multiphase workflow, such as seen in actual live migrations
15:41:10 <sigmavirus> jimbaker: yeah, I mean people like github3.py because it lets people follow their noses
15:41:19 <jimbaker> sigmavirus, exactly
15:41:24 <sigmavirus> (I have a github client, I can get a repo. now I can get a pull request, etc.)
15:42:02 <jimbaker> so that connectivity also makes sense. what workflows did i apply to this host?
15:42:09 <jimbaker> what variables did this workflow capture?
15:42:10 <jimbaker> etc
15:42:45 <sigmavirus> jimbaker: sure, and cratonclient at present kind of allows for that already
15:42:57 <sigmavirus> we'll just end up doing things differently
15:43:01 <jimbaker> the craton client is the most important thing for our operators
15:43:14 <sigmavirus> instead of craton = client.Client(...); client.hosts.list() we'd end up with client.list_hosts()
15:43:45 <sigmavirus> er, 'craton.hosts.list()', 'craton.list_hosts()' or even just 'craton.hosts()'
15:43:47 <jimbaker> sigmavirus, more direct access makes a lot of sense
15:43:53 <jimbaker> craton.hosts()
15:43:58 <jimbaker> etc
15:44:04 <jimbaker> or so i would think
15:44:33 <jimbaker> anyway, if we can address FLT005 from this question, and come up with the corresponding code usage of the cratonclient api
15:44:40 <jimbaker> i think we will be in great shape
15:46:11 <cmspence> I've already started on the CLI commands we may want to use for FLT005:  I would anticipate the simliar python command as well as eventually how we achieve this in horizon:  Feel free to add some, remove some, etc:  https://etherpad.openstack.org/p/craton_rest_api_basics
15:46:38 <jimbaker> can we agree then on an action item like so: begin operator-focused api definition against FLT005 ?
15:46:53 <cmspence> jimbaker: +1
15:47:18 <jimbaker> i can add in some thoughts based on sulo's script that we use for live migration at rackspace
15:47:39 <jimbaker> ok, need to wrap this up
15:48:02 <jimbaker> #action begin operator-focused api definition against FLT005 jimbaker, cmspence, sigmavirus, sulo
15:48:58 <jimbaker> #topic taskflow container discussion
15:49:01 <sulo> lets move this to #craton maybe, there is few things to sort out for workflow though cli
15:49:19 <sulo> especially .. understanding flow -> workflow relationship etc
15:49:22 <jimbaker> sulo, yeah, we must do that given the lack of time
15:49:31 <jimbaker> in  this meeting room
15:49:35 <sulo> ok
15:50:02 <jimbaker> sulo, jimbaker, and sputnik13 met up last friday to discuss container support
15:50:08 <jimbaker> w/ respect to taskflow
15:50:34 <jimbaker> harlowja could not attend due to travel problems/nightmare
15:51:02 <jimbaker> we are going to follow up with them, starting in the forthcoming #openstack-meeting-alt meeting in 9 min
15:51:33 <jimbaker> sulo, do you want to briefly summarize where we stand?
15:51:39 <sulo> sure
15:51:49 <sulo> so the idea from craton side is:
15:52:26 <sulo> allow running tasks inside a container such that we have a continer based engine in taskflow
15:52:47 <sulo> this will allow to use multiple languages support including bash scipts and binaries
15:52:51 <sulo> which is what operators do
15:53:09 <sulo> this is not possible currently in taskflow model .. so we'd like to bake this into either taskflow project
15:53:14 <sulo> or in oslo
15:53:24 <sulo> so we discussed this.
15:53:49 <jimbaker> with the possible outcome: a separate library focused on container support, but in the taskflow namespace
15:54:05 <jimbaker> given general applicability to not just craton
15:55:10 <jimbaker> i think this is a pretty exciting discussion, given the possibility of radically simplifying how we package up tasks to run on workers
15:55:24 <jimbaker> by moving to a docker packaging problem
15:55:52 <jimbaker> we just have 4 minutes left
15:55:55 <jimbaker> any questions?
15:56:02 <jimbaker> #topic questions
15:57:23 <jimbaker> we can always follow up in #craton (or perhaps soon #openstack-craton...)
15:58:54 <jimbaker> if you are interested in the taskflow discussion, we may have a chance to followup in the oslo meeting starting momentarily, #openstack-meeting-alt
15:59:09 <jimbaker> sulo, ^^^ feel free to attend, but i will scope it out
15:59:18 <jimbaker> #endmeeting