| openstackgerrit | Devananda van der Veen proposed openstack/ironic: Add new enrollment and troubleshooting doc sections https://review.openstack.org/136202 | 00:03 |
|---|---|---|
| devananda | (I forgot we had a separate command for set maintenance mode) | 00:04 |
| devananda | (oh! I need more coffee) | 00:04 |
| NobodyCam | lol coffee is aways a good thing | 00:05 |
| NobodyCam | speaking of I should get some food | 00:12 |
| *** rushiagr_away is now known as rushiagr | 00:17 | |
| *** romcheg has quit IRC | 00:19 | |
| *** penick has quit IRC | 00:20 | |
| *** penick has joined #openstack-ironic | 00:24 | |
| JayF | https://review.openstack.org/#/c/136867/2 is tested working locally if anyone has devstack power to point at it | 00:26 |
| jroll | dtroyer is a good person to bug | 00:27 |
| jroll | (#openstack-qa) | 00:27 |
| Haomeng | JayF: +1:) | 00:28 |
| *** rushiagr is now known as rushiagr_away | 00:28 | |
| devananda | jroll: https://bugs.launchpad.net/ironic/+bug/1395946 | 00:28 |
| jroll | devananda: I completely agree, I raised this concern when people asked me to put that line there | 00:28 |
| jroll | do you think just removing it is ok? | 00:29 |
| jroll | also | 00:29 |
| jroll | "The PATCH mechanism was not actually deprecated or removed" | 00:29 |
| jroll | the goal was to do that | 00:29 |
| jroll | but that should have an api version bump | 00:30 |
| jroll | backwards compat is hard :| | 00:30 |
| openstackgerrit | Jim Rollenhagen proposed openstack/ironic: Remove useless deprecation warning for node-update maintenance https://review.openstack.org/136934 | 00:32 |
| jroll | devananda: at any rate, ^ | 00:32 |
| *** penick has quit IRC | 00:33 | |
| *** zhenzanz has joined #openstack-ironic | 00:42 | |
| JayF | adam_g: I'm digging down the libvirt path | 00:42 |
| JayF | adam_g: if we can reconfigure it to do the right thing, that'd be great | 00:42 |
| *** zhenzanz_ has joined #openstack-ironic | 00:42 | |
| devananda | jroll: cheers | 00:44 |
| devananda | also this: 00:30:07 < jroll> backwards compat is hard :| | 00:44 |
| jroll | yeah. | 00:45 |
| jroll | folks wanted to deprecate setting maintenance that way, idk if that's good or bad, consistency is nice to have | 00:46 |
| jroll | can have "micro-versions"? | 00:46 |
| adam_g | JayF, im fairly certain its a 'limitation' of qemu--there are alternatives to file logging (ie, tcp/telnet) | 00:46 |
| jroll | (which, to me, means real actual versioning) | 00:46 |
| *** zhenzanz has quit IRC | 00:47 | |
| *** zhenzanz_ is now known as zhenzanz | 00:47 | |
| devananda | mmm, micro-versioning the REST API ... that'd be great | 00:48 |
| jroll | yes | 00:48 |
| devananda | I mean, it sounds nice | 00:48 |
| devananda | also, a proposal to add PUT /v1/nodes is up -- https://review.openstack.org/#/c/130228/ | 00:48 |
| jroll | yeah, I don't really see the point in that, I guess | 00:49 |
| jroll | other than not having to diff? | 00:49 |
| JayF | adam_g: yeah, I'm well down the rabbithole now :P | 00:49 |
| jroll | I'm of the opinion that if you're changing a node, you should know what you're changing | 00:49 |
| JayF | adam_g: I also thought about things like adding a hook in the ssh driver to "rotate the logs" since that driver is essentially targetted at devstack | 00:51 |
| JayF | adam_g: but that seems like it could be a layering violation :P | 00:52 |
| adam_g | JayF, we just need to be able to spawn the equiv of 'while [ ! -f $console_log_file ]; do sleep 1; done; sudo tail -f $console_log_file >$DATA/logs/persistent_$console_log_file', which is hard to do given how devstack does its process tracking. might be easiest to just add a 1 line script to ./tools/ironic/ that it can call rather than the in-line scripting | 00:52 |
| *** ryanpetrello has quit IRC | 00:52 | |
| adam_g | run_process() or whatever gets used | 00:52 |
| JayF | adam_g: I'd be +1 to putting that script in | 00:53 |
| adam_g | JayF, ill poke at it tomorrow. i had a bunch of devstack hacking i wanted todo today but was side tracked with stable branch maintenance | 00:54 |
| JayF | tenfour | 00:54 |
| JayF | I'm just looking into this now and far into the rabbithole | 00:54 |
| JayF | because that log file getting blanked is no bueno :( | 00:55 |
| JayF | I'm thinking I change something IPA logs | 00:55 |
| JayF | I wanna validate it; I can't , because the log is all gone | 00:55 |
| JayF | etc etc | 00:55 |
| adam_g | yea | 00:55 |
| JayF | makes me glad that it didn't require more digging to get that low-hanging IPA change into devstack | 00:56 |
| JayF | would've been highly annoyed to put something in the image that does that for me then have it get nuked by libvirt on reboot, haha | 00:56 |
| *** ryanpetrello has joined #openstack-ironic | 01:02 | |
| jroll | devananda: so you're going to thank me for that patch without reviewing it? :P | 01:03 |
| *** r-daneel has quit IRC | 01:07 | |
| *** ChuckC has quit IRC | 01:12 | |
| *** dlaube has quit IRC | 01:17 | |
| *** chenglch has joined #openstack-ironic | 01:18 | |
| *** ChuckC has joined #openstack-ironic | 01:18 | |
| *** ChuckC has quit IRC | 01:22 | |
| *** ChuckC has joined #openstack-ironic | 01:23 | |
| *** ryanpetrello has quit IRC | 01:35 | |
| *** achanda has quit IRC | 01:50 | |
| *** nosnos has joined #openstack-ironic | 02:01 | |
| *** zhenzanz_ has joined #openstack-ironic | 02:03 | |
| *** zhenzanz has quit IRC | 02:04 | |
| *** zhenzanz_ is now known as zhenzanz | 02:04 | |
| *** yjiang5 has quit IRC | 02:32 | |
| *** Haomeng|2 has joined #openstack-ironic | 02:41 | |
| *** Haomeng has quit IRC | 02:41 | |
| *** vipul has quit IRC | 02:43 | |
| *** ramineni has joined #openstack-ironic | 02:53 | |
| *** zhenzanz has quit IRC | 03:03 | |
| *** zhenzanz has joined #openstack-ironic | 03:08 | |
| *** zhenzanz_ has joined #openstack-ironic | 03:11 | |
| *** zhenzanz has quit IRC | 03:13 | |
| *** zhenzanz_ is now known as zhenzanz | 03:14 | |
| *** nosnos has quit IRC | 03:29 | |
| *** rloo has quit IRC | 03:34 | |
| *** ryanpetrello has joined #openstack-ironic | 03:34 | |
| *** spandhe has quit IRC | 03:42 | |
| *** nosnos has joined #openstack-ironic | 04:03 | |
| *** pensu has joined #openstack-ironic | 04:12 | |
| naohirot | devananda: NobodyCam: I could access the Awesome Developer dashboard: http://perm.ly/ironic-review-dashboard in case of direct connection to the Internet. | 04:15 |
| naohirot | devananda: NobodyCam: so the root cause seems to be http proxy or firewall. | 04:16 |
| *** rameshg87 has joined #openstack-ironic | 04:19 | |
| naohirot | rameshg87: Hi, good morning | 04:25 |
| rameshg87 | naohirot, hello, good morning | 04:26 |
| naohirot | rameshg87: I waited for you :-) do you have time right now? | 04:26 |
| rameshg87 | naohirot, we can talk, but for an hour my responses might be slow as i am in another meeting. :) | 04:27 |
| *** vipul has joined #openstack-ironic | 04:28 | |
| naohirot | rameshg87: I see, I know your situation. I don't mind your response is slow. so let me ask :-) | 04:29 |
| rameshg87 | naohirot, sure go ahead :) | 04:29 |
| naohirot | rameshg87: http://docs.openstack.org/developer/ironic/drivers/ilo.html#deploy-process | 04:29 |
| naohirot | rameshg87: the last bullet, "On the first and subsequent reboots iscsi_ilo driver attaches this boot ISO image in Swift as Virtual Media CDROM and then sets iLO to boot from it." | 04:29 |
| naohirot | rameshg87: my question is that which ISO image does "this boot ISO image" refer to? | 04:30 |
| rameshg87 | naohirot, just have a look at the bullet point above it | 04:31 |
| rameshg87 | naohirot, "The driver bundles the boot kernel/ramdisk for the Glance deploy image into an ISO and then uploads it to Swift. This ISO image will be used for booting the deployed instance." | 04:31 |
| naohirot | rameshg87: the first boot is for deploy which copy user os through iscsi. | 04:32 |
| naohirot | rameshg87: the second and subsequent boot must use different ISO from the first boot. | 04:33 |
| naohirot | rameshg87: Am I correct? | 04:33 |
| naohirot | rameshg87: Is "this boot ISO image" same as deploy-ramdisk.iso or not? | 04:36 |
| naohirot | rameshg87: I believe that the last bullet should be like this: | 04:42 |
| rameshg87 | naohirot, yes it's correct | 04:43 |
| rameshg87 | naohirot, first boot is with deploy iso. this is different from the iso used for second and subsequent boots | 04:44 |
| naohirot | rameshg87: On the *second* and subsequent reboots iscsi_ilo driver attaches *newly created* boot ISO image in Swift as Virtual Media CDROM and then sets iLO to boot from it. | 04:44 |
| rameshg87 | naohirot, is that last bullet misleading ? | 04:44 |
| rameshg87 | naohirot, ah okay. yeah i agree. *newly created* avoid ambiguity | 04:45 |
| *** ryanpetrello has quit IRC | 04:45 | |
| naohirot | rameshg87: Yes, wording confused me a lot such as "The deploy kernel/ramdisk", "the deploy ramdisk image", "the ISO deploy ramdisk image" , etc. | 04:46 |
| naohirot | rameshg87: I wondered those are same image or different image. | 04:47 |
| naohirot | rameshg87: Generally speaking, is there any difference between "ramdisk image" and "kernel/ramdisk image"? | 04:49 |
| *** subscope_ has joined #openstack-ironic | 04:55 | |
| rameshg87 | naohirot, okay. i will fix the wordings. | 05:01 |
| rameshg87 | naohirot, yeah they are same "ramdisk image" and "kernel/ramdisk" image | 05:01 |
| rameshg87 | naohirot, basically the functionality of deployment is within the ramdisk, that's why we give more priority for ramdisk :) | 05:01 |
| rameshg87 | naohirot, priority in the sense, we mention it alone | 05:02 |
| rameshg87 | naohirot, i just saw your spec for virtual media deploy driver: https://review.openstack.org/#/c/134865/3/specs/kilo/irmc-deploy-driver.rst | 05:04 |
| naohirot | rameshg87: Okay, I understood. | 05:05 |
| rameshg87 | naohirot, i have one question - is there any reason why you prefer nfs/cifs instead of the current iscsi approach ? | 05:05 |
| naohirot | rameshg87: Yes, that's the reason I have a lot of questions:-) | 05:05 |
| rameshg87 | naohirot, actually i am interested in making the virtualmedia deploy driver independent of the virtual media implementation | 05:06 |
| naohirot | rameshg87: NFS/CIFS is based on my misunderstanding. | 05:06 |
| naohirot | rameshg87: I thought that iscsi_ilo uses iscsi to mount virtual media. this was my misunderstanding. | 05:07 |
| rameshg87 | naohirot, ah okay | 05:07 |
| rameshg87 | naohirot, iscsi is used for copying the image to the bare metal's disk | 05:08 |
| naohirot | rameshg87: iRMC uses NFS or CIFS to mount virtual media. | 05:08 |
| naohirot | rameshg87: so I renamed it iscsi_irmc driver. | 05:08 |
| *** mikedillion has quit IRC | 05:09 | |
| rameshg87 | naohirot, so you need an nfs share/cifs share for mounting it as virtual media ? | 05:09 |
| naohirot | rameshg87: yes, devananda gave me an advice I need to use Manila. | 05:10 |
| naohirot | rameshg87: so I need to implement image preparation part using Manila instead of Swift. | 05:11 |
| *** Nisha_ has joined #openstack-ironic | 05:14 | |
| rameshg87 | naohirot, okay | 05:15 |
| naohirot | rameshg87: do you think that I can reuse your most of code even if I use Manira? | 05:16 |
| rameshg87 | naohirot, i am not sure | 05:16 |
| rameshg87 | naohirot, can you boot from your virtual media ? | 05:17 |
| naohirot | rameshg87: Yes, I can boot from virtual media. | 05:17 |
| rameshg87 | naohirot, can you boot from an iso image ? | 05:17 |
| naohirot | rameshg87: Yes, I can boot from ISO image too. | 05:18 |
| rameshg87 | naohirot, how do we do that ? you give the nfs share location of the iso image ? | 05:18 |
| naohirot | rameshg87: iRMC mounts ISO as a virtual media through NFS or CIFS. | 05:19 |
| rameshg87 | naohirot, okay, but if i want to mount to an iso image through nfs | 05:20 |
| naohirot | rameshg87: From baremetal server's point of view, it is CDROM/DVD. | 05:20 |
| rameshg87 | naohirot, what's the input to iRMC ? | 05:20 |
| rameshg87 | naohirot, is it like 1.2.3.4:/path/to/image.iso ? | 05:20 |
| naohirot | rameshg87: Yes, exactly | 05:21 |
| rameshg87 | naohirot, does it support http ? | 05:21 |
| rameshg87 | naohirot, mounting an image over http ? | 05:21 |
| naohirot | rameshg87: Unfortunately, no. | 05:21 |
| rameshg87 | naohirot, :( | 05:21 |
| rameshg87 | naohirot, then i think % of code you can reuse from existing virtual media deploy driver might be less :( | 05:23 |
| *** ryanpetrello has joined #openstack-ironic | 05:23 | |
| naohirot | rameshg87: Okay, how about diskimage-builder and IPA coreos image part? | 05:24 |
| rameshg87 | naohirot, yeah, we can reuse those | 05:24 |
| rameshg87 | naohirot, the main reason is we rely extensively on temp-url, a feature of swift which provides access to a swift object through http | 05:25 |
| naohirot | rameshg87: Okay, I relieved :-) | 05:25 |
| *** subscope_ has quit IRC | 05:25 | |
| rameshg87 | naohirot, since proliant bare metal can use virtual media over http, it made things easy | 05:26 |
| rameshg87 | naohirot, so we can use glance images directly as bare metal's virtual media | 05:26 |
| naohirot | rameshg87: so the main difference is how to mount virtual media. | 05:26 |
| rameshg87 | naohirot, yes, that also makes the difference in how we prepare for virtual media boot | 05:27 |
| rameshg87 | naohirot, i think the first question is | 05:27 |
| rameshg87 | naohirot, if user uploads the ISO as a glance image, how do i make the bare metal node boot from it | 05:27 |
| rameshg87 | naohirot, in our case, we could just generate the swift-temp-url for the glance image (which is http) and attach it as virtual media | 05:28 |
| naohirot | rameshg87: Is that ISO User OS? | 05:29 |
| rameshg87 | naohirot, i mean the deploy ISO image | 05:29 |
| *** nosnos has quit IRC | 05:30 | |
| *** nosnos_ has joined #openstack-ironic | 05:30 | |
| rameshg87 | naohirot, which contains the deploy kernel/deploy ramdisk | 05:30 |
| naohirot | rameshg87: I'm not sure right now, but at lease I can copy the deply image to NFS disk which Manira provides. | 05:31 |
| naohirot | s/deply/deploy/ | 05:31 |
| naohirot | rameshg87: I think it's not efficient, but I need to investigate. | 05:32 |
| rameshg87 | naohirot, yeah. | 05:32 |
| rameshg87 | naohirot, even i have concerns with it. | 05:32 |
| naohirot | rameshg87: thank you for sparing your time, I'll read your source code. | 05:35 |
| rameshg87 | naohirot, wc :) | 05:35 |
| naohirot | :-) | 05:35 |
| *** rakesh_hs has joined #openstack-ironic | 05:40 | |
| devananda | naohirot: i think you might have misunderstood. Manila is a new openstack project whose goal is to provide an NFS service in the cloud | 05:46 |
| devananda | naohirot: requiring an operator to have an NFS server available for Ironic and iRMC to use is orthogonal to /how/ that NFS server is provided | 05:48 |
| devananda | naohirot: as an operator, perhaps I set up my own NFS server, or perhaps I use a hardware NAS that I already have ... or perhaps I use Manila | 05:49 |
| devananda | rameshg87: another reason for using swift is security - the access to an object is encoded in the temp-url, and you do not need to give out a shared secret (password or token) to the ramdisks | 05:50 |
| rameshg87 | devananda, yes | 05:51 |
| naohirot | devananda: Hi | 05:52 |
| * naohirot I'm reading your message | 05:54 | |
| devananda | naohirot: if all conductor's share a single NFS volume, you should look at the file caching done by ironic/drivers/modules/image_cache.py | 05:54 |
| devananda | naohirot: and you may need to consider using file-based locks (on the NFS volume) rather than the process locks we use within that module today | 05:54 |
| devananda | naohirot: so that multiple conductors do not attempt to write the same file at the same time | 05:55 |
| naohirot | devananda: do you think that it is one way to use NFS of conductor's OS? | 05:57 |
| devananda | naohirot: what does "use NFS of conductor's OS" mean? | 05:57 |
| naohirot | devananda: I meant the OS where ironic conductor is running. | 05:58 |
| devananda | naohirot: sorry, i still don't understand the question :( | 05:59 |
| naohirot | devananda: I couldn't understand "as an operator, perhaps I set up my own NFS server, or perhaps I use a hardware NAS that I already have ... or perhaps I use Manila" | 05:59 |
| devananda | k | 06:00 |
| naohirot | devananda: The OS I'm talking about is for example Ubuntu in case of DevStack. | 06:01 |
| devananda | naohirot: as I understood your spec, the iRMC driver will require: 1) that there exists an NFS / CIFS server, 2) that the driver (and thus the conductor) has access to files on the NFS / CIFS server, 3) that the hardware BMC also have access to the NFS / CIFS server | 06:01 |
| devananda | naohirot: and then, iRMC driver will store some file(s) on the NFS / CIFS server, inform the BMC how to attach those files (path, credentials, etc), and then initiate a boot from those files | 06:01 |
| devananda | is that correct? | 06:02 |
| naohirot | devananda: Yes | 06:02 |
| devananda | :) | 06:02 |
| devananda | naohirot: so, to my mind, it is reasonable to consider that NFS server as a separate operator requirement | 06:02 |
| devananda | an operator MUST have an NFS server, but neither Ironic nor iRCM care HOW that NFS server is run | 06:03 |
| naohirot | devananda: are you saying that ironc does nothing to NFS, and operator has responsible to prepare NFS so that iscsi_irmc can work? | 06:06 |
| devananda | yes | 06:08 |
| naohirot | devananda: If so, I don't need to investigate Manila, but I have to write thorough procedure document. | 06:08 |
| devananda | like tftp service -- the PXE drivers require that a TFTP service is running on each Conductor where the PXE driver is enabled | 06:08 |
| devananda | but Ironic does not start that service | 06:08 |
| devananda | naohirot: correct :) | 06:09 |
| naohirot | devananda: Okay, that's good. I'm wondering that Manila is still incubation stage, I'll face a lot of problem in development stage :-) | 06:10 |
| devananda | likely so | 06:11 |
| devananda | naohirot: I mentioned Manila more to say, "hey, there's something you might be interested in", that's all | 06:11 |
| naohirot | devananda: I thinks it's reasonable approach to think about Manila after Manila stabilized. | 06:12 |
| devananda | at some point in the future, someone may want to use these together. but that's optional | 06:12 |
| naohirot | devananda: Okay | 06:13 |
| naohirot | devananda: One thing I want to clarify is about the OS. | 06:13 |
| *** ryanpetrello has quit IRC | 06:14 | |
| naohirot | devananda: Is it illegal to access NFS partition on OS where Ironic conductor is running? | 06:14 |
| devananda | naohirot: well, why would that pose a problem? | 06:16 |
| naohirot | devananda: Because OpenStack is some kind of Cloud OS, so I thought that it is not good to access directly to any resources on OS where OpenStack services are running. | 06:18 |
| *** killer_prince is now known as lazy_prince | 06:18 | |
| *** ifarkas has joined #openstack-ironic | 06:19 | |
| *** rushiagr_away is now known as rushiagr | 06:19 | |
| devananda | naohirot: can you be more specific? acces by who/what? | 06:20 |
| naohirot | devananda: When I'll write the thorough procedure document how to set up NFS and deploy image, | 06:20 |
| naohirot | devananda: I thought that one way to describe to operator, export a disk partition on conductor node as NFS, and put deploy image into the NFS. | 06:22 |
| naohirot | devananda: That's is my question, in this case, operator doesn't have to prepare NFS box. | 06:23 |
| naohirot | devananda: operator can temporally use conductor node as NFS too. | 06:23 |
| *** k4n0 has joined #openstack-ironic | 06:24 | |
| rameshg87 | naohirot, i guess the current ipxe implementation does the same thing. it assumes that an http server is running on the conductor node. | 06:28 |
| devananda | naohirot: that volume will be shared by all nodes which are deployed from that conductor. And because it is NFS, also visible to anyone else on the same network ... | 06:28 |
| devananda | rameshg87: difference: http is probably a read-only service. nfs is not | 06:29 |
| rameshg87 | devananda, ah okay :) | 06:29 |
| rameshg87 | devananda, so if share an nfs across all conductor nodes, we could use it and use image cache | 06:30 |
| devananda | if the operator had a separate NFS server, which all conductors connected to, then yes, all conductors could share an image cache | 06:31 |
| naohirot | devananda: Okay, If I can use conductor node as NFS server for iRMC, I think it's very convenient, I don't have worry about NFS. | 06:31 |
| devananda | rameshg87: this is possible today even with the pxe driver (but there is a risk of file collissions) | 06:32 |
| rameshg87 | devananda, what do you mean by file collission | 06:33 |
| *** spandhe has joined #openstack-ironic | 06:33 | |
| rameshg87 | devananda, do you mean locking can't be done effectively when it is shared ? | 06:33 |
| devananda | naohirot: I feel that how the NFS server is configured should be outside of the control of ironic-conductor | 06:33 |
| devananda | naohirot: in other words, iRMC driver should have config options to inform it about the NFS service, but conductor can not start or manage the NFS mount point or the NFS service itself | 06:34 |
| naohirot | devananda: My question came from the fact that OpenStack storages are all abstracted. I though that this is some kind of design policy or something. | 06:34 |
| *** nosnos_ has quit IRC | 06:34 | |
| devananda | naohirot: it has nothing to do with OpenStack Block or Volume storage services | 06:34 |
| *** nosnos has joined #openstack-ironic | 06:34 | |
| naohirot | devananda: Okay, I use NFS partition on conductor node as the first option. | 06:36 |
| devananda | naohirot: personally, I think that's going to pose a security problem, and many people will not be willing to use it | 06:36 |
| devananda | naohirot: but I may be wrong on that | 06:36 |
| devananda | naohirot: where the NFS server is run should not matter to Ironic or the iRMC driver -- as long as it's accessible on the network | 06:37 |
| naohirot | devananda: if operator doesn't write data into conductor node, then suggest to use NFS somewhere | 06:37 |
| devananda | rameshg87: look at drivers/modules/image_cache.py | 06:38 |
| *** ifarkas has quit IRC | 06:39 | |
| naohirot | devananda: Okay, if there is security issue, I reverse the order, first please prepare NFS somewhere, then consider to use conductor node as the last resort. | 06:39 |
| devananda | rameshg87: fetch_image() assumes only a single conductor process is writing to the cache dir, and that it is on a file system which supports hard-links | 06:40 |
| * naohirot I'm looking at fetch_image() | 06:41 | |
| devananda | rameshg87: if you want to make image_cache work on a network file system shared by >1 conductor , you'll need to look at lockutils.lock() -- I believe there is a way to make that use a file-based lock (rather than the default in-memory lock) | 06:42 |
| rameshg87 | devananda, doesn't nfs support hardlinks ? | 06:42 |
| devananda | rameshg87: it may - I don't know offhand | 06:43 |
| rameshg87 | devananda, we count the number of hardlinks to see whether it is time to cleanup the master image or not, right ? | 06:43 |
| rameshg87 | devananda, yeah okay, file based locks might work | 06:44 |
| rameshg87 | devananda, but is it just that nobody has tried out such a thing with pxe driver ? | 06:44 |
| rameshg87 | devananda, oh okay, file based locks :) | 06:44 |
| devananda | rameshg87: also, file-based locks across a shared file system might be really slow and error prone - so please don't take this discussion as an endorsement of the idea | 06:48 |
| rameshg87 | devananda, okay | 06:48 |
| devananda | rameshg87: I think it's an _interesting_ idea. but I dont know if it's a good solution | 06:48 |
| rameshg87 | devananda, :) | 06:48 |
| devananda | ok - I need to get some sleep. good night, folks. see you tomorrow! | 06:50 |
| naohirot | devananda: good night, thanks! | 06:50 |
| rameshg87 | devananda, good night :) | 06:51 |
| naohirot | rameshg87: regarding file lock, is it not enough NFS lock daemon work for our case? | 06:52 |
| openstackgerrit | Harshada Mangesh Kakad proposed openstack/ironic: Add documentation for SeaMicro driver https://review.openstack.org/136324 | 06:58 |
| openstackgerrit | Anusha Ramineni proposed openstack/ironic: iLO Management Interface https://review.openstack.org/132746 | 06:58 |
| *** harlowja is now known as harlowja_away | 07:01 | |
| *** aswadr has joined #openstack-ironic | 07:04 | |
| rameshg87 | naohirot, i am just checking what nfs lockd is .. | 07:06 |
| *** achanda has joined #openstack-ironic | 07:08 | |
| naohirot | rameshg87: okay, I just would like to understand the lock issue you and devananda discussed. | 07:09 |
| naohirot | rameshg87: The lock NFS lockd provides may be just advisory lock, I'm not sure. | 07:13 |
| rameshg87 | naohirot, current image_cache uses locks while fetching and cleaning up the image | 07:15 |
| rameshg87 | naohirot, https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/image_cache.py#L108 | 07:15 |
| rameshg87 | naohirot, https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/image_cache.py#L108 | 07:15 |
| rameshg87 | naohirot, this uses oslo.concurrency module https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/lockutils.py#L268-L311 | 07:16 |
| rameshg87 | naohirot, we should use file based locking for locking during operations in the image_cache | 07:17 |
| *** dlpartain has joined #openstack-ironic | 07:20 | |
| naohirot | rameshg87: Okay, Is there something I should consider to use file based lock mechanize in NFS? | 07:21 |
| *** mrda is now known as mrda_away | 07:21 | |
| * naohirot rereading the discussion b/w rameshg87 and devananda | 07:23 | |
| rameshg87 | naohirot, i am not aware of file-based locking mechanisms in nfs. but if you are gonna have a single nfs server and are going to share images (like deploy ISO images), then you will definitely need a better locking mechanism on the shared nfs | 07:23 |
| naohirot | rameshg87: Okay, I got that the issue would be performance. | 07:27 |
| rameshg87 | naohirot, bigger worry would be will it work properly in all cases :) | 07:28 |
| rameshg87 | naohirot, may be the nfs specific locking mechanisms can address that | 07:28 |
| naohirot | rameshg87: Okay, I'll mention it in the spec. | 07:29 |
| rameshg87 | naohirot, okay | 07:32 |
| naohirot | rameshg87: thanks! :-) | 07:32 |
| *** achanda has quit IRC | 07:35 | |
| rameshg87 | wc | 07:39 |
| *** achanda has joined #openstack-ironic | 07:43 | |
| *** achanda has quit IRC | 07:46 | |
| *** spandhe has quit IRC | 07:47 | |
| *** achanda has joined #openstack-ironic | 07:48 | |
| *** kiku has joined #openstack-ironic | 07:50 | |
| kiku | Hii | 07:51 |
| kiku | need some help about pxe_ssh driver | 07:51 |
| *** achanda has quit IRC | 07:53 | |
| *** kiku has quit IRC | 07:53 | |
| *** achanda has joined #openstack-ironic | 07:58 | |
| *** jcoufal has joined #openstack-ironic | 08:00 | |
| *** spandhe has joined #openstack-ironic | 08:01 | |
| *** athomas has joined #openstack-ironic | 08:05 | |
| *** lucasagomes has joined #openstack-ironic | 08:06 | |
| *** lucasagomes has quit IRC | 08:06 | |
| *** lucasagomes has joined #openstack-ironic | 08:07 | |
| *** ifarkas has joined #openstack-ironic | 08:10 | |
| *** romcheg has joined #openstack-ironic | 08:10 | |
| *** achanda has quit IRC | 08:10 | |
| *** dtantsur has joined #openstack-ironic | 08:10 | |
| *** dtantsur has quit IRC | 08:11 | |
| *** dtantsur_ has joined #openstack-ironic | 08:11 | |
| *** dtantsur_ is now known as dtantsur | 08:11 | |
| *** spandhe has quit IRC | 08:13 | |
| *** jistr has joined #openstack-ironic | 08:18 | |
| GheRivero | morning all | 08:20 |
| Haomeng|2 | hi | 08:21 |
| Haomeng|2 | kiku: hi | 08:21 |
| dtantsur | morning :) | 08:32 |
| lucasagomes | morning gfolks | 08:32 |
| *** ndipanov_gone is now known as ndipanov | 08:33 | |
| openstackgerrit | Yuiko Takada proposed openstack/python-ironicclient: Fix node-set-provision-state cmd's help strings https://review.openstack.org/135518 | 08:35 |
| Nisha_ | dtantsur: lucasagomes Morning ! | 08:45 |
| dtantsur | Nisha_, hi | 08:46 |
| *** mkerrin has quit IRC | 08:48 | |
| Nisha_ | dtantsur: hi | 08:49 |
| Nisha_ | just now saw the comments on discovery spec | 08:49 |
| Nisha_ | dtantsur: some clarifications on it | 08:50 |
| Nisha_ | dtantsur what shall be the proposed timeout? | 08:50 |
| Nisha_ | dtantsur: and shall it be a new element in node object? | 08:50 |
| Nisha_ | or part of node.extra? | 08:51 |
| Nisha_ | dtantsur: i wanted to move my spec out of states spec as states spec is anyway a major dependency for all the specs | 08:51 |
| Nisha_ | dtantsur: means most of them. So by the time that piece of code is still in progress, we can atleast get our specs in? | 08:52 |
| dtantsur | Nisha_, we could, but there's no point IMO. Nothing is preventing you from writing the code right now, but it won't be approved until state machine is finished | 08:56 |
| Nisha_ | yes :( | 08:57 |
| dtantsur | Nisha_, re timeout: it's configuration option, not a node property. We probably need a new Node.discovery_started datetime field though... | 08:57 |
| Nisha_ | dtantsur: ok clarification needed above on the review comments.^^^ | 08:57 |
| Nisha_ | dtantsur: why we need timestatrted? | 08:58 |
| dtantsur | Nisha_, to calculate timeouts. Example: | 08:58 |
| Nisha_ | we are anyway adding last_discovered | 08:58 |
| Nisha_ | ohk, | 08:58 |
| Nisha_ | that may not be a seperate field anyway | 08:59 |
| dtantsur | Nisha_, we have discover started at 12:00 and died for some reason (for OOB is may be conductor dying). timeout is 1hr, so at 13:00 conductor sets it to DISCOVERYFAILED | 08:59 |
| Nisha_ | we can take a timestamp when discovery started and timeout can be calculated | 09:00 |
| Nisha_ | ? | 09:00 |
| Nisha_ | thats fine, but why we need it as a sepearte field | 09:00 |
| Nisha_ | dtantsur: it can be done even if it is not a seperate field | 09:00 |
| Nisha_ | correct? | 09:00 |
| dtantsur | Nisha_, where are you going to store " a timestamp when discovery started" for each node? | 09:00 |
| Nisha_ | the management interface can have a local variable, not saved to node object | 09:01 |
| Nisha_ | isnt that possible? | 09:01 |
| Nisha_ | ohk, or we can store it temporariy in node.etra | 09:01 |
| Nisha_ | and remove when discovery done | 09:02 |
| Nisha_ | s/node.etra/node.extra | 09:02 |
| dtantsur | Nisha_, local variable: won't work with HA and conductor dying; extra: will require going thorough all nodes instead of ``select * from nodes where discovery_started < now() - timeout`` | 09:02 |
| *** zhenzanz has quit IRC | 09:03 | |
| Nisha_ | ok | 09:03 |
| Nisha_ | Ok i will add it in the spec | 09:03 |
| Nisha_ | dtantsur: do u have any idea of default tiimeout? | 09:03 |
| openstackgerrit | Anusha Ramineni proposed openstack/ironic-specs: Add get/set boot mode to Management Interface https://review.openstack.org/129529 | 09:04 |
| dtantsur | Nisha_, hmm. it should be quite large to account for in-band. what about 1 hour? | 09:04 |
| Nisha_ | 1 hr, isnt that too large a time for a node? | 09:05 |
| Nisha_ | i was thinking in terms of seconds :) | 09:05 |
| Nisha_ | or minutes | 09:05 |
| dtantsur | Nisha_, honestly I don't know :) for in-band it's definitely not seconds. also, discoverd had it's own timeouts and OOB will rarely fail that badly. | 09:05 |
| dtantsur | so it's the last resort and can be large | 09:06 |
| Nisha_ | dtantsur: :) | 09:06 |
| Nisha_ | ok i will propose it to be that but i am not sure if people will really agree on such large timeouts | 09:06 |
| dtantsur | let us see :) | 09:06 |
| Nisha_ | dtantsur: one more thing wanted to ask | 09:07 |
| Nisha_ | as part of properties discovery, we plan to even discover hardware capabilities | 09:07 |
| Nisha_ | that said it will discover many properties than what schedular requires and update in the form of capabilities in node.properties | 09:08 |
| Nisha_ | so do i need to propose another spec for that? or it is not required to mention? or it is fine to do as part of hardware discovery | 09:09 |
| Nisha_ | above we want to do for ilo drivers | 09:09 |
| Nisha_ | i.e. discovering hw capabilities along with mandatory properties | 09:09 |
| dtantsur | good question. depending on what you mean for capabilities... | 09:10 |
| dtantsur | the only thing I suggest is not overcomplicating this spec even more :) | 09:10 |
| ekarlso- | what's instack btw? | 09:10 |
| dtantsur | Nisha_, so you may start with putting it into your ilo spec | 09:10 |
| dtantsur | ekarlso-, Red Hat's undercloud installer based on tripleo | 09:11 |
| ekarlso- | ah ok | 09:11 |
| dtantsur | ekarlso-, https://github.com/agroup/instack-undercloud | 09:11 |
| Nisha_ | dtantsur: devananda suggested to not have a another spec for ilo, the same spec can say the reference implementation will be done for ilo drivers | 09:11 |
| dtantsur | ekarlso-, https://openstack.redhat.com/Deploying_an_RDO_Undercloud_with_Instack | 09:11 |
| dtantsur | Nisha_, for just discovery - yes. for more capabilties... maybe you need it | 09:12 |
| ekarlso- | is discovery stuff coming to ironic ? | 09:12 |
| Nisha_ | dtantsur: ok. so the same managemnet interface can be used for for hw capabilities? | 09:12 |
| dtantsur | ekarlso-, yes :) https://review.openstack.org/#/c/100951/ https://review.openstack.org/#/c/135605 | 09:12 |
| ekarlso- | oh kewl :) | 09:13 |
| Nisha_ | or should it be done as a seperate mgmt interface | 09:13 |
| dtantsur | Nisha_, probably. I didn't give it a good think yet and I don't know what exactly you mean by "capabilities" | 09:13 |
| Nisha_ | i mean several prop like supported boot modes, server model, VT-d, etc etc | 09:14 |
| ekarlso- | I was wondering about the consolidation stuff that someone asked about in the MLs, maybe use ceilometer / nova api's to pull instances on hosts periodically and using ironic to control powerstate after vm's has been consolidated onto new hosts would be a fun idea | 09:14 |
| Nisha_ | we are yet to finalize on list which we want to discover, but still for ilo it is closely tied with discovery | 09:14 |
| *** derekh has joined #openstack-ironic | 09:14 | |
| dtantsur | Nisha_, honestly we'll have kind of these for in-band... but we're in the middle of the discussion right now at the meeting :) | 09:15 |
| Nisha_ | dtantsur: i didnt get | 09:16 |
| Nisha_ | for in-band, it will be done as part of hw discovery? | 09:16 |
| Nisha_ | or seperately | 09:16 |
| dtantsur | Nisha_, likely part of discovery. I just suggest not putting it into this spec, so that it can land soon :) | 09:17 |
| Nisha_ | :) | 09:18 |
| Nisha_ | dtantsur: ok then i will just update that in my ilo spec | 09:18 |
| Nisha_ | and should i rename that as hw capabilities spec for ilo ;) | 09:18 |
| dtantsur | yeah, makes sense | 09:18 |
| Nisha_ | dtantsur: one basic ques | 09:18 |
| Nisha_ | Even if it is going to be part of discovery, then also DISCOVERYFAIL shall be set only when mandatory prop fail | 09:20 |
| Nisha_ | is that fine? | 09:20 |
| Nisha_ | for other capabilities, it will not be set as DISCOVERYFAIL | 09:21 |
| Nisha_ | but the timeout will matter then | 09:21 |
| Nisha_ | how much time in-band takes for mandatory prop, approx | 09:21 |
| Nisha_ | ? | 09:21 |
| dtantsur | Nisha_, in-band will take ~the same time no matter which properties are discovered. The boot time is dominating. | 09:22 |
| *** andreykurilin_ has joined #openstack-ironic | 09:22 | |
| dtantsur | Nisha_, should be fine to call discovery done, once we have props required for scheduling, even if the other failed | 09:22 |
| Nisha_ | but its asynchronous call correct, the last disocvered will be set when the mgmt interface returns correct? | 09:23 |
| dtantsur | Nisha_, when is last_discovered is set, depends on the driver. it's set before mgmt returns by OOB driver and inside discoverd for discoverd driver | 09:25 |
| Nisha_ | dtantsur: will do as discussed and update both the specs | 09:26 |
| dtantsur | Nisha_, thanks! | 09:26 |
| Nisha_ | dtantsur: thank you. | 09:27 |
| Nisha_ | dtantsur: i was going thru the spec https://review.openstack.org/128927 | 09:27 |
| dtantsur | it's very unfinished and will probably be abanoded in favor of https://review.openstack.org/#/c/131272 | 09:28 |
| Nisha_ | do you plan to use properties field for driver capabilities | 09:29 |
| Nisha_ | :) | 09:29 |
| Nisha_ | dtantsur: thats what my main ques was do we plan to use different node filed for driver capabilities and hw capabilities or it is same for al the capabilities | 09:30 |
| Nisha_ | dtantsur: so it looks like all capabilities will be stored same | 09:31 |
| dtantsur | sorry, I don't know right now :) it was not my focus recently, I better ask devananda, or JayF, or jroll, I guess | 09:31 |
| Nisha_ | :) | 09:31 |
| Nisha_ | dtantsur: one more ques | 09:32 |
| *** jistr has quit IRC | 09:33 | |
| Nisha_ | dtantsur: for states like zapping, like firmware settings firmware update are discussed to be done thru capabilities, | 09:33 |
| Nisha_ | how does nova selects a node which is in zapping and which is in available | 09:34 |
| Nisha_ | do we need a different scheduler filer for such case | 09:34 |
| Nisha_ | ? | 09:34 |
| dtantsur | Nisha_, nova inspects provision_state | 09:34 |
| dtantsur | so interesting for Nova are only AVAILABLE nodes, it should ignore the other | 09:34 |
| Nisha_ | but then how does the nodes which are in zapping gets selected for taking action requested in flavor? | 09:35 |
| Nisha_ | ASAIUI, firmware setting, fimrware update , RAID, etc needs to be implemented thru capabilities and do not have endpoint sepeartely | 09:36 |
| dtantsur | Nisha_, not sure for now (again, ask rackspace guys), but Nova is not related to scheduling zapping actions, it's solely done by Ironic itself | 09:37 |
| *** foexle has joined #openstack-ironic | 09:37 | |
| Nisha_ | dtantsur: actually i did experimented something hw capabilities in nova, so as of now it matches the nodes as given in the flavor key | 09:38 |
| Nisha_ | so i was just thinking there is nothing as of now in Nova to prevent the node from being selected for deploying if it goes thru available filters | 09:39 |
| dtantsur | right. but Ironic only passes it nodes in AVAILABLE state | 09:39 |
| Nisha_ | as of now do we have any such discrimination? | 09:43 |
| Nisha_ | dtantsur: in my experiment i can see nova can see all the hypervisors | 09:44 |
| dtantsur | I think so. We call it "NOSTATE" now, though. But we don't provide Nova with nodes in say "DELETING" state IIRC | 09:45 |
| Nisha_ | then all the filers act | 09:45 |
| Nisha_ | hmmm not sure about deleting state, :) because mostly that time i would have been watching my instance ;) | 09:46 |
| Nisha_ | i think we will need one filter in Nova for state , not very sure as of now | 09:47 |
| Nisha_ | as of now, nova selects transparently for any node for any capabilities matched, there isno filter for state | 09:48 |
| dtantsur | hmm | 09:48 |
| dtantsur | I don't remember how it's done :) lucasagomes ^^^? | 09:49 |
| Nisha_ | if we want nova to select node only for AVAILABLE states, how do we plan the hw capabilities actions to be taken as as per requested flavor | 09:49 |
| *** pensu has quit IRC | 09:49 | |
| dtantsur | Nisha_, these do not look related. Nova will select AVAILABLE nodes that have appropriate capabilities and hw properties. Do you expect any problems here? | 09:51 |
| Nisha_ | for ex, say a node has capability to give different kind of power. the flavor say i need optimized power. The node which can provide the optimized power shall be chosen and then the driver shall take particular action to give it optimized power | 09:51 |
| Nisha_ | the above is part of firmware setting | 09:51 |
| Nisha_ | which shall be part of hw capabilities | 09:51 |
| Nisha_ | so during this requested action node should not be in AVAILABLE state correct? | 09:52 |
| dtantsur | Nisha_, if it's a fast action - yes. Nova will chose AVAILABLE node with capability like `can_optimize_power` and afterward the specific way will be enforced as part of prepare action of DEPLOY (not sure how exactly - ask J*) | 09:53 |
| Nisha_ | so if it has to come thru Nova flavor then nova should be able to select the node for that requested action and do the requested work. | 09:53 |
| Nisha_ | i just gave an example of power | 09:53 |
| Nisha_ | the firmware settings can then be part of AVAILABLE state ???? | 09:54 |
| dtantsur | Nisha_, of DEPLOY state | 09:54 |
| dtantsur | it should be set in advance (I'm not aware of the details) | 09:54 |
| Nisha_ | DEPLOY is after AVAILABLE correct...but firmware setting is supposed to be part of ZAPPING | 09:55 |
| dtantsur | Nisha_, it depends. ZAPPING is for long-running things. They become "properties" of the AVAILABLE node afterwards. SHort-running tasks a part of DEPLOY however. | 09:56 |
| Nisha_ | dtantsur: ^^^^ 1. how does Nova know it will short running task or long running task? 2) Will the time taken not differ per driver? 3) How does Nova take action during ZApping state? | 09:57 |
| Nisha_ | dtantsur: if they have seperate endpoint then it is fine, but if they dont have seperate end point then nova need to know the mechanism to differentiate between several capabilities | 09:59 |
| *** andreykurilin_ has quit IRC | 10:00 | |
| *** andreykurilin_ has joined #openstack-ironic | 10:00 | |
| *** dlpartain has quit IRC | 10:02 | |
| *** jistr has joined #openstack-ironic | 10:03 | |
| *** pensu has joined #openstack-ironic | 10:04 | |
| *** andreykurilin_ has quit IRC | 10:05 | |
| *** andreykurilin_ has joined #openstack-ironic | 10:06 | |
| *** nosnos has quit IRC | 10:08 | |
| *** nosnos has joined #openstack-ironic | 10:09 | |
| *** mkerrin has joined #openstack-ironic | 10:11 | |
| *** Nisha_ has quit IRC | 10:14 | |
| openstackgerrit | Dmitry Tantsur proposed openstack/ironic-specs: In-band hardware properites discovery via ironic-discoverd https://review.openstack.org/135605 | 10:23 |
| *** naohirot has quit IRC | 10:29 | |
| *** sambetts has joined #openstack-ironic | 10:39 | |
| *** vdrok has quit IRC | 10:55 | |
| *** MattMan has quit IRC | 10:58 | |
| *** vdrok has joined #openstack-ironic | 10:59 | |
| *** MattMan has joined #openstack-ironic | 10:59 | |
| *** naohirot has joined #openstack-ironic | 11:00 | |
| *** dlaube has joined #openstack-ironic | 11:01 | |
| *** ramineni has quit IRC | 11:03 | |
| *** dlaube has quit IRC | 11:05 | |
| *** andreykurilin_ has quit IRC | 11:12 | |
| *** rameshg87 has quit IRC | 11:13 | |
| *** k4n0 has quit IRC | 11:20 | |
| sambetts | Morning all | 11:24 |
| openstackgerrit | Yuriy Zveryanskyy proposed openstack/ironic: Rename parameters for ilo driver https://review.openstack.org/137022 | 11:32 |
| *** chenglch has quit IRC | 11:38 | |
| openstackgerrit | Nisha Agarwal proposed openstack/ironic-specs: uefi support for agent-ilo driver https://review.openstack.org/137024 | 11:46 |
| openstackgerrit | Tan Lin proposed openstack/ironic-specs: Bare Metal Trust https://review.openstack.org/133902 | 11:53 |
| *** Nisha has joined #openstack-ironic | 11:58 | |
| Nisha | dtantsur: hi | 11:58 |
| Nisha | dtantsur: wanted to check one thing on your comment | 11:59 |
| Nisha | dtantsur: "New option: ``discovery_timeout`` (integer, in seconds, default to 1 hour) with the amount of time after which discovery is considered to be failed and node is moved to DISCOVERYFAIL state" DO you propose it to be a new option in the CLI? | 11:59 |
| *** dlaube has joined #openstack-ironic | 12:02 | |
| *** dlaube has quit IRC | 12:07 | |
| dtantsur | Nisha, configuration option, in /etc/ironic/ironic.conf | 12:08 |
| dtantsur | sambetts, morning | 12:09 |
| sambetts | Morning dtantsur | 12:09 |
| lucasagomes | Nisha, it may clarify some about the zapping state https://review.openstack.org/#/c/102685/ | 12:24 |
| lucasagomes | sambetts, morning | 12:24 |
| Nisha | dtantsur: Ok. | 12:24 |
| * lucasagomes is in a meeting so I'm quiet here today | 12:25 | |
| sambetts | lucasagomes, morning | 12:25 |
| *** dlpartain has joined #openstack-ironic | 12:26 | |
| *** mjturek has quit IRC | 12:26 | |
| *** jistr is now known as jistr|english | 12:32 | |
| Nisha | lucasagomes: yes i saw it today morning itself. But still it doesnt clarify much on nova dependencies, as it is still unclear | 12:37 |
| Nisha | dtantsur: the zapping spec is not the child spec of state spec though it requires it | 12:37 |
| Nisha | so shall i also make discovery spec as independent and have state spec in the dependencies section | 12:37 |
| Nisha | ? | 12:37 |
| dtantsur | Nisha, I'm not to blame, please ask it's author :) | 12:37 |
| Nisha | :) | 12:38 |
| Nisha | dtantsur: i am not blaing you | 12:38 |
| dtantsur | Nisha, they're not independent, so no you can't IMO | 12:38 |
| Nisha | blaming* | 12:38 |
| lucasagomes | Nisha, right... This is some discussion that we have to had as part of the new state machine work | 12:38 |
| Nisha | just to land the discovery spec ;) | 12:38 |
| *** dlpartain1 has joined #openstack-ironic | 12:38 | |
| *** dlpartain has quit IRC | 12:38 | |
| lucasagomes | how nova is going to iteract with the new state machine | 12:38 |
| lucasagomes | (afk a bit... meeting) | 12:38 |
| Nisha | yes, lucasagomes correct | 12:39 |
| Nisha | ok i will pose it as dependent patch but then discovery spec cant land till state spec lands :( | 12:39 |
| dtantsur | Nisha, I personally won't approve a spec with non-solved dependencies. Because we can't land any code. | 12:40 |
| dtantsur | Nisha, also imagine, we change smth discovery-related in the states spec after we landed the discovery spec. What will we do? | 12:41 |
| *** bradjones has quit IRC | 12:45 | |
| *** Haomeng has joined #openstack-ironic | 12:45 | |
| *** bradjones has joined #openstack-ironic | 12:45 | |
| *** Haomeng|2 has quit IRC | 12:46 | |
| Nisha | dtantsur: ok :) | 12:51 |
| *** rakesh_hs has quit IRC | 12:51 | |
| *** ramineni has joined #openstack-ironic | 12:55 | |
| *** jcoufal has quit IRC | 12:56 | |
| *** jcoufal has joined #openstack-ironic | 12:57 | |
| *** Haomeng|2 has joined #openstack-ironic | 13:01 | |
| *** Haomeng has quit IRC | 13:02 | |
| *** dlaube has joined #openstack-ironic | 13:03 | |
| *** dprince has joined #openstack-ironic | 13:06 | |
| *** dlaube has quit IRC | 13:07 | |
| *** Nisha has quit IRC | 13:23 | |
| *** naohirot has quit IRC | 13:29 | |
| *** Haomeng has joined #openstack-ironic | 13:35 | |
| *** Haomeng|2 has quit IRC | 13:37 | |
| *** linggao has joined #openstack-ironic | 13:37 | |
| *** jjohnson2 has joined #openstack-ironic | 13:43 | |
| *** dlpartain1 has left #openstack-ironic | 13:47 | |
| *** nosnos has quit IRC | 13:48 | |
| *** nosnos has joined #openstack-ironic | 13:49 | |
| *** nosnos has quit IRC | 13:54 | |
| *** trown has quit IRC | 13:55 | |
| *** trown has joined #openstack-ironic | 13:56 | |
| *** rloo has joined #openstack-ironic | 14:02 | |
| *** foexle has quit IRC | 14:03 | |
| *** dlaube has joined #openstack-ironic | 14:03 | |
| *** jcoufal has quit IRC | 14:03 | |
| *** jcoufal has joined #openstack-ironic | 14:04 | |
| openstackgerrit | Vladyslav Drok proposed openstack/ironic-specs: Support for non-Glance image references https://review.openstack.org/135276 | 14:04 |
| *** dlaube has quit IRC | 14:08 | |
| *** pensu has quit IRC | 14:09 | |
| *** jistr|english is now known as jistr | 14:13 | |
| *** ryanpetrello has joined #openstack-ironic | 14:13 | |
| *** rushiagr is now known as rushiagr_away | 14:24 | |
| *** mjturek has joined #openstack-ironic | 14:38 | |
| *** mjturek has quit IRC | 14:39 | |
| *** mjturek has joined #openstack-ironic | 14:39 | |
| *** ryanpetrello has quit IRC | 14:40 | |
| *** ryanpetrello has joined #openstack-ironic | 14:46 | |
| NobodyCam | good morning Ironic | 14:46 |
| rloo | morning NobodyCam | 14:48 |
| GheRivero | morning Ironic | 14:49 |
| NobodyCam | morning rloo and GheRivero | 14:49 |
| *** r-daneel has joined #openstack-ironic | 14:51 | |
| *** rushiagr_away is now known as rushiagr | 14:51 | |
| dtantsur | morning NobodyCam, rloo, GheRivero! | 14:53 |
| rloo | hi GheRivero, dtantsur | 14:53 |
| *** dlpartain has joined #openstack-ironic | 14:53 | |
| *** jcoufal_ has joined #openstack-ironic | 14:53 | |
| *** jcoufal has quit IRC | 14:53 | |
| *** dlpartain has left #openstack-ironic | 14:53 | |
| jroll | morning everybody :) | 14:54 |
| *** jcoufal_ has quit IRC | 14:54 | |
| dtantsur | jroll, morning | 14:54 |
| rloo | morning jroll ;) | 14:54 |
| *** jcoufal has joined #openstack-ironic | 14:54 | |
| NobodyCam | morning dtantsur and jroll | 14:55 |
| jroll | dtantsur: to answer nisha's question about nova: https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L240-250 | 14:55 |
| jroll | we'll have to modify that for the new state machine, but there you have it | 14:55 |
| dtantsur | aha I see | 14:55 |
| dtantsur | thanks | 14:55 |
| jroll | np | 14:56 |
| * jroll responds to sdague's email | 14:57 | |
| *** zz_jgrimm is now known as jgrimm | 15:03 | |
| *** dlaube has joined #openstack-ironic | 15:04 | |
| openstackgerrit | Chris Krelle proposed openstack/python-ironicclient: Update README https://review.openstack.org/134541 | 15:05 |
| *** dlaube has quit IRC | 15:08 | |
| openstackgerrit | Vladyslav Drok proposed openstack/python-ironicclient: Fix log_curl_request API version duplication https://review.openstack.org/136773 | 15:09 |
| jroll | yo lucasagomes, I don't think either of those status codes would work here https://review.openstack.org/#/c/136934/ | 15:09 |
| *** ndipanov has quit IRC | 15:09 | |
| openstackgerrit | Vladyslav Drok proposed openstack/python-ironicclient: Fix log_curl_request API version duplication https://review.openstack.org/136773 | 15:10 |
| *** ryanpetrello has quit IRC | 15:16 | |
| openstackgerrit | Vladyslav Drok proposed openstack/python-ironicclient: Fix log_curl_request API version duplication https://review.openstack.org/136773 | 15:17 |
| *** ndipanov has joined #openstack-ironic | 15:18 | |
| *** ryanpetrello has joined #openstack-ironic | 15:20 | |
| *** achanda has joined #openstack-ironic | 15:29 | |
| *** achanda has quit IRC | 15:32 | |
| *** alexpilotti has joined #openstack-ironic | 15:32 | |
| dtantsur | ifarkas, https://github.com/agroup/instack-undercloud/blob/master/elements/discovery-ironic/init.d/80-discovery-ironic | 15:45 |
| ifarkas | dtantsur, thanks | 15:45 |
| *** PaulCzar has joined #openstack-ironic | 15:46 | |
| *** achanda has joined #openstack-ironic | 15:48 | |
| NobodyCam | brb | 15:51 |
| dtantsur | ifarkas, now https://review.openstack.org/#/c/122151/ | 15:54 |
| ifarkas | dtantsur, I am wondering if a ramdisk for a stackforge project will be accepted or not... | 15:55 |
| dtantsur | ifarkas, we can see :) | 15:56 |
| devananda | morning, all | 15:56 |
| dtantsur | it would be a bit strange if it doesn't actually | 15:56 |
| dtantsur | devananda, morning | 15:56 |
| ifarkas | morning devananda | 15:57 |
| sambetts | morning, devananda | 15:57 |
| NobodyCam | good morning devananda | 15:57 |
| jroll | heya deva | 15:57 |
| ifarkas | dtantsur, I am not convinced since diskimage-builder is an already accepted openstack project. We will see... | 15:58 |
| *** anderbubble has joined #openstack-ironic | 15:58 | |
| *** kfox1111 has quit IRC | 15:58 | |
| jroll | ifarkas: you mean if ironic will find it acceptable to use a ramdisk from a stackforge project? | 15:59 |
| openstackgerrit | Dmitry Tantsur proposed openstack/ironic-specs: In-band hardware properites discovery via ironic-discoverd https://review.openstack.org/135605 | 16:00 |
| ifarkas | jroll, no, I am wondering if a ramdisk for stackforge/ironic-discoverd element fits to the diskimage-builder repo | 16:00 |
| ifarkas | jroll, but I am not against it | 16:00 |
| jroll | oh, I don't see why not | 16:00 |
| devananda | ifarkas: any reason why DIB can't build a ramdisk for discoverd? | 16:01 |
| dtantsur | jroll, I'm trying https://review.openstack.org/#/c/122151/ to get the reference ramdisk in diskimage-builder. It will be kind of strange to have support for it in Ironic but not having a ramdisk anywhere within openstack | 16:01 |
| devananda | ifarkas: I would expect, if it can be built, that project will accept it | 16:01 |
| jroll | dtantsur: agree, I don't see why they wouldn't merge that | 16:01 |
| ifarkas | devananda, it can be built with DIB, so it's all cool then | 16:01 |
| *** achanda has quit IRC | 16:02 | |
| devananda | also, fwiw, the tripleo folks have wanted this functionality for a while, so I would expect them to be _pleased_ to accept it | 16:02 |
| ifarkas | that's great! then we can create a discoverd element | 16:03 |
| ifarkas | if it doesn't exist already | 16:04 |
| * devananda reviews it | 16:04 | |
| devananda | in https://review.openstack.org/#/c/122151/2/elements/ironic-discoverd-ramdisk/init.d/80-discovery-ironic -- is the node UUID alraedy known? (maybe passed in the $ironic_api_url?) | 16:05 |
| *** dlaube has joined #openstack-ironic | 16:05 | |
| jroll | is the reason for using bash in these ramdisks that python would bloat it too much? | 16:05 |
| dtantsur | devananda, no. for that we need a way to associate a machine with UUID. and that's exactly what discoverd will be doing. chicken-and-egg problem :) | 16:06 |
| devananda | dtantsur: ok. thought so.... so this will always create a new Node record, even if it is re-run multiple times on the same host | 16:06 |
| dtantsur | jroll, IIRC our ramdisks do not have infrastructure for Python. Also: I would like to port the ramdisk to IPA one day :) | 16:07 |
| dtantsur | devananda, oh no | 16:07 |
| devananda | dtantsur: ?? | 16:07 |
| dtantsur | devananda, first of all discoverd does not create nodes :) | 16:07 |
| jroll | dtantsur: I mean, it's just a matter of installing python, DIB knows how to install things | 16:07 |
| devananda | NODE_RESP=$(request_curl POST $IRONIC_API_URL $NODE_DATA) | 16:07 |
| dtantsur | devananda, second, $ironic_api_url is an awful name, because it's actually URL of discoverd | 16:07 |
| dtantsur | devananda, it is discoverd that handles the logic after that point | 16:08 |
| devananda | ooooh | 16:08 |
| devananda | ok - please change that :) | 16:08 |
| dtantsur | (oh and $IRONIC_API_URL is one more awful name :D | 16:08 |
| devananda | in that case, this is quite confusing: readonly IRONIC_API_URL=$(get_kernel_parameter ironic_callback_url) | 16:08 |
| jroll | dtantsur: I'd be happy to take this in IPA, dunno if adding to the agent itself or making a new container is the right way | 16:09 |
| dtantsur | devananda, yeah, I forgot about it, sorry :) some time ago it really was Ironic endpoint | 16:09 |
| dtantsur | jroll, dunno either | 16:09 |
| jroll | dtantsur: probably just add a "discover" command to IPA | 16:10 |
| dtantsur | jroll, the problem is to call it. Discoverd has to know it's IP address. | 16:11 |
| openstackgerrit | Yuriy Zveryanskyy proposed openstack/ironic: Change some exceptions from invalid to missing https://review.openstack.org/137124 | 16:11 |
| jroll | mmm | 16:11 |
| *** ramineni1 has joined #openstack-ironic | 16:12 | |
| jroll | well, today it calls back to ironic on boot | 16:12 |
| jroll | you could do a similar thing | 16:12 |
| devananda | dtantsur: what do you think of adding stackforge/discoverd to the IRC bot notices? | 16:12 |
| dtantsur | jroll, if we do it specially for discoverd, we can just as well just send all the data :) exactly how the reference ramdisk works. | 16:12 |
| dtantsur | devananda, to this channel? I'd be happy, if you don't mind. | 16:12 |
| devananda | dtantsur: ++ | 16:12 |
| jroll | dtantsur: right, maybe a separate container is better, use a kernel param to switch | 16:12 |
| dtantsur | right | 16:13 |
| dtantsur | devananda, ack thanks :) | 16:13 |
| jroll | devananda: sdague's nova/ironic email is highly related to your interests :) | 16:13 |
| *** ramineni has quit IRC | 16:13 | |
| dtantsur | I also need someone to review it except for 2 Red Hat guys :) and I'm ready to fast-track any ironic-code to ironic-discoverd-core as well :) | 16:13 |
| devananda | jroll: yup. on my short list to reply to. once coffee kicks i | 16:14 |
| devananda | in | 16:14 |
| jroll | cool | 16:15 |
| devananda | dtantsur: adding it to my gertty config now :) | 16:15 |
| dtantsur | oh good :) | 16:15 |
| * jroll bbiab | 16:17 | |
| NobodyCam | brb | 16:18 |
| *** kfox1111 has joined #openstack-ironic | 16:24 | |
| kfox1111 | Morning all. | 16:24 |
| kfox1111 | so, what would be the best way to go about setting up a raid with the agent? | 16:26 |
| kfox1111 | or should the image itself just pack itself as a partial array and then extend itself to the other disk? | 16:27 |
| openstackgerrit | Jarrod Johnson proposed stackforge/pyghmi: Provide access to chassis identify https://review.openstack.org/137129 | 16:28 |
| devananda | kfox1111: if you're doing hardware raid, I'd do that in the agent. if software raid, I'd go with option 2 | 16:28 |
| *** igordcard has joined #openstack-ironic | 16:31 | |
| devananda | kfox1111: i haven't tried the degraded raid image approach yet. from several discussions, I think it could work | 16:32 |
| *** hemna__ has joined #openstack-ironic | 16:32 | |
| kfox1111 | there is no hardware raid controllers, so I'll have to do the latter. | 16:33 |
| kfox1111 | do you know if dib supports tweaking the partitioning? | 16:33 |
| JayF | I'm confused by sdague's email. I thought the entire point of being integrated was being able to have voting jobs? | 16:35 |
| devananda | JayF: it used to be. That's something some people want to change | 16:35 |
| devananda | JayF: where "that" == "the definition of being 'part of OpenStack'" | 16:36 |
| JayF | Sure; but I haven't seen anything official come down that is changing; although lots of text has been written about ideas to change it | 16:36 |
| devananda | yep | 16:37 |
| *** alexpilotti has quit IRC | 16:37 | |
| *** alexpilotti has joined #openstack-ironic | 16:38 | |
| *** ramineni1 has quit IRC | 16:40 | |
| *** anderbubble has quit IRC | 16:41 | |
| devananda | jroll: do you recall the patch where unit tests were added to Nova that enforced the contract(s) we expect in their driver api ? | 16:41 |
| kfox1111 | ah. elements/vm/block-device.d/10-partition. :) | 16:41 |
| devananda | I'm grepping around and don't see them... but for now I'm going to believe that I'm just overlooking them | 16:42 |
| JayF | I do remember that | 16:43 |
| JayF | I think it was posted to the mailing list | 16:44 |
| * JayF searches | 16:44 | |
| JayF | devananda: https://review.openstack.org/#/c/98201 | 16:44 |
| * JayF is good at the internet | 16:44 | |
| openstackgerrit | Merged stackforge/pyghmi: Provide access to chassis identify https://review.openstack.org/137129 | 16:45 |
| JayF | Shrews: going to test your devstack patch this morning | 16:46 |
| JayF | erm | 16:46 |
| JayF | adam_g: ^ | 16:46 |
| lucasagomes | jroll, right (sorry the delay to answer) | 16:48 |
| lucasagomes | jroll, I was just thinking of how we can actually tell the user of the API that, maintenance is actually deprecated | 16:48 |
| lucasagomes | maybe only documentation is enough | 16:48 |
| lucasagomes | (better than the logging that he can't see anyway) | 16:48 |
| lucasagomes | but we need somehow to indicate that | 16:48 |
| devananda | this makes me sad ... | 16:49 |
| devananda | deva@9470m:/opt/source/openstack/nova⟫ find ./ -name test_ironic_api_contracts.py | 16:49 |
| devananda | deva@9470m:/opt/source/openstack/nova⟫ | 16:49 |
| devananda | where did the file go? | 16:49 |
| lucasagomes | :/ | 16:49 |
| rloo | my guess is that it was deleted after the ironic driver was merged | 16:49 |
| dtantsur | devananda, re IRC: https://review.openstack.org/#/c/137136 | 16:50 |
| lucasagomes | devananda, git log -- <file path> | 16:50 |
| devananda | dtantsur: cheers | 16:50 |
| dtantsur | ok now time to go, see you tomorrow | 16:51 |
| *** dtantsur has quit IRC | 16:52 | |
| devananda | ok -- wtf? we deleted it? https://review.openstack.org/#/c/111425/ | 16:52 |
| devananda | patch set 11 | 16:53 |
| *** yjiang5 has joined #openstack-ironic | 16:53 | |
| openstackgerrit | Merged openstack/python-ironicclient: Fix node-set-provision-state cmd's help strings https://review.openstack.org/135518 | 16:53 |
| lucasagomes | ew | 16:54 |
| devananda | mrda_away: when you're around, do you remember why you deleted test_ironic_api_contracts.py in https://review.openstack.org/#/c/111425/ ? | 16:55 |
| openstackgerrit | Nisha Agarwal proposed openstack/ironic-specs: Discover node properties using new CLI node-discover-properties https://review.openstack.org/100951 | 16:56 |
| *** ifarkas has quit IRC | 16:56 | |
| lucasagomes | does seems to have any comments to indicate why we deleted that | 16:56 |
| lucasagomes | doesn't* | 16:57 |
| lucasagomes | I will have to go (in paris now) they are closing the office | 16:57 |
| *** kfox1111 has quit IRC | 16:57 | |
| lucasagomes | see ya | 16:57 |
| *** lucasagomes has quit IRC | 16:58 | |
| openstackgerrit | Jay Faulkner proposed openstack/ironic: Improve docs for running IPA in Devstack https://review.openstack.org/137139 | 16:58 |
| openstackgerrit | Jay Faulkner proposed openstack/ironic: Improve docs for running IPA in Devstack https://review.openstack.org/137139 | 16:58 |
| *** athomas has quit IRC | 16:59 | |
| *** davideagnello has quit IRC | 17:00 | |
| *** davideagnello has joined #openstack-ironic | 17:01 | |
| *** pensu has joined #openstack-ironic | 17:01 | |
| *** sambetts has quit IRC | 17:02 | |
| *** sambetts has joined #openstack-ironic | 17:02 | |
| *** kfox1111 has joined #openstack-ironic | 17:02 | |
| *** anderbubble has joined #openstack-ironic | 17:03 | |
| jroll | devananda: maybe we thought having our unit tests in tree was enough? (I don't think it is) | 17:05 |
| devananda | maybe? | 17:06 |
| jroll | oh, there's a comment on patch set 13 | 17:07 |
| jroll | This was removed as a result of a comment by Daniel Berrange. We added in this test: | 17:07 |
| jroll | def test_public_api_signatures(self): | 17:07 |
| jroll | self.assertPublicAPISignatures(self.driver) | 17:07 |
| jroll | which is equivalent to these tests I believe. | 17:07 |
| jroll | Yes, the assertPublicAPISignatures test case validates that every API implemented by ironic/driver.py has 100% matching parameter set to the driver API in nova/virt/driver.py It is driven by python's introspection capabilities, so guaranteed to always reflect current state of affairs unlike this manually written test attempting to achieve the same end goal. | 17:07 |
| jroll | ^ that is from mrda, then berrange | 17:07 |
| *** igordcard has quit IRC | 17:10 | |
| devananda | ah, ok | 17:15 |
| *** yjiang5 has left #openstack-ironic | 17:18 | |
| *** derekh has quit IRC | 17:25 | |
| NobodyCam | zapping just seems like a strange state to do burn-in in :-p | 17:26 |
| adam_g | JayF, that devstack patch is still not quite right, at least not running in the gate with USE_SCREEN=False. | 17:26 |
| JayF | then I guess I'm, in a roundabout way, glad my VM didn't have enough ram and died during the first stack | 17:27 |
| JayF | lol | 17:27 |
| JayF | adam_g: https://review.openstack.org/137139 is relevant to your interests | 17:27 |
| JayF | jroll: ^ as well | 17:27 |
| * jroll looks | 17:28 | |
| *** alexpilotti has quit IRC | 17:28 | |
| jroll | +2 | 17:29 |
| openstackgerrit | Nisha Agarwal proposed openstack/ironic-specs: Discover node properties for iLO drivers https://review.openstack.org/103007 | 17:29 |
| openstackgerrit | Jay Faulkner proposed openstack/ironic-python-agent: Improve/add docstrings for CommandResult classes https://review.openstack.org/120663 | 17:33 |
| JayF | ^ another easy review if someone wants to have a look | 17:36 |
| *** lazy_prince is now known as killer_prince | 17:36 | |
| * JayF trying to tie up loose ends | 17:36 | |
| NobodyCam | JayF: lines 62-64 seem strange to me RE: https://review.openstack.org/#/c/120663/7/ironic_python_agent/extensions/base.py | 17:38 |
| NobodyCam | your returning excatly what was just passed in? | 17:38 |
| JayF | I'm only responsible for the comment :) | 17:38 |
| JayF | for the base command it does nothing | 17:38 |
| jroll | NobodyCam: that's the base class, check out join() for AsyncCommandResult | 17:39 |
| JayF | or for the sync | 17:39 |
| JayF | for the asy... yeah | 17:39 |
| *** ndipanov is now known as ndipanov_gone | 17:39 | |
| *** jcoufal has quit IRC | 17:40 | |
| *** Nisha has joined #openstack-ironic | 17:41 | |
| *** andreykurilin_ has joined #openstack-ironic | 17:42 | |
| jroll | JayF: reviewed, left comments | 17:43 |
| JayF | will fix real quick | 17:45 |
| *** harlowja_away is now known as harlowja | 17:49 | |
| *** jistr has quit IRC | 17:52 | |
| NobodyCam | hummm I think our spec repo may have the wrong license file: https://github.com/openstack/ironic-specs/blob/master/LICENSE is a Apache License while the spec's refference Creative Commons Attribution 3.0 Unported License.. | 17:55 |
| NobodyCam | devananda: ^^^ is that a issue? | 17:56 |
| NobodyCam | really anyone | 17:56 |
| jroll | seems fine | 17:57 |
| jroll | apache license for code, CC for prose | 17:57 |
| jroll | (I think) | 17:57 |
| jroll | I would assume that a license on a single file overrides the license for the repo, also, but I am not a lawyer :) | 17:58 |
| *** rushiagr is now known as rushiagr_away | 17:59 | |
| *** romcheg has quit IRC | 17:59 | |
| NobodyCam | jroll: I ask because I saw this on hte ML: http://lists.openstack.org/pipermail/openstack-dev/2014-November/051498.html | 18:00 |
| jroll | oh, hm | 18:01 |
| jroll | maybe respond with "this is what we're doing in ironic, is this correct?" | 18:01 |
| devananda | see next email in taht thread, referencing Nova: http://git.openstack.org/cgit/openstack/nova-specs/tree/LICENSE | 18:10 |
| devananda | so, yup, we're possibly doing it wrong | 18:11 |
| *** jjohnson2 has quit IRC | 18:11 | |
| NobodyCam | thats how I took that | 18:11 |
| *** russellb has quit IRC | 18:11 | |
| *** jjohnson2 has joined #openstack-ironic | 18:11 | |
| devananda | where "wrong" == "not like Nova" | 18:11 |
| devananda | also, I don't know why Apache v2 would be an inappropriate license here | 18:11 |
| *** russellb has joined #openstack-ironic | 18:12 | |
| devananda | given that each spec has a CC-BY-UL header, which overrides the repo-level LICENSE, I do interpret this to mean we've put an Apache license on any code in ironic-specs/ | 18:12 |
| devananda | and that is correct | 18:12 |
| *** bradjones has quit IRC | 18:13 | |
| NobodyCam | ok so no update is required :) | 18:14 |
| devananda | juno/ironic-ilo-virtualmedia-driver.rst is the only one missing a license header | 18:15 |
| openstackgerrit | Devananda van der Veen proposed openstack/ironic-specs: Add missing license header to ironic-ilo-virtualmedia-driver https://review.openstack.org/137162 | 18:17 |
| devananda | IANAL, but I think this is fine | 18:18 |
| openstackgerrit | Jay Faulkner proposed openstack/ironic-python-agent: Improve/add docstrings for CommandResult classes https://review.openstack.org/120663 | 18:18 |
| JayF | jroll: ^ | 18:18 |
| NobodyCam | ack Thank you devananda :) | 18:19 |
| Nisha | JayF: jroll i was working on enabling agent-ilo for uefi. the other day you gave me efi capable image location.http://stable.release.core-os.net/amd64-usr/current/coreos_production_rackspace_onmetal_image.img.bz2 .....but the image doesnt boot up in uefi mode | 18:22 |
| Nisha | for bios it works | 18:22 |
| JayF | I wasn't saying it was UEFI | 18:22 |
| JayF | I was saying it was GPT | 18:22 |
| JayF | and that you could use IPA to deploy an image with UEFI boot configured properly and it would work | 18:22 |
| JayF | I personally do not know where to find such an image, nor do I have hardware to test it | 18:22 |
| *** davideagnello has quit IRC | 18:23 | |
| Nisha | the system is in uefi boot mode. what else needs to be configured? | 18:23 |
| Nisha | the deploy iso goes thru, but the second boot up screen is stuck | 18:24 |
| JayF | meaning you have to have the image setup properly | 18:24 |
| *** davideagnello has joined #openstack-ironic | 18:24 | |
| JayF | i.e. GPT with a fat partition with a .efi rom inside | 18:24 |
| Nisha | please elaborate | 18:24 |
| JayF | Exactly like I said before: if you took a system, used the installer to build out a UEFI booting linux | 18:25 |
| *** sambetts has quit IRC | 18:25 | |
| JayF | then took an image of that disk | 18:25 |
| JayF | and used it as the image on another machine | 18:25 |
| Nisha | but the other day you said that itis all inbuilt inside the image | 18:25 |
| JayF | it would work and UEFI boot | 18:25 |
| JayF | it is! | 18:25 |
| JayF | an image can have multiple partitions | 18:25 |
| Nisha | yes that's true | 18:26 |
| JayF | So that means if you make an image with the right GPT paritions, and a UEFI boot rom in the proper place, all you need is a deployment method for full disk images | 18:26 |
| JayF | which IPA supports *today* | 18:26 |
| Nisha | is there a way to create such image ? | 18:27 |
| Nisha | for agent driver alone also, i was thinking it cannot automatically switch the boot mode as per the desired capability | 18:28 |
| JayF | I honestly don't know :( That's handled by a different group at Rackspace | 18:28 |
| Nisha | hmmmm how to qualify the agent ilo driver for uefi then? | 18:29 |
| Nisha | :( | 18:29 |
| Nisha | and even agent driver | 18:29 |
| JayF | IDK, I've been reviewing and trying to help but I don't have any UEFI capable hardware for testing | 18:29 |
| *** sirushti has left #openstack-ironic | 18:29 | |
| Nisha | can u test that on a vm? i think that should be same...just a suggestion not very sure | 18:30 |
| *** alexpilotti has joined #openstack-ironic | 18:33 | |
| JayF | I don't know. | 18:34 |
| *** penick has joined #openstack-ironic | 18:34 | |
| jroll | Nisha: perhaps there is someone at your employer who can make an image that is capable of UEFI | 18:35 |
| *** rushiagr_away is now known as rushiagr | 18:36 | |
| openstackgerrit | Merged openstack/ironic: Update 'Introduction to Ironic' document https://review.openstack.org/136136 | 18:36 |
| Nisha | can IPA deploy images apart from coreos? | 18:36 |
| jroll | IPA can deploy any full disk image | 18:36 |
| jroll | the coreos image was an example of an image with GPT partitions | 18:37 |
| Nisha | i asked this because even the ramdisk and kernel creation using docker uses coreos for its creation | 18:37 |
| Nisha | hence asked if it can support any disk image | 18:38 |
| jroll | we run the IPA ramdisk in CoreOS | 18:38 |
| jroll | for deploying an image with ironic, IPA can write any full disk image | 18:38 |
| jroll | it just downloads the image and dd's it to the disk | 18:38 |
| jroll | nothing fancy | 18:39 |
| jroll | no partitioning | 18:39 |
| jroll | just download and dd | 18:39 |
| rloo | NobodyCam, devananda, wrt nova-specs license. Looks like nova changed to cc-by cuz it is docn not code: http://git.openstack.org/cgit/openstack/nova-specs/commit/LICENSE?id=d230458f333fba8e4f5f1908c51df8d4e5c14dc3 | 18:39 |
| jroll | huh | 18:40 |
| jroll | but what about the code? | 18:40 |
| rloo | jroll: code we use apache | 18:41 |
| rloo | but I'm no lawyer ;) | 18:41 |
| NobodyCam | is this because the code is in a different repo? | 18:41 |
| jroll | there is code in ironic-specs | 18:41 |
| rloo | oh, you mean like the tests | 18:41 |
| rloo | russell referenced this thread: http://lists.openstack.org/pipermail/legal-discuss/2014-March/000201.html | 18:42 |
| jroll | right, I saw that | 18:43 |
| jroll | that was before they made the repo afaict | 18:43 |
| *** spandhe has joined #openstack-ironic | 18:43 | |
| rloo | it seems like the repo licence should be apache then, but the specs themselves cc-by? | 18:43 |
| jroll | as it is today : | 18:44 |
| jroll | :) | 18:44 |
| rloo | jroll: ha ha. I hadn't looked to see what we were doing, only read the scroll back! We're good then. I think ;) | 18:45 |
| *** achanda has joined #openstack-ironic | 18:47 | |
| openstackgerrit | Alex Weeks proposed openstack/ironic-specs: Moved metrics spec to kilo https://review.openstack.org/137171 | 18:48 |
| devananda | rloo: except for one spec, which was missing a cc-by header. I proposed a patch to add it. we should also have a test for it | 18:48 |
| NobodyCam | devananda: which should be landing now | 18:49 |
| rloo | devananda: +1 for a test. Do we have such a test (for apache) for our code? | 18:49 |
| * rloo never looks at that 'stuff' at the top, when reviewing | 18:50 | |
| openstackgerrit | Merged openstack/ironic-specs: Add missing license header to ironic-ilo-virtualmedia-driver https://review.openstack.org/137162 | 18:50 |
| *** achanda_ has joined #openstack-ironic | 18:52 | |
| *** achanda has quit IRC | 18:52 | |
| JoshNang | rloo: we def have a test for missing apache license | 18:53 |
| JoshNang | i've hit it before when creating new files | 18:53 |
| JayF | not in -specs | 18:53 |
| rloo | JoshNang: cool. | 18:53 |
| JayF | which is the context of the conversation currently :) | 18:53 |
| rloo | someone could go through all the *-specs repos, adding a test for the license. I'm sure someone will... | 18:54 |
| *** penick has quit IRC | 18:54 | |
| NobodyCam | rloo: sounds like a good LHF bug | 18:56 |
| rloo | NobodyCam: yeah. That's why I'm sure someone will jump at it. Much as I'd like to do that, I figure I should look at the specs ;) | 18:58 |
| *** harlowja is now known as harlowja_away | 18:58 | |
| NobodyCam | JayF: landing 120663 now :) | 18:59 |
| NobodyCam | woo hoo new meeting times are posted | 19:02 |
| *** achanda_ has quit IRC | 19:04 | |
| NobodyCam | brb... quick walkies | 19:04 |
| *** achanda has joined #openstack-ironic | 19:04 | |
| *** achanda has quit IRC | 19:05 | |
| *** achanda has joined #openstack-ironic | 19:07 | |
| *** harlowja_away is now known as harlowja | 19:07 | |
| *** penick has joined #openstack-ironic | 19:08 | |
| dlaube | hey guys, quick question about console in ironic | 19:09 |
| *** jistr has joined #openstack-ironic | 19:09 | |
| *** aswadr has quit IRC | 19:10 | |
| dlaube | when I run ironic node-get-console NODE_UUID, property console_info comes back as None | 19:11 |
| jroll | dlaube: may depend on the driver? or might need to turn on console mode, I forget | 19:11 |
| jroll | what driver are you using? | 19:11 |
| dlaube | are there some specific values I should be setting under the nodes's console_info in order to get that populated? | 19:11 |
| dlaube | pxe_ipmitool | 19:12 |
| jroll | ok, that driver should work | 19:12 |
| jroll | I have no idea on the rest, never tried it :) | 19:12 |
| dlaube | ok | 19:13 |
| dlaube | I appreciate the honest answer | 19:13 |
| jroll | I feel like there's a console state you need to flip, though | 19:14 |
| dlaube | you mean this? | 19:14 |
| dlaube | ironic node-set-console-mode 21119b95-d11a-4f95-b3c8-bf3514e06d77 true | 19:14 |
| jroll | node-set-console-mode | 19:14 |
| jroll | yeah | 19:14 |
| dlaube | let me paste output, 1sec | 19:15 |
| dlaube | http://pastie.org/private/bvcqxhtnlqluqklvporkg | 19:15 |
| *** achanda_ has joined #openstack-ironic | 19:19 | |
| *** achanda has quit IRC | 19:20 | |
| *** pensu has quit IRC | 19:20 | |
| jroll | dlaube: interesting, no idea :| | 19:20 |
| rloo | dlaube: the paste output doesn't show you setting console mode to True? | 19:21 |
| rloo | dlaube: forget that. had to scroll | 19:21 |
| rloo | dlaube: might want to look at the logs then. | 19:21 |
| openstackgerrit | Merged openstack/ironic-python-agent: Improve/add docstrings for CommandResult classes https://review.openstack.org/120663 | 19:21 |
| NobodyCam | thank you devananda | 19:23 |
| devananda | adam_g, NobodyCam: do you recall, last cycle, the times when nova changes broke our gate? sdague is asking for specific cases of that | 19:23 |
| adam_g | devananda, yeah im digging thru git now | 19:23 |
| adam_g | https://review.openstack.org/#/c/94043/ was one | 19:23 |
| devananda | I know we kept some notes on the etherpad, but .. | 19:23 |
| NobodyCam | gah I think that history was wiped out | 19:24 |
| devananda | adam_g: yup. which, sadly, I +1'd | 19:24 |
| adam_g | devananda, i remember there being a really bad one when we were sitting together in raleigh, but im having trouble findingi it | 19:24 |
| devananda | adam_g: I recall one that I thought changed test_ironic_api_contracts but now I can't find that either | 19:24 |
| jroll | devananda: etherpad has history | 19:25 |
| devananda | jroll: yup. ever try digging through a long-lived pad's history? | 19:25 |
| jroll | :D | 19:25 |
| jroll | I just removed it last week though | 19:25 |
| devananda | oh - FYI folks, I've updated the meeting time in the places and things | 19:26 |
| jroll | devananda: oh, and apparently it only is showing history for today | 19:26 |
| jroll | thanks etherpad | 19:27 |
| devananda | jroll: wait for it ... | 19:27 |
| adam_g | devananda, the only two i see that touched contract tests after they were added was https://review.openstack.org/#/c/68942/ and https://review.openstack.org/#/c/94043/ | 19:27 |
| jroll | "Version 0 Saved November 25, 2014" | 19:27 |
| *** agordeev has quit IRC | 19:29 | |
| *** agordeev has joined #openstack-ironic | 19:29 | |
| NobodyCam | devananda: https://review.openstack.org/#/c/116093/ this is one I think | 19:30 |
| adam_g | yeah ^ | 19:30 |
| adam_g | both 94043 and 68942 broke us | 19:30 |
| * devananda trawls the etherpad | 19:32 | |
| devananda | adam_g: https://review.openstack.org/#/c/68942/ is the one I was thinking of -- but it looks like our -nv test passed?? | 19:33 |
| devananda | patch 32 | 19:33 |
| devananda | check-tempest-dsvm-virtual-ironic-nv SUCCESS in 38m 56s (non-voting) | 19:33 |
| devananda | I also found these looking through the etherpad | 19:35 |
| devananda | https://review.openstack.org/#/c/107562/ | 19:35 |
| devananda | https://review.openstack.org/#/c/111538/ | 19:35 |
| devananda | https://review.openstack.org/#/c/105599/ | 19:35 |
| devananda | https://review.openstack.org/#/c/71557/ | 19:35 |
| adam_g | devananda, is there an associated bug with 68942? i dont remember how that broke us, if it did at all | 19:36 |
| jroll | devananda: I'm guessing our tests don't call shutdown | 19:37 |
| *** ChuckC has quit IRC | 19:40 | |
| *** Nisha has quit IRC | 19:43 | |
| NobodyCam | I'm glad we saved that info :) | 19:45 |
| *** penick has quit IRC | 19:49 | |
| *** achanda_ has quit IRC | 19:49 | |
| *** penick has joined #openstack-ironic | 19:49 | |
| *** penick has quit IRC | 19:51 | |
| *** penick has joined #openstack-ironic | 19:52 | |
| *** alexm__ has joined #openstack-ironic | 19:54 | |
| *** tchaypo has joined #openstack-ironic | 19:56 | |
| alexm__ | hey, why do we need to run nova-compute for ironic and how does the resource tracking work with that? | 19:59 |
| jroll | alexm__: because ironic appears to nova as a virt driver | 20:01 |
| *** ChuckC has joined #openstack-ironic | 20:01 | |
| jroll | if you use the ironic virt driver and the ironic host manager, there's code in those to handle resource tracking things | 20:01 |
| alexm__ | so must I run one nova-compute per metal node? | 20:06 |
| JayF | Oh absolutely not :) | 20:06 |
| JayF | the nova compute that talks to ironic exposes each metal node as a hypervisor host though | 20:06 |
| JayF | so you have one nova compute, it can expose hundreds or thousands of "hypervisors" (bare metal hosts) | 20:06 |
| alexm__ | yes makes more sense :) | 20:06 |
| *** achanda has joined #openstack-ironic | 20:07 | |
| alexm__ | how do we register the available memory, cpu and local disk of a remote metal node? is this part of the extra data in the ironic node? | 20:07 |
| tchaypo | I seem to have hit a fun case where my vm is running at the top of driver.modules.ssh._power_off() | 20:07 |
| JayF | it's part of node.properties on the ironic node | 20:07 |
| *** andreykurilin_ has quit IRC | 20:07 | |
| *** andreykurilin_ has joined #openstack-ironic | 20:08 | |
| tchaypo | but dead by the time virsh destroy gets called a few lines down; so the attempt to destroy it fails, and that error bubbles up and ironic gives up on the node even though it’s now in the desired state | 20:08 |
| JayF | and work to automatially populate that via introspection of the node is ongoing and mapped for kilo | 20:08 |
| alexm__ | @JayF: something like this https://pypi.python.org/pypi/ironic-discoverd/ ? | 20:08 |
| JayF | that is exactly what's being used for the in-band bit | 20:09 |
| JayF | dtantsur|afk is working on that | 20:09 |
| alexm__ | ok thanks | 20:09 |
| alexm__ | so when I add the node properties, the nova-compute will report those new resource stats for the scheduler? | 20:09 |
| jroll | yes | 20:10 |
| alexm__ | excellent, I’ll try this right way thanks guys | 20:11 |
| *** achanda has quit IRC | 20:11 | |
| *** achanda has joined #openstack-ironic | 20:12 | |
| *** jgrimm is now known as zz_jgrimm | 20:13 | |
| *** anderbubble has quit IRC | 20:14 | |
| *** zz_jgrimm is now known as jgrimm | 20:18 | |
| *** jgrimm is now known as zz_jgrimm | 20:19 | |
| *** achanda has quit IRC | 20:19 | |
| *** achanda has joined #openstack-ironic | 20:21 | |
| *** rushiagr is now known as rushiagr_away | 20:22 | |
| *** andreykurilin_ has quit IRC | 20:24 | |
| *** andreykurilin_ has joined #openstack-ironic | 20:24 | |
| *** achanda has quit IRC | 20:24 | |
| *** achanda has joined #openstack-ironic | 20:25 | |
| *** ChuckC_ has joined #openstack-ironic | 20:28 | |
| *** dprince has quit IRC | 20:29 | |
| *** ChuckC has quit IRC | 20:32 | |
| *** igordcard has joined #openstack-ironic | 20:40 | |
| *** jistr has quit IRC | 20:41 | |
| *** anderbubble has joined #openstack-ironic | 20:47 | |
| devananda | anyoen remember the wacky change to nova scheduler that broke us, then got reverted? | 20:47 |
| JayF | the arch.canonicalize() ? | 20:48 |
| *** mrda_away is now known as mrda | 20:50 | |
| devananda | found it - https://review.openstack.org/#/c/71557/ | 20:51 |
| devananda | broke ironic and tripleo with a subtle change to resource_tracker.py | 20:51 |
| mrda | Morning all | 20:52 |
| jroll | morning mrda | 20:52 |
| *** zz_jgrimm is now known as jgrimm | 20:53 | |
| *** jgrimm is now known as zz_jgrimm | 20:53 | |
| NobodyCam | moring mrda :-p | 20:55 |
| rloo | devananda: don't know if this is useful or not or if you got it: https://bugs.launchpad.net/nova/+bug/1369151 | 20:59 |
| *** alexpilotti has quit IRC | 21:04 | |
| alexm__ | quick question after testing nova+ironic, what would be the most common reason of my instance sticking to BUILD/spawning state ? | 21:12 |
| alexm__ | the scheduling phase seems to have succeeded, the instance data was set on the ironic node | 21:12 |
| alexm__ | but it doesn’t actually trigger the pxe_ipmi deployment and doesn’t create the VIF | 21:13 |
| devananda | rloo: thanks. that wasn't on my list | 21:16 |
| *** davideagnello has quit IRC | 21:25 | |
| *** achanda has quit IRC | 21:28 | |
| openstackgerrit | Chris Krelle proposed openstack/ironic-specs: Add a test for license header https://review.openstack.org/137215 | 21:30 |
| NobodyCam | I'm sure there are better ways of doing ^^^ but there is one way | 21:30 |
| *** zz_jgrimm is now known as jgrimm | 21:32 | |
| *** hemna__ has quit IRC | 21:39 | |
| *** davideagnello has joined #openstack-ironic | 21:40 | |
| *** hemna__ has joined #openstack-ironic | 21:42 | |
| *** bradjones has joined #openstack-ironic | 21:47 | |
| *** Marga_ has joined #openstack-ironic | 21:49 | |
| *** davideagnello has quit IRC | 21:57 | |
| *** davideagnello has joined #openstack-ironic | 21:59 | |
| *** jjohnson2 has quit IRC | 22:05 | |
| *** ryanpetrello has quit IRC | 22:10 | |
| *** alexpilotti has joined #openstack-ironic | 22:20 | |
| *** Hefeweizen has joined #openstack-ironic | 22:22 | |
| *** achanda has joined #openstack-ironic | 22:28 | |
| *** achanda has quit IRC | 22:39 | |
| devananda | mmm, dentist appointment .... I'll probably be offline the rest of the day | 22:46 |
| JayF | gl, have a good evening | 22:47 |
| NobodyCam | hope its just a cleaning devananda | 22:47 |
| *** andreykurilin_ has quit IRC | 23:01 | |
| *** achanda has joined #openstack-ironic | 23:03 | |
| *** linggao has quit IRC | 23:05 | |
| *** achanda has quit IRC | 23:17 | |
| Haomeng | alexm__: hi | 23:23 |
| *** achanda has joined #openstack-ironic | 23:23 | |
| Haomeng | alexm__: can you check neutron logs, maybe neutron port update call failed | 23:24 |
| Haomeng | NobodyCam: morning:) | 23:24 |
| NobodyCam | morning Haomeng :) | 23:24 |
| Haomeng | NobodyCam: :) | 23:29 |
| *** anderbubble has quit IRC | 23:29 | |
| *** mjturek has quit IRC | 23:36 | |
| mrda | Hi Haomeng | 23:39 |
| *** igordcard has quit IRC | 23:46 | |
| *** yuanying_ has joined #openstack-ironic | 23:50 | |
| Haomeng | mrda: morning:) | 23:53 |
| *** yuanying has quit IRC | 23:54 | |
| *** davideagnello has quit IRC | 23:54 | |
| *** davideagnello has joined #openstack-ironic | 23:56 | |
| *** penick has quit IRC | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!