*** epim has quit IRC | 00:13 | |
*** rloo has quit IRC | 00:23 | |
*** matsuhashi has joined #openstack-ironic | 00:29 | |
*** zdiN0bot has quit IRC | 00:32 | |
*** derekh has quit IRC | 00:37 | |
devananda | i'm done for the day. will be out in the morning for some personal errands.. see ya'll around lunch tmw! | 00:40 |
---|---|---|
*** derekh has joined #openstack-ironic | 00:43 | |
jroll | night deva :) | 00:45 |
openstackgerrit | Josh Gachnang proposed a change to openstack/ironic: Adding a reference driver for the agent https://review.openstack.org/84795 | 00:47 |
openstackgerrit | Josh Gachnang proposed a change to openstack/ironic: Adding a reference driver for the agent https://review.openstack.org/84795 | 00:59 |
*** matsuhashi has quit IRC | 00:59 | |
*** matsuhashi has joined #openstack-ironic | 01:01 | |
openstackgerrit | Josh Gachnang proposed a change to openstack/ironic: Adding a reference driver for the agent https://review.openstack.org/84795 | 01:03 |
*** yfujioka has quit IRC | 01:05 | |
*** derekh has quit IRC | 01:14 | |
*** eguz has joined #openstack-ironic | 01:20 | |
*** eghobo has quit IRC | 01:24 | |
*** nosnos has joined #openstack-ironic | 01:41 | |
NobodyCam | anyone seen this one? HTTPInternalServerError: Timeout while waiting on RPC response - topic: "ironic.conductor_manager.ubuntu", RPC method: "update_node" info: "<unknown>" | 01:48 |
*** zdin0bot has joined #openstack-ironic | 02:31 | |
*** coolsvap|afk is now known as coolsvap | 02:33 | |
*** dwalleck has joined #openstack-ironic | 02:35 | |
*** harlowja is now known as harlowja_away | 02:43 | |
*** dwalleck has quit IRC | 02:45 | |
*** krtaylor has joined #openstack-ironic | 02:58 | |
*** dwalleck has joined #openstack-ironic | 02:58 | |
*** dwalleck has quit IRC | 03:01 | |
*** dwalleck has joined #openstack-ironic | 03:02 | |
*** openstackgerrit has quit IRC | 03:04 | |
*** openstackgerrit has joined #openstack-ironic | 03:04 | |
*** dwalleck has quit IRC | 03:07 | |
*** matsuhashi has quit IRC | 03:14 | |
*** matsuhashi has joined #openstack-ironic | 03:15 | |
*** matsuhashi has quit IRC | 03:19 | |
*** nosnos has quit IRC | 03:29 | |
*** eghobo has joined #openstack-ironic | 03:48 | |
*** rwsu has quit IRC | 03:50 | |
*** zdin0bot has quit IRC | 03:50 | |
*** datajerk has joined #openstack-ironic | 03:56 | |
*** ilives has joined #openstack-ironic | 04:10 | |
*** eghobo has quit IRC | 04:10 | |
*** eghobo has joined #openstack-ironic | 04:10 | |
*** eguz has joined #openstack-ironic | 04:13 | |
*** zdin0bot has joined #openstack-ironic | 04:14 | |
*** killer_prince has quit IRC | 04:15 | |
*** eghobo has quit IRC | 04:17 | |
*** dwalleck has joined #openstack-ironic | 04:17 | |
*** rameshg87 has joined #openstack-ironic | 04:18 | |
*** matsuhashi has joined #openstack-ironic | 04:19 | |
*** nosnos has joined #openstack-ironic | 04:22 | |
*** dwalleck has quit IRC | 04:31 | |
*** dwalleck has joined #openstack-ironic | 04:31 | |
*** hemna_ has quit IRC | 04:42 | |
*** coolsvap is now known as coolsvap|afk | 04:45 | |
*** zdin0bot has quit IRC | 04:47 | |
*** dwalleck_ has joined #openstack-ironic | 04:49 | |
*** lazy_prince has joined #openstack-ironic | 04:52 | |
*** dwalleck has quit IRC | 04:52 | |
*** lazy_prince is now known as killer_prince | 04:52 | |
*** Mikhail_D_ltp has joined #openstack-ironic | 04:55 | |
*** coolsvap|afk is now known as coolsvap | 04:57 | |
*** shakamunyi has quit IRC | 05:14 | |
*** dwalleck_ has quit IRC | 05:18 | |
*** coolsvap is now known as coolsvap|afk | 05:28 | |
*** Mikhail_D_ltp has quit IRC | 05:33 | |
*** coolsvap|afk is now known as coolsvap | 05:36 | |
*** matsuhashi has quit IRC | 05:37 | |
*** matsuhashi has joined #openstack-ironic | 05:37 | |
*** matsuhashi has quit IRC | 05:43 | |
*** matsuhashi has joined #openstack-ironic | 05:44 | |
*** zdin0bot has joined #openstack-ironic | 05:44 | |
*** zdin0bot has quit IRC | 05:49 | |
*** matsuhas_ has joined #openstack-ironic | 05:50 | |
*** matsuhashi has quit IRC | 05:53 | |
*** matsuhas_ has quit IRC | 05:58 | |
*** matsuhashi has joined #openstack-ironic | 05:58 | |
*** yonglihe_ has quit IRC | 05:58 | |
*** ilives has quit IRC | 06:07 | |
*** ilives has joined #openstack-ironic | 06:07 | |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic: Imported Translations from Transifex https://review.openstack.org/88508 | 06:07 |
*** zdin0bot has joined #openstack-ironic | 06:28 | |
*** ifarkas has joined #openstack-ironic | 06:28 | |
*** eguz has quit IRC | 06:42 | |
*** lazy_prince has joined #openstack-ironic | 06:44 | |
*** lsmola has joined #openstack-ironic | 06:48 | |
*** zdin0bot has quit IRC | 06:54 | |
*** viktors_away is now known as viktors | 06:59 | |
*** romcheg1 has joined #openstack-ironic | 07:12 | |
*** martyntaylor has joined #openstack-ironic | 07:18 | |
*** ilives has quit IRC | 07:29 | |
*** ilives has joined #openstack-ironic | 07:30 | |
*** ndipanov_gone is now known as ndipanov | 07:37 | |
*** rameshg87 has left #openstack-ironic | 07:40 | |
*** ilives has quit IRC | 07:47 | |
*** vkozhukalov has joined #openstack-ironic | 07:51 | |
*** ilives has joined #openstack-ironic | 07:53 | |
*** derekh has joined #openstack-ironic | 08:02 | |
*** yuriyz has joined #openstack-ironic | 08:03 | |
Mikhail_D_wk | morning all! :) | 08:12 |
*** ilives has quit IRC | 08:20 | |
*** jistr has joined #openstack-ironic | 08:21 | |
*** ilives has joined #openstack-ironic | 08:22 | |
*** matsuhashi has quit IRC | 08:27 | |
dtantsur | Morning Ironic, morning Mikhail_D_wk | 08:28 |
*** matsuhashi has joined #openstack-ironic | 08:34 | |
*** lucasagomes has joined #openstack-ironic | 08:40 | |
*** BadCub has quit IRC | 08:41 | |
*** ilives has quit IRC | 08:42 | |
*** ilives has joined #openstack-ironic | 08:43 | |
*** radsy has joined #openstack-ironic | 08:50 | |
*** radsy has joined #openstack-ironic | 08:50 | |
*** ilives has quit IRC | 08:50 | |
*** ilives has joined #openstack-ironic | 08:52 | |
*** romcheg2 has joined #openstack-ironic | 09:10 | |
*** romcheg1 has quit IRC | 09:10 | |
*** romcheg1 has joined #openstack-ironic | 09:13 | |
*** Alexei_987 has joined #openstack-ironic | 09:14 | |
agordeev | good morning Ironic :) | 09:14 |
*** romcheg2 has quit IRC | 09:14 | |
*** ilives has quit IRC | 09:34 | |
*** radsy has quit IRC | 09:44 | |
*** radsy has joined #openstack-ironic | 10:11 | |
*** radsy has quit IRC | 10:11 | |
*** radsy has joined #openstack-ironic | 10:11 | |
*** matsuhashi has quit IRC | 10:16 | |
*** radsy has quit IRC | 10:21 | |
*** matsuhashi has joined #openstack-ironic | 10:23 | |
*** max_lobur has joined #openstack-ironic | 10:28 | |
*** foexle has joined #openstack-ironic | 10:32 | |
*** coolsvap is now known as coolsvap|afk | 10:38 | |
*** Alexei_987 has quit IRC | 10:56 | |
*** matsuhashi has quit IRC | 11:04 | |
*** killer_prince has quit IRC | 11:10 | |
*** killer_p- has joined #openstack-ironic | 11:21 | |
*** killer_p- is now known as killer_prince | 11:21 | |
*** lazy_prince has quit IRC | 11:31 | |
andreykurilin | devananda, hi! can you review my patch? https://review.openstack.org/#/c/71500/ | 11:33 |
*** lucasagomes is now known as lucas-hungry | 12:00 | |
*** coolsvap|afk is now known as coolsvap | 12:01 | |
*** romcheg1 has left #openstack-ironic | 12:04 | |
*** romcheg1 has joined #openstack-ironic | 12:04 | |
*** jistr is now known as jistr|english | 12:06 | |
*** nosnos has quit IRC | 12:10 | |
dtantsur | lifeless, around? Mind looking at https://blueprints.launchpad.net/ironic/+spec/pxe-master-images-caching ? this is result of cache-related discussion last week | 12:15 |
*** sabah has joined #openstack-ironic | 12:17 | |
*** lazy_prince has joined #openstack-ironic | 12:33 | |
*** killer_prince has quit IRC | 12:33 | |
*** lazy_prince is now known as killer_prince | 12:33 | |
*** stephenpearson has joined #openstack-ironic | 12:40 | |
openstackgerrit | Sandhya Balakrishnan proposed a change to openstack/ironic: Add Ironic User Guide https://review.openstack.org/89818 | 12:40 |
*** jgrimm has joined #openstack-ironic | 12:44 | |
*** rloo has joined #openstack-ironic | 12:44 | |
*** jdob has joined #openstack-ironic | 12:48 | |
*** sabah has quit IRC | 12:48 | |
*** lucas-hungry is now known as lucasagomes | 13:09 | |
*** jbjohnso has joined #openstack-ironic | 13:11 | |
*** matty_dubs|gone is now known as matty_dubs | 13:11 | |
*** rloo has quit IRC | 13:29 | |
*** rloo has joined #openstack-ironic | 13:30 | |
yuriyz | morning/evening Ironic | 13:39 |
NobodyCam | Morning yuriyz and ironic... running a little later this morning | 13:39 |
*** jistr|english is now known as jistr | 13:43 | |
openstackgerrit | Andrey Kurilin proposed a change to openstack/python-ironicclient: Sync latest code and reuse exceptions from oslo https://review.openstack.org/71500 | 13:43 |
*** romcheg2 has joined #openstack-ironic | 13:45 | |
matty_dubs | G'day, Ironic | 13:46 |
*** romcheg1 has quit IRC | 13:47 | |
dtantsur | morning yuriyz, NobodyCam, matty_dubs | 13:50 |
* dtantsur bbl | 13:53 | |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Implement more robust caching for master images https://review.openstack.org/85387 | 13:55 |
*** martyntaylor has left #openstack-ironic | 13:56 | |
*** linggao has joined #openstack-ironic | 13:59 | |
*** romcheg1 has joined #openstack-ironic | 13:59 | |
*** romcheg2 has quit IRC | 14:01 | |
*** zdin0bot has joined #openstack-ironic | 14:08 | |
*** rwsu has joined #openstack-ironic | 14:14 | |
*** killer_prince has quit IRC | 14:23 | |
*** dwalleck has joined #openstack-ironic | 14:24 | |
stephenpearson | Hi, Noob question .. Inside a vmware guest, I followed http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html and I have a working dev environment. What I'd like to do is to try building an external node (i.e. another vmware guest). Made some progress but got stuck and I'm struggling to find documentation to help me with this. Any general pointers? | 14:27 |
stephenpearson | I think I have dhcp requests getting as far as the dnsmasq namespace, but the dhcp config for my node I enrolled in Ironic doesn't exist. | 14:28 |
stephenpearson | Oh and my node is stuck in the spawning state. | 14:29 |
*** dwalleck has quit IRC | 14:31 | |
matty_dubs | stephenpearson: Is http://docs.openstack.org/developer/ironic/deploy/install-guide.html any help? | 14:32 |
*** zdin0bot has quit IRC | 14:32 | |
*** zdin0bot has joined #openstack-ironic | 14:32 | |
agordeev | morning/evening Ironic :) | 14:32 |
NobodyCam | morning dtantsur | 14:33 |
stephenpearson | matty_dubs: Thanks - Think that's more wrt getting the service actually running. Seems to working already for 'internal' nodes. | 14:34 |
matty_dubs | stephenpearson: We're working on documentation a good bit right now -- https://etherpad.openstack.org/p/IronicDocumentationTasks is an etherpad to track that, but the start includes links to various existing documentation | 14:35 |
stephenpearson | Maybe its something dumb like not setting the correct ram so the n-sch doesn't pick up the node. matty_dubs: Ok I'll have a rummage through those - ta. | 14:36 |
matty_dubs | Though I'm not sure any of it's terribly useful to you right now :-\ | 14:36 |
agordeev | stephenpearson: all that you want is to expose another guest as fake baremetal vm for ironic, right? | 14:37 |
stephenpearson | agordeev: Yes, but external to the devstack environment. I used the fake driver as I'm only testing for the moment. | 14:38 |
agordeev | stephenpearson: well, the fake driver is so fake. It doesn't do anything. It's only for API tests | 14:39 |
stephenpearson | ok, that's fake all right. | 14:40 |
agordeev | stephenpearson: i'm sure that it's possible to provision the another guest with ironic. But you need to configure network pieces and choose suitable power driver | 14:40 |
stephenpearson | I think (not sure) I may have the network parts working. So the key thing then is to find another driver? I don't mind restarting the vmware guest by hand. | 14:41 |
agordeev | stephenpearson: i've just checked. there's no power driver for vmware. | 14:42 |
agordeev | stephenpearson: what type of fake driver did you use? | 14:43 |
matty_dubs | agordeev: There's a reference to vmware in the ssh power driver, but I've no idea if it works | 14:43 |
stephenpearson | agordeev: In 'ironic driver-list' I see "fake". I used that. | 14:43 |
agordeev | matty_dubs: ssh driver is limited to virtualbox and virsh | 14:44 |
stephenpearson | Fine, I'll move over to vbox instead. Thanks. | 14:45 |
NobodyCam | agordeev: nope vmware has been added | 14:45 |
matty_dubs | Ah, okay. I saw some code in there for a 'vmware' virt type, but it may very well not work / be supported | 14:45 |
matty_dubs | Seems to use vim-cmd for management | 14:46 |
agordeev | stephenpearson: in you case you should choose fake_pxe, so you'll switch the node's power manually | 14:46 |
matty_dubs | But I'm wholly clueless about VMware? | 14:46 |
agordeev | NobodyCam: interesting. where to look? | 14:46 |
matty_dubs | ironic/drivers/modules/ssh.py | 14:47 |
*** newell has joined #openstack-ironic | 14:47 | |
matty_dubs | I missed it landing; has it been tested much? | 14:47 |
NobodyCam | agordeev: https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/ssh.py#L69 | 14:47 |
agordeev | ooops, i might be looking at the old code :( | 14:47 |
agordeev | NobodyCam: matty_dubs stephenpearson sorry for confusing | 14:47 |
stephenpearson | agordeev: I don't have a fake_pxe driver. Ah maybe I need to fiddle with IRONIC_DRIVERS_WHITELIST. | 14:48 |
NobodyCam | I do not have vmware to test it with so I am not sure about its testing | 14:48 |
NobodyCam | hehehe | 14:48 |
*** killer_prince has joined #openstack-ironic | 14:52 | |
agordeev | stephenpearson: the networking is the trickiest part. Idk how to properly setup the networking between guests. | 14:56 |
stephenpearson | agordeev: The fact that tcpdump shows that dhcp requests find their way to dnsmasq is encouraging to me, but perhaps its just a mirage. | 14:57 |
agordeev | stephenpearson: are you sure that those requests reach the dnsmasq at neutron side? | 14:58 |
*** jistr has quit IRC | 14:59 | |
stephenpearson | Not really. I assumed that if dnsmasq's namespace can see the packets, so can dnsmasq. I could be totally wrong. | 14:59 |
*** jistr has joined #openstack-ironic | 15:01 | |
agordeev | stephenpearson: aahh, right. just curios to know how did you able to connect the another guest to the neutron's network inside of the first guest? | 15:02 |
stephenpearson | agordeev: This is basically what I did - http://paste.openstack.org/show/76790/ | 15:04 |
dtantsur | ifarkas, around? Are you still intending to work on https://bugs.launchpad.net/ironic/+bug/1231351 ? If so, you can base it on https://review.openstack.org/#/c/85387/ , I guess. Or I can take it from you, if you don't want to | 15:10 |
*** dwalleck has joined #openstack-ironic | 15:10 | |
ifarkas | dtantsur, yeah, I can continue it on your patchset | 15:10 |
ifarkas | dtantsur, I already have something up, just waiting for your patch to rebase ;-) | 15:11 |
ifarkas | dtantsur, thanks for the heads up | 15:11 |
dtantsur | ifarkas, ack. And you can start with reviewing my patch, please :) | 15:11 |
ifarkas | dtantsur, sure ;-) | 15:11 |
dtantsur | I will consider using checksums then | 15:11 |
dtantsur | ok, I'll be back in ~40 minutes | 15:12 |
*** dwalleck has quit IRC | 15:16 | |
*** viktors is now known as viktors|afk | 15:16 | |
*** zdin0bot has quit IRC | 15:20 | |
agordeev | jroll: JayF: morning and short question about IPA. does the order matter for encoding.Serializable objects? eg.: https://github.com/openstack/ironic-python-agent/blob/master/ironic_python_agent/hardware.py#L68-L73 | 15:31 |
*** zdin0bot has joined #openstack-ironic | 15:31 | |
*** foexle has quit IRC | 15:32 | |
*** yuriyz has quit IRC | 15:32 | |
*** zdin0bot has quit IRC | 15:33 | |
*** lazy_prince has joined #openstack-ironic | 15:33 | |
*** zdin0bot has joined #openstack-ironic | 15:33 | |
agordeev | jroll: JayF: i couldn't see a place where the order matters. Why couldn't it be just dict? | 15:36 |
*** zdin0bot1 has joined #openstack-ironic | 15:39 | |
*** zdin0bot has quit IRC | 15:39 | |
jroll | agordeev: the historic reason for doing that was to generate human-readable json | 15:41 |
jroll | or more readable json | 15:41 |
jroll | I'd be fine with just using a dict - do you have a performance concern, or just curious, or? | 15:42 |
jroll | also good morning ironic :) | 15:42 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Add ManagementInterface https://review.openstack.org/86063 | 15:45 |
agordeev | jroll: morning, i'm thinking about eliminating of serialize(). What if base class has serialize() which will be generating the dict with all class attributes besides callable and underscored ones | 15:45 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: IPMITool to use the new ManagementInterface https://review.openstack.org/86092 | 15:45 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: SeaMicro to use the new ManagementInterface https://review.openstack.org/86328 | 15:45 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: IPMINative to use the new ManagementInterface https://review.openstack.org/86588 | 15:45 |
NobodyCam | mornig jroll lucasagomes :) | 15:47 |
jroll | agordeev: hmm, I'm not opposed but in general I don't like magic that iterates over __dict__ or something. I'd rather define something like `serializable_fields = ['name', 'mac_address', ...]` | 15:47 |
jroll | for each class | 15:47 |
lucasagomes | NobodyCam, yo morning :) | 15:47 |
lucasagomes | morning everybody :) | 15:48 |
jroll | morning NobodyCam lucasagomes <insert every other nick in this channel> :) | 15:48 |
lucasagomes | :) | 15:48 |
lucasagomes | NobodyCam, I'm implementing the set_boot_device for the ssh driver, I did for virsh (will push the patch) and tested it | 15:49 |
lucasagomes | but it's been a bit painful to rebase everything, do you think we can start merging some of the base patches? | 15:49 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: IPMINative set_boot_device persistent https://review.openstack.org/85742 | 15:49 |
NobodyCam | lucasagomes: yes! | 15:50 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: SSH virsh to use the new ManagementInterface https://review.openstack.org/89884 | 15:50 |
lucasagomes | NobodyCam, ^ | 15:51 |
NobodyCam | ach.. one minute chatting with suse atm | 15:51 |
NobodyCam | ack even | 15:51 |
lucasagomes | :) | 15:52 |
lucasagomes | take ur time | 15:52 |
agordeev | jroll: makes sense. I'll file a bug againts it. | 15:53 |
*** vkozhukalov has quit IRC | 15:54 | |
jroll | ok | 15:54 |
*** eghobo has joined #openstack-ironic | 15:55 | |
jroll | so, neutron uses dnsmasq for its dhcp server, right? | 16:00 |
jroll | does anybody see a problem with that, especially wrt production? | 16:01 |
matty_dubs | Are there actual issues with it? It's not the first thing that comes to mind when I think of enterprise-grade DHCP servers, but does it have actual, known limits? | 16:02 |
*** matty_dubs is now known as matty_dubs|lunch | 16:02 | |
jroll | the dnsmasq homepage specificially says it's designed for small networks, to start | 16:03 |
*** lazy_prince has quit IRC | 16:06 | |
jroll | I don't personally have a lot of experience with it, but from what I hear, it's horrible especially when used at scale | 16:07 |
jroll | was hoping someone here had more insight | 16:07 |
*** blamar has quit IRC | 16:08 | |
lucasagomes | jroll, I remember that JayF pointed that out in sunnyvalle... I looked at the neutron code and it seems that it's not even pluggable :( they just support dnsmasq and it's hardcoded | 16:10 |
lucasagomes | we would need some work there to make it support other dhcp servers | 16:10 |
jroll | yeah :/ | 16:10 |
jroll | so, devananda and I discussed that the agent would need to use neutron for dhcp etc, in order to allow for agent and pxe (and other) drivers to coexist | 16:11 |
lucasagomes | NobodyCam, http://www.meetup.com/OpenStack-Ireland/events/178774492/?a=ea1_grp&rv=ea1&_af_eid=178774492&_af=event | 16:11 |
lucasagomes | :) | 16:11 |
lucasagomes | some TripleO stuff in Ireland | 16:12 |
jroll | but I have a concern that neutron's dhcp agent isn't production-ready | 16:12 |
jroll | and I do not want to have a dependency on neutron being fixed | 16:12 |
pquerna | * i'd say it also has a different deployment model that how ironic wants it | 16:12 |
pquerna | ie, commonly, its on every compute node | 16:12 |
lucasagomes | one way would be to start ur own dhcp server and not use neutron | 16:13 |
lucasagomes | to answer the dhcp requests | 16:13 |
jroll | lucasagomes: right, that's our plan | 16:14 |
*** max_lobur has quit IRC | 16:14 | |
jroll | devananda made a point that he did not want the agent to depend on that | 16:14 |
jroll | maybe I should wait for him to be around to talk about this | 16:14 |
pquerna | i'm unsure what you mean, agent depend on it | 16:15 |
pquerna | agent just wants to be running in ram on abox that booted | 16:15 |
lucasagomes | but do the agent care about the dhcp server? (after it's booted) | 16:15 |
pquerna | how you get it booted, either via neutron-world or your own dhcp | 16:15 |
jroll | the agent driver* | 16:15 |
pquerna | doesn't matter | 16:15 |
lucasagomes | ahh | 16:16 |
lucasagomes | jroll, I bet a option to work as a switch won't be a bad thing | 16:16 |
*** mkerrin has quit IRC | 16:16 | |
jroll | pquerna: so, the pxe driver has code that interacts with neutron to set up dhcp correctly | 16:16 |
lucasagomes | you can set neutron by default | 16:16 |
lucasagomes | or disable it setting a config option | 16:16 |
jroll | pquerna: it's been said that we should do the same | 16:16 |
agordeev | jroll: i'm a bit more worried about the agent is being dependent on swift's temp url | 16:16 |
jroll | agordeev: do you have a better way for the agent to get an image from glance without passing credentials all over the network? | 16:17 |
jroll | lucasagomes: that might work, I don't love it but we could do that | 16:18 |
lucasagomes | jroll, yeah, I would prefer to have neutron to support multiple dhcp servers | 16:18 |
lucasagomes | but you know, getting things in neutron is really frustraring afaict | 16:18 |
lucasagomes | so, as a short term, a config option seems ok to me | 16:18 |
jroll | ok | 16:19 |
lucasagomes | wait for devananda anyway so we can talk more about it | 16:19 |
jroll | yeah | 16:19 |
agordeev | jroll: no, i haven't. but it is a nice work around for bypassing missing agent's authentification :) Clever, i like it. But being swift dependent seems overcomplicated for the agent (IMO) | 16:20 |
*** zdin0bot1 has quit IRC | 16:21 | |
jroll | agordeev: I'm not a fan of depending on swift either, but I don't see another way at the moment | 16:21 |
jroll | suggestions welcome | 16:21 |
*** mkerrin has joined #openstack-ironic | 16:26 | |
*** jistr_ has joined #openstack-ironic | 16:27 | |
*** zdin0bot has joined #openstack-ironic | 16:30 | |
*** ndipanov is now known as ndipanov_gone | 16:30 | |
*** ndipanov_gone has quit IRC | 16:30 | |
*** zdin0bot1 has joined #openstack-ironic | 16:31 | |
*** jistr has quit IRC | 16:31 | |
*** zdin0bot1 has quit IRC | 16:33 | |
NobodyCam | lucasagomes: :) nice meetup :) | 16:33 |
lucasagomes | NobodyCam, :) yeah cool to see tripleO idea spreading, I hope I can make it to that meetup | 16:34 |
*** zdin0bot1 has joined #openstack-ironic | 16:34 | |
*** zdin0bot has quit IRC | 16:34 | |
pquerna | jroll: i think it would be reasonable to have a configuration option that is either swift temp url, OR http-unathenticated-template... where its like http://1.2.3.4/images/${image_id} | 16:34 |
pquerna | but dunno, not excited. | 16:35 |
jroll | /shrug | 16:35 |
NobodyCam | ya | 16:35 |
jroll | I could deal with that | 16:35 |
jroll | agordeev: wdyt? | 16:35 |
NobodyCam | wow that sed line is hard to follow | 16:36 |
lucasagomes | NobodyCam, yeah, editing xml with sed heh | 16:36 |
*** jistr_ has quit IRC | 16:37 | |
lucasagomes | but it's simple, sed -i '/<boot \(dev\|order\)=*\>/d;/<\/os>/i\<boot dev=\"hd\"/>' | 16:37 |
russell_h | it feels like we just need a generic way to tell the agent that an image is at a URL | 16:37 |
russell_h | only challenge is any sort of header-based auth | 16:37 |
*** zdin0bot1 has quit IRC | 16:37 | |
lucasagomes | NobodyCam, it deletes all <boot dev=> and <boot order=> fields, and then add a <boot dev=[DEVICE]> as a child of the <os> | 16:37 |
lucasagomes | s/fields/elements/g | 16:38 |
jroll | russell_h: well, the agent just hits the URL you give it, so we have that. the swift dep is really only in the driver | 16:38 |
NobodyCam | ahh ya | 16:38 |
NobodyCam | even if its set correct to begain with | 16:38 |
russell_h | jroll: right, but glance won't even necessarily use swift | 16:38 |
lucasagomes | yeah | 16:38 |
russell_h | in fact I'm given to understand that most glance deploys probably don't use swift | 16:39 |
jroll | right | 16:39 |
russell_h | so I guess my preference would be, if we see your glance is using swift, we'll opportunistically generate temp urls | 16:39 |
russell_h | otherwise, we fall back to other options | 16:39 |
jroll | yeah | 16:40 |
jroll | but the question at hand is what other options? :P | 16:40 |
russell_h | anyway, I think we're in a reasonable position today | 16:40 |
russell_h | we can iterate in the future | 16:40 |
jroll | agreed | 16:40 |
russell_h | direct download from glance is probably the most reliable | 16:40 |
russell_h | er, and by "direct" I mean really indirect | 16:40 |
jroll | yeah, but then you have credentials everywhere | 16:40 |
jroll | which is the main reason we went to this tempurl thing | 16:41 |
jroll | anyway, we're fine for now | 16:41 |
NobodyCam | lucasagomes: in the testing I see # vmware does not support (set|get)_boot_device will this be true always? or just until its patched to support it? | 16:45 |
lucasagomes | NobodyCam, not always, but as it does not support it for now | 16:46 |
lucasagomes | I put that comment there | 16:46 |
lucasagomes | once vmware adds (set|get)_boot_device to that commands mapping | 16:46 |
lucasagomes | that test will start failing | 16:46 |
lucasagomes | which is good, so when it's being implemented it won't be missed | 16:47 |
*** matty_dubs|lunch is now known as matty_dubs | 16:48 | |
NobodyCam | ok we DO need to land the other dep patches | 16:48 |
lucasagomes | that would help a lot heh | 16:48 |
lucasagomes | because the linear dependency is getting long | 16:49 |
NobodyCam | ack | 16:49 |
*** blamar has joined #openstack-ironic | 16:50 | |
NobodyCam | lucasagomes: do you know (off the top of your head) if the DIB rhel elements work? | 16:52 |
lucasagomes | NobodyCam, hmm not anymore, long time ago I have worked with the guy who was implementing it so it worked | 16:53 |
lucasagomes | but I didn't tried it since then | 16:53 |
NobodyCam | ack :) | 16:53 |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic: Updated from global requirements https://review.openstack.org/89234 | 16:54 |
lucasagomes | NobodyCam, the IRC name of the author is funzo | 16:54 |
lucasagomes | NobodyCam, he's on the tripleo channel | 16:55 |
lucasagomes | he might know better than me | 16:55 |
NobodyCam | ack :) | 16:57 |
*** lucasagomes_ has joined #openstack-ironic | 16:59 | |
NobodyCam | just pinged him OoO | 16:59 |
lucasagomes_ | wow! great, installed vbox, had to stop all my kvm vms because vt was being used... started a machine with vbox and it gave me a kernel panic :D | 16:59 |
lucasagomes_ | on the host machine I mean | 16:59 |
lucasagomes_ | damn oracle | 17:00 |
NobodyCam | nice.... yep vbox and virsh don't play well togheter | 17:00 |
lucasagomes_ | yeah it was vbox alone | 17:00 |
* lucasagomes_ will try again | 17:00 | |
*** lucasagomes has quit IRC | 17:00 | |
dtantsur | lucasagomes_, interesting, in my experience vbox seems to be much more reliable | 17:02 |
*** lucasagomes has joined #openstack-ironic | 17:02 | |
lucasagomes | cool again, idk hw I'm adding vbox support now lol | 17:02 |
*** dwalleck has joined #openstack-ironic | 17:02 | |
*** derekh has quit IRC | 17:02 | |
*** lucasagomes_ has quit IRC | 17:05 | |
*** harlowja_away is now known as harlowja | 17:06 | |
*** dwalleck has quit IRC | 17:11 | |
*** dwalleck has joined #openstack-ironic | 17:13 | |
lucasagomes | ok I'm done for the day, have a good night everybody | 17:16 |
*** lucasagomes is now known as lucas-dinner | 17:16 | |
NobodyCam | have a good night lucas-dinner :) | 17:16 |
*** eghobo has quit IRC | 17:17 | |
*** eghobo has joined #openstack-ironic | 17:19 | |
*** eghobo has quit IRC | 17:20 | |
*** eghobo has joined #openstack-ironic | 17:20 | |
*** stephenpearson has quit IRC | 17:21 | |
openstackgerrit | Josh Gachnang proposed a change to openstack/ironic: Adding swift temp url support https://review.openstack.org/81391 | 17:27 |
*** vkozhukalov has joined #openstack-ironic | 17:27 | |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Drivers may expose a top-level passthru API https://review.openstack.org/81919 | 17:27 |
NobodyCam | brb | 17:29 |
*** zdiN0bot has joined #openstack-ironic | 17:47 | |
devananda | g'morning! | 17:48 |
NobodyCam | good morning devananda | 17:49 |
jroll | hey devananda | 17:49 |
*** lsmola has quit IRC | 17:51 | |
devananda | lucas-dinner: re: ironic ssh port, see https://review.openstack.org/#/c/87355/ | 17:52 |
devananda | lucas-dinner: erm, nvm... wrong thing | 17:54 |
devananda | dtantsur: that was meant for you ^ :) | 17:54 |
*** eguz has joined #openstack-ironic | 18:01 | |
*** dwalleck has quit IRC | 18:04 | |
*** eghobo has quit IRC | 18:05 | |
*** epim has joined #openstack-ironic | 18:05 | |
*** zdiN0bot has quit IRC | 18:11 | |
devananda | jroll: do ya'll have an etherpad up yet for the IPA session? | 18:12 |
devananda | jroll: if not, i'm going to create one and link it from the session page | 18:12 |
devananda | jroll: context here is that every session needs an etherpad for collaborative note-taking and recording of action items | 18:12 |
jroll | we don't, go for it | 18:13 |
devananda | jroll: any further changes you want to make to the proposal before i schedule it, now's your chance | 18:14 |
devananda | by EOD it will appear on sched.org | 18:14 |
jroll | I'm fine with it, I think | 18:14 |
jroll | I haven't had any revelations in the past three days :P | 18:15 |
devananda | :) | 18:15 |
jroll | y'all ever seen a scenario where pecan/wsme throws a 500 and all you get back is: {"debuginfo": null, "faultcode": "Server", "faultstring": ""} ? | 18:16 |
devananda | matty_dubs, jroll: i've thought a bit more about the scale talk, and i'd like to chat with you a bit | 18:16 |
devananda | jroll: nice. i dont recall seeing that | 18:16 |
jroll | this is happening in the agent but thought I would ask | 18:16 |
jroll | it's super helpful. | 18:17 |
devananda | indeed | 18:17 |
jroll | devananda: yeah, I can chat | 18:17 |
devananda | so, last summit, we had a similar session proposed | 18:17 |
devananda | it's a bit like this: without hard numbers, all we can do is theory craft and speculate | 18:17 |
devananda | with hard numbers, we know what to fix | 18:17 |
devananda | in the first case, there's nothing actionable at the end | 18:18 |
devananda | in the second case, we know what to do, so there's not much to discuss | 18:18 |
devananda | as a whole group | 18:18 |
jroll | sure. although in the second case, if it's an architecture thing, it could use some discussion, no? | 18:18 |
devananda | we'l have plenty of time in hallway track // around the project PODs | 18:18 |
JayF | Shouldn't there be some amount of goal setting though? Like we should be able to provision N servers with X conductors in less than 5 minutes, for instance | 18:18 |
devananda | for technical discussion of "how do we implement X" | 18:18 |
*** epim has quit IRC | 18:19 | |
jroll | devananda: yeah, that's fair. feel free to axe it if you want | 18:19 |
devananda | but we probably don't need to involve 80 - 100 ppl for that technical discussion | 18:19 |
jroll | JayF: we don't need to all be in a room for 40 minutes for that :P | 18:19 |
devananda | that's the difference -- our four slots will draw not just our main upstream developers | 18:20 |
devananda | but a lot of vendor folks, and folks from other projects | 18:20 |
jroll | yep | 18:20 |
devananda | JayF: setting/agreeing on project goals is a good use of that time, if they're somewhat contentious goals | 18:20 |
devananda | JayF: but that needs to be balanced with the tendency we, as a community, have to rehash the same things (like kexec) | 18:21 |
devananda | :) | 18:21 |
jroll | heh | 18:21 |
devananda | it's great how many folks want to make ironic fast, but hardware is complicated and likes to break | 18:22 |
devananda | we should all just go use VMs (lol...) | 18:22 |
jroll | :P | 18:23 |
*** zdiN0bot has joined #openstack-ironic | 18:23 | |
jroll | devananda: we were talking earlier about dhcp things - a couple questions for you | 18:23 |
* NobodyCam wonders if we use openstack based vms instead for virsh :-p | 18:23 | |
jroll | 1) are you ok with a config option for the agent driver to *not* use neutron's dhcp? | 18:24 |
jroll | 2) do you have any concerns with the performance / general crappiness of dnsmasq, and depending on that? | 18:24 |
devananda | jroll: re: multitenancy proposal, that's a key use case for you guys, right? | 18:25 |
jroll | 'tis | 18:25 |
devananda | jroll: like, you wouldn't be interested in ironic if it doesn't do that at some point | 18:25 |
jroll | devananda: more like, we're going to make ironic do that, even if nobody else helps us :) | 18:26 |
devananda | heh | 18:26 |
lucas-dinner | folks couple of patches in the python-ironicclient needed another +2 | 18:26 |
lucas-dinner | https://review.openstack.org/#/q/status:open+project:openstack/python-ironicclient,n,z | 18:26 |
devananda | jroll: so, given that i want that (eventually) too, and I know others do as well, I'm going to add a couple items to your proposal's description | 18:26 |
jroll | that's fine | 18:27 |
* lucas-dinner brb | 18:27 | |
devananda | jroll: 1) make the dhcp dependency pluggable for all drivers, then yes | 18:28 |
devananda | jroll: 2) for a static external dhcp dependency, ironic shouldn't care what it is | 18:28 |
*** blamar has quit IRC | 18:28 | |
devananda | jroll: 2a) if ironic needs to (re)configure some external dhcp, see (1) | 18:28 |
jroll | devananda: on 2, I agree that ironic shouldn't care what it is. but given that we know neutron is hardcoded to use dnsmasq, are you comfortable placing a dependency on that? | 18:29 |
jroll | it's pretty well known that dnsmasq is not designed for large environments | 18:29 |
devananda | jroll: i'm not sure how 2) results in a dependency on any specific dhcp provider | 18:30 |
jroll | neutron is hardcoded to use dnsmasq | 18:30 |
devananda | perhaps i misinterpreted your (2) | 18:30 |
jroll | or are you saying it doesn't necessarily depend on neutron? | 18:31 |
devananda | right | 18:31 |
jroll | ah | 18:31 |
devananda | i see two paths | 18:31 |
devananda | (1) use neutron to dynamically (re)configure dhcp (and other network bits) during provisioning/teardown/etc | 18:31 |
devananda | this will eventually also tie into things like switch configuration | 18:32 |
devananda | (2) flat network with external static DHCP and a common PXE image (eg, the agent) | 18:32 |
devananda | in (2), ironic won't care what the DHCP provider is | 18:32 |
jroll | right | 18:33 |
jroll | so you're saying that should be a single config option for all drivers? | 18:33 |
*** zdiN0bot has quit IRC | 18:33 | |
devananda | yes | 18:33 |
jroll | ok, cool | 18:33 |
*** max_lobur has joined #openstack-ironic | 18:33 | |
jroll | are you cool with landing the agent driver before this happens? | 18:33 |
jroll | (last question, promise) | 18:34 |
devananda | before the PXE driver has that option? yes | 18:35 |
NobodyCam | I have not read the entire scroll back, but seems to me the fix is it expand Neutron to use dhcp providers other then dnsmasq | 18:35 |
jroll | devananda: cool. thanks :) | 18:35 |
devananda | before the agent driver supports neutron? ... not so much | 18:35 |
jroll | oh. | 18:35 |
devananda | NobodyCam: iiuc, jroll wants to use flat networking with external static DHCP | 18:36 |
jroll | devananda: I'd really prefer to do that in a separate patch | 18:36 |
NobodyCam | ahh :) | 18:36 |
devananda | jroll: my hesitation is about landing a driver which can not be used in the same environment as the current reference driver | 18:37 |
jroll | yeah, I understand that | 18:37 |
devananda | jroll: IMHO, that's an architectural requirement, and for folks testing from trunk, it's going to be broken if we land the agent driver now | 18:38 |
jroll | even if the agent driver is not enabled by default? | 18:38 |
devananda | yep | 18:38 |
devananda | cause someone can enable it | 18:38 |
jroll | those folks will be able to continue using the pxe driver, no? | 18:38 |
jroll | mmm ok | 18:38 |
devananda | i have wavered on this point a bit, i know. the implications are becoming clearer as we discuss it and as I review the code more | 18:39 |
jroll | we talked before about the agent driver not needing to be 100% complete to land, so I've been working from the assumption | 18:39 |
jroll | yeah, I hear ya | 18:39 |
jroll | from that assumption* | 18:40 |
devananda | yea, i definitely agree, doesn't need to be 100% complete, but it should be functional | 18:40 |
devananda | as in, i should be able to test it | 18:40 |
jroll | right | 18:40 |
jroll | you can, just not at the same time as the pxe driver :P | 18:40 |
devananda | :) | 18:40 |
devananda | so, for instance | 18:41 |
devananda | to test the agent in devstack today | 18:41 |
devananda | i'd need to disable neutron and manually configure dnsmasq | 18:41 |
jroll | right, I've been there | 18:42 |
jroll | it's a pain, I agree | 18:42 |
devananda | it's taken a while to get all that tooling into devstack for Ironic | 18:42 |
devananda | *just for the pxe driver | 18:43 |
jroll | nod | 18:43 |
jroll | neutron might even be worth it just for those purposes | 18:43 |
jroll | and tempest etc | 18:43 |
devananda | right | 18:43 |
jroll | ok | 18:44 |
devananda | jroll: as an aside, have you seen the thrid-party testing guidelines I posted? | 18:44 |
jroll | maybe? | 18:44 |
jroll | I don't recall them at the moment | 18:44 |
devananda | they were an email several months back and a wiki page I just posted yesterday | 18:44 |
jroll | ok, I'll check that out | 18:44 |
devananda | jroll: https://wiki.openstack.org/wiki/Ironic/Testing | 18:45 |
jroll | ah, right | 18:45 |
jroll | cool, I'll go off of that as far as this driver goes | 18:46 |
devananda | jroll: I think it's impiortant that all supported drivers be tested on every commit to ironic (whether upstream or by third-party systems) by the time we graduate | 18:46 |
jroll | +1 | 18:46 |
devananda | jroll: so yes, we can land the driver before we land testing, but i hestitate to land code that is _untestable_ at this point | 18:47 |
jroll | I'm running off to lunch, anything else you want to chat about before I go? | 18:47 |
jroll | sure, that's fair | 18:47 |
devananda | jroll: fwiw, I am holding the ilo and seamicro drivers to that, too, though they're clearly under third-party CI umbrella | 18:47 |
devananda | jroll: nope. ttyl | 18:47 |
jroll | sounds good | 18:47 |
jroll | bbiab | 18:48 |
*** jdob_ has joined #openstack-ironic | 19:10 | |
dtantsur | devananda, hi! I've seen https://review.openstack.org/#/c/87355/, that's awesome :) | 19:16 |
dtantsur | devananda, also, if you're still around, could you have a look at https://blueprints.launchpad.net/ironic/+spec/pxe-master-images-caching ? It's a late attempt to make a blueprint for cache-related job I am and will be doing | 19:18 |
devananda | dtantsur: hi! the BP is a little hard to understand | 19:20 |
NobodyCam | dtantsur: I am concerned about Consider also Glance checksum when caching (e.g. by adding it to file name), so that when image is updated in Glance, it is redownloaded | 19:20 |
dtantsur | devananda, probably, I'm not really good at writing such things :) Something specific to clarify/enhance? | 19:21 |
NobodyCam | are you saying that if a image is updated in glance it will be redownloaded | 19:21 |
devananda | dtantsur: it may be a grammar / language issue, i'm not sure, but some things are hard to parse, eg, "so that have to redownload them every time for large deployment" | 19:21 |
*** dwalleck has joined #openstack-ironic | 19:21 | |
devananda | dtantsur: the BP should not reference existing code proposals | 19:22 |
dtantsur | devananda, oh, that should read as "so that we don't have to". Or is it also too much? | 19:22 |
devananda | dtantsur: so i dont understand that -- ironic caches the images already, doesn' tit? | 19:23 |
dtantsur | NobodyCam, redownloaded the next time it is going to be used, not for exiting instances | 19:23 |
devananda | dtantsur: the code review is to add a TTL and some cleanup jobs | 19:23 |
dtantsur | devananda, it does, but only while they are required for exiting instances. Code review is about caching them a bit more + adding TTL and size limit. | 19:24 |
NobodyCam | dtantsur: what if there are depolyments using the old Image. we don't want to change things on deployed instances | 19:24 |
devananda | dtantsur: right. the BP is implying that there is no caching at all today | 19:24 |
dtantsur | NobodyCam, sure, but for them file name and links won't change, only for new deployments | 19:25 |
dtantsur | devananda, well, that's why it reads "Enhance" :) and " Store images for some time ***after they're not in use by any instance***" | 19:25 |
devananda | dtantsur: what NobodyCam points out also concerns me. as does adding a requirement on the glance image *name* | 19:25 |
dtantsur | devananda, it's not requirement on image name in Glance, it's requirement on naming master image in cache (currently it is UUID, will be like UUID + checksum) | 19:26 |
devananda | dtantsur: oh, i see - you'd add the checksum to the local file name, not the glance image name | 19:26 |
dtantsur | ok, I do need to rephrase things :) | 19:27 |
devananda | thanks :) | 19:27 |
dtantsur | I'll fix wording for everything mentioned here, thank you. Any more concerns? | 19:28 |
*** epim has joined #openstack-ironic | 19:34 | |
*** ifarkas has quit IRC | 19:35 | |
*** Antl3r has joined #openstack-ironic | 19:38 | |
*** max_lobur has quit IRC | 19:41 | |
*** Antl3r has left #openstack-ironic | 19:52 | |
jroll | devananda: nice email, thank you for that :) | 19:54 |
jroll | although I see two meetings before the summit - are we skipping the "off week" meeting? | 19:55 |
devananda | jroll: oh. you're right. | 19:56 |
jroll | heh :) | 19:56 |
devananda | jroll: i leave on tuesday for a conference in berlin, that was my confusion | 19:56 |
jroll | ah, got it | 19:56 |
NobodyCam | lol I made exact same mistake :-p | 19:56 |
devananda | jroll: replied | 19:58 |
devananda | jroll: and now i need to find lunch and hit the road | 19:58 |
NobodyCam | hit the road? | 19:58 |
NobodyCam | up at the house? | 19:58 |
devananda | jroll: i edited http://summit.openstack.org/cfp/details/405 a bit | 19:58 |
*** dwalleck_ has joined #openstack-ironic | 19:59 | |
devananda | jroll: if you can prepare the etherpads for that and the agent session over the next two weeks, that'd be great | 19:59 |
devananda | jroll: the multitenancy one could derail really easily -- i'll probably moderate that even though you proposed it, to keep things on track of what we can actually do upstream | 20:00 |
devananda | without too much reliance on specific hardware vendors (who, yes, will want to steer the talk in their own ways, i expect) | 20:01 |
devananda | ok, really gotta run now before i get a parking ticket :p | 20:01 |
devananda | bbiah | 20:01 |
jroll | devananda: yeah, np. thanks | 20:02 |
*** dwalleck has quit IRC | 20:02 | |
*** zdiN0bot has joined #openstack-ironic | 20:07 | |
openstackgerrit | A change was merged to openstack/ironic: Clean up calls to get_node() https://review.openstack.org/84573 | 20:08 |
*** eguz has quit IRC | 20:19 | |
*** eghobo has joined #openstack-ironic | 20:20 | |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Drivers may expose a top-level passthru API https://review.openstack.org/81919 | 20:27 |
dtantsur | devananda, NobodyCam I believe I managed to make https://blueprints.launchpad.net/ironic/+spec/pxe-master-images-caching read better, could you look again? | 20:30 |
NobodyCam | brb | 20:31 |
comstud | can someone explain to me a few things about this patch: | 20:32 |
comstud | https://review.openstack.org/#/c/78651/7/ironic/conductor/manager.py,unified | 20:32 |
jbjohnso | question, so I'm chugging along on my console server, was wondering if there was a request with respect to authorization and authentication | 20:32 |
comstud | This merged... and | 20:32 |
*** dwalleck_ has quit IRC | 20:33 | |
jbjohnso | currently, I authenticate a user and then said user has equal access to all consoles that share the 'tenant' | 20:33 |
jbjohnso | user can be authenticated by passphrase or certificate | 20:34 |
comstud | 1) The commit message says nothing about the move of code into utils method (which fixes a different bug).. This is fine, but there was no mention of why | 20:34 |
comstud | 2) It removes 'maintenance' from the filters with no explanation, either. | 20:34 |
comstud | #2 is what I'm mostly concerned about | 20:34 |
jbjohnso | was wondering about either adding another user authentication or implementing a token granting facility | 20:34 |
comstud | devananda: you approved this, maybe you know why? | 20:34 |
*** jbjohnso has quit IRC | 20:41 | |
rloo | comstud: I believe devananda is away right now but he'll be back shortly | 20:43 |
rloo | comstud: wrt 1) I think the move was something to do with one of my comments. sec, let me look. | 20:43 |
*** harlowja is now known as harlowja_away | 20:44 | |
*** jdob_ has quit IRC | 20:44 | |
rloo | comstud: wrt 1), see the comment at line 624: https://review.openstack.org/#/c/78651/4/ironic/conductor/manager.py | 20:46 |
rloo | comstud: wrt 2). hmm, can a node be in maintenance AND in DEPLOYWAIT provision state? | 20:48 |
JayF | running devstack, as indicated here: http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html#deploying-ironic-with-devstack is supposed to get me a tftp and dhcp server as well, right? | 20:51 |
comstud | rloo: No idea.. but these types of things would be helpful in the commit message :) | 20:52 |
comstud | I'm resolving a conflict with one of my patches.. and I can't find any reason why 'maintenance' was dropped | 20:53 |
Shrews | JayF: yep | 20:53 |
JayF | Shrews: where would the tftp root be in that case? | 20:53 |
JayF | trying to unravel this configuration to see if ironic pxe and agent drivers could live side by side | 20:53 |
JayF | but afaict everything assumes one big network and one big pxe config | 20:54 |
* NobodyCam starts a devtest run and says brb | 20:54 | |
rloo | comstud: it isn't really clear to me how much detail should be put in the commit. But I think that if people expect to see more info there, we should try to make sure that it is there. | 20:54 |
comstud | I could see something going into maintenance while being stuck in DEPLOYWAIT | 20:54 |
Shrews | JayF: iirc, there is a map file | 20:55 |
comstud | rloo: I'm less concerned about #1.. but I don't see anything mentioned about #2 | 20:55 |
rloo | comstud: the states and their combinations, need to be clarified I think. | 20:55 |
comstud | anyway, I'm inclined to keep it in my patch (which means to re-add it) | 20:55 |
Shrews | JayF: /tftproot is mapped somewhere else, i believe | 20:55 |
JayF | yeah I've been looking for it to no avail | 20:55 |
JayF | getting the agent running with devstack / neutron dhcp = not terribly difficult. Getting teh agent driver and pxe driver running together with devstack / neutron dhcp = difficult | 20:56 |
JayF | at least from my looking so far | 20:56 |
rloo | comstud: so my assumption (and maybe my bad cuz I reviewed it) is that a node in maintenance won't be provisioning. And I think that's why it was removed. But it won't hurt to put it back in. | 20:56 |
jroll | JayF: ironic docs say /tftproot | 20:56 |
JayF | none of this was written in with the ability to have multiple different pxe targets | 20:56 |
jroll | JayF: also, tftp_root in ironic.conf | 20:56 |
JayF | jroll: yeah, it may be that JoshNang's devstack was busted, I'm waiting for mine to finish and will check there :x | 20:57 |
JayF | devstack has been installing for around an hour or so | 20:57 |
jroll | yeah | 20:57 |
jroll | wat | 20:57 |
jroll | was 1000s or so for me | 20:57 |
jroll | but that was on ethernet | 20:57 |
Shrews | JayF: the person to ask is adam_g. he set that stuff up | 20:57 |
jroll | so /shrug | 20:57 |
JayF | jroll: also I'm working from a minimal ubuntu image/install, so maybe further to go | 20:57 |
jroll | ah | 20:57 |
adam_g | JayF, is there a working branch somewhere with the changes you made for agent support? id be intersted in helping out but dont know where to start /w the agent | 21:01 |
JayF | we don't have a working branch | 21:04 |
JayF | in terms of devstack | 21:04 |
JayF | jroll should be able to let you know what patches to apply on the ironic side to make the driver work | 21:04 |
jroll | oh hey | 21:04 |
*** harlowja_away is now known as harlowja | 21:05 | |
JayF | and now a clean devstack install, from master, with the localrc from the docs is failing | 21:05 |
* JayF flips table | 21:05 | |
JayF | failed to define network from /dev/fd/63 \n Error: XML Error: unexpected virtualport type -1 | 21:06 |
jroll | adam_g: one sec | 21:06 |
jroll | adam_g: master + 81391 + 81919 + 84795 should do it | 21:08 |
Shrews | JayF: apparently /opt/stack/data/ironic/tftpboot is removed during unstack'ing, which is news to me, and perhaps why you had a hard time finding it | 21:09 |
* Shrews going through a fresh devstack setup right now too | 21:10 | |
adam_g | JayF, you need to be installing a newer libvirt from the cloud archive | 21:10 |
*** adam_g has left #openstack-ironic | 21:11 | |
*** adam_g has joined #openstack-ironic | 21:11 | |
adam_g | JayF, here is a localrc that is close to what gets run in the gate http://paste.ubuntu.com/7317641/ | 21:12 |
JayF | should the one here work? http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html#deploying-ironic-with-devstack | 21:13 |
JayF | I did see I missed a step to install the cloud archive apt repo | 21:13 |
adam_g | JayF, yes, it should | 21:13 |
Shrews | JayF: that's the one i'm using | 21:14 |
*** jdob has quit IRC | 21:17 | |
*** pradipta_away has quit IRC | 21:19 | |
Shrews | oh my, 'screen -x -p =' is my new favorite command when working with devstack | 21:22 |
JayF | nice trick | 21:23 |
Shrews | sometimes man pages are useful... sometimes | 21:23 |
JoshNang | ooo that is handy | 21:23 |
JayF | well it told me what that did, heh | 21:23 |
*** pradipta_away has joined #openstack-ironic | 21:24 | |
*** linggao has quit IRC | 21:25 | |
JayF | Shrews: how much ram do you guys give your devstack machines? | 21:27 |
JayF | and I'll add that to the doc | 21:27 |
* JayF just got out of memory erros | 21:27 | |
Shrews | JayF: i've only ever used it on vm or actual h/w with 8G minimum | 21:27 |
JayF | thanks, I can spare that much for VMs :) | 21:28 |
JoshNang | JayF: damn. should have opted for the 16gb laptop :( | 21:33 |
vkozhukalov | JayF: if you have a couple minutes, please take a look at https://blueprints.launchpad.net/ironic/+spec/ironic-python-agent-partition, I've updated API in etherpad draft https://etherpad.openstack.org/p/ironic-disk-partitioning. Removed granular API, added scheme based API. | 21:38 |
Shrews | JoshNang: i would not recommend running devstack on a personal laptop that you actually use | 21:39 |
Shrews | unless it's under a vm on the laptop | 21:39 |
JoshNang | Shrews: oh its definitely in a VM. working on a vagrant setup :) | 21:40 |
Shrews | oh neat | 21:40 |
JoshNang | yup! | 21:41 |
*** romcheg1 has quit IRC | 21:45 | |
openstackgerrit | Chris Behrens proposed a change to openstack/ironic: Eliminate races in Conductor _check_deploy_timeouts https://review.openstack.org/89223 | 21:54 |
openstackgerrit | Chris Behrens proposed a change to openstack/ironic: Spawn support for TaskManager and 2 locking fixes https://review.openstack.org/89328 | 21:54 |
comstud | devananda: ^ (for when you're back later. That spawn taskmanager review should be good to go) | 21:55 |
*** matty_dubs is now known as matty_dubs|gone | 21:58 | |
* devananda is back | 22:02 | |
openstackgerrit | Chris Behrens proposed a change to openstack/ironic: Eliminate races in Conductor _check_deploy_timeouts https://review.openstack.org/89223 | 22:03 |
openstackgerrit | Chris Behrens proposed a change to openstack/ironic: Spawn support for TaskManager and 2 locking fixes https://review.openstack.org/89328 | 22:03 |
comstud | minor fix | 22:03 |
comstud | now that you're here, I'm taking off for a while :) | 22:03 |
devananda | comstud: 2 looks like an oversight which, somehow, at least five reviewers missed | 22:07 |
comstud | devananda: ok, i've re-added it in one of my reviews above. | 22:07 |
comstud | https://review.openstack.org/#/c/89223/ | 22:08 |
comstud | I hit it when I had to rebase | 22:08 |
comstud | bbl | 22:10 |
devananda | comstud: thanks | 22:10 |
*** harlowja has quit IRC | 22:14 | |
JayF | how and where does /opt/stack/data/ironic/tftpboot/pxelinux.cfg get populated with configs? On demand as machines are provisioned? | 22:16 |
JayF | I have that dir now but the lack of configurations is confusing | 22:16 |
devananda | JayF: iirc (dont have my devstack in front of me at the moment) that dir is created when devstack starts up | 22:17 |
JayF | yeah I have the dir, and there are a few things populated in tftpboot/ that I'd expect (like pxelinux.0), but there are no configs in pxelinux.cfg/ | 22:17 |
devananda | JayF: and symlinks with MAC addresses are created that refer to the individual configs and images | 22:17 |
JayF | aha | 22:17 |
devananda | when an instance is created | 22:17 |
JayF | oh that's actually kinda awesome | 22:17 |
devananda | that way, boot requests from unknown MACs go unanswered | 22:17 |
devananda | and multiple machines which boot from the same image don't waste disk space | 22:18 |
JayF | so in order to make that support the agent, I just have to make sure when it makes that link for an agent-powered mac, that it uses a different config source | 22:18 |
devananda | yep | 22:18 |
JayF | do you happen to know where that happens? assuming in the pxe driver atm? | 22:18 |
devananda | there should be some common methods for managing the symlinks | 22:18 |
devananda | lemme look | 22:18 |
JayF | yeah that's what I'm looking fro | 22:18 |
JayF | *for | 22:18 |
JayF | fwiw neutron isn't even using dnsmasq directly, it's using libvirt which uses dnsmasq | 22:19 |
JayF | I know we were talking about pluggability earlier, but it's even one more step abstracted | 22:19 |
devananda | JayF: i'm going to just paste some paths to things related to this, see what interests you | 22:19 |
devananda | ironic/common/images.py | 22:19 |
devananda | JayF: ironic/drivers/modules/pxe.py actually contains 90% of this code | 22:20 |
devananda | i thought it was slightly better split up, but it's not | 22:21 |
devananda | just those two files | 22:21 |
JayF | jroll: devananda: ^ so doing those changes, should that be a different merge req? included in the agent driver? | 22:21 |
devananda | JayF: also, dtansur is working on refactoring the image caching code (which is what creates said symlinks) | 22:21 |
devananda | JayF: see https://blueprints.launchpad.net/ironic/+spec/pxe-master-images-caching | 22:21 |
jroll | JayF: if you refactor something that's not only in the agent, it should be a seperate patch | 22:22 |
JayF | yeah so we're going to have to refactor all that out of the pxe driver | 22:23 |
JayF | so they can share and work together | 22:23 |
JayF | if the agent and pxe driver are to work on the same machine | 22:23 |
JayF | bceause the existing assumption seems to be that the pxe driver, when active, owns all pxe/dhcp for a subnet, which clearly can't be true if we need to pxe agent images | 22:23 |
devananda | JayF: i think you mean, "the agent driver, when active, owns..." | 22:24 |
devananda | JayF: the PXE driver requires neutron to own DHCP ;) | 22:24 |
JayF | but pxe driver owns configuration for the pxe, aka the stuff under pxelinux.cfg/ | 22:24 |
JayF | which is really all that the agent cares about. We don't care about exactly what dhcp does, as long as it gets the agent on the box | 22:25 |
devananda | local tftp config - yes | 22:25 |
JayF | and as an MVP, seems like the easiest way to get there is to factor out the tftp config handling bits into something that both the agent and pxe drivers can use simlutaneously | 22:25 |
JayF | so that both drivers can be active and working in a devstack | 22:25 |
devananda | JayF: sure | 22:26 |
devananda | one thing to note | 22:26 |
devananda | CONF.pxe.tftp_server defaults to the conductor host's IP | 22:26 |
devananda | and pxe driver makes sure all the right things are set up locally | 22:26 |
JayF | All that stuff would have to move into something both agent and pxe driver could use, no? | 22:27 |
JayF | frankly, I wouldn't run the agent driver like this in a production environment, but if it's a requirement that both work under devstack simultaneously, this seems to be the most correct path to take | 22:27 |
devananda | and the current assumption is that the deploy ramdisk & kernel IDs are set on the nova flavor | 22:28 |
devananda | so that heterogeneous hardware (needing different deploy kernels) can be supported | 22:29 |
devananda | whereas, if the deploy kernel*ramdisk were a CONF option, that wouldn't be possible | 22:29 |
JayF | So the deploy ramdisk, and kernel options used, are actually baked into the nova flavor? | 22:29 |
devananda | yep | 22:29 |
devananda | well not the kernel OPTIONS | 22:30 |
devananda | the kernel image ID | 22:30 |
JayF | ah | 22:30 |
*** zdiN0bot has quit IRC | 22:30 | |
jroll | um | 22:30 |
jroll | doesn't this tie a driver to a flavor then? | 22:30 |
JayF | so the kernel command line is something we'll need to be able to modify as well | 22:30 |
jroll | JayF: that bit is done in ironic afaik | 22:30 |
JayF | That doesn't make sense though, as kernel command line opts can vary wildly as the deploy ramdisk/kernel versions vary | 22:31 |
devananda | JayF: kernel params passed in via dhcp can be set programatically by ironic, yes | 22:31 |
*** mrda_away is now known as mrda | 22:31 | |
devananda | jroll: well, now that you mention it, yes | 22:31 |
jroll | JayF: ironic knows which ramdisk is happening | 22:31 |
JayF | right now I'm not even sure libvirt supports passing in those options to dnsmasq via it's intermediate xml format | 22:31 |
JayF | so much misdirection | 22:31 |
jroll | devananda: yeah, I don't like that | 22:32 |
devananda | jroll: a flavor whose baremetal:deploy_ramdisk_id refers to the agent would not be usable on a node configured for the pxe driver | 22:32 |
devananda | hmmm | 22:32 |
devananda | i don't like it either | 22:33 |
jroll | devananda: I guess I'm of the opinion that deploy_ramdisk shouldn't be in the flavor | 22:33 |
JayF | so it's impossible for someone to upgrade from pxe->agent then, in some nebulous future where agent actually works, without a hard cutover? | 22:33 |
jroll | devananda: but then again for the different hardware you mentioned, idk what alternatives there are | 22:33 |
devananda | JayF: my goal is for that to not only be possible, but be well tested | 22:33 |
JayF | Then it seems like as an architectural point, this will be something that'll have to have it's behavior change? | 22:34 |
devananda | jroll: the nova scheduler would, in theory, need to match flavor<->driver | 22:34 |
jroll | hmm | 22:34 |
devananda | but that means, changing a node from pxe -> agent means having a separate flavor for it | 22:35 |
devananda | which i don't like | 22:35 |
jroll | right | 22:35 |
devananda | just curious, how much work do you think it would be to make the agent compatible with the current pxe driver? | 22:37 |
devananda | if a particular kernel param is passed in, create iSCSI endpoint, POST that instead, and listen for notice of complete | 22:38 |
jroll | mmm | 22:38 |
jroll | devananda: I know where you're going with this | 22:38 |
jroll | and I think it's a great idea, in general | 22:38 |
jroll | but I also think it is far too early | 22:39 |
devananda | upgrade path | 22:39 |
devananda | sure, it's early. not saying that has to happen now :) | 22:39 |
jroll | right | 22:39 |
pquerna | upgrade from what | 22:39 |
devananda | but is that possible? is that something we'll need? | 22:39 |
devananda | pquerna: pxe driver -> agent driver | 22:39 |
devananda | jroll: i think it's "yes" to both | 22:39 |
jroll | pquerna: today a nova flavor defines which ramdisk a node boots, for pxe driver | 22:40 |
jroll | pquerna: if we want feature parity in terms of dhcp things, we'll have to do the same for agent driver | 22:40 |
*** zdiN0bot has joined #openstack-ironic | 22:40 | |
jroll | pquerna: which means changing flavors to upgrade from pxe -> agent | 22:40 |
jroll | devananda: perhaps. definitely yes to #1. not sure about #2. | 22:41 |
jroll | yes comes with the question of 'is it worth it?' | 22:41 |
devananda | jroll: when there are production environments using the pxe driver, i think they'll want to upgrade | 22:42 |
jroll | sure | 22:42 |
devananda | jroll: perhaps simply creating a new flavor is sufficient. I don't have enough insight into deployer's future needs to say at this point | 22:43 |
jroll | yeah | 22:44 |
*** zdiN0bot has quit IRC | 22:44 | |
jroll | ideally one shouldn't need to do that | 22:44 |
*** zdiN0bot has joined #openstack-ironic | 22:44 | |
jroll | but it's going to be some work and especially testing to migrate as is | 22:44 |
jroll | creating a flavor is a really small thing in those terms | 22:44 |
devananda | jroll: telling all your customers to stop using flavor X and start using flavor X' -- just to get the same results | 22:45 |
devananda | jroll: that's my concern | 22:45 |
jroll | devananda: idk that you would need to | 22:45 |
JayF | looking at https://blueprints.launchpad.net/ironic/+spec/pxe-master-images-caching -- does this mean deploy ramdisks are stored in glance for purposes of the pxe driver? | 22:45 |
jroll | because the flavor in this case only matters at provision time, right? | 22:46 |
devananda | JayF: yes | 22:46 |
jroll | so you do something like 'update instances set flavor_id=$newflavor where flavor_id=$oldflavor' and you're done | 22:46 |
devananda | jroll: correct. you could update the flavor and update all the node's .driver properties -- as long as nothing was provisioned while that update happened | 22:46 |
jroll | afaict | 22:46 |
devananda | it'd be ok | 22:46 |
jroll | s/provisioned/provisioning ? | 22:46 |
devananda | jroll: that has to be sync'd with the change to node.driver | 22:47 |
jroll | sure | 22:47 |
devananda | unless the agent is backwards compatible :) | 22:47 |
jroll | still not a big deal | 22:47 |
devananda | which is why I asked | 22:47 |
jroll | right | 22:47 |
devananda | but yea, not a huge deal | 22:47 |
devananda | brief interruption in provisioning (but not of service to existing instances) | 22:47 |
devananda | reasonable for an upgrade | 22:47 |
devananda | i agree | 22:47 |
jroll | yeah | 22:47 |
JayF | Does the fact Ironic is incubating and not integrated matter for terms of this discussion? Seems like we should have a lower responsibility for backwards compatibility in something that's not integrated yet | 22:47 |
jroll | brief being the execution time of those two UPDATE queries | 22:48 |
devananda | JayF: you're correct from the TC's perspective | 22:48 |
devananda | OTOH, it shows a lot more maturity if we don't abuse that | 22:48 |
JayF | The real question has to be asked of how many people are going to use Ironic now with the pxe driver? | 22:48 |
devananda | *and* there are downstream consumers who care a lot about it | 22:48 |
devananda | folks are going to start deploying things with Ironic now that Icehouse is out | 22:48 |
JayF | It's just a little worrying that we're chatting about upgrade paths to a driver that isn't even merged yet | 22:48 |
devananda | they'll be impacted if there is no upgrade path to Juno | 22:48 |
devananda | JayF: how is that worrying? | 22:49 |
jroll | JayF: we're hypothesizing for the future, not defining work for today | 22:49 |
devananda | JayF: if the plan wasn't to upgrade from pxe to the agent driver, why would we even be working on it? | 22:49 |
JayF | Well I just would rather things work is all, and it's a little frustrating that it doesn't yet. | 22:49 |
JayF | Right now the hump I've gotta get over is getting these things running side by side in devstack for the time, and it's just a little more complex and misdirected than I realized | 22:50 |
devananda | JayF: fwiw, it took more than six months from when I forked ironic to when it "worked" | 22:51 |
JayF | you have bucketloads more patience than I do with such things then :) | 22:52 |
devananda | i would have suggested you guys take an incremental approach when ya'll started, if you'd been around prior to writing all this code | 22:52 |
devananda | merging an existing team, with your own ideas around provisioning and your culture, into this one ... it's going to have a few bumps | 22:53 |
devananda | hopefully you guys can see how ironic (both the code and the culture) is changing as a result of your input | 22:53 |
devananda | anyhow... now back to the technical stuff | 22:54 |
devananda | jroll: how do you see the agent co-operating with two different deployment styles | 22:54 |
devananda | a) use neutron for dhcp and serve tftp from each conductor host, and b) static external dhcp and tftp | 22:55 |
jroll | devananda: that shouldn't be a problem, other than time | 22:56 |
devananda | jroll: code wise, how do you want to do that? | 22:56 |
jroll | and by time is a problem, I mean it delays the goal of making it work | 22:56 |
jroll | ok, so | 22:57 |
jroll | disclaimer: I haven't looked at the pxe/neutron stuff much | 22:57 |
devananda | right. but if there's a clear path to (a) and I can see the implementation of (b) is not goign to hinder that, i'm more likely to go ahead without it initially | 22:57 |
devananda | my concern was in reviewing the code and seeing that (a) isn't even close to possible | 22:57 |
jroll | but I would think factor that stuff out into somewhere common, make config options whether to use that or rely on external, and go | 22:57 |
jroll | why do you say it's not close to possible? | 22:58 |
jroll | what's blocking us from doing (a) | 22:58 |
devananda | sorry | 22:58 |
devananda | s/possible/planned or in your awareness/ | 22:58 |
jroll | ok, much better :P | 22:58 |
jroll | it was definitely not something we had our eyes on | 22:59 |
devananda | yea, sometimes i type faster than i think :( | 22:59 |
devananda | (heh) | 22:59 |
jroll | my main motivation for doing such a thing would be for testing/devstack, because I would never recommend that configuration in production | 22:59 |
jroll | and I completely see why it's important in that regard | 22:59 |
devananda | that's an interesting statement to me | 22:59 |
JayF | dnsmasq says directly that it's only suitable for small networks | 23:00 |
JayF | I would not use it in a production sized ironic deployment | 23:00 |
devananda | because it suggests that you think that is a fundamental flaw in the current pxe driver | 23:00 |
JayF | I would say that | 23:00 |
devananda | brb | 23:01 |
JayF | I've had to replace dnsmasq in production before because it was inadequate, and more specifically, the way it's implemented now, the dnsmasq process that is spun up assumes all nodes are getting IPs in the same network | 23:02 |
jroll | I would say that *may* be a fundamental flaw in the pxe driver | 23:02 |
JayF | I'd almost say it seems like we shouldn't support nodes using different drivers inside the same dhcp domain | 23:02 |
JayF | but even that doesn't appear to be supported by the dnsmasq spun up by neutron via libvirt | 23:04 |
JayF | since it's started with the bind-interfaces flag on | 23:04 |
devananda | JayF: that's an interesting idea | 23:08 |
devananda | JayF: but I dont see how ironic can enforce that, since it doesn't control the IPs being handed out | 23:08 |
JayF | Ironic, /does/ control, via calls to neutron, what network the nodes are in though, correct? | 23:10 |
devananda | JayF: nope. Ironic doesn't determine what IP is put on the node | 23:10 |
JayF | I'm not talking about IP granularity, I'm talking about network/subnet granularity | 23:11 |
JayF | DHCP domains only for purposes of this conversation | 23:11 |
devananda | nope | 23:11 |
devananda | ironic is only passing one specific DHCP option to neutron | 23:11 |
jroll | but it *could* determine these things, no? | 23:12 |
devananda | er, 3 | 23:12 |
devananda | bootfile-name tftp-server server-ip-address | 23:12 |
jroll | what is server-ip-address? | 23:12 |
JayF | server-ip-address? | 23:12 |
devananda | to control the response that neutron('s dhcp provider) returns to a DHCP BOOT request from that port | 23:12 |
JayF | you mean server-mac-address, perhaps? | 23:13 |
devananda | CONF.pxe.tftp_server | 23:13 |
devananda | the IP address of the TFTP server, ie, ironic-conductor | 23:13 |
jroll | and then what is tftp-server? | 23:13 |
JayF | tftp-server is ^ that, correct? | 23:14 |
devananda | same thing | 23:14 |
devananda | dont ask me why neutron has two options that require the same value | 23:14 |
jroll | um | 23:14 |
devananda | yea | 23:14 |
jroll | ok | 23:14 |
jroll | huh. | 23:14 |
jroll | yay neutron. | 23:14 |
devananda | so. "could ironic determine the subnet that a given node is placed in" -- i believe the answer today is no | 23:15 |
devananda | but let me get ar eference | 23:15 |
JayF | I think that's possibly not true, or if it's true, it's because neutron isn't exposing all of libvirt's API for this | 23:15 |
devananda | http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/ironic#n335 | 23:16 |
devananda | at least right now | 23:16 |
devananda | when creating nodes for use with ironic, you have to manuyally create the neutron PORT too | 23:16 |
JayF | afaict all the config is done via etc/libvirt/qemu/networks/default.xml, and I can't see where that's setting next-server or tftp-server | 23:16 |
devananda | JayF: what i mean is, neutron determines that today | 23:17 |
devananda | not ironic | 23:17 |
devananda | JayF: and to be more precise, it's Nova that creats a neutron port on demand, within the tenant's network range, using the MAC address from the ironic node | 23:18 |
JayF | and in this case, 'tenant' network is what is used for the provisioning as well? | 23:18 |
JayF | I guess in my mind, re: deployment, you wouldn't put a node in a 'tenant' network until after it was fully prepared | 23:19 |
devananda | JayF: I agree, that's how it should work. i don't believe that's the case today (but IMBW) | 23:19 |
devananda | https://github.com/openstack/ironic/blob/master/ironic/nova/virt/ironic/driver.py#L365 | 23:20 |
*** vkozhukalov has quit IRC | 23:20 | |
devananda | https://github.com/openstack/ironic/blob/master/ironic/nova/virt/ironic/driver.py#L553 | 23:20 |
devananda | so nova has already created neutron ports prior to calling driver.spawn | 23:21 |
devananda | the nova.virt.ironic driver is passing those vif_id's down to ironic, so ironic can update them when it needs to change the DHCP options | 23:21 |
JayF | I guess I need to dig further into neutron | 23:21 |
JayF | becuase I can't find any evidence on disk, re: dnsmasq configs, that the options are making it through | 23:22 |
devananda | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4374 | 23:24 |
devananda | lastly, https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L191 | 23:25 |
devananda | note the "macs" param -- that bubbles up from ironic's port.address field | 23:26 |
adam_g | devananda, is pxe booting from neutron managed dhcp the method thats used for pxe_ipmi /w real hardware? | 23:32 |
*** max_lobur has joined #openstack-ironic | 23:33 | |
devananda | adam_g: yes. and afaik, that's what tripleo is using | 23:33 |
adam_g | hmm. curious how that works | 23:34 |
adam_g | netbooting from a dhcp server running in a namespaced tenant network | 23:34 |
JayF | adam_g: I'm still heading down the rabbithole, looks like neutron has dhcp-agents, but they aren't well documented. Trying to figure out how that works, given it's spawning dnsmasq instances with bind-interfaces on | 23:35 |
JayF | I think it's possible at all that the devstack isn't using dhcp-agents, but instead has a dnsmasq spawned by something else that's loading the stuff up | 23:36 |
adam_g | JayF, it should be writing out a config file and HUP'ing dnsmasq everytime a new networking gets configured | 23:36 |
devananda | JayF: quick google search did not yield me results, but i would be surprised if dnsmasq is the /only/ supported dhcp provider for neutron | 23:36 |
devananda | then again, neutron often surprises me | 23:36 |
JayF | adam_g: I don't see /any/ dnsmasq config other than dnsmasq.d/libvirt-bin | 23:36 |
JayF | devananda: just what I'm reading in the docs vs what's on my devstack instance don't seem to agree, and I'm trying to figure out what is doingw hat | 23:37 |
adam_g | JayF, have you booted a server? | 23:37 |
JayF | 1b700153-53d4-4df8-9e21-cdd9181ebcd4 | testing | BUILD | spawning | NOSTATE | 23:37 |
JayF | and it's been in that state for a long time | 23:37 |
JayF | following the instructions on the ironic developer page | 23:37 |
JoshNang | same here | 23:37 |
adam_g | JayF, is the corresponding ironic node powered on and wait-callback? | 23:37 |
JayF | adam_g: I seem to be getting 403s from ironic using . devstack/openrc as my creds | 23:38 |
devananda | JayF: export OS_USERNAME=admin | 23:38 |
adam_g | JayF, you need to be admin, do '. ~/devstack/openrc admin admin' instead | 23:38 |
devananda | or that | 23:38 |
JayF | adam_g: 532aafee-a04c-4f3e-83a4-5c3c9c4633b3 | 1b700153-53d4-4df8-9e21-cdd9181ebcd4 | power on | wait call-back | False | 23:39 |
adam_g | JayF, let me re-stack and see if something hasn't broken in devstack with the neutron agents. | 23:39 |
adam_g | tempest.scenario.test_baremetal_basic_ops.BaremetalBasicOptsPXESSH is failing again in our gate (it was passing yesterday) | 23:40 |
* adam_g really really really cant wait till we can actually rely on that devstack check | 23:40 | |
devananda | ugh | 23:40 |
adam_g | interestingly, the bug that is blocking it from all passing is related to devstack neutron agent configuration being broken | 23:41 |
adam_g | so its possible it may be broken wrt dhcp as well | 23:41 |
adam_g | https://review.openstack.org/#/c/89448/ | 23:41 |
JayF | and fwiw, only dhcp driver in mainline if I'm reading the code correctly appears to be dnsmasq, at least for linux | 23:42 |
* JayF digs more | 23:42 | |
adam_g | JayF, give me 5 and i can be of more help (devstack running) | 23:43 |
JayF | okay I'll take 5. | 23:44 |
*** zdiN0bot has quit IRC | 23:47 | |
adam_g | devananda, are there any other places in ironic where we'd benefit from implementing an event callback mechanism similar to novas? re https://review.openstack.org/#/c/84361/ | 23:47 |
devananda | adam_g: with ironic as the receiver or the initiator? | 23:47 |
devananda | adam_g: that patch suggests ironic would be the initiator. yes, there are others | 23:47 |
devananda | adam_g: when a node's status is changed, sending an event notice to nova right away, so that the compute stats can be updated for the scheduler | 23:47 |
adam_g | devananda, with ironic as the receiver | 23:48 |
adam_g | devananda, in the neutron case, we'd get a callback confirming all ports have been plugged, dnsmasq is HUPd and ready for netboot | 23:48 |
devananda | adam_g: ooh. that too. | 23:51 |
adam_g | the only other place i can think of is the ramdisk calling back, which is handled thru vendor_passthru atm | 23:52 |
adam_g | JayF, ugh. might be more than 5, forgot to point DIB it at my local caches | 23:53 |
devananda | anteaya: hi! do you mind if I ask you a neutron question (I dont want to bring up too many bad memories...) | 23:55 |
openstackgerrit | A change was merged to openstack/python-ironicclient: node-get-console incorporate the changes in API https://review.openstack.org/87769 | 23:56 |
*** zdiN0bot has joined #openstack-ironic | 23:57 | |
devananda | adam_g: is the event callback REST or RPC based? | 23:57 |
adam_g | devananda, REST. for the nova case, supported was added to novaclient and is used by neutron | 23:58 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic-python-agent: Accept new parameters for `prepare_image` https://review.openstack.org/86723 | 23:58 |
JayF | adam_g: heh, I thought 5m seemed optimistic given how long it took me :) | 23:59 |
devananda | adam_g: that could be useful | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!