*** matsuhashi has joined #openstack-ironic | 00:31 | |
*** mitz has quit IRC | 01:11 | |
*** mitz has joined #openstack-ironic | 01:25 | |
*** mitz has quit IRC | 01:28 | |
*** mitz has joined #openstack-ironic | 01:28 | |
*** theDavidAiken has joined #openstack-ironic | 01:37 | |
*** nosnos has joined #openstack-ironic | 01:39 | |
*** mitz has quit IRC | 01:57 | |
*** mitz has joined #openstack-ironic | 02:01 | |
*** theDavidAiken has quit IRC | 02:21 | |
*** annegentle_ has quit IRC | 02:25 | |
*** annegentle has joined #openstack-ironic | 02:35 | |
*** mitz has quit IRC | 02:48 | |
*** mitz has joined #openstack-ironic | 02:50 | |
*** mitz has quit IRC | 02:52 | |
*** mitz has joined #openstack-ironic | 02:54 | |
*** Haomeng has joined #openstack-ironic | 03:32 | |
*** Nisha has joined #openstack-ironic | 03:35 | |
*** Penick has joined #openstack-ironic | 03:37 | |
*** matsuhashi has quit IRC | 03:39 | |
*** Nisha has quit IRC | 03:40 | |
*** sseago has quit IRC | 03:47 | |
*** nosnos has quit IRC | 03:54 | |
*** Penick has quit IRC | 04:01 | |
*** sseago has joined #openstack-ironic | 04:01 | |
*** Poornima has joined #openstack-ironic | 04:05 | |
*** eghobo has joined #openstack-ironic | 04:17 | |
*** saripurigopi has joined #openstack-ironic | 04:25 | |
*** pradipta_away is now known as pradipta | 04:32 | |
*** matsuhashi has joined #openstack-ironic | 04:39 | |
*** nosnos has joined #openstack-ironic | 04:41 | |
*** rakesh_hs4 has joined #openstack-ironic | 04:45 | |
*** nosnos has quit IRC | 04:46 | |
*** nosnos has joined #openstack-ironic | 04:47 | |
*** vinbs has joined #openstack-ironic | 04:47 | |
*** nikunj2512 has joined #openstack-ironic | 04:55 | |
*** bmahalakshmi has joined #openstack-ironic | 05:07 | |
*** Poornima|mtg has joined #openstack-ironic | 05:13 | |
*** Poornima has quit IRC | 05:16 | |
*** coolsvap|afk has joined #openstack-ironic | 05:17 | |
*** coolsvap|afk is now known as coolsvap | 05:18 | |
*** ajc_ has joined #openstack-ironic | 05:29 | |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic-python-agent: Updated from global requirements https://review.openstack.org/88722 | 05:30 |
---|---|---|
*** coolsvap is now known as coolsvap|afk | 05:33 | |
*** nosnos has quit IRC | 05:35 | |
*** radsy has quit IRC | 05:36 | |
*** nosnos has joined #openstack-ironic | 05:37 | |
*** lazy_prince has joined #openstack-ironic | 05:40 | |
*** coolsvap|afk is now known as coolsvap | 05:41 | |
*** s-moriya has joined #openstack-ironic | 05:45 | |
*** s-moriya has quit IRC | 05:47 | |
*** Nisha has joined #openstack-ironic | 05:47 | |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic: Imported Translations from Transifex https://review.openstack.org/96063 | 06:01 |
*** coolsvap is now known as coolsvap|afk | 06:03 | |
*** matsuhashi has quit IRC | 06:05 | |
*** matsuhashi has joined #openstack-ironic | 06:06 | |
GheRivero | morning Ironic | 06:09 |
*** matsuhashi has quit IRC | 06:11 | |
saripurigopi | Can someone share ironic juno github link? | 06:13 |
*** coolsvap|afk is now known as coolsvap | 06:13 | |
*** matsuhashi has joined #openstack-ironic | 06:13 | |
Haomeng | morning GheRivero, saripurigopi | 06:17 |
Haomeng | saripurigopi: current is juno branch I think - https://github.com/openstack/ironic | 06:17 |
*** matsuhashi has quit IRC | 06:19 | |
*** matsuhashi has joined #openstack-ironic | 06:19 | |
saripurigopi | @Haomeng, I'm looking for driver specific vendor_passthru implementation, the defect says its fixed in juno version. | 06:22 |
*** coolsvap is now known as coolsvap|afk | 06:23 | |
saripurigopi | It is present in the latest code, Thanks @Haomeng. | 06:26 |
*** sysexit has joined #openstack-ironic | 06:26 | |
*** openstackstatus has quit IRC | 06:27 | |
Haomeng | saripurigopi: welcome:) | 06:31 |
*** vinbs has quit IRC | 06:35 | |
*** Mikhail_D_ltp has joined #openstack-ironic | 06:36 | |
*** vinbs has joined #openstack-ironic | 06:36 | |
*** vinbs has joined #openstack-ironic | 06:36 | |
*** eghobo has quit IRC | 06:37 | |
*** matsuhashi has quit IRC | 06:55 | |
*** matsuhashi has joined #openstack-ironic | 06:56 | |
*** viktors|afk is now known as viktors | 06:59 | |
*** rameshg87 has joined #openstack-ironic | 07:04 | |
*** Mikhail_D_ltp has quit IRC | 07:11 | |
*** romcheg has joined #openstack-ironic | 07:17 | |
*** coolsvap|afk is now known as coolsvap | 07:17 | |
*** ifarkas has joined #openstack-ironic | 07:31 | |
*** coolsvap is now known as coolsvap|afk | 07:41 | |
*** saripurigopi has quit IRC | 07:42 | |
*** vinbs has quit IRC | 07:44 | |
*** coolsvap|afk is now known as coolsvap | 07:54 | |
dtantsur|afk | morning Ironic | 07:55 |
mrda | hi dtantsur|afk | 07:55 |
*** dtantsur|afk is now known as dtantsur | 07:55 | |
dtantsur | mrda, hi :) | 07:55 |
romcheg | Morning dtantsur mrda and everyone else! | 07:56 |
mrda | hi romcheg | 07:56 |
dtantsur | morning, romcheg | 07:58 |
*** jcoufal has joined #openstack-ironic | 08:00 | |
*** Mikhail_D_ltp has joined #openstack-ironic | 08:04 | |
*** foexle has joined #openstack-ironic | 08:07 | |
*** Mikhail_D_ltp has quit IRC | 08:08 | |
*** Mikhail_D_ltp has joined #openstack-ironic | 08:10 | |
*** jcoufal has quit IRC | 08:11 | |
romcheg | Have to move the migration stuff to Nova | 08:11 |
Mikhail_D_ltp | Morning all! | 08:11 |
romcheg | Gah, another dependency hell :) | 08:11 |
mrda | Hi Mikhail_D_ltp | 08:12 |
mrda | and with that, good night all! | 08:12 |
*** mrda is now known as mrda-away | 08:12 | |
Mikhail_D_ltp | mrda-away: g'night :) | 08:12 |
*** jcoufal has joined #openstack-ironic | 08:13 | |
*** vinbs has joined #openstack-ironic | 08:23 | |
dtantsur | morning, Mikhail_D_ltp | 08:24 |
*** lucasagomes has joined #openstack-ironic | 08:28 | |
*** Mikhail_D_ltp has left #openstack-ironic | 08:38 | |
*** martyntaylor has joined #openstack-ironic | 08:41 | |
*** Poornima|mtg has quit IRC | 08:45 | |
*** romcheg has quit IRC | 08:55 | |
*** romcheg has joined #openstack-ironic | 08:55 | |
*** athomas has joined #openstack-ironic | 08:58 | |
*** Mikhail_D_ltp has joined #openstack-ironic | 08:59 | |
*** romcheg1 has joined #openstack-ironic | 09:03 | |
*** romcheg has quit IRC | 09:05 | |
*** mkerrin has quit IRC | 09:15 | |
*** romcheg1 is now known as romcheg | 09:16 | |
*** mkerrin has joined #openstack-ironic | 09:18 | |
*** max_lobur has joined #openstack-ironic | 09:19 | |
dtantsur | Folks, what is our current policy on changes introduced before we have a spec procedure? I'm feeling like requesting spec for https://review.openstack.org/#/c/86744/ | 09:25 |
dtantsur | As people keep arriving with different ideas on how to implement the particular feature | 09:25 |
rameshg87 | dtantsur, since it involved changes the base.py, yes i think it might make sense to have a spec for this | 09:28 |
rameshg87 | dtantsur, but i thought that was almost signed-off change :-) | 09:28 |
dtantsur | that's why I'm in doubts | 09:28 |
romcheg | ++ for spec! | 09:29 |
dtantsur | ok, I will block a patch and review spec asap, once it arrives | 09:29 |
rameshg87 | dtantsur, yeah ++ from me too :-) | 09:29 |
romcheg | dtantsur: agree! | 09:29 |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Add some real-world testing on DiskPartitioner https://review.openstack.org/94620 | 09:37 |
openstackgerrit | Imre Farkas proposed a change to openstack/ironic-specs: DRAC power driver https://review.openstack.org/99352 | 09:43 |
*** Poornima has joined #openstack-ironic | 09:43 | |
rameshg87 | dtantsur, romcheg i have a question | 09:44 |
romcheg | rameshg87: ask then :) | 09:44 |
rameshg87 | there was a previous commit from lucas which changed all the parameters from driver_info to instance_info recently: https://review.openstack.org/#/c/94855/14 | 09:45 |
dtantsur | not all but most, yes | 09:45 |
romcheg | s/all/some/ | 09:45 |
romcheg | s/some/most/ :) | 09:45 |
rameshg87 | having moved to instance_info, the parameter names have been changed to generic ones, and can be used by other deploy drivers | 09:45 |
rameshg87 | i think we can move to a common location. | 09:46 |
dtantsur | what exactly do you suggest to move? | 09:46 |
rameshg87 | this method: https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/pxe.py#L119-L164 | 09:47 |
romcheg | rameshg87: it depends on a driver I believe | 09:47 |
rameshg87 | romcheg, most of the fields are passed by nova to ironic, and won't most drivers atleast need a look at those fields ? | 09:48 |
rameshg87 | romcheg, except for CONF.pxe.default_ephemeral_format, i don't see anything 'pxe'-specific there :-) | 09:49 |
*** pelix has joined #openstack-ironic | 09:49 | |
dtantsur | Maybe (except for deploy_key). This worse trying to write a spec, I guess :) | 09:50 |
romcheg | rameshg87: We cannot say some other drivers won't need putting something different there. I'm not as familiar with different hardware as NobodyCam is so I'd ask his opinion | 09:51 |
rameshg87 | romcheg, i was thinking if we can move the most common things (which are all already in that method) to a common place | 09:52 |
romcheg | dtantsur: Do we need a spec for a refactoring? In general it should not change the behaviour of the code in the end | 09:52 |
rameshg87 | romcheg, dtantsur, yeah that was my question. can we file a bug and suggest a change like this in a patch ? | 09:53 |
dtantsur | romcheg, I don't know. These kinds of refactoring often go to far... | 09:53 |
romcheg | rameshg87: It makes sense if we move the common properties to a common place (by common I mean that we guarantee that those properties are required for all observable drivers) | 09:53 |
*** Nisha has quit IRC | 09:53 | |
romcheg | rameshg87: and then we add methods like _populate_instance_info(…) to the drivers and so drivers add their own stuff | 09:54 |
dtantsur | rameshg87, romcheg: my request for spec was to at least specify: 1. what we mean by "common properties", 2. which properties we expect to be common | 09:54 |
romcheg | dtantsur: Agree, if we define those common properties, we can factor them out to some common place. | 09:55 |
rameshg87 | dtantsur, romcheg, okay. thanks :-) | 09:56 |
rameshg87 | dtantsur, romcheg, i would pursue writing a spec for this .. | 09:56 |
romcheg | rameshg87, dtantsur: If most of the instance_info is common, that factoring it out makes sense. Otherwise it'll only add more complexity | 09:56 |
romcheg | Anyway, NobodyCam, devananda, we need your opinion on ^^ | 09:57 |
rameshg87 | romcheg, i feel it is. if those deploy drivers are not going to honour them, they may ignore them | 09:57 |
*** vinbs has quit IRC | 09:57 | |
*** vinbs has joined #openstack-ironic | 09:58 | |
foexle | heyho guys, i'm trying to write a manual install doc for ironic on different hosts (comp, controller, net) and i've some questions is here anyone they can help ? | 10:06 |
foexle | first question: i installed conductor and api on controller host, confgure nova config for ironic and now on the compute node the network. Is that correct or should the conductor running on the comp host ? | 10:09 |
romcheg | foexle: Do you mean Ironic Conductor? | 10:11 |
foexle | romcheg: yep :) | 10:12 |
dtantsur | foexle, as devananda explained last week, Conductor is completely independent and can be run everywhere | 10:13 |
romcheg | So Nova does not interract with Ironic Conductor. It only queries Ironic over the API | 10:13 |
dtantsur | foexle, it may be even better to run it on a separate machine, as it's quite privileged | 10:13 |
romcheg | foexle: Does it answer your question? | 10:13 |
foexle | dtantsur: yes i know, romcheg answer solved my question. so conductor doesn't need to commuicate directly with libvirt | 10:17 |
foexle | nova-comute will communicate ? .... exactly the ironic compute driver | 10:18 |
dtantsur | right, conductor does not communicate with libvirt. ironic driver does all interaction with nova internals, conductor is accessed via HTTP API | 10:18 |
foexle | dtantsur: thanks :), i'm installing and configuring step by step with help of devstack | 10:20 |
*** amitpp has joined #openstack-ironic | 10:32 | |
dtantsur | Folks, we're having our docs builds marked as "UNSTABLE". What does it mean? | 10:35 |
romcheg | dtantsur: Usually that means some problems with the node | 10:35 |
romcheg | dtantsur: Better ask in #openstack-infra | 10:36 |
dtantsur | ack thnx | 10:36 |
*** amitpp has quit IRC | 10:42 | |
*** amitpp has joined #openstack-ironic | 10:42 | |
*** petertoft has joined #openstack-ironic | 10:43 | |
*** pradipta is now known as pradipta_away | 10:45 | |
*** amitpp has quit IRC | 10:47 | |
*** amitpp has joined #openstack-ironic | 10:47 | |
dtantsur | https://bugs.launchpad.net/openstack-ci/+bug/1333197 | 10:56 |
dtantsur | tl;dr docs server ran out of disk space | 10:57 |
romcheg | Just as I said — a problem with the node | 11:01 |
*** pradipta_away is now known as pradipta | 11:04 | |
lucasagomes | :( | 11:07 |
*** romcheg1 has joined #openstack-ironic | 11:09 | |
*** romcheg has quit IRC | 11:10 | |
*** coolsvap is now known as coolsvap|afk | 11:11 | |
dtantsur | Folks, anyone to approve https://review.openstack.org/#/c/94371/ ? 2x +2, 3x +1 already | 11:12 |
dtantsur | also, <ruhe> you can use "recheck bug 1333197" to restart jenkins jobs | 11:13 |
yuriyz | good day dtantsur, I will look | 11:14 |
dtantsur | yuriyz, hi, thanks! | 11:14 |
*** romcheg has joined #openstack-ironic | 11:14 | |
*** romcheg1 has quit IRC | 11:15 | |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Do not delete pxe_deploy_{kernel, ramdisk} on tear down https://review.openstack.org/101864 | 11:31 |
openstackgerrit | Ramakrishnan G proposed a change to openstack/ironic-specs: iLO Power Driver for Ironic https://review.openstack.org/97455 | 11:33 |
*** rameshg87 has left #openstack-ironic | 11:36 | |
*** rameshg87 has joined #openstack-ironic | 11:36 | |
*** rameshg87 has left #openstack-ironic | 11:36 | |
foexle | question again :( .... ironic node-create => -i ssh_address and other ssh options which ip should i use here ? Do i need to take a free ipaddress of my neutron subnet ? or the ip of the compute host ?! | 11:37 |
*** lucasagomes is now known as lucas-hungry | 11:38 | |
*** pradipta is now known as pradipta_away | 11:46 | |
dtantsur | foexle, that's if you use virtual environment and PXE power driver | 11:48 |
dtantsur | foexle, than it's IP address of virtualization host, where your VM's will run | 11:48 |
dtantsur | yuriyz, changes you commented on were introduced after previous reviews :) I don't care, I can just as well delete them, as I anyway have to rebase | 11:49 |
foexle | dtantsur: ah ok what should i use if i dont user venv ? and which driver ? | 11:49 |
dtantsur | foexle, probably one of IPMI drivers | 11:49 |
foexle | ahhh i see and as IP address the IPMI ip with login creds right ? | 11:50 |
yuriyz | dtantsur, ok | 11:50 |
dtantsur | I guess we don't have docs on IPMI, do we? | 12:02 |
dtantsur | added to https://bugs.launchpad.net/ironic/+bug/1323589 | 12:03 |
*** vinbs has quit IRC | 12:08 | |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: PXE to pass hints to ImageCache on how much space to reclaim https://review.openstack.org/94371 | 12:09 |
dtantsur | yuriyz, lucas-hungry, romcheg rebased ^^^ could you reconsider? | 12:10 |
yuriyz | ok | 12:10 |
foexle | dtantsur: thx i'll try to boot with IPMI and will inform you .... I'll try to make a github repo with my doc i've done some steps which is missing in your doc | 12:19 |
dtantsur | foexle, cool! If you do, please link it to bug report https://bugs.launchpad.net/ironic/+bug/1323589 | 12:20 |
*** matsuhashi has quit IRC | 12:23 | |
*** jdob has joined #openstack-ironic | 12:23 | |
*** matsuhashi has joined #openstack-ironic | 12:23 | |
*** matsuhashi has quit IRC | 12:28 | |
*** matsuhashi has joined #openstack-ironic | 12:28 | |
foexle | dtantsur: of course :) | 12:31 |
*** Poornima has quit IRC | 12:33 | |
*** bmahalakshmi has quit IRC | 12:35 | |
*** matsuhashi has quit IRC | 12:35 | |
*** matsuhashi has joined #openstack-ironic | 12:35 | |
viktors | dtantsur: around? | 12:38 |
dtantsur | viktors, yep | 12:38 |
dtantsur | hi | 12:38 |
*** matsuhas_ has joined #openstack-ironic | 12:38 | |
viktors | dtantsur: hi! | 12:38 |
viktors | I have a question about bug https://launchpad.net/bugs/1277555 | 12:39 |
dtantsur | sure | 12:39 |
*** matsuhashi has quit IRC | 12:39 | |
*** ajc_ has quit IRC | 12:40 | |
viktors | dtantsur: why do you suppose to map all db exception to IronicDBError class instead of raise something like NodeAlreadyExist? | 12:41 |
dtantsur | viktors, the idea (inherited from Josh actually) is to raise specific exception, when we have it. When we don't - raise generic exception, that hides SQL details | 12:42 |
*** lucas-hungry is now known as lucasagomes | 12:43 | |
dtantsur | any comments and suggestions are welcome :) | 12:43 |
viktors | well, I'm just confused a bit with this change, but anyway, it's just IMO - I'm not from core team :) | 12:44 |
dtantsur | viktors, it's a difficult topic, any feedback is highly appreciated | 12:45 |
viktors | dtantsur: AFAIK, such approach is preferable in OS - https://github.com/openstack/ironic/blob/master/ironic/db/sqlalchemy/api.py#L388 | 12:45 |
dtantsur | viktors, sure, my point is what to do, when we don't expect a particular exception | 12:46 |
viktors | dtantsur: well, anyway it's should be a some kind of server error | 12:47 |
viktors | so there is no big sense to cut SQL tracebach there | 12:47 |
viktors | *traceback | 12:47 |
dtantsur | viktors, I guess the point is to never show SQL details in e.g. node-show output | 12:48 |
viktors | dtantsur: yes, but it's not commercial product, so we can allow it for debug | 12:50 |
viktors | at least | 12:50 |
dtantsur | viktors, IIRC, if debug = True, everything is left as it is | 12:51 |
*** amitpp has quit IRC | 12:52 | |
viktors | dtantsur: you mean, if we will use patch https://review.openstack.org/#/c/73121 & | 12:54 |
viktors | ? | 12:54 |
viktors | seems to be, that we loose thaceback in this case (or maybe I miss something?) | 12:55 |
dtantsur | viktors, at least it used to be there... now I don't see the code, but I can reintroduce it | 12:55 |
dtantsur | viktors, we're loosing Python traceback (it still gets logged), and I expected we leave SQL error in case of debug=True, but it seems no longer the case and I will check it | 12:56 |
*** linggao has joined #openstack-ironic | 12:57 | |
viktors | dtantsur: ok, just to be sure, that we don't loose debug information (like traceback) in this case | 12:58 |
viktors | dtantsur: in a few worlds - my point is - we set code 409 only for DBDuplicateEntry, so IMO, there is a sense to catch there exceptions in db-api methods. Another exception can provide usefull debud information. | 12:58 |
viktors | *debug | 12:59 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Do not delete pxe_deploy_{kernel, ramdisk} on tear down https://review.openstack.org/101864 | 12:59 |
dtantsur | viktors, you mean, catch DBDuplicateEntry in db-api methods explicitly? | 13:00 |
viktors | dtantsur: yes, see an example here - https://github.com/openstack/ironic/blob/master/ironic/db/sqlalchemy/api.py#L388 | 13:01 |
*** coolsvap|afk is now known as coolsvap | 13:01 | |
dtantsur | viktors, provided that this exception only happens on save and create - yes, makes sense | 13:02 |
viktors | dtantsur: agreed | 13:02 |
*** rloo has joined #openstack-ironic | 13:03 | |
*** matsuhas_ has quit IRC | 13:03 | |
dtantsur | viktors, cool, thanks! So I'll update a patch with 2 fixes we spotted: don't hide SQL error with debug=True and catch DBDuplicateEntry explicitly | 13:03 |
*** matsuhashi has joined #openstack-ironic | 13:03 | |
*** dtantsur is now known as dtantsur|lunch | 13:06 | |
viktors | dtantsur|lunch: : ok, I will also add a comment to discussion in launchpad | 13:06 |
*** rloo has quit IRC | 13:07 | |
*** rloo has joined #openstack-ironic | 13:07 | |
*** matsuhashi has quit IRC | 13:08 | |
*** matsuhashi has joined #openstack-ironic | 13:08 | |
*** rloo has quit IRC | 13:08 | |
*** rloo has joined #openstack-ironic | 13:09 | |
*** matsuhashi has quit IRC | 13:13 | |
*** rloo has quit IRC | 13:14 | |
*** matsuhashi has joined #openstack-ironic | 13:14 | |
*** rloo has joined #openstack-ironic | 13:14 | |
*** rloo has quit IRC | 13:17 | |
*** rloo has joined #openstack-ironic | 13:17 | |
*** rloo has quit IRC | 13:17 | |
*** rloo has joined #openstack-ironic | 13:17 | |
*** matsuhashi has quit IRC | 13:18 | |
*** rloo has quit IRC | 13:18 | |
*** rloo has joined #openstack-ironic | 13:21 | |
*** rloo_ has joined #openstack-ironic | 13:21 | |
*** rloo has quit IRC | 13:24 | |
NobodyCam | good morning | 13:26 |
NobodyCam | brb mak'n coffee | 13:27 |
*** dtantsur|lunch is now known as dtantsur | 13:27 | |
*** matty_dubs has joined #openstack-ironic | 13:28 | |
dtantsur | NobodyCam, morning! | 13:28 |
matty_dubs | Mornin' NobodyCam, dtantsur! | 13:28 |
dtantsur | matty_dubs, \o/ | 13:29 |
dtantsur | how were your pto? | 13:29 |
*** nosnos has quit IRC | 13:29 | |
matty_dubs | dtantsur: Great! Nice and relaxing. But, soooooo much email this morning. | 13:30 |
lucasagomes | morning all | 13:30 |
dtantsur | lucasagomes, morning :) | 13:31 |
jroll | morning y'all | 13:31 |
dtantsur | matty_dubs, oh yeah, I got back from PTO last monday I was shocked. Next week I'm going on 2-weeks PTO and it's going to be much worse :) | 13:31 |
dtantsur | jroll, morning! | 13:31 |
romcheg | Morning NobodyCam jroll matty_dubs! | 13:31 |
jroll | dtantsur: hey, about https://review.openstack.org/#/c/86744/ | 13:32 |
jroll | I have mixed feelings about needing a spec for this | 13:32 |
jroll | there's two ways to look at this change: | 13:32 |
jroll | 1) removing hard-coded assumptions: IMO doesn't need a spec | 13:33 |
jroll | 2) supporting long-running deploy ramdisks: definitely needs a spec, but the spec would be along the lines of supporting that, not a simple spec to factor the hard-coded logic out | 13:33 |
NobodyCam | morning dtantsur lucasagomes romcheg matty_dubs and jroll | 13:36 |
jroll | hey NobodyCam | 13:36 |
dtantsur | jroll, I also have mixed feeling actually, but it's changing our interfaces, so there should be a spec. I would not require it, though, was it not for the last comment, which asked to change the implementation substantially | 13:36 |
dtantsur | jroll, now we have either to ignore the comment and approve (possible, not good) or change the way it's implemented (than we need a spec, so that we don't argue forever) | 13:37 |
dtantsur | what do you think? | 13:37 |
jroll | dtantsur: I'm not sure I understand the point of that comment :/ | 13:38 |
jroll | 2. The function can't be reused. For example, if some other operations, say 'firmware update' or something wanted to check power state, this method can't be reused. | 13:38 |
jroll | this isn't true | 13:38 |
jroll | (1) is about it being odd to be on the base class, and I'm not sure that's a valid comment | 13:39 |
jroll | valid comment to block the work on, I should say | 13:39 |
jroll | rameshg8-: ^ around? | 13:39 |
dtantsur | jroll, I understood it like: we may want every interface to have a list of operations and possible states for them | 13:39 |
rloo_ | dtantsur: hi! wrt https://review.openstack.org/#/c/100571/3//COMMIT_MSG, 'docn' is short for documentation. 'docs' isn't quite right cuz it is only one section that is updated (not more than one doc). | 13:39 |
NobodyCam | morning rloo_ :) | 13:40 |
dtantsur | jroll, and than it may make sense to have a generic function | 13:40 |
rloo_ | dtantsur: hi. sorry, i'll just reply to the patch. no need to ping you here about it ;) | 13:40 |
rloo_ | NobodyCam: morning! | 13:40 |
dtantsur | rloo_, morning :) thanks you for explanation, as you probably know my English leaves a lot to be desired :) | 13:40 |
jroll | dtantsur: if a driver needs to check power state for 'firmware update', it would add 'firmware update' to `valid_states` dict defined in that driver | 13:40 |
dtantsur | jroll, to me (1) is not valid: interface can have default implementations (e.g. in modern programming languages) | 13:41 |
rloo_ | dtantsur: no worries! Your English is quite good considering it isn't your first language. | 13:41 |
dtantsur | rloo_ :) | 13:41 |
openstackgerrit | A change was merged to openstack/ironic: PXE to pass hints to ImageCache on how much space to reclaim https://review.openstack.org/94371 | 13:41 |
jroll | dtantsur: if a new method 'firmware update' is added to the base class or conductor or whatever, defaults will be added to the `valid_states` dict, drivers can implement as needed | 13:41 |
dtantsur | jroll, but "firmware update" won't be in deploy interface, it's likely to be in management interface | 13:41 |
*** rloo_ has quit IRC | 13:41 | |
jroll | hrm | 13:42 |
*** rloo has joined #openstack-ironic | 13:42 | |
jroll | fwiw, I'm still not sure how I feel about the fact that we have Power/Management/Deploy interfaces, but that might just be me | 13:42 |
jroll | e.g. the ManagementInterface for agent_ipmitool will need to speak both to the agent and to IPMI | 13:43 |
dtantsur | jroll, heh... the separation may be a bit artificial from the very beginning | 13:44 |
dtantsur | jroll, does writing a spec for this change seriously slow down your work? | 13:45 |
jroll | dtantsur: if I say yes, will you change your mind? :) | 13:45 |
*** blamar has joined #openstack-ironic | 13:45 | |
jroll | dtantsur: I'm coming from a project perspective on this, I don't mind writing a spec | 13:46 |
jroll | dtantsur: my plan is eventually to write a spec about long-running deploy ramdisks, and this patch would be part of that patch series | 13:46 |
jroll | (if it's not landed before I get to that, of course) | 13:46 |
dtantsur | jroll, I could :) But I definitely prefer a spec for everything that changes interfaces | 13:47 |
dtantsur | also, I don't how the others feel, but I prefer many small specs rather than one huge | 13:47 |
*** rloo has quit IRC | 13:48 | |
jroll | +1 | 13:48 |
*** rloo has joined #openstack-ironic | 13:48 | |
jroll | although, sometimes I'd rather have 1 large spec per feature, rather than many small specs to build one feature | 13:49 |
jroll | dtantsur: in the bottom section here, 'depends on 84795', we will need specs for all of those https://etherpad.openstack.org/p/ipa-todos | 13:50 |
jroll | dtantsur: so you can expect specs for each of those | 13:50 |
dtantsur | jroll, I understand the feeling. But it's obviously easier to review small ones | 13:50 |
dtantsur | jroll, I am ready, you won't scare me :) | 13:51 |
*** rloo has quit IRC | 13:51 | |
* dtantsur thinks we should speed up with approving specs actually | 13:51 | |
jroll | dtantsur: heh, getting there :) | 13:52 |
jroll | and +1 on speeding up | 13:52 |
* jroll pokes russell_h to do a bunch of spec review | 13:52 | |
dtantsur | jroll, I'll talk to devananda today, but I guess we need at least one more low-level things guru (like IPMI etc) | 13:53 |
dtantsur | ... in specs-core team | 13:53 |
*** rloo has joined #openstack-ironic | 13:54 | |
*** rloo has quit IRC | 13:54 | |
*** rloo has joined #openstack-ironic | 13:54 | |
jroll | dtantsur: indeed | 13:54 |
jroll | dtantsur: for ipmi specifically, I'd nominate jbjohnso (though he's not here as much as he used to be, it seems) | 13:55 |
*** rloo has quit IRC | 13:55 | |
*** rloo has joined #openstack-ironic | 13:55 | |
dtantsur | ok, we can discuss on the meeting | 13:55 |
jroll | dtantsur: also, JayF comes from an ops background and is pretty good with low-level systems stuff, e.g. kernels, disk partitioning, etc | 13:55 |
jroll | JayF has been our go-to guy for debugging linux incompatibilities on our opencompute gear | 13:56 |
*** rloo has quit IRC | 13:56 | |
jroll | s/incompatibilities/random issues/ | 13:56 |
*** rloo has joined #openstack-ironic | 13:56 | |
*** rloo has quit IRC | 13:57 | |
*** rloo has joined #openstack-ironic | 13:58 | |
*** rloo has quit IRC | 14:00 | |
*** rloo has joined #openstack-ironic | 14:01 | |
*** rloo has quit IRC | 14:02 | |
openstackgerrit | David Shrewsbury proposed a change to openstack/ironic-specs: Make the REST API fully asynchronous https://review.openstack.org/94923 | 14:02 |
*** rloo has joined #openstack-ironic | 14:02 | |
lucasagomes | jroll, ping re agent POSTing things back to the Ironic API. I see that the agent when it starts it will POST the hardware information to the drivers/.../vendor_passthru/lookup URI | 14:03 |
lucasagomes | jroll, how the authentication works? | 14:04 |
*** rloo has quit IRC | 14:04 | |
*** rloo has joined #openstack-ironic | 14:04 | |
lucasagomes | jroll, there's a token in the tftp directly that the agent will get in order to authenticate when talking to the ironic API? | 14:04 |
jroll | lucasagomes: we've been debating how that will work. maybe client cert checking. there's nothing today, except securing the heck out of the provisioning network | 14:04 |
lucasagomes | jroll, right | 14:05 |
lucasagomes | jroll, but how u guys are doing today? no auth? | 14:05 |
jroll | correct, just a very secure network | 14:05 |
Shrews | All: 94923 is my attempt to pick up some of that work from devananda and coalesce some ideas that were discussed in an etherpad. Please be gentle and be aware that I *very likely* have some misunderstandings that will need correcting. :) | 14:05 |
lucasagomes | jroll, ok gotcha, thanks | 14:05 |
jroll | lucasagomes: we expect to have auth soon | 14:05 |
jroll | lucasagomes: I'm not sure if I like the token thing, because any node that can dhcp can get a token, yes? | 14:06 |
lucasagomes | jroll, yea that would be good... just checking because I was thinking about how to do that, but don't want to reivent the wheel in case u guys already had something ready for it | 14:06 |
lucasagomes | jroll, yeah the token is flawed | 14:06 |
lucasagomes | jroll, we need something better for sure | 14:07 |
jroll | lucasagomes: yeah, client cert checks are the idea right now... however there exists zero python to do such a thing afaik :/ | 14:07 |
jroll | lucasagomes: a couple guys working on barbican/cryptography.io even told us "just use nginx" | 14:07 |
lucasagomes | jroll, you guys have any etherpad/wiki/... about how would that work? | 14:07 |
jroll | no, we've just been tossing around ideas at lunch etc | 14:08 |
lucasagomes | right, yeah :( | 14:08 |
lucasagomes | jroll, no problemo | 14:08 |
jroll | security is hard (tm) | 14:08 |
lucasagomes | +1 | 14:09 |
dtantsur | Shrews, sure, will have a look :) | 14:11 |
Shrews | dtantsur: you may want to wait and let devananda have a pass at it first :) | 14:12 |
NobodyCam | everyone looked at todays agenda, are we all up to date? | 14:13 |
*** rloo has quit IRC | 14:13 | |
* dtantsur is looking | 14:13 | |
NobodyCam | :-p | 14:13 |
*** rloo has joined #openstack-ironic | 14:14 | |
*** lazy_prince has quit IRC | 14:15 | |
*** rloo has quit IRC | 14:15 | |
jroll | NobodyCam: btw, I have to leave the meeting about 10 minutes early... if the meeting is moving slow please keep me in mind :) | 14:15 |
NobodyCam | jroll: ack.. we'll try and get you up to bat early | 14:16 |
*** rloo has joined #openstack-ironic | 14:16 | |
jroll | thanks :) | 14:16 |
* jroll owes NobodyCam a bagel for that one :P | 14:17 | |
NobodyCam | :-p | 14:17 |
*** rloo has quit IRC | 14:17 | |
*** rloo has joined #openstack-ironic | 14:17 | |
*** rloo has joined #openstack-ironic | 14:18 | |
*** rloo has quit IRC | 14:18 | |
*** rloo has joined #openstack-ironic | 14:19 | |
*** rloo_ has joined #openstack-ironic | 14:20 | |
*** rloo__ has joined #openstack-ironic | 14:21 | |
*** rloo__ has quit IRC | 14:22 | |
*** rloo__ has joined #openstack-ironic | 14:23 | |
*** rloo has quit IRC | 14:24 | |
*** rloo_ has quit IRC | 14:24 | |
*** pcrews has joined #openstack-ironic | 14:25 | |
*** rloo has joined #openstack-ironic | 14:31 | |
*** rloo__ has quit IRC | 14:31 | |
*** rakesh_hs4 has quit IRC | 14:37 | |
*** rloo has quit IRC | 14:38 | |
*** rloo has joined #openstack-ironic | 14:39 | |
*** rloo has joined #openstack-ironic | 14:40 | |
*** rloo has quit IRC | 14:40 | |
*** rloo has joined #openstack-ironic | 14:41 | |
*** rloo has quit IRC | 14:41 | |
*** rloo has joined #openstack-ironic | 14:42 | |
*** rloo has quit IRC | 14:43 | |
*** rloo has joined #openstack-ironic | 14:45 | |
*** rloo_ has joined #openstack-ironic | 14:46 | |
NobodyCam | any one know if neutron supports dhcp option #42 .. would setting that work for https://bugs.launchpad.net/ironic/+bug/1331862 | 14:47 |
*** rloo_ has quit IRC | 14:48 | |
*** rloo_ has joined #openstack-ironic | 14:48 | |
*** rloo has quit IRC | 14:49 | |
Shrews | NobodyCam: hrm, that's interesting. alas, i have no answer for you | 14:50 |
*** rloo has joined #openstack-ironic | 14:50 | |
*** rloo has quit IRC | 14:51 | |
NobodyCam | 42 is the ultimate answer ... :-p | 14:51 |
lucasagomes | NobodyCam, +1 | 14:52 |
lucasagomes | hah | 14:52 |
*** rloo has joined #openstack-ironic | 14:52 | |
*** rloo has quit IRC | 14:53 | |
*** rloo has joined #openstack-ironic | 14:53 | |
*** rloo_ has quit IRC | 14:53 | |
*** rloo has quit IRC | 14:55 | |
*** rwsu has joined #openstack-ironic | 14:55 | |
*** rloo has joined #openstack-ironic | 14:56 | |
*** rloo has quit IRC | 15:01 | |
*** rloo has joined #openstack-ironic | 15:01 | |
*** rloo has quit IRC | 15:02 | |
*** rloo has joined #openstack-ironic | 15:03 | |
*** rloo has quit IRC | 15:04 | |
*** rloo has joined #openstack-ironic | 15:04 | |
*** rloo has quit IRC | 15:04 | |
*** rloo has joined #openstack-ironic | 15:05 | |
*** rloo has quit IRC | 15:06 | |
*** mdorman has joined #openstack-ironic | 15:07 | |
*** rloo has joined #openstack-ironic | 15:08 | |
*** rloo has quit IRC | 15:08 | |
*** rloo has joined #openstack-ironic | 15:09 | |
*** rloo has quit IRC | 15:11 | |
petertoft | Any takers for https://bugs.launchpad.net/ironic/+bug/1321787? This is breaking most of our virtual runs using TripleO, and hence is a critical issue for us. I have folks on my team looking at it, but additional expertise would be welcome. | 15:14 |
NobodyCam | petertoft: have you looked at https://github.com/paramiko/paramiko/issues/173 | 15:17 |
*** rloo_ has joined #openstack-ironic | 15:18 | |
*** rloo has joined #openstack-ironic | 15:18 | |
*** rloo has quit IRC | 15:19 | |
*** rloo has joined #openstack-ironic | 15:19 | |
*** rloo__ has joined #openstack-ironic | 15:20 | |
*** rloo_ has quit IRC | 15:21 | |
*** rloo__ has quit IRC | 15:21 | |
*** rloo_ has joined #openstack-ironic | 15:21 | |
petertoft | NobodyCam: Thanks. My folks have indicated that there are underlying Paramiko/Eventlet issues, but I guess I'm concerned that this is going to fall into the gaps. | 15:23 |
*** rloo has quit IRC | 15:24 | |
Shrews | interesting comment at the end of https://bugs.launchpad.net/sahara/+bug/1212341 What version of paramiko are you using, petertoft? | 15:24 |
Shrews | oh, we already require a version higher than that. nevermind | 15:25 |
openstackgerrit | Dan Prince proposed a change to openstack/ironic: Port iBoot PDU driver from Nova https://review.openstack.org/50977 | 15:25 |
petertoft | Heh, I've no idea (whatever upstream is using), but I'll pass this along. Thanks Shrews. | 15:26 |
Shrews | petertoft: i don't think it's relevant, actually | 15:26 |
petertoft | Yeh, saw that. Thanks anyway | 15:26 |
*** rloo_ has quit IRC | 15:26 | |
*** nikunj2512 has quit IRC | 15:28 | |
*** romcheg1 has joined #openstack-ironic | 15:30 | |
lifeless | mrda-away: were you going to land https://review.openstack.org/#/c/97693/ ? | 15:31 |
devananda | morning, all | 15:31 |
*** romcheg has quit IRC | 15:32 | |
lucasagomes | devananda, morning | 15:33 |
NobodyCam | good morning devananda | 15:34 |
lucasagomes | devananda, can you scroll back a bit and see the conversation I had with jroll about authentication and ramdisk | 15:34 |
*** rloo has joined #openstack-ironic | 15:34 | |
lucasagomes | devananda, have you put any thoughts about the right way to solve that problem? | 15:34 |
devananda | foexle: "ssh*" driver is meant for test environments which do not have real hardware with remote power capabilities (eg, no IPMI) | 15:35 |
devananda | foexle: if you are testing with real hardware, you should probably use the pxe_ipmitool driver for now | 15:35 |
*** jcoufal has quit IRC | 15:35 | |
dtantsur | morning, devananda! | 15:37 |
* devananda is catching up ons crollback | 15:37 | |
*** romcheg has joined #openstack-ironic | 15:38 | |
lifeless | mrda-away: ah, nvm I see. | 15:38 |
*** romcheg1 has quit IRC | 15:40 | |
jroll | mornin devananda | 15:43 |
devananda | lucasagomes: hi! caught up now - i think you're asking about securely auth'ing the first POST from the ramdisk (whether IPA or PXE ramdisk, doedsn't matter) | 15:44 |
devananda | lucasagomes: yes? | 15:44 |
lucasagomes | devananda, correct | 15:44 |
devananda | lucasagomes: while using standard IPMI, I'm not aware of any solution yet, though jbjohnso may know some tricks using the SOL console to inject data | 15:45 |
lifeless | mrda-away: but I prefer your patch I think. Commented on NobodyCam's | 15:45 |
devananda | lucasagomes: if using a driver which extends OOB channel, eg iLO or SeaMicro, then it is much simpler | 15:45 |
NobodyCam | morning lifeless ... On a conf call atm ... will look over the comments in a little bit | 15:47 |
lucasagomes | devananda, wait, I think we are a bit out of sync... because it's between the ramdisk and our API | 15:47 |
devananda | lucasagomes: create a small ISO9660 image, containing a cert or priv key unique to that machine, and a copy of the server's pub key, load that via the BMC, then DHCP BOOT a ramdisk which uses those to communicate back to ironic | 15:47 |
*** rloo_ has joined #openstack-ironic | 15:47 | |
lucasagomes | devananda, like when we POST the iqn for the ISCSI disk to the vendor_passtrhu/pass_deploy_info URI | 15:47 |
devananda | right | 15:47 |
lucasagomes | devananda, or for future work, to the discovery ramdisk to talk back to the Ironic api and register itself on it | 15:48 |
lucasagomes | independent from the driver | 15:48 |
romcheg | Good morning devananda! | 15:49 |
devananda | lucasagomes: yep yep. well, not independent from the driver | 15:49 |
devananda | lucasagomes: because any crypto capabilities of the hardware will be known by the driver -- they won't be generic | 15:49 |
*** martyntaylor has quit IRC | 15:50 | |
lucasagomes | devananda, right | 15:50 |
lucasagomes | devananda, cause I was thinking about how to eliminate that admin token on the tftp directory that we use right now | 15:51 |
devananda | lucasagomes: load the token directly via the BMC | 15:51 |
*** eghobo has joined #openstack-ironic | 15:51 | |
devananda | let me see if this is described in the ilo spec ... | 15:51 |
devananda | it should be | 15:51 |
lucasagomes | right | 15:51 |
lucasagomes | devananda, ok so I'm out of the track hehe, I was reading about Keystone Trust | 15:52 |
*** rameshg87 has joined #openstack-ironic | 15:52 | |
lucasagomes | like having a user for the deployment with scoped permissions | 15:52 |
devananda | lucasagomes: keystone should probably be used as the source of trust. or barbican. or something. | 15:52 |
devananda | lucasagomes: but the delivery of those keys to the node needs to be dnoe by the driver's management interface via the OOB virtual-media channel | 15:52 |
*** eghobo has quit IRC | 15:53 | |
devananda | lucasagomes: that is the most trusted channel in deployment environments | 15:53 |
lucasagomes | devananda, I c | 15:53 |
devananda | which is somewhat ironic, because IPMI is actually rather insecure | 15:53 |
lucasagomes | interesting I will take a look at the iLo spec | 15:53 |
lucasagomes | lol | 15:53 |
lucasagomes | yeah | 15:53 |
*** Nisha has joined #openstack-ironic | 15:54 | |
Nisha | dtantsur: Hi | 15:54 |
devananda | lucasagomes: https://review.openstack.org/#/c/97744/2/specs/ironic-ilo-virtualmedia-driver.rst | 15:55 |
devananda | described there | 15:55 |
*** rloo_ has quit IRC | 15:56 | |
rameshg87 | devananda, lucasagomes, looks like i joined at the right time. i was just thinking i would remind someone about having a look at the ilo deploy spec :-) | 15:56 |
devananda | rameshg87: o/ | 15:56 |
lucasagomes | :D | 15:56 |
lucasagomes | rameshg87, devananda thanks | 15:56 |
*** eghobo has joined #openstack-ironic | 15:58 | |
devananda | rameshg87: in deploy(), is the deploy_iso shared? or is it unique to each node? | 15:59 |
dtantsur | Nisha, hi | 15:59 |
rameshg87 | devananda, the deploy_iso is shared. | 15:59 |
Nisha | dtantsur: I have seen your comments for https://review.openstack.org/#/c/100951/7 | 16:00 |
NobodyCam | brb | 16:00 |
devananda | rameshg87: ok, small problem in the spec, leaving a comment | 16:00 |
Nisha | Why do you think it shall be split into two? | 16:01 |
*** viktors is now known as viktors|afk | 16:01 | |
Nisha | dtantsur: : Why do you think it shall be split into two? | 16:01 |
devananda | rameshg87: actually, question -- why does this driver need both deploy kernel/ramdisk AND deploy_iso ? | 16:01 |
rameshg87 | devananda, we don't ask the user to build the deploy_iso. for the first deployment, ironic conductor builds deploy kernel/ramdisk and then uploads the glance. | 16:02 |
devananda | rameshg87: how? | 16:02 |
dtantsur | Nisha, it's proposed change part is nearly 200 lines and looks like covering several use cases. It would be very good for reviewers, if you manage to split it. | 16:03 |
rameshg87 | devananda, it uses mkisofs utility to create an isolinux based iso image. the user just provides the deploy kernel/ramdisk for the image (as glance arguments). | 16:04 |
dtantsur | Nisha, when reviewing a spec, we have to read it several times and understand as a whole, which is hard for a large spec. | 16:04 |
devananda | rameshg87: if the deploy iso is shared across many nodes, I think the operator should be required to create it | 16:04 |
dtantsur | Nisha, not sure, but maybe you can handle --create_ports and --discover separately... | 16:04 |
Nisha | dtantsur: , but its a general proposal and we are implementing through iLO driver | 16:05 |
Nisha | dtantsur: i didnt get , how do we handle them seperately | 16:05 |
Nisha | dtantsur: manually doing all these tasks are already there | 16:05 |
Nisha | dtantsur: the proposal is to automate them | 16:05 |
dtantsur | Nisha, ah, yeah, general proposal should be separate, because it's something that affects the whole Ironic, may require reviews from people from other subteams etc | 16:05 |
devananda | rameshg87: ironic does not, today, build images and upload them to glance, change nova or glance image properties, and so on. This seems like a change in scope, not just adding a new driver | 16:05 |
rameshg87 | devananda, we were just thinking of avoiding an extra step for the operator. (to obtain parity with what is required for other drivers) | 16:06 |
devananda | rameshg87: I had thought the iLO driver was going to stash objects in swift for a short time (eg, during a deploy) then delete them | 16:06 |
*** martyntaylor has joined #openstack-ironic | 16:06 | |
dtantsur | Nisha, your introduction reads as a general means of handling this situation, but than you follow with ILO-specific part | 16:06 |
rameshg87 | devananda, do you feel the iso should be created by the operator himself ? | 16:06 |
devananda | rameshg87: requiring the operator to build an ISO image, which is used by all nodes in their environment that use the iLO driver, seems fine to me | 16:06 |
rameshg87 | devananda, okay | 16:07 |
Nisha | dtantsur: , the egneric stuff needs to be implemented by any driver | 16:07 |
jroll | Nisha, dtantsur, I agree that any driver-specific things should not be in that spec | 16:07 |
*** eguz has joined #openstack-ironic | 16:07 | |
devananda | rameshg87: it should be documented. eg, "if using the iLO driver, do $this and configure $that" | 16:07 |
devananda | rameshg87: but that seems fine to me | 16:07 |
dtantsur | Nisha, IPA folks will want to review the generic part, as it may be closely related to their work, but they barely want to get deep into iLO details: they have their own | 16:07 |
*** petertoft1 has joined #openstack-ironic | 16:08 | |
jroll | Nisha, dtantsur, that spec should define the api and scope for discovery, not any implementations | 16:08 |
dtantsur | +1 | 16:08 |
rameshg87 | devananda, the ilo driver will upload the floppy images to swift with auto-expiring feature | 16:08 |
Nisha | dtantsur: jroll , but ilo stuff is how it is implemented in ilo driver. rest is generic | 16:08 |
devananda | rameshg87: for passing tokens to the node -- yes, that's fine :) | 16:08 |
devananda | rameshg87: the IPA driver is doing something very similar | 16:08 |
rameshg87 | devananda, the floppy image will have the parameters for the deploy and the token | 16:08 |
*** romcheg has quit IRC | 16:09 | |
dtantsur | Nisha, yes, and I don't see any compelling reason for them to be mixed. Or otherwise also add sections for _all_ drivers (which you surely don;t want to do :) | 16:09 |
jroll | Nisha: indeed, and that should be a separate spec (if it should even be a spec at all) | 16:09 |
Nisha | jroll, dtantsur last week when the spec was reviewed by devananda, devananda proposed to add the details how the changes will be implemented in the spec | 16:09 |
rameshg87 | devananda, if we mandate operator himself to build isos, then the operator will need to build the deploy iso (shared across nodes) and boot iso(one per image) | 16:09 |
dtantsur | Nisha, quoting devananda: So, if this is a specific feature of the iLO driver, please update the title and introductory paragraph to indicate that. On the other hand, if it's a generic feature (which I think is your intent) then it should discuss how other drivers will implement the same feature. | 16:10 |
Nisha | jroll: dtantsur , i added implementation specific details only in latest patch | 16:10 |
*** romcheg has joined #openstack-ironic | 16:10 | |
*** petertoft has quit IRC | 16:10 | |
rameshg87 | devananda, we were just thinking of simplifying this step for the operator. do you feel it's okay to leave the operator to do so ? | 16:10 |
jroll | Nisha: I'd bet good money he meant how will the changes be implemented at the generic level :) | 16:10 |
jroll | or what dtantsur said :p | 16:11 |
dtantsur | Nisha, as 1st is not the case and you barely want to do the second, I suggest one more option: have 1 spec talking about this feature in general and the second only for iLO-specific things | 16:11 |
*** eghobo has quit IRC | 16:11 | |
devananda | rameshg87: I believe the operator should build the shared image (whether that is deploy kernel & ramdisk for PXE driver, or deploy iso for ILO driver) | 16:11 |
devananda | rameshg87: and the operator should set the appropriate nova and/or glance metadata | 16:12 |
rameshg87 | devananda, what about boot kernel/ramdisk ? | 16:12 |
rameshg87 | devananda, we would need a boot_iso from boot kernel/ramdisk, and then use that to boot up the node | 16:12 |
*** Mikhail_D_ltp has quit IRC | 16:12 | |
devananda | rameshg87: same for boot kernel/ramdisk -- this is also a common object which requires setting glance metadata. | 16:12 |
*** matty_dubs is now known as matty_dubs|lunch | 16:12 | |
rameshg87 | devananda, yes | 16:13 |
rameshg87 | devananda, okay | 16:13 |
jroll | dtantsur: so a more meta question, shpuld we require specs for "implement some existing generic feature in $driver"? /cc devananda | 16:13 |
devananda | jroll: yes | 16:13 |
rameshg87 | devananda, one more thing to catch attention is how the node is booted up. | 16:13 |
jroll | ok :) | 16:13 |
Nisha | dtantsur: jroll , quoting IRC chat comments from deva on 19th June: "<devananda> wanyen: so i'm thinking of the REST API -- and the CLI as an extension of that. how does "--discover" look to the REST API ?" | 16:13 |
rameshg87 | devananda, after deployment, we need to attach the boot_iso everytime to boot up the node | 16:14 |
jroll | Nisha: yes, that has nothing to do with ilo | 16:14 |
rameshg87 | devananda, when the power driver of ilo recieves a request to reboot a deployed node, it would first attach the boot iso to the ilo and then boot the node. | 16:14 |
* jroll still does not quite understand why we don't write boot partitions and boot from disk :/ | 16:15 | |
rameshg87 | devananda, the boot iso will be attached as virtual media in such a way that it gets removed after that boot | 16:15 |
rameshg87 | devananda, i would like to know your thoughts on that | 16:15 |
rameshg87 | devananda, we felt it had an advantage that the baremetal node can never come up without being managed by ironic conductor | 16:16 |
devananda | rameshg87: that will need to be optional, eventually | 16:17 |
devananda | rameshg87: some operators want to enable boot-from-local-disk while otheres do not | 16:17 |
rameshg87 | devananda, this is only for fs-images | 16:17 |
Nisha | dtantsur: jroll it may not be possible to paste complete chat from that day chat, but initially spec just said that /v1/nodes/post and /v1/nodes/patch , then devananda asked to update the spec how they will be modified | 16:17 |
rameshg87 | devananda, if the user deploy a disk image, it can boot up from the node | 16:17 |
*** ellenh has joined #openstack-ironic | 16:17 | |
devananda | jroll: we should. and we should not. i have the start of a spec for that. want to take it over? I'd love that feature :) | 16:17 |
jroll | devananda: I was waiting for you to finish it :p | 16:18 |
dtantsur | Nisha, I don't understand your point at all, sorry. I don't know why you're talking about some API's, while what we ask you is to split generic and non-generic parts | 16:18 |
rameshg87 | devananda, we wanted to put forward the solution this way. if the operator wants that "bm nodes never come up without conductor's knowledge, then use fs images" | 16:19 |
devananda | rameshg87: that's fine | 16:19 |
dtantsur | devananda, could you provide your opinion on this spec discussion? | 16:20 |
rameshg87 | devananda, thanks | 16:20 |
devananda | dtantsur: link? sorry, too many thinsg already open ... | 16:20 |
dtantsur | devananda, https://review.openstack.org/#/c/100951/7 I insist we split it into generic spec and iLO-specific one, jroll seems to agree | 16:20 |
rameshg87 | devananda, just one more thing, please have a look at ilo power driver when you get time: https://review.openstack.org/#/c/97455/ (already got one +2) | 16:21 |
lucasagomes | lifeless, the problem with mrda-away patch is that it sets the power_state w/o validating the credentials | 16:21 |
lucasagomes | lifeless, so if the credentials are not correct, and the power_state != None, after awhile the node is put in maintenance mode | 16:22 |
* NobodyCam is back | 16:22 | |
rameshg87 | lucasagomes, i would request you also to take a look at ilo power driver since you reviewed code a while back https://review.openstack.org/#/c/97455/ | 16:22 |
lucasagomes | lifeless, I think that's not desirable ^ and we would need to work that out. NobodyCam's patch at least doesn't have that problem | 16:23 |
rameshg87 | lucasagomes, this is spec btw | 16:23 |
lucasagomes | rameshg87, sure will do... interesting that other virtual media spec | 16:23 |
devananda | rameshg87: have you considered how a node will be restarted without doing a full deploy? | 16:23 |
rameshg87 | devananda, i guess i didn't get the question | 16:25 |
devananda | rameshg87: oh, never mind. it's further towards the end of the spec | 16:25 |
rameshg87 | devananda, okay :-) | 16:26 |
dtantsur | learning czech time, brb | 16:28 |
Nisha | devananda: Do you think the spec to be splitted into two? I have just proposed that the feature be implemented by ilo driver its not specific to ilo driver | 16:32 |
Nisha | https://review.openstack.org/#/c/100951/7 | 16:32 |
lucasagomes | devananda, https://review.openstack.org/#/c/96136/ was rebased on trunk already, so you might want to remove the -1 (if that's the only reason for the -1) | 16:32 |
devananda | Nisha: yes, this needs two specs. one describing the new REST and RPC and driver APIs, what the control flow looks like, etc. and another for iLO's implementation. | 16:34 |
Nisha | dtantsur: devananda jroll : Thanks will split it and post another patch | 16:34 |
devananda | Nisha: it looks like this is adding several features, not one | 16:34 |
Nisha | means? | 16:35 |
jroll | Nisha: thabk you! | 16:35 |
Nisha | devananda: could you explain further more on your comment | 16:35 |
*** amitpp has joined #openstack-ironic | 16:36 | |
Nisha | jroll: no probs | 16:37 |
*** martyntaylor has left #openstack-ironic | 16:37 | |
Nisha | devananda: apart from node properties discovery and automatic port create at node-create/node-update do you see any other feature is included here? | 16:39 |
devananda | Nisha: I'm not yet convinced that --create-ports should be part of this. seems like a separate feature. | 16:39 |
devananda | Nisha: also, you did not add what I asked for last time | 16:39 |
devananda | Nisha: which is a description of this work item: REST API node-create and node-update changes. | 16:39 |
*** eghobo has joined #openstack-ironic | 16:40 | |
devananda | Nisha: line 284 says "REST APIs .. need to be modified to have a new option" but doesn't show /how/ they will be modified | 16:40 |
Nisha | devananda:I think you mean when node-create and node-update is patched ? | 16:40 |
devananda | Nisha: yes | 16:41 |
*** lazy_prince2 has joined #openstack-ironic | 16:41 | |
devananda | Nisha: what REST API changes will be made to POST and PATCH such that the ironic-api service knows that --discover or --create-ports were specified on the CLI? | 16:42 |
*** eguz has quit IRC | 16:42 | |
devananda | Nisha: this is not explained in your spec | 16:42 |
Nisha | devananda: please see line 296 onwards, it proposes the algo followed in node-create (this is when its not patched). I will add the description/details for patched approach. | 16:43 |
devananda | Nisha: this is not what i'm asking for | 16:43 |
devananda | Nisha: if I were to send a raw HTTP query string to ironic-api to initiate discovery, what would that HTTP query look like? | 16:44 |
devananda | Nisha: what is the new parameter which triggers discovery? | 16:44 |
Nisha | devananda: i think u mean the path ? | 16:45 |
devananda | Nisha: path or resource or parameter -- yes | 16:45 |
Nisha | devananda: do u mean this way: "PUT /v1/nodes/68228b2d-fc97-4fc3-b31f-e1616777af8d/management HTTP/1.1" 200 63 | 16:45 |
devananda | Nisha: so, that is the URL for that node's management resource. a PUT to that URL must have some body, and that body is a structured JSON document | 16:46 |
devananda | Nisha: your proposal to modify "POST /v1/nodes" does not specify how you intend to change the POST body | 16:47 |
devananda | or if you intend to introduce a new resource URL, or what you intend to do | 16:47 |
Nisha | devananda: triggering discovery is based on the argument passed to --discover option, that will be in CLI. CLI will decide whether to invoke the REST API or not for hw discovery | 16:47 |
lucasagomes | Nisha, I think that what devananda is saying is that... all that the CLI does is send HTTP requests to the API... so you will need a flag in the REST API to tell Ironic to do the discovery for u | 16:48 |
lucasagomes | e.g | 16:48 |
lucasagomes | POST /nodes/?discover=true | 16:49 |
lucasagomes | something like that | 16:49 |
devananda | yes :) | 16:49 |
devananda | though I was trying not to suggest a specific implementation | 16:49 |
Nisha | lucasagomes: devananda Ok i got the point but I intended to do automatic hw discovery while doing node-create, and add the option --discover only for node-update if user wants to rediscover properties at node-update | 16:51 |
devananda | Nisha: so the same question would apply to "node-update --discover" | 16:51 |
Nisha | devananda: lucasagomes in that case node-create will not have any option of "--discover", it will rather do automatically | 16:51 |
devananda | Nisha: also, it sounds like you are suggesting that node-create will ALWAYS do automatic hw discovery | 16:52 |
lucasagomes | Nisha, right, so there will be like a config option that Ironic will look at to know if it should discover things automatically or not | 16:52 |
Nisha | devananda: Yes, i will update for node-update | 16:52 |
* lucasagomes I need to read the spec... | 16:52 | |
Nisha | devananda: lucasagomes Yes the proposal is that | 16:53 |
Nisha | devananda: for node-create | 16:53 |
*** klindgren has quit IRC | 16:53 | |
devananda | Nisha: which is not stated clearly in your specification | 16:53 |
lucasagomes | ack | 16:53 |
lucasagomes | it kinda looks like something that could be put on the ManagementInterface for the update part | 16:53 |
lucasagomes | like a trigger that would return 202 and do the job on the background to find out the physical characterists of that node | 16:54 |
* lucasagomes might be going to far | 16:54 | |
Nisha | lucasagomes Yes the proposal is under ManagementInterface | 16:54 |
lucasagomes | hah ok I will read the spec | 16:54 |
lucasagomes | sorry | 16:54 |
* lucasagomes RTFS :) | 16:54 | |
rameshg87 | JoshNang, are you there ? | 16:54 |
Nisha | devananda: Ok i will update the spec with that :) | 16:55 |
JoshNang | rameshg87: i am, but i have to run in about 3 mins | 16:55 |
JoshNang | but i'll be back in an hour. what's up? | 16:55 |
rameshg87 | JoshNang, just had a couple of question regarding direct url. in short, it is not working for me :-( | 16:55 |
*** lucasagomes is now known as lucas-afk | 16:55 | |
rameshg87 | JoshNang, i would like to use the same code in ilo deploy, i am trying to make it work for me as well. | 16:56 |
rameshg87 | JoshNang, but due to some reason it is not working :-( | 16:57 |
JoshNang | rameshg87: i saw that. we've had some issues with direct url in our deployment and wound up going with config settings to override the host part | 16:57 |
rameshg87 | JoshNang, ah okay. i have a problem similar to that | 16:57 |
JoshNang | i have tested it and it works, but we had some security concerns with the username and password possibly getting exposed | 16:57 |
JoshNang | (works in at least one config. apparently not all) | 16:57 |
rameshg87 | JoshNang, giving only the secret key doesn't generate url which can be retrieved over http for me. i am on devstack | 16:58 |
JoshNang | rameshg87: is it possible to private gist me the config file (with passwords etc removed?) for glance? | 16:58 |
rameshg87 | JoshNang, which config file do you need ? ironic.conf ? | 16:58 |
*** lazy_prince has joined #openstack-ironic | 16:58 | |
JoshNang | glance.conf (or is glance-api.conf?). but i gotta run. i'll be back in an hour | 16:58 |
JoshNang | ironic.conmf wouldn't hurt either | 16:59 |
*** Mikhail_D_ltp has joined #openstack-ironic | 16:59 | |
rameshg87 | JoshNang, np. i will ping you back. i should be around when you are back | 16:59 |
rameshg87 | JoshNang, please ping me if possible when you are back and you are free. | 16:59 |
Nisha | devananda: DO you still think create-ports be another feature for this spec? | 17:00 |
devananda | Nisha: possibly... | 17:00 |
devananda | i am going to post comments soon | 17:00 |
Nisha | devananda: but we want to create ports at the time hw discovery | 17:01 |
*** lazy_prince has quit IRC | 17:03 | |
*** killer_prince has joined #openstack-ironic | 17:07 | |
*** Penick has joined #openstack-ironic | 17:07 | |
*** killer_prince is now known as lazy_prince | 17:07 | |
*** lazy_prince has quit IRC | 17:08 | |
*** harlowja_away is now known as harlowja | 17:08 | |
devananda | Nisha: dtantsur: many comments posted on https://review.openstack.org/#/c/100951/ | 17:10 |
*** wanyen has joined #openstack-ironic | 17:13 | |
Nisha | devananda: Thanks for the review | 17:14 |
*** romcheg has quit IRC | 17:15 | |
rameshg87 | devananda, request some time for this review as well, https://review.openstack.org/#/c/97455/ . a simple review compared to deploy one btw .. :-) | 17:16 |
*** romcheg has joined #openstack-ironic | 17:16 | |
*** klindgren has joined #openstack-ironic | 17:16 | |
devananda | rameshg87: almost done with deploy driver review, fwiw | 17:17 |
*** hemna_ is now known as hemna | 17:17 | |
*** killer_prince has joined #openstack-ironic | 17:17 | |
*** eghobo has quit IRC | 17:17 | |
rameshg87 | devananda, thanks :-) | 17:18 |
*** amitpp has quit IRC | 17:19 | |
NobodyCam | brb | 17:19 |
*** amitpp has joined #openstack-ironic | 17:19 | |
*** eghobo has joined #openstack-ironic | 17:24 | |
*** romcheg has quit IRC | 17:31 | |
*** killer_prince has quit IRC | 17:34 | |
*** sam__ has joined #openstack-ironic | 17:36 | |
*** killer_prince has joined #openstack-ironic | 17:37 | |
*** Penick has quit IRC | 17:37 | |
*** Penick has joined #openstack-ironic | 17:41 | |
*** killer_prince has quit IRC | 17:43 | |
rameshg87 | devananda, just had one question on your comment. rest all 11 comments are fine with me. | 17:45 |
rameshg87 | devananda, regarding "That said, I think there is a cleaner solution for the boot_iso. Build it and cache it locally on the conductor." | 17:46 |
*** killer_prince has joined #openstack-ironic | 17:46 | |
*** pelix has quit IRC | 17:46 | |
rameshg87 | devananda, we would need the boot iso to be in glance to be able to attach as the virtual media. we generate the temp-url for the glance image and then attach it as virtual media cdrom | 17:47 |
*** ellenh has quit IRC | 17:47 | |
devananda | rameshg87: ooh. gotcha | 17:47 |
rameshg87 | devananda, if we cache it locally on the conductor alone, we won't be able to attach it as virtual media (unless we run a web server on the ironic conductor node which we preferably wanted to avoid) | 17:48 |
devananda | rameshg87: ok. please disregard that comment then. | 17:48 |
rameshg87 | devananda, then we might need the operator to build the boot iso from boot kernel and boot ramdisk as well (just like they build deploy iso from deploy kernel and deploy ramdisk) | 17:48 |
*** ellenh has joined #openstack-ironic | 17:48 | |
devananda | rameshg87: yep | 17:49 |
devananda | rameshg87: have you proposed to diskimage-builder that it create iso images? | 17:49 |
rameshg87 | devananda, no i haven't. | 17:49 |
devananda | rameshg87: that seems like the natural solution to me. It already has this utility: https://github.com/openstack/diskimage-builder/blob/master/bin/disk-image-get-kernel | 17:50 |
rameshg87 | devananda, it just need to be a small shell script iso-image-create which can create iso images given a kernel/ramdisk pair | 17:50 |
devananda | rameshg87: exactly | 17:50 |
devananda | rameshg87: and for tripleo, it would be easy to add a flag whcih says, "when using the iLO driver, call disk-image-make-iso instead" -- or smoething like that | 17:50 |
rameshg87 | devananda, okay. i would do that. do we need a design spec or just a launch bug is sufficient ? just asking because the shell script would be small | 17:51 |
devananda | lifeless: how does ^ sound to you? | 17:51 |
*** jdob has quit IRC | 17:51 | |
*** jdob has joined #openstack-ironic | 17:51 | |
*** lazy_prince2 has quit IRC | 17:52 | |
lifeless | devananda: not sure how far back I need to read | 17:54 |
lifeless | rameshg87: why is it a temp url ? | 17:54 |
devananda | lifeless: tldr; instead of disk-image-get-kernel, have another utility which wraps it up in an ISO image | 17:54 |
lifeless | disk-image-get-kernel is deprecated in favour of spitting out the files at build time | 17:54 |
devananda | lifeless: so that things like iLO can mount dib output over virtual media | 17:54 |
lifeless | spitting out an iso seems like a reasonable variation on the ramdisk thing | 17:55 |
devananda | need a spec for that? or just a patch to add it? | 17:55 |
rameshg87 | lifeless, instead of asking operators run a webserver, we have them in swift and generate a tmp url which can be accessed over http/htps | 17:55 |
lifeless | rameshg87: you answered a different question | 17:56 |
lifeless | rameshg87: I asked why a temp url | 17:57 |
lifeless | rameshg87: not why the use of swift | 17:57 |
*** martyntaylor has joined #openstack-ironic | 17:57 | |
rameshg87 | lifeless, the tempurl generated will be attached as virtual media on the ilo | 17:57 |
lifeless | again, different question | 17:58 |
devananda | lifeless: i think your question may be to something out of context | 17:58 |
lifeless | why a temp url. | 17:58 |
lifeless | why a /temp/ url | 17:58 |
devananda | lifeless: the tempurl is only for the instance-specific token | 17:58 |
devananda | which is only needed during deploy | 17:58 |
devananda | lifeless: and has nothing to do with DIB :) | 17:58 |
lifeless | I understood it to be for the virtual media ISO | 17:58 |
devananda | no | 17:58 |
devananda | taht should be in glance | 17:58 |
*** matty_dubs|lunch is now known as matty_dubs | 17:58 | |
devananda | lifeless: you didn't read back far enough ;) | 17:59 |
rameshg87 | lifeless, ah was the question "why the url is temp ?" | 17:59 |
lifeless | devananda: "05:47 < rameshg87> devananda, we would need the boot iso to be in glance to be able to attach as the virtual | 17:59 |
lifeless | media. we generate the temp-url for the glance image and then attach it as virtual media | 17:59 |
lifeless | cdrom | 17:59 |
lifeless | " | 17:59 |
lifeless | rameshg87: yes! | 17:59 |
*** petertoft1 has quit IRC | 17:59 | |
rameshg87 | lifeless, the url needs to be accessible for only for a few mins for the proliant server to boot | 18:00 |
*** harlowja has quit IRC | 18:00 | |
devananda | lifeless: ah. I mis-parsed that. thanks! | 18:00 |
devananda | rameshg87: the boot ISO will be shared by any node booting that glance image. it should be in glance. | 18:00 |
rameshg87 | devananda, yes, the boot iso will be shared. | 18:00 |
lifeless | rameshg87: but why not just get the permanent url, why a temp one? Seems like pointless overhead | 18:01 |
rameshg87 | lifeless, we are using a feature of swift which generates http urls valid only for a certain amount of time | 18:01 |
lifeless | rameshg87: do we need to use that feature? | 18:02 |
rameshg87 | lifeless, yes | 18:02 |
lifeless | rameshg87: I have to pop into a meeting, sorry | 18:03 |
rameshg87 | lifeless, i request if you take a look at this spec when you get time: https://review.openstack.org/#/c/97744/2/specs/ironic-ilo-virtualmedia-driver.rst | 18:04 |
devananda | jroll: you may want to review https://review.openstack.org/#/c/97736/2/specs/juno/deploy-ironic-bm.rst -- it seems like it is duplicating some IPA functionality | 18:04 |
devananda | jroll: or perhaps implementing a very small subset in ways that could be better shared? I dunno... | 18:06 |
devananda | rameshg87: regarding using the iLO virtual media channel to load a secure token, please think about how this can be used by other drivers besides iLO | 18:07 |
devananda | rameshg87: i dont see any coverage for this in your specs yet, and I believe it is important | 18:07 |
rameshg87 | devananda, sure. i will explore more in this. | 18:08 |
devananda | rameshg87: the APIs should be distinct engouh so that other drivers can use OOB virtual-media channels to load secure keys with other deploy drivers, eg IPA | 18:08 |
rameshg87 | devananda, isn't that a future refactor that you are meaning ? | 18:09 |
rameshg87 | devananda, currently the loading of keys is part of ilo deploy driver itself | 18:10 |
rameshg87 | devananda, i mean in the current proposed spec | 18:10 |
devananda | rameshg87: right. but what if I want to use the iLO power and iLO management interfaces with the IPA deploy interface? | 18:10 |
rameshg87 | devananda, yes, i see your point. first, the ilo code should be easy enough to be modified and made to work with ipa deploy interface | 18:11 |
jroll | devananda: sounds like IPA implemented in bash :| | 18:12 |
rameshg87 | devananda, did i get it right ? | 18:12 |
jroll | devananda: This type of change is already proposed in the IPA, but IPA will not be using diskimage-builder to build the images. | 18:12 |
jroll | devananda: uhhhhhh | 18:12 |
jroll | lifeless: one benefit of temp urls that rameshg87 may be betting on, is that they are unauthenticated (so you don't have to give iLO any creds) | 18:13 |
devananda | jroll: comments just posted on there, fwiw | 18:13 |
jroll | yeah, doing the same now | 18:13 |
*** jcoufal has joined #openstack-ironic | 18:14 | |
devananda | rameshg87: correct. you don't need to implement that, but I would appreciate if the proposal describes how that functionality (loading keys via virtual media) could be used with other drivers. | 18:15 |
rameshg87 | devananda, okay. i will do that. | 18:16 |
*** killer_prince has quit IRC | 18:17 | |
*** romcheg has joined #openstack-ironic | 18:17 | |
rameshg87 | jroll, we knew that ipa has a similar proposed functionality, but then the diskimage-builder changes were small enough if we can make it. we wanted to integrate with ipa as well, when it is ready. | 18:17 |
jroll | rameshg87: I don't see what the difference is, really | 18:18 |
jroll | rameshg87: other than using bash instead of python, no REST API, etc | 18:18 |
*** killer_prince has joined #openstack-ironic | 18:18 | |
rameshg87 | jroll, the current proposed diskimage-builder element is just a parity of what ironic conductor is doing | 18:18 |
jroll | rameshg87: IPA *is* ready. we have it running in production. patches just aren't great and so haven't landed | 18:19 |
*** killer_prince has quit IRC | 18:19 | |
jroll | rameshg87: I see. I still don't see the point. :/ | 18:19 |
*** killer_prince has joined #openstack-ironic | 18:19 | |
jroll | rameshg87: all it takes to run IPA today is to apply some in-flight patches to ironic | 18:19 |
*** athomas has quit IRC | 18:20 | |
rameshg87 | jroll, will it get merged to ironic soon ? | 18:20 |
jroll | rameshg87: ask cores :P more seriously, though, we're refactoring the patches to make them more easily landable, and my goal is to land deploy/tear_down functionality by J2 | 18:21 |
*** romcheg has quit IRC | 18:21 | |
rameshg87 | devananda, jroll, do you feel it's better for the ilo driver to use ipa instead of the new proposed element in dib ? | 18:27 |
jroll | rameshg87: the ilo driver should be able to use the pxe deploy driver *and* the agent driver | 18:28 |
NobodyCam | brb | 18:28 |
rameshg87 | jroll, the difference that we are trying to bring in is to be able to avoid pxe | 18:28 |
jroll | rameshg87: that said, yes, I think there's no reason to make the new proposed element, especially if the goal is only to use it with the iLO driver. | 18:29 |
jroll | rameshg87: to avoid PXE booting or the PXE driver? | 18:29 |
rameshg87 | jroll, to avoid pxe booting | 18:29 |
jroll | um | 18:29 |
jroll | how do you plan to avoid pxe booting with either driver? mount the deploy ramdisk as virtual media? | 18:30 |
jroll | I don't see why that's a problem with either driver | 18:30 |
rameshg87 | jroll, create a bootable iso with kernel/ramdisk and then attach it as virtual media and then boot up the machine | 18:30 |
rameshg87 | jroll, i assume we can boot up the ipa kernel/ramdisk as well ... | 18:31 |
jroll | rameshg87: right, ok. I don't see why you need a new DIB to do that | 18:31 |
jroll | indeed | 18:31 |
*** romcheg has joined #openstack-ironic | 18:32 | |
*** max_lobur has quit IRC | 18:33 | |
JoshNang | rameshg87: back if you still have questions | 18:33 |
rameshg87 | JoshNang, i was into another discussion, will get back in a few mins ... | 18:34 |
devananda | rameshg87: I think you should add a new ability to DIB to create the ISO images, but I dont think you need a separate element for the iLO driver | 18:34 |
JoshNang | np | 18:34 |
rameshg87 | devananda, so just use ilo driver to boot up the ipa ? | 18:34 |
rameshg87 | devananda, instead of dib build deploy kernel/ramdisk ? | 18:35 |
rameshg87 | devananda, we had that in the plan, but we didn't know if ipa was ready yet for that | 18:35 |
jroll | rameshg87: what does IPA need to do to be ready for that? | 18:35 |
devananda | rameshg87: i think that is going to be easier than duplicating all those features yourself in a bash script | 18:35 |
jroll | ^ | 18:35 |
*** eghobo has quit IRC | 18:35 | |
devananda | actually | 18:36 |
*** killer_prince has quit IRC | 18:36 | |
devananda | jroll: just to be devil's advocate for a moment | 18:36 |
jroll | oh god | 18:37 |
jroll | :) | 18:37 |
*** Penick has quit IRC | 18:37 | |
*** bandicot has joined #openstack-ironic | 18:37 | |
devananda | IFF the only thing this ramdisk needs to do is: fetch image from $URL, partition disk based on $PARAMS, write image to disk, POST to $URL using $TOKEN | 18:38 |
devananda | it would be quite a lot smaller and simpler than IPA | 18:38 |
*** harlowja has joined #openstack-ironic | 18:38 | |
*** harlowja has quit IRC | 18:38 | |
jroll | sure, I have no problem with a ramdisk that does that | 18:38 |
*** eghobo has joined #openstack-ironic | 18:38 | |
*** killer_prince has joined #openstack-ironic | 18:38 | |
devananda | there's no interaction or flow control | 18:39 |
*** harlowja has joined #openstack-ironic | 18:39 | |
*** harlowja has quit IRC | 18:39 | |
jroll | but in that case, this spec should be titled: "add option for s/iscsi/curl/ in pxe driver" | 18:39 |
*** Penick has joined #openstack-ironic | 18:39 | |
jroll | right? | 18:39 |
devananda | yep | 18:39 |
devananda | "enable current ramdisk to fetch image from $URL" | 18:39 |
jroll | yeah, I have no problem with a ramdisk like this, for use with the pxe driver | 18:39 |
devananda | or something | 18:39 |
jroll | but I have many problems with the current version of the spec | 18:39 |
devananda | *nod* | 18:40 |
rameshg87 | jroll, why only pxe driver ? :-) | 18:40 |
* devananda steps away to prep for the meeting in ~20m | 18:40 | |
jroll | rameshg87: what other driver would use this? | 18:40 |
devananda | rameshg87: the same image could be used with iLO or PXE -- that is only the delivery mechanism. | 18:40 |
Shrews | devstack is being a major PITA today with the latest ironic :( | 18:41 |
* Shrews sets RECLONE=true | 18:41 | |
jroll | rameshg87: (maybe I missed the fact that there will be an iLO deploy driver, I thought iLO was only a management/power interface) | 18:41 |
jroll | JoshNang: maybe I missed something, but in the agent tests, 'driver': 'fake_pxe', etc, should be 'fake_agent', no? | 18:42 |
rameshg87 | jroll, yes, with ilo and pxe | 18:42 |
JoshNang | jroll: yes | 18:42 |
jroll | rameshg87: is ilo going to have a deploy interface as well? | 18:43 |
rameshg87 | jroll, yes it is. | 18:43 |
jroll | ok | 18:43 |
rameshg87 | jroll, instead of using pxe for booting up the machine, ilo will use virtual media to boot up the node | 18:43 |
jroll | right | 18:43 |
rameshg87 | jroll, 1 - we try to avoid pxe boot for customers who don't prefer pxe, 2 - it uses oob channel to get the token to the bm node | 18:44 |
jroll | rameshg87: sounds good, then, but this spec should be to improve the existing ironic DIB element, not for a new one (I think) | 18:44 |
rameshg87 | jroll, yeah, i mentioned that in the alternative as well. | 18:45 |
*** eghobo has quit IRC | 18:45 | |
jroll | right, I think it's a totally valid alternative :) | 18:45 |
*** eghobo has joined #openstack-ironic | 18:45 | |
* jroll walks away until meeting time | 18:45 | |
rameshg87 | jroll, the existing element deploy-ironic can be modified to do download the image and write it instead of exposing the disk over iscsi | 18:46 |
rameshg87 | jroll, just to confirm if we are on the same page :-) | 18:46 |
jroll | rameshg87: yes :) | 18:46 |
rameshg87 | jroll, point taken. please add that as comment if you wish. | 18:47 |
rameshg87 | devananda, does adding the functionality proposed in new element into the existing element deploy-ironic makes sense to you as well ? | 18:48 |
rameshg87 | devananda, did i make a confusing statement ? i mean does adding that functionality into existing element make sense to you ? | 18:48 |
devananda | rameshg87: adding it to existing element in a way that is compatible with the current PXE driver -- yes. I think that would be ideal | 18:49 |
rameshg87 | devananda, that would mean the element deploy-ironic would support 2 modes of installation - 1. expose current disk over iscsi and ask conductor to complete installation | 18:50 |
rameshg87 | 2. download the image by temp url and do deployment on its own | 18:50 |
rameshg87 | devananda, we would be able to invoke the required functionality by passing required arguments. | 18:51 |
*** harlowja has joined #openstack-ironic | 18:51 | |
*** harlowja has quit IRC | 18:51 | |
rameshg87 | devananda, pxe driver will continue to use the iscsi mode of installation (unless someone feels it needs to be changed) | 18:52 |
rameshg87 | devananda, ilo driver will start using the mode tempurl #2 mechanism of installation | 18:52 |
rameshg87 | devananda, does that make sense ? | 18:52 |
*** harlowja has joined #openstack-ironic | 18:52 | |
*** harlowja has quit IRC | 18:52 | |
devananda | rameshg87: sounds good so far | 18:53 |
*** harlowja has joined #openstack-ironic | 18:53 | |
*** hello has joined #openstack-ironic | 18:53 | |
rameshg87 | devananda, thanks..i would revise the spec based on our chat and then initiate review again. | 18:53 |
devananda | rameshg87: thanks! | 18:53 |
*** dwalleck has joined #openstack-ironic | 18:54 | |
*** sysexit has quit IRC | 18:55 | |
*** Abhishe__ has joined #openstack-ironic | 18:56 | |
*** Abhishe__ has joined #openstack-ironic | 18:56 | |
*** mrda-away is now known as mrda | 18:56 | |
mrda | Morning Ironic! | 18:57 |
*** lucas-afk is now known as lucasagomes | 18:57 | |
dtantsur | morning, mrda! :) | 18:57 |
NobodyCam | DKMS is unstable in opensuse :-p | 18:58 |
NobodyCam | morning mrda | 18:58 |
dtantsur | nearly meeting time! | 18:59 |
mrda | NobodyCam and dtantsur: hi | 18:59 |
romcheg | Morning again mrda :) | 19:00 |
devananda | meeting time! | 19:00 |
devananda | morning, mrda | 19:00 |
mrda | romcheg and devananda: o/ | 19:01 |
*** ellenh has quit IRC | 19:02 | |
*** Abhishe__ is now known as achanda | 19:06 | |
*** wanyen has quit IRC | 19:06 | |
*** devananda has quit IRC | 19:10 | |
*** coolsvap is now known as coolsvap|afk | 19:16 | |
*** hello has quit IRC | 19:16 | |
*** devananda has joined #openstack-ironic | 19:18 | |
*** devananda is now known as devananda_ | 19:18 | |
*** devananda_ is now known as devananda | 19:18 | |
*** Nisha has quit IRC | 19:20 | |
*** achanda has quit IRC | 19:22 | |
*** rameshg87 has left #openstack-ironic | 19:27 | |
*** amitpp has quit IRC | 19:28 | |
*** devanand1 has joined #openstack-ironic | 19:28 | |
*** killer_prince has quit IRC | 19:30 | |
*** killer_prince has joined #openstack-ironic | 19:32 | |
*** achanda has joined #openstack-ironic | 19:36 | |
*** killer_prince has quit IRC | 19:37 | |
*** killer_prince has joined #openstack-ironic | 19:41 | |
*** sysexit has joined #openstack-ironic | 19:46 | |
openstackgerrit | Mathieu Gagné proposed a change to openstack/ironic: Add genconfig tox job for sample config file generation https://review.openstack.org/101614 | 19:49 |
*** foexle has quit IRC | 19:56 | |
NobodyCam | ahh back homw ... great meeting everyone | 20:01 |
lucasagomes | rloo, yes, if we do it, it's mb for everything | 20:01 |
NobodyCam | esp the tea reports TY all | 20:01 |
*** devananda has quit IRC | 20:01 | |
*** yuriyz has quit IRC | 20:01 | |
*** devanand1 is now known as devananda | 20:01 | |
lucasagomes | rloo, and the driver would convert it for us, root 1GB in nova == 1024 MB in Ironic | 20:01 |
NobodyCam | s/tea/team/ | 20:01 |
matty_dubs | But #2 would allow <1GB partitions too, wouldn't it? | 20:01 |
* devananda is back on his irc proxy now | 20:02 | |
lucasagomes | matty_dubs, yes | 20:02 |
Shrews | NobodyCam: i prefer tea reports. much more tasty | 20:02 |
NobodyCam | matty_dubs: we would have to do math then | 20:02 |
ifarkas | devananda, re: ceilometer integration. thanks for the link. I guess it's not a requirement for graduation, is that correct? | 20:02 |
dtantsur | matty_dubs, yeah, and some surprises like 1.999999999999 GiB :) | 20:02 |
lucasagomes | matty_dubs, by using floats, but ppl may argue that floats are not good to represent partition sizes | 20:02 |
devananda | matty_dubs: the concern with #2 is taht it allows sizes like ^ | 20:02 |
rloo | lucasagomes, did you get a chance to discuss with lifeless ? | 20:02 |
dtantsur | or what was this funny number? | 20:02 |
matty_dubs | I'm not sure I fully understand the controversy, but I don't see refusing to accept things less than full GBs as a feature. | 20:02 |
romcheg | devananda: So in Grenade test it should be possible to build images, upload them to glance and generate a csv | 20:02 |
NobodyCam | lucasagomes: 3.14..... | 20:02 |
lucasagomes | rloo, wanted to do it in the meeting, I left some questions in the review as well I think | 20:02 |
lucasagomes | rloo, but no dice | 20:02 |
devananda | ifarkas: for metering and billing -- that should be handled by nova already, AIUI | 20:03 |
lucasagomes | brazil match just started! | 20:03 |
devananda | ifarkas: for monitoring, ceilometer team did not agree wether they want to handle all the fan speed and temperature stats | 20:03 |
romcheg | lucasagomes: Oh, I will cheer for Brazil :) | 20:04 |
lucasagomes | romcheg, :D cheers | 20:04 |
devananda | ifarkas: I do believe that Ironic should support a pluggable way to emit notifications for hardware sensor data and events. and ceilometer would be one such receiver | 20:04 |
matty_dubs | That discussion seemed to bring up a fundamental disagreement within the ceilometer community, really | 20:04 |
devananda | matty_dubs: yep | 20:04 |
lucasagomes | ok so should I send it to the mailist? or we can vote on the unit sizes thing? | 20:04 |
romcheg | It's a trend in Ukraine this season to cheer anyone but Russia. I haven't chosen my favourite team yet :) | 20:04 |
rloo | lucasagomes, so, why even change it? to be consistent with units? | 20:05 |
lucasagomes | romcheg, hah brazil man :P | 20:05 |
NobodyCam | romcheg: lol I'll bet | 20:05 |
lucasagomes | tho we are not doing well in this cup | 20:05 |
NobodyCam | brb | 20:05 |
lucasagomes | rloo, for the sake of consistency | 20:05 |
lucasagomes | rloo, but I asked that too, do we want to have consistency or just leave it? | 20:05 |
ifarkas | devananda, yeah, it seems to be the right thing. is there a mailing list discussion, or there wasn't any between the two projects? | 20:05 |
devananda | ifarkas: there hasn't been one since the summit | 20:06 |
*** dwalleck has quit IRC | 20:06 | |
lucasagomes | I'm almost leaving it because I think I already implemented all the 3 options I gave there at some point in time :) | 20:06 |
romcheg | We need to set time limits for each topic for the meeting | 20:06 |
rloo | lucasagomes, it seems to me that this is something that can be done at a later date? | 20:06 |
devananda | lucasagomes: ugh! :( | 20:06 |
lucasagomes | rloo, yea | 20:06 |
lucasagomes | rloo, but if we are doing it's better now since it's affect the driver | 20:06 |
rloo | lucasagomes, because it doesn't seem clear which way to go. | 20:06 |
lucasagomes | rloo, so as sooner the better | 20:06 |
ifarkas | devananda, ok, thanks | 20:06 |
romcheg | Because we usually spend half of the meeting for one topic and then there's no time for the rest of the stuff | 20:06 |
devananda | lucasagomes: it's like metric vs. imperial units! | 20:07 |
rloo | lucasagomes, i think the 'right' way to do it is to support whatever X way in the future, but also support existing way for some period of time. | 20:07 |
lucasagomes | devananda, hah yeah!!!!!! | 20:07 |
rloo | oh, devananda has a grand idea. support both. but metric is clearly better ;) | 20:08 |
lucasagomes | rloo, :P | 20:08 |
devananda | romcheg: i am working on that. sometimes it's hard to tell how long a topic needs | 20:08 |
lucasagomes | rloo, right, hmm ok... I don't want to complicate things... it just that it kinda annoys me to see root_gb ephe_gb and swap_MB! | 20:08 |
lucasagomes | lol | 20:08 |
romcheg | devananda: That could be changed by a topic lead | 20:08 |
devananda | romcheg: if topics are urgent or require everyone, i generally try to bring them up early on | 20:08 |
Shrews | lucasagomes: i vote making the units configurable!!! :) | 20:09 |
devananda | romcheg: also, i lost 'net for the first ~20 minutes today ... which definitely slowed me down | 20:09 |
* Shrews hides from lucasagomes | 20:09 | |
lucasagomes | Shrews, hah hah oh god lol | 20:09 |
romcheg | What are imperial units for partition sizes? :) | 20:10 |
rloo | lucasagomes: Shrews vote basically means support root_gb, root_mb, ephemeral_gb, ephemeral_mb, swap_mb and swap_gb. I don't see why not. | 20:10 |
* devananda wants to measure everything in medival japanese units of Shaku and Koku | 20:10 | |
* rloo wonders if we should believe that devananda knows what he's talking about. He probably does though. | 20:10 | |
lucasagomes | rloo, unit configurable for me includes: B, KB, KiB, MB, MiB, GB, GiB... | 20:10 |
matty_dubs | Speaking of the metric system... http://en.wikipedia.org/wiki/Metrication#Chronology_and_status_of_conversion_by_country -- the US, Liberia, and Burma/Myanmar are effectively the only countries that have not adopted them. | 20:10 |
matty_dubs | ^ today's semi-off-topic trivia | 20:10 |
lifeless | rloo: discuss what wwith me? | 20:10 |
rloo | lucasagomes, ah, you're right. I think we should stick with 'i' only ;) | 20:11 |
devananda | koku = unit of rice | 20:11 |
devananda | shaku = roughly the length of an arm | 20:11 |
*** achanda has quit IRC | 20:11 | |
lucasagomes | devananda, lol | 20:11 |
dtantsur | it's a wonderful idea to measure partitions on rice and arms! | 20:11 |
romcheg | ++ for koku and shaku :D | 20:11 |
lucasagomes | cool, 15 arms for the root partition | 20:11 |
*** max_lobur has joined #openstack-ironic | 20:11 | |
rloo | lifeless, using GB vs MB for root/ephemeral/swap. | 20:12 |
devananda | oh, actually, shaku is derived as roughly the distance between two nodes on a bamboo pole | 20:12 |
romcheg | Guys, aren't you in a coffe shop in Amsterdam right now? :) | 20:12 |
matty_dubs | LOL romcheg | 20:12 |
lifeless | rloo: I would be fine with all-in-MB; seems wasteful, but 1000% better than floats. | 20:12 |
dtantsur | romcheg :D | 20:12 |
matty_dubs | So, I think I missed the background -- but is there any downside, other than it being change, to using MB everywhere? (Or allowing fractional GB?) | 20:13 |
lucasagomes | lifeless, aye! | 20:13 |
rloo | lifeless, and the reason against floats is cuz it won't always translate from eg GB to units of MB. | 20:13 |
mrda | so a better measure for network latency? devananda | 20:13 |
lifeless | rloo: aye | 20:13 |
lucasagomes | ok so MB then!? | 20:14 |
lifeless | rloo: also because its just the wrong tool for the job | 20:14 |
rloo | matty_dubs, so the downside to using MB is that the user may think in GB (or more accurately GiB). | 20:14 |
dtantsur | rloo, user may also think in shaku! And even worse - in koku! | 20:14 |
rloo | lifeless, yeah, you're probably right. I was willing to go with floats cuz I didn't think that 5 MB should be converted to 1 GB. | 20:14 |
romcheg | mrda: Arm/Season for network | 20:14 |
*** achanda has joined #openstack-ironic | 20:14 | |
lucasagomes | dtantsur, hah | 20:15 |
lucasagomes | so do we have a consensus here? | 20:15 |
rloo | so to be honest, I am now thinking that we should support GiB and MiB and let the user choose to be consistent or not. Our examples etc could use MiB if you like. Of course, we don't use 'MiB' now in anything. | 20:15 |
matty_dubs | rloo: Oh, hrm. You're probably right. But when I go to install a Linux distro, I'm usually asked to put in data in GB -- but with floats allowed. | 20:15 |
matty_dubs | Could we just do MiB in the code, and *1024 in the UI as an option? | 20:16 |
matty_dubs | Or, take the units? --size 4000M or --size 8G? | 20:16 |
lucasagomes | matty_dubs, sure, tuskar can do that | 20:16 |
rloo | one day, someone might want TiB... | 20:16 |
mrda | matty_dubs: I like this. | 20:16 |
matty_dubs | Well, until someone does --size 20 expecting 20MB/GB and gets 20 bytes ;) | 20:17 |
lucasagomes | GOAL!!! brazil 1x0 | 20:17 |
dtantsur | lucasagomes, lol | 20:18 |
devananda | mrda: traditional japanese hours were based on the length of the day. which naturally vary by season and latitude. that would make fascinating network latency measurements :) | 20:18 |
dtantsur | ok folks, I like this Monday evening with you in this channel, but I have to go :) | 20:19 |
dtantsur | g'night everyone | 20:19 |
devananda | dtantsur: g'night! | 20:19 |
lucasagomes | dtantsur, night! | 20:19 |
NobodyCam | night dtantsur | 20:19 |
lucasagomes | yeah I'm going as well (want to watch the match) | 20:19 |
*** dtantsur is now known as dtantsur|afk | 20:19 | |
NobodyCam | night lucasagomes | 20:19 |
rloo | night lucasagomes, dtantsur|afk | 20:20 |
*** lucasagomes is now known as lucas-dinner | 20:20 | |
matty_dubs | See ya, lucas-dinner and dtantsur|afk ! | 20:20 |
lucas-dinner | night everyone! | 20:20 |
mrda | devananda: the measurements of a network wouldn't be any less correct using that system though :) | 20:20 |
romcheg | Have to go as well | 20:20 |
romcheg | G'night everyone | 20:21 |
matty_dubs | Oh, I aksed this in the meeting but we didn't have time -- do we all plan to attend the meeting all day Wednesday? Or are people leaving mid-day? | 20:21 |
devananda | matty_dubs: the midcycle? | 20:21 |
matty_dubs | devananda: Yes. Oops, context helps. | 20:21 |
*** Manishanker has joined #openstack-ironic | 20:22 | |
devananda | matty_dubs: I tend to think 2 days is too little for int'l travel, so I'd encourage folks to stay for all of wed. But that's just my 2c :) | 20:22 |
matty_dubs | That's what I was thinking, too, but every time I think that, half the people leave the AM of the last day. ;) | 20:22 |
devananda | matty_dubs: folks dont want to travel on weekends :) | 20:23 |
matty_dubs | Oh, that's a good point | 20:23 |
devananda | so mon-fri often becomes mon-thu with fri being a travel day for int'l flights | 20:23 |
mrda | matty_dubs: I've got a 6:20pm flight leaving PDX, so I'll be leaving around 4pm I guess | 20:23 |
devananda | mrda: are you arriving sunday? | 20:23 |
mrda | I'll be in Saturday night | 20:23 |
devananda | mrda: awesome. let's do things on sunday | 20:24 |
*** bandicot has quit IRC | 20:24 | |
mrda | devananda: sounds great! Would like to hang out a bit and make the most of the trip | 20:24 |
* devananda points at the "if you're arriving early" bit | 20:24 | |
devananda | https://etherpad.openstack.org/p/juno-ironic-sprint | 20:24 |
mrda | pyconau in BNE is on Friday, so any people at nova/ironic midcycle need to scoot back on Wed night to make it | 20:25 |
devananda | ahh | 20:25 |
mrda | as in, don't go home, get off a 15 hour flight and go straight to conference and be two hours late | 20:25 |
lifeless | devananda: review 97736 seems like it should be an ironic spec | 20:26 |
* mrda thinks this is a crazy schedule | 20:26 | |
devananda | lifeless: we discussed with rameshg8- earlier. i need to update my comments | 20:27 |
devananda | lifeless: posted | 20:28 |
devananda | lifeless: ultimately, it's a change in DIB which will be leveraged by Ironic. There is a spec alraedy in Ironic to match (ilo deploy driver) | 20:30 |
devananda | lifeless: I'm fine with it if you dont want a spec in DIB for that. we can fold it into the existing ironic spec | 20:30 |
*** ifarkas has quit IRC | 20:30 | |
*** max_lobur1 has joined #openstack-ironic | 20:31 | |
*** max_lobur has quit IRC | 20:31 | |
*** martyntaylor has quit IRC | 20:36 | |
*** ellenh has joined #openstack-ironic | 20:36 | |
*** Haomeng has quit IRC | 20:40 | |
matty_dubs | Oh, anyone know if there's any sort of shuttle, or if we'll need a car rental between the hotel and office each day? | 20:46 |
matty_dubs | (Or if they're within walking distance?) | 20:46 |
mrda | matty_dubs: if you're staying at Larkspur Landing or whatever, I think it's too long a walk | 20:47 |
mrda | ...but if we're all in the designated hotel, I'm sure there'll be a spare seat in a car or something | 20:47 |
matty_dubs | mrda: Yeah, I just Google Maps'ed it. Looks like about 3 miles | 20:48 |
matty_dubs | Or whatever that is in non-imperial units ;) | 20:48 |
mrda | I don't mind walking that, especially in July in the USA, but some might not like it | 20:48 |
*** jcoufal has quit IRC | 20:49 | |
matty_dubs | Unless it rains :-\ | 20:49 |
matty_dubs | I think it'll book a car. It'll probably look bad if the people Red Hat sends all have to bum rides from other people. ;) | 20:50 |
*** sam__ has quit IRC | 20:50 | |
mrda | We should all start talking in shaku. | 20:50 |
mrda | West Coast USA is in a drought, right? Or is this just CA? | 20:51 |
matty_dubs | mrda: I haven't been keeping up, honestly. When I was in CA just before the last meetup, they were in the midst of the worst drought in about 125 years. My flight was delayed 6 hours due to torrential downpours in Los Angeles. | 20:52 |
matty_dubs | It seems like no major airlines fly into Hillsboro Airport? It seems kind of silly that the hotel and the office are separated by an airport, but not the one I'm flying into. | 20:54 |
mrda | matty_dubs: lol | 20:54 |
*** max_lobur1 has quit IRC | 20:54 | |
JoshNang | mrda: looks like its mostly CA affected by the worst parts of the drought http://droughtmonitor.unl.edu/ | 20:54 |
mrda | I think Hillsboro airport is there for Intel private jets | 20:55 |
*** jdob has quit IRC | 20:55 | |
matty_dubs | Ooh. Maybe I can hitch a ride on one of those! | 20:56 |
*** Manishanker has quit IRC | 20:56 | |
devananda | i need to run out soon and am way behind on things -- anyone want to rebase https://review.openstack.org/#/c/92819/ ? | 21:03 |
*** Haomeng has joined #openstack-ironic | 21:04 | |
mrda | devananda: sure | 21:04 |
devananda | mrda: thanks! | 21:04 |
*** linggao has quit IRC | 21:04 | |
*** matty_dubs is now known as matty_dubs|gone | 21:04 | |
jroll | devananda, mrda, my goal is to get to portland sunday afternoon and be able to hang out | 21:18 |
mrda | jroll: cool! | 21:19 |
*** mdorman_ has joined #openstack-ironic | 21:23 | |
*** mdorman_ has quit IRC | 21:25 | |
*** mdorman_ has joined #openstack-ironic | 21:26 | |
*** mdorman has quit IRC | 21:27 | |
*** mdorman_ is now known as mdorman | 21:27 | |
*** chen has joined #openstack-ironic | 21:29 | |
openstackgerrit | Michael Davies proposed a change to openstack/ironic: Mock pyghmi lib in unit tests if not present https://review.openstack.org/92819 | 21:30 |
*** Mikhail_D_ltp has quit IRC | 21:33 | |
*** chen has quit IRC | 21:38 | |
*** yu_ has joined #openstack-ironic | 21:53 | |
* devananda reviews more specs | 21:56 | |
NobodyCam | brb | 21:59 |
*** achanda has quit IRC | 22:03 | |
devananda | heading out in a bit for an appt... | 22:06 |
NobodyCam | :) | 22:08 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Add ironic-python-agent deploy driver (DO NOT MERGE) https://review.openstack.org/101020 | 22:23 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Adding swift temp url support https://review.openstack.org/81391 | 22:27 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Factor out TFTPImageCache https://review.openstack.org/100734 | 22:29 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Factor out deploy info from PXE driver https://review.openstack.org/100735 | 22:29 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Add methods to ipmitool driver https://review.openstack.org/100364 | 22:29 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Add ironic-python-agent deploy driver (DO NOT MERGE) https://review.openstack.org/101020 | 22:29 |
jroll | wheeeeeeee | 22:30 |
*** sysexit has quit IRC | 22:33 | |
*** achanda has joined #openstack-ironic | 22:45 | |
*** romcheg has quit IRC | 22:47 | |
*** kylers has joined #openstack-ironic | 23:26 | |
*** mdorman has quit IRC | 23:27 | |
lifeless | devananda: I've no objection to the spec there, but I think it needs Ironic consensus before +A | 23:30 |
* NobodyCam steps afk | 23:52 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!