15:00:55 <bswartz> #startmeeting manila
15:00:56 <openstack> Meeting started Thu Jul 14 15:00:55 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:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:59 <openstack> The meeting name has been set to 'manila'
15:01:02 <bswartz> hello all
15:01:03 <toabctl> hi
15:01:03 <cknight> Hi
15:01:04 <gouthamr> hello o/
15:01:07 <ganso> hello
15:01:07 <xyang> hi
15:01:08 <aovchinnikov> hi
15:01:08 <vponomaryov> hello
15:01:09 <zhongjun_> hello
15:01:10 <jseiler> hi
15:01:28 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:34 <tpsilva> hello
15:01:39 <dustins> \o
15:01:50 <MikeG451> Hi
15:01:55 <bswartz> #topic N-2 milestone
15:02:07 <markstur_> hello
15:02:23 <bswartz> So we can't wait any longer to tag the milestone
15:02:42 <bswartz> there were are few patches I was hoping we could get in before the tag, but it looks like they won't
15:02:57 <bswartz> does anyone have anything they're still hoping to merge before we tag N-2?
15:03:51 <markstur_> nothing that can't wait for N-2+x
15:03:54 * bswartz hears crickets
15:03:58 <bswartz> okay then
15:04:21 <markstur_> Seems hardly anyone is here today
15:04:24 <tpsilva> I have a patch ready for merge
15:04:27 <bswartz> expect current branch HEADS to be tagged -- please don't workflow anything else until the tags are made
15:04:45 <tpsilva> I am on mobile, so ganso could look for the link for me
15:04:48 <bswartz> markstur_: that's because you came in late
15:04:54 <bswartz> :-p
15:05:16 <ganso> #link https://review.openstack.org/336138
15:05:24 <tpsilva> ganso: thanks
15:05:39 <markstur_> oh. I was actually early but there was a disconnect. Didn't realize I missed stuff.
15:06:01 <cknight> I'd like to review that patch before we merge it, please.
15:06:13 <bswartz> cknight: will you have time for that after the meeting?
15:06:20 <bswartz> wait cknight aren't you on vacation?
15:06:21 <vponomaryov> also no real need to hurry merge it in N-2
15:06:40 <cknight> bswartz: No, it'll be tomorrow.  Anything pulled directly from Cinder is automatically suspect.
15:06:47 <bswartz> okay
15:07:03 <vponomaryov> cknight: +1 ))
15:07:05 <bswartz> I'm hearing that it doesn't need to be in N-2 and some people still want to review it
15:07:40 <vponomaryov> bswartz: it doesn't because nothing is going to use it
15:08:10 <bswartz> #topic Managing initial security (of the root directory) for new shares
15:08:10 <vponomaryov> bswartz: in scope of N-2 code base
15:08:32 <bswartz> so this probably matters more for CIFS than NFS, but it affects NFS too
15:08:50 <bswartz> currently we leave this out of scope for Manila, but I have a feeling that will create problems
15:09:03 <bswartz> it certainly created problems for me when testing the docker cifs driver
15:09:25 <bswartz> the basic problem is that every share, even though it starts empty, still has a directory in it
15:09:34 <bswartz> and that directory has an owner and mode bits
15:09:50 <bswartz> or ACLs for you windows people
15:09:54 <ganso> bswartz: /home directory?
15:10:08 <bswartz> ganso: I'm talking about /
15:10:58 <bswartz> the permissions on the root of a share determine who can mount (in the case of CIFS) and who can add/delete files in the share
15:11:37 <bswartz> in the NFS world the traditional approach to solving this is to make sure at least one client has root permissions (no root squash) so he can change the values to what he wants
15:12:20 <bswartz> the disadvantage is that requires users to grant root access to at least one client for a least some time which might be unwanted step in their workflow
15:12:37 <bswartz> and on the CIFS side it's worse because there is no "root" who can assume this function
15:13:20 <bswartz> so it occurs to me that maybe Manila should solve this problem for our users
15:13:26 <ganso> bswartz: if we changed NFS to be "no_root_squash" by default wouldn't it make sense to do the same for CIFS?
15:13:41 <bswartz> ganso: CIFS has no such concept
15:13:44 <ganso> bswartz: current behavior in CIFS is what we previously had with "root_squash" in NFS
15:13:58 <ganso> bswartz: it has the concept of admin users... you can make all users admin
15:14:31 <bswartz> you're right about the concept of Administrators, but the solution is not to make everyone and administrator
15:14:39 <bswartz> s/and/an/
15:14:58 <ganso> bswartz: isn't it essentially what we done in NFS?
15:15:06 <bswartz> so if there is an administrator, and the client knows the account name and the password, he can fix this problem for himself in the CIFS world
15:15:24 <bswartz> the problem is that in the CIFS world the administrator account and password are typically not well-known
15:15:36 <bswartz> if they are then you have basically no security
15:16:08 <ganso> bswartz: even though they are administrators you would need to allow access to the share
15:16:18 <bswartz> and don't get me wrong -- I'm sure that no security is acceptable for a certain set of users
15:16:25 <ganso> bswartz: I've tested this in the generic driver (configuring the share server manually)
15:16:28 <bswartz> I'm interested in making this work for everyone though
15:17:19 <bswartz> this gets more interesting when you add share servers
15:18:01 <bswartz> actually its interesting in both cases, but for different reasons
15:18:47 <bswartz> with share servers, the client should be defining a security services which ultimately determines the universe of usernames, passwords, and permissions
15:19:23 <bswartz> so in that case, as long as you have a security service, you as the client can control the administrator account name and password can you can solve this yourself
15:19:38 <bswartz> without security services, you're again left with undefined behavior
15:20:28 <bswartz> without share servers, the usernames, passwords, and permissions are managed out of band
15:21:08 <bswartz> but IMO Manila should still have admin access to shares and the ability to chown/chmod the root directory on behalf of the end user to address the case when the end user doesn't have admin access
15:21:47 <bswartz> I'm thinking of some kind of new API or new arguments to existing APIs to make manila manage this filesystem metadata
15:22:14 <bswartz> and I'm not exactly sure what it should look like but I wanted to mention it in case others have ideas
15:22:57 <bswartz> also it reinforces that CIFS without a security service is pretty useless for anything except toy deployments
15:23:20 <aovchinnikov> how Manila would distinguish between regular users and users who are allowed to have admin access to shares?
15:23:38 <bswartz> aovchinnikov: membership in the "Administrators" group
15:24:03 <bswartz> That's how windows does it
15:24:11 <bswartz> if you a member of the group, you have the special powers
15:24:28 <bswartz> typically the group has one member called Administrator
15:24:52 <bswartz> but in real CIFS deployments there can be several
15:25:11 <bswartz> the point is you need an AD controller to define/manage this stuff
15:25:18 <ganso> bswartz: when an user invokes access_allow with 'user' access type, the driver has no way to know if that permission should be added to the group of Administrators or Users
15:25:51 <bswartz> ganso: it shouldn't have to -- there should be a separate function to address that
15:26:01 <bswartz> you can allow access to multiple users
15:26:08 <ganso> bswartz: separate function outside of manila?
15:26:24 <bswartz> well currently it is outside Manila but I'm proposing we bring it in
15:26:27 <bswartz> and keep it separate
15:26:59 <bswartz> so user A can "own" the share but you can grant access to A, B, and C
15:27:28 <ganso> bswartz: drivers always assume access_allow will add to the Users group then
15:27:31 <aovchinnikov> does it make A an administrator?
15:27:34 <ganso> bswartz: currently ^
15:27:36 <bswartz> right now the risk we have is that you can grant access to A, B, and C, but if D actually owns the share you can't fix that without going out of band
15:28:24 <bswartz> ganso: I think that behavior mentioned is not defined -- different drivers are not acting consistently
15:29:04 <bswartz> and obviously we won't have truly consistent behavior until we have CIFS scenario tests that exercise this code and make sure things behave as expected
15:29:34 <bswartz> anyways, that was a top-of-mind thing for me
15:29:41 <bswartz> we've got 2 other topics
15:30:03 <bswartz> #topic Mascot/Logo discussion
15:30:13 <bswartz> unfortunately I don't have a link handy
15:30:28 <gouthamr> #link: http://www.openstack.org/project-mascots
15:30:42 <bswartz> but the foundation is moving towards creating a logo for each project with a consistent theme and artwork
15:30:42 <gouthamr> tl;dr: Project teams pick an animal or natural feature as their mascot, and a professional illustrator will create their logo in a consistent style across projects
15:30:47 <bswartz> ty gouthamr
15:31:19 <dustins> So I should hang on to my now "limited edition" Manila Jeep sticker?
15:31:23 <bswartz> someone of you may be partial to the jeepeny logo which was on the stickers passed out in austin
15:31:42 <gouthamr> dustins: :( i tried convincing my team that jeepneys exist in the wild
15:31:43 <bswartz> I think that has been vetoed though
15:31:44 <markstur_> I want a manila gorilla
15:31:56 <bswartz> markstur_: you're the second person to suggest that
15:31:58 <gouthamr> the gorrilla in manila :D
15:32:05 <bswartz> I like it because it rhymes
15:32:11 <markstur_> has anyone suggested Manila Ice yet?
15:32:18 <markstur_> I think he's available
15:32:34 <bswartz> and gorillas are pretty awesome animals
15:32:36 <tpsilva> +1 manila gorilla
15:32:42 <ganso> markstur_: lol
15:32:44 <xyang> any object from nature that looks like a manila folder?:)
15:32:56 <bswartz> however this decision will ultimately be a community one
15:32:59 <dustins> A Box Turtle? :)
15:33:06 <xyang> :)
15:33:12 <dustins> You know, because you put manila folders in boxes?
15:33:13 <bswartz> xyang: if there was, I would vote against it just because
15:33:35 <gouthamr> i can think of a venus flytrap... but that's not very pleasant
15:33:46 <markstur_> I think gouthamr could come up with a folder shaped llama if we let him
15:33:52 <ganso> xyang: a sea shell possibly?
15:33:56 <bswartz> dustins: turtles are pretty slow though -- and they bite
15:34:02 <xyang> bswartz: you don’t want to stay consistent?
15:34:07 <tmazur> gouthamr, a venus trap with a ribbon?
15:34:14 <tmazur> *flytrap
15:34:24 <dustins> bswartz: I just like box turtles :)
15:34:32 <ameade> kangaroo has a pouch
15:34:49 <gouthamr> haha >.<
15:34:50 <xyang> ameade: I like that:)
15:34:52 <markstur_> open folders look like wings.  Could be moths
15:34:53 <dustins> So do Koalas
15:35:01 <vponomaryov> bswartz: turtles are energy saving, I saw river-turtle running really fast
15:35:04 <bswartz> xyang: file folders are pretty boring, and still not of the natural world
15:35:10 <dustins> Lunar Moth?
15:35:19 <markstur_> moths are not as cool as gorillas.  Sorry moths
15:35:26 <xyang> moths are ugly
15:35:28 <bswartz> I think the point is to be more whimsical
15:35:33 <bswartz> xyang: not all of them
15:35:46 <jseiler> I was thinking kangaroo too because of the pouch
15:35:50 <xyang> anyway I don’t like insets in general
15:36:00 <xyang> kangaroo is really cute
15:36:12 <bswartz> i hope someone is writing these down
15:36:17 <jseiler> vanilla manila bean
15:36:22 <bswartz> we could make an etherpad and turn it into a poll
15:36:24 <ganso> xyang: +1 no insects
15:36:25 <markstur_> xyang, moth-hater
15:36:32 <gouthamr> http://ct.fra.bz/ol/fz/sw/i53/2/3/12/frabz-im-sooooo-confused-b62996.jpg
15:36:39 <markstur_> xyang, How about a nightime butterfly then?
15:36:52 <xyang> markstur_: I like butterflies
15:37:16 * bswartz thought that butterflies were insects....
15:37:45 * bswartz is not a biologist
15:37:46 <tmazur> manila is an anagram for 'animal' by the way...
15:37:55 <markstur_> manila monarchs
15:37:59 <ganso> tmazur: mind blown
15:38:02 <gouthamr> tmazur: ah! that's true
15:38:02 <xyang> right, they are disgusting when they are worms
15:38:04 <dustins> tmazur: So really anything we use would work...
15:38:17 <tmazur> totally :D
15:38:25 <ameade> opossums have pouches too
15:38:27 <ameade> lol
15:39:11 <vponomaryov> xyang: worms are animals, not insects
15:39:24 <bswartz> The National Animal of the Philippines is the carabao, the Asian Water Buffalo [1] google
15:39:46 <xyang> vponomaryov: they are insects.  anyway I hate them whatever they are:)
15:39:52 <ganso> vponomaryov: insects are not animals?
15:40:09 <vponomaryov> different entity classes
15:40:14 <dustins> Ceph kinda cornered the market on Cephlaopod based mascots, so no krakens or eldrich horrors
15:40:33 <bswartz> dustins: I know
15:40:42 <bswartz> I worry that whatever we pick will conflict with something
15:40:46 <dustins> a centaur?
15:40:48 <bswartz> animal mascots are pretty common
15:41:00 <markstur_> manila koalla
15:41:21 <bswartz> the important thing is that we don't conflict with any other openstack projects, so the sooner we decide on something the better
15:41:22 <gouthamr> “It will be a killa and a chilla and a thrilla when I get the gorilla in Manila" (that's sticky)
15:41:26 <ameade> trust me, nobody has opossum
15:41:28 <bswartz> because other teams are having similar discussions
15:41:29 <markstur_> ^ has a pouch and ends in la and their darn cute too.
15:41:35 <xyang> dustins: you can’t have imaginary thing
15:42:05 <vponomaryov> xyang: prove it does not exists
15:42:08 <ganso> xyang: no unicorns then? :(
15:42:09 <bswartz> I'm really wondering what the smaug team will choose, since I suspect that dragons aren't valid either
15:42:11 <dustins> xyang: aww :(
15:42:18 <xyang> yes, not unicorn nor dragon
15:42:26 <vponomaryov> ganso: unicorn!
15:42:27 <dustins> Well, could do a Komodo Dragon
15:42:39 <xyang> bswartz: good point.  I wonder too
15:42:51 <bswartz> something tells me they won't choose the komodo
15:43:06 * dustins is surprised Tolkien's estate hasn't dropped the hammer on Smaug
15:43:07 <ganso> can we consider dinosaurs?
15:43:21 <bswartz> ganso: I suspect yes
15:43:29 <dustins> Pterodactyl?
15:43:32 <ameade> oh that opens up a crazy world
15:43:37 <ameade> dimorphadon
15:43:58 <bswartz> #link https://etherpad.openstack.org/p/manila-mascot-brainstorm
15:44:05 <markstur_> are pokemons real?
15:44:06 <xyang> ganso: doesn’t that mean outdated
15:44:18 <zhongjun_> smaug will change the name, because of the conflict, dragons will also be changed
15:44:32 <aovchinnikov> oh, also armadillo sort of fits
15:44:32 <gouthamr> markstur_: they are. how many have you caught?
15:44:34 <ganso> xyang: indeed
15:44:39 <dustins> Dire Wolf?
15:45:04 <bswartz> so I made an etherpad to collect ideas
15:45:18 <bswartz> I'll turn that into a poll and we can vote
15:45:24 <markstur_> gouthamr, zero. they are trying to catch me.
15:45:26 <vponomaryov> in a week?
15:45:33 <vponomaryov> or in ettherpad anytime?
15:46:14 <bswartz> put suggestions in the etherpad ASAP
15:46:19 <bswartz> when it quiets down I'll convert to a poll
15:46:26 <bswartz> no later than the end of the week
15:46:37 <bswartz> okay I had something else more serious
15:46:46 <bswartz> #topic Tempest alternatives
15:47:03 <bswartz> So this comes up from time to time
15:47:15 <bswartz> we've always had an uneasy relationship with the tempest team
15:47:34 <bswartz> they break us, we complain, they ignore, repeat
15:47:58 <bswartz> the problems caused by this are similar to the problems caused by the generic driver in the gate
15:48:54 <bswartz> As far as I can tell, tempest doesn't add much value on top of testr or os-testr other than as a place to check in test code and duplications of every openstack REST client
15:49:45 <bswartz> we really shouldn't be using the tempest clients for anything other than manila -- for nova, keystone, etc we should be using the released libraries from pypi
15:49:55 <vponomaryov> bswartz: it is much esier to test lots of OpenStack services using one tool
15:50:46 <bswartz> vponomaryov: I don't disagree, but what I'm proposing is that we use os-testr as the common tool
15:51:38 <vponomaryov> bswartz: so, you propose to remove any dependency on tempest as much as possible and still provide our tests as plugin for it?
15:51:47 <dustins> bswartz: I'm a fan of ostestr, myself
15:52:02 <bswartz> I suspect if we used the existing clients from pypi to talk to things, we could keep all of our existing test code in Manila and base it on os-testr instead and not much would have to change
15:52:03 <dustins> Was quite easy to use compared to tox
15:52:10 <vponomaryov> bswartz: if yes, we still can be broekn
15:52:37 <bswartz> vponomaryov: no the goal is to slowly iterate until we don't depend on it at all
15:52:55 <vponomaryov> bswartz: so, no plugin for tempest?
15:53:11 <bswartz> my question is that, aside from the clients, what else would we need to change if we stopped depending on tempest?
15:53:22 <vponomaryov> bswartz: all QAs of clouds where manila is installed will blame us
15:53:52 <bswartz> vponomaryov: I think keeping a tempest plugin costs us more than it gives us value for testing our own code
15:54:01 <vponomaryov> bswartz: also, tempest's stable interface is under development
15:54:06 <bswartz> we know the cost -- they break us somewhat regularly and we have to fix
15:54:20 <bswartz> the question is what do we gain from tempest, and my current understanding is not much
15:54:30 <dustins> So you'd need to do something specific to test manila in a cloud?
15:54:36 <bswartz> they don't let us submit code and they don't fix problems that they cause for us
15:54:44 <dustins> Rather than rely on Tempest?
15:54:50 <vponomaryov> bswartz: they already on that way
15:55:00 <vponomaryov> bswartz: it is just in progress
15:55:06 <bswartz> tempest's "stable interface" has been on the way for 2 years
15:55:07 <dustins> Or would the Tempest plugin still be used?
15:55:11 <gouthamr> bswartz: if we have a tempest plugin, it will enable other services to use our client (tempest is working on a feature like this: https://review.openstack.org/#/c/334596/)
15:55:13 <bswartz> it's not done yet
15:55:20 <bswartz> I call BS that it will ever be done
15:56:29 <bswartz> I would love to be proved wrong here
15:56:53 <xyang> I’m not a fan of tempest so I have no problem if we want to move away from it
15:56:58 <dustins> Would we have to rewrite our tests to not use anything related to Tempest or Tempst-Lib?
15:57:02 <gouthamr> afaik, there has been decent progress.. and we have a small list of clients that aren't 'stable' yet.
15:57:02 <vponomaryov> bswartz: I would say it is esier for us to keep compatibility than to port our tests to something new
15:57:02 <bswartz> but I think it would be irresponsible to not consider alternatives at this point
15:57:19 <bswartz> vponomaryov: how different is os-testr compared to tempest?
15:57:21 <vponomaryov> bswartz: in addition to keeping common interface as for lots of other projects
15:57:45 <bswartz> there's a lot of unknowns here (for me) which is why I want to at least answer the questions of could we do it and how bad would it be
15:57:52 <bswartz> so we can compare that to how bad the status quo is
15:58:06 <gouthamr> bswartz: tempest gives us waiters, cleanup handlers, exceptions, clients and easy keystone access
15:58:42 <dustins> Is the goal of this exercise to ultimately have Manila's tests be self-sufficient?
15:58:45 <gouthamr> we'd have to write all these on our own (and use existing python-x-clients) and maintain them
15:58:50 <dustins> And not rely on Tempest in any way?
15:58:52 <vponomaryov> bswartz: it just designed in general for tests, tempest provides lots of openstack stuff
15:59:22 <bswartz> dustins: yes, we hoped to get there 2 years ago when we started with the tests in the manila repo and the plugin interface with "tempest_lib"
15:59:46 <dustins> Hmm, could be interesting
15:59:49 <vponomaryov> bswartz: so, I would say I disagree to drop our tempest plugin, we should provide it
16:00:11 <bswartz> so I'm not opposed to having a tempest plugin -- I just think we should avoid using it in our gate
16:00:27 <dustins> Might make it a nightmare for deployers who need to track test cases and such and rely on Tempest's commonality to generalize test cases and environments
16:00:37 <bswartz> I'd rather that our manila functional tests didn't depend on unstable things (which tempest is)
16:00:55 <bswartz> dustins: that's good input
16:01:12 <bswartz> dustins: I hope that whatever we would build would ultimately be better, but I could be wrong
16:01:21 <bswartz> anyways we're over time and I've said what I wanted
16:01:27 * bswartz looks around for fuel ppl
16:01:34 * xarses hides
16:01:36 <bswartz> thanks everyone see you next week
16:01:38 <dustins> I already have a hard enough time doing Tempest runs against our stuff, making it MORE unlike the others will make it worse in the short term at least
16:01:46 <bswartz> #endmeeting