17:02:19 #startmeeting craton 17:02:21 Meeting started Thu Feb 16 17:02:19 2017 UTC and is due to finish in 60 minutes. The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:24 The meeting name has been set to 'craton' 17:02:50 #chair sigmavirus sulo jimbaker thomasem 17:02:51 Current chairs: jimbaker sigmavirus sulo thomasem 17:02:58 #link https://etherpad.openstack.org/p/craton-meetings 17:03:51 sigmavirus, around? 17:04:08 if not we can have thomasem chair again... 17:04:40 I don't mind. It'll be my first time, if you don't mind offering up some halps with the commands. 17:04:50 thomasem, sounds good 17:04:53 #topic Roll Call 17:05:05 and looks like you have it down already 17:05:05 :) 17:05:09 o/ 17:05:12 o/ 17:05:13 hello 17:05:40 * jimbaker should not chair, is the general consensus of the group, i believe :) 17:05:45 Welcome to the party, jimbaker, jovon 17:06:09 #topic Agenda 17:06:14 #undo 17:06:15 Removing item from minutes: #topic Agenda 17:06:23 #topic Action Items 17:06:50 #link http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-01-30-15.00.html 17:07:18 #undo 17:07:20 Removing item from minutes: #link http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-01-30-15.00.html 17:07:21 I think that one was old 17:07:34 http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-13-15.00.html 17:07:41 Here we are 17:07:44 #link http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-13-15.00.html 17:07:50 I'm chairing the OSSP meeting 17:07:50 Thanks, jimbaker 17:07:54 sorry 17:07:58 We'll miss you, sigmavirus 17:08:04 yeah, unlikely 17:08:06 =P 17:08:11 Working on the docker fix right now for infra too 17:08:18 Excellent! 17:08:38 sigmavirus, very nice. i think i can repeat here, +1000 17:08:41 jimbaker: turn Dusty's document into etherpad, I guess our poorly name etherpad is sufficient? 17:09:44 https://etherpad.openstack.org/p/cmdb_prototype_meeting_2017_02_09 17:09:45 That guy 17:09:46 #link https://etherpad.openstack.org/p/cmdb_prototype_meeting_2017_02_09 17:09:52 yes, that one 17:10:00 let's just paste dusty's doc at the end 17:10:13 and we will work on making it better. sounds good? 17:10:38 Yeah, sounds good to me. 17:11:03 jimbaker: Add reviewing said etherpad as a standard agenda item to our meeting template 17:11:46 dusty's doc added to cmdb tracking doc 17:12:10 Awesome. Let's also add that as a standing item for our meeting template 17:12:35 To review progress-wise, I imagine 17:13:31 right, the doc as added is not terribly useful for the review process, but we will put it in a form to do so 17:14:01 #action thomasem to write BP regarding deployment as a starting point for iterating on a suggested deployment model 17:14:02 this is something that toan effectively asked me to do - to match requirements to work 17:14:09 Right 17:14:44 So, do we want to turn that into an action item? 17:14:59 thomasem, sure, let's do that 17:15:46 #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:15:56 thomasem, +1 17:16:20 sigmavirus's pagination stuff got finished and merged 17:16:34 and to be clear - this will be selective - only will consider short term stuff (first 3 reqs iirc) 17:16:41 for this mapping 17:17:00 jimbaker: I would confirm that... I still think some folks are expecting more than what we are. 17:17:30 Do you mean UC1-3 are all that's expected? 17:18:10 thomasem, https://etherpad.openstack.org/p/cmdb_prototype_meeting_2017_02_09, starting at line 89 17:18:24 not another set of stories we have been recently looking at 17:18:39 which have the UCn numbering 17:19:03 Oh, okay 17:19:05 clear? i'm hoping to make it so :) 17:19:15 for my sanity's sake at least 17:19:28 Haha, indeed. Not entirely clear to me yet. I'll review it in more detail. 17:19:58 I've read through all of the things, but they continue to have additional scope that I don't think we can meet with Craton, at least. 17:19:59 going from reqs to something actionable is always a challenge 17:20:04 Definitely 17:20:14 thomasem, feel free to add your comments accordingly 17:20:18 so we can converge 17:20:29 And scoping that by responsibility so Craton doesn't become the Australian from Futurama. 17:21:02 #action thomasem to review Dusty and Bjorn's stories/use-cases and add notes on concerns or questions 17:21:10 and now i know that meme... 17:21:26 I hope it's the one I was thinking of, and not something bad. 17:21:32 Well... tasteless. 17:21:54 i believe we have a joint understanding. but hey, brains 17:22:01 Anyway, does anyone know the status of the CLI testing that sigmavirus had an action item for? 17:22:09 Lol, indeed 17:22:52 I'll carry that one forward until we can get a status on it. 17:23:01 #action sigmavirus to finish up testing on cli 17:23:17 that will be a good hamster wheel for sigmavirus 17:23:27 o_O 17:23:30 Do we then do Stand Up in this meeting? 17:23:39 o/ 17:23:56 #topic Stand Up 17:24:00 yes. but sigmavirus is here, so let's cover that action item? 17:24:11 #undo 17:24:12 Removing item from minutes: #topic Stand Up 17:24:23 #undo 17:24:24 Removing item from minutes: #action sigmavirus to finish up testing on cli 17:24:37 Pardon the onslaught of pings 17:24:43 some handy commands here... 17:25:12 I dunno, jimbaker, I think he's busy. 17:25:53 sigmavirus just pops in with emoticons as necessary 17:25:59 Yep 17:26:03 Alright, let's move on. 17:26:12 +1 17:26:28 #action sigmavirus to finish up testing on cli 17:26:32 #topic Stand Up 17:26:39 #info each team member briefly describes what they are working on this week, and describes blockers (if there are any) 17:26:58 #topic Stand Up :: jimbaker 17:27:58 finish up WIP on vars in client/CLI; map reqs to craton tasks, focused on short term for the cmdb milestone; review stuff 17:27:59 done 17:28:15 #topic Stand Up :: thomasem 17:29:20 project vars merged (yay!); working on some bugs found during that work, then moving back to adding clouds; reviewing queue; review user stories and use-cases for concerns/questions I have so we can improve communication and expectations there. 17:29:22 done 17:29:36 #topic Stand Up :: jovon 17:30:50 cleaning some current doc patches as well as investigating current doc tools available doc generating more autoimatic 17:31:03 automatic* 17:31:11 +1 17:31:13 awesome 17:32:10 Anything else, jovon, or 'done'? :) 17:32:11 Ian Cordasco proposed openstack/craton master: Fix up functional testing https://review.openstack.org/435038 17:32:15 done 17:32:17 ^ should be fun to watch 17:32:18 sorry 17:32:26 No problem at all! 17:32:31 #topic Stand Up :: Syed__ 17:32:54 Working on patch for update project and users 17:33:00 tests are broken now and its a mess :/ 17:33:11 but well, hoping to get it going today 17:33:17 sigmavirus, nice about that possible bug fix 17:33:38 apart from that working over CLI tests 17:33:43 be back in ~10 min 17:34:01 Syed__: mind linking the review? I'll pull it down when I get a moment and see if anything jumps out at me that might help? 17:34:20 thomasem: https://review.openstack.org/#/c/425463/ 17:34:25 thomasem: thanks 17:34:29 this is an important thing to get fixed 17:34:36 #link https://review.openstack.org/#/c/425463/ 17:34:39 You bet! 17:34:46 once i get this merged, have couple of minor reviews in the queue i would like y'all to check them out 17:35:01 then will focus towards CLI users and projects 17:35:04 done 17:35:19 #topic Open Discussion 17:35:27 basically all the refactoring that has hit projects... it's good, but definitely a lot of stepping on each other, given centrality 17:35:49 Yes. It's caused a fair amount of pain for all involved. 17:36:10 But, we're trucking through it. I am curious how everyone's feeling? We've been going at a bit of a pace here. :) 17:36:23 Working early/late/weekends 17:36:33 thomasem, well, if i tried to sustain yesterday's pace for much longer, i will fall over 17:36:55 I could do with some reviews on https://review.openstack.org/#/c/435005/ 17:37:01 before I start on the code 17:37:13 so no, not sustainable. but i think it was important to pitch in here to break logjams 17:37:29 #link https://review.openstack.org/#/c/435005/ 17:37:30 Ian Cordasco proposed openstack/craton master: Fix up functional testing https://review.openstack.org/435038 17:37:44 git-harry, thanks, will take a look 17:38:42 to summarize, git-harry captures in that spec our discussion about a heterogeneous device collection, to accommodate for now net devices and hosts, but other devices in the future 17:39:13 so important stuff to be able to fully query with respect to a given switch for example 17:39:33 Right, since /hosts doesn't support that? 17:40:07 And we don't want /[switches,firewalls,hosts,etc.], rather just /devices 17:40:08 thomasem, correct - /hosts not surprisingly only returns host objects 17:40:18 LOL yes, I was surprised at least.. 17:40:22 * thomasem kids 17:40:31 :) 17:40:42 Excellent 17:40:47 so switches, firewalls - presumably network devices 17:40:51 Right 17:40:57 Cool. I will take a look also 17:41:28 the intent is that /devices will also in the future cover such usage as AWS resources, which are not hosts 17:41:40 but are they devices... 17:41:43 ;) 17:42:10 we may have to accept that generalization may mean we are not going to refactor our names. i don't know 17:42:30 refactor our names? 17:42:44 s/device/resource/ in our code base, or something like that 17:42:56 Ahhhhhhhhh, gotcha 17:43:29 Alright, cool. Any other topics of discussion? 17:43:34 anyway, for rackspace private cloud (potential customer #1 for craton), this is moot 17:43:41 Yep 17:43:41 i like the idea 17:43:57 jovon, i like it too, other than the pain it will cause 17:44:21 c'est la vie! 17:44:37 I think we should make the functional testing non-voting to unblock the gate. 17:45:11 but i was on a project at canonical where we decided to change the name from ensemble to juju. this was a very pervasive change, and impacted tooling, bug trackers, launchpad projects, etc 17:45:17 I know sigmavirus is trying to fix the problem but we risk not being able to merge anything for a while if the issue ends up being problematic to solve. 17:45:42 git-harry, +1 17:45:44 +1 17:45:51 Yeah, let's be sure it's working before gating on it. 17:46:08 i believe sigmavirus stated he had submitted something to that effect 17:46:13 https://review.openstack.org/#/c/435038/ can be done in parallel 17:46:15 i feel like functional testing is an important aspect and once its out there it will be greate 17:46:17 jimbaker: https://review.openstack.org/#/c/434979/ 17:46:18 great ** 17:46:25 It's been marked as -W 17:46:54 by sigmavirus, yeah we need to reverse that 17:47:47 Added notes to that effect on the review 17:47:58 in retrospect, a bit of settling in with a nonvoting gate would have been nice. but funct testing had been stable quite recently 17:48:25 Yeah. This is always a concern when executing in a different environment, though. 17:48:40 I think in the future it'd be nice to see it pass there at least once before making it voting. 17:48:43 so i would say non-voting for a week or so might be the right way to do this 17:49:13 once the gate starts *working* of course 17:49:23 yep 17:49:34 Alright, cool. Well, let's follow up with sigmavirus about that. 17:49:50 Any other topics? Or do we want 10 minutes back? 17:50:12 thomasem, maybe cli testing? 17:50:26 Integration testing? 17:50:36 of course the vagueness of the action item for sigmavirus suggests that it is his forever & ever 17:50:43 eg hamster wheel 17:50:44 Pretty much. 17:50:52 but yes, integration testing 17:50:55 Wait, so you mean to tell me he doesn't want to do that forever? 17:51:35 So, how has integration testing typically been done in OpenStack, especially between client and API? 17:51:38 thomasem, i don't know. let's ask him? sigmavirus, it's ok if you work on that task forever? remember silence means yes 17:51:48 Cruel 17:52:05 ;) 17:52:33 ok, so yeah, i mean actually testing the client/CLI in some reasonably robust way against the api sever 17:52:46 tox -e integration 17:53:07 Is it a usual pattern for that to live in the client project, or API server? 17:53:23 we could start with the generate fake data as a way of loading up fixture data, suitably modified to support the changes we make 17:53:43 so we decided not to make it a dependency on the api server. because circularity 17:54:22 craton itself should be tested via rest tests, as we now do in tox -e functional 17:54:36 that's the only true contract it provides 17:54:43 So, then you'd tox -e integration in python-cratonclient project? 17:55:06 And that would... set up a craton-api and go to town exercising the code paths, or would it be a mock craton API? 17:55:12 yes, and it can potentially take advantage of projects for suitable isolation 17:55:23 Ah 17:55:43 Yeah, generate a couple of projects specific to the integration test and then mutate those projects 17:55:44 we already have some form of mock craton api testing going on the client. that's good, but we need stronger 17:55:57 and all of their descendants. 17:56:43 i'm sure we can get some fun stuff going, but i just want to verify stuff works. such as the recent pagination stuff comes to mind 17:57:02 passing sort_keys should be tested, and verified it goes end-to-end 17:57:06 hence tox -e integration 17:57:18 I don't think anyone is going to disagree with that. 17:57:35 cool. and again, silence means a chorus of resounding yeses ;) 17:58:05 My only concern is how the python-cratonclient project now has to know how to deploy a craton-api for testing. 17:58:20 thomasem, i'm ok if we put in a separate project as well 17:58:36 I was imagining that's what, like, tempest tests did. 17:58:37 but that's just extra stuff in all likelihood 17:59:04 so for tempest, that makes a lot of sense, because there are multiple projects 17:59:16 As there are here 17:59:30 right now, we just have one client. so until we grow more, easier to track in place 17:59:33 in one place 17:59:46 can always refactor by pulling out 17:59:51 Sure. I do anticipate it moving out, though. With a separate project, you can more easily manage versions and such that are being tested. 18:00:01 good points indeed 18:00:02 But, I'm not going to plant my feet over it 18:00:09 And that may take up valuable time 18:00:15 yeah, i just want one test script that can grow over time 18:00:17 So, I appreciate where you're coming from. 18:00:33 and start with generate_fake_data.py, and start updating it 18:01:06 Honestly, a lot of the stuff from our functional tests can apply here. 18:01:13 Just would need to be leveraged by python-cratonclient 18:01:23 Since that sets up a craton-api 18:01:27 i'm pretty sure we can just use in some fashion. it should be dockerized 18:01:38 And has all of the logic for create/teardown 18:01:39 and such 18:01:42 and it's available as an import, etc 18:01:57 Yeah, I guess it is. 18:02:02 didn't think about that 18:02:03 handy 18:02:03 there's no reason the test harness in the integration testing cannot just use 18:02:08 Yep 18:02:18 yeah, those pieces can continue to live in the craton project 18:02:35 So, as long as we maintain that contract, the integration tests will be fine. 18:03:10 Save for legitimate breakage. :P 18:03:20 I'm going to end the meeting (over time) 18:03:23 but we can continue this chat 18:03:29 #endmeeting