19:00:46 <catherineD|2> #startmeeting refstack 19:00:47 <openstack> Meeting started Mon Feb 29 19:00:46 2016 UTC and is due to finish in 60 minutes. The chair is catherineD|2. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:50 <openstack> The meeting name has been set to 'refstack' 19:02:04 <pvaneck> o/ 19:02:12 <rockyg> o/ 19:02:32 <catherineD|2> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-02-29 19:03:17 <catherineD|2> hi pvaneck: rockyg: 19:03:23 <andrey-mp> o/ 19:03:27 <andrey-mp> hello 19:03:44 <catherineD|2> hello andrey-mp: 19:04:48 <catherineD|2> meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-02-29 19:04:58 <catherineD|2> let's start 19:05:17 <catherineD|2> #topic Next week meeting 19:06:05 <catherineD|2> pvaneck: will chair next week IRC meeting ... I will not b able to attend the meeting 19:06:17 <pvaneck> sure 19:06:47 <catherineD|2> thx 19:06:58 <catherineD|2> #topic Vendor user management 19:07:45 <catherineD|2> andrey-mp: thank you for submited https://review.openstack.org/#/c/285714/ 19:08:42 <catherineD|2> for user management 19:09:21 <andrey-mp> ok. I will do most things in my huge review and extract parts to commit after specification approve 19:10:00 <catherineD|2> andrey-mp: thx ... I think that is better for debug and review 19:10:59 <catherineD|2> everyone please review the vendo API spec https://review.openstack.org/#/c/274837/ 19:11:45 <catherineD|2> then andrey-mp: can proceed to implement the spec ... I think andrey-mp: has most of the code already 19:12:37 <catherineD|2> Let's target to merge the vednor API spec by tomorrow 19:12:47 <catherineD|2> moving on ... 19:12:57 <catherineD|2> #topic refstack-client should help user to avoid test duplication 19:13:20 <alexandrelevine> catherineD: Sorry, may I bring you back to vendor API? 19:13:23 <alexandrelevine> sorry again. 19:13:35 <catherineD|2> alexandrelevine: sure 19:13:56 <catherineD|2> alexandrelevine: np 19:14:08 <alexandrelevine> catherineD: I wanted to say that approve-decline would be better, because those are important functions and we don't need to change arbitrary types. 19:15:07 <catherineD|2> alexandrelevine: yea I was debating about that per REST best practices ... the action should be on a resources 19:15:29 <alexandrelevine> catherineD: change_type - is a sort of technical backdoor which doesn't show what can be change to what and who can do what. I think approve/decline would cover both important actions which will have many different things implemented inside and actions to follow. It is bad to put all of them into change_type. 19:16:32 <alexandrelevine> catherineD: I believe we can find similar stuff in existing OpenStack APIs. And it's pretty much the same like attach/detach. Moreover, those calls most probably would need different parameters later on. 19:16:52 <catherineD|2> so in OpenStack most of the time if they want to present actions the REST would be .../actions to maintain using resource on the REST 19:16:57 <alexandrelevine> catherineD: We won't be able to squeeze all of them into change_type later. 19:17:18 <catherineD|2> alexandrelevine: andrey-mp: I do not see attach/detach any more 19:17:33 <catherineD|2> are they older APIs? 19:18:00 <catherineD|2> I feel like they are nove-volume API which may not be using now 19:18:27 <alexandrelevine> catherineD: Well, you're right, they use <action> now which is also fine if we want. But not change_type 19:18:56 <catherineD|2> alexandrelevine: yea ... because they got feedback on REST best practices 19:19:05 <alexandrelevine> Let's do the same. Use action 19:19:10 <catherineD|2> sure we can use action 19:19:23 <catherineD|2> I will update that 19:19:37 <alexandrelevine> Thanks. 19:19:40 <catherineD|2> alexandrelevine: thx 19:19:52 <catherineD|2> moving on ? 19:19:56 <alexandrelevine> yes 19:20:40 <catherineD|2> #link https://bugs.launchpad.net/refstack/+bug/1498159 refstack-client should help user to avoid test duplication 19:20:40 <openstack> Launchpad bug 1498159 in refstack "refstack-client should help user to avoid test duplication" [Medium,In progress] - Assigned to David Liu (lzbj) 19:21:01 <catherineD|2> I feel like there is no good solution for the bug at the moment 19:21:21 <catherineD|2> the reason is the subunit file is a text file ... and it is very easy to change 19:21:38 <catherineD|2> I would just change one character then the file data will chamge 19:21:50 <alexandrelevine> catherineD: It doesn't matter. Anything can be changed by the uploader if it's not done by refstack-client and done later 19:21:53 <catherineD|2> so is the hash of all dates 19:22:06 <alexandrelevine> catherineD: You won't be able to compete with the root of the machine. 19:22:20 <alexandrelevine> catherineD: If he wants he'll change all the dates. 19:22:47 <catherineD|2> alexandrelevine: yea he does not need to change all the dates just one data is good enough to change the hash 19:22:51 <alexandrelevine> catherineD: Besides, we need to know time of the test run. We can keep both dates - test-run and test-upload. 19:23:00 <catherineD|2> so I feel like we do not know how to fix this 19:23:16 <alexandrelevine> catherineD: So subunit result is ok. We're not fighting malicious users here. 19:23:30 <alexandrelevine> catherineD: Just trying to prevent garbage in our DB. 19:24:05 <alexandrelevine> catherineD: Good solution would be to prohibit late uploading of results. Only refstack-client tests. 19:24:18 <catherineD|2> alexandrelevine: ++ 19:24:41 <alexandrelevine> catherineD: Whoever wants to test and participate in RefStack - uses refstack-client or centralized testing through RefStack panel. 19:24:48 <catherineD|2> I think that is the only option 19:24:55 <alexandrelevine> I'm fine with that 19:25:13 <pvaneck> I like that as well 19:25:19 <alexandrelevine> And I'm sure it's understandable and valid. 19:25:24 <catherineD|2> How about we check with foundation and defcore on that recomendation ? 19:25:33 <catherineD|2> me too I think that is the only way 19:25:35 <alexandrelevine> I'm fine with that too :) 19:25:35 <rockyg> Sounds reasonable to me, but how do you deal with clouds not connected to the internet? 19:25:53 <alexandrelevine> Still - refstack-client is used to test and crypt the result. 19:26:09 <rockyg> cool. 19:26:15 <alexandrelevine> "sign" the result. 19:26:18 <catherineD|2> rockyg: you have a point about internet connection 19:26:41 <rockyg> Yeah. We talked about this when we first started working on refstack. 19:27:02 <rockyg> But it was the whole reason for the client, so client didn't need access to net. 19:27:10 <catherineD|2> alexandrelevine: sign the results seems like something to look into 19:27:57 <catherineD|2> rockyg: correct .. thx for reminding us on this requirement 19:28:02 <alexandrelevine> So refstack-client generates unique ID for test run and supplies the time/date of the run. 19:28:40 <alexandrelevine> then it signs everything and we can use it later and find duplicates. 19:29:43 <catherineD|2> alexandrelevine:again this is about malicious intention ... because refstack-client is on the client side ... they can really generate the signature by editting the refstack-client code .. 19:30:24 <alexandrelevine> catherineD: You cannot physically fight a malicious superuser with debugger. 19:30:37 <catherineD|2> alexandrelevine: yea 19:30:52 <catherineD|2> that is why this is not an easy topic 19:31:11 <catherineD|2> rockyg: I think this is a topic for DefCore midcycle too 19:31:11 <alexandrelevine> catherineD: It is physically impossible. I'll be able to hack anything on my own hardware. So we should use some reasonable algorythms, not trying to achieve the impossible. 19:31:27 <alexandrelevine> catherineD: Quite the reverse. That's why it's easy :) 19:31:36 <rockyg> Works for me. 19:32:11 <catherineD|2> alexandrelevine: agree .. so I think there are 2 action items for this topic 19:33:04 <catherineD|2> #action RefStack team looks into the possibility of implementing signed the results 19:33:28 <alexandrelevine> catherineD: There is one sure solution - we can demand opening enough tunnels for us to run tests from our premises and control the results and forbid the remote self-done testing altogether. 19:36:16 <catherineD|2> #action Regeust guidance from DefCore/Foundation on 1) test should be run from from refstack-client. 2) out-bound connect from refstack-client to RefStack server is required 19:36:48 <catherineD|2> so at least there is a connection for uploading data 19:37:14 <catherineD|2> perfect solution would be centralized testing initiated from RefStack server ... but we are not there yet 19:38:05 <alexandrelevine> catherineD: It's not a perfect solution. Because opening connection from the inside to us is safer for some clients then having refstack panel coming from the outside. It's like passive and active ftp 19:38:17 <alexandrelevine> "than having" 19:38:53 <rockyg> right. Some clouds will be airgapped from the net 19:38:54 <catherineD|2> alexandrelevine: agree 19:38:56 <alexandrelevine> So to be safe 2 modes can exist: initiated from our side (includes Centralized option) and initiated from the client side. 19:39:25 <alexandrelevine> But still, if it's our refstack-client on that side it can safely test and pass the results. 19:39:52 <alexandrelevine> "relatively safely", of course :) It can be done too hard to hack. 19:40:49 <catherineD|2> so do everyone agree with the action statement to DefCore/foundation above? 19:40:55 <alexandrelevine> yes 19:41:01 <rockyg> ++ 19:41:19 <pvaneck> +1 19:41:20 <catherineD|2> ok so weill revisit this topic next week ... 19:41:29 <catherineD|2> moving on .. 19:41:54 <catherineD|2> #topic Please review Alex's updated requirement doc 19:42:21 <catherineD|2> #link https://goo.gl/bvo4FG (The new sections for review are starting from the "Vednor registration" section.) 19:42:35 <catherineD|2> alexandrelevine: thx for updating the doc 19:42:52 <alexandrelevine> my pleasure :) 19:43:56 <catherineD|2> I have reviewed and made some comments ... would appreciate everyone to review ... 19:44:41 <catherineD|2> moving on .. 19:45:04 <catherineD|2> #topic Pending reviews 19:45:39 <catherineD|2> #link https://review.openstack.org/#/c/283885/ Fix link error for RefStack PyPI 19:46:31 <catherineD|2> if you look at https://pypi.python.org/pypi/refstack/1.0.1 19:47:16 <catherineD|2> the API and UI install docs: doc/refstack.md link is broken .. 19:47:40 <pvaneck> I can change that manually I believe, but still good to update the readme to use direct links i think 19:48:17 <catherineD|2> let's do it on the read me it does not hurt and avoid you to manually fix every time 19:48:41 <catherineD|2> moving on 19:49:06 <catherineD|2> #link https://review.openstack.org/#/c/284992/ Update angular bootstrap components 19:50:18 <catherineD|2> I guess we just need David or Sergey to do a final review on this one .. 19:51:09 <catherineD|2> for 6.3 and 6.4 since they are new just let everyone have a chance to review them ... 19:51:35 <catherineD|2> any other topic? 19:51:58 <alexandrelevine> catherineD: Yes 19:52:05 <catherineD|2> alexandrelevine: please 19:53:06 <alexandrelevine> catherineD: I think that the fact that after 3 weeks and one response I had to resort to suggesting some solutions myself instead of getting answers from DefCore means that they do not care enough about RefStack. Usually it leads to results not expected by stakeholders when they get the product. 19:54:05 <catherineD|2> alexandrelevine: How about this ... Let us put this on the agenda for Wed IRC meeting .. 19:54:26 <rockyg> Midcycle is coming up shortly. I think maybe there are some DefCore members that would respond if reached out to directly. Maybe we should try that. 19:54:51 <alexandrelevine> catherineD: Put what? Conceptual problem or particular one? 19:55:17 <catherineD|2> alexandrelevine: put the questions in your second email to the agenad 19:55:23 <catherineD|2> agenda 19:55:34 <alexandrelevine> catherineD: We can't discuss something during one meeting. There should be a way to communicate complicated matters and have responsible people to pay attention. 19:55:37 <catherineD|2> so we will get response 19:55:55 <alexandrelevine> catherineD: We won't. At least not a thought-over one. 19:56:03 <catherineD|2> alexandrelevine: we will ask on the meeting that they respond to the email 19:57:27 <catherineD|2> IMO. DefCore is our stake holder 19:57:35 <alexandrelevine> catherineD: Well, it won't solve conceptual problem. They haven't read the doc with requirements also. Only Eigle once. So maybe we shouldn't bother. I'm trying to bring attention to the whole picture. 19:57:47 <alexandrelevine> catherineD: Of course they are. 19:58:24 <alexandrelevine> catherineD: Anyways. If we want to have particular answers then important one is about the info for vendor registration. 19:58:32 <alexandrelevine> catherineD: That can be asked. 19:59:20 <catherineD|2> OK let's do that ... I will give update the team on Wed afternoon ... of course will ask for response via email too 19:59:32 <catherineD|2> I think we are about out of time 19:59:44 <catherineD|2> thank you everyone!!! 19:59:46 <alexandrelevine> yep. 19:59:59 <andrey-mp> thank you! 20:00:01 <catherineD|2> #endmeeting