15:00:31 #startmeeting craton 15:00:31 Meeting started Mon Dec 5 15:00:31 2016 UTC and is due to finish in 60 minutes. The chair is sigmavirus. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:34 The meeting name has been set to 'craton' 15:00:35 #chair jimbaker 15:00:36 Current chairs: jimbaker sigmavirus 15:00:53 #link https://etherpad.openstack.org/p/craton-meetings 15:01:31 #topic Roll Call 15:01:32 o/ 15:03:07 o/ 15:04:04 Looks like it's just the two of us sulo 15:04:10 :( 15:05:16 * sigmavirus shrugs 15:05:20 #topic Updates 15:05:27 Any updates on your end sulo ? 15:05:43 not much other than i've update thew wf blueprint 15:05:56 https://blueprints.launchpad.net/craton/+spec/craton-workflow-engine 15:08:10 so i am working mosting on that 15:08:18 most of it i have it in some form in code 15:08:29 but watned to put that up for discussion 15:09:45 o/ 15:09:49 sigmavirus, sulo, sorry, overslept here :) 15:10:04 jimbaker: np, we just started 15:10:04 * sigmavirus is just back from vacation 15:10:06 sulo, thanks for that blueprint 15:10:15 I see tojuvone and toan are joining us today 15:10:43 jimbaker: any concise updates for us today? 15:11:13 sigmavirus, right, conciseness is something i could work on... 15:11:59 i have been working on blueprints about virtualized variables and how secrets are stored in craton 15:12:51 virtualized variables are fairly straightforward, especially because we have discussed them at length 15:13:25 secrets are potentially a rabbit hole that go as deep as we want it to go 15:13:52 jimbaker: so secrets are back? 15:13:58 o/ 15:14:53 sigmavirus, how else are we able to execute against target nodes? or against remote resources for virtualized variables? 15:15:15 jimbaker: a simple yes or no is all I need :) 15:15:21 sigmavirus, yes 15:15:32 (not trying to pick a fight) 15:15:42 heh, secrets are b a c k !! 15:15:56 or are they in the back? With the cookies? :P 15:16:21 sigmavirus, i'm just trying to pick a scheme where we have secrets, but really it's deferred to another system 15:16:22 sigmavirus: yes yes ;) 15:16:33 okay 15:17:23 jimbaker: what happened to gathering requirements and rbac? 15:17:27 anyway, it's a topic we will have to discuss in greater depth 15:17:39 jimbaker: let's queue that for tomorrow's video meeting? 15:17:43 sigmavirus, requirements were further gathered 15:18:21 good 15:18:22 so good discussion with rackspace private cloud about what they need 15:18:29 woot 15:18:40 we will be working on taking that doc and publishing on a public etherpad this week 15:19:25 sigmavirus, with respect to rbac, i think we need to gather more feedback on the blueprint i put out last week 15:19:57 Fair, I didn't have enough time to review it then. It's on my list for today 15:20:03 * sigmavirus crosses fingers hoping to get to it 15:20:03 i believe it would be better to discuss rbac in tomorrow's vidyo 15:20:04 anyway, vidyo meeting on all three tomorrow sounds good 15:20:07 Syed__: any uupdates? 15:20:16 or just updates, either way 15:20:29 yeah. been working on gathering information for Rbac 15:20:54 i have one patch in the queue. Today will try uploading two more for networks tests and routes.py tests 15:23:58 ok lets move on ? 15:24:03 +1 15:24:30 sulo: move on to? 15:24:36 Priority Reviews maybe? 15:24:41 #topic Priority Reviews 15:24:57 i dont have any reviews pending :) 15:25:21 however, not sure if git-harry is in today .. but he has a lot of open review that 15:25:35 at this point, it's really git-harry 15:26:05 I'm in but need to go in 2 minutes. Saw the -2, will rework (probably go back to my original patch) 15:26:07 with the bulk of reviews. but i think the root has been -2 by me, so need to revisit 15:26:08 yeah so i was goint to say they need review that i've -1'ed 15:26:30 but i thik those are teh ones that are in chain and have a -2 on endpoint 15:26:45 jimbaker: yeah i think thats right 15:27:13 git-harry, so we agreed to keep /v1/hosts, /v1/regions, etc 15:27:27 Yeah, I saw that 15:27:30 i guess no dispute on /v1/regions... anyway 15:27:53 so keep flat, but actually make it work for querying more generally 15:28:18 we could start by removing region_id as a required param 15:28:50 Yeah, it's fine. 15:28:51 which presumably should just work with the python-cratonclient as it is 15:29:00 Anyway, gotta go 15:29:17 hieulq, yes here, have overlapping meeting. Need to go soon. 15:30:09 git-harry, np, thanks for looking into this 15:30:49 sigmavirus, so am i'm correct on python-cratonclient? 15:31:39 yeah it should work without change .. atleast the api .. as region_id is something that is passed 15:31:50 so should work with minimal change if any 15:31:56 jimbaker: I'm not sure what you're talking about, I'd need a link to brush up on it and confirmd/eny 15:32:17 yeah, it's just a question of whether the client is specifically checking for this param or not 15:32:34 but agreed about minimal change (if any) 15:33:07 going forward, it's certainly easy for the client - just needs to handle pagination as necessary 15:35:54 that's it for priority reviews - i see that Syed__ just put in something into review a few minutes ago 15:36:29 There is one another for me 15:36:33 For network endpoints 15:36:52 The one for networks is actually dependent for me for routes and networks tests 15:36:53 :) 15:37:06 Syed__, url ? 15:37:09 of the review 15:37:29 is this https://review.openstack.org/#/c/400977/ ? 15:37:43 https://review.openstack.org/#/c/400977/ 15:37:45 Yeap 15:37:50 Thats the one jim 15:38:06 ok, i will test. especially since sulo hasn't actually tested it directly 15:38:33 Sure 15:38:34 Thank you 15:39:12 Syed__, were you able to add a functional test to this change? 15:39:31 (now that we have functional testing, we should be using it for future changes....) 15:39:34 No this change doesnt needs one i believe 15:39:46 I will add more functional tests for regions, cells etc this week 15:39:53 Will raise bugs individually for those 15:40:05 Syed__: you can leave them .. i have them already 15:40:08 Syed__, i', pretty sure if there's an endpoint involved, it will require one :) 15:40:20 Ohh i see. I didnt knew that. 15:40:21 was waiting for endpoint change to go though 15:40:27 Cool sulo 15:40:28 Thank you 15:40:47 anyway, usual transition 15:41:14 the other consideration we will have is how to bring in the python client into the functional testing 15:41:31 jimbaker: I don't think the client should be part of functional testing 15:41:39 the client and server should have their own individual functional tests 15:41:51 jimbaker: you mean from teh client side ? 15:41:56 the client shouldn't be used in the server's functional tests 15:42:24 if the server changes something that breaks the client then that change becomes dependent on the fix in the client, which is dependent on the change on the server and you have a loop that will never merge 15:42:26 sigmavirus, yeah, sure, we might call this integration testing. but similar leverage of the functional test framework 15:42:27 it's a terrible diea 15:42:39 sigmavirus, oh i agree it's horribly complicated 15:43:05 but having something that does this test is still going to be important 15:43:59 jimbaker: right, what you want is for the client to have functional tests that run the server 15:44:00 sigmavirus, i don't know where these tests are currently done in openstack projects. but hopefully the combination of standard client + service is tested on a regular basis, challenges and all 15:44:02 I agree, and we'll set that up 15:44:08 i am totes confused ... are we talking about putting client in server functional test or doing functional test for client ? 15:44:23 sulo: I understood the former, but I"m advocating solely for the latter 15:44:26 sulo, i'm just saying, do test 15:44:45 ok 15:45:11 the specifics i'm completely open to. it sounds like the client testing will drive, which is absolutely fine for me 15:46:17 which means the functional testing of the server code itself will purely look at its rest api, as is being done now 15:46:56 and speculating: the client will probably reuse the server functional test harness to do its own testing 15:48:02 if the server breaks its contract, the client tests will all start failing on a recheck. but at least we can fix the server, and get out of the pernicious loop that sigmavirus mentioned 15:48:04 jimbaker: potentially 15:48:14 (reuse the harness) 15:48:39 sigmavirus, yeah, just throwing something out there 15:50:12 anything else we should discuss in this meeting? 15:52:08 i guess that's a *no* 15:52:37 i am done 15:52:44 nothing from my side 15:52:45 thanks jim 15:52:50 Nothing that special 15:52:58 let's move additional discussion to #craton 15:53:07 +1 15:53:09 #endmeeting