Thursday, 2016-11-17

*** absubram has quit IRC00:02
*** cknight has quit IRC00:25
*** david-lyle_ is now known as david-lyle00:35
*** ameade has quit IRC00:57
*** ameade has joined #openstack-manila00:57
openstackgerritVictoria Martinez de la Cruz proposed openstack/manila-ui: Moves OPENSTACK_MANILA_SETTINGS TO local_settings.d/  https://review.openstack.org/39792601:12
openstackgerritzhongjun proposed openstack/manila-specs: Add spec for enable IPv6 in manila  https://review.openstack.org/36278601:18
openstackgerritzhongjun proposed openstack/manila-specs: Add spec for enable IPv6 in manila  https://review.openstack.org/36278601:31
*** tuanluong has joined #openstack-manila02:06
openstackgerritzhongjun proposed openstack/manila-specs: Add detail API to quota-set API collection  https://review.openstack.org/39005202:37
*** kaisers_ has joined #openstack-manila02:44
*** kaisers_ has quit IRC02:49
openstackgerritYingzhe Zeng proposed openstack/manila: Change huawei driver to only pass needed info while replica creating  https://review.openstack.org/39871703:05
*** kaisers_ has joined #openstack-manila03:31
*** kaisers_ has quit IRC03:35
openstackgerritzhongjun proposed openstack/manila-specs: Add detail API to quota-set API collection  https://review.openstack.org/39005204:38
*** lpetrut has joined #openstack-manila04:59
*** cdelatte has quit IRC05:08
*** wiebalck has joined #openstack-manila05:18
*** wiebalck has joined #openstack-manila05:19
*** digvijay2016 has joined #openstack-manila05:19
*** vponomaryov has quit IRC05:33
*** kaisers_ has joined #openstack-manila05:47
*** kaisers_ has quit IRC05:51
*** nkrinner_afk is now known as nkrinner06:00
*** lpetrut has quit IRC06:02
*** wiebalck has quit IRC06:10
*** belmoreira has joined #openstack-manila06:25
*** dsariel has joined #openstack-manila06:38
*** pcaruana has joined #openstack-manila07:18
openstackgerritPony Chou proposed openstack/manila: Add QNAP Manila Driver  https://review.openstack.org/39470307:26
openstackgerritPony Chou proposed openstack/manila: Add QNAP Manila Driver  https://review.openstack.org/39470307:32
*** kaisers_ has joined #openstack-manila07:48
*** akapil has joined #openstack-manila07:49
*** kaisers_ has quit IRC07:52
*** akapil has quit IRC07:53
*** nkrinner is now known as nkrinner_trainin07:56
*** lpetrut has joined #openstack-manila08:00
*** jprovazn has joined #openstack-manila08:02
*** nherciu has joined #openstack-manila08:09
*** kaisers_ has joined #openstack-manila08:23
*** akapil has joined #openstack-manila08:25
*** akapil has quit IRC08:29
*** gouthamr has joined #openstack-manila08:45
openstackgerritMerged openstack/manila: devref/driver_requirements: add cephfs protocol  https://review.openstack.org/39856408:53
*** igajsin has joined #openstack-manila08:57
*** cknight has joined #openstack-manila09:03
*** cknight1 has joined #openstack-manila09:04
*** akapil has joined #openstack-manila09:05
*** gouthamr has quit IRC09:05
*** akapil has quit IRC09:07
*** cknight has quit IRC09:07
*** akapil has joined #openstack-manila09:11
*** TommyLikeHu has quit IRC09:12
*** TommyLikeHu has joined #openstack-manila09:13
*** akapil has quit IRC09:14
TommyLikeHuhey any core member can take a look at this spec? https://review.openstack.org/#/c/390052/  much thanks~09:14
*** gouthamr has joined #openstack-manila09:15
*** ociuhandu has joined #openstack-manila09:21
*** akapil has joined #openstack-manila09:25
openstackgerritXiaoyang Zhang proposed openstack/manila: Fix extend operation of shrinked share in generic driver  https://review.openstack.org/39358909:31
*** rraja has joined #openstack-manila09:37
*** dsariel has quit IRC09:44
*** openstackgerrit has quit IRC09:48
*** openstackgerrit has joined #openstack-manila09:49
*** cknight1 has quit IRC09:49
*** akapil has quit IRC09:50
arnewiebalck_rraja: Good morning! Horizon logs for the dirty auth meta issue are here: http://paste.openstack.org/show/589553/09:57
arnewiebalck_rraja: IIRC, the user tried to create two rules which both ended in error, he deleted them, then he successfully recreated one.09:59
openstackgerritXiaoyang Zhang proposed openstack/manila: Fix share-service VM restart problem  https://review.openstack.org/39359410:03
*** akapil has joined #openstack-manila10:04
openstackgerritXiaoyang Zhang proposed openstack/manila: Fix share-service VM restart problem  https://review.openstack.org/39359410:08
*** akapil has quit IRC10:08
rrajaarnewiebalck_: hey! i'm checking the logs. thanks!10:14
*** jcsp has quit IRC10:16
rrajaarnewiebalck_: it's not clear to me from the horizon logs how the dirty auth meta issue was hit. can you share the corresponding errors that might have been recorded in m-shr or m-api logs when the user's access rules ended in error state?10:19
*** vponomaryov has joined #openstack-manila10:19
arnewiebalck_rraja: I think these are the relevant lines: http://paste.openstack.org/show/589555/10:24
arnewiebalck_rraja: from m-shr10:25
*** akapil has joined #openstack-manila10:26
*** akapil has quit IRC10:26
*** akapil has joined #openstack-manila10:27
*** dsariel has joined #openstack-manila10:33
*** tpsilva has joined #openstack-manila10:36
*** ganso has joined #openstack-manila10:36
rrajaarnewiebalck_: i'm wondering if the problematic code in ceph_volum_client is the same as is for the issue http://tracker.ceph.com/issues/17800 reported by toabctl.10:36
rrajaarnewiebalck_: can you share the request/sent json which triggered this traceback?10:37
arnewiebalck_rraja: As I didn’t have debugging enabled at the time, I don’t think I have that.10:41
arnewiebalck_rraja: This would be in the client’s (i.e. the m-shr side’s) Ceph logs, right?10:42
*** ociuhandu has quit IRC10:43
arnewiebalck_rraja: It may very well be that we manoeuvered ourselves into this situation as we touched the caps in order to work around some CephFS issues with Manila created shares.10:47
rrajaarnewiebalck_: i'm not sure. but checking the ceph client logs is a good idea.10:47
arnewiebalck_rraja: The client logs are basically empty.10:47
rrajaarnewiebalck_: okay.10:48
rrajaarnewiebalck_: so you're saying that it's possible that the mon caps of the auth IDs created by manila/volume client were manipulated outside manila/volumeclient?10:50
arnewiebalck_rraja: Absolutely, yes. The problem would probably not have occurred if I didn’t share the office with our Ceph admin :)10:51
*** gouthamr has quit IRC10:53
rrajaarnewiebalck_: oh okay. :) but it'll be interesting to know why this error was hit, as basically what the volumeclient does is fetch the existing mon caps of auth ID and reapplies it. so unless the MON caps of the auth ID was unset/not set as was the case in the tracker issue I already pointed out this error shouldn't have occurred? anyway I'll try figuring out how this error could've happened.10:56
arnewiebalck_rraja: this is the bug we’re trying work around: http://tracker.ceph.com/issues/1785810:58
arnewiebalck_rraja: Yes, you can assume that the caps have been manipulated (if you don’t find any other explanation).11:02
rrajaarnewiebalck_: thanks for sharing the issue that you're trying to work around.11:05
rrajaarnewiebalck_: okay.11:05
*** nkrinner_trainin has quit IRC11:05
*** khamtamtun has joined #openstack-manila11:06
*** nkrinner_trainin has joined #openstack-manila11:07
openstackgerritRodrigo Barbieri proposed openstack/manila-specs: Add spec for Share Migration Ocata improvements  https://review.openstack.org/39229111:11
*** akapil has quit IRC11:11
openstackgerritRodrigo Barbieri proposed openstack/manila-specs: Add spec for Share Migration Ocata improvements  https://review.openstack.org/39229111:12
*** khamtamtun has quit IRC11:12
*** ociuhandu has joined #openstack-manila11:14
*** kamtamtun has joined #openstack-manila11:14
*** ianychoi has quit IRC11:14
*** andreaf has quit IRC11:26
*** andreaf has joined #openstack-manila11:26
*** gouthamr has joined #openstack-manila11:32
*** andreaf has quit IRC11:36
*** andreaf has joined #openstack-manila11:36
*** akapil has joined #openstack-manila11:38
*** andreaf has quit IRC11:39
*** akapil has quit IRC11:42
*** andreaf has joined #openstack-manila11:43
*** kamtamtun has quit IRC11:45
*** gouthamr has quit IRC11:47
*** gouthamr has joined #openstack-manila11:51
*** kamtamtun has joined #openstack-manila11:52
*** kamtamtun has quit IRC11:53
openstackgerritValeriy Ponomaryov proposed openstack/manila-specs: Remove duplicated imports of specs into index  https://review.openstack.org/39896511:58
gansovponomaryov: ^ when I first read it, seemed like a spec to remove duplicated specs lol12:00
*** zhugaoxiao has quit IRC12:01
mkoderer__dmellado: if you have problems with dailing in we move over to hangout12:01
*** zhugaoxiao has joined #openstack-manila12:01
dmelladomkoderer__: I should be there, i got forwarded to a page saying that the organizer would soon admit me12:02
*** mkoderer_ has joined #openstack-manila12:02
tbarronmkoderer__: dmellado i think i'm in by phone12:02
mkoderer__dmellado: mhhhh12:02
*** akapil has joined #openstack-manila12:02
dmelladolet me check the number, I'll just do phone12:03
*** tuanluong has quit IRC12:04
*** kamtamtun has joined #openstack-manila12:04
*** kamtamtun has quit IRC12:05
*** dustins has joined #openstack-manila12:05
*** digvijay2016 has quit IRC12:06
*** akapil has quit IRC12:07
mkoderer__https://etherpad.openstack.org/p/manila_no_tempest_deps12:10
*** kaisers__ has joined #openstack-manila12:18
*** akapil has joined #openstack-manila12:19
openstackgerritValeriy Ponomaryov proposed openstack/manila-specs: Add py27 tox env to tox config to unblock CI  https://review.openstack.org/39897312:19
*** kaisers_ has quit IRC12:20
*** mkoderer_ has quit IRC12:21
*** mkoderer_ has joined #openstack-manila12:21
*** akapil has quit IRC12:23
*** akapil has joined #openstack-manila12:37
*** catintheroof has joined #openstack-manila12:46
*** akapil has quit IRC12:49
openstackgerritRodrigo Barbieri proposed openstack/manila-specs: Add spec for Share Migration Ocata improvements  https://review.openstack.org/39229112:51
openstackgerritRodrigo Barbieri proposed openstack/manila-specs: Add spec for Share Migration Ocata improvements  https://review.openstack.org/39229112:51
*** gouthamr has quit IRC12:52
*** chlong has joined #openstack-manila13:00
*** akapil has joined #openstack-manila13:09
*** akapil has quit IRC13:10
*** akapil has joined #openstack-manila13:11
vponomaryovganso, tbarron: manila-specs CI fix -> https://review.openstack.org/#/c/398973/13:15
*** akapil has quit IRC13:15
tbarronvponomaryov: thanks, after that merges we can do the other one (that removes the duplicatses)13:19
tbarronganso: ^^^^ you need it too13:19
*** akapil has joined #openstack-manila13:21
openstackgerritRodrigo Barbieri proposed openstack/manila-specs: Add spec for Share Migration Ocata improvements  https://review.openstack.org/39229113:23
gansovponomaryov, tbarron: Thanks!13:23
openstackgerritRodrigo Barbieri proposed openstack/manila-specs: Add spec for Data Jobs table  https://review.openstack.org/39226213:27
openstackgerritRodrigo Barbieri proposed openstack/manila-specs: Add spec for Data Jobs table  https://review.openstack.org/39226213:28
gansovponomaryov, tbarron: off to lunch, brb13:29
tbarronganso: enjoy your early? lunch13:29
*** gouthamr has joined #openstack-manila13:30
tbarronvponomaryov: do you need to put 'commands = ' under [testenv] in https://review.openstack.org/#/c/398973/ ?13:31
gouthamrvponomaryov: ah crap13:32
vponomaryovwhy we have this py27 job at all?13:34
vponomaryovwhen we do not have tests13:34
gouthamryes13:34
gouthamrwe should probably get rid of it13:34
gouthamrnova has a couple of tests13:35
vponomaryovcinder has just 1 - https://github.com/openstack/cinder-specs/blob/master/tests/test_titles.py13:35
gouthamrah, interesting... seems like they want to impose a format..13:36
vponomaryovhaha, after first test run CI bug got immunity against fix ))13:38
vponomaryovevolves13:38
vponomaryov^_^13:38
*** porrua has joined #openstack-manila13:42
openstackgerritValeriy Ponomaryov proposed openstack/manila-specs: Add py27 tox env to tox config to unblock CI  https://review.openstack.org/39897313:42
tbarronvponomaryov: ^^ :)13:43
TommyLikeHuvponomaryov: hey could you take a look this spec, again? <vponomaryov>13:45
TommyLikeHuhttps://review.openstack.org/#/c/390052/13:45
gouthamrvponomaryov tbarron: heh if i did that on my internal CI, the QA engineer would come after my soul #dummyCIJobs13:45
vponomaryovgouthamr: and will why you do no test that does not exist?13:46
vponomaryovs/will/will ask/ ?13:46
vponomaryovs/no/not/13:46
gouthamrvponomaryov: nah.. nodes are expensive, we pay money, the cloud is someone else's computer kinda arguments.13:47
*** akapil has quit IRC13:47
gouthamrnot saying 'openstack i n f r a' folks would be okay with this.13:48
*** akapil has joined #openstack-manila13:48
vponomaryovgouthamr: we are ok if they disable it13:48
*** eharney has quit IRC13:48
vponomaryovgouthamr: what is the problem?13:48
gouthamrvponomaryov: can't we disable it?13:48
vponomaryovgouthamr: we can13:48
vponomaryovgouthamr: but, I guess, better to add some test, for example, port Cinder's13:48
vponomaryovgouthamr: till that moment we can have that placeholder13:49
vponomaryovgouthamr, tbarron: it passed )13:49
vponomaryovit is right time to either +2 it or -2 it13:49
*** akapil has quit IRC13:49
tbarrongouthamr: my irc alerts me on 'm a n i l a' :)13:50
vponomaryovtbarron, right, I summoned you )13:50
gouthamrtbarron: sheesh13:50
tbarronwe can always remove the test later ...13:52
tbarronif we decide there's no useful content to put in that slot13:52
vponomaryovtbarron: "remove test"? we don't have test13:52
tbarronvponomaryov: yeah, bad wording.  disable the job.13:53
vponomaryovbut FIRST, we should add laucnhpad manila-specs project )13:54
vponomaryovto be able to file bugs13:55
vponomaryovabout all that kind of stuff13:55
tbarronvponomaryov: delegate that to bswartz13:55
*** ianychoi has joined #openstack-manila14:10
*** eharney has joined #openstack-manila14:12
*** akapil has joined #openstack-manila14:18
bswartzwhat?14:19
bswartzbugs for specs?14:20
bswartzjust fix them14:20
vponomaryovbswartz: to fix them we should file them14:21
vponomaryovbswartz: and track it14:21
bswartzwhy not just push change to gerrit?14:21
vponomaryovnow we did so, yes14:21
*** akapil has quit IRC14:23
*** wiebalck has joined #openstack-manila14:24
wiebalckIs there a reason why shrinking shares is not permitted?14:26
gansowiebalck: why do you mean by not permitted?14:27
bswartzwiebalck: shrinking shares is allowed, but only if driver supports it14:27
wiebalckwhen trying to reduce the size of a CephFS share, at least the UI says the new size must be larger than the current one14:28
bswartzwiebalck: maybe the UI doesn't know how to call the shrink API? I'd need to check14:30
*** timcl has joined #openstack-manila14:31
gansowiebalck: new size must be larger? that's the extend feature... or a bug in shrink functionality14:32
wiebalckganso: correct, it’s extend14:33
gansowiebalck: ok so you would like to extend or shrink? I am confused14:33
wiebalckganso: sorry for the confusion, the attempt was to extend to a smaller size (wasn’t aware that the cli has a ’shrink’ subcommand)14:34
rrajawiebalck: :)14:34
gouthamrweibalck: not a subcommand, a whole different 'action' API14:34
gouthamrsry, wiebalck - i before e. :)14:35
rrajagouthamr: :)14:35
wiebalckwill check UI, but smells like PEBKAC …14:37
openstackgerritDaniel Mellado proposed openstack/manila: [Tempest] Port remote_client into Manila  https://review.openstack.org/39606714:37
vponomaryovwiebalck: googled, PEBKAC and laughed a lot )) "Problem Exists Between Keyboard And Chair" ^_^14:39
wiebalckvponomaryov: :)14:40
openstackgerritMerged openstack/manila-specs: Remove duplicated imports of specs into index  https://review.openstack.org/39896514:42
*** cdelatte has joined #openstack-manila14:44
vponomaryovwiebalck: and really was surprised that you tried to "extend" a share to "smaller" size. It sounds to me as "curly and bald head"14:45
gansovponomaryov, wiebalck: yes lol, TIL that one as well, I feel like using that acronym everyday now14:45
wiebalckFrom what I see, I can shrink my CephFS based share via the cli, but not via the UI. The UI only offers extend.14:49
gouthamri think that's a nice interaction... as a user, i just want to resize the share.14:49
wiebalckgouthamr: I agree.14:50
gouthamrmanila-ui can have a resize option that's smart enough to do the right thing..14:50
*** tommylikehu_ has joined #openstack-manila14:51
vponomaryovgouthamr: we have a volunteer for new shiny UI feature!14:51
wiebalckAt minimum, not offering “shrink” should be fixed, no?14:51
gouthamrwiebalck: +114:51
gouthamrvponomaryov: shiny bald14:52
vponomaryovgouthamr: i don't mind if manila features are implemented by someone being shiny bald ))14:54
gouthamrwiebalck: some share drivers may not allow shrinking shares... so, it feels like more of a reason to just have 'resize' and hide the API interaction from the user and spit out the error message if unable to shrink.. however, if a user tries to shrink a share that can't really be shrunk, the state transitions to 'shrinking_error'14:54
gouthamrvponomaryov: oh not me then14:54
vponomaryovwhy? )14:54
openstackgerritTiago Pasqualini da Silva proposed openstack/manila-specs: Add spec for mountable snapshots  https://review.openstack.org/32121314:54
vponomaryovgouthamr: you can save money on shampoo! )14:55
tbarrongouthamr is bragging about his great hair again14:55
* tbarron has not actually heard gouthamr do that ...14:55
gouthamr:D yeah!14:55
gouthamrbswartz: can we make shrink a capability?14:55
gouthamr:P14:56
openstackgerritGoutham Pacha Ravi proposed openstack/manila-specs: Fix and improve Access Rules  https://review.openstack.org/39904914:57
gouthamr^ WIP14:57
gouthamr#tardy14:57
gansogouthamr: so the admin can create a "shrinkable" share type?14:58
bswartzgouthamr: it's worth considering14:58
*** xyang_ has joined #openstack-manila14:59
bswartzgouthamr: extend/shrink were added in the bad old days when we were just copying ideas from cinder so we didn't think about that14:59
bswartzdespite that, it's possible that shrink is okay the way it is15:00
gouthamrganso bswartz: it would be easier error reporting... because it is an optional feature.. otherwise, the interaction is broken if we do add it to manila-ui, user may shrink an unshrinkable share and has to call the admin to reset state15:00
bswartzI need to consider it15:00
*** zengyingzhe has joined #openstack-manila15:05
wiebalckI created https://bugs.launchpad.net/manila/+bug/164262715:05
openstackLaunchpad bug 1642627 in Manila "Option to "shrink" a share is missing on the UI " [Undecided,New]15:05
openstackgerritMerged openstack/puppet-manila: Prepare 10.0.0 release  https://review.openstack.org/39742415:07
gouthamrwiebalck: thanks15:07
*** alyson_ has joined #openstack-manila15:16
*** akapil has joined #openstack-manila15:25
openstackgerritDaniel Mellado proposed openstack/manila: [Tempest] Port remote_client into Manila  https://review.openstack.org/39606715:30
*** absubram has joined #openstack-manila15:34
*** cdelatte has quit IRC15:35
*** absubram_ has joined #openstack-manila15:35
*** akapil has quit IRC15:38
*** absubram has quit IRC15:38
*** absubram_ is now known as absubram15:38
*** timcl1 has joined #openstack-manila15:39
*** akapil has joined #openstack-manila15:41
*** timcl has quit IRC15:42
*** akapil has quit IRC15:45
*** akapil_ has joined #openstack-manila15:45
bswartztpsilva, ganso: ping16:01
bswartzalso tbarron16:01
tpsilvabswartz: pong16:01
* ganso moves over to this channel16:01
bswartzhttps://review.openstack.org/#/c/321213/16:01
marksturo/16:01
*** zengyingzhe has quit IRC16:01
bswartzIn order to support this feature, a new extra spec called mount_snapshot_support will be added16:02
gansobswartz: LN 5216:02
gansobswartz: ya16:02
bswartzno capability mentioned in the driver impact section16:02
bswartzI'll post more specific feedback16:02
*** absubram has quit IRC16:03
bswartzThe new capability is important and definitely impacts drivers16:03
tpsilvait will look for the implemented methods and will add the capability, just like revert_to_snapshot or the current snapshot_support16:03
tpsilvais that what you want to be on the spec?16:03
bswartzmarkstur: did you have something about mountable snapshots?16:03
gansobswartz: humm I thought that stating that a new "extra_spec" is being added, it implies that it is a new capability for drivers to implement and report support16:03
tbarronganso: it implies, but we should *say*16:04
bswartzmarkstur: or just friendly waving?16:04
marksturI was trying to show that I'm on time16:04
openstackgerritMarc Koderer proposed openstack/manila: Make share size configurable  https://review.openstack.org/39911616:04
marksturmountable snapshots should be good to code (the spec is missing a little on capability, but not a big road-block)16:04
bswartztpsilva: it's something that simply has to be called out in driver impact16:05
tpsilvabswartz: ok, that's a simple edit, I can add that16:05
*** nkrinner_trainin is now known as nkrinner16:05
* tbarron suggests a new review-focus deadline on high prio specs, perhaps December 1.16:06
tbarronganso: bswartz I'm not suggesting moving the cutoff date closer.16:06
tbarronganso: bswartz just a date where high prio specs that have review focus get attention from all cores16:07
bswartztbarron: it's a good point16:07
tbarronganso: bswartz don't know if it's the best idea, just brainstormiinng about how to avoid last-minute crunch16:07
openstackgerritzhongjun proposed openstack/manila-specs: Add detail API to quota-set API collection  https://review.openstack.org/39005216:07
bswartztbarron: more serious concern is when the specs should be done by16:07
bswartztbarron: personally I've been dedicating myself to reviewing the low priority stuff and not spending any time on my own spec16:08
tbarroni hate having to +2 when a spec really needs some fixing (more than typos and spelling) and we really think the basic idea is sound and we should do the work  in this release16:08
TommyLikeHubswartz: :(16:08
* tbarron spent some time on bswartz's spec :)16:09
bswartzthanks16:09
tpsilvabswartz: on question16:09
bswartzokay I'm going to push 3 changes to designate specs high priority16:09
tpsilvaone*16:09
*** pcaruana has quit IRC16:10
tpsilvabswartz: you pointed that the drivers should report the capability, rather than automatically looking for the implemented methods like it's currently being done with snapshot_support16:10
tpsilvabswartz: are you against automatically reporting it as true or false depending on the methods?16:10
bswartztpsilva: if we can make the capability automatically report that that maybe be better16:11
gouthamrtpsilva: we don't need the automatic check.. you can default to False and if drivers support it with their implementation, they will override it16:11
bswartzI like simple solutions though16:12
gouthamrtpsilva: look at replication_type or thin_provisioning16:12
bswartzwe need to consider a case when the driver supports mountable snapshots on some pools but not all pools16:12
gouthamr^ yeah, so more sense not to do any automatic setting16:13
bswartzjust letting the driver set the boolean seems pretty idiot-proof to me16:13
tpsilvagouthamr, bswartz: ok... I just proposed to be automatically because that's how revert_to_snapshot is being implemented16:13
gansogouthamr: revert-to-snapshot is already doing that even though there is no existing code to automatically detect https://review.openstack.org/#/c/340502/20/manila/share/driver.py@81916:14
gouthamr:( i thought we only did that for create_share_from_snapshot support16:14
gouthamr-116:14
bswartztpsilva: following the model for revert is a good idea, but they will both suffer from the same problem16:14
bswartzI'm not sure if any driver every would need to support the capability on some pools and not others16:14
bswartzbut if they did then this design would cause problems16:15
tpsilvaI agree16:15
bswartzmaybe we need to propose a change to cknight's spec16:15
tpsilvawe should report manually16:15
tpsilvayes16:15
tpsilva+116:15
*** akapil_ has quit IRC16:15
markstur+116:15
gouthamr+116:15
gansobswartz: doesn't the scheduler already accept it to be assigned to that backed even if the share type extra spec is False but the capability is True?16:16
tpsilvaI'll quickly fix the issues that you pointed out and I would appreciate more reviews :D16:16
marksturI think auto was useful when we were defaulting a feature to true and wanted to automatically weed out the ones that didn't have it16:16
bswartzganso: no!16:16
bswartzganso you're thinking of the case when the extra spec is set to None not False16:16
gansobswartz: oh yes, the "dont care" extra specs16:16
marksturFor default false the drivers can manually opt-in when they implement it and document support, etc16:17
bswartzif the extra spec is set to None then the scheduler won't filter on it, but end users will still think the value is false16:17
*** falavinha has quit IRC16:17
vponomaryovbswartz: in case auto detection is not suitable driver just should redefine it16:17
marksturvponomaryov: but that means a driver maintainer needs to do it.  Best part about auto is dealing with those that did nothing16:18
vponomaryovbswartz: so it will have correct False value if not implemented and when implemented - driver wil ldefine it16:18
bswartzvponomaryov: as long as the code to do that isn't too fancy I', fine with it16:18
gouthamri think we're in agreement here: for both revert_to_snapshot and mount_snapshot use cases, drivers *have* to implement additional logic - this isn't the same thing as snapshot_support becoming optional and un-overloading create_share_from_snapshot_support16:18
gansomarkstur: but there is no existing code to take advantage of the auto, the interface to be implemented does not exist16:18
gouthamrwhere we implemented these changes expecting to maintain backwards compatibility16:18
tpsilvagouthamr: +116:19
*** timcl has joined #openstack-manila16:19
marksturSo we probably all agree here but could keep arguing anyway now that there is no # endmeeting16:19
gansomarkstur: lol16:19
gouthamr#endmeeting16:20
gouthamr:P16:20
marksturganso: lol16:20
* markstur put a space after # just to make sure I didn't end manila16:20
TommyLikeHulol16:21
bswartzthis room is like a 24/7 meeting16:21
marksturnice try gouthamr16:21
*** timcl1 has quit IRC16:21
marksturIt was16:21
bswartzyou can check out but you can never leave16:21
marksturgouthamr: ended it16:21
tbarrongouthamr has a flight to catch16:21
gouthamrbingo16:21
marksturWelcome to Hotel California16:21
tpsilvait's all over16:21
dustinsbswartz: Oh god I'm in 20 meetings at once O_o16:21
tpsilvanice working with you16:22
bswartzgouthamr: is Insight done then?16:22
marksturdustins: or are you in no meetings16:22
dustinsmarkstur: I don't even know any more :)16:22
gouthamrbswartz: got done today - flying home tomorrow16:22
*** tommylikehu_ has quit IRC16:22
bswartzgouthamr: you mean flying to India right?16:23
gouthamrhome=india16:23
gouthamryeah :P16:23
dustinsgouthamr: Safe travels, man!16:23
bswartzokay have a nice flight gouthamr16:23
gouthamrthanks dustins bswartz :)16:23
gansogouthamr: have a nice flight!16:23
gansobswartz: btw, I am confused if it has been agreed that the data jobs table spec will be withdrawn16:23
gouthamrthank you :)16:23
*** gouthamr has quit IRC16:23
bswartzganso: well if you withdraw it then we can spend time focusing on the other low priority specs16:24
bswartzit's your decision16:24
gansobswartz, tbarron, markstur: and btw I am glad that I got some feedback on taskflow, still would like to know it better to justify not going with it16:24
bswartzyou could just git mv from ocata to pike to make the intention clear16:24
vponomaryovganso: look at peace of code in Cinder16:25
bswartzand remove it from review focus etherpad16:25
bswartzs/peace/piece/16:25
gansovponomaryov: "peace of code" is good16:25
gansovponomaryov: lol :P16:25
vponomaryov>.<16:25
vponomaryovsorry )16:25
bswartzganso: in addition to looking at how it works in cinder, talk to the developers who maintain that code16:26
bswartzthe code in cinder is so hard to understand that even though the community is in favor of removing it, nobody has volunteered to do that work16:27
tbarronganso: i'm interested in jobs table and in progressing investigation/design of it during ocata even if we don't target implementation till pike16:27
gansotbarron: thanks tbarron :)16:28
tbarronbswartz: i'd like to understand if taskflow works at the wrong granularity for job restarts or if we just never mapped things right in cinder.  I agree that developers tend to shy away from it but am not totally convinced that it couldn't be used more effectively.16:30
tbarronbswartz: mostly I just think we really need to be sure we aren't doing NIH and have good reasoning in the spec.16:30
tbarronbswartz: ganso it really seems to me that tracking long-running jobs, restart after failure, etc. are not manila-specific issues.16:31
tbarronbswartz: ganso maybe we solve them in manila with manila data service and then generalize16:31
*** nkrinner is now known as nkrinner_afk16:32
*** dsariel has quit IRC16:32
tbarronbswartz: ganso but I'd like us to keep the possibility of the general case in mind16:32
bswartztbarron: in Cinder there are a few problems16:32
gansotbarron: they are not, but that logic I would like to integrate with the approach that will be taken for HA A-A16:32
bswartzone is that taskflow was used for a few workflows but not nearly all of them16:32
bswartztwo is that it doesn't actually persist its state in the DB so many of the purported benefits are not realized16:32
tbarronganso: yes, we will need to think it through for HA A-A for sure16:32
gansotbarron: so, I am proposing a phased implementation, and the parts that you and toabctl highlighted are in fact not going to be resolved in that first phase16:33
tbarronbswartz: agree, not sure if that's inherent or just cinder implementation16:33
bswartzand three is that the code is so byzantine that understanding it is comparable to learning a new programming language16:33
bswartzit's the last one that makes me oppose it16:33
tbarronganso: phasing is fine, but first phase can't paint us  in a corner for second phase.  Not saying it does, just explaining my wanting to be somewhat deliberate.16:34
bswartzI like idiot proof code16:34
tbarronbbiab16:34
*** akapil has joined #openstack-manila16:35
*** belmoreira has quit IRC16:35
gansotbarron: yes, that is another concern I have, If I should just wait for this mechanism to exist prior to adding the jobs table because it will be incomplete and needs to be compatible with something that does not exist yet16:35
marksturganso: I  used taskflow for a multi-step retype in the HP driver (hpe3par_common.py?)16:36
gansotbarron: on the other hand, what is proposed fixes existing problems... like, there is nothing tracking migration at all, so user's experience using migration may not be ideal16:36
marksturganso: What it did for me was allow retype to work in phases and taskflow framework took care of how to rollback earlier phases if a later one failed16:36
*** akapil has quit IRC16:37
marksturIt's not idiot proof, but helped with rollback16:37
gansomarkstur: that sounds like a mechanism for HA A-A as well, but I wouldn't want to use that if manila is not onboard and does not want that mechanism for m-shr HA A-A16:37
marksturganso: I've heard after I was told I should use it that some folks wanted to get rid of it16:38
gansomarkstur: yea, if we have a feature tied to it, it makes it even more complicated to remove16:39
marksturganso: I think more specifically many just don't like how it was used in cinder create_volume(?) and maybe it isn't maintained(?)16:39
marksturganso: So I'd be reluctant to use it.16:40
*** gcb has quit IRC16:40
gansomarkstur: ok I think I will take a step back and redesign the spec, maybe remove stuff proposed so I have a smaller risk of adding something that will not be compatible with our future HA A-A mechanism16:40
toabctlganso, maybe you can ask jharlow in the oslo channel16:40
toabctlabout the taskflow state16:41
marksturganso: ...but it could still be worth a look if it does what you'd end up writing anyway16:41
*** gcb has joined #openstack-manila16:41
gansotoabctl: thanks, I will join that channel and try to talk to him16:42
toabctlI just want to avoid the NIH syndrom16:42
gansomarkstur: even if it does, it would not be implemented in the first phase anyway16:42
marksturIt fails 2 of Ben's criteria:  1) idiot-proof  2) not fancy16:42
*** lpetrut has quit IRC16:44
*** akapil has joined #openstack-manila16:45
*** rraja has quit IRC16:51
openstackgerritBen Swartzlander proposed openstack/manila-specs: Mark Eliminate Race Conditions high priority  https://review.openstack.org/39913516:57
*** wiebalck has quit IRC16:58
*** xyang_ has quit IRC16:59
openstackgerritBen Swartzlander proposed openstack/manila-specs: Mark Fix and improve Access Rules high priority  https://review.openstack.org/39913817:02
openstackgerritBen Swartzlander proposed openstack/manila-specs: Mark Enable IPv6 high priority  https://review.openstack.org/39914017:06
*** lpetrut has joined #openstack-manila17:12
*** akapil_ has joined #openstack-manila17:12
*** akapil has quit IRC17:12
gansomarkstur, bswartz, toabctl: waiting for feedback in https://review.openstack.org/392291/ ... seems ready so far17:14
*** xyang_ has joined #openstack-manila17:19
openstackgerritTiago Pasqualini da Silva proposed openstack/manila-specs: Add spec for mountable snapshots  https://review.openstack.org/32121317:19
*** xyang_ has quit IRC17:21
*** lpetrut has quit IRC17:26
*** jcsp has joined #openstack-manila17:34
*** akapil_ has quit IRC17:36
*** akapil has joined #openstack-manila17:36
*** jcsp has quit IRC17:40
*** jcsp has joined #openstack-manila17:40
gansobswartz: ping17:44
*** akapil has quit IRC17:55
openstackgerritMauricio Lima proposed openstack/manila-specs: Spec for openstack client support  https://review.openstack.org/39577518:02
*** xyang_ has joined #openstack-manila18:03
*** xyang_ has quit IRC18:05
bswartzganso: pong18:05
gansobswartz: I would like to discuss an aspect of the data jobs spec18:05
bswartzk18:06
gansobswartz: I remember at the design summit session that some folks cringed when I mentioned that we would store the job details as string JSON in the database18:06
bswartzyeah I was one of them18:06
gansobswartz: so I came up with an alternative that has its advantages and disadvantages18:06
gansobswartz: so if you are familiar with the ShareServerBackendDetails table, it is exactly the same18:06
* markstur doesn't cringe18:07
gansobswartz: it is a separate table "JobDetails" where each key-value pair is a row18:07
*** akapil has joined #openstack-manila18:07
bswartzyeah that's the alternative I would have suggested18:07
bswartzit doesn't allow for infinitely nested structures like json does, but it scales better18:07
gansobswartz: the disadvantage is that, for the amount of jobs we may have, it will probably not scale so well to seek the information in the JobDetails table every time the Jobs table is queried18:08
marksturganso: index the table18:08
bswartzganso: I don't see why it would be any worse than other cases where keys/values are stored in a separate table18:08
gansomarkstur: it will be indexed, yes18:08
bswartzthink of access rules, type keys, driver private share data18:09
gansobswartz: it is not really worse than those, pretty much equivalent18:09
bswartzindexed lookups generally perform very well on SQL databases18:09
gansobswartz: but seems to me the previous approach would scale better if the data is limited and contained in the same table18:09
bswartzthe first part of that IF is the crux of the problem18:10
bswartzif the data is limited, then every solution works well18:10
bswartzthe problem is that we (apparently) don't want to limit the data18:11
*** akapil has quit IRC18:11
gansobswartz: it seems like we never do limit the data hehe18:12
bswartzyeah18:12
gansobswartz: never do *want18:12
gansobswartz: if we think about 1 million rows, the JSON alternative scales better18:12
gansobswartz: ... with the JSON being limited to like 255 chars18:13
bswartzso if we don't know what fields the jobs will required ahead of time, or we don't know how wide those fields would be, then we're stuck with either a potentially huge JSON blob or possibly a large number of rows in some join table18:13
bswartzI don't think it's practical to put a size limit on JSON blobs -- it introduces a huge new set of error conditions and ugly workarounds18:14
bswartzunless the limit is so high that nobody will ever hit it in practice18:15
gansobswartz: well, I will just state in the spec that the JobDetails table is preferred approach then...18:15
bswartzthanks18:15
bswartzsome examples will help reviewers18:15
*** xyang_ has joined #openstack-manila18:16
gansobswartz: for the preferred approach it is detailed18:16
gansobswartz: thanks18:16
*** xyang_ has quit IRC18:18
*** xyang_ has joined #openstack-manila18:21
marksturganso: minor thing in migration spec and then hopefully done18:23
*** xyang_ has quit IRC18:23
bswartzganso, tbarron: you put +2 on 2/3 of the high priority spec changes -- did you opposed the 3rd one?18:24
gansobswartz: I need to re-read the spec, haven't had time yet18:24
gansomarkstur: thanks18:24
tbarronbswartz: i didn't intentionally oppose adding any of the high prio specs that we all talked about, which review looks like I'm opposing?18:25
bswartztbarron: I pushed 3 changes in a row ^^^ and you +2 two of them18:26
bswartzdidn't know if you just missed the 3rd or intentionally didn't +2 it18:26
tbarronbswartz: i think i just missed one then, looking ...18:26
*** xyang_ has joined #openstack-manila18:26
gansobswartz: re-reading the spec I will be taking a more conscious decision regarding the risks, because hi-pri means "we want that feature in ocata"18:26
marksturI +2*3, but honestly that IPv6 one is the situation where sure it's nice to have the core work merged, but when only 1 driver implements a new feature it kind of looks bad18:28
tbarronbswartz: ganso I am in favor of that being hi prio; i see it as not high risk but would benefit from more review; also not a big diversion of resources - we'll need to review but huawei folks will do the implementation18:28
tbarronganso: do you think it's risky?18:29
tbarronganso: my sense is that the spec is almost ready.  Just mostly nits and need to nail down the capabilities/extra-spec a bit.18:29
bswartzmarkstur: It's important to decouple the support for a feature in manila from support in drivers18:29
marksturSo there's that fence between better to let it sit in gerrit ready for drivers to play with and merge day 1 vs merge w/ lousy support18:29
marksturI'm sitting on that fence, but this time I guess I lean to agree with merging would be best18:30
bswartzmarkstur: this is the approach we've taken with other major features18:30
marksturYes. Single driver features aren't great.  Problem with the other approach though...18:31
bswartzwhen adding a new features we require support in a small handful of drivers to validate the design, and to enable automated gate testing, but we allow all other driver to implement the feature and their leisure18:31
marksturis if we delay merge until day1 of next release.  Would drivers just delay yet another release...18:31
marksturSo OK18:31
tbarronmarkstur: we should require a first-party driver implementation at least18:31
marksturbswartz: Totally agree that we HAVE TO allow drivers time to implement.18:31
marksturIt's the only 1 driver did it situation that looks bad.18:32
marksturbut like I said above.  Could be that the alternative is worse.  So let's go.18:32
bswartzIPv6 *should* be easy enough to add to most drivers that I doubt we'll end up in that boat18:32
gansotbarron: I need to catch up with the latest patches in the IPv6 spec, the last one I had read I was against and saw high-risk18:32
marksturbswartz: What's the deadline for hi-pri feature to merge?18:32
tbarronganso: ack18:32
gansotbarron: in today's meeting someone said it has been decoupled, so I need to revisit that18:33
bswartzyes, in this case the alternative is that Manila remains in the 90s with it's IPv4-only support18:33
bswartzmarkstur: same as any feature -- the feature freeze18:33
tbarronganso: so it's being hi-prio doesn't mean it has to be approved.  You have till ocata-2 to -2 :)18:33
* markstur mind wanders back to the 90s18:33
marksturbswartz: So IPv6 merges late in the release.  Most drivers won't jump on it until next release.  Unfortunate situation vs early merge.18:34
tbarronmaking it hi-prio means we *want* to have it but is not a guarantee18:34
marksturAnywho. Let's see if we can get it soon and right.  The spec needs work, but sure. It is 2016.18:35
marksturBy the way!!!  Anyone have a good design for an extra spec that says <all> ('4','6')18:36
*** lpetrut has joined #openstack-manila18:36
tbarronmarkstur: we have to accomodate the non-IP backends too with the new extra-specs/capabilities ...18:37
marksturWe need a user-friendly way of saying '4&6' or 'both' but it should be listy18:37
tbarronmarkstur: that's the area of the spec that needs the most thought I think18:37
bswartztbarron: what?18:37
openstackgerritRodrigo Barbieri proposed openstack/manila-specs: Add spec for Data Jobs table  https://review.openstack.org/39226218:37
* bswartz hopes tbarron was making a joke that he missed18:38
tbarronbswartz: well right now every driver is saying I can do v4, i can do v6, or i can do both, and it's defaulting to v4.18:38
tbarronmarkstur: do I have that right?18:38
bswartzyou mean the spec says that or that's reality?18:38
marksturtbarron: So. An IPv4, an IPv6, and a non-IP walk into a bar...18:38
markstur^ that's how you start a joke18:39
tbarronbswartz: i think that's what the spec says atm, but the capabilites/extra spec stuff was added to the spec quite late.18:39
bswartzIf someone proposes a fibre channel driver for manila I'm going to start throwing chairs18:39
tbarronthat's why i didn't want to rush approval +2 by ocata-1 even though I think this is totally implementable18:39
tbarronbswartz: no, i'm talking about exports and access lists, think native cephfs, hdfs, native glusterfs18:40
marksturAgree that the spec isn't right, but fixing it could be punted to the code.  I think.18:40
bswartztbarron: oh are you referring to non-IP *access rules*?18:40
tbarronmarkstur: if we make it high-prio spec we have time to fix the spec18:40
marksturtbarron: Didn't get the "non-IP" comment.18:40
marksturWe did make it hi-pri. So we're good.18:41
tbarronbswartz: isn't the capability advertising what kind of exports one can support?18:41
marksturBut I don't see a great way of doing a spec that says I want "both"18:41
marksturreluctant to use "both" because of some future IPvX18:41
bswartztbarron: access rules != export locations18:41
bswartzexport locations are now and always will be IP address-based18:42
marksturWe can have driver report ('4','6') as we already support both capabilities like dhss (True, False)18:42
bswartzaccess rules can be IP, user, cert, etc18:42
tbarronbswartz: true that18:42
marksturBut there isn't a good way to do extra-spec that says I want ip_version = '4' and ip_version = '6'18:42
bswartzmarkstur: yes there is18:42
marksturunless you are allowed to repeat a spec like that.  Which would be OK I guess, but not if it is used as a key18:42
*** ociuhandu has quit IRC18:43
bswartzyou create 2 extra specs ipv4_support=True, ipv6_support=True18:43
marksturbswartz: good.  What is it.  Let's get it in the spec18:43
marksturOK.18:43
marksturI didn't get a chance to test it18:43
marksturSeems like I've accessed that as a keyed dict18:43
bswartzI provided that feedback in the ML thread18:43
marksturOops.  I didn't read your suggest correctly18:43
marksturI see what you mean18:43
bswartzmaybe it didn't get reflected in the spec yet18:43
marksturCool.  I didn't review all the reviews last night.18:44
marksturWe should be able to settle this with the hi-pri deadline18:44
tbarronbswartz: yeah, your point is sound, but the spec needs work on the extra_spec b/c it says "Add new optional extra_spec 'ip_version for  share type that indicate[sic] the access ip version".  Sounds like access rules though export locations are likely intended ??18:45
bswartztbarron: yes18:45
tbarronbswartz: ok, we're on the same page.  I let the language muddle me up.18:45
bswartzI think our friends a huawei are probably in bed by now but we should keep helping straighten the spec out18:46
marksturYeah. I thought at first that export_locations was being dropped from the feature, but then I read on and let it go.18:46
bswartzif someone wants to clean up the language maybe ask them if they'd mind someone else pushing an update to the spec18:46
marksturI feel bad I wanted to post my feedback last night so TommyLikeHu could work on it, but this morning I found that the publish button I thought I hit before I had to run off did not get hit  :(18:47
bswartzmarkstur: ouch I hate that18:47
marksturGlad we have extended w/ the hi-pri.  We'll work this one out18:47
marksturbswartz: Especially when I wake up mid-manila meeting open my laptop and see the review right there waiting for me to press the button18:48
bswartzhave you ever made the mistake where you posted a bunch a feedback against the wrong changeset, then when you pressed publish it *still* didn't publish?18:48
marksturbswartz: Don't think so.  I have of course found stuff in drafts way after I thought I was being ignored18:48
tbarronI put a comment in the spec about export_locations vs export rules.  TommyLikeHu will pick that up first thing tomorrow and we'll see a new draft I'm sure.18:49
*** timcl1 has joined #openstack-manila18:53
openstackgerritRodrigo Barbieri proposed openstack/manila-specs: Add spec for Share Migration Ocata improvements  https://review.openstack.org/39229118:54
gansotoabctl, tbarron: if you could please take a look at the updated data jobs spec, I hope I have addressed the concerns, please let me know if there are any more outstanding concerns18:56
*** timcl has quit IRC18:56
openstackgerritTiago Pasqualini da Silva proposed openstack/manila-specs: Add spec for mountable snapshots  https://review.openstack.org/32121318:57
openstackgerritTiago Pasqualini da Silva proposed openstack/manila-specs: Add spec for mountable snapshots  https://review.openstack.org/32121318:58
*** timcl1 has left #openstack-manila19:09
tbarronganso: I made a couple more remarks in the review, will look again fresh tomorrow but have to do some other stuff the rest of today.19:10
gansotbarron: ok! thanks Tom!19:14
tbarronganso: yw, good stuff!19:14
*** xyang_ has quit IRC19:28
*** xyang_ has joined #openstack-manila19:28
*** nherciu_ has joined #openstack-manila19:33
*** xyang_ has quit IRC19:35
*** xyang_ has joined #openstack-manila19:35
*** wiebalck has joined #openstack-manila19:37
*** nherciu has quit IRC19:37
*** porrua has quit IRC19:38
*** openstackgerrit has quit IRC19:48
*** openstackgerrit has joined #openstack-manila19:49
*** porrua has joined #openstack-manila19:56
*** wiebalck has quit IRC20:08
*** wiebalck has joined #openstack-manila20:09
waj334How does that Auto-Negotiation feature in the Manila API work exactly?20:12
*** xyang_ has quit IRC20:20
*** xyang_ has joined #openstack-manila20:21
*** wiebalck has quit IRC20:25
waj334Nevermind. Found the blueprint20:27
waj334again20:27
openstackgerritMarc Koderer proposed openstack/manila: [Tempest] Make share size configurable in scenario tests  https://review.openstack.org/39911620:27
bswartzwaj334: are you talking about the microversion negotiation?20:27
*** wiebalck has joined #openstack-manila20:39
*** timcl has joined #openstack-manila20:43
*** timcl has left #openstack-manila20:44
waj334bswartz: Yes. I'm trying to propose doing something similar for Cinder20:49
bswartzwaj334: the way it works is that the client always sends requests with the highest microversion it supports -- and if it receives a version error it retries with the highest mutually supported version (if there is one) or fails (if there's no mutually supported version)20:50
bswartzservers are expected to support several releases worth of old microversions to support old clients, and client are expected to support several releases worth of old microversions to support old servers20:52
*** xyang_ has quit IRC21:01
*** xyang_ has joined #openstack-manila21:01
*** wiebalck has quit IRC21:02
*** xyang_ has quit IRC21:05
*** xyang_ has joined #openstack-manila21:05
*** alyson_ has quit IRC21:07
*** dustins has quit IRC21:13
*** akapil has joined #openstack-manila21:23
*** akapil has quit IRC21:27
*** sticker has joined #openstack-manila21:38
*** porrua has quit IRC21:44
*** xyang_ has quit IRC21:55
*** xyang_ has joined #openstack-manila21:57
*** xyang_ has quit IRC22:00
*** eharney has quit IRC22:12
*** jcsp has quit IRC22:16
*** wiebalck has joined #openstack-manila22:17
*** wiebalck has quit IRC22:19
*** xyang_ has joined #openstack-manila22:22
*** xyang_ has quit IRC22:25
*** xyang_ has joined #openstack-manila22:26
*** lpetrut has quit IRC22:27
*** jprovazn has quit IRC22:31
*** nherciu_ has quit IRC22:34
*** ganso has quit IRC22:36
*** tpsilva has quit IRC23:05
*** catintheroof has quit IRC23:29
*** catintheroof has joined #openstack-manila23:30
*** catintheroof has quit IRC23:35
*** sticker has quit IRC23:42
*** sticker has joined #openstack-manila23:43

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