Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone
On the ceilometer integration front, I think that, over the course of Icehouse, the proposed Ironic driver API for gathering metrics was fleshed out and agreed upon internally. I am hoping that work can be completed early in Juno, at which point we'll be looking to Ceilometer to start consuming it. On the where does Ironic store credentials front, yes, I think we do need to talk at the summit about that. It might not warrant a whole session, but it seems like we need to chat with Keystone and Barbican to figure out the right place and format for secure hardware/BMC credential storage. I'm still leaning heavily towards this being natively inside Ironic to preserve the layer separation; otoh, if it is reasonable for operators to run a private keystone and a public keystone (or private/public barbican), then it may be reasonable to put the BMC credentials in there... Regards, Devananda On Wed, Mar 26, 2014 at 1:25 PM, Eoghan Glynn egl...@redhat.com wrote: I haven't gotten to my email back log yet, but want to point out that I agree with everything Robert just said. I also raised these concerns on the original ceilometer BP, which is what gave rise to all the work in ironic that Haomeng has been doing (on the linked ironic BP) to expose these metrics for ceilometer to consume. Thanks Devananda, so it seems like closing out the ironic work started in the icehouse BP[1] is the way to go, while on the ceilometer side we can look into consuming these notifications. If Haomeng needs further input from the ceilometer side, please shout. And if there are some non-trivial cross-cutting issues to discuss, perhaps we could consider having another joint session at the Juno summit? Cheers, Eoghan [1] https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer Typing quickly on a mobile, Deva On Mar 26, 2014 11:34 AM, Robert Collins robe...@robertcollins.net wrote: On 27 March 2014 06:28, Eoghan Glynn egl...@redhat.com wrote: On 3/25/2014 1:50 PM, Matt Wagner wrote: This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store is pluggable. Fetch these bare metal statistics doesn't seem too off-course for Ironic to me. The alternative is that Ceilometer and Ironic would both have to be configured for the same pluggable credential store. There is already a blueprint with a proposed patch here for Ironic to do the querying: https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer. Yes, so I guess there are two fundamentally different approaches that could be taken here: 1. ironic controls the cadence of IPMI polling, emitting notifications at whatever frequency it decides, carrying whatever level of detail/formatting it deems appropriate, which are then consumed by ceilometer which massages these provided data into usable samples 2. ceilometer acquires the IPMI credentials either via ironic or directly from keystone/barbican, before calling out over IPMI at whatever cadence it wants and transforming these raw data into usable samples IIUC approach #1 is envisaged by the ironic BP[1]. The advantage of approach #2 OTOH is that ceilometer is in the driving seat as far as cadence is concerned, and the model is far more consistent with how we currently acquire data from the hypervisor layer and SNMP daemons. The downsides of #2 are: - more machines require access to IPMI on the servers (if a given ceilometer is part of the deployed cloud, not part of the minimal deployment infrastructure). This sets of security red flags in some organisations. - multiple machines (ceilometer *and* Ironic) talking to the same IPMI device. IPMI has a limit on sessions, and in fact the controllers are notoriously buggy - having multiple machines talking to one IPMI device is a great way to exceed session limits and cause lockups. These seem fundamental showstoppers to me. -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 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] [Ironic][Keystone] Move drivers credentials to Keystone
On 3/25/2014 1:50 PM, Matt Wagner wrote: This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store is pluggable. Fetch these bare metal statistics doesn't seem too off-course for Ironic to me. The alternative is that Ceilometer and Ironic would both have to be configured for the same pluggable credential store. There is already a blueprint with a proposed patch here for Ironic to do the querying: https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer. Yes, so I guess there are two fundamentally different approaches that could be taken here: 1. ironic controls the cadence of IPMI polling, emitting notifications at whatever frequency it decides, carrying whatever level of detail/formatting it deems appropriate, which are then consumed by ceilometer which massages these provided data into usable samples 2. ceilometer acquires the IPMI credentials either via ironic or directly from keystone/barbican, before calling out over IPMI at whatever cadence it wants and transforming these raw data into usable samples IIUC approach #1 is envisaged by the ironic BP[1]. The advantage of approach #2 OTOH is that ceilometer is in the driving seat as far as cadence is concerned, and the model is far more consistent with how we currently acquire data from the hypervisor layer and SNMP daemons. Cheers, Eoghan [1] https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer I think, for terms of credential storage (and, for that matter, metrics gathering as I noted in that blueprint), it's very useful to have things pluggable. Ironic, in particular, has many different use cases: bare metal private cloud, bare metal public cloud, and triple-o. I could easily see all three being different enough to call for different forms of credential storage. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone
Comments inline. On 3/26/14, 10:28 AM, Eoghan Glynn wrote: On 3/25/2014 1:50 PM, Matt Wagner wrote: This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store is pluggable. Fetch these bare metal statistics doesn't seem too off-course for Ironic to me. The alternative is that Ceilometer and Ironic would both have to be configured for the same pluggable credential store. There is already a blueprint with a proposed patch here for Ironic to do the querying: https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer. Yes, so I guess there are two fundamentally different approaches that could be taken here: 1. ironic controls the cadence of IPMI polling, emitting notifications at whatever frequency it decides, carrying whatever level of detail/formatting it deems appropriate, which are then consumed by ceilometer which massages these provided data into usable samples 2. ceilometer acquires the IPMI credentials either via ironic or directly from keystone/barbican, before calling out over IPMI at whatever cadence it wants and transforming these raw data into usable samples IIUC approach #1 is envisaged by the ironic BP[1]. The advantage of approach #2 OTOH is that ceilometer is in the driving seat as far as cadence is concerned, and the model is far more consistent with how we currently acquire data from the hypervisor layer and SNMP daemons. Approach #1 permits there to be possible other systems monitoring this information. Many organizations already have significant hardware monitoring systems setup, and would not like to replace them with Ceilometer in order to monitor BMCs registered with Ironic. I think, especially for Ironic, being able to play nicely with things outside of Openstack is essential as most users aren't going to replace their entire datacenter management toolset with Openstack... at least not yet :). Thanks, Jay Cheers, Eoghan [1] https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer I think, for terms of credential storage (and, for that matter, metrics gathering as I noted in that blueprint), it's very useful to have things pluggable. Ironic, in particular, has many different use cases: bare metal private cloud, bare metal public cloud, and triple-o. I could easily see all three being different enough to call for different forms of credential storage. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone
I haven't gotten to my email back log yet, but want to point out that I agree with everything Robert just said. I also raised these concerns on the original ceilometer BP, which is what gave rise to all the work in ironic that Haomeng has been doing (on the linked ironic BP) to expose these metrics for ceilometer to consume. Typing quickly on a mobile, Deva On Mar 26, 2014 11:34 AM, Robert Collins robe...@robertcollins.net wrote: On 27 March 2014 06:28, Eoghan Glynn egl...@redhat.com wrote: On 3/25/2014 1:50 PM, Matt Wagner wrote: This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store is pluggable. Fetch these bare metal statistics doesn't seem too off-course for Ironic to me. The alternative is that Ceilometer and Ironic would both have to be configured for the same pluggable credential store. There is already a blueprint with a proposed patch here for Ironic to do the querying: https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer. Yes, so I guess there are two fundamentally different approaches that could be taken here: 1. ironic controls the cadence of IPMI polling, emitting notifications at whatever frequency it decides, carrying whatever level of detail/formatting it deems appropriate, which are then consumed by ceilometer which massages these provided data into usable samples 2. ceilometer acquires the IPMI credentials either via ironic or directly from keystone/barbican, before calling out over IPMI at whatever cadence it wants and transforming these raw data into usable samples IIUC approach #1 is envisaged by the ironic BP[1]. The advantage of approach #2 OTOH is that ceilometer is in the driving seat as far as cadence is concerned, and the model is far more consistent with how we currently acquire data from the hypervisor layer and SNMP daemons. The downsides of #2 are: - more machines require access to IPMI on the servers (if a given ceilometer is part of the deployed cloud, not part of the minimal deployment infrastructure). This sets of security red flags in some organisations. - multiple machines (ceilometer *and* Ironic) talking to the same IPMI device. IPMI has a limit on sessions, and in fact the controllers are notoriously buggy - having multiple machines talking to one IPMI device is a great way to exceed session limits and cause lockups. These seem fundamental showstoppers to me. -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] [Ironic][Keystone] Move drivers credentials to Keystone
- Original Message - On 27 March 2014 06:28, Eoghan Glynn egl...@redhat.com wrote: On 3/25/2014 1:50 PM, Matt Wagner wrote: This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store is pluggable. Fetch these bare metal statistics doesn't seem too off-course for Ironic to me. The alternative is that Ceilometer and Ironic would both have to be configured for the same pluggable credential store. There is already a blueprint with a proposed patch here for Ironic to do the querying: https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer. Yes, so I guess there are two fundamentally different approaches that could be taken here: 1. ironic controls the cadence of IPMI polling, emitting notifications at whatever frequency it decides, carrying whatever level of detail/formatting it deems appropriate, which are then consumed by ceilometer which massages these provided data into usable samples 2. ceilometer acquires the IPMI credentials either via ironic or directly from keystone/barbican, before calling out over IPMI at whatever cadence it wants and transforming these raw data into usable samples IIUC approach #1 is envisaged by the ironic BP[1]. The advantage of approach #2 OTOH is that ceilometer is in the driving seat as far as cadence is concerned, and the model is far more consistent with how we currently acquire data from the hypervisor layer and SNMP daemons. The downsides of #2 are: - more machines require access to IPMI on the servers (if a given ceilometer is part of the deployed cloud, not part of the minimal deployment infrastructure). This sets of security red flags in some organisations. - multiple machines (ceilometer *and* Ironic) talking to the same IPMI device. IPMI has a limit on sessions, and in fact the controllers are notoriously buggy - having multiple machines talking to one IPMI device is a great way to exceed session limits and cause lockups. These seem fundamental showstoppers to me. Thanks Robert, that's really useful information, and I agree a compelling argument to invert control in this case. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone
Also, some systems have more sophisticated IPMI topology than a single node instance, like in case of chassis-based systems. Some other systems might use vendor-specific IPMI extensions or alternate platform management protocols, that could require vendor-specific drivers to terminate. Going for #2 might require Ceilometer to implement vendor-specific drivers at the end, slightly overlapping what Ironic is doing today. Just from pure architectural point of view, having a single driver is very preferrable. Regards, Gergely On Wed, Mar 26, 2014 at 8:02 PM, Devananda van der Veen devananda@gmail.com wrote: I haven't gotten to my email back log yet, but want to point out that I agree with everything Robert just said. I also raised these concerns on the original ceilometer BP, which is what gave rise to all the work in ironic that Haomeng has been doing (on the linked ironic BP) to expose these metrics for ceilometer to consume. Typing quickly on a mobile, Deva On Mar 26, 2014 11:34 AM, Robert Collins robe...@robertcollins.net wrote: On 27 March 2014 06:28, Eoghan Glynn egl...@redhat.com wrote: On 3/25/2014 1:50 PM, Matt Wagner wrote: This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store is pluggable. Fetch these bare metal statistics doesn't seem too off-course for Ironic to me. The alternative is that Ceilometer and Ironic would both have to be configured for the same pluggable credential store. There is already a blueprint with a proposed patch here for Ironic to do the querying: https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer. Yes, so I guess there are two fundamentally different approaches that could be taken here: 1. ironic controls the cadence of IPMI polling, emitting notifications at whatever frequency it decides, carrying whatever level of detail/formatting it deems appropriate, which are then consumed by ceilometer which massages these provided data into usable samples 2. ceilometer acquires the IPMI credentials either via ironic or directly from keystone/barbican, before calling out over IPMI at whatever cadence it wants and transforming these raw data into usable samples IIUC approach #1 is envisaged by the ironic BP[1]. The advantage of approach #2 OTOH is that ceilometer is in the driving seat as far as cadence is concerned, and the model is far more consistent with how we currently acquire data from the hypervisor layer and SNMP daemons. The downsides of #2 are: - more machines require access to IPMI on the servers (if a given ceilometer is part of the deployed cloud, not part of the minimal deployment infrastructure). This sets of security red flags in some organisations. - multiple machines (ceilometer *and* Ironic) talking to the same IPMI device. IPMI has a limit on sessions, and in fact the controllers are notoriously buggy - having multiple machines talking to one IPMI device is a great way to exceed session limits and cause lockups. These seem fundamental showstoppers to me. -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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone
I haven't gotten to my email back log yet, but want to point out that I agree with everything Robert just said. I also raised these concerns on the original ceilometer BP, which is what gave rise to all the work in ironic that Haomeng has been doing (on the linked ironic BP) to expose these metrics for ceilometer to consume. Thanks Devananda, so it seems like closing out the ironic work started in the icehouse BP[1] is the way to go, while on the ceilometer side we can look into consuming these notifications. If Haomeng needs further input from the ceilometer side, please shout. And if there are some non-trivial cross-cutting issues to discuss, perhaps we could consider having another joint session at the Juno summit? Cheers, Eoghan [1] https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer Typing quickly on a mobile, Deva On Mar 26, 2014 11:34 AM, Robert Collins robe...@robertcollins.net wrote: On 27 March 2014 06:28, Eoghan Glynn egl...@redhat.com wrote: On 3/25/2014 1:50 PM, Matt Wagner wrote: This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store is pluggable. Fetch these bare metal statistics doesn't seem too off-course for Ironic to me. The alternative is that Ceilometer and Ironic would both have to be configured for the same pluggable credential store. There is already a blueprint with a proposed patch here for Ironic to do the querying: https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer . Yes, so I guess there are two fundamentally different approaches that could be taken here: 1. ironic controls the cadence of IPMI polling, emitting notifications at whatever frequency it decides, carrying whatever level of detail/formatting it deems appropriate, which are then consumed by ceilometer which massages these provided data into usable samples 2. ceilometer acquires the IPMI credentials either via ironic or directly from keystone/barbican, before calling out over IPMI at whatever cadence it wants and transforming these raw data into usable samples IIUC approach #1 is envisaged by the ironic BP[1]. The advantage of approach #2 OTOH is that ceilometer is in the driving seat as far as cadence is concerned, and the model is far more consistent with how we currently acquire data from the hypervisor layer and SNMP daemons. The downsides of #2 are: - more machines require access to IPMI on the servers (if a given ceilometer is part of the deployed cloud, not part of the minimal deployment infrastructure). This sets of security red flags in some organisations. - multiple machines (ceilometer *and* Ironic) talking to the same IPMI device. IPMI has a limit on sessions, and in fact the controllers are notoriously buggy - having multiple machines talking to one IPMI device is a great way to exceed session limits and cause lockups. These seem fundamental showstoppers to me. -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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone
Hi, Right now Ironic is being responsible for storing the credentials for the IPMI and SSH drivers (and potentially other drivers in the future), I wonder if we should delegate this task to Keystone. The Keystone V3 API now has a /credentials endpoint which would allow us to specify arbitrary types (not only ec2 anymore) and use it as a credential store[1]. That would avoid further fragmentation of credentials being stored in different places in OpenStack, and make the management of the credentials easier (Think about a situation where many nodes share the same IPMI username/password and we need to update it, if this is stored in Keystone it only needs to be updated there once cause nodes will only hold a reference to it) It also was pointed to me that setting a hard dependency on Keystone V3 might significantly raises the bar for integration with existing clouds*. So perhaps we should make it optional? In the same way we can specify a username/password or key_filename for the ssh driver we could have a reference to a credential in Keystone V3? What you guys think about the idea? Hi Lucas, At a high level, this sounds like an excellent idea to me. IIUC the major blocker to ceilometer taking point on controlling the IPMI polling cycle has been secure access to these credentials. If these were available to ceilometer in a controlled way via keystone, then the IPMI polling cycle could be managed in a very similar way to the ceilo polling activity on the hypervisor and SMNP daemons. However, I'm a little fuzzy on the detail of enabling this via keystone v3, so it would be great to drill down into the detail either on the ML or at summit. For example, would it be in the guise of a trust that delegates limited privilege to allow the ceilometer user call GET /credentials to retrieve the IPMI user/pass? Or would the project_id parameter to POST /credentials suffice to limit access to IPMI credentials to the ceilometer tenant only? (as opposed to allowing any other openstack service access these creds) In that case, would we need to also decouple the ceilometer user from the generic service tenant? Cheers, Eoghan What are the cloud operators/sysadmins view on that? * There's also some ongoing thoughts about using v3 for other things in Ironic (e.g signed url's) but that's kinda out of the topic. [1] https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#create-credential-post-credentials Ironic bp (discussion): https://blueprints.launchpad.net/ironic/+spec/credentials-keystone-v3 ___ 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] [Ironic][Keystone] Move drivers credentials to Keystone
On Tue, 2014-03-25 at 12:23 +, Lucas Alvares Gomes wrote: Hi, Right now Ironic is being responsible for storing the credentials for the IPMI and SSH drivers (and potentially other drivers in the future), I wonder if we should delegate this task to Keystone. The Keystone V3 API now has a /credentials endpoint which would allow us to specify arbitrary types (not only ec2 anymore) and use it as a credential store[1]. That would avoid further fragmentation of credentials being stored in different places in OpenStack, and make the management of the credentials easier (Think about a situation where many nodes share the same IPMI username/password and we need to update it, if this is stored in Keystone it only needs to be updated there once cause nodes will only hold a reference to it) It also was pointed to me that setting a hard dependency on Keystone V3 might significantly raises the bar for integration with existing clouds*. So perhaps we should make it optional? In the same way we can specify a username/password or key_filename for the ssh driver we could have a reference to a credential in Keystone V3? I think the idea of using Keystone for keypair management in Nova is a good one. There is already precedent in Nova for doing this kind of thing ... it's already been done for images, volumes, and network. One problem with the Keystone v3 credentials API, though, is that it does not have support for unique names of keypairs per project, as that is how the Nova API /keypairs resource endpoint works. What you guys think about the idea? What are the cloud operators/sysadmins view on that? As long as the functionality was enabled using the standard driver-based setup (as was done for glance, nova, cinder, and neutron integration), I don't see any issues for deployers. Of course, you'd need a migration script, but that's not a huge deal. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone
Why not use Barbican? It stores credentials after encrypting them. -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Tuesday, March 25, 2014 9:50 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone On Tue, 2014-03-25 at 12:23 +, Lucas Alvares Gomes wrote: Hi, Right now Ironic is being responsible for storing the credentials for the IPMI and SSH drivers (and potentially other drivers in the future), I wonder if we should delegate this task to Keystone. The Keystone V3 API now has a /credentials endpoint which would allow us to specify arbitrary types (not only ec2 anymore) and use it as a credential store[1]. That would avoid further fragmentation of credentials being stored in different places in OpenStack, and make the management of the credentials easier (Think about a situation where many nodes share the same IPMI username/password and we need to update it, if this is stored in Keystone it only needs to be updated there once cause nodes will only hold a reference to it) It also was pointed to me that setting a hard dependency on Keystone V3 might significantly raises the bar for integration with existing clouds*. So perhaps we should make it optional? In the same way we can specify a username/password or key_filename for the ssh driver we could have a reference to a credential in Keystone V3? I think the idea of using Keystone for keypair management in Nova is a good one. There is already precedent in Nova for doing this kind of thing ... it's already been done for images, volumes, and network. One problem with the Keystone v3 credentials API, though, is that it does not have support for unique names of keypairs per project, as that is how the Nova API /keypairs resource endpoint works. What you guys think about the idea? What are the cloud operators/sysadmins view on that? As long as the functionality was enabled using the standard driver-based setup (as was done for glance, nova, cinder, and neutron integration), I don't see any issues for deployers. Of course, you'd need a migration script, but that's not a huge deal. Best, -jay ___ 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] [Ironic][Keystone] Move drivers credentials to Keystone
On Tue, 2014-03-25 at 17:39 +, Miller, Mark M (EB SW Cloud - RD - Corvallis) wrote: Why not use Barbican? It stores credentials after encrypting them. No reason not to add a Barbican driver as well. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone
Yes, this is exactly the use case we’re trying to address with Barbican. I think this is something that definitely belongs in Barbican, especially now that we are an incubated project. We’d love to help out with any integration questions you may have. -Doug Mendizabal On 3/25/14, 12:49 PM, Jay Pipes jaypi...@gmail.com wrote: On Tue, 2014-03-25 at 17:39 +, Miller, Mark M (EB SW Cloud - RD - Corvallis) wrote: Why not use Barbican? It stores credentials after encrypting them. No reason not to add a Barbican driver as well. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone
On Tue, Mar 25, 2014 at 12:49 PM, Jay Pipes jaypi...@gmail.com wrote: On Tue, 2014-03-25 at 17:39 +, Miller, Mark M (EB SW Cloud - RD - Corvallis) wrote: Why not use Barbican? It stores credentials after encrypting them. No reason not to add a Barbican driver as well. If Keystone's /v3/credentials API has any legs, it should be backed by barbican, if not superseded by it completely. Best, -jay ___ 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] [Ironic][Keystone] Move drivers credentials to Keystone
On 25/03/14 12:23 +, Lucas Alvares Gomes wrote: Hi, Right now Ironic is being responsible for storing the credentials for the IPMI and SSH drivers (and potentially other drivers in the future), I wonder if we should delegate this task to Keystone. The Keystone V3 API now has a /credentials endpoint which would allow us to specify arbitrary types (not only ec2 anymore) and use it as a credential store[1]. That would avoid further fragmentation of credentials being stored in different places in OpenStack, and make the management of the credentials easier (Think about a situation where many nodes share the same IPMI username/password and we need to update it, if this is stored in Keystone it only needs to be updated there once cause nodes will only hold a reference to it) It also was pointed to me that setting a hard dependency on Keystone V3 might significantly raises the bar for integration with existing clouds*. So perhaps we should make it optional? In the same way we can specify a username/password or key_filename for the ssh driver we could have a reference to a credential in Keystone V3? As others seem to be saying, I think it might make sense to make this pluggable. Store it in driver metadata, or store it in Keystone, or store it in Barbican. Of course, that's 3x the effort. As a relative newcomer -- is it problematic for us to leverage an incubated service? I suppose that a pluggable approach with Barbican as one option would alleviate any problems that might exist. This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store is pluggable. Fetch these bare metal statistics doesn't seem too off-course for Ironic to me. The alternative is that Ceilometer and Ironic would both have to be configured for the same pluggable credential store. Or am I crazy? -- Matt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone
On 3/25/2014 1:50 PM, Matt Wagner wrote: This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store is pluggable. Fetch these bare metal statistics doesn't seem too off-course for Ironic to me. The alternative is that Ceilometer and Ironic would both have to be configured for the same pluggable credential store. There is already a blueprint with a proposed patch here for Ironic to do the querying: https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer. I think, for terms of credential storage (and, for that matter, metrics gathering as I noted in that blueprint), it's very useful to have things pluggable. Ironic, in particular, has many different use cases: bare metal private cloud, bare metal public cloud, and triple-o. I could easily see all three being different enough to call for different forms of credential storage. -Jay Faulkner ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
