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