Wednesday, 2016-07-13

*** piet has quit IRC00:00
*** rama_y has quit IRC00:01
*** sabeen has joined #openstack-ironic00:05
*** rbudden has quit IRC00:18
*** daemontool has quit IRC00:21
*** ChrisAusten has quit IRC00:24
*** Sukhdev has quit IRC00:29
*** hoangcx has joined #openstack-ironic00:38
*** mtanino has quit IRC00:53
*** garthb has quit IRC00:53
*** piet has joined #openstack-ironic00:57
*** tiendc has joined #openstack-ironic01:05
tiendcgood morning, folks01:06
tiendclucasagomes vdrok jlvillal: hi, could you help to review https://review.openstack.org/#/c/328168/  https://review.openstack.org/#/c/293873/01:12
tiendclucasagomes vdrok jlvillal: they got some +2 from you, only minor changes remain01:13
*** piet has quit IRC01:17
*** ijw has joined #openstack-ironic01:19
*** baoli has joined #openstack-ironic01:25
*** clenimar_ has quit IRC01:29
*** phuongnh has joined #openstack-ironic01:32
*** hshiina has joined #openstack-ironic01:38
*** rloo has quit IRC01:39
*** clenimar_ has joined #openstack-ironic01:41
*** baoli has quit IRC01:42
*** ijw has quit IRC01:49
*** ccamacho has joined #openstack-ironic01:53
*** ijw has joined #openstack-ironic01:54
*** ijw has quit IRC01:59
*** caoshufeng has joined #openstack-ironic02:18
*** jaybeale has joined #openstack-ironic02:19
*** joprovost has joined #openstack-ironic02:26
TheJuliayeouch, bifrost with cirros on a CI run... [ 1230.758644] systemd[1]: Startup finished in 25.705s (kernel) + 38.269s (initrd) + 19min 26.631s (userspace) = 20min 30.607s. :(02:31
caoshufengGood morning all. I need some suggestion with this bug report. https://bugs.launchpad.net/ironic/+bug/160249002:35
openstackLaunchpad bug 1602490 in Ironic "inconsistent log of node_id and node_uuid when acquiring node lock" [Undecided,New] - Assigned to Cao ShuFeng (caosf-fnst)02:35
caoshufengShould this bug be fixed?02:36
caoshufengOr this bug is invalid?02:36
openstackgerritJulia Kreger proposed openstack/bifrost: Do Not Merge: Canery test for ironic networking changes  https://review.openstack.org/33013802:37
openstackgerritJulia Kreger proposed openstack/bifrost: Do Not Merge: another test for ironic networking  https://review.openstack.org/33021002:37
TheJuliaAnd I'm worried bifrost's gate might be broken hence ^^^ :(02:38
TheJulialooking caoshufeng02:38
caoshufengTheJulia, Thanks in advance02:39
*** jaybeale has quit IRC02:41
*** ijw has joined #openstack-ironic02:41
*** vishwanathj has quit IRC02:41
*** ijw has quit IRC02:42
*** thrash|wknd has quit IRC02:42
*** vishwanathj has joined #openstack-ironic02:42
*** ijw has joined #openstack-ironic02:42
*** baoli has joined #openstack-ironic02:42
*** thrash has joined #openstack-ironic02:44
*** thrash has quit IRC02:44
*** thrash has joined #openstack-ironic02:44
*** bvandewa_ has joined #openstack-ironic02:44
*** amoralej|off has quit IRC02:46
*** amoralej has joined #openstack-ironic02:47
*** ijw has quit IRC02:47
*** bvandewa has quit IRC02:48
TheJuliacaoshufeng: oh, I see... the way the task_manager.acquire statement, at least with update_port, sets the port_obj.node_id instead of task.node.uuid02:48
*** bvandewa_ has quit IRC02:48
TheJuliacaoshufeng: I think a more verbose example might help for anyone looking at the bug, but yes, that does seem like a bug02:49
caoshufengTheJulia, yeah, I known it's sort of "trivalfix" if I try to close it.02:50
caoshufengSo I ask here in advance.02:51
caoshufengTheJulia, I will commit a change to fix it,since not only myself treat it as a bug.02:52
TheJuliahttps://github.com/openstack/ironic/blob/master/ironic/conductor/manager.py#L163002:53
TheJulia:)02:53
TheJuliaI marked the bug as confirmed02:53
TheJuliaand with that, I think I likely need to call it a night02:54
TheJuliaHave a wonderful day caoshufeng02:55
caoshufengOh, yeah, Thanks.02:56
caoshufengI will start the patch soon.02:56
TheJuliacaoshufeng: you may just want to look for other places where that is done, espescially if you have more examples of such inconsistency :)02:57
gbraadTheJulia have a good one02:58
caoshufengTheJulia, can I updata codes here: https://github.com/openstack/ironic/blob/master/ironic/conductor/task_manager.py#L19802:58
caoshufeng1. get the node_uuid from node_id   2. log the node_uuid02:59
TheJuliacaoshufeng: not exactly.... https://github.com/openstack/ironic/blob/master/ironic/conductor/task_manager.py#L17103:01
caoshufengYes, I will update this function.03:02
TheJuliait is a parameter, I think we should be honoring the input, it just seems like the input is wrong03:02
TheJuliaI think.  My brain is fried for the day03:02
caoshufengTheJulia, so I will update this function :https://github.com/openstack/ironic/blob/master/ironic/conductor/manager.py#L163003:03
caoshufengAnd look for other places that passed "node_id" but not "node_uuid"03:04
*** bvandewa has joined #openstack-ironic03:04
TheJuliacaoshufeng: Excellent, thank you03:05
caoshufengTheJulia, Thanks very much for your guidance.03:05
*** cdearborn has joined #openstack-ironic03:09
*** cdearborn has quit IRC03:14
*** vishwanathj has quit IRC03:17
*** vishwanathj has joined #openstack-ironic03:18
*** rama_y has joined #openstack-ironic03:29
*** joprovost has quit IRC03:43
*** Sukhdev has joined #openstack-ironic03:48
*** hshiina has quit IRC03:50
*** garthb has joined #openstack-ironic03:52
*** hshiina has joined #openstack-ironic04:01
*** vishwanathj has quit IRC04:02
*** links has joined #openstack-ironic04:03
*** ijw has joined #openstack-ironic04:11
*** baoli has quit IRC04:20
*** piet has joined #openstack-ironic04:20
*** sdake has joined #openstack-ironic04:23
*** yogi has joined #openstack-ironic04:35
*** Fdaisuke_ has joined #openstack-ironic04:39
*** Fdaisuke has quit IRC04:40
*** rama_y has quit IRC04:41
*** ijw has quit IRC04:45
*** piet has quit IRC04:47
*** ijw has joined #openstack-ironic04:49
*** sdake has quit IRC04:50
*** ijw has quit IRC04:53
*** amotoki has joined #openstack-ironic05:26
*** hparekh has quit IRC05:29
*** hparekh has joined #openstack-ironic05:43
*** ChubYann has quit IRC05:45
*** amotoki has quit IRC05:51
*** kalpase has joined #openstack-ironic05:53
*** amotoki has joined #openstack-ironic05:53
*** kalpase has quit IRC05:53
*** amotoki has quit IRC05:57
*** Goneri has joined #openstack-ironic05:57
*** edand has joined #openstack-ironic05:58
*** amotoki has joined #openstack-ironic05:59
openstackgerritVasyl Saienko proposed openstack/python-ironicclient: Fix Quick-start example syntax.  https://review.openstack.org/34094406:02
*** Goneri has quit IRC06:02
*** Goneri has joined #openstack-ironic06:02
*** mjura has joined #openstack-ironic06:04
*** Sukhdev has quit IRC06:07
*** makowals has quit IRC06:07
*** mjura has quit IRC06:11
*** mjura has joined #openstack-ironic06:11
*** hshiina2 has joined #openstack-ironic06:21
*** hshiina has quit IRC06:23
openstackgerritZhenguo Niu proposed openstack/ironic: Add nodes tagging support - API  https://review.openstack.org/25047806:28
*** baoli has joined #openstack-ironic06:32
*** pcaruana has joined #openstack-ironic06:35
*** baoli has quit IRC06:36
*** makowals has joined #openstack-ironic06:41
*** fragatina has joined #openstack-ironic06:48
*** openstackgerrit has quit IRC06:48
*** amotoki has quit IRC06:48
*** openstackgerrit has joined #openstack-ironic06:48
*** fragatina has quit IRC06:49
*** fragatina has joined #openstack-ironic06:50
*** mkovacik__ has joined #openstack-ironic06:51
*** _milan_ has quit IRC06:53
*** rajinir has quit IRC06:55
*** garthb has quit IRC06:56
*** mkovacik__ has quit IRC06:56
*** amotoki has joined #openstack-ironic07:01
*** clenimar__ has joined #openstack-ironic07:03
*** clenimar_ has quit IRC07:06
*** tesseract- has joined #openstack-ironic07:10
*** rcernin has joined #openstack-ironic07:13
*** Romanenko_K has joined #openstack-ironic07:16
*** daemontool has joined #openstack-ironic07:17
*** athomas has joined #openstack-ironic07:22
*** _Fdaisuke_ has joined #openstack-ironic07:28
*** Fdaisuke_ has quit IRC07:29
*** daemontool_ has joined #openstack-ironic07:31
*** bvandewa has quit IRC07:32
*** moshele has joined #openstack-ironic07:34
*** daemontool has quit IRC07:34
*** ohamada has joined #openstack-ironic07:35
openstackgerritAndreas Jaeger proposed openstack/virtualbmc: Remove unused releasenote setup  https://review.openstack.org/34133307:36
*** bvandewa has joined #openstack-ironic07:37
*** moshele has quit IRC07:40
*** amotoki has quit IRC07:40
*** moshele has joined #openstack-ironic07:40
*** ifarkas has joined #openstack-ironic07:44
vdrokgood morning ironic!07:46
Romanenko_KMorning!07:47
*** amotoki has joined #openstack-ironic07:50
moshelemorning :)07:50
*** zzzeek has quit IRC08:00
*** pcaruana has quit IRC08:00
*** zzzeek has joined #openstack-ironic08:01
*** d0ugal has joined #openstack-ironic08:01
*** fragatina has quit IRC08:02
vdrokmorning Romanenko_K and moshele :)08:02
*** jpich has joined #openstack-ironic08:10
openstackgerritDavanum Srinivas (dims) proposed openstack/ironic: [WIP] Testing latest u-c  https://review.openstack.org/31844008:11
openstackgerritDavanum Srinivas (dims) proposed openstack/ironic: [WIP] Testing latest u-c  https://review.openstack.org/31844008:11
lucasagomesmorning all08:14
*** pcaruana has joined #openstack-ironic08:14
*** jrist_ has joined #openstack-ironic08:14
aarefievmorning Ironic!08:15
ifarkasmorning all!08:16
*** rbartal has joined #openstack-ironic08:16
alinebmorning!08:16
*** mbound has joined #openstack-ironic08:16
*** mbound has quit IRC08:17
*** hkominos has joined #openstack-ironic08:19
*** MattMan has quit IRC08:19
hkominosGood morning everybody08:19
*** MattMan has joined #openstack-ironic08:19
*** hshiina2 has quit IRC08:21
*** hshiina has joined #openstack-ironic08:21
*** jtomasek__ has joined #openstack-ironic08:22
hkominosgoodmorning everyone08:25
*** derekh has joined #openstack-ironic08:33
*** amotoki has quit IRC08:38
*** milan has joined #openstack-ironic08:41
milanmorning team!08:41
milan#pixiesay Morning, Team! -m flexing08:41
PixieBootsᕙʕ⇀ᴥ⇀ʔᕗ: Morning, Team!08:41
*** tiendc has quit IRC08:48
*** chlong has joined #openstack-ironic08:48
*** mgould|afk is now known as mgould08:49
mgouldmorning Ironic!08:49
*** dtantsur|afk is now known as dtantsur08:53
dtantsurMorning Ironic, morning mgould, milan, alineb, ifarkas, hkominos, lucasagomes and everyone08:53
*** hshiina has quit IRC08:55
openstackgerritNisha Agarwal proposed openstack/proliantutils: Discover driver type and rotational speed  https://review.openstack.org/34137008:56
mgouldmorning dtantsur milan alineb lucasagomes ifarkas hkominos vdrok moshele aarefiev09:00
vdrokmorning all :)09:00
milanmgould, vdrok, dtantsur good morning! :)09:01
*** bvandewa has quit IRC09:02
lucasagomesmilan, mgould dtantsur hkominos alineb ifarkas vdrok aarefiev morning :-)09:02
aarefievmorning all! :09:03
milanlucasagomes, aarefiev good morning :)09:03
*** sabeen has quit IRC09:03
alinebmorning dtantsur mgould lucasagomes09:05
dtantsurmorning aarefiev09:05
*** moshele has quit IRC09:14
*** moshele has joined #openstack-ironic09:15
*** mbound has joined #openstack-ironic09:17
*** bvandewa has joined #openstack-ironic09:17
*** pcaruana has quit IRC09:18
openstackgerritYuuki Mori proposed openstack/ironic: Add keystone_auth descripton for Mitaka Release  https://review.openstack.org/34138309:21
*** Goneri has quit IRC09:22
*** mbound has quit IRC09:22
*** e0ne has joined #openstack-ironic09:24
*** tiendc has joined #openstack-ironic09:30
*** amotoki has joined #openstack-ironic09:30
*** pcaruana has joined #openstack-ironic09:31
*** makowals has quit IRC09:34
*** yonglihe has quit IRC09:34
*** amotoki has quit IRC09:34
*** Goneri has joined #openstack-ironic09:36
*** makowals has joined #openstack-ironic09:38
*** makowals has quit IRC09:39
*** pcaruana has quit IRC09:48
*** pcaruana has joined #openstack-ironic09:48
*** pcaruana has quit IRC09:50
*** pcaruana has joined #openstack-ironic09:50
*** pcaruana has quit IRC09:51
*** e0ne has quit IRC09:53
*** fragatina has joined #openstack-ironic09:57
*** pcaruana has joined #openstack-ironic09:57
*** jrist_ has quit IRC10:01
*** e0ne has joined #openstack-ironic10:01
*** athomas has quit IRC10:08
*** bvandewa has quit IRC10:12
*** fragatina has quit IRC10:12
*** athomas has joined #openstack-ironic10:13
vsaienk0Morning aarefiev, dtantsur, vdrok, milan, alineb and all Ironic'ers!10:14
milanmorning vsaienk0! :)10:15
*** daemontool_ has quit IRC10:16
*** daemontool_ has joined #openstack-ironic10:21
*** radek_ has joined #openstack-ironic10:23
*** e0ne has quit IRC10:24
*** e0ne has joined #openstack-ironic10:25
*** tiendc has quit IRC10:26
jrollhey, morning y'all10:29
jrollJayF: replied in gerrit to your question10:29
dtantsurmorning jroll, vsaienk010:34
lucasagomesjroll, vsaienk0 hey there10:34
*** moshele has quit IRC10:35
*** moshele has joined #openstack-ironic10:36
openstackgerritYuuki Mori proposed openstack/ironic: Add keystone_auth descripton for Mitaka Release  https://review.openstack.org/34138310:39
openstackgerritVladyslav Drok proposed openstack/ironic: Add multitenancy-related fields to port API object  https://review.openstack.org/20624410:40
openstackgerritVladyslav Drok proposed openstack/ironic: Add 'neutron' network interface  https://review.openstack.org/31739310:40
openstackgerritVladyslav Drok proposed openstack/ironic: Expose node's network_interface field in API  https://review.openstack.org/31739210:40
openstackgerritVladyslav Drok proposed openstack/ironic: Update the deploy drivers with network flipping logic  https://review.openstack.org/21326210:40
*** e0ne has quit IRC10:41
*** hoangcx has quit IRC10:44
openstackgerritVladyslav Drok proposed openstack/ironic: Expose node's network_interface field in API  https://review.openstack.org/31739210:45
*** jrist has joined #openstack-ironic10:49
*** jrist has quit IRC10:49
*** jrist has joined #openstack-ironic10:49
mgouldmorning vsaienk0 jroll10:50
*** ccamacho is now known as ccamacho|lunch10:56
*** baoli has joined #openstack-ironic10:59
sambetts|afkMorning all11:03
*** sambetts|afk is now known as sambetts|catinbo11:03
*** sambetts|catinbo is now known as sambetts|cat11:03
jrollcatbetts11:04
dtantsurlol11:04
dtantsurmorning sambetts|cat11:04
sambetts|cathehe, I wish11:04
sambetts|catschrodinger fitted ...11:04
sambetts|catjroll: your up early again11:05
sambetts|cato/ dtantsur11:05
lucasagomessambetts|cat, here but not here or both, again?11:06
sambetts|catyup11:06
lucasagomes:D11:06
*** baoli has quit IRC11:06
jrollsambetts|cat: meh, it's 7am already :P11:08
*** edand has quit IRC11:11
lucasagomesthat sounds very early for /me heh11:11
lucasagomestho sometimes I find mornings very productive, way less interruptions11:12
lucasagomes(works for very late too)11:12
jrollindeed, I love mornings11:12
*** lucasagomes is now known as lucas-hungry11:13
* lucas-hungry will grab some bites, brb11:13
sambetts|cathehe /me is a night owl, my best work has been at 3 in the morning while topped up on way to much caffine11:14
mgouldmorning sambetts|cat11:14
sambetts|cato/ mgould11:14
* mgould is not a morning person either11:15
*** skramaja has quit IRC11:25
*** moshele has quit IRC11:28
*** moshele has joined #openstack-ironic11:32
*** edand has joined #openstack-ironic11:39
*** hkominos has quit IRC11:42
*** sdake has joined #openstack-ironic11:48
*** sdake_ has joined #openstack-ironic11:50
*** e0ne has joined #openstack-ironic11:51
*** jrist has quit IRC11:51
*** jrist has joined #openstack-ironic11:51
*** jrist has quit IRC11:51
*** jrist has joined #openstack-ironic11:51
*** sdake has quit IRC11:54
vdrokdtantsur: milan btw I will be in brno this saturday, can meet you there if you're around :)11:59
*** ccamacho|lunch is now known as ccamacho11:59
dtantsurvdrok, I think we can :) not sure about my plans, but nothing for now11:59
vdrokdtantsur: okie, I'll pm you then12:00
*** pece has joined #openstack-ironic12:01
openstackgerritSergii Turivnyi proposed openstack/python-ironicclient: Tests for testing chassis-create command  https://review.openstack.org/29363412:02
*** loki_ has joined #openstack-ironic12:05
TheJuliavdrok: heh, I had a feeling you squashed the two revs together :)12:07
vdrokTheJulia: yup :) git commit --amend instead of git rebase --continue :)12:07
*** lucas-hungry is now known as lucasagomes12:13
*** mbound has joined #openstack-ironic12:13
lucasagomesvdrok, you should try to zebras (means ribs) while you are there12:16
lucasagomesdon't miss it!12:16
TheJuliavdrok: well, it looked mostly good ;)12:16
*** tshefi has joined #openstack-ironic12:16
vdroklucasagomes: :) will do12:16
mgouldmeet your protein-intake goals for the week in one meal...12:16
* TheJulia is now intruiged12:17
lucasagomesmgould, lol indeed12:17
vdroklucasagomes: there should also be pork knee or something like that12:18
vdrokthat looked really huge :)12:19
mgouldvdrok: it is12:19
lucasagomesvdrok, yup! Tho I'm not sure if I've tried that yet12:19
tshefiAny one successfully use Ironic pxe_ssh driver with esxi/vcenter?12:20
lucasagomestshefi, I'm about to asnwer ur email... but tl;dr I haven't tried esxi12:22
tshefilucasagomes, thanks dude im almost ready to give up on this :(12:23
lucasagomestshefi, one option, have you tried to use it with VirtualBMC ?12:23
lucasagomestshefi, https://github.com/openstack/virtualbmc12:23
tshefilucasagomes, no didn't know about this I'll check it out now, thanks12:24
lucasagomestshefi, here's a demo:https://raw.githubusercontent.com/umago/virtualbmc/master/images/demo.gif12:24
lucasagomestshefi, so basically it converts ipmi commands (like ipmitool) to libvirt12:24
*** phuongnh has quit IRC12:24
lucasagomesand libvirt supports esxi as per http://lbvirt.org/12:24
lucasagomesso you can create a vbmc for the vms and then enroll the node in ironic using the default pxe_ipmitool driver12:25
tshefilucasagomes, nice I'll go over it and try. thanks12:25
lucasagomestshefi, cool12:26
*** rbudden has joined #openstack-ironic12:27
tshefilucasagomes, one more thing i forgot to mention on the email if it helps, on esxi/vc I don't even see ssh attempts from ironic, only when I try ssh.12:27
lucasagomestshefi, strange, I thought it was trying since the error in the email is "SSH connection cannot be established"12:29
tshefilucasagomes, exactly what i was thinking till i figured lets look at esxi's access logs12:30
tshefilucasagomes, which means it's probably not even opening it or failing before it actually attempts to ssh.12:31
tshefilucasagomes, any way if you want to test this or look at it, ping me up any time.12:31
*** clenimar__ has quit IRC12:32
lucasagomestshefi, will do12:32
openstackgerritKyrylo Romanenko proposed openstack/python-ironicclient: Tests for testing chassis-create command  https://review.openstack.org/29363412:33
openstackgerritKyrylo Romanenko proposed openstack/python-ironicclient: Tests for testing node-create command  https://review.openstack.org/26205512:33
*** caoshufeng has quit IRC12:34
openstackgerritKyrylo Romanenko proposed openstack/python-ironicclient: Tests for testing node-create command  https://review.openstack.org/26205512:37
openstackgerritKyrylo Romanenko proposed openstack/python-ironicclient: Tests for testing chassis-create command  https://review.openstack.org/29363412:40
thiagopGood morning, Ironicers12:40
*** rloo has joined #openstack-ironic12:41
lucasagomesthiagop, hi there12:41
TheJuliagood morning rloo12:42
vdrokmorning thiagop and rloo12:42
TheJuliagood morning thiagop12:42
*** skramaja has joined #openstack-ironic12:42
thiagopmorning lucasagomes TheJulia vdrok rloo12:43
milanvdrok, awesome, let's have a ton of beer&bbq :D12:43
rloomorning TheJulia, vdrok, thiagop, lucasagomes, milan!12:44
vdrokmilan: not sure about a ton of beer, but bbq sounds good :)12:44
milangood morning rloo :)12:44
rloovdrok: think we can get all the network patches done today? :)12:44
milanvdrok, ack :)12:44
vdrokrloo: I have 3 more hours till pto so might be :D12:45
rloovdrok: OH. when will you be back?12:45
*** vmud213 has joined #openstack-ironic12:45
vdrokon tuesday12:45
rloovdrok: anyone going to take over your stuff in the mean time?12:45
vmud213good morning all12:45
vdrokrloo: yup, I think vsaienk0 will be able to resolve stuff if needed12:46
rloovdrok: awesome. If I hadn't met you both, I'd say you were the same person :)12:46
vdrokrloo: there won't be much to change anyway after the first one is in :)12:46
vdrokheh12:46
vdrokmorning vmud21312:47
rloovdrok: have a great PTO!12:47
vdrokthx rloo :)12:47
vmud213morning vdrok12:47
*** sdake_ has quit IRC12:47
vmud213lucasagomes: one question related to image building with rhel7.12:48
*** daemontool_ has quit IRC12:49
lucasagomesvmud213, shoot (tho you may want to ask at #tripleo since they take care of building the images)12:49
lucasagomesrloo, morning12:49
thiagopmorning vmud21312:49
*** sdake has joined #openstack-ironic12:49
vmud213lucasagomes: During the image building process when it is trying to execute grub2-mkinstall it fails with some error saying /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist12:49
milandtantsur & vdrok's bbq is now in milan's calendar, ifarkas how about you and zebra? this Saturday in Brno? ;)12:49
vmud213morning thiagop12:49
milanof course anyone who can manage let's meet here :)12:49
ifarkasmilan, lol, that would be awesome12:50
*** daemontool_ has joined #openstack-ironic12:50
vmud213lucasagomes: after googling ii got a link, https://bugzilla.redhat.com/show_bug.cgi?id=1101352 which says to install grub2-efi-modules12:50
openstackbugzilla.redhat.com bug 1101352 in grub2 "[UEFI] grub2-install grub2-install: error: modinfo.sh doesn't exist" [Unspecified,Closed: notabug] - Assigned to pjones12:50
milanifarkas, cool :) let's meet in Brno then on Saturday! :D12:50
vdrokhope there will be no rain12:51
vmud213llucasagomes:but i could not get it? Any clue? I remember i faced the same issue when fixing issue with fedora uefi local boot with partition images.12:51
ifarkasmilan, ack, but not this Saturday :D12:51
mgouldmorning thiagop TheJulia rloo12:52
milanifarkas, aaah, too bad, vdrok it's this Saturday, right?12:52
rloohi mgould12:52
vdrokmilan: yup :(12:52
mgouldmorning vmud21312:52
lucasagomesvmud213, you couldn't install grub2-efi-modules? Or you installed and it failed anyway?12:52
vmud213lucasagomes: I tried in tripleO related to redhat image building issues..But not much response..You are the one atleast i know are part of redhat..12:53
vmud213so poking here :)12:53
*** jistr is now known as jistr|cowork12:53
sambetts|catvmud213: what call are you using? are you using the grub2 element or manaually listing the grub2 package ??12:53
milanvdrok, ifarkas, OK there's enough BBQ for both this and next Saturday in Brno :)12:53
vdrokwoohoo :)12:53
vmud213Actually i am building it for vm which will include bootloader and grub212:53
* vmud213 looking into thye elements listed12:54
sambetts|catwhat does your DIB command look like?12:54
vmud213sambetts|cat: disk-image-create rhel7 vm dhcp-all-interfaces -o rhel7-dib-mkfs-uefi12:55
vmud213lucasagomes,sambetts|cat:The element dependencies resolved to the following  "rhel7 dib-python rpm-distro install-types install-bin redhat-common dib-run-parts rhel-common vm manifests base pkg-map yum cache-url source-repositories dib-init-system bootloader dhcp-all-interfaces package-installs"12:56
sambetts|cathmm, so your not using the grub2 or localboot elements :/12:56
vmud213morning mgould12:56
lucasagomesvmud213, as sambetts|cat I think you need to add "grub2" to the list of elements there12:57
sambetts|catnot sure if you do if your using VM not baremetal12:57
sambetts|catbut the grub2 element does include a shim that fixes some problems with installing grub212:58
lucasagomeshttps://github.com/openstack/diskimage-builder/blob/7c6f91fe37f1cff4f486e8f20edf501445bc4d0f/elements/grub2/pkg-map#L1612:58
openstackgerritVladyslav Drok proposed openstack/python-ironicclient: Add create command to ironic client  https://review.openstack.org/32895512:59
vmud213lucasagomes: I have pasted the relevent log here http://paste.openstack.org/show/531698/13:01
vmud213lucasagomes,sambetts|cat: The packages are already included13:01
openstackgerritNisha Agarwal proposed openstack/proliantutils: Discover driver type, rotational speed, raid_level, controller name and location.  https://review.openstack.org/34137013:02
vmud213shim only comes in picture if we are interested in secure boot13:02
*** moshele has quit IRC13:02
*** moshele has joined #openstack-ironic13:03
*** radek_ has quit IRC13:08
vmud213lucasagomes,sambetts|cat: Will try including grub2 element and see how it goes..Thanks for the pointers..13:09
lucasagomesvmud213, yeah I don't have much idea, I have to try as well13:10
lucasagomesand sorry cause I'm kinda looking at other stuff at the same time13:10
*** links has quit IRC13:11
vmud213lucasagomes: no prob..will try...13:11
rloohi milan, i just saw your email reply wrt network_interface.13:13
milanrloo, hi, wdyt?13:13
rloomilan: did anyone discuss with you? they met yesterday about it.13:13
milanrloo, nope13:14
rloomilan: i am not up to date on what they decided yesterday.13:14
rloomilan: but...13:14
milanI hope I wasn't too much out of line13:14
rloomilan: yes, you were very out of line :D ANd TOOO LATE :D but seriously, i think it is good that you replied.13:14
milanrloo, lol OK13:14
milan:D13:14
*** baoli has joined #openstack-ironic13:14
* TheJulia has not looked at email yet today13:15
rloomilan: give me a few minutes to see what they decided yesterday. unless sambetts|cat is around or someone else that was at that meeting.13:15
* TheJulia opens email13:16
milanrloo, thx13:16
*** sdake has quit IRC13:16
*** adu has joined #openstack-ironic13:16
rloomilan: this is the etherpad: https://etherpad.openstack.org/p/ironic_network_interface_discussion13:16
sambetts|catmilan: and this is the patch updating the driver comp spec with comments: https://review.openstack.org/#/c/341084/13:17
milanrloo, sambetts|cat thanks13:18
*** baoli_ has joined #openstack-ironic13:19
rloosambetts|cat: so you all actually decided that a hardware_type could not (or should not?) specify a default_network_interface?13:19
*** chlong has quit IRC13:20
sambetts|catAs I understand it yes13:20
rloosambetts|cat: so 'should not' means we don't think they should but they can. 'could not' means we don't provide the ability to do it.13:20
TheJuliaYes, that ws the consensus13:20
sambetts|catrloo: I'm pretty sure we went with could not13:21
*** ametts has joined #openstack-ironic13:21
rloosambetts|cat: it sez "shouldn't".13:21
TheJuliaanytime we approached should, we all started to get headaches due to the implications13:21
rloosambetts|cat, TheJulia: sigh. why didn't someone put 'could not' or 'cannot'... now what.13:22
*** baoli has quit IRC13:22
TheJuliasambetts|cat: is your hardware case the case where it could be useful to allow it to be specified?13:22
sambetts|catno, my hardware case is actual an ideal argument against having a default13:23
TheJuliarloo: weeds grow quickly in cut fields? :)13:24
*** piet has joined #openstack-ironic13:24
TheJuliasambetts|cat: okay, in that case I just think the notes need to be fixed13:24
rlooTheJulia: ha ha.13:24
rlooTheJulia, sambetts|cat: if I understand what you all decided, I really don't like the inconsistency between network_interface vs the rest of the interfaces, and it makes it look like it should not be part of the hardware type's interfaces :-(13:25
* milan simplified network_interface in his mind to an attribute of the conductor rather than of the node13:25
rlooTheJulia, sambetts|cat: I mean, with this proposal, why not just have a node.network_thing and a config default_network_thing?13:26
sambetts|catbecause we still need hardware_types to be able list supported_network_things13:26
sambetts|catIMO hardware_types are for listing supported things not things to use13:26
rloosambetts|cat: makes me sad if we special case the network interface from the other interfaces. I wanted a generic/consistent model for them all.13:28
sambetts|catrloo: well its not the only one either, volume interfaces is also a special cases, and is even not consistent with network interfaces13:30
sambetts|catspecial case*13:30
TheJulianetworks and storage are both very... different things that may have some influence from hardware, but ultimately rest upon the operator.  It would kind of be the same case for power if someone had a transparent redfish to ipmi converter hidden in the network13:30
TheJuliasambetts|cat: I was actually thinking about that, and we could make it consistent, the operator still has to opt in by populating capabilities13:30
TheJuliaunless inspector magically populates that, then... *headache*13:31
rloosambetts|cat, TheJulia: I guess I don't like the 'cannot' restriction. Anyway, as long as we can get the network stuff in, i can think about the driver composition stuff later.13:31
jrolldevil's advocate question: for network/volumes, what if we just hardcoded the default that should work in 'most' environments?13:31
jrollinstead of leaving the default to the ops13:31
sambetts|catwe discussed making the noop interface that13:32
jrollI'm kind of tired of saying "making a decision is too hard, leave it to deployers"13:32
jrollhence our massive amount of config options13:32
rloojroll: regardless of whether we put in a default (or suggested default), i think we'd need a config option for this particular case.13:33
TheJuliajroll: ops may have separate networks, so magically expecting consistency with a default would cause headaches for anyone who does not mach that environment or configuration exactly13:33
rlooi actually like config options, the more the merrier.13:33
* jroll counts 378 configs in our sample file at the moment13:34
* dtantsur also likes more options13:34
rloojroll: true (well, assuming you can count), but not all those are from *our* code.13:34
jrollTheJulia: well, we can choose the most common or recommended13:34
jrollrloo: I understand13:34
rloojroll: are the number of config options, something that ops folks complain about?13:35
rloojroll: as long as the defaults are appropriate, they shouldn't have to even touch them. and if they have to touch them, then it is good that there are configs to tweak.13:35
jrollrloo: a common request is making deploying openstack easier; part of that is the number of config options13:35
TheJuliajroll: but then if the operator is in a different environment, what do they have to go through to change what the community thinks is a default?13:35
dtantsurI disagree that less options make deployment easier13:36
jrollTheJulia: add --network-interface foo to their node enrollment script13:36
* rloo thinks of a good panel discussion at summit. more or fewer config options...13:36
dtantsurwe have to tune a surprising amount of things for tripleo to work sanely...13:36
TheJuliaand if their environment is a completely different driver?13:36
TheJuliathat is contrary to the default?13:36
TheJuliaand there is no reason for the default to exist in their environment?13:36
jrollTheJulia: not sure what you're saying, I'm talking specifically about e.g. making the default 'flat' always13:37
jrolland overrideable via node.network_interface13:37
dtantsurfor me more options is like more logs13:37
TheJuliajroll: that is how it is coded now for backwards compatability13:37
sambetts|catTheJulia argument is my argument about removing all defaults from hardware_types13:37
dtantsurthey don't get in way when everything is fine, and they help a lot when it's not13:38
jrollTheJulia: okay, so my question is, what's the issue with that which requires adding a default_network_interface config?13:38
sambetts|catpeople deploying into a scenario where they want to use neutron for all created nodes and don't want to override it everytime13:39
TheJuliajroll: operator convenience as an override for the default flat setting at present.13:39
jrollokay, so the big question here is, is that convenience worth the inconsistency, right? rloo?13:39
*** mbound_ has joined #openstack-ironic13:39
dtantsurjroll, if we don't have the default, people using old API versions are out of luck13:40
jrolland a secondary question is, should we do it for all interfaces and remove the inconsistency, which it sounds like y'all decided 'no'13:40
sambetts|catI say remove all defaults and make everything explict13:40
sambetts|catimplict things just lead to problems13:41
jrolldtantsur: people using the old API version can't add switchport data, they're out of luck anyway :)13:41
dtantsurjroll, but they also won't be able to switch from "flat" to "manual". so their nodes will require non-existing neutron13:41
milanrloo, sambetts|cat  what if instead a default_X_interface it was a per-conductor.X_interface that is used when talking to X ("network") so hardware_type needn't specify this? I may miss the reason why hardware_type should verify network interface compatibility...13:42
jrolldtantsur: "manual"?13:42
TheJulianoop13:42
jrollis that the new noop13:42
jrollok13:42
dtantsurah13:42
dtantsuryeah, sorry, I was using my old suggestion13:43
*** mbound has quit IRC13:43
*** trown|outtypewww is now known as trown13:43
dtantsurso if "flat" won't be available or not usable for any reason, new nodes will end up effectively broken13:43
dtantsurs/won't/isn't/13:43
jrolltoday it chooses noop or flat based on dhcp provider, so I think that will work for them13:43
* TheJulia resists urge to make a joke about noop13:43
rloomilan: cuz that adds a new/different *thing* and volume interface may be a similar issue so I think we'd like to have some uniform way to deal with them.13:43
*** amotoki has joined #openstack-ironic13:43
dtantsurjroll, this is an implicit default btw13:44
dtantsurjroll, if we say "remove defaults", we can't use dhcp providers for the same reason13:44
jrolldtantsur: didn't say it wasn't, just trying to understand everything here13:44
sambetts|catmilan: if we specify default_X_interface then it has to be validated against enabled hardware_types so that we know its a valid fall back for nodes created with any hardware_type13:44
rloojroll: wrt convenience vs consistency. I think the *user* is our customer, so I go with trying to address the user's concerns first, before code consistency.13:45
*** mgoddard_ has joined #openstack-ironic13:45
jrollrloo: well, it's about API and configuration consistency, too, right?13:45
dtantsurmilan, per-conductor settings are nearly never a good idea, cause a node can change conductors during its life cycle13:45
milansambetts|cat, it makes sense to me for other interfaces but I've got the impression that the network_interface is different here; why would the hardware_type verify that network is provided through neutron13:46
milanor that it isn't13:46
TheJuliamilan: also conductor take_over upon conductor failure would complicate matters with per-conductor config13:47
rloojroll: yup. that's true.13:47
jrollmilan: because cisco makes crazy weird servers :)13:47
sambetts|catmilan: huh? It doesn't we're not suggesting that, the hardware_type does no validation13:47
sambetts|cathardware_type just lists supported things13:47
sambetts|catconductors do validation that a default is supported by all hardware_types13:47
rloojroll: which is why i want to allow for defaults/settings at every level, node, hwtype, global (config)13:47
milansambetts|cat, precisely, so in supported_types you'd declare particular net?13:47
milan*network type?13:47
sambetts|catyes, because I can make a network interface that is tied to my server, because I have magic nics13:48
*** mgoddard has quit IRC13:48
jrollrloo: right, okay got it13:48
milansambetts|cat, OK that makes sense then13:48
sambetts|catits not related to whether or not its neutron or not, its whther or not it interacts with my magic nics13:48
jrollso, if this is for user convenience, why doesn't for example default_power_interface make sense?13:49
* milan had the impression this was rather about the switch than the nic13:49
sambetts|catjroll: default_power_interface in config or hardware_type?13:49
jrollsambetts|cat: config13:49
jrollI see in the etherpad: "default configs don't make sense for other interfaces (power, mgmt, etc)"13:49
jrollwhy?13:50
sambetts|catjroll: how would that play with the hardware_type default for that interface?13:50
jrollsambetts|cat: that's unrelated to if it makes sense, right?13:50
jrollsambetts|cat: though, I would think it'd just override it13:50
dtantsursambetts|cat, the same question about network interfaces. what if an hw type has the default?13:50
rloosambetts|cat: it only "plays" with hardware_type default for that interface, if the hw-default is 'use the config value'13:51
vdrokhw-type default overriding config default should be ok13:51
sambetts|catalso specifying a default in the config means that all hardware_types must have an intersect between supported_x_interfce13:51
jrolllet's slow down, I want to understand why default_power_interface doesn't make sense13:51
*** amotoki has quit IRC13:51
sambetts|cat^ specifying a default in the config means that all hardware_types must have an intersect between supported_x_interfce13:51
jrollI'm not sure who said/wrote that, but it sounds like a convenience to me13:52
jrollsure13:52
rloosambetts|cat: so that is what i don't understand. why does a config default mean that all hwtypes must have an intersect between supported_x_interface?13:52
jrollOR it means that we fail if a hardware type without the default is used, without specifying a different power interface13:52
sambetts|catrloo: because otherwise Ironic would set an implementation unsupported by a hardware_tyoe13:53
jrollor throw a 40013:53
*** jcoufal has joined #openstack-ironic13:53
*** PollyZ has joined #openstack-ironic13:53
jrollright?13:53
jrollwe need a whiteboard :|13:54
rloosambetts|cat: guess i don't understand. a hwtype has a list of supported x_interfaces. a hwtype can specify the default x_inteface. if default x_interface is in supported, all is ok. regardless of default_x-config value.13:54
sambetts|catthats another solution we discussed, but that means that all nodes of particular hardware_type will always have to be overriden13:54
TheJuliaI think it would be conductor failing to start territory13:54
jrollsambetts|cat: sure, that's fine13:54
jrollTheJulia: why?13:54
*** mgoddard has joined #openstack-ironic13:55
TheJuliaI think validation was discussed at start-up of the conductor so if matches were not found based upon defined drivers, it seemed like in the dicussion that we wouldn't have a working conductor13:55
*** mgoddard_ has quit IRC13:55
jrollsambetts|cat: fwiw, I don't see a heterogenous deployment *using* this option at all13:55
jrollbut take a deployment of identical supermicro boxes that wants to use pyghmi13:55
sambetts|catrloo: I have an environment with 2 loaded hw_types, which don't support any of the same power interfaces, no default will work for this environemnt13:56
jrollpyghmi won't be the hw_ype default13:56
jrollsambetts|cat: if you're deploying that environment, you'd probably not set that default, right?13:56
TheJuliajroll: we need a really large white board13:56
jrollTheJulia: ikr13:56
rloosambetts|cat: does 'default-anything' value mean that the whole universe has to work with default-anything?13:56
TheJuliajroll: and whisky13:56
jroll+113:57
sambetts|catrloo: yes, if we fall back to that value if we don't get given another13:57
sambetts|catfor everything13:57
*** amotoki has joined #openstack-ironic13:58
rloosambetts|cat: so *IF* a hwtype chooses to set it's default to the config setting, yes. but otherwise, I don't see why.13:58
TheJuliaThis compeltely seems like a conundrum we can solve later, and in order to come to a happy place for now, we can remove the default_network_interfaces setting in the network patchset chain, and just force users to define their network interface if not flat for Newton13:58
TheJuliaAnd by later, I mean in-person13:58
sambetts|catrloo: we said that config values will override hw_Type defaults13:58
rloosambetts|cat: and if the user specifies a default that doesn't make sense, we have enough checks in place to error out.13:59
loki_review please https://review.openstack.org/#/c/272658/13:59
rloosambetts|cat: OH. who said that? Well it wasn't in my proposal. i need to look at what you guys decided.13:59
rloosambetts|cat: and i disagree. config values never? do they? override higher level settings.13:59
*** vmud213 has quit IRC14:00
sambetts|catrloo: config value is a higher level setting than the hardware_types default, because the hardware_type default can not be changed14:00
rloosambetts|cat: yikes.14:01
jrollI would think config would need to override hw_type, right? /me goes back to the ipmi case with default_power_interface=pyghmi14:01
jrollbut the other way around is interesting14:02
rloosambetts|cat: so you're saying that *if* a hwtype could specify a default interface value, and *if* there was a corresponding config default interface, the config default interface would override the hw default?14:02
TheJuliaan override is intruiging14:02
sambetts|catyes14:02
rloosambetts|cat: that isn't how configs normally work, unless I guess, you call it 'an override'.14:02
rloosambetts|cat: is this really the functionality that is being asked for?14:02
openstackgerritKyrylo Romanenko proposed openstack/python-ironicclient: Tests for testing port-create command  https://review.openstack.org/29180214:03
sambetts|catwell then default_X_interface in the config file doesn't make any ssense14:03
jrollI think the hierarchy here is node > config > hw type14:03
jrollbecause hw type is code14:03
sambetts|cat+!14:03
sambetts|cat+114:03
*** amotoki has quit IRC14:03
rlooi think the hierarchy here is node -> hwtype -> config. it is *only* if hwtype is unspecified (ie, specified to use config value), that config is used.14:04
openstackgerritVladyslav Drok proposed openstack/python-ironicclient: Add internal_info field to port  https://review.openstack.org/34155214:04
*** wajdi has joined #openstack-ironic14:04
jrollrloo: right, I guess I misunderstood that14:04
rloodid i ever mention that i didn't like hwtype being in code? but i think that was to enforce things.14:04
*** yuriyz has quit IRC14:05
jrollI shouldn't say I think that's the hierarchy, I should say that's how I understood the hierarchy being discussed14:05
sambetts|catand this is why I hate hardware_types having defaults14:05
rloojroll: *unless* we don't call it a default config, but an override config I guess.14:05
jrollright14:05
rlooso i guess i don't understand the functionality we are looking for14:05
sambetts|catI'm going back to IMO hardware_types should specifc support implementations and not which implementation to use in anyway14:06
sambetts|catspecify*14:06
rlooare we saying that if a hwtype can specify default network='flat', that operators will want to override that and not via node.network_interface but via a network_interface_thingy config?14:06
*** loki_ has quit IRC14:07
jrollrloo: that's what I'm hearing, but not that operators will want to override that, but providing it as a convenience14:07
rlooor is sam saying, hwtype cannot specify any default interface, only supported; and the corresponding config specifies the default?14:07
jrollrloo: and sam would prefer what you just said14:07
sambetts|catrloo: I don't even really want config options14:07
rloojroll: then what's the use of a hwtype having a default?14:07
TheJuliarloo: essentially yes because it could all be neutron for them, or they only want to explicity opt in the flat nodes in the special clsuter over int he corner14:07
jrolloh14:07
jrollrloo: for when the operator does not want to specify the default, I guess?14:08
rlooalthough hwtype (at least for corresponding classic drivers) need to have defaults :)14:08
jrollidk, I wrote down the two cases I see here: https://etherpad.openstack.org/p/ironic_network_interface_discussion14:08
jrollor how I see this working, if we have a default_*_interface for everything14:08
sambetts|catIMO you put a node into Enroll and then you have to update all the driver_info anyway to make it get through validation, so why not just make setting the interface explict per node14:08
sambetts|catno defaults anywher14:09
jrollI also would like consistency, so I'm trying to understand why we need default_network_interface but default_anythingelse_interface doesn't make sense14:09
rloosambetts|cat: cuz when i am testing, i am too lazy to get that command correct.14:09
TheJuliasambetts|cat: then we have no "explicitly known to work" base configurations14:09
rloosambetts|cat: and it goes back to jroll saying we need to make it easy for operators/usage; pick sane defaults14:10
jrollwhat I would like to get to => a modern ironic deployment with e.g. opencompute hardware is just specifying --hardware-type ipmi and ipmi creds14:11
jrolland you get a relatively secure deployment, tenant isolation, etc14:11
*** alex_xu has quit IRC14:11
jrollmore medium term because back-compat, but yeah14:11
sambetts|catjroll: I would prefer --hardware_type opencompute --power-interface ipmi because then I know what I'm getting14:12
*** joprovost has joined #openstack-ironic14:12
*** sdake has joined #openstack-ironic14:12
jrollsambetts|cat: s/opencompute/generic whitebox/14:12
*** alex_xu has joined #openstack-ironic14:12
jrollsambetts|cat: you'd know what you were getting because the hardware type docs would tell you that the default is ipmi :)14:13
rloosambetts|cat: and/or by querying ironic, whenever we have an API for getting that info...14:13
sambetts|catand if as a deployer I blcok ipmi in my environemtn and want to force nodes to use WOL how do I do?14:13
jrollsambetts|cat: --power-interface wol14:14
rloosambetts|cat: is WOL a supported interface? if so, what jroll said ^^14:14
rloosambetts|cat: if it isn't supported, ... complain to dtantsur :)14:14
jrollfwiw, I don't believe that any production deployment of ironic will have a person sitting at a computer enrolling nodes one by one, but rather some sort of script or tool14:14
sambetts|catjroll: but if I don't specify it then the node will be created with IPMI even though as a deployer I know it won't work14:14
jrollsambetts|cat: then why wouldn't you specify it?14:15
rloosambetts|cat:  so specify it. you are allowed to do that.14:15
sambetts|catjroll: depends if the deployer is the user of Ironic or not right? They might not know?14:15
sambetts|catcase when deployer != operator14:16
jrollif the person onlining hardware doesn't know that IPMI won't work in the environment, there's a bigger problem somewhere14:16
jrollI don't believe that the person enrolling hardware is completely oblivious to the datacenter architecture14:16
rloosambetts|cat: the person might not know what?14:16
jrollever14:16
jrollthat's just silly14:16
sambetts|catthen why not just remove deaults and make it explict ?14:16
sambetts|catbecause if in my env I don't want IPMI then every node I enroll I have to override14:17
rloosambetts|cat: that's like asking why not remove *all* defaults, even for config values and make the user/operator specify *everything*14:17
jrollbecause in most cases where someone is dpeloying generic whitebox hardware, they'll want to use ipmi14:17
jrolland that's what we would recommend14:17
jrolljust like if someone uses ilo, we'd recommend ilo, they'd likely use ilo. why make them specify it for equality with the one operator out there that uses ipmitool with ilo hardware?14:18
*** ChrisAusten has joined #openstack-ironic14:18
sambetts|catcomes back to consistacy vs convience I guess14:18
jrolldepends how you define consistency :)14:19
jrollin this case, consistent to me means:14:19
jrollevery hardware type is documented, with the defaults14:19
jrollwhen you don't specify *_interface, the documented default is used14:19
sambetts|catconsistent means to me: If I run ironic node-create --hardware_type X that behaves the same, and if the default works in some clouds but not others than that is inconsistent14:21
sambetts|catif we make it explict, then operators can disable certain interfaces, and if I make an ironic node-create call with an interface that is disabled then I know14:22
sambetts|catits not going to work14:22
sambetts|catand it'll fail14:22
jrollwell14:22
openstackgerritVladyslav Drok proposed openstack/python-ironicclient: Add internal_info field to port  https://review.openstack.org/34155214:22
jrolldisabling interfaces is a separate topic, right?14:23
jlvillalkrtaylor, sambetts|cat: Any chance one of you could chair the QA meeting today? I am supposed to get my new work laptop 30 minutes before the meeting starts. So I don't think I will make it :(14:23
jlvillalkrtaylor, sambetts|cat The appointment was made over a month ago, and I can't change the time :(14:23
sambetts|catnot really because specifying a default_X_interface automatically adds it to the enabled_interfaces list14:23
sambetts|catjroll: ^14:23
mariojvmorning ironic14:23
mariojvis there a way to see summit abstracts related to ironic that have been submitted yet?14:24
jrollmariojv: not until submissions close14:24
sambetts|catjroll: so as an operator I'm forced to enable certain interfaces even if I know it won't work in my environemt14:24
jlvillalmariojv, Yes. Just hack into the submission system :P14:24
mariojvthanks14:24
jlvillalmariojv, Otherwise, I don't think so :(14:24
*** dtantsur is now known as dtantsur|brb14:25
jrollsambetts|cat: grumble14:25
rloosambetts|cat: not sure i understand. why would the operator enable an interface that doesn't work? wouldn't they want to specify the one that does work?14:25
sambetts|catrloo: thats my whole point, default_X_interfaces take that out of the operators control14:25
jrollrloo: the default for a hw type is always enabled14:25
*** mtanino has joined #openstack-ironic14:25
rloosambetts|cat, jroll: but that's why you just override it at the node level?14:26
vdroksambetts|cat: they still can be overriden per node14:26
*** sabeen has joined #openstack-ironic14:26
*** wajdi has quit IRC14:26
rloosambetts|cat: i mean, isn't that what you were advocating with your node-create command?14:26
jrollright, so sambetts|cat point is that there's a vector for creating a broken node, if you fail to override it14:27
jrollif the default does not work14:27
*** wajdi has joined #openstack-ironic14:27
rloojroll: right. isn't that the way other thigns work or don't work? if the default doesn't work in your environment, you change it.14:27
jrollI honestly don't think that's a major problem, I believe that operators should/will write a script for enrolling nodes14:27
rlooi mean, regardless of default network/power/whatever. that's the nature of defaults.14:28
jrolland in this case that script would always pass the override14:28
sambetts|catrloo: but you can't change the default for a hardware_tpye14:28
jrollrloo: you can't change the default interfaces for a hw type14:28
sambetts|catits written in code14:28
rloosambetts|cat: OH. that is a different problem than what we are trying to address (or what i was initially)14:29
rloosambetts|cat: first, do we want to allow for that?14:29
rloosambetts|cat: i am guessing you do.14:29
openstackgerritSergii Turivnyi proposed openstack/python-ironicclient: Tests for testing chassis-create command  https://review.openstack.org/29363414:29
rloosambetts|cat: so, after thinking about it, i am not sure we want to allow for that.14:30
rloosambetts|cat: the whole idea of driver composition, is to allow the configuration/composition to be flexible.14:30
rloosambetts|cat: so i think it makes sense that you 'change' the default on a per-node basis.14:31
rloosambetts|cat:  the default is a convenience thing.14:31
*** sdake has quit IRC14:31
rloosambetts|cat: so if as you would like, there were no default, you'd have to specify it at the node level anyway.14:31
rloosambetts|cat: or am i missing something?14:31
*** sdake has joined #openstack-ironic14:32
jrollrloo: right, sambetts|cat is saying the user should always need to specify, so they always know what they are getting14:32
krtaylorjlvillal, I'm not sure I'll be able to make it either :(  but maybe mjturek1 can run the meeting if sambetts|cat can't14:33
rloojroll, sambetts|cat: so I don't like the 'should always'. I mean, we can say they 'should always', if that's what you want to recommend.14:33
rloojroll, sambetts|cat: BUT I would oppose it if you said they 'must'14:33
jrollrloo: right, 'must' is the right word here14:33
rloojroll, sambetts|cat: what's the argument for 'must'? I see no reason to make people do that.14:34
sambetts|catI think if you remove defaults that hardware_type supported_X_interfaces + enabled_X_interface should be able to gurantee that the node you are creating will work in the environment you are deploying into, defaults remove the control from the enabled_X_interfaces config option14:34
jrollrloo: so it's always consistent14:34
jrollrloo: I agree with you14:34
jrollrloo: the argument is an environment where the default will not work, and the person enrolling nodes is doing it by hand, and does not know this.14:35
jrollwhich I don't believe is a case that should ever exist14:35
rloojroll: I don't actually understand that argument.14:35
rloojroll: if the user doesn't know that some X implementation doesn't work, even if they were to be forced to specify it, they still wouldn't know it didn't work.14:36
sambetts|catthey wouldn't be able to create a node with that implementation though because the operator knowing it doesn't work will have removed it from the enabled_interfaces14:36
rloojroll: if the X implementation is in the list of enabled/supported, how does it matter that there is or isn't a default?14:37
rlooOH. sambetts|cat, so your concern is that hw-default is *always* considered supported/enabled.14:37
sambetts|catrloo: yes14:38
jrollyes14:38
rloosambetts|cat, jroll: that might be a valid concern, honestly, i glossed over all that wrt the driver composition, although i wondered about it.14:39
sambetts|catkrtaylor, jlvillal: I can chair if neither of you are around14:39
rloosambetts|cat, jroll: so honestly, i really want to get the network stuff done. i suspect we may have more conversations about the driver composition stuff.14:39
rloosambetts|cat, jroll: can we capture this concern somewhere and try to address it with dtantsur|brb later?14:40
jlvillalsambetts|cat, Thank you! :)14:40
sambetts|catrloo: right so I think the way we've done the network stuff right now is good to go and isn't blocked by this conversation14:40
*** ChrisAusten has quit IRC14:40
*** amotoki has joined #openstack-ironic14:40
sambetts|catthis is tied more heaviy to the driver comp stuff than anything else14:40
rloosambetts|cat, jroll: I just want to know two things> 1. are network_interfaces part of the hwtype interfaces; and 2. do we have a story on how the default-interface-config fits into the driver composition stuff.14:40
rloosambetts|cat: ok great. please bring this up later!14:41
*** moshele has quit IRC14:41
rloosambetts|cat: cuz https://review.openstack.org/#/c/285852/ has 3 +2's and I'm going to approve it sometime today unless someone disagrees or someone else beats me to approving it14:42
sambetts|catrloo: I think network_interfaces need to be tied to hardware_type because of cases like mine and oneview's where we have server NIC specific network_interfaces14:42
*** vishwanathj has joined #openstack-ironic14:42
rloosambetts|cat: right. that makes sense.14:42
sambetts|catrloo: I'm not sure where to track the concern about default interfaces14:43
rloomaybe in the RFE for that feature?14:43
rloosambetts|cat: add a comment? and hope we remember?14:43
sambetts|catNot sure what the timeline of the driver comp stuff is but maybe we need a whiteboard session at the summit about it14:44
*** moshele has joined #openstack-ironic14:44
rloosambetts|cat: i would *really* like to get that merged in newton.14:44
rloosambetts|cat: but not as much as i want the network stuff done :)14:44
sambetts|cat:-P14:44
mjturek1krtaylor: I'd love to but today is the department picnic :( sorry14:44
thiagopnot many people to the meeting though...14:45
*** moshele has quit IRC14:46
*** moshele has joined #openstack-ironic14:58
*** ijw has joined #openstack-ironic14:59
*** ijw has quit IRC15:00
*** jistr|cowork is now known as jistr|mtg15:00
*** ijw has joined #openstack-ironic15:01
*** links has joined #openstack-ironic15:01
*** vishwanathj has quit IRC15:02
*** vishwanathj has joined #openstack-ironic15:02
*** vishwanathj has quit IRC15:03
*** vishwanathj has joined #openstack-ironic15:04
openstackgerritKyrylo Romanenko proposed openstack/python-ironicclient: Tests for testing chassis-create command  https://review.openstack.org/29363415:06
*** dtantsur|brb is now known as dtantsur15:07
dtantsurjroll, rloo, I'm back, could you give me a tl;dr?15:07
rloodtantsur: ask sambetts|cat :) He is concerned that with the driver composition stuff, the hwtype's default_x_interface will always be considered enabled/supported, even if it isn't in the supported_x or enabled_x list.15:08
jrolldtantsur: in mtgs now :(15:09
dtantsurno worries15:09
sambetts|catjust writing up my concern as a comment on the RFE15:09
rloodtantsur: so that if for whatever reason, that default_x_interface doesn't work in their environment, the operator has no way to disable/say-don't-use-it.15:09
rloothx sambetts|cat15:09
dtantsurthat's correct15:09
dtantsurby enabling the hardware type you enable the default interface. this is a limitation, but it's a useful limitations for the majority of cases15:10
*** ametts has quit IRC15:10
dtantsurand remember that we have all-or-nothing approach right now, so it's still an improvement :)15:10
sambetts|cathttps://bugs.launchpad.net/ironic/+bug/152474515:10
openstackLaunchpad bug 1524745 in Ironic "RFE: driver composition reform" [Wishlist,In progress] - Assigned to Dmitry Tantsur (divius)15:10
rloodtantsur: i'll leave it for you to discuss with sambetts|cat. I'd be happy to discuss later (in a few weeks or whatever). right now, i want to get networking stuff reviewed.15:11
sambetts|catI've left a comment there with a example, I hope it makes sense15:11
TheJulianetworking ++15:12
*** edand has quit IRC15:12
dtantsursambetts|cat, it makes sense, but I'm fine with the behaviour you've described, even if it breaks some corner cases...15:12
dtantsursambetts|cat, that's essentially why we introduce the default option for network/volume: because these cases are not rare for them15:13
dtantsurbut e.g. for deploy, or power, or management...15:13
dtantsurbut this is a good reminder that we should think twice when setting the defaults for hardware types15:13
sambetts|catthe reason this discussion came up is because we were discussing the consistancy of having different behaviours for different interfaces, and whether hardware_types should be able to specify a default for network_interface15:15
*** tshefi has quit IRC15:15
dtantsurfwiw I've always been fine with more user-friendly behavior at the expense of slight inconsistency15:16
sambetts|catif hardware_types can specify a default for network_interface, then what is an edge case for the other interfaces is a much bigger deal for network_interface15:16
*** vishwanathj has quit IRC15:17
dtantsurI agree with having the default option for network and volume15:17
*** vishwanathj has joined #openstack-ironic15:17
sambetts|catdtantsur: whats you stance of if hardware_types should be able to specify a default for network_interface?15:17
sambetts|catyour stance*15:17
sambetts|caton15:17
sambetts|cat(its getting to that point in the day again)...15:17
rloosambetts|cat: please, just don't cry, i don't think i can stand it ;)15:18
dtantsursambetts|cat, I think it can, but I kind of think that the configuration option should have a bigger priority15:18
*** moshele has quit IRC15:19
sambetts|catdtantsur: problem is that having 1 configuration option only works if all your hardware_types you load have at least 1 interface of that type that is the same15:20
dtantsurthat's true, and I think we can live with it15:20
*** Romanenko_K has quit IRC15:20
dtantsurit will definitely prevent us from setting the vendor-specific thing as the default, unless all hw types support it15:20
dtantsurbut yeah, the driver comp is not without limitations...15:21
sambetts|catdtantsur: what if I have 2 hardware types one has supported_network_interfaces = [flat] and the other has supported_network_interfaces = [CiscoFlat] I can't set a sane default then?15:22
dtantsurthen only "noop" is your common default (both must include it)15:22
*** sabeen1 has joined #openstack-ironic15:22
dtantsurwhich is sad, I agree, but how realistic is hardware not supporting our "flat" implementation at all?15:22
sambetts|catdo we then enforce all hardware_types support noop?15:23
dtantsursambetts|cat, on code review - yes15:23
lucasagomeshi all, can someone take a quick look at https://review.openstack.org/#/c/338245/ ? (2+2 already)15:23
*** ametts has joined #openstack-ironic15:23
sambetts|catdtantsur: its a possblity with hardwre that requires nics to be poofed out of thin air and has no "nics" to begin with15:23
TheJuliadtantsur: well, in some hardware, even in flat, the ports need to be plugged of sorts.  An example is oneview kind of15:23
*** sabeen has quit IRC15:23
dtantsuroh, I see now15:24
dtantsurwell, it looks like no default here. I guess in this case we should require an explicit network_interface15:24
sambetts|catso you set the conf option to None, then if hardware_types have default it falls back to that which also might be broken in this environment15:26
*** ifarkas has quit IRC15:26
*** jistr|mtg is now known as jistr15:27
dtantsurit's also possible. I see the problems, I don't see the solution, however. Do you have practical ideas on fixing it?15:27
*** pcaruana has quit IRC15:28
*** trown is now known as trown|lunchnlear15:29
*** trown|lunchnlear is now known as trown|lunchlearn15:30
sambetts|catMy only solution that works in my head so far is remove all defaults, make hardware_types just list supported_X_interfaces, make interfaces explictly enabled by the deployer using enabled_X_interfaces, and make interfaces explictly picked by the operator during node enrollment15:30
sambetts|catAnother possiblity is that we remove the idea of a hardware_type have 1 default interface15:31
sambetts|catmake the support_X_interfaces prioritised, and then have Ironic take [0] from the list generated by interseting enabled_X_interfaces with supported_X_interfaces15:32
sambetts|catas the default15:32
*** sukhdev has joined #openstack-ironic15:32
sambetts|catalthough I've not though that one through completely15:32
sambetts|catthought*15:32
dtantsurthe first idea sacrifices basic usability and I'm not sure what you get in the end. You'll just have to update all interfaces explicitly,.15:33
dtantsuryou can do it with the current proposal too15:33
*** rcernin has quit IRC15:33
dtantsurthe second case is interesting, but it's very implicit, so it should be well-thought15:33
*** rajinir has joined #openstack-ironic15:34
*** adu has quit IRC15:34
sambetts|catthe first idea regains the deployers control of enabled_X_interfaces, so they can remove interfaces they don't want to/can't support and then if you try to create a node with a disable interface i'll fail15:34
sambetts|catit'll*15:34
dtantsuryeah, but the API side is terrible: you'll have to list all (8? 9?) interfaces during enrollment15:35
dtantsurwhich is terrible already, and is completely impossible with old API versions15:35
*** mjura has quit IRC15:35
*** mordred has quit IRC15:35
dtantsurand again: how does it fix your case?15:36
sambetts|catbecause a node-create with an interface not in enabled_X_interfaces will fail15:37
sambetts|catso its impossible to create a broken node15:37
sambetts|catunlike right now were by default I'd get a broken node15:37
dtantsurwell ok, we can check that the default is in the supported list, and refuse to start if it's not15:38
dtantsurdoes it cover this problem?15:38
*** jtomasek__ has quit IRC15:39
sambetts|catno, because that means I all my hardware_interfaces have to have at least one common interface15:39
sambetts|catfor each type15:39
*** piet has quit IRC15:40
*** piet has joined #openstack-ironic15:40
dtantsurthen set both defaults to "None" and let node enrollment fail if the explicit value is not provided15:41
sambetts|catI can't change the hardware_types default15:41
*** jpich has quit IRC15:41
*** watanabe_isao has joined #openstack-ironic15:42
dtantsurright, you only need to set the default in configuration to None15:43
dtantsurI mean, we have it now: some deploy interfaces require swift and will break if it's not deployed15:43
sambetts|catthen it falls back to my hardware_types default which doesn't work in this deploy15:43
dtantsurok, I'm fine with it15:43
sambetts|catso I end up with a broken node by default15:44
dtantsurthis is something that happens now and will happen in the future15:44
dtantsurcorrect. try iscsi_ilo driver without swift - iirc it's the same situation15:44
sambetts|catand this could be easily resovled if the deployer could just remove the hardware_type default from the enabled_X_interface list15:44
sambetts|catbut if we do that then what do we fall back to15:45
dtantsurcorrect, that's why we can't do that15:45
sambetts|catso I say remove defaults, and make it so that you always have to be explict15:45
dtantsuralso these is a vague situation with driver vendor passthru in this case15:45
dtantsurno15:45
dtantsur"we can't heal 2 people, so lets destroy the whole hospital" :)15:46
*** jrist has quit IRC15:46
*** d0ugal has quit IRC15:46
sambetts|catwe can't heal 2 people with this solution so lets heal both with a slight differnt one15:46
dtantsurwe're moving in circles already15:47
* TheJulia suspects the weeds grow fast with this topic15:47
dtantsurI'm not buying making terrible UX in favor of a rare case, which exists now already and can be worked around15:47
sambetts|catIMO you have to do a bunch of calls specific to the interfaces anyway to update the driver info, so I don't see why not just set the interface at the same time15:47
dtantsursambetts|cat, please show me an example of how to do it with an old API version, to begin with :)15:48
rlooTheJulia: I think this is a 'lets get popcorn' one :)15:48
sambetts|cathaha15:48
TheJuliarloo: or beer, since I can't eat popcorn15:48
rlooTheJulia: I'm at https://review.openstack.org/#/c/206244/, getting there...15:49
dtantsurbut seriously, barely anybody will like adding 7-8 mandatory arguments to node creation API just because we have a rare case to fix15:49
rlooTheJulia: didn't realize you can't have popcorn. so sad.15:49
sambetts|catdtantsur: Im not a fan that interfaces are mandatory like that anyway IMO thats why we have enroll state.. so I can update the nodes async then make them avaialbe15:50
TheJuliarloo: That ones seems really strait forward to me.  I stayed up till nearly midnight local looking at reviews15:50
*** ametts has quit IRC15:50
TheJulias/ones/one/15:50
mariojvwin 2015:50
mariojvsorry, mistype15:50
rloothx TheJulia, for working on it. I went to sleep :)15:50
TheJuliamariojv: did we all win $20 ? ;)15:51
*** Sukhdev_ has joined #openstack-ironic15:51
sambetts|catall /me has won is a headache15:51
TheJuliarloo: you may want to have a cup of coffee before you get to the documentation patch15:51
dtantsursambetts|cat, I already envision people asking "why could not you create a default??"15:51
dtantsur:)15:51
mariojvsure, if you buy some cloud from us :P jk15:51
dtantsursambetts|cat, but old API versions give me even more headache15:51
rlooTheJulia: oh, you mean I shouldn't review that one eh? :)15:52
sambetts|catdtantsur: yeah :/15:52
TheJuliarloo: possibly, I've asked for it to be broken out of the main install text body and there are a number of areas where more context is required.  I think I left 19 comments on it last night15:52
rlooTheJulia: I'm not too worried about the doc one landing soon ;)15:53
TheJuliarloo: yeah, I think the doc might take another week or two15:53
rlooTheJulia: quick question for you. the port.pxe_enabled and port.local_link_connection fields. do you think of those as fields for multitenancy use (only)?15:53
*** watanabe_isao has quit IRC15:54
TheJuliaI only think that for local_link_connection15:54
TheJuliapxe_enabled has been around for a while and was just masked until now15:54
*** vishwanathj has quit IRC15:54
rlooTheJulia: yeah. not sure i like seeing them described as multitenancy. will think about it.15:55
*** vishwanathj has joined #openstack-ironic15:55
TheJuliarloo: I kind of saw it falling under the unbrella since someone would very likely want to not dhcp on some of their network ports... or they can't potentially15:55
TheJuliaat least when configuring their bare metal network connectivity15:56
sambetts|catI think pxe_enabled is not multitenant specific I think the flat network interface case might take that into account at some point too, if people register more than 1 nic in Ironic for a node15:56
TheJuliasambetts|cat: I think it already does15:56
sambetts|catcool :)15:56
TheJuliaI remember the database migration was missed for it origionally, so all of a sudden we were not writing pxe configs15:56
rloothx. i'll keep that in mind when reviewing the code. <strike>multitenancy</strike> :)15:56
*** watanabe_isao has joined #openstack-ironic15:57
*** catintheroof has joined #openstack-ironic15:58
*** baoli_ has quit IRC15:59
*** amotoki has quit IRC15:59
*** rcernin has joined #openstack-ironic16:00
*** rpioso has joined #openstack-ironic16:00
*** davideagnello has quit IRC16:01
*** mgoddard_ has joined #openstack-ironic16:02
*** openstackgerrit has quit IRC16:03
*** openstackgerrit has joined #openstack-ironic16:03
*** bvandewa has joined #openstack-ironic16:04
*** tesseract- has quit IRC16:06
*** mgoddard has quit IRC16:06
vdrokrloo: it's not multitenancy now - I've renamed it to advanced_net_fields iirc16:10
vdrokand /me leaves :)16:10
vdrokgood night everyone!16:10
rloovdrok: yes, i noticed that. except in at least one place (and the commit) :)16:10
rloovdrok: bye, have a great time!16:11
*** wajdi has quit IRC16:11
vdrokrloo: whoops, that happens all the time :)16:11
*** wajdi has joined #openstack-ironic16:11
rloovdrok: no worries. cosmetic stuff :) GO!16:11
thiagopnight vdrok, have fun!16:11
lucasagomesdtantsur, on top of the discussion in the internal channel but now related to upstream16:11
lucasagomesdtantsur, what do you think about having a clean step to remove the disks metadatas rather than the whole data16:12
*** tiendc has joined #openstack-ironic16:12
lucasagomesdtantsur, for situations like ours where the data from previous tenants (since it's a installer) is not important and can be in the disk16:12
lucasagomesdtantsur, but the metadata can cause problems16:12
dtantsurlucasagomes, in theory we're supposed to remove disk metadata before deployment, maybe we didn't have it back in liberty?16:12
dtantsuroh, maybe we remove metadata only from one disk16:12
lucasagomesdtantsur, only for the disk we are deploying onto16:13
lucasagomesdtantsur, exactly not all disks16:13
dtantsurcorrect, correct, ignore me16:13
lucasagomeslike cleaning would be suppose to do16:13
dtantsurI agree, a step to wipe metadata would be helpful. or should it be a flag for the existing step?16:13
lucasagomesdtantsur, could be as well16:15
lucasagomesbut that's implementation detail16:15
dtantsuryeah. mind filing an RFE?16:15
lucasagomesdtantsur, will do, probably tomorrow cause I've stopped everything to look at that probelm16:15
lucasagomesI will finish some stuff and as a TODO tomorrow morning16:15
lucasagomesI will fill one out16:15
*** joprovost1 has joined #openstack-ironic16:16
dtantsurawesome, thanks!16:16
*** joprovost has quit IRC16:17
*** joprovost1 is now known as joprovost16:17
openstackgerritNisha Agarwal proposed openstack/proliantutils: Discover iscsi_boot and iscsi_iqn  https://review.openstack.org/34165316:18
NobodyCamgood morning Ironers16:24
*** sdake has quit IRC16:24
NobodyCam:p Ironicers even16:24
TheJuliagood morning NobodyCam16:24
*** adu has joined #openstack-ironic16:25
NobodyCamMorning TheJulia16:26
dtantsurmorning NobodyCam16:26
dtantsurand good night everyone else for I call it a day :)16:26
jrollsambetts|cat: dtantsur: I still assert that instead of requiring enabled interfaces have something in common for all enabled hw types, the default_network_interface config can be set to any enabled interface, and if a node is created with a hw type that doesn't have that interface, the request fails16:26
Sukhdev_devananda dtantsur sambetts|cat - are we having a voice call to get the ironic networking patches merged?16:27
dtantsurjroll, that's an option too16:27
sambetts|catjroll: I'm working on a proposal that might resolve that part16:27
dtantsurSukhdev_, not me, sorry :(16:27
TheJuliagoodnight dtantsur16:27
jrollSukhdev_: we had one yesterday to get over the hurdle we were facing16:27
NobodyCammorning and good night dtantsur16:27
NobodyCammorning sambetts|cat roll :)16:27
Sukhdev_jroll : cool - and welcome back16:28
NobodyCamgah ... roll = roll :)16:28
NobodyCamwhat the16:28
jrollSukhdev_: thanks16:28
jrollmorning NobodyCam :)16:28
*** dtantsur is now known as dtantsur|afk16:28
* jroll assumes NobodyCam j key is broken :P16:28
TheJuliaNobodyCam: broken j key?16:28
TheJuliaheh16:28
NobodyCamjroll nope its the auto correct :p16:29
jrolllol16:29
sambetts|catjroll: https://etherpad.openstack.org/p/ironic_network_interface_discussion can you look at my second solution @L101 and see what you think?16:29
TheJuliaautocorrect is evil16:29
TheJuliaand not the good kind of evil, it is the bad kind of evil16:29
jrollthe evil kind of evil?16:30
TheJuliaWell, there is the evil league of evil....16:30
jrollTheJulia: autocorrect for pokemon: https://i.redditmedia.com/LID9qujoR1LN1oguTwIxNrrION1kmuugiGwoUmfmzUQ.jpg?w=432&s=5d4678ce9ab6043e46b5b58b533e17f016:30
*** rbartal has quit IRC16:30
* sambetts|cat is still waiting for EU release of go...16:31
jrollsambetts|cat: not a terrible idea16:31
jrollI obviously haven't thought it through fully16:31
* TheJulia will just stick with ingress whens he is in the mood16:31
sambetts|catjroll: works pretty well for the network_interface case too, because a vendor might recomned neutron above flat, but if you remove neutron from enabled then it'll fall back to the next thing in the list16:32
lucasagomesNobodyCam, TheJulia morning16:32
jrollsambetts|cat: rightright16:33
*** piet has quit IRC16:33
lucasagomesI'm also calling it a day folks, have a great night all16:33
jrollwow, I'm good at typing too16:33
lucasagomessee you all tomorrow16:33
*** lucasagomes is now known as lucas|afk16:33
NobodyCamnight lucas|afk16:33
sambetts|catrloo, TheJulia, dtantsur|afk: https://etherpad.openstack.org/p/ironic_network_interface_discussion @L101 is a proposed solution to the defaults issue can you take a look through when you get a moment?16:33
TheJuliasure sambetts|cat16:34
JayFsambetts|cat: as an operator, is there a way for me to know before creating the node what network interface I'd get on a given hardware type?16:34
jrollooo yeah, that is a bit implicit16:34
JayFsambetts|cat: The only reason I wouldn't like that is that it makes the behavior a little ... squishier. Although I guessed if I cared that much I would only enable one interface in my config?16:34
sambetts|catJayF: we could provide an API to return the list of possible interfaces for that hardware_type16:35
sambetts|catwe're providing one to list the support interfaces anyway right?16:36
jrollhttp://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/driver-composition-reform.html#rest-api-impact16:36
jrollalso has default16:36
JayFthe lists-of-defaults thing is just a strange interface, I agree it's smarter in general, but I'm wondering if it makes it less predictable16:37
JayFI don't have a strong opinion either way just asking the question16:37
jrollit would be list-of-preferred, I guess16:38
sambetts|catlist of supported interfaces in order of preference by the vendor16:38
*** jaybeale has joined #openstack-ironic16:38
sambetts|catwe must not forget the supported part :)16:39
*** derekh has quit IRC16:39
TheJuliasambetts|cat: it is an interesting idea, I'll have to simmer on it a little16:39
JayFWith the supported interfaces bit, are we going to require that some drivers support all interfaces?16:39
JayFLike with neutron or flat, it's pretty well independent of the hardware, right? Why wouldn't every driver support those?16:40
JayFI feel like I'm missing something -- namely the case where a vendor would want to blacklist a "generic"-style network interface in their driver16:40
jrollbecause there is hardware that needs to do extra things like poof nics out of thin air :(16:40
jrollsee: cisco, oneview16:41
JayFbut how is that any different than requiring port metadata be provided for "normal" hardware with a neutron driver?16:41
jrollbecause it needs to be done on the fly in the network driver, apparently16:41
JayFlike, Ironic doesn't guarantee the nics are sanely physically configured in any case, do we?16:41
jrollno16:42
jrollbut we assume they exist if they are registered16:42
TheJuliaSo that is pretty much what I told the oneview folks that the neutron stuff can partially solve the issue if they are an ML2 driver and the MAC addresses are known, the problem is, they can be assigned from a pool afaik16:42
jrollidk what magic the cisco driver does, sambetts|cat is that open source?16:42
sambetts|catnot that I'm aware of16:42
JayFjroll: so why is the cisco/oneview case different from the "I have a server with no registered nics" case?16:43
jrollJayF: because in the latter we just fail the deployment16:43
TheJuliaand in the case with oneview on a c7000 chassis, the port exists in the profile, but to dynamicly connect things even in flat since ironic is not the ultimate controller of the hardware, it still has to ask for the port to get attached to a specific network16:43
jrollin the former I guess it sets it up16:43
jrollbut honestly I have no way to tell16:43
JayFSo why is that not an acceptable answer for those other cases too?16:43
sambetts|catJayF: because we can create a network interface that can poof nics out of thin air16:43
JayFWhy add all this complexity to solve a case we can't fully solve anyway?16:43
jrollso this makes me wonder: do we do all of this work to handle an edge case16:44
jrollright16:44
JayFyeah that's what I'm getting at16:44
jrollan edge case for a proprietary out of tree driver*16:44
JayFand we aren't even fully handling the edge case16:44
sambetts|cat?16:44
sambetts|cathttps://review.openstack.org/#/c/327046/16:45
sambetts|cat^ this + the BM VlAN spec makes that case work just fine16:45
JayFsambetts|cat: basically asking the question: Why can't it be OK for those drivers to just fail a deployment if given a network interface that doens't provide full functionality, in the same way a "generic" node would fail a deployment if it didn't have any nics registered16:45
jrollJayF: oh, that's just a terrible user experience16:46
sambetts|catwe shouldn't even be able to create a broken node16:46
sambetts|catlike that16:46
jrollright16:46
sambetts|catthats what the hardware_types are for16:46
jrollmy bigger question, is why add this complexity for an edge case?16:46
jrollbut I suspect the answer is, this becomes less of an edge case16:47
JayFjroll: how is that different than what I asked?16:47
jrollas more vendors build hardware that can do this16:47
*** ijw has quit IRC16:47
jrollJayF: my 'edge case' == 'hardware that has virtual NICs'16:47
JayFokay16:47
jrollnot 'someone put the wrong network interface on a node'16:47
jrollI guess it's both cases combined, though16:47
sambetts|catI think it solves the edge case, but it also makes it possible to make network_interfaces consistent with the other interface types in hardware_types16:48
*** bvandewa has quit IRC16:49
sambetts|catwhich in the current solution network_interfaces are special because hardware_types can't define a default for them16:49
JayFjroll: yeah; that's what I'm getting at16:49
JayFjroll: and I'm OK if the virtual nic case is handled better, just wanted to boil it down to the most basic issue16:49
jrollsambetts|cat: I do worry about the implicitness, but it's likely fine16:49
jrollJayF: sure16:49
jrollJayF: that's why I've been hesitant to solve this edge case, it depends on two things16:50
sambetts|catthe defaults are kind of implict anyway, and obay the deplyers decision to not enable them16:50
sambetts|catand don't obay *16:50
jrollJayF: 1) deployers are enrolling nodes by hand and might forget to add the non-default interface needed16:50
jrollJayF: 2) people enrolling nodes don't know that the default interface won't work in the deployment they're enrolling them to (different ironic ops vs deployers etc)16:51
*** fragatina has joined #openstack-ironic16:52
*** Nisha_away has joined #openstack-ironic16:52
*** fragatina has quit IRC16:52
*** vishwanathj has quit IRC16:52
jrolloff topic: whoa. https://lwn.net/Articles/692638/16:53
*** fragatina has joined #openstack-ironic16:53
*** piet has joined #openstack-ironic16:53
*** vishwanathj has joined #openstack-ironic16:53
sambetts|catwith network_interfaces many hardware_types are likely to intersect on which interfaces they support, but power interfaces not so much, and if a deployer doesn't want to supprt the default power interface for a particular hardware_type then the only way to disable it is to disable that hardwre_type16:54
sambetts|cateven if that hardware_type does support other power interfaces that deployer is willing to support16:54
jrollyeah, I've gathered as much16:55
sambetts|catmore for JayF's benfit than anything else :)16:55
jrollI just tend to think people working on a deployment won't be so far out of touch that someone will enroll a node with the default interface16:55
sambetts|catbut why even allow that in the first place16:55
JayFI honestly just dislike things that are implicit in the way the "intersecting preference lists" suggestions are16:56
jrollI think allowing that is better than requiring every interface be specified in an enroll command16:56
jrollI know we're looking at better options16:56
*** sdake has joined #openstack-ironic16:56
jrollI just think this is probably the least worst16:56
JayFI feel like an operator who doesn't understand Ironic's internals will get surprised by that behavior16:56
JayFbut I don't feel strongly about it, just food for thought16:56
*** edand has joined #openstack-ironic16:57
*** cdearborn has joined #openstack-ironic16:59
sambetts|catmy brain feels like its been put in a blender after all this discussion17:00
*** ijw has joined #openstack-ironic17:00
*** links has quit IRC17:01
sambetts|catI don't know what right or not anymore but at least this solution gives us the best of both worlds, and gurantees you get a "working" node by default17:01
* jroll hands sambetts|cat a beer17:01
sambetts|catmuch needed, thank you17:02
jrollI have to miss the QA meeting today, sorry :(17:02
sambetts|cattbh this is problem solving is a welcome relieve from the downstream deadline I've got atm :-P17:02
sambetts|catjroll: ok :)17:02
*** sambetts|cat is now known as sambetts17:03
*** edand has quit IRC17:04
*** Sukhdev_ has quit IRC17:05
*** sambetts is now known as sambetts|cat17:06
*** PollyZ has quit IRC17:06
*** baoli has joined #openstack-ironic17:07
*** penick has joined #openstack-ironic17:09
*** mgoddard_ has quit IRC17:09
*** mgoddard has joined #openstack-ironic17:09
*** bnemec has quit IRC17:10
*** ChrisAusten has joined #openstack-ironic17:13
*** bnemec has joined #openstack-ironic17:13
*** fragatina has quit IRC17:15
lazy_princeanyone here form oneview team..?17:16
TheJuliathiagop17:16
thiagopMe17:17
thiagop:)17:17
lazy_princeso i am trying to use ironic-oneview cli..17:17
lazy_princedo you know if there is a way to specify the output directory for genrc cmd..?17:18
*** marios is now known as marios|gone17:19
thiagoplazy_prince: I think the last question is the path where to save the genrc file17:19
*** marios|gone is now known as marios17:19
lazy_princeyes..17:19
lazy_princethiagop: and what is the default path..17:20
thiagoplazy_prince: ~/ironic-oneview-cli.rc or something (it is shown between brackets)17:21
lazy_princeokay.. anyway to change that by some parameter..?17:21
*** trown|lunchlearn is now known as trown17:23
*** PollyZ has joined #openstack-ironic17:24
lazy_princethiagop: sorry.. I get your response now..17:24
lazy_princethank you..17:24
thiagoplazy_prince: np ;)17:25
* mgould -> home; good night!17:25
lazy_princethiagop: so now that it is generated in a different folder, how do I specify to use it..?17:25
*** mgould is now known as mgould|afk17:25
thiagopjust pass a different (full) path in the last step17:26
thiagopfull == with filename included17:26
lazy_princeI did that.. but when I invoke node-create, what option i have to use to use this file..17:27
lazy_princesay, I generated two rc files.. and i want to switch between then on need basis..17:27
*** PollyZ has quit IRC17:29
*** penick has quit IRC17:29
*** fellypefca has joined #openstack-ironic17:29
lazy_princefor eg: I could have two oneview setups and each one of them may be used in different regions... so I will generate two rc files for each oneview.17:30
lazy_princethiagop: let us say I need to register nodes for one of the oneview in respective region, how can i specify the rc file with node-create17:32
thiagoplazy_prince: have you 'sourced' the file?17:32
thiagoplazy_prince: like 'source ironic-oneview-cli.rc' then 'ironic-oneview-cli node-create'17:33
lazy_princeaha.. so dumb and I was was worried of how to specify it as a parameter..17:34
lazy_princethanks much...17:34
*** yogi has quit IRC17:35
thiagoplazy_prince: np, we thought of that to be as near as possible of the ironicclient usage17:35
*** PollyZ has joined #openstack-ironic17:37
lazy_princethiagop: last question.. does it support v3 auth APIs..? I do not see Domain info being accepted...17:39
*** ohamada has quit IRC17:39
thiagoplazy_prince: I think it doesn't. Is Ironic already supporting v3?17:39
lazy_princethiagop: as a client, I guess yes..17:40
lazy_princeI mean cli client..17:41
*** trown is now known as trown|relocating17:41
*** PollyZ has quit IRC17:43
*** PollyZ has joined #openstack-ironic17:51
*** vishwanathj has quit IRC17:52
*** vishwanathj has joined #openstack-ironic17:53
*** sukhdev has quit IRC17:53
*** PollyZ has quit IRC17:56
*** ametts has joined #openstack-ironic18:00
*** rama_y has joined #openstack-ironic18:02
thiagopsambetts|cat: rajinir I'm setting something on your speaker profile just to submit the panel, please update it later :)18:03
rajinirthiagop: sure thanks18:03
*** PollyZ has joined #openstack-ironic18:05
sambetts|catthiagop: I didn't  know you could change that18:08
*** PollyZ has quit IRC18:09
thiagopsambetts|cat: kinda strange indeed, but some fields were required18:09
sambetts|catthiagop: have you got a link to the presentation?18:09
*** pcaruana has joined #openstack-ironic18:09
thiagopsambetts|cat: just for edition, I think once the selection starts, they'll send a link18:10
thiagopjust to edit*18:11
sambetts|catah, its not appearing in the "Presentations Other Submitted with you as a speaker" section on my profie18:11
sambetts|catthats why I wondered if you had got the right me18:11
sambetts|cat:-p18:11
sambetts|catDoes it have my blue logo?18:11
thiagopsambetts|cat: yep. Didn't you received an e-mail about the submission?18:12
sambetts|catthiagop: I got an email saying to edited my profile that was all18:12
thiagopLOL18:12
*** ccamacho has quit IRC18:15
sambetts|catI'm heading off18:16
sambetts|catnight all18:16
*** sambetts|cat is now known as sambetts18:16
*** sambetts is now known as sambetts|afk18:16
thiagopnight sambetts|afk18:17
*** mordred has joined #openstack-ironic18:19
*** vishwanathj has quit IRC18:22
*** ametts has quit IRC18:24
*** mbound_ has quit IRC18:26
*** ametts has joined #openstack-ironic18:28
*** mbound has joined #openstack-ironic18:28
*** mbound has quit IRC18:29
openstackgerritJay Faulkner proposed openstack/ironic: Metric chassis, driver, node, and port API calls  https://review.openstack.org/30192318:31
*** ChubYann has joined #openstack-ironic18:33
JayFjroll: ^ updated, and it deps on the global-requirements patch18:34
*** ccamacho has joined #openstack-ironic18:34
*** wajdi has quit IRC18:35
rloohear ye, hear ye, anyone interested in the networking patches. The next path has three +2's. Does anyone want to look? If not (I'll wait 10 minutes), I'll +A. https://review.openstack.org/#/c/285852/18:36
*** trown|relocating is now known as trown18:38
*** Sukhdev has joined #openstack-ironic18:42
*** PollyZ has joined #openstack-ironic18:45
*** PollyZ has quit IRC18:50
* TheJulia sees a +A and feels like dancing... except the work is not done18:52
*** PollyZ has joined #openstack-ironic18:52
TheJuliaNext patch in the networking series, has 2x +2s, one +1. https://review.openstack.org/#/c/317393  If you haven't reviewed it yet, might be a good time to review it now.18:53
rlooTheJulia: do you have a good answer for Yuriy's question in that patch?18:53
rlooTheJulia: I was thinking it was cuz cleaning is 'flaky'18:53
TheJuliaI _think_ it is because we explicitly call cleaning and we may need to retry it18:53
rlooTheJulia: cuz the cleaning didn't finish, right?18:54
TheJuliaWe likely need a remove_all_ports thing or something18:54
TheJuliayup18:54
*** tiendc has quit IRC18:54
TheJuliaor cleaning had to be restarted due to some unknown reasons18:54
*** baoli has quit IRC18:54
rlooTheJulia: the 'flaky' bit :)18:55
TheJuliayeah..... I think we fixed part of the flaky bit though :)18:55
rlooTheJulia: but provisioning should be more certain... Although I wonder if we should also roll back? What/Can we get into a similar state with provisioning?18:55
TheJuliatruthfully, really, we need a "nuke all my ports" or something method, but after these are landed18:55
rlooTheJulia: yeah. So I am fine if we also land that patch. Anything we do can be added later.18:56
rlooTheJulia: but maybe we can wait for one of the v* to reply? dunno.18:56
*** ijw has quit IRC18:56
TheJuliarloo: if we can't get that patch in nova, we will need something to ports that are attached that don't matter or that are invalid based on the state machine in order to properly attach networking18:56
TheJuliarloo: I was thinking of waiting until they could look at it again in the morning, I just would also love other eyes on it, looking at who has reviewed it18:56
rlooTheJulia: yup, can wait til tomorrow. vdrok is away til tues but vsaienk0 I think will look.18:57
rlooTheJulia: one a day is good :)18:57
TheJuliathiagop: How about a nice neutron driver before you leave for the day? *ducks*18:57
* TheJulia is kidding, because if memory serves it is something like 5pm there18:58
*** sdake has quit IRC18:58
rlooTheJulia: ha ha. Maybe if you promise to review his patch(es) :)18:58
*** mordred has quit IRC18:59
openstackgerritNisha Agarwal proposed openstack/ironic: Fix iLO drivers temporarily for local_gb  https://review.openstack.org/34175219:00
*** baoli has joined #openstack-ironic19:01
TheJuliaI commented in the rev with our context since Yuriy will surely see early tomorrow morning19:01
rloothx TheJulia. Good thinking!19:02
jroll]/b 11719:02
jrolloooops.19:02
*** trown is now known as trown|mtg19:03
*** bvandewa has joined #openstack-ironic19:07
*** moshele has joined #openstack-ironic19:08
*** ChrisAusten has quit IRC19:12
*** causten_ has joined #openstack-ironic19:12
thiagopTheJulia: missing context19:16
* thiagop reads19:16
TheJulia:)19:17
thiagopTheJulia: 4pm in fact19:18
TheJuliaoh... I guess it was DST when I thought it was 2 hours19:18
thiagopTheJulia: "Winter is here" </endquote>19:19
*** bvandewa has quit IRC19:19
thiagop#pixiesay quotes_count += 119:19
PixieBootsʕ•͡ᴥ•ʔ: quotes_count += 119:19
TheJuliathiagop: "Summer is here, but winter is coming."19:21
*** sdake has joined #openstack-ironic19:22
*** nicodemos has quit IRC19:26
*** bvandewa has joined #openstack-ironic19:28
*** nicodemos has joined #openstack-ironic19:29
*** mbound has joined #openstack-ironic19:30
*** dprince has joined #openstack-ironic19:32
*** fellypefca has quit IRC19:34
*** mbound has quit IRC19:35
*** pcaruana has quit IRC19:35
thiagophttps://review.openstack.org/#/c/285852/19:36
thiagopops19:36
thiagopbad paste19:36
*** moshele has quit IRC19:39
*** e0ne has quit IRC19:43
*** moshele has joined #openstack-ironic19:47
jrollthis is the last patch to unblock iLO CI, if someone has a cycle or two to review https://review.openstack.org/#/c/264590/2919:48
devanandajroll: spec is merged, could you drop your -2 on https://review.openstack.org/#/c/325599/ ?19:49
jrolldevananda: done19:49
devanandaI'm picking up work on that code again today19:49
devanandatyvm19:49
jrollnp, ty!19:49
* devananda reviews the ilo devstack patch19:53
*** bvandewa has quit IRC19:53
*** vishwanathj has joined #openstack-ironic19:54
*** sdake has quit IRC19:57
*** moshele has quit IRC19:58
*** catintheroof has quit IRC20:07
*** bvandewa has joined #openstack-ironic20:14
*** Nisha_away has quit IRC20:15
watanabe_isaorajinir, ping20:16
*** trown|mtg is now known as trown20:16
thiagopwatanabe_isao: have you received an email notification about the submission of the panel?20:19
thiagopmjturek1: ^20:19
*** trown is now known as trown|outtypewww20:21
devanandajroll: I'm reviewing the network patches now -- there are 5 or 6 in a chain, including the API one with my procedural -2 on it20:21
devanandajroll: wdyt of landing aaallll of that now? I see some +2's from you, but not on all of them yet20:22
watanabe_isaothiagop, yes. A mail said I was ad to the panel.20:23
*** ijw has joined #openstack-ironic20:24
thiagopwatanabe_isao: wonderful, thanks20:25
openstackgerritMerged openstack/ironic: Add network interface to base driver class  https://review.openstack.org/28585220:25
openstackgerritMerged openstack/ironic: Allow to use network interfaces in devstack  https://review.openstack.org/29352020:26
*** ijw_ has joined #openstack-ironic20:27
*** nicodemos has left #openstack-ironic20:27
*** nicodemos has joined #openstack-ironic20:27
*** piet has quit IRC20:28
*** ijw has quit IRC20:28
*** ijw_ has quit IRC20:30
*** ijw has joined #openstack-ironic20:30
*** athomas has quit IRC20:31
mjturek1thiagop: sorry! yes I recieved the notification, thank you!20:31
*** bvandewa has quit IRC20:34
*** clenimar__ has joined #openstack-ironic20:35
*** joprovost has quit IRC20:35
*** bvandewa has joined #openstack-ironic20:35
*** PollyZ_ has joined #openstack-ironic20:36
*** PollyZ has quit IRC20:37
thiagopmjturek1: great!20:38
*** daemontool_ has quit IRC20:41
*** clenimar__ has quit IRC20:42
*** clenimar_ has joined #openstack-ironic20:42
*** david-lyle has joined #openstack-ironic20:43
*** piet has joined #openstack-ironic20:45
*** piet has quit IRC20:46
*** piet has joined #openstack-ironic20:46
openstackgerritChris Krelle proposed openstack/ironic: Upadte devstack section of quickstart to use agent_ssh  https://review.openstack.org/34180120:47
*** david-lyle has quit IRC20:47
*** david-lyle has joined #openstack-ironic20:49
JayFNobodyCam: AFAIK we aren't deprecating pxe_ssh?20:52
JayFNobodyCam: it's been reimplented to work with IPA doing the iscsi exposures20:53
jrolldevananda: I have no opposition to landing all the things :)20:53
NobodyCamI thought we were going to move it to the staging repo20:53
JayFthe *_ssh drivers are going to staging repo if/when we move our gate to *_ipmitool20:54
JayFwhich is when we'd change devstack to use a *_ipmitool driver w/vbmc instead of *_ssh20:54
jrolldevananda: I just got back home from a quick appt and was planning to review some of it, but if I don't need to that makes me happy :)20:54
openstackgerritDevananda van der Veen proposed openstack/ironic: Upadte devstack section of quickstart to use agent_ssh  https://review.openstack.org/34180120:54
JayFdevananda: ^ same question I just posed to nobodycam20:55
TheJuliasame rev even20:55
devanandaJayF: I just edited a typo in there20:55
devanandano opinion on the actual deprecation of pxe_ssh20:55
TheJuliahave we officially deprecated it yet?20:56
TheJuliait being the ssh drivers?20:56
thiagopdevananda: s/Upadte/Update/20:56
JayFWe can't until we have the gate running on *_ipmitool drivers.20:56
JayFWe haven't changed those yet because the pass rate, as graphed, isn't as high as our *_ssh drivers20:56
JayFI would be +1 to a change making the ipmitool + vbmc the devstack default and what our docs reccomend, though20:56
NobodyCamdevananda: thank you :)20:56
TheJuliaI thoughtahh yeah, stil two ssh jobs20:56
*** e0ne has joined #openstack-ironic20:57
betherlyyay ironic-ui new docs finally building so they will be all up to date :D20:59
NobodyCamawesome betherly :)20:59
devanandabetherly: o/^521:00
*** ijw has quit IRC21:01
betherlyif anyone wants to try out the docs and the ui and give any user feedback it is always always appreciated so we can make sure that everything works as you would expect and require :D21:01
betherlyadd and delete node functionalities have merged and work. its the edit node stuff that is still WIP so that could be frustrating but i promise its coming soon!!21:02
jrollNobodyCam: left another note - tl;dr pxe_* is iscsi, agent_* is http, both use IPA, neither is more capable just different21:03
*** adu has quit IRC21:04
NobodyCamack :)21:05
*** e0ne has quit IRC21:06
openstackgerritRamamani Yeleswarapu proposed openstack/ironic: Centralize config options - [neutron]  https://review.openstack.org/30483821:06
*** ijw has joined #openstack-ironic21:10
rajinirwatanabe_isao: hi21:11
*** adu has joined #openstack-ironic21:13
*** dprince has quit IRC21:21
*** vishwanathj has quit IRC21:25
watanabe_isaorajinir, sorry. Nothing at all, now. :) Moving to the company...21:25
*** watanabe_isao has quit IRC21:25
*** vishwanathj has joined #openstack-ironic21:25
openstackgerritRamamani Yeleswarapu proposed openstack/ironic: Centralize config options - [DEFAULT]  https://review.openstack.org/30907021:30
openstackgerritDevananda van der Veen proposed openstack/python-ironicclient: Updates supporting ironic-neutron integration  https://review.openstack.org/20614421:32
devanandaTheJulia: I've added the depends-on ^21:32
TheJuliaMerci21:32
*** rpioso has quit IRC21:32
devanandaincidentally, I also -1'd the thing it depends on21:32
*** baoli has quit IRC21:33
TheJuliadevananda: I saw21:33
devanandathat seems to be my only real objection in that series21:33
devanandathough I'd like to see rloo's and my comments on 206244 fixed21:34
rloodevananda: yeah, i'd be fine with that too. I was being nice :)21:35
devanandavdrok, vsaienk0: I know it's late for you both, but just checking if you're around & have a moment to discuss 317392?21:36
*** cdearborn has quit IRC21:37
*** aNupoisc has joined #openstack-ironic21:39
openstackgerritMerged openstack/ironic: Add support for building ISO for deploy ramdisk  https://review.openstack.org/26459021:39
openstackgerritMerged openstack/ironic: Config variable to configure [glance] section  https://review.openstack.org/26680321:39
*** daemontool_ has joined #openstack-ironic21:40
TheJuliadevananda: I think this is the driver https://review.openstack.org/#/c/188370/20/specs/approved/driver-composition-reform.rst@198  What if we just take whatever when the post occurs?  Validation still has to occur, updating still has to have a check based on the driver composition spec.21:40
*** vishwanathj has quit IRC21:41
devanandaTheJulia: exactly21:41
devanandaI just posted a longer comment on that review, too21:41
TheJuliaawesome21:41
*** vishwanathj has joined #openstack-ironic21:41
jrolldevananda: "I'm fairly convinced the RPC call get_enabled_network_interfaces will need to be removed later -- this should be visible from the database, much like the current list of enabled drivers is determined by querying the database." that is the plan21:42
devanandajroll: cool. I didn't see any notes inline about that21:42
jrolldevananda: I should say, that's what the driver comp spec outlines21:43
jrolland we're treating this as part of that21:43
devanandait outlines adding the RPC call?21:43
* devananda must have forgotten that detail21:43
jrollit outlines putting enabled interfaces in the db21:43
devanandaright21:43
devanandathat I knew21:43
jrollokay cool21:43
*** rcernin has quit IRC21:43
devanandamy objection is adding an RPC call into POST21:43
jrollyep, I agree21:44
devananda:)21:44
devanandathe three patches before that LGTM21:44
TheJuliaagreed, just posted another comment to it21:44
jrolljust making sure you know that this being visible from the db is the goal for the driver comp stuff21:44
devanandaI'm going through the grenade logs now21:44
jrolland we plan to refactor some of this to fit this better21:44
devanandajroll: yea. I was pretty sure that was the plan21:44
devanandathanks for confirming :)21:44
jroll:)21:44
thiagopI'm calling it a day21:45
thiagopsee you tomorrow21:45
devanandathiagop: g'night!21:45
jrollnight thiagop21:45
TheJuliaditto, I think it is time to call it a day21:45
*** thiagop has quit IRC21:45
TheJuliagoodnight everyone21:45
jroll\o TheJulia21:45
jrolldevananda: did you want my eyes on those or not +W for some other reason?21:46
devanandahttp://logs.openstack.org/44/206244/116/check/gate-grenade-dsvm-ironic/634ba53/logs/new/screen-ir-cond.txt.gz?level=INFO#_2016-07-13_11_59_00_84021:47
devanandajroll: I hav enot +W'd yet because I hae ve an upgrade concern21:47
devanandahttp://logs.openstack.org/44/206244/116/check/gate-grenade-dsvm-ironic/634ba53/logs/etc/ironic/ironic.conf.txt.gz21:47
jrollk21:47
devananda[neutron]21:47
devanandacleaning_network_uuid = b7a97c12-24cd-499b-8530-9f4b6f5ed8de21:47
devananday21:47
devanandathe grenade 'new' env includes this in the ironic.conf21:47
devanandaand the 'new' ironic-conductor logs are, indeed, doing all the wonderful network magic21:48
devanandaeven before hte API changes are included21:48
devanandathat actually concerns me21:48
devananda*even before the API or devstack changes have landed21:48
*** Goneri has quit IRC21:48
jrolldevananda: wait, which magic concerns you?21:49
devanandahm21:49
devanandaI'm still digging -- pardon my thinking outloud21:49
jrollno worries21:49
jrolltrying to help you walk through it :)21:49
devanandaI guess we're setting [neutron] cleaning_network_id all the time now ?21:49
jrollwe always have been21:49
jrollI believe21:50
devanandait is not actually required though21:50
TheJuliait is not required for the current state afaik21:50
jrollyeah, see an unrelated change http://logs.openstack.org/90/264590/29/check/gate-tempest-dsvm-ironic-agent_ssh/6beab66/logs/etc/ironic/ironic.conf.txt.gz21:50
TheJuliaunless the neutron tenant networkd river is selected21:50
jrolleh?21:50
jrollit's totally required to do cleaning today, before this work lands21:50
jrollironic manages the cleaning ports today21:51
devanandaI had an issue in my dev lab with these patches a couple months ago. "noop" network broke w/o a cleaning_net_id21:51
jrollit does not use the nova ports for cleaning21:51
devanandajroll: only in some cases21:51
jrolldevananda: in current trunk, it manages cleaning ports when using neutron for dhcp21:51
devanandajroll: right. I think I didn't realize that because it wasn't logging it >_<21:51
TheJuliadevananda: that has been fixed21:51
jrollyeah, maybe21:51
devanandaTheJulia: thus my surprise :)21:52
jrollwe don't test noop dhcp driver, so we won't be able to test the upgrade in that mode21:52
devanandaso, I see it is not some bad magic in the network patches -- it's just bette rlogging :)21:52
jrollhehe21:52
TheJuliaindeed()21:52
rloodevananda, TheJulia, jroll: fyi, vdrok is on PTO, he'll be back on Tues. In the meantime, he said vsaienk0 would baby the network patches.21:53
devanandarloo: ah, ty21:54
devanandaunless ya'll speak up now, I'm going to land the first three of those patches -- I think they're good enough() and they've been passing tests and grenade21:54
devanandaand the second API patch is separate enough now that we can land it later21:54
rloogo for it devananda!!!21:55
jrolldevananda: please do21:56
rloodevananda: didn't you -1 the third one though?21:57
devanandarloo: I did, with nits.21:57
devanandasuitale to a follow on, as we often do21:57
*** vishwanathj has quit IRC21:57
rloodevananda: i thought if nits only, you do +, not -1. Anyway, I don't really care. Will just be amused if you can +A/-1.21:58
rloodevananda: darn! :)21:58
devanandarloo: you're correct. I -1'd while still going through the patches ... and just changed my -1 to a +2. call me fickle if you will21:59
rloodevananda: ha ha.21:59
JayFyou're going to get dinged by reviewstats for a disagreement!22:00
JayF:P22:00
*** sinh has quit IRC22:02
*** adu has quit IRC22:02
devanandaLOL22:03
*** jcoufal has quit IRC22:04
devanandaok - those three are in the gate now ....22:04
* devananda crosses fingers22:04
jroll\o/22:04
JayFnice!22:04
devanandatime to move the car & find a late lunch .... bbiab22:05
jrollanyone have a reason not to move py35 jobs to voting?22:15
openstackgerritMario Villaplana proposed openstack/ironic: Add power state change notifications  https://review.openstack.org/32186522:15
openstackgerritMario Villaplana proposed openstack/ironic: Add notification base classes and docs  https://review.openstack.org/29846122:15
*** sinh has joined #openstack-ironic22:15
JayFjroll: I'd sat go fo rit22:16
jrollJayF: I just realized this means going through all projects we own >.>22:18
jrollwhich is fine22:18
jrolljust took on more work than I thought :P22:18
JayFjroll: going through all the projects we own?22:19
jrollJayF: yeah, IPA, ironic-lib, etc22:20
jrollmake sure the jobs are massing22:20
jrollpassing.22:20
JayFgotcha22:20
*** causten_ has quit IRC22:20
*** ametts has quit IRC22:20
*** garthb has joined #openstack-ironic22:22
betherlyjroll: updated https://wiki.openstack.org/wiki/Ironic#Projects to add the ironic-ui22:27
betherlylet me know if you want me to edit it further22:27
jrollJayF: if you're curious, they were all passing on all of our projects that support py3 at all, here's the patch https://review.openstack.org/34183022:28
JayFI'll review it22:28
jrollbetherly: we should really use git.o.o for everything on that page, but that isn't your problem, I'll fix it. LGTM :)22:28
jrollbetherly: also, what're you doing here, it's borderline late for me let alone you22:28
betherlyjroll: woops sorry :/ just knew i said id update it * months ago and have completely failed to. let me know if you want me to submit it through gerrit somehow22:29
*** jrist has joined #openstack-ironic22:29
* betherly is not sure how though so would appreciate jroll insight22:29
jrollbetherly: no, I mean the code links should be to git.openstack.org instead of github22:29
jrollfixing that now though22:29
jrollthank you for the updates :)22:30
betherlyjroll: dont worry im not up stupid o'clock. im in CA this week so its only 15:30 :)22:30
jrollaha!22:30
jrollenjoy the best coast, then22:30
betherlywhat was stupid o'clock was my body waking me up at 3:30am local time today and yesterday22:30
betherlyfacepalm22:30
jrollhehe22:31
*** ElCoyote_ has left #openstack-ironic22:35
*** jrist has quit IRC22:46
JayFhttps://review.openstack.org/#/c/301923/ has 1x+1, 1x+2, is an easy review, and the requirement bump it depends on is in the gate22:48
JayFsomeone should do me a solid and land it :D22:48
*** milan has quit IRC22:52
*** PollyZ_ has quit IRC22:58
*** mordred has joined #openstack-ironic23:01
*** sabeen1 has quit IRC23:01
*** adu has joined #openstack-ironic23:03
*** ionutbalutoiu has quit IRC23:05
*** bradjones has quit IRC23:06
*** bradjones has joined #openstack-ironic23:07
*** bradjones has quit IRC23:07
*** bradjones has joined #openstack-ironic23:07
*** ionutbalutoiu has joined #openstack-ironic23:08
*** piet has quit IRC23:10
openstackgerritChris Krelle proposed openstack/ironic: Upadte devstack section of quickstart to use agent_ipmitool  https://review.openstack.org/34180123:15
NobodyCamJayF: like that ^^^^^23:15
NobodyCam??23:15
NobodyCam:p23:15
NobodyCamlol23:16
openstackgerritChris Krelle proposed openstack/ironic: Update devstack section of quickstart to use agent_ipmitool  https://review.openstack.org/34180123:16
JayFNobodyCam: +2'd23:17
NobodyCam:)23:17
JayFNobodyCam: wanna take a look at 301923 ^ I linked earlier23:17
NobodyCamsure23:18
*** piet has joined #openstack-ironic23:21
*** rbudden has quit IRC23:22
jrollNobodyCam: quick nits there23:23
jrollI can fix them and land if you want though23:23
*** ijw has quit IRC23:24
JayFjroll: your project-config change got V-1 and I commented a -1 on it23:24
jrollJayF: lame23:24
JayFjroll: you have to also modify the names of the actual jobs, not just the list in zuul layout23:24
jrollwhaaaaat23:24
JayFyep23:24
jrollugh I hate jjb23:25
NobodyCamJayF: I kinda wise that had a release note just because its adding a new thing23:25
NobodyCamjroll: let me take a quick look23:25
JayFNobodyCam: that's exceedingly valid, especially since it adds config options23:25
JayFNobodyCam: please -1 it with that comment23:25
jrollthanks for copying out the errors for me JayF23:25
jrollNobodyCam: good catch on reno23:25
*** adu has quit IRC23:26
*** sdake has joined #openstack-ironic23:26
JayFI should probably also regen config file for that too, honestly23:26
JayFand make sure it's actually pulling in those option23:26
JayF*options23:26
jrollhrm, ag ironic-python35 gives me nothing, so where were the old ones defined? :/23:27
NobodyCamJayF: oh that would be good too. thou I did not comment about it23:27
jrolloh I see it, lame23:28
JayFyeah; it's really obnoxious how it's laid out23:28
*** sdake__ has joined #openstack-ironic23:28
openstackgerritChris Krelle proposed openstack/ironic: Update devstack section of quickstart to use agent_ipmitool  https://review.openstack.org/34180123:29
NobodyCamjroll: nits addressed :)23:29
jrollNobodyCam: +223:29
jrollthanks23:29
JayF+2a23:30
jrollI might leave that til morning for the euro opinion23:30
jrollor not23:30
jrolllol23:30
JayFI mean, I can if we need/want to?23:30
JayFI can unland it, lol23:30
NobodyCamlol23:30
NobodyCam:)23:30
JayFseems like an obvious/minor change23:30
jrollyeah the s/pxe/agent/ is the weird part23:30
JayFPatch Set 5: -Workflow23:31
JayFGoing to let someone less invested in the agent land this :P23:31
NobodyCam:) +++23:31
*** sdake has quit IRC23:32
*** ijw has joined #openstack-ironic23:33
*** piet has quit IRC23:33
* devananda eagerly watches the network patches finish the gate23:33
*** piet has joined #openstack-ironic23:33
jrollsorry, power failure23:34
* jroll should stop working and go shopping for a UPS23:34
jrollthanks JayF23:34
jrollI'll land tomorrow if nobody nacks it23:34
devanandajroll: UPS's are great23:35
jrollindeed23:35
NobodyCam++ on UPS's23:35
jrollI've been lazy23:35
devanandaI've had my wireless router, NAS, etc, on UPS for years.23:35
jrollalso didn't have many power problems in CA, this is the second blip in a month here23:35
devanandait's fun whenthe power goes out at home, I'm on the road, and I can still VPN in to my testbed :)23:36
NobodyCamdevananda: have you replaced the battery on the ups?23:36
devanandaNobodyCam: nope23:36
NobodyCam:p23:36
*** sdake__ has quit IRC23:36
devanandaI think it's 7yr old now? ... still working well enough.23:36
*** jaybeale has quit IRC23:36
devanandathe systems I have attached draw maybe 30W ... it's designed for 400W ;)23:37
NobodyCammine go about every three to four years23:37
NobodyCamahh23:37
*** yuanying_off is now known as yuanying23:37
openstackgerritMerged openstack/ironic: Add 'neutron' network interface  https://review.openstack.org/31739323:40
devananda\o/23:41
*** watanabe_isao has joined #openstack-ironic23:41
openstackgerritChris Krelle proposed openstack/ironic: Update devstack section of quickstart to use agent_ipmitool  https://review.openstack.org/34180123:41
NobodyCamfixed pep8 on the link23:42
openstackgerritMerged openstack/ironic: Update the deploy drivers with network flipping logic  https://review.openstack.org/21326223:42
openstackgerritMerged openstack/ironic: Add multitenancy-related fields to port API object  https://review.openstack.org/20624423:42
harlowjarloo lucas|afk https://review.openstack.org/34185823:43
devananda\o/ \o/ /o/ \o\ \o/ \o/23:43
NobodyCamhehehe23:43
devanandaonly took 12 months for that patch to merge ;)23:44
*** mtanino has quit IRC23:44
devanandaSukhdev: we've made progress ^^^23:44
NobodyCam\o/ did we start this journey at the Paris summit?23:45
NobodyCamdid == didn't23:45
*** adu has joined #openstack-ironic23:50
openstackgerritOpenStack Proposal Bot proposed openstack/ironic: Updated from global requirements  https://review.openstack.org/34185923:51
openstackgerritOpenStack Proposal Bot proposed openstack/ironic-python-agent: Updated from global requirements  https://review.openstack.org/34186023:51
*** adu has quit IRC23:55
*** Sukhdev has quit IRC23:58
*** Sukhdev has joined #openstack-ironic23:59

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