Thursday, 2018-12-20

tbarronbswartz: xyang: gouthamr: I'm going to put a slot on tomorrow's meeting for "report from kubecon" - it's an opportunity for you folks to share your01:24
tbarronthoughts about where cloud storage is going.  Is manila still relevant?  What should we be paying attention to?  etc. etc.01:24
openstackgerritTom Barron proposed openstack/manila master: DNM - testing ganesha log collection  https://review.openstack.org/62622001:45
openstackgerritDingDong proposed openstack/manila master: Manila Unity/VNX] add 'snapshot support' related Doc for Unity/VNX driver  https://review.openstack.org/62611102:13
openstackgerritGoutham Pacha Ravi proposed openstack/manila master: DNM - testing ganesha log collection  https://review.openstack.org/62622002:34
openstackgerritzhongshengping proposed openstack/puppet-manila master: DNM test lint  https://review.openstack.org/62647303:27
openstackgerritMerged openstack/manila master: Fix image_name retrieval in custom-image jobs  https://review.openstack.org/62355104:20
*** pcaruana has joined #openstack-manila07:25
openstackgerritGoutham Pacha Ravi proposed openstack/manila master: Deprecate old keystone session config opts  https://review.openstack.org/62650607:52
openstackgerritGoutham Pacha Ravi proposed openstack/manila master: Deprecate old keystone session config opts  https://review.openstack.org/62650607:55
*** luizbag has joined #openstack-manila09:31
openstackgerritDingDong proposed openstack/manila master: [Manila Unity/VNX] add 'snapshot support' related Doc for Unity/VNX driver  https://review.openstack.org/62611109:39
*** e0ne has joined #openstack-manila09:53
*** ganso has joined #openstack-manila10:08
*** e0ne has quit IRC10:29
*** e0ne has joined #openstack-manila10:30
*** arne_wiebalck has quit IRC10:58
*** arne_wiebalck has joined #openstack-manila10:59
openstackgerritMerged openstack/manila master: Only run the needed services for CephFS jobs  https://review.openstack.org/62602111:52
*** erlon_ has joined #openstack-manila11:54
*** luizbag has quit IRC12:29
*** luizbag has joined #openstack-manila12:30
openstackgerritTom Barron proposed openstack/manila master: DNM - testing ganesha log collection  https://review.openstack.org/62622012:53
openstackgerritTom Barron proposed openstack/manila master: speed up GET scheduler-stats/pools/detail  https://review.openstack.org/61957613:00
*** e0ne has quit IRC13:19
openstackgerritTom Barron proposed openstack/manila stable/rocky: Only run the needed services for CephFS jobs  https://review.openstack.org/62657613:32
*** e0ne has joined #openstack-manila13:33
*** e0ne has quit IRC14:11
*** e0ne_ has joined #openstack-manila14:11
*** baojg has quit IRC14:15
*** baojg has joined #openstack-manila14:16
*** a-pugachev has joined #openstack-manila14:16
*** a-pugachev has quit IRC14:23
*** mmethot has quit IRC14:27
*** mmethot has joined #openstack-manila14:29
openstackgerritTom Barron proposed openstack/manila master: DNM - testing ganesha log collection  https://review.openstack.org/62622014:46
*** tpsilva has joined #openstack-manila15:26
tbarrongouthamr: yes, we should do a bug triage, do you have a time in mind?16:00
gouthamrxyang bswartz ganso: https://review.openstack.org/#/c/609598/ needs your re-reviews16:00
gouthamrtbarron: so last time, we spent a lot of time triaging bugs on the manila bug squash day, maybe we need bug triage day/s?16:01
tbarrongouthamr: fine idea, maybe we should target one for the second week of January?16:02
tbarrongouthamr: lots of people are out next week and will be recovering the week after that16:03
gouthamryep, works for me16:03
amitoI thought we had a midcycle on the 16-17?16:03
amitowe plan to have*16:03
gouthamrwe do? :P16:03
amitoIt's in my calendar :)16:04
tbarronyep16:04
tbarronso we could do it as part of mid-cycle or separately16:04
tbarronmid-cycle might be a good target for a new design for service vm connectivity16:05
tbarronganso: bswartz: why don't we already have security issues when we stitch an svm into the integration bridge on the node where manila-share runs?  probably I'm missing something.16:07
bswartztbarron: The thing we worry about is the tenant breaking into the service VM16:12
bswartzIf they manage that, then how much damage can they cause?16:12
tbarronbswartz: and what i'm missing is what we have today that keeps the tenant from breaking into the service VM16:12
bswartzWith the integration bridge approach, they can attack only m-shr and things that coexist with m-shr16:12
bswartzWith a dual-NIC approach, they could attack anything on the other end of that other NIC16:13
tbarronbswartz: even if the SVM is on the tenant net it can have security rules that allow only access to port 2049 on the SVM16:13
bswartztbarron: that's an exercise left to the deployer16:13
bswartzWe've never invested much in hardening the service VM16:14
tbarronbswartz: we can always set up the SVM that way16:14
bswartzIn theory it could be quite secure, but since nobody spends time on that, it would be difficult to trust it16:14
tbarronand today they can still send packets to the SVM so it seems there is the same issue16:14
bswartzIt's a question of security in layers16:15
bswartzThe layer between the tenant and the service VM has always been iffy, but there are ways to make it more secure16:16
tbarronwell my main interest actually is in getting a reference driver in gate to work reliably16:16
bswartzI'm talking about the layer of security behind the service VM -- the layer you would rely on after someone compromised the service VM somehow16:16
tbarronif I were to actually try to deploy generic driver in producation I'd use isolated networks, etc.16:16
tbarronwhich we don't have in devstack16:16
bswartzYeah I know -- I'm not opposed to using a less secure approach if it solves our problems16:16
bswartzWe would just need to document the tradeoffs and try to get people to working on addressing all the new vulnerabilities16:17
tbarronbswartz: +116:17
bswartzEarlier I was just explaining why it hasn't been tried before and why it wasn't the default initially16:17
tbarronyup16:18
gansotbarron: don't you face similar problems with ganesha?16:27
tbarronganso: we run ganesha to tenant on an isolated network with only port 2049 open16:28
tbarronganesha to manila-share is on an isolated internal api network16:28
tbarronganso: and we're looking to scale out ganeshas per tenant and connect their nfs interfaces directly onto the tenant net, with again only 2049 open16:29
tbarronganso: these won't be service vms but yes the issues are similar16:30
tbarronganso: they'll be processes in containers so it would be more like a client trying to do 'docker|podman exec <container>' than ssh into vm16:32
gansotbarron: hmmm16:33
bswartztbarron: does nova support vsock yet?16:35
tbarronbswartz: the libvirt part of vsock is there, dunno if nova knows about it yet, but16:36
bswartztbarron: that's the place we want to get to eventually16:37
tbarronthe hitch on vsock is NFS-over-vsock, which isn't16:37
tbarronmaking IETF progress16:37
bswartztbarron: no I'm thinking of SSH-over-vsock16:37
bswartzIf we can talk to the service VMs over vsock then they need no second NIC, no horrible back doors16:38
tbarronbswartz: I see16:38
tbarronbswartz: you need to run the SVM on the same node as the tenant VM though don't you?16:38
bswartztbarron: nope, not at all16:38
tbarronad tenant VMs for the same tenant could be spread over multiple nodes16:39
bswartzIf I had a whiteboard I'd draw it out16:39
tbarronso it's manila-share doing the ssh to the SVM16:39
tbarronif over vsock it will be to a CID or whatever on the node manila-share is on16:40
bswartzYeah that's my thinking16:40
bswartzThat or something like that16:40
tbarronso SVMs would be bound to the node manila-share runs on16:40
bswartzAnything to close off the network path on the backend side of the service VM16:40
bswartzNo no16:40
bswartzM-shr can reach out and talk to any nova node because it's an openstack service16:41
bswartzNova just needs to provide a way to access this hypothetical service16:41
bswartztbarron: you could prototype with something like this: https://gist.github.com/mcastelino/9a57d00ccf245b98de2129f0efe3985716:50
*** erlon_ has quit IRC16:55
*** erlon has joined #openstack-manila16:55
*** e0ne_ has quit IRC16:59
*** gouthamr has quit IRC17:31
*** gouthamr has joined #openstack-manila17:40
*** luizbag has quit IRC17:57
*** luizbag has joined #openstack-manila17:58
tbarronbswartz: will look, meetings ...18:12
*** luizbag has quit IRC18:13
*** luizbag has joined #openstack-manila18:13
*** ianychoi has quit IRC18:22
*** luizbag has quit IRC18:25
*** gouthamr_ has joined #openstack-manila18:37
*** gouthamr has quit IRC18:37
*** e0ne has joined #openstack-manila18:49
*** e0ne_ has joined #openstack-manila19:25
*** e0ne has quit IRC19:25
bswartztbarron: the basic idea works fine19:57
bswartzThe big thing that's missing is nova code to add vsock support and expose tunnels19:57
*** pcaruana has quit IRC19:57
bswartzProbably the nova folks will never be motivated to do that work19:57
bswartzBut the basic kernel, userspace, qemu/kvm, and libvirt bits are all in place19:58
bswartzThe missing piece is just something in nova, and support inside the guest VM for listening on a vsock (but that part is trivial to do with a socat proxy like the one on that gist)19:59
*** erlon has quit IRC20:05
*** gouthamr_ is now known as gouthamr20:13
*** e0ne_ has quit IRC21:21
gouthamrtbarron21:55
gouthamrtbarron: ping21:55
gouthamrre: config file generatio21:56
tbarrongouthamr: pong21:56
gouthamrn*21:56
tbarrongouthamr: yup, we're broken21:56
gouthamrtbarron: hey Tom, do you really want me to hand-change the stuff with my patch? i ought to fix it for teh last few releases, no? :)21:56
tbarrongouthamr: just your little piece of the world21:56
tbarrongouthamr: we fix one thing at a time21:57
tbarrongouthamr: if you want to fix config file generation, sure, fine, but not as a part of *this* patch21:57
gouthamrtbarron: okay... i remember we took an AI from the PTG based on sfinucan's work21:57
tbarronjust what you touch21:57
tbarrongouthamr: we have many AIs and that one isn't our highest prio21:57
gouthamrtbarron: ack, works for me.. i'll just toggle those couple of opts21:58
tbarrongouthamr: right, I know it feels bad not to fix the *real* issue but it's a different real issue than what your patch addresses21:58
gouthamrtbarron: true, but customers and downstream folks were looking at those files as source of truth for a bug and that got me nervous... i thought people just ran `tox -egenconfig` to get those deets21:59
tbarrongouthamr: we have to keep scope creep in control or we start putting spackling on a wall and pretty soon we're looking at bare studs and all the plaster is gone21:59
gouthamrtbarron: you're the boss :D21:59
tbarrongouthamr: it doesn't and that's broken for a lot of projects21:59
tbarrongouthamr: maybe nova has fixed it since sfinacun works there22:00
tbarronI'm not in any way discouraging fixing, i'm decoupling that fix from your *current* patch22:00
gouthamryep, probably.. that and the config file changes from release to release22:00
gouthamrack, thank you for clarifying.. we must still have a bug, maybe we can find a volunteer22:01
* gouthamr looks for bug22:01
gouthamrtbarron: this one: https://bugs.launchpad.net/manila/+bug/171306222:01
openstackLaunchpad bug 1713062 in Manila "Missing ability to automatically build configuration reference artifacts" [High,Triaged]22:01
tbarrongouthamr: yup22:01
gouthamrsheesh, pike :(22:02
tbarrongouthamr: feel free to argue that it should be higher in our backlog and take it to our next meeting, right now we don't have someone to work on it22:03
gouthamrtbarron: ack, will add it to the etherpad cc: jgrosso22:04
gouthamrwho ain't here, but will let him know22:04
openstackgerritGoutham Pacha Ravi proposed openstack/manila master: Deprecate old keystone session config opts  https://review.openstack.org/62650622:15
gouthamrtbarron: i had to delete those lines because the opts that i "added" were already there ^22:16
tbarrongouthamr: yup22:19
tbarrongouthamr: if that works, cool22:20
gouthamrtbarron: actually, on a deeper thought - i would like to backport that fix so it lines up with puppet changes that vkmc's making22:23
gouthamrtbarron: these options were already shadowing other options since a long time, so is it okay to backport this deprecation?22:25
gouthamrthe problem arises because of api_insecure which has a default value :(22:26
tbarronyes22:26
gouthamrand it overrides whatever people provide with "insecure"22:26
tbarrongouthamr: ^^22:26
tbarrongouthamr: we need to make things work even in stable branches so don't get hung up about chasnging config options that don't work22:27
tbarrongouthamr: need appropriate release notes of course, 'splainin22:28
gouthamrtbarron: okay, i'll clarify further22:29
*** ganso has quit IRC22:51
openstackgerritGoutham Pacha Ravi proposed openstack/manila master: Deprecate old keystone session config opts  https://review.openstack.org/62650623:04
openstackgerritGoutham Pacha Ravi proposed openstack/manila master: Deprecate old keystone session config opts  https://review.openstack.org/62650623:11
*** tpsilva has quit IRC23:16

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