| *** esker has quit IRC | 00:28 | |
| *** Apsu has quit IRC | 00:42 | |
| *** Apsu has joined #refstack | 00:42 | |
| *** markvoelker has joined #refstack | 01:01 | |
| *** esker has joined #refstack | 01:26 | |
| *** esker has quit IRC | 01:40 | |
| *** esker has joined #refstack | 01:41 | |
| *** esker has quit IRC | 01:45 | |
| *** edmondsw has quit IRC | 03:49 | |
| *** markvoelker has quit IRC | 04:15 | |
| *** markvoelker has joined #refstack | 04:16 | |
| *** dwalleck has joined #refstack | 05:27 | |
| *** esker has joined #refstack | 06:08 | |
| *** esker has quit IRC | 06:21 | |
| *** esker has joined #refstack | 06:32 | |
| *** openstackgerrit has quit IRC | 07:47 | |
| *** openstackgerrit has joined #refstack | 07:47 | |
| *** esker has quit IRC | 07:56 | |
| *** esker has joined #refstack | 07:59 | |
| *** dwalleck has quit IRC | 08:16 | |
| *** pilgrimstack has joined #refstack | 08:53 | |
| *** cjvolzka has joined #refstack | 12:22 | |
| *** edmondsw has joined #refstack | 12:29 | |
| *** krotscheck_dcm is now known as krotscheck | 12:38 | |
| *** edmondsw has quit IRC | 13:11 | |
| *** pilgrimstack has quit IRC | 13:31 | |
| *** pilgrimstack has joined #refstack | 13:32 | |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Add user management. REST API and UI https://review.openstack.org/276420 | 13:57 |
|---|---|---|
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: DNM: fake auth https://review.openstack.org/275133 | 13:57 |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Add vendors UI https://review.openstack.org/274417 | 13:57 |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Add vendors REST API https://review.openstack.org/272188 | 13:57 |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Implement confirmation modal with input textbox https://review.openstack.org/277415 | 13:57 |
| *** esker has quit IRC | 14:52 | |
| *** esker has joined #refstack | 16:12 | |
| *** esker has quit IRC | 16:16 | |
| *** esker has joined #refstack | 16:17 | |
| *** cjvolzka has quit IRC | 17:15 | |
| pilgrimstack | hi, do you know if there is a irc chan on tempest ? | 17:29 |
| eglute | pilgrimstack i don't think so! but here is a list of all the channels: https://wiki.openstack.org/wiki/IRC | 17:45 |
| eglute | try #openstack-qa for tempest questions? | 17:45 |
| openstackgerrit | Catherine Diep proposed openstack/refstack: Update to the organization and product tables. https://review.openstack.org/278026 | 17:51 |
| *** esker has quit IRC | 18:04 | |
| catherineD | eglute: thx | 18:18 |
| catherineD | RefStack team: Please vote for RefStack speaker session ... https://www.openstack.org/summit/austin-2016/vote-for-speakers/Presentation/7575 | 18:55 |
| *** pvaneck has joined #refstack | 18:59 | |
| *** alexandrelevine has joined #refstack | 18:59 | |
| catherineD | hello | 19:03 |
| sslypushenko | hi! o/ | 19:03 |
| catherineD | hI sslypushenko: I am so glad that you can make it ... Thank you ! | 19:04 |
| sslypushenko | It's my pleasure) | 19:04 |
| pvaneck | o/ | 19:04 |
| catherineD | alexandrelevine: ping | 19:04 |
| alexandrelevine | o/ | 19:05 |
| catherineD | we will discuss item 2 and 3 in https://etherpad.openstack.org/p/refstack-meeting-16-02-08 | 19:05 |
| catherineD | Let start with item 3 : Vendor user management | 19:06 |
| catherineD | spec https://review.openstack.org/#/c/277313/ | 19:06 |
| catherineD | The issue to discuss is ... what should we use as input for user management REST API. 1) OpenID 2) email 3) both email and fullname | 19:07 |
| alexandrelevine | id | 19:08 |
| alexandrelevine | We can't use anything els | 19:08 |
| alexandrelevine | else | 19:08 |
| sslypushenko | OpenID for sure | 19:09 |
| alexandrelevine | Pretty much all of the REST APIs use ID if it's present as a primary means of identification | 19:09 |
| pvaneck | i liked the user search andrey had as a means of getting the id | 19:09 |
| alexandrelevine | pvaneck: +1 | 19:09 |
| catherineD | Even if we use OpenID (regardless of how the OpenID is fetched), Refstack need to check the user existing in RefStack table ... | 19:09 |
| sslypushenko | pvaneck: +1 | 19:09 |
| alexandrelevine | catherineD: What do you mean? | 19:10 |
| alexandrelevine | catherineD: In what scenario? | 19:10 |
| catherineD | add user | 19:10 |
| alexandrelevine | catherineD: Most of the cases working with REST API will look like this - UI lists users; client chooses which user to detail, for example; we send another REST API request with id to retrieve user details... | 19:11 |
| catherineD | alexandrelevine: I agree with UI but not totally agree with REST API | 19:12 |
| alexandrelevine | catherineD: User logs in with his OpenID and can self-register filling in all of the necessary fields and we'll fetch the rest automatically | 19:12 |
| alexandrelevine | catherineD: Sorry, not "logs in" - "signs in" | 19:12 |
| catherineD | alexandrelevine: keep in mind that adding a user is done by a admin not the user himself .. so the user does not log in in this case | 19:12 |
| alexandrelevine | catherineD: Why? | 19:12 |
| catherineD | why what? | 19:13 |
| alexandrelevine | catherineD: We won't have many users playing with our software if we make them to register through admin with hassles | 19:13 |
| alexandrelevine | catherineD: User should be able to come as Guest. And then self-sign-in and start playing with his clouds privately. | 19:13 |
| sslypushenko | alexandrelevine: +1 | 19:14 |
| alexandrelevine | catherineD: If he wants to become "official" - he'll register a Vendor | 19:14 |
| catherineD | alexandrelevine: we are talking about line 100 in https://review.openstack.org/#/c/277313/1/specs/mitaka/approved/vendor-user-management-api.rst | 19:14 |
| catherineD | sslypushenko: alexandrelevine: I do not think we talk about the same use case | 19:15 |
| catherineD | take a look at line 100 ...in https://review.openstack.org/#/c/277313/1/specs/mitaka/approved/vendor-user-management-api.rst | 19:15 |
| catherineD | that is the use case I am talking about | 19:15 |
| alexandrelevine | This is "list" case, right? | 19:16 |
| catherineD | no | 19:16 |
| catherineD | the case is to add a user to a vendor group .. that is making that user an admin of the vendor | 19:16 |
| alexandrelevine | Line 100? | 19:17 |
| alexandrelevine | It's under list section | 19:17 |
| catherineD | sorry my mistake ... line 128 | 19:17 |
| catherineD | we will come back to line 100 | 19:18 |
| catherineD | but a lot of the comments on line 100 are applicable to line 128 | 19:19 |
| alexandrelevine | Scenario will look like this: Vendor admin will find existing user in our DB by means of email or name or openID or just by paging and looking into a list of all users and clicks on it with action Add to Vendor (I'm simplifying the flow, but nevertheless). We'll take this user's ID and send request Add_user_to_Group with this ID. | 19:19 |
| alexandrelevine | catherineD: I think we can skip the case when Vendor admin adds user which hasn't previously signed in ever. | 19:20 |
| catherineD | alexandrelevine: so the goal is to add an user to a vendor ... | 19:20 |
| alexandrelevine | catherineD: So if user wants to administrate some Vendor he needs to first sign in and then he'll be added by Vendor admin as a co-admin. | 19:21 |
| alexandrelevine | Thus adding admin to vendor will require to choose one of existing users, take his id and pass it to the add call | 19:21 |
| catherineD | a REST API to add this vendor need input parameter. The input parameters can be 1) OpenID 2) email 3) email and name | 19:21 |
| alexandrelevine | 1 | 19:21 |
| alexandrelevine | only | 19:21 |
| alexandrelevine | email and/or name can be used only to find a particular user in find or list method | 19:22 |
| alexandrelevine | The rest of the calls, all actions and such are done with ID only. | 19:22 |
| alexandrelevine | It should be definitive, unique, unchangeable and only. ID all the way :) | 19:22 |
| catherineD | in this REST API in all cases, we will need to verify that the OpenID existing in RefStack user table ... | 19:22 |
| alexandrelevine | You just got it from our DB. | 19:23 |
| alexandrelevine | No need for further verification. | 19:23 |
| alexandrelevine | As I said, the ID is not entered manually by someone. | 19:23 |
| alexandrelevine | It's taken from the list we displayed ourselves previously fetching it from our DB | 19:23 |
| catherineD | so with 1, the user will need to perform 2 tasks 1) get the OpenID from somewhere (RefStack or OpenStack) 2) call RefStack API to add user to vendor | 19:24 |
| alexandrelevine | No | 19:24 |
| sslypushenko | alexandrelevine: I think it is not big deal to do such verification | 19:24 |
| alexandrelevine | No need. Come one. | 19:24 |
| alexandrelevine | Come on :) | 19:24 |
| catherineD | alexandrelevine: keep in mind I am at the REST API level where people can call the API with curls | 19:24 |
| alexandrelevine | When you add some user to group in Windows you first find this user by his name and then you are adding by SID. The same here. | 19:25 |
| sslypushenko | alexandrelevine: catherineD It is too deep tech details | 19:25 |
| catherineD | alexandrelevine: again I am not talking about UI design ... I am at REST API desing | 19:25 |
| catherineD | design | 19:25 |
| sslypushenko | we will discuss it on implementation stage | 19:26 |
| alexandrelevine | You mean that prior to adding such a user to group on the DB level you want to check that this id is in DB? I don't mind. I didn't think it's what we have to discuss :) | 19:26 |
| catherineD | sslypushenko: we need to define the spec for the REST API | 19:26 |
| alexandrelevine | sslypushenko:+1 | 19:26 |
| sslypushenko | catherineD: yeap, just don't dig too much | 19:27 |
| catherineD | The spec serve as a doc for people to know what REST API RefStack support | 19:27 |
| pvaneck | rest call would fail anyway if openid doesnt exist due to failing foreign key constraint right? | 19:27 |
| catherineD | sslypushenko: we are not ... we are just trying to define what is the input ofor the API | 19:27 |
| alexandrelevine | Input is ID | 19:28 |
| alexandrelevine | In all of our REST APIs working with objects we should work with IDs except for "find" or "list with filter" | 19:28 |
| sslypushenko | I think that it is obvious for all of us that API should be curl-safe) | 19:28 |
| alexandrelevine | sslypushenko: +1 | 19:28 |
| catherineD | sslypushenko: ++ | 19:29 |
| catherineD | so which input will be curl safe? | 19:29 |
| catherineD | pvaneck: I am checking the vendor table to see whether it is FK | 19:29 |
| alexandrelevine | catherineD: ID is the only input we can use here :) And we'll make it safe | 19:29 |
| alexandrelevine | catherineD: Does it matter? We can check in BL if not. | 19:30 |
| alexandrelevine | It shouldn't depend on the type of DB we use. If we store everything in json we still have to check. | 19:30 |
| catherineD | alexandrelevine: keep in mind the if you offer REST API ... any one can do curl and may not have the same BL as you have defined ... | 19:31 |
| alexandrelevine | It still doesn't matter. Even if we add a user with ID to Vendor which and such a user accidentally gets deleted from all of the tables except the Group ones we'll still be safe. | 19:32 |
| alexandrelevine | He'll have to log in and send authentication information with his curl or we won't listen about anything he says. | 19:32 |
| catherineD | pvaneck: you are right ...it is a FK ... | 19:32 |
| alexandrelevine | curl is not anonymous. | 19:33 |
| alexandrelevine | I mean it can be but we won't allow the action. | 19:33 |
| alexandrelevine | And if it has correct token with such a curl - it means we verified him against our DB. | 19:34 |
| catherineD | alexandrelevine: he who log in is not the OpenID that will be add | 19:34 |
| catherineD | added | 19:34 |
| alexandrelevine | He is. | 19:34 |
| alexandrelevine | In order to do anything it's him. | 19:34 |
| catherineD | so say alex is the admin in a vendor ABC but Caherine is not | 19:34 |
| alexandrelevine | You're talking about the case where we added someone as Vendor admin and later he'll come and do something nasty with curl, right? So in order to do this he'll still have to log in. | 19:35 |
| catherineD | Alex logs in to add Catherine to the vendor user ... it is Catheibe's OpenID that should be added not Alex's | 19:35 |
| alexandrelevine | Ok, Alex feels proud already :) | 19:35 |
| catherineD | :-) | 19:35 |
| alexandrelevine | Yes. And? | 19:35 |
| alexandrelevine | Alex searches for Catherine throughout the list of all users, selects Catherine's row and click add. | 19:36 |
| catherineD | so should the REST API that Alex curl to add Catherine use 1) Catherine 's OpenID 2) Cahterine's email 2) name and email | 19:36 |
| alexandrelevine | REST API request with Alex's token and Catherine's id goes to "add" request. | 19:36 |
| alexandrelevine | 1 of course | 19:37 |
| alexandrelevine | Again, we can't use email or name in anything else besides "find" or "list with filter" | 19:37 |
| catherineD | so Alex needs to do 2 tasks to add Catherine 1) get catherine openid 2) add catherine to the vendor | 19:37 |
| alexandrelevine | Yes. I explained how he gets Catherine's id. Through UI | 19:38 |
| catherineD | not if the input is 2 mail | 19:38 |
| alexandrelevine | I hope we won't try to work on usability of REST API for manual operations through curl?? :) | 19:38 |
| catherineD | then Alex just call the REST API with catherine email ... RefStack will take the email and get the OpenID from the RefStack user table and add to vendor | 19:38 |
| catherineD | alexandrelevine: if it is a REST API it should be callable by all tools supporting REST API call | 19:39 |
| sslypushenko | catherineD: It is not the best idea | 19:39 |
| alexandrelevine | curl is not a tool for end-user. It's a debugging tool. | 19:39 |
| sslypushenko | alexandrelevine: is right here | 19:39 |
| alexandrelevine | REST API is a programming facade. | 19:40 |
| sslypushenko | REST should use only user openid | 19:40 |
| alexandrelevine | It should complement different rules than UIs | 19:40 |
| sslypushenko | except "find" endpoint | 19:40 |
| alexandrelevine | REST API is not even a major facade. It's just a transport for normal API. So you can think of it in terms of python functions. Not curl. | 19:41 |
| catherineD | alexandrelevine: I disagree on it is not a major facade ... if we define REST we should abide to REST | 19:42 |
| alexandrelevine | We can decide to switch to binary protocol or SOAP later and curl won't work but nothing would change for end-user. | 19:42 |
| alexandrelevine | We will. To its syntax. | 19:42 |
| alexandrelevine | Semantics are determined by the objects API and model. | 19:42 |
| catherineD | so I take that both sslypushenko: alexandrelevine: go with OpenID as input for add user REST API? | 19:43 |
| alexandrelevine | yes | 19:43 |
| sslypushenko | +1 | 19:43 |
| catherineD | pvaneck: you? | 19:43 |
| pvaneck | Yes, as the input param to the rest call, assuming the user has a means to search for other users via their names/emails | 19:44 |
| catherineD | ok ...It is the team decisions 3 to 1 :-) | 19:45 |
| catherineD | I will change the spec to take OpenID | 19:45 |
| catherineD | before I go to the next topic | 19:45 |
| catherineD | sslypushenko: pvaneck: please review https://review.openstack.org/#/c/269066/ | 19:46 |
| catherineD | I think we are ready to merge that patch ... | 19:46 |
| sslypushenko | catherineD: will do | 19:47 |
| catherineD | sslypushenko: thx | 19:47 |
| *** krotscheck is now known as krotscheck_dcm | 19:47 | |
| catherineD | Next topic now back to line 100 | 19:47 |
| catherineD | when returning the list of user ... currently in https://review.openstack.org/#/c/277313/1/specs/mitaka/approved/vendor-user-management-api.rst | 19:48 |
| catherineD | only user name. email is returned ... | 19:48 |
| catherineD | shoud we add openid? | 19:48 |
| pvaneck | i think so | 19:48 |
| sslypushenko | +1 | 19:48 |
| alexandrelevine | Of course. | 19:48 |
| alexandrelevine | Otherwise nothing else would work :) | 19:49 |
| alexandrelevine | Because it takes id only | 19:49 |
| catherineD | ok | 19:49 |
| catherineD | #topic Vendor REST APIs | 19:50 |
| catherineD | spec: https://review.openstack.org/#/c/274837/ | 19:50 |
| catherineD | on list vendor ... | 19:51 |
| catherineD | currently the results are filter base on whether the request user is foundation admin or vendor admin ... | 19:52 |
| catherineD | pls see line 125 and 140 | 19:52 |
| catherineD | what do you think? | 19:52 |
| alexandrelevine | It's clear that the results should be limited to what user can see in terms of records. However I don't see why we want to limit some properties in those records. | 19:53 |
| alexandrelevine | I guess we should just return whole record if User has permissions to see it. | 19:53 |
| catherineD | alexandrelevine: we are not determine what should be seen per the permissions | 19:54 |
| catherineD | should any one see who create the vendor? | 19:54 |
| catherineD | and when | 19:54 |
| alexandrelevine | catherineD: It's not for us to decide. I suggest now we start with returning everything and in the meantime we ask DefCore. If they want to limit - we'll add requirement and create another patch. | 19:55 |
| alexandrelevine | catherineD: Until we released it we'll have plenty of time to adjust to what DefCore decides. | 19:55 |
| catherineD | alexandrelevine: as soon as you merge something is RefStack GitHub ... It is release .. | 19:56 |
| catherineD | released | 19:56 |
| alexandrelevine | catherineD: Let's not slow down development. It's really really complicated for Andrey to work with so many open reviews. He'd be able to work twice as fast if we were more flexible. | 19:56 |
| alexandrelevine | catherineD: Do you restart the service right away? That's a big problem. | 19:57 |
| catherineD | alexandrelevine: I would rather be slow and safe | 19:57 |
| alexandrelevine | catherineD: We should be able to commit and not show it until many more functionality is not there. | 19:57 |
| catherineD | alexandrelevine: yes | 19:57 |
| alexandrelevine | catherineD: We should separate contribution of several pieces and release of the new RefStack. | 19:57 |
| catherineD | we are in a CI and CD process ... anything merge will show up on the RefStack site 15 mins later | 19:58 |
| alexandrelevine | catherineD: Otherwise we'll end up in a situation where someone can register half the Vendor. Or register Vendor and not be able to do anything with it. And so on. | 19:58 |
| catherineD | alexandrelevine: you can see why I am very careful in merging code | 19:58 |
| alexandrelevine | catherineD: We should change it, I believe. | 19:58 |
| alexandrelevine | catherineD: We've got many pieces and some of them make no sense without others. | 19:59 |
| alexandrelevine | catherineD: Maybe we should go to branch then. | 19:59 |
| catherineD | alexandrelevine: that is why we selectively merge code based on impact ... | 19:59 |
| alexandrelevine | catherineD: Especially later, when the RefStack UI will be really used. We can't experiment on live users. | 19:59 |
| catherineD | but the Rest API pieces is very critical ... | 20:00 |
| alexandrelevine | catherineD: No it just won't work. | 20:00 |
| catherineD | as soon as the code is merge ... people can use it | 20:00 |
| alexandrelevine | catherineD: Contribution chunks and reviews are definitely smaller than a number of pieces required for next release. | 20:00 |
| alexandrelevine | catherineD: I think it's wrong. | 20:00 |
| alexandrelevine | catherineD: We'll have lots of trouble with it. Both development-wise and usage-wise. | 20:00 |
| sslypushenko | catherineD: It looks this approach will not work for now | 20:01 |
| alexandrelevine | catherineD: We should speed up development but separate it from releases. | 20:01 |
| sslypushenko | we should push new patches on production | 20:01 |
| sslypushenko | *should not | 20:01 |
| alexandrelevine | sslypushenko: +1. | 20:01 |
| catherineD | I am open on suggestion on how to fix it .. | 20:02 |
| catherineD | but that is how hosting on Infra is ... | 20:02 |
| catherineD | the code is from the project repository | 20:02 |
| sslypushenko | yeap it is clear | 20:02 |
| sslypushenko | And it is an issue | 20:02 |
| alexandrelevine | catherineD: We can start with a separate release branch from which the RefStack will be run. And you'll be moving some verified and ready snapshots (tags) of our repo when you decide it's ready. | 20:02 |
| sslypushenko | alexandrelevine: nope | 20:03 |
| alexandrelevine | sslypushenko: why not? | 20:03 |
| sslypushenko | it to complicated | 20:03 |
| alexandrelevine | It's usual practice. | 20:03 |
| sslypushenko | because it affects infra | 20:03 |
| alexandrelevine | How? | 20:03 |
| sslypushenko | we need add release branches | 20:04 |
| alexandrelevine | And? | 20:04 |
| sslypushenko | and it can be done only by infra) | 20:04 |
| alexandrelevine | I mean other projects produce packages (pypi, rpm, deb) when they are ready to release, right? | 20:05 |
| sslypushenko | it can be done | 20:05 |
| alexandrelevine | Let's produce something as solid. | 20:05 |
| sslypushenko | but it can slowdown the process | 20:05 |
| sslypushenko | I think we can solve current issue easier | 20:05 |
| alexandrelevine | Again, OpenStack projects develop in Master and when they are ready they set a Tag, right? Release tag. We can do similar thing. However, RefStack site should take only such released Tags. | 20:06 |
| sslypushenko | just review related patched one by one but squash it before merge | 20:06 |
| catherineD | sslypushenko: ++ that is what we are doing | 20:07 |
| sslypushenko | to keep behavior constent | 20:07 |
| catherineD | very careful in reviewing | 20:07 |
| sslypushenko | so just don't merge related patch before whole feature is not ready | 20:07 |
| alexandrelevine | Again, we can't release what we merge. | 20:07 |
| pvaneck | yea so currently our puppet repo is https://github.com/openstack-infra/puppet-refstack | 20:07 |
| alexandrelevine | We can't release the Vendors stuff we're about to merge. No way. | 20:07 |
| pvaneck | we use a module called vcsrepo where we can specify a branch or tag or whatever | 20:08 |
| alexandrelevine | And if we agree on it, then we'll understand that our merged patches are not the end of the world and we still have time to adjust until release. | 20:08 |
| sslypushenko | pvaneck: If you can handle it - it would be great | 20:08 |
| pvaneck | will have to look more into it and how we will be doing tags on our end | 20:10 |
| catherineD | in any way , it won't be quick | 20:10 |
| catherineD | because it involve a life site and other people | 20:11 |
| sslypushenko | you just ask someone on openstack-infra team | 20:11 |
| alexandrelevine | catherineD: So let's freeze current RefStack site now and separate it from the development repo | 20:11 |
| alexandrelevine | catherineD: Otherwise we should move to branc. | 20:11 |
| alexandrelevine | branch | 20:11 |
| catherineD | sslypushenko: just remember how long it takes us last time to get into infra | 20:11 |
| sslypushenko | but really, it will not happens quicly | 20:11 |
| alexandrelevine | we can't expose our half-baked processless Vendors. | 20:12 |
| alexandrelevine | And the rest of the stuff. | 20:12 |
| catherineD | alexandrelevine: ++ | 20:12 |
| alexandrelevine | Also I don't understand how can we expose any UI without some integration testing, at least manual/ | 20:12 |
| sslypushenko | alexandrelevine: other option is to push Vendors stuff in a single big patch | 20:12 |
| alexandrelevine | It just won't do. | 20:12 |
| catherineD | alexandrelevine: what ever being merge so far have no public facing ... so it is OK | 20:12 |
| alexandrelevine | sslypushenko: No! We need to have everything we decide is sufficient for next release ready and then test it. | 20:13 |
| alexandrelevine | sslypushenko: Not run around each single patch like it's a finished and polished thing. It's not the case. | 20:13 |
| catherineD | alexandrelevine: we can merge the code but just control permission | 20:13 |
| sslypushenko | alexandrelevine: in is case we should go to the infra team | 20:13 |
| sslypushenko | and ask for help | 20:13 |
| alexandrelevine | catherineD: The we should allow to merge more freely. That's what I begin from. | 20:14 |
| sslypushenko | alexandrelevine: Actually | 20:14 |
| alexandrelevine | What I'm saying is that we need to speed up development and unhook it from the release and the released site. | 20:14 |
| sslypushenko | I prefer your suggestion | 20:14 |
| catherineD | alexandrelevine: not in RefStack that things should merged freely ... we do review very carefully | 20:14 |
| sslypushenko | but it is risky) | 20:14 |
| alexandrelevine | catherineD: We should be much more agile (I hate this word) | 20:15 |
| alexandrelevine | catherineD: We can implement all that's planned or big part if we don't deal with each patch for that long. We should be always change and adjust in a frame of one sprint. Otherwise it won't work. | 20:16 |
| catherineD | depending on which agile angle .. | 20:16 |
| catherineD | This is not a PoC ... | 20:16 |
| sslypushenko | Lets stick to the point that we don't merge anything before clarifying the situation with tags | 20:16 |
| alexandrelevine | catherineD: The "agile" which allows to develop the functionality I listed in requirements in one quarter which is totally feasible. | 20:16 |
| catherineD | sslypushenko: I think we can merge a lot of things ... except for the public facing stuff | 20:17 |
| alexandrelevine | sslypushenko: Please keep in mind, that Andrey is pretty much stuck because of this hanging review. | 20:17 |
| alexandrelevine | catherineD: You won't be able to separate. | 20:17 |
| catherineD | alexandrelevine: do you think the review is helping so far? | 20:17 |
| alexandrelevine | catherineD: Sooner or later you'll catch something. | 20:17 |
| sslypushenko | alexandrelevine: +1 | 20:18 |
| catherineD | alexandrelevine: we do ... but I wnat to minimuze that ... and that is how RefStack is working so far | 20:18 |
| alexandrelevine | catherineD: Review is a necessary process, absolutely. It just should use a little different criteria and definitely not expect the merging result to be exposed right away in production. | 20:18 |
| catherineD | minimize | 20:18 |
| alexandrelevine | catherineD: You won't be able to "minimize". It doesn't work this way. | 20:19 |
| sslypushenko | so we need to adjust with infra workflow and that is it | 20:19 |
| catherineD | alexandrelevine: do you agree that we point out some aspects that you misse? | 20:19 |
| alexandrelevine | catherineD: You need just one major problem because of this minimization to sneak into production and that's it. | 20:19 |
| catherineD | ok let's end this call | 20:19 |
| alexandrelevine | Guys, can we right now freeze the exposed public site? | 20:19 |
| catherineD | I think meanwhile we can merge stuff that are not public facing | 20:19 |
| alexandrelevine | Thus we'll be able to move on with development. | 20:20 |
| alexandrelevine | catherineD: There is no such thing. | 20:20 |
| catherineD | user manage ment is one | 20:20 |
| alexandrelevine | catherineD: Our DB change is affecting public. | 20:20 |
| catherineD | specs are the other | 20:20 |
| catherineD | no DB change does not | 20:20 |
| alexandrelevine | catherineD: Specs - of course. I'm talking about code. | 20:20 |
| alexandrelevine | catherineD: How come it doesn't ? | 20:20 |
| alexandrelevine | catherineD: Because you are not upgrading the DB right away? | 20:21 |
| catherineD | this https://review.openstack.org/#/c/269066/ does not afrfect anything | 20:21 |
| catherineD | let's review and merge it | 20:21 |
| catherineD | alexandrelevine: even we upgrade ... it is just creating a table ... which the public site does not use | 20:21 |
| alexandrelevine | catherineD: I definitely agree on that one :) | 20:21 |
| pvaneck | should look into creating a tag in our repo, then switch puppet to use that tag for now | 20:21 |
| catherineD | pvaneck: you also need to think about the case when we will have bug fix | 20:22 |
| alexandrelevine | catherineD: No way. You can screw up the whole DB because me or Andrey introduced some critical bug. | 20:22 |
| catherineD | how do we tag code selectively | 20:22 |
| sslypushenko | catherineD: It is common workflow | 20:23 |
| alexandrelevine | catherineD: Has anyone tested the existing functionality with the new DB for real? | 20:23 |
| sslypushenko | just | 20:23 |
| catherineD | alexandrelevine: I always test every time I want to merge a patch | 20:23 |
| sslypushenko | just push patches to branch with tag | 20:23 |
| alexandrelevine | catherineD: With the UI? Whole thing? Wow! That's awesome, really. | 20:24 |
| catherineD | alexandrelevine: of course | 20:24 |
| alexandrelevine | catherineD: Do we have test plans? | 20:24 |
| catherineD | catherineD: not official one ... that is one of the bug that sslypushenko: create | 20:25 |
| catherineD | I should say kind of | 20:25 |
| catherineD | sslypushenko: suggests that we do scenario tests | 20:25 |
| alexandrelevine | Ok, we'd need them now that functionality is growing. | 20:25 |
| alexandrelevine | We'd need to test UI. Not just the REST API | 20:26 |
| catherineD | alexandrelevine:our work is base on priority | 20:26 |
| catherineD | Let's end this discussion today ... | 20:26 |
| alexandrelevine | ok | 20:27 |
| catherineD | I think Paul is going to look into tags release? | 20:27 |
| catherineD | sslypushenko: pvaneck: will try to review and merge https://review.openstack.org/#/c/269066/ | 20:27 |
| pvaneck | that or another branch | 20:27 |
| catherineD | pvaneck: sure | 20:27 |
| catherineD | Catherine will update https://review.openstack.org/#/c/277313/ | 20:28 |
| catherineD | anything else? | 20:28 |
| alexandrelevine | Ask defcore about visibility? | 20:28 |
| alexandrelevine | of properties | 20:28 |
| catherineD | alexandrelevine: ++ | 20:29 |
| catherineD | Catherine will confirm with DefCore to identify properties that can be exposed to any user | 20:30 |
| alexandrelevine | catherineD: Can we ask it from the other side, sort of? | 20:30 |
| alexandrelevine | catherineD: Do they want to hide any properties specifically? | 20:30 |
| catherineD | Ok thank you sslypushenko: alexandrelevine: pvaneck: .. | 20:30 |
| pvaneck | thanks | 20:31 |
| catherineD | alexandrelevine: we can will do that | 20:31 |
| sslypushenko | thanks | 20:31 |
| alexandrelevine | perfect. thanks | 20:31 |
| *** cjvolzka has joined #refstack | 20:43 | |
| *** alexandrelevine has quit IRC | 21:15 | |
| *** christiana has quit IRC | 21:42 | |
| *** Apsu has quit IRC | 21:48 | |
| *** hockeynut has quit IRC | 21:48 | |
| *** hockeynut has joined #refstack | 21:49 | |
| *** Apsu has joined #refstack | 21:50 | |
| *** cjvolzka has quit IRC | 22:31 | |
| *** catherineD has quit IRC | 23:00 | |
| *** catherineD has joined #refstack | 23:05 | |
| *** christiana has joined #refstack | 23:23 | |
| *** edmondsw has joined #refstack | 23:34 | |
| openstackgerrit | Catherine Diep proposed openstack/refstack: REST API specification for vendor user management. https://review.openstack.org/277313 | 23:43 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!