| *** pvaneck has quit IRC | 01:10 | |
| *** dwalleck has joined #refstack | 05:03 | |
| *** andrey-mp has joined #refstack | 05:34 | |
| openstackgerrit | zhufl proposed openstack/refstack: Remove unused LOG https://review.openstack.org/338711 | 06:21 |
|---|---|---|
| *** andrey-mp has quit IRC | 06:54 | |
| *** dwalleck has quit IRC | 07:22 | |
| *** pilgrimstack has joined #refstack | 07:59 | |
| *** openstackgerrit has quit IRC | 08:18 | |
| *** openstackgerrit has joined #refstack | 08:19 | |
| *** andrey-mp has joined #refstack | 08:32 | |
| sslypushenko | Hi,folks! I tested RefStack app from https://review.openstack.org/#/c/336656 and find it functional. So, if someone is able to try it, I'll be appreciated to hear any feedback | 12:44 |
| sslypushenko | it is a direct link on application package --> https://www.dropbox.com/s/gcs8qpd7vphangp/RSC.zip | 12:58 |
| andrey-mp | I never installed Murano :) | 13:02 |
| *** cjvolzka has joined #refstack | 13:13 | |
| sslypushenko | andrey-mp: you are so lucky man))) | 14:03 |
| sslypushenko | but you want to try you can install it with devstack | 14:04 |
| sslypushenko | *but if you want | 14:04 |
| andrey-mp | no-no, I don't want ) | 14:16 |
| *** davidlenwell has quit IRC | 15:20 | |
| *** davidlenwell has joined #refstack | 15:30 | |
| *** ChanServ sets mode: +o davidlenwell | 15:30 | |
| *** dwalleck has joined #refstack | 15:33 | |
| *** cjvolzka has quit IRC | 15:36 | |
| *** cjvolzka has joined #refstack | 15:37 | |
| *** pvaneck has joined #refstack | 15:59 | |
| *** alevine has joined #refstack | 16:00 | |
| catherineD|2 | hello everyone ... pls let me know you are here for the "RefStack Test Results Ownership Discussion" meeting | 16:01 |
| alevine | o/ | 16:01 |
| andrey-mp | o/ | 16:01 |
| catherineD|2 | alevine: hi | 16:01 |
| alevine | hi | 16:01 |
| hogepodge | o/ | 16:01 |
| pvaneck | o/ | 16:01 |
| catherineD|2 | first of all thx for your time to attend this special meeting | 16:02 |
| catherineD|2 | we will continue last week's agenda (at the bottom) of https://etherpad.openstack.org/p/refstack-meeting-16-06-28 | 16:03 |
| sslypushenko | o/ | 16:03 |
| catherineD|2 | Summary of last week’s discussion: | 16:04 |
| catherineD|2 | I will signal when I am done | 16:04 |
| hogepodge | I want to preface the meeting with a reminder of the RefStack mission statement | 16:04 |
| hogepodge | #link http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n3583 | 16:04 |
| hogepodge | "RefStack is a test result collection and reporting service to support the DefCore interoperability testing process." | 16:04 |
| catherineD|2 | We agreed on the following: | 16:04 |
| catherineD|2 | hogepodge: thx | 16:04 |
| catherineD|2 | 1) RefStack needs to provide a mean to identify the test results that were used for certification. | 16:04 |
| catherineD|2 | 2) · The candidate test results could be anonymous or owned by creators/vendors. | 16:05 |
| catherineD|2 | 3) Those tests (that are marked as “used for certification”) are longer owned by creators/vendors, rather they are owned by the OSF (community). | 16:05 |
| catherineD|2 | done. Any feedback on what I just type? | 16:05 |
| hogepodge | s/are longer/are no longer/ | 16:06 |
| catherineD|2 | hogepodge: Oops yes .. thanks for the correction .. | 16:07 |
| sslypushenko | Maybe we should emphasize ownership... Just data used for certification should be keept unchanged | 16:07 |
| catherineD|2 | sslypushenko: not neccessary unchange.... OSF can decide to delete | 16:08 |
| alevine | catherineD: Yes. From what I've learned just now in the hogepodge's response in your review I see that some of the initial presumed use-cases in the design doc are completely wrong. So the world should be put to rights in that department first before I can suggest or reply something on current matters. | 16:08 |
| catherineD|2 | OSF can do anything to the data | 16:09 |
| sslypushenko | catherineD|2: it looks like not the best idea | 16:09 |
| hogepodge | alevine: can you please tell me where these presumptions are. I'm particularly frustrated that you don't seem to have engaged much on the DefCore front to understand what and why we're doing things. What are you hoping to accomplish with your contributions to RefStack if you don't have an understanding of the DefCore process? | 16:09 |
| catherineD|2 | sslypushenko: pls explain | 16:10 |
| alevine | catherineD: From what I've learned - everything is based on trust. So no automatically determined cloudID is available or required. No userID or cloudID can come with the test results. Because of that I'd like to understand how all of the management and association is to be done manually for all of the objects in the system. | 16:10 |
| alevine | hogepodge: In the design doc in the Use-Case section. I asked everybody, including defcore to review and agree on it before we started with the implementation. Catherine had reviewed and approved. Egle had come once and asked a couple of questions. | 16:11 |
| alevine | hogepodge: What I'm trying to achieve is to make RefStack better and along with that suitable for third-party products validation needs. | 16:12 |
| hogepodge | alevine: link please | 16:12 |
| catherineD|2 | alevine: everything based on trust is the best we can do at the moment ... we either do something with trust (and agree that sometimes trust has defeated us) or do nothing | 16:12 |
| hogepodge | alevine: it is not for third party product validation needs | 16:12 |
| alevine | https://docs.google.com/document/d/1s_dAIuluztlCC6AZ-WO4_FR2CLje1QyS6kbMxlFHaMk/edit# | 16:12 |
| hogepodge | alevine: I'm getting tired of repeating the mission statement of the project over and over | 16:12 |
| sslypushenko | catherineD|2: ownership is a tricky question, especially if it has business impact, like it is in our case. Idea of transfer of ownership is out of scope for Alex's document. I guess it is his major concern | 16:13 |
| catherineD|2 | alevine: we try to do the best we can do at the moment ... | 16:13 |
| alevine | hogepodge: Of course, that's why I said along with that.... if it's possible. I got impression that it might be possible. | 16:13 |
| hogepodge | alevine: Not at the expense of meeting the needs of DefCore | 16:13 |
| alevine | hogepodge: I might be wrong. But definitely first of all all of the defcore's needs should be fulfilled. That's unquestionable. | 16:14 |
| alevine | hogepodge: And usually to properly do this it's a good idea to first understand them. Which I don't yet apparently. So I'm trying to find some source of info to understand them. | 16:14 |
| catherineD|2 | sslypushenko: I disagree that because something is not in Alex's document then it is out of the scope .... if needed I can add it to the doc ... | 16:14 |
| alevine | catherineD: I don't mind depending on trust but you could've mentioned that when you reviewed the design doc, we should've changed that. | 16:15 |
| catherineD|2 | I want to remind the RefStack team that we should use blueprint and spec as our final implementation guidance | 16:15 |
| hogepodge | alevine: looking through that document, for example, there are many presumptions that fall outside of the scope of the project. | 16:16 |
| alevine | hogepodge: I'd be happy to remove them or if possible to tweak them to align with the project. | 16:16 |
| hogepodge | alevine: I'm also really bothered that it's not in a community approved review system. This is the sort of thing that absolutely needs to be in code review and on the mailing list | 16:16 |
| hogepodge | alevine: We can't halt work on this project for your own vendor-specific needs | 16:17 |
| catherineD|2 | alevine: I take the design doc as a working doc ... not as a hard core cast in stone doc | 16:17 |
| alevine | hogepodge: I agree. I exposed it and asked if there is any better place for it to be. I can copy-paste it in a spec if needed. | 16:17 |
| catherineD|2 | if you notice, most of our new feature implementation are preceding with blueprint or spec in addition to the google doc | 16:18 |
| sslypushenko | catherineD|2: hogepodge alevine My suggestion is to put on hold idea with ownership transfer. I guess that for now the major Defcore requirement - is a persistent links on test results. So, if all of us agreed with this statement, we can move on with implementation and continue with developing spec for ownership transfer | 16:19 |
| alevine | hogepodge: There should be some centralized place to define scenarios and use-cases I believe. And it's good to have some centralized place to put design based on that. Usually it's very hard to implement something without that. | 16:19 |
| hogepodge | sslypushenko: no, I absolutely want an interface to capture anonymous test results and make them foundation owned, at a minimum. | 16:20 |
| *** dwalleck has quit IRC | 16:20 | |
| catherineD|2 | alevine: I totally agree .. that is why I spent the amount of time I did on the google doc ... however, when it is time to implementation .. it needed to be open and review by all via blueprint or spec | 16:21 |
| sslypushenko | hogepodge I'm not talking about anonymous results. These results should be owned by OSF. | 16:21 |
| hogepodge | sslypushenko: not all, I don't want every single result to become my problem | 16:21 |
| hogepodge | sslypushenko: just the ones I care about | 16:21 |
| alevine | catherineD: I agree totally. But it turns out there are two problem: the central place for the requirements and for the doc is now improper; and the some presumptions in there are wrong. So we should do something about these two things first because they affect everything and implementation in particular. | 16:22 |
| catherineD|2 | sslypushenko: not all certified results were uploaded anoynously ... IBM resutls were not uploaded anonymously and many other company | 16:22 |
| hogepodge | alevine: You talk as if this document is an official spec of what refstack is doing. | 16:23 |
| alevine | hogepodge: In the absence of anything better it is now. I totally want to change it. I'd be happy to have it done by someone else but it is required. | 16:24 |
| hogepodge | alevine: catherineD|2 just said "I take the design doc as a working doc ... not as a hard core cast in stone doc" | 16:24 |
| catherineD|2 | alevine: again I want to emphasize that the google doc is a guidance working doc .... it brings tremendous values ... it should be updated as needed | 16:25 |
| alevine | hogepodge: "In the absence of anything better it is now". We need the one cast in stone. But with the same scope. | 16:25 |
| catherineD|2 | alevine: blueprint and spec is the official guidance doc | 16:26 |
| alevine | There should be an official place with an official requirements doc and an architectural doc for the global high-level architecture. It cannot be split up. | 16:26 |
| hogepodge | alevine: it ignores the defcore repository, previously existing design docs, and how the team has grown and been established. Showing up does not give you ownership of the direction. | 16:26 |
| *** dwalleck has joined #refstack | 16:26 | |
| alevine | catherineD: No blueprint or spec now reflects neither all non-conflicting and consise set of requirements, nor architecture of the system. | 16:27 |
| hogepodge | alevine: openstack is built on a spec and blueprint process to grow naturally | 16:27 |
| alevine | hogepodge: Of course not. And the doc I made is based on all of the existing sources of information and have links to them. None of them satisfies the needs unfortunately. | 16:28 |
| alevine | hogepodge: Then should be a blueprint or spec to reflect all of the requirements and blueprint or spec to define architecture IMO. | 16:28 |
| catherineD|2 | alevine: I don't mind if I need to update your doc ... but I do not want that to stop what we are doing here | 16:28 |
| alevine | catherineD: The problem with doing anything is that neither me nor Andrey really understand what to do because we see that it has many conflicts in the future and it won't work in some other cases. | 16:29 |
| catherineD|2 | alevine: I welcome such blueprint .. .but that should not stop what we are doing with the spirit of agile development | 16:29 |
| hogepodge | alevine: Exactly what catherine is saying. Development has halted for your needs, and it's been harmful to the project, both in terms of progress and morale. | 16:29 |
| hogepodge | alevine: In many instances I've clearly stated needs, and you seem to ignore them or be confused by them. I get tired of repeating myself. I get tired of repeating the mission statement. | 16:30 |
| alevine | hogepodge: I cannot agree with that. You can see that lots if not most of the development was done by Andrey Pavlov recently according to approved directions. | 16:30 |
| alevine | hogepodge: Sorry to "halt" the project but I just see that it has problems with requirements and I'm just trying us to understand them first. | 16:31 |
| catherineD|2 | alevine: I am greatful that andrey-mp: has join and he is a valuable addition to our team a long side with other development members .. please check the team contribution statistic here http://stackalytics.com/?release=all&metric=commits&project_type=openstack&module=refstack-group | 16:32 |
| alevine | ok. I understand that you people have clear picture and I don't. Then I guess I'll try to catch up. That's the best I can do. | 16:34 |
| catherineD|2 | alevine: I should not undermine the contribution of other members in the team | 16:34 |
| *** andrey-mp has quit IRC | 16:34 | |
| catherineD|2 | alevine: thank you! | 16:34 |
| catherineD|2 | Next move on to discuss product_id vs cloud_id and association to test results ... | 16:35 |
| catherineD|2 | Please take a look at https://docs.google.com/presentation/d/1btnlXcCoucjbmUNd18QoPK68UNuNLN9oFvUBWtYgATo/edit#slide=id.p | 16:36 |
| catherineD|2 | slide 5 show the current db tables in refstack | 16:37 |
| catherineD|2 | the box in blue is the only one with suggested updates | 16:37 |
| catherineD|2 | the rest of the tables were implemented before newton | 16:38 |
| catherineD|2 | let move on to slide 6 .. we will return to slide 5 later | 16:39 |
| catherineD|2 | slide 6 is a distro use case | 16:39 |
| catherineD|2 | here productA is a product in the distro page of the marketplace | 16:39 |
| catherineD|2 | it has a product id | 16:40 |
| sslypushenko | catherineD|2: hogepodge I guess we need input from Defcore here | 16:40 |
| catherineD|2 | does everyone understan what I want to describe here? | 16:41 |
| hogepodge | sslypushenko: what's the question? | 16:41 |
| sslypushenko | This question looks like out of scope for RefStack | 16:41 |
| catherineD|2 | my point here is we can not use cloudid to associate data to product ... we need to add a column product_id to store the product id in the test table | 16:42 |
| sslypushenko | Should be test results associated with product or cloud instance? | 16:42 |
| hogepodge | sslypushenko: On the marketplace side I have the notion of a product, and it can have multiple test results associate with it | 16:42 |
| hogepodge | sslypushenko: more specifically, my model is that one product can can many licenses (with only the latest active), and a license has to have a test result associated with it. That's my internal modeling, though. | 16:43 |
| catherineD|2 | sslypushenko: a test result is always associate to a cloud instance (we have that today the test table has a cpid column) .. that is done already | 16:44 |
| hogepodge | catherineD|2: that's true, a distro is usually tested against some sort of CI that is setting up and tearing down clouds with regularity | 16:44 |
| hogepodge | catherineD|2: even in the public/private cloud case, vendors often stand up a test cloud to guarantee customers aren't disrupted by testing, although we try to mitigate that by encouraging the use of non-admin guest accounts | 16:44 |
| catherineD|2 | catherineD|2: the question here is how do we associate the results to the product .. (as what hogepodge: has been manually done today ) | 16:45 |
| *** Rockyg has joined #refstack | 16:45 | |
| alevine | The products in the implementation right now are actually meant to reflect two different users registering the same cloud so there'll be two products with different Product_IDs for the same Cloud with CloudID=Product_Ref_ID. I'm not sure it fits into the model Catherine presented. | 16:45 |
| catherineD|2 | alevine: that is correct the in the product table there is a product_ref_id (clouidid) | 16:46 |
| catherineD|2 | but this relationship (product to cloud) is 1 - 1 | 16:46 |
| alevine | It doesn't correspond to your picture Catherine | 16:46 |
| hogepodge | alevine: I can see how the non-uniqueness impacts the model on both sides | 16:46 |
| catherineD|2 | it does | 16:46 |
| catherineD|2 | In the picture there is a broken line and there is a solid line from the product to the cloud | 16:47 |
| hogepodge | alevine: where you can have multiple product_ids that refer to the same actual product, and multiple cloud_ids that refer to the same product | 16:47 |
| alevine | There you showed one one Product with one Product_Ref_ID associated with two Clouds which actually have different Product_Ref_IDs (CloudIDs). I understand it's for distro though. | 16:47 |
| catherineD|2 | what I am trying to show is that you can only associate a product to one cloud at a time | 16:47 |
| catherineD|2 | alevine: maybe it does no show well but one line is solid and the other is broken line | 16:48 |
| alevine | hogepodge: It's not allowed by the design and implementation at the moment because idea was different. Product (many) to Cloud (one) or Distro (one). | 16:48 |
| alevine | hogepodge: And I don't mean that the implemented idea is right. | 16:48 |
| hogepodge | catherineD|2: that is the correct implementation. that might mean you would need a way to merge products or re-associate a cloud to a product. | 16:48 |
| alevine | hogepodge: I'm just saying that there is a conflict now as I understand. | 16:48 |
| catherineD|2 | hogepodge: that is why I suggest to add a product_id field to the test results table | 16:49 |
| hogepodge | catherineD|2: what's the difference between solid and broken? | 16:49 |
| hogepodge | catherineD|2: I think your intention is similar to what mine is, at a given time only one result is the official result, but there may be historically relevant results and those should be preserved? | 16:50 |
| catherineD|2 | solid mean it is currently associated (the cloudid2 id is updated in tje product_ref_id of the product) ... broken means previously associated but no longer currently | 16:50 |
| catherineD|2 | hogepodge: yes | 16:51 |
| alevine | catherineD: Association between Product and Cloud?? | 16:51 |
| alevine | catherineD: Got reassociated? | 16:51 |
| catherineD|2 | yes if needed ... as said in 2015 , you stand up a cloud for your test ... that would have one cloudid | 16:52 |
| hogepodge | alevine: My understanding is that there is a one to many association between product_id and cloud_id, and that the cloud_id has a test result associated with it that is official | 16:52 |
| catherineD|2 | in 2016 you stand uo an other cloud .. that would have a different cloud id | 16:52 |
| alevine | Just to remind, currently Cloud IS Product. There is no association between them. | 16:52 |
| hogepodge | (that is, one product can have many clouds associated with it) | 16:53 |
| alevine | hogepodge: Right now it's exactly the opposite. One to many between cloud_id and product_id. | 16:53 |
| catherineD|2 | hogepodge: correct ... therefore to associate a single test result (the one that is certified) to a product we add the product_id to the test result as I suggested in the spec | 16:53 |
| alevine | hogepodge: Because cloud IS product. Product is just a user-registered facade of the particular Cloud in RefStack. | 16:53 |
| Rockyg | I suspect it is really many when you take in versions of cloud or product | 16:54 |
| Rockyg | many to many that is | 16:54 |
| catherineD|2 | Rockyg: he | 16:54 |
| catherineD|2 | he --> hi | 16:54 |
| Rockyg | hey. got the time wrong..... | 16:54 |
| *** andrey-mp has joined #refstack | 16:55 | |
| alevine | Also Product is a facade of a particular Distro. Because Distro IS also a Product. | 16:55 |
| Rockyg | for instanc, would th cloud id change when the cloud owndr upgrades to a new version? | 16:55 |
| catherineD|2 | hogepodge: we need to clearly associate (indicate) which test result (among the many results) tested against a cloud that you want to associate to a product (for certification) | 16:55 |
| Rockyg | sorry. ee key acting up | 16:55 |
| alevine | What CatherineD tries to depict maybe association of two different entities - Distro and Cloud. But we don't have it right now and it better not be confused with existing IS relation of Product and Cloud/Distro. | 16:56 |
| hogepodge | Is there space to start more simply? | 16:56 |
| hogepodge | Begin by saying "this result is special and can not be deleted, and is now owned by OSF" | 16:57 |
| Rockyg | so, a cloud is an instance of a product (object?) | 16:57 |
| hogepodge | The work with associating that result to cloud and product. | 16:57 |
| alevine | A Product is an instance of a Cloud. | 16:57 |
| alevine | Oops, sorry. That's not true. | 16:57 |
| hogepodge | I have qa meeting in two minutes | 16:58 |
| Rockyg | uh, multiple cloud owner deploy their clouds using a distro. each cloud is an instance of that distro, but very diffrnt. | 16:58 |
| catherineD|2 | what I try to say is we need to associate the test to product with relationship 2 (1 -1 relationship from product to test ) ... I just add 2 now (did not want to add that earlier since this is the siggestion) | 16:58 |
| alevine | Product can be either a Cloud or a Distro. And in the Product table right now a Product record reflects user registered instance of particular Cloud or Distro. | 16:58 |
| catherineD|2 | can everyone take a look at slide 6 and 7 | 16:59 |
| catherineD|2 | hogepodge: thank you .. | 16:59 |
| hogepodge | catherineD|2: I'd discourage the differentiation between cloud and distro | 16:59 |
| Rockyg | Ah. I hat overloading of terms. Makes communication much less clar. | 16:59 |
| Rockyg | hat>>hate | 17:00 |
| hogepodge | catherineD|2: it makes the distinction between slides 6 and 7 messy imo | 17:00 |
| Rockyg | post the link again, please? | 17:00 |
| alevine | Rockyg: Maybe you're right, there should've been another table for user-created instance of particular product. | 17:00 |
| catherineD|2 | Rockyg: https://docs.google.com/presentation/d/1btnlXcCoucjbmUNd18QoPK68UNuNLN9oFvUBWtYgATo/edit#slide=id.g153c0f8180_0_0 | 17:01 |
| catherineD|2 | slide 6 and 7 | 17:01 |
| catherineD|2 | hogepodge: I am trying to depict is that if we use a product_id field in the test table .. it works in all case distro or cloud | 17:02 |
| catherineD|2 | but if we use cloudid to associate test results to product it only works for public cloud (that is if the public cloud is the official one not the test cloud) | 17:03 |
| hogepodge | catherineD|2: ok, thanks | 17:03 |
| catherineD|2 | so we have a solution that works for all casess and I want to explain that | 17:04 |
| catherineD|2 | Let's end this meeting ... everyone please review slide 6 and 7 ... pls post question here .. | 17:07 |
| Rockyg | will do. | 17:07 |
| catherineD|2 | I will put this as a topic for next week IRC meeting | 17:07 |
| catherineD|2 | alevine: andrey-mp: pvaneck: hogepodge: Rockyg: thank you very much for attending the meeting!!! | 17:09 |
| alevine | catherineD: Here you mean in the channel? | 17:09 |
| Rockyg | sorry I was late | 17:09 |
| *** alevine has quit IRC | 17:14 | |
| *** andrey-mp has quit IRC | 17:19 | |
| *** dwalleck has quit IRC | 17:39 | |
| catherineD|2 | alevine: yes in the #refstack channel | 17:48 |
| *** andrey-mp has joined #refstack | 17:55 | |
| *** dwalleck has joined #refstack | 18:04 | |
| *** pvaneck has quit IRC | 18:06 | |
| *** dwalleck has quit IRC | 18:12 | |
| *** Rockyg has quit IRC | 18:14 | |
| *** dwalleck has joined #refstack | 18:27 | |
| *** pvaneck has joined #refstack | 18:42 | |
| *** andrey-mp has quit IRC | 21:31 | |
| *** dwalleck has quit IRC | 21:38 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!