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