*** chuckC has quit IRC | 00:14 | |
*** zul has quit IRC | 00:20 | |
*** zul has joined #openstack-ironic | 00:24 | |
*** mitz has joined #openstack-ironic | 00:26 | |
*** rainya has joined #openstack-ironic | 01:24 | |
*** pcrews has joined #openstack-ironic | 01:29 | |
*** Haomeng has quit IRC | 01:35 | |
*** pcrews has quit IRC | 01:43 | |
*** pcrews has joined #openstack-ironic | 01:51 | |
*** rainya has quit IRC | 01:53 | |
*** rainya has joined #openstack-ironic | 01:56 | |
*** chuckC has joined #openstack-ironic | 02:00 | |
*** pcrews has quit IRC | 02:28 | |
*** chuckC has quit IRC | 02:42 | |
*** ramineni has joined #openstack-ironic | 03:03 | |
*** eghobo has joined #openstack-ironic | 03:17 | |
*** chuckC has joined #openstack-ironic | 03:27 | |
*** chuckC has quit IRC | 03:30 | |
*** Nisha has joined #openstack-ironic | 03:56 | |
*** Poornima|mtg has joined #openstack-ironic | 04:16 | |
*** eghobo has quit IRC | 04:16 | |
*** eghobo has joined #openstack-ironic | 04:17 | |
*** Poornima|mtg is now known as Poornima_ | 04:19 | |
Nobodycam_afk | morning mrda | 04:30 |
---|---|---|
*** Nobodycam_afk is now known as NobodyCam | 04:33 | |
mrda | Hey NobodyCam | 04:35 |
NobodyCam | :) just checked into hotel in raleigh | 04:42 |
mrda | yay! Have a great sprint NobodyCam | 04:47 |
mrda | Looking forward to seeing you and everyone else in Hillsboro next week | 04:47 |
*** chuckC has joined #openstack-ironic | 04:48 | |
Nisha | Morning NobodyCam :) | 04:49 |
NobodyCam | mrda: ya; Nisha: Good morning | 04:50 |
Nisha | NobodyCam: :) | 04:51 |
*** rakesh_hs has joined #openstack-ironic | 05:05 | |
*** eghobo has quit IRC | 05:13 | |
*** rakesh_hs has quit IRC | 05:22 | |
*** shausy has joined #openstack-ironic | 05:22 | |
*** rakesh_hs has joined #openstack-ironic | 05:24 | |
*** bvivek has joined #openstack-ironic | 05:35 | |
*** rameshg87 has joined #openstack-ironic | 05:36 | |
dtantsur|afk | Good monday morning, Ironic :) | 06:02 |
*** dtantsur|afk is now known as dtantsur | 06:02 | |
*** k4n0 has joined #openstack-ironic | 06:16 | |
mrda | hi dtantsur | 06:16 |
Nisha | hi dtantsur : please look at the https://review.openstack.org/#/c/100951/ i have addressed your comment | 06:21 |
*** pradipta_away is now known as pradipta | 06:28 | |
dtantsur | Nisha, mrda, hi | 06:34 |
dtantsur | Nisha, ack, when I have some time | 06:34 |
*** pcrews has joined #openstack-ironic | 06:38 | |
rameshg87 | dtantsur: good morning | 06:39 |
*** Haomeng has joined #openstack-ironic | 06:39 | |
rameshg87 | dtantsur: just had a question | 06:39 |
dtantsur | rameshg87, morning | 06:39 |
rameshg87 | dtantsur: currently we have tftp server running on each conductor node, right ? | 06:40 |
rameshg87 | dtantsur: i am wondering whether tftp service can be moved to neutron, something like n-tftp; it seems a network service just like neutron-dhcp | 06:41 |
*** eghobo has joined #openstack-ironic | 06:41 | |
dtantsur | rameshg87, not necessary on each, but likely yes | 06:41 |
dtantsur | rameshg87, I doubt it. Neutron is about managing networks for instances, TFTP is about deploying instances, just what we do | 06:42 |
*** eghobo has quit IRC | 06:42 | |
rameshg87 | dtantsur: so currently we don't need to have tftp service running on every conductor node ? can 2 conductor nodes share a tftp service ? | 06:42 |
rameshg87 | dtantsur: based on this code, it look like we always need a tftp service for a conductor node: https://github.com/openstack/ironic/blob/master/ironic/common/tftp.py#L45-L51 | 06:43 |
dtantsur | rameshg87, no, each conductor that _requires_ tftp must have it's own | 06:44 |
dtantsur | rameshg87, but if conductor does not manager PXE nodes, it's not required to have TFTP server :) | 06:44 |
rameshg87 | dtantsur: ah okay .. | 06:44 |
*** pcrews has quit IRC | 06:44 | |
rameshg87 | dtantsur: i have seen somewhere that the issue of pxe driver is not "truly" managing the tftp service. i.e, it doesn't know really if tftp service is running or not.. | 06:45 |
dtantsur | rameshg87, that's true, and that's a current design decision. We won't manage HTTP server for iPXE just as well... | 06:46 |
dtantsur | (we could check that server is running, though) | 06:46 |
dtantsur | short walk, brb | 06:47 |
rameshg87 | dtantsur: okay.. | 06:47 |
*** ifarkas has joined #openstack-ironic | 06:52 | |
*** Halacs has joined #openstack-ironic | 07:05 | |
*** vinbs has joined #openstack-ironic | 07:12 | |
rameshg87 | hi dtantsur, are you back ? | 07:14 |
*** faizan has joined #openstack-ironic | 07:17 | |
Halacs | hi, I would like to try open stack bare metal, but I have some problems so are there any other installation guide besides the following? http://docs.openstack.org/developer/ironic/deploy/install-guide.html | 07:21 |
Halacs | I think I installed bare metal but I got this exception: TRACE nova.api.openstack OperationalError: (OperationalError) no such table: bm_nodes u'SELECT bm_nodes.created_at AS ... | 07:22 |
Halacs | Can anybody help? | 07:23 |
*** Mikhail_D_ltp has joined #openstack-ironic | 07:24 | |
*** kpavel has joined #openstack-ironic | 07:27 | |
*** pradipta is now known as pradipta_away | 07:38 | |
*** jistr has joined #openstack-ironic | 07:38 | |
*** bvivek has quit IRC | 07:41 | |
dtantsur | rameshg87, I am now | 08:05 |
dtantsur | Halacs, hi. First I guess you're still using Nova Baremetal instead of Ironic | 08:06 |
*** athomas has joined #openstack-ironic | 08:06 | |
dtantsur | Halacs, did you reconfigure Nova to use Ironic? | 08:06 |
Halacs | Hi dtantsur. No, I didn't. Do you have any guideline to do it? | 08:07 |
*** viktors|afk is now known as viktors | 08:08 | |
*** dguerri is now known as _dguerri | 08:12 | |
*** mrda is now known as mrda-away | 08:14 | |
mrda-away | night all | 08:14 |
*** _dguerri is now known as dguerri | 08:16 | |
*** dguerri is now known as _dguerri | 08:16 | |
*** _dguerri is now known as dguerri | 08:16 | |
*** dguerri is now known as _dguerri | 08:16 | |
*** _dguerri is now known as dguerri | 08:16 | |
dtantsur | Halacs, this step: http://docs.openstack.org/developer/ironic/deploy/install-guide.html#configure-compute-service-to-use-the-bare-metal-service | 08:23 |
*** lucasagomes has joined #openstack-ironic | 08:24 | |
*** romcheg1 has joined #openstack-ironic | 08:29 | |
*** romcheg1 has quit IRC | 08:30 | |
*** Nisha has quit IRC | 08:31 | |
*** bvivek has joined #openstack-ironic | 08:32 | |
Halacs | dtantsur: it should be work if I use Redhat 6.5 on all node excepts the only one which run bare metal? I have 3 nodes: controller, compute and baremetal (legacy network config) | 08:38 |
dtantsur | lucasagomes, hi! Do we need a spec for our work on TripleO as well? | 08:38 |
*** shausy has quit IRC | 08:39 | |
dtantsur | Halacs, likely yes, provided you can install the dependencies, though I'm not 100% sure. | 08:39 |
*** shausy has joined #openstack-ironic | 08:41 | |
viktors | dtantsur: hi! Could you please look at patch https://review.openstack.org/#/c/42159/ (Use oslo.db library) , when you'll have a time | 08:44 |
dtantsur | viktors, sure! | 08:44 |
Halacs | dtantsur: It seems to me I didn't configured nova.conf on each nodes, but only on the controller node. But now on controller, when I try to restart scheduler I got this on scheduler.log: ironic.nova.scheduler.ironic_host_manager : | 08:45 |
Halacs | : | 08:45 |
Halacs | :( | 08:45 |
*** Poornima_ has quit IRC | 08:45 | |
dtantsur | Halacs, ehhhr... could you paste the whole log somewhere? | 08:45 |
lucasagomes | dtantsur, hey I don't think so, for the discovery you mean? | 08:46 |
dtantsur | lucasagomes, yep. Maybe we should ask lifeless? | 08:46 |
Halacs | yes, of course, just a second and I will send a pastebin link | 08:46 |
lucasagomes | dtantsur, sure | 08:47 |
dtantsur | lucasagomes, mind asking in #tripleo ? | 08:48 |
Halacs | dtantsur: http://pastebin.com/WgY5Th0s | 08:49 |
lucasagomes | lemme do it, tho it may be quite there | 08:49 |
lucasagomes | the ooo mid-cycle starts today I think | 08:50 |
dtantsur | lucasagomes, oh, I forgot bout it | 08:50 |
dtantsur | Halacs, 1. you have to fix Glance and QPid problems first, 2. Seems like Ironic python modules are not installed to where Nova can find them | 08:51 |
*** shausy has quit IRC | 08:51 | |
lucasagomes | dtantsur, yeah... well I asked anyway | 08:51 |
dtantsur | Folks, especially, cores, it's the last call to review oslo.db patch https://review.openstack.org/#/c/42159/ :) It got 3x +2 and is close to being approved | 08:54 |
*** Alexei_9871 has joined #openstack-ironic | 08:55 | |
*** dguerri is now known as _dguerri | 08:56 | |
lucasagomes | dtantsur, I will approve it, I left a comment saying that I didn't approve before because I wanted to get more reviews | 08:56 |
lucasagomes | so now I think it's fine to go and approve it | 08:57 |
dtantsur | heh, that's good :) | 08:57 |
lucasagomes | and folks we need more reviews at the mgmt interface as well | 08:57 |
lucasagomes | https://review.openstack.org/86092 | 08:57 |
dtantsur | viktors, does oslo.db has something similar to what we do in https://review.openstack.org/#/c/73121/ ? I remember asking this, but things could change | 08:57 |
dtantsur | lucasagomes, did we again agree on using _LW? | 08:58 |
lucasagomes | dtantsur, oh I think so, we even merged the oslo i18n patch | 08:59 |
lucasagomes | I'm trying to use on my patches _LW, _LI | 08:59 |
lucasagomes | cause that's the new way to do it | 08:59 |
dtantsur | lucasagomes, wow. Was it announced? Because I had not idea previously... | 08:59 |
lucasagomes | https://review.openstack.org/#/c/105132 | 09:00 |
lucasagomes | right... hmm lemme search, I got some -1's telling me to use it | 09:00 |
lucasagomes | but lemme search for a better source | 09:01 |
dtantsur | lucasagomes, one issue with mgmt patch, otherwise ok | 09:02 |
Halacs | dtantsur, 1. I think glance and QPid problems is solved because I can start a standard virtual machine from web UI. 2. I check it know. | 09:02 |
lucasagomes | dtantsur, ack cheers, I will fix it quickly | 09:02 |
*** _dguerri is now known as dguerri | 09:03 | |
dtantsur | Halacs, there should not be errors in a log; at least Ironic won't work w/o QPid. Please solve these first. | 09:03 |
*** rainya has quit IRC | 09:03 | |
Halacs | dtantsur, okey | 09:04 |
lucasagomes | dtantsur, I will have to dig into the functions and find out what exceptions it may raise... I left Exception because the it's not obivious on the function, and the docstring doesn't help much either: ":raises: some Exception from making the password file or from executing the command" | 09:06 |
lucasagomes | hah | 09:06 |
lucasagomes | some Exception... | 09:06 |
lucasagomes | lol | 09:06 |
viktors | dtantsur: at the moment no. But we are going to modify error wrapping in oslo.db, see spec - https://review.openstack.org/#/c/105306/ | 09:07 |
dtantsur | lucasagomes, well, I can try to live with `except Exception`, but I highly want the `try` block to cover only this peace | 09:07 |
lucasagomes | dtantsur, yeah lemme take a look | 09:08 |
*** martyntaylor has joined #openstack-ironic | 09:08 | |
*** romcheg1 has joined #openstack-ironic | 09:09 | |
*** rainya has joined #openstack-ironic | 09:10 | |
dtantsur | viktors, interesting spec. When do you expect it to land? | 09:10 |
*** Nisha has joined #openstack-ironic | 09:12 | |
*** martyntaylor has quit IRC | 09:13 | |
viktors | dtantsur: Mike Bayer (zzzeek) working on this at the moment. Feel free to review his patches - https://review.openstack.org/#/q/project:openstack/oslo.db+branch:master+topic:bp/use-events-for-error-wrapping,n,z | 09:13 |
dtantsur | ack | 09:13 |
viktors | dtantsur: we are suppose to get these pathes merged during the week (or two) | 09:13 |
dtantsur | I see | 09:14 |
*** Poornima|mtg has joined #openstack-ironic | 09:22 | |
*** rainya has quit IRC | 09:22 | |
*** dguerri is now known as _dguerri | 09:25 | |
*** pelix has joined #openstack-ironic | 09:26 | |
*** Poornima|mtg is now known as Poornima_ | 09:26 | |
lucasagomes | dtantsur, problem with the exceptions is the mkstemp | 09:27 |
lucasagomes | https://docs.python.org/2/library/tempfile.html#tempfile.mkstemp | 09:27 |
lucasagomes | it's not even documented what it may raise | 09:27 |
dtantsur | lucasagomes, I would assume it should not raise, unless something completely crazy is going on | 09:27 |
lucasagomes | I can log a debug of the stdout and stderr of that command to help with the debug | 09:27 |
*** martyntaylor has joined #openstack-ironic | 09:28 | |
lucasagomes | dtantsur, right, so catch only the processutils.execute exceptions? | 09:28 |
romcheg1 | Morning guys! | 09:28 |
dtantsur | lucasagomes, yes. If we encounter something new, we should give it a thought, not just try to cover everything :) and also please cover only that block with try..except.. | 09:28 |
dtantsur | romcheg1, morning :) | 09:28 |
*** _dguerri is now known as dguerri | 09:29 | |
lucasagomes | dtantsur, ack | 09:29 |
dtantsur | Folks, lucasagomes, we have more-or-less prioritized specs to review: IPA https://review.openstack.org/#/c/98506/ ; discovery https://review.openstack.org/#/c/107344 :) | 09:31 |
*** athomas has quit IRC | 09:34 | |
*** Nisha has quit IRC | 09:38 | |
faizan | Hi dtantsur, lucasagomes, | 09:44 |
dtantsur | faizan, hi! | 09:44 |
faizan | dtantsur: lucasagomes: request you folks to review this design spec for uefi support https://review.openstack.org/#/c/99850/ | 09:45 |
dtantsur | faizan and folks: please note that we do have your patches on our dashboards; unlike ironic-core team, ironic-specs-core is very limited, with only ~3 folks constantly reviewing things. We don't skip your patches because of bad will ;) | 09:47 |
dtantsur | I mean, sure, once we have some time :) | 09:47 |
*** athomas has joined #openstack-ironic | 09:49 | |
*** enikanorov__ has quit IRC | 09:52 | |
dtantsur | lucasagomes, we agreed on you chairing the meeting today, right? | 09:52 |
lucasagomes | yup | 09:53 |
lucasagomes | hope I remember all the commands heh | 09:53 |
dtantsur | I guess there are docs somewhere :) | 09:56 |
*** dguerri is now known as _dguerri | 10:02 | |
*** _dguerri is now known as dguerri | 10:02 | |
faizan | dtantsur: thanks for having it in your pipeline. Will wait for your review comments. | 10:06 |
mrda-away | dtantsur: thanks for your review of 107316 | 10:21 |
lucasagomes | py26 test is broke in gate :/ | 10:21 |
mrda-away | dtantsur: I have a differing view on changing host_state_cls - this is the interface into baremetal, so with ironic coming in, I was keen to maintain that interface. | 10:22 |
mrda-away | dtantsur: but if you want to discuss this more, I'm happy to ;) | 10:22 |
dtantsur | mrda-away, IIRC, you're anyway introducing a new base class and will be changing bm code. So I don't think we should keep a confusing (and it's obviously confusing, if it used to require a special comment) name | 10:23 |
dtantsur | lucasagomes, oh no | 10:23 |
*** romcheg1 has left #openstack-ironic | 10:26 | |
*** romcheg1 has joined #openstack-ironic | 10:26 | |
mrda-away | dtantsur: so this will be a little tricky - it impacts another file then - nova/tests/scheduler/test_baremetal_host_manager.py - which is not in our tree, but we're proposing to modify | 10:26 |
dtantsur | mrda-away, it will impact it anyway: you're changing attribute to a function | 10:27 |
mrda-away | umm, no, because originally it has a function reference - the move to an attribute was an attempt to be tricky at maintaining the interface but cleaning it up. Unfortunately properties can't have multiple params, so we couldn't go down that path | 10:28 |
mrda-away | sorry, originally host_state_cls was a function reference | 10:28 |
dtantsur | mrda-away, yeah, sorry, I see now | 10:29 |
dtantsur | so if it's for compatibility, then let's leave it | 10:29 |
dtantsur | (I'd like to see it changed later in Nova tree though) | 10:29 |
*** romcheg2 has joined #openstack-ironic | 10:30 | |
mrda-away | How about I compromise - what if I propose a change in the Nova tree to change the interface, and if it lands before we do, then we'll rebase accordingly? | 10:30 |
mrda-away | dtantsur: does that sound like a good idea? | 10:30 |
dtantsur | mrda-away, sounds good! | 10:30 |
mrda-away | So, to be clear, I agree, but I really want this to land in J :) | 10:31 |
*** romcheg1 has quit IRC | 10:32 | |
dtantsur | mrda-away, yeah sure, me too :) | 10:32 |
*** Haomeng|2 has joined #openstack-ironic | 10:33 | |
*** Haomeng has quit IRC | 10:35 | |
Halacs | dtantsur: now in scheduler.log, the only message is "ImportError: No module named ironic.nova.scheduler.ironic_host_manage". Can you give me, for example, a package name which I should install to RedHat6.5? python-ironicclient yum package isn't enough unfortunately | 10:39 |
dtantsur | Halacs, ironicclient is required, but not enough. You have to install Ironic itself | 10:40 |
dtantsur | I am not sure how it is called, probably ironic-conductor | 10:40 |
rameshg87 | Halacs: seems a typo ?? | 10:40 |
rameshg87 | Halacs: did you paste the full error message ? | 10:41 |
Halacs | This is the full error msg: "2014-07-21 11:30:56.459 2231 CRITICAL nova [-] ImportError: No module named ironic.nova.scheduler.ironic_host_manager" | 10:41 |
dtantsur | ironic.nova.scheduler.ironic_host_manager is not in python-ironicclient package | 10:42 |
*** Poornima_ has quit IRC | 10:48 | |
dtantsur | lucasagomes, re my discovery spec: I realized I barely understand, on which conductors to call set_discovery_enabled? On every? What if they modify some global resource (like neutron)? | 10:52 |
lucasagomes | dtantsur, yes it should go to all conductors | 10:52 |
dtantsur | lucasagomes, should I put this to a spec? | 10:52 |
lucasagomes | I think so | 10:53 |
dtantsur | ack | 10:53 |
lucasagomes | crap can't find the ML about the specs deadline | 10:54 |
dtantsur | lucasagomes, you can just propose and see what happens :D | 10:55 |
lucasagomes | nah it's not up to me | 10:55 |
mrda-away | lucasagomes: http://openstack.10931.n7.nabble.com/Ironic-Juno-priorities-and-spec-review-timeline-td44905.html | 10:55 |
lucasagomes | cheers mrda-away ! | 10:56 |
mrda-away | I really should be away | 10:56 |
mrda-away | ;P | 10:56 |
lucasagomes | hehe | 10:57 |
lucasagomes | ta much | 10:58 |
dtantsur | lucasagomes, please also have a look, if I forgot something else in my spec | 11:01 |
*** ramineni has quit IRC | 11:05 | |
rameshg87 | dtantsur: just a question for a spec which you have reviewed, eventhough it is for ipa | 11:25 |
dtantsur | ? | 11:25 |
rameshg87 | dtantsur: for "Add deploy driver for ironic-python-agent" https://review.openstack.org/#/c/98506/7 | 11:25 |
rameshg87 | dtantsur: we don't say how the deploy agent ramdisk is booted on the bm node | 11:26 |
*** dguerri is now known as _dguerri | 11:26 | |
rameshg87 | dtantsur: and we have another blueprint "Support long-running deploy ramdisks" https://review.openstack.org/#/c/102405/ | 11:26 |
dtantsur | rameshg87, I guess deploy ramdisk is booted like in PXE, though you better ask jroll | 11:27 |
rameshg87 | dtantsur: so does ipa will have a configuration option ? | 11:27 |
*** ifarkas has quit IRC | 11:27 | |
rameshg87 | dtantsur: to choose whether they want long-running-ramdisks OR on-demand-booted-ramdisks ? | 11:27 |
rameshg87 | dtantsur: yeah, i though jroll might be a better person to ask, was just checking if you would know :-) | 11:28 |
dtantsur | rameshg87, I don't quite remember, sorry. I'm not sure it's 100% decided | 11:28 |
rameshg87 | dtantsur: okay .. | 11:28 |
rameshg87 | dtantsur: is it targeted for juno ? | 11:28 |
rameshg87 | dtantsur: long running ramdisks ??? | 11:28 |
dtantsur | rameshg87, probably not, I'm not sure either | 11:29 |
rameshg87 | dtantsur: okay .. | 11:29 |
*** lucasagomes is now known as lucas-hungry | 11:33 | |
viktors | anybody knows, what happened with py26 gate tests? | 11:35 |
Halacs | I want to install a new OpenStack for Ubuntu, but which version of Ubuntu is compatible with bare metal? | 11:37 |
Halacs | 14.04 LTS? | 11:38 |
*** lazy_prince has quit IRC | 11:38 | |
*** igordcard has joined #openstack-ironic | 11:40 | |
NobodyCam | good morning Ironic | 11:44 |
Shrews | morning NobodyCam. Welcome to NC | 11:45 |
NobodyCam | thank you thank you :) | 11:45 |
NobodyCam | wow its muggie out side | 11:45 |
Shrews | yup | 11:46 |
*** chuckC has quit IRC | 11:47 | |
*** Haomeng has joined #openstack-ironic | 11:48 | |
*** Haomeng|2 has quit IRC | 11:49 | |
*** igordcard has quit IRC | 11:52 | |
dtantsur | NobodyCam, morning :) | 12:00 |
dtantsur | Halacs, 14.04 should be ok, though Ironic has developed greatly since Icehouse release | 12:00 |
Halacs | great, thanks. | 12:06 |
*** killer_prince has joined #openstack-ironic | 12:06 | |
*** killer_prince is now known as lazy_prince | 12:07 | |
*** vinbs has quit IRC | 12:07 | |
*** lsmola has joined #openstack-ironic | 12:24 | |
*** k4n0 has quit IRC | 12:28 | |
*** lsmola has quit IRC | 12:34 | |
*** jdob has joined #openstack-ironic | 12:36 | |
*** derekh_ has joined #openstack-ironic | 12:37 | |
*** lucas-hungry is now known as lucasagomes | 12:39 | |
lucasagomes | morning NobodyCam Shrews | 12:39 |
lucasagomes | if you guys have a time please take a look at https://review.openstack.org/#/c/86092/ | 12:39 |
lucasagomes | dtantsur, will take a look, I'll also try to see if I can workaround that problem on ks | 12:41 |
*** lazy_prince is now known as killer_prince | 12:42 | |
lifeless | dtantsur: hi, ask me what? | 12:42 |
lucasagomes | lifeless, I think it was about the autodiscovery we are working on for Ironic... I will need to create an element for DIB for that, he was wondering whether we would need a spec for that or not | 12:43 |
lucasagomes | lifeless, the element is here https://review.openstack.org/107672 | 12:44 |
lifeless | we don't need a spec just because, but if its going to be contentious or tricky, we will | 12:44 |
lucasagomes | yeah, I don't think we need any as well, we are not changing anything on DIB | 12:44 |
lucasagomes | no special needs for that element | 12:44 |
lucasagomes | but thanks for confirming it | 12:45 |
*** lsmola has joined #openstack-ironic | 12:47 | |
Shrews | lucasagomes: morning! about to drive down to the tripleo meetup, but can try to look later | 12:49 |
lucasagomes | Shrews, oh aight, no problem! enjoy the meeting | 12:49 |
*** rameshg87 has left #openstack-ironic | 12:52 | |
*** Halacs has quit IRC | 12:53 | |
lucasagomes | viktors, yeah it seems to be failing... weird enough some patches have passed that test. Have you tried to rebase the oslo.db patch with master recently? | 12:55 |
NobodyCam | morning dtantsur | 12:56 |
*** lsmola has quit IRC | 12:58 | |
NobodyCam | morning lucasagomes | 12:58 |
*** lsmola has joined #openstack-ironic | 13:05 | |
viktors | lucasagomes: no, I haven't. I looked into the tests log, and seems to be, that rebase will not help | 13:05 |
lucasagomes | yeah it's something with pip | 13:05 |
lucasagomes | :( | 13:05 |
viktors | yes :( | 13:06 |
*** jcoufal has joined #openstack-ironic | 13:07 | |
*** matty_dubs|gone is now known as matty_dubs | 13:09 | |
*** rloo has joined #openstack-ironic | 13:10 | |
*** ramineni has joined #openstack-ironic | 13:24 | |
jroll | goodmorning everybody | 13:34 |
*** bvivek has quit IRC | 13:34 | |
jroll | I missed ramesh :( | 13:34 |
lucasagomes | morning jrist | 13:35 |
lucasagomes | jroll, | 13:35 |
lucasagomes | jrist, morning hah sorry man | 13:35 |
jroll | heya lucas | 13:35 |
*** lsmola has quit IRC | 13:39 | |
dtantsur | jroll, morning | 13:40 |
jrist | morning to you lucasagomes :) | 13:40 |
jrist | also good morning jroll | 13:40 |
jroll | mornin dtantsur, jrist | 13:40 |
* jroll makes a script to say good morning to everyone currently in channel | 13:40 | |
lucasagomes | :D | 13:40 |
*** dhellmann is now known as dhellmann_ | 13:41 | |
*** ramineni has quit IRC | 13:42 | |
*** kpavel has quit IRC | 13:48 | |
*** Poornima|mtg has joined #openstack-ironic | 13:49 | |
*** Poornima|mtg is now known as Poornima_ | 13:49 | |
*** faizan has quit IRC | 13:53 | |
*** martyntaylor has left #openstack-ironic | 13:59 | |
jroll | 2014-07-21 14:00:30.478 WARNING wsme.api [-] Client-side error: Couldn't apply patch '[{'path': '/extra/vif_port_id', 'op': 'remove'}]'. Reason: 'vif_port_id' | 14:04 |
jroll | anybody know what might make this happen in devstack? | 14:04 |
jroll | oh that's tearing down isn't it | 14:05 |
* jroll booooooo | 14:05 | |
devananda | o/ | 14:05 |
jroll | morning deva | 14:06 |
devananda | mornin | 14:07 |
*** killer_prince has quit IRC | 14:08 | |
*** Poornima_ has quit IRC | 14:09 | |
*** Poornima|mtg has joined #openstack-ironic | 14:10 | |
*** Poornima|mtg is now known as Poornima_ | 14:10 | |
dtantsur | devananda, morning | 14:11 |
lucasagomes | devananda, morning | 14:14 |
lucasagomes | jroll, I think the driver capture that and just pass | 14:14 |
NobodyCam | good morning devananda | 14:16 |
jroll | lucasagomes: yeah, figured that one out... | 14:17 |
jroll | now running into: 2014-07-21 14:16:48.007 WARNING nova.network.neutronv2.api [-] Neutron error: quota exceeded | 14:18 |
lucasagomes | :/ | 14:18 |
jroll | killing builds | 14:18 |
dtantsur | lucasagomes, I'm thinking about discovery again and now I'm starting to think, that we should only route `enable_discovery` request to one of the conductors | 14:18 |
lucasagomes | dtantsur, only one? why? | 14:18 |
lucasagomes | dtantsur, btw, we need to know if it's enabled or not | 14:18 |
dtantsur | lucasagomes, why would we want all of them? discovery does not seem to require some local environment | 14:19 |
dtantsur | lucasagomes, are we really going to create PXE environment on every conductor? | 14:20 |
lucasagomes | dtantsur, well I was thinking that all conductors would need to be able to answer the dhcp request | 14:20 |
dtantsur | lucasagomes, you mean PXE? | 14:20 |
jroll | keep in mind the use case for this is running discovery on a ton of nodes at one time | 14:20 |
jroll | I'd prefer that be able to scale :) | 14:20 |
*** jgrimm has joined #openstack-ironic | 14:21 | |
devananda | dtantsur: all conductors need to be able to perform discovery | 14:21 |
lucasagomes | dtantsur, well PXE starts with a dhcp requests | 14:21 |
lucasagomes | and as jroll pointed it needs to scale | 14:21 |
jroll | lucasagomes: neutron answers the dhcp request | 14:21 |
devananda | dtantsur: if we have only one conductor responsible for an entire capability, it isn't HA | 14:21 |
jroll | the conductor just does the tftp bit | 14:21 |
lucasagomes | so we can't let only 1 conductor handle it all | 14:21 |
lucasagomes | yeah | 14:21 |
devananda | dtantsur: and we may have conductors deployed in different locations | 14:21 |
devananda | eg, different racks | 14:22 |
jroll | but yeah, that's a non-starter | 14:22 |
dtantsur | devananda, lucasagomes, makes sense | 14:22 |
* jroll waits for stack.sh | 14:22 | |
lucasagomes | jroll, yeah and tftp is _very_ testing with 3 machines its already pretty slow | 14:22 |
devananda | eventually we should have location-awareness (eg, for affinity-based scheduling) | 14:22 |
jroll | lucasagomes++ | 14:22 |
lucasagomes | devananda, jroll https://www.youtube.com/watch?v=gZGYeo7sJhQ | 14:22 |
lucasagomes | very first stab at it on friday | 14:22 |
jroll | lucasagomes: try tftp with a large image... doesn't even work | 14:23 |
lucasagomes | jroll, yeah, that's why iPXE ftw! | 14:23 |
dtantsur | now a stupid question: how can I send a message to all conductors with a given driver? Should I get list of hosts from hash ring and iterate over it? Doesn't sound right :) | 14:23 |
*** datajerk has quit IRC | 14:23 | |
jroll | lucasagomes++++++++ | 14:23 |
lucasagomes | dtantsur, you have that list from the hashring | 14:23 |
jroll | lucasagomes: are you using kvm in that video? | 14:24 |
lucasagomes | jroll, yeah | 14:24 |
dtantsur | lucasagomes, right. Is it good to put N messages to RPC, where N is number of conductors from hash ring? | 14:24 |
jroll | lucasagomes: what's that gui vm manager thing? also, you running devstack locally, outside of a vm? D: | 14:24 |
lucasagomes | dtantsur, you can also send a broadcast to all conductors, and they can check if they have the driver loaded | 14:24 |
lucasagomes | jroll, yeah that's virt-manager, devstack is inside a vm | 14:25 |
jroll | ah | 14:25 |
dtantsur | hmmm.... any advice on which approach is better? | 14:25 |
jroll | thanks | 14:25 |
lucasagomes | jroll, https://review.openstack.org/#/c/107672/ | 14:25 |
lucasagomes | jroll, that's the custom ramdisk I created that interrogate the machine and register on ironic | 14:25 |
jroll | lucasagomes: nice :) | 14:27 |
dtantsur | still folks, what is better: a broadcast message to all conductors or several messages only to related conductors? | 14:28 |
lucasagomes | dtantsur, hmm /me thinking | 14:28 |
* dtantsur is not strong in AMQP and friends | 14:28 | |
*** dhellmann_ is now known as dhellmann | 14:30 | |
lucasagomes | devananda, btw, this thing about the discovery... it's per driver but drivers but there's no driver table in the db | 14:31 |
lucasagomes | devananda, I think we would need to make drivers an entity on the db as well to hold such informations | 14:31 |
* lucasagomes can't think about any other solution :/ | 14:32 | |
dtantsur | lucasagomes, let's skip it, it won't get into Juno, I'm afraid... | 14:32 |
devananda | dtantsur: each driver has (or could have) separate RPC bus | 14:32 |
*** rwsu has joined #openstack-ironic | 14:32 | |
lucasagomes | dtantsur, I'm trying to think in a way to avoid having it... but I didn't yet | 14:33 |
devananda | dtantsur: so you should be able to do RPC broadcast to notify all conductors "driver X should start discovery with paramters Y" | 14:33 |
*** datajerk has joined #openstack-ironic | 14:33 | |
devananda | and not need any db changes | 14:33 |
devananda | API service can already check "is driver X supported by active conductors?" | 14:33 |
devananda | so we can error out before broadcast if the driver is not loaded | 14:33 |
devananda | and if it is, jsut broadcast it, and tell user 202 ACCEPTED | 14:34 |
dtantsur | devananda, so it's similar to get_topic_for_driver, but with notifying all topics? | 14:34 |
devananda | and each conductor, upon receiving that message, checks local drivers and discards the message if that driver isn't supported | 14:34 |
devananda | dtantsur: no | 14:35 |
lucasagomes | dtantsur, there's a default topic on each conductor | 14:35 |
lucasagomes | you can use that topic to send it to all conductors | 14:35 |
dtantsur | ah, seems like I'm starting to understand | 14:35 |
dtantsur | so it's essentially not passing any topic to the call, just using the default? | 14:35 |
dtantsur | devananda, re returning 202, I thought of returning error to use, if driver does not support the feature. Does it make sense to you? | 14:36 |
lucasagomes | dtantsur, if no conductors on the cluster supports that driver, yes makes sense return error | 14:36 |
lucasagomes | if >= 1 does, 202 | 14:37 |
dtantsur | lucasagomes, no, I meant if driver is not imlementing the feature | 14:37 |
devananda | lucasagomes: I think dtantsur is saying, if the requested driver is active but IT doesn't support discovery | 14:37 |
devananda | so | 14:37 |
devananda | dtantsur: | 14:37 |
lucasagomes | ah | 14:37 |
dtantsur | yes | 14:37 |
devananda | dtantsur: the API service should already know that | 14:39 |
devananda | ah, no | 14:39 |
devananda | it doesn't | 14:39 |
devananda | it knows taht per-node | 14:39 |
devananda | :( | 14:39 |
devananda | v1/driver/XXX/validate would indicate which driver interfaces are supported | 14:40 |
devananda | but taht's per-node | 14:40 |
devananda | lucasagomes: so, driver interface question | 14:40 |
dtantsur | yeah, it's a bit difficult... to me this will require actually calling the RPC and checking the results | 14:40 |
devananda | dtantsur: lucasagomes: where does "discovery" fit w.r.t. the DriverInterface API, as you two are proposing it? | 14:40 |
dtantsur | devananda, I expected it to be something new in the management interface | 14:41 |
devananda | the interfaces are, by definition, node-specific, with the exception of driver_vendor_passthru, which is exempt from considerations of supported, etc | 14:41 |
dtantsur | if I got your question right | 14:41 |
devananda | dtantsur: but the management interface is meant to address any request to a specific node | 14:42 |
dtantsur | hmmmm... | 14:42 |
devananda | really all the interfaces are | 14:42 |
*** ramineni has joined #openstack-ironic | 14:42 | |
devananda | to add a non-node-dependent discovery function to the mgmt interface, it means adding an interface method which doesn't take a TaskManager parameter | 14:43 |
devananda | to get down to the specifics | 14:43 |
dtantsur | yes, that's how I saw it.. | 14:43 |
lucasagomes | hmm thinking... | 14:43 |
lucasagomes | yeah that's correct :/ | 14:43 |
devananda | and at the high level, it means calls like MagagementInterface.validate() don't apply to it | 14:43 |
dtantsur | well, yes | 14:44 |
dtantsur | devananda, do you suggest creating a new interface? or what? | 14:46 |
dtantsur | all this does not look perfect to me, but nor does it look awful | 14:46 |
lucasagomes | unless we use discover as a driver vendor passthru method | 14:47 |
lucasagomes | for now | 14:47 |
lucasagomes | as a first stab at it | 14:47 |
devananda | lucasagomes: ++ | 14:47 |
dtantsur | driver vendor passthru is Yet Another exceptional method | 14:48 |
devananda | *vendor_passthru is there to break such new ground until folks can agree | 14:48 |
devananda | dtantsur: it is granted exceptional status intentionally | 14:48 |
devananda | because it doesn't lock down the API | 14:48 |
lucasagomes | right, yeah it can work | 14:48 |
dtantsur | aren't we complicating things again? | 14:48 |
devananda | it IS going to cause pain to folks | 14:48 |
devananda | no matter how we address this now, I don't see any concensus | 14:48 |
jroll | wait... what are we adding to the API? | 14:49 |
devananda | either we put it in the expection and widely visible exception area as an exception to the API | 14:49 |
jroll | a thing to initiate discovery or? | 14:49 |
devananda | ie, vendor passthru | 14:49 |
lucasagomes | jroll, yeah, active/deactive discovery | 14:49 |
devananda | or we add something to the common API that we have not come to an agreement on | 14:50 |
dtantsur | devananda, but vendor passthru now is routed to only one conductor | 14:50 |
dtantsur | chosen randomly | 14:50 |
devananda | and will probably have to change, thus breaking API compatibility | 14:50 |
jroll | I almost think of discovery as a provision_state... but I guess you can't do that without the node id | 14:50 |
devananda | dtantsur: yes. vendor passthru is very limited | 14:50 |
devananda | jroll: right | 14:50 |
jroll | but what is there to enable? just turning on pxe/tftp for unidentified nodes? | 14:50 |
devananda | jroll: a node could be in provision_state "DOING_DISCOVERY_ON_THIS_THING" :) | 14:50 |
devananda | jroll: running a special discovery ramdisk | 14:51 |
dtantsur | I hoped we got the spec procedure to come to agreements... | 14:51 |
devananda | dtantsur: I haven't looked in the last few days, but is there agreement? | 14:51 |
jroll | devananda: on identified nodes, why not just add to /nodes/uuid/states/provision | 14:51 |
dtantsur | devananda, no, nobody has looked :) | 14:51 |
devananda | dtantsur: heh | 14:51 |
jroll | like set provision_state to 'discovery' and pass off to the conductor | 14:51 |
dtantsur | so there's neither agreement nor disagreement :) | 14:51 |
jroll | and for unidentified nodes... just look at the config option on startup | 14:52 |
dtantsur | jroll, we're only discussing unregistered nodes | 14:52 |
jroll | so what's wrong with looking at configs, and always having that ramdisk available? | 14:52 |
jroll | (or never) | 14:52 |
devananda | jroll: ++ | 14:52 |
*** MattMan has joined #openstack-ironic | 14:52 | |
dtantsur | devananda, it was your point, that we should have a way to enable/disable discovery w/o restarting | 14:52 |
devananda | jroll: though I think the 'config' there needs to be dynamic | 14:53 |
devananda | dtantsur: yes. was typing second half of my thought :) | 14:53 |
jroll | devananda: meh | 14:53 |
devananda | perhaps that is a sufficient first approximation | 14:53 |
devananda | dtantsur: would that simplify the discussion enough to bring agreement? | 14:53 |
jroll | why do we need to do that without restarting? | 14:53 |
jroll | like, rolling restarts are a thing | 14:54 |
Shrews | lucasagomes: re: 86092... test_management_interface_get_boot_device_unkown_dev .... should be "unknown" | 14:54 |
dtantsur | devananda, everything that will get to somewhat-working discovery has my agreement :D | 14:54 |
devananda | jroll: example... I have a cloud. I plug in a new rack. I want to discover it. Then, I want to STOP discovery so as to prevent uninvited guests | 14:54 |
lucasagomes | Shrews, :( typo? I will fix that | 14:54 |
dtantsur | devananda, do we have a way for a driver to do something on start-up? | 14:54 |
jroll | devananda: I get the use case... and I get that we'd prefer it to be dynamic... but for a first version, jfdi and worry about an api endpoint for it later | 14:55 |
jroll | devananda: or like, lock the door on your DC :) | 14:55 |
* dtantsur was suggesting not doing it from the beginning >_< | 14:56 | |
dtantsur | I am really wondering, if our spec process is working, provided we anyway have to discuss everything on IRC... | 14:57 |
*** bvivek has joined #openstack-ironic | 14:57 | |
jroll | but if we must add an endpoint... driver_vendor_passthru ftw | 14:57 |
dtantsur | brb, need some coffee | 14:58 |
Shrews | lucasagomes: also, the generated docs for get_boot_device() don't look correct. http://docs-draft.openstack.org/92/86092/23/check/gate-ironic-docs/4811662/doc/build/html/api/ironic.drivers.modules.ipmitool.html#module-ironic.drivers.modules.ipmitool | 14:59 |
Shrews | lucasagomes: otherwise, lgtm :) | 14:59 |
*** malini1 has joined #openstack-ironic | 14:59 | |
*** rainya has joined #openstack-ironic | 14:59 | |
rloo | hi lucasagomes: wrt 86092 - I had a question (see my comment). | 14:59 |
lucasagomes | Shrews, thanks will address that | 15:00 |
*** rainya has quit IRC | 15:00 | |
lucasagomes | rloo, will take a look | 15:00 |
devananda | jroll: yes. but jfdi in a way that doesn't break the API for the next improvement | 15:00 |
*** rainya has joined #openstack-ironic | 15:00 | |
devananda | dtantsur: we have conductor.manager:init_host() which could be extended to let drivers do some init too | 15:01 |
devananda | dtantsur: I think that's totally reasonable but no, we don't have a separate interface for that today | 15:01 |
jroll | devananda: if we don't touch the API, I don't think it will break it :) | 15:01 |
devananda | jroll: exactly :) | 15:01 |
lucasagomes | rloo, right... so the idea is that if we can't get the boot device we return unknown | 15:01 |
jroll | devananda: so... make it a config option | 15:01 |
jroll | don't make it dynamic (yet) | 15:02 |
rloo | lucasagomes: but if we can't even do an ipmitool cmd, we raise an exception instead of returning unknown. | 15:02 |
devananda | jroll: *nod* | 15:02 |
jroll | devananda: deploy new configs /b 74 | 15:02 |
NobodyCam | is the py26 job broken? | 15:02 |
jroll | ughhhhhhh | 15:02 |
* jroll needs to learn to finish thoughts | 15:03 | |
*** openstackgerrit has joined #openstack-ironic | 15:03 | |
lucasagomes | rloo, right I can do that then | 15:03 |
devananda | jroll: so that works for a DHCP-based boot mechanism | 15:03 |
dtantsur | devananda, let me ask, if the only generic thing left is adding a newly_discovered column, should I even have a spec for it? Or we just silently add it :) | 15:03 |
devananda | jroll: how does config-option-driven discovery work for something like iLO-based boot mechanism? | 15:03 |
lucasagomes | rloo, will change it to raise IPMIFailure on an error from ipmitool | 15:03 |
jroll | devananda: touché | 15:04 |
devananda | thus the need for an API | 15:04 |
devananda | :( | 15:04 |
rloo | lucasagomes: thx. I wasn't sure which made more sense, but yeah, raising IPMIFailure might be good. | 15:04 |
jroll | devananda: driver_vendor_passthru awayyyyyyyyyy | 15:04 |
lucasagomes | hah | 15:04 |
devananda | jroll: yea.... | 15:04 |
lucasagomes | devananda, jroll so... config option for now? | 15:05 |
devananda | lucasagomes: that seems to unblock the discussion, be generally applicable (even iLO can use a cnofig option) and then non-DHCP-based drivers will need to use driver_vendor_passthru | 15:05 |
devananda | we should check with wan-yen (or who ever was proposing iLO discovery) if that can work for them | 15:06 |
lucasagomes | right, yeah... we def can improve it on K | 15:06 |
lucasagomes | it's good to have something for now, baby steps | 15:06 |
devananda | NobodyCam: are you seeing all the py26 jobs failing? | 15:07 |
devananda | NobodyCam: http://logs.openstack.org/59/42159/16/check/gate-ironic-python26/890b436/console.html has some really neat errors | 15:07 |
devananda | NobodyCam: but I haven't looked at other jobs yet | 15:07 |
jroll | I know this is an outstanding bug, but for this library it's so ironic | 15:08 |
jroll | 2014-07-21 12:05:28.266 | http://pypi.openstack.org/simple/cryptography/ uses an insecure transport scheme (http). Consider using https if pypi.openstack.org has it available | 15:08 |
* jroll bbl | 15:09 | |
dtantsur | devananda, lucasagomes, jroll, ok, config options. In my spec I document the new field and these options? or we don't even need a spec for it? | 15:09 |
*** mdorman has joined #openstack-ironic | 15:10 | |
jroll | new db column, new configs, both require specs | 15:10 |
*** athomas has quit IRC | 15:10 | |
NobodyCam | devananda: not all but many | 15:11 |
jroll | dtantsur: I'd also mention that drivers like ilo will need to use driver vendor passthru | 15:11 |
rloo | dtantsur: I haven't been paying attention but it seems to me that if you've been having lots of discussions on how to do discovery and what the requirements/constraints are, it might be good to put those in a spec. | 15:11 |
NobodyCam | devananda: ya that was the one I was looking at | 15:11 |
*** athomas has joined #openstack-ironic | 15:12 | |
Shrews | devananda: NobodyCam: https://bugs.launchpad.net/openstack-ci/+bug/1344023 seems relevant | 15:13 |
lucasagomes | yuriyz, what you mean by "Looks like default value for group should be '' instead of 1." ? | 15:15 |
NobodyCam | Shrews: yep that was the one I rechecked with and it failed again. | 15:15 |
NobodyCam | will tray again | 15:15 |
Shrews | "102 fails in 24hrs" ... geeesh | 15:16 |
yuriyz | hello lucasagomes see example 2 for groups() in documentation https://docs.python.org/2/library/re.html | 15:17 |
lucasagomes | yuriyz, ack lemme take a look | 15:17 |
lucasagomes | thanks | 15:17 |
dtantsur | rloo, I have a spec, but nobody likes reading specs :D so we discuss it here | 15:18 |
rloo | dtantsur: i like reading the spec before I review the code :-) | 15:19 |
dtantsur | rloo, heh, it's too late for the discussion | 15:19 |
openstackgerrit | Chris Krelle proposed a change to openstack/ironic: Add option to allow soft power off https://review.openstack.org/107778 | 15:19 |
rloo | dtantsur: it definitely makes sense to discuss outside the spec though. just that sometimes, I think it is worth capturing the discussion (pros/cons/why/which decision) in the spec. | 15:19 |
lucasagomes | yuriyz, ah gotcha, will fix it | 15:20 |
rloo | dtantsur: my comment was in response to your question as to whether a spec was necessary :-) | 15:20 |
dtantsur | ah, I see :) | 15:20 |
lucasagomes | yuriyz, I also better check if the regex object was returned | 15:20 |
yuriyz | lucasagomes +1 | 15:20 |
dtantsur | devananda, what do you think about adding some init_discovery() method to DriverInterface, which will be called, if according to the config this driver will be used for discovery? | 15:21 |
*** rainya has quit IRC | 15:29 | |
devananda | Shrews: we're not based on the alpha prerelease of oslo.messaging, but yea, looks like a similar error | 15:31 |
*** rainya has joined #openstack-ironic | 15:32 | |
*** Poornima_ has quit IRC | 15:33 | |
devananda | dtantsur: I think adding an init_discovery() method to DriverInterface which will be called during ConductorManager.init_host(), every time the service is started, for every loaded driver, if the CONF option for discovery is enabled | 15:34 |
devananda | dtantsur: is a reasonable initial step | 15:35 |
*** jistr has quit IRC | 15:35 | |
devananda | dtantsur: but to be clear, this is not per-driver. it's global | 15:35 |
devananda | and called on every loaded driver | 15:35 |
dtantsur | devananda, why on every? | 15:35 |
dtantsur | we want only one driver to install it's environment, no? | 15:35 |
devananda | huh? | 15:35 |
devananda | dtantsur: all drivers must be able to co-exist | 15:36 |
*** rameshg87 has joined #openstack-ironic | 15:36 | |
devananda | dtantsur: a feature which means "if you use driver X, you can't use driver Y" is a feature that I very strongly think we can't land. Perhaps I misunderstand, but why would we want only one driver to prepare for discovery? | 15:36 |
dtantsur | devananda, how will they share PXE configuration for example? | 15:37 |
dtantsur | devananda, imagine 2 drivers want their ramdisk to be "the default" | 15:37 |
devananda | dtantsur: IPA and PXE driver need to be able to coexist with each other, and with iLO driver, and with DRAC driver ... | 15:37 |
dtantsur | devananda, they can be _enabled_, but how can they do discovery together? | 15:37 |
devananda | dtantsur: exactly. | 15:38 |
devananda | dtantsur: at the driver layer, they can both be enabled. then it's up to the DHCP service which ramdisk to reply with | 15:38 |
dtantsur | devananda, I think we misunderstand each other. It is we who dictate DHCP, which ramdisk to return. We can have PXE and IPA both enabled as drivers, but only one of them can be returned by DHCP | 15:39 |
dtantsur | devananda, so we allow only on driver to do the discovery | 15:39 |
dtantsur | Am I wrong? | 15:39 |
devananda | dtantsur: in the current approach, neutron controls DHCP. ironic tells neutron what ramdisk to associate to specific MAC addresses | 15:40 |
devananda | dtantsur: but not the general setting | 15:40 |
devananda | dtantsur: and the rackspace folks (and others) are not using neutron at all, eg with IPA | 15:40 |
dtantsur | devananda, well, ok, but how we decide, which of them to pass to neutron? | 15:40 |
devananda | dtantsur: the call to neutron which we make for a specific MAC is done within the driver.deploy interface | 15:41 |
devananda | dtantsur: it's totally unrelated to discovery | 15:41 |
dtantsur | ok, what about catch-all DHCP setting? | 15:41 |
devananda | configuring neutron's default "if uyou get a DHCP BOOT request from an UNKOWN MAC" | 15:41 |
devananda | is not done by ironic today | 15:41 |
dtantsur | I understand :) that's what I am talking about | 15:41 |
devananda | ok | 15:42 |
devananda | so there's another issue here, too | 15:42 |
dtantsur | devananda, my point is: only one driver should instruct neutron: "if you get a DHCP BOOT request from an UNKOWN MAC, give him this ramdisk", right? | 15:42 |
devananda | for a DHCP-based discovery mechanism | 15:42 |
devananda | how does neutron know which conductor's IP to point to? | 15:42 |
rloo | Shrews, NobodyCam: wrt py26 failure, 1344023. Should we recheck, or just wait til it is fixed? Looks like it affects all the nodes. | 15:42 |
devananda | dtantsur: it's not "this ramdisk" it's "this IP" | 15:42 |
devananda | if there are 10 conductors, all could have the same ramdisk cached, but neutron must point the boot request to a specific conductor's IP | 15:43 |
devananda | how does neutron pick which one? | 15:43 |
dtantsur | hmmmmm.... | 15:43 |
devananda | or how does ironic decide which conductor to tell neutron? | 15:43 |
rameshg87 | jroll: hello | 15:43 |
devananda | when all 10 of them are capable of handling booting the discovery ramdisk | 15:43 |
dtantsur | devananda, I assume Neutron can't round-robin then, right? | 15:44 |
*** romcheg2 has quit IRC | 15:44 | |
dtantsur | If so, it looks like we have to stick with only one conductor for now... | 15:44 |
devananda | dtantsur: maybe it can? or maybe it should be added there? | 15:44 |
devananda | dtantsur: if ironic picks only one conductor IP for discovery here, it's not HA. what happens when taht conductor fails? | 15:44 |
devananda | dtantsur: ironic will need to inform neutron that it needs to change the IP | 15:45 |
devananda | dtantsur: but another ironic conductor needs to know to take that action | 15:45 |
dtantsur | devananda, well, adding HA to non-existing feature may be overcomplication. We won't be able to fix Neutron for J (provided it can't) | 15:45 |
dtantsur | devananda, btw how do we do it now for the deploy? If conductor assigned to a node fails? | 15:46 |
devananda | dtantsur: adding a non-HA feature to an openstack service is bad. | 15:46 |
devananda | dtantsur: so, actually. it's broken. I'd MUCH rather we fix that. | 15:46 |
dtantsur | devananda, even if it's a baby step? | 15:46 |
devananda | dtantsur: there are hooks in the conductor today to handle rebalancing the hash ring | 15:46 |
*** eghobo has joined #openstack-ironic | 15:47 | |
devananda | dtantsur: those do the take-over for nodes which were assigned to the now-failed-conductor | 15:47 |
dtantsur | devananda, so we can also do a take-over, right? | 15:47 |
devananda | dtantsur: the patch I tossed upa while ago needed mroe work, and I've, well, been distracted | 15:47 |
devananda | dtantsur: right | 15:47 |
Shrews | rloo: idk. haven't looked into it | 15:53 |
dtantsur | devananda, so, if neutron can't have several IP's for DHCP, is it ok to stick with one conductor and plan rebalancing? | 15:53 |
rloo | Shrews: no worries. I did a recheck cuz I saw another patch that passed that test. Will see what happens. | 15:53 |
*** eghobo has quit IRC | 15:54 | |
*** shakamunyi has joined #openstack-ironic | 15:54 | |
*** eghobo has joined #openstack-ironic | 15:55 | |
*** rameshg87 has quit IRC | 15:56 | |
devananda | dtantsur: frankly, i think this needs more thought / discussion as we still haven't come to an agreement (and this discussion may be progress, but isn't enough yet) and we have many more serious needs in the next month | 15:57 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Expose {set,get}_boot_device in the API https://review.openstack.org/90151 | 15:57 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: SSH virsh to use the new ManagementInterface https://review.openstack.org/89884 | 15:57 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: IPMITool to use the new ManagementInterface https://review.openstack.org/86092 | 15:57 |
*** victor_lowther has joined #openstack-ironic | 15:57 | |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: SeaMicro to use the new ManagementInterface https://review.openstack.org/86328 | 15:57 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: IPMINative to use the new ManagementInterface https://review.openstack.org/86588 | 15:57 |
lucasagomes | rloo, Shrews yuriyz hope I have addressed all the concerns | 15:57 |
dtantsur | devananda, well, we need the discovery quite badly, so it will anyway distract me from things... | 15:58 |
devananda | dtantsur: I think a f2f discussion next week will be good | 15:58 |
devananda | dtantsur: we all want the feature :) | 15:58 |
devananda | dtantsur: but, for example, we actually also all need HA of conductors | 15:59 |
dtantsur | devananda, if you mean meet-up, I won't be there, but you can talk to lucasagomes | 15:59 |
* lucasagomes reads | 15:59 | |
openstackgerrit | Ruby Loo proposed a change to openstack/ironic: Use mock.assert_called_once_with() https://review.openstack.org/108418 | 15:59 |
devananda | which is less glamorous but, IMO, more important | 15:59 |
devananda | bbiab | 15:59 |
*** rameshg87 has joined #openstack-ironic | 16:04 | |
*** rainya has quit IRC | 16:06 | |
rameshg87 | dtantsur: request you to take a look at moving code to image cache to a common place https://review.openstack.org/#/c/107996/ | 16:08 |
rameshg87 | dtantsur: the one which you had reviewed earlier. :-) | 16:08 |
lucasagomes | ouch we need a spec for that!? | 16:09 |
dtantsur | lucasagomes, there is some interesting feature there, which deserves discussion | 16:10 |
*** rainya has joined #openstack-ironic | 16:10 | |
*** Mikhail_D_ltp has quit IRC | 16:11 | |
lucasagomes | right | 16:11 |
*** Nisha has joined #openstack-ironic | 16:16 | |
*** ramineni has quit IRC | 16:18 | |
rameshg87 | lucasagomes: was that to me ? :-) | 16:19 |
rameshg87 | lucasagomes: "ouch we need a spec for that!?" ? | 16:19 |
lucasagomes | rameshg87, yeah heh | 16:19 |
lucasagomes | but I haven't read it yet so | 16:19 |
rameshg87 | lucasagomes: okay. i didn't get it first. please have a look at it if you get time. it's simple one btw. | 16:19 |
lucasagomes | sure | 16:20 |
*** steveh has quit IRC | 16:22 | |
rloo | hey, did I miss something. Which _LI/_LW/_LE/_LC do we use? https://github.com/openstack/ironic/blob/master/ironic/common/i18n.py or https://github.com/openstack/ironic/blob/master/ironic/openstack/common/gettextutils.py | 16:23 |
jroll | rameshg87: hi! | 16:23 |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic-python-agent: Updated from global requirements https://review.openstack.org/88722 | 16:23 |
rameshg87 | jroll: hi | 16:24 |
rameshg87 | jroll: wanted some information regarding ipa. | 16:24 |
jroll | ask away :) | 16:24 |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic-specs: Generic Hardware Discovery Bits https://review.openstack.org/107344 | 16:24 |
lucasagomes | jroll, https://review.openstack.org/#/c/100735/ | 16:24 |
lucasagomes | jroll, can you rebase that on master | 16:24 |
lucasagomes | that's already approved but not merged because the dependency is outdated | 16:25 |
dtantsur | devananda, jroll, lucasagomes, I tried to collect more-or-less non-contradictive things in a base spec: https://review.openstack.org/107344 (this does not touch how it will work for PXE) | 16:25 |
dtantsur | if it gets merged, it will be at least easier to prototype things | 16:25 |
jroll | lucasagomes: on the train but will do when I land at the office | 16:25 |
rameshg87 | jroll: from the ipa spec it looks like it will need keystone token to make heartbeat ping, am i correct ? | 16:25 |
Shrews | rloo: umm.... hrm.... | 16:25 |
lucasagomes | jroll, right... you mind if I rebase that? | 16:25 |
jroll | lucasagomes: doeet | 16:26 |
lucasagomes | ack | 16:26 |
jroll | I never mind someone doing work for me | 16:26 |
*** romcheg1 has joined #openstack-ironic | 16:26 | |
rloo | Shrews: I say use neither, but if we're going to use, which one? | 16:26 |
Shrews | rloo: last paragraph: https://wiki.openstack.org/wiki/LoggingStandards | 16:27 |
jroll | rameshg87: that's complicated.... I think the first version will, but I also think passing keystone tokens to ipa is horrible and would like to do better | 16:27 |
rameshg87 | jroll: the spec doesn't talk about that. | 16:27 |
jroll | rameshg87: other option today is to not auth for heartbeat | 16:27 |
jroll | but that's just as bad | 16:27 |
rameshg87 | jroll: so in the first version, it is planned to do in the same way as pxe does now ? | 16:27 |
rloo | Shrews, thx (#$#$%!) | 16:27 |
rameshg87 | jroll: expect token-<node-uuid> in tftp root ?? | 16:28 |
jroll | rameshg87: the spec says tbd because I would rather not pass keystone tokens :/ but I don't think that will land | 16:28 |
jroll | and in memory on the agent | 16:28 |
Shrews | rloo: do we need to remove the common/i18n.py file and replace it with oslo.i18n? | 16:28 |
rameshg87 | jroll: if we don't do both, how will we do heartbeat to the api ?? :-) | 16:29 |
rloo | Shrews: you're asking me? :-) I think Ghe added the common/i18n.py, and that uses oslo.i18n. | 16:29 |
rameshg87 | jroll: heartbeat AFAIK is an important part of IPA, right ? | 16:29 |
Shrews | GheRivero: ^^^^ ? | 16:29 |
jroll | rameshg87: could change api noauth whitelist to include the heartbeat url :) | 16:30 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Factor out deploy info from PXE driver https://review.openstack.org/100735 | 16:30 |
rloo | Shrews: I think it means that we need to change all occurrences of gettextutils blah blah, to use the common/i18n ones. | 16:30 |
JayF | rameshg87: we don't want to do it the same way as pxe, because we don't want to pass around ironic admin tokens if possible :x | 16:30 |
JayF | IMO noauth is better than passing around an Ironic admin token, in IPA context | 16:30 |
jroll | rameshg87: in an hour or two I will have code up that does this... can we chat about it in the meeting maybe? I'd like lots of opinions on this | 16:30 |
JayF | because you can at least secure the networks and limit it by IP :x | 16:30 |
jroll | JayF: better? probably not :/ but I know what you mean :) | 16:31 |
rameshg87 | jroll: JayF: i was just checking regarding integration of ilo-virtual-media with IPA | 16:31 |
JayF | jroll: I think it's a ton better | 16:31 |
Shrews | rloo: but i think the common directory one is likely outdated. i18n is it's own module now: https://github.com/openstack/oslo.i18n | 16:31 |
JayF | rameshg87: for iLo, with an oob way to get things there, I' | 16:32 |
JayF | rameshg87: I think you ahve more interesting options | 16:32 |
rameshg87 | JayF: yes, passing admin token is okay with iLO | 16:32 |
jroll | agree | 16:32 |
rameshg87 | JayF: i was just trying to put up a spec for ilo-ipa integration, you guys can review it | 16:32 |
JayF | I think passing around admin tokens in general is not wonderful, I wish there was a way for us to have something more limited than a full ironic admin token | 16:33 |
JayF | that could only do the things ipa needs to do | 16:33 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Rename/update common/tftp.py to common/pxe_utils.py https://review.openstack.org/103595 | 16:33 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Add iPXE Installation Guide documentation https://review.openstack.org/106809 | 16:33 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Add iPXE support for Ironic https://review.openstack.org/99318 | 16:33 |
JayF | I'd just rather have the endpoints IPA hit be unauthed than giving IPA a full admin token to Ironic, if those are the choices | 16:33 |
JayF | a limited access user/token is much less scary imo, but we don't have that | 16:33 |
jroll | rameshg87: awesome, would love to look | 16:33 |
rameshg87 | JayF: okay | 16:34 |
rameshg87 | JayF: jroll: just wanted to check if we can factor out the boot vs "actual deploy" code in IPA separately | 16:34 |
JayF | what do you mean boot vs actual deploy? | 16:34 |
jroll | rameshg87: yes definitely | 16:34 |
JayF | Oh, you mean booting it in ways other than pxe? for sure. | 16:34 |
JayF | just probably not with our current set of images | 16:34 |
rameshg87 | JayF: jroll: ah something like making it easy to replace the "pxe" parts of ipa with "ilo virtual media" | 16:34 |
JayF | IPA is software than runs places. Right now we only have a CoreOS ramdisk to run it in. You could almost certainly install it in something other than a ramdisk | 16:35 |
jroll | JayF: in general we have been talking abour separating "how does ironic interact with a deploy ramdisk" from "how does ironic put a ramdisk on a node" | 16:35 |
JayF | rameshg87: I'm assuming iLo wants a full disk image with kernel integratied? | 16:35 |
rameshg87 | JayF: sorry, i meant in the deploy driver in ironic | 16:35 |
jroll | rameshg87: I think that division will be in the ironic driver interfaves... but yes can do | 16:35 |
rameshg87 | JayF: let me bring in what i am talking about | 16:36 |
rameshg87 | JayF: i saw your very old review that has been abandoned to see how the code will look like (eventhough it might change) | 16:36 |
rameshg87 | JayF: jroll: https://review.openstack.org/#/c/84795/ | 16:36 |
JayF | rameshg87: that is not me. that is JoshNang | 16:37 |
jroll | rameshg87: see review 101020 for somewhat current code | 16:37 |
JayF | although he sits a desk across from me :) | 16:37 |
rameshg87 | JayF: okay :-) | 16:37 |
rameshg87 | jroll: just checking .. | 16:37 |
jroll | rameshg87: will be updating 101020 later today | 16:37 |
jroll | rameshg87: the new review is similar to pxe driver, at least in terms of how to boot | 16:38 |
jroll | so replacing will be similar | 16:38 |
rloo | Shrews: I guess we should find out from GheRivero. It looks to me like the common/i18n file was added 5 days ago, and it uses oslo.i18n, so I think it is needed. | 16:38 |
rloo | Shrews: see http://docs.openstack.org/developer/oslo.i18n/usage.html#creating-an-integration-module | 16:39 |
Shrews | rloo: ah, ok | 16:39 |
rloo | Shrews: and I really don't want to know any more about this ;) | 16:39 |
rameshg87 | jroll: JayF: in ilo virtual media, we will have an iso, instead of a kernel/ramdisk. the iso will contain the kernel and ramdisk and how to boot up the ramdisk | 16:39 |
Shrews | rloo: lol | 16:39 |
JayF | rameshg87: I suspect we could easily setup a coreos image that'd be a fully contained ramdisk | 16:40 |
*** pcrews has joined #openstack-ironic | 16:40 | |
rameshg87 | jroll: JayF: the extra parameters for deploy and the token (if required), we are planning to pass through the virtual media floppy | 16:40 |
JayF | rameshg87: Does DIB produce an ISO? | 16:40 |
JayF | That should be easy to do, you'll just have to build up another image | 16:40 |
anteaya | so romcheg was working on something and then went offline | 16:40 |
rameshg87 | JayF: we are changing DIB to produce ISO. it's a small change. | 16:40 |
rameshg87 | JayF: yes :-) | 16:40 |
JayF | rameshg87: OK, fwiw, we don't have any DIB elements built yet | 16:40 |
jroll | rameshg87: right, I understand. we're doing those options the same way as pxe | 16:40 |
anteaya | he was having an issue with six versioning and using the openstackclient | 16:40 |
anteaya | requirements for the openstackclient are different from what was installed for what he was running: http://git.openstack.org/cgit/openstack/python-openstackclient/tree/requirements.txt | 16:41 |
JayF | rameshg87: Looking at the images, I'm 90% sure it'd be possible to do the ISO using coreos as well. | 16:41 |
rameshg87 | jroll: please have a look at https://review.openstack.org/#/c/107996/ | 16:41 |
*** romcheg2 has joined #openstack-ironic | 16:41 | |
JayF | rameshg87: or like you said, support it in DIB, but we don't have the elemnts yet | 16:41 |
rameshg87 | jroll: i am proposing to change _cleanup_caches_if_required() to a common place. may be you might have a say on that. | 16:42 |
rameshg87 | jroll: i see that used in your code. | 16:42 |
*** romcheg1 has quit IRC | 16:43 | |
jroll | rameshg87: I like it :) | 16:43 |
jroll | rameshg87: go ahead... if your code lands first, I can do the work to move it in ipa driver | 16:44 |
rameshg87 | JayF: jroll: just a quick look at the code. i guess it might be easy to integrate. | 16:44 |
*** martyntaylor has joined #openstack-ironic | 16:44 | |
jroll | rameshg87: I'll +1 or add comments on that spec shortly | 16:44 |
rameshg87 | JayF: jroll: i just need to setup the machine to boot up through virtual media parameters and looks like the vendor passthru will take care of all the other things :-) | 16:44 |
rameshg87 | jroll: thanks :-) | 16:45 |
jroll | rameshg87: np :) | 16:45 |
*** lucasagomes is now known as lucas-dinner | 16:45 | |
lucas-dinner | I will be back for the meeting | 16:45 |
rameshg87 | jroll: just one question | 16:47 |
jroll | sure | 16:47 |
rameshg87 | jroll: in _reboot_to_instance(), i see we are setting boot from disk | 16:47 |
rameshg87 | jroll: so ipa supports only disk images ? | 16:48 |
rameshg87 | jroll: we won't use pxe to boot up an instance ? | 16:48 |
jroll | rameshg87: today, yes, but it should be trivial to use pxe | 16:48 |
rameshg87 | jroll: okay. and this worries me :-( | 16:49 |
rameshg87 | jroll: sending raw bytes | 16:49 |
rameshg87 | jroll: task.driver.ipmi_vendor._send_raw_bytes(task, '0x00 0x08 0x03 0x08') | 16:50 |
jroll | to ipmi? why? (it is a pretty standard set of bytes... not optimal but a lot of hardware doesnt boot from disk without that | 16:51 |
JoshNang | i'm pretty sure phygmi also sends those bytes (but automatically) | 16:51 |
rameshg87 | jroll: okay. will check that part. worried because ilo will not use ipmi. | 16:52 |
jroll | pyghmi does | 16:52 |
jroll | rameshg87: right, that would be part of the boot code | 16:52 |
rameshg87 | jroll: yes.. | 16:52 |
jroll | rameshg87: I hate that it is there and might fix it in a better way :) | 16:52 |
rameshg87 | jroll: would love if you would just give some hook so that it can be replaced easily with ours | 16:52 |
jroll | rameshg87: all of this sit is going to be a larger refactor in ironic itself :/ | 16:53 |
rameshg87 | jroll: may be a method which we can inherit and change..i don't know..may be we can discuss and sort it out.. :-) | 16:53 |
jroll | s/sit/stuff/? | 16:53 |
rameshg87 | jroll: :-) | 16:53 |
jroll | rameshg87: I think ironic will end up with a bootinterface and a deployinterfave | 16:54 |
*** romcheg1 has joined #openstack-ironic | 16:54 | |
jroll | face | 16:54 |
rameshg87 | jroll: yeah | 16:54 |
jroll | romcheg1: anteaya is looking for you :) | 16:54 |
rameshg87 | jroll: but may be only in K, we could make an early proposal for that. | 16:54 |
rameshg87 | jroll: when K opens. | 16:54 |
anteaya | romcheg1: you disappeared | 16:55 |
rameshg87 | jroll: so that we can mix - different boot methods with different deploy engines | 16:55 |
*** romcheg2 has quit IRC | 16:55 | |
anteaya | romcheg1: so whatever you are installing is using a version of six that is too low for openstackclient | 16:55 |
anteaya | romcheg1: http://git.openstack.org/cgit/openstack/python-openstackclient/tree/requirements.txt | 16:55 |
jroll | rameshg87: yep, I would propose that spec in the k directory :) | 16:55 |
NobodyCam | hey anteaya long time no see | 16:55 |
NobodyCam | welcome back home :) | 16:56 |
anteaya | NobodyCam: how are you? | 16:56 |
anteaya | NobodyCam: I'm in frankfurt | 16:56 |
anteaya | :D | 16:56 |
rameshg87 | jroll: okay. i will wait for your next patch set. | 16:56 |
rameshg87 | jroll: meanwhile i will raise a spec for ilo-ipa integration. | 16:56 |
GheRivero | rloo: Shrews: the i18n.py common landed last week. The only change missed is to replace all gettextutils injection, and import the _LW, _, LD from i18n.py when needed | 16:56 |
NobodyCam | doing good, I'm in Raleigh, NC | 16:56 |
Shrews | GheRivero: ah, ok. thx | 16:57 |
rloo | GheRivero: is there a bug or are you going to do the missing stuff? | 16:57 |
jroll | rameshg87: cool | 16:57 |
GheRivero | rloo: I'm doing/will do it. But I can open a bug to keep track of it if you want | 16:58 |
anteaya | NobodyCam: nice | 16:58 |
anteaya | NobodyCam: how is Raleigh treating you? | 16:58 |
rloo | GheRivero: it would be good to open a bug. Then I would have known that it is something to be done. | 16:58 |
rloo | thx GheRivero ;) | 16:58 |
NobodyCam | :) its nice, We're running the TripleO mid cycle right now | 16:58 |
GheRivero | rloo: Sure. My bad. Opening it now | 16:58 |
anteaya | NobodyCam: ah yes, how is it going? | 16:59 |
*** bvivek has quit IRC | 17:00 | |
NobodyCam | anteaya: So far Well, :) but we're just getting rolling | 17:01 |
*** Mikhail_D_ltp has joined #openstack-ironic | 17:02 | |
anteaya | NobodyCam: :D | 17:03 |
anteaya | NobodyCam: I hope you have a great time | 17:03 |
*** malini1 has quit IRC | 17:05 | |
rameshg87 | devananda: NobodyCam: request you to take a look at revised ilo virtual media deploy spec, https://review.openstack.org/#/c/97744 | 17:06 |
*** harlowja_away is now known as harlowja | 17:12 | |
*** ChuckC has joined #openstack-ironic | 17:12 | |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Avoid calling _parse_deploy_info twice. https://review.openstack.org/108442 | 17:16 |
openstackgerrit | Ramakrishnan G proposed a change to openstack/ironic-specs: iLO-IPA Deploy Driver https://review.openstack.org/108445 | 17:20 |
*** Alexei_9871 has left #openstack-ironic | 17:24 | |
*** martyntaylor has left #openstack-ironic | 17:38 | |
jroll | would it be ok for me to approve this? lucas rebased it for me, it was +A before that. https://review.openstack.org/#/c/100735 | 17:41 |
jroll | devananda: ^ | 17:41 |
jroll | barring jenkins ofc | 17:41 |
jroll | (or you could do it :) | 17:41 |
openstackgerrit | Josh Gachnang proposed a change to openstack/ironic: Adding swift temp url support https://review.openstack.org/81391 | 17:43 |
*** Haomeng|2 has joined #openstack-ironic | 17:45 | |
*** shakamunyi_ has joined #openstack-ironic | 17:46 | |
*** athomas has quit IRC | 17:46 | |
rloo | jroll: I was going to approve it after jenkins. did you want me to approve it now? (100735) | 17:46 |
*** Haomeng has quit IRC | 17:46 | |
jroll | rloo: either is fine | 17:47 |
jroll | jenkins won't let it merge if it fails, so it's your call :) | 17:47 |
jroll | I just want to make sure it lands :) | 17:47 |
rloo | jroll: I waited cuz lucas didn't approve it but why wait ;) Let's see what happens. And I would say it is OK for you to approve it ;) | 17:49 |
*** shakamunyi has quit IRC | 17:49 | |
jroll | ha, ok. thanks! :) | 17:49 |
*** martyntaylor has joined #openstack-ironic | 17:51 | |
JayF | NobodyCam: if you want any tips about what to do/where to eat in Raleigh, LMK -- that's my hometown :) | 17:54 |
*** rainya has quit IRC | 17:56 | |
*** martyntaylor has quit IRC | 17:56 | |
*** rainya has joined #openstack-ironic | 17:57 | |
NobodyCam | woo hoo | 17:58 |
*** rainya has quit IRC | 18:00 | |
*** rameshg87 has quit IRC | 18:01 | |
JayF | NobodyCam: You gotta make sure to eat at The Pit while you're there --> http://www.thepit-raleigh.com/ | 18:02 |
devananda | jroll: yea. when it's clear (like this) that you're not just approving your own patch, it's fine -- but when others are available, it's better for someone else to do it | 18:03 |
jroll | devananda: thought so, thanks | 18:04 |
devananda | jroll: also, py26 is failing | 18:04 |
devananda | it seems like that job is failing everything | 18:04 |
*** malini1 has joined #openstack-ironic | 18:04 | |
jroll | oh yeah | 18:04 |
jroll | AWESOME | 18:04 |
JayF | gcc failed | 18:04 |
JayF | while installing requirements | 18:04 |
jroll | JayF: that's happening on most patches | 18:04 |
jroll | right now | 18:04 |
JayF | hooray | 18:05 |
*** martyntaylor has joined #openstack-ironic | 18:05 | |
*** rainya has joined #openstack-ironic | 18:05 | |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Raise MissingParameterValue instead of invalid https://review.openstack.org/108455 | 18:07 |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Use _check_for_missing_params when validating glance info https://review.openstack.org/108456 | 18:07 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Add ironic-python-agent deploy driver https://review.openstack.org/101020 | 18:07 |
*** rainya has quit IRC | 18:09 | |
NobodyCam | JayF: oh yummy !!! | 18:10 |
jroll | winning: https://review.openstack.org/#/c/108457/ | 18:10 |
JayF | NobodyCam: also look up Smokey's BBQ Shack in Morrisville, if you're driving out that far. Mmmm bbq | 18:11 |
JayF | Smokey's BBQ shack is the hole-in-the-wall type place you'd only know about if a local (me) told you about :P so go there if you've got a car | 18:11 |
NobodyCam | JayF: no car :-p | 18:12 |
JayF | NobodyCam: aw, the Pit should be able to be gotten to easily from RH HQ though | 18:14 |
JayF | NobodyCam: they're still in NCSU Centinnial Campus, right? | 18:14 |
NobodyCam | we on 100 E Davie St, Raleigh, NC | 18:16 |
JayF | the progress energy building? | 18:16 |
JayF | heh | 18:16 |
JayF | I think the pit might be walking distance | 18:16 |
JayF | Also I wonder where Coopers BBQ moved to, their old place was right by ther etoo | 18:16 |
NobodyCam | :) | 18:17 |
openstackgerrit | Chris Krelle proposed a change to openstack/ironic: Add option to allow soft power off https://review.openstack.org/107778 | 18:21 |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Fix tear_down a node with missing info https://review.openstack.org/103685 | 18:26 |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Avoid calling _parse_deploy_info twice. https://review.openstack.org/108442 | 18:26 |
*** harlowja has quit IRC | 18:27 | |
*** harlowja has joined #openstack-ironic | 18:35 | |
*** jgrimm has quit IRC | 18:38 | |
*** lucas-dinner is now known as lucasagomes | 18:51 | |
lucasagomes | devananda, NobodyCam ayou guys around? | 18:51 |
devananda | lucasagomes: yah. with GheRivero and adam_g and Shrews | 18:52 |
lucasagomes | devananda, nice... just checking if you want to chair the meeting or I should do it | 18:53 |
devananda | lucasagomes: go for it. I'm already multitasking too many f2f conversations | 18:53 |
lucasagomes | hah ack | 18:53 |
devananda | lucasagomes: and likely to pull these fine folks away from their computers in a minute to talk about ironic :) | 18:54 |
lucasagomes | devananda, +1 go for it! | 18:54 |
*** rakesh_hs has quit IRC | 18:55 | |
dtantsur | lucasagomes, you have a chance of leading a private party :D | 18:56 |
lucasagomes | dtantsur, heh... not that private | 18:56 |
*** mrda-away is now known as mrda | 18:58 | |
mrda | Morning Ironic! | 18:59 |
romcheg1 | Good morning mrda! | 19:00 |
lucasagomes | morning | 19:01 |
lucasagomes | meeting time | 19:01 |
jroll | mrda \o | 19:01 |
*** tatyana has joined #openstack-ironic | 19:01 | |
*** Nisha has quit IRC | 19:15 | |
*** enikanorov_ has joined #openstack-ironic | 19:16 | |
mrda | rloo: the nova reviews have comments in them linking to the ironic reviews, and the child ironic reviews have links in them back to the parent nova reviews. | 19:17 |
mrda | rloo: happy to explain more if necessary ;) | 19:17 |
rloo | mrda: no worries. I figured it out via the etherpad ;) I had wondered about those patches but didn't think they were 'important'. | 19:17 |
mrda | rloo: you eyeballs would be very welcome on those reviews :) | 19:18 |
rloo | mrda: yup, will do now that I know :-) | 19:18 |
mrda | we do need quite turnaround on these reviews so I can get the Nova reviewers focussed | 19:19 |
rloo | mrda: understandable. Esp by next week... | 19:19 |
mrda | thanks rloo, sorry this was explained previously | 19:20 |
mrda | ^^wasn't | 19:20 |
rloo | mrda: no worries. It might have been and I might have missed it. Or not. But now we know :-) | 19:20 |
mrda | if there's any questions on getting the nova ironic driver in, let me know because I'm now focusing on this | 19:22 |
openstackgerrit | Nisha Agarwal proposed a change to openstack/ironic-specs: Discover node properties at node-create/node-update https://review.openstack.org/100951 | 19:26 |
*** achanda has joined #openstack-ironic | 19:26 | |
*** achanda has quit IRC | 19:38 | |
*** malini1 has quit IRC | 19:42 | |
*** tatyana has quit IRC | 19:50 | |
*** malini1 has joined #openstack-ironic | 19:52 | |
*** jdob has quit IRC | 19:52 | |
*** jdob has joined #openstack-ironic | 19:56 | |
lucasagomes | yay, alright folks it's pretty late here and I'm starving | 20:01 |
lucasagomes | thanks for the meeting! | 20:01 |
lucasagomes | have a good night everyone | 20:01 |
dtantsur | g'night, lucasagomes | 20:01 |
jroll | night lucas | 20:01 |
dtantsur | I'm also going | 20:01 |
jroll | night dtantsur | 20:01 |
* jroll goes afk for a bit | 20:02 | |
*** lucasagomes is now known as lucas-dinner | 20:02 | |
*** achanda has joined #openstack-ironic | 20:02 | |
*** igordcard has joined #openstack-ironic | 20:03 | |
* mrda goes back to sleep | 20:05 | |
*** dtantsur is now known as dtantsur|afk | 20:06 | |
*** achanda has quit IRC | 20:07 | |
*** Nisha has joined #openstack-ironic | 20:08 | |
victor_lowther | https://github.com/eventlet/eventlet/issues/94 appears to still be an issue in the ironic codebase | 20:14 |
victor_lowther | at least, it seems to be screwing up my devtest runs rather alot. | 20:14 |
openstackgerrit | Nisha Agarwal proposed a change to openstack/ironic-specs: Discover node properties for iLO driver https://review.openstack.org/103007 | 20:20 |
*** martyntaylor has left #openstack-ironic | 20:23 | |
adam_g | Shrews, http://paste.ubuntu.com/7832262/ | 20:23 |
adam_g | http://atdt.no-carrier.net:18080/~adam/results.html | 20:25 |
jroll | victor_lowther: yeah, we see that in jenkins too :| | 20:25 |
victor_lowther | It is seriously harshing my devtest mellow, because nova-baremetal Just Won't Do. | 20:27 |
*** Nisha has quit IRC | 20:27 | |
jroll | indeed | 20:27 |
*** amitpp has joined #openstack-ironic | 20:29 | |
*** amitpp has quit IRC | 20:29 | |
*** romcheg1 has quit IRC | 20:36 | |
*** romcheg1 has joined #openstack-ironic | 20:44 | |
*** jgrimm has joined #openstack-ironic | 20:46 | |
devananda | mrda: ping | 20:57 |
devananda | mrda: we've been chatting about the client token caching | 20:57 |
devananda | mrda: and figure it'd be really good to involve you :) | 20:58 |
*** chuckC_ has joined #openstack-ironic | 21:08 | |
*** matty_dubs is now known as matty_dubs|gone | 21:09 | |
*** jdob has quit IRC | 21:13 | |
*** romcheg1 has left #openstack-ironic | 21:16 | |
*** malini1 has quit IRC | 21:22 | |
*** shakamunyi_ has quit IRC | 21:24 | |
mrda | hey devananda | 21:25 |
mrda | (sorry fell asleep) | 21:25 |
devananda | mrda: hey there! | 21:27 |
mrda | \o | 21:27 |
devananda | mrda: so Shrews posted a comment on your patch | 21:27 |
mrda | great | 21:27 |
mrda | I'll take a look | 21:28 |
mrda | hmmm, ok | 21:29 |
devananda | mrda: i think what we want is to cache and share the token among requests | 21:30 |
devananda | mrda: but not use a shared TCP connection | 21:30 |
devananda | mrda: and after shrews sharing his concern and me digging into it, i think the current code is going to try to share a socket among multiple greenthreads | 21:31 |
mrda | yeah, just thinking through the consequences of that | 21:31 |
*** romcheg1 has joined #openstack-ironic | 21:32 | |
Shrews | mrda: hope my comments made sense. let me know if not | 21:32 |
mrda | It should be possible to just share the token, but how to differentiate the callers so the socket isn't shared... | 21:32 |
mrda | Shrews: thanks for thinking through this | 21:33 |
mrda | I'll see what I can come up with to address these concerns | 21:33 |
*** chuckC_ has quit IRC | 21:35 | |
NobodyCam | tempest.api.compute.servers.test_attach_interfaces.AttachInterfacesTestJSON.test_create_list_show_delete_interfaces | 21:38 |
*** rameshg87 has joined #openstack-ironic | 21:38 | |
openstackgerrit | Ramakrishnan G proposed a change to openstack/python-ironicclient: Add ironic cli support for vendor-passthru https://review.openstack.org/101297 | 21:40 |
*** romcheg1 has left #openstack-ironic | 21:49 | |
Shrews | devananda: https://review.openstack.org/107710 implementation of nodelocked retry | 21:56 |
*** ChuckC has quit IRC | 21:58 | |
NobodyCam | https://github.com/openstack/tempest/blob/master/tempest/services/compute/json/interfaces_client.py#L77 | 21:59 |
*** derekh_ has quit IRC | 22:01 | |
*** rwsu has quit IRC | 22:02 | |
mikal | Morning | 22:08 |
mikal | devananda: are yuo really opposed to landing the refactor in https://review.openstack.org/#/c/107316/ in your tree, even temporarily? | 22:10 |
devananda | mikal: hi! i don't see why we'd add code unrelated to ironic | 22:10 |
devananda | mikal: i dont see any benefit, even in our process | 22:11 |
mikal | devananda: because you're requiring our review comments to be implemented in your tree first? | 22:11 |
devananda | mikal: that should simply be a separate patch to nova | 22:11 |
mikal | devananda: but that will break your driver in your tree | 22:11 |
devananda | mikal: it's a cross-project coordination | 22:11 |
devananda | mikal: yep | 22:11 |
mikal | devananda: as we will require that your new driver use that new base class | 22:11 |
devananda | mikal: wait. how will landing that in nova break ironic? | 22:12 |
devananda | mikal: this cross tree deps stuff is painful :( | 22:12 |
mikal | devananda: your preferred process (which I have been trying to work with) is that you land the changes we ask for in your tree before proposing them in ours. We will ask you to use the base class, which you will then need to land in your tree, thus breaking your driver. | 22:12 |
mikal | devananda: the base class would only be temporary in your tree (for however long it takes to get the driver into nova) | 22:13 |
mikal | devananda: I assume the entire nova directory gets deleted from your tree once its landed in ours | 22:13 |
mikal | devananda: so I really don't see why you'd care about landing that base class | 22:13 |
devananda | mikal: eh. I didn't see the relevance to having it in our tree. but I was probably in an airport when I posted that comment. | 22:14 |
devananda | mikal: if it really simplifies things that much, OK | 22:14 |
mikal | devananda: we will have to keep the baremetal code around for probably another year | 22:14 |
mikal | devananda: so the base class is a win for us as its less code for us to carry around | 22:15 |
mikal | devananda: I agree its irrelevant to your tree, but so is the entire nova driver | 22:15 |
devananda | mikal: right. also, remind me - why are you keeping an untested driver in tree? | 22:15 |
mikal | devananda: because it pre-exists those requirements and got a special case for the CI requirements last cycle because it was on a deprecation path | 22:17 |
mikal | devananda: basically because we're trying to not throw users under the bus | 22:17 |
mikal | devananda: and I know you like to insist there are no users, but I think that's untrue | 22:17 |
mikal | devananda: tripleo uses it for example, thus showing that it is possible to use | 22:17 |
*** Mikhail_D_ltp has quit IRC | 22:18 | |
* JayF thinks a user of nova-bm would be the person driving the bus, and devananda is the person being thrown under it ;) | 22:19 | |
*** jogo has joined #openstack-ironic | 22:19 | |
mikal | The TC requirements for replacing and openstack component have been around for quite a while now | 22:19 |
mikal | Requiring an upgrade path and staged deprecation should not be a surprise to anyone | 22:20 |
devananda | mikal: dont go quoting that req to me, please ... | 22:20 |
devananda | mikal: is nova maintaining the baremetal driver code? are you guys testing it in devstack-gate? | 22:21 |
devananda | is anyone fixing bugs in it? | 22:21 |
jogo | devananda: as for upgrade testing, I think we can use javelin | 22:21 |
devananda | jogo: you can't even use grenade | 22:21 |
devananda | jogo: please read my email(s) on that subject | 22:21 |
jogo | we can turn off the old checks | 22:21 |
jogo | and just do javelin | 22:21 |
mikal | devananda: all of that is irrelevant | 22:22 |
mikal | devananda: sure, its horrible and under tested | 22:22 |
mikal | devananda: but it still might have users | 22:22 |
mikal | devananda: we shipped it and therefore be responsible about deprecating it | 22:22 |
devananda | mikal: does that responsibility mean preventing another project's progress? | 22:22 |
mikal | Yes, I think it does | 22:23 |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Avoid calling _parse_deploy_info twice https://review.openstack.org/108442 | 22:23 |
mikal | It is the clear intent of the TC in the requirements to block graduation for projects until they have handled this deprecation case | 22:24 |
mikal | * In the case that a project has intentionally duplicated functionality of | 22:24 |
mikal | another project, or portion of a project, the new project must reach a level | 22:24 |
mikal | of functionality and maturity such that we are ready to deprecate the old | 22:24 |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Fix tear_down a node with missing info https://review.openstack.org/103685 | 22:24 |
mikal | code and remove it after a well defined deprecation cycle. The deprecation | 22:24 |
mikal | plan agreed to by the PTLs of each affected project, including details for | 22:24 |
mikal | how users will be able to migrate from the old to the new, must be submitted | 22:24 |
mikal | to the TC for review as a part of the graduation review. | 22:24 |
mikal | i.e. ironic must convince the TC that the baremetal users have not been dead ended | 22:24 |
devananda | Wow. I asked you not to quote that, and you actually pasted it | 22:24 |
devananda | :( | 22:24 |
mikal | devananda: because you're not listening | 22:24 |
mikal | I am trying to help you here | 22:24 |
mikal | The only code reviews I have done for the last couple of days have been in _your_tree_ | 22:24 |
mikal | No one else is getting that | 22:25 |
mikal | But what I get in return is complaints about a process we've been warning you about for ages | 22:25 |
mikal | You can't pretend that requirement doesn't exist | 22:25 |
mikal | It does, and you must meet it | 22:25 |
*** jcoufal has quit IRC | 22:25 | |
openstackgerrit | A change was merged to openstack/ironic: Use mock.assert_called_once_with() https://review.openstack.org/108418 | 22:27 |
devananda | mikal: so I proposed a plan for that on May 22. It got a +2 on Jun 18, a few minor nits, and then a -2 on July 16 | 22:27 |
devananda | mikal: and then last week, we talked about it, which should have happened months ago | 22:28 |
devananda | mikal: we have been working on and proposing code to DO the upgrade in parallel with the spec | 22:28 |
devananda | mikal: but no one on Nova has looked | 22:28 |
devananda | until now | 22:28 |
devananda | jogo: i don't know what javelin is or how that helps here. please explain. | 22:29 |
devananda | mikal: also, thank you for the code reviews. I am sure taht you're busier than I am, and I really do appreciate your input here. | 22:29 |
*** malini1 has joined #openstack-ironic | 22:30 | |
devananda | mikal: even though we've had a near vacuum for months, and then got thrown under the bus because teh upgrade spec wasn't landed in time | 22:30 |
jogo | devananda: its what grenade uses to make sure resources stay around after an upgrade | 22:30 |
jogo | so you create some resources on old | 22:30 |
jogo | upgrade | 22:30 |
jogo | check on new cloud | 22:31 |
jogo | so for ironic it would be: | 22:31 |
jogo | create resources on old nova-bm | 22:31 |
jogo | check on ironic | 22:31 |
*** jgrimm has quit IRC | 22:31 | |
devananda | jogo: and does that require actually BOOTING anything with nova-bm? | 22:32 |
devananda | also - food.. I really need to eat | 22:32 |
devananda | and sleep | 22:32 |
jogo | devananda: it requires nova to think something has booted | 22:33 |
jogo | I dont' think it SSHs in or anything | 22:33 |
jogo | if it does we can make that an option | 22:33 |
* devananda gets food | 22:34 | |
mikal | devananda: so, I get that you have a plan for upgrade. That's why I am surprised when it keeps coming up. What this conversation started as was -- if you want to land our review requests in your tree first, then you will need to land some changes which are irrelevant to a strict interpretation of ironic but which make sense in the context of nova. That shouldn't be a big deal, because your copy of the code will be deleted soon. | 22:35 |
mikal | devananda: i.e. we want that refactor of the host manager class, and if that means landing a base class (and possibly the baremetal host manager) in your repo temporarily, then so be it | 22:36 |
mikal | I have to go feed a baby, back in a bit | 22:36 |
openstackgerrit | A change was merged to openstack/ironic: Factor out deploy info from PXE driver https://review.openstack.org/100735 | 22:39 |
*** Haomeng has joined #openstack-ironic | 22:42 | |
*** Haomeng|2 has quit IRC | 22:44 | |
*** lucas-dinner has quit IRC | 22:44 | |
*** malini1 has quit IRC | 22:44 | |
mikal | . | 22:45 |
*** shakamunyi_ has joined #openstack-ironic | 22:53 | |
*** rainya has joined #openstack-ironic | 22:58 | |
*** malini1 has joined #openstack-ironic | 23:07 | |
openstackgerrit | A change was merged to openstack/ironic: Use oslo.db library https://review.openstack.org/42159 | 23:12 |
*** rainya has quit IRC | 23:18 | |
*** mdorman has quit IRC | 23:23 | |
*** shakamunyi_ has quit IRC | 23:33 | |
*** chuckC has joined #openstack-ironic | 23:39 | |
*** rameshg87 has left #openstack-ironic | 23:44 | |
*** igordcard has quit IRC | 23:45 | |
*** eghobo has quit IRC | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!