| *** markvoelker has joined #refstack | 00:11 | |
| *** pvaneck has quit IRC | 00:27 | |
| *** Deng has joined #refstack | 00:46 | |
| *** edmondsw has quit IRC | 01:04 | |
| *** andrey-mp has joined #refstack | 06:16 | |
| *** rmart04 has joined #refstack | 06:50 | |
| *** rmart04 has quit IRC | 06:56 | |
| *** andrey-mp has quit IRC | 07:07 | |
| *** rmart04 has joined #refstack | 07:28 | |
| *** markvoelker has quit IRC | 07:59 | |
| *** markvoelker has joined #refstack | 09:00 | |
| *** markvoelker has quit IRC | 09:05 | |
| *** andrey-mp has joined #refstack | 09:33 | |
| *** markvoelker has joined #refstack | 10:01 | |
| *** markvoelker has quit IRC | 10:05 | |
| *** markvoelker has joined #refstack | 11:02 | |
| *** markvoelker has quit IRC | 11:06 | |
| *** markvoelker has joined #refstack | 12:02 | |
| *** markvoelker has quit IRC | 12:07 | |
| *** markvoelker has joined #refstack | 12:23 | |
| *** edmondsw has joined #refstack | 13:19 | |
| *** andrey-mp has quit IRC | 14:21 | |
| *** rmart04 has quit IRC | 15:32 | |
| *** rmart04 has joined #refstack | 15:34 | |
| *** andrey-mp has joined #refstack | 17:37 | |
| *** dwalleck has joined #refstack | 17:56 | |
| *** dwalleck has quit IRC | 18:00 | |
| *** pvaneck has joined #refstack | 18:02 | |
| *** dwalleck has joined #refstack | 19:04 | |
| *** dwalleck has quit IRC | 19:55 | |
| catherineD | on slide 6 | 20:00 |
|---|---|---|
| catherineD | andrey-mp: slide 6 shows the use case flow | 20:02 |
| catherineD | what I suggest us to do is on slide 7 | 20:02 |
| catherineD | I suggest for us to create a version table (to model the 1 to 0 ..n relationship) | 20:02 |
| andrey-mp | on slide 7 - why relation version-test is not similar to other relations? what it mean? | 20:02 |
| catherineD | can you give me example of which other relationship you refer to? | 20:03 |
| *** dwalleck has joined #refstack | 20:03 | |
| andrey-mp | on this slide 7 - product-version and test-results | 20:04 |
| catherineD | the relation ship of product to version is like the relationship of vendor to product | 20:04 |
| andrey-mp | table 'version' is just a second normal form for products | 20:04 |
| andrey-mp | they have different arrows ) | 20:05 |
| catherineD | sure so you put the uuid of version to the test | 20:05 |
| catherineD | ic let me try to explain | 20:05 |
| catherineD | a product_vestion can have zero to namy test | 20:06 |
| andrey-mp | i just want to understand why arrows are different | 20:06 |
| catherineD | a test can have o or at most 1 product_version associated to it | 20:06 |
| catherineD | andrey-mp: np | 20:06 |
| andrey-mp | ok. 1-to-N and 0-to-N | 20:06 |
| andrey-mp | so I don't have questions right now | 20:07 |
| catherineD | a product can have 1 to many version (I know the bussiness model dictate no version for public cloud but for refstack we will define it as must have 1... and the vesion name can be blank | 20:07 |
| *** dwalleck has quit IRC | 20:08 | |
| catherineD | sorry this is Entity relationship symbols which are mostly used to model database | 20:08 |
| catherineD | where as UML is mostly used for object modeling etc | 20:09 |
| catherineD | the only thing that is not model in here is the relationship between product_version to a deployed cloud which is used to test | 20:10 |
| sslypushenko | catherineD: btw... what do you want to achieve with cloud versioning? | 20:14 |
| catherineD | To display the additional parameters in the result page .. | 20:14 |
| sslypushenko | because technically it will be really hard to define what is new version of cloud | 20:15 |
| catherineD | soryy | 20:15 |
| catherineD | wrong answer | 20:15 |
| catherineD | let me describe | 20:15 |
| sslypushenko | so... we have to think more then twice before put our efforts in direction | 20:16 |
| catherineD | look at this product https://www.openstack.org/marketplace/distros/distribution/mirantis/mirantis-unlocked-appliances | 20:16 |
| catherineD | it is tested with guideline 2015.04 ... but we have no idea what is the version of the product itself | 20:17 |
| sslypushenko | pretty good example, I'd say) | 20:17 |
| catherineD | I raise that question in the midcycle ... and the foundation think that they will add version of the product to this page | 20:18 |
| catherineD | since the product name is always "Mirantis Unlocked Appliances " just the version is different | 20:19 |
| sslypushenko | the issue you want to address is more or less clear... BUT! it requires a definition of term 'version' | 20:19 |
| catherineD | It would be product version or what ever discription that product used to differenticate | 20:20 |
| catherineD | I believe you have version ...6, 7 .. and 9 now? | 20:20 |
| sslypushenko | we have a versions for Fuel | 20:20 |
| catherineD | for IBM Bluebox have version 4.2 ... | 20:20 |
| sslypushenko | but real clouds are different | 20:21 |
| catherineD | that is why they say real cloud have no version right? | 20:21 |
| sslypushenko | each deployment is different | 20:21 |
| catherineD | sure | 20:21 |
| sslypushenko | I know it, because I'm sitting next to our L2 support engineers))) | 20:22 |
| andrey-mp | ssplypushenko: i think about 'common' deployment with this product. or in other words - 'the such cloud can be built with product' | 20:22 |
| catherineD | so for use a unique product is a comnation of product+version ... there will be an entry in the product table and 1 in the version table ... for the product that ahve no version we still ahve an entry in the version table but the name will be blank | 20:22 |
| andrey-mp | ups, sorry for mistake in name | 20:23 |
| sslypushenko | if we don't have our strong opinion on version term, it will leads to the situation when each deployed cloud will have a unique version) | 20:23 |
| andrey-mp | several weeks ago I've asked about products' versions | 20:23 |
| andrey-mp | like MOS 6.1, 7, 8, 9, ... | 20:24 |
| catherineD | sslypushenko: that means each deployed cloud will be a product | 20:24 |
| sslypushenko | andrey-mp: np) try irccloud.com ;) | 20:24 |
| andrey-mp | i'm using nettalk now ) | 20:24 |
| catherineD | andrey-mp: absolutely you are the one who brought this to the attention ... I asked DefCore in the midcycle | 20:24 |
| sslypushenko | catherineD: it will be perfect) but Defcore wants to have Distro type of product | 20:25 |
| sslypushenko | and Appliances... ( | 20:25 |
| catherineD | sslypushenko: the model hould work with distro too | 20:25 |
| andrey-mp | let's treat a cloud as a 'maximum' deployment of the product - when L2 is correct, baremetal is very good | 20:25 |
| sslypushenko | no... it wont... | 20:25 |
| catherineD | look at slide 6 | 20:25 |
| catherineD | sslypushenko: reason? | 20:26 |
| sslypushenko | in reality there are tons of way how to deploy Distro | 20:26 |
| sslypushenko | *ways | 20:26 |
| catherineD | sslypushenko: absolutely | 20:27 |
| catherineD | but the validation is only from the vendor | 20:27 |
| catherineD | it is up to the vendor to define what is a product to them | 20:27 |
| sslypushenko | in this case it will be useless | 20:28 |
| catherineD | for the distro Mirantis define that Mirantis Unlocked Appliances is a product | 20:28 |
| catherineD | useless for who what? | 20:28 |
| sslypushenko | if vendor will validate Distro and then use deploy Distro and get cloud which does not meats user's expectations | 20:29 |
| sslypushenko | bases on validation summary | 20:29 |
| catherineD | to me a product with default deployment pattern is what being validated ... but that is just my opinion | 20:29 |
| catherineD | sslypushenko: then the users will be the one who complain to the vendor | 20:30 |
| catherineD | it is up to whatever standard&reference implementation that the venmdor should test ... | 20:30 |
| sslypushenko | it will not make our life easier) | 20:30 |
| catherineD | sslypushenko: that I agree :-) | 20:31 |
| catherineD | but we need to model the DefCore and Foundation usecase ... that is to support the marketplace | 20:31 |
| catherineD | on this page ... Chris want to replace the "see full results" link to a link of test result at the RefStack site | 20:32 |
| sslypushenko | Personally, I more or less understand usecases with deployed clouds... But Distro... it still hard | 20:33 |
| catherineD | yea .. agree distro implies many deployment options ... | 20:34 |
| sslypushenko | catherineD: >> we need to model the DefCore and Foundation usecase ...<< Exactly!!! That is what I want to see from Defcore | 20:34 |
| sslypushenko | Defcore/Fondation Usecases | 20:34 |
| sslypushenko | described in spec | 20:34 |
| catherineD | I describe that on slide 6 and Chris typed it on our meeting .. .I will extract it | 20:35 |
| sslypushenko | with terms definitions | 20:35 |
| andrey-mp | (as I remember they don't like slides/documents out of specs folder) | 20:35 |
| sslypushenko | nooope, it wont work in this way) It too questionable) | 20:36 |
| catherineD | no they don't ...and I don't ... as I said earlier I will put all of this in a spec | 20:36 |
| sslypushenko | Great) then we can continue our discussion in review on this spec | 20:37 |
| catherineD | this type of info were the target for the Mitaka cycle ... we missed it ... I really would like it to happen in Newton | 20:37 |
| catherineD | ok will do .. | 20:37 |
| sslypushenko | basically, suggested workflow can work... but there are to many details needs to be discussed to make it work | 20:38 |
| catherineD | Paul pretty much has all the code ...when he worked on the prototype | 20:38 |
| catherineD | let me submit a patch and we can go from there ... | 20:38 |
| sslypushenko | catherineD: np) prototype looks good | 20:39 |
| catherineD | sslypushenko: andrey-mp: as always thank you so much .... your inputs are very valuable for the success of this project ... we all expect differences but that is what make a good project | 20:40 |
| catherineD | bye now | 20:40 |
| andrey-mp | if spec will be ready - then we need one-two weeks for implement. spec is a main trouble | 20:40 |
| andrey-mp | bye | 20:40 |
| sslypushenko | catherineD: Thank you | 20:41 |
| sslypushenko | bye | 20:41 |
| *** andrey-mp has quit IRC | 21:10 | |
| *** Deng has quit IRC | 21:30 | |
| *** designbybeck_ has quit IRC | 21:52 | |
| *** dwalleck has joined #refstack | 22:05 | |
| *** davidlenwell has quit IRC | 22:25 | |
| *** edmondsw has quit IRC | 22:36 | |
| *** davidlenwell has joined #refstack | 22:38 | |
| *** ChanServ sets mode: +o davidlenwell | 22:38 | |
| *** dwalleck has quit IRC | 22:51 | |
| openstackgerrit | Paul Van Eck proposed openstack/refstack: Restrict test result metadata keys https://review.openstack.org/348581 | 23:18 |
| hogepodge | sslypushenko: the whole discussion on distros happened last year. The conclusion reached was that a distribution must be configurable to be OpenStack Powered, but that it is not possible to enforce that in the field. So a vendor only need demonstrate the test results against a 'correctly' configured product | 23:38 |
| hogepodge | we can't stop someone who purchases it from misconfiguring it, but the Powered logo assures the end operator that it can be deployed to be interoperable | 23:48 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!