| *** hogepodge has joined #refstack | 01:34 | |
| *** hogepodge has quit IRC | 01:38 | |
| *** markvoelker has joined #refstack | 01:42 | |
| *** markvoelker has quit IRC | 01:46 | |
| *** Deng has joined #refstack | 03:20 | |
| *** markvoelker has joined #refstack | 03:43 | |
| *** markvoelker has quit IRC | 03:47 | |
| *** coolsvap|away is now known as coolsvap | 05:19 | |
| *** markvoelker has joined #refstack | 05:44 | |
| *** markvoelker has quit IRC | 05:48 | |
| *** pilgrimstack has quit IRC | 06:40 | |
| *** davidlenwell has quit IRC | 07:00 | |
| *** davidlenwell has joined #refstack | 07:02 | |
| *** ChanServ sets mode: +o davidlenwell | 07:02 | |
| *** davidlenwell has quit IRC | 07:24 | |
| *** coolsvap is now known as coolsvap|away | 07:25 | |
| *** davidlenwell has joined #refstack | 07:26 | |
| *** ChanServ sets mode: +o davidlenwell | 07:26 | |
| *** davidlenwell has quit IRC | 07:29 | |
| *** davidlenwell has joined #refstack | 07:33 | |
| *** ChanServ sets mode: +o davidlenwell | 07:33 | |
| *** davidlenwell has quit IRC | 07:41 | |
| *** markvoelker has joined #refstack | 07:44 | |
| *** davidlenwell has joined #refstack | 07:45 | |
| *** ChanServ sets mode: +o davidlenwell | 07:45 | |
| *** markvoelker has quit IRC | 07:49 | |
| *** coolsvap|away is now known as coolsvap | 08:16 | |
| *** markvoelker has joined #refstack | 09:45 | |
| *** markvoelker has quit IRC | 09:50 | |
| *** Deng has quit IRC | 11:13 | |
| *** markvoelker has joined #refstack | 11:46 | |
| *** markvoelker has quit IRC | 11:51 | |
| *** hogepodge has joined #refstack | 12:27 | |
| *** hogepodge has quit IRC | 12:32 | |
| *** pilgrimstack has joined #refstack | 12:56 | |
| *** markvoelker has joined #refstack | 13:16 | |
| *** edmondsw has joined #refstack | 13:32 | |
| *** coolsvap is now known as coolsvap|away | 13:51 | |
| *** resker has quit IRC | 14:05 | |
| *** esker has joined #refstack | 14:05 | |
| *** esker has quit IRC | 14:05 | |
| *** esker has joined #refstack | 14:24 | |
| *** hogepodge has joined #refstack | 14:28 | |
| *** esker has quit IRC | 14:29 | |
| *** hogepodge has quit IRC | 14:33 | |
| *** hogepodge has joined #refstack | 14:34 | |
| *** pilgrimstack has quit IRC | 15:12 | |
| *** pilgrimstack has joined #refstack | 15:14 | |
| *** pilgrimstack has quit IRC | 15:19 | |
| *** pilgrimstack has joined #refstack | 15:23 | |
| *** markvoelker_ has joined #refstack | 16:01 | |
| *** markvoelker has quit IRC | 16:02 | |
| *** markvoelker has joined #refstack | 16:05 | |
| *** esker has joined #refstack | 16:06 | |
| *** markvoelker_ has quit IRC | 16:07 | |
| *** esker has quit IRC | 16:07 | |
| *** esker has joined #refstack | 16:07 | |
| *** pilgrimstack has quit IRC | 16:38 | |
| *** pilgrimstack has joined #refstack | 16:46 | |
| *** catherineD has joined #refstack | 16:49 | |
| openstackgerrit | Merged openstack/refstack: Specification to add user/group support in RefStack https://review.openstack.org/269893 | 16:50 |
|---|---|---|
| openstackgerrit | Merged openstack/refstack: Create group table. https://review.openstack.org/268929 | 17:08 |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Implement organization and product tables https://review.openstack.org/269066 | 17:19 |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: WIP: add vendors and products UI https://review.openstack.org/272188 | 17:19 |
| *** andrey-mp has joined #refstack | 17:21 | |
| *** pilgrimstack has quit IRC | 17:23 | |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Implement organization and product tables https://review.openstack.org/269066 | 17:26 |
| *** pvaneck has joined #refstack | 18:41 | |
| *** alexandrelevine has joined #refstack | 18:54 | |
| openstackgerrit | Catherine Diep proposed openstack/refstack: Fix broken links. https://review.openstack.org/272224 | 18:55 |
| *** openstackgerrit has quit IRC | 19:02 | |
| *** openstackgerrit has joined #refstack | 19:03 | |
| catherineD | Hello everyone, Please join RefStack IRC meeting at #openstack-meeting-3 going on now .... | 19:05 |
| *** andrey-mp has quit IRC | 19:05 | |
| *** andrey-mp has joined #refstack | 19:05 | |
| *** pvaneck_ has joined #refstack | 19:07 | |
| *** pvaneck has quit IRC | 19:10 | |
| catherineD | sorry meeting is at #openstack-meeting-alt | 19:11 |
| *** andrey-mp has quit IRC | 19:12 | |
| *** andrey-mp has joined #refstack | 19:12 | |
| *** pvaneck has joined #refstack | 19:21 | |
| *** pvaneck_ has quit IRC | 19:24 | |
| alexandrelevine | o/ | 20:00 |
| andrey-mp | . | 20:00 |
| alexandrelevine | catherineD: Please let me know, when do I start the explanation | 20:01 |
| catherineD | I am here ... thx | 20:01 |
| sslypushenko | I need to go... Will check your discussion later) | 20:01 |
| catherineD | sslypushenko: thx ... please check the log and let us know if you have concern ... | 20:02 |
| *** rockyg has joined #refstack | 20:02 | |
| rockyg | o/ | 20:02 |
| catherineD | alexandrelevine: andrey-mp: let me phrase the question ? what would be store in the product_id field for 1) a Software Product 2) a cloud | 20:03 |
| catherineD | rockyg: thank you for joining us ... I am sorry that we keep needed overtime ... | 20:03 |
| alexandrelevine | 1) Some GUID, or URL. We haven't decided yet for the Software. If we decide that the name should be unique anll have to decide what this isd unchangeable it can be the name duplicated there. Three should be a unique id for each Software. We' | 20:04 |
| alexandrelevine | We'll have to decide what this is | 20:04 |
| alexandrelevine | 2) cpid for OpenStack cloud; most probably "http://www.aws.com" for Amazon; "http://www.gce.com" for Google, etc (I might be mistaken in exact urls) | 20:05 |
| rockyg | catherineD, not a problem ;-) I'm finally getting back into my projects, so I need to catch up anyway. | 20:06 |
| catherineD | so different types of data can be stored in this field ... do we care ? | 20:06 |
| alexandrelevine | catherineD: So you don't need the question how Software Product is associated with Cloud answered? | 20:06 |
| catherineD | alexandrelevine: I do but I want to ask the question in a different way so you can see my point | 20:07 |
| alexandrelevine | catherineD: It's Unique Identifier of String format. That's all we should know about it in terms of its nature. | 20:07 |
| alexandrelevine | We have various Clouds and Software Products as Products. We'll store them in Product table. Each of them should have a unique id. That's that. | 20:08 |
| catherineD | so right now we have the ID field (which is UUID), we have name (which may not be unique because of mix cases) ... is that enough to identify a cloud .. why do we need an other ID namely Product_ID | 20:09 |
| catherineD | alexandrelevine: each of the record would have a UUD is that not enough for product uniqueness? | 20:10 |
| alexandrelevine | Again. ID which is UUID is not a place we'll store cpid for OpenStack cloud, correct? | 20:10 |
| catherineD | alexandrelevine: then we go back to the question that the product_id will stor CPID? | 20:10 |
| alexandrelevine | What's absent in this table, actually, is the "type" field, which will state what's that - Software Product or a Cloud | 20:10 |
| catherineD | why don't we name it CPID? | 20:11 |
| alexandrelevine | catherineD: If product_id stores CPID then it'll store all of the other Product IDs. What I'm saying is that I don't really care where unique ID is store, it's just it should be stored in the same place for all of the Products. | 20:11 |
| catherineD | alexandrelevine: let's explore the 'type' filed idea ... | 20:11 |
| alexandrelevine | catherineD: Such a unique ID for OpenStack Cloud is cpid in the moment. So wherever it's stored in the table - Software Product ID and Public Cloud ID should be stored in this same field | 20:12 |
| alexandrelevine | catherineD: "type" would be required to select Clouds out of Products, for example. | 20:13 |
| catherineD | is the field ID (UUID) not enough? | 20:13 |
| alexandrelevine | catherineD: Will it store cpid? | 20:13 |
| alexandrelevine | catherineD: Is it suitable for storing URLs? | 20:13 |
| catherineD | no it is RefStack generated UUID | 20:14 |
| alexandrelevine | catherineD: Then it doesn't satisfy my statement that the unique id field should store cpid and other unique ids. No, uuid cannot be used then. | 20:14 |
| alexandrelevine | catherineD: Maybe I'm missing your point, or something? | 20:15 |
| alexandrelevine | catherineD: I don't quite understand the problem again :) | 20:15 |
| catherineD | alexandrelevine: ok so you need a field which is user input and unique? | 20:15 |
| alexandrelevine | catherineD: I didn't say anything about "user input" | 20:16 |
| catherineD | how do you get the content of this field? | 20:16 |
| alexandrelevine | catherineD: No, I'd rather hope that it's an automatically determined unique id. You can't rely on user input in the case. | 20:16 |
| alexandrelevine | catherineD: How do you get cpid? | 20:17 |
| alexandrelevine | catherineD: That's how | 20:17 |
| catherineD | cpid -> refstack generate the cpid base on user input url ... it is still a user input .. we can not guarantee the uniqueness | 20:18 |
| alexandrelevine | catherineD: I had a different understanding. That it's automatically determined by means of querying keystone or its urls. Isn't it? | 20:18 |
| alexandrelevine | catherineD: Please read the section CloudID in the Requirements doc. | 20:19 |
| alexandrelevine | catherineD: It's important that everything is determined automatically. Otherwise we can't trust it. | 20:19 |
| catherineD | alexandrelevine: yes and no ... yes because it is taken from tempest config (so it must ve valid or we can not run test) .. no because it is not from keystone | 20:20 |
| catherineD | alexandrelevine: I think we get the point I want to discuss that is what is this field ... what is it for Clouds , Software Product | 20:21 |
| alexandrelevine | catherineD: Ok, isn't cpid the hashed keystone endpoint? | 20:21 |
| catherineD | alexandrelevine: it is a keystone endpoint input by the user in the form of tempest.conf | 20:21 |
| catherineD | it is still a user input but it must be valid | 20:22 |
| catherineD | however, we can not guarantee uniqueness .. | 20:22 |
| alexandrelevine | catherineD: Correct, however, it is verified by us going there and communicating and authenticating with that keystone. So it's good and can be trusted. | 20:22 |
| catherineD | alexandrelevine: correct ... | 20:23 |
| alexandrelevine | catherineD: What do you mean we can't? | 20:23 |
| catherineD | because when testing on-premis ... you can build a cloud with https://192.168.56.1:5000/v2.0 and I can use the same URL too .. | 20:24 |
| catherineD | on-premise | 20:24 |
| catherineD | those are private IP that anyone can use | 20:25 |
| *** alexandrelevine_ has joined #refstack | 20:25 | |
| catherineD | however the URL of the publicly accessible cloud would be unique ... | 20:25 |
| alexandrelevine_ | Sorry. Got kicked out. | 20:25 |
| alexandrelevine_ | Ok. So, even if you reinstall devstack on the same machine you'll get different keystone enpoints, right? | 20:26 |
| catherineD | yes | 20:26 |
| catherineD | depending on how you want to config it ... that is what ip you want to use | 20:26 |
| alexandrelevine_ | ip is the same | 20:27 |
| catherineD | in devstack it is | 20:27 |
| catherineD | but if I build a cloud .. I will have to define what ip to use for my cloud .. | 20:27 |
| *** alexandrelevine has quit IRC | 20:27 | |
| alexandrelevine_ | And? | 20:28 |
| catherineD | one identical URL can be used by more than one clouds | 20:28 |
| alexandrelevine_ | How is this possible? Give me an example. | 20:29 |
| catherineD | in my private VLAN , I build a cloud using URL https://192.168.56.1:5000/v2.0 as my keystone URL .... in Huawei, rockyg: could build a cloud using the same url ... | 20:30 |
| catherineD | potentially , we both can send data up to RefStack with identical URL ... | 20:31 |
| alexandrelevine_ | You're welcome to have your private clouds but you won't be able to register them as Products in central RefStack in this case. | 20:31 |
| catherineD | Rocky and I won't have IP conflict because we both operating in our private VLAN | 20:32 |
| alexandrelevine_ | You will. In RefStack | 20:32 |
| catherineD | we allow user to upload data today ... there is no where that we enforce that all URLs are unique | 20:33 |
| alexandrelevine_ | Or we'll have to use GUIDs of Keystone if any such exists to uniquelly identify cloud. | 20:33 |
| alexandrelevine_ | That's the problem of current design. | 20:34 |
| catherineD | alexandrelevine_: you won't be able to get keystone id from public cloud | 20:34 |
| alexandrelevine_ | Unless we guarantee uniqueness and automatic differentiation of your two clouds we can't allow you to upload or register nothing more than test results which are now not associated with any product - they hang in the air. | 20:34 |
| alexandrelevine_ | catherineD: I'll deal with the non-OpenStack clouds, no problem. We know how. | 20:35 |
| catherineD | catherineD: most of public clouds requires admin credential for that | 20:35 |
| alexandrelevine_ | catherineD: Or are you talking about public OpenStack clouds? | 20:35 |
| catherineD | I am talking about OpenStack public cloud .. | 20:36 |
| alexandrelevine_ | Very good then. It means that legit results can come from a user with admin creds only. | 20:36 |
| alexandrelevine_ | There is no way you can do it otherwise. | 20:36 |
| catherineD | alexandrelevine_: yea that is why the URL is used ... | 20:36 |
| alexandrelevine_ | You need to correctly identify the cloud being tested. | 20:36 |
| alexandrelevine_ | catherineD: Url is not sufficient. | 20:37 |
| catherineD | back to our question .. | 20:37 |
| catherineD | if you still want to keep the product_id field .. | 20:37 |
| alexandrelevine_ | Anyways. There is the following constraint that should be satisfied: The cloud ID should be globally unique and automatically determined (from tempest config or from the cloud itself)l | 20:38 |
| alexandrelevine_ | catherineD: Product_ID is just a place to store. | 20:38 |
| alexandrelevine_ | catherineD: What I need is a uniquely defined ID. | 20:38 |
| alexandrelevine_ | Forget about Product ID field. We can name it however we want. Forget about the DB. Let's decide upon the concept. Each Product should be correctly identified. How do we do it? | 20:39 |
| catherineD | from our system it would be UUID | 20:40 |
| alexandrelevine_ | Where does it come from? | 20:40 |
| catherineD | the next thing is and ID based on URL | 20:40 |
| catherineD | the URL will guarantee to be unique in a cloud registerd for centralized test | 20:41 |
| alexandrelevine_ | It's not good enough. | 20:42 |
| catherineD | centralized test means RefStack initiates the test ... therefore the URL have to be unique | 20:42 |
| rockyg | catherineD, no clue about how huawei works their products. They don't communicate about products with our R&D | 20:42 |
| alexandrelevine_ | I don't make difference between centralized or local testing. There should be no difference in fact. | 20:42 |
| alexandrelevine_ | Where does UUID come from? | 20:43 |
| catherineD | alexandrelevine_: you understand I I raise the question ... we can keep the field but we just know what to store in it and how we use it .. | 20:43 |
| catherineD | UUID is generated automatically | 20:43 |
| catherineD | we can check which python lib we are using ... but it is guaranteed to be unique | 20:44 |
| alexandrelevine_ | catherineD: Where does UUID come from? | 20:44 |
| alexandrelevine_ | catherineD: Is RefStack generating it? Is it in any way connected to the Cloud at all? | 20:45 |
| catherineD | yes RefStack generated UUID ... | 20:45 |
| alexandrelevine_ | catherineD: It's not connected to the Cloud at all, correct? | 20:45 |
| catherineD | you can not connect to the cloud with it ... | 20:45 |
| alexandrelevine_ | catherineD: Perfect. Then it doesn't help us, we as well can drop it. | 20:46 |
| alexandrelevine_ | catherineD: So we need to define a unique ID which IS connected to Cloud. | 20:46 |
| alexandrelevine_ | catherineD: It can be the URL, however it'll mean that no private Clouds with the same URLs will be registered in the RefStack. | 20:47 |
| catherineD | it does not help to connect to a cloud but it is a unique field to identify a row in a db | 20:47 |
| alexandrelevine_ | catherineD: I understand. That's what I thought. Now, let's try to forget about the DB altogether and think about the concept. | 20:47 |
| catherineD | we can not drop the ID field it is also our primary key | 20:47 |
| alexandrelevine_ | catherineD: Ok, ok. Let's suppose we drop the DB and use big JSON to store everything. Let's not rely on the storage layer. We need to understand how it works in the Object Model. | 20:49 |
| catherineD | I have a meeting in 12 mins ... we can keep this field in there ... I just want us to have some thouights about the issue | 20:49 |
| catherineD | alexandrelevine_: that would be a bigger issue to drop the database .. | 20:49 |
| alexandrelevine_ | catherineD: Please reread the CloudID section in the Reqs doc and let me know when we can talk about it more. | 20:49 |
| catherineD | I don't think it is realistic | 20:50 |
| catherineD | ok .. | 20:50 |
| alexandrelevine_ | catherineD: I'm not talking to drop it for real. I'm saying we should think independently of storage layer. | 20:50 |
| catherineD | alexandrelevine_: sure ... sorry I have to go ..... thank you very very much!!!! | 20:51 |
| alexandrelevine_ | Thank you. Bye. | 20:51 |
| catherineD | rockyg: thx! | 20:51 |
| catherineD | andrey-mp: thx | 20:51 |
| andrey-mp | bye! | 20:52 |
| *** andrey-mp has quit IRC | 20:52 | |
| *** alexandrelevine_ has quit IRC | 20:52 | |
| rockyg | Hey, guys! don't know if any of you ar still around. So, I get what is being said ...If implementation is changed, how would you implement the concept....but, I'll take this offline with Catherine. | 20:57 |
| *** davidlenwell has quit IRC | 21:16 | |
| *** davidlenwell has joined #refstack | 21:18 | |
| *** ChanServ sets mode: +o davidlenwell | 21:18 | |
| * rockyg waves to davidlenwell! | 21:40 | |
| *** davidlenwell has quit IRC | 21:55 | |
| *** davidlenwell has joined #refstack | 21:56 | |
| *** ChanServ sets mode: +o davidlenwell | 21:56 | |
| davidlenwell | hi rockyg | 22:12 |
| rockyg | How's life? | 22:12 |
| *** davidlenwell has quit IRC | 22:34 | |
| *** davidlenwell has joined #refstack | 22:36 | |
| *** ChanServ sets mode: +o davidlenwell | 22:36 | |
| catherineD | davidlenwell: hello | 22:38 |
| davidlenwell | lifes good .. officially an employee of HPE | 22:49 |
| davidlenwell | on the Ironic team | 22:49 |
| catherineD | davidlenwell: Congrats!! | 22:50 |
| davidlenwell | thanks! | 22:52 |
| davidlenwell | sadly I am not going to have a lot of time for refstack | 22:53 |
| catherineD | davidlenwell: :-( | 22:53 |
| rockyg | Ah, well. but, a solid position and some fun stuff happening in Ironic. Cool. | 22:59 |
| rockyg | And congratz! | 22:59 |
| davidlenwell | thanks! I can still help out from time to time.. but it will be more of how the last cycle was | 23:00 |
| *** rockyg has quit IRC | 23:18 | |
| *** edmondsw has quit IRC | 23:47 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!