Thursday, 2017-04-20

*** markstur has joined #openstack-manila00:21
*** markstur has quit IRC00:25
*** gcb has quit IRC00:29
*** gcb has joined #openstack-manila00:31
*** catintheroof has quit IRC00:52
*** markstur has joined #openstack-manila00:53
*** markstur has quit IRC00:57
openstackgerrityangweiwei proposed openstack/manila master: Change to share access list API  https://review.openstack.org/45681901:16
*** markstur has joined #openstack-manila01:24
*** markstur has quit IRC01:28
*** markstur has joined #openstack-manila01:40
*** markstur has quit IRC01:44
*** dsariel has quit IRC02:03
*** markstur has joined #openstack-manila02:11
*** markstur has quit IRC02:16
*** yankee has joined #openstack-manila02:18
*** markstur has joined #openstack-manila02:36
*** markstur has quit IRC02:44
*** markstur has joined #openstack-manila02:44
*** gouthamr has joined #openstack-manila02:46
*** markstur has quit IRC02:49
*** markstur has joined #openstack-manila03:00
*** markstur has quit IRC03:05
zhongjunbswartz: hi, in ensure share spec, why we remove the ensure_shares method? Could I let it back?   https://review.openstack.org/#/c/44649403:16
*** markstur has joined #openstack-manila03:31
*** markstur has quit IRC03:36
bswartzzhongjun: I want to write a new version, and add it back03:44
openstackgerritzhongjun proposed openstack/manila-specs master: Add spec for autosized share  https://review.openstack.org/45209703:50
*** markstur has joined #openstack-manila04:03
*** markstur has quit IRC04:08
*** markstur has joined #openstack-manila04:34
*** markstur has quit IRC04:39
openstackgerritBen Swartzlander proposed openstack/manila-specs master: Add spec for change ensure share to make startup faster  https://review.openstack.org/44649404:39
bswartzzhongjun:  if you want to tweak the spec further, you're welcome to04:40
bswartzI'm going to bed now, we'll discuss the spec again at tomorrow's IRC meeting04:40
*** kaisers has joined #openstack-manila04:42
*** kaisers has quit IRC04:47
*** kaisers has joined #openstack-manila04:48
zhongjunbswartz: OK ,  see you tomorrow04:54
*** markstur has joined #openstack-manila05:06
*** ganso has quit IRC05:06
*** markstur has quit IRC05:10
*** dsariel has joined #openstack-manila05:34
*** gcb has quit IRC05:51
*** gouthamr has quit IRC05:54
*** winston-d_ has joined #openstack-manila06:03
*** jprovazn has joined #openstack-manila06:18
*** pcaruana has joined #openstack-manila06:40
*** rraja has joined #openstack-manila06:55
*** arnewiebalck_ has joined #openstack-manila07:35
*** arnewiebalck_ has quit IRC07:44
*** arnewiebalck_ has joined #openstack-manila08:02
*** rraja has quit IRC08:29
*** arnewiebalck_ has quit IRC08:36
*** lpetrut has joined #openstack-manila09:32
*** rraja has joined #openstack-manila09:34
*** jprovazn has quit IRC10:28
*** ganso has joined #openstack-manila10:38
*** ociuhandu has joined #openstack-manila10:45
*** yankee has quit IRC10:51
tommylikehubswartz always  have a short time for sleep10:55
*** jprovazn has joined #openstack-manila11:01
*** winston-d_ has quit IRC11:03
openstackgerritMerged openstack/manila-ui master: Update tox envlist  https://review.openstack.org/45793711:03
openstackgerritMerged openstack/manila master: Refactor and rename CephFSNativeDriver  https://review.openstack.org/42120111:05
openstackgerritValeriy Ponomaryov proposed openstack/python-manilaclient master: Always use domain names and IDs for functional tests  https://review.openstack.org/45845311:07
*** kaisers_ has joined #openstack-manila11:17
*** kaisers has quit IRC11:20
*** openstackgerrit has quit IRC11:32
*** dsariel has quit IRC11:49
*** openstackgerrit has joined #openstack-manila12:16
openstackgerritValeriy Ponomaryov proposed openstack/python-manilaclient master: Use Identity v3 API always for functional tests  https://review.openstack.org/45845312:16
*** catintheroof has joined #openstack-manila12:27
*** catintheroof has quit IRC12:30
*** catintheroof has joined #openstack-manila12:30
*** dsariel has joined #openstack-manila12:32
rrajatbarron: maybe you already saw this? manila is mentioned here http://www.zdnet.com/article/ubuntu-17-04-the-bittersweet-linux-release/12:34
*** dsariel has quit IRC12:35
*** dsariel has joined #openstack-manila12:37
tbarronrraja: hadn't seen it, thanks for the pointer12:37
rrajacsaba found it somehow.12:38
csabatbarron. rraja : I guess they ripped it from here: https://insights.ubuntu.com/2017/04/13/ubuntu-17-04-supports-widest-range-of-container-capabilities/12:40
*** catintheroof has quit IRC12:40
rrajaoh okay12:41
*** catintheroof has joined #openstack-manila12:41
*** catintheroof has quit IRC12:41
*** catintheroof has joined #openstack-manila12:41
*** gcb has joined #openstack-manila12:43
*** catintheroof has quit IRC12:43
*** catintheroof has joined #openstack-manila12:43
arnewiebalckTrying to create a share with an existing but non-accessible (i.e. non-public) share type leads to an undeletable share stuck in “creating” (which needs an admin intervention to clean up). Even if the user cannot see the type in the first place and one could argue it is somewhat unlikely he’d end up in this situation, this looks like a bug to me. IMO it’d be better if Manila could react the same way as if the user had12:50
arnewiebalckspecified an non-existent type, no?12:50
*** eharney has joined #openstack-manila12:51
*** porrua has joined #openstack-manila13:00
tbarronarnewiebalck: that sounds right.  Pls. file a bug ...13:15
arnewiebalcktbarron: thx13:18
tbarronarnewiebalck: while I have you on the line, I remember that you mentioned wanting to track "fill status" when chatting with vkmc about ceilometer integration.13:21
tbarronarnewiebalck: is this per backend/pool, or per share?13:21
arnewiebalcktbarron: per share13:21
arnewiebalcktbarron: it’s basically to see how much of the handed out quota is used13:21
tbarronarnewiebalck: how many shares do you have today, and how many do you expect to have?13:22
tbarronon a single cephfs backend13:22
arnewiebalcktbarron: we’re still in preprod, so the service is not opened to users yet13:22
tbarronarnewiebalck: right13:22
arnewiebalcktbarron: we have 27 shares today :)13:22
arnewiebalcktbarron: ~18TB13:22
arnewiebalcktbarron: we have ~3’500 Cinder volumes13:23
tbarronarnewiebalck: do you expect a few thousand shares then?13:23
arnewiebalcktbarron: I’d guess once users understand how to use shares we’ll have a few hundred maybe13:23
tbarronok13:23
tbarronnot thousands13:23
arnewiebalcktbarron: probably not: shares are used by multiple nodes, volumes only by one13:24
tbarronarnewiebalck: and how frequently would you need fill size updates?13:24
arnewiebalcktbarron: once a day should be good enough13:24
tbarronzhongjun: ^^^^^ relevant to the auto-size spec and valeriy's and my concern about usage updating ...,13:25
*** ociuhandu has quit IRC13:25
tbarronarnewiebalck: do the fill status results for the shares need to be all at the same point in time, or can they be spaced out over the day?13:26
*** lpetrut has quit IRC13:27
tbarronarnewiebalck: oh, I'll let you deal with your DB stuff in cinder :(13:27
arnewiebalcktbarron: spaced out should be fine, it’s to avoid sudden surprises13:27
tbarronarnewiebalck: thanks!13:27
tbarronarnewiebalck: ok, one more $64000 question13:28
arnewiebalcktbarron: sure!13:28
tbarronarnewiebalck: if you could track usage per share and users could say "give me a share with automatic resizing" instead of specifying a size when they create the share, would you want that in your cloud?13:29
*** dsariel has quit IRC13:29
tbarronarnewiebalck: for cephfs this just means removing the cephfs quota13:29
tbarronthat's enforced cooperatively by the cephfs client13:30
arnewiebalcktbarron: that really is a $64000 question :)13:30
arnewiebalcktbarron: quotas is a general issue with CephFS atm13:30
arnewiebalcktbarron: we have some k8s clients, i.e. kernel, and there is no quota13:31
arnewiebalcktbarron: and as you said the fuse one is only advisroy13:31
tbarronarnewiebalck: right, because resources have to be controlled somehow, and still need to guard against filling the whole system up or runaway processing ...13:31
*** dustins has joined #openstack-manila13:32
arnewiebalcktbarron: exactly: we assume users do not misuse the system on purpose13:32
arnewiebalcktbarron: so the quotas is a proection for the service13:32
arnewiebalcktbarron: so I’d think automatic resizing (and hence no quotas) is not what we (or the Ceph team) would want13:33
tbarronarnewiebalck: ok, I just wanted to check :D13:33
tbarronarnewiebalck: do you do any internal chargeback for resources?13:33
*** ociuhandu has joined #openstack-manila13:34
*** ig0r_ has joined #openstack-manila13:34
tbarronarnewiebalck: some customers might want to set very high quotas so that end users don't have the inconvenience of resizing shares as they fill, but want to13:34
tbarronarnewiebalck: bill for actual usage rather than for the nominal size of the share.13:35
arnewiebalcktbarron: we do not chargeback atm, but we’re considering showback to start with13:35
tbarronarnewiebalck: k13:35
arnewiebalcktbarron: but this is for cores, not storage13:36
arnewiebalcktbarron: IIRC, we “charge” on quota, not usage13:36
tbarronarnewiebalck: so in summary collection of fill info is useful/necessary for your cloud but not removal of share sizes.13:36
arnewiebalcktbarron: correct13:36
*** gcb has quit IRC13:40
*** ociuhandu has quit IRC13:41
zhongjuntbarron:  hi~~~13:42
tbarronzhongjun: hi.  arnewiebalck runs the cloud at CERN so I wanted to ask him about per-share usage collection needs.13:42
tbarronzhongjun: even though he doesn't want to use auto/infinite shares in his cloud, he does want the space-collection that you also need for that spec13:43
tbarronzhongjun: and that vkmc is looking at for the ceilometer integration work.13:43
tbarronzhongjun: So you can see why I personally emphasize the usage collection problem more than the infinite/auto-size problem at this stage.13:44
zhongjuntbarron:  so, you mean we could implement usage collection first?13:44
tbarronzhongjun: yes, that is exactly what I have been trying to argue,13:44
vkmco/13:45
zhongjuntbarron: good, we could do it in the first step13:45
tbarronzhongjun: I think the usage collection is a necessary condition for your auto/infinite work, but also can stand on its own as a real need.13:45
tbarronzhongjun: and I think we don't have a full understanding of the use cases and a full design for it yet.13:46
tbarronzhongjun: arnewiebalck just filled out his use case for us, but there may be others that need to be considered.13:46
zhongjuntbarron:  but we could also discuss about what the infinite share ought to be in IRC meeting13:48
tbarronzhongjun: +113:48
tbarronzhongjun: and think about whether for infinite share infrequent collection of usage info would be sufficient ...13:49
arnewiebalcktbarron: zhongjun: apologies for my ignorance, but would infinite shares be tied to a share type?13:49
zhongjuntbarron: If it is necessary, I will separate 1 spec to  213:49
tbarronarnewiebalck: https://review.openstack.org/#/c/452097/  I will let zhongjun answer since it's her spec :D13:51
*** chlong has joined #openstack-manila13:51
zhongjuntbarron: yes, think about  when we will really need usage info.13:52
zhongjunarnewiebalck: The infinite shares could not tied to a share type. The infinite shares be tied to a share type in my spec, because of some backend don't support infinite share.13:54
arnewiebalckzhongjun: I’m reading the spec, but how do prevent a run-away script to fill up the backend?13:55
arnewiebalcks/do/do you/13:55
zhongjuntbarron: In ensure share, Could we use get_backend_info  name?13:57
zhongjunarnewiebalck: Before, I try to add a new driver interface (limit_size) to prevent a run-away script to fill up the backend.    now,  we can use shrink share command to prevent a run-away script to fill up the backend.13:59
*** eharney has quit IRC14:01
arnewiebalckzhongjun: what would invoke shrink_share, and when?14:01
arnewiebalckzhongjun: is that explained in the spec (haven’t finished reading)?14:01
zhongjunarnewiebalck:  manila shrink <share> <new_size>.   just use manila CLI command. then the share size will be limited within new size14:04
zhongjunarnewiebalck: Currently, the auto share just like a max size thin share.14:05
zhongjunarnewiebalck: thin share with max size14:05
arnewiebalckzhongjun: yes, but who is going to run a CLI command at 3am when the backend is full due to a runaway script (and all other client have to stop writing)?14:06
arnewiebalckzhongjun: how about limiting the autosize share to the quota of the tenant?14:06
*** rraja has quit IRC14:07
tbarronzhongjun: 'get_backend_info' seems to me more accurate thatn 'get_backend_config'.14:08
*** dsariel has joined #openstack-manila14:10
*** esker has joined #openstack-manila14:11
*** eharney has joined #openstack-manila14:14
zhongjunarnewiebalck: admin will going to run a CLI command, we have usage size, and the user will pay for usage size.  If the admin(or third part bill software) find the user is out of control, it will stop the user.14:16
*** esker has quit IRC14:18
*** gouthamr has joined #openstack-manila14:18
*** esker has joined #openstack-manila14:18
*** esker has quit IRC14:20
*** rraja has joined #openstack-manila14:20
*** esker has joined #openstack-manila14:21
*** rraja has quit IRC14:25
arnewiebalckzhongjun: Hmm, I’m not sure the approach of asking the admin to manually cut down the sizes of individual shares in case they filled up a backend (and affected other users) is practical, esp. if you have 1000’s of users. Also: what does happen to the data of the cut down share? I guess users won’t like it either if the admin removes some of their data.14:27
arnewiebalckzhongjun: How about limiting autosized shares by the project quota?14:27
zhongjunarnewiebalck: oh, shrink doesn't remove some of their data.14:29
zhongjunarnewiebalck: We have quota limit for user14:30
arnewiebalckzhongjun: so, if the backend is full, how does shrink help you then?14:31
arnewiebalckzhongjun: so, the autosized share would be limited to the user’s quota?14:31
zhongjunarnewiebalck: Could you see line 44-55 in auto-size share spec?14:32
arnewiebalckzhongjun: sorry, didn’t manage to read the spec yet … if I understand 44-55 correctly, even with autosize shares a user would never be able to use more than his quota?14:37
zhongjunarnewiebalck: now  auto-size share is a thin share with max size, we still need to discuss it in IRC meeting today.  welcome to join us.14:37
arnewiebalckzhongjun: I will, thanks! :)14:38
zhongjunyes,  now,  even with autosize shares a user would never be able to use more than his quota14:39
vponomaryovarnewiebalck: hey14:40
vponomaryovarnewiebalck: still around?14:40
bswartzzhongjun ganso tbarron: a question was raised about where we store the hash for ensure_shares -- I accidentally left that out of the spec14:40
zhongjunarnewiebalck: just in my spec, not other guys mind :D14:40
gansobswartz: I replied to a comment in the in spec review, I believe it should be stored in a field in shares table14:41
*** markstur has joined #openstack-manila14:41
zhongjunganso: why share table, not store in share instance table?14:41
bswartzganso: we don't want to store it per-share14:41
vponomaryovarnewiebalck: according to share type quotas, have you had some expectations for manila UI part?14:41
bswartzjust once per backend is enough14:41
arnewiebalckzhongjun: all good then, isolating users/tenants from each other is important for operators :)14:41
arnewiebalckvponomaryov: yes, still around14:42
gansobswartz, zhongjun: you're right, share replicas are supposed to be in different backends14:43
*** dgonzalez_ has joined #openstack-manila14:43
*** mkoderer_ has joined #openstack-manila14:43
arnewiebalckvponomaryov: of course :-D14:43
zhongjunbswartz:  the hash value is related to host, I think we need to store it with 'host'14:44
vponomaryovarnewiebalck: and where I can see it? ))14:44
*** dgonzalez_ has quit IRC14:45
*** mkoderer_ has quit IRC14:45
arnewiebalckvponomaryov: it’d be of course nice if the per share type quota is reflected on the “Create Share" panel14:45
vponomaryovarnewiebalck: you mean all quota-related things?14:45
vponomaryovarnewiebalck: extend share? create snapshot?14:46
openstackgerritBen Swartzlander proposed openstack/manila-specs master: Add spec for change ensure share to make startup faster  https://review.openstack.org/44649414:46
*** esker has quit IRC14:47
*** rraja has joined #openstack-manila14:47
bswartzzhongjun: do we have a hosts table?14:47
bswartzI can't find a table specific to hosts14:47
arnewiebalckvponomaryov: using Cinder as an (advanced) example: if a user picks the type, the quota section changes to the corresponding type and the user can see how much quota he has left for this type14:47
vponomaryovarnewiebalck: ok, clear14:48
arnewiebalckvponomaryov: yes, that would apply to all quota related panels14:48
vponomaryovarnewiebalck: that's all the expectations?14:48
arnewiebalckvponomaryov: don’t know … feels a little bit like x-mas :-D14:48
vponomaryovarnewiebalck: bombarded with questions? ))14:49
arnewiebalckvponomaryov: do you have anything else in mind?14:49
arnewiebalckvponomaryov: no, I describe and you say “ok!”14:49
vponomaryovarnewiebalck: there are possible use cases, such as possibility to update quotas in admin panel14:49
arnewiebalckvponomaryov: I understand, it’s only ‘expectations’ :-D14:49
arnewiebalckvponomaryov: I don’t think we use the admin panel ever14:50
vponomaryovarnewiebalck: nice ))14:50
vponomaryovarnewiebalck: ok14:50
tbarronhttp://www.zastavki.com/pictures/originals/2013/New_Year_wallpapers_Russian_Santa_Claus_051246_.jpg14:50
arnewiebalckvponomaryov: but that’s how we do it14:50
arnewiebalcktbarron: is that vponomaryov on the picture?14:51
vponomaryovtbarron: this is GrandFather Moroz! )14:51
tbarronarnewiebalck: looks just like him :D14:51
arnewiebalcktbarron: :-D14:51
zhongjunbswartz: no, I think we don't have a hosts table.  just need to store hash value and host_name in one table.14:51
vponomaryovarnewiebalck: your expectations are just similar to mine14:52
arnewiebalckvponomaryov: nice!14:52
bswartzzhongjun: that's what I wrote in my spec update, but it would be better to reuse an existing table if we had one14:52
vponomaryovarnewiebalck: and I just paid attention to absense of possiblity to set quotas via UI14:52
bswartzarnewiebalck vponomaryov: you both have the same color in pidgin and it makes it impossible to read your conversations!14:52
vponomaryovbswartz: not in case one of us mentions you )14:53
arnewiebalckbswartz: as we just find out: our expectations are similar as well14:53
zhongjunbswartz: yes, I see it14:53
vponomaryovarnewiebalck: now we mention bswartz togather and still have the same color ^_^14:54
bswartzargh14:54
vponomaryovbswartz: can we merge this -> https://review.openstack.org/#/c/458453/14:54
*** esker has joined #openstack-manila14:54
vponomaryovbswartz: fix for gates of client14:55
vponomaryovit has been broken for some time14:55
vponomaryovbswartz: ty14:55
bswartztbarron: I deleted your items from the meeting agenda because it looks like they all got addressed14:59
bswartzlmk if we need to bring any back14:59
tbarronbswartz: I think we're fine on that front.15:00
tbarronit's late for this cycle but a number of the specs would have benefited from some simple sequence diagrams15:01
*** jmlowe has joined #openstack-manila15:02
jmloweI'm giving manila a try.  I'm getting hung up creating my first share with this "The requested availability zone is not available" in the share server log.  Any hints?15:04
gouthamrjmlowe: couple of pointers: check your "storage_availability_zone" in manila.conf. also, check "manila service-list" and verify that your volume service is up for the backend configured and it is running in the zone you requested with your manila create15:09
jmlowehmm, looks like if I set it to something it works, nova does not15:10
jmloweso it seems it has to be specified and real unlike nova boot where you can just leave off the az and it will just stick it somewhere?15:10
*** hongbin has joined #openstack-manila15:13
*** pcaruana has quit IRC15:14
gouthamrjmlowe: are you using any stable branch, or are you on master?15:15
gouthamrjmlowe: replies here will be slower until the weekly meeting ends in about 44 mins15:16
gouthamr#openstack-meeting-alt15:16
jmloweI'm on newton15:16
arnewiebalckjmlowe: gouthamr: not sure if I understood correctly, but ‘nova’ as avz works for me (on Newton)15:19
jmloweall of my compute nodes are in az zone-r[1-7], nothing is in zone nova15:20
gouthamrjmlowe: are you using the generic driver?15:20
jmloweso when it does nova boot --zone nova, it fails, if it didn't pass a zone then it would succeed15:21
jmloweI am15:21
gouthamrarnewiebalck jmlowe: when using the generic driver, your storage_availability_zone must match what you've configured on cinder and nova...15:21
jmloweif I don't give manila a zone it does nova boot --zone nova15:21
jmloweI'm backed by ceph, cinder only has nova and has been instructed to ignore zones15:22
arnewiebalckgouthamr: sorry, I’m only using CephFS, so forget my input15:22
gouthamrjmlowe: yep.. because "nova" is the default AZ when you don't specify it in your conf file.. its a legacy default..15:22
gouthamrjmlowe: we don't have an option to ignore the zone in manila... you can set your compute AZ as your storage AZ then?15:23
jmloweIf I don't give manila a zone it shouldn't use one for nova boot, then everything would just work15:23
jmloweI break other things if i can't put my computes in different zones15:23
jmlowealso, manila shouldn't expose zones from nova, it should expose the union of the share server zones and nova compute zones, ie zone1,zone2,zone3 for nova but zone2,zone3 for manila share means you are presented with zone1 as a valid manila zone but if you select it the manila scheduler can't match15:26
gouthamrhmmm, if you're using the generic driver, its expected that manila-share is running alongside nova-compute so, its in the same zone... but what would solve your use case is the ignore_az option for the generic driver... i'd let vponomaryov weigh in because he has the most context with the generic driver's design15:33
*** dsariel has quit IRC15:40
*** eharney has quit IRC15:42
*** eharney has joined #openstack-manila15:46
jmloweah, that would also make the networking a little cleaner, wasn't too excited about running share on my controllers and having any sort of network path to instances15:50
jmloweso pick let's say two computes in each zone and run share on them15:50
openstackgerritMerged openstack/python-manilaclient master: Use Identity v3 API always for functional tests  https://review.openstack.org/45845315:56
tommylikehu--------meeting start again---------16:00
bswartzhow many people want to see the filtering improvement happend during pike?16:00
bswartzshow of hands please16:00
tommylikehu+116:00
gouthamro/16:00
zhongjunI want to see the new filter16:00
dustinsI would, yes16:00
vponomaryovbswartz: simple "like" approach for names and description is ok16:01
vponomaryovso, o/16:01
bswartzganso tbarron xyang2 vponomaryov markstur: ^16:01
*** jmlowe has quit IRC16:01
gansobswartz: I don't have a very strong feeling about it16:01
marksturi don't have a strong opinion on this one16:01
*** jmlowe has joined #openstack-manila16:01
*** ig0r_ has quit IRC16:01
tbarronit's not a high priority for me but I'm not trying to block either.16:01
bswartzI see 5 +116:01
bswartz3 abstain16:01
tbarronThere are lots of good ideas but I don't have customers asking for it.16:02
bswartzseems like an extension makes sense here16:02
bswartzplease let's get this sorted out in the next week16:02
gouthamrbswartz: +1 thanks.16:02
zhongjunCould we define how the filter looks like?16:02
zhongjunWhat16:03
zhongjunjust go back to the original spec?  like filter?16:03
gouthamrnope.. zhongjun, lemme post my comments.16:04
*** esker has quit IRC16:05
zhongjunoh16:08
zhongjunWe all agree with this?16:09
*** rraja has quit IRC16:10
*** jmlowe has quit IRC16:14
*** jmlowe has joined #openstack-manila16:15
tommylikehuany core would like to take a look at this patch when you free? https://review.openstack.org/#/c/440155/16:20
zhongjungouthamr: thank you,16:21
zhongjuntommylikehu: done16:22
*** jmlowe has quit IRC16:22
*** jmlowe has joined #openstack-manila16:22
bswartzvponomaryov ganso: https://review.openstack.org/#/c/446494/16:28
*** jmlowe has quit IRC16:29
*** jmlowe has joined #openstack-manila16:30
gansobswartz: I don't agree with it16:30
gansobswartz: I asked what to do when vendors don't implement get_backend_info() and general consensus was that we wouldn't run ensure_shares then16:31
gansobswartz: I think that is a step backwards. It is a performance improvement, but some vendors may lose functionality16:31
*** jmlowe has quit IRC16:46
*** jmlowe has joined #openstack-manila16:46
*** jmlowe has quit IRC17:10
*** jmlowe has joined #openstack-manila17:11
*** jmlowe has quit IRC17:19
*** jmlowe has joined #openstack-manila17:19
*** ig0r_ has joined #openstack-manila17:25
bswartzganso: my proposal is that the default implementation returns an empty dict17:27
bswartzthat would always hash to the same value and cause ensure_share not to get called17:27
bswartzfor drivers where it's important to call it every time, it's easy to achieve that behavior by putting a random number in the returned dict, but that goes against the point of what we're trying to achieve with this spec17:28
bswartzganso: in what cases do you think it makes sense to call ensure_shares() on every startup?17:28
gansobswartz: I don't know, it probably does not make sense for any vendor, but if one would want to motivate a vendor to implement the get_backend_info() method, we shouldn't implement something that causes loss of functionality when we could do it the other way. There are several improvements to any vendor by implementing get_backend_info(), and that should be17:30
gansomotivation enough17:30
bswartzganso: this change will cause rewriting of every driver's ensure_share function already -- if we also have to add get_backend_info() implementations to some drivers to preserve the existing (bad) behavior that's fine17:31
bswartzthe intention is to not break anything17:31
gansobswartz: if vendors have ensure_share running every time there is a database upgrade, or manila upgrade,  or certain conditions in the storage are met, those will not run at all if they don't implement get_backend_info(), and implementing the random number would be something we don't want them to do17:32
gansobswartz: well, that's not what the comment repliers stated, they said that it was an unfortunate side-effect17:33
gansogouthamr: ^17:33
bswartzganso: gouthamr's comment is accurate about the default case I think, but my point is that any individual driver that relies on the old behavior can be hacked to continue working the old way17:34
bswartzwe want to encourage drivers to not rely on the legacy behavior, and to behave better when restarting17:35
bswartzwe don't need to force anyone though, and we don't need to cause breakage17:35
*** jmlowe has quit IRC17:36
*** jmlowe has joined #openstack-manila17:37
gansobswartz: but who will implement the hack? the vendors? our implemention will break them by default then17:37
bswartzganso: no it should be part of the change that adds the feature17:38
bswartzwe just need a way to figure out which drivers actually rely on ensure_share getting called all the time vs which don't17:39
gansobswartz: I would like to see a clarification on that on the spec, basically what you just said above ^17:41
bswartzganso: which section would be the best place to put that?17:42
gansobswartz: driver impact17:42
bswartzwork items?17:42
bswartzoh okay17:42
openstackgerritMerged openstack/python-manilaclient master: Explicitly set 'builders' option  https://review.openstack.org/45795917:50
openstackgerritMerged openstack/python-manilaclient master: Use Sphinx 1.5 warning-is-error  https://review.openstack.org/45797617:50
openstackgerritMerged openstack/python-manilaclient master: doc: Remove cruft from conf.py  https://review.openstack.org/45797717:52
openstackgerritBen Swartzlander proposed openstack/manila-specs master: Add spec for change ensure share to make startup faster  https://review.openstack.org/44649418:01
bswartzganso: ^18:01
bswartzdoes anyone have yankee's email address or know how to get in touch with him outside of IRC?18:02
gansobswartz: added comments18:04
gansobswartz: almost nits, except for "we will", which I think is important18:04
bswartzthe "we can" is a reference to the optional-ness of the get_backend_info override18:05
bswartzthe next paragraph specifies what we will actually do as part of this work18:05
bswartzganso: are you sure about class's -> class' ?18:05
gansobswartz: it is how I learned in school o_O18:05
bswartzmaybe I'm bad at english o_O18:06
bswartzlet me look that up18:06
gansobswartz: if the correct is class's my whole life has been a lie18:06
bswartzhttps://english.stackexchange.com/questions/15609/how-do-you-write-a-classs-constructor18:06
gansoboth are correct lol18:06
bswartzyeah this is a debatable case18:07
bswartzthere are cases in English where it's correct to drop the final s18:07
bswartzbut this isn't one18:07
gansobswartz: whoa I've never seen that18:07
gansobswartz: +2'ed18:08
bswartzwait what about the other typo18:09
bswartzyou did find one mistake18:09
gansoit is just a typo18:09
openstackgerritBen Swartzlander proposed openstack/manila-specs master: Add spec for change ensure share to make startup faster  https://review.openstack.org/44649418:09
gansodoesn't change the meaning of the sentence18:09
bswartzstill if I don't fix it gouthamr or xyang or tbarron will find it and -1 me18:10
bswartzfixed ^18:10
gansobswartz: lol I am sure they wouldn't -1 this one18:10
gansobswartz: thanks for fixing it18:10
vponomaryovvponomaryov's 2 comments are ignored and he does not -1 ))18:10
* bswartz checks18:11
*** jmlowe has quit IRC18:13
*** jmlowe has joined #openstack-manila18:14
openstackgerritBen Swartzlander proposed openstack/manila-specs master: Add spec for change ensure share to make startup faster  https://review.openstack.org/44649418:14
bswartzxyang1 vponomaryov vkmc arnewiebalck ganso tbarron zhongjun: based on people's availability, it's better to plan to meet at 1400 UTC Friday18:40
gansobswartz: ok18:41
bswartzlet's plan on that and I'll ping you all tomorrow morning18:41
xyang1Ok18:41
bswartzthis is regarding unlimited shares (I prefer unlimited to infinite) but we can talk about related concepts like auto-re-sizing etc18:42
bswartzwhoops cc markstur: ^18:42
bswartzhope I didn't miss anyone who expressed interest18:42
vkmcbswartz, thx18:52
tbarronbswartz: ack18:56
xyang1bswartz: will it be on this channel?18:58
bswartzxyang1: I plan to host a webex like we did earlier this week for ensure_shares19:03
xyang1Ok19:03
bswartzit's higher bandwidth and will hopefully get us all on the same page faster19:03
bswartzwe're writeup any decisions that were made for people who couldn't attend19:04
bswartzs/we're/we'll/19:04
xyang1bswartz: thanks19:06
*** jmlowe has quit IRC19:17
*** jmlowe has joined #openstack-manila19:17
*** zhonghua2 has quit IRC19:22
*** zhonghua has joined #openstack-manila19:23
*** jmlowe has quit IRC19:32
*** jmlowe has joined #openstack-manila19:33
gouthamrhttps://media.giphy.com/media/xUySTMPTqceh0JkPrW/giphy.gif19:44
gansogouthamr: can't wait to watch that one19:46
*** jprovazn has quit IRC19:46
openstackgerritMerged openstack/manila-specs master: Add spec for change ensure share to make startup faster  https://review.openstack.org/44649419:46
*** jmlowe has quit IRC19:49
*** jmlowe has joined #openstack-manila19:49
*** eharney has quit IRC20:08
*** jmlowe has quit IRC20:10
*** porrua has quit IRC20:13
*** jprovazn has joined #openstack-manila20:34
*** kaisers_ has quit IRC20:35
*** jmlowe has joined #openstack-manila20:35
*** dustins has quit IRC20:37
*** cknight has joined #openstack-manila20:47
*** jprovazn has quit IRC21:15
*** catintheroof has quit IRC21:34
*** kaisers has joined #openstack-manila21:35
*** gouthamr has quit IRC21:57
*** ganso has quit IRC22:26
*** kaisers has quit IRC23:19
*** gouthamr has joined #openstack-manila23:33
*** abhi has joined #openstack-manila23:37

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!