| *** aesr_ has joined #refstack | 00:57 | |
| *** pvaneck_ has joined #refstack | 00:57 | |
| *** catherineD|2 has joined #refstack | 00:58 | |
| *** aesr has quit IRC | 01:00 | |
| *** pvaneck_ has quit IRC | 01:01 | |
| *** pvaneck has quit IRC | 01:01 | |
| *** catherineD has quit IRC | 01:01 | |
| *** davidlenwell has quit IRC | 02:14 | |
| *** davidlenwell has joined #refstack | 02:16 | |
| *** ChanServ sets mode: +o davidlenwell | 02:16 | |
| *** cody-somerville has quit IRC | 05:00 | |
| *** cody-somerville has joined #refstack | 07:19 | |
| *** nijaba has quit IRC | 07:27 | |
| *** nijaba has joined #refstack | 07:27 | |
| *** cody-somerville has quit IRC | 08:14 | |
| *** pilgrimstack has joined #refstack | 08:24 | |
| *** pilgrimstack has quit IRC | 08:59 | |
| *** pilgrimstack has joined #refstack | 09:05 | |
| *** pilgrimstack has quit IRC | 09:20 | |
| *** pilgrimstack has joined #refstack | 09:22 | |
| *** markvoelker has quit IRC | 09:23 | |
| *** markvoelker has joined #refstack | 10:23 | |
| *** markvoelker has quit IRC | 10:28 | |
| *** sc has quit IRC | 11:06 | |
| *** pilgrimstack has quit IRC | 11:38 | |
| *** markvoelker has joined #refstack | 12:25 | |
| *** markvoelker has quit IRC | 12:29 | |
| *** pilgrimstack has joined #refstack | 12:59 | |
| *** pilgrimstack has quit IRC | 13:18 | |
| *** edmondsw has joined #refstack | 13:18 | |
| *** markvoelker has joined #refstack | 13:25 | |
| *** pilgrimstack has joined #refstack | 13:26 | |
| *** markvoelker has quit IRC | 13:28 | |
| *** markvoelker has joined #refstack | 13:28 | |
| *** pilgrimstack has quit IRC | 13:40 | |
| *** pilgrimstack has joined #refstack | 13:56 | |
| *** pilgrimstack has quit IRC | 13:59 | |
| *** pilgrimstack has joined #refstack | 14:13 | |
| *** davidlenwell has quit IRC | 14:35 | |
| *** davidlenwell has joined #refstack | 14:49 | |
| *** ChanServ sets mode: +o davidlenwell | 14:49 | |
| *** esker has quit IRC | 15:12 | |
| *** esker has joined #refstack | 15:13 | |
| *** esker has quit IRC | 15:14 | |
| *** esker has joined #refstack | 15:14 | |
| *** esker has quit IRC | 15:22 | |
| *** pilgrimstack has quit IRC | 16:08 | |
| *** pilgrimstack has joined #refstack | 16:14 | |
| *** nijaba has quit IRC | 17:07 | |
| *** nijaba has joined #refstack | 17:08 | |
| *** nijaba has quit IRC | 17:08 | |
| *** nijaba has joined #refstack | 17:08 | |
| *** openstackgerrit has quit IRC | 17:17 | |
| *** openstackgerrit has joined #refstack | 17:18 | |
| *** cody-somerville has joined #refstack | 17:45 | |
| *** hockeynut is now known as hockeynut_otr | 17:51 | |
| *** hockeynut_otr is now known as hockeynut | 17:52 | |
| *** cody-somerville has quit IRC | 17:53 | |
| *** hockeynut_afk has joined #refstack | 18:00 | |
| *** pilgrimstack has quit IRC | 18:02 | |
| *** alexandrelevine has joined #refstack | 18:03 | |
| *** hockeynut_afk has quit IRC | 18:05 | |
| catherineD|2 | about the keystone id | 18:06 |
|---|---|---|
| *** hockeynut_otr has joined #refstack | 18:06 | |
| alexandrelevine | catherineD? | 18:12 |
| catherineD|2 | our patch related to keystone id -hockeynut_otr: . https://review.openstack.org/#/c/245007/ https://review.openstack.org/#/c/224965/ | 18:12 |
| catherineD|2 | pls take a look ... | 18:13 |
| alexandrelevine | which means that we can rely on having unique cloudID, right? | 18:13 |
| catherineD|2 | yes and no ... for v2 no .. for v3 yes | 18:14 |
| catherineD|2 | but the main issue is some public cloud do not offer keystone list service command to non-admin user | 18:15 |
| catherineD|2 | devstack or private clouds maybe OK ... but the concern is public cloud | 18:15 |
| alexandrelevine | are you sure? We checked that demo user in devstack has access. Are you saying public clouds forbid it in policies or I don't know where? | 18:16 |
| catherineD|2 | public cloud can defined policy file to restrict the list service commands | 18:17 |
| catherineD|2 | RefStack has been using keystone since day 1 | 18:18 |
| alexandrelevine | do we need to allow regular user to test the cloud in the case? I mean if someone want's to certify a public cloud he'll have the admin creds and we'll have the keystone list service available, no? | 18:18 |
| catherineD|2 | No all DefCore define tests are targeted at being run without admin user... | 18:19 |
| alexandrelevine | Andrey is saying that keystone catalog will work in any case and it has service id. Isn't it enough? | 18:20 |
| alexandrelevine | catherineD: That's a problem too, no? What are they going to do about the admin-related functionality? How are they going to certify a cloud against this functionality? | 18:21 |
| catherineD|2 | alexandrelevine: I am saying that keystone catalog may not be served by all public cloud for regular user .... | 18:21 |
| catherineD|2 | our current code is using keystone catalog | 18:22 |
| catherineD|2 | API to retrive the keystone service ID | 18:22 |
| alexandrelevine | catherineD: Do you know such a cloud? From our experience keystone catalog works all the time - otherwise some of the functionality won't work for regular user, like metadata service. | 18:22 |
| catherineD|2 | no certification is from the regular user aspect no admin certification | 18:23 |
| alexandrelevine | catherineD: I did see clouds with keystone list service forbidden but not keystone catalog. It works all the time. | 18:23 |
| catherineD|2 | Rackspace is one of the cloud raising this issue sometime ago ... | 18:24 |
| catherineD|2 | please take a look at https://review.openstack.org/#/c/265747/ .. | 18:25 |
| alexandrelevine | "no certification is from the regular user aspect no admin certification". I don't understand this statement. An OpenStack cloud provides a number of APIs and in order to be compliant with Logo all of them (selected of course) should pass tests. Admin related functionality is one of such APIs. What if I have a cloud which presents OpenStack logo and I try to use some admin-related functionality and it doesn't work? What's th | 18:25 |
| alexandrelevine | catherineD: Are you sure that Rackspace forbade "keystone catalog"? Can we recheck? I'm saying that the cloud will be not fully functional in this case. It's like prohibiting to use "nova list" for regular user. | 18:26 |
| alexandrelevine | catherineD: What about this review? It replaces calls to keystone client with HTTP calls | 18:28 |
| *** hockeynut_otr has quit IRC | 18:28 | |
| catherineD|2 | any way fetching the cpid from keystone is still in RefStack code ...so if you decide that that good enough ... we are ok for now | 18:29 |
| alexandrelevine | Yes. Then we'll have our unique cpid (CloudID) which we'll put into Product ID in DB and will always have something unique to address by | 18:29 |
| catherineD|2 | this review is using the catalog list RES API.. I want to tell you that we are very familiar with this aspect and keep improvint our pricess .... | 18:30 |
| catherineD|2 | based on the issues we encountered .... | 18:30 |
| catherineD|2 | we have at least 5 or 6 patches for the keystone service ID related | 18:31 |
| alexandrelevine | catherineD: I didn't doubt it :) The question was, is it really so that "keystone catalog" is forbidden? How does functionality relying on it work in such clouds, do you know? | 18:31 |
| catherineD|2 | What I am saying is that OpenStack allows vendor to create policy files which vendor can specify stricter policy for their cloud ... | 18:33 |
| alexandrelevine | catherineD: No problem. Vendor can even not install cinder and nova or do whatever he wants. We just won't test such a Cloud in the case - that's all. | 18:34 |
| catherineD|2 | and getting keystone service id is not one of the must pass test ... | 18:34 |
| alexandrelevine | catherineD: In order to be officially and openly tested and certified, some rules should be abided and some services should work correctly. I guess it's not too much to ask for keystone catalog to be available, no? | 18:35 |
| alexandrelevine | catherineD: That might have to change now. Because without it we can't identify the cloud and what certification can we talk about in this case? | 18:35 |
| catherineD|2 | we can not ask some feature that is not in must-pass test list fronm DefCore | 18:35 |
| alexandrelevine | catherineD: We can ask them to enhance the list. As I said - we need to correctly identify Cloud. Or let them suggest the way to do this without it. | 18:36 |
| catherineD|2 | the only keystone test in DefCore must pass list is create token | 18:36 |
| alexandrelevine | catherineD: For Clouds testing we'll either need keystone catalog working or admin creds - customer's choice. | 18:37 |
| alexandrelevine | We can't just trust some URL. I don't think it's right. Or if DefCore is ok with it, then all of the devstacks and temporary URLs are out of our testing. | 18:37 |
| catherineD|2 | alexandrelevine sure but to add a test it will first needed to add to the advisory catagory then to required catagory ... it will take 2 OpenStack release cycle | 18:38 |
| catherineD|2 | back to our issues | 18:38 |
| alexandrelevine | catherineD: This is not a test. This is a requirement for testing - there is a difference. | 18:38 |
| alexandrelevine | catherineD: Prerequisites for certification should be handled differently than certification tests. | 18:38 |
| catherineD|2 | for centralize testing your need a URL... | 18:39 |
| alexandrelevine | catherineD: I need many things. URL, creds, access tokens .... | 18:39 |
| catherineD|2 | do you want to fetch that URL from the config file or from a field in the product table (prodcut_id)? | 18:39 |
| alexandrelevine | catherineD: And again I don't want to differentiate Centralized or Local testing. They are the same for me in terms of cloud identification | 18:39 |
| alexandrelevine | catherineD: Right now it's in Config | 18:40 |
| catherineD|2 | for local testing RefStack do not need any URL and can cont controll because all tests are done on-premise by the vendor | 18:41 |
| alexandrelevine | catherineD: ProductID - is just an ID. | 18:41 |
| alexandrelevine | catherineD: It needs exactly the same tempest config. There is no difference. | 18:41 |
| alexandrelevine | catherineD: Our Centralized testing right now does exactly the same - it just places the Tempest config where refstack client will be run and then just run it. There is no difference. | 18:42 |
| catherineD|2 | in the product table , cureently there is a ID field (which is UUID created automatically by RefStack) and product_id (the intention is for unique id) ... we can just choose to use one of them | 18:43 |
| alexandrelevine | We don't need the UUID. But we do need the Product ID. | 18:44 |
| catherineD|2 | ok suppose we get rid of ID and only use Product_ID ... what would be the value of Product_id when a product is created? | 18:45 |
| alexandrelevine | catherineD: What do you mean? :) It'll be used as a regular ID of any entity. For each and every operation with it. | 18:46 |
| catherineD|2 | currently the field product_id is defined as nullable=false ... that means that when you create a product you must give a value to this fiedl ... what value will it be? | 18:49 |
| alexandrelevine | You should pass it during creation of a Product. If you register a Cloud it should be a CPID. If you register a Software, it'll also be passed or GUID generated (not sure about Software id yet) | 18:50 |
| alexandrelevine | Procedure of Cloud registration should take creds sufficient for going to the Cloud, determining the CloudID and then passing this info to our engine and DB for Product Creation. | 18:53 |
| *** pvaneck has joined #refstack | 18:54 | |
| catherineD|2 | so when you register a cloud (that is create a prodcut) you will need to connect to the cloud get the CPID then initializes the product_id field? | 18:56 |
| alexandrelevine | yes | 18:56 |
| catherineD|2 | OK I agreed with a cloud registration ... and you say we don't know what it is for software prodcut ? | 18:57 |
| alexandrelevine | catherineD: We talked about it internally. It's either Software name if we work with only unique names and no renaming. Or we'll have to generate a GUID for each new Software we register. | 18:58 |
| catherineD|2 | so for software product the product_ID can be : case 1: software name case 2: refstack generate a UUID . For a cloud it will be case 3: some id fetch from the cloud | 19:00 |
| catherineD|2 | so in one fiedl we have at least 2 types of data ... how do we differenticat whch is which? or do need to differentiat them? | 19:01 |
| alexandrelevine | For a public Amazon and Google Clouds we'll have case 4: we'll define it by Tempest config by predefined URL for the cloud and we'll use some predefined IDs for those clouds | 19:01 |
| alexandrelevine | catherineD: We don't. That's why STRING | 19:01 |
| alexandrelevine | catherineD: We don't care about the format of this string. | 19:02 |
| catherineD|2 | but our BL logic need to know which of the 4 types it need to initiate the field with | 19:02 |
| alexandrelevine | catherineD: Or we can make it all uniform by taking hash of those various ID contents | 19:03 |
| alexandrelevine | catherineD: Why? It'll need to know only about Software or Cloud. And we'll have field "type" for this. | 19:03 |
| alexandrelevine | Oh. You mean to initialize it initially? | 19:03 |
| catherineD|2 | before taking a hash BL code still need to know case 1: expect user input (it may not be uniqe) case 2: Refstack need to create UUID case 3: go to the cloud and get it case 4: got to tempest config and get it | 19:04 |
| alexandrelevine | Yes. It'll know. Various code for registration of Software and Clouds will employ various mechanisms for determining the ID and then pass it down. | 19:04 |
| alexandrelevine | 1. I still think that there is no such case. I don't see how we can work with it. | 19:04 |
| catherineD|2 | ok remove 1 | 19:05 |
| alexandrelevine | For the rest it's just different registration code. | 19:05 |
| alexandrelevine | Software registration code will create GUID or use Software name. | 19:05 |
| alexandrelevine | Cloud registration code will take a look into Tempest config and determine if it's OpenStack cloud. If yes, it'll go to the cloud and determine cpid. If not, it'll work otherwise. | 19:06 |
| catherineD|2 | ok so it is required to upload a tempest.config file to register a software product? | 19:08 |
| alexandrelevine | No. Software product doesn't need tempest config | 19:09 |
| alexandrelevine | Only Cloud Product | 19:09 |
| catherineD|2 | So when a product is created it will check to see whether tempest.conf is included if it is not included it will assume that it is a software product? | 19:10 |
| alexandrelevine | No. When you create Software Product one interface and Controller is invoked. When Cloud product another. | 19:11 |
| alexandrelevine | Roughly, refstack API will have two different calls create_software and create_cloud | 19:11 |
| alexandrelevine | (maybe Contoller is the same but methods are different) | 19:12 |
| catherineD|2 | so if that is the case , we should have a type filed in the product | 19:13 |
| alexandrelevine | catherineD: Exactly | 19:13 |
| catherineD|2 | ok great | 19:14 |
| catherineD|2 | if type=software_product, product_id will be a UUID generated by refstack | 19:15 |
| alexandrelevine | (or software name) | 19:15 |
| catherineD|2 | if type = cloud, product_id = a keystone ifrom the cloude | 19:15 |
| catherineD|2 | we can not guarantee that software name will be unique | 19:16 |
| catherineD|2 | ther is also a name field in the table | 19:16 |
| alexandrelevine | I'm still not sure about that (that software name is not unique). At least combination Vendor-Software name should be unique, what do you think? | 19:16 |
| alexandrelevine | We can use Vendor-Software name as a unique ID, I guess? | 19:17 |
| catherineD|2 | ok since software name is user input, Amazon amd AMAZON are actually 2 unique name | 19:18 |
| alexandrelevine | However, we might have a problem here with the registration of User's Software. | 19:18 |
| alexandrelevine | Yes, maybe GUID is the safest for Software now. At least I can't imagine how to automatically deduce something unique for each Software | 19:19 |
| alexandrelevine | Maybe some #ID in Amazon's goods listings? (just kidding) | 19:20 |
| catherineD|2 | at least from db table point of view ... I am ok with having product_id (unique, none nullable) with a type field | 19:20 |
| alexandrelevine | great | 19:20 |
| catherineD|2 | let's discuss the public flag in the prodcut table ... I will indicate when I am done | 19:21 |
| alexandrelevine | listening | 19:22 |
| catherineD|2 | my main concern about having the public flag (share/not share) at various levels is about consistency | 19:23 |
| catherineD|2 | currently, we have a flag at the test level. | 19:23 |
| catherineD|2 | a flag at the prodcut level . | 19:24 |
| catherineD|2 | so in the case when a test run result which is associated to a product .. | 19:24 |
| catherineD|2 | what would happend if a test is public but the product is private? | 19:25 |
| catherineD|2 | done | 19:25 |
| alexandrelevine | The same as now happens in RefStack. You can see lots of test results and no Products. | 19:25 |
| catherineD|2 | ok. | 19:26 |
| catherineD|2 | I just want us to think about and document that | 19:26 |
| catherineD|2 | one more topic ..then we should be done :-) | 19:27 |
| alexandrelevine | Well, ok. How do you want it to be documented? I can create another section in Design Decisions in Requirements doc stating exactly this. | 19:27 |
| catherineD|2 | I would like to have the update_by_user in both org and product tables . | 19:28 |
| catherineD|2 | you can add to the requriement doc and I will add that to the spec too .. | 19:28 |
| alexandrelevine | You want it why? | 19:29 |
| catherineD|2 | I know it is not a perfect solution with the up_date_by ... but at least we know who did what the last time | 19:29 |
| catherineD|2 | because now we have a group of admins we can update the recored ... | 19:30 |
| alexandrelevine | You want it for audit purposes? | 19:30 |
| catherineD|2 | yes minimum tracking | 19:30 |
| catherineD|2 | until we have a better solution | 19:31 |
| alexandrelevine | Do we need such an audit? If we do then first of all we should add it to non-functional requirements. | 19:31 |
| alexandrelevine | Secondly, if we do, then we'd better devise and agree upon some efficient and specialized mechanism for this. Not just spread this by chunks and pieces everywhere. | 19:32 |
| alexandrelevine | Can't we use logging for this? | 19:32 |
| catherineD|2 | we do need it ... would be greate if you could add them the non-functional requirement | 19:32 |
| alexandrelevine | I'll add | 19:32 |
| catherineD|2 | agree that we should have a more robust auditting strategy... but I don't think it would happend in the Mitaka release | 19:33 |
| catherineD|2 | so I suggest that we do the minimum .. | 19:33 |
| catherineD|2 | by adding the update_by_user since this type of data is not reproduce .. | 19:35 |
| catherineD|2 | anything else to discuss? I am good ... I will update the spec and then Andrey can update his .. | 19:36 |
| *** alexandrelevine_ has joined #refstack | 19:36 | |
| alexandrelevine_ | catherineD: I'm sorry, I got disconnected for like 3 minutes | 19:36 |
| alexandrelevine_ | Could you repeat your last messages? | 19:37 |
| *** alexandrelevine has quit IRC | 19:37 | |
| catherineD|2 | ic ... just ask whether you have anything else to discuss? I am good .. and will update the org./product spec then Andrey can update his .. | 19:38 |
| alexandrelevine_ | We haven't decided about the updated_by_user. | 19:38 |
| alexandrelevine_ | Wouldn't logging be good enough for the total audit? | 19:39 |
| catherineD|2 | oh I would like to have it .. | 19:39 |
| catherineD|2 | yes logging is the right way ... this is for the meantime | 19:39 |
| alexandrelevine_ | I mean I'm not totally against it, but in terms of design it's not good to have such rudiments if we satisfy the audit requirement by other means. | 19:40 |
| alexandrelevine_ | catherineD: Why can't we start logging right away? To avoid having garbage in a future in our DB? | 19:40 |
| catherineD|2 | I totally agree that we need to have full blown audtiting solution but that take ttime | 19:41 |
| alexandrelevine_ | catherineD: We can start logging everything right away. It's not a problem. At least logging the "update" actions by some user we can for sure. | 19:41 |
| catherineD|2 | we only add one field per table .. | 19:42 |
| alexandrelevine_ | You yourself were very much worried about the DB structure, further upgrades, consistency and stuff. | 19:42 |
| catherineD|2 | logging need analyzer | 19:42 |
| alexandrelevine_ | And? | 19:42 |
| catherineD|2 | I don;t see that we have time for this round | 19:43 |
| alexandrelevine_ | No more than this field in DB. Even less. You can grep logs by "updated_by_user" substring while here you'll have to use mysql utlility and use correct Select and stuff. Much more complicated for my taste. | 19:43 |
| alexandrelevine_ | catherineD: Just writing some logs? The technology is quite developed. We use it in our projects and we just took it from nova or oslo, or whatever. | 19:44 |
| catherineD|2 | that means that we need to create a grep script | 19:44 |
| catherineD|2 | keep in mind that you and I are not the one who can acces the log | 19:44 |
| catherineD|2 | logs | 19:44 |
| alexandrelevine_ | No. You need to write in bash: grep -r "updated_by_user" *.log :) | 19:44 |
| catherineD|2 | and a API to retrieve this info? | 19:45 |
| alexandrelevine_ | catherineD: Why API? Are you going to provide API for the access to this field in DB? | 19:46 |
| catherineD|2 | if we want to go the log path we need a psce | 19:46 |
| catherineD|2 | spec | 19:46 |
| alexandrelevine_ | What about other actions? Which can't be recorded this way? | 19:46 |
| catherineD|2 | I am only focusing on the important actions here ... | 19:47 |
| alexandrelevine_ | Same here. If we want to implement one of the key non-functional reqs in some way we need to somehow make sure that it's known. And it's known what's covered by this decison and why.... | 19:47 |
| catherineD|2 | that is why I suggest that we have this one filed here ...to capture some data in case we need it | 19:48 |
| alexandrelevine_ | catherineD: Ok, making something Public is important or not? Changing name is important or not? All of those fields are in this same record. I'll change the public flag and you'll change the name tomorrow. But only one updated_by_user will remain. Yours. You'll never know who changed the public flag. And you'll never know what exactly was changed. What's the use? | 19:48 |
| alexandrelevine_ | How are you going to audit actions for a complex structure controlled by a group of admins with just one value? | 19:49 |
| alexandrelevine_ | What's the use? | 19:49 |
| catherineD|2 | at least I know who to go to for the last change ... hopefully he/she will know what was the state of the data before he.she changes it | 19:50 |
| catherineD|2 | without that you don't even know where to start | 19:50 |
| alexandrelevine_ | Why is it important? And what if he/she changed something unimportant, and then changed it back? | 19:50 |
| alexandrelevine_ | catherineD: Honestly, the more I talk about it the more I'm against it. It's useless and misleading for the purposes you try to put into it. | 19:51 |
| alexandrelevine_ | catherineD: It'll give a fake sense of safety which will be totally untrue. | 19:51 |
| alexandrelevine_ | audit cannot be done in such a way. | 19:51 |
| alexandrelevine_ | So if it is really important we should do the logging. If it's not that important we shouldn't spoil our DB with something which is totally unusable. | 19:52 |
| catherineD|2 | I really want to have at least a spec or blueprint for our plan on autditing | 19:52 |
| alexandrelevine_ | Perfect suggestion. | 19:53 |
| *** edmondsw has quit IRC | 19:53 | |
| alexandrelevine_ | Let me put our ideas about a logging into the doc for the beginning, what do you think? | 19:53 |
| catherineD|2 | sure ... | 19:53 |
| catherineD|2 | that should be all for today ? | 19:54 |
| alexandrelevine_ | Yes, I guess that was great. Thank you so much. | 19:54 |
| catherineD|2 | alexandrelevine_: same here ... I really appreciate you taking the time ... I know it is late for you ... thanks again! godd night! | 19:55 |
| alexandrelevine_ | catherineD: And sorry for being so tough on you :) | 19:55 |
| catherineD|2 | being tough means that you really care about the project .... I have no complaint ... I would rather everyone to be tought forRefStack | 19:57 |
| alexandrelevine_ | I do. At least I can guarantee you that :) | 19:58 |
| *** alexandrelevine_ has quit IRC | 20:03 | |
| *** tobybot11 has joined #refstack | 21:06 | |
| *** esker has joined #refstack | 21:08 | |
| *** tobybot11 has quit IRC | 21:57 | |
| *** davidlenwell has quit IRC | 22:24 | |
| *** davidlenwell has joined #refstack | 22:25 | |
| *** ChanServ sets mode: +o davidlenwell | 22:25 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!