*** Haomeng|2 has joined #openstack-ironic | 00:03 | |
*** Haomeng has quit IRC | 00:03 | |
devananda | on the not-a-cmdb topic, what can we do to better facilitate integration with _existing_ CMDBs? | 00:04 |
---|---|---|
devananda | that might help make the line clearer, too | 00:05 |
devananda | jroll: that totally might be related to ironic. or it totally might be something else. | 00:06 |
jroll | yeah :P | 00:06 |
jroll | it just doesn't call it out | 00:06 |
devananda | jroll: I suspect it's mroe of a "look at our cool thing which shows all your physical and virtual assets in one screen!" | 00:07 |
*** ellenh has quit IRC | 00:07 | |
jroll | devananda: indeed | 00:08 |
* jroll has to run | 00:08 | |
*** igordcard has quit IRC | 00:08 | |
*** openstackgerrit has quit IRC | 00:16 | |
*** openstackgerrit has joined #openstack-ironic | 00:17 | |
*** killer_prince has joined #openstack-ironic | 00:20 | |
*** killer_prince is now known as lazy_prince | 00:20 | |
devananda | https://www.openstack.org/vote-paris/Presentation/trusted-bare-metal-what-s-that | 00:22 |
*** ellenh has joined #openstack-ironic | 00:25 | |
*** rameshg87 has joined #openstack-ironic | 00:49 | |
*** chuckC has quit IRC | 00:51 | |
rameshg87 | lifeless, hi | 00:51 |
*** rameshg87 has quit IRC | 00:56 | |
*** rameshg87 has joined #openstack-ironic | 00:57 | |
*** ellenh has quit IRC | 01:05 | |
*** rameshg87 has quit IRC | 01:11 | |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: WIP: '_periodic_last_run' missing (simple test) https://review.openstack.org/111126 | 01:14 |
openstackgerrit | Yongli He proposed a change to openstack/ironic: Rewrite ironic policy to use the new changes of common policy https://review.openstack.org/97731 | 01:30 |
*** mitz_ has joined #openstack-ironic | 01:34 | |
*** mitz has quit IRC | 01:36 | |
*** lazy_prince has quit IRC | 01:44 | |
*** nosnos has joined #openstack-ironic | 01:51 | |
*** dkehn_ has joined #openstack-ironic | 01:55 | |
*** dkehnx has quit IRC | 01:59 | |
*** jgrimm has joined #openstack-ironic | 02:07 | |
*** killer_prince has joined #openstack-ironic | 02:16 | |
*** killer_prince is now known as lazy_prince | 02:16 | |
*** eghobo has quit IRC | 02:17 | |
*** rainya has quit IRC | 02:20 | |
*** zz_nkubota is now known as nkubota | 02:21 | |
*** aswadr has joined #openstack-ironic | 02:31 | |
*** hemna has quit IRC | 02:33 | |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Update strutils from oslo-incubator https://review.openstack.org/111144 | 02:34 |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Fix not attribute '_periodic_last_run' https://review.openstack.org/111126 | 02:40 |
*** chuckC has joined #openstack-ironic | 02:40 | |
*** lazy_prince has quit IRC | 02:45 | |
*** Haomeng|2 has quit IRC | 02:46 | |
*** nkubota is now known as zz_nkubota | 02:51 | |
*** killer_prince has joined #openstack-ironic | 02:55 | |
*** rwsu has quit IRC | 02:55 | |
*** killer_prince is now known as lazy_prince | 02:55 | |
*** Zerpex has quit IRC | 02:58 | |
*** Zerpex has joined #openstack-ironic | 02:58 | |
*** jgrimm has quit IRC | 03:00 | |
*** jgrimm has joined #openstack-ironic | 03:01 | |
*** Haomeng|2 has joined #openstack-ironic | 03:10 | |
*** nosnos has quit IRC | 03:13 | |
*** nosnos has joined #openstack-ironic | 03:14 | |
*** rainya has joined #openstack-ironic | 03:17 | |
*** nosnos has quit IRC | 03:18 | |
*** scubacuda has quit IRC | 03:25 | |
*** nosnos has joined #openstack-ironic | 03:44 | |
*** Haomeng|2 has quit IRC | 03:53 | |
*** Haomeng|2 has joined #openstack-ironic | 03:55 | |
*** eghobo has joined #openstack-ironic | 04:09 | |
*** nosnos has quit IRC | 04:11 | |
*** nosnos has joined #openstack-ironic | 04:20 | |
*** Poornima has joined #openstack-ironic | 04:22 | |
openstackgerrit | Yongli He proposed a change to openstack/ironic: Rewrite ironic policy to use the new changes of common policy https://review.openstack.org/97731 | 04:23 |
*** pcrews has quit IRC | 04:52 | |
*** ramineni has joined #openstack-ironic | 04:54 | |
*** bmahalakshmi has joined #openstack-ironic | 04:58 | |
*** lazy_prince is now known as killer_prince | 05:02 | |
openstackgerrit | A change was merged to openstack/ironic: Updated from global requirements https://review.openstack.org/106569 | 05:06 |
*** zz_nkubota is now known as naotok | 05:09 | |
*** jcoufal has joined #openstack-ironic | 05:16 | |
*** bmahalakshmi has quit IRC | 05:27 | |
*** k4n0 has joined #openstack-ironic | 05:28 | |
*** rainya has quit IRC | 05:29 | |
*** rainya has joined #openstack-ironic | 05:30 | |
*** killer_prince has quit IRC | 05:31 | |
*** rakesh_hs has joined #openstack-ironic | 05:35 | |
*** nikunj2513 has joined #openstack-ironic | 05:37 | |
*** bvivek has joined #openstack-ironic | 05:37 | |
*** killer_prince has joined #openstack-ironic | 05:41 | |
*** killer_prince is now known as lazy_prince | 05:41 | |
*** rainya has quit IRC | 05:59 | |
*** lynxman has quit IRC | 06:03 | |
GheRivero | morning all! | 06:04 |
*** lynxman has joined #openstack-ironic | 06:05 | |
GheRivero | Can I get some love for https://review.openstack.org/#/c/111126/ ? | 06:07 |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic: Imported Translations from Transifex https://review.openstack.org/110860 | 06:10 |
*** eghobo has quit IRC | 06:32 | |
openstackgerrit | David J Hu proposed a change to openstack/python-ironicclient: Add keystone v3 CLI support https://review.openstack.org/111175 | 06:34 |
Haomeng|2 | GheRivero: morning | 06:36 |
Haomeng|2 | GheRivero: sure, let me help to review | 06:37 |
Haomeng|2 | GheRivero: :) | 06:37 |
Haomeng|2 | GheRivero: Thanks for the patch, code lgtm, and left some nits with the commit message. | 06:41 |
GheRivero | Haomeng|2: yeah, the commit message, it was like 4am for me so I doubt the message make any sense at all :) | 06:51 |
Haomeng|2 | GheRivero: :) | 06:52 |
Haomeng|2 | GheRivero: ok, that is fine with me | 06:52 |
*** radsy has quit IRC | 06:52 | |
Zerpex | Morning people - I'm trying to deploy a server using ironic - but every time I get: | 06:53 |
Zerpex | 2014-08-01 08:25:51.368 5421 INFO nova.filters [req-4a372c33-4219-45ed-a96b-371860f26ba3 e37d75eaf5dd4b7084ab9ef75087502d 5e4448cf9b524d16a7b89af6c6669311] Filter ComputeFilter returned 0 hosts | 06:53 |
Haomeng|2 | Zerpex: morning | 06:53 |
Zerpex | hi again Haomeng|2 :D | 06:53 |
Haomeng|2 | Zerpex: :) | 06:53 |
Haomeng|2 | Zerpex: can you show your node and flavor and properties | 06:53 |
GheRivero | and nova hypervisor-stats | 06:54 |
Zerpex | http://snaps.lucasrolff.com/ie1s47tw1706v1t.png is the node and flavor | 06:55 |
Haomeng|2 | yes, should be some not maching | 06:55 |
*** jgrimm has quit IRC | 06:56 | |
Zerpex | http://snaps.lucasrolff.com/g2o0q37pssyobwi.png is the hypervisor stats.. but seems like that is the current machine I'm on (controller1) and not the actual 10.1.30.105 node | 06:57 |
Haomeng|2 | Zerpex: did you set ironic scheduler in nova.conf? | 06:57 |
Zerpex | Yep | 06:57 |
Zerpex | scheduler_host_manager=ironic.nova.scheduler.ironic_host_manager.IronicHostManager | 06:57 |
Haomeng|2 | Zerpex: looks like there is no 'arch' with your node attributes | 06:58 |
Zerpex | should be under "properties" or instance_info ? | 06:58 |
Haomeng|2 | Zerpex: let me check the devstack scripts, my env is down, can not check my node attributes | 07:00 |
Haomeng|2 | https://github.com/openstack-dev/devstack/blob/master/lib/ironic#L357 | 07:01 |
Haomeng|2 | Zerpex: ironic should have cpu_arch=x86_64 attribute I think to match flavor's ext data | 07:02 |
Zerpex | cool - will try adding the info as in that line! | 07:02 |
Haomeng|2 | Zerpex: ok, try again, and good luck | 07:03 |
Haomeng|2 | Zerpex: I think that should be default flavor filter enabled to select the nodes | 07:08 |
Haomeng|2 | Zerpex: if it is working now? | 07:10 |
Zerpex | Currently testing - need to delete the old node | 07:10 |
Haomeng|2 | Zerpex: ok | 07:12 |
Haomeng|2 | Zerpex: you can run "ironic node-update" to add/update the node attributes | 07:13 |
Zerpex | still not working, bah | 07:17 |
*** bvivek has quit IRC | 07:19 | |
Haomeng|2 | Zerpex: not the node has cpu_arch attribute, right? | 07:19 |
Zerpex | http://snaps.lucasrolff.com/ntsder4fmg231so.png | 07:19 |
Zerpex | yap | 07:19 |
*** viktors|afk is now known as viktors | 07:20 | |
Haomeng|2 | Zerpex: yes, the properties looks fine | 07:21 |
Haomeng|2 | Zerpex: for this - http://snaps.lucasrolff.com/g2o0q37pssyobwi.png, strnage, why runing-vms=2? | 07:23 |
Haomeng|2 | Zerpex: you have launched 2 vms already? | 07:23 |
Zerpex | Haomeng|2: back in time when I wasn't using ironic - yes - i launched two VMs on the controller node.. not on the 10.1.30.105 node - which also surprises me, because I would assume the hypervisor-stats would show my ironic node | 07:24 |
Haomeng|2 | Zerpex: did you have multi compute nodes? | 07:25 |
Haomeng|2 | Zerpex: I understand you have multi hypervisors including ironic and others | 07:25 |
Zerpex | I used to have a compute node, which I removed (also wondering why it shows two vms when I deleted them :D) | 07:26 |
Haomeng|2 | so have to check ironic hyper-visior status | 07:26 |
Zerpex | and now I just have the controller server, and 1 ironic thing | 07:26 |
*** dtantsur|afk is now known as dtantsur | 07:26 | |
Haomeng|2 | Zerpex: maybe nova database is wrong | 07:26 |
dtantsur | Morning everyone! | 07:26 |
Haomeng|2 | dtantsur: morning:) | 07:26 |
Zerpex | Haomeng|2: need to find a way to clean that then | 07:28 |
Haomeng|2 | Zerpex: I understand you have old nova.conf, and modified it to enable ironic, right? | 07:29 |
Zerpex | yeap | 07:30 |
dtantsur | Haomeng|2, great job with Ceilometer patch! | 07:30 |
Haomeng|2 | dtantsur: thanks for you kindly review and valuable comments again:) | 07:32 |
dtantsur | np :) | 07:32 |
Haomeng|2 | dtantsur: :) | 07:32 |
openstackgerrit | Yongli He proposed a change to openstack/ironic: Rewrite ironic policy to use the new changes of common policy https://review.openstack.org/97731 | 07:32 |
Haomeng|2 | dtantsur: one question about our ironic scheduler filter | 07:32 |
Haomeng|2 | dtantsur: I understand the logic is we use default nova flavor filter to checkout the baremetals from ironic nodes which has cpu_arch value matches the flavor ext cpu_arch data, right? | 07:33 |
dtantsur | Haomeng|2, I'm not really strong here, but yes, should be | 07:34 |
Haomeng|2 | dtantsur: Zerpex encoutered the issue which ironic scheduler does not work, can not check out the ironic nodes | 07:34 |
Haomeng|2 | dtantsur: :) | 07:34 |
* dtantsur reading scrollback | 07:34 | |
Zerpex | Even when I do a "nova hypervisor-list" I don't see the machine either :/ | 07:35 |
Haomeng|2 | Zerpex: you mean the output is empty with "nova hypervisor-list" command call? | 07:36 |
Haomeng|2 | Zerpex: should be a hypervisor which is ironic compute | 07:37 |
Zerpex | nope - it shows the controller server | 07:37 |
dtantsur | Zerpex, I see several problems with http://snaps.lucasrolff.com/ie1s47tw1706v1t.png | 07:37 |
dtantsur | 1. Node.properties does not contain memory_mb, cpu_arch, cpus | 07:38 |
dtantsur | 2. local_gb = 60, in flavor disk = 40 | 07:39 |
Haomeng|2 | dtantsur: yes, we add cpu_arch already, and should add others | 07:39 |
Haomeng|2 | yes, should be matched with flavor | 07:39 |
Zerpex | | properties | {u'memory_mb': u'4096', u'cpu_arch': u'x86_64', u'local_gb': u'60', u'cpus': u'2'} | 07:39 |
dtantsur | looks good | 07:39 |
Haomeng|2 | is this now attributes? | 07:39 |
dtantsur | did you fix the flavor? | 07:40 |
Zerpex | Haomeng|2: yes - and I'll fix the flavor now | 07:40 |
Haomeng|2 | it is better we make sure flavor's attribute matchs ironic node properties | 07:41 |
Haomeng|2 | Zerpex: if still not working,have to check ironic hypervisor status and properties | 07:41 |
Zerpex | Can I actually update the disk for a flavor | 07:41 |
Haomeng|2 | looks like there is no such flavor-update command | 07:42 |
Haomeng|2 | Zerpex: so can you take devstack scripts as reference and recreate the flavor - https://github.com/openstack-dev/devstack/blob/master/lib/ironic#L368 | 07:43 |
*** ifarkas has joined #openstack-ironic | 07:44 | |
Zerpex | Recreated it - now let's see if it will work :D | 07:45 |
Haomeng|2 | Zerpex: good luck:) | 07:46 |
Haomeng|2 | Zerpex: if still not working,have to check nova side | 07:46 |
Zerpex | okay, so still not working - ComputeFilter always return 0 :( | 07:47 |
Haomeng|2 | nova-manage service list | 07:47 |
Haomeng|2 | Zerpex: to see if our ironic compute driver is normal status | 07:47 |
Zerpex | http://snaps.lucasrolff.com/926ff5eenzbw9ss.png bah | 07:47 |
*** jistr has joined #openstack-ironic | 07:48 | |
Haomeng|2 | status is not :) | 07:48 |
Zerpex | http://snaps.lucasrolff.com/bbc25j5h99y2wpb.png | 07:48 |
Haomeng|2 | nova-compute line | 07:48 |
Zerpex | but is running :D | 07:48 |
Haomeng|2 | you can paste the text with http://paste.openstack.org/ also:) | 07:49 |
Haomeng|2 | should be ironic driver side issue | 07:49 |
Haomeng|2 | can you check nova compute log? | 07:49 |
Haomeng|2 | Zerpex: maybe our ironic nova driver is not started with exceptions | 07:49 |
Haomeng|2 | and help to paste the nova compute log via http://paste.openstack.org/ , thanks | 07:50 |
*** Mikhail_D_ltp has joined #openstack-ironic | 07:50 | |
Zerpex | http://paste.openstack.org/show/89543/ | 07:51 |
Zerpex | wat - it did cut my paste | 07:51 |
Haomeng|2 | Zerpex: ok | 07:52 |
Haomeng|2 | Zerpex: maybe the last lines contain some exception that will cause nova compute wrong status | 07:53 |
Haomeng|2 | Zerpex: one finding - scheduler_manager = nova.scheduler.manager.SchedulerManager | 07:53 |
Haomeng|2 | Zerpex: should be "ironic.nova.scheduler.ironic_host_manager.IronicHostManager" I think | 07:54 |
dtantsur | brb | 07:54 |
Haomeng|2 | Zerpex: in the compute log line 278 | 07:54 |
*** dtantsur is now known as dtantsur|brb | 07:55 | |
Zerpex | nova-compute controller1 nova enabled :-) 2014-08-01 07:32:12 | 07:56 |
Zerpex | now is ok | 07:56 |
Haomeng|2 | Zerpex: did you set scheduler_manager=ironic.nova.scheduler.ironic_host_manager.IronicHostManager ? | 07:56 |
Haomeng|2 | Zerpex: how did you fix? | 07:57 |
Zerpex | http://snaps.lucasrolff.com/sqss2atppjja3ms.png | 07:57 |
Zerpex | yes :D | 07:57 |
Zerpex | so now it returns the correct thing as well | 07:57 |
Haomeng|2 | Zerpex: looks fine | 07:57 |
Haomeng|2 | Zerpex: have interested with your actions -how did you fix? | 07:57 |
*** romcheg1 has joined #openstack-ironic | 07:58 | |
Zerpex | rebooted the server and changed the scheduler_manager :') | 07:58 |
Haomeng|2 | Zerpex: cool:) | 07:58 |
Haomeng|2 | Zerpex: try again, and good luck:) | 07:58 |
Zerpex | http://snaps.lucasrolff.com/f13r7tmc9pgafrm.png | 07:59 |
Zerpex | but now I get that | 07:59 |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Fix not attribute '_periodic_last_run' https://review.openstack.org/111126 | 07:59 |
Zerpex | brb 4 mins | 08:00 |
Haomeng|2 | Zerpex: :) | 08:00 |
*** romcheg_ltp has quit IRC | 08:00 | |
*** naotok is now known as zz_naotok | 08:01 | |
Zerpex | hmm - wondering where that comes from :3 | 08:01 |
Haomeng|2 | Zerpex: can you check the nova.conf carefuly? | 08:02 |
Zerpex | I'll do | 08:02 |
Haomeng|2 | Zerpex: and not sure if your nova code is so old which does not match the new ironic code? | 08:03 |
Zerpex | I did use the RDO installer - so would assume is somewhat new :D | 08:04 |
Zerpex | and was deployed like 1 week ago | 08:04 |
Haomeng|2 | Zerpex: looks the code is trying to access the unknow attribute self.host | 08:04 |
Zerpex | http://snaps.lucasrolff.com/kxnuy19vum65wwk.png should be there | 08:04 |
Haomeng|2 | Zerpex: or self is none | 08:05 |
Haomeng|2 | strange | 08:05 |
Haomeng|2 | any more information from log? | 08:05 |
Zerpex | let me see | 08:05 |
Haomeng|2 | Zerpex: manager_class has no such host argument, I think, based on the error message | 08:06 |
Haomeng|2 | let me check our ironic scheduler manager code | 08:07 |
*** romcheg1 has quit IRC | 08:09 | |
Haomeng|2 | base class is nova.scheduler.host_manager.HostManager | 08:09 |
*** bvivek has joined #openstack-ironic | 08:12 | |
*** ndipanov has joined #openstack-ironic | 08:18 | |
*** foexle has joined #openstack-ironic | 08:18 | |
*** nikunj2513 is now known as nikunj2512 | 08:19 | |
*** derekh_ has joined #openstack-ironic | 08:19 | |
*** derekh_ is now known as derekh__ | 08:22 | |
*** derekh__ is now known as derekh_ | 08:22 | |
*** MattMan has quit IRC | 08:32 | |
*** MattMan has joined #openstack-ironic | 08:32 | |
*** bmahalakshmi has joined #openstack-ironic | 08:50 | |
*** romcheg1 has joined #openstack-ironic | 08:55 | |
*** lazy_prince has quit IRC | 09:16 | |
*** athomas has joined #openstack-ironic | 09:18 | |
*** rameshg87 has joined #openstack-ironic | 09:21 | |
openstackgerrit | Vladyslav Drok proposed a change to openstack/ironic: Remove gettextutils _ injection https://review.openstack.org/110634 | 09:26 |
*** killer_prince has joined #openstack-ironic | 09:38 | |
*** killer_prince is now known as lazy_prince | 09:38 | |
*** rameshg87_ has joined #openstack-ironic | 10:03 | |
*** ndipanov_ has joined #openstack-ironic | 10:05 | |
*** rameshg87 has quit IRC | 10:11 | |
*** ndipanov has quit IRC | 10:11 | |
*** Mikhail_D_ltp has quit IRC | 10:11 | |
*** foexle has quit IRC | 10:11 | |
*** foexle has joined #openstack-ironic | 10:14 | |
*** Mikhail_D_ltp has joined #openstack-ironic | 10:16 | |
*** ndipanov_ has quit IRC | 10:19 | |
*** ndipanov has joined #openstack-ironic | 10:19 | |
openstackgerrit | Ramakrishnan G proposed a change to openstack/ironic: Take iSCSI deploy out of pxe driver https://review.openstack.org/111232 | 10:21 |
*** romcheg1 has left #openstack-ironic | 10:37 | |
*** romcheg1 has joined #openstack-ironic | 10:37 | |
marios | anyone tried devtest with ironic lately? my undercloud heat stack create timed out - trying again | 10:38 |
Haomeng|2 | marios: hi | 10:52 |
Haomeng|2 | marios: if the root cause is timeout, you can modify the default timeout value in devstack scripts | 10:52 |
*** romcheg1 has quit IRC | 10:52 | |
Haomeng|2 | marios: stack.sh:SERVICE_TIMEOUT=${SERVICE_TIMEOUT:-60} | 10:53 |
Haomeng|2 | marios: you mean tripleo's devtest? | 10:53 |
Haomeng|2 | marios: not devstack? | 10:54 |
Haomeng|2 | marios: and you can raise the question to tripleo | 10:54 |
Haomeng|2 | marios: irc #tripleo | 10:54 |
marios | Haomeng|2: thanks, seems to be metadata (Aug 01 10:49:20 localhost nova-api[3384]: 2014-08-01 10:49:20.798 3788 ERROR nova.api.metadata.handler [-] Failed to get metadata for...92.0.2.3 | 10:56 |
Haomeng|2 | marios: so have to check nova-api-metadata service process and log | 10:57 |
Haomeng|2 | marios: welcome | 10:57 |
*** dtantsur|brb is now known as dtantsur | 10:59 | |
*** ramineni has quit IRC | 11:01 | |
*** Alexei_9871 has joined #openstack-ironic | 11:03 | |
dtantsur | Folks, anyone wanting to have a look at Ceilometer integration https://review.openstack.org/#/c/72538/ before it's approved? | 11:04 |
openstackgerrit | Ramakrishnan G proposed a change to openstack/ironic: Take iSCSI deploy out of pxe driver https://review.openstack.org/111232 | 11:30 |
*** bmahalakshmi has quit IRC | 11:37 | |
rameshg87_ | dtantsur, just have a quick question | 11:40 |
dtantsur | rameshg87_, yep | 11:41 |
rameshg87_ | dtantsur, https://review.openstack.org/#/c/111232/1/ironic/drivers/modules/deploy_utils.py L352 | 11:41 |
rameshg87_ | dtantsur, comment on "redundant" | 11:41 |
dtantsur | yes | 11:41 |
dtantsur | you don't need a return value in case of exception | 11:41 |
dtantsur | (that's why it wasn't there from the beginning) | 11:41 |
rameshg87_ | dtantsur, ah okay, because we are rethrowing the exception ? | 11:42 |
dtantsur | rameshg87_, exactly | 11:42 |
rameshg87_ | dtantsur, ah okay .. i missed that part .. | 11:43 |
rameshg87_ | dtantsur, i will revise it, thanks | 11:43 |
dtantsur | yeah, I'm also often confused at this point | 11:43 |
dtantsur | np :) | 11:43 |
rameshg87_ | dtantsur, i just posted a new patch excatly at the same minute you posted comment | 11:43 |
rameshg87_ | dtantsur, i will address in next patch :-) | 11:43 |
dtantsur | yeah, I've seen it :) | 11:43 |
openstackgerrit | Imre Farkas proposed a change to openstack/ironic: Add DracDriver and its DracPower module https://review.openstack.org/104850 | 11:58 |
*** nikunj2512 has quit IRC | 12:02 | |
*** Shrews has joined #openstack-ironic | 12:02 | |
*** rameshg87_ has quit IRC | 12:04 | |
*** Shrews has quit IRC | 12:06 | |
*** Shrews has joined #openstack-ironic | 12:06 | |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: EXPERIMENTAL Implement hardware discovery in PXE driver https://review.openstack.org/110031 | 12:06 |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Add newly_discovered column to Node object https://review.openstack.org/107389 | 12:06 |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: EXPERIMENTAL Add Conductor.discovery_driver field https://review.openstack.org/109304 | 12:06 |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: EXPERIMENTAL Implement conductor part of hardware discovery https://review.openstack.org/109312 | 12:06 |
*** jasondotstar has quit IRC | 12:10 | |
openstackgerrit | Imre Farkas proposed a change to openstack/ironic: Add DracDriver and its DracPower module https://review.openstack.org/104850 | 12:18 |
openstackgerrit | A change was merged to openstack/ironic: Implements send-data-to-ceilometer https://review.openstack.org/72538 | 12:29 |
*** lazy_prince has quit IRC | 12:41 | |
*** killer_prince has joined #openstack-ironic | 12:56 | |
*** mkerrin has quit IRC | 12:56 | |
*** killer_prince is now known as lazy_prince | 12:56 | |
*** mkerrin has joined #openstack-ironic | 12:57 | |
openstackgerrit | A change was merged to openstack/ironic: Fix not attribute '_periodic_last_run' https://review.openstack.org/111126 | 13:05 |
*** jistr has quit IRC | 13:12 | |
*** jistr has joined #openstack-ironic | 13:14 | |
*** jasondotstar has joined #openstack-ironic | 13:19 | |
*** k4n0 has quit IRC | 13:26 | |
*** stendulker has joined #openstack-ironic | 13:28 | |
*** jasondotstar has quit IRC | 13:40 | |
*** jasondotstar has joined #openstack-ironic | 13:41 | |
NobodyCam | Good morning Ironic TGIF!!! | 13:44 |
dtantsur | NobodyCam, morning, TGIF :) | 13:46 |
NobodyCam | morning dtantsur :) | 13:46 |
*** mkerrin has quit IRC | 13:48 | |
*** mkerrin has joined #openstack-ironic | 13:48 | |
NobodyCam | brb... | 13:49 |
*** jistr has quit IRC | 13:52 | |
*** jistr has joined #openstack-ironic | 13:53 | |
*** Poornima has quit IRC | 13:56 | |
*** dkehn_ is now known as dkehnx | 14:02 | |
*** pcrews has joined #openstack-ironic | 14:06 | |
*** rainya has joined #openstack-ironic | 14:06 | |
stendulker | JayF: Hello, are you there? | 14:07 |
NobodyCam | much too cold outside for summer :-p | 14:08 |
*** rainya has quit IRC | 14:09 | |
stendulker | NobodyCam: Hello | 14:10 |
*** rainya has joined #openstack-ironic | 14:10 | |
NobodyCam | good morning stendulker :) | 14:10 |
stendulker | NobodyCam: good morning :) | 14:10 |
stendulker | NobodyCam: Wanted to discuss regarding firmware settings spec https://review.openstack.org/#/c/101122/ | 14:11 |
*** lazy_prince is now known as killer_prince | 14:11 | |
jroll | morning y'all | 14:12 |
stendulker | NobodyCam: It seems this spec got discussed during mid-cycle meetup and it was felt this spec is kind of outside Ironic scope. JayF have left me comment summarizing it. | 14:12 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Remove dbapi calls from agent driver https://review.openstack.org/111292 | 14:12 |
NobodyCam | morning jroll | 14:13 |
*** igordcard has joined #openstack-ironic | 14:13 | |
dtantsur | jroll, morning! | 14:13 |
jroll | gah I forgot a bug for that | 14:13 |
*** killer_prince is now known as lazy_prince | 14:13 | |
NobodyCam | stendulker: let me review the comments | 14:14 |
stendulker | NobodyCam: Ok. | 14:14 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Remove dbapi calls from agent driver https://review.openstack.org/111292 | 14:15 |
jroll | much better | 14:15 |
jroll | fairly easy review there, I think | 14:15 |
*** zul has joined #openstack-ironic | 14:17 | |
*** rakesh_hs has quit IRC | 14:27 | |
*** nosnos has quit IRC | 14:31 | |
openstackgerrit | A change was merged to openstack/ironic-python-agent: Updated from global requirements https://review.openstack.org/88722 | 14:32 |
*** comstud is now known as bearhands | 14:36 | |
NobodyCam | stendulker: we did discuss the firmware and inventory aspects at the meetup. | 14:37 |
*** jgrimm has joined #openstack-ironic | 14:40 | |
*** nosnos has joined #openstack-ironic | 14:41 | |
NobodyCam | stendulker: I really what to find out what will come out of this : https://www.openstack.org/vote-paris/Presentation/cmdb-for-openstack-public-cloud-based-assets | 14:42 |
stendulker | NobodyCam: Ok, I had posted the comment justifying the need for the individual tuning as well as 'Capability' attribute proposed in the comment which would be part of the flavor | 14:42 |
*** Mikhail_D_ltp has quit IRC | 14:42 | |
stendulker | NobodyCam: I was not fully convinced that 'Capability' attribute in flavor would be able to tune the BM node in a desired fashion for the user. | 14:43 |
*** nosnos has quit IRC | 14:44 | |
NobodyCam | stendulker: In your example are saying expert users would what to fine tune systems after they have been provisioned? | 14:50 |
*** lazy_prince is now known as killer_prince | 14:57 | |
*** rainya has quit IRC | 14:59 | |
stendulker | nobodyCam: Not after. Before provisioning would want to tune the system for his workload which would be run after deploy. | 15:02 |
stendulker | NobodyCam: Most of the firmware settings would need a reboot, so best time to perform tuning would be before deploy | 15:03 |
jroll | stendulker: if the desired settings are known before provisioning, a capability could be created to handle that. right? | 15:03 |
*** rainya has joined #openstack-ironic | 15:03 | |
stendulker | jroll: The 'Capability' being a single property, it may not be handle multiple tuning that may be required to achieve the end result. | 15:05 |
jroll | stendulker: I think the idea is that a capability could handle multiple firmware settings | 15:05 |
stendulker | Cpability would be broad level setting which would be interpreted by the driver as a pre-defined set of firmware settings and not individual ones. This would prevent the custom tuning by the user. | 15:06 |
jroll | why couldn't the user make his or her own new capability? | 15:06 |
jroll | with all the right settings? | 15:06 |
devananda | morning, all | 15:08 |
stendulker | jroll: How do the driver interpret user defined capability. Can you please give me a possible example | 15:08 |
jroll | stendulker: the same way. any user of ironic is an admin user, and so could create a capability | 15:08 |
jroll | morning devananda | 15:08 |
stendulker | jroll : Will the capability have set of name/value pairs? | 15:08 |
jroll | stendulker: I don't think people have decided how a capability will be defined | 15:09 |
stendulker | jroll: Say the user wants to deploy a node to use UEFI boot with power tuned to optimum value and few more processor related settings | 15:09 |
jroll | in terms of firmware things | 15:09 |
jroll | yes, that will be possible, it appears | 15:10 |
*** dkehn_ has joined #openstack-ironic | 15:10 | |
jroll | stendulker: we want to enable your use case, just in a (seemingly) better way | 15:10 |
jroll | devananda: found some dbapi calls in the driver after all :P https://review.openstack.org/111292 | 15:10 |
stendulker | jroll: Will capability be used by nova scheduler for node selection or it is something that would be used by driver to prepare the node for deploy post selection | 15:11 |
jroll | stendulker: sounds like both | 15:12 |
jroll | if needed, the driver could prepare the node | 15:12 |
devananda | jroll: good stuff | 15:13 |
stendulker | jroll: Wanted to understand the capability better as firmware settings are mostly vendor specific and flavor is something which is generic in nature | 15:13 |
*** dkehnx has quit IRC | 15:14 | |
jroll | stendulker: right, I have to run in a moment, but hopefully someone else can explain :) | 15:15 |
jroll | stendulker: but, short version is that we can support your needs, I think | 15:15 |
JayF | stendulker: exactly why I said what I did | 15:16 |
stendulker | jroll: ok. Thanks. If I could get more details, it would help me understand if the usecase gets covered. | 15:16 |
JayF | stendulker: firmware settings *are* vendor dpecific | 15:16 |
JayF | *specific | 15:16 |
JayF | stendulker: and Ironic has to abstract that to present a reasonable api | 15:16 |
stendulker | JayF: Good morning :) | 15:16 |
JayF | stendulker: the point you crossover into configuring a single machine in a highly specific way, you've moved out of the realm of cloud and treating servers at cattle into the realm of managing snowflakes, which isn't really in the scope of openstack generally | 15:17 |
JayF | stendulker: good morning :) | 15:17 |
stendulker | JayF: The proposed API were accepting key/value pairs for the firmware settings so that drivers could handle it based on the individual vendor | 15:18 |
JayF | stendulker: I think that'll be somewhat preserved, but in the form of 'capabilities' that then a driver could implement however | 15:18 |
JayF | theoretically, you could make a driver that exposed a large number of bios settings as different capabilities | 15:18 |
JayF | and require them all on the nova flavor definition | 15:18 |
JayF | that's absolutely not the way I'd use it, but I think enabling custom capabilities is important; but it has to be made better for the generic case | 15:19 |
stendulker | JayF: so is a capability be defined as a set of generic firmware settings to be done by driver before provisioning? | 15:20 |
*** dtantsur is now known as dtantsur|brb | 15:21 | |
JayF | Well, we have to write a spec to define exactly what it would be :), but the idea talked about at the meetup is like this: | 15:21 |
JayF | capabilities are ternary: true/false/configure | 15:21 |
JayF | in the case of BIOS settings, you're almost always going to expose them as a configurable option | 15:21 |
JayF | we would have a small generic set (think: HPC, virtualization, etc) which we would want all drivers to support, so an operator could configure a 'virutalization' flavor which would schedule to a server with the proper config; including VT bit set, turbo mode disabled, etc | 15:22 |
stendulker | JayF: So, I suppose the capabilities would be pre-defined key names having one of the ternary values | 15:23 |
JayF | and then also drivers could expose their own capabilities | 15:23 |
JayF | like for instance, for IPA, the agent could query loaded hardware managers to capabilities | 15:23 |
JayF | or for iLo/DRAC, it could query those and determine additional capabilities | 15:23 |
JayF | stendulker: yeah, exactly. | 15:23 |
JayF | stendulker: and for ones that are 'configure', you'd have a new call, just before deploy, that does that configuration | 15:24 |
devananda | JayF: It sounds like you want to write the spec for Kilo :) | 15:25 |
stendulker | JayF: So this will not cover any vendor spefic tunings or custom tuning required by the user | 15:25 |
JayF | devananda: I wouldn't have had such well-formed ideas if I knew they came with responsiblity :P | 15:25 |
devananda | JayF: ideas always come with responsibility ;) | 15:25 |
JayF | stendulker: explicitly not; the only real customization you can expose to the user is via nova flavors | 15:25 |
JayF | stendulker: or from an ironic api standpoint directly; capabilities | 15:26 |
JayF | stendulker: if you have a cool vendor specific set of tunings; you /could/ expose it as capabilities, you just have to do it from within a driver -- like via a custom IPA hardware manager | 15:28 |
stendulker | JayF: But doesn't this constrain the user to pre-defined capabilities and take away the flexibility to fine tune ? | 15:28 |
JayF | stendulker: so lets step back for a second, I'm assuming your use case is using Ironic behind Nova, correct? | 15:28 |
JayF | stendulker: with a Nova driver? | 15:28 |
stendulker | yes ironic behind nova | 15:29 |
JayF | OK, so assuming it would be OK scope wise and abstraction wise to set specific BIOS settings, how would those users pass those requests through to Ironic via Nova API? | 15:30 |
stendulker | any capability defined would not be able to cater all tuning needs of the user. | 15:30 |
NobodyCam | stendulker: do you have an example of a setting that a user would fine tune? | 15:32 |
*** foexle has quit IRC | 15:32 | |
* Shrews hopes everyone had a better week than he did | 15:32 | |
JayF | I'm also still curious about how you'd feed that information through nova to ironic. I don't think there's a mechanism/interface for it now either :) Remember that adding something to Ironic API still means only an admin could do it | 15:32 |
NobodyCam | Shrews: :( | 15:33 |
NobodyCam | Shrews: and good morning :) | 15:33 |
Shrews | NobodyCam: morning :) | 15:33 |
stendulker | NobodyCam: Say user wants to tune the power NIC and processor settings | 15:33 |
stendulker | there are multiple tunables names within power, NIC and processor and users would want to use different combinations | 15:34 |
stendulker | so the different combinations could become individual capabilities? | 15:35 |
JayF | Yes, absolutely | 15:36 |
JayF | Or as separate, so say for power, you could have a 'power-saving power-medium power-performance' capability set | 15:37 |
JayF | or something better named :) | 15:37 |
stendulker | JayF: Can a single flavor have multiple capabilities? | 15:37 |
JayF | I think we'd want to do it that way, yes | 15:38 |
*** killer_prince is now known as lazy_prince | 15:38 | |
JayF | but given we're talking about somethign that hasn't even been codified to a spec, anything is possible as long as it fits within the scope and abstractions of Ironic :P | 15:38 |
stendulker | JayF: I understand, trying to understand the idea :) | 15:39 |
JayF | The big issue is just that the idea of what a 'setting' is has to be abstracted so it could work for a set of devices, not just one | 15:39 |
JayF | and that Ironic-itself would directly list a small number of them, and drivers could expose more as needed | 15:40 |
*** Hefeweizen has quit IRC | 15:41 | |
JayF | power-saving vs power-performance are even capabilities I could see making a whole lot of sense on the global scale :) | 15:41 |
stendulker | JayF: may be better to delegate that responsibility to the driver which is closest to the node and they can handle for individual vendors | 15:42 |
JayF | the only difference between global vs driver-specific would be that all drivers would be (forced || strongly encouraged) to implement global ones | 15:43 |
JayF | so you would still have the driver close to the node deciding what that means, in a specific sense | 15:43 |
stendulker | JayF: That is possible by making certain settings as mandatory ones. | 15:44 |
NobodyCam | JayF: as a host would a setting like power saving/performance be something you would bill differently for, or even something you want run from specific raq's | 15:45 |
JayF | stendulker: exactly | 15:46 |
stendulker | JayF: So necessarily, capabilities could be individual or group of settings that are part of the flavor and are completed before actual deploy operation begins. Is this understanding correct? | 15:46 |
JayF | NobodyCam: I would think more like, setting the bios settings to aggressively power save | 15:46 |
JayF | stendulker: capabilities would become a part of the ironic api that would be exposed via nova flavors and completed as part of provisioning -- so yes, that's what I'm thinking | 15:47 |
JayF | stendulker: the key thing there being that it's part of provisioning. If it's not part of or related to provisioning, it's arguably not in Ironic's scope | 15:47 |
stendulker | JayF: What would happen to deploy if the capability tuning fail? Or any of the capability itself needs a reboot to get into effect? | 15:48 |
JayF | stendulker: I was actually talking to jroll ^ about that exact possibility. I'd think you'd just do that as neccessary at deploy time | 15:49 |
*** ifarkas has quit IRC | 15:49 | |
JayF | stendulker: although, also, most bios settings would be fine to just take effect as you reboot into the instance | 15:50 |
stendulker | JayF: I did not get you fully. | 15:50 |
JayF | stendulker: meaning you could either just do a reboot during the provision to make it take effect if that's required | 15:51 |
*** BadCub has quit IRC | 15:51 | |
stendulker | JayF: yes, but if any tuning itself needs a recycle. though I do not have any example for that. | 15:51 |
JayF | stendulker: or just utilize the reboot that already happens when you're about to reboot into a customer image | 15:51 |
*** BadCub has joined #openstack-ironic | 15:52 | |
JayF | stendulker: i.e., write image to disk, change bios settings, reboot into customer image | 15:52 |
*** viktors is now known as viktors|afk | 15:52 | |
JayF | stendulker: or something like apply settings, reboot, write image, reboot into customer image | 15:52 |
*** lazy_prince is now known as killer_prince | 15:52 | |
stendulker | JayF: it should be possible to have multiple reboots within provisoning. | 15:53 |
JayF | I agree, actually :) | 15:53 |
JayF | So this sounds like it'd be an interesting spec for Kilo -- does it seem like it matches up with your use case? | 15:54 |
*** rainya has quit IRC | 15:55 | |
stendulker | JayF: Will capabilities be defined by Ironic? Or user would define it based on published list of global key/values? Can vendor publish its own key/value pairs? | 15:55 |
JayF | stendulker: I'm not 100% sure, but it would probably be done at the driver level -- which would be super easy to customize if using IPA (custom HardwareManager), but IDK how it'd work if you wanted to configure things using out of band methods (like ilo) | 15:56 |
jbjohnso | fyi, it may be pertinent to some interest around here (a place employing pyghmi and a possible contender to serve in place of complex neutron interaction) | 15:57 |
jbjohnso | https://sourceforge.net/p/xcat/wiki/Confluent/ | 15:57 |
JayF | stendulker: I'd see where and how those are defined as something that likely needing the most additional thought :) | 15:57 |
jbjohnso | It might have a bit more stuff than ironic would want to use, but my goal is to have a pretty tunable experience | 15:57 |
jbjohnso | so one could just tell it 'boot this kernel without messing with dhcp' | 15:58 |
jbjohnso | and/or 'give me a token to delegate console access to a client' | 15:58 |
NobodyCam | oh jbjohnso morning: I wanted to point out we landed this: https://github.com/openstack/ironic-specs/blob/master/specs/juno/enabling-ipmi-double-bridge-support.rst | 15:59 |
stendulker | If driver could publish possible tunables then user should be able to define its own set of capabilities using the combination of global and vendor specific tunables | 15:59 |
NobodyCam | does pyghmi expose dbl bridging? | 16:00 |
jbjohnso | NobodyCam, someone at intel submitted something I accepted it | 16:00 |
jbjohnso | NobodyCam, but I have no idea what testing it would be like | 16:00 |
JayF | stendulker: yeah, I'm not 100% sure about that, but we should get a spec up when K opens and chat about it there. Sounds like there's a happy middle ground that fits in Ironic's model and covers most, if not all, of your use case | 16:00 |
jbjohnso | NobodyCam, at the time, intel guy said it was mostly about getting at the ME in a system with ME and vendor-specific bmc mostly | 16:01 |
stendulker | JayF: yes, I think we will surely need to discuss more on this. | 16:01 |
jbjohnso | but I have no architectures that opted to use ipmi bridging for bmc sharing.. can't say more than that | 16:02 |
stendulker | JayF, NobodyCam, jroll: Thank you for your patience and helping me understand this. | 16:02 |
jbjohnso | I can't recall specifics, but there seems to be quite a few hiccups in some concepts in a bridged management situation | 16:04 |
jbjohnso | I want to say I thought SOL payload was an example where a distinct model than bridging is indicated... | 16:04 |
*** rainya has joined #openstack-ironic | 16:04 | |
*** rainya has quit IRC | 16:05 | |
jbjohnso | but haven't honestly discussed it much in depth with the platform guys | 16:05 |
bearhands | devananda: any reason you did not +A: https://review.openstack.org/#/c/111292 ? | 16:05 |
*** rainya has joined #openstack-ironic | 16:05 | |
JayF | stendulker: no problem, I wasn't sure about which way to go either which is why I brought it up last week :) nice chat :) have a good day | 16:07 |
*** Haomeng has joined #openstack-ironic | 16:08 | |
*** ndipanov is now known as ndipanoff | 16:08 | |
NobodyCam | brb | 16:08 |
JayF | devananda: very curious as to your thoughts on https://review.openstack.org/#/c/97744/10/specs/juno/ironic-ilo-virtualmedia-deploy.rst line 147 | 16:08 |
stendulker | JayF: On side note, would the capability obsolete the boot device related management APIs whcih are already defined? | 16:09 |
*** Haomeng|2 has quit IRC | 16:09 | |
JayF | stendulker: not at all, I don't think | 16:10 |
*** dkehn__ has joined #openstack-ironic | 16:10 | |
*** mdorman has joined #openstack-ironic | 16:10 | |
stendulker | JayF: Isnt that boot device could get covered in Capabilities? | 16:11 |
JayF | I'm not sure it's something we want to be user configurable | 16:11 |
JayF | it's mostly an attribute of the image used (and by extension, currently in ironic, the deploy driver used) | 16:11 |
*** dkehn_ has quit IRC | 16:13 | |
stendulker | JayF: Isnt these APIs could be used by user to configure teh same? | 16:14 |
JayF | I'm honestly not sure :( | 16:15 |
JayF | I have a meeting in a few minutes I have to prep for so can't stick around in IRC, but lets keep pondering on this, and get a spec up first thing for kilo | 16:15 |
JayF | once it opens | 16:15 |
devananda | bearhands: yep. it hadn't passed jenkins yet | 16:16 |
bearhands | devananda: jenkins will not do anything more if it failed :) | 16:17 |
bearhands | i don't see the point in waiting | 16:17 |
stendulker | JayF: Ok. Thank you for a nice discussion. | 16:17 |
*** ellenh has joined #openstack-ironic | 16:17 | |
devananda | bearhands: i know. but I wanted to see it | 16:17 |
*** dkehn__ is now known as dkehnx | 16:18 | |
bearhands | haa | 16:18 |
bearhands | i still don't get it, but okay :) | 16:18 |
bearhands | seems like a waste of time.. this could have been hitting the gate already :) | 16:18 |
*** matty_dubs is now known as matty_dubs|lunch | 16:25 | |
*** dkehnx has quit IRC | 16:28 | |
*** dkehn has joined #openstack-ironic | 16:30 | |
*** Hefeweizen has joined #openstack-ironic | 16:31 | |
*** Mikhail_D_ltp has joined #openstack-ironic | 16:40 | |
*** aswadr has quit IRC | 16:42 | |
jroll | devananda: you don't trust me to run tox? :) | 16:43 |
JayF | I don't trust our tests at all until we have tempest working against ipa :x | 16:45 |
*** eghobo has joined #openstack-ironic | 16:45 | |
jroll | that's a completely different thing :P | 16:46 |
*** derekh_ has quit IRC | 16:46 | |
* jroll runs off to hack devstack | 16:46 | |
*** stendulker has quit IRC | 16:46 | |
JayF | jroll: oh yeah, I had the second stack.sh running in a vm, I should finish that up and boot an agent :D | 16:47 |
JayF | jroll: 2014-08-01 01:04:45.395 | [ERROR] /opt/stack/devstack/lib/ironic:324 pxelinux.0 (from SYSLINUX) not found. | 16:47 |
JayF | jroll: wonder if that's a missing dep for ironic or a missing dep for ipa? probably just ironic? | 16:47 |
jroll | O.o | 16:47 |
jroll | ironic | 16:47 |
jroll | but like... I've never seen that | 16:48 |
jroll | with a fresh cloud server, even | 16:48 |
jroll | are you following the ironic devstack guide? | 16:48 |
JayF | I cloned devstack, ran stack.sh. Did your steps including replacing my existing localrc (excepting creds) and reran stack.sh | 16:48 |
jroll | "excepting creds"? | 16:49 |
JayF | meaning I had already set passwords for some things | 16:49 |
JayF | so I kept my passwords instead of using yours | 16:49 |
*** Mikhail_D_ltp has quit IRC | 16:49 | |
jroll | oh, lame | 16:49 |
jroll | password is the best password | 16:49 |
jroll | JayF: you on 12.04 or 14.04? | 16:50 |
jroll | or... something else? | 16:50 |
JayF | 14.04, using p1-8gb w/pvhvm | 16:51 |
JayF | after apt-get install syslinux it appears to be continuing | 16:51 |
jroll | weird | 16:51 |
*** MattMan has left #openstack-ironic | 16:51 | |
* jroll shrugs | 16:51 | |
openstackgerrit | A change was merged to openstack/ironic: Remove dbapi calls from agent driver https://review.openstack.org/111292 | 16:56 |
*** bvivek has quit IRC | 16:56 | |
NobodyCam | https://wiki.openstack.org/wiki/Blazar | 16:57 |
*** Nisha has joined #openstack-ironic | 16:57 | |
NobodyCam | wtf https://www.openstack.org/vote-paris/Presentation/astrologer | 17:04 |
jroll | NobodyCam: blazar looks.... interesting | 17:06 |
*** ndipanoff has quit IRC | 17:06 | |
jroll | astrologer looks LOL | 17:06 |
NobodyCam | jroll: ya... | 17:07 |
NobodyCam | :/ | 17:07 |
jroll | aaand googling his name (not clicking links) logged me out in os x D: | 17:09 |
jroll | wtf | 17:09 |
jroll | probably unrelated but wtf | 17:09 |
*** penick has joined #openstack-ironic | 17:11 | |
*** mdorman has quit IRC | 17:12 | |
*** scubacuda has joined #openstack-ironic | 17:12 | |
*** mdorman has joined #openstack-ironic | 17:16 | |
NobodyCam | jroll: its written in the stars | 17:18 |
jroll | lol | 17:19 |
*** mdorman has quit IRC | 17:21 | |
matty_dubs|lunch | Oh man, this would be an awesome session | 17:21 |
JayF | We could ask them to put together our roadmap for kilo | 17:22 |
JayF | since they'd already know what we'd get done | 17:22 |
matty_dubs|lunch | LOL | 17:22 |
jroll | hahaha | 17:22 |
*** Alexei_9871 has quit IRC | 17:24 | |
*** dkehn is now known as dkehnx | 17:28 | |
matty_dubs|lunch | I seriously think it would be awesome if this guy had a booth | 17:29 |
matty_dubs|lunch | Though I'd hate to reward spammers | 17:29 |
*** mdorman has joined #openstack-ironic | 17:29 | |
*** matty_dubs|lunch is now known as matty_dubs | 17:30 | |
NobodyCam | :) | 17:30 |
Shrews | i love that he offers a 101% guarantee | 17:31 |
Shrews | that extra 1%, man.... | 17:31 |
*** mmitchell has quit IRC | 17:31 | |
jroll | matty_dubs: I'd bet he's not the only spammer submitting talks :P | 17:32 |
adam_g | jroll, re, 'pxelinux.0 (from SYSLINUX) not found.' and other things that require stuff from packages, make sure to delete devstack/.prereqs before re-running devstack. i was hitting the same issue yesterday. | 17:32 |
adam_g | er JayF ^ | 17:32 |
jroll | huh, I didn't know that existed | 17:32 |
*** mdorman has quit IRC | 17:33 | |
adam_g | me either. :) it leaves some time stamp there and only installs package dependencies on re-run if some amount of time has passed | 17:33 |
*** mdorman has joined #openstack-ironic | 17:33 | |
JayF | adam_g: nice, thanks | 17:34 |
NobodyCam | adam_g: jroll: have you seen : https://bugs.launchpad.net/tripleo/+bug/1351010 | 17:34 |
adam_g | NobodyCam, no i haven't. where did syslinux get bumped to v6? debian? | 17:34 |
jroll | NobodyCam: oh goody | 17:35 |
NobodyCam | not sure it has been ... I just saw that lastnight | 17:35 |
*** mdorman_ has joined #openstack-ironic | 17:36 | |
*** mmitchell has joined #openstack-ironic | 17:38 | |
*** mdorman has quit IRC | 17:38 | |
*** mdorman_ is now known as mdorman | 17:38 | |
*** mdorman has quit IRC | 17:40 | |
*** mdorman has joined #openstack-ironic | 17:40 | |
devananda | NobodyCam: http://packages.ubuntu.com/trusty/utils/syslinux-common IIUC this says it is still syslinux 5 | 17:42 |
devananda | 4 | 17:42 |
*** Shrews has quit IRC | 17:43 | |
adam_g | debian's bumped to 3:6.03~pre18+dfsg-1 | 17:45 |
*** rameshg87 has joined #openstack-ironic | 17:46 | |
devananda | urgh | 17:49 |
*** Shrews has joined #openstack-ironic | 17:49 | |
rameshg87 | JayF, devananda, hi | 17:50 |
devananda | adam_g: wheezy is still 4. jessie is 6. yes? | 17:51 |
devananda | ah, and so is sid | 17:51 |
devananda | ok. taggign ironic on this | 17:51 |
adam_g | devananda, yup | 17:52 |
NobodyCam | jroll: the dib ipa ramdisk has no /usr at all | 17:59 |
rameshg87 | devananda, request your thoughts on comment on https://review.openstack.org/#/c/97744/10/specs/juno/ironic-ilo-virtualmedia-deploy.rst (L79) | 18:03 |
NobodyCam | jroll: I think I may need to fiddle around here, to fix that | 18:04 |
NobodyCam | https://github.com/openstack/diskimage-builder/blob/master/lib/ramdisk-functions#L49 | 18:04 |
rameshg87 | devananda, JayF & lifeless suggests we build an image from kernel/ramdisk at run time and then attach it to the baremetal node (which you were probably against at the time of patch set 2) | 18:05 |
JayF | NobodyCam: so where are the python packages pip installed to? | 18:08 |
*** athomas has quit IRC | 18:10 | |
openstackgerrit | Ramakrishnan G proposed a change to openstack/ironic-specs: iLO-IPA Deploy Driver https://review.openstack.org/108445 | 18:11 |
NobodyCam | JayF: I am assuming that the /usr is just not linked in the final ramdisk. I am checking on that now | 18:12 |
JayF | ah, okay | 18:13 |
NobodyCam | humm : No distributions matching the version for oslo.config>=1.4.0.0a3 (from ironic-python-agent==50b8f25) | 18:14 |
JayF | NobodyCam: you need a newer version of pip | 18:15 |
JayF | NobodyCam: this is why we had to bump the agent container to trusty | 18:15 |
JayF | NobodyCam: so we could land the global reqs change which forces that version of oslo.config, which is apparently only packaged as a wheel file | 18:15 |
*** amitpp has joined #openstack-ironic | 18:17 | |
NobodyCam | JayF: will "sudo pip install pip --upgrade" work for saucy | 18:20 |
* NobodyCam wants to not reformat' | 18:21 | |
JayF | NobodyCam: in the container, that moved my pip binary from /usr/bin/pip to /usr/local/bin/pip and 'broke' just running "pip" without a path, so I didn't do that for the container | 18:21 |
JayF | NobodyCam: I can tell you that the trusty one Just Works(tm) | 18:21 |
*** amitpp has quit IRC | 18:23 | |
NobodyCam | JayF: what version of pip do I need. the upgrade line seem to not ave broken my pip but I still get error about oslo.config | 18:25 |
NobodyCam | my pip is now 1.5.6 was 1.5.2 | 18:25 |
JayF | let me see what the last agent container built with | 18:25 |
JayF | root@e432ea033395:/# pip --version | 18:27 |
JayF | pip 1.5.4 from /usr/lib/python2.7/dist-packages (python 2.7) | 18:27 |
JayF | NobodyCam: so obviously something is a little different | 18:28 |
NobodyCam | yep let me see if I can build trusty | 18:28 |
rameshg87 | JayF, just a question | 18:28 |
JayF | NobodyCam: I actually have to leave very shortly, but you can see the exact things running in my container in the dockerfile | 18:28 |
rameshg87 | JayF, regarding https://review.openstack.org/#/c/97744/10/specs/juno/ironic-ilo-virtualmedia-deploy.rst | 18:28 |
JayF | NobodyCam: and that starts from a really barebones trusty container | 18:29 |
JayF | rameshg87: if it's quick I have a minute | 18:30 |
rameshg87 | JayF, don't think it will be over in a minute, then i will leave you rather :-( | 18:30 |
rameshg87 | JayF, do you have plans to login later today ? | 18:30 |
*** Nisha has quit IRC | 18:30 | |
NobodyCam | brb | 18:30 |
JayF | rameshg87: if you put the comments/discussion in the spec I'll absolutely check in on it over the weekend | 18:31 |
rameshg87 | JayF, okay here is a quick one .. | 18:31 |
JayF | rameshg87: I try to keep low-latency reviewing on stuff that I know people (aka you) are looking at quickly :) | 18:31 |
rameshg87 | JayF, there were two concerns in the end if i get it right | 18:31 |
rameshg87 | JayF, 1 - the boot image not persistent across reboots, 2 - building the boot image dynamically inorder to be same as pxe deployement | 18:32 |
rameshg87 | JayF, for #2 we will check with devananda to get his thoughts | 18:33 |
JayF | #1 I feel pretty strongly we should set the state of the machine to continue to boot whatever iso is configured until ironic reconfigures it | 18:33 |
rameshg87 | JayF, for #1 i would leave a comment, but i can make it persistent by use BOOT_ALWAYS option and generating swift temp url long enough | 18:33 |
rameshg87 | JayF, swift temp url long reasonbly long enough so that it can stay until the user releases the machine | 18:34 |
JayF | oooh. I didn't think about the possibility of swift temp url expiration. | 18:34 |
rameshg87 | JayF, the swift temp url will expire after the given time ... | 18:35 |
JayF | Yeah, I hadn't thought about that at all. Does the iLO not cache the image? | 18:35 |
rameshg87 | JayF, no it doesn't | 18:35 |
JayF | I think some amount of this depends on the behavior of the iLO, which I'm sadly not as up on | 18:35 |
rameshg87 | JayF, the ilo just uses the http location given by swift temp url and uses it as virtual cdrom | 18:36 |
jbjohnso | I don't know about iLO, but if the image is sufficently small it can be uploaded to IMM | 18:36 |
rameshg87 | JayF, what is IMM ? | 18:36 |
jbjohnso | rameshg87, it's IBM's x86 service processor | 18:36 |
jbjohnso | we upload a ~700 kilobyte ipxe payload | 18:36 |
jbjohnso | which has things like a CA cert to trust and private node credentials | 18:37 |
rameshg87 | JayF, jbjohnso, so you mean to cache the image somewhere ? | 18:37 |
jbjohnso | rameshg87, the IMM has 50 MB of space that can be uploaded to via an http api | 18:37 |
JayF | rameshg87: Do floppy images work the same way? | 18:37 |
JayF | rameshg87: like can floppy images be cached? | 18:37 |
rameshg87 | JayF, yes, it works the same way .. | 18:38 |
JayF | rameshg87: that really introduces a huge limitation | 18:38 |
jbjohnso | I suggest that a small ISO scheme | 18:38 |
jbjohnso | with the mount semantics dealt with separately | 18:38 |
jbjohnso | would enable best available | 18:38 |
rameshg87 | JayF, there might be some caching, but it is not predictable i guess. the http url needs to be accessible. | 18:38 |
*** romcheg1 has joined #openstack-ironic | 18:38 | |
JayF | rameshg87: if you provision a customer node, and that customer reboots after the swift temp url for the boot iso expires, the customer machine becomes unusable | 18:39 |
NobodyCam | JayF: trusty built | 18:39 |
*** tatyana has joined #openstack-ironic | 18:39 | |
JayF | NobodyCam: \o/ | 18:39 |
rameshg87 | JayF, if the reboot method in ironic takes care of that, then is it a real concern ? | 18:39 |
jbjohnso | surprised iLO can't do the same trick | 18:39 |
JayF | rameshg87: a *customer* in-band can restart an image | 18:39 |
JayF | rameshg87: aka a 'reboot' from the command line on a provisioned machine | 18:40 |
*** romcheg1 has quit IRC | 18:40 | |
JayF | rameshg87: and if the boot [floppy || iso] is gone, it won't boot | 18:40 |
*** romcheg1 has joined #openstack-ironic | 18:40 | |
rameshg87 | JayF, i agree.. | 18:40 |
JayF | rameshg87: which means that URL has to be forever-persistent... which shouldn't be a problem for an image with a kernel and initrd, but we should call that out | 18:40 |
JayF | rameshg87: you can't make a swift temp url that never expires, but you can make one that will effectively last for longer than the machine | 18:41 |
rameshg87 | JayF, then can't we keep the swift-temp-url long enough ? | 18:41 |
jbjohnso | so I was thinking of extending pyghmi to automate upload of .iso images and the like to endpoints... | 18:41 |
rameshg87 | jbjohnso, i think ilo needs the url to be always accessible | 18:41 |
jbjohnso | but I could only do the IBM/Lenovo backend... | 18:42 |
JayF | rameshg87: I think you can't make it *unlimited*, but you can make it long enough to not matter so much | 18:42 |
jbjohnso | rameshg87, I don't care about iLO ;) | 18:42 |
*** lsmola has quit IRC | 18:42 | |
jbjohnso | rameshg87, if HP wants to implement the backend though... | 18:42 |
rameshg87 | jbjohnso, :-) | 18:42 |
JayF | rameshg87: I'd suggest you add to the spec that the temp-url for the kernel ramdisk be defaulted to a long time | 18:42 |
JayF | rameshg87: and that the deploy disk be setup with a temp-url of something like an hour, and persisted | 18:42 |
rameshg87 | JayF, yes, that can be done .. | 18:43 |
*** romcheg2 has joined #openstack-ironic | 18:43 | |
*** romcheg1 has quit IRC | 18:43 | |
JayF | rameshg87: then I think that would resolve my issue with #1, and for #2, we'll have to see what devananda says... | 18:43 |
NobodyCam | brb | 18:44 |
devananda | #2? | 18:44 |
JayF | devananda: https://review.openstack.org/#/c/97744/10/specs/juno/ironic-ilo-virtualmedia-deploy.rst | 18:44 |
rameshg87 | devananda, we were discussing about comment on L147 ^^ | 18:44 |
jbjohnso | how small is your boot.iso? | 18:46 |
devananda | JayF: so right now, each "boot driver" (yes, i'm using a new term here) requires a different image | 18:46 |
rameshg87 | jbjohnso, usually 6-7 MiB | 18:46 |
JayF | devananda: I'm OK with it requiring a separate image; just I thought the suggestion was a good one given ironic would hve to generate floppy images anyway | 18:47 |
jbjohnso | rameshg87, that's surprising, bigger than I'd expect one way, smaller than I'd expect the other | 18:47 |
devananda | PXE driver requires kernel & initrd made by dib/elements/ironic-deploy-ramdisk | 18:47 |
jbjohnso | 674K is one of mine for rhels6 deploy | 18:47 |
jbjohnso | but if I did it with kernel and initrd onboard it would be bigger.. | 18:48 |
JayF | devananda: I would propose that this driver pull those initrd/kernel down, embed them in a floppy boot image, and mount that via ilo | 18:48 |
JayF | devananda: rather than having a new set of DIB elements to package them into an iso || floppy image | 18:49 |
devananda | JayF: not via floppy. via cd-rom. | 18:49 |
JayF | devananda: we would change to via floppy as well if we did that | 18:49 |
JayF | devananda: so ironic would only have to build floppy images, which is already in scope of that spec | 18:49 |
JayF | and per rameshg87, iLO does not impose size restriction on virtual floppies | 18:49 |
devananda | JayF: except it's building a floppy image right now just for a specific vector -- load keys over a secure channel | 18:50 |
devananda | JayF: this conflates that mechanism to deliver non-secure payloads | 18:50 |
rameshg87 | JayF, sorry i am yet to confirm that it can put kernel/ramdisk into floppy image, but looks possible to me .. | 18:50 |
JayF | devananda: if that distinction crosses a scope line, I'm OK with it being done the existing proposed way | 18:51 |
JayF | devananda: this was originally lifeless's suggestion, I just picked it up becuase I thought it was worthwhile :) if it's an issue we can do it as written currently | 18:51 |
JayF | and generate the image (using DIB) beforehand | 18:51 |
rameshg87 | JayF, the initial plan was to make dib capable of giving out boot iso | 18:52 |
jbjohnso | I'd say that an .iso format would look less... bizarre.... | 18:52 |
devananda | JayF: I don't see any particular benefit to doing it the way lifeless/you are proposing, and I see some operator confusion and additional overhead. | 18:52 |
JayF | ok then :) | 18:53 |
devananda | what I'd really like to see in Kilo is the iLO attach-virtual-floppy mechanism become a separate interface | 18:53 |
rameshg87 | JayF, additional concern was the kernel/initrd will be duplicated for each instance | 18:53 |
rameshg87 | JayF, if we dynamically generate image for each instance | 18:53 |
devananda | something like PassSecureMedia (or some better name than that) | 18:53 |
jbjohnso | rameshg87, which is a good reason to contemplate the concept I describe | 18:53 |
JayF | that's fine :) I'm totally sold on going back to building the iso with the image now :) no need to keep convincing me, lol | 18:53 |
rameshg87 | JayF, :-) | 18:54 |
jbjohnso | rameshg87, which basically keeps the flow for things identical to pxe except without dhcp, proxydhcp, or tftp | 18:54 |
rameshg87 | JayF, just was saying my point again :-) | 18:54 |
jbjohnso | rameshg87, a ~1MB unique payload per target or so... | 18:54 |
rameshg87 | jbjohnso, okay | 18:55 |
jbjohnso | made a touch easier if Michael Brown's recent endeavor pans out... | 18:55 |
jbjohnso | but only for UEFI style boots | 18:55 |
jbjohnso | BIOS style is a pretty hopeless cause with the way entry vector to entry would work | 18:56 |
jbjohnso | well, not hopeless, you could build ipxe with drivers instead of duing undi, but it'd get bigger | 18:56 |
rameshg87 | devananda, just one more thing if you have time. probably this is something we discussed long back. | 18:56 |
rameshg87 | devananda, regarding comment on https://review.openstack.org/#/c/97744/10/specs/juno/ironic-ilo-virtualmedia-deploy.rst (L79) | 18:57 |
devananda | oh,the boot-once or always-boot-from | 18:58 |
rameshg87 | devananda, yes | 18:58 |
devananda | so in a broader context, i think we need to be able to determine that programatically, regardless of the driver | 18:58 |
rameshg87 | devananda, yes we can .. | 18:59 |
rameshg87 | devananda, but JayF concern was if the user does an in-band reboot on baremetal node, the machine wouldn't boot | 18:59 |
devananda | AIUI, PXE driver always boots from PXE, IPA driver will boot from PXE only when required to (user image is not going to be net booted, ever) | 18:59 |
devananda | rameshg87: so that depends on the BIOS settings. Will the local drives be *removed* from the boot options? | 19:00 |
JayF | but fwiw, IPA does always set persistent=true when calling the force-pxe option | 19:00 |
JayF | because it will be an explicit post-deploy ironic call to flip it back to disk | 19:00 |
rameshg87 | devananda, no the local drives are not removed from boot options | 19:00 |
devananda | JayF: right. when deploy is done, you set boot optionsback to disk | 19:00 |
devananda | JayF: whereas the PXE driver does not (today) | 19:01 |
jbjohnso | btw, how much of this is UEFI style versus BIOS boot? | 19:01 |
rameshg87 | devananda, if a user deploys an fs-image, the bm node will need to be booted from virtual media everytime for ilo driver | 19:01 |
JayF | Yes :) my concern in that spec for rameshg87 was about if the node reboots due to non-ironic reasons (power cycle in rack, in-band reboot via IPA, etc) it should boot back into the state it was before | 19:01 |
devananda | so it sounds like the proposal for the iLO driver is: if it uses PXE, it's going to break when the user reboots locally. if it uses IPA, it will boot locally just fine. | 19:01 |
jbjohnso | I ask because efibootmgr with UEFI boot services means you can rejigger things in an utterly agnostic fashion at the iend | 19:01 |
jbjohnso | UEFI runtime service I mean | 19:01 |
devananda | jbjohnso: all BIOS today | 19:01 |
jbjohnso | devananda, that's sad... | 19:02 |
rameshg87 | devananda, exactly...s/PXE/virtual media boot/ | 19:02 |
devananda | jbjohnso: so come help add UEFI support. there's a proposal from HP, but we haven't had time to review it | 19:02 |
devananda | jbjohnso: or more clearly, come help review specs and code for the project. there's not enough of us reviewing to keep up with demand as it is. | 19:03 |
*** dkehn__ has joined #openstack-ironic | 19:03 | |
jbjohnso | well, just keep it in the back of your mind that efibootmgr in-band when possible works in interestingly awesome ways | 19:03 |
rameshg87 | jbjohnso, https://review.openstack.org/99850 uefi review :-) | 19:03 |
JayF | I have to leave for the day, thanks for the good chat on ilo spec, I am eager for it to land and will check on it this weekend :) | 19:04 |
devananda | rameshg87: er, right. I meant, if it uses iSCSI as the deploy mechanism, it'll need to boot from iLO every time | 19:04 |
devananda | rameshg87: and if it uses IPA as the deploy mechanism, it'll be able to boot from local disk | 19:04 |
rameshg87 | devananda, an alternative to that suggested was to make a swift-temp-url looong enough and keep it attached to the ilo everytime | 19:04 |
rameshg87 | JayF, thanks ... | 19:04 |
rameshg87 | devananda, exactly .. | 19:04 |
devananda | rameshg87: until the iSCSI deploy method gets support added for local boot loaders | 19:05 |
rameshg87 | devananda, yes, but is there a plan to do so ? | 19:05 |
devananda | rameshg87: "I wish that it would happen." -- does that count as a plan? :) | 19:05 |
*** dkehnx has quit IRC | 19:06 | |
rameshg87 | devananda, yes it does, but not for juno i guess :-) | 19:06 |
rameshg87 | devananda, we can try to get in a spec early for K | 19:06 |
devananda | rameshg87: sounds good | 19:06 |
jbjohnso | devananda, I commented some | 19:07 |
jbjohnso | devananda, in short, that could be done in a very auto-sensing way and require less configuration by operator | 19:07 |
rameshg87 | devananda, but for now for the ilo driver does this look fine ? - "make a swift-temp-url looong enough and keep it attached to the ilo everytime" | 19:07 |
devananda | rameshg87: it's hackish and prone to edge failures | 19:11 |
devananda | rameshg87: curious, does that even need to be a swift tempurl? | 19:12 |
devananda | rameshg87: if the boot.iso is shared across machines (eg, no private data on it) then why not use the glance URL to it? | 19:12 |
rameshg87 | devananda, the images are expected to be backed by glance, so swift gives away http access easily through temp-url | 19:13 |
rameshg87 | devananda, s/backed by glance/backed by swift/ | 19:13 |
rameshg87 | devananda, the boot.iso is shared across machines | 19:14 |
devananda | rameshg87: right. so why does it need a temp url? | 19:14 |
rameshg87 | devananda, but the url scheme needs to be http for ilo to access it | 19:14 |
rameshg87 | devananda, glance will require authentication in normal mode, right ? | 19:14 |
rameshg87 | devananda, swift anyway provides the feature of temp url which guarantees http access for the images for the specified duration | 19:15 |
*** tatyana has quit IRC | 19:15 | |
rameshg87 | devananda, so is there a advantage for glance over swift-temp-url ? | 19:16 |
devananda | rameshg87: swift temp-url encodes the access in the URL, rather than requiring a separate X-Auth-Token header, which iLO does not support sending | 19:16 |
rameshg87 | devananda, yes .. | 19:16 |
devananda | rameshg87: does a public glance image require an X-Auth-Token header to access it directly? What about a swift object that is made public? | 19:17 |
devananda | rameshg87: what I'm getting at is the boot.iso does not need to be private | 19:17 |
devananda | rameshg87: Setting a long expiration time is a work-around, but it's going to lead to edge cases where it fails | 19:18 |
devananda | rameshg87: eg, if someone rotates the signing key used to create temp-url's, it will invalidaet previously generated ones | 19:18 |
*** Mikhail_D_ltp has joined #openstack-ironic | 19:18 | |
devananda | rameshg87: for a short-duration object, like the vfat image, that's fine. for long-running instances, this would cause them to be unrebootable | 19:18 |
rameshg87 | devananda, yes i agree .. | 19:19 |
rameshg87 | devananda, but i guess for glance/swift, we will still need some specific configuration to directly access the image data from either glance/swift from its APIs | 19:20 |
rameshg87 | devananda, --is-public says "Makes an image accessible for all the tenants" | 19:22 |
rameshg87 | devananda, can't we just offer to boot from virtual media everytime with "reboot from ironic" attaching the boot iso on demand | 19:25 |
devananda | rameshg87: sure. except we can't control when the user issues a local reboot | 19:26 |
*** tatyana has joined #openstack-ironic | 19:26 | |
rameshg87 | devananda, yes, the user can still trigger a reboot, but may be trigger a "vendor passthru" before rebooting inband which attaches boot iso ? | 19:27 |
devananda | rameshg87: in any case, I don't want to hold up driver over this, but it definitely needs to be addressed at some point | 19:27 |
devananda | rameshg87: please add it as a known limitation right now | 19:28 |
rameshg87 | devananda, if they forget to do so, they always have a second chance to boot it from ironic again | 19:28 |
devananda | rameshg87: that could be a note on the spec. and it should be(come) a bug in launchpad | 19:28 |
devananda | rameshg87: right. there is an easy work-around -- just ask ironic to reboot it | 19:28 |
*** tatyana has quit IRC | 19:28 | |
rameshg87 | devananda, yes .. | 19:28 |
rameshg87 | devananda, okay .. | 19:28 |
devananda | rameshg87: if this code were already in production, I would classify it as a Medium bug | 19:28 |
devananda | affects-some-users, has-workaround | 19:28 |
rameshg87 | devananda, okay .. | 19:29 |
devananda | so as long as that's documented, I'm OK to proceed | 19:29 |
rameshg87 | devananda, "a "vendor passthru" before rebooting inband which attaches boot iso" - does it make sense to have it right now ? | 19:29 |
devananda | rameshg87: no | 19:29 |
devananda | rameshg87: if the user is going to issue an API call to reboot, they should just use the existing reboot mechanism | 19:30 |
devananda | rameshg87: no need to issue an API call to vendor passthru, and _then_ reboot inband | 19:30 |
rameshg87 | devananda, okay, i was just wondering if there was some software update that was going to trigger reboot automatically on the bm node | 19:30 |
rameshg87 | devananda, some inband reboots that are not in user's control | 19:30 |
rameshg87 | devananda, and ironic doesn't support soft reboot right now - it doesn't reboot in the "nice" way | 19:31 |
devananda | rameshg87: so, on that last comment, actually it looks like iLO does not support "hard" reboot | 19:31 |
devananda | on the hardware in the tripleo CI cloud, they observe that an "ipmi chassis power off" command actually issuse an ACPI soft-off | 19:32 |
*** dkehn__ is now known as dkehnx | 19:32 | |
rameshg87 | devananda, oh okay .. | 19:32 |
devananda | that seems like a bug to me, but i haven't dug into it more | 19:33 |
devananda | anyway, I need to go AFK for a few hours | 19:33 |
rameshg87 | devananda, okay, then for now i will file a bug for now | 19:33 |
rameshg87 | devananda, and refer it as a limitation with a workaround and repost the spec .. | 19:33 |
devananda | rameshg87: thanks! | 19:34 |
rameshg87 | devananda, thanks a lot :-) | 19:34 |
*** rwsu has joined #openstack-ironic | 19:37 | |
*** pcrews has quit IRC | 19:39 | |
*** Mikhail_D_ltp has quit IRC | 19:45 | |
Shrews | Bug 1351026 - 483 fails in 24hrs | 19:46 |
Shrews | yowzers | 19:46 |
Shrews | lol. the fix is to skip the test :) | 19:47 |
NobodyCam | lol, Shrews no no the correct fix is to edit the test so it passes LOL.... | 19:50 |
NobodyCam | :-p | 19:50 |
Shrews | :) | 19:51 |
*** jcoufal has quit IRC | 19:56 | |
*** jcoufal has joined #openstack-ironic | 19:56 | |
openstackgerrit | Ramakrishnan G proposed a change to openstack/ironic-specs: iLO Virtual Media iSCSI Deploy Driver https://review.openstack.org/97744 | 20:07 |
openstackgerrit | A change was merged to openstack/python-ironicclient: Add {set,get}_boot_device and get_supported_boot_devices https://review.openstack.org/109640 | 20:08 |
openstackgerrit | Ramakrishnan G proposed a change to openstack/ironic-specs: iLO-IPA Deploy Driver https://review.openstack.org/108445 | 20:08 |
*** rameshg87 has quit IRC | 20:09 | |
*** f13o_ has joined #openstack-ironic | 20:12 | |
*** romcheg2 has quit IRC | 20:18 | |
*** funid has joined #openstack-ironic | 20:32 | |
*** pcrews has joined #openstack-ironic | 20:39 | |
*** derekh_ has joined #openstack-ironic | 20:40 | |
*** jcoufal has quit IRC | 20:43 | |
*** jgrimm has quit IRC | 20:45 | |
*** ellenh has quit IRC | 20:46 | |
*** penick has quit IRC | 20:50 | |
*** marzif_ has joined #openstack-ironic | 21:02 | |
*** funid has left #openstack-ironic | 21:24 | |
*** matty_dubs is now known as matty_dubs|gone | 21:26 | |
*** jasondotstar has quit IRC | 21:34 | |
*** romcheg1 has joined #openstack-ironic | 21:34 | |
*** igordcard has quit IRC | 21:36 | |
*** pcrews has quit IRC | 21:41 | |
*** igordcard has joined #openstack-ironic | 21:50 | |
openstackgerrit | Roman Prykhodchenko proposed a change to openstack/ironic: Add charset and engine settings to every table https://review.openstack.org/111402 | 22:06 |
*** romcheg1 has quit IRC | 22:39 | |
*** jistr has quit IRC | 22:50 | |
*** scubacuda has quit IRC | 23:08 | |
*** mdorman has quit IRC | 23:19 | |
*** pcrews has joined #openstack-ironic | 23:23 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!