19:01:28 <catherineD2> #startmeeting refstack
19:01:29 <openstack> Meeting started Mon Mar 16 19:01:28 2015 UTC and is due to finish in 60 minutes.  The chair is catherineD2. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:34 <openstack> The meeting name has been set to 'refstack'
19:01:38 <catherineD2> hello Rockyg:
19:01:47 <Rockyg> Hi!
19:01:54 <vladiskuz_> o/
19:02:12 <sslypushenko_> o/
19:02:24 <pvaneck> o/
19:02:55 <catherineD2> David will miss today's call ... He will catch up with us later ...
19:03:05 <catherineD2> Today's agenda :
19:03:37 <catherineD2> 1) uuid issue and refstrack test results json schema 2) Review Feb 18 f2f action items. 3) Do we need a f2f meeting for March 4) Review patches ..
19:03:37 <hogepodge> o/
19:03:43 <catherineD2> Any other topics?
19:03:57 <hogepodge> [refstack] tag for mailing list
19:04:37 <hogepodge> OpenStack ID integration.
19:04:57 <Rockyg> take aways from Ops midcycle?
19:05:04 <catherineD2> ok we will discuss those items before review the patches then ...
19:05:30 <catherineD2> #topic uuid issue and refstrack test results json schema
19:06:54 <catherineD2> sslypushenko_: is working on a patch ... not sure how it will turn out ... we need to decide on what to use for the result schema for refstack-client
19:07:14 <catherineD2> do we still use the fully-qualified-name ?
19:07:37 <catherineD2> since uuid is not unique at this time ...
19:07:44 <sslypushenko_> I guess we should provide both name and uuid
19:08:12 <sslypushenko_> Also I'm expected to fix duplication issue
19:08:13 <Rockyg> I don't think we have a choice unless we map the foll path to test name elsewhere
19:08:24 <catherineD2> the problem is with the name we need to stick on a certain tempest tag or the names do not help much ....
19:08:35 <hogepodge> Ultimately the tempest team has to decide is the idempotent_id metadata is enough or if they want more.
19:08:49 <catherineD2> so practically ... that uuid is not ver y helpful to us at this moment ...
19:09:19 <hogepodge> To me it seems like they're happy with the way things are. A test with an ID should have the same functionality, just slightly different application. Say ipv4 vs ipv6
19:09:32 <hogepodge> It's more helpful than nothing.
19:09:44 <catherineD2> for tempest it is the right thnik to do ...
19:09:55 <catherineD2> more important is for defcore
19:10:21 <Rockyg> Yeah, but the IPV4 vs IPV6 is *really* important to some folks, so they will want something to identify which is which
19:10:26 <catherineD2> is passing a test in ipv6 and ipv4 the same for defcore ?
19:10:31 <hogepodge> catherineD2: that needs to be communicated with mtreinish then. It's important that we speak with them about issues we face.
19:10:57 <catherineD2> I think it is more to defcore than tempest's interest \s ..
19:11:06 <Rockyg> catherineD2:  no.  IPV6 is what is keeping the china nodepool down
19:11:07 <catherineD2> to tempest they are the same test ..
19:11:27 <sslypushenko_> hogepodge I will finish my patch and write letter to Matt
19:11:57 <catherineD2> hogepodge:Rockyg: my concern is the 2015.03 spec
19:12:07 <hogepodge> sslypushenko_: thanks.
19:12:28 <Rockyg> I think we need to be explicit in the spec, too.
19:12:29 <catherineD2> people start discussing tests ... we do not even know the name that we will use ...
19:12:40 <hogepodge> between idempotant_id, test name, and github hash, we have completely trackable tests across locations.
19:13:01 <Rockyg> Right now, IPV6 doesn't work totally, but by the next spec, it will likely be part of it.
19:13:08 <hogepodge> even with idempotent_id, we still have to have the test name for human readability.
19:13:13 <catherineD2> to me idempotant and test name is the same thing ...
19:13:30 <catherineD2> hogepodge: agree on that  front
19:13:39 <catherineD2> what is github hash>
19:13:41 <catherineD2> ?
19:13:53 <hogepodge> This is mostly to track tests through refactorings.
19:14:09 <Rockyg> The hash that translates to the specific checkin of the patch
19:14:27 <hogepodge> Every point in time in a github project has a hash that references that checkin.
19:14:50 <hogepodge> You can check out code against that hash.
19:15:16 <hogepodge> For example, the latest tempest checkin https://github.com/openstack/tempest/commit/4baeda6b8060e2bd1ca1092e7f5de4b2e338bd98
19:15:21 <Rockyg> You can check out the whole repository from that hash and get a copy of what each file was when the hash was generated
19:15:21 <catherineD2> I am not sure how would that be implemented in refstack-client ....
19:16:10 <Rockyg> Well, the hash is the same as a label.  The label just points to a hash, so it give us a snapshot of the tree
19:16:13 <catherineD2> how do we enforce that the the refstack-client user ? that is why we decided to use tag release in the pass ... so we level set all users ...
19:16:58 <catherineD2> so basically I see nothing change ... we still will have to stick with a certain tag or release ..
19:16:59 <hogepodge> catherineD2: Defcore needs a schema update to reference github hash for tempest at time of approval.
19:17:08 <catherineD2> hogepodge: +1
19:17:38 <hogepodge> catherineD2: Yes, the main benefit is tracking tests as they move. If sslypushenko_ has is idea approved we'll be closer to the ideal of a unique idea for every test
19:17:53 <hogepodge> Oh, this also came through today: a bug against idempotent_id
19:17:54 <hogepodge> sslypushenko_: ^^
19:18:00 <catherineD2> sslypushenko_: this is why I do not think we need to merge https://review.openstack.org/#/c/161760/ and https://review.openstack.org/#/c/161315/ at this time ..
19:18:09 <hogepodge> https://bugs.launchpad.net/bugs/1431267
19:18:11 <openstack> Launchpad bug 1431267 in tempest "tools/check_uuid.py works incorect for tests with decorators " [Undecided,Fix released] - Assigned to Marc Koderer (m-koderer)
19:18:12 <uvirtbot> Launchpad bug 1431267 in tempest "tools/check_uuid.py works incorect for tests with decorators " [Undecided,Fix released]
19:18:13 <uvirtbot> Launchpad bug 1431267 in tempest "tools/check_uuid.py works incorect for tests with decorators " [Undecided,Fix released] https://launchpad.net/bugs/1431267
19:18:26 <hogepodge> please review the fix.
19:18:38 <hogepodge> #link https://review.openstack.org/#/c/153234/
19:19:45 <hogepodge> #link https://review.openstack.org/#/c/164647
19:20:11 <catherineD2> so from refstack and refstack-client point of view ... we are waiting for defcore's update schema ... and meanwhile we will stick with tag-3 and fully-qualified-test-name?
19:20:12 <hogepodge> (the second was the patch, and it was merged)
19:20:26 <sslypushenko_> catherineD2 Ok. Lets fix duplication issue first
19:20:35 <catherineD2> sslypushenko_: +1
19:20:54 <hogepodge> catherineD2: for 2013.3 we should use a more recent tempest tag. bug fixes, etc.
19:21:22 <catherineD2> which tag?
19:21:43 <catherineD2> +1 about bug fixes ..
19:21:47 <hogepodge> not tag, hash.
19:22:04 <Rockyg> Right.  I think we need to pull a hashtag from when 2015.3 is approved, test it, and if it is good, label it.  Otherwise, fix problems, retest, and label when OK.
19:22:46 <catherineD2> so 2015.3 should define the hash then refstack and refstack-client will update appropriately?
19:22:59 <Rockyg> Yes.
19:23:24 <Rockyg> Well, actually, pick the hash that meets 2015.3 definition
19:23:31 <catherineD2> hogepodge: the reason we use tag because those are official tag the tempest published ...
19:23:53 <catherineD2> for every OpenStack release
19:24:02 <hogepodge> catherineD2: Maybe we can ask the qa team to tag tempest at the time of defcore approvals.
19:24:03 <Rockyg> We can submit a patch to label a specific hash for the defcore version
19:24:11 <catherineD2> hogepodge: +1
19:24:17 <catherineD2> let do that ...
19:24:52 <Rockyg> Sounds like this needs to be added to the defcore process zehicle
19:25:07 <catherineD2> Rockyg: hogepodge: we just need something that is offical and can be tracked and easily locate by all users ..
19:25:33 <Rockyg> Yup.  And documented in the defcore process doc.
19:25:40 <Rockyg> Easy, once we have the plan
19:25:45 <catherineD2> Rockyg: hogepodge: we need very close communicatio with defcore ... I start to listening at defcore meeting too
19:25:52 <Rockyg> Which we do, now.
19:26:15 <catherineD2> 2014.3 schema is something we need now ...
19:26:32 <Rockyg> You mean 2015.03?
19:26:45 <Rockyg> Ichouse sort of equivalent?
19:26:46 <catherineD2> right now it is still defined test as an arrays for fully-quialified-testnames
19:26:48 <catherineD2> yes
19:26:58 <catherineD2> 2015.03
19:27:03 <Rockyg> thanks
19:27:49 <Rockyg> I think we will need two labels:  one for proposed and one for approved.  But the fully qualified paths will be mostly the same from approval to tagging.
19:28:22 <Rockyg> Also will need to tag the tests "interop"
19:28:43 <catherineD2> ok for this topic we will operate business-as-usual until we get a new schema?
19:28:50 <Rockyg> ++
19:29:01 <hogepodge> Rockyg: We need a qa spec for that, a spec I need to write.
19:29:15 <catherineD2> hogepodge: +1
19:29:27 <Rockyg> ++
19:29:27 <catherineD2> ready to move to the next topic?
19:29:49 <catherineD2> #topic Review Feb 18 f2f action items
19:30:06 <catherineD2> #link https://etherpad.openstack.org/p/refstack_f2f_feb_2015
19:30:43 <catherineD2> Please scroll to the botton section labeled "Action Items based on priorities"
19:32:08 <catherineD2> sslypushenko_: vladiskuz_: are working on item 1.0.1 ?
19:32:44 <catherineD2> are we good that this is a must-have item for vancouver?
19:33:01 <sslypushenko_> We discussed that item with hogepodge and agreed that it would be better to start with auth based on openstack-id
19:33:51 <hogepodge> sslypushenko_: more specifically, open id (or oauth2) auth plugged with openstack-id as a provider
19:34:11 <sslypushenko_> Sure, that item should be done as fast as possible
19:34:15 <Rockyg> ++
19:34:23 <catherineD2> ++,  where do we save the credential?
19:34:31 <sslypushenko_> hogepodge Yep
19:35:01 <hogepodge> catherineD2: I imagine something like a openrc file for storing generated token credentials
19:35:09 <sslypushenko_> catherineD2 In Refstach database
19:35:27 <vladiskuz_> but auth with openstack-id without browser is very difficult
19:35:57 <sslypushenko_> for Refstack API - databese. for client in .openrc file
19:36:13 <catherineD2> sslypushenko_: that means that we will be keeping user's id and passworf in refstack dabase ...
19:36:17 <hogepodge> vladiskuz_: We have a choice between openid and oauth
19:36:26 <sslypushenko_> catherineD2 only id
19:36:30 <hogepodge> catherineD2: no, id
19:36:52 <catherineD2> we will need to authenticale before the token is created right?
19:36:54 <sslypushenko_> hogepodge We need a little more time to investigate
19:37:02 <catherineD2> sslypushenko_: ++1
19:37:04 <hogepodge> sslypushenko_: of course
19:37:05 <Rockyg> We're going to run apache on refstack.org, aren't we?  Folks will access from browser.....
19:37:26 <Rockyg> All tied to openstack.org which is the definitive for the auth?
19:37:43 <hogepodge> Rockyg: there will need to be an approval step for any single sign on id
19:37:59 <hogepodge> Rockyg: that's usually done in a browser
19:38:14 <hogepodge> Rockyg: I don't know if there's a way to do it without
19:38:46 <catherineD2> hogepodge: we used to log in refstack using our openstack credential ...
19:38:47 <Rockyg> Wouldn't you want an interactive session for any official push, anyway?
19:39:03 <catherineD2> let's check back with David ... he implemented that section of cide
19:40:50 <Rockyg> Mockup shows "vendor login" so I assume the access to refstack is through the browser....
19:40:56 <catherineD2> so the status of this iten (section 1.0.1) is sslypushenko_: will need to investigate some more and we will check with David ...
19:41:26 <sslypushenko_> That is correct
19:41:48 <catherineD2> Rockyg: we will discuss more on mockup next ..
19:41:59 <Rockyg> k
19:42:03 <catherineD2> any other thought for this section?
19:42:36 <catherineD2> If not, let's move on to section 1.0.3  ok?
19:43:18 <catherineD2> I do not think we have time to implement vendor related aspect for Vancouver ....
19:43:39 <sslypushenko_> +1
19:43:40 <catherineD2> section 1.0.1 that we discussed earlier is for a specfic user
19:44:22 <Rockyg> agreed on 1.0.3
19:44:24 <catherineD2> and before vendor implememtation ... there will be no association between user and vendor
19:44:57 <hogepodge> A user can clearly be a proxy for a vendor in the meantime.
19:45:26 <catherineD2> Rockyg: great if we all agree on 1.0.3 then all mock up about vendor will not be relavent ...
19:45:42 <Rockyg> Can we verify user email address against vendor domain?
19:45:58 <Rockyg> Or that gets too much into stuff like 1.0.3 needs to do?
19:46:11 <catherineD2> Rockyg: yes that is why ..
19:46:37 <Rockyg> With a user, can we piggyback on what openstack.org already does for verification?
19:46:47 <catherineD2> and for vancouver the data will be anonymous
19:46:53 <Rockyg> Ah.
19:47:26 <catherineD2> the reason we want user authentication ... to prevent one user flooding and bias the results ...
19:47:27 <Rockyg> So, just assume no official vendor data.  this is all community.
19:47:34 <catherineD2> yes
19:48:24 <catherineD2> so for section 1.0.3 we will move it to after vancouver ...
19:48:29 <catherineD2> plase vote :-)
19:48:40 <hogepodge> +1 for now
19:48:46 <Rockyg> +1
19:48:50 <sslypushenko_> +1
19:48:54 <vladiskuz_> +1
19:49:12 <catherineD2> Paul?
19:49:31 <sslypushenko_> unanimously)
19:49:36 <pvaneck> +1 from me
19:49:39 <catherineD2> OK 1.0.3 will be moved to after vancouver
19:49:49 <catherineD2> only 10 mins left ..
19:50:10 <catherineD2> section 1.0.4   Please look at the mockup ..
19:50:28 <catherineD2> so we still need page 1.
19:50:50 <catherineD2> skip page 2 (vendor log-in)
19:51:27 <catherineD2> skip page 3 -- results associated with a specifc vendor ..
19:51:42 <catherineD2> we will need page 4 ..
19:52:45 <Rockyg> Question on this:  will vendor be identified with test, or even the vendors anonymous on the results here?
19:53:35 <catherineD2> vendors (or the users) can identify their test by 1) remember the testod when they submit the test
19:53:52 <sslypushenko_> It will be good we they will have both options
19:54:18 <Rockyg> So, no grouping by vendor available  on this page
19:54:23 <catherineD2> 2) or they can identify their on tests by checking the cpid
19:54:44 <catherineD2> remember we do not have vendor info at this point ...
19:54:46 <hogepodge> I'd be for having a user account that is a vendor
19:55:15 <Rockyg> True.  But futue will want that option so maybe greyed out?
19:55:25 <catherineD2> the question is for vacouver do we even want  to display the cpid?
19:55:37 <Rockyg> Also, should be Results in title
19:56:25 <Rockyg> Do we want to call these Refstack test Results or DefCore test results? and do we want a test set version on this page
19:56:53 <catherineD2> Rockyg: yes need more work in this mock up ... at this point I would like to see us decide on we only want page 1 and 4 for vancouver ... we will work on the detail some more ..
19:56:59 <Rockyg> Again, I think the test set selection can be grayed out, but should be there.
19:57:16 <catherineD2> just time check ..
19:57:29 <Rockyg> No need for 2 or 3 if no vendor registration available
19:57:34 <catherineD2> we have a lot to discuss ... do we want to continue in #refstack?
19:57:42 <catherineD2> Rockyg: yes ..
19:57:50 <vladiskuz_> what about my patches with unit tests?
19:58:41 <catherineD2> can everyone meet over in #refstack?  we will discuss vladiskuz_: patches ...
19:58:49 <hogepodge> yes
19:59:07 <Rockyg> yes
19:59:27 <catherineD2> let' wrap up here
19:59:40 <catherineD2> #endmeeting