*** markstur has joined #openstack-manila | 00:21 | |
*** markstur has quit IRC | 00:25 | |
*** gcb has quit IRC | 00:29 | |
*** gcb has joined #openstack-manila | 00:31 | |
*** catintheroof has quit IRC | 00:52 | |
*** markstur has joined #openstack-manila | 00:53 | |
*** markstur has quit IRC | 00:57 | |
openstackgerrit | yangweiwei proposed openstack/manila master: Change to share access list API https://review.openstack.org/456819 | 01:16 |
---|---|---|
*** markstur has joined #openstack-manila | 01:24 | |
*** markstur has quit IRC | 01:28 | |
*** markstur has joined #openstack-manila | 01:40 | |
*** markstur has quit IRC | 01:44 | |
*** dsariel has quit IRC | 02:03 | |
*** markstur has joined #openstack-manila | 02:11 | |
*** markstur has quit IRC | 02:16 | |
*** yankee has joined #openstack-manila | 02:18 | |
*** markstur has joined #openstack-manila | 02:36 | |
*** markstur has quit IRC | 02:44 | |
*** markstur has joined #openstack-manila | 02:44 | |
*** gouthamr has joined #openstack-manila | 02:46 | |
*** markstur has quit IRC | 02:49 | |
*** markstur has joined #openstack-manila | 03:00 | |
*** markstur has quit IRC | 03:05 | |
zhongjun | bswartz: hi, in ensure share spec, why we remove the ensure_shares method? Could I let it back? https://review.openstack.org/#/c/446494 | 03:16 |
*** markstur has joined #openstack-manila | 03:31 | |
*** markstur has quit IRC | 03:36 | |
bswartz | zhongjun: I want to write a new version, and add it back | 03:44 |
openstackgerrit | zhongjun proposed openstack/manila-specs master: Add spec for autosized share https://review.openstack.org/452097 | 03:50 |
*** markstur has joined #openstack-manila | 04:03 | |
*** markstur has quit IRC | 04:08 | |
*** markstur has joined #openstack-manila | 04:34 | |
*** markstur has quit IRC | 04:39 | |
openstackgerrit | Ben Swartzlander proposed openstack/manila-specs master: Add spec for change ensure share to make startup faster https://review.openstack.org/446494 | 04:39 |
bswartz | zhongjun: if you want to tweak the spec further, you're welcome to | 04:40 |
bswartz | I'm going to bed now, we'll discuss the spec again at tomorrow's IRC meeting | 04:40 |
*** kaisers has joined #openstack-manila | 04:42 | |
*** kaisers has quit IRC | 04:47 | |
*** kaisers has joined #openstack-manila | 04:48 | |
zhongjun | bswartz: OK , see you tomorrow | 04:54 |
*** markstur has joined #openstack-manila | 05:06 | |
*** ganso has quit IRC | 05:06 | |
*** markstur has quit IRC | 05:10 | |
*** dsariel has joined #openstack-manila | 05:34 | |
*** gcb has quit IRC | 05:51 | |
*** gouthamr has quit IRC | 05:54 | |
*** winston-d_ has joined #openstack-manila | 06:03 | |
*** jprovazn has joined #openstack-manila | 06:18 | |
*** pcaruana has joined #openstack-manila | 06:40 | |
*** rraja has joined #openstack-manila | 06:55 | |
*** arnewiebalck_ has joined #openstack-manila | 07:35 | |
*** arnewiebalck_ has quit IRC | 07:44 | |
*** arnewiebalck_ has joined #openstack-manila | 08:02 | |
*** rraja has quit IRC | 08:29 | |
*** arnewiebalck_ has quit IRC | 08:36 | |
*** lpetrut has joined #openstack-manila | 09:32 | |
*** rraja has joined #openstack-manila | 09:34 | |
*** jprovazn has quit IRC | 10:28 | |
*** ganso has joined #openstack-manila | 10:38 | |
*** ociuhandu has joined #openstack-manila | 10:45 | |
*** yankee has quit IRC | 10:51 | |
tommylikehu | bswartz always have a short time for sleep | 10:55 |
*** jprovazn has joined #openstack-manila | 11:01 | |
*** winston-d_ has quit IRC | 11:03 | |
openstackgerrit | Merged openstack/manila-ui master: Update tox envlist https://review.openstack.org/457937 | 11:03 |
openstackgerrit | Merged openstack/manila master: Refactor and rename CephFSNativeDriver https://review.openstack.org/421201 | 11:05 |
openstackgerrit | Valeriy Ponomaryov proposed openstack/python-manilaclient master: Always use domain names and IDs for functional tests https://review.openstack.org/458453 | 11:07 |
*** kaisers_ has joined #openstack-manila | 11:17 | |
*** kaisers has quit IRC | 11:20 | |
*** openstackgerrit has quit IRC | 11:32 | |
*** dsariel has quit IRC | 11:49 | |
*** openstackgerrit has joined #openstack-manila | 12:16 | |
openstackgerrit | Valeriy Ponomaryov proposed openstack/python-manilaclient master: Use Identity v3 API always for functional tests https://review.openstack.org/458453 | 12:16 |
*** catintheroof has joined #openstack-manila | 12:27 | |
*** catintheroof has quit IRC | 12:30 | |
*** catintheroof has joined #openstack-manila | 12:30 | |
*** dsariel has joined #openstack-manila | 12:32 | |
rraja | tbarron: 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 IRC | 12:35 | |
*** dsariel has joined #openstack-manila | 12:37 | |
tbarron | rraja: hadn't seen it, thanks for the pointer | 12:37 |
rraja | csaba found it somehow. | 12:38 |
csaba | tbarron. 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 IRC | 12:40 | |
rraja | oh okay | 12:41 |
*** catintheroof has joined #openstack-manila | 12:41 | |
*** catintheroof has quit IRC | 12:41 | |
*** catintheroof has joined #openstack-manila | 12:41 | |
*** gcb has joined #openstack-manila | 12:43 | |
*** catintheroof has quit IRC | 12:43 | |
*** catintheroof has joined #openstack-manila | 12:43 | |
arnewiebalck | Trying 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 had | 12:50 |
arnewiebalck | specified an non-existent type, no? | 12:50 |
*** eharney has joined #openstack-manila | 12:51 | |
*** porrua has joined #openstack-manila | 13:00 | |
tbarron | arnewiebalck: that sounds right. Pls. file a bug ... | 13:15 |
arnewiebalck | tbarron: thx | 13:18 |
tbarron | arnewiebalck: 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 |
tbarron | arnewiebalck: is this per backend/pool, or per share? | 13:21 |
arnewiebalck | tbarron: per share | 13:21 |
arnewiebalck | tbarron: it’s basically to see how much of the handed out quota is used | 13:21 |
tbarron | arnewiebalck: how many shares do you have today, and how many do you expect to have? | 13:22 |
tbarron | on a single cephfs backend | 13:22 |
arnewiebalck | tbarron: we’re still in preprod, so the service is not opened to users yet | 13:22 |
tbarron | arnewiebalck: right | 13:22 |
arnewiebalck | tbarron: we have 27 shares today :) | 13:22 |
arnewiebalck | tbarron: ~18TB | 13:22 |
arnewiebalck | tbarron: we have ~3’500 Cinder volumes | 13:23 |
tbarron | arnewiebalck: do you expect a few thousand shares then? | 13:23 |
arnewiebalck | tbarron: I’d guess once users understand how to use shares we’ll have a few hundred maybe | 13:23 |
tbarron | ok | 13:23 |
tbarron | not thousands | 13:23 |
arnewiebalck | tbarron: probably not: shares are used by multiple nodes, volumes only by one | 13:24 |
tbarron | arnewiebalck: and how frequently would you need fill size updates? | 13:24 |
arnewiebalck | tbarron: once a day should be good enough | 13:24 |
tbarron | zhongjun: ^^^^^ relevant to the auto-size spec and valeriy's and my concern about usage updating ..., | 13:25 |
*** ociuhandu has quit IRC | 13:25 | |
tbarron | arnewiebalck: 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 IRC | 13:27 | |
tbarron | arnewiebalck: oh, I'll let you deal with your DB stuff in cinder :( | 13:27 |
arnewiebalck | tbarron: spaced out should be fine, it’s to avoid sudden surprises | 13:27 |
tbarron | arnewiebalck: thanks! | 13:27 |
tbarron | arnewiebalck: ok, one more $64000 question | 13:28 |
arnewiebalck | tbarron: sure! | 13:28 |
tbarron | arnewiebalck: 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 IRC | 13:29 | |
tbarron | arnewiebalck: for cephfs this just means removing the cephfs quota | 13:29 |
tbarron | that's enforced cooperatively by the cephfs client | 13:30 |
arnewiebalck | tbarron: that really is a $64000 question :) | 13:30 |
arnewiebalck | tbarron: quotas is a general issue with CephFS atm | 13:30 |
arnewiebalck | tbarron: we have some k8s clients, i.e. kernel, and there is no quota | 13:31 |
arnewiebalck | tbarron: and as you said the fuse one is only advisroy | 13:31 |
tbarron | arnewiebalck: 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-manila | 13:32 | |
arnewiebalck | tbarron: exactly: we assume users do not misuse the system on purpose | 13:32 |
arnewiebalck | tbarron: so the quotas is a proection for the service | 13:32 |
arnewiebalck | tbarron: so I’d think automatic resizing (and hence no quotas) is not what we (or the Ceph team) would want | 13:33 |
tbarron | arnewiebalck: ok, I just wanted to check :D | 13:33 |
tbarron | arnewiebalck: do you do any internal chargeback for resources? | 13:33 |
*** ociuhandu has joined #openstack-manila | 13:34 | |
*** ig0r_ has joined #openstack-manila | 13:34 | |
tbarron | arnewiebalck: 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 to | 13:34 |
tbarron | arnewiebalck: bill for actual usage rather than for the nominal size of the share. | 13:35 |
arnewiebalck | tbarron: we do not chargeback atm, but we’re considering showback to start with | 13:35 |
tbarron | arnewiebalck: k | 13:35 |
arnewiebalck | tbarron: but this is for cores, not storage | 13:36 |
arnewiebalck | tbarron: IIRC, we “charge” on quota, not usage | 13:36 |
tbarron | arnewiebalck: so in summary collection of fill info is useful/necessary for your cloud but not removal of share sizes. | 13:36 |
arnewiebalck | tbarron: correct | 13:36 |
*** gcb has quit IRC | 13:40 | |
*** ociuhandu has quit IRC | 13:41 | |
zhongjun | tbarron: hi~~~ | 13:42 |
tbarron | zhongjun: hi. arnewiebalck runs the cloud at CERN so I wanted to ask him about per-share usage collection needs. | 13:42 |
tbarron | zhongjun: 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 spec | 13:43 |
tbarron | zhongjun: and that vkmc is looking at for the ceilometer integration work. | 13:43 |
tbarron | zhongjun: So you can see why I personally emphasize the usage collection problem more than the infinite/auto-size problem at this stage. | 13:44 |
zhongjun | tbarron: so, you mean we could implement usage collection first? | 13:44 |
tbarron | zhongjun: yes, that is exactly what I have been trying to argue, | 13:44 |
vkmc | o/ | 13:45 |
zhongjun | tbarron: good, we could do it in the first step | 13:45 |
tbarron | zhongjun: 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 |
tbarron | zhongjun: and I think we don't have a full understanding of the use cases and a full design for it yet. | 13:46 |
tbarron | zhongjun: arnewiebalck just filled out his use case for us, but there may be others that need to be considered. | 13:46 |
zhongjun | tbarron: but we could also discuss about what the infinite share ought to be in IRC meeting | 13:48 |
tbarron | zhongjun: +1 | 13:48 |
tbarron | zhongjun: and think about whether for infinite share infrequent collection of usage info would be sufficient ... | 13:49 |
arnewiebalck | tbarron: zhongjun: apologies for my ignorance, but would infinite shares be tied to a share type? | 13:49 |
zhongjun | tbarron: If it is necessary, I will separate 1 spec to 2 | 13:49 |
tbarron | arnewiebalck: https://review.openstack.org/#/c/452097/ I will let zhongjun answer since it's her spec :D | 13:51 |
*** chlong has joined #openstack-manila | 13:51 | |
zhongjun | tbarron: yes, think about when we will really need usage info. | 13:52 |
zhongjun | arnewiebalck: 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 |
arnewiebalck | zhongjun: I’m reading the spec, but how do prevent a run-away script to fill up the backend? | 13:55 |
arnewiebalck | s/do/do you/ | 13:55 |
zhongjun | tbarron: In ensure share, Could we use get_backend_info name? | 13:57 |
zhongjun | arnewiebalck: 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 IRC | 14:01 | |
arnewiebalck | zhongjun: what would invoke shrink_share, and when? | 14:01 |
arnewiebalck | zhongjun: is that explained in the spec (haven’t finished reading)? | 14:01 |
zhongjun | arnewiebalck: manila shrink <share> <new_size>. just use manila CLI command. then the share size will be limited within new size | 14:04 |
zhongjun | arnewiebalck: Currently, the auto share just like a max size thin share. | 14:05 |
zhongjun | arnewiebalck: thin share with max size | 14:05 |
arnewiebalck | zhongjun: 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 |
arnewiebalck | zhongjun: how about limiting the autosize share to the quota of the tenant? | 14:06 |
*** rraja has quit IRC | 14:07 | |
tbarron | zhongjun: 'get_backend_info' seems to me more accurate thatn 'get_backend_config'. | 14:08 |
*** dsariel has joined #openstack-manila | 14:10 | |
*** esker has joined #openstack-manila | 14:11 | |
*** eharney has joined #openstack-manila | 14:14 | |
zhongjun | arnewiebalck: 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 IRC | 14:18 | |
*** gouthamr has joined #openstack-manila | 14:18 | |
*** esker has joined #openstack-manila | 14:18 | |
*** esker has quit IRC | 14:20 | |
*** rraja has joined #openstack-manila | 14:20 | |
*** esker has joined #openstack-manila | 14:21 | |
*** rraja has quit IRC | 14:25 | |
arnewiebalck | zhongjun: 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 |
arnewiebalck | zhongjun: How about limiting autosized shares by the project quota? | 14:27 |
zhongjun | arnewiebalck: oh, shrink doesn't remove some of their data. | 14:29 |
zhongjun | arnewiebalck: We have quota limit for user | 14:30 |
arnewiebalck | zhongjun: so, if the backend is full, how does shrink help you then? | 14:31 |
arnewiebalck | zhongjun: so, the autosized share would be limited to the user’s quota? | 14:31 |
zhongjun | arnewiebalck: Could you see line 44-55 in auto-size share spec? | 14:32 |
arnewiebalck | zhongjun: 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 |
zhongjun | arnewiebalck: 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 |
arnewiebalck | zhongjun: I will, thanks! :) | 14:38 |
zhongjun | yes, now, even with autosize shares a user would never be able to use more than his quota | 14:39 |
vponomaryov | arnewiebalck: hey | 14:40 |
vponomaryov | arnewiebalck: still around? | 14:40 |
bswartz | zhongjun ganso tbarron: a question was raised about where we store the hash for ensure_shares -- I accidentally left that out of the spec | 14:40 |
zhongjun | arnewiebalck: just in my spec, not other guys mind :D | 14:40 |
ganso | bswartz: I replied to a comment in the in spec review, I believe it should be stored in a field in shares table | 14:41 |
*** markstur has joined #openstack-manila | 14:41 | |
zhongjun | ganso: why share table, not store in share instance table? | 14:41 |
bswartz | ganso: we don't want to store it per-share | 14:41 |
vponomaryov | arnewiebalck: according to share type quotas, have you had some expectations for manila UI part? | 14:41 |
bswartz | just once per backend is enough | 14:41 |
arnewiebalck | zhongjun: all good then, isolating users/tenants from each other is important for operators :) | 14:41 |
arnewiebalck | vponomaryov: yes, still around | 14:42 |
ganso | bswartz, zhongjun: you're right, share replicas are supposed to be in different backends | 14:43 |
*** dgonzalez_ has joined #openstack-manila | 14:43 | |
*** mkoderer_ has joined #openstack-manila | 14:43 | |
arnewiebalck | vponomaryov: of course :-D | 14:43 |
zhongjun | bswartz: the hash value is related to host, I think we need to store it with 'host' | 14:44 |
vponomaryov | arnewiebalck: and where I can see it? )) | 14:44 |
*** dgonzalez_ has quit IRC | 14:45 | |
*** mkoderer_ has quit IRC | 14:45 | |
arnewiebalck | vponomaryov: it’d be of course nice if the per share type quota is reflected on the “Create Share" panel | 14:45 |
vponomaryov | arnewiebalck: you mean all quota-related things? | 14:45 |
vponomaryov | arnewiebalck: extend share? create snapshot? | 14:46 |
openstackgerrit | Ben Swartzlander proposed openstack/manila-specs master: Add spec for change ensure share to make startup faster https://review.openstack.org/446494 | 14:46 |
*** esker has quit IRC | 14:47 | |
*** rraja has joined #openstack-manila | 14:47 | |
bswartz | zhongjun: do we have a hosts table? | 14:47 |
bswartz | I can't find a table specific to hosts | 14:47 |
arnewiebalck | vponomaryov: 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 type | 14:47 |
vponomaryov | arnewiebalck: ok, clear | 14:48 |
arnewiebalck | vponomaryov: yes, that would apply to all quota related panels | 14:48 |
vponomaryov | arnewiebalck: that's all the expectations? | 14:48 |
arnewiebalck | vponomaryov: don’t know … feels a little bit like x-mas :-D | 14:48 |
vponomaryov | arnewiebalck: bombarded with questions? )) | 14:49 |
arnewiebalck | vponomaryov: do you have anything else in mind? | 14:49 |
arnewiebalck | vponomaryov: no, I describe and you say “ok!” | 14:49 |
vponomaryov | arnewiebalck: there are possible use cases, such as possibility to update quotas in admin panel | 14:49 |
arnewiebalck | vponomaryov: I understand, it’s only ‘expectations’ :-D | 14:49 |
arnewiebalck | vponomaryov: I don’t think we use the admin panel ever | 14:50 |
vponomaryov | arnewiebalck: nice )) | 14:50 |
vponomaryov | arnewiebalck: ok | 14:50 |
tbarron | http://www.zastavki.com/pictures/originals/2013/New_Year_wallpapers_Russian_Santa_Claus_051246_.jpg | 14:50 |
arnewiebalck | vponomaryov: but that’s how we do it | 14:50 |
arnewiebalck | tbarron: is that vponomaryov on the picture? | 14:51 |
vponomaryov | tbarron: this is GrandFather Moroz! ) | 14:51 |
tbarron | arnewiebalck: looks just like him :D | 14:51 |
arnewiebalck | tbarron: :-D | 14:51 |
zhongjun | bswartz: no, I think we don't have a hosts table. just need to store hash value and host_name in one table. | 14:51 |
vponomaryov | arnewiebalck: your expectations are just similar to mine | 14:52 |
arnewiebalck | vponomaryov: nice! | 14:52 |
bswartz | zhongjun: that's what I wrote in my spec update, but it would be better to reuse an existing table if we had one | 14:52 |
vponomaryov | arnewiebalck: and I just paid attention to absense of possiblity to set quotas via UI | 14:52 |
bswartz | arnewiebalck vponomaryov: you both have the same color in pidgin and it makes it impossible to read your conversations! | 14:52 |
vponomaryov | bswartz: not in case one of us mentions you ) | 14:53 |
arnewiebalck | bswartz: as we just find out: our expectations are similar as well | 14:53 |
zhongjun | bswartz: yes, I see it | 14:53 |
vponomaryov | arnewiebalck: now we mention bswartz togather and still have the same color ^_^ | 14:54 |
bswartz | argh | 14:54 |
vponomaryov | bswartz: can we merge this -> https://review.openstack.org/#/c/458453/ | 14:54 |
*** esker has joined #openstack-manila | 14:54 | |
vponomaryov | bswartz: fix for gates of client | 14:55 |
vponomaryov | it has been broken for some time | 14:55 |
vponomaryov | bswartz: ty | 14:55 |
bswartz | tbarron: I deleted your items from the meeting agenda because it looks like they all got addressed | 14:59 |
bswartz | lmk if we need to bring any back | 14:59 |
tbarron | bswartz: I think we're fine on that front. | 15:00 |
tbarron | it's late for this cycle but a number of the specs would have benefited from some simple sequence diagrams | 15:01 |
*** jmlowe has joined #openstack-manila | 15:02 | |
jmlowe | I'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 |
gouthamr | jmlowe: 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 create | 15:09 |
jmlowe | hmm, looks like if I set it to something it works, nova does not | 15:10 |
jmlowe | so 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-manila | 15:13 | |
*** pcaruana has quit IRC | 15:14 | |
gouthamr | jmlowe: are you using any stable branch, or are you on master? | 15:15 |
gouthamr | jmlowe: replies here will be slower until the weekly meeting ends in about 44 mins | 15:16 |
gouthamr | #openstack-meeting-alt | 15:16 |
jmlowe | I'm on newton | 15:16 |
arnewiebalck | jmlowe: gouthamr: not sure if I understood correctly, but ‘nova’ as avz works for me (on Newton) | 15:19 |
jmlowe | all of my compute nodes are in az zone-r[1-7], nothing is in zone nova | 15:20 |
gouthamr | jmlowe: are you using the generic driver? | 15:20 |
jmlowe | so when it does nova boot --zone nova, it fails, if it didn't pass a zone then it would succeed | 15:21 |
jmlowe | I am | 15:21 |
gouthamr | arnewiebalck jmlowe: when using the generic driver, your storage_availability_zone must match what you've configured on cinder and nova... | 15:21 |
jmlowe | if I don't give manila a zone it does nova boot --zone nova | 15:21 |
jmlowe | I'm backed by ceph, cinder only has nova and has been instructed to ignore zones | 15:22 |
arnewiebalck | gouthamr: sorry, I’m only using CephFS, so forget my input | 15:22 |
gouthamr | jmlowe: yep.. because "nova" is the default AZ when you don't specify it in your conf file.. its a legacy default.. | 15:22 |
gouthamr | jmlowe: 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 |
jmlowe | If I don't give manila a zone it shouldn't use one for nova boot, then everything would just work | 15:23 |
jmlowe | I break other things if i can't put my computes in different zones | 15:23 |
jmlowe | also, 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 match | 15:26 |
gouthamr | hmmm, 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 design | 15:33 |
*** dsariel has quit IRC | 15:40 | |
*** eharney has quit IRC | 15:42 | |
*** eharney has joined #openstack-manila | 15:46 | |
jmlowe | ah, 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 instances | 15:50 |
jmlowe | so pick let's say two computes in each zone and run share on them | 15:50 |
openstackgerrit | Merged openstack/python-manilaclient master: Use Identity v3 API always for functional tests https://review.openstack.org/458453 | 15:56 |
tommylikehu | --------meeting start again--------- | 16:00 |
bswartz | how many people want to see the filtering improvement happend during pike? | 16:00 |
bswartz | show of hands please | 16:00 |
tommylikehu | +1 | 16:00 |
gouthamr | o/ | 16:00 |
zhongjun | I want to see the new filter | 16:00 |
dustins | I would, yes | 16:00 |
vponomaryov | bswartz: simple "like" approach for names and description is ok | 16:01 |
vponomaryov | so, o/ | 16:01 |
bswartz | ganso tbarron xyang2 vponomaryov markstur: ^ | 16:01 |
*** jmlowe has quit IRC | 16:01 | |
ganso | bswartz: I don't have a very strong feeling about it | 16:01 |
markstur | i don't have a strong opinion on this one | 16:01 |
*** jmlowe has joined #openstack-manila | 16:01 | |
*** ig0r_ has quit IRC | 16:01 | |
tbarron | it's not a high priority for me but I'm not trying to block either. | 16:01 |
bswartz | I see 5 +1 | 16:01 |
bswartz | 3 abstain | 16:01 |
tbarron | There are lots of good ideas but I don't have customers asking for it. | 16:02 |
bswartz | seems like an extension makes sense here | 16:02 |
bswartz | please let's get this sorted out in the next week | 16:02 |
gouthamr | bswartz: +1 thanks. | 16:02 |
zhongjun | Could we define how the filter looks like? | 16:02 |
zhongjun | What | 16:03 |
zhongjun | just go back to the original spec? like filter? | 16:03 |
gouthamr | nope.. zhongjun, lemme post my comments. | 16:04 |
*** esker has quit IRC | 16:05 | |
zhongjun | oh | 16:08 |
zhongjun | We all agree with this? | 16:09 |
*** rraja has quit IRC | 16:10 | |
*** jmlowe has quit IRC | 16:14 | |
*** jmlowe has joined #openstack-manila | 16:15 | |
tommylikehu | any core would like to take a look at this patch when you free? https://review.openstack.org/#/c/440155/ | 16:20 |
zhongjun | gouthamr: thank you, | 16:21 |
zhongjun | tommylikehu: done | 16:22 |
*** jmlowe has quit IRC | 16:22 | |
*** jmlowe has joined #openstack-manila | 16:22 | |
bswartz | vponomaryov ganso: https://review.openstack.org/#/c/446494/ | 16:28 |
*** jmlowe has quit IRC | 16:29 | |
*** jmlowe has joined #openstack-manila | 16:30 | |
ganso | bswartz: I don't agree with it | 16:30 |
ganso | bswartz: I asked what to do when vendors don't implement get_backend_info() and general consensus was that we wouldn't run ensure_shares then | 16:31 |
ganso | bswartz: I think that is a step backwards. It is a performance improvement, but some vendors may lose functionality | 16:31 |
*** jmlowe has quit IRC | 16:46 | |
*** jmlowe has joined #openstack-manila | 16:46 | |
*** jmlowe has quit IRC | 17:10 | |
*** jmlowe has joined #openstack-manila | 17:11 | |
*** jmlowe has quit IRC | 17:19 | |
*** jmlowe has joined #openstack-manila | 17:19 | |
*** ig0r_ has joined #openstack-manila | 17:25 | |
bswartz | ganso: my proposal is that the default implementation returns an empty dict | 17:27 |
bswartz | that would always hash to the same value and cause ensure_share not to get called | 17:27 |
bswartz | for 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 spec | 17:28 |
bswartz | ganso: in what cases do you think it makes sense to call ensure_shares() on every startup? | 17:28 |
ganso | bswartz: 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 be | 17:30 |
ganso | motivation enough | 17:30 |
bswartz | ganso: 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 fine | 17:31 |
bswartz | the intention is to not break anything | 17:31 |
ganso | bswartz: 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 do | 17:32 |
ganso | bswartz: well, that's not what the comment repliers stated, they said that it was an unfortunate side-effect | 17:33 |
ganso | gouthamr: ^ | 17:33 |
bswartz | ganso: 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 way | 17:34 |
bswartz | we want to encourage drivers to not rely on the legacy behavior, and to behave better when restarting | 17:35 |
bswartz | we don't need to force anyone though, and we don't need to cause breakage | 17:35 |
*** jmlowe has quit IRC | 17:36 | |
*** jmlowe has joined #openstack-manila | 17:37 | |
ganso | bswartz: but who will implement the hack? the vendors? our implemention will break them by default then | 17:37 |
bswartz | ganso: no it should be part of the change that adds the feature | 17:38 |
bswartz | we just need a way to figure out which drivers actually rely on ensure_share getting called all the time vs which don't | 17:39 |
ganso | bswartz: I would like to see a clarification on that on the spec, basically what you just said above ^ | 17:41 |
bswartz | ganso: which section would be the best place to put that? | 17:42 |
ganso | bswartz: driver impact | 17:42 |
bswartz | work items? | 17:42 |
bswartz | oh okay | 17:42 |
openstackgerrit | Merged openstack/python-manilaclient master: Explicitly set 'builders' option https://review.openstack.org/457959 | 17:50 |
openstackgerrit | Merged openstack/python-manilaclient master: Use Sphinx 1.5 warning-is-error https://review.openstack.org/457976 | 17:50 |
openstackgerrit | Merged openstack/python-manilaclient master: doc: Remove cruft from conf.py https://review.openstack.org/457977 | 17:52 |
openstackgerrit | Ben Swartzlander proposed openstack/manila-specs master: Add spec for change ensure share to make startup faster https://review.openstack.org/446494 | 18:01 |
bswartz | ganso: ^ | 18:01 |
bswartz | does anyone have yankee's email address or know how to get in touch with him outside of IRC? | 18:02 |
ganso | bswartz: added comments | 18:04 |
ganso | bswartz: almost nits, except for "we will", which I think is important | 18:04 |
bswartz | the "we can" is a reference to the optional-ness of the get_backend_info override | 18:05 |
bswartz | the next paragraph specifies what we will actually do as part of this work | 18:05 |
bswartz | ganso: are you sure about class's -> class' ? | 18:05 |
ganso | bswartz: it is how I learned in school o_O | 18:05 |
bswartz | maybe I'm bad at english o_O | 18:06 |
bswartz | let me look that up | 18:06 |
ganso | bswartz: if the correct is class's my whole life has been a lie | 18:06 |
bswartz | https://english.stackexchange.com/questions/15609/how-do-you-write-a-classs-constructor | 18:06 |
ganso | both are correct lol | 18:06 |
bswartz | yeah this is a debatable case | 18:07 |
bswartz | there are cases in English where it's correct to drop the final s | 18:07 |
bswartz | but this isn't one | 18:07 |
ganso | bswartz: whoa I've never seen that | 18:07 |
ganso | bswartz: +2'ed | 18:08 |
bswartz | wait what about the other typo | 18:09 |
bswartz | you did find one mistake | 18:09 |
ganso | it is just a typo | 18:09 |
openstackgerrit | Ben Swartzlander proposed openstack/manila-specs master: Add spec for change ensure share to make startup faster https://review.openstack.org/446494 | 18:09 |
ganso | doesn't change the meaning of the sentence | 18:09 |
bswartz | still if I don't fix it gouthamr or xyang or tbarron will find it and -1 me | 18:10 |
bswartz | fixed ^ | 18:10 |
ganso | bswartz: lol I am sure they wouldn't -1 this one | 18:10 |
ganso | bswartz: thanks for fixing it | 18:10 |
vponomaryov | vponomaryov's 2 comments are ignored and he does not -1 )) | 18:10 |
* bswartz checks | 18:11 | |
*** jmlowe has quit IRC | 18:13 | |
*** jmlowe has joined #openstack-manila | 18:14 | |
openstackgerrit | Ben Swartzlander proposed openstack/manila-specs master: Add spec for change ensure share to make startup faster https://review.openstack.org/446494 | 18:14 |
bswartz | xyang1 vponomaryov vkmc arnewiebalck ganso tbarron zhongjun: based on people's availability, it's better to plan to meet at 1400 UTC Friday | 18:40 |
ganso | bswartz: ok | 18:41 |
bswartz | let's plan on that and I'll ping you all tomorrow morning | 18:41 |
xyang1 | Ok | 18:41 |
bswartz | this is regarding unlimited shares (I prefer unlimited to infinite) but we can talk about related concepts like auto-re-sizing etc | 18:42 |
bswartz | whoops cc markstur: ^ | 18:42 |
bswartz | hope I didn't miss anyone who expressed interest | 18:42 |
vkmc | bswartz, thx | 18:52 |
tbarron | bswartz: ack | 18:56 |
xyang1 | bswartz: will it be on this channel? | 18:58 |
bswartz | xyang1: I plan to host a webex like we did earlier this week for ensure_shares | 19:03 |
xyang1 | Ok | 19:03 |
bswartz | it's higher bandwidth and will hopefully get us all on the same page faster | 19:03 |
bswartz | we're writeup any decisions that were made for people who couldn't attend | 19:04 |
bswartz | s/we're/we'll/ | 19:04 |
xyang1 | bswartz: thanks | 19:06 |
*** jmlowe has quit IRC | 19:17 | |
*** jmlowe has joined #openstack-manila | 19:17 | |
*** zhonghua2 has quit IRC | 19:22 | |
*** zhonghua has joined #openstack-manila | 19:23 | |
*** jmlowe has quit IRC | 19:32 | |
*** jmlowe has joined #openstack-manila | 19:33 | |
gouthamr | https://media.giphy.com/media/xUySTMPTqceh0JkPrW/giphy.gif | 19:44 |
ganso | gouthamr: can't wait to watch that one | 19:46 |
*** jprovazn has quit IRC | 19:46 | |
openstackgerrit | Merged openstack/manila-specs master: Add spec for change ensure share to make startup faster https://review.openstack.org/446494 | 19:46 |
*** jmlowe has quit IRC | 19:49 | |
*** jmlowe has joined #openstack-manila | 19:49 | |
*** eharney has quit IRC | 20:08 | |
*** jmlowe has quit IRC | 20:10 | |
*** porrua has quit IRC | 20:13 | |
*** jprovazn has joined #openstack-manila | 20:34 | |
*** kaisers_ has quit IRC | 20:35 | |
*** jmlowe has joined #openstack-manila | 20:35 | |
*** dustins has quit IRC | 20:37 | |
*** cknight has joined #openstack-manila | 20:47 | |
*** jprovazn has quit IRC | 21:15 | |
*** catintheroof has quit IRC | 21:34 | |
*** kaisers has joined #openstack-manila | 21:35 | |
*** gouthamr has quit IRC | 21:57 | |
*** ganso has quit IRC | 22:26 | |
*** kaisers has quit IRC | 23:19 | |
*** gouthamr has joined #openstack-manila | 23:33 | |
*** abhi has joined #openstack-manila | 23:37 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!