[openstack-dev] [Ironic] 'Chassis' element in Ironic
Dear All, In one of the Ironic IRC meetings, a discussion on whether to retain the 'Chassis' element in Ironic or not came up. I am interested to know whether this is still valid and a decision is to be made on whether the component is retained or not. Thanks, Sandhya __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ironic]
Hi All, I would like to discuss the Chassis Discovery Tool Blueprint - https://review.openstack.org/#/c/134866/ The blueprint suggests Hardware enrollment and introspection for properties at the Chassis layer. Suitable for micro-servers that have an active chassis to query for details. Initially, the idea was proposed as an API change at the Ironic layer. We found many complexities such as interaction with conductor and the point of nodes in a chassis being mapped to different conductors. So, decision was taken to keep it as a separate tool above the Ironic API layer. It is a generic tool that can be plugged in for specific hardware. There are different opinions from the community on this and it will be good to come to a consensus. I have also added the topic as an agenda in the Ironic IRC meeting. Thanks, Sandhya __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] disambiguating the term discovery
Hi All, Based on the discussions, I have filed a blue print that initiates discovery of node hardware details given its credentials at chassis level. I am in the process of creating a spec for it. Do share your thoughts regarding this - https://blueprints.launchpad.net/ironic/+spec/chassis-level-node-discovery Thanks, Sandhya. -Original Message- From: Dmitry Tantsur [mailto:dtant...@redhat.com] Sent: Thursday, November 13, 2014 2:20 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Ironic] disambiguating the term discovery On 11/12/2014 10:47 PM, Victor Lowther wrote: Hmmm... with this thread in mind, anyone think that changing DISCOVERING to INTROSPECTING in the new state machine spec is a good idea? As before I'm uncertain. Discovery is a troublesome term, but too many people use and recognize it, while IMO introspecting is much less common. So count me as -0 on this. On Mon, Nov 3, 2014 at 4:29 AM, Ganapathy, Sandhya sandhya.ganapa...@hp.com mailto:sandhya.ganapa...@hp.com wrote: Hi all, Following the mail thread on disambiguating the term 'discovery' - In the lines of what Devananda had stated, Hardware Introspection also means retrieving and storing hardware details of the node whose credentials and IP Address are known to the system. (Correct me if I am wrong). I am currently in the process of extracting hardware details (cpu, memory etc..) of n no. of nodes belonging to a Chassis whose credentials are already known to ironic. Does this process fall in the category of hardware introspection? Thanks, Sandhya. -Original Message- From: Devananda van der Veen [mailto:devananda@gmail.com mailto:devananda@gmail.com] Sent: Tuesday, October 21, 2014 5:41 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Ironic] disambiguating the term discovery Hi all, I was reminded in the Ironic meeting today that the words hardware discovery are overloaded and used in different ways by different people. Since this is something we are going to talk about at the summit (again), I'd like to start the discussion by building consensus in the language that we're going to use. So, I'm starting this thread to explain how I use those two words, and some other words that I use to mean something else which is what some people mean when they use those words. I'm not saying my words are the right words -- they're just the words that make sense to my brain right now. If someone else has better words, and those words also make sense (or make more sense) then I'm happy to use those instead. So, here are rough definitions for the terms I've been using for the last six months to disambiguate this: hardware discovery The process or act of identifying hitherto unknown hardware, which is addressable by the management system, in order to later make it available for provisioning and management. hardware introspection The process or act of gathering information about the properties or capabilities of hardware already known by the management system. Why is this disambiguation important? At the last midcycle, we agreed that hardware discovery is out of scope for Ironic -- finding new, unmanaged nodes and enrolling them with Ironic is best left to other services or processes, at least for the forseeable future. However, introspection is definitely within scope for Ironic. Even though we couldn't agree on the details during Juno, we are going to revisit this at the Kilo summit. This is an important feature for many of our current users, and multiple proof of concept implementations of this have been done by different parties over the last year. It may be entirely possible that no one else in our developer community is using the term introspection in the way that I've defined it above -- if so, that's fine, I can stop calling that introspection, but I don't know a better word for the thing that is find-unknown-hardware. Suggestions welcome, Devananda P.S. For what it's worth, googling for hardware discovery yields several results related to identifying unknown network-connected devices and adding them to inventory systems, which is the way that I'm using the term right now, so I don't feel completely off in continuing to say discovery when I mean find unknown network devices and add them to Ironic. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack
Re: [openstack-dev] [Ironic] disambiguating the term discovery
Hi all, Following the mail thread on disambiguating the term 'discovery' - In the lines of what Devananda had stated, Hardware Introspection also means retrieving and storing hardware details of the node whose credentials and IP Address are known to the system. (Correct me if I am wrong). I am currently in the process of extracting hardware details (cpu, memory etc..) of n no. of nodes belonging to a Chassis whose credentials are already known to ironic. Does this process fall in the category of hardware introspection? Thanks, Sandhya. -Original Message- From: Devananda van der Veen [mailto:devananda@gmail.com] Sent: Tuesday, October 21, 2014 5:41 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Ironic] disambiguating the term discovery Hi all, I was reminded in the Ironic meeting today that the words hardware discovery are overloaded and used in different ways by different people. Since this is something we are going to talk about at the summit (again), I'd like to start the discussion by building consensus in the language that we're going to use. So, I'm starting this thread to explain how I use those two words, and some other words that I use to mean something else which is what some people mean when they use those words. I'm not saying my words are the right words -- they're just the words that make sense to my brain right now. If someone else has better words, and those words also make sense (or make more sense) then I'm happy to use those instead. So, here are rough definitions for the terms I've been using for the last six months to disambiguate this: hardware discovery The process or act of identifying hitherto unknown hardware, which is addressable by the management system, in order to later make it available for provisioning and management. hardware introspection The process or act of gathering information about the properties or capabilities of hardware already known by the management system. Why is this disambiguation important? At the last midcycle, we agreed that hardware discovery is out of scope for Ironic -- finding new, unmanaged nodes and enrolling them with Ironic is best left to other services or processes, at least for the forseeable future. However, introspection is definitely within scope for Ironic. Even though we couldn't agree on the details during Juno, we are going to revisit this at the Kilo summit. This is an important feature for many of our current users, and multiple proof of concept implementations of this have been done by different parties over the last year. It may be entirely possible that no one else in our developer community is using the term introspection in the way that I've defined it above -- if so, that's fine, I can stop calling that introspection, but I don't know a better word for the thing that is find-unknown-hardware. Suggestions welcome, Devananda P.S. For what it's worth, googling for hardware discovery yields several results related to identifying unknown network-connected devices and adding them to inventory systems, which is the way that I'm using the term right now, so I don't feel completely off in continuing to say discovery when I mean find unknown network devices and add them to Ironic. ___ 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] [cinder] Bug#1231298 - size parameter for volume creation
Hi, This is to discuss Bug #1231298 - https://bugs.launchpad.net/cinder/+bug/1231298 Bug description : When one creates a volume from a snapshot or another volume, the size argument is calculated automatically. In the case of an image it needs to be specified though, for something larger than the image min_disk attribute. It would be nice to automatically get that size if it's not passed. That's is a behavior of Cinder API. Conclusion reached with this bug is that, we need to modify cinder client in order to accept optional size parameter (as the cinder's API allows) and calculate the size automatically during volume creation from image. There is also an opinion that size should not be an optional parameter during volume creation - does this mean, Cinder's API should be changed in order to make size a mandatory parameter. Which direction should I take to fix this bug? Thanks, Sandhya. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] Bug 1224972 When createing a volume from an image - nova leaves the volume name empty
Hi, I just need a suggestion to fix this bug. Link to the bug : https://bugs.launchpad.net/nova/+bug/1224972 This bug says that the name of the volume is not set when an instance is booted from a new volume giving image as the source. Fix for this bug could be at the Nova side wherein we append the name of the image as the volume name and call cinder api to create volume with it. Would the fix for this bug be better handled if it is done at the cinder level? If the request to create a volume comes without a name, a default (image or vol name from which it is created - this is how horizon behaves) name can be given as display name for volume creation. Thanks, Sandhya. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
