| rloo | Shrews: out of curiosity, what do the logs show you? Are we logging enough that you can figure out why it is locked? | 00:00 |
|---|---|---|
| lifeless | Shrews: on bare metal? | 00:00 |
| lifeless | Shrews: its the background power assert thread. | 00:00 |
| Shrews | rloo: i see nothing in the logs that is relevant | 00:00 |
| lifeless | Shrews: if you have a bad ilo that thread can lock a node for an extended time period | 00:00 |
| Shrews | lifeless: this is with the fake_ipmitool driver | 00:01 |
| rloo | Shrews: that isn't good. means it'll be hard for people to troubleshoot. | 00:01 |
| lifeless | Shrews: oh, huh. | 00:01 |
| rloo | Shrews: can you change the config setting to 'turn off' the periodic task. if you get NodeLocked, I might start to worry ;) | 00:01 |
| Shrews | rloo: good idea | 00:02 |
| Shrews | rloo: recall which setting it is? | 00:02 |
| rloo | sync_power_state_interval I think. set to 1 minute now. | 00:02 |
| rloo | set it to 100000 or something like that. I assume you're faster than that ;) | 00:02 |
| Shrews | oh, lookie there... | 00:04 |
| Shrews | output when I ctrl-C the conductor... | 00:05 |
| Shrews | 2014-06-18 20:02:19.054 3592 WARNING ironic.drivers.modules.ipmitool [-] IPMI power status failed for node 62474f5b-c07a-4bb1-84f5-dd3be095b799 with error: Unexpected error while running command. | 00:05 |
| Shrews | Command: ipmitool -I lanplus -H 1.2.3.4 -L ADMINISTRATOR -U admin -R 12 -N 5 -f /tmp/tmp6vemNu power status | 00:05 |
| Shrews | Exit code: 255 | 00:05 |
| Shrews | Stdout: '\nSIGN INT: Close Interface IPMI v2.0 RMCP+ LAN Interface\n' | 00:05 |
| Shrews | Stderr: 'Error: Unable to establish IPMI v2 / RMCP+ session\n'. | 00:05 |
| Shrews | oh, it's there on startup. scrolled by too quickly | 00:06 |
| Shrews | why is that being run with fake_ipmitool?? | 00:07 |
| Shrews | rloo: what is the output of 'git rev-parse HEAD' for you? | 00:08 |
| rloo | Shrews: ccf0950043775da941bb1bc0fd87e5106cd7b1ef | 00:09 |
| rloo | Shrews: looks like you found a bug! | 00:10 |
| Shrews | rloo: ??? that's o nthe master branch? | 00:10 |
| Shrews | i don't see that commit hash | 00:10 |
| rloo | Shrews: yeah. I did a pull recently. | 00:11 |
| rloo | Shrews: sorry wrong window. that was the client code. | 00:11 |
| rloo | Shrews: de8e5e1621ba0cead4bdb6edf97d75462d8b52d5 | 00:12 |
| Shrews | ok, me too. what the fudge is going on | 00:12 |
| rloo | Shrews: I can look (start a new dev env) tomorrow and try it out. I don't like looking into things like this in the evening cuz I don't want to work all night. | 00:13 |
| Shrews | rloo: ++ | 00:14 |
| Shrews | I'm the same way, though I know it's probably going to bug the heck out of me and keep me awake until I resolve it. | 00:14 |
| * Shrews is a bit OCD'ish sometimes | 00:14 | |
| rloo | Shrews: ha ha. Well, start a new dev environment then. FWIW, I'm running in RHEL and I don't expect the node I added to ironic, to do anything. | 00:16 |
| *** matsuhashi has joined #openstack-ironic | 00:20 | |
| *** Chandra has quit IRC | 00:23 | |
| *** hemna is now known as hemna_ | 00:25 | |
| *** meylor has joined #openstack-ironic | 00:37 | |
| *** meylor has left #openstack-ironic | 00:37 | |
| *** nosnos has joined #openstack-ironic | 00:43 | |
| *** ellenh has quit IRC | 01:03 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic: Updated from global requirements https://review.openstack.org/96228 | 01:07 |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic-python-agent: Updated from global requirements https://review.openstack.org/88722 | 01:07 |
| *** Haomeng has quit IRC | 01:13 | |
| *** eguz has joined #openstack-ironic | 01:25 | |
| *** eghobo has quit IRC | 01:29 | |
| *** dwalleck has joined #openstack-ironic | 01:39 | |
| *** eguz has quit IRC | 01:42 | |
| *** foexle_ has joined #openstack-ironic | 01:46 | |
| *** foexle has quit IRC | 01:49 | |
| *** matsuhashi has quit IRC | 02:07 | |
| *** matsuhashi has joined #openstack-ironic | 02:08 | |
| *** matsuhashi has quit IRC | 02:08 | |
| *** matsuhashi has joined #openstack-ironic | 02:08 | |
| openstackgerrit | A change was merged to openstack/ironic: Destroy instance to clear node state on failure https://review.openstack.org/99519 | 02:12 |
| *** rloo has quit IRC | 02:17 | |
| *** yfujioka has quit IRC | 02:50 | |
| *** ramineni has joined #openstack-ironic | 02:58 | |
| *** vinbs has joined #openstack-ironic | 03:05 | |
| *** rwsu has quit IRC | 03:27 | |
| *** blamar has joined #openstack-ironic | 03:38 | |
| *** blamar has quit IRC | 03:38 | |
| *** matsuhashi has quit IRC | 03:38 | |
| *** matsuhashi has joined #openstack-ironic | 03:39 | |
| *** matsuhashi has quit IRC | 03:45 | |
| *** matsuhashi has joined #openstack-ironic | 03:45 | |
| *** matsuhashi has quit IRC | 03:46 | |
| *** dwalleck has quit IRC | 03:46 | |
| *** radsy has quit IRC | 03:48 | |
| *** sabah has joined #openstack-ironic | 03:52 | |
| *** nosnos has quit IRC | 04:02 | |
| *** matsuhashi has joined #openstack-ironic | 04:37 | |
| *** nosnos has joined #openstack-ironic | 04:43 | |
| *** Nisha has joined #openstack-ironic | 04:46 | |
| *** rameshg87 has joined #openstack-ironic | 04:52 | |
| *** matsuhashi has quit IRC | 04:56 | |
| *** matsuhashi has joined #openstack-ironic | 04:57 | |
| *** k4n0 has joined #openstack-ironic | 05:08 | |
| *** rakesh_hs2 has joined #openstack-ironic | 05:35 | |
| *** bmahalakshmi has joined #openstack-ironic | 05:37 | |
| *** pcrews has quit IRC | 05:45 | |
| *** harlowja is now known as harlowja_away | 05:54 | |
| *** lazy_prince has joined #openstack-ironic | 06:00 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic: Imported Translations from Transifex https://review.openstack.org/96063 | 06:02 |
| Nisha | k4n0: are you working on seamicro? | 06:06 |
| k4n0 | Nisha, used to work on that | 06:10 |
| k4n0 | Nisha, why? | 06:10 |
| Nisha | k4n0: I have raised a design spec review https://review.openstack.org/#/c/100951/ | 06:13 |
| Nisha | k4n0: Deva's opinion is that Seamicro and IPA guys shall also have a look at it | 06:14 |
| k4n0 | Nisha, does this discovery happen after node registration? | 06:15 |
| Nisha | and give their opinion on it | 06:15 |
| *** rakesh_hs2 has quit IRC | 06:15 | |
| *** rakesh_hs2 has joined #openstack-ironic | 06:16 | |
| k4n0 | Nisha, does this discovery happen after manual node registration? | 06:16 |
| Nisha | k4n0: Yes and No. Yes because after node id is created and node is registered, the properties are discovered. No, because the node is not returned until the discovery is completed and properties fields are populated. | 06:16 |
| k4n0 | Nisha, ok, i will take a deeper look and get back to you, btw i am no longer associated with SeaMicro. | 06:17 |
| k4n0 | Nisha, you should talk to michael patridge at SeaMicro | 06:17 |
| Nisha | k4n0: It will be good if you could review and let me know the opinion. Do you know who is currently working on seamicro? | 06:18 |
| *** Poornima|mtg has joined #openstack-ironic | 06:19 | |
| *** Mikhail_D_ltp has joined #openstack-ironic | 06:19 | |
| *** pcrews has joined #openstack-ironic | 06:20 | |
| Nisha | JayF: Are you working on IPA? | 06:20 |
| k4n0 | Nisha, Michael Patridge from AMD | 06:23 |
| k4n0 | Nisha, dunno if he is on this chan | 06:23 |
| Nisha | k4n0: Thanks | 06:25 |
| dtantsur|afk | Morning Ironic! | 06:50 |
| mrda | hi dtantsur|afk | 06:52 |
| *** dtantsur|afk is now known as dtantsur | 06:53 | |
| *** jcoufal has joined #openstack-ironic | 07:10 | |
| *** sysexit has joined #openstack-ironic | 07:15 | |
| *** ajc_ has joined #openstack-ironic | 07:17 | |
| *** athomas has joined #openstack-ironic | 07:21 | |
| openstackgerrit | Shivanand Tendulker proposed a change to openstack/ironic-specs: Design spec for firmware settings feature. https://review.openstack.org/101122 | 07:25 |
| *** Madasi has quit IRC | 07:27 | |
| *** Madasi has joined #openstack-ironic | 07:29 | |
| openstackgerrit | Shivanand Tendulker proposed a change to openstack/ironic-specs: Design spec for firmware settings feature. https://review.openstack.org/101122 | 07:31 |
| *** vinbs has quit IRC | 07:33 | |
| *** vinbs has joined #openstack-ironic | 07:34 | |
| *** pcrews has quit IRC | 07:37 | |
| openstackgerrit | A change was merged to openstack/ironic: Add 'context' parameter to get_console_output() https://review.openstack.org/100768 | 07:48 |
| *** sabah has quit IRC | 08:05 | |
| *** sysexit has quit IRC | 08:06 | |
| *** sysexit has joined #openstack-ironic | 08:07 | |
| ramineni | dtantsur , Hi | 08:20 |
| dtantsur | ramineni, hi | 08:20 |
| ramineni | dtantsur, regarding the comment in the ilo power spec , | 08:21 |
| ramineni | dtantsur, by ilo specification , u meant some API documentation about functions? | 08:22 |
| dtantsur | ramineni, any kind, that people may read to know what iLO is :) it's more-or-less formal request from me, so that spec is complete | 08:22 |
| ramineni | dtantsur , ok userguide kind of? | 08:24 |
| dtantsur | ramineni, should be enough, I guess | 08:24 |
| ramineni | dtantsur , thanks ..will udpate that :) | 08:25 |
| *** pelix has joined #openstack-ironic | 08:35 | |
| *** igordcard has joined #openstack-ironic | 08:36 | |
| *** romcheg has joined #openstack-ironic | 08:39 | |
| *** mrda is now known as mrda-away | 08:43 | |
| *** nosnos has quit IRC | 08:44 | |
| *** lucasagomes has joined #openstack-ironic | 08:45 | |
| *** nosnos has joined #openstack-ironic | 08:46 | |
| *** igordcard has quit IRC | 08:48 | |
| openstackgerrit | Imre Farkas proposed a change to openstack/ironic-specs: DRAC power driver https://review.openstack.org/99352 | 08:49 |
| *** igordcard has joined #openstack-ironic | 08:52 | |
| *** rakesh_hs2 has quit IRC | 08:54 | |
| *** rakesh_hs2 has joined #openstack-ironic | 08:58 | |
| *** saripurigopi has joined #openstack-ironic | 08:59 | |
| *** sabah has joined #openstack-ironic | 09:10 | |
| saripurigopi | I'm testing the vendor_passthru using curl+POST., i'm testing a simplet method that returns firmware information. but i'm not seeing any response. | 09:10 |
| saripurigopi | In the logs I can see the info printed. | 09:10 |
| saripurigopi | any idea why it is returning null in the response. | 09:13 |
| *** openstackgerrit has quit IRC | 09:14 | |
| rameshg87 | saripurigopi, i don't vendor passthru returns anything in http body back | 09:15 |
| rameshg87 | saripurigopi, is your vendor passthru getting called ? (checking api and conductor logs ??) | 09:15 |
| saripurigopi | rameshg87, Yes, In the conductor log I can see the return values printed. | 09:16 |
| saripurigopi | 2014-06-19 15:50:12.500 29936 DEBUG ironic.drivers.modules.cisco [-] UCS server firmware version: {'Dn': 'sys/chassis-1/blade-5/fw-status', 'OperState': 'ready', 'PackageVersion': '2.1(1a)B'} _get_firmware_info /opt/stack/ironic/ironic/drivers/modules/cisco.py:525 | 09:17 |
| *** martyntaylor has joined #openstack-ironic | 09:17 | |
| saripurigopi | @rameshg87, At the moment vendor_passthru is used only for set operations ? | 09:19 |
| rameshg87 | saripurigopi, yes i think it is | 09:20 |
| rameshg87 | saripurigopi, https://github.com/openstack/ironic/blob/master/ironic/conductor/manager.py#L257-L290 | 09:20 |
| rameshg87 | saripurigopi, the conductor thread processing vendorpassthru rpc message, triggers the vendor passthru in the background and comes out immediately. so it doesn't return anything | 09:21 |
| saripurigopi | rameshg87, are there any plans to support GET? | 09:21 |
| rameshg87 | saripurigopi, i guess there has been no requirement for GET till now, so only POST has been implemented https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/node.py#L450-L477 | 09:22 |
| rameshg87 | saripurigopi, you may add support for making a GET call on the nodes/vendor_passthru | 09:23 |
| rameshg87 | saripurigopi, :-) | 09:23 |
| lucasagomes | jroll, instance_info patches were updated again after rloo review | 09:24 |
| saripurigopi | @rameshg87, I'm not very familier with the framework, I'm willing to add the support with some help on understanding the framework. | 09:25 |
| rameshg87 | saripurigopi, sure :-) | 09:26 |
| rameshg87 | saripurigopi, if you wanted to add GET interface for vendorpassthru, the existing code should help. changes required for that would be similar | 09:27 |
| rameshg87 | saripurigopi, you may refer an existing thing nodes/console which supports both GET and PUT https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/node.py#L75-L110 | 09:27 |
| saripurigopi | @rameshg87, ok. | 09:28 |
| saripurigopi | @rameshg87, will gothrough the links and try this out. | 09:29 |
| ramineni | saripurigopi , if you are looking for getting firmware information , I have proposed a standard API for that | 09:30 |
| ramineni | saripurigopi, u can have a look at that , https://review.openstack.org/#/c/100842/3 | 09:30 |
| ramineni | saripurigopi, still in design spec review though :) | 09:31 |
| saripurigopi | @rameshg87, there are various other get methods I'm trying to verify. | 09:32 |
| saripurigopi | ok | 09:32 |
| *** nosnos has quit IRC | 09:40 | |
| *** matsuhashi has quit IRC | 09:44 | |
| *** matsuhashi has joined #openstack-ironic | 09:44 | |
| *** matsuhashi has quit IRC | 09:46 | |
| *** matsuhashi has joined #openstack-ironic | 09:47 | |
| lucasagomes | a-ha... * openstackgerrit has quit (Ping timeout: 240 seconds) | 09:51 |
| *** coolsvap|afk is now known as coolsvap | 09:55 | |
| rameshg87 | lucasagomes, :-) , how do we get it back in ? | 09:58 |
| lucasagomes | rameshg87, hah no idea | 09:58 |
| dtantsur | openstackgerrit is on PTO :D | 10:00 |
| lucasagomes | lol | 10:01 |
| *** Nisha has quit IRC | 10:12 | |
| *** coolsvap is now known as coolsvap|afk | 10:15 | |
| *** max_lobur has joined #openstack-ironic | 10:16 | |
| *** Manishanker has joined #openstack-ironic | 10:20 | |
| *** Manishanker has quit IRC | 10:24 | |
| *** viktors has joined #openstack-ironic | 10:24 | |
| *** coolsvap|afk is now known as coolsvap | 10:32 | |
| *** romcheg has quit IRC | 10:34 | |
| lucasagomes | lifeless, ping re #86092, left a comment there, I believe that patches are safe to land each patch in a standalone fashion | 10:35 |
| *** takadayuiko has joined #openstack-ironic | 10:36 | |
| lucasagomes | lifeless, there's an abstraction layer that checks whether that driver supports the management interface and use it if so, or it falls back to the normal vendor_passthru (just as before) | 10:36 |
| *** coolsvap is now known as coolsvap|afk | 10:57 | |
| *** matsuhashi has quit IRC | 11:00 | |
| *** matsuhashi has joined #openstack-ironic | 11:01 | |
| *** ramineni has left #openstack-ironic | 11:03 | |
| *** matsuhashi has quit IRC | 11:05 | |
| *** dtantsur is now known as dtantsur|lunch | 11:11 | |
| *** Mikhail_D_ltp has quit IRC | 11:14 | |
| *** Mikhail_D_wk has quit IRC | 11:14 | |
| *** Mikhail_D_ltp has joined #openstack-ironic | 11:15 | |
| *** Mikhail_D_wk has joined #openstack-ironic | 11:15 | |
| *** matsuhashi has joined #openstack-ironic | 11:16 | |
| *** romcheg has joined #openstack-ironic | 11:20 | |
| *** rameshg87 has left #openstack-ironic | 11:23 | |
| *** pradipta_away is now known as pradipta | 11:30 | |
| *** sabah has quit IRC | 11:34 | |
| *** saripurigopi has quit IRC | 11:35 | |
| *** ajc_ has quit IRC | 11:50 | |
| *** ajc_ has joined #openstack-ironic | 11:50 | |
| *** bmahalakshmi has quit IRC | 11:54 | |
| *** ajc_ has quit IRC | 11:55 | |
| *** shausy has joined #openstack-ironic | 11:55 | |
| Shrews | lucasagomes: mrda-away: commit messages can be edited directly in gerrit. new feature since the upgrade | 12:00 |
| lucasagomes | oh that's true | 12:02 |
| *** sysexit has quit IRC | 12:03 | |
| *** koolks has joined #openstack-ironic | 12:03 | |
| *** Poornima|mtg has quit IRC | 12:07 | |
| *** pradipta is now known as pradipta_away | 12:11 | |
| *** matsuhashi has quit IRC | 12:13 | |
| *** matsuhashi has joined #openstack-ironic | 12:14 | |
| *** matsuhas_ has joined #openstack-ironic | 12:18 | |
| *** matsuhashi has quit IRC | 12:18 | |
| vinbs | Hi lucasagomes :) | 12:19 |
| vinbs | lucasagomes, pxe boot on ironic baremetal passes but the eventual os deploy fails | 12:21 |
| romcheg | Morning Ironic! | 12:21 |
| vinbs | lucasagomes, I think it's an issue with the partitioning | 12:22 |
| lucasagomes | vinbs, hey right... do you have the conductor log handy? | 12:23 |
| vinbs | lucasagomes, yes let me share it with you | 12:23 |
| *** sysexit has joined #openstack-ironic | 12:24 | |
| vinbs | lucasagomes, here's the conductor log http://paste.openstack.org/show/84494/ | 12:30 |
| vinbs | lucasagomes, I'm using the icehouse version of ironic | 12:31 |
| lucasagomes | vinbs, oh right yeah I can see the sfdisk there | 12:32 |
| lucasagomes | vinbs, the partitioning seems to be fine, the image was copied to the disk as well "3431565312 bytes (3.4 GB) copied, 79.6272 s, 43.1 MB/s" | 12:32 |
| lucasagomes | vinbs, which error you get when booting the instance? | 12:32 |
| vinbs | lucasagomes, I dont see an error on the openstack side | 12:33 |
| vinbs | lucasagomes, but after copying the image, the server reboots for the actual os deploy | 12:33 |
| lucasagomes | vinbs, right, something on the console? | 12:33 |
| lucasagomes | vinbs, ohh | 12:33 |
| lucasagomes | vinbs, the instance in nova-list is marked as active? | 12:34 |
| vinbs | lucasagomes, and it again goes into pxe bott | 12:34 |
| vinbs | lucasagomes, yes | 12:34 |
| lucasagomes | vinbs, and u sure ur not using the same deploy ramdisk and deploy kernel in the image metadata? | 12:34 |
| lucasagomes | vinbs, right, one thing is, local boot is not actually implemented in Ironic | 12:35 |
| lucasagomes | so, it will PXE boot to boot the final image | 12:35 |
| lucasagomes | vinbs, it's done because we want to guarantee the order that the machines are booted (hosts first and then guests) so having guests to always PXE boot we can ensure that ordem | 12:35 |
| *** k4n0 has quit IRC | 12:36 | |
| vinbs | lucasagomes, I'm confused about the different images I need to use | 12:36 |
| lucasagomes | vinbs, right... so you have 2 pairs of ramdisks and kernels | 12:37 |
| lucasagomes | you have the deploy kernel and ramdisk, which are set in the flavor | 12:37 |
| vinbs | lucasagomes, ahh that is where I'm making a mistake! | 12:37 |
| lucasagomes | this is a special ramdisk that actually does the deployment of the node (expose the iscsi etc) | 12:37 |
| lucasagomes | and you have the real image ramdisk and kernel set as metadata in glance | 12:37 |
| lucasagomes | vinbs, right | 12:37 |
| *** coolsvap|afk is now known as coolsvap | 12:38 | |
| vinbs | lucasagomes, and both these pairs of images need to be imported into glance? | 12:38 |
| lucasagomes | so the metadata in glance should point to the real ramdisk and kernel of the image u want to deploy | 12:38 |
| lucasagomes | vinbs, yes | 12:38 |
| vinbs | lucasagomes, so in glance I would be having two pairs of ramdisk and kernel images and one actual image of the deploy OS? | 12:39 |
| lucasagomes | vinbs, yes | 12:39 |
| vinbs | lucasagomes, one pair I would have associated with the flavor and the other pair with the actual deploy OS by using glance image-update | 12:39 |
| vinbs | lucasagomes, is that right? | 12:39 |
| lucasagomes | vinbs, that's correct... the deploy one in flavor | 12:40 |
| *** takadayuiko has quit IRC | 12:40 | |
| lucasagomes | vinbs, you can use some tripleO scripts to extract the kernel/ramdisk from the image and upload it to glance | 12:40 |
| lucasagomes | or at least look at how it's done... lemme grab the link | 12:40 |
| lucasagomes | vinbs, https://github.com/openstack/tripleo-incubator/blob/master/scripts/load-image | 12:41 |
| vinbs | lucasagomes, yes I did use diskimage builder to extract kernel and ramdisk from my deploy image | 12:41 |
| lucasagomes | (we def need to document such things better, and I'm looking fwd to have local boot as an option) | 12:41 |
| lucasagomes | vinbs, right, so you upload those to glance | 12:41 |
| lucasagomes | and then set their ID's on the image metadata | 12:41 |
| vinbs | lucasagomes, so I associate the id of these extracted images with my actual deploy image | 12:42 |
| lucasagomes | vinbs, yes | 12:42 |
| vinbs | lucasagomes, I can't use the same kernel and ramdisk images to associate with the flavor? | 12:42 |
| lucasagomes | vinbs, no because the flavor one points to the deploy ramdisk | 12:43 |
| lucasagomes | vinbs, which is a special ramdisk... this deploy ramdisk has a customized init script | 12:43 |
| lucasagomes | vinbs, which takes the disk expose it via iscsi, try to talk back to the Ironic api etc... | 12:43 |
| vinbs | lucasagomes, where do I get the images which I need to associate with the flavor? | 12:44 |
| lucasagomes | vinbs, you can build a deploy ramdisk using the diskimage-builder | 12:44 |
| lucasagomes | vinbs, https://github.com/openstack/diskimage-builder/tree/master/elements/deploy-ironic/ | 12:44 |
| vinbs | lucasagomes, these special ramdisk images are extracted from a cloud image which diskimage builder gets over the internet | 12:47 |
| vinbs | lucasagomes, is that right? | 12:47 |
| *** rloo has joined #openstack-ironic | 12:47 | |
| lucasagomes | vinbs, afaiui, yes, it uses a base image (ubuntu by default I think) to build it | 12:48 |
| vinbs | lucasagomes, cool.. that was a very informative conversation | 12:49 |
| vinbs | lucasagomes, it cleared many doubts for me | 12:50 |
| lucasagomes | vinbs, :) | 12:50 |
| vinbs | lucasagomes, thanks! :) | 12:50 |
| lucasagomes | vinbs, cool, glad to help | 12:50 |
| lucasagomes | yw | 12:50 |
| *** rloo has quit IRC | 12:51 | |
| *** rloo has joined #openstack-ironic | 12:51 | |
| *** rloo_ has joined #openstack-ironic | 12:55 | |
| *** lucasagomes is now known as lucas-hungry | 12:55 | |
| *** rloo has quit IRC | 12:56 | |
| *** jcoufal has quit IRC | 12:56 | |
| *** rloo has joined #openstack-ironic | 12:58 | |
| *** rloo_ has quit IRC | 13:00 | |
| *** rloo has quit IRC | 13:02 | |
| *** rloo has joined #openstack-ironic | 13:02 | |
| *** dtantsur|lunch is now known as dtantsur | 13:12 | |
| *** shausy has quit IRC | 13:13 | |
| *** jcoufal has joined #openstack-ironic | 13:23 | |
| *** linggao has joined #openstack-ironic | 13:31 | |
| *** lucas-hungry is now known as lucasagomes | 13:33 | |
| NobodyCam | good morning Ironic | 13:38 |
| linggao | morning NobodyCam | 13:39 |
| dtantsur | morning, NobodyCam, lucasagomes, romcheg, vinbs :) | 13:39 |
| romcheg | Mornint guys! | 13:39 |
| dtantsur | ... and linggao! | 13:39 |
| lucasagomes | morning linggao romcheg NobodyCam dtantsur | 13:39 |
| vinbs | morning dtantsur! | 13:39 |
| linggao | morning dtantsur lucasagomes romcheg vinbs | 13:39 |
| NobodyCam | morning linggao dtantsur romcheg lucasagomes and vinbs :) | 13:40 |
| dtantsur | Our greeting lists are becoming longer :) I guess it's a good sign :) | 13:40 |
| romcheg | ++ | 13:40 |
| NobodyCam | lucasagomes: your buying e-novance .. or so i've heard | 13:41 |
| dtantsur | wow, lucasagomes is buying a company :D | 13:41 |
| NobodyCam | lol welll red hat really | 13:41 |
| NobodyCam | :-p | 13:41 |
| lucasagomes | lol | 13:42 |
| lucasagomes | NobodyCam, yup that's correct: http://www.redhat.com/about/news/press-archive/2014/6/red-hat-to-acquire-enovance | 13:42 |
| NobodyCam | :) wow :) | 13:43 |
| NobodyCam | very nice, just in time to fill up the paris summit :) oh there is going to be so many red hats runninng around :-p | 13:44 |
| *** vinbs has quit IRC | 13:44 | |
| lucasagomes | yeah, there's a mid-cycle there as well | 13:45 |
| *** sysexit has quit IRC | 13:45 | |
| lucasagomes | NobodyCam, https://wiki.openstack.org/wiki/Sprints/ParisJuno2014 | 13:45 |
| lucasagomes | btw devananda ^ | 13:45 |
| dtantsur | lucasagomes, btw I'll be in Paris for my PTO, so maybe will drop by for OpenStack party :) | 13:45 |
| dtantsur | (depending on what mrs. Tantsur will say)) | 13:45 |
| linggao | dtantsur, lol | 13:46 |
| NobodyCam | congratz lucasagomes: Ironic | 13:46 |
| NobodyCam | Lucas Alvares Gomes | 13:46 |
| lucasagomes | dtantsur, haha ack, yeah sure that would be cool | 13:46 |
| rloo | hello ironicees | 13:46 |
| dtantsur | hi rloo! | 13:46 |
| NobodyCam | morning ironic | 13:46 |
| lucasagomes | NobodyCam, :) | 13:46 |
| NobodyCam | gah | 13:46 |
| lucasagomes | rloo, yo morning | 13:46 |
| NobodyCam | morning rloo | 13:46 |
| NobodyCam | :-p | 13:46 |
| linggao | hi rloo | 13:47 |
| rloo | looks like Paris is the place to be in 2014! | 13:47 |
| rloo | lucasagomes: wrt https://review.openstack.org/#/c/94855/. Had more comments. Let me know if I don't make sense. | 13:48 |
| lucasagomes | rloo, sorry i think I missed ur comment for the states | 13:49 |
| rloo | lucasagomes: no worries. I know I had a lot. | 13:49 |
| NobodyCam | we need to add set-provision-state to None that doesn't call verify :-p (to clear stuck nodes) | 13:50 |
| *** sysexit has joined #openstack-ironic | 13:50 | |
| *** davidlenwell has quit IRC | 13:51 | |
| *** anteaya has quit IRC | 13:51 | |
| *** anteaya has joined #openstack-ironic | 13:52 | |
| *** davidlenwell has joined #openstack-ironic | 13:53 | |
| *** rloo has quit IRC | 13:56 | |
| *** rloo has joined #openstack-ironic | 13:56 | |
| *** rloo has quit IRC | 13:57 | |
| *** rloo has joined #openstack-ironic | 13:57 | |
| *** dguerri has joined #openstack-ironic | 13:57 | |
| *** rloo has quit IRC | 14:01 | |
| *** hemna has joined #openstack-ironic | 14:02 | |
| *** rloo has joined #openstack-ironic | 14:02 | |
| NobodyCam | lucasagomes: Ironic | 14:08 |
| NobodyCam | Lucas Alvares Gomes | 14:08 |
| NobodyCam | grrr | 14:08 |
| NobodyCam | lucasagomes: http://paste.openstack.org/show/Sec5sjsKOVprN8BLQXNA/ | 14:08 |
| NobodyCam | ahh worked that time | 14:08 |
| lucasagomes | :( NobodyCam to tear down the machine after the deploy failed? | 14:09 |
| lucasagomes | NobodyCam, what caused the deploy to fail? | 14:09 |
| NobodyCam | yea, tftp issues | 14:10 |
| jroll | morning y'all! | 14:10 |
| NobodyCam | morning jroll | 14:11 |
| romcheg | Morning jroll! | 14:11 |
| jroll | NobodyCam: +1 on and endpoint for fixing stuck nodes :) | 14:11 |
| NobodyCam | I kinda think we should have somehting in the cli that would allow operators to do that | 14:12 |
| NobodyCam | some thing like set-provision-state=None or --force option | 14:12 |
| jroll | yep | 14:13 |
| jroll | the current solution is a mysql shell :( | 14:13 |
| *** matsuhas_ has quit IRC | 14:17 | |
| *** foexle has joined #openstack-ironic | 14:18 | |
| *** dguerri is now known as _dguerri | 14:19 | |
| *** foexle_ has quit IRC | 14:19 | |
| lucasagomes | :( yeha | 14:21 |
| lucasagomes | rloo, the states looks alright i think... it's talking about setting/validating the power state of the node | 14:23 |
| lucasagomes | not the provision state | 14:23 |
| *** matsuhashi has joined #openstack-ironic | 14:23 | |
| lucasagomes | rloo, tho, maybe that needs a general update (or removal) | 14:23 |
| lucasagomes | idk if makes much sense to have that doc there | 14:23 |
| *** _dguerri is now known as dguerri | 14:24 | |
| rloo | lucasagomes: ok. I wondered ;) | 14:24 |
| lucasagomes | rloo, so for power state it doesn't need to touch the instance_info | 14:24 |
| lucasagomes | rloo, ack, cheers for the other two comments there | 14:24 |
| romcheg | Guys, I just ran stack.sh and noticed that node validation says "Can not validate PXE bootloader. The following parameters were not passed to ironic: ['pxe_root_gb', 'pxe_image_source']" | 14:29 |
| romcheg | Looks like devstack has to be updated | 14:29 |
| lucasagomes | romcheg, weird lastest version of devstack and ironic? | 14:31 |
| romcheg | Fresh install | 14:31 |
| romcheg | New VM, fresh sources, etc | 14:32 |
| lucasagomes | ic | 14:32 |
| romcheg | I'll take a look | 14:32 |
| *** jdob has joined #openstack-ironic | 14:33 | |
| *** athomas_ has joined #openstack-ironic | 14:33 | |
| *** rakesh_hs2 has quit IRC | 14:33 | |
| *** matsuhashi has quit IRC | 14:33 | |
| *** matsuhashi has joined #openstack-ironic | 14:33 | |
| *** rwsu has joined #openstack-ironic | 14:34 | |
| * Shrews notes to NOT upgrade devstack | 14:34 | |
| *** theDavidAiken has joined #openstack-ironic | 14:35 | |
| *** athomas_ has quit IRC | 14:36 | |
| romcheg | And the node's stuck in "wait call-back" :( | 14:37 |
| lucasagomes | ew, wondering how tests are passing | 14:37 |
| *** jbjohnso has joined #openstack-ironic | 14:37 | |
| *** hemna has quit IRC | 14:37 | |
| *** matsuhashi has quit IRC | 14:38 | |
| * romcheg is going to debug that | 14:38 | |
| *** matsuhashi has joined #openstack-ironic | 14:40 | |
| *** dguerri is now known as _dguerri | 14:41 | |
| *** _dguerri is now known as dguerri | 14:41 | |
| lucasagomes | NobodyCam, https://review.openstack.org/#/c/101148/ easy one | 14:45 |
| NobodyCam | doh hahaha good catch | 14:48 |
| rloo | lucasagomes: wrt 101148 (am just looking at it). not all the tests call sleep, is the idea to just put sleep in all the tests, just in case? | 14:49 |
| lucasagomes | rloo, well I though it would be easier to put at the class level so that we make sure that no tests would waste time sleeping | 14:49 |
| lucasagomes | (we don't access the BMC on tests so no reason to sleep between ipmi commands there) | 14:50 |
| NobodyCam | rloo I just landed it | 14:51 |
| lucasagomes | rloo, if you think it's better I could add the sleep only on the tests that actually are using it | 14:51 |
| NobodyCam | or +a | 14:51 |
| NobodyCam | 'd | 14:51 |
| lucasagomes | oh | 14:51 |
| lucasagomes | heh ok a bit late :) | 14:51 |
| rloo | lucasagomes: I should probably read up more on mocks. If it is at the class level, is it used for all tests in that class, or only for tests that have it in their list of parameters? | 14:51 |
| lucasagomes | rloo, it affects all the methods on the class AFAIUI | 14:52 |
| lucasagomes | I mean, the class will pass that mock to all the methods | 14:52 |
| lucasagomes | that mock will be passed to all the methods in that class* | 14:53 |
| rloo | lucasagomes: so even if mock_sleep isn't in a method's args, that mock will still be invoked in that method? | 14:53 |
| rloo | lucasagomes: eg test__power_status_exception(self, mock_exec, mock_sleep). Did you need to put mock_sleep there? | 14:54 |
| lucasagomes | rloo, yeah, it that mock affects all tests, and the mock will be passed to all methods in that class | 14:55 |
| lucasagomes | passed as a parameter* | 14:55 |
| *** romcheg1 has joined #openstack-ironic | 14:55 | |
| *** romcheg has quit IRC | 14:58 | |
| rloo | lucasagomes: ok, got it. So it *has* to be passed in as a parameter, cannot NOT pass it in. Thx. | 15:01 |
| lucasagomes | rloo, yup | 15:02 |
| lucasagomes | rloo, there a way to mock something at the class level but it won't be passed as parameter to any method | 15:02 |
| lucasagomes | rloo, @mock.patch.object(time, 'sleep', lambda _: None) | 15:03 |
| lucasagomes | but it seems to be something like, or u always pass the mock to all methods, or u never pass it to any method | 15:03 |
| * lucasagomes needs to read more about mock | 15:04 | |
| rloo | lucasagomes: cool. If you used the mock.patch.object, can you access it from w/i a test? If so, that seems 'cleaner'. | 15:04 |
| lucasagomes | rloo, both cases uses mock.patch.object, but that lambda prevents it from being passed as a parameter... And if it's not passed as a parameter I don't know how to access that mock | 15:05 |
| * lucasagomes will investigate | 15:06 | |
| NobodyCam | humm, should we have a node-set-maintenance in the client? | 15:06 |
| lucasagomes | NobodyCam, node-update? | 15:06 |
| *** matsuhashi has quit IRC | 15:07 | |
| NobodyCam | ya but we have set-Provision and power as a option | 15:07 |
| *** matsuhashi has joined #openstack-ironic | 15:07 | |
| NobodyCam | why is maintenance different | 15:08 |
| NobodyCam | just looking at the node-list fields | 15:08 |
| NobodyCam | vs the info dict fields | 15:08 |
| lucasagomes | NobodyCam, afaiui because to set the power or provision in the rest api you have a special resource to validate the request (instead of only setting it on the db) | 15:09 |
| lucasagomes | where maintanance you don't need any special validation to set, if the node resource can be updated (I think we prevent updates mid-provisioning operation) you can set maintenance just like any other field | 15:10 |
| dtantsur | lucasagomes, rloo, I guess instead of lambda you can pass return_value=None and you'll get both return_value and mock object as a parameter | 15:10 |
| dtantsur | (did not follow context, just saw the latest discussion) | 15:10 |
| lucasagomes | dtantsur, ah good to know | 15:11 |
| jbjohnso | fyi, I've pushed the web widget code for confluent if anone has interest | 15:11 |
| dtantsur | needs to be checked but I remember I did it once :) | 15:11 |
| Shrews | adam_g: devananda: changed https://review.openstack.org/94439 to add a new BaremetalFeaturesGroup config group so we can selectively turn off the rebuild() test (or others) | 15:11 |
| jbjohnso | I also have started doing service processor and node autodetection groundwork there | 15:11 |
| rloo | dtantsur: thx. I think you're the resident mock expert :-) | 15:11 |
| *** matsuhashi has quit IRC | 15:11 | |
| dtantsur | rloo, you're overestimating me :) just did some research some time ago | 15:12 |
| rloo | dtantsur: more research than I did! :D | 15:12 |
| *** blamar has joined #openstack-ironic | 15:12 | |
| *** romcheg1 has left #openstack-ironic | 15:15 | |
| *** mdorman has joined #openstack-ironic | 15:15 | |
| *** athomas_ has joined #openstack-ironic | 15:18 | |
| *** athomas_ has quit IRC | 15:18 | |
| *** athomas has quit IRC | 15:19 | |
| *** jcoufal has quit IRC | 15:21 | |
| *** dwalleck has joined #openstack-ironic | 15:25 | |
| *** hemna has joined #openstack-ironic | 15:25 | |
| *** coolsvap is now known as coolsvap|afk | 15:27 | |
| *** athomas has joined #openstack-ironic | 15:28 | |
| jbjohnso | out of band inventory..... so I can offer some generally applicable stuff if interested and a scheme where in knowing which mac is which (or even needing to know the mac addresses at all) is not required | 15:30 |
| jbjohnso | if anyone is interested in talking | 15:30 |
| jbjohnso | cpu and memory are possible to describe reasonably within the standard, mac and disk are not, but uuid is | 15:31 |
| *** jgrimm has quit IRC | 15:34 | |
| linggao | jbjohnso, devananda is not here. but I am very interested in knowing how to tell which mac is install mac without booting the node. | 15:34 |
| jbjohnso | that's not possible, but you can know another PXE idenetfier reliably that does not vary with NIC, the UUID | 15:35 |
| linggao | meaning, which mac is facing the conductor. | 15:35 |
| jbjohnso | then you can shift to focus on UUID to do boot configuration | 15:35 |
| jbjohnso | and then the OS will pick up the correct nic to ifup by way of BOOTIF= | 15:35 |
| jbjohnso | IP configuration could be done outside the scope of DHCP with a generic identity instead to tide things over to static identity assignment | 15:36 |
| jbjohnso | or DHCP could do DDNS update from client to assign a reliable name to a pool allocated address... so many options | 15:36 |
| lucasagomes | rloo, have u read lifeless comments at #99426 ? I just added another one, what do u think? | 15:44 |
| * rloo looks | 15:44 | |
| rloo | lucasagomes: oh boy. | 15:47 |
| lucasagomes | rloo, lol I hear yah | 15:47 |
| rloo | lucasagomes: maybe a discussion with lifeless would help. It seems to me that you're doing his first suggestiong, make everything MB to get consistency. | 15:48 |
| lucasagomes | rloo, that was the initial idea | 15:48 |
| lucasagomes | rloo, back in february... anyway yeah... | 15:49 |
| rloo | so, just to be clear. the issue was the inconsistency, right? swap was in MB, but root and ephemeral was in GB. | 15:49 |
| lucasagomes | rloo, yup | 15:49 |
| rloo | lucasagomes: wait a minute. sorry. we want to use GB, not MB. and lifeless suggested going MB. | 15:51 |
| lucasagomes | rloo, yeah... but the initial idea was to use MB and (I forgot exactly) then after some discussion we decided to use GB | 15:52 |
| *** eghobo has joined #openstack-ironic | 15:52 | |
| *** eghobo has quit IRC | 15:52 | |
| lucasagomes | I forgot exactly why we changed our minds* | 15:53 |
| rloo | lucasagomes: maybe it needs a BP? (just joking). I think there may be two issues here but not sure. | 15:53 |
| *** eghobo has joined #openstack-ironic | 15:53 | |
| rloo | lucasagomes: 1. want consistency in units, either MB or GB. | 15:53 |
| *** eghobo has quit IRC | 15:53 | |
| rloo | lucasagomes: 2. want to make sure we keep the same 'intention' as currently, so if GB, and swap was in MB, we don't want 1 MB swap -> 1 GB swap. | 15:54 |
| *** eghobo has joined #openstack-ironic | 15:54 | |
| lucasagomes | rloo, aye, sounds correct | 15:54 |
| rloo | lucasagomes: 3. Is lifeless disagreeing with allowing root/ephemeral to be in units smaller than a GB? | 15:54 |
| rloo | lucasagomes: wrt 3. I am wondering if he is OK with swap_GB being in fractions, but not root/ephemeral. | 15:55 |
| lucasagomes | rloo, I don't think so cause he suggested to use MB on that comment | 15:55 |
| lucasagomes | rloo, let's wait for lifeless to comment again | 15:56 |
| lucasagomes | rloo, cause having only swap_GB to accept fractions sounds even more incosistent | 15:56 |
| rloo | lucasagomes: yeah. So if MB is the smallest unit we're dealing with, it seems to me that we should use MB. but maybe the argument was that people think in GB these days. | 15:57 |
| lucasagomes | rloo, yeah I agree... seems that going back to the original idea of MB is the best choice... 1) it's consistent 2) don't add the complexity of having fractions | 15:58 |
| lucasagomes | devananda, ^ thoughts? | 15:58 |
| *** lazy_prince has quit IRC | 16:00 | |
| lucasagomes | rloo, thank u | 16:02 |
| rloo | lucasagomes: yw. hope I helped ;) | 16:03 |
| lucasagomes | rloo, it did, a lot | 16:05 |
| lucasagomes | tho I'm not coding anything until I make sure we all have an agreement on that | 16:05 |
| *** jcoufal has joined #openstack-ironic | 16:06 | |
| Shrews | NobodyCam: ping | 16:07 |
| *** vinbs has joined #openstack-ironic | 16:10 | |
| NobodyCam | reply with "pong" | 16:10 |
| Shrews | NobodyCam: why does FakeIPMIToolDriver not use a fake power driver? If there nothing real deployed, those calls won't work. | 16:12 |
| *** vinbs_ has joined #openstack-ironic | 16:12 | |
| Shrews | i'm failing to understand the purpose of these | 16:12 |
| *** cdent has joined #openstack-ironic | 16:13 | |
| NobodyCam | humm, | 16:13 |
| Shrews | "these" being fake drivers | 16:13 |
| *** vinbs has quit IRC | 16:14 | |
| *** vinbs_ is now known as vinbs | 16:15 | |
| NobodyCam | Shrews: say I have a laptop that I want to use as a test node, I could hit the power button at the correct time and the deploy would work? | 16:15 |
| *** Nisha has joined #openstack-ironic | 16:17 | |
| Shrews | NobodyCam: so all of the Fake* drivers (except for FakeDriver), are expected to have real h/w for nodes? | 16:17 |
| *** blamar has quit IRC | 16:18 | |
| NobodyCam | or used to check that the rest of the bits did their thing, I.e setup the tftp dir correctly, pulled images | 16:18 |
| NobodyCam | etc, | 16:18 |
| NobodyCam | oh bbt brb | 16:19 |
| *** martyntaylor has left #openstack-ironic | 16:23 | |
| *** ellenh has joined #openstack-ironic | 16:23 | |
| *** foexle has quit IRC | 16:28 | |
| Nisha | linggao: Hi | 16:29 |
| Nisha | linggao: saw the comment on https://review.openstack.org/#/c/100951/5 "Discover node properties at node-create/node-update" | 16:31 |
| *** coolsvap|afk is now known as coolsvap | 16:31 | |
| *** cdent_ has joined #openstack-ironic | 16:31 | |
| *** cdent has quit IRC | 16:32 | |
| *** cdent_ is now known as cdent | 16:32 | |
| *** jcoufal has quit IRC | 16:41 | |
| *** jcoufal has joined #openstack-ironic | 16:42 | |
| *** koolks has quit IRC | 16:53 | |
| *** ellenh_ has joined #openstack-ironic | 16:55 | |
| *** ellenh has quit IRC | 16:55 | |
| *** ellenh_ is now known as ellenh | 16:55 | |
| Nisha | Hi linggao | 16:57 |
| dtantsur | instance_info patch https://review.openstack.org/#/c/94855/ got 2x +2 and is waiting for final approval | 16:59 |
| dtantsur | NobodyCam, devananda wanna have a look ^^^ ? | 16:59 |
| JayF | http://www.rackspace.com/cloud/servers/onmetal/ just got announced today. https://gist.github.com/jnoller/248a9d7f9b008f5d0aee | 17:02 |
| JayF | We'll be posting a blog very shortly about how our production environment works. TL;DR: Ironic master + Agent patches, everything provisioned with the agent. | 17:02 |
| rloo | dtantsur: why don't you want to approve? | 17:02 |
| JayF | Thanks to everyone here for helping us get up to speed, learn about how things work, and providing a foundation for us to build something awesome on. | 17:03 |
| Nisha | JayF: Hi | 17:03 |
| dtantsur | rloo, give folks chances to have last look. Will approve, if noone else appears for review after some time :) | 17:03 |
| lucasagomes | o/ | 17:04 |
| JayF | Nisha: hey, I saw your message overnight but you weren't in here when I got in. | 17:04 |
| rloo | dtantsur: ok. | 17:04 |
| jroll | oh Nisha, you're here now! I put "review Nisha's spec" on my todo list :) (I also work on IPA) | 17:04 |
| rloo | JayF: you scared me. I thought you were thanking us cuz you were leaving! | 17:04 |
| comstud | hahaha | 17:04 |
| JayF | rloo: no absolutely not! This is the start of a long journey | 17:04 |
| comstud | SEE YA GUYS... HAVE FUN! | 17:04 |
| Nisha | JayF: jroll: Thanks | 17:04 |
| rloo | ha ha ha | 17:04 |
| jroll | lol comstud | 17:05 |
| *** pcrews has joined #openstack-ironic | 17:05 | |
| Nisha | Please could you review https://review.openstack.org/#/c/100951/5 and let me know the comments on the same | 17:05 |
| *** harlowja_away is now known as harlowja | 17:05 | |
| dtantsur | JayF, wow cool! | 17:05 |
| Nisha | JayF: jroll: If any doubts we can discuss here also | 17:05 |
| jroll | Nisha: sure. Jay and I are at a conference today, and have a hack day tomorrow. we'll take a look next week at the latest :) | 17:06 |
| Nisha | Ok | 17:06 |
| JayF | dtantsur: thanks! | 17:07 |
| lucasagomes | aight, it's late here and I came to the office so gotta take the train back home | 17:09 |
| lucasagomes | have a good night everybody | 17:09 |
| JayF | lucasagomes: thanks, goodnight | 17:09 |
| *** lucasagomes has quit IRC | 17:09 | |
| *** blamar has joined #openstack-ironic | 17:15 | |
| *** dguerri has quit IRC | 17:19 | |
| *** athomas has quit IRC | 17:22 | |
| *** Mikhail_D_ltp has quit IRC | 17:33 | |
| *** eghobo has quit IRC | 17:37 | |
| *** eguz has joined #openstack-ironic | 17:37 | |
| *** Shrews has quit IRC | 17:37 | |
| *** jcoufal has quit IRC | 17:38 | |
| *** pelix has quit IRC | 17:41 | |
| *** eguz has quit IRC | 17:49 | |
| *** eghobo has joined #openstack-ironic | 17:50 | |
| anteaya | NobodyCam: is deva around today? | 17:50 |
| *** Shrews has joined #openstack-ironic | 17:50 | |
| devananda | morning, all | 17:53 |
| devananda | anteaya: hi! | 17:53 |
| anteaya | devananda: hello | 17:53 |
| anteaya | jeblair pinged you in infra linking you to https://news.ycombinator.com/item?id=7917098 | 17:54 |
| anteaya | just wanted to ensure you were going to be around today | 17:54 |
| anteaya | nothing like accurate information | 17:54 |
| jroll | morning devananda :) | 17:55 |
| NobodyCam | anteaya: he is working on securing a new home for him self | 17:55 |
| NobodyCam | oh didn't see ya there devananda :) | 17:55 |
| anteaya | NobodyCam: ah cool | 17:56 |
| anteaya | yes having a place to live is very important | 17:56 |
| anteaya | or you can just take it with you everywhere you go | 17:56 |
| NobodyCam | I have to run to the store real quick | 17:56 |
| anteaya | like a turtle or NobodyCam | 17:56 |
| NobodyCam | lol | 17:56 |
| anteaya | :D | 17:57 |
| devananda | yea - i'll be offline again in a few min | 17:57 |
| anteaya | kk | 17:57 |
| devananda | doing the paperwork dance for a new apartment | 17:57 |
| jroll | anteaya: "nothing like accurate information" - what do you mean? | 17:57 |
| anteaya | I hope it goes well | 17:57 |
| *** blamar has quit IRC | 17:57 | |
| devananda | anteaya: I was about to ask what jroll just asked | 17:57 |
| BadCub | Oooh.. How fun | 17:57 |
| anteaya | I mean that a trail of comments is all spectulation | 17:57 |
| anteaya | so hearing from people who have actual real information is sometimes helpful | 17:58 |
| jroll | anteaya: hm, those comments | 17:58 |
| anteaya | yeah | 17:58 |
| devananda | anteaya: taht seems more in line with something a representative of rackspace should cover, no? | 17:58 |
| anteaya | so joining in on the thread might be a chance to share some real information about what ironic does and doenst' do | 17:58 |
| anteaya | sure | 17:58 |
| anteaya | if they know it is on hacker news | 17:59 |
| jroll | I have no idea wtf a micro-vm | 17:59 |
| jroll | is | 17:59 |
| anteaya | right | 17:59 |
| anteaya | neither do folks in the comments | 17:59 |
| devananda | jroll: oh, so the announcement covered BOTH OnMetal and CoreOS / Docker | 17:59 |
| anteaya | here comes the spin | 17:59 |
| jroll | I think I got it | 17:59 |
| devananda | jroll: so i blame your marketing peopel for any confusion that ensues | 17:59 |
| jroll | devananda: I mean, kind of | 17:59 |
| jroll | nobody knows where that article came from | 17:59 |
| jroll | it also dropped *before* the announcement | 17:59 |
| jroll | so like, idk | 17:59 |
| devananda | hah | 17:59 |
| devananda | that's fun | 18:00 |
| devananda | jroll: not much before ... maybe minutes, or less | 18:00 |
| JayF | devananda: we blame our marketing people for any confusion that ensues :) | 18:00 |
| anteaya | so contributing might be a chance to get accurate info out there | 18:00 |
| anteaya | or whether the storm when inaccurate info about ironic hits people in the subconcsious | 18:01 |
| anteaya | weather | 18:01 |
| devananda | gotta run ... bbiah | 18:01 |
| JayF | jroll has a blog post written describing how this stuff is running in our environment | 18:01 |
| jroll | anteaya: commented on that | 18:01 |
| JayF | but pretty much anytime in the last 2 months when we've said 'this works in our lab' or 'this works in our environment'... we pretty much mean that | 18:01 |
| JayF | lol | 18:01 |
| jroll | ^ said blog post is having delays going up, but will be soon | 18:02 |
| anteaya | so folks are already thinking that rackspace build ironic | 18:02 |
| anteaya | built | 18:02 |
| jroll | anteaya: sigh | 18:02 |
| anteaya | yup | 18:02 |
| jroll | due to that article? | 18:02 |
| anteaya | follow or get trampled | 18:02 |
| anteaya | https://news.ycombinator.com/item?id=7917203 | 18:03 |
| JayF | People think lots of crazy things :) | 18:03 |
| anteaya | sorry, lead or get trampled | 18:03 |
| anteaya | Kudos to Rackspace for building this. | 18:03 |
| JayF | anteaya: FWIW, none of us feel that way | 18:03 |
| anteaya | oh I know that | 18:03 |
| *** hemna has quit IRC | 18:03 | |
| jroll | hrm | 18:03 |
| *** ryanpetrello has quit IRC | 18:03 | |
| anteaya | but trying changing public perception _after_ it has formed | 18:04 |
| jroll | ggreer used to work in our office, I'd be shocked if he thought we built ironic | 18:04 |
| jroll | but will comment | 18:04 |
| * anteaya returns to doing battle in the third party space | 18:04 | |
| anteaya | clarity is good | 18:04 |
| jroll | +1 | 18:04 |
| JayF | anteaya: I commented | 18:07 |
| * NobodyCam is back | 18:07 | |
| JayF | anteaya: my annoyance with it is actually more that so many people are overlooking that these are OpenCompute machines! | 18:07 |
| *** vinbs has quit IRC | 18:08 | |
| *** rloo has quit IRC | 18:08 | |
| *** viktors has quit IRC | 18:08 | |
| *** dshulyak has quit IRC | 18:08 | |
| *** slamont has quit IRC | 18:08 | |
| *** Madasi has quit IRC | 18:08 | |
| *** mkerrin has quit IRC | 18:08 | |
| *** rushiagr has quit IRC | 18:08 | |
| *** russell_h has quit IRC | 18:08 | |
| *** eghobo has quit IRC | 18:08 | |
| *** wendar has quit IRC | 18:08 | |
| *** harlowja has quit IRC | 18:08 | |
| *** mgagne has quit IRC | 18:08 | |
| *** agordeev has quit IRC | 18:08 | |
| *** yjiang5 has quit IRC | 18:08 | |
| *** adam_g has quit IRC | 18:08 | |
| *** rainya has quit IRC | 18:08 | |
| *** stevebaker has quit IRC | 18:08 | |
| *** pquerna has quit IRC | 18:08 | |
| *** zigo has quit IRC | 18:08 | |
| *** morgabra has quit IRC | 18:08 | |
| *** mrda-away has quit IRC | 18:08 | |
| *** antonym has quit IRC | 18:08 | |
| *** cdent has quit IRC | 18:08 | |
| *** eghobo has joined #openstack-ironic | 18:10 | |
| *** vinbs has joined #openstack-ironic | 18:10 | |
| *** rloo has joined #openstack-ironic | 18:10 | |
| *** viktors has joined #openstack-ironic | 18:10 | |
| *** Madasi has joined #openstack-ironic | 18:10 | |
| *** dshulyak has joined #openstack-ironic | 18:10 | |
| *** mkerrin has joined #openstack-ironic | 18:10 | |
| *** wendar has joined #openstack-ironic | 18:10 | |
| *** slamont has joined #openstack-ironic | 18:10 | |
| *** harlowja has joined #openstack-ironic | 18:10 | |
| *** yjiang5 has joined #openstack-ironic | 18:10 | |
| *** mgagne has joined #openstack-ironic | 18:10 | |
| *** agordeev has joined #openstack-ironic | 18:10 | |
| *** rushiagr has joined #openstack-ironic | 18:10 | |
| *** adam_g has joined #openstack-ironic | 18:10 | |
| *** rainya has joined #openstack-ironic | 18:10 | |
| *** russell_h has joined #openstack-ironic | 18:10 | |
| *** antonym has joined #openstack-ironic | 18:10 | |
| *** mrda-away has joined #openstack-ironic | 18:10 | |
| *** morgabra has joined #openstack-ironic | 18:10 | |
| *** zigo has joined #openstack-ironic | 18:10 | |
| *** pquerna has joined #openstack-ironic | 18:10 | |
| *** stevebaker has joined #openstack-ironic | 18:10 | |
| *** dguerri has joined #openstack-ironic | 18:10 | |
| linggao | Hi Nisha | 18:12 |
| Nisha | Hi linggao | 18:13 |
| *** Mikhail_D_ltp has joined #openstack-ironic | 18:13 | |
| Nisha | I posted the resolution comments on the comments you gave on Discover node properties design spec | 18:14 |
| linggao | Nisha, let me take a look.... | 18:14 |
| *** vinbs has quit IRC | 18:14 | |
| *** rloo has quit IRC | 18:14 | |
| *** viktors has quit IRC | 18:14 | |
| *** dshulyak has quit IRC | 18:14 | |
| *** slamont has quit IRC | 18:14 | |
| *** Madasi has quit IRC | 18:14 | |
| *** mkerrin has quit IRC | 18:14 | |
| *** rushiagr has quit IRC | 18:14 | |
| *** russell_h has quit IRC | 18:14 | |
| *** eghobo has quit IRC | 18:14 | |
| *** wendar has quit IRC | 18:14 | |
| *** harlowja has quit IRC | 18:14 | |
| *** mgagne has quit IRC | 18:14 | |
| *** agordeev has quit IRC | 18:14 | |
| *** yjiang5 has quit IRC | 18:14 | |
| *** adam_g has quit IRC | 18:14 | |
| *** rainya has quit IRC | 18:14 | |
| *** stevebaker has quit IRC | 18:14 | |
| *** pquerna has quit IRC | 18:14 | |
| *** zigo has quit IRC | 18:14 | |
| *** morgabra has quit IRC | 18:14 | |
| *** mrda-away has quit IRC | 18:14 | |
| *** antonym has quit IRC | 18:14 | |
| Nisha | linggao: Thanks | 18:15 |
| *** eghobo has joined #openstack-ironic | 18:16 | |
| *** vinbs has joined #openstack-ironic | 18:16 | |
| *** rloo has joined #openstack-ironic | 18:16 | |
| *** viktors has joined #openstack-ironic | 18:16 | |
| *** Madasi has joined #openstack-ironic | 18:16 | |
| *** dshulyak has joined #openstack-ironic | 18:16 | |
| *** mkerrin has joined #openstack-ironic | 18:16 | |
| *** wendar has joined #openstack-ironic | 18:16 | |
| *** slamont has joined #openstack-ironic | 18:16 | |
| *** harlowja has joined #openstack-ironic | 18:16 | |
| *** yjiang5 has joined #openstack-ironic | 18:16 | |
| *** mgagne has joined #openstack-ironic | 18:16 | |
| *** agordeev has joined #openstack-ironic | 18:16 | |
| *** rushiagr has joined #openstack-ironic | 18:16 | |
| *** adam_g has joined #openstack-ironic | 18:16 | |
| *** rainya has joined #openstack-ironic | 18:16 | |
| *** russell_h has joined #openstack-ironic | 18:16 | |
| *** antonym has joined #openstack-ironic | 18:16 | |
| *** mrda-away has joined #openstack-ironic | 18:16 | |
| *** morgabra has joined #openstack-ironic | 18:16 | |
| *** zigo has joined #openstack-ironic | 18:16 | |
| *** pquerna has joined #openstack-ironic | 18:16 | |
| *** stevebaker has joined #openstack-ironic | 18:16 | |
| *** bmahalakshmi has joined #openstack-ironic | 18:18 | |
| *** mdorman has quit IRC | 18:18 | |
| *** mdorman has joined #openstack-ironic | 18:19 | |
| jroll | oh, right, for any of you that happen to be in SF today, this is the party I mentioned on monday: http://www.eventbrite.com/e/rackspace-special-announcement-party-onmetal-tickets-11943323803?aff=estw | 18:20 |
| Nisha | linggao, there? | 18:21 |
| *** ryanpetrello has joined #openstack-ironic | 18:21 | |
| linggao | Nisha, the mac address in the port table is for deployment use, manly for dhcp. | 18:22 |
| linggao | So it does not make sense to put all the mac addresses in the port table. | 18:22 |
| linggao | the cpu, meomory, disk properties are for scheduling purpose. | 18:23 |
| Nisha | Yes, i know that MAC address is for deploy use. | 18:23 |
| Nisha | But when we say we will discover hw properties all those also form part of the hw properties | 18:23 |
| linggao | then how do you tell which mac is for deployment? | 18:24 |
| Nisha | each NIC/MAC have some prop at firmware level | 18:24 |
| Nisha | the states i have seen are disabled, PXE, iSCSI | 18:25 |
| Nisha | i think PXE state MAC address can be chosen for deploy | 18:25 |
| Nisha | and BTW nothing stops an admin to set other MAC addresses to PXE or iSCSI state | 18:25 |
| Nisha | by default i have seen only one having PXE state and others in disabled state, and generally we will pick up that MAC address for deploy | 18:26 |
| Nisha | does it make sense? | 18:26 |
| linggao | is this for iLO or IPMI? | 18:27 |
| Nisha | linggao: The MAC address state can be get | 18:27 |
| linggao | jbjohnso, are you there? | 18:28 |
| Nisha | The feature proposal isgeneric, it can be acheived thru iLO and ipmi both | 18:28 |
| Nisha | atleast we can use ipmi commands to get the state of MAC, thats for sure | 18:28 |
| Nisha | linggao: we plan to implement it thru iLO but it shall be possible via IPMI too | 18:29 |
| linggao | let me ask jbjohnso, he knows more about firmware than I. | 18:29 |
| Nisha | ok | 18:29 |
| Nisha | :) | 18:29 |
| Nisha | linggao: meanwhile can we discuss about your comment for disk inventory | 18:31 |
| jbjohnso | hello | 18:31 |
| jbjohnso | linggao, I'm awake | 18:32 |
| linggao | jbjohnso, that's good. :) | 18:32 |
| Nisha | jbjohnso, Hi | 18:32 |
| jbjohnso | Nisha, hello | 18:32 |
| jbjohnso | so for memory and cpu, at least those can be described via strict ipmi specification to pretty specific stuff | 18:32 |
| linggao | Nisha and I are dicussing how to identify the install mac through IPMI. Nisha said there is a state associated with each mac | 18:33 |
| jbjohnso | well, state is an interesting question | 18:33 |
| Nisha | jbjohnso, are u aware of it? | 18:34 |
| jbjohnso | so whatever data about a nic won't be in standard ipmi as far as I can think, but at least we do it using OEM vocabulary | 18:34 |
| Nisha | Yes we need to use raw command | 18:34 |
| jbjohnso | now for state, how much do yu see? We could distingush things like linuk state, but that doesn't seem adequate | 18:34 |
| jbjohnso | what I was planning to do to facilitate more arbitrary less context sensitive stuff was to enable tooling to do boot configuration keyed more into the UUID than the mac addresses | 18:35 |
| rloo | dtantsur: I had another comment for 94620 | 18:35 |
| jbjohnso | since I could forsee a lot of cases where indequate context can be retrieved (e.g. which vlan is where and also what about off the shelf pci adapters) | 18:35 |
| Nisha | jbjohnso, i didnt get your statement | 18:36 |
| Nisha | the second last one | 18:36 |
| jbjohnso | Nisha, so a PXE discover and such all comes with two servicable identifiers (well, one in DHCPv6, 2 in ipv4 | 18:36 |
| dtantsur | rloo, always thought that int(float) behaves exactly as int(round(float)) lemme check | 18:36 |
| jbjohnso | UUID and mac address | 18:36 |
| jbjohnso | the former is unique per node, the latter unique per iface | 18:36 |
| Nisha | ok. | 18:37 |
| linggao | jbjohnso, let's not go to the UUID yet. Nisha said there are states like: pxe, iscsi, and disable. he/she can pick the the mac with pxe state as install nic. | 18:37 |
| dtantsur | rloo, int(floor(float)) actually | 18:37 |
| Nisha | Yes lingago is correct | 18:37 |
| Nisha | linggao* | 18:37 |
| rloo | dtantsur: that will take the floor. did you want the floor or round? | 18:37 |
| Nisha | sorry misspelled the name | 18:37 |
| rloo | dtantsur: eg for 1.6, do you want 1 or 2? | 18:38 |
| linggao | Nisha, np, I just learned that you can use the tab key to auto fill the name. | 18:38 |
| Nisha | linggao: I am she | 18:38 |
| *** bandicot has joined #openstack-ironic | 18:38 | |
| dtantsur | rloo, that's a fair question and I don't see a correct answer :) I preferred floor because it's more predictable | 18:38 |
| linggao | Nisha, same here. | 18:38 |
| Nisha | gr8 | 18:39 |
| jbjohnso | Nisha, so you are basically reying upon someone exlicitly configuring the roles in firmware? | 18:39 |
| Nisha | jbjohnso | 18:39 |
| Nisha | No | 18:39 |
| rloo | dtantsur: I'm fine with that (see what happens if that function is actually being used). but you need to document it then. it says 'round' ;) | 18:39 |
| Nisha | by default, say a BM has 10 ports | 18:39 |
| dtantsur | rloo, I mean, both variants are bad if we have 1.6 MiB, but we can't with current disk partitioner :) | 18:39 |
| jbjohnso | ok. | 18:39 |
| Nisha | jbjohnso, then one is enabled as PXE state and others are in disabled state | 18:39 |
| jbjohnso | Nisha, right, but who enabled one? | 18:40 |
| rloo | dtantsur: yeah, i know that in practise it won't happen, just want to make sure the code is accurate/does what it says. | 18:40 |
| Nisha | i think that comes factory shipped | 18:40 |
| jbjohnso | Nisha, so for us, we have PXE attempts go through all available ports | 18:40 |
| Nisha | or we can add a step to enable one of the port to PXE and create a port for it | 18:40 |
| Nisha | I am not very sure if PXE state shall work for all deploys, but i think so | 18:41 |
| dtantsur | rloo, round, ceil and floor all are called "rounding" actually: http://en.wikipedia.org/wiki/Rounding | 18:41 |
| dtantsur | if you do insist, I will change, but please provide me with the correct variant :) | 18:42 |
| jbjohnso | Nisha, we have analagous capability, but it just seems like the system has to have a fair amount of accurate config as a prereq and would not be able to cover use of off the shelf adapters without particular UEFI drivers.. | 18:42 |
| jbjohnso | Nisha, well, about the disk side... | 18:43 |
| Nisha | i didnt get ur statement | 18:43 |
| jbjohnso | Nisha, well, like put a solarflare adapter into the server | 18:43 |
| jbjohnso | now what will the inventory do.... | 18:43 |
| jbjohnso | or perhaps more challenging, a Chelsio... | 18:43 |
| linggao | Nisha, jbjohnso, in our case, pxe go through all the macs, but only one (hopefully) responded from the server side. that is the one we need to put in the port table for the node. | 18:44 |
| rloo | dtantsur: yes, but using 'round' isn't specific enough. round up, round down, round... if you want to leave it as you have it then | 18:44 |
| jbjohnso | linggao, if we must be as boring as that, true. However we also don't need to do just one... | 18:44 |
| rloo | dtantsur: based on http://en.wikipedia.org/wiki/Rounding#Rounding_to_integer, it is round towards zero I think. | 18:44 |
| jbjohnso | that was one mistake I made in our implementation | 18:44 |
| *** notarealperson has quit IRC | 18:44 | |
| jbjohnso | you can have multiple fixed-address entries mapping to the same value | 18:44 |
| Nisha | jbjohnso: i didnt get :) | 18:45 |
| jbjohnso | that would mean you didn't have to pick the right one, any that appeared in inventory would work | 18:45 |
| *** wanyen has joined #openstack-ironic | 18:45 | |
| dtantsur | rloo, it seems to me we try to do to much to a single comment :) | 18:45 |
| jbjohnso | of course, the inventory may likely not cover add-in cards that are not options from the server vendor... | 18:45 |
| Nisha | wanyen, i am talking to jbjohnso and linggao | 18:45 |
| jbjohnso | UUID would however cover all if we so enabled ;0 | 18:45 |
| linggao | jbjohnso, let's not get there :). I know you love UUID. | 18:46 |
| wanyen | what is the subject for discussion? | 18:46 |
| jbjohnso | on the disk piece, I've not had much use for out of band assessment.. mainly because I get interested in vpd page 80 as a way to corrrelate SAN hosted volumens to deployment view.. | 18:46 |
| rloo | dtantsur: maybe I've worked on too much s/w where the kind of rounding made a difference :-( | 18:46 |
| Nisha | wanyen, discussion gng on for automatic port create | 18:46 |
| dtantsur | heh, that's possible :) | 18:47 |
| devananda | back. but on really slow connection, it seems | 18:47 |
| Nisha | jbjohnso, linggao, so is it fine to do auto-creation of ports based on state | 18:47 |
| Nisha | ? | 18:47 |
| dtantsur | anyway, my brain refuses to work and I already nearly written "code looks code" in one review :) so see you tomorrow | 18:47 |
| dtantsur | devananda, hello and good buy :) | 18:47 |
| linggao | Nisha, no, because it is not reliable. | 18:47 |
| jbjohnso | fyi, Iconfess to not be tracking the ironic data model closely | 18:48 |
| Nisha | linggao, why do you think its not reliable | 18:48 |
| wanyen | what are the concerns of doing port create? | 18:48 |
| rloo | night dtantsur! | 18:48 |
| jbjohnso | is it arbitrarily many ports or one port per server? | 18:48 |
| *** dtantsur is now known as dtantsur|afk | 18:48 | |
| jbjohnso | guess the question is whether we are talking about a not as awesome as it could be, but better than nothing for now.. | 18:49 |
| linggao | jbjohnso, to register a bm node, Ironic needs to know the bmc ip/username/password for BMC access, cpu, memory and disk size for scheduling, mac for deployment. | 18:49 |
| jbjohnso | depending on the overall architecture... | 18:49 |
| jbjohnso | it needs to know the disk size in advance? | 18:49 |
| Nisha | disk size can be retrieved | 18:49 |
| linggao | Nisha proposed a design spec to get cpu, memory and disk size and mac out-of-band | 18:49 |
| jbjohnso | what if you have a mix of direct attached and san volumes, or in general a plurality? | 18:49 |
| linggao | yes, for scheduling purpose. | 18:50 |
| jbjohnso | linggao, when you say 'mac for deplayment, must it be singular? | 18:50 |
| linggao | It can be multiple, I think. | 18:51 |
| jbjohnso | hmm, would it be so bad if multiple macs were crammed in to cover an 'any of the above scenario' | 18:51 |
| Nisha | yes , a node can have multiple ports today also | 18:51 |
| jbjohnso | a common scenario there would be pxe boot over what is intended to be a redundant bond.. | 18:51 |
| jbjohnso | either nic as a singular item can function good enough to pxe without minding the bond nature | 18:52 |
| *** vinbs has quit IRC | 18:52 | |
| linggao | Nisha, I think we can put multiple all of them have connection to the conductor node? | 18:52 |
| jbjohnso | I'm still not convinced that any mac inventory scheme will be robust and comprehensive in the face of arbitrary server and/or adapter vendor, but it would be better than nothing | 18:53 |
| linggao | let's ping devananda | 18:53 |
| Nisha | i meant for BM node, we can have multiple ports today too | 18:53 |
| wanyen | I know that Nova virtual instance alow multiple ports | 18:54 |
| jbjohnso | Nisha, and tehy can have a many to one mapping and nothing consideres an error if some of those never come to fruition? | 18:54 |
| Nisha | yes, true | 18:54 |
| Nisha | wanyen, i have tried on ironic node also | 18:54 |
| *** [1]Sam_S has joined #openstack-ironic | 18:55 | |
| jbjohnso | hmm, so as a 'best effort', cram as many candidates as can be flagged so that if any of them crop up in the right place at right time, golden | 18:55 |
| Nisha | ironic node can be associated with multiple ports today also | 18:55 |
| jbjohnso | though if you are bootstrapping the boot from a fake usb stick, that wouldn't fly | 18:55 |
| jbjohnso | the mechanism in that case would specifically have to know 'the one' without much chance to discover | 18:55 |
| *** dwalleck has quit IRC | 18:56 | |
| devananda | linggao: hi! | 18:56 |
| jbjohnso | of course, if something is trying to apply distinct configuration to each port and this data is shared with such a facility, that scheme wouldn't be too happy either | 18:56 |
| Nisha | if the "extra" field in the port object is populated with the state of the MAC, then it can be helpful for deploy to chose the MAC | 18:56 |
| linggao | devananda, Nisha jbjohnso and wanyen are discussing the auto discovery of the node properties. | 18:56 |
| devananda | great! | 18:57 |
| *** Sam_S has quit IRC | 18:57 | |
| *** [1]Sam_S is now known as Sam_S | 18:57 | |
| *** max_lobur has quit IRC | 18:57 | |
| linggao | devananda, one question is that node in Ironic can asscociate with many ports (macs) | 18:57 |
| wanyen | what kind of MAC state? | 18:57 |
| linggao | why is that? | 18:57 |
| jbjohnso | wanyen, I think a better word is mac 'role' | 18:57 |
| wanyen | I see. | 18:58 |
| devananda | because a physcal machine may have more than one NIC | 18:58 |
| Nisha | wanyen, each NIC on the BM has state associated (disabled/PXE/iSCSI). | 18:58 |
| jbjohnso | If the data is only to facilitate deployment in a manner that won't step on other stuff | 18:58 |
| devananda | Nisha: i don't know what these states are that you refer to | 18:58 |
| linggao | devananda, should we put all the macs in the port talbe for the node? | 18:58 |
| devananda | linggao: yes | 18:58 |
| jbjohnso | then you could just say 'whatever mac you see, go for it, here's all the possibilities' | 18:59 |
| devananda | linggao: ironic (will) inform neutron of the MACs for the node when it is placed on a network | 18:59 |
| linggao | devananda, I thought the ports in the port talbe is for install nic only. | 18:59 |
| jbjohnso | I need to add the memory inventory to pyghmi... well all the inventory... | 18:59 |
| devananda | linggao: so ironic must know all data-plane MAC addresses for that node in order for it to be properly connected to tenant network | 18:59 |
| Nisha | devananda: when we get firmware settings of the NICs, we get these details too | 18:59 |
| Nisha | by default, i have seen only one nIC having PXE state and rest as disabled | 19:00 |
| linggao | devananda, even if the port is disabled from the firmware? | 19:00 |
| devananda | linggao: ironic also informs neutron of the MAC address(es) to which DHCP should be honored, and which are expected to PXE boot | 19:00 |
| *** ekarlso has quit IRC | 19:01 | |
| jbjohnso | Nisha, devananda though I think the 'role' information is at some significant risk for being inadequate, and to some extent mac inventory at all even amongst the most careful non-bladed designs.. | 19:01 |
| klindgren | Hello - I am working on getting the anvil project to build packages for ironic. I have a working example - but am hoping for some input on the spec file: https://review.openstack.org/#/c/100693/2/conf/templates/packaging/specs/openstack-ironic.spec | 19:01 |
| devananda | linggao: if the NIC does not need to be placed on a network, and will not be handling traffic, ironic does not need to know about it | 19:01 |
| devananda | linggao: however, that gets potentially awkward. what if the tenant turns that NIC on in firmware? | 19:01 |
| jbjohnso | bladed designs can guarantee by virtue of having proprietary only io adapters.. | 19:01 |
| linggao | devananda, how does Ironic know which MAC address to use when informing Neutron about dhcp. | 19:01 |
| devananda | klindgren: hi! can you give us a link / some background on what Anvil is? | 19:02 |
| jbjohnso | devananda, fyi, I think this might be an interesting place to consider the role of MAC in a mandatory prereq for deployment as a stop-gap | 19:02 |
| devananda | linggao: right now it's naive -- it just says "all of them" | 19:02 |
| devananda | jbjohnso: i *think* it is. I think a node with no macs can not be deployed to | 19:02 |
| jbjohnso | devananda, as fixed target identity without foreknowledge of mac is quite feasible | 19:02 |
| devananda | jbjohnso: though i'm not sure we're enforcing that in the right places | 19:02 |
| jbjohnso | devananda, well, that's because the tooling isn't cool enough then | 19:02 |
| devananda | jbjohnso: no. we just haven'maybe t aded a check for that inthe right spot. the data's al lthere to do it | 19:03 |
| jbjohnso | devananda, incidentally, my scheme here is why I did RFC 6355 and got it into UEFI and WHQL specs | 19:03 |
| jroll | devananda: (and friends): http://developer.rackspace.com/blog/how-we-run-ironic-and-you-can-too.html | 19:03 |
| jbjohnso | devananda, so that I don't ever need to care about mac addresses, but that scheme can map to ipv4 as well | 19:03 |
| devananda | jroll: awesome, thanks! /me reaeds | 19:04 |
| jbjohnso | at least to bootstrap deployment for the 'deployment' nic | 19:04 |
| devananda | klindgren: hello? | 19:04 |
| *** ekarlso has joined #openstack-ironic | 19:04 | |
| linggao | Nisha, in that case, we can put all the mac addresses in the ports table. | 19:04 |
| wanyen | that's great! | 19:05 |
| Nisha | Ok, with the states associated? | 19:05 |
| linggao | Nisha, that's your choice. | 19:05 |
| Nisha | states will go in port object extra field if required | 19:05 |
| wanyen | I think we just ut all the ports | 19:05 |
| Nisha | ok | 19:05 |
| Nisha | lingago can we now discuss disk inventory comemnt too | 19:05 |
| jbjohnso | wanyen, I think I agree with that unless there is fear of trampling some non-deployment config hook | 19:05 |
| linggao | Nisha, for disk size, I saw two comments. | 19:05 |
| linggao | one from jbjohnso | 19:06 |
| klindgren | devananda, sorry - was getting some lunch | 19:06 |
| linggao | one from dguerri in the blueprint I pointed to you | 19:06 |
| klindgren | Anvil is a project headed up by yahoo to help package openstack from source into rpm's currently but in the future debian packages as well | 19:06 |
| jbjohnso | in the plurality case, I wasn't sure what you decide.... for that matter I am curious how the target selection scheme works (passing NAA or something like it or something else) | 19:06 |
| linggao | jbjohnso, are you saying that we cannot get accurate disk size from ipmi? | 19:06 |
| klindgren | it also lets you specific the code code base to use and lets you do any custom patches on top | 19:07 |
| Nisha | yes i saw them, but the example xml i pasted shows disk info | 19:07 |
| jbjohnso | linggao, well, you can do *anything* over ipmi messages, but using OEM commands... | 19:07 |
| jbjohnso | linggao, there are more usefully specific standard things (like inventory of all dimms by offering up the raw SPD) | 19:07 |
| klindgren | devananda, http://anvil.readthedocs.org/en/latest/ for some docs | 19:08 |
| jbjohnso | linggao, I'm unaware of a specific structure that can be related to disk attributes like say NAA or WWNN+LUN or what have you) | 19:08 |
| *** theDavidAiken has quit IRC | 19:08 | |
| jbjohnso | so such inventory to my knowledge exists as vendor-specific vocabulary | 19:09 |
| linggao | Nisha, my point in the comment is that since we cannot or hard to get correct info, I prefer we just display the inventory (properties), do not auto update the node. | 19:09 |
| jbjohnso | to the extent that vendor specific vocabulary can possibly be avoided, I get happier... for disk if it must be know whithout ever booting an in-band assessment agent, there isn't a rosy picture to be had | 19:09 |
| linggao | Nisha, as jbjohnso mentioned, there is no standard languange to pass for disk. | 19:10 |
| jbjohnso | in-band assessment can be very well informed through nicely neutral udevadm friends | 19:10 |
| *** hemna has joined #openstack-ironic | 19:10 | |
| linggao | jbjohnso, there will be a in-band discovery in IPA. | 19:11 |
| Nisha | linggao, jbjohnso, but same can be retrieved thru iLO | 19:11 |
| wanyen | however, if a vednor BMC has the capability to report total disk size , we should allow vendors to make use of that data | 19:11 |
| jbjohnso | of course even memory is not without it's faults. Inventory won't be accurate after manipulating the dimm contents but before firmware boot | 19:11 |
| jbjohnso | Nisha, the same what can be retrieved? | 19:11 |
| jbjohnso | nice thing about in band assessment is that it will never be cached data at time of retrieval | 19:12 |
| Nisha | the storage details | 19:12 |
| Nisha | the example xml i have pasted in the design spec resolution comments | 19:13 |
| Nisha | <PHYSICAL_DRIVE> <LABEL VALUE = "Port 5I Box 1 Bay 1"/> <STATUS VALUE = "OK"/> <SERIAL_NUMBER VALUE = "6SL7H2DP0000B41800T9"/> <MODEL VALUE = "EF0600FARNA"/> <CAPACITY VALUE = "558 GB"/> <LOCATION VALUE = "Port 5I Box 1 Bay 1"/> <DRIV | 19:13 |
| jbjohnso | Nisha, don't see wwnn+lun or naa in there ;) | 19:14 |
| Nisha | what is naa? | 19:14 |
| jbjohnso | well, it matters more with virtual luns | 19:14 |
| jbjohnso | well, vrtual is a bad word | 19:14 |
| Nisha | logical drive? | 19:14 |
| jbjohnso | but if you have a san controller and you create a lun | 19:15 |
| Nisha | yes u can | 19:15 |
| jbjohnso | then you can get a viable naa to identify it | 19:15 |
| Nisha | <CONTROLLER> <LABEL VALUE = "Controller in Slot 1"/> <STATUS VALUE = "OK"/> <CONTROLLER_STATUS VALUE = "OK"/> <SERIAL_NUMBER VALUE = "PDVTF0BRH5L0EA"/> <MODEL VALUE = "HP Smart Array P822 Controller"/> <FW_VERSION VALUE = "4.68"/> <CACHE_MODULE_STATUS VALUE = "OK"/> <CACHE_MODULE_SERIAL_NUM VALUE = | 19:15 |
| jbjohnso | but not so much a viable serial number | 19:15 |
| jbjohnso | so that's the controller | 19:15 |
| jbjohnso | well, specifically, a direct attach controller | 19:15 |
| Nisha | i cant paste the complete xml here, too big :) | 19:15 |
| jbjohnso | as opposed to a SAN controller (e.g. netapp or emc) | 19:16 |
| jbjohnso | in any event, 'do not let the enemy be the perfect of the good' and all | 19:16 |
| linggao | Nisha, wait | 19:16 |
| *** ellenh has quit IRC | 19:16 | |
| jbjohnso | but I guess people should be mindful that there will be circumstances beyond the reach of out-of-band inventory, even sticking with a server vendor that tries to do a pretty thorough job of it | 19:17 |
| linggao | Nisha, you can use http://paste.openstack.org/ to paste. | 19:17 |
| jbjohnso | put in some SAN or pcie adapters and things can go all over the place quickly | 19:17 |
| linggao | and put the link here. | 19:17 |
| Nisha | ok. | 19:17 |
| jbjohnso | and state can be stale and context impractical or inaccurate | 19:17 |
| jbjohnso | of course, being at a vendor that also does it's best to assure that inventory is accurate I probably should not be so discouraging... | 19:18 |
| Nisha | :) | 19:19 |
| jbjohnso | though we are doing some reduced cost offerings that eschew the expensive restrictions required... | 19:19 |
| jbjohnso | to get the inventory 95% of the way there... | 19:19 |
| jbjohnso | I just hate things where we can really only get 95% of the way there.. | 19:20 |
| Nisha | jbjohnso, linggao, anyway i have proposed as of now only the disk size as the property to be discovered | 19:21 |
| Nisha | that anyway is needed for scheduling properties | 19:21 |
| jbjohnso | Nisha, what do you do about plurality of volumes? | 19:21 |
| jbjohnso | oh, so memory isn't a scheduling property? | 19:22 |
| jbjohnso | oh, we are talking about disk volumes... | 19:22 |
| Nisha | yes it is also | 19:22 |
| linggao | jbjohnso, memory and cpu are. | 19:22 |
| jbjohnso | ok, but the comment was just talking about the only storage property of interest at the moment | 19:22 |
| linggao | are you saying that memory is not accurate neither? | 19:22 |
| jbjohnso | linggao, well, it's unlikely, but it can be inaccurate | 19:22 |
| jbjohnso | linggao, an off system won't update dimm contents if a dimmi s added or removed | 19:23 |
| jbjohnso | but that's probably enough of a corner case to not sweat too bad | 19:23 |
| Nisha | the storage property can be rediscovered for a node if storage is updated | 19:23 |
| jbjohnso | storage fabrics can make the storage inventory a bit more sloppy | 19:23 |
| Nisha | means all the properties can be rediscovered | 19:23 |
| jbjohnso | Nisha, well, with the server off it will ramp up the memory controller enough to take stock? | 19:24 |
| Nisha | jbjohnso, could u explain "plurality of volumes"? | 19:24 |
| jbjohnso | Nisha, you have 2 disks, which disk do you care about? | 19:24 |
| devananda | klindgren: ok, got it. so - what are you lokoing for from us? | 19:24 |
| devananda | klindgren: there are alraedy folks packaging ironic for deb/rh | 19:24 |
| jbjohnso | you have 2 local disks, they are to be raided but not raided yet, and you also have visibility let's say to 3 san volumes... | 19:24 |
| klindgren | devananda, I didn't see anything from redhat.... but I did see stuff from suse | 19:25 |
| jbjohnso | or no local disks but 3 san volumes with an intent to boot one particular one (and the 3 are spread across two discrete storage subsystems... | 19:25 |
| Nisha | how do we do manually today for ironic | 19:25 |
| klindgren | the spec is largely based upon suse's spec file. More that the service names and packages seem correct | 19:25 |
| *** hemna has quit IRC | 19:25 | |
| jbjohnso | ok, so just a 'helpful best guess' | 19:26 |
| Nisha | how does the admin choose them today when he configures manually | 19:26 |
| jbjohnso | not intended to be perfect perfect | 19:26 |
| jbjohnso | Nisha, well, so one thing is whether it is manually configured or not | 19:26 |
| jbjohnso | Nisha, e.g. in the san case, we've done situations where software is auto-creating a lun with intent clear | 19:26 |
| jbjohnso | Nisha, and it relays that intent by flagging the NAA to the deployment tool | 19:26 |
| jbjohnso | so the os deployment says 'hey, I should touch this one and only this volume' | 19:27 |
| *** bandicot has quit IRC | 19:27 | |
| Nisha | ok | 19:27 |
| devananda | klindgren: i'm not teh best person to ask about packaging -- GheRivero would probably be more help | 19:27 |
| jbjohnso | but again, that's a scenario with very end to endautomation | 19:27 |
| jbjohnso | so other environments may benefit from a best guess | 19:27 |
| wanyen | Ironic does not support boot from SANyet. Si, I think it should be covered by cinder and ironic discussion. | 19:28 |
| Nisha | jbjohnso, i emant we can consider scenarios how disk size is manually provided today | 19:28 |
| devananda | klindgren: i'm a little confused by this. why is it installed as "openstack-ironic-api" instead of "ironic-api" ? | 19:28 |
| jbjohnso | wanyen, does it support 'don't screw up visible san volumes?' ;) | 19:28 |
| devananda | klindgren: oh - that's just the init script. nvm :) | 19:29 |
| jbjohnso | wanyen, e.g. an os deployment facility that is ruthless would ideally pick the local single hard drive over then 500TB san volume.. | 19:29 |
| klindgren | devananda, all of the openstack init script just have openstack-<project>-<service> | 19:29 |
| devananda | yep yep | 19:29 |
| devananda | i misraed and thougt that was the bin/* name | 19:29 |
| klindgren | ah yea - that wouldn't be good | 19:30 |
| klindgren | :-) | 19:30 |
| devananda | klindgren: this doesn't seem to contain any of the non-python deps | 19:30 |
| devananda | klindgren: eg, tftpd, tgtadm, etc. should it? | 19:30 |
| devananda | klindgren: or is that being left to the deployer to know what to install to get the conductor working in their config | 19:30 |
| devananda | as some of those are optional // have multiple packages which could satisfy the requirement | 19:31 |
| wanyen | so how does in-band discovery solve all disk size problems? | 19:31 |
| devananda | nisha, wanyen, jbjohnso - one problem with reporting disk size(s) is modelling the entire disk topology. available storage is variable if there is a hardware RAID controller | 19:31 |
| jbjohnso | wanyen, it probably more helps a scenario which I suspect is not covered, automated end to end configuration and the ability of external components to relay identifiers and be correlated | 19:32 |
| linggao | Nisha, again. Since there is no standard language in IPMI to parse disk. I think let's not get too aggressive here to auto-update-node. We just display the the hardware inventory as a MangementInterface function. | 19:32 |
| jbjohnso | linggao, and the lack of a standard vocablary, though that can be mapped.. | 19:32 |
| klindgren | devananda, actually - thats a good catch - it should spell out all the requirements that are needed for boot -outside of python | 19:32 |
| jbjohnso | each vendor would have to provide their own layer and ideally a user need not fret about manually selecting the layer | 19:32 |
| anteaya | JayF: good that you got your voice out there | 19:32 |
| linggao | jbjohnso, and accuracy as you mentioned is another problem. | 19:33 |
| anteaya | before the thundering herds ignore it | 19:33 |
| devananda | klindgren: happy to help | 19:33 |
| *** vinbs has joined #openstack-ironic | 19:33 | |
| JayF | anteaya: I am a buffalo | 19:33 |
| JayF | anteaya: and I herd that | 19:33 |
| jbjohnso | lifeless, yes, though it might be a 'better than nothing' approach for less ambitious circumstances... (to be devil's advocate since I really don't live and breath the openstack infrastructure yet) | 19:33 |
| *** sacharya has joined #openstack-ironic | 19:34 | |
| jbjohnso | linggao, I meant you... | 19:34 |
| harlowja | devananda a quick summary of anvil, anvil sucks down all the various openstack components, analyzes there requirements files and finds the master list of requirements that works across all the downloaded compoents, then can build (using these spec files) a unified set of rpms (in the future debian?) that are built from the downloaded components (and the unified requirements master list), and then u can put those rpms in yum | 19:34 |
| harlowja | repo somewhere and later install from that | 19:34 |
| jbjohnso | I should really start typing more than two chars before tab.. | 19:34 |
| wanyen | Linggao- I think auto update the node or not could be a driver choice. | 19:34 |
| harlowja | devananda yahoo uses it and godaddy (and others?) for building openstack components from git into packages | 19:35 |
| harlowja | *in an automated way* | 19:35 |
| klindgren | devananda, is their a list of those external requirements somewhere that I could look at? (tftpd, tgtadm)? | 19:35 |
| *** bmahalakshmi has quit IRC | 19:35 | |
| harlowja | *it also has capabilities to install those rpms locally and such for developers (if they want to go this way) | 19:35 |
| linggao | jbjohnso, :) | 19:35 |
| linggao | jbjohnso, thanks for all the info you have given us. | 19:36 |
| *** sysexit has quit IRC | 19:36 | |
| devananda | klindgren: take a look in devstack .... :( | 19:36 |
| harlowja | http://anvil.readthedocs.org/en/latest/topics/summary.html (is a good summary) | 19:37 |
| devananda | harlowja: thanks for the summary! | 19:37 |
| Nisha | linggao, jbjohnso, as wanyen said it can be driver choice to auto update the node for disk size | 19:37 |
| harlowja | devananda np :) | 19:37 |
| Nisha | is that fine? | 19:37 |
| *** vinbs has quit IRC | 19:38 | |
| linggao | Nisha, can we split it into two parts. First, make display working. Then propose auto-create and auto-update. For auto discovery, discovering and configuring BMCs may be very important too. | 19:39 |
| Nisha | make display working means? | 19:39 |
| jbjohnso | on that subject, if, hypothetically, something cropped up that could provide that service as a long-running component | 19:39 |
| jbjohnso | would that be of interest? to show autodetected pxe and service processors? | 19:40 |
| linggao | Nisha and wanyen, expecially there will be auto discovery of the node properties in-band in IPA soon. | 19:40 |
| jroll | heh | 19:40 |
| jroll | "soon" | 19:40 |
| linggao | jroll, I made a promise for you, lol. Do not sweat. | 19:41 |
| wanyen | The out-of-band discovery is an alternative to IPA in-band discovery. | 19:41 |
| jbjohnso | fyi that is my current project to extend confluent to be able to detect various management and pxe things (and to control the latter) | 19:41 |
| jroll | linggao: :) | 19:41 |
| linggao | wanyen, I understand, if it can get accurate information. | 19:41 |
| jbjohnso | well, I guess control both... | 19:41 |
| wanyen | it is useful for drivers that uses out-of-band operatins | 19:41 |
| wanyen | I like to undersatdn how in-band discovery solves all the different storage configuration, e.g., SAN, RAID, ..etc | 19:43 |
| jbjohnso | wanyen, well, two pieces | 19:43 |
| jbjohnso | wanyen, for one, it eliminates a great deal of vendor to vendor code branching | 19:43 |
| jbjohnso | three pieces | 19:44 |
| jbjohnso | for another, the in band scheme is very much what you see is what you get at the moment of collection with a pretty strong guarantee, since storage inventory tends to be a push from storage adapter to service processor.. | 19:44 |
| jbjohnso | and finally, the inventory doesn't have every attribute that might be relevant for safe deployment anyhow in an orchestrated environment | 19:45 |
| linggao | I think that's all handled by OS right? | 19:46 |
| jbjohnso | out-of-band is proprietary agreements between HCA and controller vendors and service processor vendors, whereas in-band is highly standard SCSI and FCP thingamajigs. | 19:46 |
| wanyen | How would in-band discovery know which SAN voluem to use? | 19:46 |
| linggao | brb | 19:46 |
| jbjohnso | wanyen, in a wider orchestration sense, the lun proviosioning software talking to netapp or emc has a chance to pass a recognizable unique id to the deployment facility | 19:47 |
| wanyen | Yes. out-of-band discovery is meant for vendor-specific drivers | 19:47 |
| jbjohnso | wanyen, I haven't seen a host service processor ever provide a very viable inventory of SAN volumes | 19:48 |
| wanyen | We want to support SAN volume through Cinder so Cinder wil choose a vloume. | 19:48 |
| * linggao back | 19:49 | |
| wanyen | That's teh reason I think SAN will be a subject that needs to get Cinder involves | 19:51 |
| jbjohnso | So in short, there's a data model that can either be blank or have some driver driven guesses that can then be fixed manually | 19:53 |
| jbjohnso | I suppose that's better than being unhelpful | 19:53 |
| Nisha | jbjohnso: linggao so you are ok with the given proposal for disk inventory? | 19:54 |
| Nisha | linggao: if yes, we move to next comment. that is to standardize the CLI along with node-create/node-update | 19:55 |
| jbjohnso | I only describe my thoughts, I make no judgement calls ;) | 19:56 |
| Nisha | linggao: there? | 19:57 |
| jbjohnso | I have more ambitious desires, but that does not preclude me being accepting of other solutions if I think they wouldn't interefere with a better way down the road | 19:57 |
| linggao | Nisha, from ipmi stand point, I do not feel parsing the text that are not standalized. I am in favor of just displaying the hard inventory for Juno release. But I can be flexible on auto update if you think iLO can give you accurate info. Let's see what other folks say. | 20:00 |
| *** sysexit has joined #openstack-ironic | 20:00 | |
| Nisha | ipmi and ilo will get sam information from a baremetal | 20:00 |
| Nisha | same* | 20:01 |
| Nisha | linggao: i think even ipmi has documented health information publicly available. | 20:02 |
| jbjohnso | I need to create vendor extensibility and add IBM extensions as an example to pyghmi | 20:02 |
| jbjohnso | health or inventory? | 20:02 |
| Nisha | this information is retrieved from health information only | 20:03 |
| jbjohnso | Nisha, the disk size is health? | 20:03 |
| jbjohnso | I would have probably considered 'get sensor reading' as directed by the SDR as health-y stuff | 20:03 |
| Nisha | :) i didnt mean that | 20:03 |
| linggao | Nisha, these are different categories. | 20:04 |
| Nisha | Ok i think probably ilo and ipmi differs there | 20:04 |
| jbjohnso | and get fru as the mechansim to get fru data with oem content (though we do have oem commands for some health and inventory stuff) | 20:04 |
| Nisha | yes i know OEM comamnds are there | 20:04 |
| jbjohnso | but I was going to model under 'get_sensors' (and by extention 'get_health') a lookup table based on vendor (which would also be fed product id if it matters to said vendor) | 20:05 |
| Nisha | which get health information, since i dont understand the raw imput/output much for ipmi i am not sure if it has disk information or not | 20:05 |
| jbjohnso | for any 'health' type data whatever thatmeans | 20:05 |
| JayF | There's kinda an interesting dependency being talked about in some of this -- how do you intend the BMCs themselves to get IPs in this kind of discovery context? | 20:05 |
| jbjohnso | for inventory, same deal, an oem hook to go (with raw sdr and fru available in both cases) | 20:05 |
| Nisha | ok | 20:06 |
| jbjohnso | JayF, if we are talking about utterly automagic, the way we have done it is one of two ways | 20:06 |
| jbjohnso | JayF, the vendor agnostic way is 'pxe first', where the service processor has no or not viable or just don't care config | 20:06 |
| lifeless | My plan for BMC ip management is to register the BMC's with neutron directly | 20:06 |
| lifeless | DC ops get BMC MAC, API call to neutron to create a port on the BMC network. Done. | 20:07 |
| jbjohnso | the other is to scan and/or sense the presence of entities on network segments | 20:07 |
| JayF | jbjohnso: Yeah my main problem with discerning that is how you tie BMC IP <> Hardware in the case | 20:07 |
| JayF | jbjohnso: like if you PXE boot the hardware we're running, there's no way to determine BMC IP from a running OS | 20:07 |
| jbjohnso | JayF, in the pxe first case, by using ipmitool commands to configure the service processor the way you know it should be | 20:07 |
| JayF | jbjohnso: assuming your BMC is truly isolated, that doesn't work | 20:07 |
| jbjohnso | JayF, determining is lame, focing the correct configuration is good | 20:07 |
| jbjohnso | JayF, when you say 'truly' isolated | 20:08 |
| jbjohnso | JayF, I presume you mean no KCS or BT relation? | 20:08 |
| jroll | separate physical BMC network. | 20:08 |
| jroll | as you should | 20:08 |
| jroll | because every BMC can be presumed to be insecure | 20:09 |
| jbjohnso | jroll, right, but that says nothing about whether ipmitool on the node can work over KCS or BT | 20:09 |
| jroll | idk what KCS or BT are | 20:09 |
| lifeless | Me neither | 20:09 |
| lifeless | I was just about to ask | 20:09 |
| jbjohnso | /dev/ipmi0 | 20:09 |
| jbjohnso | modprobe ipmi_devintf | 20:09 |
| lifeless | oh, local mode? | 20:09 |
| jbjohnso | and maybe ipmi_si (though that is likely compiled in) | 20:09 |
| jbjohnso | right | 20:09 |
| jbjohnso | so you pxe boot node | 20:09 |
| devananda | russell_h: nice dash board integration! also, I didn't know ya'll had remote usage monitoring going on yet. | 20:09 |
| lifeless | So more recent hardware is locking access to the BMC locally down | 20:09 |
| JayF | jbjohnso: that's blocked via firmware in the devices we're using | 20:09 |
| lifeless | (e.g. moonshot) | 20:09 |
| jbjohnso | then node knows what the BMC is supposed to be configured | 20:09 |
| jbjohnso | in a case where KCS/BT is forbidden from working, then you must rely upon service processor first | 20:10 |
| jroll | devananda: before this project, russell was a manager for our cloud monitoring product :P | 20:10 |
| jbjohnso | service processor first is something that is far lest standardized | 20:11 |
| jbjohnso | but for example, you scan for service processors as they are accurately configured | 20:11 |
| jroll | devananda: it's just a little agent that you install: http://www.rackspace.com/cloud/monitoring/ | 20:11 |
| jbjohnso | and then for the candidates, you allow for manual or automatic relationship | 20:11 |
| jbjohnso | e.g. we identify the attached switch port and based intended service processor based on that in xCAT | 20:12 |
| devananda | jroll: ah, nice | 20:12 |
| JayF | devananda: a large number of us on the project were former Cloud Monitoring (me, russell, paul) | 20:12 |
| jbjohnso | then we connect out of band to said piece and inventory gives us hint for correlation (e.g. UUID as it appears in DMI table) | 20:12 |
| JayF | devananda: honestly, running that system made me wish I had real hardware available via API... so here we are :) | 20:12 |
| jbjohnso | so that's the service processor first scheme | 20:12 |
| JayF | jbjohnso: that would work, like using a serial in the fru data to map in-band to out-of-band | 20:13 |
| jbjohnso | JayF, well, the best one is 'get system uuid' | 20:13 |
| jbjohnso | JayF, since that readily appears in a PXE discover packet, you can make the bind without ever entering a kernel | 20:13 |
| *** hemna has joined #openstack-ironic | 20:13 | |
| jbjohnso | in fact, that sort of discovery (where the binding appers after the pxe discover is sent just in time for the offer) is one of the things I'm gunning for in my toy | 20:15 |
| jbjohnso | I clearly should have played with more conventional toys in my childhood... | 20:15 |
| jbjohnso | JayF, there will be of course be two distinct cases driving the need for node first and service processor first | 20:16 |
| Nisha | Thanks for the discussion guys , but are we OK with the given proposal or you see modification required for disk size? | 20:16 |
| jbjohnso | JayF, node first for cases where the service processor might not bereachable by default until configured in band | 20:16 |
| jbjohnso | JayF, and service processor first for less open ended out of band state (and in fact mandated by architectures that refuse in-band) | 20:17 |
| jbjohnso | service processor first does require something to understand some proprietary behavior and vocabulary at the moment | 20:17 |
| jbjohnso | well, except for manually configured targets | 20:18 |
| jbjohnso | e.g. in the IBM case, understanding how it behaves with respect to SLP and what attributes are used and what default credentials are to be employed and what protocols are enabled/disabled by default | 20:18 |
| jbjohnso | default credentials can have an static, algorithmic, or user by user customized situation | 20:19 |
| jbjohnso | anyway, I'm manifesting uncategorized detected elements in my toy under a '/detected/' collection | 20:19 |
| jbjohnso | when something enters the collection, it is to be vetted against enclosure and network identifier maps to see if it matches something | 20:20 |
| jbjohnso | if match, automagic happens and you have your node ready to go one way or the other | 20:20 |
| Nisha | ok, but we can under properties even | 20:20 |
| jbjohnso | JayF, I have spent an unhealthy amount of time living in the world of cardboard box to manageable for thousands of systems... | 20:21 |
| *** sysexit has quit IRC | 20:22 | |
| linggao | Nisha, I am thinking of how end user is uisng this function. | 20:22 |
| *** dwalleck has joined #openstack-ironic | 20:23 | |
| linggao | Nisha, user run ironic node-update, then you have to tell them that the disk size is just the best guess. | 20:23 |
| linggao | Nisha, then tell them to run IPA node discovery to get it updated. | 20:23 |
| Nisha | hmmm if u want a manual step here by an admin then we can have all the disks details in a sub-dictionary in properties | 20:24 |
| linggao | my question is why bother have the first step? | 20:24 |
| Nisha | then admin can select from the sub-dictionary and manually assign disk size as he does today | 20:25 |
| *** ellenh has joined #openstack-ironic | 20:26 | |
| jroll | I'm of the opinion that if you're running IPA, you won't be doing any OOB discovery | 20:26 |
| Nisha | the disk properties can be rediscovered if required during deploy (thats what i understand you meant by having "run IPA node discovery to get it updated") | 20:27 |
| jroll | register a node, Ironic PXE boots IPA, IPA sends back hardware info | 20:27 |
| JayF | jroll: there will have to be some interaction with OOB though | 20:27 |
| jroll | Ironic optionally shuts the node back down | 20:27 |
| jroll | for why | 20:27 |
| jbjohnso | jroll, I think that's the most robust strategy at least | 20:27 |
| JayF | jroll: to map OOB interface information (what is your BMC IP?) to IN-Band information | 20:27 |
| JayF | jroll: ironic can't 'shut the node back down' if it knows nothing of the bmcs | 20:27 |
| wanyen | <Jroll> exactly. If a user eitehr choose IPA or OOB driver | 20:27 |
| jroll | JayF: you register BMC IP when registering the node | 20:27 |
| jbjohnso | JayF, though that can be done in the pre-boot phase | 20:27 |
| JayF | jroll: then it's not discovery | 20:27 |
| JayF | jroll: it's only slightly less manual at that point than what we've already done | 20:28 |
| devananda | regarding using "ironic node-update" to initiate discovery -- this doesn't make sense to me | 20:28 |
| jroll | JayF: everyone else is talking about "when you register a node, it discovers hardware" | 20:28 |
| JayF | oh. that's less exciting. | 20:28 |
| devananda | could someone explain how that is being proposed to work? | 20:28 |
| *** blamar has joined #openstack-ironic | 20:28 | |
| jroll | JayF: I'd rather have "when you plug in a new node, it self-registers" | 20:28 |
| JayF | jroll: +1 | 20:28 |
| jroll | JayF: but that's harder | 20:28 |
| jroll | JayF: because auth | 20:28 |
| jbjohnso | jrist, JayF well, we have that model operational in xCAT.... | 20:28 |
| devananda | jroll: so, auth. "autodiscover new hardware" is what everyone wants | 20:29 |
| jbjohnso | jroll, I could chat all day about that | 20:29 |
| devananda | baby steps | 20:29 |
| devananda | let's go first for "enroll minimal info, let irnic *interrogate* the hardware" | 20:29 |
| JayF | I think the agent is incredibly well suited for that | 20:29 |
| jroll | devananda: of course :) I'm saying we should start with "give ironic a BMC IP, let it figure everything else out" | 20:29 |
| devananda | to discover any additional properties | 20:29 |
| jbjohnso | I favor formulaic datacenter description for large systems and automagically filling in the gaps | 20:29 |
| devananda | jroll: yes | 20:29 |
| wanyen | <deva> ironic node-update can be used to re-discover if hw changes | 20:29 |
| JayF | I just don't think we'd be as likely to gain benefit from it. But we're only one use case :) | 20:29 |
| jrist | :) | 20:29 |
| devananda | wanyen: how and why | 20:29 |
| jroll | JayF: our bootstrap script would be much smaller :P | 20:30 |
| devananda | wanyen: node-updaet is a means for the user to *update* the node. not request that smoe action be performed | 20:30 |
| devananda | well. today it is | 20:30 |
| devananda | taht could change :) | 20:30 |
| wanyen | <deva> if adding NICs or replace hardwae components | 20:30 |
| devananda | but let me reword that | 20:30 |
| * jroll hates the thought that hardware will be changed while registered in ironic | 20:30 | |
| devananda | node-update is a way for the user to pass known-information to Ironic | 20:30 |
| jbjohnso | so if there was a service which gave a structure of detected elements (pxe and/or service processors, chassis managers, etc), who all might want to discuss that design? | 20:30 |
| jbjohnso | since I'm in process of building such a capability now.. | 20:31 |
| jroll | jbjohnso: so, regarding structure... | 20:31 |
| * jroll finds something | 20:31 | |
| devananda | wanyen: so if a NIC were replaced, I would use "irnoic port-update" to supply the new MAC address | 20:31 |
| wanyen | node-update does not do automatic discovery. It only does that if "--discover" is specified | 20:32 |
| devananda | wanyen: if I need Ironic to interrogate the hardware because I do not know the new MAC address, I wold not use ndoe-update | 20:32 |
| devananda | ah, i see | 20:32 |
| jbjohnso | jroll, something? | 20:32 |
| devananda | wanyen: so i'm thinking of the REST API -- and the CLI as an extension of that. how does "--discover" look to the REST API ? | 20:32 |
| linggao | devananda, Nisha proposed a design sepc that you wanted to take a look. In there it will use "ironic node-create" or "ironic node-update" command to put cpu/memory/disk/mac info for the node by querrying BMC under the cover. | 20:33 |
| Nisha | devananda : it will be like : ironic node-update <node_uuid> --discover <true/false> | 20:34 |
| devananda | that's the CLI | 20:34 |
| Nisha | Yes | 20:34 |
| wanyen | <deva> NIC update is just an example, Ther could be more hardware changes than just NIC. So we thought provding "--discover" option is a convinent way to re-discover and update node properties. | 20:34 |
| jroll | jbjohnso: I can't find it :( | 20:34 |
| devananda | what is the proposed REST API for this functin? | 20:34 |
| linggao | The issue with that is that you cannot get accurate disk size from out-of-band. jbjohnso has a long explaination to it. | 20:34 |
| jroll | jbjohnso: but with this review, we've been working on a giant json blob describing hardware: https://review.openstack.org/#/c/92847 | 20:34 |
| jroll | jbjohnso: but I can't find what the output looks like at the moment | 20:34 |
| Nisha | The existing REST API patch and post will be modified for it | 20:35 |
| adam_g | Shrews, ping | 20:35 |
| devananda | Nisha: modified how? | 20:35 |
| Nisha | Example prototype looks like : | 20:35 |
| linggao | devananda, besides, IPMI output does not have standard text for disks because of different vendors uses different text. | 20:35 |
| Nisha | 1. node.create() | 20:36 |
| Nisha | 2. call ManagementInterface() function | 20:36 |
| Nisha | which updates the properties filed of the node object | 20:36 |
| Nisha | 3. if create_ports option provided on command line, create ports for the mac addresses returned | 20:37 |
| devananda | Nisha: that's not the REST API either -- taht's the ConductorManager | 20:37 |
| Shrews | adam_g: sup? | 20:37 |
| devananda | Nisha: how does this change -- http://docs.openstack.org/developer/ironic/webapi/v1.html#nodes | 20:37 |
| Nisha | Why, NodesController Class is under REST APIS, correct? | 20:38 |
| devananda | Nisha: do support a PATCH /v1/nodes/NNNN which will perform this function | 20:38 |
| adam_g | Shrews, re: that tempest rebuild flag.. is it expected that rebuild is going to be supported across all ironic drivers? | 20:38 |
| devananda | Nisha: without breakign backwards compatibility | 20:38 |
| Shrews | adam_g: no, which is why i added it | 20:38 |
| Shrews | adam_g: oh, wait.... drivers.... | 20:38 |
| Nisha | devananda: Thanks, i will add that to design spec | 20:39 |
| devananda | jroll: will IPA support rebuild --preserve-ephemeral? | 20:39 |
| Shrews | adam_g: i don't see why not | 20:39 |
| devananda | jroll: eventually | 20:39 |
| devananda | Nisha: thanks :) | 20:39 |
| jroll | devananda: I guessssssss | 20:39 |
| lifeless | tripleo depends on it | 20:39 |
| jroll | devananda: I don't believe in --preserve-ephemeral, ideologically | 20:39 |
| lifeless | if you want to move to IPA being default... | 20:39 |
| jroll | devananda: but we will support it | 20:39 |
| Nisha | linggao: devananda last comment on the design spec is to have standard CLI for it | 20:40 |
| jroll | lifeless: we will support everything pxe driver supports, no worries (even if I don't like it) | 20:40 |
| Nisha | Do we really want to have one even when node-create and node-update are being modified to do so | 20:40 |
| JayF | and we /really/ don't like --preserve-ephemeral :( | 20:40 |
| jroll | JayF: that's just like, your opinion, man | 20:41 |
| devananda | Nisha: the CLI is an implementation of a python client which speaks to the RESTful API | 20:41 |
| * Shrews loves that "ephemeral" is used for partitions that don't have to be ephemeral | 20:41 | |
| Nisha | Yes | 20:41 |
| JayF | Shrews: very yes | 20:41 |
| JayF | also the entire concept of 'replace my OS, leave the data' is scary to me from an operational standpoint | 20:41 |
| JayF | if that's the model you want, put your data on cinder, and spin up a *new* node and attach your volume to it | 20:42 |
| lifeless | JayF: ever hear of cinder? | 20:42 |
| Nisha | devananda: But as per proposal we are modifying the node-create and node-update CLI with the options for discovery feature | 20:42 |
| JayF | but it doesn't matter, as I said the other day I joined openstack much too late to have this argument | 20:42 |
| lifeless | JayF: this is the equivalent for LCD hardware | 20:42 |
| lifeless | bn;/.B9~' | 20:42 |
| devananda | Nisha: but your proposal does not describe how that is implemented on the REST API | 20:42 |
| lifeless | bah, sorry. | 20:42 |
| JayF | so I'm sure we'll take our medicine and implement that :( | 20:42 |
| JayF | lifeless: lcd hardware? | 20:42 |
| lifeless | lowest common denominator | 20:42 |
| devananda | Nisha: it says only "Modify existing PATCH /v1/nodes/patch to call new rpcapi function and the port-create functions." | 20:42 |
| lifeless | commodity | 20:43 |
| lifeless | vs required a hardware SAN | 20:43 |
| *** theDavidAiken has joined #openstack-ironic | 20:43 | |
| Nisha | devananda: for my prototype i modified the "post" and "patch" methods | 20:43 |
| devananda | Nisha: please describve those changes in the spec :) | 20:43 |
| Nisha | Ok, will add that :) | 20:43 |
| devananda | Nisha: not just "call the rpc method" -- the spec need to describe what different API endpoints or functions are exposed | 20:44 |
| devananda | thanks! | 20:44 |
| lifeless | JayF: what rebuild --preserve-ephemeral does is the closest approximation we know of to cinder + attach. | 20:44 |
| Nisha | so a seperate CLI si not needed for this, correct? | 20:44 |
| jroll | lifeless: it's fine, we'll be implementing it. JayF is just extra opinionated today :) | 20:44 |
| *** rch has joined #openstack-ironic | 20:44 | |
| devananda | Nisha: changes to the python-ironicclient project (our CLI) will be required, yes | 20:44 |
| Nisha | devananda: sure will do that | 20:45 |
| JayF | lifeless: I disagree, but it doesn't matter, because the decision was made well before I was an Openstack contributer, so like I said I'm sure we'll end up implementing it whether we like it or not. | 20:45 |
| * devananda needs to run and move car before gettign a ticket | 20:45 | |
| devananda | bbiab! | 20:45 |
| Nisha | Thanks devananda jbjohnso linggao wanyen for the discussion | 20:45 |
| linggao | bye devananda. | 20:45 |
| Nisha | very late now, need to get some sleep | 20:45 |
| lifeless | JayF: I'd love to hear your suggestions for an alternative. Really - if we can do something better, lets. | 20:45 |
| linggao | thank you Nisha | 20:45 |
| linggao | good night Nisha | 20:45 |
| Nisha | Thanks linggao | 20:45 |
| Nisha | bye gn | 20:46 |
| linggao | :) | 20:46 |
| lifeless | JayF: but saying 'I hate X and waah waah it happened before I joined' is not constructive | 20:46 |
| jbjohnso | jroll, fyi, I was thinking a skeleton set of idenetfier data until fleshed out | 20:46 |
| lifeless | JayF: and its not inclusive | 20:46 |
| JayF | lifeless: Arguing about it when my opinion has no alternative other than 'we shouldn't do this at all' isn't constructive either :x | 20:46 |
| jbjohnso | jroll, an 'unknown' node may enumerate mac addresses, uuid, but wouldn't do an exhaustive inventory until categorized | 20:46 |
| JayF | lifeless: not trying to troll or being not constructive | 20:47 |
| lifeless | ok | 20:47 |
| lifeless | so - we're still in the status quo - we don't have a better alternative | 20:47 |
| JayF | lifeless: so like I said, we'll end up implementing it. Other people need it, and it's important to us to support upstream even if our use cases don't always align. | 20:48 |
| Shrews | adam_g: hrm, you raise an interesting point (rebuild is part of nova, not ironic), but it's the ironic driver that actually implements the rebuild (and thus a feature of ironic). I can't make up my mind if that should be a tempest config option of compute or baremetal ... | 20:48 |
| adam_g | Shrews, is there any reason to skip it currently? | 20:50 |
| Shrews | adam_g: but we DO need the flag so we can skip it when we test older stable releases (which we arent' doing yet) | 20:51 |
| Shrews | so, stable/icehouse | 20:51 |
| *** Nisha has quit IRC | 20:52 | |
| Shrews | adam_g: this was something devananda brought up yesterday, and mentioned here: https://review.openstack.org/#/c/97834/3/README.rst | 20:52 |
| adam_g | Shrews, ah! | 20:52 |
| Shrews | adam_g: i'm just flip-flopping on where it should reside now :/ | 20:53 |
| Shrews | i can't think of a solid reason to not put it under compute now | 20:54 |
| *** linggao has quit IRC | 20:56 | |
| adam_g | Shrews, you may want to get other opinions from the -qa folk. | 20:56 |
| adam_g | someone brought a loud pomeranian to this coffee shop. i need to relocate back home. | 20:57 |
| *** jdob has quit IRC | 20:58 | |
| lifeless | Shrews: FWIW I want to add --preserve-ephemeral support to libvirt too | 20:59 |
| jbjohnso | JayF, I'm largely thinking that it can be ignored and scrapped when better comes along and that as an alternative to completely empty values, it might not be shabby | 20:59 |
| lifeless | Shrews: there was support for that in the original proposal, its just been ETIME since | 20:59 |
| lifeless | Shrews: dunno if that helps | 20:59 |
| jbjohnso | JayF, in other words, I'm not a fan either, but if I can ignore it, great (e.g. my attitude toward OpenLMI implementation) | 20:59 |
| jbjohnso | anyway, if I had some auto-detection stuff I'll maybe mention ithere, but I'll stop nagging people here with the minutia unless they want to in #confluent | 21:00 |
| *** coolsvap is now known as coolsvap|afk | 21:09 | |
| *** Mikhail_D_ltp has quit IRC | 21:11 | |
| *** dwalleck has quit IRC | 21:12 | |
| *** dwalleck has joined #openstack-ironic | 21:12 | |
| *** dwalleck has quit IRC | 21:16 | |
| *** jbjohnso has quit IRC | 21:17 | |
| devananda | adam_g, Shrews: so there's another wrinkle in the where-to-put-tempest-preserve-ephemeral-config-option discussion: taht ironic is an admin-only API *and* the test exercizing this is conencting to Nova, not ironic | 21:21 |
| devananda | Shrews: so ya, explaining this to QA folks and getting their opinion is def the right way to go | 21:22 |
| *** sysexit has joined #openstack-ironic | 21:24 | |
| devananda | JayF: fwiw, if you don't like something, work to change it in the minds of people. the code will follow. | 21:26 |
| JayF | devananda: I agree and understand, but maybe not so good at making the "Openstack shouldn't do this at all, userspace tools should" argument :) | 21:27 |
| JayF | devananda: BTW, thank you very much for being welcoming to us, it's a big day for those of us who've worked on this, and we've appreciated how welcoming the Ironic community has been | 21:28 |
| JayF | My only curiosity is if we immediately win the 'largest deployment of Ironic' award ;) | 21:28 |
| *** mrda-away is now known as mrda | 21:32 | |
| mrda | Morning Ironic! | 21:32 |
| devananda | JayF: depends. how large is your deployment? :) | 21:32 |
| devananda | mrda: g'morning | 21:32 |
| JayF | devananda: lets say it's hundreds of servers at the moment | 21:33 |
| devananda | lifeless: that actually might be a better question for you at this point ^ ? | 21:33 |
| JayF | jroll: do you think we can say the actual server count? seems relevant for proving a scaling model | 21:33 |
| JayF | jroll: and you're at least 90% less scaredy cat than I am about such things :) | 21:34 |
| *** openstackgerrit has joined #openstack-ironic | 21:34 | |
| JayF | devananda: our existing environment is managing 170 servers, with two conductors, two apis, all control plane running on vms | 21:36 |
| *** dwalleck has joined #openstack-ironic | 21:43 | |
| *** dwalleck has quit IRC | 21:44 | |
| lifeless | JayF: I can't really say :P - but I can say that our commercial edition is targeting multiple K's of servers. | 21:46 |
| lifeless | JayF: I can't really say because other teams are doing lots of scale testing etc | 21:47 |
| lifeless | JayF: and I'm not directly involved there - but I am with the overall arch | 21:47 |
| JayF | lifeless: that's fair. I think our intention is to get to multiple k's of servers too :) | 21:47 |
| *** sacharya has quit IRC | 21:58 | |
| *** sysexit has quit IRC | 22:02 | |
| *** hemna has quit IRC | 22:08 | |
| *** hemna has joined #openstack-ironic | 22:10 | |
| *** davidlenwell is now known as davidlenwell_ | 22:14 | |
| *** davidlenwell_ is now known as davidlenwell | 22:14 | |
| *** hemna has quit IRC | 22:25 | |
| *** ellenh_ has joined #openstack-ironic | 22:32 | |
| *** ellenh has quit IRC | 22:33 | |
| *** ellenh_ is now known as ellenh | 22:33 | |
| *** blamar has quit IRC | 22:34 | |
| *** openstackgerrit has quit IRC | 22:34 | |
| *** 20WAAHXAJ has joined #openstack-ironic | 22:36 | |
| *** radsy has joined #openstack-ironic | 22:36 | |
| *** sacharya has joined #openstack-ironic | 22:37 | |
| *** sacharya has left #openstack-ironic | 22:37 | |
| *** wanyen has quit IRC | 22:39 | |
| *** openstack has joined #openstack-ironic | 22:51 | |
| *** ellenh has quit IRC | 22:59 | |
| *** ellenh has joined #openstack-ironic | 23:05 | |
| *** ellenh has quit IRC | 23:11 | |
| *** ellenh has joined #openstack-ironic | 23:14 | |
| *** ellenh has quit IRC | 23:16 | |
| *** 20WAAHXAJ has quit IRC | 23:29 | |
| *** openstackgerrit has joined #openstack-ironic | 23:31 | |
| *** dwalleck has joined #openstack-ironic | 23:33 | |
| *** Abhishek has joined #openstack-ironic | 23:44 | |
| *** ellenh has joined #openstack-ironic | 23:44 | |
| *** dwalleck has quit IRC | 23:49 | |
| *** mdorman has quit IRC | 23:51 | |
| *** dwalleck has joined #openstack-ironic | 23:51 | |
| *** hemna has joined #openstack-ironic | 23:52 | |
| *** dwalleck has quit IRC | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!