| *** tinwood has quit IRC | 00:00 | |
| *** tinwood has joined #openstack-manila | 00:02 | |
| *** xyang_ has quit IRC | 00:08 | |
| *** alyson_ has joined #openstack-manila | 00:10 | |
| *** catintheroof has joined #openstack-manila | 00:11 | |
| *** tuanluong has joined #openstack-manila | 00:35 | |
| TommyLikeHu | ping | 00:42 |
|---|---|---|
| *** catintheroof has quit IRC | 00:54 | |
| markstur | Hi Tommy | 00:55 |
| *** chlong has quit IRC | 01:11 | |
| *** akapil has joined #openstack-manila | 01:39 | |
| *** akapil has quit IRC | 01:44 | |
| TommyLikeHu | ping markstur, tbarron, zengyingzhe_, bswartz | 01:47 |
| TommyLikeHu | If we add extra_specs 'ip_support' in share type, I am confused which one should be the default value without declaratiom | 01:47 |
| *** zhugaoxiao has quit IRC | 01:47 | |
| TommyLikeHu | none or 4, which one is more reasonable, do you have any suggestion? | 01:48 |
| bswartz | TommyLikeHu: I propose ipv4_support and ipv6_support | 01:52 |
| bswartz | not ip_support | 01:53 |
| TommyLikeHu | bswartz: I am ok with it | 01:54 |
| TommyLikeHu | how about the default value (used for the existed share type..) | 01:54 |
| *** xyang_ has joined #openstack-manila | 01:55 | |
| *** xyang_ has quit IRC | 01:57 | |
| zengyingzhe_ | TommyLikeHu, so we'll have two individual extra specs, ipv4_support and ipv6_support? | 02:17 |
| TommyLikeHu | yes | 02:17 |
| zengyingzhe_ | TommyLikeHu, that's OK to me. | 02:17 |
| TommyLikeHu | and this is not the main concern around this spec | 02:18 |
| bswartz | TommyLikeHu: existing drivers should report capabilities ipv4_support=True and ipv6_support=False | 02:21 |
| bswartz | the extra specs should have no default value | 02:21 |
| TommyLikeHu | ok | 02:22 |
| TommyLikeHu | what should we do if I have a share type which created months ago and no extra_spec about ip version | 02:24 |
| TommyLikeHu | when create share with this one | 02:24 |
| TommyLikeHu | also mark mentioned we have native-glusterfs and native-cephfs driver which do not support IP access | 02:27 |
| zengyingzhe_ | TommyLikeHu, if ipv4_support and ipv6_support have no default value, I think it'll be OK to the drivers that don't support IP access. | 02:28 |
| zengyingzhe_ | then the scheduler won't filter the backends by those capabilities. | 02:29 |
| TommyLikeHu | oh~ got you | 02:29 |
| zengyingzhe_ | but for the drivers that do have IP support capabilities, for instance, if a driver reports it supports both v4&v6, then which version will be used if we don't specify the spec in share type? | 02:31 |
| TommyLikeHu | according to the share-network when creating share | 02:36 |
| TommyLikeHu | if it has | 02:36 |
| bswartz | zengyingzhe_: +1 | 02:49 |
| *** kaisers_ has joined #openstack-manila | 02:52 | |
| *** kaisers__ has quit IRC | 02:55 | |
| *** alyson_ has quit IRC | 03:07 | |
| *** tuanluong has quit IRC | 03:10 | |
| openstackgerrit | zhongjun proposed openstack/manila-specs: Add spec for enable IPv6 in manila https://review.openstack.org/362786 | 03:11 |
| *** tuanluong has joined #openstack-manila | 03:15 | |
| openstackgerrit | Xiaoyang Zhang proposed openstack/manila: Fix extend operation of shrinked share in generic driver https://review.openstack.org/393589 | 03:26 |
| *** zengyingzhe_ has quit IRC | 04:28 | |
| *** zengyingzhe_ has joined #openstack-manila | 04:28 | |
| *** wiebalck has joined #openstack-manila | 04:58 | |
| *** lpetrut has joined #openstack-manila | 05:01 | |
| *** shausy has joined #openstack-manila | 05:08 | |
| openstackgerrit | Merged openstack/manila-specs: Add detail API to quota-set API collection https://review.openstack.org/390052 | 05:22 |
| *** akapil has joined #openstack-manila | 05:56 | |
| *** digvijay2016 has joined #openstack-manila | 05:59 | |
| *** akapil has quit IRC | 06:00 | |
| *** sandanar has joined #openstack-manila | 06:07 | |
| *** sandanar_ has joined #openstack-manila | 06:08 | |
| *** sandanar has quit IRC | 06:08 | |
| *** sandanar_ has quit IRC | 06:08 | |
| *** sandanar has joined #openstack-manila | 06:09 | |
| *** wiebalck has quit IRC | 06:12 | |
| TommyLikeHu | ping zengyingzhe_ | 06:13 |
| *** dsariel has joined #openstack-manila | 06:55 | |
| *** lpetrut has quit IRC | 07:08 | |
| *** nkrinner_afk is now known as nkrinner | 07:24 | |
| *** nherciu has joined #openstack-manila | 07:24 | |
| zengyingzhe_ | TommyLikeHu, hi | 07:26 |
| TommyLikeHu | thanks, I uploaded an new patch on IPv6,could you take a look?https://review.openstack.org/#/c/362786/ | 07:28 |
| openstackgerrit | zhongjun proposed openstack/manila-specs: Add spec for enable IPv6 in manila https://review.openstack.org/362786 | 07:34 |
| zengyingzhe_ | TommyLikeHu, sure | 07:36 |
| *** zhongjun_ has joined #openstack-manila | 07:40 | |
| *** pcaruana has joined #openstack-manila | 07:45 | |
| *** belmoreira has joined #openstack-manila | 07:51 | |
| *** sticker_ has joined #openstack-manila | 07:57 | |
| *** sticker has quit IRC | 08:00 | |
| *** tuanluong has quit IRC | 08:01 | |
| *** openstackgerrit has quit IRC | 08:03 | |
| *** openstackgerrit has joined #openstack-manila | 08:04 | |
| *** jprovazn has joined #openstack-manila | 08:28 | |
| *** sandanar has quit IRC | 08:49 | |
| *** sandanar has joined #openstack-manila | 08:51 | |
| *** belmoreira has quit IRC | 09:03 | |
| *** akapil has joined #openstack-manila | 09:06 | |
| *** akapil has quit IRC | 09:06 | |
| *** akapil has joined #openstack-manila | 09:06 | |
| *** akapil has quit IRC | 09:11 | |
| *** akapil has joined #openstack-manila | 09:13 | |
| *** ganso has joined #openstack-manila | 09:49 | |
| *** rraja has joined #openstack-manila | 09:55 | |
| *** rraja has quit IRC | 09:55 | |
| openstackgerrit | Xiaoyang Zhang proposed openstack/manila: Fix share-service VM restart problem https://review.openstack.org/393594 | 09:58 |
| *** belmoreira has joined #openstack-manila | 10:17 | |
| ganso | bswartz: ping | 10:32 |
| *** ociuhandu has joined #openstack-manila | 10:38 | |
| *** senk has joined #openstack-manila | 10:44 | |
| openstackgerrit | Merged openstack/python-manilaclient: Updated from global requirements https://review.openstack.org/395368 | 10:46 |
| *** nkrinner is now known as nkrinner_trainin | 10:47 | |
| *** lpetrut has joined #openstack-manila | 10:49 | |
| openstackgerrit | Cedric Zhuang proposed openstack/manila: Add "update_access" interface support for VNX. https://review.openstack.org/395404 | 10:54 |
| *** akapil has quit IRC | 10:55 | |
| *** ociuhandu has quit IRC | 10:56 | |
| *** lpetrut1 has joined #openstack-manila | 11:01 | |
| *** lpetrut has quit IRC | 11:01 | |
| *** lpetrut1 is now known as lpetrut | 11:01 | |
| *** rraja has joined #openstack-manila | 11:07 | |
| *** akapil has joined #openstack-manila | 11:07 | |
| ganso | vponomaryov, toabctl, tbarron: Hello guys, could you please take a look at https://review.openstack.org/#/c/392291/ ? Thanks in advance | 11:08 |
| *** ociuhandu has joined #openstack-manila | 11:08 | |
| *** tpsilva has joined #openstack-manila | 11:17 | |
| *** akapil has quit IRC | 11:20 | |
| *** lpetrut has quit IRC | 11:27 | |
| *** akapil has joined #openstack-manila | 11:30 | |
| *** shausy has quit IRC | 11:32 | |
| *** lpetrut has joined #openstack-manila | 11:40 | |
| *** digvijay2016 has quit IRC | 11:48 | |
| openstackgerrit | Mauricio Lima proposed openstack/manila-specs: Spec for openstack client support https://review.openstack.org/395775 | 11:49 |
| *** lpetrut has quit IRC | 11:56 | |
| *** dsariel has quit IRC | 12:05 | |
| openstackgerrit | zhongjun proposed openstack/manila-specs: Add spec for enable IPv6 in manila https://review.openstack.org/362786 | 12:06 |
| openstackgerrit | Merged openstack/manila: [Tempest] Make share size configurable in scenario tests https://review.openstack.org/399116 | 12:08 |
| openstackgerrit | zhongjun proposed openstack/manila-specs: Add spec for enable IPv6 in manila https://review.openstack.org/362786 | 12:11 |
| openstackgerrit | Mauricio Lima proposed openstack/manila-specs: Spec for openstack client support https://review.openstack.org/395775 | 12:27 |
| *** mliima has joined #openstack-manila | 12:27 | |
| mliima | vponomaryov, i still don't know much about microversions, im trying to better understand it :/ | 12:29 |
| mliima | https://review.openstack.org/#/c/395775/ | 12:29 |
| vponomaryov | mliima: https://www.openstack.org/videos/barcelona-2016/api-microversions-for-operators-what-why-and-how | 12:35 |
| vponomaryov | mliima: its support is a must | 12:36 |
| vponomaryov | mliima: nova and cinder use microversions as well as manila | 12:36 |
| ganso | mliima: you could take a look at how Cinder and Nova are handling it in their openstack client | 12:39 |
| *** gcb has quit IRC | 12:40 | |
| *** porrua has joined #openstack-manila | 12:43 | |
| *** alyson_ has joined #openstack-manila | 12:50 | |
| mliima | ok vponomaryov, ganso | 12:56 |
| *** senk has quit IRC | 13:07 | |
| *** akapil_ has joined #openstack-manila | 13:30 | |
| *** akapil_ has quit IRC | 13:31 | |
| *** akapil_ has joined #openstack-manila | 13:31 | |
| *** akapil has quit IRC | 13:34 | |
| *** timcl has joined #openstack-manila | 13:41 | |
| openstackgerrit | zhongjun proposed openstack/manila-specs: Add spec for enable IPv6 in manila https://review.openstack.org/362786 | 13:41 |
| *** porrua has quit IRC | 13:42 | |
| *** tpatzig_1 has quit IRC | 13:43 | |
| *** mkoderer_ has quit IRC | 13:43 | |
| *** sapcc-bot1 has quit IRC | 13:43 | |
| *** david_1 has joined #openstack-manila | 13:44 | |
| *** sapcc-bot has joined #openstack-manila | 13:44 | |
| *** tpatzig_ has joined #openstack-manila | 13:44 | |
| *** tommy_ has joined #openstack-manila | 13:44 | |
| *** dgonzalez_ has joined #openstack-manila | 13:44 | |
| *** tommy_ is now known as Guest67005 | 13:44 | |
| *** Guest67005 has quit IRC | 13:46 | |
| *** dgonzalez_ has quit IRC | 13:46 | |
| *** david_1 has quit IRC | 13:46 | |
| *** dmellado is now known as dmellado|lunch | 13:50 | |
| *** senk has joined #openstack-manila | 13:51 | |
| *** dmellado|lunch is now known as dmellado | 14:12 | |
| *** senk has quit IRC | 14:15 | |
| *** dsariel has joined #openstack-manila | 14:20 | |
| *** jcsp has joined #openstack-manila | 14:26 | |
| *** porrua has joined #openstack-manila | 14:26 | |
| *** akapil_ has quit IRC | 14:35 | |
| *** zengyingzhe has joined #openstack-manila | 14:36 | |
| *** akapil has joined #openstack-manila | 14:36 | |
| *** akapil has joined #openstack-manila | 14:47 | |
| bswartz | ganso: https://review.openstack.org/#/c/398508 | 14:49 |
| ganso | bswartz: I did read not the bug report in the detail, according to the patch description it seemed like a minor bugfix and not critical | 14:52 |
| bswartz | ganso: after reading the bug report do you still think it's not critical? | 14:52 |
| *** chlong has joined #openstack-manila | 14:53 | |
| bswartz | it's easy to write off UI issues as not-critical because they don't affect the server, but within the UI project, broken pages seem critical | 14:53 |
| ganso | bswartz: I am looking for the attached screenshot "See attached screenshot. All limits are expected to be located in a row, but now they are located one-by-line." | 14:53 |
| ganso | bswartz: found it | 14:53 |
| ganso | bswartz: ok, seems critical | 14:54 |
| bswartz | I also feel it's pretty low risk to backport it | 14:54 |
| bswartz | definitely not someone trying to sneak in a new feature as a bugfix | 14:54 |
| TommyLikeHu | lol | 14:55 |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila-specs: Add spec for Manila share groups https://review.openstack.org/315730 | 14:56 |
| ganso | bswartz: definitely not trying to sneak in a feature. As I said, according to the patch description and code it did not seem like a critical bugfix | 14:57 |
| ganso | bswartz: anyway | 14:57 |
| ganso | bswartz: I +A'e | 14:57 |
| ganso | bswartz: +A'ed | 14:57 |
| ganso | bswartz: Could you please take a look at the Data Jobs spec? that is one last concern that I think you are more familiar with to comment on | 14:59 |
| ganso | bswartz: it seems that the approach proposed would depend on tooz to prevent race conditions | 14:59 |
| *** eharney has joined #openstack-manila | 15:00 | |
| bswartz | everything depends on tooz to prevent race conditions | 15:05 |
| bswartz | only other solution is to avoid races altogether | 15:05 |
| ganso | bswartz: yes, so if we have tooz in Ocata, the feature can be implemented without problems. If we don't, either we have more race conditions, or we need to figure out another approach | 15:06 |
| *** zengyingzhe has quit IRC | 15:20 | |
| *** nkrinner_trainin is now known as nkrinner | 15:22 | |
| openstackgerrit | zhongjun proposed openstack/manila-specs: Add spec for enable IPv6 in manila https://review.openstack.org/362786 | 15:23 |
| *** lpetrut has joined #openstack-manila | 15:25 | |
| openstackgerrit | Tiago Pasqualini da Silva proposed openstack/manila-specs: Add spec for mountable snapshots https://review.openstack.org/321213 | 15:26 |
| tpsilva | vponomaryov: please see my answers ^ | 15:26 |
| tbarron | ganso: on the Data Jobs spec I wasn't asking you to solve the general races problem, but rather to indicate that a race will need to be avoided, which service will take care of it, what will be the critical region, scope of potential race (threads, processes within a node, processes on multiple nodes, ...) | 15:26 |
| vponomaryov | tpsilva: let's talk here | 15:27 |
| vponomaryov | tpsilva: your comment "And how are old ones going to get the export location?" - who old ones? | 15:27 |
| tpsilva | vponomaryov: the existing snapshots | 15:28 |
| tpsilva | vponomaryov: when you happen to update manila | 15:28 |
| vponomaryov | tpsilva: nohow, that feature was not supported | 15:29 |
| *** sandanar has quit IRC | 15:29 | |
| tpsilva | vponomaryov: makes sense... new share type is needed also | 15:30 |
| tpsilva | vponomaryov: ok, now I get it | 15:30 |
| tpsilva | vponomaryov: for the extra API calls, do you think they are needed? | 15:31 |
| vponomaryov | tpsilva: what "extra" API calls? | 15:31 |
| tpsilva | vponomaryov: export location show for snapshots and snapshot instances | 15:31 |
| vponomaryov | oh, those | 15:31 |
| vponomaryov | why extra? ) | 15:31 |
| tpsilva | vponomaryov: because they're not on the original proposal :) | 15:32 |
| vponomaryov | tpsilva: using this APi you see all details of an EL | 15:32 |
| vponomaryov | tpsilva: that you do not see using "list" API | 15:32 |
| vponomaryov | tpsilva: the fact that you do not use does not mean other do not use | 15:32 |
| tpsilva | vponomaryov: it makes sense for shares, since EL has a lot of metadata, but snapshot EL only has paths | 15:32 |
| *** nherciu has quit IRC | 15:32 | |
| vponomaryov | tpsilva: "is_admin_only" will be only there | 15:33 |
| vponomaryov | tpsilva: "preffered" | 15:33 |
| vponomaryov | ^ attributes of an export location | 15:33 |
| tpsilva | vponomaryov: those were not on my original implementation, but I probably should add them | 15:34 |
| tpsilva | vponomaryov: alright, I'll make those changes | 15:34 |
| ganso | tbarron: thanks for the clarification, I am thinking on a possible approach that does not run into race conditions before sending an update that states that we depend on tooz | 15:34 |
| tpsilva | vponomaryov: anything else to achieve your +2? :) | 15:35 |
| vponomaryov | tpsilva: yes | 15:37 |
| vponomaryov | tpsilva: link https://review.openstack.org/#/c/321213/15/specs/ocata/mountable-snapshots.rst@194 refers to wrong spec | 15:37 |
| vponomaryov | tpsilva: or description is wrong | 15:37 |
| tpsilva | vponomaryov: lol, not sure why I keep linking it to the wrong spec | 15:37 |
| tpsilva | vponomaryov: brain fart | 15:37 |
| *** senk has joined #openstack-manila | 15:41 | |
| openstackgerrit | Tiago Pasqualini da Silva proposed openstack/manila-specs: Add spec for mountable snapshots https://review.openstack.org/321213 | 15:43 |
| tbarron | ganso: a design that doesn't require locks is even better. | 15:44 |
| tpsilva | vponomaryov: thank you, also ^ | 15:44 |
| ganso | tbarron: yes, I am trying to figure that out... :\ | 15:44 |
| *** senk has quit IRC | 15:44 | |
| *** senk has joined #openstack-manila | 15:45 | |
| *** senk has quit IRC | 15:45 | |
| ganso | tbarron: anytime there are more than 1 consumir this is bound to happen | 15:45 |
| openstackgerrit | Tiago Pasqualini da Silva proposed openstack/manila-specs: Add spec for mountable snapshots https://review.openstack.org/321213 | 15:45 |
| tpsilva | there was a minor formatting error | 15:46 |
| ganso | tbarron: I am thinking about using the rabbit RPCs to sort this out, it already addresses this problem when one service reads the message first | 15:46 |
| ganso | tbarron: but then we need a single entity to produce this RPC message, which is now another problem | 15:47 |
| ganso | tbarron: as we may have several manila-shr or several data services that could create this message, and would need locking to do so as well... unless all jobs are started manually | 15:47 |
| ganso | tbarron: but it would need an API and it kinda defeats the purpose | 15:48 |
| *** pcaruana has quit IRC | 15:50 | |
| tbarron | ganso: ack | 15:51 |
| TommyLikeHu | hey manila members, if the IPv6 spec can't manage to merge in O-1, can we keep on this and reach an agreement on this spec in Ocata? with this we can shift some framework code and debug jobs in Ocata, and may reduce some risk. | 15:56 |
| bswartz | TommyLikeHu: as long as you keep working on it we can get it done in ocata -- we've designated this effort high priority so we'll make sure the reviews happen | 15:57 |
| *** belmoreira has quit IRC | 15:57 | |
| ganso | bswartz: doesn't it have to merge to be designated as hi-pri? | 15:58 |
| ganso | bswartz: ^ the patch that marks it hi-pri | 15:58 |
| bswartz | ganso: yes and I just workflowed that chain of patches | 15:59 |
| ganso | bswartz: oh ok, it is hi-pri now | 15:59 |
| bswartz | the important part of the discussion happened in the weekly meeting | 15:59 |
| bswartz | I wanted to wait 24 hours before workflowing in case someone had objections they didn't get a chance to share | 16:00 |
| *** jprovazn has quit IRC | 16:01 | |
| openstackgerrit | Merged openstack/manila-specs: Mark Eliminate Race Conditions high priority https://review.openstack.org/399135 | 16:01 |
| openstackgerrit | Merged openstack/manila-specs: Mark Fix and improve Access Rules high priority https://review.openstack.org/399138 | 16:01 |
| openstackgerrit | Merged openstack/manila-specs: Mark Enable IPv6 high priority https://review.openstack.org/399140 | 16:01 |
| openstackgerrit | Merged openstack/manila-specs: Add spec for Share Migration Ocata improvements https://review.openstack.org/392291 | 16:04 |
| openstackgerrit | Ben Swartzlander proposed openstack/manila-specs: Fix table of Ocata priorities https://review.openstack.org/399669 | 16:14 |
| bswartz | ^ this fixes a dumb error in the priorities table | 16:16 |
| bswartz | I didn't check how the rst would render before committing... | 16:16 |
| tbarron | tpsilva: ganso bswartz on the moutable snapshot spec https://review.openstack.org/#/c/321213 did we settle the question gouthamr posed in the review of PS11: should spec state explicitly that if driver cannot support separate export locations for share and snapshot, then it shold not set ''mouont_snapshot_support'' capability True (even if it could allow mounts but only with no separation of export locations from those of the | 16:18 |
| tbarron | original shares) ? | 16:18 |
| tbarron | tpsilva: I think we implicitly decided +1 on that, but is it said explicitly in the spec, I'm not seeing it. | 16:18 |
| *** nherciu has joined #openstack-manila | 16:19 | |
| tbarron | tpsilva: bswartz ganso I'm ready to +2 except that I don't want to re-visiit/re-argue that issue during implementation, or worse, when drivers implement the capabiltiy | 16:19 |
| tpsilva | tbarron: Some users or systems that do not have access to the parent share might need access to the snapshot, so the access rules for the snapshot must be separated from its parent share. | 16:20 |
| tbarron | tpsilva: +1 | 16:20 |
| tpsilva | tbarron: is this what you mean? | 16:20 |
| tbarron | tpsilva: there are real use cases | 16:20 |
| tpsilva | tbarron: that part is on the proposal section of the spec | 16:20 |
| tbarron | tpsilva: that is clear | 16:20 |
| tbarron | tpsilva: look at gouthamr's remarks is PS11, he asked whether you should explicitly state that in order for a driver to claim support of this capability they must genuinely be able to support this separation. | 16:21 |
| tbarron | tpsilva: they must not e.g. just fake it, cloing form the share, and erroring if you thry to set difft export locations on the snapshot | 16:22 |
| tbarron | cloning export locatioonns | 16:22 |
| * tbarron can't type | 16:22 | |
| bswartz | tbarron: drivers need to match the semantics manila expects to advertise the capability | 16:23 |
| tpsilva | tbarron: but doesn't that part that I copied already states that? | 16:23 |
| bswartz | it's irrelevant if they can do something similar but not what's expected | 16:23 |
| bswartz | Ideally test code would verify that the behavior was correct | 16:24 |
| tbarron | bswartz: tpsilva ok, I'll plus 2 and cite this IRC convo. Just want something in the spec, or at least the review, that can be pointed to. | 16:25 |
| tbarron | bswartz: tpsilva one purpose of specs is to avoid ambiguity and rehash later | 16:26 |
| tpsilva | tbarron: it's better to add this then... just a sec | 16:27 |
| tbarron | tpsilva: thanks for indulging me | 16:29 |
| *** surabujin has quit IRC | 16:29 | |
| openstackgerrit | Tiago Pasqualini da Silva proposed openstack/manila-specs: Add spec for mountable snapshots https://review.openstack.org/321213 | 16:30 |
| tpsilva | tbarron: does this look ok? ^ | 16:30 |
| tbarron | tpsilva: perfect | 16:31 |
| tbarron | bswartz: ganso your +2s are needed again | 16:31 |
| tpsilva | and also vponomaryov's :D | 16:31 |
| tbarron | bswartz: ganso vponomaryov https://review.openstack.org/#/c/321213/18 | 16:31 |
| openstackgerrit | Merged openstack/manila-specs: Fix table of Ocata priorities https://review.openstack.org/399669 | 16:36 |
| *** ChanServ changes topic to "OpenStack Shared File Systems | Manila | Spec freeze 11/18" | 16:36 | |
| *** akapil has quit IRC | 16:40 | |
| *** dsariel has quit IRC | 16:41 | |
| ganso | tbarron: are you familiar with how the manila-scheduler is deployed in HA envs? | 16:47 |
| ganso | tbarron: I am thinking about it as the single entity that takes the decisions | 16:47 |
| bswartz | ganso: very carefully | 16:48 |
| tbarron | ganso: we deploy both scheduler and api today active-active, managed by systemd rather than pacemaker | 16:48 |
| bswartz | ganso: and it's not a single decider -- each scheduler makes decisions independently | 16:48 |
| tbarron | ganso: there are races (in api) but so far they are more bad-user-experience problems than data corruption | 16:48 |
| ganso | bswartz: hmmm, ok, so it does not solve our problems if we have 2 or more schedulers making decisions | 16:49 |
| tbarron | ganso: sheduler likely not so much subject to races as api | 16:49 |
| *** surabujin has joined #openstack-manila | 16:49 | |
| bswartz | solve what problems? | 16:49 |
| *** makowals has quit IRC | 16:49 | |
| ganso | bswartz: the one in data jobs table spec | 16:49 |
| bswartz | oh | 16:49 |
| tbarron | ganso: the default HA deployment is with three controllers running API and scheduleers | 16:50 |
| *** makowals has joined #openstack-manila | 16:50 | |
| ganso | tbarron: I wasn't sure if schedulers were Active/Active and if there was more than one. My lab production deployment does not have redundant schedulers I think | 16:51 |
| tbarron | bswartz: I realized the reason for 3 is probably less load-sharing than that some of the services (non-manila) that run on controllers in this deployment need to do quorum among themselves | 16:51 |
| bswartz | tbarron: that's ridiculously dangerous if you don't do it right | 16:51 |
| tbarron | ganso: yeah, we standardly do either 3 of api and scheduler or just 1 (non-HA deployment). in psp-10 (our newton based release) we'll have 'composable roles' that allow more mix and match | 16:52 |
| tbarron | bswartz: what is "that' - deployinng 3 schedulers, 3 apis, or a more general issue? | 16:53 |
| bswartz | how do services know when they're out of quorum? | 16:53 |
| *** makowals has quit IRC | 16:53 | |
| *** makowals has joined #openstack-manila | 16:54 | |
| tbarron | bswartz: oh, *that* - I dunno offhand, but for the services in question I think it's old territory. | 16:54 |
| bswartz | the idea that simply supporting active/active HA and then making lots of copies protects you from Bad Things (tm) | 16:54 |
| tbarron | bswartz: I don't think that's the general idea | 16:54 |
| bswartz | active/active configurations actually opens you up to more problems than active/passive | 16:55 |
| tbarron | bswartz: some services (mongodb as ex I've heard) quite apart from openstack know how to do their own quorum, etc. | 16:55 |
| tbarron | bswartz: ceph services do that stuff themselves | 16:55 |
| bswartz | I hope the people designing this stuff have thought through the netsplit scenarios | 16:55 |
| tbarron | bswartz: well that's what **I** keep sayign when we say we'll just solve all the issues for DLM by running tooz !! | 16:56 |
| bswartz | you have to have quorum at every level of the stack though and the different levels need to agree with eachother | 16:56 |
| tbarron | bswartz: tooz is nice abstraction, but the devil is in the details with its backends and deployment of same | 16:57 |
| openstackgerrit | Tiago Pasqualini da Silva proposed openstack/manila-specs: Add spec for mountable snapshots https://review.openstack.org/321213 | 16:57 |
| tpsilva | bswartz, ganso, tbarron, gouthamr, vponomaryov, markstur: hopefully last one ^ | 16:57 |
| bswartz | if you have 3 DBs and 3 services, and DBs A+B are in quorum but services B+C are in quorum then when service C talk to DB C you get breakage | 16:57 |
| *** makowals has quit IRC | 16:58 | |
| tbarron | bswartz: to be clear, I'm **not** saying that all services that run on our 3 controllers are determiinging quorum, only some special ones, and that until osp-10 the three-controller arch is the standard HA arch. | 16:59 |
| bswartz | k | 16:59 |
| tbarron | the other services are supposed to be safe (enough) to run active-active on their own right | 16:59 |
| bswartz | I hope there's some kind of stonith mechanism to prevent surviving out-of-quorum services from doing evil things | 17:00 |
| tbarron | bswartz: as I say, for those services that do quorum stuff, I think they implement well-known design patterns, but I'm no expert in those areas. | 17:01 |
| tbarron | bswartz: was just remembering you asking "why three, api isn't really that likely to require 3 just to handle load" | 17:01 |
| bswartz | my point was that manila doesn't have anything like that -- so unless it exists externally, we'll have problems | 17:01 |
| tbarron | tpsilva: looking | 17:01 |
| tbarron | bswartz: maniila is right now being deployed like cinder, with hand-waving for api | 17:02 |
| tbarron | bswartz: with the thought that there are already races there even with one node, but they don't kill us | 17:02 |
| bswartz | yeah I presume someone has thought about this stuff but it's so complex that I'm not confident that all necessary precautions are being taken | 17:02 |
| tbarron | bswartz: but with enough worry about consequences of races in the share/volume services that they are put under pacemaker control and run active/passive | 17:03 |
| ganso | vponomaryov: are you here? | 17:04 |
| vponomaryov | ganso: yes | 17:04 |
| ganso | vponomaryov: just saw the change in tpsilva's latest patch | 17:04 |
| ganso | vponomaryov: not sure if I agree, because I am thinking of a case where it is best to have the other way around | 17:04 |
| vponomaryov | ganso: ? | 17:05 |
| ganso | vponomaryov: I think it is best if backends provide the export location for the snapshot during allow | 17:05 |
| vponomaryov | ganso: then let's return export locations via allow | 17:06 |
| *** rraja has quit IRC | 17:06 | |
| vponomaryov | ganso: still no need to have third driver interface | 17:07 |
| ganso | vponomaryov: in case a share is created in a backend that supports mountable snapshots, but using a share type that says mountable_snapshots=False, creates a snapshot, but then it is retyped to a type that says mountable_snapshot=True, then it should be able to provide the export_locations, but it is unable to do so now because that was defined only at | 17:07 |
| ganso | creation time | 17:07 |
| vponomaryov | ganso: (19:07:08) vponomaryov: ganso: still no need to have third driver interface | 17:08 |
| ganso | vponomaryov: I don't see this third driver interface anywhere | 17:09 |
| ganso | vponomaryov: which PS was it introduced? | 17:09 |
| markstur | ganso: I wonder if any driver would provide export location at creation and not be able to afterwords. Just wonder. | 17:10 |
| ganso | markstur: but share manager would need something to invoke it | 17:10 |
| ganso | markstur: drivers would certainly be able | 17:10 |
| ganso | markstur: but I am concerned with the workflow, it is only invoked by share manager like "snap_exports = driver.create_snapshot..." then at what other point after a retype will this be invoked again? | 17:11 |
| markstur | ganso: probably. It's kind of rare for new features to work retroactively on old entities. Might expose problems. I'm not very concerned in this case. | 17:11 |
| vponomaryov | ganso: if drivers return export locations from "create_snapshot" and "allow_snapshot_access" methods, what problem are you expecting? | 17:11 |
| vponomaryov | ganso: without access it is useless to have export location | 17:12 |
| markstur | So if we follow the share model and export locations are done at creation (and retype? and migration) there is less adhoc asking for them | 17:12 |
| ganso | vponomaryov: exactly, it must the return value of snapshot_allow_access | 17:13 |
| markstur | I'm not seeing real concerns -- but the more it aligns w/ our current share impl the better (probably) | 17:13 |
| markstur | So should shares only return and export_loc after allow access? Probably. | 17:14 |
| markstur | oops | 17:14 |
| ganso | markstur: yes, I am thinking in a bit of advance because the design decision here may be less significant looking just at the mountable_snapshots implementation but later for retype it would complicate things | 17:14 |
| ganso | markstur: lol we are almost walking into a different discussion | 17:15 |
| markstur | I worry less about retype because when you do that it is more of a free-for-all to change stuff | 17:15 |
| markstur | But you are more "into" retype. So I'll trust you on that | 17:15 |
| markstur | OK. Let's stop looking at today's specs and argue about retype :) | 17:16 |
| vponomaryov | retype "snapshot"? | 17:16 |
| vponomaryov | really? | 17:16 |
| ganso | vponomaryov: no, retype share lol | 17:17 |
| vponomaryov | then we have more questions here, what to do with all the snapshots retyping share? | 17:17 |
| vponomaryov | access for them, when we change network? | 17:17 |
| ganso | vponomaryov: retype shares that have previous snapshots, in this case it would be just changing a flag, by retyping from a type that does not have mountable_snapshots extra spec to one that does and set to True | 17:17 |
| vponomaryov | Rodrigo, I guess it is question of "retype" spec | 17:18 |
| vponomaryov | not this one | 17:18 |
| ganso | vponomaryov: depending on this design, it can either be hell for retype feature, or just easily manageable change | 17:18 |
| bswartz | retype will need all of the flags that migration needs | 17:19 |
| vponomaryov | hell? It is heaven compared to real coding hell that may be faced )) | 17:19 |
| bswartz | including stuff like --preserve-snapshots which won't work in the default case | 17:19 |
| ganso | bswartz: problem is not API, it is driver interface | 17:19 |
| ganso | bswartz: share manager needs to be able to ask for snapshot export locations even after snapshot has been already created | 17:20 |
| ganso | bswartz: if it is only at creation time, then it is more complicated for retype. I don't see why it cannot be on snapshot_allow_access | 17:20 |
| bswartz | ganso: don't we just store it in the DB? | 17:21 |
| bswartz | when the driver returns from snasphot creation? | 17:21 |
| vponomaryov | bswartz: ganso is talking about upgrade existing cloud and retping share | 17:21 |
| markstur | Poor man's retype feature: Click retype. Get user notification that says your share was unfortunately deleted. Please start over. | 17:21 |
| ganso | bswartz: yes, but if this snapshot has been created before the retype, when the mountable_snapshot extra spec was not present in the share type when the snapshot was created | 17:22 |
| bswartz | okay I see a flaw in the design then | 17:22 |
| markstur | OK. User notification should not be part of "poor man's" feature so I guess it would just be logged | 17:22 |
| vponomaryov | markstur: even worse, we do not have user notifications ^_^ | 17:22 |
| bswartz | snapshots should *always* return export locations at creation time | 17:22 |
| ganso | bswartz: ok, what about after? | 17:22 |
| bswartz | and those export locations need to be updated by any migrations (including retypes) that are able to preserve snapshots | 17:23 |
| *** adrianofr_ has quit IRC | 17:23 | |
| markstur | +1 | 17:23 |
| bswartz | ganso: export locations never change | 17:23 |
| markstur | wait | 17:23 |
| vponomaryov | bswartz: actually, they can | 17:23 |
| vponomaryov | bswartz: when IP of a host changes | 17:23 |
| bswartz | technically a migration that preserve snapshots actually creates new instances | 17:24 |
| vponomaryov | and configuration of a driver | 17:24 |
| markstur | He bswartz just said updated them and then said they never change | 17:24 |
| ganso | bswartz: in this case he retype does not move the share or the snapshots | 17:24 |
| bswartz | markstur: I meant 1 instance never changes, and if it moves the new instance has a new export location | 17:24 |
| markstur | Ahhh | 17:24 |
| bswartz | and the snapshot should get its export location from the active snapshot instance | 17:24 |
| bswartz | but vponomaryov has a point | 17:25 |
| ganso | bswartz: what retype would do in this case is notice that it is only mountable_snapshots that is changed from "dont care" to True, and then it needs to return the export locations to the share manager for update | 17:25 |
| bswartz | vponomaryov: how does manila discover changed export locations for shares? | 17:25 |
| vponomaryov | bswartz: checking shares on restart of a manila-share service | 17:26 |
| ganso | bswartz: but if the design of mountable_snapshot was different, as I am suggesting, then it would not need to do that, so when allow_snapshot_access is invoked, it would return/update the export_location | 17:26 |
| markstur | ensure | 17:26 |
| vponomaryov | bswartz: but it is up-to-the-driver to just mock it | 17:26 |
| bswartz | vponomaryov: that's something we planned to remove | 17:26 |
| vponomaryov | bswartz: I faced such problem when was coding ZFSonLinux driver | 17:26 |
| bswartz | it was a topic we didn't get to in BCN | 17:26 |
| bswartz | ensure share must die | 17:27 |
| ganso | bswartz: we planned to remove ensure because it is "jack-of-all-trades" but replace it with functionality that actually focuses on doing one thing specifically | 17:27 |
| markstur | When we do retype. A retype could allow retype to same share-type just to refresh stuff including share type changes and also things like IP changes I s'pose | 17:27 |
| bswartz | ganso: I still don't like the idea of going back to the driver to get information the manager should already know | 17:28 |
| bswartz | it's a scalability nightmare | 17:28 |
| markstur | And I guess a future ensure_share_v2() could do that also -- but only after it is really defined what it should/shouldn't do | 17:28 |
| bswartz | markstur ganso: we NEED to have the discussion about ensure share soon it sounds like | 17:29 |
| markstur | soon as in later. not now | 17:29 |
| ganso | bswartz: we did not get a spec for it... so I guess it is not changing in Ocata anymore | 17:29 |
| bswartz | if correctness of features going into ocata depends on it then we have a problem | 17:30 |
| tpsilva | what about my spec? will it be merged as is? do I need address rodrigo's concerns? | 17:30 |
| markstur | If any of you are looking at IPv6 now -- I have questioned in there the whole optional spec vs. in-the-model spec. | 17:30 |
| bswartz | we either have to postpone those features or solve the issues now | 17:30 |
| bswartz | markstur: where? they should be ordinary extra specs | 17:30 |
| markstur | The IPv6 spec is adding ipv4 and ipv6 to the share model | 17:31 |
| bswartz | okay that I don't agree with | 17:31 |
| markstur | I'm hoping it is more like dedup and less like snapshot_support | 17:31 |
| bswartz | yes | 17:31 |
| bswartz | particularly because it can change over time | 17:31 |
| markstur | Good. So I commented in there, but don't want TommyLikeHu or whoever is rewriting to have to go back and forth | 17:32 |
| bswartz | a backend that was ipv4 only can gain ipv6 support quite easily | 17:32 |
| ganso | bswartz: it kinda suffers from the same problem, needs to refresh after retype | 17:32 |
| markstur | retype retype retype | 17:32 |
| markstur | everyone wants retype. Where's ganso? | 17:32 |
| ganso | bswartz: but vponomaryov's point is important as well, if it changes IP, needs to refresh, so we would need ensure | 17:32 |
| markstur | Ugh | 17:33 |
| bswartz | ganso: the theory there is that you shouldn't change IPs | 17:33 |
| bswartz | changing a backend's IP will break all ongoing access | 17:33 |
| bswartz | adding a new IP is less dangerous, but you really can never take one away without breaking somebody | 17:33 |
| tpsilva | we can try to support everything and have a whole lot of broken features, or we can have limited but solid features | 17:34 |
| tpsilva | you can't have both | 17:34 |
| ganso | bswartz, markstur: I am also thinking about how we can migrate to new features without having to re-create all the resources. The IPv6 case is probably the best one. We have several existing IPv4 shares and now we want them to support IPv6 as well, how do we do that? | 17:34 |
| markstur | Safest it so say new feature apply to new entities | 17:34 |
| markstur | Old features don't get them | 17:34 |
| bswartz | ganso: in that case it would be ideal for new export location to magically appear | 17:34 |
| ganso | bswartz: yes | 17:35 |
| markstur | Doing retroactive features is awesome, but it leads to cases that just can't. | 17:35 |
| tpsilva | markstur: +1 | 17:35 |
| ganso | bswartz: if share is in a backend that already supports the feature, but it needs to have its share-type changed accordingly | 17:35 |
| tpsilva | I'm always in favor of limited features that work as they should, instead of features that promise to do evertyhing but simply don't | 17:36 |
| markstur | Another safety thing is to say we can retrofix, but you need to use retype to do it. OK I said 'retype' again. Everybody drink. | 17:36 |
| ganso | markstur: lol | 17:36 |
| bswartz | the main question is how do you know if you can add a v6 access rule | 17:36 |
| * markstur takes a couple more huge gulps of coffee | 17:37 | |
| bswartz | or a v4 access rule if you started out with a v6-only share | 17:37 |
| ganso | bswartz: according to the spec, the validation is by checking the share's export location | 17:37 |
| bswartz | oh, I like that | 17:37 |
| ganso | bswartz: if it has IPv4 EL you can accept IPv4 rules | 17:37 |
| bswartz | +1 | 17:38 |
| markstur | Does that mean just looking for colons vs dots in EL? | 17:38 |
| bswartz | so the only challenge then is how does the manager become aware that new export locations are available | 17:38 |
| ganso | markstur: using a library that properly parses it, yes | 17:39 |
| bswartz | markstur: we'd add a column to the table | 17:39 |
| bswartz | NFS export locations always have colons | 17:39 |
| bswartz | and IPv6 addresses technically can have dots | 17:39 |
| markstur | ok. so we'll have a is_v6() is_v4() and don't need metadata that says what it is | 17:39 |
| ganso | bswartz: we would need ensure_share? | 17:40 |
| markstur | bswartz: yeah but you knew what I meant I think. Parsing to detect vs. metadata. | 17:40 |
| bswartz | ganso: NO! | 17:40 |
| ganso | bswartz: lol | 17:40 |
| bswartz | #die_ensure_share_die | 17:40 |
| markstur | LOL | 17:40 |
| markstur | #ImWithEnsure | 17:40 |
| markstur | Ben just walked out mad | 17:41 |
| bswartz | #feeltheretype | 17:41 |
| ganso | #makeManilaGreatAgain | 17:41 |
| bswartz | okay on that note, I think I will get lunch | 17:41 |
| markstur | I hope no one reading this thought I actually saw you stomp out. I can't see Ben. It was just awkward silence. | 17:41 |
| vponomaryov | and only tpsilva crying in the corner having -1 on his spec befor edeadline ) | 17:42 |
| tpsilva | :( | 17:42 |
| markstur | Yeah. tpsilva is saying "Lunch? You can't go to lunch!" | 17:42 |
| tpsilva | more like weekend :P | 17:43 |
| tpsilva | on a serious note? did you come to any conclusions? all I saw was "this is retype issue", but the -1 is still there | 17:44 |
| *** nkrinner is now known as nkrinner_afk | 17:44 | |
| vponomaryov | tpsivla: hack ganso's ack and change his mark ^_^ or you can threat him )) | 17:44 |
| markstur | ganso: How do we make this an Ocata feature and maybe make it better later? Do you think we're really stuck? | 17:45 |
| markstur | vponomaryov: No hacking allowed. | 17:45 |
| tpsilva | vponomaryov: just waiting for him to leave his laptop unattended | 17:45 |
| ganso | markstur: well, since it is driver interface, we can improve it later... if everybody acknowledges what the problem is and what the path of solution is (and we can get there), we can merge as-is and improve later... | 17:46 |
| ganso | we just need a way to refresh the export location | 17:46 |
| ganso | we just noticed we have the same problem for IPv6 and mountable_snapshots | 17:46 |
| markstur | ganso: Yes. If you don't' think we're "painting ourselves into a corner", then it is time to spec what we can do in O and merge | 17:46 |
| vponomaryov | especially when "retype" is out of O | 17:47 |
| ganso | vponomaryov: yes, I am about to change the vote mostly because of that fact | 17:47 |
| markstur | That and the fact that he knows he'll forget to lock his computer | 17:48 |
| markstur | ganso: Where's that retype spec. Maybe we can cram it in :) | 17:49 |
| vponomaryov | tpsilva: at least, you have a reason now to call ganso in the middle of the night and breathe into the phone | 17:49 |
| markstur | LOL | 17:49 |
| tpsilva | slow movements everyone, he's about to do it... i saw him alt-tabbing to gerrit | 17:49 |
| markstur | that's just wrong | 17:49 |
| * markstur "wrong" was re: vponomaryov's comment not re: ganso abs(-1) | 17:50 | |
| ganso | tpsilva: there you go | 17:52 |
| ganso | vponomaryov: btw that's a very creepy idea | 17:54 |
| * tpsilva is happy | 17:54 | |
| *** eharney has quit IRC | 17:56 | |
| vponomaryov | ganso: are you afraid of th dark? )) | 17:57 |
| bswartz | okay I got my sandwich and I'm not sure what happened while I was gone | 17:57 |
| markstur | Oh. Nothing. We didn't talk about you. | 17:58 |
| * ganso wonders if the Data Jobs Table spec still has any chance of merging | 18:00 | |
| markstur | ganso: I was wondering if you still wanted that in O | 18:02 |
| ganso | markstur: I am still thinking on a mechanism that would not be victim of race conditions | 18:02 |
| markstur | ganso: That is sounding like a "P" thing then. | 18:04 |
| bswartz | ganso: given everything else we're signing up for, I'm not in favor of it merging because I think we're overcommiting this short release | 18:05 |
| bswartz | ganso: that doesn't mean we can't review and merge a p-targeted spec and get a lot of the coding done during ocata | 18:05 |
| bswartz | this is a case where we need to use the specs system to express the core team's priorities and limited bandwidth | 18:06 |
| markstur | If you code it and it is the most awesome thing ever, then you could force us to implement an emergency exception process. | 18:07 |
| *** ociuhandu has quit IRC | 18:07 | |
| markstur | but it is feeling like we are overcommitting | 18:07 |
| bswartz | remember the specs process isn't about controlling what contributors work on, it's about controlling what reviewers review | 18:08 |
| bswartz | many of us are both contributors and reviewers | 18:08 |
| ganso | I am confident about not overcommitting because those 2 features (share migration improvements and data jobs table proposed) are small in amount of code and effort | 18:08 |
| *** lpetrut has quit IRC | 18:09 | |
| bswartz | ganso: you might be overlooking the testing impacts | 18:09 |
| markstur | I also think we could use less last-minute feature merges and more got-it-ready-last-release-will-merge-early-this-release features. Although I know the owner (anyone) usually doesn't like sitting on finished work. | 18:09 |
| bswartz | markstur: that's the part of the culture I'm trying to change | 18:10 |
| ganso | if I update the spec saying that we depend on tooz, and we do not have proper tooz by the FF, then I would -2 my code as I don't want a feature that suffers from race conditions | 18:10 |
| bswartz | I ran for the TC and got pretty low votes :-( | 18:10 |
| ganso | markstur: specs merged don't mean code merged | 18:11 |
| markstur | bswartz: The system is rigged. | 18:11 |
| tbarron | ganso: toabctl and I want the spec to show that we're not doinng Not Invented Here solution and there's no time to do that before the merge deadline. That doesn't mean we can't do that work with you strarting now ... | 18:12 |
| bswartz | markstur: indeed | 18:12 |
| bswartz | tbarron: that doesn't worry me at all | 18:13 |
| tbarron | bswartz: not you, but two other cores it does | 18:13 |
| ganso | tbarron: there is a paragraph stating that we are not reinventing the wheel | 18:13 |
| tbarron | ganso: stating that we're not and not are two different things | 18:13 |
| *** nherciu has quit IRC | 18:14 | |
| bswartz | markstur: should we start a #notmytc movement? | 18:14 |
| markstur | bswartz: Don't start | 18:15 |
| bswartz | lol | 18:15 |
| tbarron | ganso: so maybe i'm wrong but I just think there's more to think about before approval of a spec. doesn't mean prototype coding can't be done and as markstur says if something compellling develops then maybe it can still happen in O. | 18:16 |
| * markstur said "awesome" not "compellling" (sic) | 18:16 | |
| * tbarron misquotes markstur again | 18:17 | |
| tbarron | ganso: if i'm the only holdout, I won't block though | 18:17 |
| * tbarron runs out for lunch for an hour, coward that he is | 18:17 | |
| markstur | If working out the spec issues takes time, then it's good to keep working on that instead of landing the spec today. But it means code is unlikely to land in O | 18:18 |
| *** senk has joined #openstack-manila | 18:19 | |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs: Add spec for Data Jobs table https://review.openstack.org/392262 | 18:20 |
| *** tpatzig_ has quit IRC | 18:25 | |
| *** sapcc-bot has quit IRC | 18:25 | |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs: Add spec for Data Jobs table https://review.openstack.org/392262 | 18:25 |
| *** sapcc-bot has joined #openstack-manila | 18:25 | |
| *** tpatzig_ has joined #openstack-manila | 18:26 | |
| *** david_1 has joined #openstack-manila | 18:26 | |
| *** tpatzig_ has quit IRC | 18:27 | |
| *** david_1 has quit IRC | 18:27 | |
| ganso | bswartz: is there anything left to discuss prior to merging tpsilva's spec? | 18:29 |
| openstackgerrit | Victoria Martinez de la Cruz proposed openstack/manila-ui: Moves OPENSTACK_MANILA_SETTINGS TO local_settings.d/ https://review.openstack.org/397926 | 18:29 |
| bswartz | ganso: my +2 got clobbered by the last patch | 18:30 |
| bswartz | I was going to wait until discussion settled down before looking at the diff | 18:30 |
| bswartz | looking now | 18:30 |
| bswartz | btw I suspect several specs that are merging at not updating the appropriate index files -- I don't want to block any specs on that issue but someone will need to go clean up the indices in the specs repo | 18:31 |
| bswartz | I'm not sure if we'll get votes from cknight or gouthamr -- AFAIK they're both on airplanes or sleeping in weird timezones | 18:32 |
| tpsilva | gouthamr already +2'ed a patch ago | 18:33 |
| bswartz | xyang did too | 18:33 |
| *** tpatzig_ has joined #openstack-manila | 18:34 | |
| bswartz | I'll workflow now | 18:35 |
| bswartz | https://review.openstack.org/#/c/395775/ | 18:37 |
| bswartz | ^ this going anywhere? | 18:37 |
| ganso | bswartz: seems like not before the deadline, mliima is still researching what needs to be done so it can be included in the spec | 18:38 |
| openstackgerrit | Merged openstack/manila-specs: Add spec for mountable snapshots https://review.openstack.org/321213 | 18:38 |
| bswartz | I'm glad we focused on specs so well the last 2 weeks | 18:40 |
| bswartz | it gives me a good feeling about the next 10 weeks | 18:40 |
| bswartz | maybe there will be fewer surprises | 18:40 |
| openstackgerrit | Merged openstack/manila-specs: Add spec for Manila share groups https://review.openstack.org/315730 | 18:40 |
| openstackgerrit | Merged openstack/manila-specs: Add Stochastic Weighing Scheduler https://review.openstack.org/395777 | 18:40 |
| openstackgerrit | Merged openstack/manila-specs: Add share_type filter support to pool_list https://review.openstack.org/390034 | 18:41 |
| *** eharney has joined #openstack-manila | 18:53 | |
| *** lpetrut has joined #openstack-manila | 18:56 | |
| mliima | what is deadline? bswartz ganso | 18:58 |
| bswartz | mliima: today | 18:59 |
| mliima | well, I missed this deadline. :/ | 19:03 |
| bswartz | mliima: it's a short cycle -- we'll be working on pike very soon | 19:03 |
| mliima | bswartz, regarding the next deadline | 19:05 |
| mliima | we have any definition? | 19:05 |
| bswartz | mliima: definition of what? | 19:06 |
| bswartz | you mean future deadlines for specs? | 19:06 |
| mliima | yes | 19:06 |
| bswartz | it's the milestone-1 date according to current policies | 19:06 |
| bswartz | for ocata we granted a 1-day blanket extension because things were not in good shape yesterday | 19:06 |
| mliima | oh, ok bswartz | 19:08 |
| *** senk has quit IRC | 19:09 | |
| *** mliima has quit IRC | 19:23 | |
| *** dsariel has joined #openstack-manila | 19:24 | |
| *** nherciu has joined #openstack-manila | 19:26 | |
| vkmc | hey all, https://review.openstack.org/#/c/388859/ I'd appreciate a few more eyes on this patch set | 19:31 |
| *** nherciu has quit IRC | 19:38 | |
| vkmc | bswartz, ganso ^ | 19:40 |
| *** nherciu has joined #openstack-manila | 19:41 | |
| vkmc | tbarron, if you are around as well ^ | 19:42 |
| bswartz | vkmc: I talked to vponomaryov about this earlier in the week | 19:42 |
| bswartz | I think his argument was that an experimental job will tell us if there are any gate-affecting bugs in this change, and if there are, then we can fix them in the same change | 19:42 |
| bswartz | your suggestion is to test it after it merges and bugfix anything that breaks | 19:43 |
| bswartz | I think vponomaryov's approach is safer | 19:43 |
| bswartz | I hope he volunteered to help get that job created -- knowledge of creating new jobs is something that not enough people have | 19:44 |
| vkmc | not really, my approach is to add it because it's not a breaking change | 19:46 |
| bswartz | vkmc: but we have no way to test the new code | 19:47 |
| bswartz | other than manually | 19:47 |
| vkmc | right | 19:47 |
| vkmc | Manila UI as is has a DevStack plugin that doesn't work | 19:47 |
| vkmc | that was not tested | 19:48 |
| *** alyson_ has quit IRC | 19:48 | |
| vkmc | this patch set fixes that | 19:48 |
| tbarron | bswartz: i'm confused, we've been doing all kinds of ui changes till now without this job, what makes this patch0-set special? | 19:48 |
| vkmc | the only thing we can test on that patch if it actually enabled or not Manila UI | 19:48 |
| tbarron | bswartz: i'll commit my team's resources to working on that experimental job | 19:48 |
| *** porrua has quit IRC | 19:48 | |
| bswartz | tbarron: manila-ui currently has NO dsvm jobs at all | 19:48 |
| tbarron | bswartz: yes, and we've been meerging manila-ui bug fixes all along, so why this change set has the particular burden before it can merge | 19:49 |
| bswartz | all of the testing of the devstack plugin happen in the manila project | 19:49 |
| bswartz | after this change, it will become possible to check in a breaking change to manila-ui's devstack plugin and for it not to be caught | 19:50 |
| bswartz | today it would be caught, because it would go into the manila project, where we do have a dsvm job | 19:50 |
| bswartz | I'm only trying to explain vponomaryov's logic since he's not here | 19:51 |
| vkmc | now... something I'm not entirely sure about | 19:51 |
| vkmc | how are we planning to add the non-voting gate if the code is not merged? | 19:51 |
| bswartz | vkmc: it would go like this | 19:51 |
| bswartz | 1) submit experimental job to project-config | 19:52 |
| bswartz | 2) update manila-ui change to depend on (1) | 19:52 |
| vkmc | ... | 19:52 |
| vkmc | ok | 19:52 |
| vkmc | thanks | 19:53 |
| bswartz | 3) run experimental job before (2) merges | 19:53 |
| bswartz | workflow (1) and (2) | 19:53 |
| bswartz | 4) change experimental job to nonvoting check job | 19:53 |
| bswartz | 5) change job to gate job | 19:53 |
| bswartz | vponomaryov: could probably explain the details better | 19:54 |
| bswartz | I've created new jobs before so I can help | 19:54 |
| vkmc | all right | 19:55 |
| bswartz | I think having a dsvm job running for manila-ui will be a positive thing | 19:55 |
| vkmc | of course | 19:55 |
| bswartz | it will slow down merge times, but catch more issues | 19:55 |
| vkmc | will work on that | 19:55 |
| tbarron | vkmc: i'll learn how to do it along with you | 19:56 |
| tbarron | bswartz: thanks for volunteering yourself and valeriy as tutors :) | 19:56 |
| vkmc | I want to see the DevStack plugin working, that's my main concern | 19:57 |
| vkmc | I have been trying to contribute to Manila UI when I just started and the whole process if painful | 19:57 |
| bswartz | tbarron: just trying to spread the knowledge | 19:58 |
| *** jcsp has quit IRC | 20:09 | |
| *** dsariel has quit IRC | 20:16 | |
| *** porrua has joined #openstack-manila | 20:21 | |
| *** timcl1 has joined #openstack-manila | 20:30 | |
| *** timcl1 has left #openstack-manila | 20:31 | |
| *** timcl has quit IRC | 20:33 | |
| *** xyang1 has joined #openstack-manila | 20:33 | |
| *** akapil has joined #openstack-manila | 20:50 | |
| *** xyang_ has joined #openstack-manila | 20:52 | |
| *** chlong has quit IRC | 20:53 | |
| *** akapil has quit IRC | 20:54 | |
| *** lpetrut has quit IRC | 21:08 | |
| *** lpetrut has joined #openstack-manila | 21:17 | |
| *** ChanServ changes topic to "OpenStack Shared File Systems | Manila" | 21:21 | |
| *** catintheroof has joined #openstack-manila | 21:31 | |
| *** xyang_ has quit IRC | 21:34 | |
| *** tpsilva has quit IRC | 21:35 | |
| *** xyang_ has joined #openstack-manila | 21:36 | |
| *** lpetrut has quit IRC | 21:39 | |
| *** xyang_ has quit IRC | 21:40 | |
| *** xyang_ has joined #openstack-manila | 21:45 | |
| *** xyang_ has quit IRC | 21:49 | |
| *** xyang_ has joined #openstack-manila | 21:58 | |
| *** xyang_ has quit IRC | 22:00 | |
| *** ganso has quit IRC | 22:06 | |
| *** xyang_ has joined #openstack-manila | 22:06 | |
| *** xyang_ has quit IRC | 22:09 | |
| *** xyang_ has joined #openstack-manila | 22:12 | |
| *** xyang_ has quit IRC | 22:17 | |
| *** xyang_ has joined #openstack-manila | 22:36 | |
| *** xyang_ has quit IRC | 22:36 | |
| *** xyang1 has quit IRC | 23:01 | |
| *** erlon-airlong has quit IRC | 23:22 | |
| *** eharney has quit IRC | 23:49 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!