15:00:23 #startmeeting manila 15:00:24 Meeting started Thu Oct 15 15:00:23 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:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:28 The meeting name has been set to 'manila' 15:00:31 Hi 15:00:32 Hello 15:00:33 hello all 15:00:38 hi 15:00:38 hello 15:00:41 hi 15:00:51 so today there is no real agenda 15:00:56 hi 15:00:56 it will be a short meeting 15:00:58 Hi 15:01:03 I have 2 things to mention 15:01:17 #topic liberty release 15:01:20 \o 15:01:53 liberty release is today -- there was an RC3 on tuesday to fix a critical bug which carried a bunch a gate-block-fixes back to liberty 15:02:05 hi 15:02:30 the main thing for you guys is that as you find bugs in mitaka, if they need backporting the correct tag is now "liberty-backport-potential" 15:03:09 bswartz: should we set also set "kilo-*" and "juno-*" tags? 15:03:24 thanks to all to tested the Liberty release and found and fixed bugs, I think it was very successful 15:04:07 also thanks to those who implemented new features and very special thanks to those who did the hard work of setting up CI systems for vendor drivers -- I know that work is not easy but I do believe it pays off 15:04:34 vponomaryov: stable/juno should go away very soon, and stable/kilo will only be open for security fixes 15:04:51 that's according the stable maintenance policy 15:04:53 bswartz: ah, ok, thanks 15:05:26 if there's any critical bugfixes that need backported to kilo, let's do it before the weekend 15:05:52 the other topic is 15:05:57 #topic mitaka design summit 15:06:05 #link https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Manila 15:06:32 those are the session I selected -- it's still possible to make changes though if someone has strong feelings 15:06:53 xyang1: I didn't get a chance to talk to you earlier about your session proposal: "minimum required features" 15:07:43 Can we talk about that at a work session? Or we are out of slots 15:07:46 xyang1: I didn't really understand what the point of that session would be and it didn't sound to me like a full 40 minute topic 15:08:01 we can if you think it needs a full 40 minutes and if you want to present something 15:08:08 I'll move something else to make room 15:08:11 Not need a full session, but we should decide on it 15:08:18 the alternative is to cover it a the contributor meetup 15:08:35 I know you have conflict between the manila contributor meetup and the cinder all-day meetup 15:08:38 I may not be able to make it on Friday 15:08:43 Right 15:09:15 xyang1: is it something we could cover during a weekly meeting? such as today or next week? 15:09:24 or does it require us all to be in a room together? 15:09:35 That is fine too 15:09:51 okay I want to make sure it gets the time it deserves 15:09:52 We need to make a decision and put on wiki 15:09:57 it just didn't feel like a full 40 minutes to me 15:10:16 I don't think it needs 40 minutes 15:10:18 ganso: you had an etherpad with minimum required features 15:10:28 (I think it was ganso) 15:10:30 bswartz: yes 15:10:38 However we spent lots of time talking about snapshot 15:10:42 did that ever get converted into a dev doc in the manila tree? 15:10:53 ganso: ^ 15:10:54 bswartz: no 15:11:03 okay well that's something we should probably do 15:11:07 Maybe this can be done via code reviews 15:11:16 xyang1: +1 15:11:17 +1 15:11:21 #link https://etherpad.openstack.org/p/manila-minimum-driver-requirements 15:11:22 xyang1: I made one the fishbowl sessions to discuss new snapshot semantics 15:11:40 because that topic will probably be of great interest to many people 15:11:55 I'm not sure if there are any other features which will invite a lot of discussion 15:11:59 bswartz: I suggested merging both subjects, but that would be up to xyang1 15:12:43 I'm in favor of managing that through code review 15:12:53 as far as I remember, during midcycle meetup, one of the topics was minimum required features and snapshot was 80% of the discussion 15:13:04 if we discover that there is another feature which invites a lot of discussion, then we can set aside time for those discussions 15:13:23 but I would bet that there's nothing else contentions 15:13:27 ganso: Yes, but that was whether basic snapshots would be part of the minimum set. We did agree they would not be. 15:13:36 contentious* 15:13:57 ganso: can you submit a patch before the summit 15:14:08 +1 for dev doc patch before summit 15:14:08 xyang1: yes 15:14:13 ganso: thanks 15:14:29 okay that's all I had for today 15:14:32 #topic open discussion 15:14:36 So we can start reviewing and make sure everyone agrees 15:14:54 If there are conflicts, we discuss at the summit 15:15:14 anyone else have something for this week? 15:15:17 I made a small change in Manila QoS design. 15:15:33 Manila QoS add a few common capabilities in qos-create command. 15:15:49 thanks Zhongjun 15:15:57 such as: manila qos-create [--max_kbps ] [--min_kbps ] [--max_iops ] [--min_iops ] [ ...] 15:16:12 Is it reasonable for that? 15:16:27 I suggest people review the QoS design before tokyo -- it's on the agenda to be discussed during the contributor meetup 15:17:03 * bswartz reminds himself to update the etherpads with topics 15:17:08 #link: https://wiki.openstack.org/wiki/Manila/QoS 15:17:54 Zhongjun: that's reasonable, it looks similar to what cinder has 15:18:16 I'm not convinced we want to copy cinder's design exactly, but if that's what others want then I would be okay with it 15:18:47 In particular I'm unclear on what "min" means 15:19:09 I want to hear from the vendors that can implement a min_iops and an min_kpbs what it means for their systems 15:19:20 min -> minimum 15:19:44 yes but how can it be enforced -- is it a hard limit or a soft limit? 15:19:55 for ceph, it would be useful to have a limit on the metadata op rate, separate from the data IOPS/bandwidth 15:20:07 we don't have QoS in there yet, but when we add it there'll certainly be a separate between data and metadata qos. 15:20:10 it seems it would have to be soft because if the whole system bogs down then nobody will get the minimums they were promised 15:20:41 jcsp: The design allows for backend-specific QoS keys. But common ones should be, well, common! 15:20:47 presumably vendors who implement qos minimums have a way to ensure their systems don't bog down, but I don't understand how that works 15:21:03 yes, for huawei, it would have to be soft 15:21:38 Zhongjun: it could just be a matter of documentation, to make sure users are clear on what it means 15:22:18 okay anything else for today? 15:22:19 bswartz: ok, I will add the detail about that. 15:23:11 alright thanks everyone 15:23:18 one more week to tokyo! 15:23:32 #endmeeting