*** xuhaiwei_ has joined #openstack-ironic | 00:11 | |
*** lnxnut has quit IRC | 00:12 | |
*** sseago has quit IRC | 00:24 | |
*** sseago has joined #openstack-ironic | 00:26 | |
*** matsuhashi has joined #openstack-ironic | 00:30 | |
*** sseago has quit IRC | 00:38 | |
*** sseago has joined #openstack-ironic | 00:38 | |
*** matsuhashi has quit IRC | 00:52 | |
*** matsuhashi has joined #openstack-ironic | 00:58 | |
*** nosnos has joined #openstack-ironic | 01:00 | |
*** zdin0bot has joined #openstack-ironic | 01:41 | |
*** zdin0bot has quit IRC | 01:43 | |
*** zdin0bot has joined #openstack-ironic | 01:44 | |
*** zdin0bot has quit IRC | 02:20 | |
*** zdin0bot has joined #openstack-ironic | 02:24 | |
*** zdin0bot has quit IRC | 02:49 | |
*** eghobo has joined #openstack-ironic | 02:51 | |
*** zdin0bot has joined #openstack-ironic | 03:01 | |
*** coolsvap|afk is now known as coolsvap | 03:09 | |
*** eghobo has quit IRC | 03:15 | |
*** matsuhashi has quit IRC | 03:32 | |
*** matsuhashi has joined #openstack-ironic | 03:32 | |
*** matsuhashi has quit IRC | 03:37 | |
*** zdin0bot has quit IRC | 03:43 | |
*** nosnos has quit IRC | 03:46 | |
*** zdin0bot has joined #openstack-ironic | 03:49 | |
*** eghobo has joined #openstack-ironic | 04:03 | |
*** romcheg has joined #openstack-ironic | 04:11 | |
*** romcheg has left #openstack-ironic | 04:11 | |
*** zdin0bot has quit IRC | 04:18 | |
*** blamar has quit IRC | 04:18 | |
*** xuhaiwei_ has quit IRC | 04:20 | |
*** nosnos has joined #openstack-ironic | 04:28 | |
*** matsuhashi has joined #openstack-ironic | 04:29 | |
*** romcheg has joined #openstack-ironic | 04:38 | |
*** romcheg has left #openstack-ironic | 04:38 | |
*** vkozhukalov has joined #openstack-ironic | 04:41 | |
*** vkozhukalov has quit IRC | 04:42 | |
openstackgerrit | Yuiko Takada proposed a change to openstack/python-ironicclient: Add set_provision_state command https://review.openstack.org/89301 | 04:43 |
---|---|---|
*** vkozhukalov has joined #openstack-ironic | 05:27 | |
*** Mikhail_D_ltp has joined #openstack-ironic | 05:46 | |
*** nosnos_ has joined #openstack-ironic | 05:51 | |
*** nosnos has quit IRC | 05:54 | |
*** matsuhashi has quit IRC | 05:59 | |
*** matsuhashi has joined #openstack-ironic | 06:00 | |
*** vkozhukalov has quit IRC | 06:02 | |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic: Imported Translations from Transifex https://review.openstack.org/88508 | 06:08 |
*** Mikhail_D_ltp has left #openstack-ironic | 06:22 | |
*** nosnos has joined #openstack-ironic | 06:32 | |
*** matsuhashi has quit IRC | 06:32 | |
*** nosnos_ has quit IRC | 06:32 | |
*** matsuhashi has joined #openstack-ironic | 06:34 | |
*** kevinbenton has quit IRC | 07:05 | |
*** eghobo has quit IRC | 07:05 | |
openstackgerrit | Chris Behrens proposed a change to openstack/ironic-python-agent: Fix wait argument on POST https://review.openstack.org/89311 | 07:06 |
*** kevinbenton has joined #openstack-ironic | 07:12 | |
*** max_lobur has joined #openstack-ironic | 07:17 | |
*** vkozhukalov has joined #openstack-ironic | 07:44 | |
*** max_lobur has quit IRC | 07:45 | |
*** kevinbenton has quit IRC | 08:17 | |
*** kevinbenton has joined #openstack-ironic | 08:23 | |
*** matsuhashi has quit IRC | 09:48 | |
*** matsuhashi has joined #openstack-ironic | 09:54 | |
*** coolsvap is now known as coolsvap|afk | 10:03 | |
*** rameshg87 has joined #openstack-ironic | 10:04 | |
openstackgerrit | Chris Behrens proposed a change to openstack/ironic: Create helper method for worker with lock https://review.openstack.org/89328 | 10:31 |
*** rameshg87 has left #openstack-ironic | 11:05 | |
*** matsuhashi has quit IRC | 11:22 | |
*** tatyana has joined #openstack-ironic | 11:23 | |
*** matsuhashi has joined #openstack-ironic | 11:30 | |
*** tatyana has quit IRC | 11:31 | |
*** vkozhukalov has quit IRC | 11:33 | |
*** vkozhukalov has joined #openstack-ironic | 11:33 | |
*** max_lobur has joined #openstack-ironic | 11:41 | |
*** hewbrocc` has joined #openstack-ironic | 11:41 | |
*** matsuhashi has quit IRC | 11:48 | |
*** matsuhashi has joined #openstack-ironic | 11:49 | |
*** max_lobur has quit IRC | 12:10 | |
*** linggao has joined #openstack-ironic | 12:17 | |
NobodyCam | good morning Ironic | 12:41 |
*** matsuhashi has quit IRC | 12:42 | |
*** matsuhashi has joined #openstack-ironic | 12:44 | |
*** matsuhashi has quit IRC | 12:51 | |
*** max_lobur has joined #openstack-ironic | 12:52 | |
agordeev | NobodyCam: good morning! | 12:55 |
NobodyCam | morning agordeev :) | 12:55 |
agordeev | also good morning everyone else | 12:55 |
*** matsuhashi has joined #openstack-ironic | 13:06 | |
*** matsuhashi has quit IRC | 13:12 | |
*** max_lobur has quit IRC | 13:12 | |
*** matsuhashi has joined #openstack-ironic | 13:21 | |
NobodyCam | brb | 13:22 |
*** jbjohnso has joined #openstack-ironic | 13:31 | |
*** matty_dubs|gone is now known as matty_dubs | 13:35 | |
*** blamar has joined #openstack-ironic | 13:35 | |
*** jgrimm has quit IRC | 13:39 | |
*** nosnos has quit IRC | 13:53 | |
*** rwsu has joined #openstack-ironic | 14:11 | |
*** matsuhashi has quit IRC | 14:17 | |
NobodyCam | gah that was no fun.. expence report with a refund. :-p | 14:32 |
NobodyCam | brb | 14:33 |
*** jgrimm has joined #openstack-ironic | 14:35 | |
*** dwalleck has joined #openstack-ironic | 14:41 | |
*** dshulyak has quit IRC | 14:41 | |
*** hemna has quit IRC | 14:42 | |
*** max_lobur has joined #openstack-ironic | 14:43 | |
*** dwalleck has quit IRC | 14:46 | |
*** dwalleck has joined #openstack-ironic | 14:56 | |
NobodyCam | great session suggestions everyone! | 15:04 |
*** linggao_ has joined #openstack-ironic | 15:14 | |
*** linggao__ has joined #openstack-ironic | 15:14 | |
*** max_lobur has quit IRC | 15:17 | |
*** jbjohnso has quit IRC | 15:18 | |
*** linggao has quit IRC | 15:18 | |
*** linggao_ has quit IRC | 15:19 | |
*** mrda_away has quit IRC | 15:27 | |
*** mrda_away has joined #openstack-ironic | 15:28 | |
*** dwalleck_ has joined #openstack-ironic | 15:29 | |
NobodyCam | has anyone looked into what happens if we are worknig with ipv6 addresses? or even a mixture of v4 nd v6 addys? | 15:30 |
*** jbjohnso has joined #openstack-ironic | 15:31 | |
*** dwalleck has quit IRC | 15:32 | |
*** reaper has joined #openstack-ironic | 15:35 | |
*** vkozhukalov has quit IRC | 15:36 | |
*** mrda_away has quit IRC | 15:37 | |
*** jgrimm_ has joined #openstack-ironic | 15:38 | |
*** jgrimm has quit IRC | 15:39 | |
*** reaper has quit IRC | 15:42 | |
*** dwalleck has joined #openstack-ironic | 15:43 | |
*** dwalleck_ has quit IRC | 15:46 | |
*** matty_dubs is now known as matty_dubs|lunch | 15:52 | |
devananda | morning, all | 16:03 |
NobodyCam | good morning devananda :) | 16:03 |
Shrews | devananda: morning | 16:04 |
*** dwalleck has quit IRC | 16:04 | |
Shrews | so, is this mysterious, empty vda4 partition normal? http://paste.openstack.org/show/76545/ | 16:05 |
NobodyCam | Shrews: are you using the entire disk? | 16:06 |
Shrews | NobodyCam: i didn't do the partitioning. all i did was specify an ephemeral size when booting | 16:07 |
Shrews | disk = 10g total, ephemeral is 1g | 16:07 |
NobodyCam | Shrews: I don't recall seeing such, but it is all zero and empty | 16:07 |
Shrews | hrm, either i missed a setting, or the partitioning logic might need a closer inspection | 16:08 |
*** tatyana has joined #openstack-ironic | 16:09 | |
devananda | Shrews: i see that too | 16:10 |
devananda | Shrews: whether or not there's an ephemeral partition | 16:10 |
devananda | it's creating 4 entries | 16:10 |
Shrews | odd | 16:10 |
Shrews | devananda: fyi, your 87396 change now works for me | 16:11 |
devananda | Shrews: awesome | 16:12 |
NobodyCam | could that be a result of the switch to parted? | 16:13 |
Shrews | I'm also going to send this change up to devstac for usk: http://paste.openstack.org/show/76545/ | 16:14 |
Shrews | (wow, that's REALLY bad typing) | 16:14 |
NobodyCam | ie it creates the four primary partitions | 16:14 |
* Shrews gets moor koffee | 16:14 | |
*** coolsvap|afk is now known as coolsvap | 16:20 | |
jroll | happy monday ironic :) | 16:31 |
openstackgerrit | A change was merged to openstack/ironic-python-agent: Fix wait argument on POST https://review.openstack.org/89311 | 16:32 |
NobodyCam | happy monday jroll .. you working today? | 16:32 |
jroll | yep! you too? | 16:34 |
NobodyCam | :) | 16:35 |
*** tatyana has left #openstack-ironic | 16:38 | |
*** zdiN0bot has joined #openstack-ironic | 16:46 | |
*** harlowja_away is now known as harlowja | 16:48 | |
*** newell has joined #openstack-ironic | 16:56 | |
* NobodyCam .. brb... mak'n a bagel before conf call.. | 17:02 | |
*** matty_dubs|lunch is now known as matty_dubs | 17:12 | |
*** dwalleck has joined #openstack-ironic | 17:21 | |
Shrews | When doing a 'replace' for a node PATCH call, will it add the value if it doesn't already exist? | 17:23 |
*** killer_prince has quit IRC | 17:23 | |
*** killer_prince has joined #openstack-ironic | 17:24 | |
*** lazy_prince has joined #openstack-ironic | 17:32 | |
*** killer_prince has quit IRC | 17:34 | |
*** lazy_prince is now known as killer_prince | 17:34 | |
*** vkozhukalov has joined #openstack-ironic | 17:34 | |
*** max_lobur has joined #openstack-ironic | 17:37 | |
Shrews | hrm, "no" is the answer | 17:43 |
*** eghobo has joined #openstack-ironic | 17:43 | |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic-python-agent: Check configdrive size before writing to partition https://review.openstack.org/89390 | 17:46 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic-python-agent: Accept new parameters for `prepare_image` https://review.openstack.org/86723 | 17:46 |
Shrews | appears the dev quickstart guide needs an update, too | 17:46 |
openstackgerrit | Josh Gachnang proposed a change to openstack/ironic: Adding swift temp url support https://review.openstack.org/81391 | 17:49 |
*** BadCub has joined #openstack-ironic | 17:54 | |
openstackgerrit | David Shrewsbury proposed a change to openstack/ironic: Update quickstart guide to enable fake_ipmitool https://review.openstack.org/89392 | 17:56 |
*** BLZbubba_ has joined #openstack-ironic | 17:57 | |
BLZbubba_ | hello how are things going? | 17:57 |
BLZbubba_ | I /win 52 | 17:57 |
BLZbubba_ | heh | 17:57 |
NobodyCam | good mornig BLZbubba_ :) | 17:57 |
*** dwalleck has quit IRC | 17:57 | |
BLZbubba_ | it's been a few weeks since my havana experiment so now i am ready to try icehouse | 17:58 |
*** dwalleck has joined #openstack-ironic | 18:03 | |
*** rameshg87 has joined #openstack-ironic | 18:04 | |
NobodyCam | :) | 18:04 |
rameshg87 | Hello NobodyCam | 18:04 |
NobodyCam | hey hey rameshg87 :) good morning :) | 18:04 |
rameshg87 | good morning :-) | 18:04 |
devananda | Shrews: but "add" will either add OR replace it | 18:05 |
rameshg87 | devananda: NobodyCam: we would like to start the process of adding ilo driver into ironic | 18:06 |
Shrews | devananda: that's... odd/unintuitive | 18:07 |
rameshg87 | as a first step we are planning to raise a separate review for the common code for the ilo driver | 18:07 |
rameshg87 | can i raise a new gerrit review request for them ? | 18:07 |
NobodyCam | rameshg87: yep! | 18:07 |
NobodyCam | be sure to tag the Ilo BluePrint | 18:08 |
rameshg87 | NobodyCam: sure, will do that .. thanks :-) | 18:08 |
*** rameshg87 has left #openstack-ironic | 18:09 | |
devananda | Shrews: https://tools.ietf.org/html/rfc6902#section-4.1 | 18:12 |
devananda | Shrews: just following the RFC here... | 18:12 |
matty_dubs | I'm positive that this has been discussed before and that I should know the answer, but where does etc/ironic/ironic.conf.sample come from? Should it be manually maintained? | 18:13 |
NobodyCam | matty_dubs: https://github.com/openstack/ironic/blob/master/tools/config/generate_sample.sh | 18:14 |
matty_dubs | Rock. Thanks NobodyCam! | 18:15 |
NobodyCam | :) | 18:15 |
NobodyCam | be back before mmeting | 18:15 |
*** coolsvap is now known as coolsvap|afk | 18:18 | |
*** dwalleck has quit IRC | 18:18 | |
BLZbubba_ | ok i'm looking through the etherpad notes and the ironic deploy guide. once I get my ironic system up to the same functionality as my havana-baremetal setup, what will I have to do differently to make non-pxe disk image booting work? | 18:23 |
*** newell has quit IRC | 18:26 | |
openstackgerrit | Josh Gachnang proposed a change to openstack/ironic: Adding a reference driver for the agent https://review.openstack.org/84795 | 18:26 |
*** zdiN0bot has quit IRC | 18:29 | |
*** zdiN0bot has joined #openstack-ironic | 18:35 | |
*** newell has joined #openstack-ironic | 18:38 | |
comstud | devananda: dunno if you saw my reply to your, regarding instance.name. it's a @property on Instance object. | 18:42 |
comstud | your/you | 18:42 |
devananda | comstud: ah, thanks. i mean, what sets it? it's not a DB field afaict | 18:44 |
comstud | so it's a really old nova thing.. that I extremely dislike | 18:45 |
comstud | it's build from a .conf setting | 18:45 |
*** lucasagomes has joined #openstack-ironic | 18:45 | |
comstud | built | 18:45 |
comstud | instance-%08d or something is the extremly old default | 18:45 |
comstud | where %08d is Instance.id | 18:45 |
comstud | but you can instance-%{uuid}s , etc, also | 18:46 |
comstud | IMO, it needs to go away. some (most?) of the nova drivers use this to set the name of the VM in the hypervisor | 18:47 |
comstud | in order to find the VM later to do an action on it. | 18:47 |
comstud | which means... if you change the .conf setting... all of the sudden, your instances are 'gone' from the hypervisor | 18:48 |
NobodyCam | last chance to review the agenda | 18:48 |
lucasagomes | afternoon everybody :) | 18:49 |
matty_dubs | Heya lucasagomes! | 18:49 |
NobodyCam | good afternoon lucasagomes :) | 18:49 |
comstud | (I think 'name' should go away and something like 'hypervisor_label' be added to Instance) | 18:49 |
devananda | comstud: right - so the problem is nova's reliance on that instance.name for certain actions | 18:49 |
lucasagomes | matty_dubs, NobodyCam :) hey | 18:49 |
comstud | devananda: correct | 18:49 |
devananda | comstud: where eg. a local hypervisor might impose a uniqueness on it, irnoic doesn't even store it | 18:49 |
comstud | ah | 18:49 |
comstud | well, you can probably fudge it | 18:49 |
comstud | in the virt driver | 18:50 |
devananda | comstud: eg https://review.openstack.org/#/c/88611/2/ironic/nova/virt/ironic/driver.py | 18:50 |
lucasagomes | devananda, comstud, that's about that patch I had up? yeah I was thinking about simply retuning False on the instance_exists() method | 18:50 |
comstud | blah | 18:50 |
lucasagomes | for efficiency | 18:50 |
devananda | lucasagomes: that's not viable either | 18:50 |
comstud | We should change instance_name arg to be 'instance', I think | 18:51 |
comstud | in nova | 18:51 |
lucasagomes | comstud, yeah, but mostly drivers rely on the instance name | 18:51 |
lucasagomes | xen, libvirt | 18:51 |
comstud | sure | 18:51 |
comstud | but you can then use instance.name there | 18:51 |
comstud | and Ironic can... not use instance.name. | 18:51 |
lucasagomes | right that sounds quite reasonable | 18:51 |
lucasagomes | that name attribute is a pain, it's built on the fly | 18:52 |
lucasagomes | there's no get_by_name() on the instance object | 18:52 |
comstud | lucasagomes: see above -- i'd like to change virt drivers not relying on instance.name | 18:52 |
comstud | :) | 18:52 |
comstud | correct | 18:52 |
lucasagomes | comstud, heh sorry I've no scrollback, I just joined | 18:52 |
comstud | ah | 18:52 |
lucasagomes | (it's holiday here also, came for the meeting) | 18:52 |
comstud | lucasgomes: http://paste.openstack.org/show/76556/ | 18:53 |
comstud | but really: [11:48:56] <comstud> (I think 'name' should go away and something like 'hypervisor_label' be added to Instance) | 18:53 |
comstud | heh | 18:53 |
lucasagomes | heh +1 | 18:54 |
lucasagomes | that's a confusing attribute there | 18:54 |
comstud | I'm considering a BP for juno for this... | 18:54 |
comstud | it's annoyed me for 3 years. | 18:54 |
comstud | and it's not difficult to fix | 18:54 |
lucasagomes | lol | 18:54 |
lucasagomes | yeah | 18:55 |
lucasagomes | but for ironic... should we do what I'm doing on the #8611? | 18:55 |
lucasagomes | find out the instance_uuid using the instance_name | 18:55 |
lucasagomes | ? | 18:55 |
comstud | I'll study it here | 18:55 |
comstud | in compute manager... | 18:55 |
lucasagomes | and check if ironic haven't deployed it yet | 18:55 |
lucasagomes | acl | 18:56 |
lucasagomes | ack* | 18:56 |
comstud | er n/m... let me review this | 18:56 |
*** dwalleck has joined #openstack-ironic | 18:56 | |
comstud | lucasagomes: I think what you do for now... | 18:57 |
comstud | is actually filter on Instance.node | 18:57 |
comstud | and then manually loop through those matching instance_name with Instance.name | 18:57 |
comstud | although that wouldn't be atomic | 18:58 |
comstud | although I guess if you add the filter in nova's DB API, you can do it within the session | 18:58 |
lucasagomes | yeah, we need a get_by_name method in the instance | 18:59 |
lucasagomes | just like we have for flavor | 18:59 |
comstud | lucasagomes: I think that I'd rather fix the instance_exists() argument in nova first | 18:59 |
lucasagomes | comstud, ack | 18:59 |
comstud | before adding teh DB API filter | 18:59 |
comstud | (so the filter isn't needed - i'd rather less code looking at 'name' :) | 18:59 |
lucasagomes | comstud, right I will take a look at it | 18:59 |
comstud | i think it should be easy.. I can also look at a nova patch for it if you want | 19:00 |
NobodyCam | meeting time | 19:00 |
lucasagomes | comstud, sure, that would be great | 19:00 |
comstud | ok, i'll take a look during/after meeting | 19:00 |
*** zdiN0bot has quit IRC | 19:02 | |
lucasagomes | comstud, thanks | 19:03 |
comstud | lucasagomes: ok, I think I have a patch ready... minus any test fixes | 19:07 |
*** romcheg has joined #openstack-ironic | 19:07 | |
romcheg | Guys, it's a public holiday in Ukraine today. I want to let you know that Ukrainian part of Ironic might not be present on the meeting | 19:09 |
NobodyCam | romcheg: ack.. enjoy the holiday | 19:09 |
NobodyCam | and be safe :) | 19:10 |
romcheg | We will read the log | 19:10 |
romcheg | NobodyCam: revolutions and Molotov cocktails is not the way we spend holidays here... most of the times :) | 19:11 |
NobodyCam | :) hehehe | 19:11 |
max_lobur | :) | 19:12 |
lucasagomes | comstud, that was quick hah | 19:12 |
comstud | yeah | 19:13 |
comstud | most drivers use some logic in the base driver class | 19:13 |
comstud | only xenapi and libvirt override it right now | 19:13 |
lucasagomes | ah good | 19:14 |
*** romcheg has quit IRC | 19:16 | |
*** romcheg has joined #openstack-ironic | 19:21 | |
comstud | lucasagomes: https://review.openstack.org/#/c/89407/1 we'll see how that goes | 19:28 |
lucasagomes | comstud, :) added myself as review | 19:29 |
lucasagomes | will review it tomorrow | 19:29 |
lucasagomes | (holiday today) | 19:29 |
comstud | yep cools | 19:29 |
*** romcheg has quit IRC | 19:33 | |
*** zdiN0bot has joined #openstack-ironic | 19:42 | |
*** dwalleck has quit IRC | 19:42 | |
openstackgerrit | Adam Gandelman proposed a change to openstack/ironic: Decouple state inspection and availability check https://review.openstack.org/88476 | 19:48 |
*** zdiN0bot has quit IRC | 19:50 | |
*** zdiN0bot has joined #openstack-ironic | 19:50 | |
jroll | vkozhukalov, agordeev, I don't think we'll make it in the meeting - can we talk about https://blueprints.launchpad.net/ironic/+spec/ipa-discovery-ext | 19:51 |
jroll | I have one question - why? | 19:51 |
*** eghobo has quit IRC | 19:51 | |
jroll | I get the feeling we're getting out of scope again | 19:51 |
*** eghobo has joined #openstack-ironic | 19:51 | |
vkozhukalov | jroll: as far as I remember we agreed about that from the very beginning | 19:54 |
vkozhukalov | jroll: i mean we need to be able to get hardware info via api | 19:54 |
jroll | agreed about what? listing hardware? | 19:54 |
jroll | sure | 19:54 |
jroll | but I'm re-thinking if it is needed | 19:54 |
vkozhukalov | jroll: and we certainly need to get a bit more detailed info | 19:55 |
jroll | why? | 19:55 |
vkozhukalov | jroll: ok, as you remember we are going to use ironic with IPA as our provisioning system in Fuel | 19:55 |
vkozhukalov | jroll: and our use case assumes we have detailed info about cpu disks and network cards | 19:56 |
vkozhukalov | jroll: a bit more detailed that it is not | 19:56 |
vkozhukalov | *that it is now | 19:57 |
jroll | hmm | 19:57 |
adam_g | NobodyCam, RE: tripleO failures | 19:57 |
vkozhukalov | *than it is now )) | 19:57 |
adam_g | NobodyCam, it looks firewall related, i hit the same thing last week with the default openstack-INPUT chain http://logs.openstack.org/29/85529/20/check-tripleo/check-tripleo-ironic-undercloud-precise/d79e330/iptables.txt.gz | 19:57 |
NobodyCam | adam_g: awesome will look after meeting | 19:57 |
adam_g | NobodyCam, had to get https://review.openstack.org/#/c/87416/ merged to update the chain on the devstack slaves. im sure there is a similar puppet manifest for the tripelOs | 19:57 |
jroll | vkozhukalov: I'm not necessarily against this, but it's unclear to me if we should be doing work specifically to support fuel, if that is in scope. would love to hear devananda's take on this when he is done with the meeting | 19:58 |
NobodyCam | adam_g: yes ++ TY | 19:58 |
vkozhukalov | jroll: we are not so sure about getting hardware info via api because it is supposed to be available after discovering | 19:58 |
vkozhukalov | jroll: but i m pretty sure about detailing info | 19:58 |
jroll | ok | 19:59 |
jroll | I think that work should be done in the hardware manager IMO | 19:59 |
jroll | other than that, I would like the blueprint to specify exactly what info and format | 20:00 |
vkozhukalov | jroll: of course fuel is not the only aim, but as far as i understand it is supposed to be a community tool, and we just suggest our vision | 20:00 |
jroll | that's fine :) | 20:00 |
*** max_lobur has quit IRC | 20:00 | |
vkozhukalov | jroll: we need this stuff and we are going to implement that | 20:00 |
jroll | but this is an ironic tool, not a community tool | 20:00 |
jroll | I do appreciate the ideas and the code, I just want to keep this in line with ironic's goals | 20:00 |
jroll | and while I am in a position to make opinions on the IPA goals, I am *not* in such a position with ironic | 20:01 |
jroll | which is why I appreciate devananda's feedback on things like this | 20:01 |
vkozhukalov | jroll: ironic isn't community tool? it is a bit surprising -) | 20:02 |
jroll | I mean | 20:02 |
jroll | it is a community tool | 20:02 |
lucasagomes | thanks for the meeting... have a good night everyone | 20:02 |
jroll | but it is a tool built specifically for ironic | 20:02 |
matty_dubs | Night lucasagomes | 20:02 |
JoshNang | g'night! | 20:02 |
vkozhukalov | jroll: ok, i'll tell agordeev to add detailed info about how he is going to implement that stuff about hardware manager | 20:03 |
jroll | it follows the same model as e.g. python-ironicclient or python-novaclient | 20:03 |
*** lucasagomes is now known as lucas-holiday | 20:03 | |
Shrews | devananda: yes, i'm hoping i can just call power_off() just before spawn() | 20:03 |
devananda | Shrews: do you have a WIP i can look at? | 20:04 |
JoshNang | vkozhukalov: are you planning on just adding additional hardware manager modules? | 20:04 |
jroll | vkozhukalov: does that make sense? | 20:04 |
vkozhukalov | jroll: i understand, and that's why i'm ready to change my opinion wherever i can (for example, lvm is not so critical for me any more -)) | 20:05 |
Shrews | devananda: no. can provide a diff though. it's fairly simple: http://paste.openstack.org/show/76560/ | 20:05 |
vkozhukalov | jroll: JoshNang: ok, for example disks | 20:05 |
vkozhukalov | jroll: JoshNang: for now discovering disks, is just a list of their sizes and names | 20:06 |
vkozhukalov | jroll: JoshNang: it's definitely not enough | 20:06 |
devananda | jroll: jumping in here, the idea of "boot this generic image which interrogates hw and POSTs details to ironic" | 20:06 |
devananda | jroll: that seems like something we've talked about several times | 20:06 |
jroll | vkozhukalov: definitely not enough for what? fuel? | 20:06 |
devananda | jroll: talked about in the positive, yes-ironic-needs-that, sense | 20:07 |
vkozhukalov | jroll: for making right decision about where to install OS and where to locate database for example | 20:07 |
devananda | vkozhukalov: do you have a list of what specific information you need to gather? | 20:08 |
jroll | devananda: indeed, and I'm fine with that. not sure how I feel about exposing hardware via API (I was ok with this at one point but I think I have changed my mind) | 20:08 |
NobodyCam | humm adam_g : do you know if 87416 would apply to all gate nodes or just the devstack ones? | 20:08 |
jroll | vkozhukalov: where to install OS, sure. "where to locate database" has nothing to do with ironic | 20:08 |
devananda | jroll: "exposing hardware via API" -- please clarify. this could be interpreted to refer to Ironic itself | 20:09 |
jroll | devananda: an API endpoint on the agent that lists HW info | 20:09 |
adam_g | NobodyCam, i think that is just the devstack nodes, but i'm not certain | 20:09 |
jroll | devananda: for reference we're looking at https://blueprints.launchpad.net/ironic/+spec/ipa-discovery-ext | 20:09 |
NobodyCam | adam_g: ack... Ty looking now | 20:09 |
devananda | vkozhukalov: jroll: "where to locate database" is a decision that should be made at a higher level, but ironic should *expose* enough information that a service like TripleO or Fuel can make that decision | 20:09 |
jroll | sure, that's fair | 20:10 |
vkozhukalov | devananda: for example we need to have info about io performance, about disk bus etc. why can't we just give some detailed info to user and let him to make his own decision | 20:10 |
vkozhukalov | devananda: exactly | 20:11 |
jroll | vkozhukalov: interesting, how would you gather io performance info without running benchmarks? | 20:11 |
vkozhukalov | devananda: we are not going to enforce ironic to deal with that info, we just want to have this info in hardware field of a node (extra field) | 20:12 |
jroll | vkozhukalov: one other thing that troubles me about storing it in ironic's database is the data structure there - if it's in the db, you won't be able to nest dicts or lists | 20:13 |
vkozhukalov | jroll: i definitely can find out if disk ssd or not for example without any benchmarks | 20:13 |
comstud | we can nest dicts or lists in the DB | 20:14 |
comstud | however, i would probably avoid that | 20:14 |
jroll | comstud: today we cannot, because validation | 20:14 |
comstud | the field type validation? | 20:14 |
jroll | vkozhukalov: sure | 20:14 |
jroll | comstud: I think it's in the API | 20:14 |
jroll | well, I know it's in the API, not sure about elsewhere | 20:14 |
comstud | oh | 20:14 |
vkozhukalov | jroll: i can put json into extra, what is wrong with this kind of structure | 20:14 |
jroll | maybe object level | 20:15 |
jroll | vkozhukalov: ironic today does not allow nested json | 20:15 |
jroll | just as an fyi | 20:15 |
comstud | I know less about the type validation code for API | 20:15 |
comstud | so n/m :) | 20:15 |
jroll | vkozhukalov: that may just be in the api validation, I would need to look | 20:15 |
jroll | comstud: it's... interesting | 20:15 |
devananda | a) nested dicts -- not today. and i'd rather avoid anyway | 20:16 |
devananda | b) it's fine to use namespaces in the extra field | 20:16 |
devananda | eg, extra/foo_bar && extra/foo_baz | 20:16 |
devananda | vkozhukalov: the problem is not "get the info from hw, store in ironic" | 20:17 |
devananda | vkozhukalov: it is "how does nova scheduler find the node with $THIS performance" | 20:17 |
jroll | right, I just see extra/disks__0__type, extra/disks__0__size etc coming | 20:17 |
devananda | right | 20:17 |
jroll | which seems unhealthy to me | 20:17 |
devananda | this problem falls really into the nova scheduler domain | 20:17 |
jroll | at least for my sanity | 20:18 |
devananda | how do we leverage teh data taht ironic CAN gather? | 20:18 |
devananda | and based on that, what data SHOULD we gather (since the ways we can leverage it will be limited) | 20:18 |
jroll | yes, that's the inherent problem | 20:18 |
devananda | vkozhukalov: so please take a close look at how you will utilize this ifnormation in Nova before deciding what to gather from the hardware or what format to store it in Ironic | 20:18 |
devananda | for instance, you can't search by a field in extra | 20:19 |
devananda | and IMNSHO you never will :) | 20:19 |
vkozhukalov | devananda: isn't this a scheduler problem? we just need to implement smart enough scheduler filter, don't we? | 20:19 |
devananda | mysql is a terrible place to search inside a JSON field | 20:19 |
devananda | vkozhukalov: that's not as simple as it sounds | 20:19 |
*** GheRivero is now known as GheAway | 20:20 | |
jroll | to be fair, nova-compute today does a GET for each node in the db... | 20:20 |
devananda | vkozhukalov: what if you have 10k hw nodes and user requests a flavor that matches only 10 of them -- and taht info is in the extra/__disk_performance field. you can't query Ironic for that, so nova has to fetch the entire data set of all nodes from ironic | 20:20 |
vkozhukalov | devananda: ok, I'll point it out to agordeev | 20:20 |
devananda | and iterate in python | 20:20 |
devananda | jroll: it's abominable today. but this will make it worse, IMO | 20:21 |
jroll | sure. | 20:21 |
jroll | but not as much as someone would expect, not knowing that fact :) | 20:21 |
vkozhukalov | devananda: thank for paying our attention to this stuff, will think of that | 20:22 |
*** dwalleck has joined #openstack-ironic | 20:23 | |
devananda | vkozhukalov: absolutely. this is all important stuff. if only the day had more hours in it ... :) | 20:24 |
devananda | ok, time for lunch | 20:24 |
devananda | bbiab | 20:24 |
* jroll brb too | 20:25 | |
*** zdiN0bot has quit IRC | 20:28 | |
*** zdiN0bot has joined #openstack-ironic | 20:35 | |
*** dwalleck has quit IRC | 20:42 | |
NobodyCam | doh help to actually set USE_IRONIC if you are trying to test ironic :-p (*FaceToPalms*) | 20:42 |
*** linggao__ has quit IRC | 20:46 | |
*** jbjohnso has quit IRC | 21:09 | |
Shrews | i love that my devstack test vm just mysteriously likes to randomly run sooooo sloooooooow | 21:11 |
* Shrews turns it off and on again | 21:11 | |
devananda | Shrews: i see you updating the dev-quickstart for fake_ipmitool -- but why is taht driver in the quickstart anyway? | 21:19 |
*** hewbrocc` is now known as hewbrocca | 21:20 | |
NobodyCam | adam_g: that patch you did should actually work for the tripleO nodes too, clark just checked in -infra and the tripleo check nodes were build on 136 hours ago which makes them older then your patch :) | 21:21 |
adam_g | NobodyCam, ah. makes sense. | 21:22 |
jroll | is there some amount of disk reserved in ironic/nova? I just tried to boot an image with minDisk==20 to a node with local_gb==32, and got ERROR: Flavor's disk is too small for requested image. (HTTP 400) | 21:30 |
comstud | that's on the image metadata | 21:34 |
comstud | there's a min_disk_size or something on the image | 21:34 |
jroll | right, the image has minDisk 20 | 21:34 |
comstud | sorry, i misread | 21:35 |
comstud | hm | 21:35 |
* jroll will poke around | 21:35 | |
comstud | it's something tod ow ith that | 21:35 |
comstud | hm | 21:35 |
adam_g | jroll, what are the disk/ephemeral sizes for the correspoinding nova flavor? | 21:35 |
comstud | i'm in nova right now, i'll look | 21:35 |
*** openstackstatus has quit IRC | 21:35 | |
jroll | oh heh | 21:36 |
jroll | thanks adam_g | 21:36 |
comstud | 613 if int(image.get('size') or 0) > root_gb * (1024 ** 3): | 21:36 |
adam_g | :) | 21:36 |
*** openstackstatus has joined #openstack-ironic | 21:36 | |
comstud | uh | 21:36 |
* jroll tracks down whoever put this flavor in | 21:36 | |
comstud | image metadata needs to be the full size? | 21:36 |
jroll | comstud: turns out this flavor is set to 8gb | 21:36 |
comstud | in bytes | 21:36 |
jroll | flavor-show doesn't give me size :/ | 21:37 |
comstud | root_gb | 21:37 |
jroll | root_gb should be in gb | 21:38 |
jroll | no? | 21:38 |
comstud | yes | 21:38 |
comstud | it's 8 ? | 21:38 |
comstud | ah, you're hitting this | 21:38 |
comstud | 616 if int(image.get('min_disk') or 0) > root_gb: | 21:38 |
jroll | "disk" is 8 on the flavor | 21:38 |
comstud | 617 raise exception.FlavorDiskTooSmall() | 21:38 |
comstud | so yeah | 21:38 |
comstud | 20 > 8 | 21:38 |
adam_g | jroll, IIRC you can set the flavor sizes to -1 to avoid the restriction | 21:38 |
jroll | right | 21:38 |
jroll | comstud: the flavor should be 32 :P | 21:39 |
comstud | gotcha | 21:39 |
comstud | i can update that | 21:39 |
comstud | :) | 21:39 |
comstud | i shall make it so? | 21:39 |
jroll | sure | 21:39 |
jroll | where is that, for the record? | 21:39 |
jroll | what table, that isd | 21:39 |
jroll | is | 21:39 |
jroll | instance_types? | 21:39 |
adam_g | at one point m1.tiny's (disk 0) could attempt to boot a 500TB image, or at least attempt to | 21:39 |
comstud | yeah | 21:40 |
jroll | cool | 21:40 |
devananda | so there seems to often be confusion about this | 21:41 |
devananda | by default today, afaik, flavor specs (cpu, ram, disk) need to be <= node properties | 21:41 |
devananda | we have ExactMatch filter schedulers in ironic, that need to be copied to the Nova tree to be used | 21:42 |
devananda | that make it an == check | 21:42 |
comstud | yeah, this issue is some API validation | 21:44 |
comstud | on image vs flavor | 21:44 |
devananda | oh, gotcha | 21:44 |
devananda | not flavor vs node | 21:44 |
comstud | ie, flavor is 8GB disk, but image says it needs at least 20GB | 21:44 |
comstud | etc | 21:44 |
comstud | nod | 21:44 |
comstud | devananda: curious your thoughts on: https://review.openstack.org/#/c/89328/ | 21:45 |
comstud | i have a couple of patches ahead of it.. previous one also fixes a potential stuck-lock issue in _check_deploy_timeouts | 21:46 |
comstud | then I realized I should probably make a helper method because this is extremely fragile | 21:46 |
devananda | looking | 21:46 |
*** dwalleck has joined #openstack-ironic | 21:47 | |
devananda | comstud: yea. task_manager wasn't originally intended to handle this sort of use. | 21:51 |
comstud | nod | 21:51 |
comstud | i want to consolidate this logic that makes sure we unlock.. | 21:51 |
comstud | for this spawn_worker case | 21:51 |
devananda | comstud: my initial thought is that, yes, a helper here would be very good, but it should be in the task_manager module | 21:52 |
comstud | This is the best I could think of off-hand | 21:52 |
devananda | comstud: think that's doable? | 21:52 |
comstud | I wanted to put it there... | 21:52 |
comstud | I think maybe I could | 21:52 |
comstud | just make it more generic... the context manager not call self._spawn_worker | 21:53 |
comstud | but just call any method you want to call | 21:53 |
comstud | or something. | 21:53 |
devananda | right | 21:53 |
comstud | the one thing I want to consolidate is... the spawn/link handling | 21:53 |
Shrews | devananda: i dunno. why wouldn't it be? | 21:53 |
comstud | to make sure you thread.cancel, also | 21:53 |
comstud | which is why this helper is in the Manager | 21:54 |
comstud | but maybe I can move most of this and still have a helper in the manager also | 21:54 |
comstud | devananda: i'll re-work a bit and see what I come up with | 21:54 |
*** datajerk has quit IRC | 21:55 | |
devananda | comstud: this might be a bit much, and i haevn't thought it through yet | 21:56 |
devananda | comstud: but what if we moved teh worker_pool into the task_manager namespace? | 21:56 |
comstud | maybe TaskManager() just needs a way for you to say "hey, don't unlock these guys" | 21:56 |
comstud | when the ctxt mgr exits | 21:56 |
comstud | then you can keep the spawn helper more simplified in Manager | 21:57 |
devananda | comstud: that's not what we have? | 21:57 |
comstud | 235 def __exit__(self, exc_type, exc_val, exc_tb): | 21:57 |
comstud | 236 self.release_resources() | 21:57 |
comstud | that's TaskManager | 21:57 |
comstud | say.. if you could so something like this: | 21:57 |
comstud | with TaskManager() as task: | 21:57 |
devananda | comstud: i mean, ues, but that doesn't solve the "its easy to leave a dangling lock" -- it makes it easier to break | 21:57 |
comstud | .. do some stuff .. | 21:57 |
comstud | spawn_worker() | 21:58 |
comstud | link() | 21:58 |
comstud | task.dont_unlock() | 21:58 |
comstud | then you get most of the logic that I've added here | 21:58 |
*** mrda has joined #openstack-ironic | 21:58 | |
devananda | but it's still explicit | 21:58 |
devananda | and duplicated in every function in the manager that needs it | 21:58 |
comstud | i'd keep my helper in the manager | 21:59 |
comstud | but it's just more simplified | 21:59 |
comstud | but yeah, if you want spawn to move to TaskManager... | 21:59 |
comstud | maybe that's better | 21:59 |
devananda | Shrews: in a pure venv, are you testing IPMI? | 21:59 |
devananda | Shrews: there's nothing really in the guide right now for what to do with the "ipmi" part of fake_ipmi | 22:00 |
Shrews | devananda: i abandoned the change | 22:00 |
devananda | Shrews: i think you're pointing out a valid problem though :) | 22:00 |
devananda | Shrews: i just think it should be s/fake_ipmi/fake/ | 22:00 |
BLZbubba_ | oops I didn't check on my earlier question | 22:00 |
Shrews | devananda: i just noticed it when i was testing the behavior of the node-update command | 22:00 |
comstud | devananda: I'll iterate on this... i know what you're saying | 22:01 |
BLZbubba_ | looking at how to do non pxe booting so I can add some windows baremetal ( unfortunately :P ) | 22:01 |
devananda | comstud: i'm not sure -- but i think i prefer keeping the Manager focused on the interfacing between RPC calls and drivers and the hash ring | 22:01 |
comstud | i'll do a v2... knowing I may be doing a v3.. but it's just shuffling code around | 22:01 |
comstud | yeah | 22:02 |
comstud | I have something in mind here for v2 that might be acceptable | 22:02 |
comstud | but i can iterate on that if it's not quite right also | 22:02 |
devananda | comstud: great. thanks for workin on that :) | 22:02 |
comstud | np | 22:02 |
devananda | BLZbubba_: hi! iiuc, you want to enable localboot, yes? | 22:03 |
devananda | BLZbubba_: bcause it is possible to pxe boot windows (chain boot to hd0) | 22:03 |
*** matty_dubs is now known as matty_dubs|gone | 22:04 | |
Shrews | ugh. so close | 22:11 |
openstackgerrit | Chris Behrens proposed a change to openstack/ironic: Create helper method for worker with lock https://review.openstack.org/89328 | 22:16 |
comstud | iteration 2.. didn't fix tests yet | 22:17 |
comstud | going to do iteration 3 to see what it looks like.. | 22:17 |
mikal | devananda: we're apparently talking about a thing? | 22:17 |
devananda | mikal: hi! yep, this - http://summit.openstack.org/cfp/details/215 | 22:18 |
devananda | mikal: specifically, we were discussing whether we can realistically talk about a roadmap to getting ironic to graduate prior to taht session with nova | 22:18 |
mikal | devananda: sure, what's the question though? | 22:18 |
comstud | er oops | 22:19 |
BLZbubba_ | devananda: ah interesting | 22:19 |
mikal | Ahhh, I see | 22:19 |
devananda | mikal: if/when that session is going to be scheduled. so we can find some uncnoference time to formulate ironic's plans | 22:19 |
openstackgerrit | Chris Behrens proposed a change to openstack/ironic: Create helper method for worker with lock https://review.openstack.org/89328 | 22:20 |
mikal | devananda: so, you're talking about trying to find time to talk about it before the session at the summit, or in a mail thread? | 22:20 |
mikal | devananda: also, no unconference this time around | 22:20 |
devananda | mikal: at the summit | 22:21 |
mikal | devananda: ok | 22:21 |
devananda | mikal: also, huh? i thought there were going to be tables and things for each project | 22:21 |
mikal | devananda: I think having someone like sdague in the room for the chat would be a good idea | 22:21 |
devananda | mikal: yes, and jeblair as well, possibly, since it's an infra problem | 22:22 |
mikal | devananda: ahhh, maybe we're using different meanings. There used to be an unconference for presentations. That has gone away. I assume there will still be tables in the dev lounge. | 22:22 |
devananda | mikal: ahh. no, you're right -- having a serious roadmap discussion for ironic at a table is a bad idea | 22:22 |
mikal | devananda: well, I'm more than happy to chat about it... Monday might be the winning day because there's no dsign summit that day. | 22:22 |
devananda | mikal: ifw e can get the right people together, monday would be great. ironic only has 4 slots, and they're all on tuesday (co-placed with the cross project track) | 22:23 |
devananda | without an unconference room, i'm wondering if we'll get any time as a whole project to meet | 22:23 |
devananda | * after taht | 22:23 |
mikal | Well, how about I send you and email with my current commitments for Monday, and I am happy to slot in whenever I am free | 22:24 |
devananda | mikal: thanks! | 22:24 |
mikal | NP! | 22:24 |
devananda | mikal: want me to send a summary to the dev list, start getting a discussion going ahead of the summit? | 22:26 |
openstackgerrit | Chris Behrens proposed a change to openstack/ironic: Create helper method for worker with lock https://review.openstack.org/89328 | 22:29 |
comstud | devananda: https://review.openstack.org/#/c/89328/4/ironic/conductor/task_manager.py,unified | 22:32 |
comstud | i could just return after the thread.link, I guess | 22:33 |
comstud | and forget this cancel_unlock() method.. i used it in previous iteration | 22:33 |
devananda | comstud: yea, taht's more what i had in mind | 22:34 |
comstud | https://review.openstack.org/#/c/89328/4/ironic/conductor/manager.py,unified line 739 shows what the Manager helper looks like | 22:34 |
comstud | if you didn't look at that side yet | 22:34 |
comstud | although I could probably just ditch it | 22:35 |
devananda | comstud: you've still got self._spawn_after_lock | 22:35 |
comstud | i could ditch it now, I guess.. | 22:35 |
comstud | it doesn't save any lines of code | 22:35 |
comstud | ok | 22:35 |
devananda | i thnk you want "with task_manager.acquire() .." | 22:35 |
comstud | yep | 22:35 |
comstud | fixing | 22:35 |
devananda | and then call task.spawn_after() inside the context | 22:35 |
comstud | yep | 22:36 |
*** jgrimm_ has quit IRC | 22:37 | |
comstud | this is going to look nice, I think | 22:38 |
openstackgerrit | Chris Behrens proposed a change to openstack/ironic: Create helper method for worker with lock https://review.openstack.org/89328 | 22:41 |
comstud | ok, let's see what this looks like | 22:41 |
comstud | ah, missing a try around spawn | 22:42 |
openstackgerrit | Chris Behrens proposed a change to openstack/ironic: Create helper method for worker with lock https://review.openstack.org/89328 | 22:43 |
*** lucas-holiday has quit IRC | 22:44 | |
comstud | this nukes a lot of code from the manager.. good | 22:44 |
comstud | ok, need to update commit reason and fix tests. | 22:45 |
*** vkozhukalov has quit IRC | 22:46 | |
Shrews | devananda: so apparently, i need to set power state to "power off" and provision state to "None" in order to rebuild. Do you see any adverse side effects of me doing this to an active instance? | 22:52 |
Shrews | Not so much the power state but rather the provision state | 22:55 |
jroll | Shrews: that sounds like a bug to me... isn't it just a spawn if the node isn't provisioned? | 22:56 |
Shrews | jroll: The node is already provisioned, that's the problem. We're trying to rebuild a provisioned instance. | 22:57 |
jroll | right, I thought rebuild was always for provisioned nodes | 22:57 |
jroll | by that definition you should not need to set provision_state = None | 22:58 |
Shrews | The default implementation of 'rebuild' will destroy the instance, so the state isn't a problem. | 22:58 |
jroll | ahh | 22:58 |
Shrews | jroll: I'm trying to make preserve_ephemeral work | 22:58 |
jroll | right | 22:59 |
devananda | Shrews: yep | 23:02 |
devananda | Shrews: rebuild should actually power off and copy a new OS image onto the node | 23:02 |
*** eguz has joined #openstack-ironic | 23:03 | |
devananda | Shrews: the hooks to preserve ephemeral in ironic shoudl already be done, i think | 23:03 |
devananda | it's just a matter of nova knowing to pass in the right info | 23:03 |
Shrews | devananda: right, but let me restate the question... | 23:03 |
devananda | jroll: ya'll added node.instance_info a while back. were you going to pivot the pxe driver to use that? | 23:04 |
devananda | jroll: i think that's going to be necessary prior to landing the agent, so that both pxe and agent can accept the same data from Nova | 23:04 |
devananda | jroll: or have you already got a patch doing it that i overlooked? | 23:04 |
jroll | devananda: oh yeah, I should do that | 23:04 |
devananda | :) | 23:04 |
jroll | devananda: pxe and agent driver will still be posting different data to ironic, though | 23:04 |
jroll | jfyi | 23:05 |
devananda | jroll: erm | 23:05 |
Shrews | nova requires the node provision state to not be active in order to spawn() it. my plan is to power it down then change the provision state before doing the spawn(). just wondering if that plan would have side effects i'm not considering | 23:05 |
devananda | jroll: oh, you mean, the deploy ramdisk && the agent ramdisk will POST different data back to ironic-api | 23:05 |
devananda | jroll: yes, that's fine -- it's the Nova->ironic interaction taht needs to be the same | 23:05 |
jroll | devananda: erm indeed :P I mean the nova driver will post different data for pxe and agent drivers. | 23:05 |
devananda | jroll: that's not right | 23:05 |
jroll | ehhhh isn't that why we have the driverfactory thing? | 23:05 |
jroll | devananda: for reference: https://review.openstack.org/#/c/85131/ | 23:05 |
devananda | jroll: it is. and i think we should kill that :) | 23:06 |
jroll | one example is that we need configdrive | 23:06 |
jroll | do you want to build configdrives for the pxe driver? | 23:06 |
jroll | devananda: sorry, I shuold reference https://review.openstack.org/#/c/86192/8/ironic/nova/virt/ironic/ironic_driver_fields.py | 23:06 |
*** eghobo has quit IRC | 23:06 | |
devananda | oh, gotcha | 23:06 |
jroll | but yeah, pxe has extra data agent doesn't need and vice versa | 23:07 |
jroll | I would love for them to be the same but I don't know that it's crucial | 23:07 |
devananda | Shrews: do we need to call nova.virt.ironic.driver.spawn() at all? | 23:07 |
devananda | Shrews: i mean, that method is intended for new instances. rebuild's default implementation uses it, but our real implementation shouldn't.. .right? | 23:08 |
devananda | Shrews: I think spawn is goign to fail here: https://github.com/openstack/ironic/blob/master/ironic/nova/virt/ironic/driver.py#L347 | 23:09 |
devananda | Shrews: because the node.isntance_uuid property can not be set twice -- but if you unset it from Nova, you craet a race condition | 23:10 |
devananda | Shrews: also, setting the node.provision_staet to None will trigger a conductor.Manager.tear_down() which may erase the disks | 23:10 |
devananda | depending on whether that driver implements any remote wipe (pxe does not, agent ... maybe?) | 23:11 |
devananda | jroll: what extra data does pxe have that agent does not? | 23:11 |
Shrews | devananda: why can't it be set twice? you just confirmed for me earlier that 'add' will also do a replace in a patch | 23:11 |
Shrews | but that bit about the tear_down() is what i was looking for with my original question... | 23:11 |
devananda | Shrews: heh, well... instance_uuid is handled separately.. | 23:12 |
mikal | devananda: I just sent you that promised email | 23:12 |
Shrews | so perhaps skipping spawn() is what should be down, given that | 23:12 |
Shrews | s/down/done/ | 23:12 |
devananda | Shrews: imagine node N is unassociated. two nova instances are created, both attempt toa ssociate to node N. | 23:12 |
jroll | devananda: today, root_gb, swap_gb, deploy_kernel, deploy_kernel_id, deploy_ramdisk_id | 23:12 |
devananda | Shrews: if both attempts' PATCH requests succeeded, things would break because two instances would be trying to be built (fron nova's pov) on one node | 23:13 |
devananda | Shrews: https://github.com/openstack/ironic/blob/master/ironic/db/sqlalchemy/api.py#L373 | 23:14 |
devananda | Shrews: perhaps that needs to be better documented... | 23:14 |
Shrews | gotcha | 23:15 |
Shrews | so, two reasons why spawn() must be skipped | 23:15 |
* Shrews calling it a day. g'night all | 23:18 | |
devananda | fwiw, https://bugs.launchpad.net/ironic/+bug/1310843 | 23:20 |
devananda | jroll: root, swap, and ephemeral need to be supported | 23:20 |
devananda | jroll: and what are you using for PXE booting the agent, if you dont use the deploy_* fields? | 23:20 |
jroll | devananda: right, those should be supported eventually | 23:21 |
jroll | for PXE booting, we use a single image | 23:21 |
devananda | jroll: so, those should move to instance_info since both drivesr need them | 23:22 |
jroll | right | 23:22 |
devananda | jroll: and ironic needs to suppot environments with multiple drivers | 23:22 |
devananda | really, all drivers in parallel should be supported | 23:22 |
devananda | so if you have a hard requirement on a static DHCP config that responds with the agent image | 23:22 |
devananda | that can't work | 23:22 |
jroll | erm | 23:22 |
devananda | i mean, that is not acceptable upstream ... it may work fine locally | 23:22 |
jroll | hmm | 23:22 |
devananda | because it would prevent the existing driver from working | 23:23 |
devananda | right? | 23:23 |
jroll | right | 23:23 |
jroll | for the pxe driver, ironic-conductor acts as the dhcp server yes? | 23:23 |
devananda | jroll: neutron | 23:24 |
jroll | ah | 23:24 |
jroll | does that support ipxe chainloading over http by chance? thinking no? | 23:24 |
devananda | i would very much like it to | 23:25 |
jroll | hmm | 23:25 |
jroll | we very much need it to, for now | 23:25 |
jroll | devananda: hmm, I'll look into what we can do as far as supporting envs with multiple drivers. is that a hard requirement for landing the agent driver and iterating on it? | 23:29 |
devananda | jroll: i should be less hasty in my typing :) | 23:29 |
*** dwalleck has quit IRC | 23:29 | |
devananda | jroll: it's a significant part of the architecture of ironic, the message i have been telling everyone about ironic for the last year, and it's intent | 23:30 |
devananda | jroll: manage heterogeneous hardware platforms from a single control plane | 23:30 |
devananda | jroll: a lot of the architecture hinges on the ability for conductors to support multiple drivers *concurrentlY* | 23:30 |
jroll | devananda: right, I understand | 23:31 |
devananda | jroll: i dont see any technical reason why the pxe and agent driver couldn't coexist | 23:31 |
jroll | agreed | 23:32 |
jroll | and I plan to work toward that | 23:32 |
jroll | but right now I would like to land these patches because our patch dependency tree is now 5 or 6 levels deep :| | 23:33 |
devananda | :) | 23:33 |
jroll | I'm beginning to cringe every time I type the word rebase | 23:33 |
jroll | so, my question is: | 23:33 |
jroll | are you okay with landing the current in-flight patches and fixing that afterward? | 23:34 |
kevinbenton | devananda: ping | 23:35 |
devananda | sorry, my internet's being a bit flaky... | 23:35 |
devananda | jroll: some - yes, particularly the ones that are refactoring code in generally-good ways | 23:36 |
devananda | jroll: but the driver itself, probably not yet | 23:36 |
jroll | devananda: I'm mostly referring to the agent driver patch ( https://review.openstack.org/#/c/84795/ ) and the things it depends on | 23:36 |
jroll | ok. | 23:36 |
devananda | lemme see | 23:36 |
jroll | that patch doesn't have the nova bits fwiw | 23:37 |
jroll | and if you don't want to merge 84795 without deploy_* fields etc, then I'm going to squash all of these patches into one, if that's ok with you | 23:38 |
devananda | jroll: a fwe questions | 23:38 |
jroll | and there will be potentially multiple people amending that commit - bit of a pain on our side, not sure what that is like for reviewers | 23:38 |
jroll | shoot | 23:38 |
devananda | jroll: have you thought about how you'll test this upstream? ie, plug into devstack/tempest | 23:38 |
devananda | kevinbenton: hi! fire off your questions, i'll respond async | 23:39 |
jroll | devananda: JoshNang is currently working on a devstack setup using the ssh driver etc for our use, we'd probably doing something similar | 23:39 |
devananda | jroll: how do you feel about having the driver in tree but not enabled by default (ie, marked experimental) | 23:40 |
jroll | devananda: that's been the plan :) are you okay with leaving a WIP review to enable by default? | 23:41 |
devananda | jroll: the driver still has many TODO's in it. based on those, it looks like it won't function today | 23:42 |
devananda | eg, tear_down is not doign anything | 23:42 |
jroll | right, we're working on those. some are addressed in later patches, some are optimizations (like configdrive in swift) | 23:43 |
devananda | k | 23:43 |
jroll | some like tear_down we just haven't done | 23:43 |
jroll | all that said, if you're not comfortable merging this stuff yet, we can just iterate on this single patch | 23:44 |
jroll | or in multiple patches if necessary, but that's proving to be a major pain for us | 23:44 |
devananda | jroll: for a driver, i actually prefer it to be one patch, as long as the changes are self-contained | 23:45 |
devananda | jroll: anything that is useful refactoring and not directly part of that driver (eg, the nodeless vendor passhtru) should be separate patches | 23:45 |
devananda | and i think you guys have been doing the right thing there | 23:45 |
devananda | i'd like to see those land | 23:45 |
jroll | agreed | 23:45 |
devananda | and hoping other reviewers will step up ... | 23:46 |
jroll | :) | 23:46 |
jroll | so, here's my plan | 23:46 |
jroll | tonight or tomorrow morning, I'm going to condense (most|all) of the agent-driver patches into 84795 | 23:46 |
jroll | and I'll shoot something out to the ML about the fact that I did that, what we know is missing to land it, and please review to find things we don't know are missing | 23:47 |
jroll | I'll remove from setup.cfg (or did the whitelist thing land?) for the purposes of that review | 23:47 |
jroll | but will probably add a 'do not merge' patch to enable by default, for ease of testing on our end | 23:48 |
jroll | what do you think? | 23:48 |
*** openstackgerrit has quit IRC | 23:50 | |
*** openstackgerrit has joined #openstack-ironic | 23:50 | |
kevinbenton | devananda: i’m interesting in the integration of neutron and ironic | 23:51 |
kevinbenton | devananda: it’s something we had in mind when creating the now-named external-port extension for neutron | 23:52 |
kevinbenton | devananda: is this something that there is interest from on the ironic side? | 23:52 |
devananda | jroll: enabled-drivers list landed | 23:53 |
jroll | nice, I'll use that | 23:53 |
devananda | jroll: otherwise yes, sounds like a good plan to me. specifically calling out the present incompatibilities and your plans for testing is great | 23:54 |
jroll | cool, will do that. thanks. | 23:54 |
devananda | kevinbenton: hi! i saw your BP -- thanks for tagging me. Yes, that's definitely something we've talkeda bout | 23:54 |
kevinbenton | devananda: should we just meet up at the summit to see what work needs to be done. I would really like to contribute to ironic if nobody else is working on it alreay | 23:56 |
devananda | kevinbenton: aiui, this relates to http://summit.openstack.org/cfp/details/405 | 23:57 |
devananda | kevinbenton: we wont have time for that session, but... | 23:57 |
devananda | kevinbenton: there are definitely folks interested in network isolation for bare metal tenents | 23:57 |
devananda | kevinbenton: and i'm not aware of anyone working on code yet | 23:57 |
jroll | \o :) | 23:57 |
jroll | kevinbenton: we should talk :) | 23:58 |
kevinbenton | jroll: ok, will you be at the summit? | 23:59 |
jroll | yep! | 23:59 |
*** dwalleck has joined #openstack-ironic | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!