| *** bill_az has quit IRC | 00:00 | |
| *** sticker has joined #openstack-manila | 00:08 | |
| *** bill_az has joined #openstack-manila | 01:15 | |
| *** bill_az has quit IRC | 01:32 | |
| *** chlong has joined #openstack-manila | 02:04 | |
| *** bill_az has joined #openstack-manila | 02:56 | |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila: Migrate API reference into tree https://review.openstack.org/313874 | 03:04 |
|---|---|---|
| *** akerr has joined #openstack-manila | 03:08 | |
| *** bill_az has quit IRC | 03:08 | |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila: Migrate API reference into tree https://review.openstack.org/313874 | 03:12 |
| *** akerr has quit IRC | 03:12 | |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila: Migrate API reference into tree https://review.openstack.org/313874 | 03:18 |
| *** chlong has quit IRC | 03:34 | |
| *** chlong has joined #openstack-manila | 03:51 | |
| *** amit213 has quit IRC | 04:08 | |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila: Migrate API reference into tree https://review.openstack.org/313874 | 04:14 |
| *** gouthamr has quit IRC | 04:24 | |
| *** chlong has quit IRC | 04:26 | |
| *** chlong has joined #openstack-manila | 04:38 | |
| *** yangyapeng has joined #openstack-manila | 04:57 | |
| *** chlong has quit IRC | 05:05 | |
| *** pcaruana has quit IRC | 05:13 | |
| *** chlong has joined #openstack-manila | 05:18 | |
| *** chlong has quit IRC | 05:37 | |
| *** openstackgerrit has quit IRC | 06:02 | |
| *** openstackgerrit has joined #openstack-manila | 06:03 | |
| openstackgerrit | Merged openstack/manila-ui: Updated from global requirements https://review.openstack.org/323899 | 06:10 |
| openstackgerrit | liuke proposed openstack/manila: Huawei: Support reporting disk type of pool https://review.openstack.org/324194 | 06:21 |
| *** chlong has joined #openstack-manila | 06:31 | |
| *** shausy has joined #openstack-manila | 06:31 | |
| *** ociuhandu has joined #openstack-manila | 06:35 | |
| openstackgerrit | Merged openstack/manila: Updated from global requirements https://review.openstack.org/324833 | 06:44 |
| *** pcaruana has joined #openstack-manila | 07:14 | |
| *** chlong has quit IRC | 07:56 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [Tempest] Add valuable tags to tests https://review.openstack.org/324006 | 07:56 |
| *** rraja has joined #openstack-manila | 08:17 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [Tempest] Add valuable tags to tests https://review.openstack.org/324006 | 08:30 |
| *** lpetrut has joined #openstack-manila | 08:45 | |
| openstackgerrit | liuke proposed openstack/manila: Huawei: Support reporting disk type of pool https://review.openstack.org/324194 | 08:55 |
| *** sgotliv has joined #openstack-manila | 08:57 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: Stop using deprecated tempest opts https://review.openstack.org/322895 | 09:16 |
| *** kaisers1 has joined #openstack-manila | 09:17 | |
| *** permalac has joined #openstack-manila | 09:22 | |
| *** yangyapeng has quit IRC | 10:22 | |
| *** chlong has joined #openstack-manila | 10:44 | |
| *** shausy has quit IRC | 10:49 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [Tempest] Add valuable tags to tests https://review.openstack.org/324006 | 10:54 |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: Stop using deprecated tempest opts https://review.openstack.org/322895 | 10:54 |
| *** adrianofr has joined #openstack-manila | 11:17 | |
| *** lgreg has joined #openstack-manila | 11:43 | |
| openstackgerrit | Merged openstack/manila-image-elements: Add tox job for building Docker image https://review.openstack.org/305681 | 11:50 |
| *** JoseMello has joined #openstack-manila | 12:00 | |
| *** ociuhandu has quit IRC | 12:03 | |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs: Add spec for Share Retype https://review.openstack.org/315708 | 12:13 |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs: Add spec for Share Migration Newton improvements https://review.openstack.org/315707 | 12:17 |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [Tempest] Add valuable tags to tests https://review.openstack.org/324006 | 12:17 |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [Tempest] Stop using deprecated Tempest opts https://review.openstack.org/322895 | 12:17 |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs: Add spec for Data Service API https://review.openstack.org/315709 | 12:17 |
| *** eharney has joined #openstack-manila | 12:28 | |
| *** akshai has joined #openstack-manila | 12:38 | |
| *** gouthamr has joined #openstack-manila | 12:44 | |
| *** ociuhandu has joined #openstack-manila | 12:46 | |
| *** eharney has quit IRC | 12:48 | |
| *** cknight has joined #openstack-manila | 12:53 | |
| *** timcl has joined #openstack-manila | 12:54 | |
| *** ociuhandu has quit IRC | 12:58 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [Tempest] Stop using deprecated Tempest opts https://review.openstack.org/322895 | 13:04 |
| *** lgreg has quit IRC | 13:06 | |
| *** lgreg has joined #openstack-manila | 13:06 | |
| *** porrua has joined #openstack-manila | 13:07 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [Tempest] Add valuable tags to tests https://review.openstack.org/324006 | 13:08 |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [Tempest] Stop using deprecated Tempest opts https://review.openstack.org/322895 | 13:08 |
| *** mtanino has joined #openstack-manila | 13:15 | |
| *** xyang1 has joined #openstack-manila | 13:15 | |
| *** absubram has joined #openstack-manila | 13:17 | |
| *** yangyapeng has joined #openstack-manila | 13:23 | |
| *** alyson_ has joined #openstack-manila | 13:25 | |
| *** jcsp has joined #openstack-manila | 13:27 | |
| *** jcsp has quit IRC | 13:27 | |
| *** jcsp has joined #openstack-manila | 13:28 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [Tempest] Stop using deprecated Tempest opts https://review.openstack.org/322895 | 13:29 |
| openstackgerrit | Clinton Knight proposed openstack/manila-specs: Add spec for Manila share revert to snapshot https://review.openstack.org/315695 | 13:33 |
| *** cbader has joined #openstack-manila | 13:33 | |
| *** mtanino has quit IRC | 13:36 | |
| *** xyang1 has quit IRC | 13:40 | |
| *** xyang1 has joined #openstack-manila | 13:41 | |
| *** yangyape_ has joined #openstack-manila | 13:42 | |
| *** yangyapeng has quit IRC | 13:43 | |
| *** dmk0202 has joined #openstack-manila | 13:44 | |
| *** dustins has joined #openstack-manila | 13:47 | |
| *** eharney has joined #openstack-manila | 13:47 | |
| *** permalac has quit IRC | 13:54 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [Tempest] Stop using deprecated Tempest opts https://review.openstack.org/322895 | 14:19 |
| dustins | tellesnobrega: Lemme know if you need any Manila information to get ramped up! | 14:21 |
| tellesnobrega | dustins, will do :) thanks | 14:21 |
| dustins | Lots of other great folks here as well :) | 14:22 |
| *** permalac has joined #openstack-manila | 14:33 | |
| tellesnobrega | dustins, i've met ganso so far, will get to know more soon (questions to come) | 14:34 |
| *** mtanino has joined #openstack-manila | 14:34 | |
| dustins | Just let us know :D | 14:34 |
| tellesnobrega | thanks | 14:38 |
| *** merooney has joined #openstack-manila | 14:47 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [Tempest] Stop using deprecated Tempest opts https://review.openstack.org/322895 | 14:52 |
| *** permalac has quit IRC | 14:52 | |
| *** dsariel has joined #openstack-manila | 14:53 | |
| *** dustins has quit IRC | 14:59 | |
| *** dustins has joined #openstack-manila | 15:01 | |
| *** dmk0202 has quit IRC | 15:05 | |
| *** dsariel has quit IRC | 15:17 | |
| *** dgonzalez has quit IRC | 15:17 | |
| *** dgonzalez has joined #openstack-manila | 15:19 | |
| *** lgreg has left #openstack-manila | 15:27 | |
| openstackgerrit | Merged openstack/manila: Hacking check for str in exception breaks in py34 https://review.openstack.org/320962 | 15:29 |
| *** nkrinner_afk has quit IRC | 15:42 | |
| *** dmk0202 has joined #openstack-manila | 15:58 | |
| ganso | bswartz: ping | 16:02 |
| *** dmk0202 has quit IRC | 16:06 | |
| *** dustins_ has joined #openstack-manila | 16:10 | |
| *** dustins_ has quit IRC | 16:10 | |
| *** dustins has quit IRC | 16:13 | |
| bswartz | ganso: pong | 16:32 |
| *** pcaruana has quit IRC | 16:34 | |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila: Pass context down to ViewBuilder method https://review.openstack.org/326030 | 16:34 |
| *** lpetrut has quit IRC | 16:39 | |
| *** mtanino_ has joined #openstack-manila | 16:41 | |
| *** mtanino has quit IRC | 16:42 | |
| *** Suyi has joined #openstack-manila | 16:56 | |
| ganso | Hi Ben, I am renaming the parameters in migration-start API | 16:56 |
| ganso | bswartz: ^ | 16:56 |
| ganso | bswartz: since it is still experimental, I am not sure the backwards compatibility with previous versions should be maintained | 16:57 |
| bswartz | ganso: oh good | 16:57 |
| ganso | bswartz: I would need to support the old-named parameters | 16:57 |
| bswartz | I was looking at the APIs in the spec and thinking we might want to restructure them for better clarity | 16:57 |
| bswartz | yes the change should be microversioned -- however supporting the old names is entirely optional | 16:58 |
| ganso | bswartz: I am coding it right now... spec is taking too long to be approved :( | 16:58 |
| bswartz | in fact we might want to avoid supporting the old parameters as it could set a bad precendent | 16:58 |
| bswartz | I guess it depends how much work it is | 16:59 |
| ganso | bswartz: if you have comments for restructuring the API parameters different from what is currently in the spec could you please post as soon as you have some time? | 16:59 |
| bswartz | do you have a new proposal ready yet? | 16:59 |
| ganso | bswartz: when it moves out of experimental, the experimental API will be deleted, right? | 17:00 |
| ganso | bswartz: new proposal? | 17:00 |
| bswartz | new API proposal | 17:00 |
| ganso | bswartz: in the spec the API has new parameters and changes an existing one | 17:00 |
| bswartz | ganso: ideally what happens is that the experimental API becomes the final API | 17:01 |
| bswartz | so we should make any changes while the API is still experimental, then when we're satisfied it won't need to change we just remove the experimental tag and leave the API exactly as is | 17:01 |
| ganso | bswartz: ok | 17:02 |
| ganso | bswartz: my patch does not change it to non-experimental yet | 17:02 |
| ganso | bswartz: should we do it close to FF when the update is already merged? | 17:06 |
| *** rraja has quit IRC | 17:06 | |
| bswartz | yes any API changes would need to be BEFORE FF | 17:07 |
| bswartz | and we'd only do it if we were entirely happy with the API definintion | 17:08 |
| bswartz | if there was doubt we would leave it experimental until Ocata | 17:08 |
| *** mtanino has joined #openstack-manila | 17:12 | |
| *** mtanino_ has quit IRC | 17:14 | |
| bswartz | has anyone else read rraja's ML post? | 17:15 |
| bswartz | it's a heavy one which deserves a response | 17:15 |
| tbarron | bswartz: well, i have | 17:23 |
| tbarron | bswartz: the area that rraja is working in overlaps with his items a-c, but I don't think his initial implementation should wait for completion of any of a-c. | 17:24 |
| tbarron | bswartz: we can iterate | 17:24 |
| *** catintheroof has joined #openstack-manila | 17:25 | |
| tbarron | bswartz: e.g. he can return a dict of access rules until a) gets done | 17:25 |
| tbarron | bswartz: and until c) is done he can return a regular model update | 17:25 |
| bswartz | I think I just need to grok the use case better | 17:26 |
| bswartz | When the idea was originally proposed I wasn't convinced it was a real problem | 17:26 |
| tbarron | bswartz: sure, and rraja and jcsp will be better guides to that than I am. | 17:26 |
| bswartz | I want to make sure we make the best possible case for this feature and that we understand why the alternatives are insufficient | 17:27 |
| tbarron | bswartz: maybe raise the question again in the morning when it will be more TZ appropriate for jcsp and rraja | 17:28 |
| tbarron | bswartz: working with ceph a bit now (mostly for a cinder backup issue r/t manila) i am getting a feel for how ceph auth works and why this feature would be useful but I want to take care not to muddy the waters with my ideas when you can talk to the right people | 17:31 |
| *** dsariel has joined #openstack-manila | 17:34 | |
| jcsp | bswartz: the core point in Ramana's post is that we have this update_access change for ceph keys in the pipe, but we know there are two other things that may touch the same code in this cycle | 17:41 |
| jcsp | (the other things being the racyness of it, and the desire for per-rule status) | 17:42 |
| jcsp | so we are happy with our approach for handling auth keys, but would rather have a conversation about how this is going to fit together, instead of potentially having a patch get stuck in merge hell later | 17:42 |
| openstackgerrit | Merged openstack/manila-specs: Add spec for Manila share revert to snapshot https://review.openstack.org/315695 | 17:43 |
| bswartz | jcsp: so can you refresh my memory on what this security mechanism actually does? | 17:44 |
| bswartz | or is there a doc I should read? | 17:44 |
| bswartz | I'm trying to understand who does what -- what are the input and outputs at each stage | 17:44 |
| jcsp | let me try and find the link to my old mailing list post about it | 17:44 |
| bswartz | that's right you did write a ML post about this around the time of Tokyo | 17:45 |
| bswartz | I should have it in my archives (those got wiped just before Tokyo) | 17:45 |
| jcsp | here we are: https://openstack.nimeyo.com/62893/openstack-dev-manila-share-allow-deny-by-shared-secret | 17:45 |
| bswartz | jcsp: who is the decider for access to ceph shares? if an unauthorized user requests access what happens? | 17:47 |
| *** harlowja has joined #openstack-manila | 17:48 | |
| bswartz | You refer to "caller" and "driver" but the caller could be an admin or a normal user | 17:48 |
| jcsp | the ceph monitor servers handle authentication: they hand out kerberos-style tickets. | 17:48 |
| jcsp | caller in that context means person accessing manila API (i.e. administrative access) | 17:48 |
| bswartz | If I want to create a share and grant access to alice and bob, but not charlie, do I create 2 keys and give one each to alice and bob? | 17:49 |
| jcsp | yes | 17:49 |
| bswartz | or do I create one key and give it to both of them? | 17:49 |
| jcsp | assuming that alice and bob need distinct ceph names. If alice and bob are just two servers you could create a ceph key named "aliceandbob" and give it to both | 17:49 |
| bswartz | but there could be a differet share which bob and charlie should have access to, but not alice | 17:50 |
| jcsp | right | 17:50 |
| bswartz | in that case can bob use a single key for both shares, or does he need a different key per share? | 17:50 |
| jcsp | he uses the same key for both shares | 17:50 |
| bswartz | so these access keys amount to unique identities, which can be associated with one or more shares | 17:51 |
| jcsp | zero or more, yes. | 17:51 |
| bswartz | and the admin creates them at will and distributes them out of band | 17:51 |
| jcsp | right, where "the admin" in practice probably means some cloud orchestration tool, and "out of band" probably means as part of provisioning VMs. | 17:52 |
| bswartz | but the whole theory of this features is to make that out of band distribution mechanism be the Manila API | 17:52 |
| jcsp | not quite -- the Manila API means that the admin/orchestrator can get his key without talking to the ceph cluster. Getting the key onto openstack guests is still his problem (it is not expected that guests would access keys from the Manila API) | 17:53 |
| bswartz | okay that helps | 17:53 |
| bswartz | the part of this that makes my cautious is that we're handing secrets around and it's very important that secrets don't get into the wrong hands | 17:53 |
| bswartz | so the part that Manila is involved with is only the channel between the admin and the storage controller | 17:54 |
| jcsp | the basis of the security is that access to the Manila share API for a given tenant is limited to that tenant | 17:54 |
| *** timcl1 has joined #openstack-manila | 17:55 | |
| bswartz | well yeah the term "admin" is problematic again because it's not the manila admin | 17:55 |
| bswartz | it's the admin in the sense that he's creating shares and setting access rules, but he's the manila tenant | 17:56 |
| jcsp | right. I'm trying to avoid saying admin | 17:56 |
| bswartz | and any "users" he's controlling access to are subordinates within his project/tenant | 17:57 |
| jcsp | yep | 17:57 |
| bswartz | okay so this leads me back to a question I think I asked before but I can't remember the answer | 17:57 |
| *** timcl has quit IRC | 17:58 | |
| bswartz | why must the admin create these keys and distribute them to the users? why can't the users create the keys and have the admin "grant access" to pre-existing keys? | 17:58 |
| bswartz | you mentioned above that key's can be mapped to ZERO or more shares, so clearly the existence of a share isn't a prerequisite to create one | 17:59 |
| jcsp | because for "the users" (i.e. guests) to create Ceph keys, they would need administrative access to the Ceph cluster | 17:59 |
| bswartz | still there's 2 separate tasks here though | 18:00 |
| bswartz | there's a creation of users and their keys, which I understand must be undertaken by an admin | 18:00 |
| bswartz | but the mapping of the share to the user doesn't need to be linked to that | 18:01 |
| jcsp | at the ceph level, both of those things require super-privileges | 18:01 |
| bswartz | right, so I'm trying to imagine the analogue in the CIFS or NFS world | 18:02 |
| *** dustins has joined #openstack-manila | 18:02 | |
| jcsp | so they both need to live behind the access-controlled Manila API (we can't let any guest have access to that super-privileged Ceph interface) | 18:02 |
| bswartz | in the CIFS world, an AD administrator must create an account for you before you can get access to anything | 18:02 |
| bswartz | Manila doesn't insert itself into that workflow | 18:02 |
| jcsp | so presumably in a cloud environment that means the AD administrator is the tenant himself, i.e. he creates his own domain for his application? (I don't know much about this) | 18:03 |
| bswartz | Manila grants access on CIFS shares to pre-existing users in the AD domain | 18:03 |
| jcsp | or does your whole cloud have one AD administrator who has to manually intervene for cloud guests to run up their applications? | 18:03 |
| bswartz | typically the AD domain would be a shared resources, but possibly you could have a special one just for the cloud | 18:04 |
| jcsp | s | 18:04 |
| bswartz | resource* | 18:04 |
| jcsp | so the AD part is a below-cloud resource, that you have to do something out-of-cloud to before enabling a new tenant to use your cloud? | 18:04 |
| bswartz | well we can actually go 2 different ways there | 18:05 |
| bswartz | with share-servers, each tenant can have his own AD domain | 18:05 |
| bswartz | without share servers, all the tenants would share a common AD domain | 18:05 |
| jcsp | so the ceph case would be analogous to the "without share servers" case | 18:06 |
| bswartz | so in the latter case you're correct | 18:06 |
| bswartz | I keep thinking that there should be a way to decouple this "identity creation" operation from the "access granting" operation | 18:07 |
| bswartz | but the proposal is to force them to be linked | 18:07 |
| jcsp | architecturally, the cleanest way would be to give Manila a whole new API for managing identities | 18:08 |
| jcsp | which might not be 100% crazy if AD needed it the same way Ceph does | 18:08 |
| jcsp | but if it's just for Ceph it feels like dramatic overkill | 18:08 |
| bswartz | well I agree it should be separate APIs -- it's debatable whether those APIs belong in Manila | 18:08 |
| bswartz | I think the challenge is that other protocols (NFS, CIFS) have existing tools that people expect to use for the identity creation task | 18:09 |
| bswartz | Ceph is new enough that you can get users to use whatever API/interface you want | 18:09 |
| bswartz | And if you want it to be Manila, I don't have a problem with that, but it feels like we should create an extension or something | 18:10 |
| bswartz | if we did add an identity-management API, it probably would be possible to make it work with other protocols in addition to ceph | 18:11 |
| jcsp | ...or, if we made this relatively small change to store access keys in Manila, we wouldn't have to create a whole identity management API. | 18:11 |
| jcsp | and our users wouldn't have to talk to two APIs | 18:11 |
| jcsp | the thing is, at the point that users were writing code that used a Ceph-specific API, they might as well just use CephFSVolumeClient directly and skip Manila | 18:12 |
| jcsp | the value we want is to have users able to use one API, so that they can swap filesystems in and out | 18:12 |
| bswartz | I'm not trying to say we don't do this in Manila, I'm trying to say let's not overload the APIs to do more than what they're supposed to do | 18:12 |
| bswartz | an extra few APIs might be all we need to make this work | 18:13 |
| jcsp | except those APIs would need corresponding parts of the ShareDriver interface to actually get their data | 18:13 |
| bswartz | so access-allow will just be a mapping step | 18:13 |
| jcsp | it would be really really heavyweight | 18:14 |
| bswartz | hmm | 18:15 |
| jcsp | and we'd have a whole API+driver interface that was only used by one driver. I would rather do the work on the Ceph side to fit into the existing Manila mould as much as possible, so that we have a minimal amount of code in Manila that's only used by ceph | 18:16 |
| bswartz | so back to the use case I outlined above: I want to create share 1 and share 2, I want Alice and Bob to have access to share 1 and bob and charlie to have access to share 2 | 18:16 |
| bswartz | what sequence of call do you propose that the manila tenant does to make this happen? | 18:16 |
| jcsp | you do "allow share1 bob", "allow share1 alice", "allow share2 bob", "allow share2 charlie". | 18:17 |
| jcsp | then you have four access mappings | 18:17 |
| jcsp | that would give you three keys under the hood. Or, you could create two keys for your two "groups" of guests | 18:17 |
| bswartz | and when the tenant lists the access mappings, he sees keys in the API result, which were created by ceph and stored in the DB? | 18:18 |
| jcsp | yes | 18:18 |
| bswartz | and "bob" would get only one key because of magic inside the driver? | 18:18 |
| jcsp | right. he sees the same key for the bob->share1 mapping as he sees for the bob->share2 mapping, because they're the same bob. | 18:18 |
| jcsp | in database terms it is denormalised. | 18:18 |
| jcsp | but not gratuitously so | 18:18 |
| bswartz | can the driver scope the identities to the tenant? so tenant1/bob is not the same as tenant2/bob ? | 18:19 |
| jcsp | yes, we could internally compose key names like <share id>.bob to artificially introduce that limitation. | 18:20 |
| bswartz | that would cause bob to have different keys for share1 and share2 though | 18:20 |
| jcsp | but that would be annoying for someone if they genuinely wanted their guest bob to access N shares without giving him N keys | 18:20 |
| jcsp | yes, quite so. | 18:20 |
| bswartz | I'm thinking prefix the IDs with the tenant/project ID, not the share ID | 18:20 |
| jcsp | yes, we've discussed that quite a bit. | 18:21 |
| bswartz | okay well I can't argue that this won't work | 18:21 |
| bswartz | and it does seems rather simple to implement compared to adding new APIs | 18:21 |
| bswartz | if it's what the Ceph team wants for an access control interface I won't stand in the way | 18:22 |
| jcsp | we've gone back and forth a bit on whether to prefix keys with the tenant ID internally or not | 18:23 |
| jcsp | if we don't do that, we have to remember internally which tenant created a named key, so that we don't give its secret to another tenant | 18:23 |
| bswartz | if there are use cases for not doing it (because tenants might share data) then you could make it a configurable option | 18:23 |
| jcsp | we're working on the assumption that shares never get shared between tenants. | 18:24 |
| bswartz | it's less trusting (public cloud) environments though you would want assurances that other tenants can never see your secrets | 18:24 |
| jcsp | the downside to prefixing with tenant ID is that someone has to know the trick to get their ceph key name | 18:25 |
| bswartz | if you don't prefix the identities with a project ID, then another tenant can get your secrets by simply guessing your identity names | 18:25 |
| jcsp | so they ask for alice to be authorized, but they actually get a9s8d7as8d7.alice authorized | 18:25 |
| jcsp | right, they can do that unless we do the extra work in ceph to remember which tenant "owns" a secret (we have code for that, it's a complexity cost inside ceph) | 18:25 |
| bswartz | oh I see | 18:26 |
| jcsp | fortunately since we're a filesystem we can remember as much state as we want :-) | 18:26 |
| jcsp | the updates to that state were what originally prompted my questions about concurrency on the list a while back | 18:26 |
| jcsp | because we have to make sure that our updates to this state are safe | 18:26 |
| *** timcl1 has quit IRC | 18:26 | |
| bswartz | it seems like that approach amounts to the same implementation though -- ceph ends up storing both the identity name and the project ID | 18:26 |
| jcsp | yes, but we store it in a way that gives the tenant the identity that they'd asked for: they ask for alice, they get alice (not <something>.alice) | 18:27 |
| bswartz | perhaps the difference is that you could choose to share some IDs but not others in that case | 18:27 |
| bswartz | okay I see what you mean | 18:28 |
| *** pcaruana has joined #openstack-manila | 18:29 | |
| jcsp | at the risk of complicating things further, it's probably worth mentioning that we anticipate the consumer of the Manila auth API ultimately being Nova. When someone asks nova to attach a cephfs share to a guest, Nova would generate an attachment ID, and then pass that ID as the key name when authorizing it for the Manila share | 18:30 |
| jcsp | the Nova FS attachment spec isn't going in Newton, but work is ongoing on it anyway (as is work on the lower layers including libvirt, so that we can have domain <filesystem> tags that actually attach cephfs to guests) | 18:31 |
| *** tpsilva has joined #openstack-manila | 18:31 | |
| jcsp | nobody had fundamental issues with our Nova API, but they weren't willing to move forward with the spec until more of the other dependencies had landed the needed patches | 18:32 |
| jcsp | (7 layers in this stack, fun times) | 18:32 |
| bswartz | that doesn't complicate things at all | 18:39 |
| bswartz | it's sad that the large number of pieces and their dependencies will take a long time to all finally land | 18:40 |
| bswartz | but quality software can't be rushed | 18:40 |
| *** lpetrut has joined #openstack-manila | 18:41 | |
| *** krotscheck has quit IRC | 18:42 | |
| *** krotscheck_ has joined #openstack-manila | 18:42 | |
| *** krotscheck_ is now known as krotscheck | 18:44 | |
| tellesnobrega | dustins, hey, quick question, generic share backend supports the usage of share servers? | 18:51 |
| dustins | tellesnobrega: It will support either mode, either DHSS True or False | 18:51 |
| tellesnobrega | DHSS == driver handles share servers, correct? | 18:52 |
| dustins | You just have to specify in the manila.conf in the driver configuration stanza either "driver_handles_share_servers=True/False" | 18:52 |
| dustins | tellesnobrega: You got it! | 18:53 |
| tellesnobrega | cool | 18:53 |
| dustins | tellesnobrega: If you find anything lacking with any docs or such, let gouthamr and I know | 18:53 |
| tellesnobrega | dustins, sure, will do :) | 18:54 |
| dustins | we're trying to make it all better for new and existing contributors alike :D | 18:54 |
| tellesnobrega | dustins awesome | 18:54 |
| tellesnobrega | dustins, found something weird on devstack deploy | 18:56 |
| dustins | tellesnobrega: What's up? | 18:56 |
| tellesnobrega | i looked /etc/manila/manila.conf | 18:57 |
| tellesnobrega | and in the generic section is points ids of admin_network_id and admin_subnet_id | 18:57 |
| dustins | Yup | 18:58 |
| tellesnobrega | but the weird thing is the admin_network_id I can see when I run openstack subnet list | 18:58 |
| tellesnobrega | nevermind | 18:58 |
| tellesnobrega | my bad :) | 18:58 |
| tellesnobrega | looking on the wrong place | 18:58 |
| tellesnobrega | looks good | 18:59 |
| dustins | haha, no worries | 18:59 |
| dustins | Those should correspond to the Neutron network/subnet that the generic driver uses for talking to its helper VM | 18:59 |
| dustins | (IIRC) | 18:59 |
| tellesnobrega | hmm | 19:00 |
| *** timcl has joined #openstack-manila | 19:01 | |
| tellesnobrega | dustins, maybe something to improve on the docs is to move the other components cli commands to the new openstack cli commands | 19:05 |
| dustins | tellesnobrega: You mean to have the keystone/nova/neutron/etc commands "ported" to the openstack unified client? | 19:06 |
| tellesnobrega | yes | 19:06 |
| dustins | bswartz: Do we have a plan for adding our stuff to the openstack unified client? | 19:07 |
| dustins | The docs updates for the other projects would be fairly easy if we wanted to do that | 19:08 |
| tellesnobrega | that is something that I could start doing in manila | 19:08 |
| dustins | You'll get no complaints from me :) | 19:09 |
| tellesnobrega | If we don't have any cons, it would be something cool to start on | 19:09 |
| dustins | tellesnobrega: I say give it hell | 19:11 |
| dustins | Go for it! | 19:11 |
| tellesnobrega | cool :) | 19:11 |
| dustins | And let me know if I can help in any way | 19:11 |
| ganso | bswartz: backports https://review.openstack.org/#/c/325874/ and https://review.openstack.org/#/c/325871 are ready for workflowing | 19:19 |
| tellesnobrega | dustins, does manila communicate with keystone using Keystone API v3? | 19:21 |
| dustins | tellesnobrega: Good question, I have no clue | 19:22 |
| dustins | I would assume so | 19:22 |
| tellesnobrega | ganso, do you know this? ^ | 19:22 |
| *** timcl has quit IRC | 19:23 | |
| ganso | tellesnobrega: my current devstack setup uses v2.0 | 19:23 |
| ganso | tellesnobrega: I remember seeing a while ago some patches to fix CI when devstack started using keystone v3 | 19:23 |
| ganso | tellesnobrega: but I am not sure if manila is supporting it | 19:24 |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila: Add user_id and project_id to snapshot APIs https://review.openstack.org/323547 | 19:24 |
| tellesnobrega | ganso, dustins It may be interesting to see how is the v3 integration status, keystone has done major efforts to move to v3 this last cycle and they are going to continue to do so. All projects should move to v3 | 19:24 |
| tellesnobrega | this might be interesting to work on this cycle if we have time | 19:25 |
| ganso | tellesnobrega: indeed | 19:25 |
| dustins | tellesnobrega: Indeed, | 19:25 |
| * dustins thinks we might need some more specs | 19:25 | |
| dustins | :) | 19:25 |
| gouthamr | ganso dustins tellesnobrega: we've supported keystone v3 since liberty | 19:25 |
| gouthamr | iirc | 19:26 |
| tellesnobrega | gouthamr, awesome :) | 19:26 |
| dustins | gouthamr: Good to know! | 19:26 |
| tellesnobrega | gouthamr, if keystone dropped v2 now, would manila work properly still? I guess this is the major question | 19:27 |
| gouthamr | tellesnobrega: we run with v3 default in the gate.. | 19:27 |
| gouthamr | tellesnobrega: https://github.com/openstack/manila/blob/210cda/contrib/ci/pre_test_hook.sh#L31 | 19:27 |
| ganso | gouthamr: for some reason, every time I set up my devstack, it is set to run v2 o_O | 19:36 |
| ganso | gouthamr: I guess it does not run any of those hooks | 19:37 |
| gouthamr | ganso: yep.. mine too, the question reminded me of a discussion a long time ago, so i code searched to realize it's in the CI hook :) | 19:38 |
| tellesnobrega | nice gouthamr, that is one less thing to worry about | 19:38 |
| gouthamr | tellesnobrega: yep.. | 19:40 |
| *** lpetrut has quit IRC | 19:41 | |
| gouthamr | tellesnobrega: regarding the openstackclient: https://review.openstack.org/#/c/301150/ <-- was put up a while ago.. but i'm not sure that's being actively worked on. | 19:42 |
| gouthamr | dustins ^ | 19:42 |
| *** lpetrut has joined #openstack-manila | 19:43 | |
| dustins | Hmm, looks like it hasn't seen anything in two months | 19:48 |
| *** sgotliv has quit IRC | 19:48 | |
| *** eharney has quit IRC | 19:49 | |
| *** mtanino has quit IRC | 19:52 | |
| *** openstackstatus has quit IRC | 19:55 | |
| *** mtanino has joined #openstack-manila | 19:56 | |
| *** openstackstatus has joined #openstack-manila | 19:57 | |
| *** ChanServ sets mode: +v openstackstatus | 19:57 | |
| *** timcl has joined #openstack-manila | 19:58 | |
| *** timcl1 has joined #openstack-manila | 19:58 | |
| *** timcl has quit IRC | 20:03 | |
| *** dsariel has quit IRC | 20:07 | |
| tellesnobrega | gouthamr, nice, i will take a look and see if i can bring it back to life | 20:08 |
| gouthamr | tellesnobrega: +1 happy to help. | 20:08 |
| tellesnobrega | gouthamr, thanks | 20:08 |
| *** merooney has quit IRC | 20:09 | |
| *** lpetrut has quit IRC | 20:10 | |
| tellesnobrega | gouthamr, I'm Telles by the way, work for red hat, starting just now to work with manila | 20:10 |
| gouthamr | tellesnobrega: nice! great stuff Telles.. I'm Goutham. Always happy to see new contributors in manila.. would be happy to help you get up to speed! :) | 20:13 |
| tellesnobrega | thanks gouthamr, I will ping when I need assistance | 20:14 |
| *** porrua has quit IRC | 20:14 | |
| gouthamr | tellesnobrega: sure thing.. | 20:14 |
| tellesnobrega | what is the purpose of the manila image that is available with devstack? | 20:26 |
| dustins | tellesnobrega: The manila-service-image? | 20:26 |
| tellesnobrega | yes | 20:26 |
| dustins | tellesnobrega: it is an Ubuntu 12.04 image that is spun up to provide NAS mount points from the Generic Driver | 20:27 |
| *** alyson_ has quit IRC | 20:28 | |
| dustins | The generic driver uses Nova to create an instance that allows the sharing of Cinder Volumes as Manila Shares | 20:28 |
| dustins | (not confusing at all) :P | 20:28 |
| tellesnobrega | dustins, I see, but i can create an instance with any other images (including cirros?) to attach the share to it correct? | 20:28 |
| dustins | Right, the service-image is purely for the generic driver to provide the shares | 20:29 |
| tellesnobrega | ok | 20:29 |
| dustins | You can mount the shares with any instance that can mount an NFS/CIFS/etc share | 20:29 |
| tellesnobrega | thanks dustins | 20:37 |
| *** timcl has joined #openstack-manila | 20:38 | |
| *** timcl1 has quit IRC | 20:40 | |
| *** cknight has quit IRC | 20:46 | |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs: Add spec for Share Retype https://review.openstack.org/315708 | 20:47 |
| *** dsariel has joined #openstack-manila | 20:52 | |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs: Add spec for Share Migration Newton improvements https://review.openstack.org/315707 | 20:58 |
| *** timcl has quit IRC | 21:03 | |
| *** akshai has quit IRC | 21:05 | |
| *** dustins has quit IRC | 21:06 | |
| *** pcaruana has quit IRC | 21:08 | |
| *** eharney has joined #openstack-manila | 21:13 | |
| *** cknight has joined #openstack-manila | 21:17 | |
| *** FL1SK has quit IRC | 21:18 | |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila-specs: Extend the design of share networks to span subnets https://review.openstack.org/323646 | 21:21 |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila-specs: Extend the design of share networks to span subnets https://review.openstack.org/323646 | 21:22 |
| *** gouthamr has quit IRC | 21:27 | |
| *** dsariel has quit IRC | 21:33 | |
| *** absubram has quit IRC | 21:40 | |
| *** catintheroof has quit IRC | 21:46 | |
| *** JoseMello has quit IRC | 21:49 | |
| *** xyang1 has quit IRC | 21:51 | |
| *** FL1SK has joined #openstack-manila | 22:11 | |
| *** jay-mehta has joined #openstack-manila | 22:13 | |
| *** absubram has joined #openstack-manila | 22:41 | |
| *** gouthamr has joined #openstack-manila | 22:54 | |
| *** FL1SK has quit IRC | 22:58 | |
| *** harlowja has quit IRC | 23:01 | |
| *** cknight has quit IRC | 23:09 | |
| *** FL1SK has joined #openstack-manila | 23:15 | |
| *** tpsilva has quit IRC | 23:37 | |
| *** FL1SK has quit IRC | 23:44 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!