| *** rameshg87 has joined #openstack-ironic | 00:29 | |
| openstackgerrit | Josh Gachnang proposed a change to openstack/ironic-python-agent: Add versioning to Agent decommission https://review.openstack.org/106859 | 00:34 |
|---|---|---|
| *** hemna is now known as hemna_ | 00:43 | |
| openstackgerrit | Michael Davies proposed a change to openstack/ironic: Review fixes from Nova scheduler reviews https://review.openstack.org/107316 | 00:58 |
| mrda | NobodyCam: that took longer than expected (@property can only have one param :) but when you have a moment, 107316 is ready for review. | 01:00 |
| *** foexle_ has joined #openstack-ironic | 01:06 | |
| openstackgerrit | Ruby Loo proposed a change to openstack/ironic: Add drivers.base.BaseDriver.get_properties() https://review.openstack.org/107092 | 01:07 |
| openstackgerrit | Ruby Loo proposed a change to openstack/ironic: Implement API to get driver properties https://review.openstack.org/107096 | 01:08 |
| *** foexle has quit IRC | 01:10 | |
| NobodyCam | lifeless: you see the failed test on 107511 | 01:10 |
| NobodyCam | looks like https://github.com/openstack/nova/blob/master/nova/tests/compute/test_compute_mgr.py#L1815 needs a update too | 01:10 |
| lifeless | NobodyCam: this is why I want someone to pick the patch up and run with it | 01:11 |
| NobodyCam | lol... ack | 01:11 |
| rloo | NobodyCam: thx for rechecking 107092 & 107096. I "fixed" it I hope, but not sure why it caused sphinx to barf. | 01:13 |
| NobodyCam | rloo: ya that was very odd error | 01:17 |
| *** rameshg87 has left #openstack-ironic | 01:41 | |
| *** nosnos has joined #openstack-ironic | 01:49 | |
| *** malini has quit IRC | 01:59 | |
| *** killer_prince is now known as lazy_prince | 02:18 | |
| *** geekyogi has joined #openstack-ironic | 02:32 | |
| *** rloo has quit IRC | 02:40 | |
| *** ramineni has joined #openstack-ironic | 02:59 | |
| *** Penick has joined #openstack-ironic | 03:01 | |
| *** vinbs has joined #openstack-ironic | 03:02 | |
| *** Penick has quit IRC | 03:05 | |
| *** Poornima has joined #openstack-ironic | 03:05 | |
| *** nosnos has quit IRC | 03:06 | |
| vinbs | Morning Ironic! | 03:21 |
| *** pcrews has quit IRC | 03:24 | |
| *** nosnos has joined #openstack-ironic | 03:33 | |
| *** rakesh_hs has joined #openstack-ironic | 03:37 | |
| Haomeng|2 | vinbs: morning:) | 03:52 |
| mrda | Hi Haomeng|2 and vinbs | 03:53 |
| Haomeng|2 | mrda: morning:) | 03:53 |
| mrda | \o | 03:53 |
| vinbs | Haomeng|2 , mrda have you come across this error anytime: "Returning exception string indices must be integers to caller" | 03:57 |
| vinbs | when I try to launch an instance I'm running into this error | 03:57 |
| Haomeng|2 | vinbs: can you paste the code? | 03:57 |
| openstackgerrit | Michael Davies proposed a change to openstack/ironic: Ironic nova driver to cache ironic client calls https://review.openstack.org/102695 | 03:58 |
| vinbs | Haomeng|2: you mean the logs? I'm using ironic juno code | 03:58 |
| Haomeng|2 | vinbs: I mean what code you run out such exception | 03:59 |
| Haomeng|2 | maybe this can help you - http://stackoverflow.com/questions/20084779/typeerror-string-indices-must-be-integers-while-parsing-json-using-python | 03:59 |
| vinbs | Haomeng|2 here's the traceback | 04:00 |
| vinbs | http://paste.openstack.org/show/86860/ | 04:00 |
| Haomeng|2 | ok | 04:00 |
| mrda | vinbs: what were you doing to trigger this? | 04:02 |
| mrda | do you have a commandline you can share? | 04:02 |
| vinbs | mrda: I run into this error when I launch an instance through the Horizon | 04:03 |
| Haomeng|2 | looks like instance['uuid'] is not integers | 04:03 |
| lifeless | mrda: replied, i hope. | 04:04 |
| mrda | cool (I hope :) | 04:04 |
| mrda | lifeless: so, are you happy with removing the 30 second check and no other changes? | 04:06 |
| mrda | lifeless: or are you stuck on caching being implemented in the python-ironicclient? | 04:06 |
| lifeless | mrda: no - expired tokens do need to be handled | 04:06 |
| lifeless | mrda: I'm pretty stuck on that | 04:06 |
| mrda | is token.expiry > now: request new token | 04:06 |
| lifeless | insufficient | 04:07 |
| vinbs | mrda, Haomeng|2 I do not have any other instance running prior to launching this instance (when I get the error) | 04:07 |
| lifeless | uhm, I seem to not be describing the situation well enough | 04:07 |
| mrda | hmmm, I disagree based on what I've read so far. | 04:07 |
| lifeless | mrda: here is the way tokens behave. Sometimes they go away in a graceful fashion. Other times the token store is deleted. | 04:08 |
| vinbs | mrda, HAomeng|2 and I can see that the instance which fails due to this error gets an id like 7c7af6ec-ed4c-4611-9d8e-247dd7f0956f | 04:08 |
| Haomeng|2 | vinbs: can you debug it, should be type error | 04:08 |
| Haomeng|2 | vinbs: yes, the uuid should be string, not integer | 04:08 |
| vinbs | Haomeng|2 so it might be a problem with the code I have? | 04:09 |
| lifeless | mrda: ok, so which of these axioms do you disagree with? | 04:09 |
| Haomeng|2 | vinbs: sorry, not sure, have to debug I think | 04:09 |
| lifeless | *) clients cannot tell if a token is valid | 04:09 |
| lifeless | *) servers are allowed to revoke tokens before their expiry date | 04:09 |
| lifeless | *) clients and servers may have clock skew | 04:09 |
| vinbs | Haomeng|2 okay.. I'll look deeper into it | 04:10 |
| Haomeng|2 | vinbs: ok, good luck:) | 04:10 |
| *** rakesh_hs has quit IRC | 04:11 | |
| mrda | lifeless: so I get this. I don't understand though why you think that implementing this in ironicclient is better than in the ironic_client_wrapper code | 04:11 |
| lifeless | mrda: because its not unique to the nova ironic driver | 04:11 |
| lifeless | mrda: its a global challenge that all users of ironic's python API have | 04:11 |
| mrda | how many programmatic users of python-ironicclient are there? | 04:12 |
| lifeless | at least 3 - os-cloud-config, nova's ironic driver, openstackclient (the last one is 'in principle') | 04:13 |
| lifeless | we'll have monitoring stuff for ironic sometime soon I sspect as well | 04:14 |
| *** lazy_prince is now known as killer_prince | 04:17 | |
| lifeless | plus I don't see how you can cleanly solve it in wrapper code since it depends on understanding the semantics of failures | 04:18 |
| mrda | I do think the current solution solves the problem | 04:18 |
| mrda | ...as much as doing it in ironicclient | 04:19 |
| lifeless | well, it doesn't solve the token revocation issue yet | 04:19 |
| *** bmahalakshmi has joined #openstack-ironic | 04:19 | |
| mrda | without talking to keystone, I don't think you can | 04:19 |
| mrda | no matter where that code might live | 04:20 |
| lifeless | you catch the validation failure, ask for a new token, and submit | 04:20 |
| lifeless | or maybe I'm confused about something here | 04:21 |
| mrda | well, i'm going to have to go back an re-read ironicclient code if you think that's possible | 04:22 |
| lifeless | I'm sure ironicclient will need to change | 04:22 |
| lifeless | but I really don't want to have to go and restart nova-compute if keystone has to revoke a bunch of tokens | 04:23 |
| lifeless | so we need this to cope | 04:23 |
| lifeless | it should be fairly straightforward: if the error is a keystone token error, we know it happened before any POST / PUT / PATCH action occured, so we have situation specific knowledge to permit a resubmission of the request, and we need to ask for a new token then submit it | 04:24 |
| lifeless | now, ironicclient may not have a way to ask for a new token yet - so we may need to add that (e.g. a callback the user of ironicclient can supply) | 04:24 |
| *** pradipta_away is now known as pradipta | 04:25 | |
| lifeless | I have to go pick up C | 04:27 |
| *** pcrews has joined #openstack-ironic | 04:30 | |
| *** malini has joined #openstack-ironic | 04:31 | |
| *** geekyogi has quit IRC | 04:45 | |
| *** pcrews has quit IRC | 04:49 | |
| *** rameshg87 has joined #openstack-ironic | 04:50 | |
| *** malini has quit IRC | 04:56 | |
| *** killer_prince is now known as lazy_prince | 05:10 | |
| *** malini has joined #openstack-ironic | 05:20 | |
| *** shausy has joined #openstack-ironic | 05:25 | |
| lifeless | mrda: back if you want to talk round this more | 05:32 |
| *** rakesh_hs has joined #openstack-ironic | 05:41 | |
| *** chuckC has joined #openstack-ironic | 05:43 | |
| *** jcoufal has joined #openstack-ironic | 05:57 | |
| *** malini has quit IRC | 06:02 | |
| *** Nisha has joined #openstack-ironic | 06:05 | |
| *** malini has joined #openstack-ironic | 06:06 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic: Imported Translations from Transifex https://review.openstack.org/106948 | 06:11 |
| *** malini has quit IRC | 06:11 | |
| *** bvivek has joined #openstack-ironic | 06:12 | |
| *** malini has joined #openstack-ironic | 06:12 | |
| openstackgerrit | Nisha Agarwal proposed a change to openstack/ironic-specs: Discover node properties at node-create/node-update https://review.openstack.org/100951 | 06:17 |
| *** k4n0 has joined #openstack-ironic | 06:22 | |
| openstackgerrit | Nisha Agarwal proposed a change to openstack/ironic-specs: Discover node properties at node-create/node-update https://review.openstack.org/100951 | 06:25 |
| *** pcrews has joined #openstack-ironic | 06:28 | |
| *** foexle_ has quit IRC | 06:29 | |
| *** ramineni1 has joined #openstack-ironic | 06:31 | |
| *** pleia2_ has joined #openstack-ironic | 06:33 | |
| *** lynxman_ has joined #openstack-ironic | 06:33 | |
| mrda | lifeless: I'm just going to focus on review comments this afternoon and come back to client auth tomorrow | 06:33 |
| *** viktors|afk has quit IRC | 06:34 | |
| *** Poornima has quit IRC | 06:34 | |
| *** d0ugal has quit IRC | 06:34 | |
| *** jrist has quit IRC | 06:34 | |
| *** krtaylor has quit IRC | 06:34 | |
| *** ramineni has quit IRC | 06:34 | |
| *** lynxman has quit IRC | 06:34 | |
| *** pleia2 has quit IRC | 06:34 | |
| *** mmitchell_ has quit IRC | 06:34 | |
| *** k4n0 has quit IRC | 06:34 | |
| lifeless | mrda: k | 06:34 |
| *** lynxman_ is now known as lynxman | 06:34 | |
| *** lynxman has quit IRC | 06:34 | |
| *** lynxman has joined #openstack-ironic | 06:34 | |
| *** mmitchell has joined #openstack-ironic | 06:34 | |
| *** Poornima has joined #openstack-ironic | 06:35 | |
| *** jrist has joined #openstack-ironic | 06:35 | |
| *** d0ugal has joined #openstack-ironic | 06:36 | |
| *** krtaylor has joined #openstack-ironic | 06:36 | |
| *** viktors has joined #openstack-ironic | 06:36 | |
| *** k4n0 has joined #openstack-ironic | 06:36 | |
| openstackgerrit | Haomeng,Wang proposed a change to openstack/ironic: Implements send-data-to-ceilometer https://review.openstack.org/72538 | 06:41 |
| *** foexle has joined #openstack-ironic | 06:44 | |
| *** bvivek has quit IRC | 06:48 | |
| *** bvivek2 has joined #openstack-ironic | 06:49 | |
| *** pcrews has quit IRC | 06:49 | |
| *** Nisha has quit IRC | 06:51 | |
| *** Haomeng|2 has quit IRC | 06:51 | |
| *** Haomeng has joined #openstack-ironic | 06:52 | |
| soren | /win 295 | 06:53 |
| soren | DOh | 06:53 |
| rameshg87 | lifeless: are you still around. just had a quick question for you :-) | 06:56 |
| *** ifarkas has joined #openstack-ironic | 06:59 | |
| lifeless | rameshg87: a little | 07:03 |
| rameshg87 | thanks lifeless. won't take much of your time. | 07:04 |
| rameshg87 | lifeless: this is regarding the virtual media deploy spec that we were discussing a few hours back | 07:05 |
| rameshg87 | lifeless: based on the last discussion, your suggestion was to break down and propose as 3 specs | 07:05 |
| rameshg87 | lifeless: #1 - add a generic virtual media boot mechnaism for booting the node and passing information out-of-band | 07:05 |
| rameshg87 | lifeless: #2 - replace the "pxe" part of the current pxe+iscsi deploy solution and bring up a vmedia+iscsi deploy solution | 07:06 |
| *** pradipta is now known as pradipta_away | 07:06 | |
| rameshg87 | lifeless: #3 - propose the (currently proposed) baremetal deploy solution from swift in a third spec, in a new vmedia+bm_deploy_swift deploy solution | 07:07 |
| lifeless | 1) was ilo specific | 07:07 |
| rameshg87 | lifeless: yes, #1 was ilo specific | 07:08 |
| rameshg87 | lifeless: #1 which can be used by any deploy driver with ilo | 07:08 |
| lifeless | 1) would deliver ilo w/iscsi | 07:08 |
| lifeless | so ilo native power management, virtual media boot, virtual media token handoff | 07:09 |
| rameshg87 | lifeless: #1 is not a deploy driver by itself, just a mechanism to boot up the node and pass information out-of-band which can be used by any driver | 07:09 |
| rameshg87 | lifeless: yes | 07:09 |
| lifeless | its a deploy module | 07:09 |
| rameshg87 | lifeless: #2 and #3 are deploy drivers | 07:09 |
| lifeless | the 2 and 3 you have above is slightly different to what I proposed | 07:09 |
| lifeless | 1) IMO includes the 2) you have | 07:10 |
| lifeless | the 2) I was saying was making it possible to mix different boot methods with deploy code | 07:10 |
| lifeless | (and vice versa) | 07:10 |
| lifeless | internal refactoring to make it possible to use a different deploy solution | 07:10 |
| lifeless | 3) would use that to do swift for ilo+vmedia or pxe+ipmi | 07:11 |
| rameshg87 | lifeless: so do you suggest to have swift for pxe+ipmi as well. | 07:12 |
| lifeless | It would be a natural consequence, if we decide swift support makes sense | 07:13 |
| lifeless | its not obvious that it does | 07:14 |
| rameshg87 | lifeless: basically your suggestion is to modularize the deploy solution so that ultimately after everything ( deploy solution = boot method + deployment engine ) | 07:14 |
| lifeless | given the already existing option of IPA which does swift | 07:14 |
| rameshg87 | lifeless: am i correct ? | 07:14 |
| rameshg87 | lifeless: so that we can mix match boot methods and deployment engines to create different deployment engines | 07:15 |
| rameshg87 | lifeless: currently the only thing available is "pxe" for boot method and "iscsi" for deployment engine | 07:15 |
| rameshg87 | lifeless: typo above "lifeless: so that we can mix match boot methods and deployment engines to create different deployment *SOLUTIONS*" | 07:16 |
| *** jistr has joined #openstack-ironic | 07:18 | |
| lifeless | yes | 07:18 |
| lifeless | we have a bunch of modularity there already | 07:18 |
| rameshg87 | lifeless: yeah. | 07:20 |
| *** viktors has quit IRC | 07:22 | |
| *** kpavel has quit IRC | 07:23 | |
| rameshg87 | lifeless: we wanted to see if we can make something for juno | 07:23 |
| rameshg87 | lifeless: we can add vmedia boot mechanism (booting with vmedia + passing information out-of-band) as it is mostly approved. | 07:24 |
| rameshg87 | lifeless: i can propose to do vmedia + bm deploy in a modular way for now, as the solution is ready tested | 07:25 |
| rameshg87 | lifeless: we would also propose vmedia + iscsi in design spec, but i doubt if it will get approved as it will involve some refactoring on the existing code | 07:26 |
| rameshg87 | lifeless: is it okay if we propose the spec for refactoring and subsequently vmedia+iscsi, and do it in K release. does that look okay to you ? | 07:26 |
| *** romcheg1 has joined #openstack-ironic | 07:27 | |
| *** Mikhail_D_ltp has joined #openstack-ironic | 07:32 | |
| lifeless | I am confused | 07:33 |
| openstackgerrit | Michael Davies proposed a change to openstack/ironic: Review fixes from Nova scheduler reviews https://review.openstack.org/107316 | 07:33 |
| lifeless | what I'm proposing is vastly less code, much easier to land for juno | 07:33 |
| *** viktors has joined #openstack-ironic | 07:35 | |
| rameshg87 | lifeless: possible to code by juno timeframe, but no new specs(or proposals) in ironic will be accepted as per my knowledge for juno release | 07:36 |
| rameshg87 | lifeless: am i correct ? | 07:36 |
| lifeless | thats a question for devananda | 07:37 |
| lifeless | but this spec isn't approved yet anyway | 07:37 |
| lifeless | breaking it into three subsidiary specs doesn't seem like a reason to not accept part of it | 07:37 |
| *** harlowja is now known as harlowja_away | 07:41 | |
| *** geekyogi has joined #openstack-ironic | 07:42 | |
| rameshg87 | lifeless: i will discuss with devananda and get back regarding what all can be accommodated and get back. | 07:46 |
| rameshg87 | lifeless: meanwhile i will just start working on breaking down specs | 07:46 |
| rameshg87 | lifeless: thanks .. | 07:46 |
| *** bvivek2 has quit IRC | 07:57 | |
| openstackgerrit | Haomeng,Wang proposed a change to openstack/ironic: Implements send-data-to-ceilometer https://review.openstack.org/72538 | 07:58 |
| *** pleia2_ is now known as pleia2 | 08:04 | |
| *** derekh_ has joined #openstack-ironic | 08:08 | |
| *** kpavel has joined #openstack-ironic | 08:10 | |
| *** malini has quit IRC | 08:12 | |
| *** rwsu has quit IRC | 08:13 | |
| *** lucasagomes has joined #openstack-ironic | 08:23 | |
| *** bmahalakshmi has quit IRC | 08:24 | |
| *** bvivek has joined #openstack-ironic | 08:30 | |
| *** bmahalakshmi has joined #openstack-ironic | 08:30 | |
| *** ndipanov has joined #openstack-ironic | 08:36 | |
| *** pelix has joined #openstack-ironic | 08:38 | |
| *** martyntaylor has joined #openstack-ironic | 08:40 | |
| *** ndipanov has quit IRC | 08:40 | |
| lucasagomes | lifeless, morning/evening... can you remove the -2 here? https://review.openstack.org/#/c/86092/ spec is already approved | 08:42 |
| *** athomas has joined #openstack-ironic | 08:42 | |
| mrda | lucasagomes: If I ask nicely will lifeless remove any -ve votes? :-) | 08:43 |
| lucasagomes | mrda, haha you can try :P | 08:43 |
| mrda | (and good morning to you lucasagomes btw) | 08:43 |
| lucasagomes | mrda, morning buddy, how it's going? | 08:43 |
| mrda | good - you coming to midcycle? | 08:43 |
| lucasagomes | mrda, yeah, I am | 08:43 |
| mrda | Great! Looking forward to hanging out with you again! | 08:44 |
| lucasagomes | same here, are you going for pizza on sunday right? | 08:44 |
| mrda | f'sure - I arrive Sat night, so I'm up for it | 08:44 |
| lucasagomes | I will try to make it, if nothing bad happens, no delays etc | 08:44 |
| lucasagomes | ah great | 08:44 |
| mrda | I need the Sunday to get me in the right TZ | 08:45 |
| lucasagomes | yeah hah I hear you | 08:45 |
| dtantsur|afk | Morning Ironic :) | 08:58 |
| mrda | hey dtantsur|afk | 08:59 |
| *** dtantsur|afk is now known as dtantsur | 08:59 | |
| dtantsur | mrda, good evening :) | 08:59 |
| dtantsur | lucasagomes, morning :) you know, what I am going to ask you, right? ;) | 09:00 |
| lucasagomes | dtantsur, heh yeah | 09:00 |
| ramineni1 | dtantsur: hi, morning :) | 09:01 |
| dtantsur | ramineni1, hi | 09:04 |
| ramineni1 | dtantsur: regarding your comments on https://review.openstack.org/#/c/89500/25/etc/ironic/ironic.conf.sample | 09:05 |
| ramineni1 | dtantsur: here we meant ilo_client_timeout , actually for timeout to be specified for IloClient in proliantutils module . | 09:06 |
| ramineni1 | dtantsur : so, named it that way | 09:06 |
| dtantsur | ramineni1, it does not matter for Ironic itself, how you used. I'm just worried about inconsistent naming | 09:07 |
| lifeless | lucasagomes: my comment has nothing to do with the spec | 09:08 |
| lucasagomes | lifeless, yup, I answer that a bit back | 09:08 |
| lifeless | lucasagomes: devananda said | 09:08 |
| lucasagomes | lifeless, there's an abstraction layer there that checks wheteher the driver does have the mgmt or not | 09:08 |
| lifeless | " this whole patch series needs to land at once. Partial changes to some drivers will be very detrimental without the corresponding API changes, which are at the tail of this patch series, and are NOT approved yet." | 09:08 |
| lucasagomes | yup | 09:08 |
| lucasagomes | but that's no problem, cause there's a backward comp layer there, if the mgmt interface is not implemented it uses the vendor_passthru | 09:09 |
| lucasagomes | so patches can be merged separately | 09:09 |
| lucasagomes | deva already removed his -2 | 09:09 |
| lifeless | so what detrimental effect is devananda pointing out? | 09:09 |
| lucasagomes | lifeless, https://review.openstack.org/#/c/86092/20/ironic/conductor/utils.py | 09:09 |
| lucasagomes | lifeless, oh... so, I can put the API patch in front of the series | 09:12 |
| lucasagomes | lifeless, would that solve his concern you think? | 09:12 |
| lifeless | lucasagomes: I'm not sure | 09:12 |
| lucasagomes | I will ask him later | 09:12 |
| lifeless | I've removed my -2, I don't want to block for no reason | 09:12 |
| lucasagomes | lifeless, ack, I will sync with him about it. Thanks | 09:13 |
| ramineni1 | dtantsur: yes , but its not actually prefixing ilo to the variable , but want to specify its actually the timeout to be specified for IloClient, do u still feel need to change the naming | 09:13 |
| lifeless | but I'm very firmly of the opinion we shouldn't land things unless we're happy with the patch in isolation | 09:13 |
| lucasagomes | +1 | 09:13 |
| lifeless | because we can't predict what will happen (the gate might wedge, for instance) | 09:13 |
| dtantsur | ramineni1, it's quite obvious, that for ILO driver you use ILO client :) yes, I feel like that | 09:13 |
| lucasagomes | lifeless, +1, I think it's fine. But I will double check | 09:14 |
| ramineni1 | dtantsur: ok ..will change it :) | 09:15 |
| *** mkerrin has quit IRC | 09:16 | |
| *** Nisha has joined #openstack-ironic | 09:17 | |
| Nisha | dtantsur: Hi | 09:18 |
| *** mkerrin has joined #openstack-ironic | 09:23 | |
| *** martyntaylor has left #openstack-ironic | 09:29 | |
| dtantsur | Nisha, hi! I didn't quite get your questions, sorry. What do you mean by blocked here? | 09:30 |
| lucasagomes | dtantsur, reviewed, looking good | 09:33 |
| lucasagomes | dtantsur, few concerns, about how to know if the discovery is enabled for a specific driver (suggestion inline) and if we should make the activation/deactivation async | 09:34 |
| lucasagomes | since some drivers may need to talk to the BMC | 09:34 |
| *** Nisha has quit IRC | 09:35 | |
| dtantsur | lucasagomes, I guess it should be async, it even seems to me I put it to spec :) | 09:36 |
| dtantsur | will see your comments, thanks | 09:36 |
| lucasagomes | dtantsur, right it was retuning 200 after the put | 09:36 |
| lucasagomes | so it should return 202 (accepted) | 09:36 |
| lucasagomes | to indicate it's async | 09:36 |
| dtantsur | aaaah | 09:36 |
| openstackgerrit | Anusha Ramineni proposed a change to openstack/ironic: Add IloDriver and its IloPower module https://review.openstack.org/89500 | 09:47 |
| openstackgerrit | Syed Ismail Faizan Barmawer proposed a change to openstack/ironic-specs: UEFI support for Ironic deploy drivers https://review.openstack.org/99850 | 09:50 |
| *** nosnos has quit IRC | 09:54 | |
| *** romcheg2 has joined #openstack-ironic | 09:54 | |
| dtantsur | lucasagomes, devananda, re https://review.openstack.org/#/c/107407/: reported https://bugs.launchpad.net/ironic/+bug/1343195 . If we can't support SQLite properly, I suggest not supporting it at all. | 09:56 |
| *** romcheg1 has quit IRC | 09:57 | |
| rameshg87 | lucasagomes, dtantsur, just had a quick question about a refactoring i am thinking | 09:58 |
| lucasagomes | rameshg87, hey sure | 09:58 |
| rameshg87 | lucasagomes, dtantsur, might not be that quick, but just wanted to check if it makes sense :-) | 09:58 |
| lucasagomes | dtantsur, yeah, well I think it's more like an openstack thing | 09:59 |
| lucasagomes | dtantsur, idk if it's our call to remove sqlite support like that | 09:59 |
| rameshg87 | lucasagomes, dtantsur, currently our pxe driver is not truly "pxe", it's actually "pxe+iscsi", uses pxe for booting and uses iscsi for deployment | 09:59 |
| lucasagomes | rameshg87, true | 09:59 |
| rameshg87 | lucasagomes, dtantsur, if i wanted to have a deploy driver which uses virtual media (vmedia) for booting and iscsi for deployment, i can make use of most of the code in there | 10:00 |
| rameshg87 | lucasagomes, dtantsur, each stage of the PXEDeploy contains some things related to "pxe" and some things related to "iscsi" | 10:01 |
| *** nosnos has joined #openstack-ironic | 10:01 | |
| *** bvivek has quit IRC | 10:01 | |
| lucasagomes | rameshg87, yup, we also have the TFTP factor as well our driver pretty much assume that PXE == TFTP | 10:02 |
| lucasagomes | iPXE change that so I had to do some refactoring | 10:02 |
| rameshg87 | lucasagomes, okay | 10:02 |
| lucasagomes | I bet the iscsi is something similar we should start refactoring that parts out of the pxe driver | 10:02 |
| dtantsur | lucasagomes, left one question is the spec. | 10:02 |
| lucasagomes | putting in a common directory that other drivers may use as well | 10:02 |
| rameshg87 | lucasagomes: exactly, that is what i want :-) | 10:03 |
| rameshg87 | lucasagomes: does it make sense if we split a deploy driver, so that deploy driver = BootManager + DeployManager | 10:03 |
| lifeless | hah, nova is picking an in-maintenance node. | 10:03 |
| lifeless | wtf | 10:03 |
| dtantsur | Oo | 10:04 |
| lifeless | I will poke around that tomorrow, but that might explain some things :> | 10:04 |
| rameshg87 | lucasagomes: each of BootManager and DeployManager has their own actions to perform for each stages of deploy - validate, deploy, tear_down, prepare, cleanup | 10:04 |
| rameshg87 | lucasagomes: does that make sense ? | 10:04 |
| openstackgerrit | Michael Davies proposed a change to openstack/ironic: Review fixes from Nova scheduler reviews https://review.openstack.org/107316 | 10:05 |
| rameshg87 | lucasagomes: the actual deploy driver will just call BootManager's and DeployManager's corresponding method | 10:06 |
| lucasagomes | dtantsur, yeah I can only think about having it in the db :/ | 10:06 |
| dtantsur | lucasagomes, but where? | 10:07 |
| lucasagomes | lifeless, ew, yeah shouldn't happen :/ | 10:07 |
| lucasagomes | rameshg87, hmm I have to think about... you mean having another driver interface for boot manager? | 10:07 |
| lucasagomes | dtantsur, yeah thinking... cause drivers doesn't have it's on model in the db | 10:08 |
| rameshg87 | lucasagomes: sort of, because from each of the actual deploy steps, there are certain steps belonging to the boot manager alone .. | 10:09 |
| dtantsur | lucasagomes, if we are to create a new DB model, I would rather drop it :) but enabling 2 drivers to do the discovery may lead to a disaster | 10:10 |
| rameshg87 | lucasagomes: some high level method calls BootManager's method followed by DeployManager's method | 10:10 |
| *** nosnos has quit IRC | 10:10 | |
| lucasagomes | dtantsur, somewhere we have to indicate if it's enabled no? | 10:10 |
| *** romcheg1 has joined #openstack-ironic | 10:10 | |
| dtantsur | lucasagomes, I think so | 10:10 |
| dtantsur | and it should be something global | 10:11 |
| lucasagomes | yeah that's why I only can think about db, cause even if we talk about using config options | 10:11 |
| rameshg87 | lucasagomes: ultimately deploy_driver.deploy() calls BootManager.deploy() and then calls DeployManager's deploy() [and returns whatever it is returning] | 10:11 |
| lucasagomes | they are not global | 10:11 |
| *** romcheg2 has quit IRC | 10:11 | |
| lucasagomes | rameshg87, right, it makes sense... but is it something that we want to have in juno? | 10:11 |
| dtantsur | oooh | 10:11 |
| lucasagomes | cause that will be hard man | 10:11 |
| dtantsur | lucasagomes, should we discuss it more with devananda and folks this evening? | 10:12 |
| *** nosnos has joined #openstack-ironic | 10:12 | |
| lucasagomes | dtantsur, I think so... maybe drivers need to have their db model as well, since they even have their own endpoint, vendor_passthru etc | 10:12 |
| lucasagomes | it makes sense to have the driver entity representation on the db | 10:12 |
| lucasagomes | as well as we have in the api | 10:13 |
| dtantsur | lucasagomes, wow-wow. this looks like a big task. I wonder if it's an acceptable compromise not to do this check | 10:13 |
| dtantsur | lucasagomes, put then set_discovery_enabled will no longer be idempotent | 10:13 |
| lucasagomes | dtantsur, yeah we can for the first version simply have no check like that | 10:13 |
| lucasagomes | I'm fine with that | 10:14 |
| openstackgerrit | Victor Sergeyev proposed a change to openstack/ironic: POC: sync models with migrations test https://review.openstack.org/107628 | 10:14 |
| openstackgerrit | Victor Sergeyev proposed a change to openstack/ironic: POC: use metadata.create_all() to fill database https://review.openstack.org/107629 | 10:14 |
| lucasagomes | we document it as an experimental feature etc | 10:14 |
| dtantsur | lucasagomes, ok. I'll add 2 TODO's to the text, stating it should be done later and why | 10:14 |
| lucasagomes | ack | 10:14 |
| dtantsur | brb | 10:15 |
| rameshg87 | lucasagomes: don't know was just thinking before i want to put it in a spec. do you think it will be too late for juno ? :D | 10:18 |
| *** martyntaylor1 has joined #openstack-ironic | 10:19 | |
| lucasagomes | rameshg87, I think that if we are going to introduce a new interface for the drivers in juno | 10:20 |
| lucasagomes | + having to change all the existing drivers | 10:20 |
| lucasagomes | it will be late | 10:20 |
| lucasagomes | because we are planning on landing not only the iLO driver | 10:20 |
| lucasagomes | but also Drac and IPA | 10:20 |
| lucasagomes | and this are ongoing work, so it will all conflict | 10:20 |
| lifeless | lucasagomes: so drac and IPA are orthogonal | 10:21 |
| lifeless | lucasagomes: IPA needs a boot mechanism too, right? | 10:21 |
| lucasagomes | lifeless, they have a deploy interface as well afair | 10:21 |
| lucasagomes | lemme check the code | 10:21 |
| lifeless | lucasagomes: the more I think about this the more I'm convinced we have three dimensions that vary independently | 10:21 |
| lifeless | lucasagomes: a) how do we control power, b) how do we get our code onto the machine - how do we boot it, c) what code we're expecting on the machine (IPA / deploy-ironic-init) | 10:22 |
| lifeless | lucasagomes: e.g. iLO + iLO virtualmedia + IPA should totally be a thing | 10:22 |
| lifeless | lucasagomes: but equally we could in principle do iLO + PXE + IPA | 10:23 |
| lucasagomes | I agree, IPA and ILO virtualmedia are deploy interfaces, where iLO is a power interface | 10:23 |
| lucasagomes | and I agree with rameshg87 thinking as well | 10:23 |
| lucasagomes | but I'm just wondering what can be make for _juno_ | 10:23 |
| lifeless | lucasagomes: well, I'm saying that IPA is a deploy interface, but iLO virtualmedia is a boot interface. | 10:23 |
| lifeless | lucasagomes: different things | 10:23 |
| lucasagomes | if we introduce a new interface for the drivers in this moment, I don't think it will make it to juno | 10:23 |
| mrda | ok, enough for me. Good night Ironic! | 10:24 |
| lifeless | lucasagomes: for Juno I'm proposing that we do iLO virtualmedia as subclass of the PXE deploy module | 10:24 |
| *** mrda is now known as mrda-away | 10:24 | |
| lucasagomes | right | 10:24 |
| lifeless | lucasagomes: (effectively, maybe a little pull-up into a common class) | 10:24 |
| lifeless | which should be trivial | 10:25 |
| rameshg87 | lucasagomes, lifeless, yes a common class might also make sense because pxe inheriting virtualmedia doesn't make true sense here :-) | 10:25 |
| rameshg87 | sorry virtualmedia inheriting pxe | 10:25 |
| lucasagomes | lifeless, rameshg87 yeah I think u guys are right the way it boots the machine != the way the machine gets deployed | 10:27 |
| lucasagomes | rameshg87, yup, the PXE driver is now bloated. It's all together PXE + TFTP + iSCSI | 10:27 |
| lifeless | PXE+TFTP is the boot component | 10:28 |
| lifeless | iSCSI is deploy | 10:28 |
| lifeless | and there's a niche thing in there about token hand-off | 10:28 |
| lucasagomes | lifeless, yeah well if you think about iPXE TFTP is only used for chainloading | 10:28 |
| lucasagomes | lifeless, the rest can all happen over other transport layer like HTTP | 10:28 |
| lucasagomes | that's why we kinda have to refactor that as well, make it more flexible at least | 10:28 |
| *** derekh_ has quit IRC | 10:31 | |
| lucasagomes | rameshg87, lifeless so we agreed that boot interface != deploy interface | 10:31 |
| lucasagomes | lifeless, rameshg87 but what we can make for J? | 10:31 |
| lucasagomes | can we keep only the deploy interface for this cycle, and introduce a new boot interface in K? | 10:32 |
| rameshg87 | lucasagomes, i think refactoring pxe might not be that difficult if we can quickly get a spec in (if it will be accepted) | 10:32 |
| viktors | dtantsur: hi! | 10:32 |
| lucasagomes | rameshg87, right, so other projects like nova already started -2ing new specs | 10:33 |
| lucasagomes | we are almost at the end of j-2 | 10:33 |
| lucasagomes | going to j-3 | 10:33 |
| lucasagomes | we have ~8 specs approved | 10:34 |
| lucasagomes | according to last devananda's email | 10:34 |
| lucasagomes | and they all need reviews etc, that's why I think it will be a bit hard | 10:34 |
| rameshg87 | lucasagomes: okay .. | 10:35 |
| lucasagomes | rameshg87, but as I said, I agree with the idea | 10:35 |
| lucasagomes | def we have to improve that abstraction | 10:35 |
| lucasagomes | just trying to be realistic about what can be achieved in this cycle | 10:35 |
| lucasagomes | lifeless, how is it in tripleO? are you guys still accepting new specs? | 10:37 |
| *** lazy_prince is now known as killer_prince | 10:38 | |
| lifeless | I don't think we can do the refactoring in juno | 10:38 |
| lifeless | but we can land a minimal virtualmedia ilo deploy driver that shares 99% of its code with pxe | 10:38 |
| lucasagomes | yeah | 10:38 |
| lucasagomes | +10000 | 10:38 |
| *** nosnos has quit IRC | 10:38 | |
| rameshg87 | lucasagomes, lifeless, okay. so just to make use of the "common" code and not to touch anything in "pxe", we might need to inherit from "pxe" ? | 10:38 |
| rameshg87 | lucasagomes, lifeless, ilo_vmedia_driver inherits from pxe and calls whatever it requires. eventhough logically it doesn't sound good, is it acceptable ? | 10:39 |
| lifeless | lets not confound spec (design) with impl | 10:40 |
| lucasagomes | rameshg87, I don't understand exactly all the bits and pieces needed for ilo media driver to tell that | 10:40 |
| lucasagomes | but if there's a common code we may want to put in a common place | 10:40 |
| lifeless | the spec thing here is to say that we want 99% code sharing and only diff being how it boots and how it hands tokens across | 10:40 |
| lucasagomes | that can be accessed by both drivers | 10:40 |
| *** derekh_ has joined #openstack-ironic | 10:40 | |
| *** killer_prince is now known as lazy_prince | 10:41 | |
| rameshg87 | lifeless: okay | 10:41 |
| lifeless | the impl thing is to pull pxe apart vertically into 99% common code and 1% truely-pxe/tftp-unique | 10:41 |
| lifeless | and plug in the 1% virtualmedia glue beside it | 10:41 |
| rameshg87 | lifeless: okay :-) | 10:41 |
| rameshg87 | lifeless, lucasagomes, thanks a lot for your thoughts | 10:43 |
| lucasagomes | rameshg87, yvw | 10:43 |
| *** dguerri is now known as _dguerri | 10:44 | |
| *** romcheg has quit IRC | 10:44 | |
| *** romcheg1 is now known as romcheg | 10:44 | |
| *** _dguerri is now known as dguerri | 10:46 | |
| *** Alexei_987 has joined #openstack-ironic | 10:46 | |
| viktors | lucasagomes: hi! Can I discuss with you an idea about initial database migration? | 10:47 |
| lucasagomes | viktors, can we talk in a bit? I'm going for lunch | 10:49 |
| openstackgerrit | Mikhail Durnosvistov proposed a change to openstack/ironic: Check whether specified FS is supported https://review.openstack.org/98102 | 10:50 |
| viktors | lucasagomes: ok, sure. | 10:50 |
| *** martyntaylor1 has quit IRC | 10:50 | |
| *** martyntaylor has joined #openstack-ironic | 10:51 | |
| dtantsur | viktors, hi! sorry, was out | 10:57 |
| viktors | dtantsur: no problem | 10:57 |
| viktors | dtantsur: as for our yesterday's discussion about migrations on SQLite - I want to show you the proof-of-concept, how to fill database from models | 10:59 |
| viktors | dtantsur: I suppose to create DB schema from models 1) - for testing, 2) - for installation on demand | 11:00 |
| *** ndipanov has joined #openstack-ironic | 11:00 | |
| viktors | dtantsur: what do you think about it? | 11:00 |
| *** ndipanov has quit IRC | 11:01 | |
| *** ramineni1 has quit IRC | 11:01 | |
| openstackgerrit | Victor Sergeyev proposed a change to openstack/ironic: Use oslo.db library https://review.openstack.org/42159 | 11:05 |
| openstackgerrit | Victor Sergeyev proposed a change to openstack/ironic: POC: use metadata.create_all() to fill database https://review.openstack.org/107629 | 11:05 |
| openstackgerrit | Victor Sergeyev proposed a change to openstack/ironic: POC: sync models with migrations test https://review.openstack.org/107628 | 11:05 |
| openstackgerrit | Victor Sergeyev proposed a change to openstack/ironic: Use opportunistic approach for migration testing https://review.openstack.org/107053 | 11:05 |
| *** dguerri is now known as _dguerri | 11:05 | |
| dtantsur | viktors, should be good, let me see | 11:06 |
| viktors | dtantsur: POC: use metadata.create_all() to fill database https://review.openstack.org/107629 | 11:06 |
| dtantsur | yeah, I see :) | 11:06 |
| *** lucasagomes is now known as lucas-hungry | 11:07 | |
| *** Haomeng|2 has joined #openstack-ironic | 11:08 | |
| dtantsur | lgtm actually | 11:09 |
| *** Haomeng has quit IRC | 11:10 | |
| viktors | dtantsur: thanks! I want to show this approach to lucas-hungry also | 11:10 |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Add newly_discovered column to Node object https://review.openstack.org/107389 | 11:11 |
| viktors | ad it still required oslo.db, which actuary -2'ed :( | 11:11 |
| dtantsur | viktors, how are things with it? does it make sense to give it a second try? | 11:12 |
| kpavel | Hi. Can anybody point me to the reference of the neutron configuration for ironic? thanks | 11:12 |
| viktors | dtantsur: I talked with devananda last night, he told, that he will re-review patch with oslo.db, because this oslo.db required for another changes | 11:14 |
| dtantsur | cool! | 11:14 |
| viktors | dtantsur: :) | 11:18 |
| *** martyntaylor has left #openstack-ironic | 11:19 | |
| *** _dguerri is now known as dguerri | 11:20 | |
| *** jcoufal has quit IRC | 11:22 | |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic-specs: Generic Hardware Discovery Bits https://review.openstack.org/107344 | 11:29 |
| dtantsur | lucas-hungry, romcheg, NobodyCam, hopefully addressed your comments ^^^ | 11:29 |
| * romcheg is looking | 11:29 | |
| *** rameshg87 has left #openstack-ironic | 11:32 | |
| romcheg | dtantsur, lucas-hungry: I'm not very familiar with different BMCs so it may be a stupid idea | 11:33 |
| romcheg | But is there a way to force IPMI credentials from inside the server? | 11:33 |
| romcheg | So when the discovery ramdisk is running it changes the ipmi creds | 11:34 |
| dtantsur | romcheg, I'm not familiar with IPMI at all, so I don't know... It would be nice to have actually. | 11:34 |
| romcheg | I also think there should be a way not only set driver specific params but also to read them | 11:35 |
| romcheg | Anyway, every driver at least should know the credentials to for the power management interface | 11:36 |
| romcheg | Discovering nodes without that information is useless IMO | 11:36 |
| romcheg | Because we cannot do anything with them after they were discovered | 11:36 |
| romcheg | Manually setting required params is not an option if we have a few hundreds of nodes | 11:37 |
| dtantsur | romcheg, well, you're right. That should be prototyped by somebody knowing the topic, though :( | 11:43 |
| romcheg | dtantsur: I think NobodyCam can help us :) | 11:43 |
| dtantsur | romcheg, he suggested cipher 0 (or how it is called) :D | 11:44 |
| *** lazy_prince has quit IRC | 11:47 | |
| openstackgerrit | Imre Farkas proposed a change to openstack/ironic-specs: DRAC management driver https://review.openstack.org/107033 | 11:47 |
| jroll | vinbs: did you get things sorted? looks like you're running an older nova... see https://github.com/openstack/nova/commit/ccf423333a52af9d650b2eba7199dd3a3c78f0a3 | 12:06 |
| jroll | morning ironic :) | 12:06 |
| * jroll makes coffee and ponders a BootManager thing | 12:07 | |
| *** shausy has quit IRC | 12:07 | |
| *** jdob has joined #openstack-ironic | 12:14 | |
| dtantsur | jroll, morning :) | 12:19 |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic-specs: Add deploy driver for ironic-python-agent https://review.openstack.org/98506 | 12:19 |
| jroll | dtantsur: morning :) fixed that for you ^ | 12:20 |
| vinbs | jroll: yes, I have nova from icehouse version and ironic drom juno version | 12:20 |
| dtantsur | jroll, cool! Will have a look after lunch | 12:20 |
| vinbs | jroll: I was hoping it would work | 12:20 |
| jroll | vinbs: it should mostly work... you'll need to pull that patch in at a minimum | 12:21 |
| jroll | vinbs: running nova from juno will definitely work :) | 12:21 |
| vinbs | jroll: will try just patching.. thanks :) | 12:21 |
| jroll | for some definition of "work" :) | 12:22 |
| jroll | no problem | 12:22 |
| kpavel | Can anybody point me to the neutron configuration reference for ironic? | 12:26 |
| jroll | kpavel: I'm not aware of any... but I don't use neutron | 12:27 |
| jroll | or I should say not in the way ironic does today :P | 12:28 |
| kpavel | jroll: If i'm using devstack to run ironic with virtual mocked nodes it uses neutron...thought just to make few changes to control real physical hardware, but no luck :( | 12:29 |
| *** ndipanov has joined #openstack-ironic | 12:29 | |
| *** vinbs has quit IRC | 12:29 | |
| jroll | kpavel: that should be right :/ | 12:29 |
| * jroll looks at a thing | 12:29 | |
| kpavel | jroll: The real physical node seems to be pxe booted, even can see prompt on the screen, but it doesn't aswer to ping | 12:30 |
| jroll | kpavel: got console logs? | 12:31 |
| kpavel | jroll: maybe you have a one good reference to "howto" install/configure ironic? :) | 12:31 |
| agordeev | romcheg: thx for the link | 12:32 |
| kpavel | jroll: where do i find them? it's physical machine. actually a blde.. | 12:32 |
| jroll | kpavel: not for the pxe driver, I don't, sorry :( | 12:32 |
| jroll | kpavel: might need to set up the ports in neutron like devstack does? https://github.com/openstack-dev/devstack/blob/master/lib/ironic#L334 | 12:32 |
| jroll | kpavel: console logs would be found by attaching to the console via ipmi or something | 12:33 |
| jroll | kpavel: if you're seeing a prompt, though... it might not be pxe booted? I'm not sure if the deploy ramdisk shows a prompt | 12:34 |
| jroll | need to step away for 10 minutes... brb | 12:35 |
| *** lucas-hungry is now known as lucasagomes | 12:39 | |
| kpavel | jroll: it's pxe booted. twice :) first from deploy ramdisk/kernel and after that from ramdisk/kernel. seems to be fine. | 12:40 |
| kpavel | jroll: maybe you know what is the expected network setup with the real network? | 12:41 |
| jroll | kpavel: the bare metal node needs to be able to reach ironic-api on port 6385, and ironic-conductor need to be able to mount a disk on the baremetal node over iscsi | 12:42 |
| *** jcoufal has joined #openstack-ironic | 12:44 | |
| jroll | kpavel: does this machine have ipmi? | 12:44 |
| jroll | lucasagomes: got a sec to talk about https://review.openstack.org/#/c/105590/ ? | 12:50 |
| jroll | lucasagomes: just wondering if I should also fix the config in devstack... or just the bug in ironicclient | 12:50 |
| kpavel | jroll: no, the machine is blade and i developed it's own power control interface similar to ipmi. the power control seems to work fine. | 12:54 |
| *** matty_dubs|gone is now known as matty_dubs | 12:54 | |
| lucasagomes | jroll, hey yes | 12:57 |
| lucasagomes | jroll, hmm well... to be honest I didn't look much into it, cleary our client should be more flexible and append the version if not specified | 12:57 |
| lucasagomes | and not append it if already specified | 12:57 |
| lucasagomes | jroll, but changing devstack should work both ways | 12:58 |
| lucasagomes | so changing devstack right now to workaround that problem seems grand | 12:58 |
| lucasagomes | IMO | 12:58 |
| lucasagomes | until we get the client to be more tolerant | 12:58 |
| jroll | lucasagomes: right... I'm going to put up both patches, I think | 12:58 |
| jroll | and land in order of: devstack -> client -> 105590 | 12:59 |
| lucasagomes | jroll, cool | 12:59 |
| lucasagomes | sounds good to me | 12:59 |
| *** dguerri is now known as _dguerri | 13:00 | |
| jroll | hmm | 13:00 |
| * jroll wonders if path.replace('/v1', '') is too hacky :P | 13:01 | |
| *** k4n0 has quit IRC | 13:01 | |
| lucasagomes | jroll, it is | 13:02 |
| lucasagomes | jroll, we can't just replace, use urlparse | 13:02 |
| lucasagomes | it will split the url, into address, args etc | 13:02 |
| jroll | right | 13:02 |
| lucasagomes | check if v1 is thre | 13:02 |
| lucasagomes | there* | 13:02 |
| jroll | going to check .endswith /v1 | 13:02 |
| jroll | or .endswith /v1/ | 13:02 |
| jroll | or like... rstrip('/'); rstrip('/v1') | 13:03 |
| jroll | I think is the right thing to do | 13:03 |
| lucasagomes | heh imo +1 for urlparse | 13:03 |
| lucasagomes | :P | 13:03 |
| jroll | ofc | 13:04 |
| jroll | we're already using urlparse | 13:04 |
| jroll | you get the whole path back | 13:04 |
| jroll | and someone might have apache in front and a weird subpath... like http://somehost:1234/ironic/v1 | 13:04 |
| lucasagomes | yeah | 13:04 |
| jroll | so urlparse().path is /ironic/v1 | 13:05 |
| jroll | but could also be /ironic/v1/ | 13:05 |
| jroll | on the bright side, now we won't need to rstrip('/') on every request :) | 13:05 |
| jroll | oh good, no tests for get_connection_params \o/ | 13:05 |
| *** Poornima has quit IRC | 13:06 | |
| lucasagomes | lol | 13:06 |
| *** _dguerri is now known as dguerri | 13:06 | |
| lucasagomes | :( | 13:06 |
| jroll | that means I don't need to update tests, right? ;) | 13:06 |
| lucasagomes | :P | 13:07 |
| *** athomas has quit IRC | 13:07 | |
| lucasagomes | be a good guy and create some tests | 13:07 |
| lucasagomes | heh | 13:07 |
| *** bmahalakshmi has quit IRC | 13:07 | |
| jroll | yeah, I am :P | 13:08 |
| *** athomas has joined #openstack-ironic | 13:11 | |
| *** Nisha has joined #openstack-ironic | 13:12 | |
| viktors | lucasagomes: around? | 13:16 |
| lucasagomes | viktors, hey yes | 13:16 |
| viktors | lucasagomes: I wanted to discuss patch https://review.openstack.org/107629 ( POC: use metadata.create_all() to fill database) | 13:17 |
| viktors | lucasagomes: do you have a time for this? | 13:17 |
| lucasagomes | viktors, yeah lemme take a look at the patch | 13:18 |
| viktors | lucasagomes: sure | 13:18 |
| lucasagomes | database is not my strongest, but let's do it :D | 13:18 |
| lucasagomes | viktors, so what is that patch doing exactly? (no commit msg :() | 13:19 |
| viktors | lucasagomes: yes, that my miss. The main idea of this patch is - allow to create DB schema from models for testing, and for initial installation on demand | 13:21 |
| viktors | lucasagomes: tis will be faster, that from migrations and suitable for SQLite | 13:21 |
| lucasagomes | right, well it sounds good, what are the cons? | 13:22 |
| lucasagomes | we don't execute all the migrations script | 13:22 |
| lucasagomes | to get to the final schema right? | 13:22 |
| lucasagomes | wondering if for tests... executing each migration script is what we actually want to do, to guarantee it's working | 13:22 |
| viktors | lucasagomes: yes, correct. We will use create_all() to get DB shema | 13:22 |
| lucasagomes | or we should at least have 1 test that create the schema with create_all() and one by executing all the scripts | 13:23 |
| lucasagomes | and compare if they are the same? | 13:23 |
| viktors | lucasagomes: as for migrations script - I suppose to use another approach for it | 13:23 |
| viktors | this will test migrations scripts on DB backents - https://review.openstack.org/107053 | 13:24 |
| * lucasagomes clicks | 13:25 | |
| viktors | lucasagomes: and this will test, that we will get same shema from migrations and from metadata.create_all() - https://review.openstack.org/107628 | 13:25 |
| yuriyz | hello victors lucasagomes I think this is great idea. SQLite should not be used for production (bad support in alembic) but anyone can create new empty DB for test | 13:25 |
| lucasagomes | viktors, so, as I said I'm not the strongest guy in databse. But I like the idea | 13:26 |
| lucasagomes | I would +1 it | 13:26 |
| lucasagomes | I never really understood why we run all the migration scripts to create the db | 13:26 |
| lucasagomes | and projects like nova may have like 200 migration scripts and we ran it all for a fresh install | 13:27 |
| lucasagomes | so sounds to me | 13:27 |
| lucasagomes | sounds good to me* | 13:27 |
| lucasagomes | yuriyz, +1 | 13:27 |
| lucasagomes | and we will have a specific test to make sure that the migrations are working and the final result is _exactly_ same as the create_all() | 13:28 |
| lucasagomes | so sounds pretty good | 13:28 |
| viktors | lucasagomes: afaik, folks from Nova want to be sure, that thay will get same DB shema from models and from migrations | 13:28 |
| lucasagomes | yup, yeah we may want that as well | 13:28 |
| lucasagomes | we def have to cover that case | 13:28 |
| viktors | lucasagomes: this patch check it - https://review.openstack.org/107628 | 13:29 |
| viktors | lucasagomes: so it should be totally safe | 13:29 |
| lucasagomes | viktors, +1 | 13:29 |
| yuriyz | oslo.db patch is the blocker | 13:29 |
| lucasagomes | viktors, good stuff | 13:29 |
| viktors | lucasagomes, yuriyz: yes, but id depends of oslo.db, which -2'ed at the moment =( | 13:30 |
| lucasagomes | viktors, right, it's -2d because it doesn't run the migration scripts on gate right? | 13:31 |
| lucasagomes | or something like that | 13:31 |
| lucasagomes | that approach would solve that? | 13:31 |
| dtantsur | jroll, re your IPA spec: can we do without `lookup` method, provided our discovery discussions? that does not seem in line with what you voted for then :) | 13:32 |
| viktors | lucasagomes: it blocked because of bugs 1327397 and 1328997. | 13:32 |
| viktors | lucasagomes: I tried to fix these bugs in patch https://review.openstack.org/#/c/107053/ | 13:32 |
| lucasagomes | right | 13:33 |
| viktors | lucasagomes: but this patch also requires last common db code | 13:33 |
| dtantsur | jroll, you can put heartbeat_timeout into driver_info and have some reasonable default | 13:33 |
| lucasagomes | viktors, alright... maybe we should just ping deva about it and the plans | 13:33 |
| lucasagomes | but seems that having oslo.db is the base for everything | 13:33 |
| lucasagomes | so we should do it | 13:33 |
| lucasagomes | baby steps, get the oslo.db merged -> fix the migration in gate -> use the create_all schema() | 13:34 |
| yuriyz | lucasagomes +1 | 13:35 |
| viktors | lucasagomes: yes, you right. It's just difficult for me to ping Deva because of time difference | 13:35 |
| lucasagomes | viktors, right, I will try to proxy him to it then | 13:35 |
| lucasagomes | idk if he's in an event right now, so today I may not see him as well | 13:36 |
| lucasagomes | but I will try to talk to him soon | 13:36 |
| viktors | lucasagomes: thanks! | 13:37 |
| viktors | lucasagomes: should I build a chain from all these patches? | 13:37 |
| lucasagomes | viktors, linear dependency? I think so | 13:37 |
| lucasagomes | I mean yes | 13:37 |
| viktors | lucasagomes: ok, will do. | 13:37 |
| viktors | lucasagomes: thanks! | 13:38 |
| lucasagomes | viktors, yvw, thank you for the hard working! | 13:38 |
| viktors | lucasagomes: no problem :) | 13:39 |
| jroll | dtantsur: this is where I put my foot in my mouth :| | 13:46 |
| dtantsur | too late :D | 13:47 |
| jroll | dtantsur: honestly? I want to have a later iteration where I match on a serial number in Node.extra. or something. | 13:47 |
| jroll | dtantsur: but not sure how possible that is in our environment anyway :) | 13:47 |
| dtantsur | jroll, not really possible, e.g. you can't search nodes based on extra | 13:47 |
| dtantsur | jroll, also, you'll have to prove to devananda that you can store some inventory in extra :) | 13:48 |
| jroll | dtantsur: ah, yeah. | 13:48 |
| jroll | dtantsur: an operator can put whatever they like in extra :P | 13:48 |
| jroll | (we already store serial number there) | 13:48 |
| jroll | (as well as other things) | 13:48 |
| jroll | (just no code interaction) | 13:49 |
| *** ramineni has joined #openstack-ironic | 13:49 | |
| Shrews | So, I have an ironic review to push up that adds a new python module to requirements.txt, but it's version requirement is higher than that in global-requirements.txt. I wonder if it's safe to push that up?? | 13:50 |
| dtantsur | jroll, well, my point is to do similar things similarly. if we decided to implement discovery this way, it's reasonable for IPA to also work this way :) | 13:50 |
| jroll | dtantsur: I'm conflicted here, I'd like to keep our lookup function, but my reviewer hat says no | 13:50 |
| jroll | right | 13:50 |
| jroll | I just don't want to change a bunch of code, I think :) | 13:50 |
| jroll | dtantsur: I'll chat with people about it in the office today | 13:51 |
| dtantsur | jroll, I suggest re-introducing lookup, when it will be really _required_ | 13:51 |
| dtantsur | sure, let me know how it goes :) | 13:51 |
| jroll | Shrews: we do that in IPA, but then need to -2 all the "update global requirements" reviews :/ | 13:51 |
| jroll | Shrews: I'd ask deva, or even infra | 13:51 |
| Shrews | jroll: I've pushed up a review to bump the version in global-requirements.txt, it's just not +A'd yet. | 13:52 |
| jroll | dtantsur: will do :) | 13:52 |
| Shrews | but asking infra is probably the right call | 13:52 |
| jroll | Shrews: oh, maybe just WIP the ironic review until that lands. what's the review #? | 13:52 |
| jroll | infra does global-requirements reviews, so you've already asked :P | 13:52 |
| Shrews | jroll: https://review.openstack.org/107423 | 13:52 |
| Shrews | i'm just wondering if timing matters here. probably not | 13:53 |
| jroll | oh yeah, that should be fine, I wouldn't worry about it | 13:53 |
| jroll | the worst that will happen is we'll have to wait until that lands to approve "update global requirements" patches in ironic | 13:54 |
| Nisha | dtantsur: hi | 13:55 |
| dtantsur | Nisha, hi again | 13:55 |
| Nisha | dtantsur: :) | 13:55 |
| *** malini2 has joined #openstack-ironic | 13:55 | |
| openstackgerrit | David Shrewsbury proposed a change to openstack/ironic: Implement retry on NodeLocked exceptions https://review.openstack.org/107710 | 13:56 |
| Nisha | dtantsur: i wanted to ask if i should retain the inventory structure as it was proposed in your earlier spec or its fine to have it the way it was earlier? | 13:56 |
| dtantsur | Nisha, by `inventory structure` you mean what will be returned from new ManagementInterface method? | 13:57 |
| Nisha | yes | 13:57 |
| openstackgerrit | Mikhail Durnosvistov proposed a change to openstack/ironic: Check whether specified FS is supported https://review.openstack.org/98102 | 13:58 |
| Nisha | dtantsur: yes you are right...i meant the dictionary returned by new ManagemnetInterface function | 14:00 |
| *** Mikhail_D_ltp has quit IRC | 14:00 | |
| dtantsur | Nisha, you're free to use whatever you want (though I still like my structure :) and it corresponds to IPA's one) | 14:00 |
| Nisha | dtantsur: Ok. I have no issues to use that one | 14:01 |
| Nisha | dtantsur: i just wanted to know if its required to retain that structure | 14:01 |
| *** dguerri is now known as _dguerri | 14:05 | |
| Nisha | dtantsur: lucasagomes devananda NobodyCam lifeless : request your review for https://review.openstack.org/#/c/100951/ | 14:07 |
| *** _dguerri is now known as dguerri | 14:07 | |
| *** Nisha has quit IRC | 14:11 | |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/python-ironicclient: Trim trailing slash and version from endpoint https://review.openstack.org/107715 | 14:13 |
| jroll | lucasagomes: ^ | 14:13 |
| NobodyCam | good morning Ironic | 14:15 |
| dtantsur | NobodyCam, o/ | 14:15 |
| NobodyCam | mornign dtantsur | 14:16 |
| openstackgerrit | Victor Sergeyev proposed a change to openstack/ironic: Use metadata.create_all() to get database schema https://review.openstack.org/107629 | 14:17 |
| openstackgerrit | Victor Sergeyev proposed a change to openstack/ironic: Add a test case for DB schema comparison https://review.openstack.org/107628 | 14:17 |
| *** lazy_prince has joined #openstack-ironic | 14:19 | |
| *** lazy_prince has quit IRC | 14:19 | |
| *** lazy_prince has joined #openstack-ironic | 14:20 | |
| jroll | lucasagomes: wondering if this is worth fixing in devstack, even... it's no longer a bug in devstack with that patch | 14:24 |
| lucasagomes | jroll, I think it does, fixing in the client requires a release of the client | 14:25 |
| dtantsur | brb | 14:26 |
| *** jgrimm has joined #openstack-ironic | 14:27 | |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Add missing docstrings https://review.openstack.org/106202 | 14:30 |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Add methods to ipmitool driver https://review.openstack.org/100364 | 14:30 |
| jroll | whee | 14:30 |
| *** jdob has quit IRC | 14:31 | |
| *** jcoufal has quit IRC | 14:32 | |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic-specs: Add deploy driver for ironic-python-agent https://review.openstack.org/98506 | 14:37 |
| jroll | dtantsur: decided to just update, I'll ping you if there is objections :) | 14:37 |
| *** jdob has joined #openstack-ironic | 14:38 | |
| *** rloo has joined #openstack-ironic | 14:40 | |
| jroll | hey y'all, this spec covers things to fix a bug targeted for J2, can I have some eyes on it? :) https://review.openstack.org/#/c/102405/ | 14:44 |
| jroll | rloo: updated https://review.openstack.org/106202 - thanks for the feedback | 14:45 |
| jroll | brb | 14:45 |
| rloo | jroll: thx, will look (at both maybe) in a few minutes. | 14:46 |
| *** pcrews has joined #openstack-ironic | 14:46 | |
| jroll | rloo: thanks, no rush :) | 14:46 |
| rloo | jroll: ok, then I'll wait til next week :D (am only working a few hours and then off) | 14:47 |
| *** malini2 has quit IRC | 14:49 | |
| yuriyz | morning/evening rloo one question in comment https://review.openstack.org/#/c/107092/3/ironic/drivers/base.py | 14:52 |
| rloo | hi yuriyz (morning for me). I'm just replying to that :-) | 14:53 |
| rloo | yuriyz: just replied. let me know if you want to discuss. lucas and I have had quite a lot of discussion about a 'required' field. | 14:54 |
| *** kpavel_ has joined #openstack-ironic | 14:55 | |
| NobodyCam | if any would like to toss a +1 on a nova review https://review.openstack.org/#/c/107511 | 14:56 |
| yuriyz | rloo your answer makes sence. 'required' is not suitable for all options variants. | 14:59 |
| NobodyCam | anyone know if any server then supermicro supports gracefully shut down over ipmi | 14:59 |
| rloo | yuriyz: that was Lucas' idea. I initially had 'required', and put the XofYproperties as required, then as optional, and both weren't quite right. So now nothing. | 15:00 |
| *** foexle has quit IRC | 15:01 | |
| *** kpavel has quit IRC | 15:02 | |
| *** Alexei_987 has quit IRC | 15:02 | |
| *** derekh_ has quit IRC | 15:02 | |
| *** viktors has quit IRC | 15:02 | |
| *** ifarkas has quit IRC | 15:02 | |
| yuriyz | NobodyCam, HP proliantutils for ILO (not ipmi) has press_pwr_btn() method | 15:06 |
| *** derekh_ has joined #openstack-ironic | 15:07 | |
| *** Alexei_987 has joined #openstack-ironic | 15:07 | |
| *** ifarkas has joined #openstack-ironic | 15:07 | |
| *** ifarkas has quit IRC | 15:07 | |
| *** ifarkas has joined #openstack-ironic | 15:07 | |
| *** 18VAAEB97 has joined #openstack-ironic | 15:07 | |
| *** viktors has joined #openstack-ironic | 15:08 | |
| *** ramineni has quit IRC | 15:10 | |
| NobodyCam | also looks like ipmitool has power soft support | 15:10 |
| *** kpavel_ has quit IRC | 15:13 | |
| *** mdorman has joined #openstack-ironic | 15:23 | |
| NobodyCam | brb | 15:27 |
| *** rakesh_hs has quit IRC | 15:28 | |
| *** matty_dubs is now known as matty_dubs|lunch | 15:29 | |
| *** viktors is now known as viktors|afk | 15:31 | |
| *** mdorman has quit IRC | 15:34 | |
| *** mdorman has joined #openstack-ironic | 15:34 | |
| *** jcoufal has joined #openstack-ironic | 15:38 | |
| *** 18VAAEB97 has quit IRC | 15:44 | |
| *** ifarkas has quit IRC | 15:47 | |
| *** krtaylor has quit IRC | 15:57 | |
| *** lazy_prince is now known as killer_prince | 15:57 | |
| *** jcoufal has quit IRC | 15:59 | |
| *** jistr has quit IRC | 16:01 | |
| *** hemna has joined #openstack-ironic | 16:02 | |
| *** ramineni has joined #openstack-ironic | 16:06 | |
| *** jcoufal has joined #openstack-ironic | 16:08 | |
| jroll | rloo: noooo, today please :( | 16:08 |
| rloo | jroll: take a look at my latest comment then. | 16:08 |
| *** ramineni has quit IRC | 16:10 | |
| jroll | rloo: checking in from the train atm, will look when I get to the office, thanks | 16:11 |
| rloo | jroll: ha ha. | 16:11 |
| *** malini1 has joined #openstack-ironic | 16:21 | |
| *** bvivek has joined #openstack-ironic | 16:23 | |
| *** mkerrin has quit IRC | 16:24 | |
| *** Mikhail_D_wk has quit IRC | 16:28 | |
| *** Mikhail_D_wk has joined #openstack-ironic | 16:28 | |
| lucasagomes | aight folks I'll have to go now, came to the office today | 16:29 |
| lucasagomes | gotta get the train back home | 16:29 |
| lucasagomes | have a good night everyone | 16:29 |
| *** lucasagomes has quit IRC | 16:30 | |
| *** christop1eraedo is now known as christopheraedo | 16:34 | |
| romcheg | g'night Lucas! | 16:34 |
| NobodyCam | night lucas | 16:35 |
| *** Poornima has joined #openstack-ironic | 16:36 | |
| *** krtaylor has joined #openstack-ironic | 16:42 | |
| *** rameshg87 has joined #openstack-ironic | 16:43 | |
| *** derekh_ has quit IRC | 16:49 | |
| *** rwsu has joined #openstack-ironic | 16:55 | |
| dtantsur | jroll, aha, cool, thanks! | 17:02 |
| devananda | morning, all | 17:05 |
| * devananda tries to catch up on all the scrollback | 17:07 | |
| dtantsur | devananda, morning :) | 17:09 |
| *** Alexei_987 has quit IRC | 17:09 | |
| dtantsur | jroll, +2 from me :) | 17:09 |
| *** hemna has quit IRC | 17:11 | |
| NobodyCam | good morning devananda | 17:12 |
| devananda | dtantsur: it's probably a question for the oslo.db team -- why are certain ALTERs not supported/testable on sqlite? | 17:13 |
| devananda | dtantsur: we should switch to oslo.db soon. the patch is up, and in my review queue. if that doesn't support sqlite, it's a much bigger problem than just Ironic | 17:14 |
| devananda | dtantsur: and if it does, then great. no reason for us to not support it | 17:14 |
| dtantsur | devananda, yeah... maybe someone just should implement them :) ok, let us see. viktors|afk's feature to create the whole base w/o migrations still looks promising to me | 17:15 |
| devananda | dtantsur: the oslo.db migration code is done, afaik. GheRivero and viktors proposed it. just needs review | 17:15 |
| devananda | dtantsur: i blocked it a month ago due to a bug i found in it. i need to confirm that it's fixed | 17:16 |
| devananda | other than that, it LGTM | 17:16 |
| dtantsur | ok | 17:16 |
| *** Nisha has joined #openstack-ironic | 17:16 | |
| *** Poornima has quit IRC | 17:17 | |
| * devananda has read scrollback up to T-7hrs ... wow, lots of discussions last night! | 17:18 | |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Raise appropriate errors on duplicate Node, Port and Chassis creation https://review.openstack.org/102506 | 17:18 |
| jroll | dtantsur: sweet :) | 17:19 |
| jroll | thank you! | 17:19 |
| *** harlowja_away is now known as harlowja | 17:20 | |
| dtantsur | np) | 17:20 |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Fix leaking DB details to API on error https://review.openstack.org/73121 | 17:21 |
| jroll | morning devananda | 17:23 |
| devananda | romcheg: "a way to force IPMI credentials from inside the server" -- would be a huge breach of security IF it's possible | 17:23 |
| openstackgerrit | Chris Krelle proposed a change to openstack/ironic: Add option to allow soft power off https://review.openstack.org/107778 | 17:25 |
| rloo | jroll: gonna take off now. I'll try to check in later today to see if you've updated that docstring review. (and you too dtantsur wrt 102506) | 17:26 |
| NobodyCam | have a good night rloo | 17:26 |
| jroll | rloo: gah, just got in | 17:27 |
| devananda | Shrews: any change to requriements.txt must match global-reqs, or it fails gate | 17:27 |
| jroll | rloo: have a good weekend :) don't worry about me | 17:27 |
| dtantsur | g'night, rloo | 17:27 |
| devananda | jroll: i'm sad that you allow things not in global-req into IPA. very sad. | 17:27 |
| Shrews | devananda: ah. yeah, i was wondering if there was a gotcha. | 17:27 |
| jroll | rloo: oh, do you have a sec? | 17:27 |
| rloo | bye. not night yet for me. yay! :-) | 17:27 |
| rloo | jroll: 2 secs ;) | 17:27 |
| jroll | devananda: no... we require a later pecan version than global-req | 17:28 |
| jroll | rloo: I removed them because it's encompassed by "invalid parameters" | 17:28 |
| devananda | jroll: so update global-req | 17:28 |
| jroll | rloo: maybe I'm wrong in the first one, because validate() checks that, but vendor_passthru doesn't raise the exception directly so I think it's fine | 17:28 |
| * devananda is finally caught up on scrollback | 17:29 | |
| rloo | jroll: hmm. let me think about it on my ride home. i think other methods do mention those extra invalidates too. | 17:29 |
| jroll | devananda: it's for a better test fixture thing, it was unclear to me that would be a valid reason for infra | 17:29 |
| jroll | rloo: ok, I can take another look too. thanks | 17:29 |
| rloo | jroll: later. ciao. | 17:30 |
| *** hemna has joined #openstack-ironic | 17:30 | |
| *** rloo has quit IRC | 17:30 | |
| *** chuckC has quit IRC | 17:30 | |
| devananda | jroll: hm. I dunno. usually "project X needs min version Y" is good enough | 17:30 |
| jroll | 10:27:09 devananda | Shrews: any change to requriements.txt must match global-reqs, or it fails gate <- also, what checks this, I'm not sure that's true | 17:30 |
| devananda | jroll: it's not true for IPA because ya'll aren't running the right checks | 17:30 |
| devananda | *if | 17:31 |
| devananda | *then | 17:31 |
| jroll | right | 17:31 |
| jroll | so what checks it | 17:31 |
| jroll | because we run pep8 | 17:31 |
| jroll | I would assume it would be there | 17:31 |
| jroll | but I'm usually wrong | 17:31 |
| romcheg | devananda: Good morning | 17:32 |
| romcheg | devananda: I suspected that | 17:32 |
| devananda | jroll: oh. Ironic isn't running it either. Gah. | 17:34 |
| devananda | jroll: "gate-***-requirements" | 17:34 |
| devananda | it's a separate jenkins job | 17:34 |
| jroll | devananda: heh | 17:34 |
| jroll | I find this failure hilarious, on an "update requirements.txt" review in IPA: | 17:36 |
| jroll | 2014-07-12 23:04:20.971 | Could not find a version that satisfies the requirement oslo.config>=1.4.0.0a2 (from -r /tmp/ironic-python-agent/requirements.txt (line 8)) (from versions: ) | 17:37 |
| devananda | jroll: taht the result of a network / pip failure? | 17:37 |
| jroll | unclear, it's in multiple jobs | 17:38 |
| jroll | I'm going to recheck... once this merges: https://review.openstack.org/#/c/107780/ | 17:38 |
| jroll | (bump global pecan | 17:38 |
| jroll | ) | 17:38 |
| devananda | ok, i think something's wrong with ironic's jenkins config | 17:39 |
| devananda | or i'm just braindead right now | 17:39 |
| devananda | Shrews: around? | 17:39 |
| Shrews | devananda: aye | 17:39 |
| devananda | Shrews: have a minute to look at infra config and tell me if i'm crazy? | 17:39 |
| Shrews | devananda: i can make a minute. what do you want me to look at? | 17:40 |
| devananda | pick any recent patch to ironic -- i'm looking at https://review.openstack.org/#/c/107214/ | 17:40 |
| devananda | actually, lemme move to -infra in case they know | 17:40 |
| Shrews | k | 17:40 |
| Shrews | though they're all in germany so unlikely to be responsive | 17:41 |
| devananda | ah, right | 17:41 |
| devananda | staying here then | 17:41 |
| devananda | so i'm looking at a random recent patch in ironic, and wondering why i see "gate-*" jobs running for an initial check | 17:41 |
| openstackgerrit | Chris Krelle proposed a change to openstack/ironic: Add option to allow soft power off https://review.openstack.org/107778 | 17:41 |
| devananda | and i just noticed that's also the case for nova | 17:41 |
| devananda | so it's not just us | 17:41 |
| JayF | devananda: it looks like they merged gate/check jobs where there is no difference | 17:42 |
| JayF | devananda: config file looked that way to me when I added the IPA builder | 17:42 |
| devananda | huh | 17:42 |
| devananda | ok. i'm just behind the times | 17:42 |
| JayF | devananda: i.e. where 'gate' jobs that don't differ from 'check' jobs are just left as the same job and named gate- | 17:42 |
| devananda | so real question then is, why http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml#n980 isn't running | 17:43 |
| JayF | interesting, I don't know. I know that job isn't setup for IPA though | 17:44 |
| devananda | eg, looking at a recent patch https://review.openstack.org/#/c/107214/ | 17:44 |
| devananda | there's no gate-ironic-requirements | 17:44 |
| Shrews | hrm, *that* is a good question | 17:44 |
| jroll | odd | 17:45 |
| Shrews | doesn't run for other projects, it seems. e.g., cinder | 17:45 |
| *** pelix has quit IRC | 17:45 | |
| jroll | maybe it just isn't posting back status? | 17:45 |
| openstackgerrit | A change was merged to openstack/ironic: ManagementInterface {set, get}_boot_device() to support 'persistent' https://review.openstack.org/105757 | 17:45 |
| jroll | like, the job could be broken | 17:45 |
| devananda | it runs for nova | 17:46 |
| NobodyCam | brb quick walkies | 17:46 |
| Shrews | devananda: does it? don't see it here: https://review.openstack.org/106952 | 17:48 |
| Shrews | oh | 17:49 |
| Shrews | i know | 17:49 |
| *** malini1 has quit IRC | 17:49 | |
| Shrews | it only runs if there is a change to requirements.txt | 17:49 |
| jroll | oh heh | 17:49 |
| jroll | nice :) | 17:49 |
| Shrews | devananda: https://review.openstack.org/107710, for example | 17:49 |
| Shrews | i borked it :) | 17:49 |
| * Shrews WIP's that change until his global-requirements.txt change merges | 17:51 | |
| *** vinbs has joined #openstack-ironic | 17:57 | |
| *** jcoufal has quit IRC | 17:58 | |
| *** malini1 has joined #openstack-ironic | 17:59 | |
| openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Raise appropriate errors on duplicate Node, Port and Chassis creation https://review.openstack.org/102506 | 18:01 |
| *** wanyen has joined #openstack-ironic | 18:01 | |
| wanyen | ramesh87: hi | 18:02 |
| *** vinbs_ has joined #openstack-ironic | 18:02 | |
| rameshg87 | hi wanyen | 18:02 |
| rameshg87 | hello devananda | 18:03 |
| wanyen | Deva and liefless are you there? | 18:03 |
| wanyen | s/lief/lifeless | 18:03 |
| *** vinbs has quit IRC | 18:04 | |
| *** vinbs_ is now known as vinbs | 18:04 | |
| wanyen | Deva, we would like ot discuss liefeless review commetns regarding iLO deploy driver | 18:04 |
| wanyen | lifeless requests ilo deploy driver to support conductor deploy over iscsi | 18:06 |
| rameshg87 | dtantsur: request you to have a look at https://review.openstack.org/#/c/89500/ . we have addressed your comments. | 18:07 |
| *** vinbs has quit IRC | 18:08 | |
| jroll | wanyen: I don't see that comment on the review? | 18:09 |
| devananda | wanyen: i'm waiting for another meeting to resume. have a few minutes | 18:09 |
| Shrews | So, I wonder if we should be requiring all new API calls to be asynchronous? There is a spec to change all current synchronous calls to async (in K), but should we change the way we design new calls? | 18:09 |
| devananda | wanyen: i read the discussion rameshg87 and lifeless had here in channel, and the internal emails | 18:09 |
| dtantsur | rameshg87, sure, but tomorrow, it 8pm and I'm nearly leaving :) | 18:09 |
| devananda | wanyen: I think his points are valid | 18:09 |
| wanyen | we can add iLO deploy over iscsi as a seperate spec but I think it should not be a blocking factor for current spec | 18:09 |
| *** chuckC has joined #openstack-ironic | 18:10 | |
| devananda | wanyen: duplciating most of the deploy logic of IPA or PXE drivers is going to add a burden to the code taht is unnecessary | 18:10 |
| devananda | wanyen: my impression from the spec was that taht wasn't being proposd, but clearly I didn't read it thoroughly enough | 18:10 |
| dtantsur | g'night folks, going now | 18:10 |
| devananda | wanyen: using the virtual media channel to load (a slightly modified form of) the current ramdisk should be totally sufficient | 18:10 |
| wanyen | Deva> cusotmer willeither choose iPA or iLO driver so iLO need to be able to support bm deploy over swift as well | 18:11 |
| rameshg87 | dtantsur: goodnight, thanks, will wait for your review :-) | 18:11 |
| *** dtantsur is now known as dtantsur|afk | 18:11 | |
| devananda | wanyen: iPA can be used instead of tftp to load the deploy ramdisk and keys | 18:11 |
| devananda | wanyen: * iLO can be used ... | 18:11 |
| jroll | wanyen: what was discussed this morning is separating deploy mechanisms from boot mechanisms, and combining the two for a driver | 18:12 |
| jroll | wanyen: so iLO can boot a deploy ramdisk, to be used with iscsi or IPA | 18:13 |
| wanyen | Deva> I don't understand why because IPA does BM deploy then iLO driver cannot do it because some customers will want otuse iLO driver to provision Proliant server and they need to be able to do bm deploy over swift with iLO driver. | 18:13 |
| rameshg87 | jroll: doesn't ipa have the same problem with issues - with low memory systems and unsure if it scales better than current iscsi-dd solution | 18:16 |
| rameshg87 | jroll: is ipa planning to support iscsi deployment requesting the conductor to do it ? | 18:17 |
| jroll | wat | 18:17 |
| jroll | so | 18:17 |
| rameshg87 | jroll: just a question :-) | 18:17 |
| jroll | the proposal is that we should separate boot mechanisms and deploy mechanisms | 18:17 |
| *** tatyana has joined #openstack-ironic | 18:18 | |
| jroll | so boot mechanisms will include: pxe/tftp, iLO, ?? | 18:18 |
| rameshg87 | jroll: yeah, my question was just a general question | 18:18 |
| jroll | deploy mechanisms will include: iscsi, ipa, ?? | 18:18 |
| jroll | rameshg87: right, so | 18:18 |
| rameshg87 | jroll: i thought ipa had a boot mechanism too which is superior to pxe. | 18:18 |
| jroll | 1) maybe has issues with low memory systems. I believe it scales better than iscsi for *my use case* | 18:18 |
| jroll | 2) hell no IPA will not support iscsi | 18:19 |
| jroll | we use ipxe at rackspace | 18:19 |
| rameshg87 | jroll: okay. :-) | 18:19 |
| jroll | the upstream driver will use pxe/tftp, initially | 18:19 |
| rameshg87 | jroll: oh okay. | 18:19 |
| jroll | hope that helps :) | 18:20 |
| wanyen | my point is that iLO driver should be able to do both iscsi and swift.bm deploy. I tshould not be limited to do just iscsi. | 18:20 |
| jroll | rameshg87, wanyen, I think using iLO to boot a deploy ramdisk that works with iscsi or IPA deploy driver is a great idea, FWIW | 18:20 |
| jroll | wanyen: agreed | 18:20 |
| jroll | wanyen: so if I understand correctly, this morning people proposed: v1 of ilo deploy driver subclasses the pxe driver. v2 relies on splitting up DeployInterface and BootInterface, where iLO is a BootInterface, and can be mixed with IPA or iscsi DeployInterface | 18:22 |
| *** jcoufal has joined #openstack-ironic | 18:22 | |
| devananda | wanyen: yes, using iLO virtual media channel to (securely) load the deploy agent (whether that is IPA or DIB/deploy-ironic or something else) is very important | 18:22 |
| jroll | for example, rackspace probably has some HP servers. I want to use IPA to deploy images to those servers :) | 18:23 |
| jroll | but I also want to do it as securely as possible, which this iLO driver can help me do :) | 18:23 |
| devananda | wanyen: as that out of band channel is the only secure means to load cryptographic data to a preboot environment to populate a TPM | 18:23 |
| devananda | jroll: ^ :) | 18:23 |
| jroll | \o/ | 18:23 |
| jroll | <3 secure software | 18:23 |
| devananda | jroll: i had a great conversation with some folks from Intel and the NSA yesterday about this sort of thing | 18:24 |
| wanyen | deva and jroll, I am glad to hear that ilo vm driver can be useful for IPA but it will require investigation so we can do it as incremental feature | 18:24 |
| devananda | also, i sort of feel dirty talking to NSA folks, but they're nic | 18:24 |
| devananda | nice | 18:25 |
| devananda | wanyen: lifeless and I recommended this incremental approach during the last cycle | 18:25 |
| devananda | before atlanta summit | 18:25 |
| wanyen | For the time being, we would like to be availale to do iLO driver with bm delpoy over swift and vm+ iscsi | 18:26 |
| wanyen | s/available/able | 18:26 |
| devananda | wanyen: what is "over swift and vm+iscsi" ? | 18:27 |
| devananda | wanyen: that sounds like using the iLO to load the current ironic initramdisk and using the PXE deploy driver to copy the image over iSCSI | 18:27 |
| wanyen | I mean to do able to do provisioning on teh bm node using swift tempURL and be able to do provisionin gfrom conductor over iscsi | 18:27 |
| wanyen | s/do/be | 18:27 |
| devananda | wanyen: you are proposing two different implementations? | 18:28 |
| devananda | wat? | 18:28 |
| devananda | wanyen: "provisioning from conductor over iscsi" ==> this is what the PXE deploy driver does today. so what are you proposing here? | 18:28 |
| jroll | devananda: yeah, that's what you said... would love to hear more :) | 18:28 |
| wanyen | Again, we can do this incrementally, bm/swift first or iscsi first | 18:28 |
| devananda | wanyen: just using iLO to load the deploy ramdisk on the node, then letting the PXE deploy driver to the rest? | 18:29 |
| jroll | ^^ | 18:29 |
| jroll | so much this | 18:29 |
| devananda | I think that was discussed in IRC already | 18:29 |
| devananda | it would take some refactoring, but that's fine | 18:29 |
| devananda | the actual new code would be VERY small | 18:29 |
| devananda | wanyen: that ^ seems totally fine. I'm pretty sure it's exactly what lifeless already suggested to you | 18:29 |
| rameshg87 | devananda: yeah. vmedia+iscsi = add code to boot from virtual media + refactored code from current pxe driver. | 18:30 |
| devananda | rameshg87: ++ | 18:30 |
| jroll | or even subclass the pxe driver? | 18:30 |
| jroll | not sure if that would be better or worst | 18:30 |
| devananda | jroll: i think it'll be a refactoring, fwiw | 18:30 |
| jroll | I selfishly would love for someone to factor out all of the pxe things :) | 18:30 |
| devananda | possibly creating a base class taht pxe and ilo inherit from. | 18:30 |
| jroll | although this is probably the opposite way | 18:30 |
| jroll | factoring out the iscsi things | 18:31 |
| devananda | jroll: IPA wants to use many of them too, right? | 18:31 |
| wanyen | we have customers who don't want to use pxe | 18:31 |
| jroll | we want to use pxe/tfto things yes | 18:31 |
| wanyen | so want to make iLO driver pxe-less | 18:31 |
| devananda | wanyen: we know | 18:31 |
| devananda | wanyen: taht's EXACTLY what we're suggesting to you | 18:31 |
| jroll | wanyen: share the iscsi parts and none of the pxe/tftp parts :) | 18:32 |
| wanyen | jroll: that's fine but don't block us to do bm node deploy + swift | 18:32 |
| jroll | nobody is blocking you on that | 18:33 |
| jroll | or, wait. maybe | 18:33 |
| devananda | sure we are | 18:33 |
| jroll | yeah | 18:33 |
| wanyen | lifeless is blocking that | 18:33 |
| devananda | the swift tempurl code is ALREADY blocked | 18:33 |
| jroll | devananda: nop | 18:33 |
| devananda | it is needed for IPA | 18:33 |
| devananda | jroll: oh? when i looked yesterday it was blocked | 18:33 |
| jroll | temp url spec landed | 18:33 |
| devananda | jroll: right - but the impl is blocked on swiftclient | 18:33 |
| devananda | so i bumped the BP to J3 | 18:34 |
| jroll | oh, right | 18:34 |
| JoshNang | which reminds me, i need to go poke people in -swift to get that approved again | 18:34 |
| jroll | +1 | 18:34 |
| jroll | JoshNang: +9000 | 18:34 |
| devananda | JoshNang: ++ | 18:34 |
| devananda | on another topic | 18:35 |
| devananda | we srsly need the nova baremetal -> ironic migration work that romcheg is working on | 18:35 |
| wanyen | deva> I just want to make sure once we modify our spec to reflect the suggestion, our spec can get reviewed quickly and still target for Juno | 18:35 |
| devananda | and we need grenade testing of it | 18:35 |
| devananda | and we need it soon | 18:35 |
| devananda | because it is looking like nova won't accept the driver without an already-tested migration path | 18:36 |
| devananda | the promise of implementing one later is not sufficient | 18:36 |
| jroll | wanyen: your spec is high priority for juno, it will get reviewed | 18:36 |
| devananda | and we do not have grenade tests yet | 18:36 |
| jroll | devananda: I'm out of tables to flip :( | 18:36 |
| devananda | jroll: so am I | 18:36 |
| devananda | I fondly remember the days when I had tiem to write code .... | 18:37 |
| *** matty_dubs|lunch is now known as matty_dubs | 18:37 | |
| jroll | do we have a recent status update from romcheg ? | 18:37 |
| jroll | or any progress? | 18:37 |
| jroll | etc | 18:37 |
| wanyen | jroll: thanks! We need reivwers to review them quickly as it's already late in teh Juno cycle | 18:37 |
| jroll | wanyen: indeed | 18:37 |
| jroll | wanyen: /me checks list to make sure I'm not lying about priorities | 18:38 |
| jroll | wanyen: maybe I shouldn't say "high" priority, but it's on the list | 18:38 |
| lifeless | morning | 18:39 |
| lifeless | devananda: ahh welcome to my life :) | 18:40 |
| wanyen | ramesh87: do you know what we need to do to modify the spec. ? I was not in irc discussion earlier this morning | 18:40 |
| devananda | jroll: see the whiteboard | 18:40 |
| devananda | jroll: there's two patches from romcheg. i haven't had time to test. tldr, we need grenade to test them | 18:40 |
| rameshg87 | wanyen: i think i have discussed with lifeless and lucasagomes earlier today | 18:40 |
| jroll | wanyen: http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2014-07-17.log | 18:41 |
| rameshg87 | wanyen: what can be done for vmedia+iscsi is clear | 18:41 |
| wanyen | lifeless, we have discussed iLo deploy driver with Deva and Jroll | 18:41 |
| wanyen | we are okay to do vm+ iscsi but we don't think we should be block to do bm deploy over swift as we have customers who want to use iLO driver to deploy prolisnt servers and they need to be able to bm deploy over swift | 18:43 |
| *** bvivek has quit IRC | 18:43 | |
| wanyen | s/prolsnt/proliant | 18:43 |
| devananda | wanyen: "they need to be able to bm deploy over swift" why? | 18:45 |
| jroll | wanyen: what deploy ramdisk will you use to deploy over swift? | 18:45 |
| devananda | wanyen: what prevents those customers from using iSCSI? | 18:46 |
| wanyen | deva> it's the choice of customer pending on their deploy environment. | 18:46 |
| devananda | wanyen: why would they choose swift over iscsi? | 18:47 |
| wanyen | jroll: we already developed a ramdisk to do bm deploy over swift | 18:47 |
| jroll | >.> | 18:47 |
| rameshg87 | jroll: it will use a deploy ramdisk with deploy-ironic element. changes to deploy-ironic for this were also proposed in the same spec. | 18:47 |
| jroll | ok | 18:47 |
| devananda | rameshg87: is the change for deploy-ironic proposed to DIB? | 18:48 |
| rameshg87 | devananda: if you remember we had 2 specs initially - one in ironic and one in tripleo, and both were merged together | 18:48 |
| wanyen | deva> I thought at one point ironic is in favor of doing deployment on bm node because it was believed to be more scalabe. I think it's pending on customer's environment. | 18:48 |
| devananda | rameshg87: yes. but there is still code change needed in both projects | 18:48 |
| wanyen | s/is/was | 18:49 |
| devananda | rameshg87: is the CODE change proposed to diskimage-builder yet? | 18:49 |
| jroll | my question is... what's the problem with a separate spec for the swift things? remove all references to swift from this spec, push it through, put up a different spec for swift + ilo | 18:49 |
| rameshg87 | devananda: ah okay. no code change is not proposed to diskimage-builder yet | 18:49 |
| devananda | wanyen: yes. IPA is doing that | 18:49 |
| devananda | (and more) | 18:49 |
| devananda | wanyen: i think the concern is bloating the diskimage-builder/deploy-ironic code, which is in bash and harder to debug/maintain | 18:50 |
| devananda | wanyen: and thus duplicating functionality, increasing complexity, and making life harder for the core team | 18:50 |
| devananda | wanyen: when IPA is already proposing to cover that requirement | 18:50 |
| jroll | let me write code for you :) | 18:50 |
| devananda | why should we have two implementations? | 18:50 |
| devananda | rameshg87: this may be a case where seeing that code change will help clarify things | 18:51 |
| devananda | rameshg87: if you already have it working internally, please propose it to DIB | 18:51 |
| devananda | rameshg87: so we can all see how complex it is. maybe it's trivially simple and that might change opinions | 18:52 |
| wanyen | deva> as I said, customer will either use iLo driver or IPA driver to deploy a ProLaint server. So, when customers choose iLO driver to do the deploy, they need to be able to do bm deploy with swift if that's what they desire. | 18:52 |
| devananda | wanyen: that does not make sense | 18:52 |
| devananda | wanyen: see the whole conversation we jsut had about using iLO with either iSCSI or IPA | 18:52 |
| devananda | I need to get lunch now, then catch a train. bbi2hr | 18:53 |
| jroll | wanyen: if I'm deploying an HP server with IPA, I *want* to use iLO to put the IPA image on that server | 18:53 |
| wanyen | deva and jroll: yes. I got that part. However, a customer may just wan to use iLO driver to do deploy as well as OOB firmware update, fimrware setting.,,,etc, so they will just use iLO driver but not iLO driver and IPA driver together. | 18:54 |
| jroll | wanyen: I still think that would be possible... I would assume firmware update etc would be part of the ManagementInterface | 18:55 |
| jroll | wanyen: these are features that don't exist, you can't use them to justify duplicating functionality | 18:55 |
| NobodyCam | brb | 18:57 |
| wanyen | jroll> we have sumbitted design specs for these features with the proposed managemetn interface | 18:57 |
| jroll | I understand that | 18:57 |
| jroll | I still don't think "deploying via swift" should be in this spec | 18:58 |
| *** rloo has joined #openstack-ironic | 18:58 | |
| jroll | this spec should be about "putting the pxe driver's deploy ramdisk onto a node via ilo virtual media" | 18:59 |
| wanyen | jroll: why only limit deplyin gvia swift to IPA? That's teh part I don't underastand because some users may not use IPA and will use iLO driver only. | 18:59 |
| jroll | that's not what I'm saying | 19:00 |
| jroll | that should be in a different spec | 19:00 |
| jroll | I don't foresee ilo deploy driver *AND* ilo deploy via swift landing in juno | 19:00 |
| jroll | and if those are the same spec... I don't see those landing in juno | 19:00 |
| *** Nisha has quit IRC | 19:00 | |
| jroll | but that's just my opinion | 19:00 |
| wanyen | jroll: that was our current iLo virtual deploy spec to do deploying over swift. Now you folks are sugfgesting something different and I think it should be a differnt spec but it should not block our current spec. | 19:01 |
| NobodyCam | brb | 19:02 |
| wanyen | jroll: our current iLO virutal deploy spec of deploying over swift has approved by deva. | 19:02 |
| lifeless | it has a +2, its not fully approved | 19:03 |
| wanyen | okay. my mistake to use the appooved tearm | 19:03 |
| rloo | jroll: wrt 106202, take a look at the docstring in ipminative.py: https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/ipminative.py#L307 | 19:03 |
| lifeless | jroll: booting IPA via virtualmedia makes sense too, right ? | 19:04 |
| jroll | rloo: right... it doesn't mention "invalid IPMI parameters" | 19:04 |
| jroll | rloo: I can be more specific, will fix later | 19:04 |
| jroll | lifeless: I wouldn't deploy an HP server any other way :) | 19:04 |
| lifeless | jroll: as in boot mechanism is orthogonal to deploy logic is [mostly] orthogonal to BMC type | 19:04 |
| jroll | lifeless: yes, totally agree with separating boot management from deploy management | 19:05 |
| lifeless | thought so but worth checking :) | 19:05 |
| rloo | joll: it mentions 'or required ipmi credentials are missing' -- that's from the _parse_driver_info. and the 'invalid boot device is specified' is from the validate() code. | 19:05 |
| jroll | rloo: right... I mentioned the specific parameters before | 19:06 |
| jroll | rloo: I'll update, please hold | 19:06 |
| *** Nisha has joined #openstack-ironic | 19:06 | |
| jroll | lifeless: I wouldn't block the ilo deploy spec on that separation... as that would likely be k cycle. but I agree that it should focus on putting the existing deploy ramdisk on a server. securely. | 19:07 |
| lifeless | jroll: right, not suggesting we block it | 19:09 |
| jroll | right | 19:09 |
| wanyen | The iLo deploy spec is targeting for juno. | 19:10 |
| jroll | wanyen seems to think you're trying to block it | 19:10 |
| lifeless | jroll: my suggestion was to make it a sibling of pxe; pull up the 99% common code into a base class and have only the boot logic differences in the pxe or virtualmedia classes | 19:10 |
| jroll | lifeless: + a million | 19:10 |
| lifeless | jroll: which should make for 2 tiny patch sets | 19:10 |
| jroll | yeah | 19:10 |
| lifeless | jroll: and preps us for the bigger thing later | 19:10 |
| jroll | I read this morning :) | 19:10 |
| lifeless | wanyen: what I don't understand is the pushback here; I'm actively trying to help you get an ilo virtualmedia driver in | 19:11 |
| *** Nisha has quit IRC | 19:11 | |
| lifeless | wanyen: but you seem to be arguing that you want to bring a much bigger thing in that has (IMO) nearly no chance of passing code review, because it will have such code structural issues | 19:12 |
| jroll | (albeit without swift support) | 19:12 |
| lifeless | saying 'ilo virtualmedia driver with swift image-transfer support' makes my head hurt, because they aren't related at all | 19:12 |
| lifeless | there will be swift needed for the virtual media hosting itself | 19:12 |
| wanyen | lifeless: It wasn't clear to me whether you suggest us to do just iscsi or we can do both iscsi and bm+swift. | 19:13 |
| openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Add missing docstrings https://review.openstack.org/106202 | 19:13 |
| jroll | rloo: ^ | 19:13 |
| lifeless | wanyen: just iscsi, because the swift aspect is where the problems in the spec are | 19:13 |
| lifeless | wanyen: swift-for-the-main-image-transfer, I mean | 19:14 |
| JoshNang | tempurls were just approved in swiftclient. woo! | 19:14 |
| jroll | JoshNang: siiiick | 19:14 |
| jroll | JoshNang: now to see if they'll release a new client, or if we need to pin to a hash, or what | 19:15 |
| jroll | I suspect pinning to a hash would not be advised | 19:15 |
| lifeless | you'll need a new client | 19:15 |
| lifeless | pinning to a hash would be incompatible with global requirements | 19:15 |
| jroll | right | 19:15 |
| jroll | I assumed as such | 19:15 |
| lifeless | and changing global requirements to a hash would result in me jumping up and down and going 'you broke tripleo' :) | 19:16 |
| wanyen | I understand tha tIPA is using swift for deploy on bm but I don't understand why we limit this approach to just IPA because a custoemr can use iLo driver but not IPA driver. | 19:16 |
| jroll | JoshNang: get them to release, change global requirements, change ironic requirements | 19:16 |
| lifeless | wanyen: they are two independent drivers. | 19:16 |
| JoshNang | jroll: that's what i'm asking them for right now | 19:16 |
| JoshNang | yup, that's my plan | 19:16 |
| lifeless | wanyen: ilo(power-mgmt) and ilo(virtual-media) - neither have implication for image transfer | 19:16 |
| wanyen | lifeless: exactly. So both need be able to do deploy on bm over swift | 19:16 |
| lifeless | wanyen: you want to add deploy-ramdisk-swift, which is fine, but its a totally different conversation | 19:17 |
| lifeless | neither need to be able to do swift | 19:17 |
| jroll | wanyen: we're not limiting you to IPA. we're asking that you limit this to iscsi for juno, and in k we can split the interfaces properly, and if you like you could write a deploy-ramdisk-swift DeployInterface | 19:17 |
| jroll | (or just use IPA because E_TOOMANYREASONS) | 19:17 |
| lifeless | wanyen: it feels to me like you really really really want this swift deploy driver - why? Its going to overlap with IPA in lots of way, and there doesn't seem to be a good reason to do that. | 19:18 |
| lifeless | wanyen: we're on the path to probably deprecating all non-IPA deploy codepaths at some point | 19:18 |
| lifeless | wanyen: (long way down the track, but I can see it happening - once we IPA in mainline, + get multicast into IPA so that it can handle low-memory situations as efficiently as iSCSI does) | 19:19 |
| lifeless | wanyen: whats *functionally different* about using swift to transfer the image vs iSCSI that matters to you? | 19:20 |
| wanyen | okay. we will submit a different spec for vm+iscsi and target it for Juno. We will keep curent iLO deploy spec (the one with vm+bm deploy via swift) and try to land it in Juno if time permits. | 19:20 |
| jroll | ......... | 19:20 |
| lifeless | wanyen: I doubt we'll reach consensus on the current spec | 19:21 |
| *** tatyana_ has joined #openstack-ironic | 19:21 | |
| lifeless | wanyen: since now the issues we have have been identified everyone thats discussed this has gone 'oh yeah, we have to fix the structure, doh' | 19:21 |
| wanyen | lifeless: we just don't want to limit to iscsi and give users more choices if they feel bm deploy is more sutibale for htem | 19:21 |
| *** tatyana has quit IRC | 19:21 | |
| *** tatyana_ is now known as tatyana | 19:21 | |
| lifeless | wanyen: I want to give them more choice too, but pushing back against the clearly right road to do that is strange. | 19:22 |
| wanyen | lifeless: I am confused what's right what's wrong. A few months back it was right now it's wrong...etc | 19:24 |
| *** tatyana has quit IRC | 19:24 | |
| wanyen | ramesh87: you got what you need for the next steps? | 19:25 |
| lifeless | wanyen: you know technical design - you learn more about the problem space as you go along | 19:26 |
| lifeless | wanyen: its why we plan and deliver in short cycles | 19:26 |
| rameshg87 | wanyen: yes, i did. | 19:26 |
| wanyen | ramesh87: okay. | 19:27 |
| wanyen | folks! Thanks for the discussion. Once we submit the spec as suggested by this discussion, we will announce in the chat room, please review the spec as quickly as you can. | 19:30 |
| openstackgerrit | Ruby Loo proposed a change to openstack/ironic: Add drivers.base.BaseDriver.get_properties() https://review.openstack.org/107092 | 19:33 |
| openstackgerrit | Ruby Loo proposed a change to openstack/ironic: Implement API to get driver properties https://review.openstack.org/107096 | 19:49 |
| NobodyCam | brb | 19:49 |
| *** foexle has joined #openstack-ironic | 19:53 | |
| *** Nisha has joined #openstack-ironic | 20:04 | |
| *** hemna has quit IRC | 20:07 | |
| JayF | iLO driver only. | 20:14 |
| JayF | sorry bad paste | 20:15 |
| NobodyCam | lifeless: fyi https://review.openstack.org/#/c/107511 landed | 20:15 |
| jroll | ? | 20:15 |
| jroll | lol | 20:15 |
| JayF | I like clicking while reading too much :) | 20:15 |
| *** ndipanov has quit IRC | 20:15 | |
| lifeless | NobodyCam: wow, most excellent and fast | 20:18 |
| NobodyCam | :) | 20:21 |
| romcheg | jroll: I'm back from the dinner now | 20:21 |
| romcheg | jroll, devananda: I'm working on Grenade and trying to catch Sean to ask him a ton of questions :) | 20:22 |
| *** hemna has joined #openstack-ironic | 20:24 | |
| *** Nisha has quit IRC | 20:25 | |
| *** jdob has quit IRC | 20:25 | |
| Shrews | wow, i've never seen jenkins -2 a review before. am i that unobservant? | 20:38 |
| *** malini1 has quit IRC | 20:40 | |
| Shrews | ah, maybe just on verify | 20:40 |
| *** malini has joined #openstack-ironic | 20:52 | |
| NobodyCam | devananda: gots a second for pluck you brain? | 21:00 |
| devananda | NobodyCam: i'm on a train. and in the Nova meeting. go for it | 21:01 |
| NobodyCam | lol | 21:01 |
| NobodyCam | short version is I need to trigger this: https://review.openstack.org/#/c/107778 only for rebuilds | 21:02 |
| devananda | NobodyCam: so, why? | 21:04 |
| devananda | NobodyCam: also, that shouldn't be a config option, which makes it global to the whole cluster, it should be per-power-cycle | 21:04 |
| devananda | NobodyCam: also, why? soft-power can be ignored by the OS | 21:04 |
| NobodyCam | yea... that just a initial wip | 21:05 |
| devananda | that's a totally different function. "inform the host's operating system that we intend to power it off, and ask it to do so nicely" vs "turn it off" | 21:05 |
| NobodyCam | this was for rebuilds of things like mysql (or other db type applacations) servers where hard power offs are bad | 21:05 |
| devananda | lifeless: this something tripleo needs for rebuilds? | 21:06 |
| NobodyCam | I got it vi Ng | 21:07 |
| openstackgerrit | Ramakrishnan G proposed a change to openstack/ironic-specs: iLO Virtual Media iSCSI Deploy Driver https://review.openstack.org/97744 | 21:07 |
| devananda | i would think what ever is orchestrating the rebuild should quiesce sensitive services first | 21:07 |
| *** matty_dubs is now known as matty_dubs|gone | 21:07 | |
| NobodyCam | s/vi/via/ | 21:07 |
| devananda | not rely on that quiescense *during* the nova rebuild | 21:07 |
| devananda | Ng: hi! | 21:07 |
| Ng | hi :) | 21:07 |
| devananda | NobodyCam: I disagree that Ironic is the right the layer for quiesce of the guest | 21:07 |
| lifeless | devananda: so, turned up when looking at things | 21:07 |
| lifeless | devananda: I share your concern about layering | 21:07 |
| lifeless | devananda: I mentioned just an hour ago to ng that perhaps heat is the right place | 21:08 |
| lifeless | devananda: that said, I think ironic does need to know about soft vs hard off | 21:08 |
| lifeless | devananda: because nova knows/is learning | 21:08 |
| lifeless | devananda: (there's been some list discussion recently, didn't go all that far yet) | 21:08 |
| lifeless | I have to take C to kindy | 21:08 |
| devananda | lifeless: i agree that soft/hard power off awareness fits in ironic | 21:09 |
| lifeless | devananda: but I'm fairly sure there will be (or should be) a bug on nova libvirt w.r.t. soft vs hard poweroffs | 21:09 |
| devananda | and they're separate commands | 21:09 |
| devananda | s/command/function/ | 21:09 |
| rameshg87 | devananda, lifeless, NobodyCam, jroll, just posted a new design spec for the very recently discussed ilo driver with vmedia+iscsi. https://review.openstack.org/#/c/97744 | 21:09 |
| rameshg87 | devananda, lifeless, NobodyCam, jroll, please review it when you get time. thanks. | 21:10 |
| jroll | devananda: can I set provision_state while registering a node, or will it throw a fit? | 21:10 |
| lifeless | devananda: tl;dr - yes its needed, whatever the right design is is fine by me | 21:10 |
| *** rameshg87 has left #openstack-ironic | 21:14 | |
| devananda | jroll: you can not set provision state | 21:16 |
| jroll | boooo | 21:17 |
| jroll | where's that newly_registered flag? :P | 21:18 |
| devananda | jroll: for the upgrade from nova-bm, the plan is to stop ir-cond, write direct to the db, then start ir-cond | 21:21 |
| *** chuckC has quit IRC | 21:22 | |
| jroll | devananda: right, I want to add a node via the API that drops directly into decom | 21:22 |
| openstackgerrit | A change was merged to openstack/ironic: oslo.i18n migration https://review.openstack.org/105132 | 21:42 |
| devananda | lifeless: what's the status of nova.virt.baremetal testing in tripleo these days? | 21:44 |
| *** mrda-away is now known as mrda | 21:48 | |
| mrda | Morning Ironic! | 21:48 |
| NobodyCam | morning mrda | 21:48 |
| mrda | NobodyCam: \o | 21:48 |
| mrda | devananda: Just FYI, I've had a request to rework the client authentication code and move it all into the ironicclient. So I'll do that in the next few hours, get a patch up, and abandon the original ironic patch (102695). The good news is that this removes this dependency from landing the Nova Ironic driver - at least in direct code imports. | 21:53 |
| *** romcheg has quit IRC | 21:58 | |
| jroll | morning mrda | 22:00 |
| mrda | jroll: \o | 22:01 |
| devananda | mrda: i'm not sure that makes sense yet | 22:07 |
| * devananda looks at the review | 22:07 | |
| mrda | devananda: https://review.openstack.org/#/c/102695 | 22:08 |
| devananda | " I've seen this exact antipattern with novaclient and heatclient" | 22:09 |
| devananda | heh | 22:09 |
| mrda | devananda: I think there's validity on the current approach, but there's also merit in the new proposed approach. | 22:11 |
| lifeless | devananda: just calling it how I see it :) | 22:12 |
| mrda | devananda: I'm happy to have both reviews up and ironic cores can decide which one they want | 22:12 |
| devananda | lifeless: so there's two things here | 22:12 |
| mrda | devananda: but I am aware that we need to move on this today | 22:12 |
| devananda | which aren't really well separated in this review | 22:12 |
| lifeless | devananda: we still run jobs on check using nova baremetal | 22:12 |
| lifeless | devananda: we | 22:12 |
| devananda | lifeless: cool, thanks for the invo on taht | 22:12 |
| devananda | re 102695, tthis is adding both token caching and client caching | 22:13 |
| devananda | even if python-ironicclient cached the tokens, we would need the ClientCacher metaclass | 22:13 |
| devananda | to cache the client object itself | 22:13 |
| lifeless | devananda: so client caching pattern does seem like its tied into nova | 22:14 |
| lifeless | devananda: though a metaclass seems like a really weird implementation strategy | 22:14 |
| lifeless | devananda: token caching is the thing I am concerned about | 22:14 |
| devananda | lifeless: metaclass seemed bettter here than a module object to me, anyway | 22:14 |
| *** foexle has quit IRC | 22:15 | |
| mrda | lifeless: btw, I did invite you to comment on the review, so I got what I asked for :) | 22:15 |
| devananda | and it's a testable way to have a class-based singleton with guards around accessing / changing it | 22:15 |
| devananda | mrda: don't abandon this patch -- we need the cleint caching | 22:16 |
| mrda | devananda: so I'm not sure how we could seperate token and client caching. | 22:16 |
| lifeless | devananda: mrda: you should look at nova/network/neutronv2/__init__.py which is the neutron API client caching strategy | 22:16 |
| lifeless | no metaclass | 22:16 |
| mrda | i.e. what conditions would cause a client cache refresh if not token expiry? | 22:16 |
| devananda | oh | 22:16 |
| lifeless | in particular there's thread safety concerns | 22:17 |
| devananda | mrda: i think the point is, the ironic_client.get_client call is generating both a new client AND a new token | 22:17 |
| lifeless | which I haven't expressed in the current review | 22:17 |
| devananda | moving the "the token is invalid, fetch a new one" logic into the client itself | 22:17 |
| devananda | would mean we only create one ironic_client object, at service startup | 22:17 |
| NobodyCam | br | 22:18 |
| NobodyCam | brb | 22:18 |
| mrda | right so ironcclient.get_client gets a client object, that object would check token internally and refresh as needed. | 22:19 |
| mrda | the current ironic_client_wrapper code would remain, save for the refreshing part which would disappear | 22:19 |
| mrda | i.e. _cli would remain once set | 22:19 |
| devananda | mrda: has_token_expired also goes away | 22:19 |
| mrda | (....and associated fixings :) | 22:20 |
| *** chuckC has joined #openstack-ironic | 22:23 | |
| lifeless | devananda: https://review.openstack.org/#/c/104060/ | 22:24 |
| *** Haomeng has joined #openstack-ironic | 22:24 | |
| *** Haomeng|2 has quit IRC | 22:26 | |
| *** radsy has joined #openstack-ironic | 22:30 | |
| devananda | \o/ | 22:33 |
| *** malini has quit IRC | 22:37 | |
| *** malini has joined #openstack-ironic | 22:42 | |
| NobodyCam | brb... quick walkies | 22:44 |
| *** Haomeng has quit IRC | 22:50 | |
| *** Haomeng has joined #openstack-ironic | 22:50 | |
| *** wanyen has quit IRC | 22:50 | |
| *** wanyen has joined #openstack-ironic | 22:51 | |
| *** radsy has quit IRC | 22:51 | |
| *** pcrews has quit IRC | 22:51 | |
| *** ekarlso has quit IRC | 22:51 | |
| *** pradipta_away has quit IRC | 22:51 | |
| *** GheRivero has quit IRC | 22:51 | |
| *** zer0c00l has quit IRC | 22:51 | |
| *** boris-42 has quit IRC | 22:51 | |
| *** chuckC has quit IRC | 22:52 | |
| *** pquerna has quit IRC | 22:52 | |
| *** BadCub has quit IRC | 22:52 | |
| *** kevinbenton has quit IRC | 22:52 | |
| *** yuriyz has quit IRC | 22:52 | |
| *** gilliard has quit IRC | 22:52 | |
| *** coolsvap has quit IRC | 22:52 | |
| *** davidlenwell has quit IRC | 22:52 | |
| openstackgerrit | Michael Davies proposed a change to openstack/ironic: Review fixes from Nova scheduler reviews https://review.openstack.org/107316 | 22:52 |
| *** chuckC has joined #openstack-ironic | 22:53 | |
| *** pquerna has joined #openstack-ironic | 22:53 | |
| *** BadCub has joined #openstack-ironic | 22:53 | |
| *** kevinbenton has joined #openstack-ironic | 22:53 | |
| *** yuriyz has joined #openstack-ironic | 22:53 | |
| *** gilliard has joined #openstack-ironic | 22:53 | |
| *** coolsvap has joined #openstack-ironic | 22:53 | |
| *** davidlenwell has joined #openstack-ironic | 22:53 | |
| *** radsy has joined #openstack-ironic | 22:53 | |
| *** pcrews has joined #openstack-ironic | 22:53 | |
| *** pradipta_away has joined #openstack-ironic | 22:53 | |
| *** boris-42 has joined #openstack-ironic | 22:53 | |
| *** ekarlso has joined #openstack-ironic | 22:53 | |
| *** GheRivero has joined #openstack-ironic | 22:53 | |
| *** zer0c00l has joined #openstack-ironic | 22:53 | |
| mrda | Hey Ironic Reviewers: I'd appreciate getting some eyeballs on https://review.openstack.org/#/c/107316 - these are changes Nova reviewers are asking us to make before the Nova Ironic driver can land in their code. (Once you approve I port the change into the Nova tree for their approval) | 22:53 |
| *** mikal has quit IRC | 22:54 | |
| *** mikal has joined #openstack-ironic | 22:54 | |
| *** jrist has quit IRC | 22:54 | |
| *** lynxman has quit IRC | 22:54 | |
| *** pleia2 has quit IRC | 22:54 | |
| *** JayF has quit IRC | 22:54 | |
| *** soren has quit IRC | 22:54 | |
| *** stevebaker has quit IRC | 22:54 | |
| *** dtantsur|afk has quit IRC | 22:54 | |
| *** hemna_ has quit IRC | 22:54 | |
| *** zigo has quit IRC | 22:54 | |
| *** adam_g has quit IRC | 22:54 | |
| *** aignatov has quit IRC | 22:54 | |
| *** Isotopp has quit IRC | 22:54 | |
| *** aweeks has quit IRC | 22:54 | |
| *** mgagne has quit IRC | 22:54 | |
| *** enikanorov_ has quit IRC | 22:54 | |
| *** agordeev has quit IRC | 22:54 | |
| *** LiveOne has quit IRC | 22:54 | |
| *** comstud has quit IRC | 22:54 | |
| *** mmitchell has quit IRC | 22:55 | |
| *** morgabra has quit IRC | 22:55 | |
| *** tteggel has quit IRC | 22:55 | |
| *** keekz has quit IRC | 22:55 | |
| *** Ng has quit IRC | 22:55 | |
| *** chuckC has quit IRC | 22:55 | |
| *** jrist has joined #openstack-ironic | 22:55 | |
| *** lynxman has joined #openstack-ironic | 22:55 | |
| *** pleia2 has joined #openstack-ironic | 22:55 | |
| *** JayF has joined #openstack-ironic | 22:55 | |
| *** soren has joined #openstack-ironic | 22:55 | |
| *** stevebaker has joined #openstack-ironic | 22:55 | |
| *** dtantsur|afk has joined #openstack-ironic | 22:55 | |
| *** hemna_ has joined #openstack-ironic | 22:55 | |
| *** zigo has joined #openstack-ironic | 22:55 | |
| *** adam_g has joined #openstack-ironic | 22:55 | |
| *** aignatov has joined #openstack-ironic | 22:55 | |
| *** Isotopp has joined #openstack-ironic | 22:55 | |
| *** mgagne has joined #openstack-ironic | 22:55 | |
| *** aweeks has joined #openstack-ironic | 22:55 | |
| *** enikanorov_ has joined #openstack-ironic | 22:55 | |
| *** LiveOne has joined #openstack-ironic | 22:55 | |
| *** agordeev has joined #openstack-ironic | 22:55 | |
| *** comstud has joined #openstack-ironic | 22:55 | |
| *** mikal has left #openstack-ironic | 22:55 | |
| *** mikal has joined #openstack-ironic | 22:55 | |
| jroll | mrda: why is baremetal_host_manager getting pulled in | 22:55 |
| jroll | actually, I'll read the comments | 22:56 |
| jroll | gotta run for a bit | 22:56 |
| *** mmitchell has joined #openstack-ironic | 22:56 | |
| *** morgabra has joined #openstack-ironic | 22:56 | |
| *** tteggel has joined #openstack-ironic | 22:56 | |
| *** keekz has joined #openstack-ironic | 22:56 | |
| *** Ng has joined #openstack-ironic | 22:56 | |
| mrda | jroll: thanks | 22:57 |
| NobodyCam | mrda: py27 failed on the last version | 22:58 |
| NobodyCam | doesn't look like its the patch thou | 22:59 |
| mrda | recheck bug 1336161 :) | 23:00 |
| mrda | Le sigh | 23:00 |
| NobodyCam | wait until its done | 23:00 |
| mrda | NobodyCam: yup, need more patience :) | 23:00 |
| NobodyCam | :-p | 23:00 |
| *** krtaylor has quit IRC | 23:02 | |
| *** chuckC has joined #openstack-ironic | 23:03 | |
| *** jgrimm has quit IRC | 23:10 | |
| *** malini has quit IRC | 23:13 | |
| *** zul has quit IRC | 23:17 | |
| openstackgerrit | Michael Davies proposed a change to openstack/ironic: Ironic nova driver to cache ironic client calls https://review.openstack.org/102695 | 23:23 |
| *** zul has joined #openstack-ironic | 23:31 | |
| *** mdorman has quit IRC | 23:38 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!