| *** kylers has quit IRC | 00:01 | |
| *** lucas-dinner has quit IRC | 00:02 | |
| *** kylers has joined #openstack-ironic | 00:07 | |
| *** Penick has quit IRC | 00:14 | |
| *** matsuhashi has joined #openstack-ironic | 00:21 | |
| *** achanda has quit IRC | 00:22 | |
| *** achanda has joined #openstack-ironic | 00:24 | |
| *** eghobo has quit IRC | 00:26 | |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Add ironic-python-agent deploy driver (DO NOT MERGE) https://review.openstack.org/101020 | 00:37 |
|---|---|---|
| *** bandicot has joined #openstack-ironic | 01:00 | |
| *** eghobo has joined #openstack-ironic | 01:05 | |
| *** eghobo has joined #openstack-ironic | 01:05 | |
| *** ellenh has quit IRC | 01:09 | |
| *** yu_ has quit IRC | 01:15 | |
| *** bandicot has quit IRC | 01:16 | |
| *** kylers has quit IRC | 01:22 | |
| *** nosnos has joined #openstack-ironic | 01:44 | |
| *** eguz has joined #openstack-ironic | 01:46 | |
| *** eghobo has quit IRC | 01:50 | |
| *** eguz has quit IRC | 01:51 | |
| *** pcrews has quit IRC | 02:34 | |
| *** killer_prince is now known as lazy_prince | 02:42 | |
| *** lazy_prince is now known as killer_prince | 02:42 | |
| *** yfujioka has joined #openstack-ironic | 02:42 | |
| *** killer_prince is now known as lazy_prince | 02:43 | |
| *** lazy_prince is now known as killer_prince | 02:45 | |
| *** nosnos has quit IRC | 02:54 | |
| *** nosnos has joined #openstack-ironic | 02:54 | |
| *** nosnos has quit IRC | 02:59 | |
| *** nosnos has joined #openstack-ironic | 03:05 | |
| *** vinbs has joined #openstack-ironic | 03:06 | |
| *** matsuhashi has quit IRC | 03:18 | |
| *** matsuhashi has joined #openstack-ironic | 03:19 | |
| *** matsuhashi has quit IRC | 03:24 | |
| *** nosnos has quit IRC | 03:34 | |
| *** nosnos has joined #openstack-ironic | 03:35 | |
| *** rloo has quit IRC | 03:37 | |
| *** eghobo has joined #openstack-ironic | 03:38 | |
| *** nosnos has quit IRC | 03:39 | |
| *** saripurigopi has joined #openstack-ironic | 03:40 | |
| *** todd_dsm has joined #openstack-ironic | 03:52 | |
| vinbs | Morning Ironic! :) | 04:02 |
| *** GheRivero has quit IRC | 04:04 | |
| *** davidlenwell_ has joined #openstack-ironic | 04:04 | |
| *** GheRivero has joined #openstack-ironic | 04:04 | |
| *** davidlenwell has quit IRC | 04:05 | |
| *** matsuhashi has joined #openstack-ironic | 04:10 | |
| *** nosnos has joined #openstack-ironic | 04:19 | |
| *** killer_prince is now known as lazy_prince | 04:24 | |
| *** todd_dsm has quit IRC | 04:37 | |
| *** lazy_prince has quit IRC | 04:41 | |
| *** rameshg87 has joined #openstack-ironic | 04:48 | |
| *** pcrews has joined #openstack-ironic | 04:49 | |
| *** rameshg87 has quit IRC | 04:55 | |
| *** rakesh_hs4 has joined #openstack-ironic | 04:57 | |
| Haomeng | vinbs: morning:) | 04:59 |
| *** eghobo has quit IRC | 05:00 | |
| *** eghobo has joined #openstack-ironic | 05:01 | |
| *** bmahalakshmi has joined #openstack-ironic | 05:02 | |
| mrda | Hi vinbs and Haomeng | 05:06 |
| Haomeng | mrda: morning:) | 05:06 |
| *** ajc_ has joined #openstack-ironic | 05:07 | |
| *** lazy_prince has joined #openstack-ironic | 05:09 | |
| *** achanda has quit IRC | 05:11 | |
| *** rameshg87 has joined #openstack-ironic | 05:12 | |
| *** achanda has joined #openstack-ironic | 05:19 | |
| *** k4n0 has joined #openstack-ironic | 05:21 | |
| *** lazy_prince is now known as killer_prince | 05:22 | |
| *** Nisha has joined #openstack-ironic | 05:28 | |
| *** amitpp has joined #openstack-ironic | 05:29 | |
| *** coolsvap|afk is now known as coolsvap | 05:35 | |
| *** rwsu has quit IRC | 05:41 | |
| *** Mikhail_D_ltp has joined #openstack-ironic | 05:54 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic: Imported Translations from Transifex https://review.openstack.org/96063 | 06:02 |
| *** killer_prince is now known as lazy_prince | 06:15 | |
| *** harlowja is now known as harlowja_away | 06:20 | |
| *** kentaro_ has joined #openstack-ironic | 06:22 | |
| *** coolsvap is now known as coolsvap|afk | 06:24 | |
| *** k4n0 has quit IRC | 06:27 | |
| *** coolsvap|afk is now known as coolsvap | 06:28 | |
| *** k4n0 has joined #openstack-ironic | 06:39 | |
| *** Mikhail_D_ltp has quit IRC | 06:46 | |
| *** sysexit has joined #openstack-ironic | 06:51 | |
| *** ifarkas has joined #openstack-ironic | 06:53 | |
| *** eguz has joined #openstack-ironic | 06:59 | |
| *** yfujioka has quit IRC | 07:03 | |
| *** eghobo has quit IRC | 07:03 | |
| *** max_lobur has joined #openstack-ironic | 07:05 | |
| *** eguz has quit IRC | 07:05 | |
| *** openstackgerrit has quit IRC | 07:10 | |
| *** Nisha has quit IRC | 07:15 | |
| *** romcheg has joined #openstack-ironic | 07:16 | |
| *** max_lobur has quit IRC | 07:17 | |
| *** jcoufal has joined #openstack-ironic | 07:21 | |
| *** viktors|afk is now known as viktors | 07:30 | |
| *** Manishanker has joined #openstack-ironic | 07:38 | |
| *** achanda has quit IRC | 07:40 | |
| *** mrda is now known as mrda-away | 07:40 | |
| mrda-away | Night ironic... | 07:41 |
| *** foexle has joined #openstack-ironic | 07:42 | |
| Haomeng | mrda-away: night:) | 07:45 |
| comstud | for those awake... | 07:51 |
| comstud | https://review.openstack.org/#/c/89223/ | 07:51 |
| comstud | need one more +2 on that | 07:52 |
| comstud | would be nice to land it before I have more conflicts in the tests | 07:52 |
| romcheg | Morning all! | 07:52 |
| comstud | 2 month old review :-/ although I did let it sit for a while.. and gate issues n all | 07:52 |
| comstud | oh, i guess it has 2 +2's now | 07:53 |
| comstud | just need someone to approve | 07:53 |
| comstud | romcheg: hi and goodnight :) | 07:54 |
| comstud | bed time for me | 07:54 |
| romcheg | Bye comstud! | 07:54 |
| * comstud & poof | 07:54 | |
| Haomeng | comstud: :) | 08:06 |
| Haomeng | comstud: LGTM, +2 already:) | 08:07 |
| *** Mikhail_D_ltp has joined #openstack-ironic | 08:09 | |
| *** petertoft has joined #openstack-ironic | 08:10 | |
| romcheg | Oh, 3 +2s | 08:11 |
| romcheg | I will approve it then | 08:11 |
| *** amitpp has quit IRC | 08:12 | |
| *** yuriyz has joined #openstack-ironic | 08:18 | |
| *** dtantsur|afk is now known as dtantsur | 08:24 | |
| dtantsur | Morning Ironic | 08:24 |
| *** romcheg has quit IRC | 08:26 | |
| *** max_lobur has joined #openstack-ironic | 08:30 | |
| *** lucas-dinner has joined #openstack-ironic | 08:32 | |
| *** jcoufal has quit IRC | 08:33 | |
| *** jcoufal has joined #openstack-ironic | 08:34 | |
| *** athomas has joined #openstack-ironic | 08:34 | |
| foexle | Morning dtantsur :) | 08:39 |
| dtantsur | foexle, morning :) | 08:39 |
| *** martyntaylor has joined #openstack-ironic | 08:42 | |
| *** martyntaylor has quit IRC | 08:46 | |
| dtantsur | core folks, please have a look at https://review.openstack.org/#/c/90126/ | 08:48 |
| dtantsur | 1x +2 already, should be relatively easy to review | 08:48 |
| *** martyntaylor has joined #openstack-ironic | 08:50 | |
| *** romcheg has joined #openstack-ironic | 08:52 | |
| *** sysexit has quit IRC | 08:55 | |
| rameshg87 | good morning dtantsur, | 08:55 |
| rameshg87 | dtantsur, need your input on this review https://review.openstack.org/#/c/100734/4/ironic/common/tftp.py | 08:55 |
| rameshg87 | dtantsur, i feel image_cache can be moved to ironic.common with this review, what's your thought on that ? | 08:56 |
| romcheg | g'morning dtantsur rameshg87 and everyone else! | 08:57 |
| dtantsur | rameshg87, morning :) 100% agree, left a comment | 08:57 |
| dtantsur | romcheg, morning as well :) want easy target to review/maybe approve? ;) https://review.openstack.org/#/c/90126/ | 08:58 |
| *** sysexit has joined #openstack-ironic | 08:58 | |
| * romcheg is looking | 08:59 | |
| romcheg | Oh, that was the problem I raised :) | 08:59 |
| rameshg87 | thanks dtantsur | 09:08 |
| *** pelix has joined #openstack-ironic | 09:16 | |
| foexle | hey guys, is there needed by Ironic to disable the neutron dhcp too? Like baremetal drivers ? | 09:32 |
| romcheg | foexle: there should be only one DHCP _in the baremetal network_ as far as I remember | 09:33 |
| foexle | romcheg: of course but => https://wiki.openstack.org/wiki/GeneralBareMetalProvisioningFramework#Services [..]"This means that you must disable neutron-dhcp"[..] | 09:35 |
| foexle | is that problem still exists ? | 09:36 |
| *** Manishanker has quit IRC | 09:37 | |
| romcheg | foexle: you can setup a separate network for that | 09:40 |
| *** bmahalakshmi has quit IRC | 09:41 | |
| romcheg | а у меня не отменились :() | 09:41 |
| dtantsur | :) | 09:41 |
| *** amitpp has joined #openstack-ironic | 09:41 | |
| romcheg | whops, wrong window! | 09:41 |
| romcheg | sorry | 09:41 |
| dtantsur | romcheg, now folks will suspect you of using especially dirty Russian words here :D | 09:42 |
| yuriyz | romcheg lol | 09:42 |
| *** bmahalakshmi has joined #openstack-ironic | 09:43 | |
| yuriyz | morning all | 09:43 |
| viktors | romcheg: why not ukrainian? ) | 09:43 |
| romcheg | viktors: I was about to write a message to a Russian team :) | 09:44 |
| romcheg | dtantsur: I think the whole world now knows one dirty Russian word. It became popular in Western press about a week ago :) | 09:44 |
| dtantsur | LOL | 09:45 |
| romcheg | http://www.theguardian.com/world/2014/jun/15/ukraine-minister-deshchytsia-abusive-putin-russia | 09:46 |
| dtantsur | yuriyz, morning | 09:46 |
| *** openstackgerrit has joined #openstack-ironic | 09:47 | |
| *** dtantsur is now known as dtantsur|lunch | 09:50 | |
| *** romcheg has quit IRC | 10:02 | |
| *** sysexit has quit IRC | 10:04 | |
| openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Do not delete pxe_deploy_{kernel, ramdisk} on tear down https://review.openstack.org/101864 | 10:06 |
| *** athomas has quit IRC | 10:14 | |
| *** nosnos has quit IRC | 10:19 | |
| *** nosnos has joined #openstack-ironic | 10:19 | |
| *** athomas has joined #openstack-ironic | 10:23 | |
| *** matsuhashi has quit IRC | 10:23 | |
| *** matsuhashi has joined #openstack-ironic | 10:24 | |
| *** nosnos has quit IRC | 10:24 | |
| *** amitpp has quit IRC | 10:24 | |
| *** matsuhashi has quit IRC | 10:28 | |
| openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Implement security groups and firewall filtering methods https://review.openstack.org/96466 | 10:30 |
| openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Add/Update docstrings in the Nova Ironic Driver https://review.openstack.org/97536 | 10:30 |
| lucas-dinner | morning all :) | 10:32 |
| *** lucas-dinner is now known as lucasagomes | 10:32 | |
| lucasagomes | too early for dinner :D | 10:32 |
| openstackgerrit | Ramakrishnan G proposed a change to openstack/ironic-specs: iLO Virtual Media Deploy Driver https://review.openstack.org/97744 | 10:40 |
| *** sysexit has joined #openstack-ironic | 10:41 | |
| openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Add the remaining unittests to the ClientWrapper class https://review.openstack.org/92416 | 10:53 |
| *** sysexit has quit IRC | 10:54 | |
| *** romcheg has joined #openstack-ironic | 10:59 | |
| openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Do not delete pxe_deploy_{kernel, ramdisk} on tear down https://review.openstack.org/101864 | 11:00 |
| openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Add set_on_error_hook to TaskManager https://review.openstack.org/100957 | 11:08 |
| openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Fix nodes left in an incosistent state if no workers https://review.openstack.org/100958 | 11:08 |
| *** lucasagomes is now known as lucas-hungry | 11:19 | |
| *** bmahalakshmi has quit IRC | 11:26 | |
| *** coolsvap is now known as coolsvap|afk | 11:27 | |
| *** k4n0 has quit IRC | 11:28 | |
| *** bmahalakshmi has joined #openstack-ironic | 11:29 | |
| *** takadayuiko has joined #openstack-ironic | 11:43 | |
| *** bmahalakshmi has quit IRC | 11:43 | |
| *** bmahalakshmi has joined #openstack-ironic | 11:44 | |
| openstackgerrit | Mike Heald proposed a change to openstack/ironic-python-agent: Converted documentation in md format to rst. https://review.openstack.org/102196 | 11:47 |
| takadayuiko | Using Ironic succeed :D | 11:47 |
| *** igordcard has joined #openstack-ironic | 11:53 | |
| *** saripurigopi has quit IRC | 11:58 | |
| *** rakesh_hs4 has quit IRC | 12:01 | |
| *** jdob has joined #openstack-ironic | 12:01 | |
| *** vinbs has quit IRC | 12:09 | |
| *** dtantsur|lunch is now known as dtantsur | 12:20 | |
| * Shrews waves good morning from behind his breakfast smoothie | 12:20 | |
| dtantsur | Shrews, morning :) | 12:20 |
| *** bmahalakshmi has quit IRC | 12:21 | |
| *** lucas-hungry is now known as lucasagomes | 12:23 | |
| openstackgerrit | Mike Heald proposed a change to openstack/ironic-python-agent: Converted documentation in md format to rst https://review.openstack.org/102196 | 12:24 |
| rameshg87 | dtantsur, request you to take a look at these reviews: https://review.openstack.org/#/c/101765/ (bash completion support) and https://review.openstack.org/#/c/101297/ (vendor passthru support in cli) :-) | 12:25 |
| rameshg87 | dtantsur, they are small but i think it will be useful | 12:26 |
| dtantsur | rameshg87, they're on my list, but I'm short of time for now, sorry :( | 12:26 |
| rameshg87 | dtantsur, okay :-) | 12:27 |
| dtantsur | Folks, do we _ever_ change Node uuid after it was created? If not, I'm going to prevent this behavior on a DB level as part of DB exceptions clean-up | 12:30 |
| dtantsur | the same question goes for Chassis. I see that for Ports we allow (implicitly) changing UUID, but that may be by chance | 12:32 |
| dtantsur | viktors, around? Maybe you know ^^^ ? | 12:38 |
| Shrews | dtantsur: afaict, generate_uuid() is used to create the uuid, and that's only called when the node is created. so i think it's safe to say it never changes | 12:38 |
| Shrews | and it doesn't make sense for it to change | 12:38 |
| dtantsur | Shrews, I see, thank you. Maybe you know why we allow to change Port UUID? | 12:39 |
| Shrews | we do? :) no idea | 12:39 |
| viktors | dtantsur: sorry, I'm not familiar with it | 12:39 |
| dtantsur | Shrews, my bad, we don't :) And I'm going to explicitly forbid it in DB code | 12:42 |
| dtantsur | Shrews, but we have a test on changing Chassis UUID Oo | 12:45 |
| dtantsur | romcheg, lucasagomes any ideas on all this ^^^ ? | 12:45 |
| dtantsur | I feel like preventing changing UUID's, as it may break a lot of things in an interesting fashion... | 12:45 |
| romcheg | dtantsur: ++ | 12:46 |
| romcheg | But please file a bug first | 12:46 |
| dtantsur | romcheg, sure :) and seem like I need a separate patch for this | 12:46 |
| lucasagomes | dtantsur, so it's possible right now, but idk if anybody uses it actually | 12:46 |
| lucasagomes | dtantsur, there's a bug opened for it? Also if you do, you also need to prevent it in the API https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/node.py#L48 | 12:48 |
| lucasagomes | (for nodes, chassis and ports) | 12:48 |
| dtantsur | lucasagomes, if I raise InvalidParamaterValue on db level, that would solve it for API level as well, right? | 12:48 |
| romcheg | I also think that the appropriate changes to the docs should land first | 12:48 |
| romcheg | So no one would start using that | 12:49 |
| lucasagomes | dtantsur, it will, but the check for internal attributes might give a more useful error message | 12:49 |
| lucasagomes | romcheg, can't they land all together?! | 12:49 |
| dtantsur | lucasagomes, romcheg, I tested: API level explicitly forbid it, so problem is only internal | 12:50 |
| lucasagomes | if you update the docs first, and ppl try it and it works | 12:50 |
| lucasagomes | that's incosistent as well | 12:50 |
| romcheg | lucasagomes: agee | 12:50 |
| *** ajc_ has quit IRC | 12:50 | |
| romcheg | agree even | 12:50 |
| dtantsur | https://bugs.launchpad.net/ironic/+bug/1333683 | 12:52 |
| dtantsur | your opinion? | 12:52 |
| Shrews | dtantsur: how will you enforce it at the db level? | 12:53 |
| *** linggao has joined #openstack-ironic | 12:53 | |
| dtantsur | Shrews, raise error, if 'uuid' field is in 'value' dict | 12:53 |
| Shrews | oh, i don't consider that "db level". that's more db api level | 12:54 |
| *** rameshg87 has left #openstack-ironic | 12:58 | |
| *** rloo has joined #openstack-ironic | 12:58 | |
| *** sseago has quit IRC | 12:59 | |
| *** sseago_ has joined #openstack-ironic | 12:59 | |
| dtantsur | Shrews, fixed | 13:01 |
| *** rloo has quit IRC | 13:02 | |
| Shrews | ++ | 13:02 |
| *** rloo has joined #openstack-ironic | 13:02 | |
| romcheg | dtantsur: I would make it shorter: DB-API allows changing UUID for Nodes, Chassis and Ports | 13:02 |
| dtantsur | romcheg, fixed, thnx | 13:07 |
| *** lazy_prince has quit IRC | 13:13 | |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Add ironic-python-agent deploy driver https://review.openstack.org/101020 | 13:18 |
| *** sseago__ has joined #openstack-ironic | 13:20 | |
| *** sseago_ has quit IRC | 13:20 | |
| jroll | morning y'all | 13:20 |
| jroll | the agent driver is ready to start accepting reviews... I think there's some tests missing but would love to get feedback anyway: https://review.openstack.org/#/c/101020/ | 13:21 |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Fix leaking DB details to API on error https://review.openstack.org/73121 | 13:25 |
| dtantsur | morning, jroll | 13:25 |
| romcheg | Good morning jroll! | 13:26 |
| dtantsur | great news \o/ will look | 13:26 |
| romcheg | jroll: w00t! | 13:26 |
| *** matty_dubs|gone is now known as matty_dubs | 13:30 | |
| *** Mikhail_D_ltp has quit IRC | 13:31 | |
| jroll | morning dtantsur and romcheg :) | 13:32 |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic-specs: Add deploy driver for ironic-python-agent https://review.openstack.org/98506 | 13:43 |
| jroll | dtantsur, mrda-away: responded to and fixed your comments ^ | 13:44 |
| NobodyCam | good morning Ironic | 13:49 |
| jroll | morning NobodyCam! | 13:49 |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic-python-agent: Better errors for execute() failures https://review.openstack.org/99666 | 13:51 |
| NobodyCam | morning jroll | 13:51 |
| jroll | dtantsur: also finally fixed that nit on https://review.openstack.org/#/c/99666, pls to +2 :) | 13:51 |
| romcheg | Morning NobodyCam! | 13:55 |
| NobodyCam | morning romcheg | 13:55 |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Factor out TFTPImageCache https://review.openstack.org/100734 | 14:03 |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Factor out deploy info from PXE driver https://review.openstack.org/100735 | 14:03 |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Add ironic-python-agent deploy driver https://review.openstack.org/101020 | 14:03 |
| dtantsur | NobodyCam, morning! | 14:03 |
| dtantsur | jroll, sure, will have a look | 14:03 |
| jroll | thanks :) | 14:03 |
| NobodyCam | good morning dtantsur | 14:09 |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Fix leaking DB details to API on error https://review.openstack.org/73121 | 14:11 |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Prevent updating UUID of Node, Port and Chassis on DB API level https://review.openstack.org/102247 | 14:13 |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Prevent updating UUID of Node, Port and Chassis on DB API level https://review.openstack.org/102247 | 14:15 |
| *** killer_prince has joined #openstack-ironic | 14:33 | |
| NobodyCam | hummmm corp travel site is saying the hotel is not approved | 14:33 |
| NobodyCam | :( | 14:33 |
| jroll | just book outside of the system :) | 14:34 |
| jroll | what hotel is everyone staying at, anyway? | 14:34 |
| matty_dubs | I just got like 10 emails that Implement API to get driver properties cannot me merged | 14:34 |
| matty_dubs | They are still coming | 14:34 |
| *** jbjohnso has joined #openstack-ironic | 14:35 | |
| NobodyCam | https://wiki.openstack.org/wiki/Sprints/BeavertonJunoSprint | 14:35 |
| jroll | oh, cool | 14:36 |
| rloo | matty_dubs: sorry and thx for the warning. All I did was -2 it. Ouch, more are showing up. | 14:36 |
| jroll | thanks :) | 14:36 |
| jroll | rloo: "all I did" | 14:36 |
| matty_dubs | rloo: Yeah, I'm not sure what's going on, but it's crazy. ;) | 14:36 |
| matty_dubs | rloo: That will teach you to -2 patches! ;) | 14:36 |
| rloo | matty_dubs: i wonder if i triggered some sort of bug. | 14:36 |
| rloo | matty_dubs: yeah, maybe I shouldn't -2 my own patches. I wonder if that was it. Or if it is cuz there is an X for work-in-progress. | 14:37 |
| NobodyCam | morning rloo :) | 14:37 |
| rloo | morning NobodyCam! | 14:37 |
| NobodyCam | and matty_dubs too | 14:37 |
| matty_dubs | Morning NobodyCam (et al.) | 14:37 |
| romcheg | Guys, is Jenkins crazy right now or am I crazy right now? | 14:39 |
| *** killer_prince has quit IRC | 14:40 | |
| rloo | romcheg: It is just the one patch that Jenkins isn't happy with. I'm not sure why, but it started when I -2'd the patch. | 14:40 |
| rloo | romcheg: I just undid the -2. Hopefully that 'fixes' it. I'll just remember not to merge that patch ;) | 14:40 |
| romcheg | rloo: Thanks! | 14:41 |
| rloo | romcheg: that's what you all get for not approving my patch in Icehouse :-( | 14:42 |
| romcheg | rloo: I think it's better to talk to Infra guys | 14:42 |
| rloo | romcheg: ok. | 14:42 |
| *** killer_prince has joined #openstack-ironic | 14:44 | |
| romcheg | I keep receiving emails | 14:44 |
| matty_dubs | Me too | 14:45 |
| matty_dubs | On the bright side, I feel so popular now. ;) | 14:45 |
| rloo | romcheg, matty_dubs: sorry, I don't know how to stop it. I asked in infra, but not sure if anyone is there. | 14:45 |
| romcheg | rloo: Don't blame yourself | 14:46 |
| rloo | romcheg, matty_dubs: let me know if you have any ideas. Can I delete a patch? | 14:46 |
| romcheg | rloo: you can abandon it | 14:46 |
| rloo | romcheg: ok, I just abandon'd it. Lets see if that stops it. | 14:47 |
| jroll | this is why I filter jenkins emails ;) | 14:47 |
| romcheg | looks like it helped | 14:48 |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Fix leaking DB details to API on error https://review.openstack.org/73121 | 14:48 |
| *** foexle has quit IRC | 14:48 | |
| matty_dubs | Yay! | 14:49 |
| rloo | romcheg, matty_dubs: yeah. | 14:49 |
| matty_dubs | Heh, Ctrl+D to delete the thread. mutt asks: "Purge 220 deleted messages? ([yes]/no)" | 14:51 |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Fix leaking DB details to API on error https://review.openstack.org/73121 | 14:53 |
| *** achanda has joined #openstack-ironic | 14:55 | |
| dtantsur | ok, folks, you succeeded in opening gates to hell :D | 14:58 |
| rloo | dtantsur: ? which folks? | 14:59 |
| dtantsur | rloo, for example you :) I mean the infinite stream of Jenkins unhappyness | 15:00 |
| rloo | dtantsur: ha ha. Sorry, only the people that had reviewed my patch are in the club -- that's what the gate opened ;) | 15:00 |
| rloo | dtantsur: No worries. You only got 220 msgs. And who knows, maybe I've revealed a bug in infra! | 15:01 |
| *** rloo has quit IRC | 15:03 | |
| *** rloo has joined #openstack-ironic | 15:04 | |
| *** mdorman has joined #openstack-ironic | 15:06 | |
| *** achanda has quit IRC | 15:06 | |
| *** rloo has quit IRC | 15:07 | |
| *** rloo has joined #openstack-ironic | 15:08 | |
| *** rloo has quit IRC | 15:08 | |
| *** rloo has joined #openstack-ironic | 15:09 | |
| *** jcoufal has quit IRC | 15:11 | |
| rloo | lucasagomes, jroll: wrt the instance_info attribute. Just reading the spec. It isn't clear to me. How do you set eg 'root_gb'? if i do a 'nova node-create ... -i root_gb=10, it shows up in driver_info. | 15:21 |
| jroll | rloo: so uh, idk what the plans are to update the cli | 15:21 |
| rloo | jroll: ok, will check with lucasagomes. I didn't read the spec before it was approved; seems like it should have been mentioned there | 15:22 |
| jroll | it may have been | 15:22 |
| rloo | jroll: at some point, I think lucasagomes was thinking of writing specs against python-ironicclient so maybe it fell through this crack. | 15:23 |
| jroll | hmm | 15:24 |
| jroll | yeah, my memory is bad on this one | 15:24 |
| rloo | jroll: no worries. your name was on the spec, so thought i'd ping you too :-) | 15:24 |
| jroll | no problem :) | 15:24 |
| *** vinbs has joined #openstack-ironic | 15:25 | |
| lucasagomes | rloo, it's part of the flavor | 15:25 |
| rloo | lucasagomes: so are you saying that there's no API to set any of the instance_info? | 15:26 |
| lucasagomes | rloo, in case ur deploying a node w/o nova, you can set it -i instance_info/root_gb=10 | 15:26 |
| lucasagomes | rloo, there's | 15:26 |
| *** vinbs_ has joined #openstack-ironic | 15:26 | |
| lucasagomes | rloo, but there's no change on that part, we are very flexible when it comes to update attributes in our resources | 15:26 |
| lucasagomes | rloo, we use json-patch | 15:27 |
| rloo | lucasagomes: so if you do -i root_gb, it adds to driver_info? You have to specify 'instance_info/'? | 15:27 |
| lucasagomes | {'op': 'add', 'path': 'instance_info/root_gb', value='10} for e.g | 15:27 |
| lucasagomes | rloo, oh it goes to the driver info!? | 15:27 |
| lucasagomes | rloo, damn ok, so we might have to change the cli | 15:27 |
| rloo | lucasagomes: if I just do -i root_gb. | 15:27 |
| lucasagomes | rloo, right it might be some logic in the cli then | 15:28 |
| lucasagomes | :( | 15:28 |
| lucasagomes | rloo, mind opnining a bug for it? | 15:28 |
| NobodyCam | morning lucasagomes | 15:28 |
| lucasagomes | NobodyCam, morning | 15:28 |
| NobodyCam | :) | 15:28 |
| rloo | lucasagomes: no worries. i can open a bug. What do you think it should do? have to explicitly specify -i driver_info/xxx? | 15:28 |
| rloo | lucasagomes: well, i'll just open a bug :-) | 15:29 |
| lucasagomes | rloo, yeah... you still can do a node-update <node> add instance_info/root_gb=10 | 15:29 |
| lucasagomes | rloo, the -i is for node-create? | 15:29 |
| rloo | lucasagomes: yeah, -i is for node-create | 15:29 |
| lucasagomes | right | 15:29 |
| lucasagomes | so hmmm should we pass instance_info when creating a node? | 15:29 |
| *** vinbs has quit IRC | 15:30 | |
| lucasagomes | well perhaps we should allow you to create a node with all the values u already want | 15:30 |
| rloo | lucasagomes: I don't see why we would restrict it so you can't? | 15:30 |
| lucasagomes | rloo, no | 15:30 |
| lucasagomes | u want already* | 15:30 |
| lucasagomes | jroll, you guys are using iPXE internally am I right? | 15:31 |
| jroll | yes sir | 15:31 |
| lucasagomes | jroll, lemme ask, u guys are not using neutron for dhcp right? | 15:31 |
| jroll | with an external dhcp server | 15:31 |
| jroll | right | 15:31 |
| jroll | we use isc-dhcp-server | 15:31 |
| lucasagomes | a-ha! | 15:31 |
| *** rloo has quit IRC | 15:31 | |
| *** coolsvap|afk is now known as coolsvap | 15:31 | |
| lucasagomes | jroll, right, yeah I was setting my env to do iPXE instead of gPXE | 15:31 |
| jroll | lucasagomes: did you see this? :) http://developer.rackspace.com/blog/how-we-run-ironic-and-you-can-too.html | 15:31 |
| *** rloo has joined #openstack-ironic | 15:32 | |
| lucasagomes | and as neutron uses dnsmasq, I will have to update neutron as part of the spec as well :( | 15:32 |
| jroll | lucasagomes: oh lord | 15:32 |
| lucasagomes | to make it add a ipxe tag for the dhcp | 15:32 |
| *** max_lobur has quit IRC | 15:32 | |
| lucasagomes | :( | 15:32 |
| * lucasagomes feels sad | 15:32 | |
| jroll | I'm so sorry | 15:32 |
| jroll | :P | 15:32 |
| lucasagomes | jroll, will check it out! | 15:32 |
| NobodyCam | lol I like step #4 | 15:32 |
| lucasagomes | jroll, and congrats on the onmetal! pretty cool man | 15:32 |
| rloo | lucasagomes: don't be sad. be happy you noticed it now :-) | 15:32 |
| jroll | lucasagomes: I just got an email from your recruiters :P | 15:32 |
| jroll | ha thanks, it's a journey :) | 15:32 |
| *** vinbs_ has quit IRC | 15:33 | |
| lucasagomes | jroll, hah come to the dark side | 15:33 |
| lucasagomes | :D | 15:33 |
| jroll | :P | 15:33 |
| dtantsur | lucasagomes, what do you think about having a generic spec covering what should be changed for discovery, no matter which ramdisk is used? If you don't have time, I can try (based on your etherpad). | 15:33 |
| dtantsur | jroll, interested for you as well ^^^ | 15:34 |
| jroll | NobodyCam: heh, the bugs are usually, "uh oh, cherry-picking patches from gerrit failed loudly" | 15:34 |
| jroll | dtantsur: isn't that the point of Nisha's spec? | 15:34 |
| NobodyCam | :) | 15:34 |
| * jroll still needs to review that | 15:34 | |
| lucasagomes | dtantsur, hmm right, idk if that will be very well accepted upstream tho | 15:35 |
| lucasagomes | dtantsur, loads of insecurity | 15:35 |
| jroll | well | 15:35 |
| jroll | I see it more of specifying the APIs etc | 15:35 |
| dtantsur | lucasagomes, I mean, generic one. With skipping details, that can't be solved now | 15:35 |
| jroll | prescribing that auth be done with something transferred out of band | 15:35 |
| jroll | that kind of thing | 15:35 |
| dtantsur | jroll, Nisha's is about discovery on manual adding, I'm interested in auto-discovery. Of course there's a lot in common. | 15:36 |
| jroll | dtantsur: ah, yes | 15:36 |
| lucasagomes | dtantsur, right, well if u want to do the first stab | 15:37 |
| jroll | ^ | 15:37 |
| * jroll helps lucas throw dtantsur under that bus :P | 15:37 | |
| dtantsur | so nice of you, guys :) | 15:37 |
| lucasagomes | dtantsur, we can add multiple authors | 15:37 |
| lucasagomes | dtantsur, I can help a bit with the spec code as well | 15:38 |
| lucasagomes | let's add jroll too | 15:38 |
| lucasagomes | :) | 15:38 |
| jroll | gah | 15:38 |
| * jroll runs | 15:38 | |
| dtantsur | lucasagomes, cool! My point is to create and approve some basis for all future discovery work | 15:38 |
| jroll | I'll help if I can | 15:38 |
| lucasagomes | dtantsur, right, let's start tossing those first on the etherpad | 15:38 |
| dtantsur | we can try to agree on vendor endpoints/neutron/whatever | 15:38 |
| lucasagomes | dtantsur, +1 | 15:39 |
| jroll | sounds good to me | 15:43 |
| jroll | heading to the office, bbiab | 15:44 |
| linggao | Hi anteaya | 15:44 |
| NobodyCam | morning linggao | 15:45 |
| linggao | good morning NobodyCam. Had your dose of coffee? | 15:46 |
| NobodyCam | oh ya :) | 15:46 |
| *** viktors is now known as viktors|afk | 15:46 | |
| *** kylers has joined #openstack-ironic | 15:46 | |
| linggao | NobodyCam, we are setting up third party CI for Ironic to test ipminative driver. | 15:46 |
| NobodyCam | linggao: w00t!!!1 | 15:47 |
| anteaya | linggao: hello | 15:47 |
| NobodyCam | morning anteaya :) | 15:47 |
| linggao | anteaya, where do we find Ironic tempest scripts for Ironic? | 15:47 |
| anteaya | morning NobodyCam | 15:47 |
| anteaya | linggao: that is a good question for the -qa channel I do believe, if noone in ironic knows | 15:48 |
| Shrews | linggao: in the tempest repo :) | 15:48 |
| anteaya | since i do not know the answer to that | 15:48 |
| dtantsur | lucasagomes, starting dumping my thoughts on what to cover | 15:48 |
| Shrews | linggao: start with this: http://docs.openstack.org/developer/tempest/ | 15:49 |
| Shrews | linggao: api tests and scenario tests are in different subdirectories | 15:49 |
| Shrews | git://git.openstack.org/openstack/tempest.git | 15:50 |
| linggao | Shrews, we'd like to test ironic with real hardware. | 15:50 |
| Shrews | ++ | 15:50 |
| linggao | Shrews, anteaya, those tempest are for use with third party CI, correct? | 15:51 |
| linggao | with->by | 15:51 |
| Shrews | linggao: i'm not 100% sure if 3rd parties use it, but i don't see why they can't. devstack-gate definitely uses it, though | 15:52 |
| anteaya | running the tempest test suite is a good place to begin | 15:52 |
| jroll | linggao: third-party CI can run any code you wish it to. it just looks for gerrit events, acts on them, and posts a comment | 15:52 |
| lucasagomes | dtantsur, will take a look | 15:53 |
| jroll | tempest is a good start | 15:53 |
| anteaya | linggao: attending the third party meetings will be helpful: https://wiki.openstack.org/wiki/Meetings/ThirdParty | 15:53 |
| jroll | dtantsur: where is this etherpad? | 15:53 |
| anteaya | linggao: also reading the meeting logs | 15:53 |
| *** eghobo has joined #openstack-ironic | 15:53 | |
| *** eghobo has quit IRC | 15:53 | |
| anteaya | linggao: reading this page: http://ci.openstack.org/third_party.html | 15:53 |
| linggao | anteaya, yes. someone else in our team sets it up. But he cannot attend the meeting because of the time zoon | 15:54 |
| dtantsur | jroll, https://etherpad.openstack.org/p/IronicDownstreamDiscoveryRamdisk (only 1st part is of interest) | 15:54 |
| jroll | cool, thanks | 15:54 |
| * jroll really goes to the office now | 15:54 | |
| anteaya | as well as the patches to it: https://review.openstack.org/#/c/101013/ and https://review.openstack.org/#/c/101227/ | 15:54 |
| linggao | anteaya, I wil try to attend. You have gave me all the info about the meeting before. | 15:54 |
| anteaya | linggao: great, that would be a big help to both of us I think | 15:55 |
| *** eghobo has joined #openstack-ironic | 15:55 | |
| linggao | anteaya, :) | 15:55 |
| anteaya | :D | 15:56 |
| linggao | NobodyCam, anteaya, Shrews, jroll, thanks for the info. We have got the basic setup. Just need to learn how to test Ironic. https://review.openstack.org/#/c/102121/ | 15:56 |
| linggao | There is a "IBM xCAT CI", that's us. | 15:57 |
| Shrews | linggao: currently, the tempest ironic tests don't do very much. more are being added (example: https://review.openstack.org/94439) | 15:57 |
| *** hemna_ has joined #openstack-ironic | 15:58 | |
| NobodyCam | bbt brb | 15:58 |
| Shrews | and https://etherpad.openstack.org/p/IronicTempestFeatures | 15:58 |
| linggao | Shrews, this new patch still use the vm to do the tests, right? | 15:59 |
| Shrews | linggao: in devstack-gate, yes. but that is setup independently from tempest itself | 16:00 |
| Shrews | tempest doesn't care | 16:00 |
| linggao | Shrews, I see. | 16:01 |
| *** eghobo has quit IRC | 16:01 | |
| *** eghobo has joined #openstack-ironic | 16:01 | |
| linggao | Shrews, so devstack-gate set up the system when new patches are in and tempest test it? | 16:01 |
| Shrews | linggao: yes | 16:02 |
| linggao | where can I find devstack-gate? | 16:03 |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Fix leaking DB details to API on error https://review.openstack.org/73121 | 16:03 |
| Shrews | linggao: devstack-gate just uses devstack (thus the name) which sets up the vm's and tempest | 16:04 |
| linggao | Shrews, oh, so we need to write a script to use devstack to setup the node and run temest. | 16:06 |
| *** martyntaylor has quit IRC | 16:06 | |
| Shrews | linggao: no, you don't HAVE to use devstack. it just conveniently bundles tempest. tempest can run independently | 16:06 |
| *** martyntaylor has joined #openstack-ironic | 16:07 | |
| linggao | Shrews, thanks a lot for the info. | 16:08 |
| Shrews | sure, no problem | 16:09 |
| *** martyntaylor has quit IRC | 16:11 | |
| Shrews | matty_dubs: rloo: which review had the jenkins comment problem? | 16:12 |
| *** bandicot has joined #openstack-ironic | 16:12 | |
| devananda | morning, all! | 16:12 |
| dtantsur | devananda, morning | 16:12 |
| rloo | Shrews: https://review.openstack.org/#/c/73005/ | 16:12 |
| *** vinbs has joined #openstack-ironic | 16:12 | |
| rloo | morning devananda! | 16:12 |
| rloo | Shrews: i just looked on -infra. Now I know why you asked. Yes, it was me. | 16:13 |
| Shrews | rloo: :) | 16:14 |
| *** vinbs_ has joined #openstack-ironic | 16:14 | |
| *** vinbs has quit IRC | 16:14 | |
| *** vinbs_ is now known as vinbs | 16:15 | |
| jroll | heya devananda | 16:15 |
| * devananda reads all the scrollback | 16:16 | |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Prevent updating UUID of Node, Port and Chassis on DB API level https://review.openstack.org/102247 | 16:16 |
| * dtantsur back in 1 hour | 16:16 | |
| *** dtantsur is now known as dtantsur|afk | 16:16 | |
| * devananda notices someone was asking a question based on https://wiki.openstack.org/wiki/GeneralBareMetalProvisioningFramework | 16:16 | |
| devananda | maybe we should make it mroe clear that that no longer appleis | 16:16 |
| *** ellenh has joined #openstack-ironic | 16:17 | |
| rloo | devananda: well, it does apply, but for the old baremetal stuff, not for ironic. Yes, it should be made clear. | 16:18 |
| NobodyCam | good morning devananda | 16:18 |
| devananda | takadayuiko: hi! glad to hear Ironic succeeded - would you care to share any details of what you are doing? | 16:18 |
| devananda | dtantsur|afk: the UUID of a resource shouldn't be allowed to change, but the reference between two resources can change, eg. changing nodes.chassis_uuid is fine because that represents movnig a node to a new chassis | 16:20 |
| lucasagomes | devananda, morning | 16:20 |
| *** jbjohnso has quit IRC | 16:22 | |
| devananda | rloo: um, we should not pass instance_info when creating a node | 16:23 |
| rloo | devananda: ok, but we used to have the ability to pass eg 'pxe_root_gb'. | 16:24 |
| rloo | devananda: so we can update the node with instance_info? | 16:24 |
| devananda | rloo: hmm, while possible, that would have been illogical | 16:24 |
| devananda | rloo: root/swap/ephemeral sizes only have effect in the context of deploying an instance | 16:25 |
| rloo | devananda: do we need to document that you can't do that anymore (or ignore that it was possible at all) | 16:25 |
| devananda | rloo: definitely worth noting in the CLI's changelog | 16:28 |
| *** martyntaylor has joined #openstack-ironic | 16:31 | |
| *** martyntaylor has left #openstack-ironic | 16:32 | |
| rloo | devananda: how to add to CLI's changelog? When you tag the package, you generate the info from the logs, but there's no code change associated with this. | 16:32 |
| *** yjiang5 is now known as yjiang5_away | 16:33 | |
| devananda | rloo: the release notes / changelog isn't auto-generated | 16:36 |
| devananda | rloo: so i can add a line there. is there a bug or commit which should be referenced? | 16:37 |
| rloo | devananda: there are a bunch of commits wrt the instance_info stuff. Or do you want the spec/blueprint? | 16:37 |
| rloo | devananda: I suspect this is the one that changed it: https://review.openstack.org/#/c/94855/, since that's the only use of instance_info so far. | 16:39 |
| lucasagomes | devananda, I was thinking about the case where you trigger the deploy via ironic node-set-deploy-state | 16:40 |
| lucasagomes | devananda, so that would make sense to be able to input all the required infos when creating the node | 16:41 |
| lucasagomes | no? | 16:41 |
| devananda | lucasagomes: regarding https://review.openstack.org/#/c/96466/5 - does this do anything? | 16:41 |
| * lucasagomes maybe is going too far | 16:41 | |
| devananda | lucasagomes: yea... i can see the optimization when not using Nova to do deploys ... but ... | 16:41 |
| *** jcoufal has joined #openstack-ironic | 16:41 | |
| lucasagomes | devananda, nova baremetal have those functions implemented, tho, I don't know if that actually does something | 16:42 |
| lucasagomes | not in my env | 16:42 |
| devananda | lucasagomes: OTOH, I think that "create node" semantically should have physical characteristics, whereas root/swap/eph/image_source are logical characteristics of that specific instance | 16:42 |
| devananda | lucasagomes: right. i dont think they do anything, because nova baremetal requires the NoopFirewallDriver | 16:42 |
| lucasagomes | devananda, right, should we just remove those functions instead of implementing it then? | 16:43 |
| devananda | lucasagomes: i think it's fine to add those methods for consistency | 16:43 |
| lucasagomes | devananda, yeah... I think I agree with the node-create | 16:43 |
| devananda | lucasagomes: lemme check. i believe they're required | 16:43 |
| lucasagomes | devananda, ack | 16:43 |
| *** jbjohnso has joined #openstack-ironic | 16:43 | |
| devananda | lucasagomes: yea. they all raise NotImplementedError() in the base class | 16:44 |
| * Shrews changes venue. bbiab | 16:44 | |
| devananda | lucasagomes: that's why I stubbed them with pass() initially - -but your patch is cleaner | 16:44 |
| lucasagomes | devananda, ackd | 16:44 |
| lucasagomes | devananda, btw, I saw that the spec for the nova driver has now a +2 | 16:44 |
| lucasagomes | devananda, maybe we should start priorizing the patches that changes the nova driver | 16:45 |
| devananda | lucasagomes: definitely | 16:45 |
| lucasagomes | to send it to nova asap when the spec get merged | 16:45 |
| devananda | lucasagomes: all the cleanup for nova driver should be getting reviewed asap | 16:45 |
| lucasagomes | +1 | 16:45 |
| lucasagomes | devananda, https://review.openstack.org/#/c/97536 < add/update the docstrings on the driver (pinging you because having a native speaker to look at it would be good) | 16:47 |
| devananda | lucasagomes: was just looking :) | 16:47 |
| devananda | lucasagomes: also, do you know anyone who likes to write wiki pages and/or documentation? | 16:47 |
| lucasagomes | devananda, hmmmm... who actually likes it, not really | 16:48 |
| lucasagomes | maybe we should try to share some of the doc tasks between cores at least | 16:49 |
| lucasagomes | so everybody helps a little bit | 16:49 |
| devananda | lucasagomes: i'm referring to more than just the inline code docs | 16:49 |
| devananda | things like https://wiki.openstack.org/wiki/Baremetal which I wrote over a year ago | 16:50 |
| devananda | and was reminded this morning, since foexle was asking questions based onthat, that these pages still exist | 16:50 |
| devananda | i should try to find time to rewrite it for ironic ... but would love help | 16:50 |
| *** kylers has quit IRC | 16:51 | |
| *** yjiang5_away is now known as yjiang5 | 16:51 | |
| lucasagomes | devananda, I see hmm, not sure, I will ask internally | 16:52 |
| lucasagomes | devananda, maybe the guy writting those: https://review.openstack.org/#/c/94604/ ? | 16:52 |
| devananda | lucasagomes: on 97536, there are actually doc strings in the nova base class | 16:52 |
| devananda | lucasagomes: have you looked at those // considered usign them? | 16:52 |
| lucasagomes | devananda, yup I did, some of then are like hypervisorish | 16:53 |
| lucasagomes | so I adapted | 16:53 |
| lucasagomes | them* | 16:53 |
| *** kylers has joined #openstack-ironic | 16:53 | |
| devananda | k, cool | 16:53 |
| *** pelix has quit IRC | 16:54 | |
| *** harlowja_away is now known as harlowja | 16:55 | |
| *** athomas has quit IRC | 16:56 | |
| devananda | lucasagomes: you've changed the function sig for node_is_available | 16:58 |
| lucasagomes | devananda, ew :/ lemme check | 17:00 |
| lucasagomes | devananda, ah, right I changed because that's actually the uuid of the node being passed not the name | 17:00 |
| lucasagomes | so nodename as the name of the parameter makes feel sense, u think it's an unrelated change? | 17:01 |
| lucasagomes | or that we shouldn't change it | 17:01 |
| devananda | i think we shouldn't change it | 17:02 |
| devananda | nodename is the nova term for this. we use "node_id" in Ironic. | 17:02 |
| lucasagomes | devananda, right, the reason why its passing the UUID is because the get_available_nodes is returning a list of uuids | 17:03 |
| lucasagomes | devananda, I will update the patch to not change it | 17:03 |
| devananda | lucasagomes: well. more than that -- nova tracks resources as (host, hypervisor_hostname) | 17:03 |
| devananda | and awkwardly uses "hypervisor_hostname" and "nodename" interchangeably to mean the same property in different parts of the code | 17:04 |
| devananda | yay confusion :) | 17:04 |
| devananda | we've talked about cleaning that up for a year, but really should just remvoe the whole concept from nova | 17:04 |
| lucasagomes | heh yeah, well the description will say it's actually the UUID even tho it's called nodename :) | 17:04 |
| lucasagomes | right | 17:04 |
| devananda | ++ | 17:04 |
| devananda | I've got amny other comments, will post shortly | 17:04 |
| devananda | mostly the rest are wording suggestions that you asked for | 17:05 |
| *** bandicot has quit IRC | 17:06 | |
| lucasagomes | devananda, ack,will wait then before updating the patch | 17:06 |
| *** dtantsur|afk is now known as dtantsur | 17:06 | |
| dtantsur | devananda, of course! I was talking about entity's own UUID, not fkey's | 17:07 |
| devananda | lucasagomes: posted | 17:09 |
| devananda | dtantsur: right :) | 17:09 |
| lucasagomes | devananda, ta much | 17:09 |
| dtantsur | devananda, seen our discussion about generic discovery spec? Your opinion? | 17:12 |
| devananda | lucasagomes: good to tag another CLI release today? | 17:12 |
| devananda | dtantsur: I skimmed it - can you summarize? | 17:12 |
| dtantsur | devananda, my idea is to have a spec with all possible general ideas about discovery, which are independent of particular implementation (IPA, PXE, ILO, ...) | 17:13 |
| *** petertoft has quit IRC | 17:13 | |
| lucasagomes | devananda, think it's fine... there's a requirements update patch there | 17:13 |
| *** romcheg has quit IRC | 17:13 | |
| lucasagomes | maybe we should approve that first | 17:13 |
| dtantsur | devananda, so that we can agree one some small common steps before we dive into particular implementations | 17:13 |
| dtantsur | * one = on | 17:13 |
| devananda | dtantsur: ++ | 17:14 |
| lucasagomes | there's also one that I had forgot (https://review.openstack.org/#/c/91585/) adding pagination support for list commands | 17:14 |
| devananda | lucasagomes: ooh ya. which I had a problem with last time I saw | 17:14 |
| lucasagomes | I need to update that patch, I think it's a bit important because if u had more than 100 nodes (default in Ironic) they won't be listed | 17:14 |
| dtantsur | devananda, cool! lucasagomes, jroll and I will take part in prototyping it, will try to come up with something this week | 17:14 |
| devananda | lucasagomes: right - i agree, important to fix | 17:14 |
| devananda | dtantsur: awesoem, thanks | 17:14 |
| lucasagomes | dtantsur, ack! | 17:15 |
| lucasagomes | devananda, mind waiting to tag it tomorrow? | 17:15 |
| devananda | lucasagomes: nope | 17:15 |
| lucasagomes | I have to rework that patch because of the limit python have on recursive functions | 17:16 |
| NobodyCam | brb | 17:16 |
| lucasagomes | devananda, ack thanks, I will update it tomorrow | 17:16 |
| devananda | lucasagomes: also pls see my comment from may 30 | 17:16 |
| lucasagomes | will do | 17:16 |
| devananda | lucasagomes: i think it needs to introduce new --limit param | 17:16 |
| lucasagomes | devananda, ah that's true haha | 17:17 |
| devananda | lucasagomes: and therefore also a new --offset param, which should accept the UUID of a resource and start the list from that piont | 17:17 |
| lucasagomes | devananda, yeah makes sense, since it's already supported by our api | 17:18 |
| devananda | er, s/--offset/--start-with/ | 17:18 |
| * lucasagomes had totally forgot about the existence of that patch | 17:18 | |
| jroll | dtantsur: hooray for being volunteered :) | 17:18 |
| devananda | lucasagomes: right | 17:18 |
| dtantsur | jroll :D | 17:18 |
| dtantsur | jroll, you'll like it, I promise :) | 17:19 |
| lucasagomes | dtantsur, jroll o/ | 17:19 |
| jroll | dtantsur: let me finish these other 5 specs and I'll get right on it :P | 17:19 |
| dtantsur | ack | 17:19 |
| *** martyntaylor1 has joined #openstack-ironic | 17:21 | |
| lucasagomes | devananda, 2 things on the docstring patch... "List of MAC addresses for the node which this instance is associated with" is too long for the one line docstring, I will remove "addresses" right? | 17:21 |
| lucasagomes | yeah actually only 1 | 17:23 |
| devananda | lucasagomes: sure | 17:24 |
| *** rwsu has joined #openstack-ironic | 17:25 | |
| jroll | devananda: hey, if I get a decent configdrive patch up for the nova driver today, any chance we could prioritize that stuff with the other nova changes? :) | 17:26 |
| jroll | devananda: (caveat, configdrive BP is -1'd, I'll be fixing that up today) | 17:26 |
| devananda | jroll: I'd punt that to the nova team and see if they are willing to take on the additional review overhead when landing the ironic driver | 17:27 |
| devananda | jroll: if they approve the nova spec for it -- then it's quite likely i'll prioritize reviewing it | 17:27 |
| jroll | devananda: thanks, I'll see what I can do | 17:27 |
| openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Add/Update docstrings in the Nova Ironic Driver https://review.openstack.org/97536 | 17:28 |
| *** sirushti has left #openstack-ironic | 17:28 | |
| devananda | jroll: but I dont want that (or anything else) to further complicate or delay landing the ironic driver (cause, y'know, we *all* need that to land....) | 17:28 |
| jroll | of course :) | 17:28 |
| jroll | that's why I'm asking :) | 17:28 |
| devananda | :) | 17:28 |
| *** sirushti has joined #openstack-ironic | 17:28 | |
| jroll | I guess it would get split into a separate patch in the nova review anyway, so | 17:28 |
| lucasagomes | alright folks, I'm done for the day | 17:28 |
| lucasagomes | have a good night everyone! | 17:28 |
| *** bandicot has joined #openstack-ironic | 17:28 | |
| jroll | night lucasagomes | 17:29 |
| devananda | lucasagomes: cheers, g'night! | 17:29 |
| *** lucasagomes is now known as lucas-dinner | 17:29 | |
| NobodyCam | gnight lucas-dinner | 17:29 |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic-specs: Support external DHCP providers https://review.openstack.org/102296 | 17:35 |
| jroll | one down | 17:35 |
| *** openstackgerrit has quit IRC | 17:35 | |
| *** openstackgerrit has joined #openstack-ironic | 17:36 | |
| *** vinbs_ has joined #openstack-ironic | 17:38 | |
| *** achanda has joined #openstack-ironic | 17:38 | |
| *** Manishanker has joined #openstack-ironic | 17:40 | |
| openstackgerrit | Adam Gandelman proposed a change to openstack/ironic-specs: External event callback API https://review.openstack.org/99770 | 17:40 |
| *** vinbs has quit IRC | 17:41 | |
| *** vinbs_ is now known as vinbs | 17:41 | |
| NobodyCam | rameshg8-: are you around? | 17:41 |
| *** yu_ has joined #openstack-ironic | 17:43 | |
| NobodyCam | devananda: may be you know off the topof your head, dose iLo support key based logins? | 17:43 |
| *** vinbs has quit IRC | 17:46 | |
| devananda | NobodyCam: i do not know | 17:46 |
| NobodyCam | :) | 17:46 |
| *** vinbs has joined #openstack-ironic | 17:48 | |
| *** Penick has joined #openstack-ironic | 17:54 | |
| *** jcoufal has quit IRC | 17:56 | |
| *** yjiang5 is now known as yjiang5_away | 17:57 | |
| *** vinbs has quit IRC | 18:00 | |
| NobodyCam | brb | 18:02 |
| *** harlowja has quit IRC | 18:04 | |
| *** harlowja has joined #openstack-ironic | 18:07 | |
| *** harlowja has quit IRC | 18:07 | |
| Shrews | adam_g, devananda: can i get you to vote on https://review.openstack.org/94439 again? otherwise, sean will likely ignore it | 18:09 |
| *** kylers has quit IRC | 18:09 | |
| adam_g | Shrews, sure. | 18:09 |
| Shrews | gracias | 18:09 |
| rloo | JoshNang: I think you're updated https://review.openstack.org/#/c/98904/ was based off of patch set 4, not 5 :-( | 18:10 |
| JoshNang | rloo: oh shoot. | 18:10 |
| JoshNang | one sec | 18:10 |
| openstackgerrit | Josh Gachnang proposed a change to openstack/ironic-specs: Drivers Determine Acceptable Power States https://review.openstack.org/102306 | 18:10 |
| openstackgerrit | Josh Gachnang proposed a change to openstack/ironic-specs: Swift Temporary URLs Spec https://review.openstack.org/98904 | 18:14 |
| JoshNang | rloo: should be fixed :D | 18:14 |
| JoshNang | thanks! | 18:14 |
| NobodyCam | df | 18:16 |
| NobodyCam | doh | 18:16 |
| devananda | Shrews: hi! so those changes LGTM | 18:18 |
| rloo | thx JoshNang | 18:18 |
| Shrews | devananda: hi! and, yay! | 18:19 |
| devananda | Shrews: but now i want to ask you sometjhing else ... you might hate me, though | 18:19 |
| Shrews | oh geez | 18:19 |
| devananda | Shrews: the new test takes ~5 minutes, but it looks like it added ~20 minutes to the run time | 18:19 |
| devananda | Shrews: thoughts on that? | 18:19 |
| devananda | Shrews: also, is compute OK adding the new rebuild option? it should probably get a vote from someone in nova for that, I would think? | 18:20 |
| Shrews | devananda: one thing i had to add was a "wait_for_resources" method that waits until the single ironic node in devstack-gate is released | 18:20 |
| Shrews | devananda: not sure how long that takes, but should be 15 min | 18:20 |
| Shrews | devananda: i haven't asked anyone from nova, but will | 18:21 |
| Shrews | devananda: SHOULDN'T be 15 min... gah | 18:21 |
| devananda | Shrews: right, so if it waits 15 minutes, and the test takes 5, that matches my observation | 18:21 |
| devananda | oh | 18:21 |
| *** martyntaylor1 has left #openstack-ironic | 18:23 | |
| devananda | Shrews: hm, looking back at the jenkins history there, maybe it was just that run that was slow? | 18:23 |
| devananda | Shrews: patch set 11 ran in 34 min and then in 50 min ... | 18:24 |
| Shrews | devananda: i see from my review the basic one takes about 3.5 min, and the advanced in about twice that, which makes sense (2 instances created) | 18:24 |
| devananda | right | 18:25 |
| *** bandicot has quit IRC | 18:25 | |
| devananda | in the future we're going to need to add more functionality to those scenarios, rather than add more scenarios, I think | 18:25 |
| *** dsneddon has joined #openstack-ironic | 18:25 | |
| devananda | otherwise our test run will just take waaay too long | 18:26 |
| *** harlowja has joined #openstack-ironic | 18:26 | |
| *** harlowja has quit IRC | 18:26 | |
| Shrews | devananda: yeah. unless you want to get rid of the basic one, i don't see how to fix that one, though | 18:26 |
| *** harlowja has joined #openstack-ironic | 18:26 | |
| *** harlowja has quit IRC | 18:26 | |
| devananda | for now, +5 min seems OK, but we need to keep total run time in mind | 18:27 |
| *** harlowja has joined #openstack-ironic | 18:27 | |
| *** harlowja has quit IRC | 18:27 | |
| devananda | adam_g: any thoughts on ^ ? | 18:27 |
| devananda | Shrews, adam_g: also, are either of you working on moving our tempest tests to admin/ ? | 18:28 |
| Shrews | devananda: adam_g has a patch up for that | 18:28 |
| devananda | awesome | 18:28 |
| devananda | link? | 18:28 |
| adam_g | https://review.openstack.org/#/c/100989/ | 18:28 |
| *** harlowja has joined #openstack-ironic | 18:28 | |
| *** harlowja has quit IRC | 18:28 | |
| adam_g | devananda, runtime of tempest is going to absolutely explode once enable the parts of the API tests we skip via regex currently | 18:29 |
| *** harlowja has joined #openstack-ironic | 18:29 | |
| *** harlowja has quit IRC | 18:29 | |
| devananda | adam_g: fantastic. why? | 18:29 |
| *** ccrouch has joined #openstack-ironic | 18:29 | |
| adam_g | devananda, *lots* of API tests require spinning up an instance as part of the tests setUpClass or the invididual tests | 18:29 |
| devananda | ooh | 18:29 |
| devananda | right | 18:29 |
| devananda | because with libvirt, instance starts in seconds | 18:29 |
| adam_g | yeah | 18:29 |
| *** harlowja has joined #openstack-ironic | 18:29 | |
| *** harlowja has quit IRC | 18:29 | |
| devananda | pxe provisioning a nested vm is terrible tho | 18:30 |
| adam_g | some also start multiple instances | 18:30 |
| devananda | adam_g: any estimate of how bad that will be? | 18:33 |
| devananda | if it's going to be prohibitive, we will need to have a long talk with qa folks ... | 18:33 |
| openstackgerrit | Devananda van der Veen proposed a change to openstack/python-ironicclient: Make a few minor updates to node shell help strings https://review.openstack.org/102312 | 18:33 |
| *** harlowja has joined #openstack-ironic | 18:34 | |
| *** harlowja has quit IRC | 18:34 | |
| adam_g | devananda, i dont have a baseline yet, still working on getting tempest.api.compute.* to run. | 18:35 |
| devananda | adam_g: ack | 18:36 |
| adam_g | devananda, theres still a couple issues aside from feature flags there, but yeah.. i dont know how long is too long for a tempest job | 18:36 |
| devananda | adam_g: I suspect this will have to go to the ML to discuss with QA folks | 18:36 |
| devananda | adam_g: so that we can adequately explain why it's slower to the whole QA team at once, and then try to find a solution | 18:37 |
| adam_g | devananda, sure | 18:37 |
| devananda | adam_g: but having real numbers first would be good. if it's under an hour for the run, my guess is that'll be acceptable | 18:37 |
| devananda | adam_g: if it's like 5 hours .... heh, no. | 18:37 |
| adam_g | devananda, right | 18:37 |
| devananda | so we need to see | 18:37 |
| dtantsur | jroll, around? I'm shamelessly stealing things from IPA spec and I'd like to know, whether you have written format for hardware inventories in Node.extra. I would like to include it in generic spec. | 18:38 |
| devananda | as for the multiple instances tests, we can make a case that ironic tests need to run in larger instances | 18:38 |
| adam_g | devananda, theres still some other rough spots i need to work out aside from feature flags. ie, tests spawning instances too quickly before n-cpu can reclaim ironic's resources from a previous tests instance | 18:38 |
| *** harlowja has joined #openstack-ironic | 18:39 | |
| *** harlowja has quit IRC | 18:39 | |
| devananda | ahh | 18:39 |
| devananda | adam_g: i think shrews just addressed that with wait_for_resources | 18:39 |
| devananda | adam_g: but we could also make some changes in the virt driver that might help that, maybe | 18:39 |
| adam_g | devananda, yeah, the API tests need to do something similar, but they are structured such that there are admin tests and non-admin tests, and not really any mixing of the two (hypervisor-stats is an admin thing we'd be stressing from the non-admin tests) | 18:40 |
| *** harlowja has joined #openstack-ironic | 18:40 | |
| *** harlowja has quit IRC | 18:40 | |
| adam_g | devananda, what virt driver changes did you have in mind? that'd be an easier route | 18:41 |
| *** harlowja has joined #openstack-ironic | 18:42 | |
| devananda | adam_g: off hand ideas ... | 18:42 |
| devananda | - virt driver changes ResourceTracker when delete() is complete | 18:43 |
| devananda | - use nova's event API so ironic can actively inform nova of resource changes (rather than wait for pollign) | 18:43 |
| devananda | i think comstud had some sketches of how we might do the second of those | 18:43 |
| Shrews | Trying to get generate_sample.sh to work makes me want to kill bunnies | 18:44 |
| adam_g | devananda, interesting | 18:45 |
| devananda | Shrews: huh? works fine for me | 18:45 |
| Shrews | devananda: in tempest. needed a rebase now it's all borked up | 18:45 |
| devananda | Shrews: also, I think i saw a patch which will add a jenkins job to do that for us | 18:45 |
| devananda | oh | 18:45 |
| devananda | works fine /in ironic/ for me :) | 18:46 |
| * Shrews pokes devananda in eye with a stick | 18:46 | |
| devananda | ow! | 18:46 |
| comstud | I don't think I have a sketch | 18:46 |
| * devananda throws a cup'o'cold'coffee at Shrews | 18:46 | |
| comstud | but you can find examples of neutron calling back to nova... in neutron | 18:46 |
| adam_g | comstud, yeah | 18:46 |
| devananda | comstud: ah. must be wishful thinking on my part then :) | 18:47 |
| comstud | yeah :) | 18:47 |
| comstud | my part too, I guess | 18:47 |
| comstud | I'm just trying to get back to the object fixes I need to make yet | 18:48 |
| comstud | or s/need/want/ | 18:48 |
| comstud | which should be RSN | 18:48 |
| NobodyCam | grr how can one get the root device inside a chroot | 18:48 |
| Shrews | and now, pbr will not install on a fresh devstack run/reclone | 18:48 |
| * Shrews cries | 18:48 | |
| openstackgerrit | linggao proposed a change to openstack/ironic: Fix exception handling in console start https://review.openstack.org/102318 | 18:49 |
| devananda | Shrews: oh, right. my devstack was hosed last week too. | 18:49 |
| devananda | Shrews: thanks for reminding me how sad I am about that | 18:49 |
| Shrews | devananda: solution? | 18:49 |
| Shrews | if any | 18:49 |
| devananda | Shrews: shoot it? | 18:49 |
| ccrouch | any suggestions for how to deal with a failure trying to delete an instance from nova? | 18:49 |
| ccrouch | nova baremetal is complaining it can't authenticate to the node (a mock baremetal vm) via ssh | 18:49 |
| ccrouch | http://fpaste.org/112723/63498414/ | 18:49 |
| ccrouch | delete worked fine on two other instances from the same tripleo setup | 18:49 |
| devananda | ccrouch: using baremetal or ironic? | 18:50 |
| Shrews | *sigh* | 18:50 |
| devananda | ccrouch: right - baremetal. no clue, sorry. best advice i will give right now is: please use ironic instead :) | 18:50 |
| devananda | ccrouch: fwiw, that does look like a simple SSH authentication error connecting to the host on which that mock baremetal instance exist(ed) | 18:52 |
| ccrouch | right, its just that the authentication is the same across all the nodes, it just fails on this one :-( | 18:53 |
| ccrouch | i'm trying find a way to unwedge it, so i dont have to blow my undercloud away | 18:53 |
| *** krtaylor has quit IRC | 18:56 | |
| *** achanda has quit IRC | 18:56 | |
| devananda | ccrouch: fails repeatably on that node? or failed once on that instance? | 18:57 |
| *** jdob has quit IRC | 18:57 | |
| *** jdob has joined #openstack-ironic | 18:58 | |
| ccrouch | checking | 18:59 |
| *** jcoufal has joined #openstack-ironic | 18:59 | |
| *** krtaylor has joined #openstack-ironic | 19:01 | |
| ccrouch | so i can't get *anything* to happen with more runs of nova delete <blah> | 19:02 |
| ccrouch | nothing changes in /var/log/nova | 19:02 |
| ccrouch | and the instances stay in ERROR:deleting:NOSTATE | 19:02 |
| ccrouch | ERROR : deleting : NOSTATE | 19:02 |
| openstackgerrit | A change was merged to openstack/python-ironicclient: Updated from global requirements https://review.openstack.org/96263 | 19:02 |
| Shrews | devananda: so, we have our ++ from nova, now if i could just get a successful rebase, which seems to require a successful devstack re-install, which is borked. I shall drink much beer tonight, methinks | 19:04 |
| Shrews | wait, why am i even using devstack??? | 19:05 |
| * Shrews might need caffeine | 19:05 | |
| devananda | ccrouch: sure. Asking nova to delete an instance that is already in the process of deleting is just a no-op | 19:06 |
| devananda | ccrouch: that didn't answer my qusetion | 19:06 |
| *** ellenh has quit IRC | 19:07 | |
| devananda | ccrouch: you might have better luck asking in #tripleo, as it sounds like your question is really a tripleo question, not related to ironic? | 19:07 |
| *** max_lobur has joined #openstack-ironic | 19:07 | |
| ccrouch | i think the issue is with nova-baremetal which is why i came here, but I understand that is not your focus | 19:08 |
| *** max_lobur1 has joined #openstack-ironic | 19:09 | |
| *** jdob has quit IRC | 19:09 | |
| *** max_lobur has quit IRC | 19:09 | |
| *** jdob has joined #openstack-ironic | 19:09 | |
| *** Manishanker has quit IRC | 19:10 | |
| devananda | ccrouch: from what I recall of nova-baremetal, you may be able to re-initiate the delete by restarting nova-compute | 19:13 |
| devananda | ccrouch: short of that, I think you'd need to do some careful manual editing of both the nova and nova_bm databases | 19:14 |
| ccrouch | appreciated, i will give that a go. thanks | 19:14 |
| devananda | ccrouch: but it's been over a year since I worked in taht code base ... sorry | 19:14 |
| ccrouch | yeah, i think at that point i will nuke-it-from-orbit | 19:14 |
| ccrouch | no problem, thanks for giving me some pointers | 19:14 |
| devananda | Shrews: why would a rebase require devstack running? | 19:15 |
| Shrews | devananda: it doesn't. i was using devstack as a shortcut to reinstall tempest. but even manually, i get errors with pbr | 19:15 |
| Shrews | so, life sucks right now | 19:16 |
| *** killer_prince has quit IRC | 19:24 | |
| NobodyCam | ahhh fstab must be correctly set to run mkinitrd... why? | 19:28 |
| NobodyCam | nice but as a side note I was able to build and deploy a openSUSE image | 19:31 |
| *** harlowja has quit IRC | 19:31 | |
| NobodyCam | with only a couple of really nasty hacks :-p | 19:32 |
| Shrews | devananda: a 'rm -rf /usr/local/lib/python2.7' seems to be the cure | 19:32 |
| devananda | Shrews: sweet. /me tries that | 19:34 |
| NobodyCam | brb | 19:34 |
| *** Mikhail_D_ltp has joined #openstack-ironic | 19:35 | |
| Shrews | devananda: i've also set RECLONE=yes in localrc | 19:35 |
| *** achanda has joined #openstack-ironic | 19:35 | |
| Shrews | or just rm /opt/stack | 19:36 |
| *** harlowja has joined #openstack-ironic | 19:37 | |
| *** harlowja_ has joined #openstack-ironic | 19:39 | |
| devananda | Shrews: pkg_resources.DistributionNotFound: pip==1.4.1 | 19:41 |
| Shrews | devananda: yeah, i had that too, but my pip was 1.5.6 and NOT installed via apt-get | 19:42 |
| *** harlowja has quit IRC | 19:42 | |
| Shrews | it's all working for me now | 19:42 |
| devananda | Shrews: how are you installing pip? | 19:42 |
| Shrews | devananda: devstack installs it | 19:42 |
| *** max_lobur has joined #openstack-ironic | 19:44 | |
| linggao | folks, can a patch have 2 dependencies? | 19:44 |
| devananda | linggao: if they are linear, yes | 19:45 |
| devananda | linggao: A -> B -> C | 19:45 |
| *** max_lobur2 has joined #openstack-ironic | 19:45 | |
| *** max_lobur1 has quit IRC | 19:45 | |
| linggao | devananda, Can A depends both B and C, B and C has no relationship? | 19:45 |
| devananda | linggao: no | 19:46 |
| devananda | linggao: that is not modelled by gerrit, unfortunately | 19:46 |
| linggao | devananda, thanks. | 19:46 |
| *** Mikhail_D_ltp has quit IRC | 19:48 | |
| *** max_lobur has quit IRC | 19:49 | |
| *** jcoufal has quit IRC | 19:49 | |
| *** rameshg8- has quit IRC | 19:49 | |
| *** Penick has quit IRC | 19:58 | |
| *** Penick has joined #openstack-ironic | 20:03 | |
| *** zdiN0bot has joined #openstack-ironic | 20:05 | |
| *** dtantsur is now known as dtantsur|afk | 20:10 | |
| dtantsur|afk | g'night | 20:11 |
| NobodyCam | night dtantsur|afk | 20:11 |
| *** dsneddon has quit IRC | 20:11 | |
| *** rameshg87 has joined #openstack-ironic | 20:15 | |
| *** ellenh has joined #openstack-ironic | 20:15 | |
| *** Mikhail_D_ltp has joined #openstack-ironic | 20:16 | |
| *** Mikhail_D_ltp has quit IRC | 20:16 | |
| *** Mikhail_D_ltp has joined #openstack-ironic | 20:16 | |
| *** zdiN0bot has left #openstack-ironic | 20:17 | |
| jroll | dtantsur|afk: here now. not quite sure what you're asking? | 20:21 |
| *** kylers has joined #openstack-ironic | 20:23 | |
| adam_g | anyone know what the plan / stauts is for ironic.nova.compute.manager.ClusteredComputeManager ? | 20:25 |
| ellenh | devananda: hi, last week you told me to use _LI() for info logging, does that still apply? It seems to cause import errors and isn't in the logging spec anymore | 20:25 |
| jroll | adam_g: with regards to? | 20:26 |
| *** eguz has joined #openstack-ironic | 20:26 | |
| devananda | ellenh: hi! the i18n team is adding docs /right now/ on that :) see http://docs-draft.openstack.org/61/96961/7/check/gate-oslo.i18n-docs/c4074a7/doc/build/html/guidelines.html#log-translation for the pre-merge draft | 20:27 |
| adam_g | jroll, i guess wrt merging ironic.nova.* back into nova. is that going with it? do we maintain a host manager in ironic? is it even used currently? (we're not testing it upstream) | 20:27 |
| devananda | ellenh: which should be landed within an hour, i think | 20:27 |
| devananda | adam_g: CCM is not merging | 20:27 |
| devananda | adam_g: see the ironic driver spec in nova -- they kicked that bit out, even though RS is using it, and afaik so is tripleo | 20:28 |
| *** davidlenwell_ is now known as davidlenwell | 20:28 | |
| adam_g | devananda, is it going away or staying in ironic? im looking to work around the resource reclaim stuff we were talking about wrt tempest, and that would be a good place | 20:28 |
| *** eguz has quit IRC | 20:28 | |
| *** eguz has joined #openstack-ironic | 20:28 | |
| adam_g | ah! | 20:28 |
| jroll | staying in ironic pls | 20:28 |
| NobodyCam | any one happen to recall enough bash to correctly construct : if [ "${chk_device:-2}" == "p[0-9]" ]; then | 20:29 |
| devananda | jroll: i'd rather it merge to nova, fwiw | 20:29 |
| jroll | devananda: I mean short term | 20:29 |
| devananda | jroll: but it is not "going away" until there is a better solution | 20:29 |
| jroll | until that happens | 20:29 |
| ellenh | devananda: great, thanks | 20:29 |
| jroll | right | 20:29 |
| devananda | right | 20:29 |
| *** eghobo has quit IRC | 20:30 | |
| *** Mikhail_D_ltp has quit IRC | 20:39 | |
| rloo | devananda: do you have a few minutes to discuss the design of https://review.openstack.org/#/c/73005/? API to get driver_info properties? | 20:39 |
| devananda | rloo: after this meeting, yep | 20:41 |
| rloo | devananda: ok | 20:41 |
| *** max_lobur has joined #openstack-ironic | 20:41 | |
| *** max_lobur has quit IRC | 20:44 | |
| *** max_lobur2 has quit IRC | 20:44 | |
| openstackgerrit | A change was merged to openstack/ironic-python-agent: Better errors for execute() failures https://review.openstack.org/99666 | 20:47 |
| openstackgerrit | linggao proposed a change to openstack/ironic: Naming change for console terminal port https://review.openstack.org/102345 | 20:57 |
| *** jdob has quit IRC | 20:58 | |
| *** jbjohnso has quit IRC | 21:05 | |
| devananda | rloo: ok, mostly done with that meeting | 21:05 |
| jroll | thinking more about https://review.openstack.org/#/c/86744 | 21:06 |
| openstackgerrit | linggao proposed a change to openstack/ironic: Naming change for console terminal port https://review.openstack.org/102345 | 21:06 |
| rloo | devananda: thx. wrt https://review.openstack.org/#/c/73005/, my first approach was to instantiate driver objects in the API. and you said not to do that. | 21:06 |
| jroll | what if that was just general node validation for driver actions, e.g. deploy(), tear_down(), write_firmware() | 21:06 |
| rloo | the 2nd approach was to use rpc to talk to conductor. romcheg said not to do that. | 21:06 |
| rloo | the suggestion now is to save the driver_info in the db. | 21:07 |
| jroll | for example, the agent driver could make sure the agent was up and firmware exists, for write_firmware() | 21:07 |
| rloo | i was wondering why (maybe I forgot why) drivers shouldn't be loaded in the api service. | 21:07 |
| jroll | and then I realized we have validate(). maybe we should just pass the desired action to validate()? | 21:08 |
| jroll | (just thinking out loud) | 21:08 |
| rloo | and i was wondering whether saving the driver_info properties in a db table made sense. | 21:08 |
| *** igordcard has quit IRC | 21:08 | |
| rloo | vs eg having the api get the driver_info properties once and caching. | 21:08 |
| JoshNang | jroll: seems sensible. i'd rather leave it in validation than a separate method, and have validation for each action rather than general validation is more useful in my mind | 21:09 |
| *** kylers has quit IRC | 21:09 | |
| jroll | JoshNang: exactly | 21:09 |
| jroll | JoshNang: and the upgrade path for each driver is easy - add an argument that (currently) is not used | 21:09 |
| rloo | and if we saved in a db, whether it made sense to save in conductor table cuz conductor info is only there when a conductor is available. | 21:09 |
| JoshNang | jroll: well and putting the current power state validation in there | 21:10 |
| jroll | ah yes | 21:10 |
| JoshNang | which isn't much | 21:10 |
| rloo | anyway, i am wondering why i don't just get (in api service) all the drivers specified in setup.cfg (if i can figure out how to do that) and save/cache the driver_info properties and be done with it. | 21:11 |
| JoshNang | putting it in validate would make validation run longer than it does currently, because you're adding power_driver.get_power_state to validate. i don't think that's a huge concern though | 21:13 |
| jroll | well | 21:13 |
| jroll | it's just moving it to a different place | 21:13 |
| devananda | rloo: why not load drivers in the api service -- because drivers talk to hardware ,and the API service shouldn't be allowed to do that | 21:13 |
| jroll | JoshNang: you could also restrict power state validation to 'deploy' or whatever | 21:14 |
| rloo | devananda: too bad. Guess I can't get a 'read-only' driver. | 21:14 |
| JoshNang | jroll: what do ya mean? | 21:14 |
| devananda | rloo: we could factor out the validation to another (set of) class(es) | 21:15 |
| jroll | JoshNang: like, power state validation already happens somewhere in the deploy() call. this just moves it to somewhere else in the deploy() call | 21:15 |
| devananda | but... | 21:15 |
| devananda | rloo: what I was thinking is this... | 21:15 |
| JoshNang | jroll: gotcha. that's what my patch is doing currently | 21:15 |
| devananda | rloo: when a conductor service starts, it already calls register_conductor, which saves a list of available drivers in the db | 21:15 |
| jroll | JoshNang: yeah, this just moves it to somewhere else somewhere else | 21:15 |
| JoshNang | so yeah, it's really not a concern | 21:15 |
| rloo | devananda: yes. it saves the drivers for that conductor in the conductor table. | 21:16 |
| devananda | rloo: oh. gah. i'm juggling another meeting and thinking of something else. never mind | 21:16 |
| devananda | rloo: what about node update calling validate, and stashing that on the node record? | 21:17 |
| rloo | devananda: i was thinking i could put the driverinfo per driver in a different driver table. but then... how long does the driver table live? and how to coordinate/update the info? or do I always update it per driver each time a conductor is registered. | 21:17 |
| rloo | devananda: ha ha. this isn't urgent. maybe you shouldn't multitask ;) | 21:17 |
| jroll | can we not store driver capabilities in the database? please? | 21:18 |
| devananda | rloo: conductor table stores the lsit of drivers that conductor supports. it lives until that conductor goes offline | 21:18 |
| *** matty_dubs is now known as matty_dubs|gone | 21:18 | |
| devananda | rloo: that could store the list of parameters that each of those drivers needs | 21:18 |
| devananda | rloo: but that gets awkward with optional params | 21:18 |
| devananda | eg, ssh needs user + (pass OR key) | 21:18 |
| rloo | devananda: yup, unless we only want the names of the required params, i was returning required/optional/help string. | 21:19 |
| devananda | rloo: wait. are we talking abotu the API listing the params? or validate? | 21:19 |
| devananda | aren't those separate? | 21:19 |
| rloo | devananda: and yeah, even then, with optional parms there are some oddities. | 21:19 |
| rloo | devananda: listing the params. i was using that list for validate too though. | 21:19 |
| rloo | devananda: listing the required/optional params. | 21:19 |
| devananda | rloo: oh. right. so just stash a dict on the conductor table. seems easy to me. | 21:20 |
| jroll | devananda: that's going to get less and less desirable as we add features, I think | 21:20 |
| devananda | or we create another table, which is also fine | 21:20 |
| jroll | might just be me thinking that, though | 21:21 |
| devananda | jroll: i'm sure i'm not thinking it through all the way ... how so? | 21:21 |
| rloo | yeah, i thought of another table. guess i'd need to update it each time a conductor is registered, just to be sure the info / driver is updated. | 21:21 |
| rloo | i assume we're ok with the db hits for each request for driver_info properties? | 21:22 |
| jroll | devananda: more features, more functions, more arguments, more problems. (lots of optional arguments too) | 21:22 |
| *** eguz has quit IRC | 21:22 | |
| jroll | devananda: mostly just, I don't understand why we don't just get it from conductor once and then cache | 21:22 |
| jroll | (cache on the api side) | 21:22 |
| rloo | yeah, jroll: i'd rather cache on api side and not stick in a db at all. | 21:23 |
| jroll | invalidation might be tricky, but we can figure it out | 21:23 |
| rloo | jroll: but if i do it via a conductor, it means the api needs to know if new conductors/drivers come online. | 21:23 |
| * jroll waves his hands around magically | 21:23 | |
| devananda | what does an upgrade look like? | 21:23 |
| jroll | rloo: right, that's the hard part | 21:23 |
| *** bandicot has joined #openstack-ironic | 21:23 | |
| devananda | eg, if someone rolls out a new version of pxe_ipmitool that hasthis change https://review.openstack.org/#/c/102345/1 | 21:23 |
| rloo | jroll: which is why i thought if i can get all the drivers from setup.cfg, in the API, and get the info from that, it solve the problem :-) | 21:23 |
| devananda | s/terminal_port/console_port/ | 21:23 |
| jroll | devananda: maybe cache for $conductor_timeout | 21:23 |
| devananda | how and when does that propagate to the API? | 21:24 |
| jroll | rloo: ehhhhhhhh, I'd rather grab directly from the conductor or something | 21:24 |
| rloo | jroll: on the other hand, that doesn't solve the problem if a conductor is run on another box with a diff setup.cfg/version of ironic. | 21:24 |
| devananda | rloo: that would require restarting API services to reload driver modules, and keeping them in sync between conductors and api services | 21:24 |
| jroll | rloo: exactly | 21:24 |
| jroll | and what deva said | 21:24 |
| devananda | rloo: and the conductor /should/ be run on a different box | 21:24 |
| devananda | rloo: conductor is very privileged service. API is not. | 21:25 |
| * devananda needs to release a doc describing recommended service toplogy for security-minded deployments | 21:25 | |
| rloo | jroll, devananda. yeah. ok, so api makes at most one rpc call when a request comes in. gets conductor/driver info and caches it. | 21:25 |
| devananda | jroll: unless ya'll want to ^ :) | 21:25 |
| jroll | devananda: we have a diagram :P | 21:25 |
| jroll | rloo: that's my thought | 21:26 |
| rloo | devananda, jroll: i'm going to assume (still) that driver info is the same regardless of conductor. which could be wrong if diff conductors running diff versions of ironic. | 21:26 |
| devananda | rloo: that will be wrong during an upgrade window at some point in time, which we need to consider | 21:27 |
| rloo | devananda: yeah. i was just thinking of that :-( | 21:27 |
| rloo | devananda: but what does it mean when someone makes a request for driver info, and there are diff versions of conductors. that they explicitly specify the conductor? | 21:27 |
| rloo | and why would anyone ask for driver_info properties if there is an upgrade going on. they shouldn't be registering new nodes then. but of course someone will... | 21:30 |
| *** eghobo has joined #openstack-ironic | 21:32 | |
| *** eghobo has quit IRC | 21:36 | |
| *** harlowja_ has quit IRC | 21:36 | |
| *** eghobo has joined #openstack-ironic | 21:36 | |
| *** harlowja has joined #openstack-ironic | 21:36 | |
| *** linggao has quit IRC | 21:38 | |
| * devananda kicks his ISP | 21:38 | |
| devananda | rloo: indeed.... i haven't thought through all the possibilities there. randomly getting the list from *a* conductor is probably bad, because it's non-deterministic if there are dif versions of drivers | 21:40 |
| devananda | rloo: similarly, caching without explicit cache invalidation is bad | 21:41 |
| rloo | devananda: I wonder if we should be capturing the conductor's RPC_API version. | 21:41 |
| devananda | rloo: because an upgrade could leave the caches on different API instances non-deterministically in different states | 21:42 |
| devananda | rloo: that is coordinated already between api and conductor | 21:42 |
| devananda | rloo: the driver API doesnt have a version right now, tho | 21:42 |
| rloo | devananda: i was thinking that the driver_info property that is cached, needs to be associated with the conductor's rpc api version. | 21:43 |
| rloo | devananda: is there a plan to have driver versions? | 21:43 |
| *** romcheg has joined #openstack-ironic | 21:45 | |
| rloo | a particular conductor (version) handles one or more drivers (that are versioned). Ugh. | 21:45 |
| NobodyCam | rloo: oh what a tangled web you are weaving | 21:47 |
| devananda | rloo: rpc version != driver version.... right. | 21:47 |
| devananda | fun! | 21:47 |
| devananda | i could, for instance, upgrade a driver without changing the conductor -- all i would need to do is restart the conductor to pick up the new python module | 21:48 |
| rloo | NobodyCam: Yeah, who would have thought a simple API that doesn't *do* much, could be so complicated. all to make our users happy. | 21:48 |
| rloo | devananda: but if you did that, how is the user to know/specify which driver version they want to associate with a new node? | 21:49 |
| devananda | right | 21:49 |
| devananda | so the answer may be that the cluster needs to refuse certain operations on a driver if different versions are present | 21:49 |
| devananda | just thinking out loud ... | 21:50 |
| rloo | and then you're going to ask for an API so users can know what driver versions are available with which conductors. ha ha. | 21:50 |
| devananda | perhaps that's a terrible idea | 21:50 |
| devananda | but it solves several things | 21:50 |
| NobodyCam | what happens with the inevitable question: "oh we have three ironic api nodes.. I only upgraded two of them" | 21:50 |
| devananda | NobodyCam: try asking the same question of Nova. they started trying to solve this two years ago. i think it's still in progress | 21:51 |
| rloo | NobodyCam: don't confuse the issue! we're only talking about diff conductor versions and driver versions! :-) | 21:51 |
| *** yjiang5_away is now known as yjiang5 | 21:51 | |
| NobodyCam | :-p | 21:51 |
| NobodyCam | :( | 21:52 |
| openstackgerrit | Adam Gandelman proposed a change to openstack/ironic-specs: External event callback API https://review.openstack.org/99770 | 21:54 |
| NobodyCam | rameshg87: around? | 21:55 |
| jroll | JoshNang: another idea wrt long-running deploy ramdisks. 1) provide a reboot script with ironic to do rolling deploy ramdisk upgrades. 2) keep ramdisk version (glance uuid?) in the db. check if that's latest at deploy() time, if not, reboot into latest. thoughts? | 21:56 |
| *** mrda-away is now known as mrda | 21:56 | |
| mrda | Morning Ironic! | 21:56 |
| jroll | heya mrda | 21:56 |
| NobodyCam | good morning mrda | 21:56 |
| mrda | o/ | 21:56 |
| devananda | rloo: one possibility would be to simply document "when upgrading a conductor driver, you must restart all API services after the conductor service upgrades are completed" | 21:59 |
| JoshNang | jroll: that's reasonable i think | 21:59 |
| devananda | rloo: i mean, if we were to have the API cache the results | 21:59 |
| devananda | mrda: hi! replied to your email. and just thought of this -- https://review.openstack.org/#/c/79194/ | 22:00 |
| devananda | mrda: take a look and let me know if reviving that work sounds interesting to you | 22:00 |
| mrda | thanks devananda, I'll take a look | 22:00 |
| rloo | devananda: upgrading a conductor driver isn't the same as conductor service upgrades though. | 22:00 |
| devananda | rloo: but both require restarting the conductor service itself | 22:00 |
| JoshNang | jroll: personally, i'd like to avoid 2 actually happening. you'd add a post cycle + kill any precaching. but, on the other hand, if those aren't concerns for the deployer, that's much easier than rebooting all the agents and having deploy downtime | 22:01 |
| devananda | jroll: ya'll doing any work on conductor migrations / take over / ring rebalancing? | 22:01 |
| rloo | devananda: right, restarting one, not necessarily all conductor services. | 22:01 |
| rloo | devananda: so there could be two diff driver versions. | 22:01 |
| JoshNang | or having to come up with a rolling update + a scheduler update to look for only latest ramdisk | 22:01 |
| jroll | devananda: I don't believe so, right now | 22:01 |
| mrda | devananda: Just FYI, also looking at +bug/1308171 | 22:01 |
| JoshNang | jroll: where would the latest version be stored? | 22:01 |
| NobodyCam | brb | 22:02 |
| devananda | jroll: ack. it probably doesn't matter as much for IPA if you're booting instances from local disk | 22:02 |
| jroll | JoshNang: I mean, yeah. thinking now of "when ironic sees a new deploy ramdisk/kernel hit the db, reboot that node" | 22:02 |
| rloo | devananda: I seriously doubt I will get all the i's dotted and t's crossed for this 'simple' API request. ha ha. let me think about it. | 22:02 |
| jroll | JoshNang: idk, somewhere in the node table | 22:02 |
| jroll | devananda: yeah, I don't think we'd see many problems if a conductor crashed during a deploy | 22:03 |
| devananda | jroll: just taht deploy failing, at most | 22:03 |
| devananda | jroll: actually, you're not caching any local state at all, are you | 22:03 |
| jroll | devananda: I think the deploy would even go through in most (all?) cases | 22:03 |
| jroll | devananda: nope, exactly | 22:04 |
| rloo | devananda, jroll: thx for your feedback. Gotta take off for dinner so will 'sleep' on this ;) | 22:04 |
| devananda | jroll: so it'd only fail if the conductor was, say, in the middle of a db transaction | 22:04 |
| jroll | rloo: enjoy :) | 22:04 |
| JoshNang | jroll: right, so each node has like node.driver_info['ramdisk_version'] = x. if x != y, reboot node into new ramdisk before deploy. but where do we store y? | 22:04 |
| devananda | jroll: and if IPA is not smart enough (yet) to retry on error | 22:04 |
| *** rloo is now known as rloo_gone | 22:04 | |
| jroll | devananda: yeah. even then, it might just end up writing the image a second time or whatever | 22:04 |
| jroll | devananda: tldr: when the agent heartbeats, it looks at provision_state and does things based on that (write an image, or reboot, today) | 22:05 |
| * rloo_gone thinks maybe we need to add another question in the specs -- how/is the feature affected by upgrades. | 22:05 | |
| NobodyCam | night rloo_gone | 22:06 |
| jroll | JoshNang: right, this won't work in our environment or current code. but e.g. pxe driver uses driver_info['deploy_ramdisk'] = 'glance://some-image-uuid' | 22:06 |
| jroll | JoshNang: so like, if current image uuid is different than that uuid, reboot | 22:06 |
| jroll | JoshNang: does that make sense? | 22:06 |
| jroll | JoshNang: the more I think about things, the more I like ironic controlling DHCP/PXE configs. unfortunately, as you already know, dnsmasq. :| | 22:07 |
| JoshNang | jroll: so when you upload a new ramdisk to glance, how do you notify ironic of that? | 22:07 |
| jroll | JoshNang: idk, you like, update the nodes that should use it through the API | 22:07 |
| devananda | JoshNang: you change the deploy ramdisk on each node's driver_info ? | 22:08 |
| jroll | JoshNang: this is how pxe driver works today, anyway | 22:08 |
| jroll | JoshNang, devananda: the way we do things with "one golden ramdisk" doesn't really work for heterogeneous hardware :/ | 22:08 |
| jroll | and it's quite unfortunate | 22:08 |
| devananda | jroll: :( | 22:09 |
| JoshNang | jroll, devananda: gotcha. wfm. | 22:09 |
| devananda | jroll: as long as that's a limitation of your choices, and not of IPA, that's fine (but unfortunate) | 22:09 |
| jroll | splitting out these patches to work like the pxe driver has taught me a lot | 22:09 |
| devananda | jroll: :) | 22:09 |
| jroll | devananda: it's more of... a consequence of our timeline | 22:09 |
| jroll | devananda: that's not a permanent thing by any means | 22:09 |
| devananda | jroll: ah, gotcha. that makes sense | 22:10 |
| jroll | but the working code *today* assumes a lot of things that won't work upstream | 22:10 |
| jroll | devananda: that said, 101020 should work for everyone :) some small IPA changes need to happen to work with it but I think it's mostly good to go (maybe better tests too) | 22:10 |
| *** romcheg has quit IRC | 22:10 | |
| JoshNang | jroll: a compromise on ironic controlling dhcp/pxe is an api endpoint generating the ipxe config? i should go read the ipxe spec (i think there is one already) | 22:10 |
| jroll | JoshNang: hmm | 22:11 |
| jroll | JoshNang: another hard part is that endpoint would be per-node | 22:11 |
| devananda | jroll: only whole disk images supported (but those aren't supported by PXE driver yet) ? | 22:11 |
| jroll | JoshNang: so the dhcp config pointing the node to ironic for ipxe configs would need to figure that out | 22:11 |
| JoshNang | jroll: true | 22:12 |
| jroll | JoshNang: I'm tempted to make glyph happy and write that twisted dhcp server :) | 22:12 |
| devananda | jroll: that will be awkward if an environment were to run both, or migrate from pxe to ipa | 22:12 |
| JoshNang | jroll: heh | 22:12 |
| devananda | jroll: think ipa will support partition images soon? | 22:12 |
| jroll | devananda: yeah, so, that's more of an IPA limitation (just needs code to fix). plan to fix asap :) | 22:12 |
| devananda | great | 22:12 |
| jroll | devananda: not sure if that should be in that patch or a separate one; open to either | 22:13 |
| devananda | jis there a reason your patch tree is based on https://review.openstack.org/#/c/95551/12 | 22:13 |
| devananda | *is | 22:13 |
| jroll | yes, we're using instance_info things. maybe that patch isn't needed, but I just grabbed the easy end of that tree | 22:14 |
| devananda | jroll: how is the "factor out small things, keep IPA driver in one big patch" approach working for you guys? | 22:14 |
| jroll | devananda: working for us, in terms of? | 22:15 |
| jroll | devananda: this is like... minimum viable patch | 22:15 |
| devananda | jroll: so that patch actually removes backwards compat. there's another patch that makes it better compatibile with icehouse, which would be better to base on | 22:15 |
| devananda | jroll: in terms of being as painless a development process as possible, given that ipa is a work in progress still, from upstream perspective | 22:16 |
| jroll | devananda: right, so, I based from that patch before that discussion | 22:16 |
| devananda | jroll: indeed. just pointing out that you'll want to NOT depend on 95551, since that won't merge in Juno. K can break compat with I, but J should not. | 22:16 |
| jroll | devananda: right, I see that now, thanks | 22:17 |
| jroll | oh now we can base on master | 22:17 |
| jroll | yay | 22:17 |
| * jroll makes a note to rebase eventually | 22:17 | |
| devananda | :-) | 22:17 |
| devananda | jroll: so, dev process wise. carrying a long patch tree sucks, I know. Ya'll are doing great work. we talked a while back about things to make your life easier (like squashing the driver into a monolithic patch) | 22:18 |
| jroll | mhmmm, we did that and now we're going to abandon it :P | 22:19 |
| devananda | lol | 22:19 |
| devananda | in favor of? | 22:19 |
| jroll | in favor of this | 22:19 |
| jroll | our monolithic patch had configdrive, decom, long-running agent support, external dhcp support | 22:19 |
| jroll | which I'm now writing specs for and putting up as separate patch trees | 22:20 |
| devananda | ah | 22:20 |
| jroll | (which is the only sane thing to do) | 22:20 |
| jroll | but, were you saying something before that tangent? | 22:21 |
| devananda | i see. two of those (decom, ext dhcp) are immediately things i know other folks want as well | 22:21 |
| devananda | jroll: no, i think that was the tangent i was asking about | 22:21 |
| devananda | thanks | 22:22 |
| jroll | ah, ok | 22:22 |
| devananda | on swift temp urls, have ya'll talked with the oslo team about that? | 22:22 |
| devananda | or the swift and glance teams? | 22:22 |
| jroll | devananda: I'm thinking we should prioritize devstack/tempest work before those additional features. agree? | 22:22 |
| jroll | I haven't. JoshNang ? | 22:22 |
| JoshNang | devananda: not in awhile. not the oslo folks for sure | 22:23 |
| jroll | I think the original plan was, land in ironic and eventually move to oslo | 22:23 |
| devananda | jroll: yea. devstack/tempest coverage will definitely increase the rate folks are willing to review/approve IPA patches and features | 22:23 |
| JoshNang | i think the swift guys said they'd welcome it (probably in swiftclient) | 22:23 |
| devananda | test driven development and all ... | 22:23 |
| jroll | devananda: indeed | 22:23 |
| devananda | JoshNang: right. so if the swift team will accept it in swiftclient, we should just do that | 22:24 |
| devananda | JoshNang: if not -- if they dont want it and point us to oslo, then we should just land it | 22:24 |
| devananda | locally and maybe move to oslo that way | 22:24 |
| devananda | but "land in ironic, move to swiftclient" doesn't make sense | 22:24 |
| jroll | swiftclient is sort of a weird place to put it | 22:24 |
| jroll | because it doesn't actually connect to swift | 22:25 |
| devananda | right | 22:25 |
| jroll | and it accepts a glance uuid, iirc? | 22:25 |
| JoshNang | maybe oslo is the most sane place, since it needs both glance and swift support | 22:25 |
| jroll | I think that may be the same uuid in swift, though | 22:25 |
| jroll | well | 22:25 |
| * dhellmann perks up his ears | 22:25 | |
| jroll | it could be in swiftclient, as 'given this swift object id/url, give me temp url' | 22:26 |
| jroll | dhellmann: swift temporary urls. want em? :) | 22:26 |
| dhellmann | is this something more than one project is going to use? | 22:26 |
| jroll | quite possible | 22:26 |
| devananda | dhellmann: most likely, yes | 22:26 |
| dhellmann | and why doesn't it belong in the swift client? | 22:26 |
| dhellmann | does it not talk to swift to make the url? | 22:26 |
| jroll | it does not | 22:26 |
| devananda | dhellmann: correct. it does not | 22:26 |
| JoshNang | dhellmann: nope. it uses a shared private secret | 22:27 |
| dhellmann | how does it make a url? | 22:27 |
| jroll | it basically just signs a url with & | 22:27 |
| dhellmann | shared with whom? | 22:27 |
| jroll | s/&/^/ where ^ points at 'shared secret' | 22:27 |
| devananda | shared with swift | 22:27 |
| JoshNang | the service making the url and saved in swift | 22:27 |
| dhellmann | so this is a thing our services will use, but is not a thing a cloud user will use? | 22:27 |
| jroll | dhellmann: here's a cli implementation: https://github.com/openstack/swift/blob/master/bin/swift-temp-url | 22:27 |
| jroll | dhellmann: it would be a service/admin things | 22:27 |
| jroll | -s | 22:27 |
| JoshNang | i think its something a cloud user could definitely use | 22:28 |
| jroll | uh | 22:28 |
| JoshNang | here's a url that expires in x hours | 22:28 |
| dhellmann | would they have the secret, though? | 22:28 |
| JoshNang | for a file stored in swift | 22:28 |
| jroll | JoshNang: is that secret per-tenant? | 22:28 |
| JoshNang | yeah i think per tenant | 22:28 |
| jroll | ok, so that's reasonable | 22:28 |
| JoshNang | but yeah, you'd have to be an admin on that tenant to make it. | 22:28 |
| jroll | I'd want to verify that | 22:28 |
| * jroll hits rax cloud with swift client | 22:28 | |
| devananda | the swifth temp urls can be given to end-users, fwiw | 22:28 |
| devananda | http://docs.openstack.org/trunk/config-reference/content/object-storage-tempurl.html | 22:29 |
| devananda | it's not an internal service-only thing | 22:29 |
| dhellmann | they can be given to end-users, but can an end user make one? | 22:29 |
| jroll | devananda: right, but would an end user generate one? | 22:29 |
| devananda | the /generation/ of temp urls is a service thing | 22:29 |
| devananda | right | 22:29 |
| jroll | if so, yes, probably belongs in switclient | 22:29 |
| jroll | ok | 22:29 |
| devananda | actually, correction | 22:30 |
| devananda | the generation of a temp url requires privileges to access taht swift object | 22:30 |
| devananda | the temp url then grants anyone with that url access to that object | 22:30 |
| devananda | it can be done by a user | 22:30 |
| dhellmann | it feels like this should go in swift client, but I agree it should live in a common library somewhere so if they don't want it then I guess we can put it in an oslo module | 22:31 |
| dhellmann | devananda: I don't see https://github.com/openstack/swift/blob/master/bin/swift-temp-url accessing any remote resources at all | 22:31 |
| devananda | dhellmann: i dont see it doing any access to remote resoruces either | 22:31 |
| dhellmann | although I guess it takes the key it needs as input | 22:31 |
| dhellmann | and if you have that key, it implies you have access to the resources | 22:32 |
| devananda | right | 22:32 |
| jroll | so, afaik, to get the key, a user runs 'swift stat' | 22:32 |
| jroll | I don't seem to be able to do that, on the rax cloud, at least | 22:32 |
| devananda | so a user who has access to their own objects could create a temp url and give it to someone else to download that object | 22:32 |
| devananda | without giving away their credentials | 22:32 |
| devananda | *to their own key | 22:32 |
| dhellmann | ok, I still think this fits with the swiftclient best, even though it doesn't actually talk to the service it is doing things with the swift API | 22:33 |
| jroll | yeah | 22:33 |
| dhellmann | but if the swift team disagrees, we'll find a home for it in oslo | 22:33 |
| * dhellmann doesn't want an oslo.swift though | 22:33 | |
| JoshNang | jroll: http://www.rackspace.com/blog/rackspace-cloud-files-how-to-create-temporary-urls/ | 22:33 |
| devananda | heh | 22:33 |
| jroll | devananda: is putting a dependency on latest swiftclient ok with you? | 22:34 |
| jroll | (if that code goes to swiftclient) | 22:34 |
| dhellmann | I have to run, but it seems like we're converging on that answer. Let me know if that proves to be wrong. | 22:34 |
| devananda | hm | 22:34 |
| devananda | dhellmann: seems like oslo is the answer to me | 22:34 |
| jroll | JoshNang: cool | 22:34 |
| jroll | heh | 22:35 |
| devananda | dhellmann: given that this feature's existed ins wift for 2+ years | 22:35 |
| devananda | and it's not in their client yet | 22:35 |
| openstackgerrit | Jay Faulkner proposed a change to openstack/ironic-python-agent: No longer reccomend use of ipa-advertise-url https://review.openstack.org/102371 | 22:35 |
| dhellmann | was it rejected, or did they just not implement it? | 22:35 |
| devananda | dhellmann: i'll punt that to notmyname | 22:36 |
| devananda | dhellmann: anyhow, thanks. catch you later | 22:36 |
| JoshNang | i'll go see if i can get it in swiftclient, failing that oslo | 22:36 |
| dhellmann | wfm | 22:37 |
| jroll | thanks, JoshNang | 22:37 |
| jroll | dhellmann: thanks for the help :) | 22:37 |
| openstackgerrit | Jay Faulkner proposed a change to openstack/ironic-python-agent: No longer reccomend use of ipa-advertise-url https://review.openstack.org/102371 | 22:37 |
| dhellmann | jroll: any time | 22:37 |
| JoshNang | id still like about half that code to land in ironic though. the stuff that pulls the url/creates the url from the direct url seems to make sense there. and a place to stash the shared key in the conf file | 22:37 |
| JayF | jroll: ^ h8 | 22:37 |
| jroll | JayF: yeah well, grammar | 22:37 |
| JayF | jroll: I know, but it's better now | 22:38 |
| JayF | jroll: lets test this stuff, I have only a few minutes before my next session and I want to see it work :) | 22:38 |
| jroll | I +2'd | 22:38 |
| jroll | idk what you want me to do | 22:38 |
| JayF | jroll: prod JoshNang | 22:38 |
| jroll | nou | 22:38 |
| * JayF prods JoshNang to +2 +A https://review.openstack.org/102371 to test IPA builder post joerb | 22:38 | |
| jroll | oh wait | 22:38 |
| jroll | s/reccomend/recommend | 22:38 |
| jroll | in commit title | 22:38 |
| jroll | :) | 22:39 |
| JayF | I fixed it as well | 22:39 |
| jroll | uh no? | 22:39 |
| jroll | I see reccomend | 22:39 |
| JayF | jroll: https://review.openstack.org/#/c/102371/1..2//COMMIT_MSG | 22:39 |
| jroll | it's fine, unless you happen to push another | 22:39 |
| JoshNang | weird | 22:39 |
| jroll | JayF: commit title | 22:39 |
| JayF | oh bollocks | 22:39 |
| openstackgerrit | Adam Gandelman proposed a change to openstack/ironic: Update Nova's available resources at termination https://review.openstack.org/102373 | 22:39 |
| jroll | it's fine | 22:39 |
| JoshNang | :D | 22:39 |
| jroll | just... ship it | 22:39 |
| JayF | fixed it | 22:40 |
| openstackgerrit | Jay Faulkner proposed a change to openstack/ironic-python-agent: No longer recommend use of ipa-advertise-url https://review.openstack.org/102371 | 22:40 |
| jroll | +A | 22:40 |
| jroll | I'm not waiting for someone else for that. | 22:40 |
| JayF | fair | 22:40 |
| JoshNang | JayF: heh i +A'ed like a sec before you re-committed | 22:40 |
| JoshNang | and now its double +A'ed | 22:40 |
| devananda | worth calling out to ya'll there's an eventlet bug cropping up | 22:43 |
| jroll | uh oh | 22:43 |
| devananda | most notably with the ssh driver and any parallelism, but, apparently, also with our use of qemu image utils in the pxe driver | 22:43 |
| devananda | I dunno if it would affect IPA yet | 22:44 |
| devananda | see the ML post this morning about it | 22:44 |
| jroll | oh, right | 22:44 |
| jroll | morgabra has had pain with paramiko not closing connections to switches | 22:44 |
| devananda | right | 22:44 |
| devananda | possibly the same thing | 22:44 |
| devananda | also -- SSH'ing into switches? ugh :( | 22:44 |
| jroll | fyi, on swift temp urls: 15:42:23 +torgomatic | jroll: could be useful to have; I'm neutral on the topic (but I've given it only a second or two of thought) | 22:44 |
| jroll | devananda: that's how cisco switches work :( | 22:45 |
| devananda | jroll: :( :( | 22:45 |
| jroll | devananda: want to quit and go build reasonable switch software? :) | 22:45 |
| jroll | JoshNang: see the swift thing I posted about 5 lines up ^ | 22:45 |
| NobodyCam | brb ...fft | 22:46 |
| JoshNang | on the topic of broken packages, we ran into some bugs with sql-alchemy 0.9.5. can't remember if that was brought up in this channel or not. apparently nova hit them already too | 22:46 |
| JoshNang | jroll: ha you beat me to the swift room by like 30s | 22:46 |
| *** boris-42 has quit IRC | 22:46 | |
| *** romcheg has joined #openstack-ironic | 22:46 | |
| jroll | 15:46:12 +notmyname | jroll: you had me at "we're happy to write the code" ;-) | 22:47 |
| jroll | easy enough | 22:47 |
| JoshNang | sweet. i'll throw up a patch shortly. | 22:47 |
| devananda | Mikhail_D_wk: hi! want to ping you re your tempest API work here: https://review.openstack.org/#/c/71476/ | 22:48 |
| jroll | JoshNang: I just saw https://review.openstack.org/#/c/102306/ | 22:49 |
| jroll | JoshNang: so, I'm in progress on a spec for "support long-running deploy ramdisks"... which includes this | 22:49 |
| devananda | Mikhail_D_wk: we're moving all the tempest baremetal api tests under /admin/ as requested by QA team -- patch is here: https://review.openstack.org/#/c/100989/ -- these may conflict since your patch is addign a new file | 22:49 |
| JoshNang | jroll: ah. i had figured that's what prompted the thoughts on power status | 22:49 |
| jroll | JoshNang: yeahhhhhh. trying to decide if I should trump yours or go side by side or what | 22:50 |
| *** eghobo has quit IRC | 22:50 | |
| JayF | I vote jroll's trumps JoshNang's | 22:50 |
| jroll | mine is also only 30% done or so | 22:51 |
| *** Penick has quit IRC | 22:51 | |
| JayF | then shamelessly steal JoshNang's work, like a true genius | 22:51 |
| jroll | I'm just going to start riding bart for like, 4-6 hours a day. I've been trying to work on this spec all day - as opposed to finishing an entire spec on the train this morning | 22:51 |
| JoshNang | :O | 22:51 |
| *** romcheg has quit IRC | 22:52 | |
| JoshNang | jroll: frankly i like it going in validation | 22:52 |
| JoshNang | there's cooler things we can do in there | 22:52 |
| jroll | heh, ok | 22:52 |
| jroll | yeah | 22:52 |
| jroll | like, 'drivers figure out whatever the heck they want in validation' | 22:53 |
| JoshNang | +1 | 22:53 |
| adam_g | NobodyCam, did you ever figure out if it was the same bug you were hitting with other drivers? re https://review.openstack.org/#/c/91719/ | 22:57 |
| *** Penick has joined #openstack-ironic | 22:58 | |
| NobodyCam | looks | 22:58 |
| NobodyCam | adam_g: it was "other" | 22:59 |
| *** boris-42 has joined #openstack-ironic | 23:02 | |
| adam_g | NobodyCam, ah, ok | 23:03 |
| NobodyCam | :-p | 23:06 |
| *** Penick has quit IRC | 23:11 | |
| *** ifarkas has quit IRC | 23:13 | |
| devananda | adam_g: what do you think of a tempest config option to disable all the admin/* tests | 23:13 |
| adam_g | devananda, what for? | 23:14 |
| devananda | adam_g: let's say I am running a "bare metal cloud" and you want to test that cloud for feature compatibility | 23:15 |
| openstackgerrit | A change was merged to openstack/ironic-python-agent: No longer recommend use of ipa-advertise-url https://review.openstack.org/102371 | 23:15 |
| devananda | adam_g: you won't have access to ironic's API to perform any CRUD operations | 23:15 |
| devananda | adam_g: but you still want to run the scenario tests | 23:15 |
| devananda | adam_g: or let's say that I want to run those internally and publish the results, but I haven't enabled the "fake" driver -- so creating a ndoe with test-generated (fake) data is going to cause my conductors to spew errors | 23:16 |
| jroll | oh god we're creating work for people now | 23:16 |
| adam_g | devananda, you'd just exclude those tests or run the individual tests you are interested in via testr or whatever runner | 23:16 |
| devananda | jroll: LOL | 23:17 |
| jroll | :D | 23:17 |
| devananda | adam_g: that's what i mean. there's no way to exclude those tests, afaict, today | 23:17 |
| adam_g | devananda, oh actually | 23:18 |
| devananda | adam_g: if you enable ironic's tests, you get, at minimum, all the api tests. and if you set [baremeta] driver_enabled=True, ten you also get the scenario tests | 23:18 |
| devananda | or have I misunderstood | 23:18 |
| *** Penick has joined #openstack-ironic | 23:18 | |
| adam_g | devananda, admin tests would be skipped if tempest.conf didnt have proper admin crednetials defined | 23:18 |
| devananda | adam_g: oh | 23:18 |
| devananda | neat | 23:18 |
| devananda | adam_g: anyhow, take a look at my comment on https://review.openstack.org/#/c/74065/11 when you get a moment | 23:19 |
| adam_g | devananda, speaking of the crud tests + fake driver.. having spent some time in the nova API tests, i think making those support running against real drivers would not be against precedent | 23:19 |
| devananda | adam_g: um... that doesn't make any sense to me. how? | 23:19 |
| adam_g | devananda, most of the current API tests depend on real drivers | 23:19 |
| devananda | adam_g: a real virt driver != a real bare metal driver with a real piece of hardware | 23:20 |
| adam_g | devananda, maybe not in the case of devstack-gate | 23:21 |
| devananda | adam_g: you're thinking of third party CI with real hardware? | 23:21 |
| adam_g | devananda, no, just the fact that the baremetal tests are the only API tests relying on a fake driver, and thats caused some concern among the tempest folk. the idea that the API tests should run against any cloud regardless of configured driver | 23:22 |
| devananda | adam_g: i think that's a messaging failure on our part, which i'm happy to help clarify | 23:23 |
| devananda | in part, moving those tests to /admin/ should help, i think | 23:23 |
| devananda | and my suggestion on 74065 should help, too | 23:23 |
| adam_g | devananda, see matt's comments @ https://review.openstack.org/#/c/100989/1..1/tempest/api/baremetal/README.rst | 23:23 |
| devananda | adam_g: is there a ML thread? if not, care to start one? | 23:23 |
| *** mdorman has quit IRC | 23:23 | |
| * devananda looks | 23:24 | |
| devananda | ahh | 23:24 |
| *** eghobo has joined #openstack-ironic | 23:24 | |
| devananda | yah. misunderstanding about what it means to "use ironic" | 23:24 |
| devananda | "functional verification of my OpenStack deployment with Ironic" ===>> the scenario tests which exercise the Nova API | 23:25 |
| *** eghobo has quit IRC | 23:25 | |
| *** eghobo has joined #openstack-ironic | 23:25 | |
| adam_g | devananda, your comments on 74065 sort of relate to what i was proposing to matt. we update the tempest CRUD tests to support, say, testing against pxe_ipmi provided the admin makes details of the available nodes available somehow. default staying fake with no additional data requirements | 23:29 |
| devananda | adam_g: what will that API test actually do? | 23:30 |
| devananda | adam_g: i mean, if I supply tempest with IPMI creds for a unit of hardware, what will the tempest CRUD tests do that is any different than if it had the fake driver? | 23:31 |
| adam_g | devananda, the same thing they'd do with the fake driver, except they'd actually pass without conductor spewing errors, in case someone actually wanted to go through the trouble of running them with the non-default fake. | 23:33 |
| devananda | adam_g: what is the purpose? what additional functionality would be getting tested from the API side? | 23:34 |
| adam_g | devananda, nothing. :) i'm just thinking out loud as to how we can help make it all fit better within the context of tempest. | 23:35 |
| devananda | adam_g: incidentally, running this against an operational cloud would mean the operator must first delete a node from that cloud .... | 23:35 |
| devananda | adam_g: which probably isn't something folks are thinking about | 23:35 |
| takadayuiko | devananda: Hi, sorry for late reply. I went home and slept :P | 23:36 |
| devananda | adam_g: or having additional hardware accessible by ironic, in that cloud, that isn't available for the cloud itself, which seems just as odd | 23:36 |
| adam_g | devananda, yeah. | 23:36 |
| takadayuiko | devananda: I did baremetal provisioning using command "ironic node-set-provision-state" and I failed last week but I've succeed :) | 23:38 |
| devananda | takadayuiko: not using "nova boot"? | 23:39 |
| takadayuiko | devananda: No, just using "node-set-provision-state" without "nova boot". | 23:40 |
| devananda | takadayuiko: are you using neutron, or external dhcp, or ...? | 23:41 |
| takadayuiko | devananda: I did that reffering this blog. http://ma.ttwagner.com/bare-metal-deploys-with-devstack-and-ironic/ | 23:41 |
| takadayuiko | takadayuiko: Yes, using neutron, dnsmasq(not external DHCP server) | 23:42 |
| devananda | takadayuiko: ok, so that blog post describes using external dnsmasq (not neutron) to serve images | 23:43 |
| *** Penick has quit IRC | 23:45 | |
| devananda | takadayuiko: when using "nova boot", nova will coordinate with neutron to set up DHCP for the instance. that blog describes some steps to do this manually. anyhow, I'm glad to hear you got node-set-provision-state working! | 23:45 |
| devananda | matty_dubs|gone: ^ you may want to update your blog post there with the new option :) | 23:45 |
| devananda | I should also be tagging a new release of the client this week to get that option into pip, fwiw | 23:46 |
| takadayuiko | devananda: Oh, I misunderstood. I thought my neutron was used... following the blog, I killed the process of originally dnsmasq and I booted dnsmasq independently. Is that reason why "No VIFs found for node xxx" error message was shown? | 23:46 |
| devananda | yes | 23:46 |
| takadayuiko | devananda: Ah, thank you. I could check Ironic works well, so I'll try to use Ironic via Nova :) | 23:48 |
| devananda | takadayuiko: when nova handles the deployment, it coordinates between neutron VIF and physical port in Ironic. see https://github.com/openstack/ironic/blob/master/ironic/nova/virt/ironic/driver.py#L613 | 23:48 |
| *** Penick has joined #openstack-ironic | 23:52 | |
| takadayuiko | devananda: Thank you so much :) | 23:53 |
| jroll | devananda, adam_g, I'd really love for infra to have a pool of BM nodes for "real" tempest testing | 23:53 |
| NobodyCam | jroll: sound like a great third party test! have a spare raq? | 23:54 |
| jroll | unfortunately, no, not right now :( | 23:55 |
| NobodyCam | hehehe | 23:55 |
| jroll | we do have a QE environment | 23:55 |
| jroll | for both nova and ironic | 23:55 |
| JayF | We tried to do third party CI for the IPA build, was going to use one of our OnMetal nodes for it and everything :) | 23:55 |
| JayF | but instead we're actually integrated with -infra | 23:56 |
| jroll | and I still don't understand why rax doesn't submit third party CI results for nova (and now for ironic) | 23:56 |
| JayF | (assuming this build finally works, zuul queued it for the first time just now) | 23:56 |
| JoshNang | JayF: \o/ | 23:56 |
| jroll | JayF: we should still do third-party CI for the agent_* drivers, at the very least | 23:56 |
| jroll | JayF: I would even argue for all the drivers | 23:56 |
| jroll | JayF: but I'm not the one paying for hardware :) | 23:57 |
| devananda | adam_g: another problem -- as soon as tempest enrolled any real hardware, nova would be able to consume it, yanking it out of tempest's hands | 23:57 |
| devananda | adam_g: and leading to random failures of the tempest tests -- and of nova | 23:57 |
| *** harlowja_ has joined #openstack-ironic | 23:58 | |
| jroll | devananda: how... does that wokr? | 23:58 |
| jroll | work | 23:58 |
| devananda | jroll: it doesn't | 23:58 |
| jroll | I mean, how does nova just take over the hardware? | 23:58 |
| devananda | jroll: the context is: point tempest at ironic in a running cloud. run CRUD tests against ironic's API. | 23:59 |
| devananda | my point is, as soon as you create a resource in ironic, nova may see it | 23:59 |
| devananda | and if a user of that cloud says "nova boot" the scheduler could pick the node you just added | 23:59 |
| jroll | devananda: oh. no. why would you point it at a running cloud that others might use :| | 23:59 |
| devananda | and then the tempest test is goign to be mighty confused | 23:59 |
| NobodyCam | I'm sure I have some old cobalt raq's (http://www.tech.proact.co.uk/i/sun_cobalt_raq_550.jpg) I could lend. | 23:59 |
| jroll | devananda: just... make a cell | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
