19:00:10 <catherineD> #startmeeting refstack
19:00:11 <openstack> Meeting started Mon Dec  7 19:00:10 2015 UTC and is due to finish in 60 minutes.  The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:15 <openstack> The meeting name has been set to 'refstack'
19:00:39 <markvoelker> o/
19:00:43 <dwalleck> o/
19:00:47 <rockyg> o/
19:00:50 <pvaneck> o/
19:01:30 <catherineD> hello everyone
19:01:42 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-12-07
19:02:32 <davidlenwell> hi
19:03:30 <catherineD> #topic     Review mapping ( https://etherpad.openstack.org/p/mitaka-refstack-ation-items  ) of   "RefStack Enhancement" document ( https://goo.gl/hDC6U3 ) to RefStack Mitaka priority  ( https://etherpad.openstack.org/p/refstack-tokyo-summit )
19:03:36 <sslypushenko__> o/
19:04:29 <catherineD> sslypushenko__: agenda https://etherpad.openstack.org/p/refstack-meeting-15-12-07
19:04:56 <sslypushenko__> thx!
19:05:20 <catherineD> so Alex Levin send us a document describing the enhancements for Refstack
19:06:00 <catherineD> #link RefStack enhancement doc from Alex Levin https://goo.gl/hDC6U3
19:06:31 <sslypushenko__> Really good doc!
19:06:51 <dwalleck> Very detailed :-) There's a lot of good ideas here
19:06:56 <sslypushenko__> It is some what was missing
19:07:35 <catherineD> basically there are 5 majoir areas:  1 Register cloud, 2 Run test, 3 Run external test suitesm, 4 Show cloud achievement, 5 Simplify test preparation
19:08:57 <catherineD> +2 agree with everyone that it is a very good doc ... so the refstack team will seriously looking to implement those that is applicable ...
19:09:04 <sslypushenko__> It looks like a lot of work
19:09:27 <hogepodge> o/
19:09:27 <davidlenwell> it looks very close to the original vision of refstack
19:09:43 <rockyg> Sounds like time for a multi-cycle road map!
19:10:03 <sslypushenko__> rockyg +1
19:10:08 <catherineD> yes it is a lot of work but we can prioritize at the minimum to implement the building blocks first ...
19:10:09 <sslypushenko__> We need aplan)
19:10:27 <rockyg> ++
19:10:43 <davidlenwell> sounds like we should sit down and compare it against the existing use cases and then reprioritize everything and make a plan
19:10:46 <catherineD> yes ... we need a plan ... so I did a quick mapping documented in https://etherpad.openstack.org/p/mitaka-refstack-ation-items
19:11:29 <catherineD> #link quick mapping of Alex's doc to Mitak priority https://etherpad.openstack.org/p/mitaka-refstack-ation-items
19:13:23 <catherineD> the three areas that I think we could prioritize to implement for Mitaka is 1) register cloud .. this map very well to what we want to do any way for vendor registration
19:14:24 <catherineD> next is Item #3 in Alex's doc Run external test suite ---> RefStack wants to implement this for this cycle too
19:15:15 <pvaneck> I think we can go ahead with the vendor/product stuff and start implementing that. Already have a lot of details regarding that from the summit
19:15:20 <catherineD> and #4 Show cloud achievement --> If RefStack will allow testing of external test suite we need a way to render data .... t
19:16:03 <alevine> o/
19:16:16 <catherineD> pvaneck: +1 ... we could go ahead with that ..
19:16:44 <catherineD> alevine: hi ... agenda link https://etherpad.openstack.org/p/refstack-meeting-15-12-07
19:17:38 <alevine> sorry I'm late. I got the beginning of the meeting. I wanted to remind that a large part of the mentioned functionality is already implemented. At least as a working prototype
19:17:58 <catherineD> alevine: please take a look at the mapping in  https://etherpad.openstack.org/p/mitaka-refstack-ation-items
19:18:21 <alevine> CatherineD: I did see it beforehand. Thank you.
19:19:08 <catherineD> alevine: yup ... I have seen your prototype site
19:19:16 <alevine> We're more than happy to implement and contribute what's stated in the doc if you give us green light.
19:20:15 <alevine> It'd really save us time and effort if you won't make us to create all of the specs and let us refine the doc according to any comments that can arise, and then implement the thing.
19:20:21 <catherineD> #link Alex's team prototype  http://refstack.cloudscaling.com:8000/#/
19:21:26 <alevine> Everybody: Sorry, you need to use the fake sign-in at the right to get access to all functionality.
19:21:36 <sslypushenko__> alevine Sounds reasonable
19:22:06 <catherineD> alevine: the 3 building block areas that we would like to see implemented first is 1) Register cloud 2) external text 3) show cloud achievement
19:23:03 <catherineD> alevine: How about if I write the specs for the three areas mentioned above ...?
19:23:19 <alevine> catherineD: Absolutely. How about running tests from the panel though?
19:23:59 <catherineD> alevine: we can discuss running test in the next few meetings ...
19:24:11 <alevine> catherineD: Whatever you say. I can also help with righting the specs if you think it's required.
19:24:21 <catherineD> as davidlenwell: indicated earlier this is our original design ...
19:24:53 <catherineD> we have encountered a few challenging areas that I would like the team to discuss further ...
19:25:07 <sslypushenko__> catherineD It looks like we just need to convert google document into rst spec
19:25:12 <alevine> catherineD: The problem is - it's much easier to test all of the other features you mentioned when you can do everything from the panel. :) So I guess we can at least have it in some draft, experimental form just to use.
19:25:20 <catherineD> alevine: I think we should have the spec ..
19:25:33 <dwalleck> I think having a working prototype makes writing the specs easier. I think the spec process will help make sure we flesh out the features appropriately
19:25:46 <alevine> "writing the specs", sorry :)
19:26:09 <catherineD> alevine: I think a prototype would be very helpful ...
19:26:48 <alevine> dwalleck: agree. I suggest we bring the prototype up to speed with the design if the design is approved overall. And then it'll be very easy to reflect it in the specs.
19:27:35 <catherineD> if we agree that we will implement the building block as our first phase ... I would like to review our data model next ..
19:28:37 <alevine> catherineD: Ok. Sounds great. We can enhance the data model described in your doc with additional data required for new functionality.
19:28:58 <catherineD> alevine: thx ...
19:29:12 <catherineD> #topic Review and agree on data models
19:29:20 <dwalleck> alevine: I totally agree. To add to what catherineD said, I think we just want to make sure we're adding expandable bases
19:29:27 <catherineD> #link data model https://goo.gl/zWYnoq
19:29:52 <catherineD> could everyone look at slide# 7
19:30:20 <catherineD> slide# 6 was what we discussed before ...
19:30:47 <catherineD> after review alevine: 's doc I feel like we need a "product" entiry ...
19:32:35 <dwalleck> Right now Tempest tests aren't directly tied to a product. Where would that data come from?
19:32:36 <catherineD> onm slide#7 the new tables are role, group, product, vendor and grp_suer_role_relationship (used for many to many mapping of role, user, group)
19:33:02 <catherineD> dwalleck: good question ..
19:33:13 <catherineD> everyone please go to slide#2
19:34:15 <catherineD> so product can be created (register) by vendor (item 2 ) or any user (item 3)
19:34:22 <alevine> dwalleck: We suggest that Tempest tests are tied to Schemas, while test configurations are tied to clouds/products.
19:34:43 <dwalleck> Ahh, product as in a product within a vendor, not within OpenStack. I see now
19:34:56 <catherineD> dwalleck: yup
19:35:33 <catherineD> any inputs for slide#2 and slide#7?
19:35:47 <alevine> catherineD: We'll need more users and roles later
19:35:54 <sslypushenko__> LGTM
19:36:19 <catherineD> sslypushenko__: pvaneck: I think you suggested earlier that the product info can be saved in meta table ....
19:37:06 <catherineD> but with alevine: concept if cloud testing ... I think that maps well with product having its own table
19:37:06 <alevine> catherineD: Sorry, I see you covered all roles, except Guest.
19:37:07 <sslypushenko__> Now product gets more sense
19:37:16 <pvaneck> that was before we had a product table
19:37:32 <sslypushenko__> Any way it requires time to think
19:37:41 <catherineD> alevine: we can add add Guest to our table ...
19:37:55 <sslypushenko__> I will put comments in doc if I come up with something
19:38:12 <catherineD> sslypushenko__: absolutely ... that is why I would like to have us think about all of this before implementation ...
19:38:23 <catherineD> sslypushenko__: please do ...
19:38:50 <catherineD> I think having a good data model will help a lot ....
19:39:02 <sslypushenko__> for sure
19:39:35 <sslypushenko__> Any way it is a good start
19:40:37 <catherineD> How about we let everyone take sometime to review the data model until next week ... then we start to implement data model and its aspect like API for model CRUD
19:41:18 <catherineD> #action all RefStack team members to review data model described in https://goo.gl/zWYnoq
19:41:22 <alevine> catherineD: wouldn't you want to have schemas objects in data model later as well?
19:42:01 <catherineD> alevine: that is what I want to discuss next  about schemas
19:42:16 <catherineD> alevine: are you refering to schema for data rendering?
19:42:23 <catherineD> or data base schema?
19:42:41 <alevine> catherineD: For describing external test suites and Target Programs.
19:43:16 <alevine> catherineD: I'm sorry I'm not aware of any other schemas - I'm using the term from my doc.
19:43:21 <catherineD> alevine: yup ... currently we usde DefCore schena ..
19:43:33 <alevine> catherineD: Of course :)
19:44:03 <hogepodge> catherineD: guideline is probably better terminology
19:44:27 <hogepodge> the guideline has an ad-hoc schema (we haven't actually formally defined it)
19:45:30 <catherineD> alevine: I think we were talking about the ad-hoc schema  right?  schema is what we use to render the content of the Guideline ...
19:45:31 <alevine> catherineD: hogepodge: I was trying to use a parallel term from www.w3c.org - like XSD schemas for XML. So here we can define our schemas.
19:45:45 <sslypushenko__> alevine schemas will be stored in DB anyway, so model should meet this fact
19:47:02 <alevine> ssplypushenko__: No problem. Though we might consider having external schemas in outside URLs like XSD and WSDL schemas reside.
19:47:03 <catherineD> alevine: sslypushenko__: hogepodge: I think each of us may talk about different things here... I suggest that we discuss this in refstack IRC after this meeting ....
19:47:41 <catherineD> I do want to discuss externl testing next now that we have DefCore member here ...
19:48:35 <sslypushenko__> IMO, we should try to make data model as abstract as possible and get rid of details. It will give us a required level of flexibility
19:48:53 <catherineD> to sumarize, everyone will review the data model ... next week we will log our agreement and then proceed to implementation
19:49:30 <catherineD> sslypushenko__: +1
19:49:56 <sslypushenko__> alevine: Is it possible to look on code of our team prototype?
19:50:30 <catherineD> so everyone please voice your opion on the update needed on the data model via IRC, email, or update the doc ...
19:50:33 <alevine> sslypushenko__: Absolutely. Could you send me a link, please, just to be sure that's what you want us to look to?
19:51:08 <sslypushenko__> http://refstack.cloudscaling.com:8000/ this one
19:51:59 <alevine> sslypushenko__: I'm sorry I got you wrong. I thought you want my team to look at your prototype :). You want to look at our code? Sure.
19:52:12 <catherineD> #topic Pending reviews
19:52:28 <catherineD> #link     Another way to use additional tests for tempest  https://review.openstack.org/#/c/249160/
19:52:46 <alevine> sslypushenko__: Here is the repo: https://github.com/cloudscaling/refstack
19:53:01 <sslypushenko__> alevine thx!
19:53:28 <catherineD> alevine:  both sslypushenko__:  and I agree that https://review.openstack.org/#/c/249160/   is a very approached to bring in external tests
19:53:30 <sslypushenko__> catherineD I think it is kind of POC
19:54:55 <catherineD> alevine: may question is should we install non-DefCore package like (ec2-api) out of the box ... or should we provide instruction for users to add non-DefCore test packages
19:55:13 <catherineD> sslypushenko__: what is a  POC?
19:55:34 <alevine> catherineD: Yes the instruction about how to create tempest plugin and new schema would be very helpful. We have such a thing internally now.
19:55:49 <sslypushenko__> catherineD: proof of concept
19:55:59 <dwalleck> catherineD: I'd vote for installing any other test suites as a separate step. That avoids any install by default bias
19:56:35 <catherineD> alevine: but the question is should we add ec2-api into the tempest-additional-requirements.txt file?
19:57:26 <alevine> catherineD: I'd say that tempest-additoinal-requiremens.txt should be empty in RefStack repo. They are "additional". The baseline reqs should be in other .txt files.
19:57:29 <hogepodge> catherineD: it's not part of the defcore guideline, and never will be
19:57:33 <sslypushenko__> dwalleck It depends on Defcore requirements. There is a plan include some swift tests into Defcore schema
19:57:37 <catherineD> hogepodge: markvoelker: rockyg: I think that question should be toe DefCore ... should RefStack out-of-the-box installed only DefCore required external packages?
19:57:57 <alevine> catherineD: Yes, no ec2-api in RefStack repo.
19:58:01 <hogepodge> catherineD: but what external tests you want to install is up to the refstack team
19:58:12 <catherineD> alevine: great ...
19:58:25 <alevine> catherineD: defcore tests are all in core tempest, aren't they?
19:58:45 <alevine> catherineD: Then they shouldn't be in tempest-additional-requirements.txt either. It's just a placeholder.
19:58:53 <dwalleck> sslypushenko__: Agreed. I think anything DefCore requires should be installed by default (including external tests). Anything extra should be supported, but not installed by default
19:58:54 <hogepodge> alevine: we may allow some tests to be sourced externally, like swift, assuming they adopt the tempest plugin architecture
19:59:24 * redrobot pokes head in
19:59:27 <catherineD> alevine: I think DefCore is looking at bring in Swift in-tree test ... from refstack point of view ... it is like external but required test
19:59:30 <hogepodge> #link https://review.openstack.org/#/c/214206/
19:59:52 <catherineD> we need to end our meeting soon ... could we continue on #refstack
19:59:57 <alevine> hogepodge: I'd say that if we suggestion tempest-addtional-requirements.txt for external usage, we better not mix anything core into it. If we want swift as a plugin - fine. But it shouldn't go there I guess anyways.
20:00:08 <alevine> "suggest"
20:00:13 <catherineD> #endmeeting