Re: [openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains by name - policy and API issues?
On Tue, Apr 29, 2014 at 1:25 AM, Robert Collins robe...@robertcollins.netwrote: On 29 April 2014 12:27, Dolph Mathews dolph.math...@gmail.com wrote: Sure: domain names are unambiguous but user mutable, whereas Heat's approach to using admin tenant name is at risk to both mutability and ambiguity (in a multi-domain deployment). Isn't domainname/user unambiguous and unique? Yes mutability is really not keystones choice. If keystone won't accept domainname/user then that will force us to either do two stack-updates for a single deploy (ugly) or write patches to heat (and neutron where the callback-to-nova support has the same issue) to manually try a lookup and work around this. Since its trivial to write such a thunk, what benefit is there to your users - e.g. TripleO/heat/nova not have it in keystone itself? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains by name - policy and API issues?
Excerpts from Robert Collins's message of 2014-04-28 23:25:02 -0700: On 29 April 2014 12:27, Dolph Mathews dolph.math...@gmail.com wrote: Sure: domain names are unambiguous but user mutable, whereas Heat's approach to using admin tenant name is at risk to both mutability and ambiguity (in a multi-domain deployment). Isn't domainname/user unambiguous and unique? mutability is really not keystones choice. If keystone won't accept domainname/user then that will force us to either do two stack-updates for a single deploy (ugly) or write patches to heat (and neutron where the callback-to-nova support has the same issue) to manually try a lookup and work around this. Since its trivial to write such a thunk, what benefit is there to your users - e.g. TripleO/heat/nova not have it in keystone itself? So it sounds like we can drive a change into Keystone. The short version is something like this: Anywhere that accepts a domain ID, should also be able to accept a domain name. Anywhere that accepts a user ID, should also be able to accept a domain name and user name. This sounds like it has several facets and so is spec-worthy. Anyone disagree? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains by name - policy and API issues?
On 29 April 2014 12:27, Dolph Mathews dolph.math...@gmail.com wrote: Sure: domain names are unambiguous but user mutable, whereas Heat's approach to using admin tenant name is at risk to both mutability and ambiguity (in a multi-domain deployment). Isn't domainname/user unambiguous and unique? mutability is really not keystones choice. If keystone won't accept domainname/user then that will force us to either do two stack-updates for a single deploy (ugly) or write patches to heat (and neutron where the callback-to-nova support has the same issue) to manually try a lookup and work around this. Since its trivial to write such a thunk, what benefit is there to your users - e.g. TripleO/heat/nova not have it in keystone itself? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains by name - policy and API issues?
In Keystone, users are assigned to a domain when they are created. This is a unique combination. -Original Message- From: Robert Collins [mailto:robe...@robertcollins.net] Sent: Monday, April 28, 2014 11:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains by name - policy and API issues? On 29 April 2014 12:27, Dolph Mathews dolph.math...@gmail.com wrote: Sure: domain names are unambiguous but user mutable, whereas Heat's approach to using admin tenant name is at risk to both mutability and ambiguity (in a multi-domain deployment). Isn't domainname/user unambiguous and unique? mutability is really not keystones choice. If keystone won't accept domainname/user then that will force us to either do two stack-updates for a single deploy (ugly) or write patches to heat (and neutron where the callback-to-nova support has the same issue) to manually try a lookup and work around this. Since its trivial to write such a thunk, what benefit is there to your users - e.g. TripleO/heat/nova not have it in keystone itself? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains by name - policy and API issues?
So in the process of making Heat deploy itself, I've run into a bit of a deadlock. https://bugs.launchpad.net/tripleo/+bug/1287453 https://bugs.launchpad.net/heat/+bug/1313003 Currently, we deploy OpenStack like this: * First we generate usernames/passwords for all service accounts * Next we deploy Keystone and Heat (and.. the rest of OpenStack) - In this process, we feed in the usernames and passwords we generated. * Then when everything is deployed, we initialize Keystone with the generated usernames and passwords via the keystone API. * Now we test to make sure what we deployed works. However, in order to create isolated users for narrow access to Heat from inside instances, Heat needs a domain to put these narrowly scoped users in. Heat has a handy script for creating this domain and an admin inside the domain which is needed to create the lesser users. So that naturally fits into our initialization of keystone. The problem is that because of bug 1313003, Heat can only use a domain ID to specify this domain. We haven't created that domain yet at stack creation time though, so we would have to add another step before testing/using the cloud: * Update stack with ID of heat stack user domain. Steven Hardy has indicated that it was problematic to make use of names instead of id's for domains, and that to me signals a problem with the API and/or policy model in Keystone around domains. Everything else in TripleO makes use of names except this, so I think we need to solve this. This isn't just a TripleO or Heat problem though, anybody using domains will run into the same trouble Steven hit, and that is not something we should ignore. Can somebody more familiar with domains explain what would be needed to be able to have Heat able to lookup domains by name and use them like most other things in OpenStack, where we can use names or IDs interchangeably? Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains by name - policy and API issues?
On Mon, Apr 28, 2014 at 12:51 PM, Clint Byrum cl...@fewbar.com wrote: So in the process of making Heat deploy itself, I've run into a bit of a deadlock. https://bugs.launchpad.net/tripleo/+bug/1287453 https://bugs.launchpad.net/heat/+bug/1313003 Currently, we deploy OpenStack like this: * First we generate usernames/passwords for all service accounts * Next we deploy Keystone and Heat (and.. the rest of OpenStack) - In this process, we feed in the usernames and passwords we generated. * Then when everything is deployed, we initialize Keystone with the generated usernames and passwords via the keystone API. * Now we test to make sure what we deployed works. However, in order to create isolated users for narrow access to Heat from inside instances, Heat needs a domain to put these narrowly scoped users in. Heat has a handy script for creating this domain and an admin inside the domain which is needed to create the lesser users. So that naturally fits into our initialization of keystone. The problem is that because of bug 1313003, Heat can only use a domain ID to specify this domain. I agree with Stephen's assessment in bug 1313003: https://bugs.launchpad.net/heat/+bug/1313003/comments/1 It's ultimately a user experience issue (it'd require two config options to properly express two different concepts). This issue isn't unique to heat, though. As Stephen points out, it's a set-once deployer option (not a user-facing one) - the IDs are intended exactly for this purpose. They're immutable, unambiguous identifiers. They're not particularly user-friendly, but as Stephen points out, they don't need to be. They just need to be reliable. We haven't created that domain yet at stack creation time though, so we would have to add another step before testing/using the cloud: * Update stack with ID of heat stack user domain. Steven Hardy has indicated that it was problematic to make use of names instead of id's for domains, and that to me signals a problem with the API and/or policy model in Keystone around domains. Everything else in TripleO makes use of names except this, so I think we need to solve this. This isn't just a TripleO or Heat problem though, anybody using domains will run into the same trouble Steven hit, and that is not something we should ignore. Can somebody more familiar with domains explain what would be needed to be able to have Heat able to lookup domains by name and use them like most other things in OpenStack, where we can use names or IDs interchangeably? Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains by name - policy and API issues?
Excerpts from Dolph Mathews's message of 2014-04-28 12:28:41 -0700: On Mon, Apr 28, 2014 at 12:51 PM, Clint Byrum cl...@fewbar.com wrote: So in the process of making Heat deploy itself, I've run into a bit of a deadlock. https://bugs.launchpad.net/tripleo/+bug/1287453 https://bugs.launchpad.net/heat/+bug/1313003 Currently, we deploy OpenStack like this: * First we generate usernames/passwords for all service accounts * Next we deploy Keystone and Heat (and.. the rest of OpenStack) - In this process, we feed in the usernames and passwords we generated. * Then when everything is deployed, we initialize Keystone with the generated usernames and passwords via the keystone API. * Now we test to make sure what we deployed works. However, in order to create isolated users for narrow access to Heat from inside instances, Heat needs a domain to put these narrowly scoped users in. Heat has a handy script for creating this domain and an admin inside the domain which is needed to create the lesser users. So that naturally fits into our initialization of keystone. The problem is that because of bug 1313003, Heat can only use a domain ID to specify this domain. I agree with Stephen's assessment in bug 1313003: https://bugs.launchpad.net/heat/+bug/1313003/comments/1 It's ultimately a user experience issue (it'd require two config options to properly express two different concepts). This issue isn't unique to heat, though. As Stephen points out, it's a set-once deployer option (not a user-facing one) - the IDs are intended exactly for this purpose. They're immutable, unambiguous identifiers. They're not particularly user-friendly, but as Stephen points out, they don't need to be. They just need to be reliable. In this instance, I, the deployer, am a Heat and Keystone user. So that is not a valid reason to dismiss this overly complicated user experience. If it is hard for me in TripleO, and hard for Steven in Heat, then it will be hard for everybody else who wants to consume keystone domains via the API. Could you contrast domains with the way that we can use names for every other keystone component? Notice: https://git.openstack.org/cgit/openstack/tripleo-image-elements/tree/elements/heat/os-config-applier/etc/heat/heat.conf#n522 If it has to be a different config option, that is fine, as long as they're not both required. But this is the only place that we've run into where we have to put an ID in the configuration for a service, rather than a name. Also, names are unambiguous. I requested that name specifically so I could use it for this purpose. If they're not unique enough to use for lookups, then I would love to hear an explanation as to why they cannot be made unique, at least in some context. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains by name - policy and API issues?
On Mon, Apr 28, 2014 at 2:48 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Dolph Mathews's message of 2014-04-28 12:28:41 -0700: On Mon, Apr 28, 2014 at 12:51 PM, Clint Byrum cl...@fewbar.com wrote: So in the process of making Heat deploy itself, I've run into a bit of a deadlock. https://bugs.launchpad.net/tripleo/+bug/1287453 https://bugs.launchpad.net/heat/+bug/1313003 Currently, we deploy OpenStack like this: * First we generate usernames/passwords for all service accounts * Next we deploy Keystone and Heat (and.. the rest of OpenStack) - In this process, we feed in the usernames and passwords we generated. * Then when everything is deployed, we initialize Keystone with the generated usernames and passwords via the keystone API. * Now we test to make sure what we deployed works. However, in order to create isolated users for narrow access to Heat from inside instances, Heat needs a domain to put these narrowly scoped users in. Heat has a handy script for creating this domain and an admin inside the domain which is needed to create the lesser users. So that naturally fits into our initialization of keystone. The problem is that because of bug 1313003, Heat can only use a domain ID to specify this domain. I agree with Stephen's assessment in bug 1313003: https://bugs.launchpad.net/heat/+bug/1313003/comments/1 It's ultimately a user experience issue (it'd require two config options to properly express two different concepts). This issue isn't unique to heat, though. As Stephen points out, it's a set-once deployer option (not a user-facing one) - the IDs are intended exactly for this purpose. They're immutable, unambiguous identifiers. They're not particularly user-friendly, but as Stephen points out, they don't need to be. They just need to be reliable. In this instance, I, the deployer, am a Heat and Keystone user. So that is not a valid reason to dismiss this overly complicated user experience. If it is hard for me in TripleO, and hard for Steven in Heat, then it will be hard for everybody else who wants to consume keystone domains via the API. I'd like to understand your notion of an overly complicated user experience better... power users want the ability to shoot themselves in the foot, and new users want a simplified experience that doesn't require any thought beyond copy/pasting, as they still need to focus on the big picture. In this specific instance, the power-user solution is to offer both configuration options, whereas Stephen has weighed the pros and cons and determined that the reliable copy/paste experience with IDs is the safest solution. If there's a reliable middleground we're not considering, I'd be interested to hear about it. Could you contrast domains with the way that we can use names for every other keystone component? Notice: https://git.openstack.org/cgit/openstack/tripleo-image-elements/tree/elements/heat/os-config-applier/etc/heat/heat.conf#n522 Sure: domain names are unambiguous but user mutable, whereas Heat's approach to using admin tenant name is at risk to both mutability and ambiguity (in a multi-domain deployment). If it has to be a different config option, that is fine, as long as they're not both required. ++ It should be domain name XOR domain ID, given that domain names are unambiguous. But this is the only place that we've run into where we have to put an ID in the configuration for a service, rather than a name. And Stephen explained his reasoning for this approach quite well. Also, names are unambiguous. Domain* names are unambiguous, as are role names (at the moment). User, group and project names are ambiguous in a multi-domain context. I requested that name specifically so I could use it for this purpose. If they're not unique enough to use for lookups, then I would love to hear an explanation as to why they cannot be made unique, at least in some context. They are unique enough for reliable lookups. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
