Tuesday, 2015-09-22

*** Sukhdev has joined #openstack-ironic00:00
krotscheckHow does the python-ironic client do integration testing?00:02
krotscheckIn the gate?00:02
*** achanda has quit IRC00:03
krotscheckI'm trying to write some tests for the jsclient's api library, and want to make sure I don't have to rewrite things.00:03
*** achanda_ has quit IRC00:04
*** naohirot has joined #openstack-ironic00:04
*** Sukhdev has quit IRC00:10
Haomengkrotscheck: hi, welcome00:15
Haomengkrotscheck: we have https://github.com/openstack/python-ironicclient  project, which as the test code for client call00:16
krotscheckHaomeng: Neat. Where's the devtack configuration for the gate?00:20
*** shadower has quit IRC00:23
*** shadower has joined #openstack-ironic00:23
*** keekz has quit IRC00:24
*** garthb has quit IRC00:25
*** keekz has joined #openstack-ironic00:25
Haomengkrotscheck:  devtack configuration?00:30
Haomengkrotscheck: you mean devstack gate?00:31
jrolldevananda: yes, I left it on the list as only irmc/ilo is left, and if they land that's totally awesome. everything else is updated00:36
jrolldevananda: (you're probably asking that because cisco thing, which was +A'd this morning)00:37
*** ijw has quit IRC00:39
*** dims_ has quit IRC00:42
*** harshs has quit IRC00:53
*** harshs has joined #openstack-ironic00:53
*** Haomeng|2 has joined #openstack-ironic01:02
*** sdake_ has joined #openstack-ironic01:04
*** Haomeng has quit IRC01:06
*** sdake has quit IRC01:06
*** sdake_ has quit IRC01:07
*** sdake has joined #openstack-ironic01:07
openstackgerritNaohiro Tamura proposed openstack/ironic: Refactor IRMCVirtualMediaIscsiDeploy by applying new BootInterface  https://review.openstack.org/22137101:16
openstackgerritNaohiro Tamura proposed openstack/ironic: Refactor IRMCVirtualMediaAgentDeploy by applying new BootInterface  https://review.openstack.org/22157701:18
*** ijw has joined #openstack-ironic01:20
*** ijw has quit IRC01:21
*** ijw has joined #openstack-ironic01:22
*** dims has joined #openstack-ironic01:26
jrollkrotscheck: https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L338501:29
jrollkrotscheck: which maps to https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/ironic.yaml#L3801:29
*** priteau has joined #openstack-ironic01:32
*** priteau has quit IRC01:37
*** chenglch has joined #openstack-ironic01:38
*** ukalifon1 has joined #openstack-ironic01:44
*** ukalifon1 has quit IRC02:25
openstackgerritMerged openstack/ironic: Add Cisco IMC PXE Driver  https://review.openstack.org/21925302:27
openstackgerritMerged openstack/ironic: Clean up CIMC driver docs and comments  https://review.openstack.org/22595802:28
openstackgerritMerged openstack/ironic: Allow abort for CLEANWAIT states  https://review.openstack.org/20155202:29
*** achanda has joined #openstack-ironic02:33
*** dims has quit IRC02:33
*** sdake has quit IRC02:39
*** david-ly_ has joined #openstack-ironic02:39
*** david-lyle has quit IRC02:40
*** harshs has quit IRC02:40
*** dhellmann has quit IRC02:40
*** dhellmann has joined #openstack-ironic02:41
*** dansmith has quit IRC02:41
*** dansmith has joined #openstack-ironic02:42
*** dansmith is now known as Guest2437802:42
devanandayay merges!02:48
jroll\o/02:49
*** naohirot has quit IRC03:02
*** saripurigopi has joined #openstack-ironic03:03
*** rloo has quit IRC03:05
openstackgerritRamakrishnan G proposed openstack/ironic: Agent Inband RAID configuration available in cleaning  https://review.openstack.org/22493803:07
*** david-ly_ is now known as david-lyle03:17
*** ramineni1 has joined #openstack-ironic03:24
openstackgerritRamakrishnan G proposed openstack/ironic: Allow unsetting node.target_raid_config  https://review.openstack.org/22614803:24
*** ramineni_ has joined #openstack-ironic03:26
*** ramineni1 has quit IRC03:28
*** Marga__ has joined #openstack-ironic03:31
openstackgerritOpenStack Proposal Bot proposed openstack/ironic: Updated from global requirements  https://review.openstack.org/22461403:33
*** dims has joined #openstack-ironic03:34
*** Marga_ has quit IRC03:34
*** Marga__ has quit IRC03:35
*** naohirot has joined #openstack-ironic04:00
*** lazy_prince has joined #openstack-ironic04:01
*** harshs has joined #openstack-ironic04:08
*** dims has quit IRC04:09
*** garthb has joined #openstack-ironic04:10
*** ramineni_ has left #openstack-ironic04:31
*** harshs has quit IRC04:36
*** rameshg87 has joined #openstack-ironic04:43
*** ukalifon1 has joined #openstack-ironic04:46
*** Marga_ has joined #openstack-ironic04:47
*** Marga_ has quit IRC04:49
*** Marga_ has joined #openstack-ironic04:49
*** Marga_ has quit IRC05:05
*** saripurigopi has quit IRC05:19
openstackgerritAnusha Ramineni proposed openstack/ironic: Make end-points discoverable via Ironic API  https://review.openstack.org/20589505:33
openstackgerritNaohiro Tamura proposed openstack/ironic: Add hardware inspection module for iRMC driver  https://review.openstack.org/19648005:35
openstackgerritAnusha Ramineni proposed openstack/ironic: Make end-points discoverable via Ironic API  https://review.openstack.org/20589505:36
*** garthb has quit IRC05:48
*** garthb has joined #openstack-ironic05:49
*** Sukhdev has joined #openstack-ironic05:49
*** garthb has quit IRC05:55
*** Sukhdev has quit IRC06:17
*** rbudden has joined #openstack-ironic06:35
*** vinbs has joined #openstack-ironic06:52
*** david-lyle has quit IRC06:58
*** david-lyle has joined #openstack-ironic07:14
*** jamielennox is now known as jamielennox|away07:15
*** dtantsur|afk is now known as dtantsur07:16
dtantsurMorning Ironic07:16
*** achanda has quit IRC07:17
*** ifarkas has joined #openstack-ironic07:24
*** praneshp has quit IRC07:31
*** betherly has quit IRC07:41
*** zsmithnyc has quit IRC07:41
*** zhenguo has quit IRC07:41
*** Ng has quit IRC07:41
*** boris-42 has quit IRC07:41
*** cppforlife_ has quit IRC07:41
*** BadCub has quit IRC07:41
*** lekha has quit IRC07:41
*** aweeks has quit IRC07:41
*** betherly has joined #openstack-ironic07:43
*** aweeks has joined #openstack-ironic07:44
*** zhenguo has joined #openstack-ironic07:45
*** Haomeng has joined #openstack-ironic07:48
*** Haomeng|2 has quit IRC07:50
*** ndipanov has quit IRC07:52
*** Ng has joined #openstack-ironic08:02
openstackgerritGrzegorz Grasza (xek) proposed openstack/ironic: Fix rolling upgrades by implementing indirection_api  https://review.openstack.org/22407908:02
*** derekh has joined #openstack-ironic08:08
*** mgoddard has joined #openstack-ironic08:13
*** romainh has joined #openstack-ironic08:19
openstackgerritAnton Arefiev proposed openstack/ironic: Use oslo_config choices support  https://review.openstack.org/22620108:22
*** ndipanov has joined #openstack-ironic08:26
*** Marga_ has joined #openstack-ironic08:27
*** Marga_ has quit IRC08:28
*** Marga_ has joined #openstack-ironic08:29
*** karimb has joined #openstack-ironic08:29
*** priteau has joined #openstack-ironic08:31
*** lucasagomes has joined #openstack-ironic08:32
*** romainh has quit IRC08:34
*** alexpilotti has joined #openstack-ironic08:36
openstackgerritDmitry Tantsur proposed openstack/ironic-inspector: Stop recommending using DIB from source  https://review.openstack.org/22620308:36
*** vinbs_ has joined #openstack-ironic08:42
*** MattMan has quit IRC08:43
*** vinbs has quit IRC08:44
*** vinbs_ is now known as vinbs08:44
*** MattMan has joined #openstack-ironic08:44
*** romainh has joined #openstack-ironic08:46
*** alexpilotti has quit IRC08:47
openstackgerritMerged stackforge/proliantutils: Fix slow test test_wait_for_ilo_after_reset_ribcl_ok  https://review.openstack.org/22539808:49
*** lucas-dinner has joined #openstack-ironic08:50
openstackgerritRamakrishnan G proposed stackforge/proliantutils: HPSSA: Support 'MAX' as size_gb for logical disks  https://review.openstack.org/22621008:51
openstackgerritHaomeng,Wang proposed openstack/ironic: Validate the input of properties of nodes  https://review.openstack.org/21550508:54
*** xek has joined #openstack-ironic08:54
*** dtantsur is now known as dtantsur|brb08:59
openstackgerritAnton Arefiev proposed openstack/ironic: Use oslo_config choices support  https://review.openstack.org/22620109:03
*** romcheg has joined #openstack-ironic09:04
*** Marga_ has quit IRC09:05
*** pelix has joined #openstack-ironic09:06
*** saripurigopi has joined #openstack-ironic09:12
saripurigopihello Ironic...09:14
*** xek_ has joined #openstack-ironic09:18
*** xek has quit IRC09:21
*** boris-42 has joined #openstack-ironic09:26
*** e0ne has joined #openstack-ironic09:26
vinbsHello Ironic!09:30
vinbsHello saripurigopi09:30
saripurigopivinbs: :)09:30
*** romcheg has quit IRC09:32
openstackgerritMerged openstack/python-ironicclient: Introduce openstackclient plugin  https://review.openstack.org/17167209:36
*** lucas-dinner has quit IRC09:41
*** lucasagomes has quit IRC09:41
*** lucasagomes_ has joined #openstack-ironic09:41
*** lucasagomes_ has quit IRC09:41
*** lucasagomes has joined #openstack-ironic09:41
*** xek_ is now known as xek09:45
*** lucasagomes_ has joined #openstack-ironic09:45
lucasagomes_damn my connection is so **** today09:46
*** zsmithnyc has joined #openstack-ironic09:47
*** dims has joined #openstack-ironic09:47
openstackgerritMerged openstack/ironic: Updated from global requirements  https://review.openstack.org/22461409:49
*** lucasagomes has quit IRC09:52
*** lucasagomes_ is now known as lucasagomes09:52
*** lucasagomes_ has joined #openstack-ironic09:53
*** lucasagomes_ has quit IRC09:53
*** chenglch has quit IRC09:54
*** cppforlife_ has joined #openstack-ironic09:55
*** lekha has joined #openstack-ironic09:55
*** BadCub has joined #openstack-ironic09:56
*** naohirot has quit IRC09:56
*** romcheg has joined #openstack-ironic09:59
*** Haomeng|2 has joined #openstack-ironic10:02
*** Haomeng has quit IRC10:05
saripurigopiHi lucasagomes10:06
openstackgerritRamakrishnan G proposed openstack/python-ironicclient: Add CLI support RAID configuration  https://review.openstack.org/22623410:06
lucasagomessaripurigopi, hi there10:06
saripurigopilucasagomes: :)10:06
*** getvasanth has joined #openstack-ironic10:07
sambettsHey Ironicers o/10:07
saripurigopisambetts: o/10:07
lucasagomessambetts, good morning10:07
* lucasagomes connection seems more stable now10:08
saripurigopilucasagomes: Can you take a look @ https://review.openstack.org/#/c/192142/, https://review.openstack.org/#/c/204733/10:08
*** dtantsur|brb is now known as dtantsur10:08
lucasagomessaripurigopi, ack10:08
saripurigopilucasagomes: thank you10:09
rameshg87lucasagomes: dtantsur: can you please have a look at the exception approved thing - https://review.openstack.org/#/c/224938/10:09
dtantsuryeah, sure10:09
lucasagomesrameshg87, ack 1 sec10:09
*** romainh has left #openstack-ironic10:10
*** rameshg87 is now known as rameshg87-afk10:11
openstackgerritMerged openstack/ironic-inspector: Switch to using CLI for introspection rules  https://review.openstack.org/22549410:12
sambettso/ dtantsur, lucasagomes10:14
dtantsurmorning sambetts!10:14
*** yog_ has joined #openstack-ironic10:14
openstackgerritMerged openstack/ironic-inspector: Ignore IPMI Address for IPMI Bridged nodes  https://review.openstack.org/22412710:18
dtantsurthings keep merging \o/10:18
sambettsdtantsur: \o/ Yup!10:20
dtantsurI think only rootwrap patch is in indefinite state for the release, other things have a chance of landing today10:23
*** e0ne has quit IRC10:30
saripurigopidtantsur: Can you take a look @ https://review.openstack.org/#/c/192142/, https://review.openstack.org/#/c/204733/10:30
dtantsursaripurigopi, I will, but as it's not a priority for 4.2 release, it might take some time, sorry10:31
saripurigopidtantsur: okay, thank you.10:31
*** e0ne has joined #openstack-ironic10:35
*** romcheg has quit IRC10:44
openstackgerritOpenStack Proposal Bot proposed openstack/python-ironicclient: Updated from global requirements  https://review.openstack.org/22624110:44
*** romainh has joined #openstack-ironic10:49
*** trown|outttypeww is now known as trown10:51
*** romcheg has joined #openstack-ironic10:59
*** thrash|g0ne is now known as thrash11:01
*** ukalifon1 has quit IRC11:13
sambettstrown: Do you think that in my convertion patch I should delete ['data'] at all ??11:15
* dtantsur keeps an eye on the conversation11:16
trownsambetts: hmm... I think it probably does not matter either way11:17
*** baoli has joined #openstack-ironic11:17
trownwe have already stored the data to swift at that point, so we have it for debugging11:17
trownand I think we will not rely on anything in the 'data' key after your patch11:17
dtantsurdata is huge, so not duplicating it in the result is definitely nice11:17
trownah, so there is that11:18
sambettsmaybe if we can't convert it then we should just assume rules can't deal with it and remove it?11:18
trown+111:18
sambettsand extra will only get set if data is sucessfull converted11:18
*** baoli_ has joined #openstack-ironic11:19
sambetts?11:19
trownsambetts: I intend to try out the alembic patch today too fyi... I have been a bit bogged down getting inspector working in tripleoci11:19
trownsambetts: ya I like that approach11:19
*** ukalifon1 has joined #openstack-ironic11:19
trownso we know if 'extra' exists it is usable for rules11:19
sambettsok :) I'll go with that11:19
*** rameshg87-afk is now known as rameshg8711:21
* rameshg87 goes home11:21
trownthanks again for working on that, it will make the edeploy stuff much easier to work with11:21
*** rameshg87 has quit IRC11:21
*** baoli has quit IRC11:22
sambetts:D want to make 2.2.0 the best it can be before the summit, It'd be cool to get some validation of the alembic patch, I've tried it out locally and it seems to work as expected, but other people tend to be able to break my code better than I can :-P11:22
*** Haomeng has joined #openstack-ironic11:24
*** Haomeng|2 has quit IRC11:27
*** lucasagomes is now known as lucas-hungry11:34
*** athomas has quit IRC11:35
*** athomas has joined #openstack-ironic11:36
TheJuliaGood morning11:41
sinvalTheJulia: good morning11:42
getvasanthsinval: good morning11:45
sinvalgetvasanth: good morning o/11:45
getvasanthsinval: did u get a chance to read that blog?11:46
getvasanthsinval:http://getvasanth.blogspot.in/11:46
dtantsurmorning TheJulia11:47
sinvalgetvasanth: i read it at the time you sent me, other people here on the lab were interested and it helped a lot, thanks for your work, if you need some help feel free to ping me11:51
getvasanthsinval: thanks a lot for reading it, good to hear it helped others too11:51
getvasanthsinval: i have a question, did you build the image?11:52
sinvalgetvasanth: actually, i didn't tested yet, we are running Ironic liberty and OpenStack liberty right now11:53
sinval getvasanth: we had problems with wholedisk images for iSCSI deployment, but i think it was something with the DIB, and it was solved11:54
getvasanthsinval: how did u solve it?11:55
sinvalgetvasanth: we are running agent and iSCSI deployments and no problem with the images at all11:55
sinvalgetvasanth: i think that was some kind of bug on DIB and guys solved it at the time with a patch, or something like that11:56
sinvalgetvasanth: but it was a while longer...11:56
sinvalgetvasanth: did you tried to ping someone on DIB project?11:57
getvasanthsinval: No11:58
sinvalgetvasanth: would be a good try12:01
*** e0ne has quit IRC12:03
openstackgerritSam Betts proposed openstack/ironic-inspector: Convert eDeploy data so that rules can process it  https://review.openstack.org/22516812:07
*** alexpilotti has joined #openstack-ironic12:09
*** priteau has quit IRC12:15
*** priteau has joined #openstack-ironic12:16
*** Haomeng|2 has joined #openstack-ironic12:20
*** e0ne has joined #openstack-ironic12:23
*** Haomeng has quit IRC12:23
*** bizarrochristy has joined #openstack-ironic12:24
*** lucas-hungry is now known as lucasagomes12:27
*** early has quit IRC12:27
lucasagomessinval, getvasanth TheJulia trown good mroning12:28
sinvallucasagomes: good morning12:28
getvasanthsinval: will try this week12:28
getvasanthlucasagomes: good morning12:28
dtantsurfor anyone interested: I'm writing a functest for DIB ironic-agent element: https://review.openstack.org/#/c/22629312:29
dtantsurlucasagomes, ^^12:29
trownnice12:30
trowngood morning lucasagomes12:30
*** early has joined #openstack-ironic12:31
trowndtantsur: ironic_password is required even when using noauth? ie noauth is just for standalone setup12:34
dtantsurtrown, I think it has a separate setting..12:35
* dtantsur does not remember12:35
trowndtantsur: right there is a separate setting12:35
dtantsuryep, one more auth_strategy12:35
*** nicodemos has joined #openstack-ironic12:36
trownI am just redoing the defaults for the puppet module, and it seems there is no way inspector would work without an Ironic password12:36
trownso I am going to make it required instead of optional ... unlike the keystone stuff where it is optional because of "noauth"12:37
dtantsurweird, I think it was fixed... do you use ironic in noauth mode?12:41
*** achanda has joined #openstack-ironic12:41
*** saripurigopi has quit IRC12:41
*** achanda has quit IRC12:42
*** vinbs has quit IRC12:43
liliarsgetvasanth: hi, I'm from the same team as Sinval and at the top of my head I can remember we had a problem with the wholedisk image because we were building it with the 'baremetal' parameter, when we should be using the 'vm' one12:44
liliarsgetvasanth: bit confusing but I even remember we talked about it here, so it might be a thing for you to try12:45
liliarsand good morning Ironicers (:12:45
*** xek has quit IRC12:46
getvasanthliliars: hi, but in my case even the vm option didnt worked out12:46
liliarsgetvasanth: oh, then which command are you using to create the image?12:46
getvasanthliliars: i am looking for a way to test the image without using it in the glance,12:46
*** xek has joined #openstack-ironic12:47
getvasanthliliars: i got the image from the redhat: overcloud image12:47
trowndtantsur: no I have never tried noauth12:47
getvasanthliliars: i am still trying to figure out the way to build the image :)12:47
dtantsurtrown, than ironic will require a token, even if inspector won't provide it :)12:47
getvasanthliliars: any pointers to test it without using the glance12:48
trowndtantsur: ah... so we would still have that as optional... ok12:48
*** rloo has joined #openstack-ironic12:49
*** boris-42 has quit IRC12:49
liliarsgetvasanth, sorry, can't really help with this approach because I have only used it together with glance, but I can give you some directions to create the image with dib and then uploading it to glance if you want12:50
*** caiobo has joined #openstack-ironic12:50
getvasanthliliars: please share.., I will understand what i am missing12:51
*** romainh has quit IRC12:51
*** saripurigopi has joined #openstack-ironic12:52
*** romainh has joined #openstack-ironic12:54
*** [1]cdearborn has joined #openstack-ironic12:58
*** romainh has quit IRC13:01
*** romainh has joined #openstack-ironic13:04
*** MattMan has quit IRC13:12
*** MattMan has joined #openstack-ironic13:13
*** dims has quit IRC13:14
*** dims has joined #openstack-ironic13:15
*** baoli_ has quit IRC13:16
*** baoli has joined #openstack-ironic13:16
*** baoli_ has joined #openstack-ironic13:21
*** baoli has quit IRC13:24
*** thiagop has joined #openstack-ironic13:28
*** saripurigopi has quit IRC13:28
thiagopgood morning folks13:29
BobBallI've somehow got two hosts set up; one of which reboots because it can get the kernel / initramfs from PXE but the second host does not; PXE fails to get a DHCP address.  Any thoughts?13:30
BobBallMorning thiagop :)13:30
rloohi everyone, thiagop13:31
thiagophello BobBall rloo13:31
rloolucasagomes, dtantsur: if you have time, would be good to get your opinion on my comments in https://review.openstack.org/#/c/224938/13:31
rloolucasagomes, dtantsur: I don't want to hold it up if others are fine with it13:31
openstackgerritSam Betts proposed openstack/ironic-inspector: Convert eDeploy data so that rules can process it  https://review.openstack.org/22516813:32
*** karimb has quit IRC13:32
lucasagomesrloo, will do13:32
* lucasagomes is in a meeting, will take a look asap right after13:32
rloolucasagomes: thx13:33
*** karimb has joined #openstack-ironic13:33
*** rbudden has joined #openstack-ironic13:35
liliarsgetvasanth, ok so I'm assuming step 0, sorry if you already know some of this (: 1. if you don't have diskimage-builder installed then 'pip install diskimage-builder'; now you should be able to create images with it13:36
liliarsgetvasanth, 2. then to create a wholedisk image do 'disk-image-create -o <your-wholedisk-image-name> fedora vm dhcp-all-interfaces'; a .qcow2 image file will be created;13:36
*** e0ne has quit IRC13:37
liliarsgetvasanth, 3. to upload it to glance do 'glance image-create --name <your-glance-image-name> --is-public True --disk-format qcow2 --container-format bare < <your-wholedisk-image-name>.qcow2'13:37
liliarsgetvasanth, these parameters can vary a little (eg. the naming) depending on your glance installation, but that should do it and the image should be listed when doing 'glance image-list'13:37
liliarsgetvasanth, it's pretty simple actually, you might be facing some config issues, I don't know13:38
liliarsgetvasanth, you can try this and ping me if anything, I'll help if I can (:13:38
getvasanthliliars: yes, your right, i am facing some config issues, and how do u create a the ramdisk and kernel13:39
*** e0ne has joined #openstack-ironic13:39
*** e0ne has quit IRC13:39
getvasanthliliars: vm option will create a whole disk image correct?13:40
openstackgerritMerged openstack/python-ironicclient: Updated from global requirements  https://review.openstack.org/22624113:40
*** e0ne has joined #openstack-ironic13:40
liliarsgetvasanth, correct13:41
getvasanthliliars: ok i will try this and get back to you13:41
openstackgerritMerged openstack/ironic-python-agent: Add more info to checksum exception  https://review.openstack.org/21736913:46
liliarsgetvasanth, for deploy images 'ramdisk-image-create fedora deploy-ironic -o <name>', then upload it to glance in the same way just changing the --disk-format depending if it is a kernel or ramdisk image, that should do it13:47
liliarsgetvasanth, also you can use fedora or ubuntu in both commands13:48
liliarsgetvasanth, ok cool, hope it helps (:13:48
getvasanthliliars: thanks, i am building it will ping you back13:48
*** [1]cdearborn has quit IRC13:53
*** amotoki has joined #openstack-ironic13:53
openstackgerritRamakrishnan G proposed openstack/ironic: Add documentation for RAID  https://review.openstack.org/22633013:55
lucasagomesBobBall, are you using neutron as DHCP server?13:55
*** rameshg87 has joined #openstack-ironic13:56
*** romainh has quit IRC13:58
*** karimb has quit IRC14:00
jrollmorning everyone \o14:11
dtantsurmorning jroll!14:11
xekjroll, morning :)14:12
BobBalllucasagomes: I have found the issue... but trying to understand it.  boot.ipxe uses ${mac:hexhyp} to reference the actual pxe config; however we have two MACs.  ${mac} is the MAC of the second NIC, even when ipxe gets a DHCP address on the first NIC.14:12
thiagopmorning jroll14:12
*** early has quit IRC14:12
jrollheya dtantsur, xek, BobBall lucasagomes thiagop rloo anyone else :)14:12
BobBallHowdy :)14:13
rloomorning jroll14:13
dtantsurrloo, morning14:14
rloohi dtantsur14:15
lucasagomesjroll, morning14:15
lucasagomesBobBall, right, yeah this is a known problem. Nova will only pick one mac from the node (at random) and create a network for it14:16
*** olaph has quit IRC14:16
*** [1]cdearborn has joined #openstack-ironic14:16
BobBallI think what we need is undionly set in the DHCP config (a colleague of mine is explaining)14:16
*** early has joined #openstack-ironic14:17
lucasagomesBobBall, yes, we want the DHCP to be configured for all MACs we have present14:19
lucasagomesor be able to indicate which MAC(s) should be used for PXE booting14:19
lucasagomesrameshg87, hi there14:19
rameshg87lucasagomes: hi14:20
lucasagomesrameshg87, do we really expect to create/delete the RAID everytime the node goes to cleaning?14:20
rameshg87lucasagomes: yes, it doesn't harm in anyway14:20
rameshg87lucasagomes: alternately for systems like proliant14:21
BobBallWhen booting are we using Neutron's DHCP server rather ironic-discoverd, right?14:21
dtantsuryep14:21
rameshg87lucasagomes: the tenant who takes the instance may change the raid configuration in-band while the system is active14:21
rameshg87lucasagomes: so it doesn't harm to delete and re-create to make sure the desired disks are always exposed14:21
lucasagomesrameshg87, right14:21
lucasagomesBobBall, correct14:22
lucasagomesrameshg87, so what happens: 1. Node doesn't have a RAID configuration; 2. Tentant creates a RAID; 3. On cleaning target_raid_config nor rand_config is set in the node and it will skip delete raid14:23
lucasagomesrameshg87, the new tentant will have the RAID config from previous tenant, right?14:23
rameshg87lucasagomes: ah yes14:24
BobBalllucasagomes: I think the issue is that we want Neutron's DHCP server to give undionly.kpxe so ipxe doesn't enumerate all of the NICs on the host14:25
lazy_princerameshg87: Hi.. Do you know what version of proliantutils will work with the kilo ironic..?14:26
rameshg87lucasagomes: rloo: so does some other way to "opt-out" help as mentioned in the comment. what do you think about that ?14:26
lucasagomesrameshg87, will check14:26
rameshg87lazy_prince: I think even the latest version will work - 2.1.414:26
jrolllazy_prince: https://github.com/openstack/ironic/blob/stable/kilo/driver-requirements.txt#L814:26
lazy_princerameshg87: Do you know if there is any version that may not work at all...14:27
rloorameshg87: do we need a way to opt-out now, or can we punt that to a future patch?14:27
lucasagomesBobBall, I don't get it. If the ipxe image is not flashed in the NIC, the DHCP server (neutron) will give it14:27
rameshg87rloo: we need to decide now I guess. because the current behaviour might change if/when we decide a way to opt-out14:27
rloorameshg87: what i mean is don't allow opt-out now14:28
*** wshao has joined #openstack-ironic14:28
rloorameshg87: and add in opt-out later14:28
rameshg87lazy_prince: I think below 2.1.x might not work, but need to check14:28
rloorameshg87: it is all or nothing now!14:28
jrolllazy_prince: see my link, it explicitly says >=2.1.014:28
jrolllazy_prince: so those are the "supported" versions whether something lower works or not14:28
lazy_princeaha.. Thanks jroll14:29
jrollnp14:29
BobBallIt is flashed on the NIC.  The problem is that the server has two NICs, both with iPXE images.  When booting off the first NIC, it gets an IP address, but iPXE has also enumerated the second NIC because there are two in the system.  ${mac} correspondes to ${eth1/mac} even when we got a DHCP address for eth0.  My understanding from one of my infrastructure colleagues is that undionly.kpxe is intended to ensure only one of the NICs is e14:29
*** mgoddard has quit IRC14:29
rameshg87rloo: so how do you see this now ?14:29
rloorameshg87: first question. are we OK with how AgentRAID is diff from AgentDeploy wrt getting the clean steps?14:29
*** harshs has joined #openstack-ironic14:29
*** boris-42 has joined #openstack-ironic14:30
*** alexpilotti has quit IRC14:30
*** mgoddard has joined #openstack-ironic14:30
rameshg87rloo: I personally prefer this because it helps to catch a main problem of someone setting node.target_raid_config and agent ramdisk not supporting raid configuration14:30
rloorameshg87: so you think for an operator/user, they can easily understand why they might be different?14:31
rloorameshg87: the behaviour is different for deploy-cleans vs raid-cleans too.14:31
rameshg87rloo: why would operator care about the implementation unless the desired behaviour happens ?14:31
lucasagomesrameshg87, right yeah it really sounds like RAID is a driver capability that should be enabled at the node level14:31
lucasagomes(as you mentioned about driver_info)14:32
rloorameshg87: we have a, or will have an API for the user to get the clean steps. clean steps from the agent are a bit more involved (for deploy).14:32
rloorameshg87: i would have to think about it, but the behaviour is diff wrt the config/priority/ etc.14:32
rloorameshg87: eg, with agentdeploy, you can set the erase-priority to whatever you want. if the agent doesn't support that, we ignore the config.14:33
rameshg87rloo: agent has an implementation in generic hardware manager for that14:33
rloorameshg87: with agentraid, we don't ignore the raid-priority. and it fails if it is enabled but the agent doesn't support it14:33
rameshg87rloo: for erase devices14:33
rameshg87rloo: but for raid, there is no implementation in generic hardware manager14:33
rloorameshg87: how does the operator know about generic hardware manager vs non generic, etc.14:34
rloorameshg87: i'm just saying that the behaviour wrt the 'agent' is different.14:34
rameshg87rloo: they don't know14:34
rameshg87rloo: hmm, I get your point14:34
rloorameshg87: maybe we should change the deploy to be similar to raid then. i don't know.14:34
rameshg87rloo: but isn't someone setting node.target_raid_config and agent ramdisk not supporting it a serious enough issue ?14:34
rameshg87rloo: I feel it can happen14:35
rloorameshg87: i don't think we should be thinking about node.target_raid_config. the issue is inconsistency.14:35
rameshg87rloo: it's bad if we ask them you should have checked the possible clean steps before setting node.target_raid_config14:35
*** romainh has joined #openstack-ironic14:35
rloorameshg87: all (I think) of the clean steps will have a config or something to enable/disable. right now, operators don't know what clean steps are available and they can set those priorities.14:36
rameshg87right14:36
rloorameshg87: so regardless of raid or erase or foo-foo-clean-step, it is the same question. should they check possible clean steps before doing anything.14:36
*** Marga_ has joined #openstack-ironic14:37
rameshg87rloo: and if they do "that something" assuming some clean step existed, should we really bother throwing an error message ?14:37
rameshg87dtantsur: lucasagomes: jroll: thoughts ^^^^14:37
rameshg87rloo: so short answer is today we don't do it14:38
rloorameshg87: we have no idea what the user assumes. do we?14:38
rameshg87rloo: they can provide agent_erase_device_iterations but they have no idea if it got executed with shred14:39
rameshg87rloo: I feel bad about doing the same thing for raid :(14:39
rloorameshg87: so agent_erase_device_iterations is a config, similar to the priorities. which is diff from node.target-raid*. but yeah. they can change that iterations config and it'll have no effect if that clean step doesn't exist.14:40
* lucasagomes reads14:40
rloorameshg87: so if you think that is wrong; that someone changes a config blah blah, then we should fix that.14:41
*** mtanino has joined #openstack-ironic14:41
BobBalllucasagomes: Do you happen to have a link to the Nova multi-nic networking bug you mentioned?14:42
rameshg87rloo: do you think we should spend more time on this ?14:42
rameshg87rloo: and let it wait this time ?14:43
* rameshg87 feels so14:43
lucasagomesBobBall, https://bugs.launchpad.net/nova/+bug/140513114:43
openstackLaunchpad bug 1405131 in OpenStack Compute (nova) "Ports cannot be mapped to networks" [Low,In progress] - Assigned to Mark Goddard (mgoddard)14:43
rloorameshg87: i don't know. if you agree with me then no :-). seriously, i don't want to rush this in. i want to make sure we all understand how the feature will work.14:43
BobBallThanks :)14:43
lucasagomesnp14:44
rloorameshg87: to be in line with existing cleaning, I think: 1. get raid-clean steps similar to AgentDeploy14:44
rloorameshg87: 2. if create-config enabled & agent supports it, if target* not specified, FAIL.14:45
rloorameshg87: no opt out on a per-node basis. (Not yet anyway)14:45
rloorameshg87: did i miss anything?14:45
rameshg87rloo: I don't agree with #2, we should have a mechanism for opt-out.14:46
rameshg87  "opt-out" need not be a missing target_raid_config14:46
lucasagomesmy concern with it is that we have generic drivers for different types of hardware14:46
*** harshs has quit IRC14:47
rloorameshg87: i was just punting on 2 cuz that means a decision has to be made. w/o 2, raid will still work for nodes/agents that support raid.14:47
lucasagomesthe same pxe_ilo that supports RAID for certain models may not support for others14:47
lucasagomeseven tho it's possible to control the power state for both, rameshg87 right?14:47
rloorameshg87, lucasagomes: the work around is to put a different agent ramdisk on those nodes, right?14:47
rameshg87lucasagomes: yeah14:48
lucasagomeshmmmmmmmm14:48
*** x3k has joined #openstack-ironic14:48
rameshg87rloo: that's too much of an ask14:48
rloorameshg87, lucasagomes: i mean if there is no opt out, a different agent that doesn't support raid.14:48
lucasagomesrloo, wouldn't be easy to be able to say "this node supports RAID"14:48
lucasagomesinstead of it? it's much more explicity14:48
lucasagomesit's node capabilities14:48
lucasagomesI know you said about not having per node opt out14:49
lucasagomesbut I actually think that may be the right way of doingit14:49
lucasagomesdoing it*14:49
rloolucasagomes: hmm. yeah, could add it to node capabilities. or properties. or driver info or instance info. (i can't get it straight)14:49
lucasagomesthe operator knows it's hardware, and know which model supports it or not14:49
lucasagomesso he can enable for those14:49
*** mdbooth has quit IRC14:49
lucasagomesand he can see via the API what are the ones that supports it or not14:49
rloolucasagomes: i think it would be good to have node opt out. just didn't want to decide right now. but i'm fine if someone else decides how to opt out. (w/o using node.target-raid-config)14:49
lucasagomesif we leave it for the ramdisk it's very obscure, because all we can see is a UUID14:50
lucasagomesrloo, right yeah without that target_raid_config +114:50
rameshg87rloo: so are you saying we can do this14:50
rameshg87rloo: enable it for now without an opt-out so that people can at least start using it by using different ramdisks14:51
rloorameshg87: i am saying we can do a node opt out, but i am also saying that i didn't know/want to decide *how*. but with lucasagomes's help... :)14:51
rloorameshg87: right, yes, enable it now for all nodes. and add a bug/patch later for opt out per node.14:51
jrollso the proposal is to use RAID, the operator needs to set capabilities/raid = true, and target_raid_config = {...}?14:51
*** tsekiyama has joined #openstack-ironic14:51
rameshg87jroll: ah no14:51
rameshg87jroll: proposal is to switch back to the agentdeploy model of cleaning14:51
*** tsekiyam_ has joined #openstack-ironic14:52
rameshg87jroll: query the ramdisk for the supported raid clean steps14:52
rameshg87jroll: invoke them only if it is supported14:52
lucasagomesto be very honest, I think that we should keep what the spec was intended to do14:52
lucasagomeswhich is add RAID to zapping14:52
lucasagomesI undestand zapping have been postponed, and that's unfortunately14:52
rloorameshg87, jroll: (and if clean-step-priority-config is non-zero)14:52
lucasagomesbut RAID for cleaning brings a whole new level of complexity14:52
jrollhmm14:53
jrolllucasagomes: a zap step is just a manual clean step... if an operator sets a zap step priority to non-zero, it will run during cleaning14:53
lucasagomesjroll, hmm right14:54
rlooI am fine with what rameshg87 said, cuz it is in line with existing AgentDeploy.14:54
lucasagomesjroll, so zap == clean but manual14:54
*** saripurigopi has joined #openstack-ironic14:54
jrolllucasagomes: right, and we're actually planning to re-work zapping so it's just called 'manual cleaning'14:54
openstackgerritAnton Arefiev proposed openstack/ironic: Use oslo_config choices support  https://review.openstack.org/22620114:54
rloolucasagomes: yeah. So one reason why we postponed zap was cuz we'd like it to be called 'clean' cuz it is a manual clean vs an automated clean.14:54
lucasagomesjroll, +1 for that14:54
lucasagomesrloo, perfect, I just understand it now14:55
*** mdbooth has joined #openstack-ironic14:55
rloolucasagomes: and cuz we postponed zap/manual clean, we figured it might not be much work to hook in raid as an automated clean step.14:55
*** tsekiyama has quit IRC14:56
lucasagomesmakes sense14:56
jrollrameshg87: rloo I'm fine with rameshg87's proposal, but what happens if it isn't supported and target_raid_config is set?14:56
rloolucasagomes: but if you think it is more complicated than what rameshg87 and i agreed to?14:56
jroll(that was the original question iirc?)14:56
*** Guest24378 is now known as dansmith14:56
lucasagomesrloo, well, I think it has some flaws in the design14:57
rloojroll: nothing happens. i mean, i don't see that we need to log anything. the operator should be able issue the command-that-doesn't-exist-yet to see the clean steps.14:57
lucasagomesthat can be solved later tho14:57
openstackgerritVladyslav Drok proposed openstack/ironic: Add retries to ssh._get_hosts_name_for_node  https://review.openstack.org/22482814:57
*** getvasanth has quit IRC14:57
jrollrloo: yeah, but for now the reaction is "why the %^&*% doesn't this have raid?!"14:57
jrollrloo: and that's really sad for a stable release :(14:57
rloojroll: that would be a similar question for the erase stuff?14:57
*** mgoddard has quit IRC14:58
jrollrloo: an operator would have to modify the ramdisk heavily for it not to have the erase step14:58
jrolland presumably they would remember that was done14:58
*** mgoddard has joined #openstack-ironic14:59
rloojroll: the point being that w/o knowing more than 'just following the whatever steps to set up/add nodes to ironic', there are things the operator wouldn't know :-(14:59
openstackgerritVladyslav Drok proposed openstack/ironic: Add retries to ssh._get_hosts_name_for_node  https://review.openstack.org/22482814:59
jrollrloo: well, if the operator just followed our deployer's guide, erase_devices will always be there14:59
rloojroll: i don't actually like that we have to ask the agent to give us the clean steps it can support. i guess we can't do that when a node is enrolled.15:00
jrollrloo: as opposed to needing to modify the ramdisk to support raid15:00
xekdansmith, hi :)15:00
dansmithxek: hi15:00
xekdansmith, I made the changes you requested in https://review.openstack.org/#/c/224079/15:00
dansmithxek: cool, looking now15:00
rloojroll: what happens when some other foo-clean-step is added that may require additional info.15:00
lucasagomesnot wanting to defend erase here, but, a detail is that erase is generic where raid is not?15:01
rloolucasagomes: yeah. raid is not generic.15:01
dansmithxek: I still think the title of the commit is wrong, since this does not "fix rolling upgrades" :)15:01
lucasagomes(I also find it odd to get the clean step from the agent, just pointing out)15:01
rloojroll, lucasagomes: if we've architected a framework for people to plug in their own clean steps, then we need to address this I guess.15:01
lucasagomesI think that's because I think about the agent as a dummy thing, we tell it what to do15:01
lucasagomesand it just do what we say15:02
rloothe question being: what happens if a clean step is 'configured', but the clean step isn't performed. how/when do we inform the operator?15:02
lucasagomesand error if it can't do what we ask it to do15:02
jrollrloo: we have architected this15:02
jrollrloo: why wouldn't it be performed?15:02
rameshg87jroll: because it is not supported15:02
xekdansmith, ok, sa maybe just "Implementation of indirection_api"?15:02
jrollthen it should error.15:02
xekdansmith, *so15:03
jrollrloo: for an example of people plugging in their own clean steps :) https://github.com/rackerlabs/onmetal-ironic-hardware-manager/blob/master/onmetal_ironic_hardware_manager/__init__.py#L8315:03
rameshg87jroll: in zapping it makes sense to error and is right approach15:03
rloojroll: your question was: what happens if it isn't supported and target_raid_config is set?15:03
dansmithxek: yeah, let me look at the changes here and then we can just tweak it in gerrit before we approve15:03
rameshg87jroll: but in cleaning the model - execute whatever agent ramdisk supports15:03
xekdansmith, ok15:03
rloojroll: what do you think should happen?15:04
jrollrloo: right, I'm not sure, it's a weird case15:04
dansmithxek: I just noticed your topic=None on the rpcapi methods.. why do you have that?15:04
openstackgerritDmitry Tantsur proposed openstack/ironic-inspector: Support IPA in raid_device plugin  https://review.openstack.org/22565815:05
xekdansmith, all Ironic RPCs have it, I didn't dig deeper...15:05
lazy_princerameshg87: is there a deb package for proliantutils available..?15:05
dansmithxek: well, this isn't going to be called by anything other than the o.vi decorators, so I think it's dead code.. I'll comment15:06
lucasagomesjroll, rloo rameshg87 let's brainstorm one ideal model. The way I would like to see it is to have each clean step as a sort of "plugin"... And a config that would tell: clean_steps=erase,firmware_update,foo,bar15:06
rameshg87lazy_prince: I guess there is one.15:06
rloojroll: 1. do nothing; 2. emit info/warn? during cleaning operation, that <some clean step info> was set but the clean step isn't being done; 3. return fail at the time some clean-step-info is being set, if the clean step isn't going to be done15:06
rameshg87lazy_prince: python-proliantutils is it's name iirc15:06
xekdansmith, you are probably right15:06
lucasagomesthe conductor then can go and execute it in order, if the ramdisk doesn't support it it errors and the node will never ever get to available state in the first place (considering we are coming from enroll)15:06
lucasagomesthat's explicit and that's consistent to me15:07
lucasagomeseasy to extent15:07
jrolllucasagomes: so ironic needs to know about every clean step embedded in the ramdisk?15:07
lucasagomesjroll, yes15:07
lucasagomesbecause the ramdisk only does what we tell it to do15:07
jrolllucasagomes: so if we go back to https://github.com/rackerlabs/onmetal-ironic-hardware-manager/blob/master/onmetal_ironic_hardware_manager/__init__.py#L8315:07
lucasagomesit's dummy and predictable15:07
lucasagomesjroll, the conductor will have a plugin for every step there15:08
jrolllucasagomes: I would just need to set a config clean_steps=remove_bootloader,upgrade_bios,etc15:08
jrolluhhhh15:08
lucasagomesand you make sure the ramdisk supports each one15:08
jrollso now I need to write a plugin on both ends?15:08
lucasagomesor you don't even get it to available15:08
dansmithxek: okay, otherwise looks good15:08
lucasagomesjroll, right, that's consistent right?15:08
dansmithxek: can you make those tweaks real fast? If not, I can do it for you if you prefer15:08
lucasagomesclient <-> sever15:08
lucasagomeswe implement a rpc call you better have it supported on the other side15:09
jrolllucasagomes: sure, but it seems like a lot of duplicate work (and also breaking backwards compat, but let's ignore that for now)15:09
xekdansmith, I started checking when was the topic=None introduced in RPC calls15:09
*** saripurigopi has quit IRC15:09
lucasagomesjroll, the server side is a description (yeah it breaks, it's brainstorm)15:09
jrolllucasagomes: we're basically re-architecting how cleaning works at this point :)15:10
lucasagomesyou don't have to implement the clean step because it runs in-band15:10
lucasagomesjroll, yes I know15:10
lucasagomescause we brought this subject up whent alking about erasing again15:10
rameshg87lucasagomes: the model seems much simpler to me tbh15:10
lucasagomesI'm just trying to think about how we could have better and more consistent way of doing things we do15:10
lucasagomeshaving steps as plugins, where a step has two types: in-band or out-of-band15:11
lucasagomesfor out-of-band it should be implemented in the ramdisk15:11
lucasagomesin-band it's implemented in the plugin15:11
lucasagomessome sort of "remotable or not remotable thing"15:11
*** romcheg has quit IRC15:11
rameshg87lucasagomes: and a mechanism for opt-outs in a generic way as well15:11
lucasagomesthe conductor always dictates what runs and which order it runs15:11
xekdansmith, https://github.com/openstack/ironic/commit/0fc3ad85e90a05322e20f4c2c0fce299d1c352f115:12
rameshg87lucasagomes: in your model it's a CONF option, so it's going to get run for every node15:12
lucasagomesthe client (IPA in this case) just runs what it's been told to run15:12
lucasagomespriorities can be easily defined by the order we list the clean steps (clean_steps=step1,step2,step3)15:12
rameshg87lucasagomes: so perhaps a different way of telling, "hey these clean steps were skipped because of ...."15:12
lucasagomesand so on15:12
*** harshs has joined #openstack-ironic15:12
lucasagomesrameshg87, right15:12
* lucasagomes is just throwing some food for thought here, I know it changes everything!15:13
rameshg87lucasagomes: a return code could do it15:13
jrollxek: dansmith: the caller passes in the topic in (I believe) every case today, and self.topic is the fallback15:13
rameshg87but that needs to be boldly put out by conductor15:13
sambettsmaybe have a per node driver_info option that defines ones to skip ?15:13
dansmithxek: two things: 1. I'm quite sure I don't understand that at all, but 2. You're never passing anything other than None to those calls, so either your code is wrong or you can remove them for now15:14
jrollxek: dansmith: this may be the first instance of a caller not passing a topic... but we do have the fallback which I believe will cause a random conductor node to pick it up15:14
dansmithjroll: unless you're trying to control ownership of a thing, you *want* to just let rabbit round-robin the requests to spread them across conductors, right?15:15
dansmithand this would be an "any free conductors that can do this for me?" sort of thing15:16
xekdansmith, you are right, we don't pass the topic in this instance, so we should remove them, because, as you mentioned, this would be just dead code15:16
dansmithxek: yep15:17
lucasagomesrameshg87, yeah we can think about it, something like sambetts mentioned perhaps... keep in the global config the generic steps for all nodes15:17
lucasagomeskeep in the nodes (driver_info) the node specific ones15:18
jrolldansmith: right, so a conductor manages a set of nodes, determined by a hash ring. most rpc calls act on a node, so they set the topic to the conductor that corresponds to that node15:18
rameshg87yeah15:18
dansmithokay15:18
jrolldansmith: because we have evil state between node and conductor in some cases15:18
dansmithjroll: yeah, our conductors are nameless and stateless15:18
rameshg87jroll: lucasagomes: rloo: so coming back to the original problem15:19
jrolldansmith: right, our 'conductors' are more like compute nodes in that they do the provisioning etc, however when needed we can shuffle things around15:19
dansmithjroll: what is the concurrency model for your conductors? we run at least $ncpus conductor workers on each node15:19
rameshg87jroll: lucasagomes: rloo: so it's too late to decide another mechanism for an opt-out as we discussed15:19
dansmithjroll: which makes them well-suited for a bunch of upgrade-related backport noise, but if yours are single threaded then you're going to have issues asking them to do a lot of this work I think15:20
rameshg87jroll: lucasagomes: rloo: and enable it for now on experimental basis, let them use it without opt-outs now makes sense ?15:20
*** dims has quit IRC15:20
jrolldansmith: any long-ish thing on a conductor spawns a worker to do the thing15:20
jrolldansmith: that's a good point, though, hmm15:20
rameshg87jroll: lucasagomes: rloo: if not, let's try to do it better next time15:20
dansmithjroll: but a greenthread?15:20
rameshg87what do you people say ?15:20
rloorameshg87: that makes sense to me, but it doesn't address jroll's question of user setting target-raid-config and create-raid not being done15:21
lucasagomesrameshg87, right, yeah well I prefer to abstain really15:21
rameshg87rloo: that's why I said experimental basis if it's acceptable :)15:21
lucasagomesI don't think it's a very good design15:21
rloorameshg87: and the big #2. IF we change the cleaning architecture, do we want to do this raid stuff now?15:21
rloolucasagomes: by 'design', you don't mean the RAID stuff but the overall cleaning architecture?15:22
jrolldansmith: 'worker' is a greenthread there, if that's what you're asking... I'm actually not well-informed on our concurrency model outside of grabbing a greenthread from a pool for long tasks15:22
lucasagomesrloo, both... but here talking about the RAID15:22
*** tsekiyam_ has quit IRC15:22
*** lazy_prince has quit IRC15:22
lucasagomesrloo, cause I still don't see a good way we will opt-out in the future15:22
rloolucasagomes: which part of the RAID design bothers you?15:22
lucasagomesthe per-node config imo seems to be very needed for raid15:22
*** tsekiyama has joined #openstack-ironic15:23
dansmithjroll: okay, so anything that blocks the process will make the rest of the conductor go away, which means things like db accesses15:23
rloolucasagomes: i don't see why we can't set some opt-out flag like in the capabilities or driver-info or whatever15:23
dansmithjroll: we run actual process workers of our conductors on each node, with greenthreads inside, so that you don't eliminate the node's ability to handle some db traffic for compute nodes just because it made a db call15:23
lucasagomesrloo, right but that won't be part of that change right?15:23
rloolucasagomes: usually, when one has a global setting, there is a way to turn it off on a per instance basis.15:23
lucasagomesit's a future thing15:23
dansmithjroll: but doing that would be much harder for you to just do, given that your conductors are nameful and stateful15:23
rloolucasagomes: no, i don't think we want it as part of this patch.15:23
jrolldansmith: right, I need to dig some code and see exactly what's going on here, I believe RPCs may be passed off outside of the main thread15:24
rameshg87lucasagomes: right, may be a future thing, not in this release15:24
dansmithjroll: greenthread though, if you're using oslo.messaging15:24
rloolucasagomes: do you think opt-out is necessary for this feature to go out?15:24
lucasagomesrloo, yeah, so see, I don't know who is going to use it as a global thing15:24
jrolldansmith: oh, right, so mysqldb will still block yeah?15:24
dansmithjroll: we get distribution across real processes because we fork early and all the workers are pulling from a single queue15:24
dansmithjroll: correct15:24
lucasagomesrloo, IMHO, I think it's a very necessary thing15:24
rloolucasagomes: it is turned off by default anyway.15:24
rloolucasagomes: oh.15:24
jrolldansmith: side note: we use pymysql downstream :D15:24
*** vdrok has quit IRC15:25
lucasagomesrloo, right, but once you turn it on, do we really expect to all machines using a certain driver to have raid15:25
jroll(that's not a good answer, I know)15:25
*** vdrok has joined #openstack-ironic15:25
* jroll investigates15:25
dansmithjroll: that'll help, but it still limits you to one CPU of work15:25
lucasagomesI don't know. maybe I don't have enough hands-on experience with datacenters here but it seems unrealistic15:25
*** garthb has joined #openstack-ironic15:25
rameshg87lucasagomes: definitely not, considering even this is in-band15:26
lucasagomesrameshg87, rloo I'm OK if it's merged as-is, it's cool but I slight prefer we not too15:26
rloolucasagomes: so 1. we don't provide raid at all so anyone who might want to use it in cleaning for all nodes can not; 2. we provide it with those caveats.15:26
lucasagomesrloo, right, people still can create their cleaning manually and register the nodes in Ironic15:26
*** puranamr has joined #openstack-ironic15:27
lucasagomesI'm afraid of releasing something with a design that actually doesn't match the realities15:27
jrolldansmith: yeah. now that you mention this, I'm worried about landing this a bit. even with multiple workers per conductor it seems like this will/could change our scaling model15:27
*** puranamr has quit IRC15:27
lucasagomesrloo, because really, the "if you enable raid you need to enable for all nodes" seems to be a very small niche15:28
*** e0ne has quit IRC15:28
*** dims has joined #openstack-ironic15:28
lucasagomessomeone with RAID support may have big datacenters15:28
xekjroll, the actual work will be done by Mitaka version of the conductor, until then, we can work something out15:28
*** harshs has quit IRC15:28
dansmithjroll: well, the other way to look at it is, it only affects you if you run multiple versions, which you couldn't do before and can't really do because of other rpc issues, so it could just be an incremental step on which to build15:28
dansmithjroll: but yeah, your call for sure15:28
lucasagomesrloo, I don't have data tho, that's why I prefer to abstain...15:29
dansmithjroll: what xek said is true, the conductor side of this is not actually used in liberty15:29
rloolucasagomes: ok. rameshg87 there you go. it needs a way to opt-out for lucas to ok it.15:29
dansmithjroll: so if your conductors are fixed to handle the load in mitaka, then this is incremental improvement. you always have to land one part of this before you can reap the benefits a cycle later15:29
xekjroll, do you agree that the topic argument can be removed, or should it stay?15:29
jrollxek: dansmith: right, but I'm worried about landing this and then someone forgets to actually fix the load issue :)15:29
*** e0ne has joined #openstack-ironic15:30
lucasagomesrloo, rameshg87 but again, I'm not against merging it as-is. It won't do any harm to me because I know that the current design doesn't solve my problem and I will keep it disabled15:30
dansmithjroll: yep, fair point15:30
jrollxek: dansmith and our goal is to release frequently, so someone may be doing rolling upgrades in a month15:30
dansmithjroll: but again, no load unless a person actually tries to run multiple versions15:30
jrollbasically this blocks a release until the conductor is fixed15:30
lucasagomesrloo, rameshg87 I'm more thinking about someone that finds out like "oh ironic now has RAID support... damn I can't use it because it's not flexible enough even for my pretty standard setup"15:30
*** MattMan has left #openstack-ironic15:30
dansmithjroll: but yeah, if your release model makes this easier to do sooner than 6 mo, waiting for a resolution makes sense15:31
openstackgerritMerged openstack/ironic-inspector: Stop recommending using DIB from source  https://review.openstack.org/22620315:31
dansmithjroll: 6-mo release projects have to be a little proactive about landing things we can leverage the next cycle15:31
*** saripurigopi has joined #openstack-ironic15:31
rloolucasagomes: how do you think we should implement an opt-out?15:31
rameshg87lucasagomes: but this one still has your concerns15:31
*** ifarkas has quit IRC15:31
lucasagomesrameshg87, which one? cause the enable-for-all will not skip stuff will it?15:32
rameshg87lucasagomes: tbh, I don't see how I can solve the problem of delete_* not getting invoked because of empty node.target_raid_config and empty raid_config if someone wants to15:32
jrolldansmith: well, we still have the problem where many people will only run the 6-mo release. in general, I'd like to land this, I'm just a bit worried about a deployment that follows our intermediate releases falling over15:32
jrolldansmith: maybe it's a docs problem, though :)15:32
lucasagomesrameshg87, if delete is enabled always deletes the RAID (independent of what is set in the raid_config fields) >15:33
lucasagomes?*15:33
rameshg87lucasagomes: that needs a better mechanism for opt-out15:33
lucasagomesrloo, thinking...15:33
dansmithjroll: well, like I say, this doesn't actually do anything unless someone tries to run multiple versions at the same time, but your points and concerns are valid, and totally not my call of course :)15:33
jrolldansmith: yeah, totally. going to think on it a bit15:33
dansmithcool15:34
*** rameshg871 has joined #openstack-ironic15:34
rloolucasagomes, rameshg87: we need an opt-out mechanism for opting out of one or more clean steps. so it has to be a list of clean steps.15:34
rameshg871rloo: so do you unless that is solved, this is a bug and needs to be worked out separately ?15:35
* rameshg871 goes quit and is rameshg871 now15:36
rameshg871*got15:36
jrollxek: as far as the topic argument... I'm wondering if there's a case where we'd need it, maybe leave it with a FIXME?15:36
xekjroll, ok15:36
* rameshg871 feels raid is so near but far enough15:36
rloorameshg871: i think that the design for AgentRAID as we discussed is 'sound' based on existing AgentDeploy. Whatever mechanism we use for opt-out, is going to be some flag the user sets on the node, and the additional code, 'if opt-out' don't do ...15:36
rloorameshg871: which is why i'm fine w/o the opt out for now. Adding opt-out won't change the underlying design.15:37
rloorameshg871: but if it isn't going to be usable w/o an opt out, we'll need to come up with an opt out. whether we come up with it this week or next month is another question15:37
*** rameshg87 has quit IRC15:38
rameshg871makes sense, whatever opt out we choose later, would later be just an addon15:38
jrollrloo: rameshg871: lucasagomes: I think this all comes down to one question: what's going to piss off operators/deployers more, not having raid at all or having weird cases where they don't know what's going on and things don't do what they expect? (I tend to think the latter)15:38
rloorameshg871: we just have to decide on how to opt-out. I am leaning towards driver_info cuz clean steps can be avail across interfaces and may not necessarily be due to capabilities of the node.15:38
rloojroll: so we need to re-archtect cleaning then?15:39
*** praneshp has joined #openstack-ironic15:39
jrollrloo: I'm just talking about landing this patch specifically15:40
jrollwe can work out whatever we want to do in M on friday15:40
lucasagomesjroll, I mean people can have RAID, just create it manually. As a developer I'm more interested about the design we have for automating it15:40
lucasagomesis it good enough and flexible so we can extend it later15:40
rloojroll: so what is outstanding? Apart from making it consistent with AgentDeploy. 1. no opt-out; 2. user setting target-config but clean-step not invoked?15:40
lucasagomesdoes it cover the cases for RAID we have in mind even right now?15:40
jrollrloo: though I tend to not like the idea of re-architecting cleaning, just for the sake of we didn't land many features in L, we missed some big ones, and I'd like to land those in M15:41
lucasagomesjroll, I just think that if the answer is "no" or "i don't know" we should think, because getting rid of it later is painful15:41
rloojroll: i don't actually care about how many features we landed or not in L. But I think to move forward, we need to know what the concerns are.15:41
*** e0ne has quit IRC15:41
*** romainh has left #openstack-ironic15:42
jrollrloo: right, and my current concern is that we aren't going to flush out all the cases and fix them the right way15:43
jrolland we're going to have to do repairs in M15:43
rloorameshg871: my thinking given the discussion is that we won't approve that patch for L.15:43
* lucasagomes is not also very much concern if we can realease 10 or 100 features in a release, I think we should think about the quality of it more than quantity15:43
rloorameshg871: but i *would* like it updated to reflect the AgentDeploy method :)15:43
jrollthat's my thought as well15:43
jrolltoo many questions15:43
rloorameshg871: and then we can add comments about what is outstanding15:43
jrolllucasagomes: I mostly agree, I'm more concerned that we missed on networking and RAID which are the two biggest asks from users15:43
rloolucasagomes: I agree that we should think about the quality; I am sorry that we (me) are only thinking it more so close to a release.15:44
lucasagomesjroll, :-( yeah it's very unfortunate15:44
jrolllucasagomes: I want more (happy) users :)15:44
lucasagomesjroll, but again, with the new release model that's not a big deal15:44
lucasagomesthinking within the projects scope15:44
lucasagomesand not the whole openstack umbrealla15:44
jrolllucasagomes: yeah, I'm curious to see how many folks we can get on the intermediate releases15:44
jrolllucasagomes: some people are still only going to run stable, I think. I hope I'm wrong though :)15:44
* rloo still thinks the new release model is a red herring wrt getting features in15:45
lucasagomesrloo, it's all good, we all have to rush some stuff at some point. Just lets make sure the direction is right15:45
*** dtantsur is now known as dtantsur|afk15:45
lucasagomesjroll, yeah, I hope RH will do it15:45
rameshg871rloo: lucasagomes: jroll: so one last word15:45
lucasagomestho I don't foresee it at the present moment15:45
rameshg871rloo: lucasagomes: jroll: I guess it's better if we don't merge that patch in L ?15:46
jrolllucasagomes: if you tell them debian is doing it will it help them get moving on it? :D15:46
lucasagomesrameshg871, in 4.2.015:46
jrollrameshg871: I think so, yes15:46
rameshg871:)15:46
rameshg871then let's don't do it #agreed15:46
lucasagomesjroll, heh I think it's a valid argument, I dunno the weight it will have tho15:46
rloorameshg871: yeah, sorry. I know you worked a lot on the raid etc stuff.15:46
rameshg871we will merge it in 4.3.0 for sure15:46
* rameshg871 hopes so15:47
jrollrameshg871: cool. I also apologize this didn't get in15:47
rameshg871jroll: rloo: np. ultimately ironic first. :)15:47
dtantsur|afkjroll, we even package git master, but it does not mean it will be used...15:47
lucasagomesrameshg871, yeah me too, I'm not against RAID at all, I just think we need to think a bit more about how we do it15:47
rameshg871will come up with a spec on how to enable it for cleaning, let's discuss on spec15:47
lucasagomesand 2 days we have left is not comfortable enough to do it15:47
lucasagomesrameshg871, thanks15:48
rameshg871sure15:48
jrolldtantsur|afk: I'd love to see RDO using the most recent release we do15:48
rloolucasagomes, jroll, rameshg871, dtantsur|afk, everyone else: it would be useful to think about whether any of this could have been avoided at spec time.15:48
jrollrloo: +115:48
rameshg871rloo: I agree it needs to be captured in spec.15:48
rameshg871rloo: it's ideal15:48
dtantsur|afkjroll, I doubt it's possible. RDO packages stable releases. Ironic alone will pull the whole bunch of other dependencies15:49
lucasagomesrloo, yes... I'm partially blamed for it cause I think I can read code better than just ideas15:49
rloorameshg871: but *what* needs to be captured. Seems like sometimes the devil is in the details.15:49
rameshg871rloo: but I don't see something wrong if we find it later and go back and correct it15:49
lucasagomessometimes it clicks when I see what the code does, but the idea I don't get it in time :-(15:49
rameshg871rloo: as long as we do it and don't argue that "spec was submitted this way"15:49
jrolldtantsur|afk: mehhhhh15:49
openstackgerritGrzegorz Grasza (xek) proposed openstack/ironic: Implement indirection_api  https://review.openstack.org/22407915:49
rlooyeah, finding it later and fixing is better than not finding til afterwards, but would be good to see if we can be more effective so we can get more code merged etc.15:50
rameshg871rloo: +115:50
rameshg871and with that I will call it a day15:50
rloothx for staying up so late rameshg871!15:50
lucasagomesrloo, ++15:50
rameshg871good night folks, see you all tomorrow15:50
lucasagomesrameshg871, g'night!15:50
* dtantsur|afk is also really afk now15:51
*** rameshg871 has quit IRC15:51
jrollalright, so we're almost there: https://launchpad.net/ironic/+milestone/4.2.015:51
jrollI just landed the target_raid_config fix15:51
jrollso 4 bugs left (and anything else we pick up)15:51
jrolland would be nice to land the boot interface stuff, if it isn't terribly risky15:51
rloojroll: well, the node.target_raid_config thing isn't needed any more :)15:52
jrollrloo: I mean, it's still part of the API :P15:52
rloojroll: I didn't follow the irc chatter above wrt the rolling-upgrade part; is that something we still want to try to get in?15:53
jrollrloo: I think so, going to read some conductor code and think about it for a moment15:53
jrollmight just need to do some testing though15:53
rloojroll: that seems higher than boot driver interface, but maybe riskier too. i don't know much about that stuff.15:54
jrollrloo: so it isn't risky at all, for this release15:54
rloojroll: oh, that's good to know. 'for this release'!15:54
jrollrloo: it gets risky on the next release when people try to run different version of api and conductor, and the conductor falls over because it can't take the load15:54
rloojroll: vs not getting the code in, and not handling diff versions of api/conductor at all?15:55
*** mgoddard has quit IRC15:56
jrollrloo: right, so for people running stable releases only, if we get this in now, L->M can be a rolling upgrade. if we wait until M to get it in, M->N will be the first rolling upgradeable thing15:56
*** Haomeng|2 has quit IRC15:56
lucasagomesrloo, re https://review.openstack.org/#/c/205895 would be ok if we fix as a following patch?15:57
*** mgoddard has joined #openstack-ironic15:57
rloojroll: so no rolling upgrade, vs rolling upgrade but conductor might fail over...15:57
*** Haomeng|2 has joined #openstack-ironic15:57
rloojroll: so might as well get it in sooner to try it out etc :-)15:57
jrollrloo: right, that's my thought15:57
rloolucasagomes: yeah. that is fixable.15:57
rloolucasagomes: it is straightforward15:57
lucasagomesrloo, ok I will try to bake one quickly and put on top of that so we can get this fix in today15:58
*** yog_ has quit IRC15:58
devanandajroll: imbw, but I thought we already had the capability for rolling upgrades in the object code we had before o.vo15:58
rloolucasagomes: ok. we have 2 days so i'm fine waiting. that one is easy. i need to brace myself to look at the harder patches now :)15:59
jrolldevananda: apparently not - because objects could not be backported across versions etc15:59
*** cdearborn has joined #openstack-ironic15:59
jrolldevananda: I also learned @remotable wasn't actually remoting to conductor :P15:59
devanandaright -- but it would gracefully reject the request, iow, continue operating at the greatest common RPC versoin15:59
devanandaoh, hah15:59
devanandathat's different, but not great15:59
jrolldevananda: right, but if API had node v1.1 and conductor had v1.2, API would get a 1.2 object back and may not be able to make sense of it16:00
*** praneshp has quit IRC16:01
devanandareally?16:01
jrollAIUI, yes16:01
devanandai thought the RPC channel would recognize that one end was asking for 1.1 and send that16:01
jrollbut I could be wrong16:01
jrollI still don't fully grok all of this16:01
*** rbudden has quit IRC16:02
jrolldevananda: so now the question is - if we land this code that enables version backports like that case would need, and someone does a rolling upgrade, could the conductor handle the load from all of these version translations16:02
devanandahuh. well. I have no idea about *that*16:03
devanandahas anyone looked at what sort of load it generates, if any?16:03
jrollright, same, so I'm going to read some code16:03
*** whydidyoustealmy is now known as shakamunyi16:03
devanandak k16:04
jrollI'm not sure.16:04
devanandaI'll poke at the current code to see if you're right16:04
devanandawhat's a good (current) example of an object that would be afected by this?16:04
devanandanode with raid data, probably?16:04
jrollwell, today, none16:04
jrollbecause this is only allowed for RPC version > 1.31 or whatever the new version introduced is16:05
devanandakilo API vs. current conductor16:05
jrollso it would be any object updates after this lands16:05
jrolldevananda: so the thought is, land it now, fix the conductor by next release if there are issues16:06
devanandaheh16:06
jrollbecause this only enables rolling upgrades for release past the release it lands in16:06
jrollso we want to be sure to get this patch in Liberty for the stable-only folks, so Mitaka can be rolling16:06
jrollmake sense?16:06
devanandayup16:07
devanandaas long as it doesn't break Kilo -> Liberty16:07
jrollright16:08
* lucasagomes no idea either...16:10
*** romcheg has joined #openstack-ironic16:10
*** [1]cdearborn has quit IRC16:13
*** Marga_ has quit IRC16:13
*** puranamr has joined #openstack-ironic16:17
openstackgerritLucas Alvares Gomes proposed openstack/ironic: Follow-on to 90a9832131 to fix nits  https://review.openstack.org/22639716:18
lucasagomesrloo, lemme know what you think ^16:18
*** baoli_ has quit IRC16:19
*** albertoffb has joined #openstack-ironic16:21
*** enikanorov_ has quit IRC16:26
*** enikanorov_ has joined #openstack-ironic16:26
*** romcheg has quit IRC16:26
rloolucasagomes: why didn't you just update the original patch?16:29
lucasagomesrloo, I can do that too, squash it... Just wonder whether the author likes it or not (I usually ask first)16:30
lucasagomesmay be a me thing, but if you prefer on the same patch I can squash the commit there16:30
rloolucasagomes: given the amount of changes in the original (not much) I think it should just be done in the same patch16:30
lucasagomesrloo, ack 1 sec16:30
rloolucasagomes: thx. you can apologize and say it was my fault and we wanted to get it in this week :)16:31
*** romcheg has joined #openstack-ironic16:31
lucasagomesrloo, it's all good16:31
*** Marga_ has joined #openstack-ironic16:33
openstackgerritLucas Alvares Gomes proposed openstack/ironic: Make end-points discoverable via Ironic API  https://review.openstack.org/20589516:36
lucasagomesrloo, done16:36
rloolucasagomes: thx.16:37
rloolucasagomes: it closes bug 1311288, right?16:38
openstackbug 1311288 in Ironic "API end-points for changing node states are not discoverable" [Low,In progress] https://launchpad.net/bugs/1311288 - Assigned to Lucas Alvares Gomes (lucasagomes)16:38
lucasagomesrloo, reading16:39
lucasagomesrloo, I bet it does16:39
* lucasagomes updates the commit message16:40
*** athomas has quit IRC16:40
*** romcheg has quit IRC16:40
jrolllol, I was just going to ask the same thing16:40
lucasagomesrloo, or it does talk about having links in the /states to states/power and states/provision ?16:40
lucasagomesnah, I think it does16:40
rloolucasagomes: if you have a minute, could you make a similar change to https://review.openstack.org/#/c/205895/23/ironic/api/controllers/v1/driver.py16:40
lucasagomesok lemme update it16:40
lucasagomesrloo, ack16:41
lucasagomesrloo, to remove the allow_links_node_states_and_driver_properties() ?16:41
rloolucasagomes: oh wait. there is no sample() call that uses conver_with_links. hmm. that is odd.16:41
lucasagomesyeah the driver.py doesn't have a shared method to convert16:41
lucasagomesas we have for nodes.py16:41
lucasagomesodd enough16:41
rloolucasagomes: should be ok then. jenkins will test it.16:41
lucasagomesrloo, yeah I ran it locally seems fine too, but wait for jenkins16:42
lucasagomesI will update the commit message16:42
openstackgerritLucas Alvares Gomes proposed openstack/ironic: Make end-points discoverable via Ironic API  https://review.openstack.org/20589516:42
lucasagomesboom16:42
rloolucasagomes: thx. i think it does fix the bug. if it doesn't someone can open another one :)16:42
lucasagomes++16:42
*** olaph has joined #openstack-ironic16:43
jroll+@16:43
jroll+2 also.16:43
*** jxiaobin has joined #openstack-ironic16:44
lucasagomesta much!16:44
*** harshs has joined #openstack-ironic16:46
*** david-lyle has quit IRC16:46
xekdansmith, jroll, lucasagomes, jenkins finished checking https://review.openstack.org/#/c/224079/16:47
xekafk16:47
*** achanda has joined #openstack-ironic16:47
lucasagomesthanks16:48
jrollstepping away for a bit16:48
*** praneshp has joined #openstack-ironic16:49
*** cdearborn has quit IRC16:50
*** trown is now known as trown|lunch16:51
*** baoli has joined #openstack-ironic16:55
*** romcheg has joined #openstack-ironic16:56
* devananda is testing https://review.openstack.org/#/c/205895/24 16:57
*** Marga_ has quit IRC16:59
*** rbudden has joined #openstack-ironic17:00
*** Marga_ has joined #openstack-ironic17:00
rloothx devananda, since you opened the bug(s) :)17:01
*** Marga_ has quit IRC17:02
devanandayup yup17:02
rloodevananda: oh, i don't think it addresses all of https://bugs.launchpad.net/ironic/+bug/131128817:02
openstackLaunchpad bug 1311288 in Ironic "API end-points for changing node states are not discoverable" [Low,In progress] - Assigned to Anusha (anusha-iiitm)17:02
*** Marga_ has joined #openstack-ironic17:03
devanandarloo: driver/properties is now discoverable in the way I would expect17:04
devanandarloo: but yea, node/NNN/states is still awkward :-/17:05
*** Marga_ has quit IRC17:05
devanandait can be discovered from the base resource now -- so that's much better17:05
rloodevananda: you have too many expectations!17:05
*** Marga_ has joined #openstack-ironic17:06
devanandamaybe so :)17:06
*** derekh has quit IRC17:06
devanandarloo: I think it's good enough17:07
*** davideagnello has quit IRC17:08
devanandaI mean, our API here is a bit rough in general - at least this makes it a little better17:09
*** davideagnello has joined #openstack-ironic17:10
*** penick has joined #openstack-ironic17:10
devanandaGET /node/NNN/states returns, among other things, "target_provision_state" and "provision_state", but I need to POST /node/NNN/states/provision {'target': 'something'}17:10
*** puranamr has quit IRC17:10
lucasagomesdevananda, ++17:11
lucasagomesand folks I will call it a day17:11
lucasagomeshave a great night everyone17:11
thiagopnight lucasagomes17:11
lucasagomessee ya17:11
devanandag'night lucasagomes !17:11
*** lucasagomes is now known as lucas-dinner17:12
*** Sukhdev has joined #openstack-ironic17:17
*** achanda_ has joined #openstack-ironic17:17
*** achanda has quit IRC17:17
*** Marga_ has quit IRC17:20
*** Marga_ has joined #openstack-ironic17:20
*** Marga_ has quit IRC17:21
*** Sukhdev has quit IRC17:21
*** BobBall is now known as BobBall_AWOL17:22
*** baoli has quit IRC17:27
krtaylorjlvillal, I figured out the problem I was seeing running unit tests in an ubuntu VM - conflicting system prereq config from a prior devstack run, sqlite is the default for unit, mysql is the default for devstack17:29
krtaylorvery similar to the problem that gabriel-bezerra was seeing17:30
jlvillalkrtaylor: Thanks for the info. I didn't know about that.17:30
krtaylorjlvillal, I am thinking of adding a line to the dev-quickstart guide17:31
jlvillalkrtaylor: Good idea :)17:31
*** dims has quit IRC17:31
*** puranamr has joined #openstack-ironic17:31
*** dims has joined #openstack-ironic17:32
krtaylorgabriel-bezerra, when you were seeing the sqlite3.OperationalError, was it on a container that had previously run devstack?17:32
*** Marga_ has joined #openstack-ironic17:33
*** puranamr has quit IRC17:33
krtaylorjlvillal, what if we switched unit testing to use mysql? is there a requirement for sqlite for some reason?17:33
*** Marga_ has quit IRC17:34
jlvillalkrtaylor: ugh17:34
krtaylorhehheh17:34
jlvillalkrtaylor: Why do I want to run mysql on my system?17:34
*** Marga_ has joined #openstack-ironic17:34
krtaylorjlvillal, good question, but I thought we were seeing testing problems with it anyway several weeks ago17:35
jlvillalkrtaylor: I don't recall that. There was an unrelated tox issue with python 34 and 27. Said 'db' error. But switching to mysql for Ironic wouldn't change that.17:36
krotscheckDid the members of ironic-webclient-core get flushed? I was under the impression that we'd assigned someone...17:36
jlvillalAlso I think it has been fixed by running the py34 test before py27. Seems to work17:36
krtaylorok, well, the problem goes away if unit test is run on a clean vm/system install, I'll add a line in the dev-quickstart17:36
jlvillalkrtaylor: thanks17:37
*** puranamr has joined #openstack-ironic17:37
openstackgerritKurt Taylor proposed openstack/ironic: Unit test environment setup clarification  https://review.openstack.org/22644517:42
*** [1]cdearborn has joined #openstack-ironic17:43
*** trown|lunch is now known as trown17:52
*** garthb has quit IRC18:02
*** garthb has joined #openstack-ironic18:02
*** penick has quit IRC18:04
openstackgerritJulia Kreger proposed openstack/python-ironicclient: Set a default endpoint value of None  https://review.openstack.org/22647518:08
openstackgerritJuliana Motira proposed stackforge/pyghmi: Fixing set dcmi command  https://review.openstack.org/22647618:09
*** puranamr has quit IRC18:09
*** Sukhdev has joined #openstack-ironic18:12
*** krtaylor has quit IRC18:16
openstackgerritMerged openstack/ironic: Allow unsetting node.target_raid_config  https://review.openstack.org/22614818:19
*** achanda has joined #openstack-ironic18:23
*** achanda_ has quit IRC18:24
*** penick has joined #openstack-ironic18:26
rloojroll, devananda: if either of you have a few minutes to look at the patch for this bug: https://bugs.launchpad.net/ironic/+bug/1488289. The question is whether to add a new config to indicate whether to use standard locale for all commands, or only use standard locale for commands that we think needs it.18:26
openstackLaunchpad bug 1488289 in Ironic "Ironic fails to deploy instance with pxe_ipmitool driver" [High,In progress] - Assigned to Yuiko Takada (takada-yuiko)18:26
jrollrloo: -1 to a config18:28
jrollrloo: I fully support your comment from sept 1518:28
rloojroll: thx, what's your reason?18:28
jrollrloo: because wildly changing the locale for a bunch of stuff will likely break things :)18:29
rloojroll: or not. I just don't know!18:29
rloojroll: ok, please comment. should be an easy fix.18:30
jrollrloo: I think it probably will, we'd at least have to check every execute() call and see if we read stdout18:30
jrollrloo: if it ain't broke... etc18:30
*** krtaylor has joined #openstack-ironic18:30
rloojroll: heh, like i said, i don't know and if no one else knows, we shouldn't do it!18:30
jrollrloo: wdyt about me just updating the patch to move it forward?18:30
rloojroll: nah. she's got 2 days.18:31
rloojroll: she's just waiting for some comments i think, so she knows how to move forward.18:31
jrollrloo: I hope so, she hasn't been in IRC since the 17th18:31
jrolland iirc she usually logs in18:32
rloojroll: oh. well, if she doesn't do anything by tomorrow, then yeah. what is it, a 1-2 line change? we could even fix it on Thursday!18:32
jrollrloo: yeah, indeed18:32
jrollcommented.18:34
rloojroll: thx.18:35
jrollnp18:35
*** Sukhdev has quit IRC18:35
*** garthb has quit IRC18:36
gabriel-bezerrakrtaylor: as far as I recall, we had just the development tools installed from packages18:41
*** achanda has quit IRC18:42
gabriel-bezerrakrtaylor: as one can find here http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html18:42
gabriel-bezerrakrtaylor: I'm just not sure if libmysqlclient-dev installs mysql, for instance.18:43
jrollit does not18:44
jrollI really don't want to run mysql :|18:44
gabriel-bezerrakrtaylor: and the environment I was using was the jenkins-slave docker image, which is based on ubuntu18:46
*** achanda has joined #openstack-ironic18:48
*** Sukhdev has joined #openstack-ironic18:49
*** jcrubio has joined #openstack-ironic18:57
*** albertoffb has quit IRC19:00
*** davhou has joined #openstack-ironic19:05
*** jcrubio has quit IRC19:09
*** Sukhdev has quit IRC19:09
*** e0ne has joined #openstack-ironic19:10
*** Sukhdev has joined #openstack-ironic19:10
*** Sukhdev has quit IRC19:12
*** Sukhdev has joined #openstack-ironic19:12
*** pelix has quit IRC19:17
*** Sukhdev has quit IRC19:18
*** ijw has quit IRC19:19
*** Sukhdev has joined #openstack-ironic19:27
*** puranamr has joined #openstack-ironic19:27
*** puranamr has quit IRC19:28
*** ijw has joined #openstack-ironic19:29
*** wshao has quit IRC19:30
*** saripurigopi has quit IRC19:31
*** ukalifon1 has quit IRC19:31
*** Sukhdev has quit IRC19:35
*** achanda has quit IRC19:37
*** bradjones has joined #openstack-ironic19:46
*** bradjones has quit IRC19:46
*** bradjones has joined #openstack-ironic19:46
*** Sukhdev has joined #openstack-ironic19:49
*** Sukhdev has quit IRC19:50
*** penick has quit IRC19:51
*** penick has joined #openstack-ironic19:57
*** jamielennox|away is now known as jamielennox20:03
*** lucas-dinner has quit IRC20:08
krtaylorgabriel-bezerra, good info, it may be something else then, but there was a conflict somewhere, the unit tests worked on Fedora too20:10
krtayloranyway, it works on a clean install20:10
krtaylorsomething devstack did to the vm conflicted with the venv20:11
*** nicodemos has quit IRC20:15
*** achanda has joined #openstack-ironic20:15
*** lucas-dinner has joined #openstack-ironic20:20
openstackgerritMerged openstack/bifrost: Add warning text to Debian package list  https://review.openstack.org/22412920:24
*** wshao has joined #openstack-ironic20:28
krtaylorrloo, from your comment, do you think it is important for me to list all the conflicts that I find between the devstack and venv environments?20:29
krtaylorI could dig into that more, but not really sure if that scenario even works for other projects20:30
dansmithrloo: replied to some of your questions on that objects patch for clarification20:30
dansmithrloo: also, it's important to note that this really doesn't fix rolling upgrades at all, because there are lots of non-object things to handle yet20:31
dansmithrloo: but it is an incremental step in the right direction20:31
*** wshao has quit IRC20:32
rloodansmith: thx. i think we (someone) needs to know what still needs to be done to get rolling upgrades working. that was the gist of my comment in the commit msg.20:34
*** baoli has joined #openstack-ironic20:35
rlookrtaylor: no, I don't think it is important, but that's kind of a general statement. it made me wonder, like what diffs.20:36
krtaylorrloo, understood, thanks for the review, I'll put it on my todo list20:38
dansmithrloo: yep, likely "lots" from what I've seen looking through things in the last couple weeks20:40
rloodansmith: ohh, we're so bad. Thx for helping us out. We might need more guidance...20:41
dansmithno, not so bad20:41
dansmithlots < tons :)20:41
rloodansmith: we're not so bad then!20:42
*** e0ne has quit IRC20:51
openstackgerritWilliam Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - DB  https://review.openstack.org/20623220:55
*** baoli has quit IRC21:01
*** baoli has joined #openstack-ironic21:02
*** trown is now known as trown|outttypeww21:05
*** priteau has quit IRC21:09
*** baoli has quit IRC21:12
*** baoli has joined #openstack-ironic21:12
openstackgerritWilliam Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - objs  https://review.openstack.org/20623821:14
*** Sukhdev has joined #openstack-ironic21:15
openstackgerritWilliam Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - RPC  https://review.openstack.org/20624321:15
devanandajroll: on string freeze, AIUI, we need a language to hit >= 75% translated before the bot proposes it.21:17
devanandawe have several languages close to 40% .... https://translate.openstack.org/iteration/view/ironic/master/languages ... but nothing close to 75% yet21:18
jrolldevananda: yeah21:18
jrolldevananda: we did get a proposal from zanata but maybe that was the initial import for switching21:18
devanandalast cycle we were very soft on respecting string freeze because it was fairly clear none of the languages were going to get in21:18
devanandai don't have any indication yet for this cycle -- AJeager is the person to sync with, but I don't see him on IRC right now21:19
devanandathat said, I think our process will be different. once we tag 4.2, we string-freeze it anyway (except for critical backports) and master carries on21:19
devanandaya?21:20
*** Marga_ has quit IRC21:21
*** thiagop has quit IRC21:21
*** achanda has quit IRC21:21
jrolldevananda: https://review.openstack.org/#/c/224240/21:21
jrolldevananda: string freeze has changed anyway, the freeze happens at rc1 cut or something?21:22
* jroll digs links21:22
*** Marga__ has joined #openstack-ironic21:22
jrolldevananda: ok, it only applies to release-with-milestones or whatever but https://review.openstack.org/#/c/223011/2/doc/source/release-management.rst21:22
devanandaright21:23
jrollsoft freeze after X-3, hard freeze after rc121:23
devanandaso release-with-milestone will string freeze master for a few weeks21:23
devanandaduring which time they will merge translations and such21:23
devanandawe *wont* freeze master during that time21:23
devanandawhich will mess with all the i18n tooling21:23
jrollno, RC1 is when stable branch is cut21:23
jrollso master never hard freezes21:23
jrollmaybe you mean soft freeze, idk21:23
devanandano, you're right, i'm all confused21:24
devanandaother projects supposedly froze a few weeks ago (while I was on PTO)21:24
jrollyeah, they feature-froze and soft-string-froze21:24
devanandayea, and we didn't21:24
jrollright, something to think about for sure21:25
devanandaanyway, that patch looks like zanata just keeping the translation base files insync with our string changes ... and a change to two translated files that shouldn't be in the repo anyway, because they're too short21:26
devanandabut good to know it's working :)21:26
jrollheh21:27
*** [1]cdearborn has quit IRC21:30
*** caiobo has quit IRC21:31
jrolldevananda: lifeless just made me realize a thing, we should get people to update RELEASE-NOTES or whatever the name is when they propose code21:46
devanandaooh. yah21:46
devanandathe top of that file would then be "## name of next release (IN PROGRESS)" or something21:46
jrolljust gotta make cores aware21:46
jrollyep21:46
jrollalso reminds me we should start making release notes for 4.2, also moving specs to liberty/21:47
devananda++21:47
lifelessdevananda: jroll: the reno proejct handles this21:49
jrolllifeless: yep, I'm aware of the reno stuff, just never occurred to me to update while proposing code :)21:49
lifelessI think you'll enjoy using it much more than rolling our own21:49
jrolllifeless: https://github.com/openstack/ironic/blob/master/RELEASE-NOTES21:49
lifelessjroll: *your*21:49
lifelessjroll: so you don't need that file21:50
jrollwait what21:50
lifelesshttp://git.openstack.org/cgit/openstack/reno/tree/README.rst21:51
jrollok maybe I'm not at all aware of this21:51
lifelessa big file like that will be merge hell; reno is designed to avoid that - see the link to the thread I gave in -meeting21:51
jrolllifeless: ok, what we have is what we were told to do around a month+ ago :(21:53
jrolllifeless: so this is working today and the release team is using it?21:54
*** caiobo has joined #openstack-ironic21:55
lifelessits the thing to use for M21:57
jrolllifeless: also, how do we refactor existing release notes without going back and finding all the change ids?21:57
lifelessit was too tight a deadline to make it be used to do L21:57
lifelessso the change id isn't the key, its now a random uuid21:58
jrolllifeless: so where are docs on how to submit a code change that comes with release notes?21:58
lifelessthe transition will be: - make a entries for your existing things and merge those. Carry on forward.21:58
lifelessjroll: all coming soon :)21:58
*** wshao has joined #openstack-ironic21:58
jrolllifeless: ok, so "reno handles this" isn't true yet :D22:00
jrollso devananda and I should still make release notes22:01
*** baoli has quit IRC22:01
*** baoli has joined #openstack-ironic22:01
jrollthank you for tolerating my questions, btw22:01
*** baoli has quit IRC22:02
*** wshao has quit IRC22:04
*** baoli has joined #openstack-ironic22:04
lifelessjroll: its usable, its just not documented ;)22:04
jrollheh22:05
*** cppforlife_ has quit IRC22:07
*** jerrygb has joined #openstack-ironic22:08
*** BadCub has quit IRC22:08
*** ndipanov has quit IRC22:08
*** davidlenwell has quit IRC22:08
*** cppforlife_ has joined #openstack-ironic22:08
mrdaMorning22:08
*** ndipanov has joined #openstack-ironic22:09
*** davidlenwell has joined #openstack-ironic22:09
*** BadCub has joined #openstack-ironic22:10
jroll\o mrda22:10
mrdao/22:10
*** garthb has joined #openstack-ironic22:11
*** wshao has joined #openstack-ironic22:11
*** garthb has quit IRC22:11
*** garthb has joined #openstack-ironic22:12
openstackgerritWilliam Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - RPC  https://review.openstack.org/20624322:12
openstackgerritWilliam Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - API  https://review.openstack.org/20624422:12
openstackgerritWilliam Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - DB  https://review.openstack.org/20623222:12
openstackgerritWilliam Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - objs  https://review.openstack.org/20623822:12
*** zhenguo has quit IRC22:12
openstackgerritWilliam Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - net  https://review.openstack.org/20624522:12
*** zhenguo has joined #openstack-ironic22:13
*** yuriyz has quit IRC22:15
*** yuriyz has joined #openstack-ironic22:15
*** baoli has quit IRC22:18
*** baoli has joined #openstack-ironic22:20
*** penick has quit IRC22:21
*** boris-42 has quit IRC22:22
* mrda wonders whether the ironic reviewdashboard should have the other ironic projects in it: i.e. ironic-lib, ironic-inspector, ironic-webclient, bifrost (or some subset)22:22
*** achanda has joined #openstack-ironic22:22
jrollmrda: ++22:23
jrollI have a todo list item to totally revamp that dashboard22:23
jrollbut I wouldn't mind if someone else did it :D22:23
*** gridinv has quit IRC22:24
*** boris-42 has joined #openstack-ironic22:24
mrdajroll: I'm happy to fork that and add in new projects.  I'm not sure what else you'd want though.22:24
jrollmrda: I don't know yet either :)22:24
jrollthat was the main point, probably with sections for each project22:24
*** gridinv has joined #openstack-ironic22:25
*** ndipanov has quit IRC22:26
mrdaok22:26
*** puranamr has joined #openstack-ironic22:26
mrdaMaybe not everyon thinks they have the expertise to review webclient stuff for example22:27
*** ndipanov has joined #openstack-ironic22:27
*** achanda has quit IRC22:27
jrollyeah, exactly22:29
*** puranamr has quit IRC22:29
*** rbudden has quit IRC22:30
*** [1]cdearborn has joined #openstack-ironic22:31
*** romcheg has quit IRC22:34
*** Sukhdev has quit IRC22:36
*** romcheg has joined #openstack-ironic22:44
mrdajroll: did you want pyghmi included?22:46
jrollmrda: I don't personally care, I'm not sure if any cores would find that valuable22:47
*** baoli has quit IRC22:47
mrdaok22:47
jrollmrda: I suddenly wonder if that project would accept jroll.dash :D22:47
mrdajroll: of course, but the project is more than cores y'know ;)22:48
jrolltotes22:48
jrolljust more curious than anything :)22:49
mrdaSo there's a limit on the No Negative Feedback, With Negative Feedback, and Work In Progress Or Unverified. Should we have one of specs since there are so many?22:52
jrolllike, another section like that for specs?22:53
jrollidk22:53
mrdaI guess I'll put it up for review and see if people here like it22:53
*** Sukhdev has joined #openstack-ironic22:54
*** Sukhdev has quit IRC22:54
*** wshao has quit IRC22:56
devanandarandom rant: we shouldn't be returning the entire contents of the configdrive from "GET /v1/nodes/NNN"23:05
devanandathis is annoying when looking at gate logs :(23:05
jrolltry looking at it while debugging production build failures23:06
jrollI thought we fixed that btw23:06
devanandait's all over the logs for https://review.openstack.org/#/c/205895/24 's failure23:08
devanandaso apparently we didn't23:08
jrollmaybe just ironic's logs and not the api23:09
devanandaahh that's probably it23:09
*** achanda has joined #openstack-ironic23:12
*** dims has quit IRC23:18
mrdaI've just pushed a new review up for the ironic review dashboard (https://review.openstack.org/226592) that adds in all the ironic projects.  Just FYI.23:25
mrda(jlvillal: I did see your other patch for doing this dynamically, but while that's sorting itself out i figured I should push this one up anyway until the more complex and dynamic solution is ready)23:26
jlvillalmrda: Yeah, I have had that patch drop to the bottom of my TODO list.23:26
jlvillalmrda: Well at least below the line of things I need to work on now.23:27
jlvillalmrda: If you wanted to run with that patch, feel free :)23:27
mrdajlvillal: if it's below the line, you know it's up for elimination :)23:27
*** Sukhdev has joined #openstack-ironic23:28
*** Sukhdev has quit IRC23:32
*** Sukhdev has joined #openstack-ironic23:33
*** romcheg has quit IRC23:45
*** dims has joined #openstack-ironic23:54
*** dims has quit IRC23:55
*** Guest18166 has joined #openstack-ironic23:55
rloojroll, devananda: wrt completed features, the generic RAID interface: https://blueprints.launchpad.net/ironic/+spec/ironic-generic-raid-interface23:56
rloojroll, devananda: the client part isn't done yet, and whatever documentation23:56
rloojroll, devananda: do we care if they are done for Thurs?23:56
rloojroll, devananda: looks like these are the two patches: https://review.openstack.org/#/c/226234/, https://review.openstack.org/#/c/226330/ both WIP23:58

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