Tuesday, 2016-12-13

*** rpioso has quit IRC00:00
*** rama_y_ has quit IRC00:03
*** nicodemos has quit IRC00:04
*** mtanin___ has joined #openstack-ironic00:26
*** mtanino has quit IRC00:28
*** lindycoder has joined #openstack-ironic00:43
*** hw_wutianwei has joined #openstack-ironic00:44
openstackgerritMerged openstack/python-ironicclient: Updated from global requirements  https://review.openstack.org/40588700:46
*** ijw has quit IRC00:49
*** baoli has joined #openstack-ironic00:50
*** ijw_ has joined #openstack-ironic00:51
*** SerenaFeng has joined #openstack-ironic00:53
*** zhs__ has joined #openstack-ironic00:53
*** baoli has quit IRC00:55
*** hoangcx_ has joined #openstack-ironic00:55
*** ijw_ has quit IRC00:55
*** vsaienko has quit IRC00:56
*** zhs_ has quit IRC00:57
*** rbudden has quit IRC01:00
*** yufei_ has quit IRC01:04
*** aNuposic has quit IRC01:04
*** ijw has joined #openstack-ironic01:06
*** rama_y has joined #openstack-ironic01:08
*** zhangjl has joined #openstack-ironic01:10
*** yuanying has quit IRC01:11
*** ijw has quit IRC01:11
*** yuanying has joined #openstack-ironic01:11
*** fragatin_ has joined #openstack-ironic01:12
*** tuanluong has joined #openstack-ironic01:12
*** fragatin_ has quit IRC01:14
*** fragatina has quit IRC01:15
*** fragatina has joined #openstack-ironic01:15
*** jcoufal has quit IRC01:15
*** yufei_ has joined #openstack-ironic01:17
*** ijw has joined #openstack-ironic01:22
*** ijw has quit IRC01:27
openstackgerritOpenStack Proposal Bot proposed openstack/ironic-ui: Updated from global requirements  https://review.openstack.org/40997201:28
*** srobert has joined #openstack-ironic01:33
*** srobert has quit IRC01:33
*** srobert has joined #openstack-ironic01:33
*** rajinir has quit IRC01:36
*** baoli has joined #openstack-ironic01:36
*** Sukhdev has joined #openstack-ironic01:38
*** ijw has joined #openstack-ironic01:38
*** Sukhdev has quit IRC01:38
*** zhangjl has quit IRC01:43
*** ijw has quit IRC01:43
*** aNuposic has joined #openstack-ironic01:46
*** srobert has quit IRC01:48
*** hoangcx has quit IRC01:48
*** ijw has joined #openstack-ironic01:54
*** dsneddon has quit IRC01:55
*** rama_y has quit IRC01:58
*** ijw has quit IRC01:59
*** mtanino has joined #openstack-ironic02:03
*** ijw has joined #openstack-ironic02:03
*** mtanin___ has quit IRC02:04
*** fragatina has quit IRC02:06
*** fragatina has joined #openstack-ironic02:07
*** zhangjl has joined #openstack-ironic02:09
*** baoli has quit IRC02:10
*** yufei has joined #openstack-ironic02:11
*** yuanying has quit IRC02:11
*** Syed__ has quit IRC02:15
*** jkilpatr has quit IRC02:21
*** rloo has quit IRC02:22
*** gcb has joined #openstack-ironic02:25
*** aNuposic has quit IRC02:34
*** mtanino has quit IRC02:39
openstackgerritNaohiro Tamura proposed openstack/ironic: Generic power interface for soft reboot and soft power off  https://review.openstack.org/21673002:44
openstackgerritNaohiro Tamura proposed openstack/ironic: Ipmitool power driver for soft reboot and soft power off  https://review.openstack.org/21673802:45
*** chlong has quit IRC02:45
*** ijw has quit IRC02:46
openstackgerritNaohiro Tamura proposed openstack/ironic: iRMC power driver for soft reboot and soft power off  https://review.openstack.org/21674302:47
openstackgerritNaohiro Tamura proposed openstack/ironic: Update the existing APIs due to adding get_supported_power_states  https://review.openstack.org/38219402:48
*** gcb has quit IRC02:56
*** chlong has joined #openstack-ironic02:59
*** zhangjl1 has joined #openstack-ironic03:09
*** zhangjl has quit IRC03:10
*** gcb has joined #openstack-ironic03:13
*** pmannidi_ has joined #openstack-ironic03:18
*** pmannidi has quit IRC03:19
*** nicodemos has joined #openstack-ironic03:26
*** raginbajin has quit IRC03:27
*** raginbajin has joined #openstack-ironic03:32
*** vikrant has joined #openstack-ironic03:35
*** harlowja has quit IRC03:43
*** nicodemos has quit IRC03:53
*** nicodemos has joined #openstack-ironic03:54
*** lindycoder has quit IRC04:00
tuanluongMorning Ironic04:04
*** adreznec has quit IRC04:18
*** adreznec has joined #openstack-ironic04:21
*** harlowja has joined #openstack-ironic04:21
*** SerenaFeng has quit IRC04:22
*** links has joined #openstack-ironic04:22
*** ijw has joined #openstack-ironic04:25
*** ijw has quit IRC04:30
*** yuanying has joined #openstack-ironic04:33
*** hoangcx_ is now known as hoangcx04:42
*** deray has joined #openstack-ironic04:47
*** amotoki has joined #openstack-ironic04:55
*** harlowja has quit IRC05:08
*** moshele has joined #openstack-ironic05:18
*** krtaylor has quit IRC05:19
*** fragatina has quit IRC05:26
*** fragatina has joined #openstack-ironic05:26
*** SerenaFeng has joined #openstack-ironic05:39
*** harlowja has joined #openstack-ironic05:56
*** vsaienko has joined #openstack-ironic05:57
*** nmathew has joined #openstack-ironic05:57
*** vsaienko has quit IRC05:59
*** tuanluong has quit IRC06:01
*** hoangcx has quit IRC06:01
*** hoangcx has joined #openstack-ironic06:01
*** tuanluong has joined #openstack-ironic06:01
*** SerenaFeng has quit IRC06:03
*** gcb has quit IRC06:04
*** yuanying has quit IRC06:12
*** yuanying has joined #openstack-ironic06:12
*** yuanying has quit IRC06:12
*** yuanying has joined #openstack-ironic06:13
*** SerenaFeng has joined #openstack-ironic06:13
*** yuanying has quit IRC06:17
openstackgerritzhangyanying proposed openstack/ironic: Modify the "qemu-kvm" excutable path for RedHat/CentOS.  https://review.openstack.org/41005206:18
*** lindycoder has joined #openstack-ironic06:20
*** gcb has joined #openstack-ironic06:28
*** lindycoder has quit IRC06:29
*** vsaienko has joined #openstack-ironic06:32
openstackgerritVasyl Saienko proposed openstack/ironic: DON NOT REVIEW  https://review.openstack.org/40819506:33
*** links has quit IRC06:34
*** links has joined #openstack-ironic06:39
*** vsaienko has quit IRC06:42
*** amotoki has quit IRC06:52
*** amotoki has joined #openstack-ironic06:52
*** fragatin_ has joined #openstack-ironic07:05
*** fragatin_ has quit IRC07:06
*** fragatin_ has joined #openstack-ironic07:07
*** fragatina has quit IRC07:08
*** fxpester has joined #openstack-ironic07:09
*** fragatin_ has quit IRC07:11
openstackgerritMerged openstack/ironic-ui: Imported Translations from Zanata  https://review.openstack.org/40333607:15
*** gcb has quit IRC07:17
*** dsneddon has joined #openstack-ironic07:19
*** zhs__ has quit IRC07:22
*** zhs has joined #openstack-ironic07:23
*** harlowja has quit IRC07:25
pas-hamorning all :)07:27
*** gcb has joined #openstack-ironic07:28
*** vsaienko has joined #openstack-ironic07:30
tuanluongmorning ironic, pas-ha07:33
pas-hamorning tuanluong07:33
tuanluongpas-ha, I have a problem when deploy an instance follow http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html#deploying-ironic-with-devstack07:34
pas-hatuanluong: what are the symptoms?07:34
tuanluongWhen i deploy cirrros image. it succesfull, but when i create ubuntu image using disk-image-buider07:35
tuanluongi have "active"  but in VM07:35
tuanluongnot bootable07:36
openstackgerritPavlo Shchelokovskyy proposed openstack/ironic: Remove agent vendor passthru from OneView drivers  https://review.openstack.org/39784607:36
openstackgerritPavlo Shchelokovskyy proposed openstack/ironic: Remove iBoot, WoL and AMT drivers  https://review.openstack.org/39784707:36
openstackgerritPavlo Shchelokovskyy proposed openstack/ironic: Remove agent vendor passthru completely  https://review.openstack.org/39784807:36
tuanluongDo you have similar experiences?07:36
*** Romanenko_K has joined #openstack-ironic07:40
*** sacharya has quit IRC07:42
*** vsaienko has quit IRC07:44
tuanluongI'm following http://docs.openstack.org/developer/ironic/kilo/deploy/install-guide.html#image-requirements to create ubuntu image07:44
tuanluongHello pas-ha07:45
*** vsaienko has joined #openstack-ironic07:45
*** ralonsoh has joined #openstack-ironic07:45
tuanluonghello vsaienk0,07:46
pas-hatuanluong: are you following the netboot procedure? with kernel/initrd also created and uploaded to glance?07:48
*** moshele has quit IRC07:48
tuanluongpas-ha, I use whole disk-image07:48
tuanluongi just use image.qcow207:48
pas-hait seems the above will actually create an image suitable for netboot only07:49
tuanluongthus, how cirros-image successfull07:49
tuanluongI will try with partitions image later07:49
pas-hathe image you've created might be missing the bootloader installed into boot sector07:50
pas-hacirros whole-disk has it07:50
tuanluongpas-ha, I thinks the demo using cirros is whole-disk-iamge.?07:51
pas-hayes, but the image you are building with those instructions is not07:51
*** yuanying has joined #openstack-ironic07:51
pas-hatry adding a 'bootloader' dib element when building07:51
pas-hathe default images in devstack with ironic are both whole-disk (the one ending with -disk) and partition/netboot (the one ending with -uec)07:52
tuanluongpas-ha Thanks. disk-image-create ubuntu baremetal dhcp-all-interfaces bootloader -o my-image07:52
pas-hayep07:52
tuanluongis that correct. thanks you07:53
*** vsaienko has quit IRC07:55
pas-haI think it should work07:57
openstackgerritMoshe Levi proposed openstack/ironic-inspector: Adding InfiniBand Support  https://review.openstack.org/26425707:57
*** ccamacho has joined #openstack-ironic07:59
*** jaosorior has joined #openstack-ironic07:59
*** sacharya has joined #openstack-ironic08:00
*** rbartal has joined #openstack-ironic08:00
*** rcernin has joined #openstack-ironic08:05
*** sacharya has quit IRC08:05
*** pcaruana has joined #openstack-ironic08:10
*** e0ne has joined #openstack-ironic08:11
*** jaosorior has quit IRC08:12
*** jaosorior has joined #openstack-ironic08:12
*** milan has joined #openstack-ironic08:16
*** rcernin has quit IRC08:22
*** rcernin has joined #openstack-ironic08:25
openstackgerritGalyna Zholtkevych proposed openstack/ironic: Make _get_sensors_data concurrent  https://review.openstack.org/40742908:26
*** amotoki_ has joined #openstack-ironic08:29
*** kodokuuu has joined #openstack-ironic08:29
*** amotoki has quit IRC08:32
*** milan has quit IRC08:36
openstackgerritVasyl Saienko proposed openstack/python-ironicclient: Add python API and CLI for port groups  https://review.openstack.org/33596408:42
*** mjura has joined #openstack-ironic08:45
*** priteau has joined #openstack-ironic08:47
openstackgerritVasyl Saienko proposed openstack/python-ironicclient: Add more tests to node_shell  https://review.openstack.org/41010008:49
*** kodokuuu has quit IRC08:54
*** jpich has joined #openstack-ironic08:57
*** zzzeek has quit IRC09:00
*** ohamada has joined #openstack-ironic09:00
*** zzzeek has joined #openstack-ironic09:01
*** athomas has joined #openstack-ironic09:02
openstackgerritVasyl Saienko proposed openstack/python-ironicclient: Remove 'id' from API representation of resources  https://review.openstack.org/41011209:11
*** moshele has joined #openstack-ironic09:11
*** fxpester has quit IRC09:13
*** fxpester has joined #openstack-ironic09:14
openstackgerritVasyl Saienko proposed openstack/python-ironicclient: Fix API object representation in unittests  https://review.openstack.org/41011209:23
lucas-afkmorning all09:32
*** lucas-afk is now known as lucasagomes09:32
*** amotoki has joined #openstack-ironic09:36
*** derekh has joined #openstack-ironic09:41
*** yuanying has quit IRC09:47
*** dtantsur|afk is now known as dtantsur09:47
dtantsurmorning Ironic09:47
tuanluongmorning dtantsur, lucasagomes09:50
*** milan has joined #openstack-ironic09:50
lucasagomeso/09:55
milanmorning Ironic! :)09:57
milanmorning lucasagomes! :)09:57
lucasagomeshey there09:59
aarefievmorning lucasagomes, dtantsur, milan10:00
*** amotoki has quit IRC10:00
milanmorning aarefiev! :)10:00
milanmorning dtantsur! :)10:00
dtantsuro/10:08
*** e0ne has quit IRC10:09
*** SerenaFeng has quit IRC10:09
*** e0ne has joined #openstack-ironic10:10
*** links has quit IRC10:16
joannamorning :)10:17
*** hoangcx has quit IRC10:21
dtantsuraarefiev, is inspector CI still down?10:21
aarefievdtantsur: fix is merged, let see10:22
dtantsurInspector has received supports-upgrade and follows-standard-deprecation tags \o/10:23
aarefiev\o/10:23
openstackgerritYuriy Zveryanskyy proposed openstack/ironic: Add ironic resources CRUD notifications  https://review.openstack.org/35654110:24
aarefievdtantsur: btw what is the process of updating repository tags10:25
aarefievwe have merged10:25
dtantsuraarefiev, you mean https://review.openstack.org/406100 ?10:26
patchbotpatch 406100 - governance - Claim supports-upgrade and follows-standard-deprec... (MERGED)10:26
openstackgerritYuriy Zveryanskyy proposed openstack/ironic: Add node maintenance notifications  https://review.openstack.org/39623910:27
aarefievdtantsur: sorry I mean this badges10:28
aarefievgraphicals10:28
dtantsurthey're pulled from this governance repo, so I guess we should see new ones soon10:28
aarefievahh, cool10:29
dtantsurdunno, I see different things on github and in the docs..10:29
*** links has joined #openstack-ironic10:30
openstackgerritYuriy Zveryanskyy proposed openstack/ironic: Add node console notifications  https://review.openstack.org/39781210:30
vdrokmorning ironic, pas-ha tuanluong lucasagomes dtantsur aarefiev and milan !10:41
lucasagomeso/10:41
milanmorning joana, vdrok! :)10:42
vdrokmorning joanna10:42
aarefievmorning joanna, vdrok10:43
openstackgerritAparna proposed openstack/ironic-specs: In-band hpsum firmware update for iLO drivers  https://review.openstack.org/41016110:47
openstackgerritAparna proposed openstack/ironic-specs: In-band hpsum firmware update for iLO drivers  https://review.openstack.org/41016110:50
openstackgerritGalyna Zholtkevych proposed openstack/ironic: Make _get_sensors_data concurrent  https://review.openstack.org/40742910:56
openstackgerritDmitry Tantsur proposed openstack/ironic: Introduce generic hardware types  https://review.openstack.org/40067810:56
openstackgerritDmitry Tantsur proposed openstack/ironic: Support defining and loading hardware types  https://review.openstack.org/33662610:56
openstackgerritDmitry Tantsur proposed openstack/ironic: [WIP] Load hardware types in the conductor  https://review.openstack.org/40981210:58
dtantsurrebase time \o/10:58
*** amotoki_ has quit IRC11:01
*** mgould|afk is now known as mgould11:01
mgouldmorning Ironic, pas-ha tuanluong lucasagomes dtantsur aarefiev milan vdrok joanna11:01
milanmorning mgould! :)11:02
*** daemontool has joined #openstack-ironic11:02
aarefievo/11:02
*** MattMan has quit IRC11:04
*** MattMan has joined #openstack-ironic11:04
*** pester has joined #openstack-ironic11:05
*** zhangjl1 has quit IRC11:07
*** fxpester has quit IRC11:08
*** nmathew has quit IRC11:08
dtantsurhey mgould11:09
mgouldhi dtantsur11:09
openstackgerritJoanna Taryma proposed openstack/ironic: Fail ironic startup if no protocol prefix in ironic api address  https://review.openstack.org/40497511:11
*** zhugaoxiao has joined #openstack-ironic11:13
*** SerenaFeng has joined #openstack-ironic11:15
*** links has quit IRC11:15
openstackgerritzhangyanying proposed openstack/ironic: Add a "qemu-kvm" excutable path for RedHat/CentOS.  https://review.openstack.org/41005211:16
openstackgerritLucas Alvares Gomes proposed openstack/ironic: Make CONF.debug also reflect on IPA  https://review.openstack.org/41016811:16
*** deray has quit IRC11:17
*** SerenaFeng has quit IRC11:18
*** SerenaFeng has joined #openstack-ironic11:19
*** jkilpatr has joined #openstack-ironic11:22
openstackgerritVasyl Saienko proposed openstack/ironic: Do not wait Neutron by default for SSH power  https://review.openstack.org/41017011:25
*** amoralej|off is now known as amoralej11:25
vdrokmorning mgould :)11:26
*** SerenaFeng has quit IRC11:32
*** links has joined #openstack-ironic11:32
openstackgerritLucas Alvares Gomes proposed openstack/ironic-inspector: Use the device hints matching mechanism from ironic-lib  https://review.openstack.org/40855211:51
*** jkilpatr has quit IRC11:51
*** zhugaoxiao has quit IRC11:56
dtantsurinspector CI is back up, good!11:56
dtantsurmilan, btw https://review.openstack.org/#/c/409789/ was by your request looong time ago11:56
patchbotpatch 409789 - python-ironic-inspector-client - Clarify that node names can be used in addition to...11:56
*** zhugaoxiao has joined #openstack-ironic11:56
milandtantsur, I don't remember O:-) /me looks11:57
dtantsurit was months ago, really :) I found a TODO item in my personal task list yesterday11:57
milandtantsur, aaah :D11:58
milanOK11:58
* milan adds himself to review11:58
* milan right now updates the list statuses patch according to aarefiev 's review ;)11:58
dtantsuryeah, no hurry with this one12:00
robcresswellHey guys, do you have a microversion history like http://docs.openstack.org/developer/nova/api_microversion_history.html ?12:05
robcresswellah, found it, nvm12:06
lucasagomes:-)12:07
robcresswellMucking around with the standalone ironic UI :)12:07
*** tuanluong has quit IRC12:07
*** nmathew has joined #openstack-ironic12:07
openstackgerritVasyl Saienko proposed openstack/ironic: Do not wait Neutron by default with *_ssh driver  https://review.openstack.org/41017012:10
*** jkilpatr has joined #openstack-ironic12:10
*** jaosorior is now known as jaosorior_brb12:10
*** SerenaFeng has joined #openstack-ironic12:12
*** dprince has joined #openstack-ironic12:23
*** SerenaFeng has quit IRC12:25
*** yufei has quit IRC12:35
dtantsur"CoreOS Linux is Now Container Linux" https://coreos.com/blog/tectonic-self-driving.html12:41
dtantsursoon we'll have to rename some jobs :D12:42
*** krtaylor has joined #openstack-ironic12:44
*** hw_wutianwei has quit IRC12:46
*** vikrant has quit IRC12:52
*** dprince has quit IRC12:52
*** lucasagomes is now known as lucas-hungry12:58
*** eroux has joined #openstack-ironic13:05
nicodemosgood morning!13:08
*** bfournie has quit IRC13:08
openstackgerritGalyna Zholtkevych proposed openstack/ironic: [WIP] ETAG supporting to enhance API evolution  https://review.openstack.org/39221313:10
*** lindycoder has joined #openstack-ironic13:17
*** amotoki has joined #openstack-ironic13:18
openstackgerritSzymon Borkowski proposed openstack/ironic: Add RPC and object version pinning  https://review.openstack.org/40749113:20
*** lindycoder has quit IRC13:21
*** lindycoder has joined #openstack-ironic13:23
TheJuliaGood morning!13:29
TheJuliadtantsur: to have minimal OS references I hope :)13:29
milanmorning nicodemos, TheJulia! :)13:29
*** lindycoder has quit IRC13:30
dtantsurTheJulia, morning :)13:30
* milan not sure how that would work; giving them numbers the cattle way I guess ;)13:31
milananyone knows how to use https://github.com/openstack/osc-lib/blob/master/osc_lib/utils.py#L248 properly?13:31
* milan getting frustrated w/ http://paste.openstack.org/show/592217/13:32
milanwhere ('U', 't', 'i', 'r') comes from I don't follow13:33
milanthe fields I feed the function with are: ('UUID', 'Started at', 'Finished at', 'Error')13:33
* milan starts to think about blaming his Mac for it13:34
milandtantsur, ^ ;)13:34
TheJuliamilan: change the test order maybe?13:34
dtantsurI highly suspect it, yes13:34
*** trown|outtypewww is now known as trown13:35
* milan tries changing test order, then blaming the Mac :D13:35
dtantsurI think input is mismatched somewhere13:35
dtantsurhard to tell without looking at the code13:35
milanyeah most likely13:37
milanI'll push it I guess13:37
milanactually, TheJulia was right, just changed the order of the tests and it works O.o13:37
* milan tries changing it back and forth13:38
milanyup, depends on the order :-/13:39
dtantsurUGH13:40
milancoffee nr. 513:41
vdrokmorning nicodemos and TheJulia13:41
vdrokwoah milan, you know the max for the day is 50? :)13:42
milanmeh, I still have 45 to go then, vdrok :D13:43
openstackgerritSzymon Borkowski proposed openstack/ironic: Add RPC and object version pinning  https://review.openstack.org/40749113:43
vdrokmilan: also futurama says that after 100 you'll be able to slow down the time13:43
vdrokif you survive13:44
milanI'm definitely trying that one day :D13:44
*** bfournie has joined #openstack-ironic13:44
*** amoralej is now known as amoralej|lunch13:44
milanactually, slowing down the time to see the race condition in the test case might be helpful now :)13:45
milanbut I've got a strong feeling this actually going to be one of those between the keyboard and chair issues ;)13:45
*** amotoki has quit IRC13:45
*** srobert has joined #openstack-ironic13:46
mgouldmorning nicodemos TheJulia13:46
mgouldmilan, what you actually need is some cake: https://www.youtube.com/watch?v=Xbq3kc29Tmg13:47
nicodemoshey, vdrok, milan, TheJulia, mgould13:47
mgouldbut beware of Czech Neck13:48
*** jkilpatr has quit IRC13:49
milan:D lol13:49
*** hoangcx has joined #openstack-ironic13:50
*** srobert has quit IRC13:50
*** jheroux has joined #openstack-ironic13:51
*** hoangcx has quit IRC13:51
*** hoangcx has joined #openstack-ironic13:52
xavierrgood morning Ironic'ers o/13:55
mgouldmorning xavierr13:55
milanmorning xavierr! :)13:55
*** glonlas has joined #openstack-ironic13:56
openstackgerritHugo Nicodemos proposed openstack/ironic: Onetime boot when set_boot_device isn't persistent  https://review.openstack.org/34059613:57
*** jcoufal has joined #openstack-ironic13:57
*** glonlas has quit IRC13:57
*** glonlas has joined #openstack-ironic13:59
*** glonlas has quit IRC13:59
vdrokmorning xavierr14:00
*** glonlas has joined #openstack-ironic14:00
*** dprince has joined #openstack-ironic14:02
*** sborkows has joined #openstack-ironic14:05
openstackgerritKyrylo Romanenko proposed openstack/python-ironicclient: Add basic tests for OSC plugin baremetal driver commands  https://review.openstack.org/36735914:05
*** jkilpatr has joined #openstack-ironic14:06
*** jkilpatr_ has joined #openstack-ironic14:08
*** lucas-hungry is now known as lucasagomes14:08
*** jaosorior_brb is now known as jaosorior14:09
* milan asks around for some cake14:09
xavierrmilan: lol14:09
openstackgerritHugo Nicodemos proposed openstack/ironic: Onetime boot when set_boot_device isn't persistent  https://review.openstack.org/34059614:10
*** rbudden has joined #openstack-ironic14:10
*** jkilpatr has quit IRC14:10
mrtenioMorning Ironic.14:11
mgouldmorning mrtenio14:12
milanmorning mrtenio! :)14:12
mgouldmilan: the guy in that clip who said "should we ask a question about this in Parliament?" was an actual sitting MP, known for his hard-on-drugs stances14:12
xavierrhey mrtenio :)14:13
milanmgould, isn't it that one who actually thought that was a real thing?14:13
*** Goneri has joined #openstack-ironic14:15
TheJulianicodemos: slight nits on the release note, if any make sense to you, you may want to put up a follow-up patch.14:16
TheJuliaor, you could revise it if you want, would be easy for us to toss new +2's on it :)14:17
vdrokdtantsur: lucasagomes TheJulia http://logs.openstack.org/70/410170/2/check/gate-tempest-dsvm-ironic-ipa-wholedisk-agent_ipmitool-tinyipa-ubuntu-xenial/8267b81/console.html I've started seeing this recently, the reason is - set console mode is async, and seems it slowed down a bit recently, so that consequent get still gets old value14:17
TheJuliaI spotted that on a job already once this morning as well :(14:18
vdrokshould we just add polling there? remove the test? wait for notifications to merge and use them?14:18
nicodemosTheJulia, I'll fix that. Thanks.14:18
*** lets has joined #openstack-ironic14:18
TheJuliavdrok: polling most likely, it is what we do in the tests for other async things.14:18
TheJuliavdrok: like state changes14:18
TheJuliaThat would keep it consistent at least14:19
*** baoli has joined #openstack-ironic14:19
*** baoli has quit IRC14:19
*** ricardoas has left #openstack-ironic14:20
*** ricardoas has joined #openstack-ironic14:20
*** baoli has joined #openstack-ironic14:20
*** rloo has joined #openstack-ironic14:21
vdrokok, let's go that way for now :)14:21
openstackgerritHugo Nicodemos proposed openstack/ironic: Onetime boot when set_boot_device isn't persistent  https://review.openstack.org/34059614:21
TheJuliavdrok: and there are helper methods already for waiting until something returns the desired result :)14:23
openstackgerritKyrylo Romanenko proposed openstack/python-ironicclient: Add basic tests for OSC plugin baremetal port commands  https://review.openstack.org/36569214:24
TheJulianicodemos: Thank you!  I guess now we just need to wait until the oneview ci reports in14:25
vdrokTheJulia: not in api tests tho :) that's in scenario manager14:25
*** dsneddon has quit IRC14:25
TheJuliaoh weird.... because I thought I spotted it in tempest test output earlier14:25
TheJuliaoh, I get what your saying14:26
*** pester has quit IRC14:26
TheJuliaI thought they were in the base tools and that was imported into the api tests14:26
*** pester has joined #openstack-ironic14:27
vdrokTheJulia: aha, ok, there is another waiters.py in common14:27
vdrokstrange that we have basically the same thing in two places14:28
TheJuliafun!14:29
nicodemosTheJulia: \o/ yeah. Thanks. and vdrok too. --]14:30
patchbotError: Spurious "]".  You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands.14:30
milanbtw my test issue was indeed my fault. Twice. Facepalm.14:30
mgouldmilan: d'oh!14:32
*** vsaienko has joined #openstack-ironic14:33
* milan could use some cake now14:33
mgouldand I think they *all* thought it was real apart from the presenter :-)14:33
*** daemontool has quit IRC14:33
*** amoralej|lunch is now known as amoralej14:36
*** spartacloud has joined #openstack-ironic14:38
clif_hanyone know if there's a way in gerrit to unbold reviews that are updated, but you've looked at and have nothing to add?14:39
*** srobert has joined #openstack-ironic14:39
openstackgerritMilan Kováčik proposed openstack/python-ironic-inspector-client: List introspection statuses support  https://review.openstack.org/40811614:41
openstackgerritAndrey Shestakov proposed openstack/bifrost: Add support of remote logging  https://review.openstack.org/41024714:43
vdrokclif_h: don't think it's possible, unless you add a vote/comment14:43
*** zzzeek has quit IRC14:43
*** zzzeek has joined #openstack-ironic14:43
*** mkrai_ has joined #openstack-ironic14:44
clif_hvdrok: thanks, see related conversation just now in #openstack-infra if you're interested14:44
openstackgerritKyrylo Romanenko proposed openstack/python-ironicclient: Add basic tests for OSC plugin baremetal chassis commands  https://review.openstack.org/36615814:44
clif_happarently gertty supports this feature and is console-based https://pypi.python.org/pypi/gertty14:46
*** hoangcx has quit IRC14:46
openstackgerritLucas Alvares Gomes proposed openstack/ironic: Make CONF.debug also reflect on IPA  https://review.openstack.org/41016814:53
openstackgerritKyrylo Romanenko proposed openstack/python-ironicclient: Describe possible exception in docstring  https://review.openstack.org/41025314:55
*** glonlas_ has joined #openstack-ironic14:56
*** rbartal has quit IRC14:56
*** glonlas_ has quit IRC14:57
*** glonlas_ has joined #openstack-ironic14:57
*** glonlas has quit IRC14:59
openstackgerritDmitry Tantsur proposed openstack/ironic: Support defining and loading hardware types  https://review.openstack.org/33662615:05
openstackgerritVladyslav Drok proposed openstack/ironic: Use polling in set_console_mode tempest test  https://review.openstack.org/41025415:05
openstackgerritDmitry Tantsur proposed openstack/ironic: Introduce generic hardware types  https://review.openstack.org/40067815:05
*** mjura has quit IRC15:07
*** nicodemos has quit IRC15:08
*** nicodemos has joined #openstack-ironic15:09
*** nmathew- has joined #openstack-ironic15:10
openstackgerritLucas Alvares Gomes proposed openstack/ironic-lib: Correct reraising of exception  https://review.openstack.org/40573415:11
*** nmathew has quit IRC15:11
*** chlong has quit IRC15:13
*** vsaienko has quit IRC15:13
*** glonlas_ has quit IRC15:14
*** mtanino has joined #openstack-ironic15:15
*** glonlas has joined #openstack-ironic15:15
*** vsaienko has joined #openstack-ironic15:16
openstackgerritDmitry Tantsur proposed openstack/ironic: [WIP] Load hardware types in the conductor  https://review.openstack.org/40981215:17
*** rama_y has joined #openstack-ironic15:26
*** rama_y_ has joined #openstack-ironic15:26
*** yufei has joined #openstack-ironic15:27
NobodyCamGood Morning Ironic'ers15:28
*** vsaienko has quit IRC15:29
nicodemosmorning, NobodyCam15:29
vdrokmorning NobodyCam15:29
dtantsurmorning NobodyCam15:30
NobodyCammorning nicodemos vdrok dtantsur :)15:30
rloohello and a Gooooood Morning NobodyCam, nicodemos, vdrok, dtantsur :)15:31
vdrokmorning rloo :)15:31
dtantsurmorning rloo15:31
NobodyCamGood Morning rloo :)15:31
*** vsaienko has joined #openstack-ironic15:31
nicodemosmorning, rloo15:31
milanmorning NobodyCam rloo! :)15:32
NobodyCammorning milan :)15:32
rloohiya milan15:32
openstackgerritKyrylo Romanenko proposed openstack/python-ironicclient: Add basic tests for OSC plugin baremetal chassis commands  https://review.openstack.org/36615815:35
lucasagomesNobodyCam, morning15:39
lucasagomesrloo, morning too :-)15:39
NobodyCamGood Morning lucasagomes :)15:39
rloohi lucasagomes!15:39
NobodyCamhey hey lucasagomes i had a question RE staging-drivers15:41
lucasagomesNobodyCam, shoot15:41
*** links has quit IRC15:42
NobodyCamseveral of the drivers have a python-requirements.txt file, one of them (amt driver) has other-requirements.txt is it ok if I rename other- to python- so we are standardized across all the drivers?15:42
vdrokNobodyCam: there is a difference -- https://github.com/openstack/ironic-staging-drivers/blob/master/devstack/plugin.sh#L3815:43
NobodyCamahh15:44
nicodemosHey, TheJulia. If you dont mind: https://review.openstack.org/#/c/358041 , the CI its passing now. =D15:44
patchbotpatch 358041 - ironic - Reusing oneview_client when possible15:44
NobodyCamokay, i will need to handle both then15:44
NobodyCamthank you lucasagomes and vdrok :)15:44
lucasagomesNobodyCam, yeah, so others is just a plan bash script to install the dependencies15:44
lucasagomesNobodyCam, when they are not on pip15:45
vdroknp :)15:45
*** moshele has quit IRC15:45
rloodtantsur, mariojv, lucasagomes, vdrok if you understand objects -- do you know what the very first version of class NodeCRUDPayload should be? https://review.openstack.org/#/c/356541/28/ironic/objects/node.py15:47
patchbotpatch 356541 - ironic - Add ironic resources CRUD notifications15:47
* dtantsur does not understand them15:47
rlooi don't understand them either, but it seems to me that the very first time we have an object, it is version 1.0. regardless of the version of its parent class/object.15:48
vdrokrloo: in a meeting, will take a look in 15 minutes :)15:48
rloovdrok: thx.15:48
* lucasagomes looks15:48
TheJulianicodemos: of course, the logs address does not resolve :(15:49
mariojvlooking rloo15:49
*** sborkows has quit IRC15:49
mariojvrloo: i think if it was only NodePayload, then it might have to be 1.1, but since it's adding fields, 1.0 is fine15:50
mariojvrloo: i'd print out the full payload and double check first though15:50
lucasagomesrloo, apparently all payloads inheriting from nepayload is 1.115:51
lucasagomesbecause the parent (nodepayload) was updated once15:51
rloolucasagomes: but don't you just update the ones inheriting cuz they existed as version 1.0 using version 1.0 of the parent class?15:51
lucasagomesrloo, true that15:51
rloothis is a new class. i don't see why it should be version 1.115:52
rlooeg what if NodePayload was version 1.14 and we added a new class that inherited. would it start off as version 1.14?15:52
lucasagomesrloo, yeah might worth asking yuriyz about it. But it sounds like it should be '1.0' because it's a new payload15:53
nicodemosTheJulia, thanks for the report. ricardoas ^15:53
rlooi did ask yuriyz. he doesn't think it should be 1.0 but i haven't gotten a reason that makes sense to me15:53
rloolucasagomes: i don't want to approve that w/o knowing. cuz it has ramifications for future objects, etc. and i guess we really should understand it.15:54
yuriyzhi we should bump version of inherited class if parent changed15:54
mariojvyuriyz: why?15:54
rlooyuriyz: what do you mean by 'bump'. the parent changed BEFORE this class was created.15:54
yuriyzbut new payload should start from 1.015:54
mariojvoh15:54
mariojvyes, i agree15:54
lucasagomesyuriyz, I agree with that, but you should bump it when the payload that inherits it already exist, right ?15:54
mariojvyuriyz: so L592 here https://review.openstack.org/#/c/356541/28/ironic/objects/node.py should change to 1.015:55
*** glonlas_ has joined #openstack-ironic15:55
patchbotpatch 356541 - ironic - Add ironic resources CRUD notifications15:55
*** Goneri has quit IRC15:55
lucasagomesin this case, we are adding a new one. So the initial version (1.0) is already based on NodePayload 1.115:55
mariojv593, i mean15:55
ricardoasHey, nicodemos! I'll check this out... it should have been resolving to 150.165.85.31 :(15:56
mariojvwe should certainly update the docs to resolve this ambiguity, once there's consensus on what to do in that patch15:56
ricardoasTheJulia can you please check if this ip is accessible?15:56
mariojvi can do that15:56
yuriyzmariojv please look at NodeCorrectedPowerStatePayload and NodeSetPowerStatePayload they have 1.1 already15:57
*** glonlas_ has quit IRC15:57
mariojvyuriyz: ah, you're right15:58
*** glonlas_ has joined #openstack-ironic15:58
mariojv:|15:58
*** glonlas has quit IRC15:58
mariojvyuriyz: however, didn't those first merge with 1.0?15:58
*** rajinir has joined #openstack-ironic15:59
rlooyuriyz, mariojv: exactly. they existed BEFORE NodePayload got updated to v1.115:59
mariojvyuriyz: https://github.com/openstack/ironic/commit/ff32b51bbffc566d339dbb1f7f19b3b7429a91d1#diff-11867de23f1b786138f931d9736841ddR48215:59
mariojvctrl+f NodeSetPowerStatePayload15:59
yuriyzyes https://review.openstack.org/#/c/401311/12/ironic/objects/node.py15:59
patchbotpatch 401311 - ironic - Move interface validation from API to conductor side (MERGED)15:59
mariojvyuriyz: so given that this is a new notification, and that was just a payload update, i think the payload for a new notification should be 1.016:00
JayFDoes anyone know who Szymon Borkowski is on IRC?16:00
yufeiping16:00
mariojvyuriyz: unless there's a compelling reason to make it 1.0 at first16:00
mariojv*not make it 1.016:00
yuriyzmariojv ok agree16:00
mariojvthanks yuriyz16:00
mariojvi'll update docs later today to point this out for any new notifications that get added in the future16:01
*** mkrai_ has quit IRC16:01
rloothx mariojv, yuriyz.16:01
lucasagomesyuriyz, so the order they got in the code matters right ? For the CRUDPayload, it's initial version (== 1.0) is based on NodePayload 1.116:01
mariojvnp, thanks for bringing it up rloo16:01
rloomariojv: i think it is an 'object, ovo' thing, the versioning.16:01
mariojvrloo: for the docs you mean? i agree, but it's ironic policy that determines how to use the versions in notifications16:02
mariojvunless there's a cross-project notification spec i don't know about16:02
rloomariojv: ah, ok, that makes sense.16:02
*** rcernin has quit IRC16:04
*** Syed__ has joined #openstack-ironic16:06
*** daemontool has joined #openstack-ironic16:07
*** Goneri has joined #openstack-ironic16:08
*** pcaruana has quit IRC16:09
openstackgerritMerged openstack/ironic-ui: Updated from global requirements  https://review.openstack.org/40997216:11
openstackgerritMerged openstack/ironic-ui: Consolidate node last_error processing  https://review.openstack.org/40618416:11
*** jaosorior has quit IRC16:12
*** jaosorior has joined #openstack-ironic16:13
*** bfournie has left #openstack-ironic16:16
*** Nisha_Agarwal has joined #openstack-ironic16:18
Nisha_Agarwalhi16:19
*** bfournie has joined #openstack-ironic16:19
Nisha_AgarwalI am trying to login to gerrit code review, it opens the OpenID authentication page....anyone knows what we need to enter there? anyhelp is appreciated16:19
mrtenioJayF, I don't know if you found it. Did you try sborkows?16:21
JayFmrtenio: I don't see anyone by that name in here, but it's fine, I just emailed the list about the issue more generally16:21
mrtenionp16:22
TheJuliaricardoas: The IP is accessible16:23
openstackgerritYuriy Zveryanskyy proposed openstack/ironic: Add ironic resources CRUD notifications  https://review.openstack.org/35654116:23
-openstackstatus- NOTICE: Launchpad SSO is not currently working, so logins to our services like review.openstack.org and wiki.openstack.org are failing; the admins at Canonical are looking into the issue but there is no estimated time for a fix yet.16:24
*** ChanServ changes topic to "Launchpad SSO is not currently working, so logins to our services like review.openstack.org and wiki.openstack.org are failing; the admins at Canonical are looking into the issue but there is no estimated time for a fix yet."16:24
openstackgerritYuriy Zveryanskyy proposed openstack/ironic: Add node maintenance notifications  https://review.openstack.org/39623916:27
*** Romanenko_K has quit IRC16:27
*** jaosorior has quit IRC16:28
*** e0ne has quit IRC16:28
openstackgerritYuriy Zveryanskyy proposed openstack/ironic: Add node console notifications  https://review.openstack.org/39781216:30
*** baoli has quit IRC16:30
rlooNisha_Agarwal: did you see the notice above ^^?16:30
Nisha_Agarwalrloo, thanks. so currently no solution?16:31
lucasagomesvdrok, are you going to fix the test_set_console_mode() from tempest to poll ?16:32
rlooNisha_Agarwal: dunno, i only know what i read ^^16:32
*** glonlas_ has quit IRC16:32
*** aNuposic has joined #openstack-ironic16:33
Nisha_Agarwalrloo, :(16:33
vdrokLucasagomes yup it's on review16:33
lucasagomesvdrok, oh will take a look. Thanks!16:33
vdrokOut of office currently, lights gone off :(16:33
Nisha_Agarwalvdrok, lucasagomes are u guys able to access review.openstack.org?16:33
vdrokWill continue at home16:34
lucasagomesNisha_Agarwal, it's working for me16:34
*** glonlas has joined #openstack-ironic16:34
*** glonlas has quit IRC16:34
*** Goneri has quit IRC16:34
vdrokWfm Nisha_Agarwal16:34
*** glonlas has joined #openstack-ironic16:34
Nisha_Agarwaltoday i just rebooted my laptop, i think it upgraded something, and its not working after that :(16:34
vdrokOr you are not able only to log in?16:34
vdrokIf so, notice is ^^16:35
Nisha_Agarwalvdrok, i dont know what shall be OpenID for my account16:35
JayFNisha_Agarwal: As the status indicates, it's an issue on the server. I'd wait and expect the status bot to update when it's fixed.16:35
Nisha_AgarwalJayF, hmmm16:36
vsaienk0morning rloo, once you have a time please have look at: https://review.openstack.org/#/c/327046/29/ironic/drivers/modules/network/common.py@123 We didn't add VIF RPC objects so we sending VIF via RPC as json, it makes impossible to extend VIF object in future. I think that we should add VIF RPC object (inherited from oslo versioned objects) to have possibility to extend it. wdyt?16:37
patchbotpatch 327046 - ironic - Add Virtual Network Interface Driver APIs16:37
rloovsaienk0: looking...16:38
*** sacharya has joined #openstack-ironic16:38
rloovsaienk0: yeah, i was going to look at the other patches to see what that vif 'object' was.16:38
rloovsaienk0: so you're saying there is no ovo for vif?16:39
rloovsaienk0: i think part of the problem might be that this vif 'object' is vague.16:39
vsaienk0rloo: yes, there is no ovo for vif16:39
rloovsaienk0: all it is now is an ID (some string). i think the intent is that it could be something more, depending on the usecase.16:40
rloovsaienk0: and then the actual interface/driver, will know what to do with it.16:40
rloovsaienk0: so we could create an ovo for it, and then up the version after it changes. to something like an id, and a dict :)16:41
rloovsaienk0: or we leave it as a json -- and then have to update the rcp api etc if we change it to an object later. not sure which approach to take. what do you think?16:42
*** moshele has joined #openstack-ironic16:42
vsaienk0rloo: fair enough, if we decide to extend it, we may convert to ovo, and then extend.16:43
vsaienk0rloo: thanks!16:43
rloovsaienk0: the *only* problem. is that vif_attach() is an interface API.16:43
rloovsaienk0: if we change the type of vif (json to object), we can't break out-of-tree interfaces later.16:44
vsaienk0rloo: we can pass both json and ovo, and then deprecate json16:44
*** eroux has quit IRC16:45
*** vsaienko has quit IRC16:45
*** aNuposic has quit IRC16:45
*** chlong has joined #openstack-ironic16:46
*** aNuposic has joined #openstack-ironic16:46
rloovsaienk0: give me a few minutes, i want to look at all the patches together.16:47
*** rbartal has joined #openstack-ironic16:48
*** rama_y_ has quit IRC16:51
*** rama_y has quit IRC16:51
lucasagomeshi all, can someone please take a look at https://review.openstack.org/#/c/409755/ ? This prevents VBMC from hiding errors from IPMI (can lead to Ironic being fooled if a request fail and not retry)16:52
patchbotpatch 409755 - virtualbmc - Return proper errors on BMC action failures16:52
JayFlucasagomes: no, nobody can :)16:53
JayFlucasagomes: mainly because gerrit is busted, lol16:53
ricardoasTheJulia thanks for checking... we'll take a look at our dns asap :)16:53
lucasagomesJayF, :-(16:54
* TheJulia guesses this is the perfect time to prep dinner to cook for the afternoon, and then run to the store.16:55
openstackgerritAnup Navare proposed openstack/ironic: [WIP] Allow logical name along with UUID in port creation  https://review.openstack.org/41031916:55
TheJuliauhh... did we ever decide to make names unique?16:56
TheJuliahmm, looks like we did16:58
rloovsaienk0: so there are a few things that bother me about this VIF stuff. the new interface is meant to be generic, to allow something other than neutron to be used. looking at the spec, we don't save the vif in the db as a first class citizen. we save it as internal info to some node or port.16:59
dtantsurTheJulia, tbh I never understood openstack's tradition of non-unique names16:59
rloovsaienk0: the spec sez 'These API endpoints will take via a POST body, a JSON representation of a generic VIF object. Making it generic allows for non-neutron based implementations to use this API'17:00
*** rcernin has joined #openstack-ironic17:00
*** sacharya_ has joined #openstack-ironic17:00
*** ChanServ changes topic to "Bare Metal Provisioning | Status: http://bit.ly/ironic-whiteboard | Docs: http://docs.openstack.org/developer/ironic/ | Bugs: https://bugs.launchpad.net/ironic"17:01
-openstackstatus- NOTICE: Canonical admins have resolved the issue with login.launchpad.net, so authentication should be restored now.17:01
TheJuliadtantsur: names are for humans and are only for our mental connecting memories :)17:01
rlooNisha_Agarwal: ^^17:01
Nisha_Agarwalrloo, ok let me try17:01
Nisha_Agarwali tried few min back it didnt work17:01
NobodyCamI just logged in17:01
*** sacharya has quit IRC17:02
Nisha_Agarwalrloo, yes it worked17:02
Nisha_Agarwal:) thanks17:02
rlooNisha_Agarwal: now get to work :D17:02
Nisha_Agarwalrloo, :) yes17:03
mgoulddtantsur: unique per-tenant or globally?17:04
mgouldunique globally is going to be suboptimal in most cases for a cloud service17:04
Nisha_Agarwalrloo, no it didnt login...it just open the gerrit without logi17:04
Nisha_Agarwal:(17:04
Nisha_Agarwali have to yet resolve it17:04
lucasagomesmgould, I think Ironic does it globally17:05
lucasagomesbut yeah, per tenant would make more sense now (before ironic was an admin only thing)17:06
* mgould nods17:06
openstackgerritMerged openstack/ironic-inspector: Remove upgrade from non-ironic setup  https://review.openstack.org/40856917:06
mgouldbut yeah, for most of openstack "unique per tenant" is the most that makes sense17:07
TheJuliawe're unique globally, we would have do store tenant and such in the table to make a unique relationship... but are names even unique for nova?17:07
*** strigazi is now known as strigazi_AFK17:07
*** glonlas_ has joined #openstack-ironic17:07
dtantsurmgould, I guess this is why it was not done17:08
lucasagomesTheJulia, no, for nova they are not17:08
lucasagomesand neither is for neutron AFAICT17:08
TheJuliaso... we really can't logically support name use for ports associations17:09
* TheJulia thinks this discussion has been had at least twice before17:09
lucasagomesyou can have X instances called "foo" for the same tenant if you want, but it will prevent a "nova delete <name>" if there are two or more17:09
lucasagomesTheJulia, I think the idea with ports was to not store the name in the port object at all ?17:09
lucasagomesTheJulia, but instead just use it to find the right node UUID and store the UUID instead17:10
* lucasagomes understood that from the last conversations17:10
rloolucasagomes, TheJulia: sorry, haven't followed the entire conversation. is this a question of using the node's name instead of UUID, related to port stuff?17:11
*** glonlas has quit IRC17:11
rloolucasagomes, TheJulia: i think lucasagomes is right; we use node name to get the node uuid and the node id is associated with the port.17:11
lucasagomesrloo, yeah, for port creation17:11
*** glonlas_ has quit IRC17:12
openstackgerritChris Krelle proposed openstack/bifrost: Adding staging driver support  https://review.openstack.org/40640117:12
lucasagomesNobodyCam, w00t!17:12
rloolucasagomes: should be fine. i think/thought the bug described it but it was awhile ago.17:12
*** dsneddon has joined #openstack-ironic17:12
*** moshele has quit IRC17:13
lucasagomesrloo, cool, I will take a look at that patch soon17:13
lucasagomesthanks for clarifying btw17:13
rloolucasagomes: :) that's my understanding anyway but i could be wrong, it's been awhile.17:13
* lucasagomes same17:13
TheJuliaYeah, I seem to remember disagreement regarding port updates supporting names since we really shouldn't force the unique constraint on the names as we do, but *shrug*17:14
NobodyCamlucasagomes: hehehehe17:14
*** rpioso has joined #openstack-ironic17:18
openstackgerritPeter Piela proposed openstack/ironic-ui: Extend support for the Ironic state machine  https://review.openstack.org/41032617:18
*** jpich has quit IRC17:19
*** fragatina has joined #openstack-ironic17:22
*** fragatina has quit IRC17:23
*** fragatina has joined #openstack-ironic17:23
*** rcernin has quit IRC17:24
yufeihello, ironicers, I’m trying to deploy a whole-disk image to my baremetal machine today, but after ironic-conductor sucessfuly write the os to the machine disk, it throws an error “Error: Could not determine a suitable URL for the plugin”,and say deploy failed, but in fact it succeed, and it seems like something about keystone is wrong in conductor.conf, but when I try to delploy partition image to this node, I don’t meet this problem.17:24
yufeiDoes someone has meet similar problem before?17:25
*** fragatina has quit IRC17:26
*** fragatina has joined #openstack-ironic17:26
* mgould hasn't17:28
mgouldyufei: could you post the relevant section of the logs to paste.openstack.org?17:28
*** baoli has joined #openstack-ironic17:29
*** vsaienko has joined #openstack-ironic17:32
*** ohamada has quit IRC17:33
*** athomas has quit IRC17:33
*** ralonsoh_ has joined #openstack-ironic17:34
*** ccamacho has quit IRC17:35
*** rcernin has joined #openstack-ironic17:35
*** rcernin has quit IRC17:35
*** fragatina has quit IRC17:35
*** ralonsoh has quit IRC17:37
milanTheJulia, have got a minute for a boot-from-volume question?17:37
TheJuliamilan: sure17:37
milanTheJulia, https://review.openstack.org/#/c/326620/3..4/releasenotes/notes/optional-root-disk-9b972f504b2e6262.yaml17:38
patchbotpatch 326620 - ironic-inspector - Add an option to not fail when root device is not ...17:38
milanaarefiev asks about local_gb having to be set manually17:38
milandtantsur wanted that in that time ^17:38
* dtantsur is not to blame, it's all your mac17:38
milanTheJulia, isn't that information now provided by the connector in Ironic?17:39
milandtantsur :D17:39
milanI mean the local_gb for the scheduler17:39
* milan searches firefox tabs for the specs....17:40
yufeihi, mgould,I paste it here http://paste.openstack.org/show/592249/17:40
*** fragatina has joined #openstack-ironic17:41
*** fragatina has quit IRC17:42
TheJuliamilan: I would think local_gb should be set to "0" since no storage was found, but i don't know the intricacies of flavor matching in that case.  The local_gb is not provided by the connector, nova has to schedule on to the node, provide the connector info to ironic then17:42
*** fragatina has joined #openstack-ironic17:42
*** nmathew- has quit IRC17:43
TheJuliayufei: are the glance and/or swift credentials/settings correct?17:43
*** derekh has quit IRC17:43
*** vsaienko has quit IRC17:44
yufeiIt should be ok, because I can see it download the images to /var/lib/ironic successfuly17:45
milanTheJulia, ah, OK thx, I'll update the patch that way, local_gb == 0, I'm afraid I have no other option than to test the flavour matching ;)17:45
TheJuliayufei: interesting, agent_base_vendor... hmmm17:47
*** rama_y has joined #openstack-ironic17:47
*** fragatina has quit IRC17:48
openstackgerritVladyslav Drok proposed openstack/ironic: Use polling in set_console_mode tempest test  https://review.openstack.org/41025417:48
vdroklucasagomes: thanks for review, done17:49
lucasagomesvdrok, o/17:49
lucasagomes+217:49
lucasagomesand folks, I'm calling it a day17:50
lucasagomeshave a great evening all!17:50
vdrokTheJulia: rloo dtantsur ^^ easy patch to fix the race in the api test17:50
vdroklucasagomes: good night :)17:50
NobodyCamnight lucasagomes17:50
*** lucasagomes is now known as lucas-afk17:50
milangood night lucasagomes! :)17:50
lucas-afko/17:50
TheJuliayufei: so there are some lines before that we are likely missing that might provide a clue, but needless to say setting the boot loader seemed to fail, we just don't know why17:50
* milan relocates17:51
TheJuliavdrok: thank you17:51
TheJuliagoodnight lucas-afk17:51
*** moshele has joined #openstack-ironic17:52
* mgould -> home; good night!17:53
*** mgould is now known as mgould|afk17:53
yufeihi, TheJulia, I’m using newton, I’m not sure whether this exits in devstack master, I will test it tomorrow17:53
nicodemosmgould|afk, lucas-afk night17:53
openstackgerritVladyslav Drok proposed openstack/ironic: Enhance wait_for_bm_node_status waiter  https://review.openstack.org/41034317:53
openstackgerritAndre Aranha proposed openstack/python-oneviewclient: Added validation for local_link_connection  https://review.openstack.org/37710317:54
*** moshele has quit IRC17:54
openstackgerritAndrey Shestakov proposed openstack/bifrost: Add support of remote logging  https://review.openstack.org/41024717:55
yufeihi, TheJulia, please help take a look at this patch when you have time.  https://review.openstack.org/#/c/397517/9/, hope to get your suggestions.17:56
patchbotpatch 397517 - ironic - Update multitenancy docs17:56
*** milan has quit IRC17:57
rloovdrok: thx. TheJulia, does it need another review or are you good with +A'ing https://review.openstack.org/#/c/410254/?17:59
patchbotpatch 410254 - ironic - Use polling in set_console_mode tempest test17:59
*** yufei has left #openstack-ironic18:00
vdrokrloo: re vif objects, do you think it's necessary to create a db table if we switch to ovo?18:01
TheJuliarloo: I'm fine with +A'ing18:02
rloovdrok: nope, not necessary. my only concern is that people may assume if we have ovo, that it is also being saved in db18:02
JayFI just landed it, in that case18:02
vdrokrloo: well, it's not the case for notifications already :)18:02
JayFI was reviewing it already so when julia said to +A I added that with my +2 :D18:02
rloovdrok: either way, json/dict, or ovo, isn't perfect in this case18:02
rloovdrok: oh yeah, you're right.18:02
rloovdrok: i'm fine if we go with ovo. was worried it'd be more work.18:03
TheJuliayuriyz: Sorry I didn't review it yesterday.  I was pondering the wording.  I put some suggestions in for clarity, sorry to drag this along :(18:03
rloovdrok: and also, not sure what it buys us if this vif object is generic.18:03
*** ijw has joined #openstack-ironic18:04
rloovdrok: all we know is that it has an ID. the rest will have to be in a dict for it to be generic.18:04
*** ralonsoh_ has quit IRC18:04
rloovdrok: but having said that, fine if we have an ovo for it.18:04
openstackgerritPavlo Shchelokovskyy proposed openstack/ironic: Move heartbeat processing to separate mixin class  https://review.openstack.org/40436418:04
rlooJayF, TheJulia: thx!18:05
JayFI guess I can pull that "itnermittant console failures" from the whiteboard now18:06
TheJulia:)18:06
rlooJayF: *after* it lands? :)18:06
* TheJulia runs to the store, bbiab18:07
*** daemontool has quit IRC18:08
vdrokrloo: will think on that with vasyl. otoh, to have proper ovo, we have to have a separate entity vif, with functions on it available, backportable if needed etc.18:09
*** krtaylor has quit IRC18:09
dtantsurgoing now, see you tomorrow18:10
rloobye dtantsur18:10
* dtantsur will present a lightning talk about ironic deployed by tripleo tomorrow in the office :)18:10
JayFdtantsur: planning on recording it or otherwise for upstream folks to consume? I guess that also assumes it's in english :P18:10
*** dtantsur is now known as dtantsur|afk18:10
dtantsur|afkJayF, I suspect the recording will be for internal consumption only :(18:11
rloodtantsur: cool! and ^^ although i was going to ask if there will be a wiki or doc about it18:11
*** spartacloud is now known as zackf18:11
dtantsur|afkwell, if you want serious docs, we have them http://tripleo.org/advanced_deployment/baremetal_overcloud.html18:11
dtantsur|afkthis is mostly like "look folks what we've got!" in 5-10 minutes kind of talk18:11
* rloo sorry she asked :)18:11
dtantsur|afkhaha18:12
openstackgerritAnup Navare proposed openstack/ironic: Allow logical name along with UUID in port creation  https://review.openstack.org/40558618:13
rloovdrok: the other thing about the vifs stuff. you can attach a vif to a node, that vif can have id and other info. if you do a vif-list though, you only get the IDs, the other stuff isn't saved. if we do ovo, it would be odd not to save the rest of the vif somewhere, and then to return it.18:14
*** lindycoder has joined #openstack-ironic18:16
vdrokrloo: yeah, 'other stuff' def needs to be stored somewhere18:17
*** pester has quit IRC18:20
rloovdrok: i added another comment, about vif-list should be a list of whatever thing that vif was in vif_attach.18:22
rloovdrok: thx for fixing it :)18:23
*** zackf has quit IRC18:23
vdrokrloo: vifs patch? that was vsaienk0 :)18:24
rloovdrok: i know, but he isn't around and you are :D18:24
vdrokhah18:24
vdrokI'll forward it to him tomorrow :)18:25
*** zackf has joined #openstack-ironic18:28
*** fragatina has joined #openstack-ironic18:29
vdrokxavierr: around?18:36
xavierrvdrok: yeap18:38
vdrokxavierr: I'm looking at https://review.openstack.org/397846 currently, and can not get one thing.18:39
patchbotpatch 397846 - ironic - Remove agent vendor passthru from OneView drivers18:39
vdrokxavierr: the two functions that are moved to oneview deploy mixin were not present previously in the oneview deploy, there were in agent base vendor18:40
vdrokxavierr: err, oneview vendor interface18:40
vdrokxavierr: so when the /heartbeat as a separate interface was implemented, deploy.heartbeat was called18:41
vdrokxavierr: which in turn was calling self.reboot_to_instance where self was still a deploy interface.18:41
vdrokxavierr: since those methods were not in deploy interface, the ones from the base agent/agent_base_vendor mixins were used18:42
vdrokxavierr: so /heartbeat requests were not working before?18:42
vdrokxavierr: only node vendor passthru heartbeats were OK?18:43
*** glonlas has joined #openstack-ironic18:44
mrtenioJayF, could you take a look here https://review.openstack.org/#/c/377073/? Thank you18:45
patchbotpatch 377073 - ironic - Adds another validation step when using dynamic al...18:45
JayFmrtenio: fwiw I have a +1 on that :)18:45
JayFmrtenio: but I'm also wondering; that patch conflicts with one that's significantly larger18:45
JayFmrtenio: that also has a single +2, I'm thinking it might be better to land that one first?18:46
JayFmrtenio: https://review.openstack.org/#/c/358041/18:46
patchbotpatch 358041 - ironic - Reusing oneview_client when possible18:46
xavierrvdrok: they were not working18:48
xavierrvdrok: they are working for this patch because methods were moved to there and are being called18:49
vdrokxavierr: aha, so in fact it fixes another bug18:49
vdrokapart from the removal of passthru18:50
vdrokxavierr: do you mind creating it and following up with a reno then?18:50
xavierrvdrok: what we are doing now is drop the need for this OneViewAgentDeployMixin in favor of this: https://review.openstack.org/#/c/408298/18:50
patchbotpatch 408298 - ironic - Shutdown server before change boot order for agent...18:50
xavierrif this new patch get merged we will not need this OneViewAgentDeployMixin anymore18:51
vdrokxavierr: I mean, filing a bug that /heartbeat does not work, and adding a reno that it is fixed after https://review.openstack.org/397846 ?18:51
patchbotpatch 397846 - ironic - Remove agent vendor passthru from OneView drivers18:51
vdrokxavierr: yup, gotcha18:51
vdrokxavierr: still would be good to track that for some period, that endpoint did not work18:52
xavierrwould be better adding a reno or working in 408298 directly?18:53
*** dprince has quit IRC18:54
vdrokxavierr: I'd say, just amend the 397846 reno, add another -fixes point. and then 408298 is just a refactor to drop unnecessary code18:54
xavierrvdrok: our vendor interface was necessary because of this bug, look: https://bugs.launchpad.net/ironic/+bug/150385518:54
openstackLaunchpad bug 1503855 in Ironic "Set boot device while server is on" [High,In progress] - Assigned to Xavier (marcusrafael)18:54
vdrokxavierr: sure, I get that. the question was about - /heartbeat was not working as those two methods were called only when vendor passthru was used. the vendor interface removal fixes /heartbeat. would be good to mention it18:55
vdrokxavierr: it can be done as a followup to 397846 reno18:56
xavierrvdrok: indeed. so I will add a reno in <fixes> session to 397846, ok?18:56
vdrokxavierr: yup. in a followup please :) to make it merge faster :P18:57
vdrokok, merging 397846 then, thanks for clarifying xavierr18:57
xavierrvdrok: thank you!18:58
xavierrvdrok: press the red button18:58
*** Sukhdev has joined #openstack-ironic18:59
vdrokdone :)18:59
*** fragatina has quit IRC19:01
*** krtaylor has joined #openstack-ironic19:01
*** fragatina has joined #openstack-ironic19:01
*** fragatina has quit IRC19:02
mrtenioJayF, I see it, and also it would be nice your opinion on that, if you could take a look on that patch. We from OneView driver think it would be better if the patch https://review.openstack.org/#/c/358041/ gets in first. :)19:02
patchbotpatch 358041 - ironic - Reusing oneview_client when possible19:02
*** fragatina has joined #openstack-ironic19:02
JayFmrtenio: that's what I suspected. MAybe make the other patch follow on behind that one then? sicne you're going to need a rebase anyway?19:03
JayFmrtenio: just landed that one, if you wanna rebase the other I can review it again19:05
mrtenioDoing it now19:08
*** dprince has joined #openstack-ironic19:08
nicodemoswow, thanks. JayF. :)19:09
*** cloudnull has left #openstack-ironic19:10
*** rcernin has joined #openstack-ironic19:14
openstackgerritMerged openstack/ironic-lib: Correct reraising of exception  https://review.openstack.org/40573419:14
*** madhu_ak has joined #openstack-ironic19:16
vdrokrloo: added a question on the crud notifications patch. I might be missing some context and maybe it's too late ...19:19
rloovdrok: how can it be too late?19:19
rloovdrok: looking....19:19
rloovdrok: that's a discussion for the spec.19:19
JayFrloo: because I landed it :x19:20
vdrokyeah I know :(19:20
rloovdrok, JayF; even though we land specs, we are also good at recognizing when we are wrong/can do better :D19:20
JayFvdrok: yeah, that question was handled in the spec, I was one of the advocates for that19:20
rloovdrok: i can't recall now, if initially it was just 'done'. might have been me or JayF ^^ that wanted start, end ...19:20
vdrokJayF: ok, lemme look through the history19:21
rloovdrok: i know that i wanted something similar to what nova was doing19:21
JayFvdrok: mainly because a deployer/operator, who doesn't have in depth knowledge of the system, doesn't have the context to realize for those few sync notifications that they didn't "miss" part of the notifications19:21
rloovdrok: you don't know what/why someone wants notifications.19:21
JayFbasically, the idea it's sync vs async is something mostly only a developer cares about19:21
JayFand it creates a notification chain that's harder to follow without that contextual knowledge19:21
vdrokJayF: but we still have the success-only notifications in chassis case, and in port.create19:22
JayFmariojv: ^ you might find this chat interesting19:22
JayFvdrok: well that's inconsistent and silly, we should've done the start-error-end style pattern for all of them :(19:22
JayFvdrok: you're exactly right, and I missed that in review19:23
openstackgerritStenio Araujo proposed openstack/ironic: Adds another validation step when using dynamic allocation  https://review.openstack.org/37707319:23
openstackgerritStenio Araujo proposed openstack/ironic: Reusing oneview_client when possible  https://review.openstack.org/35804119:23
*** milan has joined #openstack-ironic19:23
rlooJayF: i saw that 'success' thing but i think by that time, i was happy that i got <something else> agreed to and didn't want to pick on more stuff.19:24
JayFokay, so vdrok is right19:24
JayFthe implementation doesn't match the spec19:24
JayFthe spec shows a single, node.create.success for creating a node19:24
mrtenioJayF, 'did it. :)19:24
JayFthe code implements a start-error-end19:24
mariojvhm19:24
mariojvi think .success makes sense for non-async operations19:24
rlooJayF: you must have an old version, we changed node create cuz the creating moved to the conductor19:24
rlooJayF: creation of node is a start/end/error, whereas chassis/port creation is a success i think.19:25
JayFrloo: aha, you're right. I was reading the spec via the review.openstack link, and there was also an update patch landed after that19:26
vdrokrloo: JayF if the whatever system is used filters out the representation of resources that has updated_at value earlier than what it has in cache, it should be ignoring that. If it is newer then that question still holds: if we do update start, then update error, we'll send the exact same representation of node we did already have in cache. and in case of19:26
vdrokcrud, I can't think of a case when this system is not a caching representations system19:26
rloomariojv: i think it is consistent to have start/end w/i the API level for port/chassis, but i don't care that much19:26
mariojvcorrectness is more important than consistency to me19:27
mariojvif it's async or long running, should be start/end, otherwise if it's quick and sync, .success19:27
rloovdrok: so i honestly have no idea how notifications are going to be used. seems like we should design it for general cases, whatever that might be.19:27
mariojvi don't remember that part of code exactly though19:27
JayFmrtenio: now to wait for oneview ci to pass :)19:27
mariojvi think they're mainly going to be used for searchlight. i was going to use them for an automated resolution system (downstream feature), but now we're going to have specific fault support to cover that19:28
rloovdrok: honestly, except for the notifications that have already landed, it isn't too late to change anything.19:28
mariojvit isn't too late for those, either, would just need version bumps19:28
mariojvimo19:28
vdrokrloo: the ones that landed are async, that should be OK19:28
rloomariojv: we know that they are being used for searchlight, but i would like to believe we're doing this for other consumers (in the future) besides searchlight.19:28
mariojv++19:28
JayFFWIW, I didn't land the cRUD notifications, only voted +2. I think I intended to land it and just didn't.19:29
JayFrloo: ++ one case I would have for it if I were still operating onmetal, is using the notification ordering to track a node19:29
rlooJayF: doesn't matter who landed it or who reviewed it. we're a community.19:29
rlooJayF: i'm going to blame it on vdrok for not reviewing it in the first place :D19:29
vdrokI'm trying to find are there definitions for start/end/success notification statuses anywhere outside of ironic19:29
JayFrloo: OK. I just still get a little nervous about landing stuff of that size :)19:29
*** fragatina has quit IRC19:30
mariojvvdrok: start/end yes, i doubt it for success, we came up with that term i  believe19:30
rlooJayF: i'm nervous about a lot of stuff. but gotta land them at some point and then iterate/fix later.19:30
vdrokmariojv: aha, ok19:30
*** fragatina has joined #openstack-ironic19:30
rlooJayF: some stuff isn't noticed and/or harder to argue about until the developer has coded.19:30
rloovdrok: nova's: http://docs.openstack.org/developer/nova/notifications.html19:32
vdrokyeah I'm reading through that currently19:33
rlooi think mariojv is right, we came up with 'success'.19:33
vdrokit does not define the meanings tho19:33
*** ijw has quit IRC19:33
vdrokas they appear to be self-explanatory :D19:33
vdrokJayF: rloo: mariojv on that nova page, it seems that instance.update is kind of close to our case19:35
rloovdrok: honestly, i think notification event types should be a xproject thing so there is consistency etc19:35
vdrokof synchronous update19:35
*** alexpilo_ has joined #openstack-ironic19:36
vdrokwill look into code19:36
vdrokugh, nova is so slow even for clone19:37
*** alexpilotti has quit IRC19:39
*** ijw has joined #openstack-ironic19:39
*** Sukhdev has quit IRC19:41
*** Nisha_Agarwal has quit IRC19:44
vdrokrloo: JayF mariojv yeah, so in nova, compute.instance.update is a notification sent from objects.instance.save19:44
vdrokno start/end19:45
JayFmariojv: ^19:45
JayFvdrok: I'm realy curious what mariojv has to say about that design; I know before he worked on upstream openstack he did a  *lot* of work parsing nova notifications for Rackspace19:45
*** e0ne has joined #openstack-ironic19:45
JayFand I think a lot of those lessons learned were reflected in the spec19:45
vdrokI guess it does not hurt much if we append success to that, even if it's different from nova tho19:46
vdrokJayF: sure19:46
JayFI would rather not roll back all that design work in the spec on a whim, without fully getting into the details again19:46
vdrokwell, I can not really do that myself :D19:46
rloovdrok: i think yuriyz may have initially had the CRUD stuff emit notifications in the .save() but for whatever reasons (which i must have commented on), i wanted him to move them to the api level.19:46
vdrokrloo: yeah, IIRC there were some special casing magic there19:47
rlooJayF: well, i wouldn't call it a whim. vdrok needs to be able to support his case and convince folks.19:47
mariojvnova's notifications weren't as structured as ours19:47
vdrokrloo: but looking at the nova's instance.save, I doubt we'll be able to get any close to that :)19:48
mariojvnote that it's compute.instance.update, not compute.instance.update.<phase>19:48
JayFrloo: sure; I get that. We just already went through a few rounds of that in the spec :P19:48
vdrokI'm not opposed to doing it on the api side tho19:48
rlooJayF: yeah, I know :)19:48
rloovdrok: after all that ^^, what are you proposing?19:48
vdrokmariojv: yes, exactly19:48
mariojvupdate is describing the actionbeing taken. it's not an indicator that the action is sync19:48
vdrokfor now, I have in mind - replacing all the sync actions notifications to have only .success event19:49
rloovdrok: but what if it failed?19:49
mariojvthen .error is sent19:49
vdrokthat includes all {node,port,chassis,portgroup}.{create,update,delete}19:50
*** e0ne has quit IRC19:50
JayFI didn't think all of those were sync anymore though?19:50
JayFHasn't node create been moved to the conductor?19:50
JayFOr are you talking about, things done over RPC but return sync from API client perspective19:50
rlooJayF: define 'sync'. Some of those do not go through the conductor, some do.19:50
JayFyeah, that's what I'm trying to nail down, what's mean by "sync" in this case19:51
mariojvhttps://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/notifications.html#proposed-change19:51
mariojvsuccess means "immediate"19:51
patchbotThe operation succeeded.  means immediate19:51
mariojv??? ^19:51
vdrokrloo: JayF mariojv: if the node is not created, why send any notification? user will get 500 error code or something. same for failed update/delete, they will get error code from the api. and the representation won't change19:51
mariojvstart/end are not immediate19:51
mariojvso not necessarily sync vs. async19:51
rloovdrok: because we don't know what the notification system is being used for. it is not the user.19:51
mariojvvdrok: this is for a service that may be external to the client to check19:51
mariojvsearchlight won't know, for example, if you fail to create a node19:52
JayFvdrok: use case: I have a metric based on how many failures. If I get too many .error notifications, I don't meet my sla of "running a stable ironic cloud" or something.19:52
rloovdrok: what if the notification system is used for eg, checking that the ironic service isn't flaky, that 'starts' have 'ends' or 'errors' and dont' just disappear.19:52
JayFvdrok: this is almost identical to how Rackspace uses nova notifications today, fwiw19:52
*** wajdi has joined #openstack-ironic19:52
mariojvyes19:52
vdrokmariojv: well, if you do that, then you know it failed. if someone else tells you that he's updated the node when he's got 500, he's lying :)19:53
mariojvand it's an extremely large pain19:53
mariojvbecause some errors do have notifications, and some don't19:53
mariojv*i* know19:53
JayFnotifications, logs, and immediate api response codes19:53
mariojvbut my external collection service does not19:53
JayFall have different use cases and potentially different consumers19:53
vdrokJayF: OK, that justifies error notification (but not its body sending the whole node)19:53
*** ijw has quit IRC19:54
vdrokbut start notification is kind of useless to me19:54
mariojvwell, if i want to troubleshoot why my node create calls are failing19:54
mariojvit's useful to see what was in the node19:54
JayFand it's not a bad thing; it's a good thing to duplicate information between them19:54
JayFlogs are more single-instance troubleshooting targeted, notifications can be used to troubleshoot items on a larger scale (i.e. find patterns, troubleshoot a node over a long period of time), immediate response codes are for the user right then19:54
mariojvmaybe all nodes that have a particular field error out19:54
mariojvalso, the consumer can just discard info it doesn't need19:54
JayFvdrok: ^ I think troubleshooting a node over time, and making patterns when the errors occur, justify storing the node19:55
mariojvthat's what searchlight does, only tracks changes19:55
rloovdrok: i can see that .start may be useless to you. but for mariojv and JayF, it is useful.19:55
vdrokmariojv: but you already have the representation of the node sent in previous successful notifications?19:55
JayFwe explicitly /want/ to be able to go back in time and see the exact state of the node when it errored vs when it didn't error19:55
rloovdrok: given that .start is useful to others, are you opposed to having .start. you can just ignore it.19:55
mariojvvdrok: also, if you just want error notifications, there's a config option for that19:55
JayFwhen troubleshooting these things in the real world, the one biggest lesson I learned is never underestimate how useful more informatin is :)19:56
JayFwhich is why I was especially pleased we put the node in all relevant notifications19:56
rloomariojv, vdrok: would it be useful to have .start at a diff config level from .end?19:56
JayFrloo: it would have to be orthoganal to the level19:56
mariojvi think it makes things too complicated19:56
JayFrloo: i.e. level configured, aand like what phases to notify on19:57
JayFbut I agree with mariojv about it adding complexity19:57
JayFespecially when a consumer could easily be configured to ignore the notifications it doesn't want19:57
mariojvit's easy for operators to understand priority levels, like log levels19:57
rlooJayF, mariojv: adds complexity if you want to change the default behavior. am trying to figure out something that works for you three :)19:57
mariojvconfiguring at the other granularity would probably require familiarity with the lifecycle of an operation in ironic19:57
vdrokrloo: JayF mariojv OK, i get the error case now. in case of start - 3 possibilities : create (start of create only useful if you want to see the body caused the failure), update( start not needed as you have the representation of the node from previous notifications), delete (same as update)19:57
mariojvi don't understand what the issue is though19:57
rloomariojv: the issue is vdrok doesn't care about .start notifications.19:58
vdrokin case of create failure, I'd still stick with the ironic logs, as delivery of notifications is not guaranteed19:58
mariojvfor debugging sure19:59
mariojvnot for alerting, unless you have real time log analytics19:59
JayFI mean, even for debugging: at a certain larger scale you're going to be looking at aggreggate statistics20:00
JayFand logs are /awful/ for tracking the life cycle of a single node20:00
JayFand notifications can be good for that20:00
mariojvyup20:00
vdrokmariojv: JayF rloo you'll still get sucess/error right? without start20:01
vdrokwould it be enough for statistics?20:01
*** ijw has joined #openstack-ironic20:01
JayFGoing back to the real-world usage of notifications from nova that rackspace does today20:01
JayFwe explicitly, for some actions, time the difference between the start/end notifications20:02
JayFin order to determine system performance20:02
mariojvno20:02
JayFmariojv: no?20:02
mariojvno to vdrok's question20:02
JayFah, okay20:02
JayFyeah b/c we use start/end for instance-boot-timings in nova, right?20:02
mariojvmaybe i'm getting DDoSed, and conductor is held up before everything finishes20:02
mariojvi see 10K .start events, alert an engineer20:02
mariojvyes, and timing20:02
mariojvthat can be solved separately with the @METRICS decorators thoguh20:03
vdrokhmmm20:03
vdrokOK then in theory you need start/end/error everywhere, no matter sync operation or not. just in case of any operation going outside of ironic boundaries (like write to db, sending over rpc)?20:04
openstackgerritMilan Kováčik proposed openstack/python-ironic-inspector-client: List introspection statuses support  https://review.openstack.org/40811620:05
JayFvdrok: that's exactly why I hrm'd at the idea of only doing success/error for stuff that hits rpc20:05
mariojvhmm, maybe20:05
mariojvi guess it depends on the definition of "immediate"20:05
vdrokthe only thing that would be unnecessary to have start/end/error would be eg modifying in-memory object then :)20:06
mariojvand sometimes we might notify on that20:06
mariojvfor example, conductor startup20:06
JayFWell, I think the DB operations can be pretty much presumed to be immediate, but I can see an argument for that20:06
mariojvi disagree, long-running queries happen20:06
vdrokI see your logic now. but that will end up very extensive on the messaging bus, like 3 notifications for every node action at least, very close to each other in time20:07
mariojvvdrok: that's what priority level config is for20:07
mariojvvdrok: you can ignore all notifications with priority level < ERROR if you want20:07
vdrokmariojv: JayF also for the aggregate statistics thing, we don't really need the actual object representation right?20:08
mariojvvdrok: also, nova emits *tons* more notifications than we ever will and is fine on some beefy rabbitmq nodes20:08
mariojvvdrok: yes, you do20:08
JayFvdrok: remember that multiple use cases exist; the object representation is useful for troubleshooting case, even if not useful in all cases20:08
mariojvvdrok: "show me all attempts at creating nodes with agent_ipmitool driver in the past 24 hours"20:08
vdrokright. that's hard :(20:09
mariojvvdrok: "show me all fields changed on all nodes with .error events for the past hour"20:09
vdrokto predict everything20:09
openstackgerritMerged openstack/ironic: Remove agent vendor passthru from OneView drivers  https://review.openstack.org/39784620:10
vdrokmariojv: JayF rloo OK, after that discussed, and believing you :D that a whole lot more nova notifications can be handled without much trouble, I'm good with that, thanks for clarifying!20:11
mariojvthank you vdrok! always good to check my assumptions20:11
JayFThese discussions are super fun20:11
rloothx vdrok, mariojv, JayF :)20:11
JayFhonestly20:11
JayF:D20:11
vdrokthat still leaves the problem of the patch having success things. yuriyz won't be happy about the outcome :D20:11
rlooJayF: wish we had time to document/update spec with some of this info but anyway20:12
rloovdrok: you mean, you don't like 'success'?20:12
JayFvdrok: Can you summarize what we think the diff is from what already exists in the spec?20:12
mariojvi don't think there is a difference, lol20:12
mariojvmaybe more clarity on the word "immediate"20:12
* rloo doesn't like success but didn't think it was worth arguing over it20:12
vdrokmariojv: hm, if i got you correctly, even port/chassis create would have to emit start/end/error right?20:13
mariojvvdrok: i don't really care that much20:13
vdrokJayF: rloo will do that first thing in the morning tomorrow20:13
mariojvvdrok: i'd have to read the code, but imo (the way i was envisioning in the spec)20:13
mariojvvdrok: was send .start when api call is received, .end when done20:14
mariojv.error if something bad happens in between that ironic can't handle20:14
mariojvdunno about client error20:14
JayFmariojv: the spec explicitly ssays success/error style for chassis/port create20:14
mariojvi'm fine with the way yuriyz was doing it for now though20:14
mariojvohhh20:14
JayFmariojv: so if we're doing start/error/end, that's a change from the spec and the preexisting code20:15
mariojvwell, like i said, i don't really care that much20:15
mariojvit can always be changed with version bumps later20:15
rlooi'd be very happy if we got rid of success and replaced with start/end/error20:15
mariojvi cared more about start/end with nodes20:15
vdrokif we are saying about trying to catch all cases, then it seems to me 'start/end/error' everywhere and no success20:16
rlooi think it'd make it easier for notification system, not to have to deal with 'success'.20:16
mariojvi don't think it would make things easier20:16
mariojvit's just parsing a string20:16
rloomariojv: but two diff cases instead of just one.20:16
mariojvif you want one case, just write a catch-all20:17
rloomariojv: and if we ever end up moving the chassis/port creates to the conductor, the notifications will change.20:17
mariojvonly look at .end/.success20:17
JayF^ that to me is the best argument for making port/chassis creates start/error/end20:17
JayFwhat rloo just said20:17
*** amoralej is now known as amoralej|off20:17
mariojvso, i'm +0.5 to making all the API calls start/end20:17
mariojvi'm -1 to removing .success notifications altogether20:17
rloomariojv: do we already have some .success?20:18
vdrokmariojv: I just don't know how to define it then20:18
mariojvi was just checking that20:18
mariojvthought maybe some of the power notifications might be20:18
vdroksuccess is not immediate20:18
patchbotThe operation succeeded.  is not immediate20:18
vdrokwow :D20:18
mariojvbe quiet patchbot20:18
JayFsuccess I am still a stupid patchbot.20:18
patchbotThe operation succeeded.  I am still a stupid patchbot.20:18
rloomariojv: yup baremetal.node.power_state_corrected.success20:18
rloobaremetal.node.provision_set.success20:19
vdrokthese are async right?20:19
vdrokcrud are all sync20:19
mariojvno20:19
rlooahh, those are special.the ones with .success are not initiated by any API call.20:20
mariojvhttps://github.com/openstack/ironic/blob/master/ironic/conductor/manager.py#L97320:20
rloobaremetal.node.provision_set.success is emitted when ironic-conductor successfully changes provision state instantly, without any intermediate work required (example is AVAILABLE to MANAGEABLE). It has notification level INFO.20:20
mariojvyup rloo20:20
rloobaremetal.node.power_state_corrected.success is emitted by ironic-conductor when the power state on the baremetal hardware is different from the previous known power state of the node and the database is corrected to reflect this new power state. It has notification level “info”.20:20
rloomariojv: i love documentation :)20:20
mariojv\o/20:20
rloomariojv: and i think we went back/forth on those ^^ but it didn't make sense to ahve start/end on them.20:21
mariojvexactly20:21
mariojvyou either correct it or you don't20:21
vdrokmariojv: mariojv rloo but that is still db write20:21
rloomariojv: so yeah, i'm good with them being .success.20:21
mariojvyeah20:21
mariojvimplicitly20:22
vdrokthat's why I don't know how to define success properly20:22
mariojvalso, one thing20:22
vdrokonly db write can be success, but db write + rpc can not>20:22
mariojvwell, never mind20:22
vdrok?20:22
openstackgerritMerged openstack/ironic: Use polling in set_console_mode tempest test  https://review.openstack.org/41025420:23
mariojvi guess the start/end/success distinction isn't very specific20:23
mariojvyou're right, db writes are considered "immediate" from that perspective20:24
vdrokrloo: JayF are you ok with that? ^^20:24
mariojvvdrok: i have an idea20:24
mariojvvdrok: what if we have a DB error notification?20:24
mariojvthat's just a ".error"20:24
mariojvno .success for db writes because that'd be wild20:25
mariojvvdrok: presumably, ironic will give up after a while if a db call hangs?20:25
rloovdrok: i honestly didn't/don't think of it in terms of db writes. almost any change is going to involve a db write. any change worth notifying i think.20:25
mariojvyeah, RPC vs. db is a distinction worth making i think20:26
mariojvmessage queues are lossier20:26
vdrokmariojv: success emitted in the api and and error in dbapi?20:26
mariojvvdrok: just .error in dbapi20:26
mariojvso i have baremetal.node.power_state_corrected.success20:26
mariojvif that task.process_event call right above the line i linked fails20:27
mariojvit's because of a db error20:27
vdrokmariojv: in case of update, that'd be hard to distinguish api-based update from ironic itself updating20:27
mariojvsend a notification, something like baremetal.db.write.error20:27
mariojvthe error is unrelated to whatever you're notifying on, it's a DB problem20:27
vdrokhm20:27
JayFmariojv: I like that, as an operator, but I think it's kinda orthoganal to the conversation, right?20:28
mariojvJayF: i think it's good because it keeps our assumption that db writes are immediate in place20:28
vdrokmariojv: OK, I'll need to discuss it with yuriyz, because it may require significant changes from the current impl20:28
mariojvallowing us to distinguish things like rpc calls from things that should be immediate20:28
mariojvsounds good20:28
mariojvvdrok: i wasn't saying that we should do the db error notification *now*20:29
mariojvjust that it would solve the distinction between .success and .start/.end20:29
vdrokotherwise the patch is good to go as is :)20:29
mariojvso, what needs to change about the patch?20:29
mariojvoh, just make it .success? to match spec?20:30
JayFport and chassis create need to go from success/error -> start/error/end20:30
vdrokbut I'm not ready to push +A now, will do it tomorrow, along with spec update. As it will be mostly clarifying the use cases/our intents on why we have done it this way20:30
JayFright?20:30
vdrokJayF: oh, right, errors20:30
vdrokJayF: so I think that ^^ discussions means, success/error where it is success currently20:31
vdrokand start/end/error everywhere else20:31
mariojvfine by me20:32
mariojvi prefer start/end everywhere for api stuff20:32
JayFSomeone should probably link to this IRC discussion20:32
JayFwith a -1 on the existing patch20:32
mariojvbut i can propose that as a follow up at some point20:32
JayFso that yuriy know's what happened to his patch :x20:32
vdrokmariojv: so end or error instead of success or error?\20:32
mariojvvdrok: don't worry about it, let's go with what you said20:33
vdrokOK phew :)20:33
mariojvthe sppec update for clarifyign20:33
mariojv*clarifying20:33
*** mrtenio is now known as mrtenio-afk20:33
vdrokI'll add a link and a comment20:33
mariojvmy follow up == 6 months from now :)20:34
*** ijw has quit IRC20:34
rloomariojv: i think if you just update dev docs, would be sufficient?20:35
JayFhttps://etherpad.openstack.org/p/iFoG829Xig is some info ttx pulled about participation20:35
JayFit was mentioned at the TC meeting20:35
JayFIronic has less changes proposed but more merged20:36
rlooJayF: participation in what?20:36
JayFrloo: changes proposed / changes merged20:36
JayFrloo: i.e. vs the first few weeks of newton20:36
mariojvthat seems good20:36
*** ijw has joined #openstack-ironic20:36
JayFrloo: ironic merged more commits but had less proposed, which I viewed as a good sign -- we're all very well aligned on the stuff that matters, and are staying focused on the priorities20:36
rlooJayF: didn't realize i was working on a 'protocore' project. glad to know that our core team 'operates correctly'...20:37
rlooJayF: i'm not sure what to think of these numbers. it should be the numbers. quality. makes me a bit sad. anyway, maybe it is useful...20:37
JayFrloo: *shrug* I ignored the headers because those are more or less a function of time20:37
rlooJayF: s/should/should not/20:37
JayFIt's just an interesting thing to read, and I think a credit to our ability to stay on target and land code20:38
mariojvthis seems similar to measuring lines of code as impact though, lol20:38
JayFin a time when other projects are seeing a drop20:38
mariojvexcept for the contributor metric perhaps20:38
JayFI tend to try to find the things to be happy about in numbers, and just use them as a tool for motivation :)20:38
rlooJayF: dunno about that. i wouldn't pat ourselves in our back, or whatever the expression is.20:38
rlooJayF: good attitude!20:38
*** ijw has quit IRC20:38
JayFI'm pessimistic by default so I'm always fighting the negativity20:39
JayFlol20:39
rlooJayF: really, thought the opposite of you and *I* am pessimistic :D20:39
*** ijw has joined #openstack-ironic20:40
TheJuliarloo: I've known JayF for a very long time.  He is absolutely a pessimist by default :)20:40
rlooTheJulia: thx for confirming :)20:41
JayFThat's part of why I try to be ... expressive in a positive way20:41
JayFI'm not trying to cheer others up, I'm trying to keep myself cheery20:42
openstackgerritJulia Kreger proposed openstack/ironic: Add storage_interface to base driver class  https://review.openstack.org/34800620:42
vdrokJayF: interesting stuff. nova people are who should be pessimistic, not us :)20:44
* vdrok leaves now20:44
vdrokgood night!20:44
rloonight vdrok, thx for the discussion!20:45
mariojvgood night20:45
*** moshele has joined #openstack-ironic20:57
*** ijw has quit IRC20:59
TheJuliadtantsur|afk: I finally got some brain cycles to begin work again on 355625, and I replied to your comments regarding auth parameters.  I'll try to get up early my time tomorrow to discuss if necessary.20:59
*** [1]rpioso has joined #openstack-ironic21:01
*** ijw has joined #openstack-ironic21:02
*** causten has joined #openstack-ironic21:03
*** rpioso has quit IRC21:04
*** jkilpatr_ has quit IRC21:05
*** moshele has quit IRC21:10
*** srobert has quit IRC21:14
*** moshele has joined #openstack-ironic21:16
*** baoli_ has joined #openstack-ironic21:19
*** baoli__ has joined #openstack-ironic21:19
*** baoli__ has quit IRC21:21
*** jkilpatr_ has joined #openstack-ironic21:21
*** baoli__ has joined #openstack-ironic21:21
*** baoli has quit IRC21:22
*** baoli_ has quit IRC21:24
*** glonlas_ has joined #openstack-ironic21:25
*** rajinir has quit IRC21:26
*** glonlas has quit IRC21:28
*** madhu_ak has quit IRC21:28
openstackgerritPavlo Shchelokovskyy proposed openstack/ironic-python-agent: Probe for TC mirror during tinyipa build  https://review.openstack.org/41040421:29
*** glonlas_ has quit IRC21:30
*** chlong has quit IRC21:30
*** dsneddon has quit IRC21:35
*** baoli has joined #openstack-ironic21:36
*** amoralej|off is now known as amoralej21:36
*** baoli__ has quit IRC21:37
*** ijw has quit IRC21:37
*** baoli_ has joined #openstack-ironic21:37
*** baoli_ has quit IRC21:38
*** baoli_ has joined #openstack-ironic21:38
*** dprince has quit IRC21:39
*** dprince has joined #openstack-ironic21:39
*** baoli has quit IRC21:41
*** dprince has quit IRC21:50
JayFpas-ha is going to win most ingenious IPA patch award as soon as https://review.openstack.org/#/c/410404 passes the gate so I can vote on it21:56
patchbotpatch 410404 - ironic-python-agent - Probe for TC mirror during tinyipa build21:56
JayFlol.21:56
*** jcoufal has quit IRC21:57
pas-haHehe21:58
pas-haI'll post another patch set tomorrow, one thing missing21:58
*** moshele has quit IRC21:59
*** trown is now known as trown|outtypewww21:59
*** led_ has joined #openstack-ironic21:59
*** krtaylor has quit IRC22:00
*** amoralej is now known as amoralej|off22:01
*** priteau has quit IRC22:04
*** rajinir has joined #openstack-ironic22:08
pas-hathou shall find mirrors :) http://logs.openstack.org/04/410404/1/check/gate-tempest-dsvm-ironic-ipa-partition-pxe_ipmitool-tinyipa-src-ubuntu-xenial/7bb02d8/logs/devstacklog.txt.gz#_2016-12-13_21_48_18_17122:08
* pas-ha signing off, have a good day all22:10
*** milan has quit IRC22:10
*** sacharya_ has quit IRC22:10
*** sacharya has joined #openstack-ironic22:11
*** [1]rpioso has quit IRC22:12
*** bfournie has quit IRC22:19
*** jkilpatr_ has quit IRC22:25
*** zackf has quit IRC22:28
*** zackf has joined #openstack-ironic22:29
*** jrcloud has joined #openstack-ironic22:31
*** spartacloud has joined #openstack-ironic22:32
*** ijw has joined #openstack-ironic22:33
*** zackf has quit IRC22:34
*** jrcloud has quit IRC22:35
*** zackf has joined #openstack-ironic22:45
*** jheroux has quit IRC22:45
*** spartacloud has quit IRC22:47
*** wajdi_ has joined #openstack-ironic22:51
*** wajdi_ has quit IRC22:52
*** wajdi_ has joined #openstack-ironic22:53
*** wajdi has quit IRC22:55
*** bfournie has joined #openstack-ironic23:02
*** wajdi_ has quit IRC23:04
*** jkilpatr_ has joined #openstack-ironic23:05
openstackgerritRamamani Yeleswarapu proposed openstack/ironic-inspector: Update documentation to deploy Ironic Inspector with DevStack  https://review.openstack.org/41045623:24
openstackgerritHugo Nicodemos proposed openstack/ironic: Reusing oneview_client when possible  https://review.openstack.org/35804123:26
*** swatson has joined #openstack-ironic23:29
*** swatson has left #openstack-ironic23:29
*** swatson has joined #openstack-ironic23:29
swatsonAnyone in the channel I could ask a quick question regarding your DB migration tests?23:30
swatson"your" being the ones in ironic23:30
JayFYou're welcome to ask :) This is one of the quieter times w/r/t timezones and such23:32
JayFand while I'm here, I doubt I know what you're asking23:32
JayFlol23:32
swatsonJayF: Haha well thanks :) And I kinda figured the time wasn't great anyway, but worth a shot23:33
swatsonAnyway, I was reading test_migration.py in the DB unit tests and it mentions openstack_citest, but I couldn't find any mention of it in code23:33
swatsonIs that something set up in a config file that gets read by oslo_db stuff?23:33
swatsonI should probably add I'm working on adding migration testing for magnum, and was pointed to the ironic tests23:35
JayFoh; so I think what that's talking about23:35
JayFis to run those unit tests you have to have a DB setup with access for it to use23:35
swatsonRight, but I couldn't find anywhere where that string is actually used, at least in code23:36
JayFyeah; I'm on a hunt for it now too23:36
swatson:)23:36
swatsonIt's definitely getting used, since I can run the migration tests but 14 get skipped (the other 4 all pass)23:38
swatsonI'm 99% certain it's because I haven't set up that DB yet.23:38
JayFI'm checking codesearch.openstack.org23:38
JayFI'd expect that to get setup in CI or something23:38
JayFbut it's not in ironic's devstack anywhere23:38
JayFhttp://git.openstack.org/cgit/openstack-infra/storyboard/tree/doc/source/contributing.rst references setting it up for storyboard ci too23:39
JayFso it's a common openstack pattern23:39
JayFswatson: aha! It appears to be pre-setup before the job even runs23:40
JayFswatson: via project-config23:40
JayFhttp://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/macros.yaml search that file for openstack_citest23:40
JayFswatson: I'm curious, it was a bit of an XY question, what are you really trying to do?23:41
swatsonJayF: End goal is to set up migration testing for magnum, as we currently have none23:41
JayFaha23:41
JayFwell it looks like project-config does the magic db setting up for you23:41
swatsonThanks for the find :D23:41
JayFyeah23:41
JayFand it looks like the code is directly in our repo, for test_migrations23:42
JayFto se if it can connect, if not it just happily skips it23:42
swatsonYeah, I was turning my wheels trying to figure out how the test base got the info23:42
swatsonThis at least explains how Jenkins starts the DB but it looks to me like there's something between Jenkins and tox that tells the test the DB name23:43
JayFswatson: https://github.com/openstack/ironic/blob/master/ironic/tests/unit/db/sqlalchemy/test_migrations.py#L23223:44
swatsonD'oh23:45
JayFswatson: I'm going to garner a guess that FIXTURES is configured via env variables23:45
JayFswatson: after tracking the code back23:46
swatsonJayF: I saw that call and must have just glossed over it after not seeing my string23:46
JayFI have the advantage of knowing I miss things, so I always use ^f to find the thing23:46
JayFlol23:46
swatsonSmart :D23:47
swatsonI'23:47
swatsonI'll poke around with this a bit more and see what I dig up. Thanks for the help!23:48
JayFno problem. Good luck!23:48
*** sacharya has quit IRC23:57
*** baoli_ has quit IRC23:59
*** baoli has joined #openstack-ironic23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!