| *** tpeoples has quit IRC | 00:08 | |
| *** tpeoples has joined #refstack | 00:10 | |
| *** markvoelker has joined #refstack | 00:46 | |
| *** markvoelker has quit IRC | 00:50 | |
| *** hogepodge has quit IRC | 00:56 | |
| *** hogepodge has joined #refstack | 00:59 | |
| *** markvoelker has joined #refstack | 01:47 | |
| *** markvoelker has quit IRC | 01:52 | |
| *** coolsvap|away is now known as coolsvap | 03:02 | |
| *** markvoelker has joined #refstack | 03:47 | |
| *** markvoelker has quit IRC | 03:52 | |
| openstackgerrit | Merged openstack/refstack-client: Remove RefStack dependency on Keystone client. https://review.openstack.org/265747 | 05:10 |
|---|---|---|
| *** coolsvap is now known as coolsvap|away | 05:40 | |
| *** lifeless_ has joined #refstack | 05:45 | |
| *** markvoelker has joined #refstack | 05:48 | |
| *** lifeless has quit IRC | 05:49 | |
| *** mgagne has quit IRC | 05:49 | |
| *** eglute has quit IRC | 05:49 | |
| *** mgagne_ has joined #refstack | 05:49 | |
| *** coolsvap|away is now known as coolsvap | 05:49 | |
| *** markvoelker has quit IRC | 05:53 | |
| *** eglute has joined #refstack | 05:55 | |
| openstackgerrit | David Liu proposed openstack/refstack: Fix warning message when RefStack server starts up. https://review.openstack.org/274520 | 07:00 |
| openstackgerrit | David Liu proposed openstack/refstack: Fix warning message when RefStack server starts up. https://review.openstack.org/274520 | 07:09 |
| *** markvoelker has joined #refstack | 07:49 | |
| *** markvoelker has quit IRC | 07:54 | |
| *** coolsvap is now known as coolsvap|away | 08:36 | |
| *** davidlenwell has quit IRC | 08:47 | |
| *** davidlenwell has joined #refstack | 08:56 | |
| *** ChanServ sets mode: +o davidlenwell | 08:56 | |
| *** pilgrimstack has joined #refstack | 09:24 | |
| *** pilgrimstack has quit IRC | 09:26 | |
| *** pilgrimstack has joined #refstack | 09:35 | |
| *** markvoelker has joined #refstack | 09:50 | |
| *** markvoelker has quit IRC | 09:54 | |
| *** openstackgerrit has quit IRC | 10:02 | |
| *** christiana has quit IRC | 10:45 | |
| *** lifeless_ is now known as lifeless | 11:17 | |
| *** markvoelker has joined #refstack | 11:50 | |
| *** openstackgerrit_ has joined #refstack | 11:54 | |
| *** openstackgerrit_ is now known as openstackgerrit | 11:55 | |
| *** markvoelker has quit IRC | 11:55 | |
| *** openstackgerrit has quit IRC | 11:59 | |
| *** openstackgerrit has joined #refstack | 12:08 | |
| *** christiana has joined #refstack | 12:25 | |
| *** markvoelker has joined #refstack | 12:51 | |
| *** markvoelker has quit IRC | 12:56 | |
| *** markvoelker has joined #refstack | 13:14 | |
| *** edmondsw has joined #refstack | 13:15 | |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Add vendors UI https://review.openstack.org/274417 | 14:36 |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Add vendors REST API https://review.openstack.org/272188 | 14:36 |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Add vendors UI https://review.openstack.org/274417 | 15:22 |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: WIP: Add user management for vendor https://review.openstack.org/274710 | 15:22 |
| *** cody-somerville- has quit IRC | 16:19 | |
| *** esker has joined #refstack | 17:09 | |
| *** dwalleck has joined #refstack | 17:27 | |
| *** mgagne_ has quit IRC | 17:32 | |
| *** mgagne_ has joined #refstack | 17:32 | |
| *** mgagne_ is now known as mgagne | 17:34 | |
| *** cody-somerville- has joined #refstack | 17:57 | |
| *** cody-somerville- has quit IRC | 18:05 | |
| *** cody-somerville- has joined #refstack | 18:08 | |
| *** cody-somerville- has quit IRC | 18:15 | |
| openstackgerrit | Catherine Diep proposed openstack/refstack: REST API specification for vendor registration https://review.openstack.org/274837 | 18:26 |
| openstackgerrit | Catherine Diep proposed openstack/refstack: WIP: REST API specification for vendor registration https://review.openstack.org/274837 | 18:36 |
| *** andrey-mp has joined #refstack | 18:40 | |
| *** pvaneck has joined #refstack | 18:48 | |
| *** edmondsw has quit IRC | 18:49 | |
| *** alexandrelevine has joined #refstack | 18:50 | |
| openstackgerrit | Catherine Diep proposed openstack/refstack: WIP: REST API specification for vendor registration https://review.openstack.org/274837 | 18:56 |
| *** edmondsw has joined #refstack | 19:33 | |
| alexandrelevine | catherineD: DefCore had no idea that there is an option to have it implemented in RefStack. Can't we ask them if it'll do? Because for the future it's definitely better. | 20:01 |
| *** rockyg has joined #refstack | 20:02 | |
| alexandrelevine | catherineD: They can play with the prototype and think. | 20:02 |
| rockyg | Hey guys. So, we could ask defcore to review their past decision, now that we have a different method. Let them decide which they prefer. | 20:03 |
| alexandrelevine | rockyg: +1 | 20:03 |
| alexandrelevine | It has this advantage that we'll have a proper Creator and initial Admin for the Vendor right after approval. | 20:03 |
| alexandrelevine | catherineD|2: ping | 20:05 |
| pvaneck | I'm also leaning towards the approval-based process. Can also still give foundation members the ability to create vendors too if they have the info i think. | 20:05 |
| pvaneck | but at least with an approval based process, that first user is guaranteed to have a record in refstack for the vendor group | 20:05 |
| alexandrelevine | pvaneck: +1 | 20:05 |
| sslypushenko | alexandrelevine: I think it will be better to discuss some prototype, not just specs. Because no one don't understand what will works for us at the very end | 20:05 |
| rockyg | ++ | 20:05 |
| alexandrelevine | sslypushenko: It works already here http://52.49.129.72:8000/#/user_vendors | 20:06 |
| sslypushenko | hmmm... I don't see how to approve vendor | 20:07 |
| rockyg | The advantage of the vendor input process is that they can verify correctness and they have all the info. In past companies, waiting for the customer to provide info always took a long time and they usually forgot something. With this, it won't complete until all info is in. | 20:07 |
| sslypushenko | I'm missing something? | 20:07 |
| alexandrelevine | sslypushenko: Have you signed in? | 20:07 |
| sslypushenko | oh... I see | 20:07 |
| rockyg | so, it's on the vendor to meet their own timelines at least for submitting the info. | 20:07 |
| alexandrelevine | rockyg: Yes, it has tons of advantages in fact. | 20:08 |
| sslypushenko | basically it such workflow should work for RefStack and Defcore | 20:08 |
| rockyg | alexandrelevine, right. Once in the system, the workflow can include tracking of stages and pings when process gets stuck in a stage. | 20:09 |
| alexandrelevine | rockyg: absolutely | 20:10 |
| rockyg | It would also work for new vendors in the marketplace, even before the vendor has any defcore tests. | 20:10 |
| alexandrelevine | all the niceties can be added later gradually. | 20:10 |
| alexandrelevine | Moreover it'll simplify and clarify the learning and accepting process. | 20:11 |
| rockyg | Yes. | 20:11 |
| alexandrelevine | It looks much friendlier than some rules about sending some email somewhere. | 20:11 |
| rockyg | So, vendor registration will go beyond just defcore to all foundation vendor registrations. They'd like that. | 20:11 |
| alexandrelevine | pity, catherineD is seemingly not here at the moment :) | 20:11 |
| rockyg | She's on the channel, so she can read the back scroll. | 20:12 |
| alexandrelevine | rockyg: Unless her notebook suddenly powers down :) | 20:13 |
| rockyg | Yeah. But the channel is recorded, so she can go to the eavesdrop.... | 20:13 |
| alexandrelevine | good to know :) | 20:13 |
| rockyg | I'm thinking we need to socialize this with defcore more, an the founation. Let them know that Refstack *could* provide them with 21st century tools for their marketing management. | 20:14 |
| alexandrelevine | :)) | 20:14 |
| *** andrey-mp has quit IRC | 20:14 | |
| rockyg | They just need to specify the workflow they want, and meet with us at the summit to finalize it;-) | 20:15 |
| alexandrelevine | rockyg: Summit is too late. We can have it done and ready for release by then. | 20:16 |
| alexandrelevine | I mean, it's already almost done. | 20:16 |
| rockyg | Well, if we can get their workflow, we can have the POC and they can review it. If *they* move fast enough, it can be finalized. I'm thinking they don't move that fast. | 20:16 |
| alexandrelevine | Also development-wise it's much more convenient for us to work and test, comparing to the "import" option. | 20:17 |
| rockyg | ++ | 20:17 |
| catherineD|2 | hello | 20:17 |
| catherineD|2 | let me catch up with what had been discussed first | 20:17 |
| alexandrelevine | rockyg: They don't have anything now. And they haven't approved or really verified any of the requirements I wrote, so I don't think they really care. | 20:17 |
| rockyg | We'd have another "product type" if we extend Refstack to product registration....Actually, two. Training and Consultants | 20:18 |
| rockyg | I think they do care, they are just unorganized in the marketing group, and Chris has too much on his plate. | 20:18 |
| rockyg | Email me a good link for them to explore the system and I'll post to defcore and CC some foundation marketing people. | 20:20 |
| catherineD|2 | rockyg: so what I take is you will start an email for the topic whether refstack should support the use case that a vendor can self-register in refstack? | 20:22 |
| alexandrelevine | This is a good link, I guess. For Vendor registration functionality at least. | 20:22 |
| rockyg | Yup. | 20:22 |
| catherineD|2 | and what would be the requirements for self-registration ... | 20:22 |
| rockyg | Register, but no approval. A way for a vendor to get the attention of the foundation regarding their product(s) | 20:22 |
| alexandrelevine | catherineD: Actually, except for the details of info they are in my requirements already. | 20:23 |
| catherineD|2 | rockyg: how would you prevent some one to go to RefStack and register a vendor with name as "IBM"? | 20:23 |
| alexandrelevine | catherineD: How do they prevent it now? | 20:23 |
| catherineD|2 | that should be included in the requirment | 20:24 |
| catherineD|2 | that is not RefStack's business ... | 20:24 |
| alexandrelevine | catherineD: Say, I write an email, saying that I work for IBM and require them to register "IBM" vendor for me | 20:24 |
| catherineD|2 | alexandrelevine: I can not speak for foundation ... | 20:24 |
| alexandrelevine | catherineD: Neither is here. We can provide a big text box which into which an applicant puts all of his info he now provides in emails. | 20:25 |
| catherineD|2 | but I trust that they have had a legal procdure in place ... | 20:25 |
| alexandrelevine | catherineD: They'll follow it the same way they do now. I'm just suggesting to change the way they are notified about another applicant. | 20:25 |
| alexandrelevine | What's more natural, friendly and marketing-wise appealing than possibility to apply for something from the same software you want to use? | 20:26 |
| catherineD|2 | alexandrelevine: agaim that is a bigger issues .. if we want to implement test associated with vendor tests resposiblely , the safest way is to take a vendor list from the foundation ... | 20:27 |
| alexandrelevine | Say, I heard about RefStack and I'm thinking if I want to register my OpenHelloWorld Vendor. Would I better go and read a long list of rules and guidelines about how to send what on some web-page or come to the software, trial it, play with it and then just fill in the required form and click "register"? | 20:28 |
| rockyg | It's "safe", but with the registration workflow in place, this way will be just as safe. | 20:28 |
| alexandrelevine | catherineD: What's the difference for us? We do not approve anyways. | 20:28 |
| catherineD|2 | rockyg: exactly ... we do not have a workflow in place | 20:29 |
| catherineD|2 | with audit trail | 20:29 |
| alexandrelevine | catherineD: Neither we have for import. | 20:29 |
| rockyg | Registration, as regular vendor listing, requires foundation to approve before it is "official". So, someone tries to get IBM, they get rejected. And maybe even blacklisted in DB. | 20:29 |
| catherineD|2 | alexandrelevine: but import can only be done by foundation member | 20:29 |
| catherineD|2 | we know who did it | 20:29 |
| alexandrelevine | catherineD: Why audit is so important here? We're not doing nothing else but passing the info instead of email. What's wrong with that? | 20:29 |
| rockyg | Better tracking for foundation. | 20:30 |
| alexandrelevine | catherineD: Same here. | 20:30 |
| alexandrelevine | catherineD: Only registered in RefStack Foundation admin will have interface to approve. | 20:30 |
| alexandrelevine | catherineD: And we'll know who did it. | 20:30 |
| catherineD|2 | alexandrelevine: rockyg: I am not oppose to do this if we have a robust approval process and workflow in place ... | 20:30 |
| alexandrelevine | catherineD: However, we won't know if some of the admins just call some CLI import utility. | 20:30 |
| rockyg | That's why we are going to the mailing list to get the discussion rolling. | 20:31 |
| alexandrelevine | rockyg: +1 | 20:31 |
| catherineD|2 | alexandrelevine: in your case we know who does it .. but that person has no accountability or resposibility | 20:31 |
| alexandrelevine | catherineD: What do you mean? | 20:31 |
| catherineD|2 | rockyg: ++ | 20:31 |
| alexandrelevine | catherineD: It's this same Foundation admin which we gave permissions to, say, delete Vendors, right? | 20:31 |
| rockyg | If the person approves, and shouldn't have, the foundation can fire that person, and retract the approval. | 20:32 |
| alexandrelevine | catherineD: Or you want to delete Vendors by some "export" operation? :) | 20:32 |
| rockyg | I've gotta go to the office, now. Have fun! | 20:32 |
| *** rockyg has left #refstack | 20:32 | |
| catherineD|2 | create (import) / remove (delete) have to all be done by foundation members | 20:32 |
| alexandrelevine | catherineD: Look, there is whole deal of management involved, which is not only about registration or approval. Later steps are no less important and we plan them to be done via RefStack anyways, right? | 20:33 |
| alexandrelevine | catherineD: What means do you want to provide them with? CLI? REST API? | 20:33 |
| catherineD|2 | official_vendor create/remove ahve to be done by foundation | 20:33 |
| alexandrelevine | catherineD: Or rather RefStack UI part? | 20:33 |
| alexandrelevine | catherineD: Of course. Through what interface? | 20:33 |
| catherineD|2 | we need REST API, then we can create a script to call those REST API for the foundation to import vendor from a JSON file/ | 20:34 |
| alexandrelevine | catherineD: Ok. And delete? Another script? | 20:34 |
| alexandrelevine | catherineD: How about edit of some info? | 20:35 |
| alexandrelevine | catherineD: How about management of Vendor's admins? | 20:35 |
| catherineD|2 | the first vendor_admin will be add by the foundation... can be done at import time ... | 20:36 |
| alexandrelevine | catherineD: Right, what about deletion of Vendor and update of Vendor info? | 20:36 |
| catherineD|2 | that vendor_admin then manage the vendor users | 20:36 |
| catherineD|2 | vendor admins can upate vendor info but not delete | 20:36 |
| alexandrelevine | catherineD: Who and how will delete? With what interface? | 20:37 |
| catherineD|2 | pls see https://review.openstack.org/#/c/274837/ | 20:37 |
| alexandrelevine | REST API is great, but we wouldn't want them to use "curl" to send REST requests, right? What human interface they would use? Another script? | 20:38 |
| catherineD|2 | no not curl ... that is why we will have script to import vendor from JSON ... Paul is working on that | 20:38 |
| catherineD|2 | beside the script .. | 20:39 |
| alexandrelevine | catherineD: Again, what about deletion? Another script? | 20:39 |
| *** dwalleck has quit IRC | 20:39 | |
| *** dwalleck has joined #refstack | 20:39 | |
| catherineD|2 | we can develop UI ... this is for the future when we have notification process, approval process in place then we can user can register vendor ... but until then.. .this is low priority | 20:40 |
| catherineD|2 | deletion can be an other script or UI... | 20:40 |
| catherineD|2 | before we implemented deletion .. we will ahve to decide on soft vs hard delete // | 20:41 |
| catherineD|2 | I do not see we implement deletion in this phases | 20:41 |
| alexandrelevine | catherineD: So if it's another script then we're effectively creating CLI and we'll have to maintain two different UIs de-facto. If it's GUI then why not GUI for import then? Why bother with CLI at all? If GUI for import, why not for registration process? | 20:41 |
| catherineD|2 | CLI is good too | 20:41 |
| catherineD|2 | UI import is good | 20:42 |
| sslypushenko | catherineD|2: What is main goal for such kind of import/export workflow? | 20:42 |
| sslypushenko | why just approve will not work for you | 20:42 |
| catherineD|2 | I am just thinking of the number of vendor that foundation have to create ... and UI involve user input it could be mistake | 20:42 |
| alexandrelevine | catherineD: Ok, can we at least communicate it to DefCore? My preference is 1) to keep everything in GUI (if import - let it be GUI part) 2) I don't see problems with the implemented registration mechanism and I see lots of advantages so I'd prefer this option. | 20:42 |
| catherineD|2 | sslypushenko: by keepint the vendor list in a JSO file ... the foundation has a copy of their input data ... | 20:43 |
| alexandrelevine | catherineD: They'll have all the input data centrally stored in our DB. Is it worse? If they need we'll create export to csv or whatever later. | 20:44 |
| catherineD|2 | UI is good (and i am not oppose it) it just not good when 1) number of vendor input is large 2) user errors | 20:44 |
| catherineD|2 | alexandrelevine: agree | 20:45 |
| alexandrelevine | catherineD: When you make someone send email instead of filling in predefined form with tooltips and checkings - you'll have much more errors. | 20:45 |
| catherineD|2 | My main point here is ... at this phase I would like only foundation member can create official_vendor | 20:45 |
| alexandrelevine | catherineD: In any phase it'll be the case. | 20:46 |
| alexandrelevine | catherineD: In my solution he'll do it by clicking "approve" button. | 20:46 |
| catherineD|2 | I do not mind foundation to use GUI, import script .. | 20:46 |
| alexandrelevine | catherineD: I don't see how different is using our GUI to import some Vendor info compared to clicking "Approve" button with some user-entered info. | 20:46 |
| alexandrelevine | catherineD: It's totally the same. One final click by the foundation admin. Oh, no, in case of import - more clicks. | 20:47 |
| catherineD|2 | so before approve ... will the vendor infor be publicly available | 20:47 |
| alexandrelevine | catherineD: No | 20:47 |
| catherineD|2 | and foundation admin can view it? | 20:47 |
| alexandrelevine | catherineD: Of course. You can see working now. | 20:48 |
| alexandrelevine | catherineD: We'll just have to add more required info but besides that - it's present in the prototype. | 20:48 |
| catherineD|2 | alexandrelevine: I do not see it working now because the current sign-in in the prototype is for one user .. | 20:48 |
| alexandrelevine | catherineD: Yes, it's getting Foundation Admin rights. | 20:49 |
| alexandrelevine | catherineD: There is a problem with linking our temporary sites with the Open-id authentication system, so we had to resort to fake logins. | 20:49 |
| catherineD|2 | ok I will let rockyg to send out a distribution email ... | 20:49 |
| catherineD|2 | need to go now .. | 20:49 |
| alexandrelevine | catherineD: We can create a fake drop-down with several types of logins - Foundation admin, Vendor admin, Regular user. Would be more real-life-like. | 20:50 |
| alexandrelevine | Bye, thanks :) | 20:50 |
| catherineD|2 | good discussion thx alexandrelevine: | 20:50 |
| catherineD|2 | tty! | 20:50 |
| *** alexandrelevine has quit IRC | 20:51 | |
| *** esker has quit IRC | 21:09 | |
| openstackgerrit | Merged openstack/refstack: Add database tables to support vendor/product registration. https://review.openstack.org/268922 | 21:24 |
| *** esker has joined #refstack | 21:37 | |
| *** esker has quit IRC | 21:37 | |
| *** esker has joined #refstack | 21:37 | |
| *** edmondsw has quit IRC | 21:50 | |
| *** esker has quit IRC | 22:50 | |
| *** markvoelker has quit IRC | 23:41 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!