15:00:18 <bswartz> #startmeeting Manila 15:00:19 <openstack> Meeting started Thu Dec 17 15:00:18 2015 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:23 <openstack> The meeting name has been set to 'manila' 15:00:27 <bswartz> hello all 15:00:28 <cknight> Hi 15:00:33 <ganso> hello 15:00:34 <dustins> \o 15:00:35 <tbarron> hi 15:00:37 <aovchinnikov> hi 15:00:57 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:00:58 <markstur_> hi 15:01:18 <xyang> hi 15:01:26 <gouthamr_> o/ 15:01:27 <vponomaryov> hi 15:01:34 <bswartz> #topic announcements 15:01:54 <bswartz> So I decided to cancel the next 2 meetings 15:02:08 <bswartz> due to the winter holidays 15:02:30 <gouthamr_> +1 15:02:31 <bswartz> I know many people won't be able to attend, and although some people will be working during that time, we don't really need to hold the meeting 15:02:53 <bswartz> so the next IRC meeting will be Jan 7th 15:03:30 <bswartz> #topic Proposal for share groups 15:03:45 <cknight> If you didn't see the ML post yesterday, please review the wiki. 15:03:51 <cknight> #link https://wiki.openstack.org/wiki/Manila/design/manila-generic-groups 15:04:02 <cknight> After building CGs, and then stepping back and looking at it, we think Manila will be much better served with a generic grouping construct. 15:04:02 <bswartz> #link http://lists.openstack.org/pipermail/openstack-dev/2015-December/082490.html 15:04:14 <cknight> That will enable all Manila actions for share groups on *any* driver, while still having the opportunity for drivers to provide a backend-specific advantaged implementation if possible. 15:04:30 <cknight> It would simplify and normalize the user experience. 15:04:39 <cknight> It would simplify development of future features. 15:04:46 <cknight> And it would make testing everything easier. 15:04:52 <cknight> To do this, we would morph the CG implementation into a generic group construct, add group types, and re-add CGs using the new framework. 15:05:02 <cknight> We would also build group support into the Manila UI (think tree table, perhaps?), so it would be easily usable by everyone. 15:05:09 <cknight> I tried to capture lots of implementation details in the wiki, but I'm sure y'all have questions. Thoughts? 15:05:15 <bswartz> So there was a preview of this last week 15:05:28 <bswartz> who has read the writeup? 15:05:33 <xyang> I have 15:05:38 <ganso> I do 15:05:38 <vponomaryov> I have 15:05:55 <ganso> s/do/have 15:05:55 <dustins> The wiki page? 15:05:58 <bswartz> any concerns? 15:06:02 <bswartz> dustins: yes 15:06:02 <cknight> dustins: yes 15:06:08 <dustins> Yup, I have 15:06:26 <vponomaryov> I like this idea 15:06:34 <dustins> This seems like a fantastic idea from a lot of different areas 15:06:44 <vponomaryov> just statement about two person-weeks efforts looks tooooo optimistic 15:06:46 <tbarron> i haven't had a chance to read it yet but got the early version in discussions 15:06:55 <cknight> Incidentally, we don't see this as a huge effort, since we already know where to touch the code to add groups. 15:07:11 <cknight> This should fit in M.2 if we choose to proceed. 15:07:22 <dustins> Better organization in the CLI and GUI, operations that spread across the groups, backend neutrality 15:07:37 <vponomaryov> cknight: you talk only about server side? 15:07:53 <vponomaryov> cknight: to fit M-2? 15:08:01 <dustins> Or rather spread across the members of a group 15:08:09 <cknight> vponomaryov: I think we'd do everything in parallel. 15:08:31 <cknight> vponomaryov: Only the UI might lag a bit, but doing groups in the UI becomes much more compelling than just for CGs. 15:09:00 <cknight> vponomaryov: So I hope we'd do server, client & UI in Mitaka. 15:09:00 <ganso> it looks like this will affect a lot existing APIs, should we consider this change a v3 candidate? 15:09:20 <cknight> ganso: No, it shouldn't affect many existing APIs. 15:09:23 <vponomaryov> ganso: microversions are used for such cases 15:09:26 <bswartz> ganso: the affected APIs should all be experimental ones 15:09:33 <cknight> ganso: CGs are experimental, so we can change those at will. 15:09:42 <ganso> what if I want to allow-access to a group of shares 15:10:06 <ganso> so that will be a new API command, existing allow-access to single share will remain the same then, right? 15:10:09 <xyang> One concern I have is if the group snapshot or group replication can be sometimes consistent and sometimes not, it could cause confusion to customers 15:10:11 <cknight> ganso: I think the APIs wouldn't be overloaded for shares & groups, so group APIs would be incremental. 15:10:54 <bswartz> xyang: that's true, but I don't see how this proposal makes things any worse than they already are 15:10:56 <cknight> xyang: That's fair. We could talk about public group extra specs for things that users need to know. 15:11:17 <bswartz> I think this proposal makes it better in some (but possibly not all) cases 15:11:18 <xyang> bswartz: that is inconsistent behaviour 15:11:29 <ganso> bswartz: +1 15:11:33 <xyang> if it is always consistent, then no confusion 15:12:17 <cknight> xyang: I'm not sure how it's different than shares that are sometimes deduped and sometimes not. Same for other extra specs. 15:12:21 <bswartz> I'm very against inconsistent behavior, but in cases where it can't be avoided, we have ways of dealing with it 15:12:37 <cknight> bswartz: +1 15:12:53 <bswartz> we've seen this with snapshot support and the solution is to make sure the user knows what he's going to get before he creates his first share 15:12:58 <vponomaryov> cknight: why add group type and not extend share type? 15:13:21 <xyang> cknight: dedupe is different. It could be where I'm coming from, I only know consistent group snapshot and replication 15:13:32 <cknight> vponomaryov: I had that thought as well, but Ben pointed out that the public extra specs on share types wouldn't map well to groups. 15:14:10 <vponomaryov> cknight: do you have example? 15:14:19 <vponomaryov> cknight: that would not fit? 15:14:37 <ganso> cknight: shouldn't all shares in a group be of the same type? 15:14:40 <bswartz> I know that administrators will find all the different capabilities challenging, but when I look at the various alternatives, cknight's proposal seems like the least bad option from the administrator's point of view (thinking about providing a consistent experience to his end users) 15:15:07 <cknight> vponomaryov: DHSS perhaps? Ben also wanted to be explicit about share types vs. share group types. I agree it would be possible and faster to reuse share types for this. 15:15:41 <bswartz> I think that group types are fundamentally different from share types 15:15:41 <cknight> ganso: Not necessarily. That wasn't true for CGs. 15:15:53 <ameade> I would like them as public extra specs, then i think it's easy enough as a user to know the abilities of a group 15:15:56 <dustins> Something where you could apply the share type to a share group and it would propagate to all members of the group? 15:16:16 <ameade> bswartz: +1 15:16:24 <cknight> ameade: +1 It should be simple to define a set of public group extra specs. I outlined several on the wiki. That should allay Xing's concern. 15:16:43 <ganso> cknight: that could complicate things a lot, thinking about migration... if I want to migrate a group, but a certain share in the group is not the same type, I may not be able to migrate all shares to the same destination backend anymore 15:17:28 <xyang> ganso: I'm worried about complexity too by adding a group type 15:17:37 <ameade> ganso: you already have that problem if you don't have other backends that match the share type 15:18:02 <xyang> When CG was first introduced in Cinder in Juno, it was supposed to be dependent on a Type Group too. It was in the first few revisions of the spec. 15:18:31 <xyang> It got dropped when someone raised concerns on how to support multiple Type Groups 15:18:32 <cknight> ganso: It does mean you would have to check each group member first to make sure each would be a valid migration target, but that doesn't sound terrible. And the problem already exists now, where you can create a CG with multiple share types. 15:18:48 <bswartz> whether it's a good idea to allow multiple share types in a group comes down to whether you agree with the use case for CGs -- that you want to split your dataset across 2 or more shares of different types and maintain consistency between them 15:18:51 <xyang> so it got dropped due to the increased complexity 15:19:16 <ganso> ameade: yes but would that migration succeed or fail? if fail because a single member does not fit, then it is the same as using a group type... being restrictive here reduces granularity and complexity 15:19:21 <ganso> cknight: ^ 15:19:46 <cknight> xyang: I can understand the reluctance at the time, but looking back now at all the complexity both projects have built, I'm looking for simplifying and unifying constructs. 15:19:48 <ganso> cknight: I did not participate in CG development, but would it be bad to have the restriction of same share types within a CG? 15:19:56 <ameade> it wouldn't fail due to a single member, it would fail because there is no other backend that could support the group 15:20:34 <ganso> ameade: exactly, the way I understand that is the same as the restriction 15:20:57 <xyang> ganso: initially the proposal was to support one volume type in one CG in Cinder, but quickly there are concerns that it should support multiple volume types 15:21:17 <xyang> ganso: so it is changed to support multiple volume types and the scheduler will pick one backend 15:21:31 <ameade> i think having mixed cgs is an important use case 15:21:42 <cknight> ganso: I'm not sure how restrictive that would be. But the problem isn't limited to CGs or migration. There will simply have to be logic that can evaluate the suitability of a backend to contain a group based on its type and its members' types. It's not that complicated. 15:22:25 <xyang> cknight: can we leverage share types rather than introducing another group type construct? 15:22:25 <bswartz> xyang: I know what you're talking about with the increased complexity, but after taking a look at what it will require to unify the new features we have (cgs, migration, replication) I worry that the complexity there is even worse. I think we've managed to fool ourselves into thinking we can graft features onto the side of Manila with little complexity because we're just delaying the costs until later 15:22:28 <ganso> xyang: a backend that supports all type variations within a CG then... that will restrict the number of destination backends. 15:22:40 <cknight> ganso: The goal would be to have that logic live in one place, so the migration, replication, etc. engines can use it as needed. 15:23:11 <xyang> ganso: we have to choose one backend though because there one manager that handles one backend 15:23:23 <xyang> ganso: this is a architecture limitation 15:23:36 <ganso> xyang, cknight: I understand now, thanks :) 15:24:39 <cknight> xyang: regarding another group type construct, that's what vponomaryov asked. It's possible, but Ben was keen to keep it separate for clarity. 15:25:10 <vponomaryov> cknight: is it going to be required ? 15:25:31 <cknight> vponomaryov: is what required? using groups? or group types? 15:25:44 <vponomaryov> cknight: usage of group types for each share 15:25:51 <cknight> vponomaryov: no 15:26:10 <ganso> vponomaryov: it seems the groupe type is related to group model, not share model 15:26:30 <bswartz> group types would be for groups -- shares don't have to go in a group -- and group could even have a default group type so you don't have to specify one if you don't care 15:26:32 <ganso> vponomaryov: and the share is part of a group, but is also still an individual share 15:26:41 <vponomaryov> cknight: ok, do we plan to allow existing share inclusion to some group later? 15:26:43 <cknight> vponomaryov: If there were no code in Manila today, we could choose to implement every share in its own group, but that is an implementation detail, and I think we're too far along to do that. 15:27:17 <ganso> vponomaryov: +1 15:27:30 <gouthamr_> vponomaryov 15:27:38 <cknight> vponomaryov: I think we could do that. We didn't allow that in the first release of CGs, so you could only assign group membership at either share or group creation time. 15:27:38 <gouthamr_> in that case the existing api should change 15:27:41 <xyang> cknight: what about add a share to a group or remove a share from a group? A non-pool group can support it but a pool group cannot 15:28:01 <cknight> vponomaryov: But I added 'group modification' to the list of group capabilities so we could consider that. 15:28:32 <ganso> cknight: just to confirm one thing, we are enforcing grouping, right? there will be no more shares without groups, a single share has to be a single group, right? 15:28:37 <bswartz> xyang: I think cknight said he was explicitly avoiding any pool-related groupings 15:28:50 <bswartz> pools are not groups in the current proposal 15:29:02 <xyang> bswartz: oh? 15:29:12 <bswartz> therefore pool-based replication is still out of scope 15:29:13 <gouthamr_> ganso: shares and groups are first class citizens as per the wiki.. as far as i understand, so shares can exist without groups 15:29:16 <xyang> bswartz: isn't the current CG implemented for a pool? 15:29:19 <bswartz> cknight: is that accurate? 15:29:42 <xyang> a different set of API for pool? 15:29:43 <bswartz> xyang: CGs can span pools, or not -- it's up to the backend 15:29:47 <cknight> bswartz: Yes. Pool-based replication or anything similar is fundamentally different, because a pool contains data from multiple tenants. 15:30:11 <bswartz> pools are never visible to the end user 15:30:21 <ganso> gouthamr_, cknight: having these two possibilities make for two possible branches of code, it may be very complicated to test every feature like this 15:30:26 <bswartz> pools are just for admins and for the scheduler 15:30:29 <xyang> cknight: so what about the existing CG snapshot? will that be supported by this new group? 15:30:36 <xyang> I'm confused 15:31:20 <bswartz> xyang: I think the proposal include ripping out the existing CG experimental APIs and replacing them with group-based consistent snapshot APIs 15:31:27 <ganso> xyang: the way I understand, the generic group would have the "consistent snapshot" group type, the backend would read that and do the consistent snapshot when snapshots are triggered 15:31:29 <cknight> xyang: This proposal replaces the Manila CG implementation. The admin creates a group with the CG extra spec, and the user creates a group of that type and invokes snapshot on it. 15:32:06 <cknight> xyang: When the group snapshot call arrives in the manager, the manager sees that the type of that group is CG, so it hands it off to the driver for handling. 15:32:08 <xyang> cknight: so my question is still relevant then. the existing CG implementation cannot add/remove share 15:32:46 <cknight> xyang: Yes, your question is definitely relevant. It's up to all of us to decide whether group membership can change anytime, or only at share / group creation time. 15:33:06 <bswartz> xyang: the solution there is to make add/remove from group an optional feature, some drivers may support it and others may not 15:33:45 <xyang> bswartz: ok, that's big difference between pool-based and non-pool-based grouping 15:33:54 <cknight> bswartz: +1 I think that's unavoidable, since some backends can't change CG membership anytime. That's why I suggested the 'group_modification' extra spec. 15:33:58 <gouthamr_> bswartz: +1 Manila could allow it, and fail if the driver doesn't support it. 15:34:24 <cknight> xyang: But since type creation is always admin-only, it's up to the admins to create the types correctly. 15:34:31 <markstur_> We should try to avoid "adds" that make group actions turn into "no host found" 15:34:36 <ganso> if we enforce this restriction, it may be simple for backends, because AFAIK, for CG to work, the shares have to be created in a previously defined CG... so having both behaviors (generic that allows add/remove and generic with CG extra-spec) would increase complexity 15:35:21 <ganso> backends would need to know to behave both ways if they support CG 15:35:30 <ganso> the ones that don't, need to implement add/remove 15:35:30 <xyang> If this is a loose grouping, it implies that there should be a possibility to add/remove 15:35:53 <bswartz> ganso: one issue that I've learned is that CGs work very differently on different platforms, and we don't always agree on what aspect of a CG matters most 15:36:14 <ganso> markstur_: +1 15:36:30 <bswartz> ganso: this proposal allows us to capture the important features of a CG -- such as "can take a consistent snapshot" and "can replicate with mutually ordered writes" and advertise them individually 15:36:57 <xyang> ganso, markstur_, when you add share to a group, you provide a share type, which is already supported by the group 15:37:22 <ganso> I like the idea of "group_modification" extra-spec because it can be added later, we could start simple by enforcing "create share in a group" 15:37:28 <xyang> ganso, markstur_: actually that is create and add. If it is add, it doesn't go thru scheduler 15:37:33 <cknight> ganso: +1 That was my thought. 15:37:39 <ameade> ganso: +1 15:37:41 <dustins> ganso: +1 15:37:49 <markstur_> xyang, I'm thinking that with multiple share types, the group might function until a share of the 2nd type shows up and then smoe feature won't find a target anymore 15:38:00 <cknight> ganso: A lot of this can be done incrementally. We do the groups & group types first, then vertical slices adding one grouped action at a time. 15:38:03 <markstur_> That's probably an admin mistake, but still would be annoying 15:38:33 <ameade> markstur_: i dont think that could happen because you schedule the group based on all the share types 15:38:36 <xyang> markstur_: if admin changes things afterwards, it affects not only CG but everything else 15:38:46 <ameade> so it would end up on a backend that can do all of them 15:39:11 <cknight> ameade: yes 15:39:25 <markstur_> what if migrate can't find a place that suits the whole group 15:39:46 <markstur_> The group coud be valid and claim "migration_support", but no host found 15:39:50 <ameade> then you're sol 15:39:53 <markstur_> I don't know how to solve that one 15:39:54 <xyang> markstur_: you create a share which does not support dedupe as defined in the type; now admin adds dedupe support to the same type. now what happens to the existing share? 15:40:01 <bswartz> markstur_: the same issue could happen with migration of single shares 15:40:44 <ganso> markstur_: the destination backend would need to support all the share types within that group that is being migrated... else it can't be migrated 15:41:08 <bswartz> xyang: changes to share types have never affected existing shares of that type 15:41:16 <markstur_> Again it probably comes down to the admin needs to know how to do it right 15:41:25 <bswartz> generally we advise against modifying a share type after it's been used 15:41:33 <ameade> bswartz: but how does that currently play with migration? 15:41:46 <ameade> bswartz: yeah the best way is to have immutable share types, but is that practical? 15:41:48 <xyang> bswartz: understood. I'm saying now if you look at the type and the share, how can you tell whether it support dedupe or not by the type 15:41:58 <bswartz> ameade: it works if you're clever, or lucky 15:42:31 <bswartz> xyang: actually that's not true for the reason you just mentioned 15:43:12 <xyang> bswartz: the share type says dedupe enabled, but the share does not have it 15:43:26 <bswartz> xyang: if the admin changes the share type, then that can happen 15:43:32 <ganso> xyang: I don't understand, why wouldn't it? 15:43:46 <ganso> bswartz: +1 15:43:52 <xyang> bswartz: the share was created before that 15:43:56 <bswartz> we considered this issue when thinking about snapshot support -- you can create a share type without snapshot support, and create some shares, then later modify the type to have snapshot support 15:44:33 <bswartz> you can't rely on the share type to know if the share has snapshot support or not, therefore we store in the share itself whether it had snapshot support at the time of creation 15:44:39 <xyang> bswartz: unless if you are saying the admin will go to the array and manually change things 15:45:01 <gouthamr_> bswartz : or replication_type in share replication. 15:45:35 <bswartz> if there are other aspects that manila needs to know about -- we have to store those with the shares -- we can never rely on the share type to know the actual capabilities of any given share 15:45:42 <ganso> xyang, bswartz: those are probably going to be the case where shares may have to be migrated (or re-created), even in the same backend, in order to support those features... most of them cannot be simply enabled/disabled on backends after share has been created 15:45:50 <bswartz> this is a downside of mutable share types 15:46:33 <xyang> ganso: if that is involved, yes. I have got bug report because someone just changed type without doing anything for existing shares on the array 15:46:43 <ganso> xyang, bswartz: this is something retype API has to handle... I do not see this as a problem for the generic groups approach at this moment 15:46:49 <ganso> xyang: using manage/unmanage? 15:46:56 <bswartz> okay I know this discussion could keep going, but we need to move on to other topics 15:47:21 <xyang> ganso: if you do those steps, yes. 15:47:30 <bswartz> please keep providing feedback on the proposal 15:47:55 <ganso> xyang: that is a bad practice I would say... that's why manage/unmanage is admin-only, the admin needs to know carefully what he is doing 15:47:58 <cknight> Yes, please keep the feedback coming! 15:48:07 <bswartz> cknight: some concrete examples of how your proposal might play out would probably help 15:48:11 <cknight> Don't hesitate to update the wiki. 15:48:16 <cknight> bswartz: OK, will do. 15:48:37 <bswartz> give an example of a multi-vendor deployment with some real complexity, and show how group types makes that tractable 15:48:53 <cknight> bswartz: Sure. 15:49:21 <bswartz> #topic Liberty.1 stable release 15:49:36 <bswartz> so it's come to my attention that we're late with our liberty.1 release 15:50:04 <bswartz> there's not a fixed schedule, but generally the other project lined up their liberty.1 releases with the mitaka-1 milestone 15:50:24 <bswartz> so I'm going to tag a liberty.1 as soon as I can manage it 15:50:36 <bswartz> I'm merging stuff that's been backported today 15:50:51 <bswartz> did anyone else have something that urgently needs backporting? 15:51:12 <bswartz> some distros are looking at liberty.1 as their base for their downstream branches 15:51:29 <vponomaryov> bswartz: there are manila-ui bug that should be done and backported 15:51:52 <vponomaryov> bswartz: current latest mailaclient release 1.5.0 not compatible with mainla-ui 15:51:52 <bswartz> vponomaryov: fixed in master already? 15:52:03 <bswartz> vponomaryov: yes we need releases of manilaclient too 15:52:04 <vponomaryov> bswartz: current fix broke it actually 15:52:10 <bswartz> :-( 15:52:21 <vponomaryov> bswartz: but added support of not released latest client 15:52:44 <vponomaryov> bswartz: you can find chat logs about it today in manila channel 15:52:56 <bswartz> okay so ignoring the client and UI -- is there anything in the manila project that needs backporting? 15:52:57 <vponomaryov> bswartz: toabctl made heads up 15:53:24 <bswartz> I need to spend more time catching up on the client issues, but I think the server is almost there 15:53:57 <bswartz> okay I'll read about the client problems 15:54:08 <bswartz> that's all I had to say about liberty.1 15:54:36 <bswartz> #topic open discussion 15:54:40 <zhongjun> A little question: Did we need to separation of user to user and group in Access_allow API. 15:54:40 <zhongjun> eg: access-allow %share% group %group_name% 15:54:40 <zhongjun> Because we can not distinguish between user and user groups from only user name. 15:54:51 <toabctl> bswartz: there is https://review.openstack.org/#/c/257358/ which I would like to have fixed in liberty 15:55:23 <bswartz> toabctl: this isn't merged in master yet 15:55:40 <bswartz> let's prioritize reviews of that one so it can get a workflow today and the backport can start 15:55:50 <bswartz> I'll hold off on a liberty.1 tag until that backport happens 15:55:54 <vponomaryov> bswartz: Ci feels bad today 15:56:01 <toabctl> bswartz: ok 15:56:05 <bswartz> vponomaryov: indeed 15:56:16 <bswartz> the new gerrit system is ..... weird 15:56:29 <cknight> bswartz: +1 Very weird. 15:56:33 <ganso> bswartz: +1 15:56:34 <toabctl> bswartz: +1 . it was weird but now it's even more weird 15:56:34 <zhongjun> +1 15:56:42 <gouthamr_> as with every GUI upgrade :D 15:56:50 <vponomaryov> bswartz: zhongjun had a question 15:57:05 <bswartz> zhongjun: to answer your question -- we don't currently 15:57:10 <dustins> that is weird 15:57:37 <zhongjun> But how to deal with this problem? 15:57:45 <bswartz> zhongjun: I'm not opposed to changing that if there's a good reason to, but so far nobody has had a problem with using the same API for doing CIFS group access 15:58:09 <bswartz> the driver/backend is supposed to figure out if the user is actually a group and do the right thing 15:58:32 <ganso> bswartz: that seems like a good alternative 15:59:04 <bswartz> typically user names and group names don't overlap 15:59:31 <bswartz> and when they do, the current manila behaviour is undefined 16:00:07 <bswartz> so if someone has a problem with that undefined behaviour, propose an API change to make groups explicit 16:00:09 <xarses> time check 16:00:15 <bswartz> xarses: I'm aware 16:00:24 <zhongjun> typically user names and group names don't overlap. All of this like this? 16:00:45 <bswartz> thanks everything I think we're done 16:00:54 <bswartz> #endmeeting