15:00:39 <bswartz> #startmeeting manila
15:00:40 <openstack> Meeting started Thu Sep  8 15:00:39 2016 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:43 <openstack> The meeting name has been set to 'manila'
15:00:44 <bswartz> hello all
15:00:45 <cknight> Hi
15:00:47 <gouthamr_> hello o/
15:00:47 <aovchinnikov> hi
15:00:48 <dgonzalez> hi
15:00:48 <ganso> hello
15:00:49 <tovchinnikova> \\//
15:00:53 <vponomaryov> Hello
15:00:55 <xyang1> hi
15:01:01 <tbarron> hi
15:01:24 <zhongjun_> hello
15:01:27 <rraja> hi
15:01:27 <jseiler_> hi
15:01:42 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:58 <bswartz> #topic RC1 status
15:02:50 <bswartz> so we're driving towards RC1
15:02:59 <bswartz> the target date for that is just 1 week away
15:03:06 <bswartz> #link https://launchpad.net/manila/+milestone/newton-rc1
15:03:19 <markstur> hi
15:03:38 <bswartz> the goal is to fix a the targeted bugs and the tag/branch
15:04:01 <bswartz> if anyone knows about bugs that need fixing, please make sure they're targetted, ideally by today
15:04:27 <vponomaryov> bswartz: actually we have lots of bugs with proposed fixes but not targeted
15:04:33 <bswartz> we're not going to allow targeting of new bugs to the RC unless they're critical after today
15:04:53 <bswartz> vponomaryov: let's get them targeted
15:05:12 <bswartz> my criteria for tagging RC1 will be when that list on LP has zero open bugs
15:06:22 <bswartz> #topic Project Logo
15:06:29 <bswartz> #link http://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_6f0d111cec78c5ef&akey=d34a751f2d084d79
15:06:42 <bswartz> For those who haven't voted on the new logo, there is the link
15:07:07 <bswartz> I'm using CIVS this time around because it allows us to determine a #2 and #3 winner in case the new winner is disqualified like the last one was
15:07:27 <bswartz> the poll closes tomorrow at noon UTC
15:08:07 <bswartz> #topic Container Driver Security
15:08:11 <ganso> is it working for everybody? I got a blank page after I voted
15:08:19 * bswartz goes to look for link
15:08:38 <aovchinnikov> so, there is a bug in the container driver
15:08:38 <bswartz> #link https://review.openstack.org/#/c/353463/
15:08:51 <aovchinnikov> #link https://bugs.launchpad.net/manila/+bug/1613675
15:08:51 <openstack> Launchpad bug 1613675 in Manila "Container driver does not actually mount logical volumes" [High,In progress] - Assigned to Alexey Ovchinnikov (aovchinnikov)
15:08:59 <aovchinnikov> and that's the bug
15:09:25 <aovchinnikov> the proposed solution has attracted some criticism
15:09:32 <bswartz> there were some questions about the security implications of running containers in privileged mode
15:09:36 <aovchinnikov> I've heard concerns from several community members about security aspects of this approach
15:10:33 <bswartz> My opinion on this is that: we're not using containers for any kind of security enforcement, we're using them for network namespace separation, and therefore whether the container is privileged or not doesn't matter
15:10:34 <aovchinnikov> yes, also the way /dev is proposed to be handled by containers looks dangerous
15:10:46 <bswartz> nothing the container driver does is more dangerous than what the LVM driver does
15:11:06 <aovchinnikov> I'd like to stress it that the only point of using containers in this driver is to avoid direct network namespaces manipulations
15:11:35 <aovchinnikov> that is the sole purpose of containers here
15:11:57 <aovchinnikov> so probably we should not worry too much about possible security risks here
15:12:19 <aovchinnikov> as bswartz has mentioned it is not less secure than LVM driver
15:12:40 <tbarron> do we explicitly address the question of
15:12:44 <bswartz> ganso dgonzalez: does that make sense to you?
15:13:13 <tbarron> whether container and lvm drivers should be used in non POC and non-gate-testing environments?
15:13:14 <ganso> bswartz: yes, if the vulnerability is present in other drivers as well, seems there is nothing much we can do
15:13:21 <dgonzalez> bswartz: it makes sense, but if there is a way to avoid mount /dev i would prefer it...
15:13:26 <aovchinnikov> also suggestions and alternative opinions are welcome
15:13:45 <ganso> dgonzalez: +1
15:13:49 <bswartz> dgonzalez: from what I know about docker, I'm fairly certain it's not -- docker doesn't support dynamically adding storage to running containers
15:14:27 <dgonzalez> Is it possible to stop the container and then start it with a new volume?
15:14:29 <bswartz> basically we treat every container the same as we treat the host
15:14:37 <aovchinnikov> dgonzalez, ganso: it is definitely not the best thing to do, but it seems to be the only way to do it
15:14:46 <bswartz> dgonzalez: that would be supremely disruptive to clients
15:14:52 <aovchinnikov> dgonzalez: what if someone is doing heavy io right at the moment?
15:15:42 <dgonzalez> aovchinnikov: right, that would be bad :D
15:16:19 <aovchinnikov> dgonzalez: that is a very mild way to describe it:)
15:16:38 <aovchinnikov> so apparently we have to mount the entire /dev to each container for now
15:16:45 <bswartz> personally I don't believe we even need docker's mount namespace separation -- we're only interested in the network, uts, and user namespaces being separate
15:17:16 <aovchinnikov> that should nt be a problem as long as there are no exploitable bits in smbd
15:17:17 <bswartz> however we're chose docker because it's well understood and widely supported, rather than cooking up our own container-thingy
15:17:48 <aovchinnikov> and we won't need to support our own solution
15:17:52 <dgonzalez> Seems like attaching a new volume to a running contaienr is possible via the API: https://github.com/docker/docker/issues/10975
15:17:57 <bswartz> and to add to what aovchinnikov said, if there are security holes in smbd, then they affect lvm driver too
15:18:00 <dgonzalez> But i am not sure if this helps us :P
15:18:22 <tbarron> is that a good argument?
15:18:30 <aovchinnikov> dgonzalez: afaik it is not that simple
15:18:32 <bswartz> dgonzalez: I've seen that page -- it container inaccurate information
15:18:43 <bswartz> s/container/contains/
15:19:18 <tbarron> i go back to the question of the scope and purpose of container and lvm drivers
15:19:39 <bswartz> dgonzalez: however if you can find a way to correctly plug new filesystems into a running docker container, then we would enthusiastically accept such a patch
15:20:09 <ganso> tbarron: I wonder the same
15:20:29 <ganso> we should consider the driver being used in production
15:20:43 <aovchinnikov> tbarron: POC, gate and dev environments now, production at some point later
15:20:43 <bswartz> tbarron: container driver support share servers in the most efficient way we can do with open source
15:21:05 <bswartz> IMO the design of the driver is fits production use cases well
15:21:16 <tbarron> security concerns about real tenants escaping their walls in production may be very different than if they are not meant for production and that is explicitly stated
15:21:21 <bswartz> the main thing preventing container driver from running in production is the severe limitations of nfs-ganesha
15:22:00 <tbarron> ok, then we should ask that containers provide as good walls around tenants as do vm instnaces, right?
15:22:06 <markstur> tbarron, We need to be very careful of supporting a driver for PoC/Test only because once they get out in the wild they end up in production.
15:22:27 <bswartz> tbarron: I'll try to make this pefectly clear -- the containers we create are NOT ACCESSIBLE to tenants -- they are merely for our own convenience to put samba into a tenant's network
15:22:44 <bswartz> (and nfs-ganesha in the future)
15:23:26 <bswartz> similar issues exist with q-dhcp and q-l3 -- those run in containers with no mount namespace protection
15:23:42 <bswartz> however nobody worries about this because those containers aren't accessible to tenants
15:24:46 <dgonzalez> bswartz: but when the container is attchaed to a tenant network, couldn't somebody gain access to it through security holes in samba?
15:24:52 <tbarron> yeah, i'm not arguing that the container driver is *not* secure enough, i'm just seeking clarity and what criteria are appropriate
15:25:21 <aovchinnikov> dgonzalez: in theory he can do that
15:25:26 <bswartz> dgonzalez: yes! and the same is true for generic driver and lvm driver and zfs driver, and if ther are security holes in dnsmasq then the same is true for q-dhcp, etc
15:26:05 <bswartz> what I'm trying to argue is that what we're doing with container driver is no worse than what we do everywhere else
15:26:13 <aovchinnikov> well, it will hurt less in the case of the generic driver
15:26:19 <aovchinnikov> a little less
15:26:41 <bswartz> aovchinnikov: that's not true -- if you get into the service VM you have network access to the backend resources and you can do terrible things
15:27:18 <aovchinnikov> yes, sure, but at least you are not seeing other's data immediately
15:27:33 <dgonzalez> bswartz: but if you have access to a container which can tamper with /dev from the host, you can mess with stuff that belongs to other containers and therefore other tenants
15:27:56 <bswartz> dgonzalez: the same is true of every first party driver
15:28:01 <aovchinnikov> it is a couple of commands away. I guess this could be considered as little.
15:28:43 <aovchinnikov> dgonzalez: when you have access to a generic driver's  VM you still have a chance to mess with other's data
15:28:46 <bswartz> if you can exploit the server then you can gain access to other tenant's data with all of our first party drivers
15:29:15 <bswartz> we rely on samba and nfsd being secure as part of our security for manila
15:29:23 <bswartz> if they're not secure, we have much bigger problems
15:29:34 <dgonzalez> bswartz: ok, I didn't know that
15:30:16 <bswartz> with the generic driver we have a better chance to isolate tenants from attacks
15:30:46 <bswartz> with container/lvm/zfs it's really impossible to get secure separation if the client is able to hack samba/nfsd
15:30:58 <bswartz> okay we have several more agenda items so I'd like to move on
15:31:15 <dgonzalez> to get back on topic: I'm fine with mounting /dev in containers if there is no other way to do it. But i think we should warn users that there is no real isolation between teh data of different tenants
15:31:21 <dgonzalez> bswartz: +1
15:31:28 <bswartz> dgonzalez: that makes sense
15:31:56 <bswartz> we should ensure that admins are aware that the container driver doesn't offer any additional security compared to lvm/zfs
15:32:08 <bswartz> it's main value is support of share servers
15:32:30 <bswartz> #topic  Security "vulnerability-managed" tag for manila
15:32:33 <bswartz> tbarron: you're up
15:32:54 <tbarron> I asked and yes, it is is important for us that all projecs that we ship as more than just "tech preview" have the managed vulnerability tag.
15:32:54 <tbarron> It's understood that the burden for getting the tag for newer projects is heavier than for established projects to keep it, but
15:32:54 <tbarron> we're expected to advocate for projects in which particpate to pursue the tag, and to work to make this feasi
15:33:05 <tbarron> feasible
15:33:39 <bswartz> tbarron: I abandoned the governance change related to this
15:33:50 <tbarron> bswartz: yes, you did
15:34:08 <bswartz> it's not clear to me how we get an independent security review of the project without someone volunteering to spend money
15:34:38 <tbarron> bswartz: I don't think that kind of external security audit was being requested
15:34:51 * bswartz goes to look for link
15:34:59 <vkmc> shouldn't the security audit be performed by the security council in OpenStack?
15:35:12 <tbarron> vkmc: It's not an "audit"
15:35:25 <tbarron> and prjects are OpenStack
15:35:33 <bswartz> #link http://governance.openstack.org/reference/tags/vulnerability_managed.html#requirements
15:35:45 <tbarron> we have to contribute and be a part of openstack, not run independently
15:36:05 <bswartz> Oh i wonder if the wording changed here
15:36:17 <vkmc> tbarron++
15:36:26 <bswartz> the wording is "The deliverable?s repos should undergo a review, audit, or threat analysis looking for obvious signs of insecure design or risky implementation which could imply a large number of future vulnerability reports. The review, audit, or threat analysis may be done by the project team itself or an impartial third party. In the event the project team involved in the tagging peforms the review, audit, or threat analysis, the results
15:36:46 <tbarron> right, talking to fungi, the important thing was to "get started" on this
15:37:16 <tbarron> ihere is the current template :)
15:37:17 <bswartz> I'm not sure who normally undertakes these kind of reviews
15:37:23 <tbarron> https://git.openstack.org/cgit/openstack/security-analysis/tree/doc/source/templates/
15:37:35 <tbarron> manila would be a pioneer, set precedent
15:37:48 <fungi> and would be an awesome precedent to set
15:38:00 <bswartz> still, we need volunteers to do this work
15:38:08 <tbarron> i volunteer
15:38:17 <gouthamr_> i can help
15:38:19 <fungi> i recommend popping into the security team's weekly meeting too and expressing your interest in being an early adopter of that process they've been designing
15:38:19 <bswartz> tbarron: awesome! thank you
15:38:43 <bswartz> tbarron: since you're on the project team, who could perform the third party validation of your work?
15:39:07 <tbarron> fungi: ??  ^^
15:39:47 <tbarron> the text says:
15:39:54 <bswartz> well that's not something we need to address today
15:40:02 <bswartz> as long as we have a volunteer we can get started
15:40:11 <bswartz> and find a third party to validate results in parallel
15:40:23 <tbarron> I'm guessing projects may validate other projects for third party signoff
15:40:56 <tbarron> but if the manila community is OK with it I can get the ball rolling and we'll see where it goes
15:41:06 <bswartz> tbarron: so at what point should I restore my governance change?
15:41:17 <bswartz> is your understanding that we can request that tag before the review is complete?
15:41:42 <tbarron> how about I go to the security meeting that fungi pointed to and report back
15:41:51 <bswartz> okay
15:41:56 <bswartz> anything else on this topic?
15:41:59 <tbarron> and anyone else interested from manila too of course
15:42:10 <bswartz> gouthamr: ^
15:42:14 <fungi> yeah, the vmt is really fairly autonomous and not deeply involved with the security team. we're mostly separate groups except from a governance standpoint
15:42:34 <fungi> i in fact usually don't have time to lurk the security team meeting and only pop in when summoned
15:42:54 <bswartz> #topic Zanata translations for manila-client and manila-ui
15:43:04 <bswartz> tbarron: this is you again
15:43:16 <tbarron> i meant to say for manila and manila client
15:43:22 <tbarron> we have them for manila ui
15:43:25 <bswartz> o_O
15:43:39 <tbarron> any objection to adding them to the main components too?
15:43:41 <bswartz> #undo
15:43:42 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x7f23bda21fd0>
15:43:44 <bswartz> #topic Zanata translations for manila and python-manilaclient
15:44:07 <tbarron> bswartz: ty
15:44:29 <bswartz> I don't see why we wouldn't want this
15:44:29 <gouthamr> no objections, translations are probably of great help to greater adoption
15:44:39 <gouthamr> but i want to clarify why we'd stop backports
15:44:39 <tbarron> and if not, then waht is the correct interpretation of https://wiki.openstack.org/wiki/Translations#String_Freeze w.r.t timing
15:44:42 <bswartz> what issues exist with zanata?
15:44:53 <gouthamr> ah, my question too :)
15:45:15 <tbarron> i think we can add zanata, we just can't add new strings :)
15:45:16 <bswartz> yes, string freeze has been a confusing topic for people
15:45:31 <tbarron> or do we have to wait till Ocata to turn on zanata
15:45:33 <tbarron> ?
15:45:39 <bswartz> when I -1 stuff for string freeze violations people always point out that we don't have any translations
15:45:57 <bswartz> my response is that we need to follow the rules if we want to have translations
15:46:03 <bswartz> but perhaps I'm wrong?
15:46:04 <tbarron> +1
15:46:07 <gouthamr> https://review.openstack.org/#/c/337065/ is a pretty important bugfix for our customer; and it happens to introduce a translated string.. i wasn't able to find any place where it says this is forbidden?
15:46:41 <tbarron> i think there's email, prob. from dhellman
15:47:07 <tbarron> about string freeze itself
15:47:11 <bswartz> gouthamr: http://docs.openstack.org/project-team-guide/release-management.html
15:47:13 <xyang1> new string is ok
15:47:28 <bswartz> xyang1: new strings are okay up until hard string freeze
15:47:48 <bswartz> stable releases are permanently in hard string freeze AIUI
15:48:24 <tbarron> so this is good to talk about but wasn't actually what i was asking, i will wait to pop stack though
15:49:05 <gouthamr> so when we have the translation catalogs in our project, we could include the translations in the backport itself..
15:49:10 <bswartz> if we didn't enforce hard string freeze on stable stuff, then translators would have to watch all the stable branches all the time, which doesn't scale well
15:49:35 <bswartz> gouthamr: that sounds like a suggestion for the release mgmt team
15:49:47 <gouthamr> i actually found that wording somewhere else
15:49:54 <bswartz> we're not going to make up our own rules for backports
15:49:56 * gouthamr looks for a link
15:50:30 <gouthamr> sure.. but respectfully, i have been able to backport stuff in other projects :) i dunno if this is a new restriction
15:50:58 <bswartz> gouthamr: probably stable-maint reviewers not enforcing rules correctly -- you got lucky
15:51:05 <bswartz> okay so let's get back to what tbarron was asking about
15:51:19 * bswartz looks at clock
15:51:28 <tbarron> can we turn on zanata now, as a bug, or do we have to wait till O?
15:51:41 <bswartz> tbarron: I see no reason not to turn it on -- what risk could it possibly introduce?
15:51:53 <tbarron> just checking
15:52:27 <tbarron> that's all i have on this one
15:52:34 <bswartz> anyone disagree and think we should wait until ocata to turn on translations?
15:52:37 <gouthamr> my ask is that  we backport pending backports and then turn this on and gate on it, and call it out in the devref and make this very clear that even if a critical bugfix comes along, it can't be backported if it has a translatable string
15:53:08 <bswartz> gouthamr: whether we do translations or not, I still believe we need to enforce the string freeze
15:53:10 <gouthamr> i don't understand the reasoning very well, and i might be wrong.. but this is breaking the contract that we will backport bugfixes that affect our users
15:53:56 <bswartz> okay 1 last topic
15:54:02 <bswartz> #topic Tempest direction
15:54:11 <bswartz> tbarron: you're up one last time
15:54:14 <gouthamr> bswartz: what all constitute a "user facing string"? this is confusing, perhaps a mailing list item..
15:54:15 <tbarron> let's take that one up next time as it's big, but
15:54:24 <bswartz> gouthamr: anything with _()
15:54:38 <tbarron> https://review.openstack.org/#/c/365250/ could use attention
15:54:41 <bswartz> tbarron: can you get this started?
15:55:20 <tbarron> yeah, the bigger topic is maybe we should write down our near term tactical approaches to tempest stability and longer term goals
15:55:28 <tbarron> and see if we can get agreement on these
15:55:42 <bswartz> tbarron: not a bad idea
15:55:47 <tbarron> but short term, while we don't have tempest lib, etc. it will be helpful
15:56:01 <bswartz> it's written down in meeting minutes already -- where else do you propose capturing this?
15:56:12 <tbarron> to advance the sha for the tempest we run to match the tempest label 12.2.0
15:56:18 <tbarron> hence above review
15:56:36 <tbarron> as new people come in, it's hard to have to read all the backlog
15:56:47 <bswartz> yeah I agree, but where?
15:56:52 <tbarron> probably we should have a devref?
15:56:54 <bswartz> is it a wiki thing? a devref thing?
15:57:01 <gouthamr> +1 devref
15:57:23 <bswartz> devref is supposed to be a reference document for how stuff works today
15:57:34 <bswartz> typically you don't discuss future plans in a devref
15:57:39 <bswartz> perhaps a spec....
15:57:48 <tbarron> it could start as an etherpad and evolve to more durable form, perhaps a spec
15:58:01 <tbarron> as long as that isn't a graveyard :)
15:58:11 <bswartz> tbarron: that's a whole other topic
15:58:13 <gouthamr> +1 :P
15:58:24 <bswartz> one that I'm eager to address before barcelona
15:58:24 <tbarron> bswartz: XDXD
15:59:01 <bswartz> #topic open discussion
15:59:07 <bswartz> okay 1 minute for any last things
15:59:30 <bswartz> reminder: vote for our mascot/logo
15:59:42 <bswartz> reminder: make sure bugs are targeted to RC1 if they need to be
15:59:50 <bswartz> thanks everyone
15:59:59 <bswartz> #endmeeting