15:00:03 #startmeeting manila 15:00:04 Meeting started Thu Jul 16 15:00:03 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:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:08 The meeting name has been set to 'manila' 15:00:11 hello all 15:00:17 hi 15:00:30 Hi 15:00:33 hi 15:00:37 hello 15:00:37 hi 15:00:41 hi 15:00:56 #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:01:07 looks like short agenda again 15:01:07 hi 15:01:36 I know it's vacation season and many people are in and out of the office 15:01:45 hi 15:01:46 #topic Midcycle Meetup 15:02:06 so the meetup is 2 weeks away! 15:02:08 o/ 15:02:37 I haven't heard from anyone who can travel so I'm assuming that it will be another mostly-remote midcycle meetup 15:02:43 #link https://etherpad.openstack.org/p/manila-liberty-midcycle-meetup 15:02:51 hi 15:02:55 I would still like to know who is joining remotely 15:03:00 please add your names to the etherpad 15:03:15 and I'm also looking for more topic proposals 15:03:35 bswartz: can you add meeting start and end time there also 15:03:38 there is plenty to talk about with all of the features we're currently working on, but I suspect not enough to fill up 2 days 15:03:42 xyang3: good idea 15:05:06 I was thinking 1300-2100 UTC 15:05:17 which is the same we did for the winter meetup 15:05:46 we could shorten that time if there aren't enough agenda topics 15:06:16 I've added the stuff I think it's important to talk about, but those topics probably only fill half the time 15:07:21 by next week I'll want to have scheduled times for each topic so if there aren't any new topic proposals I'll just make each day shorter 15:07:48 markstur: I just realized those times are really bad for you 15:07:56 bswartz, It's OK 15:08:05 I can just get up early 2 days 15:08:10 okay 15:08:21 I think that worked well last time. Better than going so late that people drop off 15:08:35 okay so that's all I have on the midcycle 15:08:38 Actually last time. Nobody showed up for the late sessions 15:08:44 please sign up if you're attending -- I'll send an ML post too 15:08:53 #action bswartz to send ML reminder about midcycle etherpad 15:09:16 #topic Python 3 support 15:09:29 so people have asked me when we're going to support python 3 15:09:46 the rest of openstack seems to be making significant progress 15:10:07 bswartz: yeah, we should add py3 unit tests job first 15:10:09 Most other projects have a gate-python34 job 15:10:33 any reason we can't just add gate-manila-python34? are there known bugs? 15:10:34 cool 15:10:50 bswartz: we can 15:10:51 most likely we won't know until we try 15:11:03 bswartz: sure, as non-voting until stabilization 15:11:10 lpabon: +1 15:11:13 +1 15:11:26 any volunteers to add the job? 15:11:39 * lpabon hears crickets 15:11:52 lpabon: you didn't wait long enough! 15:11:58 lol 15:11:59 :-D 15:12:00 lol 15:12:04 bswartz: it is easy, I can do it 15:12:07 okay well it shouldn't be too hard 15:12:30 just needs to be nonvoting initially 15:12:45 and after we have the job someone will need to file bugs for any detected issues 15:13:21 I know we spend some effort ensuring py3 compatibility even though we don't actively test it 15:13:41 my opinion is that we don't need to be leaders in py3 support, but we don't want to get too far behind the rest of openstack in that area 15:13:51 incidentally I feel the same way about ipv6 support 15:14:28 the lack of ipv6 support in openstack is a travesty, but I don't think this team's job is to go out and fix everything required to make it work 15:14:40 we should just make sure manila supports ipv6 15:15:21 #topic open discussion 15:15:29 that's all I had for today 15:15:37 anyone have something else they want to discuss 15:15:39 ? 15:15:40 bswartz: VNX CI started to report 15:15:50 xyang3: :D 15:15:56 bswartz: although there are still lots of failures 15:15:59 cool 15:16:13 bswartz: do you want us to turn it off until the failures are fixed 15:16:23 bswartz: otherwise it looks ugly 15:16:36 yes that reminds me I still owe several of you a 1on1 discussion about CI status 15:16:43 expect emails in the next week 15:16:51 xyang3: up to you 15:17:01 bswartz: ok, CI for Isilon is in progress 15:17:11 if it has a good chance of succeeding, leave it on -- if it's going to fail for sure, maybe turn off reporting 15:17:23 HP CI seems to have dropped off the radar 15:17:24 ok 15:17:28 it was reporting and now it's not 15:17:29 Yes 15:17:47 We had network changes and a lot of instability so it's not reporting. 15:17:51 Should be back though. 15:18:05 markstur: that's cool -- HP is still well ahead of the deadlines 15:18:29 thanks xyang3, markstur 15:18:31 Yeah. I went thru what xyang was saying about whether to turn it off 15:18:32 bswartz: we should talk about required features at the mid cycle? I don't think we settle it down yet 15:18:44 It actually is easier to track when it is on. There is that nice report. 15:18:47 xyang3: please add a proposal 15:18:53 ok 15:19:16 bswartz: that affects CI as well, so we know what tests are required and what can be skipped 15:20:00 yes it's something we should decide for sure 15:20:35 and by "we" I mean I don't want to dictate the minimum feature list, I want the community to agree 15:21:18 xyang3: are there any features in particular you have questions about? 15:21:33 bswartz: like readonly 15:21:43 bswartz: I know Isilon doesn't have it yet 15:21:48 the most common question I get is whether snapshots are required, and I find it really hard to imagine allowing manila without snapshots 15:21:56 #link https://etherpad.openstack.org/p/manila-minimum-driver-requirements 15:22:03 xyang3: I had assumed it was required, but that's worth a discussion 15:22:58 bswartz: I think if a feature is required, we should list that in wiki shortly after the summit 15:23:13 It seems a lot of drivers have "limitations" 15:23:14 bswartz: I'm saying it is late to add a requirement now for liberty 15:23:32 xyang3: why wiki? I guess it is better to have "doc" describing it 15:23:48 vponomaryov: some sort of official doc 15:23:57 I think at least some of those should become "capabilities" so we can just have a way to deal with what features to expect 15:24:01 early on 15:24:19 ganso_: thanks for the link 15:24:37 the plan for minimum features is to get them into the official developer docs 15:25:22 minimum features have been informal for a long time 15:25:38 I thought shrink share was optional... 15:25:44 having the list in the manila repo (which is where the dev docs are) will help I think 15:25:45 ganso_: +1 15:26:06 xyang3: about requirement for RO - generic driver supports only RW for CIFS 15:26:27 xyang3: so, I guess, we should require only RW 15:26:30 vponomaryov: ok, so that can't be required then 15:26:57 vponomaryov: ok. I thought that is tested in tempest 15:27:14 yeah i agree that this should not only be a doc but also part of some ci 15:27:24 I'd like to require read-only support 15:27:47 bswartz: but generic driver cannot do it for CIFS 15:27:50 but if there's a good reason it can't be implemented in certain cases then we have to find a way to communicate to the end user whether a share can support RO or not 15:27:56 But I think it varies by protocol access-type... 15:28:09 ganso_: it cannot do it currently, but that doesn't mean it can never be done 15:28:45 it would be simpler to find a way to make it work in all cases and then say it's just a required feature 15:28:50 optional features are always more messy 15:28:51 I think we should look into reporting capabilities so a share type can get the behavior it expects, but we don't have to pull a driver because it is different 15:28:56 bswart: so we need to have Liberty minimum requirements vs min requirements for the next release 15:29:12 Agree with the messy comment 15:29:14 I agree 15:29:35 just because we intend to make a new feature required doesn't mean everyone has to implement it immediately -- there can be some time delay 15:31:14 although the deadlines for when new features will be required is also something that needs to be agreed upon and clearly communicated 15:31:34 bswartz: +1 15:31:57 alright if there's nothing else we can end early today 15:32:01 bswartz: maybe we should use some tagging for drivers? 15:32:13 vponomaryov: tagging for what features are supported? 15:32:19 bswartz: yes 15:32:29 bswartz: by features or group of features 15:32:34 bswartz: all-required 15:32:37 if we agree features should be optional, then yes 15:32:39 bswartz: incubating 15:32:41 etc 15:32:41 vponomaryov, Good idea. Some master feature matrix at least 15:32:49 oh I see what you mean 15:33:37 all new drivers that does not have CI will have "incubating" or "sand-box" tag 15:33:44 s/does/do/ 15:33:58 After the deadline plan. Next we'd need a what to do with drivers that "can't" comply 15:34:00 yeah, the way I'd like to see it done, is that compliance with a new feature should be covered by tempest tests, and the group of tempest tests should be skippable as long as the feature is optional 15:34:20 I think tags sound better than moving them to stackforge 15:34:32 stackforge? 15:34:34 or to unofficial repos 15:34:34 once a feature becomes required it should no longer be skippable and backends that can't pass those tests need to do something 15:34:44 markstur: there is no requirement to something new in stackforgeanymore, AFAIK 15:34:59 to * have * 15:35:09 last I head, the plan was to delete stackforge and move everything to openstack namespace 15:35:09 I mean if a driver cannot do snapshots. Do we remove it. Where will it go. 15:35:31 It'll go somewher unofficial (let's say github) 15:35:32 markstur: that's not our problem 15:35:33 bswartz: really? then we'll have thousands of projects 15:35:47 Unless we have a way to tag it "sand-box", etc... 15:36:02 xyang3: it what I see discussed in TC/infra meetings 15:36:14 bswartz: wow 15:36:31 markstur: deleted drivers remain in the git history -- and they can be released any number of ways for users that want them 15:36:47 xyang3: our manila-image-elements project appeared in "openstack" namespace at once 15:37:25 I don't think this team should have an opinion on how drivers are released if they're not part of upstream -- personally I think out-of-tree drivers are harmless but should not be encouraged 15:37:36 vponomaryov: that is still a manila sub project. I'm not sure what happens to all the projects in general 15:38:06 xyang3: it is there because of reason bswartz described 15:38:26 xyang3: not because of manila is master-project 15:39:03 for those interested in the stackforge/openstack thing read the TC meeting minutes -- it has to do with the "big tent" concept and because infra is annoyed at having to rename projects from stackforge to openstack periodically 15:39:44 renaming projects is highly disruptive and serves no purpose other than to draw a boundary between an in-crowd and an out-crowd 15:40:11 bswartz: I'm just wondering if we can find a place to host a summit any more in the future, to fit in thousands of projects 15:40:27 Vegas 15:40:37 markstur :) 15:40:53 I don't think that suddenly every project in the openstack namespace gets time at the summit -- that's managed separately 15:41:12 this is just limited to the naming of the repos 15:41:13 bswartz: ok, let's see 15:41:29 okay we're pretty off-topic now 15:41:41 thanks everyone I think we're done 15:41:46 FYI -- I'm out-of-office tomorrow and next week. 15:41:54 I'll try to stay in touch to follow-up on reviews, but not sure how well that will work. 15:41:59 #endmeeting