*** Sukhdev has joined #openstack-ironic | 00:00 | |
krotscheck | How does the python-ironic client do integration testing? | 00:02 |
---|---|---|
krotscheck | In the gate? | 00:02 |
*** achanda has quit IRC | 00:03 | |
krotscheck | I'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 IRC | 00:04 | |
*** naohirot has joined #openstack-ironic | 00:04 | |
*** Sukhdev has quit IRC | 00:10 | |
Haomeng | krotscheck: hi, welcome | 00:15 |
Haomeng | krotscheck: we have https://github.com/openstack/python-ironicclient project, which as the test code for client call | 00:16 |
krotscheck | Haomeng: Neat. Where's the devtack configuration for the gate? | 00:20 |
*** shadower has quit IRC | 00:23 | |
*** shadower has joined #openstack-ironic | 00:23 | |
*** keekz has quit IRC | 00:24 | |
*** garthb has quit IRC | 00:25 | |
*** keekz has joined #openstack-ironic | 00:25 | |
Haomeng | krotscheck: devtack configuration? | 00:30 |
Haomeng | krotscheck: you mean devstack gate? | 00:31 |
jroll | devananda: yes, I left it on the list as only irmc/ilo is left, and if they land that's totally awesome. everything else is updated | 00:36 |
jroll | devananda: (you're probably asking that because cisco thing, which was +A'd this morning) | 00:37 |
*** ijw has quit IRC | 00:39 | |
*** dims_ has quit IRC | 00:42 | |
*** harshs has quit IRC | 00:53 | |
*** harshs has joined #openstack-ironic | 00:53 | |
*** Haomeng|2 has joined #openstack-ironic | 01:02 | |
*** sdake_ has joined #openstack-ironic | 01:04 | |
*** Haomeng has quit IRC | 01:06 | |
*** sdake has quit IRC | 01:06 | |
*** sdake_ has quit IRC | 01:07 | |
*** sdake has joined #openstack-ironic | 01:07 | |
openstackgerrit | Naohiro Tamura proposed openstack/ironic: Refactor IRMCVirtualMediaIscsiDeploy by applying new BootInterface https://review.openstack.org/221371 | 01:16 |
openstackgerrit | Naohiro Tamura proposed openstack/ironic: Refactor IRMCVirtualMediaAgentDeploy by applying new BootInterface https://review.openstack.org/221577 | 01:18 |
*** ijw has joined #openstack-ironic | 01:20 | |
*** ijw has quit IRC | 01:21 | |
*** ijw has joined #openstack-ironic | 01:22 | |
*** dims has joined #openstack-ironic | 01:26 | |
jroll | krotscheck: https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L3385 | 01:29 |
jroll | krotscheck: which maps to https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/ironic.yaml#L38 | 01:29 |
*** priteau has joined #openstack-ironic | 01:32 | |
*** priteau has quit IRC | 01:37 | |
*** chenglch has joined #openstack-ironic | 01:38 | |
*** ukalifon1 has joined #openstack-ironic | 01:44 | |
*** ukalifon1 has quit IRC | 02:25 | |
openstackgerrit | Merged openstack/ironic: Add Cisco IMC PXE Driver https://review.openstack.org/219253 | 02:27 |
openstackgerrit | Merged openstack/ironic: Clean up CIMC driver docs and comments https://review.openstack.org/225958 | 02:28 |
openstackgerrit | Merged openstack/ironic: Allow abort for CLEANWAIT states https://review.openstack.org/201552 | 02:29 |
*** achanda has joined #openstack-ironic | 02:33 | |
*** dims has quit IRC | 02:33 | |
*** sdake has quit IRC | 02:39 | |
*** david-ly_ has joined #openstack-ironic | 02:39 | |
*** david-lyle has quit IRC | 02:40 | |
*** harshs has quit IRC | 02:40 | |
*** dhellmann has quit IRC | 02:40 | |
*** dhellmann has joined #openstack-ironic | 02:41 | |
*** dansmith has quit IRC | 02:41 | |
*** dansmith has joined #openstack-ironic | 02:42 | |
*** dansmith is now known as Guest24378 | 02:42 | |
devananda | yay merges! | 02:48 |
jroll | \o/ | 02:49 |
*** naohirot has quit IRC | 03:02 | |
*** saripurigopi has joined #openstack-ironic | 03:03 | |
*** rloo has quit IRC | 03:05 | |
openstackgerrit | Ramakrishnan G proposed openstack/ironic: Agent Inband RAID configuration available in cleaning https://review.openstack.org/224938 | 03:07 |
*** david-ly_ is now known as david-lyle | 03:17 | |
*** ramineni1 has joined #openstack-ironic | 03:24 | |
openstackgerrit | Ramakrishnan G proposed openstack/ironic: Allow unsetting node.target_raid_config https://review.openstack.org/226148 | 03:24 |
*** ramineni_ has joined #openstack-ironic | 03:26 | |
*** ramineni1 has quit IRC | 03:28 | |
*** Marga__ has joined #openstack-ironic | 03:31 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/ironic: Updated from global requirements https://review.openstack.org/224614 | 03:33 |
*** dims has joined #openstack-ironic | 03:34 | |
*** Marga_ has quit IRC | 03:34 | |
*** Marga__ has quit IRC | 03:35 | |
*** naohirot has joined #openstack-ironic | 04:00 | |
*** lazy_prince has joined #openstack-ironic | 04:01 | |
*** harshs has joined #openstack-ironic | 04:08 | |
*** dims has quit IRC | 04:09 | |
*** garthb has joined #openstack-ironic | 04:10 | |
*** ramineni_ has left #openstack-ironic | 04:31 | |
*** harshs has quit IRC | 04:36 | |
*** rameshg87 has joined #openstack-ironic | 04:43 | |
*** ukalifon1 has joined #openstack-ironic | 04:46 | |
*** Marga_ has joined #openstack-ironic | 04:47 | |
*** Marga_ has quit IRC | 04:49 | |
*** Marga_ has joined #openstack-ironic | 04:49 | |
*** Marga_ has quit IRC | 05:05 | |
*** saripurigopi has quit IRC | 05:19 | |
openstackgerrit | Anusha Ramineni proposed openstack/ironic: Make end-points discoverable via Ironic API https://review.openstack.org/205895 | 05:33 |
openstackgerrit | Naohiro Tamura proposed openstack/ironic: Add hardware inspection module for iRMC driver https://review.openstack.org/196480 | 05:35 |
openstackgerrit | Anusha Ramineni proposed openstack/ironic: Make end-points discoverable via Ironic API https://review.openstack.org/205895 | 05:36 |
*** garthb has quit IRC | 05:48 | |
*** garthb has joined #openstack-ironic | 05:49 | |
*** Sukhdev has joined #openstack-ironic | 05:49 | |
*** garthb has quit IRC | 05:55 | |
*** Sukhdev has quit IRC | 06:17 | |
*** rbudden has joined #openstack-ironic | 06:35 | |
*** vinbs has joined #openstack-ironic | 06:52 | |
*** david-lyle has quit IRC | 06:58 | |
*** david-lyle has joined #openstack-ironic | 07:14 | |
*** jamielennox is now known as jamielennox|away | 07:15 | |
*** dtantsur|afk is now known as dtantsur | 07:16 | |
dtantsur | Morning Ironic | 07:16 |
*** achanda has quit IRC | 07:17 | |
*** ifarkas has joined #openstack-ironic | 07:24 | |
*** praneshp has quit IRC | 07:31 | |
*** betherly has quit IRC | 07:41 | |
*** zsmithnyc has quit IRC | 07:41 | |
*** zhenguo has quit IRC | 07:41 | |
*** Ng has quit IRC | 07:41 | |
*** boris-42 has quit IRC | 07:41 | |
*** cppforlife_ has quit IRC | 07:41 | |
*** BadCub has quit IRC | 07:41 | |
*** lekha has quit IRC | 07:41 | |
*** aweeks has quit IRC | 07:41 | |
*** betherly has joined #openstack-ironic | 07:43 | |
*** aweeks has joined #openstack-ironic | 07:44 | |
*** zhenguo has joined #openstack-ironic | 07:45 | |
*** Haomeng has joined #openstack-ironic | 07:48 | |
*** Haomeng|2 has quit IRC | 07:50 | |
*** ndipanov has quit IRC | 07:52 | |
*** Ng has joined #openstack-ironic | 08:02 | |
openstackgerrit | Grzegorz Grasza (xek) proposed openstack/ironic: Fix rolling upgrades by implementing indirection_api https://review.openstack.org/224079 | 08:02 |
*** derekh has joined #openstack-ironic | 08:08 | |
*** mgoddard has joined #openstack-ironic | 08:13 | |
*** romainh has joined #openstack-ironic | 08:19 | |
openstackgerrit | Anton Arefiev proposed openstack/ironic: Use oslo_config choices support https://review.openstack.org/226201 | 08:22 |
*** ndipanov has joined #openstack-ironic | 08:26 | |
*** Marga_ has joined #openstack-ironic | 08:27 | |
*** Marga_ has quit IRC | 08:28 | |
*** Marga_ has joined #openstack-ironic | 08:29 | |
*** karimb has joined #openstack-ironic | 08:29 | |
*** priteau has joined #openstack-ironic | 08:31 | |
*** lucasagomes has joined #openstack-ironic | 08:32 | |
*** romainh has quit IRC | 08:34 | |
*** alexpilotti has joined #openstack-ironic | 08:36 | |
openstackgerrit | Dmitry Tantsur proposed openstack/ironic-inspector: Stop recommending using DIB from source https://review.openstack.org/226203 | 08:36 |
*** vinbs_ has joined #openstack-ironic | 08:42 | |
*** MattMan has quit IRC | 08:43 | |
*** vinbs has quit IRC | 08:44 | |
*** vinbs_ is now known as vinbs | 08:44 | |
*** MattMan has joined #openstack-ironic | 08:44 | |
*** romainh has joined #openstack-ironic | 08:46 | |
*** alexpilotti has quit IRC | 08:47 | |
openstackgerrit | Merged stackforge/proliantutils: Fix slow test test_wait_for_ilo_after_reset_ribcl_ok https://review.openstack.org/225398 | 08:49 |
*** lucas-dinner has joined #openstack-ironic | 08:50 | |
openstackgerrit | Ramakrishnan G proposed stackforge/proliantutils: HPSSA: Support 'MAX' as size_gb for logical disks https://review.openstack.org/226210 | 08:51 |
openstackgerrit | Haomeng,Wang proposed openstack/ironic: Validate the input of properties of nodes https://review.openstack.org/215505 | 08:54 |
*** xek has joined #openstack-ironic | 08:54 | |
*** dtantsur is now known as dtantsur|brb | 08:59 | |
openstackgerrit | Anton Arefiev proposed openstack/ironic: Use oslo_config choices support https://review.openstack.org/226201 | 09:03 |
*** romcheg has joined #openstack-ironic | 09:04 | |
*** Marga_ has quit IRC | 09:05 | |
*** pelix has joined #openstack-ironic | 09:06 | |
*** saripurigopi has joined #openstack-ironic | 09:12 | |
saripurigopi | hello Ironic... | 09:14 |
*** xek_ has joined #openstack-ironic | 09:18 | |
*** xek has quit IRC | 09:21 | |
*** boris-42 has joined #openstack-ironic | 09:26 | |
*** e0ne has joined #openstack-ironic | 09:26 | |
vinbs | Hello Ironic! | 09:30 |
vinbs | Hello saripurigopi | 09:30 |
saripurigopi | vinbs: :) | 09:30 |
*** romcheg has quit IRC | 09:32 | |
openstackgerrit | Merged openstack/python-ironicclient: Introduce openstackclient plugin https://review.openstack.org/171672 | 09:36 |
*** lucas-dinner has quit IRC | 09:41 | |
*** lucasagomes has quit IRC | 09:41 | |
*** lucasagomes_ has joined #openstack-ironic | 09:41 | |
*** lucasagomes_ has quit IRC | 09:41 | |
*** lucasagomes has joined #openstack-ironic | 09:41 | |
*** xek_ is now known as xek | 09:45 | |
*** lucasagomes_ has joined #openstack-ironic | 09:45 | |
lucasagomes_ | damn my connection is so **** today | 09:46 |
*** zsmithnyc has joined #openstack-ironic | 09:47 | |
*** dims has joined #openstack-ironic | 09:47 | |
openstackgerrit | Merged openstack/ironic: Updated from global requirements https://review.openstack.org/224614 | 09:49 |
*** lucasagomes has quit IRC | 09:52 | |
*** lucasagomes_ is now known as lucasagomes | 09:52 | |
*** lucasagomes_ has joined #openstack-ironic | 09:53 | |
*** lucasagomes_ has quit IRC | 09:53 | |
*** chenglch has quit IRC | 09:54 | |
*** cppforlife_ has joined #openstack-ironic | 09:55 | |
*** lekha has joined #openstack-ironic | 09:55 | |
*** BadCub has joined #openstack-ironic | 09:56 | |
*** naohirot has quit IRC | 09:56 | |
*** romcheg has joined #openstack-ironic | 09:59 | |
*** Haomeng|2 has joined #openstack-ironic | 10:02 | |
*** Haomeng has quit IRC | 10:05 | |
saripurigopi | Hi lucasagomes | 10:06 |
openstackgerrit | Ramakrishnan G proposed openstack/python-ironicclient: Add CLI support RAID configuration https://review.openstack.org/226234 | 10:06 |
lucasagomes | saripurigopi, hi there | 10:06 |
saripurigopi | lucasagomes: :) | 10:06 |
*** getvasanth has joined #openstack-ironic | 10:07 | |
sambetts | Hey Ironicers o/ | 10:07 |
saripurigopi | sambetts: o/ | 10:07 |
lucasagomes | sambetts, good morning | 10:07 |
* lucasagomes connection seems more stable now | 10:08 | |
saripurigopi | lucasagomes: 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 dtantsur | 10:08 | |
lucasagomes | saripurigopi, ack | 10:08 |
saripurigopi | lucasagomes: thank you | 10:09 |
rameshg87 | lucasagomes: dtantsur: can you please have a look at the exception approved thing - https://review.openstack.org/#/c/224938/ | 10:09 |
dtantsur | yeah, sure | 10:09 |
lucasagomes | rameshg87, ack 1 sec | 10:09 |
*** romainh has left #openstack-ironic | 10:10 | |
*** rameshg87 is now known as rameshg87-afk | 10:11 | |
openstackgerrit | Merged openstack/ironic-inspector: Switch to using CLI for introspection rules https://review.openstack.org/225494 | 10:12 |
sambetts | o/ dtantsur, lucasagomes | 10:14 |
dtantsur | morning sambetts! | 10:14 |
*** yog_ has joined #openstack-ironic | 10:14 | |
openstackgerrit | Merged openstack/ironic-inspector: Ignore IPMI Address for IPMI Bridged nodes https://review.openstack.org/224127 | 10:18 |
dtantsur | things keep merging \o/ | 10:18 |
sambetts | dtantsur: \o/ Yup! | 10:20 |
dtantsur | I think only rootwrap patch is in indefinite state for the release, other things have a chance of landing today | 10:23 |
*** e0ne has quit IRC | 10:30 | |
saripurigopi | dtantsur: Can you take a look @ https://review.openstack.org/#/c/192142/, https://review.openstack.org/#/c/204733/ | 10:30 |
dtantsur | saripurigopi, I will, but as it's not a priority for 4.2 release, it might take some time, sorry | 10:31 |
saripurigopi | dtantsur: okay, thank you. | 10:31 |
*** e0ne has joined #openstack-ironic | 10:35 | |
*** romcheg has quit IRC | 10:44 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/python-ironicclient: Updated from global requirements https://review.openstack.org/226241 | 10:44 |
*** romainh has joined #openstack-ironic | 10:49 | |
*** trown|outttypeww is now known as trown | 10:51 | |
*** romcheg has joined #openstack-ironic | 10:59 | |
*** thrash|g0ne is now known as thrash | 11:01 | |
*** ukalifon1 has quit IRC | 11:13 | |
sambetts | trown: Do you think that in my convertion patch I should delete ['data'] at all ?? | 11:15 |
* dtantsur keeps an eye on the conversation | 11:16 | |
trown | sambetts: hmm... I think it probably does not matter either way | 11:17 |
*** baoli has joined #openstack-ironic | 11:17 | |
trown | we have already stored the data to swift at that point, so we have it for debugging | 11:17 |
trown | and I think we will not rely on anything in the 'data' key after your patch | 11:17 |
dtantsur | data is huge, so not duplicating it in the result is definitely nice | 11:17 |
trown | ah, so there is that | 11:18 |
sambetts | maybe if we can't convert it then we should just assume rules can't deal with it and remove it? | 11:18 |
trown | +1 | 11:18 |
sambetts | and extra will only get set if data is sucessfull converted | 11:18 |
*** baoli_ has joined #openstack-ironic | 11:19 | |
sambetts | ? | 11:19 |
trown | sambetts: I intend to try out the alembic patch today too fyi... I have been a bit bogged down getting inspector working in tripleoci | 11:19 |
trown | sambetts: ya I like that approach | 11:19 |
*** ukalifon1 has joined #openstack-ironic | 11:19 | |
trown | so we know if 'extra' exists it is usable for rules | 11:19 |
sambetts | ok :) I'll go with that | 11:19 |
*** rameshg87-afk is now known as rameshg87 | 11:21 | |
* rameshg87 goes home | 11:21 | |
trown | thanks again for working on that, it will make the edeploy stuff much easier to work with | 11:21 |
*** rameshg87 has quit IRC | 11:21 | |
*** baoli has quit IRC | 11: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 :-P | 11:22 |
*** Haomeng has joined #openstack-ironic | 11:24 | |
*** Haomeng|2 has quit IRC | 11:27 | |
*** lucasagomes is now known as lucas-hungry | 11:34 | |
*** athomas has quit IRC | 11:35 | |
*** athomas has joined #openstack-ironic | 11:36 | |
TheJulia | Good morning | 11:41 |
sinval | TheJulia: good morning | 11:42 |
getvasanth | sinval: good morning | 11:45 |
sinval | getvasanth: good morning o/ | 11:45 |
getvasanth | sinval: did u get a chance to read that blog? | 11:46 |
getvasanth | sinval:http://getvasanth.blogspot.in/ | 11:46 |
dtantsur | morning TheJulia | 11:47 |
sinval | getvasanth: 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 me | 11:51 |
getvasanth | sinval: thanks a lot for reading it, good to hear it helped others too | 11:51 |
getvasanth | sinval: i have a question, did you build the image? | 11:52 |
sinval | getvasanth: actually, i didn't tested yet, we are running Ironic liberty and OpenStack liberty right now | 11:53 |
sinval | getvasanth: we had problems with wholedisk images for iSCSI deployment, but i think it was something with the DIB, and it was solved | 11:54 |
getvasanth | sinval: how did u solve it? | 11:55 |
sinval | getvasanth: we are running agent and iSCSI deployments and no problem with the images at all | 11:55 |
sinval | getvasanth: i think that was some kind of bug on DIB and guys solved it at the time with a patch, or something like that | 11:56 |
sinval | getvasanth: but it was a while longer... | 11:56 |
sinval | getvasanth: did you tried to ping someone on DIB project? | 11:57 |
getvasanth | sinval: No | 11:58 |
sinval | getvasanth: would be a good try | 12:01 |
*** e0ne has quit IRC | 12:03 | |
openstackgerrit | Sam Betts proposed openstack/ironic-inspector: Convert eDeploy data so that rules can process it https://review.openstack.org/225168 | 12:07 |
*** alexpilotti has joined #openstack-ironic | 12:09 | |
*** priteau has quit IRC | 12:15 | |
*** priteau has joined #openstack-ironic | 12:16 | |
*** Haomeng|2 has joined #openstack-ironic | 12:20 | |
*** e0ne has joined #openstack-ironic | 12:23 | |
*** Haomeng has quit IRC | 12:23 | |
*** bizarrochristy has joined #openstack-ironic | 12:24 | |
*** lucas-hungry is now known as lucasagomes | 12:27 | |
*** early has quit IRC | 12:27 | |
lucasagomes | sinval, getvasanth TheJulia trown good mroning | 12:28 |
sinval | lucasagomes: good morning | 12:28 |
getvasanth | sinval: will try this week | 12:28 |
getvasanth | lucasagomes: good morning | 12:28 |
dtantsur | for anyone interested: I'm writing a functest for DIB ironic-agent element: https://review.openstack.org/#/c/226293 | 12:29 |
dtantsur | lucasagomes, ^^ | 12:29 |
trown | nice | 12:30 |
trown | good morning lucasagomes | 12:30 |
*** early has joined #openstack-ironic | 12:31 | |
trown | dtantsur: ironic_password is required even when using noauth? ie noauth is just for standalone setup | 12:34 |
dtantsur | trown, I think it has a separate setting.. | 12:35 |
* dtantsur does not remember | 12:35 | |
trown | dtantsur: right there is a separate setting | 12:35 |
dtantsur | yep, one more auth_strategy | 12:35 |
*** nicodemos has joined #openstack-ironic | 12:36 | |
trown | I am just redoing the defaults for the puppet module, and it seems there is no way inspector would work without an Ironic password | 12:36 |
trown | so I am going to make it required instead of optional ... unlike the keystone stuff where it is optional because of "noauth" | 12:37 |
dtantsur | weird, I think it was fixed... do you use ironic in noauth mode? | 12:41 |
*** achanda has joined #openstack-ironic | 12:41 | |
*** saripurigopi has quit IRC | 12:41 | |
*** achanda has quit IRC | 12:42 | |
*** vinbs has quit IRC | 12:43 | |
liliars | getvasanth: 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' one | 12:44 |
liliars | getvasanth: bit confusing but I even remember we talked about it here, so it might be a thing for you to try | 12:45 |
liliars | and good morning Ironicers (: | 12:45 |
*** xek has quit IRC | 12:46 | |
getvasanth | liliars: hi, but in my case even the vm option didnt worked out | 12:46 |
liliars | getvasanth: oh, then which command are you using to create the image? | 12:46 |
getvasanth | liliars: i am looking for a way to test the image without using it in the glance, | 12:46 |
*** xek has joined #openstack-ironic | 12:47 | |
getvasanth | liliars: i got the image from the redhat: overcloud image | 12:47 |
trown | dtantsur: no I have never tried noauth | 12:47 |
getvasanth | liliars: i am still trying to figure out the way to build the image :) | 12:47 |
dtantsur | trown, than ironic will require a token, even if inspector won't provide it :) | 12:47 |
getvasanth | liliars: any pointers to test it without using the glance | 12:48 |
trown | dtantsur: ah... so we would still have that as optional... ok | 12:48 |
*** rloo has joined #openstack-ironic | 12:49 | |
*** boris-42 has quit IRC | 12:49 | |
liliars | getvasanth, 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 want | 12:50 |
*** caiobo has joined #openstack-ironic | 12:50 | |
getvasanth | liliars: please share.., I will understand what i am missing | 12:51 |
*** romainh has quit IRC | 12:51 | |
*** saripurigopi has joined #openstack-ironic | 12:52 | |
*** romainh has joined #openstack-ironic | 12:54 | |
*** [1]cdearborn has joined #openstack-ironic | 12:58 | |
*** romainh has quit IRC | 13:01 | |
*** romainh has joined #openstack-ironic | 13:04 | |
*** MattMan has quit IRC | 13:12 | |
*** MattMan has joined #openstack-ironic | 13:13 | |
*** dims has quit IRC | 13:14 | |
*** dims has joined #openstack-ironic | 13:15 | |
*** baoli_ has quit IRC | 13:16 | |
*** baoli has joined #openstack-ironic | 13:16 | |
*** baoli_ has joined #openstack-ironic | 13:21 | |
*** baoli has quit IRC | 13:24 | |
*** thiagop has joined #openstack-ironic | 13:28 | |
*** saripurigopi has quit IRC | 13:28 | |
thiagop | good morning folks | 13:29 |
BobBall | I'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 |
BobBall | Morning thiagop :) | 13:30 |
rloo | hi everyone, thiagop | 13:31 |
thiagop | hello BobBall rloo | 13:31 |
rloo | lucasagomes, dtantsur: if you have time, would be good to get your opinion on my comments in https://review.openstack.org/#/c/224938/ | 13:31 |
rloo | lucasagomes, dtantsur: I don't want to hold it up if others are fine with it | 13:31 |
openstackgerrit | Sam Betts proposed openstack/ironic-inspector: Convert eDeploy data so that rules can process it https://review.openstack.org/225168 | 13:32 |
*** karimb has quit IRC | 13:32 | |
lucasagomes | rloo, will do | 13:32 |
* lucasagomes is in a meeting, will take a look asap right after | 13:32 | |
rloo | lucasagomes: thx | 13:33 |
*** karimb has joined #openstack-ironic | 13:33 | |
*** rbudden has joined #openstack-ironic | 13:35 | |
liliars | getvasanth, 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 it | 13:36 |
liliars | getvasanth, 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 IRC | 13:37 | |
liliars | getvasanth, 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 |
liliars | getvasanth, 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 |
liliars | getvasanth, it's pretty simple actually, you might be facing some config issues, I don't know | 13:38 |
liliars | getvasanth, you can try this and ping me if anything, I'll help if I can (: | 13:38 |
getvasanth | liliars: yes, your right, i am facing some config issues, and how do u create a the ramdisk and kernel | 13:39 |
*** e0ne has joined #openstack-ironic | 13:39 | |
*** e0ne has quit IRC | 13:39 | |
getvasanth | liliars: vm option will create a whole disk image correct? | 13:40 |
openstackgerrit | Merged openstack/python-ironicclient: Updated from global requirements https://review.openstack.org/226241 | 13:40 |
*** e0ne has joined #openstack-ironic | 13:40 | |
liliars | getvasanth, correct | 13:41 |
getvasanth | liliars: ok i will try this and get back to you | 13:41 |
openstackgerrit | Merged openstack/ironic-python-agent: Add more info to checksum exception https://review.openstack.org/217369 | 13:46 |
liliars | getvasanth, 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 it | 13:47 |
liliars | getvasanth, also you can use fedora or ubuntu in both commands | 13:48 |
liliars | getvasanth, ok cool, hope it helps (: | 13:48 |
getvasanth | liliars: thanks, i am building it will ping you back | 13:48 |
*** [1]cdearborn has quit IRC | 13:53 | |
*** amotoki has joined #openstack-ironic | 13:53 | |
openstackgerrit | Ramakrishnan G proposed openstack/ironic: Add documentation for RAID https://review.openstack.org/226330 | 13:55 |
lucasagomes | BobBall, are you using neutron as DHCP server? | 13:55 |
*** rameshg87 has joined #openstack-ironic | 13:56 | |
*** romainh has quit IRC | 13:58 | |
*** karimb has quit IRC | 14:00 | |
jroll | morning everyone \o | 14:11 |
dtantsur | morning jroll! | 14:11 |
xek | jroll, morning :) | 14:12 |
BobBall | lucasagomes: 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 |
thiagop | morning jroll | 14:12 |
*** early has quit IRC | 14:12 | |
jroll | heya dtantsur, xek, BobBall lucasagomes thiagop rloo anyone else :) | 14:12 |
BobBall | Howdy :) | 14:13 |
rloo | morning jroll | 14:13 |
dtantsur | rloo, morning | 14:14 |
rloo | hi dtantsur | 14:15 |
lucasagomes | jroll, morning | 14:15 |
lucasagomes | BobBall, right, yeah this is a known problem. Nova will only pick one mac from the node (at random) and create a network for it | 14:16 |
*** olaph has quit IRC | 14:16 | |
*** [1]cdearborn has joined #openstack-ironic | 14:16 | |
BobBall | I think what we need is undionly set in the DHCP config (a colleague of mine is explaining) | 14:16 |
*** early has joined #openstack-ironic | 14:17 | |
lucasagomes | BobBall, yes, we want the DHCP to be configured for all MACs we have present | 14:19 |
lucasagomes | or be able to indicate which MAC(s) should be used for PXE booting | 14:19 |
lucasagomes | rameshg87, hi there | 14:19 |
rameshg87 | lucasagomes: hi | 14:20 |
lucasagomes | rameshg87, do we really expect to create/delete the RAID everytime the node goes to cleaning? | 14:20 |
rameshg87 | lucasagomes: yes, it doesn't harm in anyway | 14:20 |
rameshg87 | lucasagomes: alternately for systems like proliant | 14:21 |
BobBall | When booting are we using Neutron's DHCP server rather ironic-discoverd, right? | 14:21 |
dtantsur | yep | 14:21 |
rameshg87 | lucasagomes: the tenant who takes the instance may change the raid configuration in-band while the system is active | 14:21 |
rameshg87 | lucasagomes: so it doesn't harm to delete and re-create to make sure the desired disks are always exposed | 14:21 |
lucasagomes | rameshg87, right | 14:21 |
lucasagomes | BobBall, correct | 14:22 |
lucasagomes | rameshg87, 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 raid | 14:23 |
lucasagomes | rameshg87, the new tentant will have the RAID config from previous tenant, right? | 14:23 |
rameshg87 | lucasagomes: ah yes | 14:24 |
BobBall | lucasagomes: 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 host | 14:25 |
lazy_prince | rameshg87: Hi.. Do you know what version of proliantutils will work with the kilo ironic..? | 14:26 |
rameshg87 | lucasagomes: rloo: so does some other way to "opt-out" help as mentioned in the comment. what do you think about that ? | 14:26 |
lucasagomes | rameshg87, will check | 14:26 |
rameshg87 | lazy_prince: I think even the latest version will work - 2.1.4 | 14:26 |
jroll | lazy_prince: https://github.com/openstack/ironic/blob/stable/kilo/driver-requirements.txt#L8 | 14:26 |
lazy_prince | rameshg87: Do you know if there is any version that may not work at all... | 14:27 |
rloo | rameshg87: do we need a way to opt-out now, or can we punt that to a future patch? | 14:27 |
lucasagomes | BobBall, I don't get it. If the ipxe image is not flashed in the NIC, the DHCP server (neutron) will give it | 14:27 |
rameshg87 | rloo: we need to decide now I guess. because the current behaviour might change if/when we decide a way to opt-out | 14:27 |
rloo | rameshg87: what i mean is don't allow opt-out now | 14:28 |
*** wshao has joined #openstack-ironic | 14:28 | |
rloo | rameshg87: and add in opt-out later | 14:28 |
rameshg87 | lazy_prince: I think below 2.1.x might not work, but need to check | 14:28 |
rloo | rameshg87: it is all or nothing now! | 14:28 |
jroll | lazy_prince: see my link, it explicitly says >=2.1.0 | 14:28 |
jroll | lazy_prince: so those are the "supported" versions whether something lower works or not | 14:28 |
lazy_prince | aha.. Thanks jroll | 14:29 |
jroll | np | 14:29 |
BobBall | It 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 e | 14:29 |
*** mgoddard has quit IRC | 14:29 | |
rameshg87 | rloo: so how do you see this now ? | 14:29 |
rloo | rameshg87: first question. are we OK with how AgentRAID is diff from AgentDeploy wrt getting the clean steps? | 14:29 |
*** harshs has joined #openstack-ironic | 14:29 | |
*** boris-42 has joined #openstack-ironic | 14:30 | |
*** alexpilotti has quit IRC | 14:30 | |
*** mgoddard has joined #openstack-ironic | 14:30 | |
rameshg87 | rloo: 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 configuration | 14:30 |
rloo | rameshg87: so you think for an operator/user, they can easily understand why they might be different? | 14:31 |
rloo | rameshg87: the behaviour is different for deploy-cleans vs raid-cleans too. | 14:31 |
rameshg87 | rloo: why would operator care about the implementation unless the desired behaviour happens ? | 14:31 |
lucasagomes | rameshg87, right yeah it really sounds like RAID is a driver capability that should be enabled at the node level | 14:31 |
lucasagomes | (as you mentioned about driver_info) | 14:32 |
rloo | rameshg87: 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 |
rloo | rameshg87: i would have to think about it, but the behaviour is diff wrt the config/priority/ etc. | 14:32 |
rloo | rameshg87: 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 |
rameshg87 | rloo: agent has an implementation in generic hardware manager for that | 14:33 |
rloo | rameshg87: with agentraid, we don't ignore the raid-priority. and it fails if it is enabled but the agent doesn't support it | 14:33 |
rameshg87 | rloo: for erase devices | 14:33 |
rameshg87 | rloo: but for raid, there is no implementation in generic hardware manager | 14:33 |
rloo | rameshg87: how does the operator know about generic hardware manager vs non generic, etc. | 14:34 |
rloo | rameshg87: i'm just saying that the behaviour wrt the 'agent' is different. | 14:34 |
rameshg87 | rloo: they don't know | 14:34 |
rameshg87 | rloo: hmm, I get your point | 14:34 |
rloo | rameshg87: maybe we should change the deploy to be similar to raid then. i don't know. | 14:34 |
rameshg87 | rloo: but isn't someone setting node.target_raid_config and agent ramdisk not supporting it a serious enough issue ? | 14:34 |
rameshg87 | rloo: I feel it can happen | 14:35 |
rloo | rameshg87: i don't think we should be thinking about node.target_raid_config. the issue is inconsistency. | 14:35 |
rameshg87 | rloo: it's bad if we ask them you should have checked the possible clean steps before setting node.target_raid_config | 14:35 |
*** romainh has joined #openstack-ironic | 14:35 | |
rloo | rameshg87: 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 |
rameshg87 | right | 14:36 |
rloo | rameshg87: 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-ironic | 14:37 | |
rameshg87 | rloo: and if they do "that something" assuming some clean step existed, should we really bother throwing an error message ? | 14:37 |
rameshg87 | dtantsur: lucasagomes: jroll: thoughts ^^^^ | 14:37 |
rameshg87 | rloo: so short answer is today we don't do it | 14:38 |
rloo | rameshg87: we have no idea what the user assumes. do we? | 14:38 |
rameshg87 | rloo: they can provide agent_erase_device_iterations but they have no idea if it got executed with shred | 14:39 |
rameshg87 | rloo: I feel bad about doing the same thing for raid :( | 14:39 |
rloo | rameshg87: 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 reads | 14:40 | |
rloo | rameshg87: 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-ironic | 14:41 | |
BobBall | lucasagomes: Do you happen to have a link to the Nova multi-nic networking bug you mentioned? | 14:42 |
rameshg87 | rloo: do you think we should spend more time on this ? | 14:42 |
rameshg87 | rloo: and let it wait this time ? | 14:43 |
* rameshg87 feels so | 14:43 | |
lucasagomes | BobBall, https://bugs.launchpad.net/nova/+bug/1405131 | 14:43 |
openstack | Launchpad bug 1405131 in OpenStack Compute (nova) "Ports cannot be mapped to networks" [Low,In progress] - Assigned to Mark Goddard (mgoddard) | 14:43 |
rloo | rameshg87: 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 |
BobBall | Thanks :) | 14:43 |
lucasagomes | np | 14:44 |
rloo | rameshg87: to be in line with existing cleaning, I think: 1. get raid-clean steps similar to AgentDeploy | 14:44 |
rloo | rameshg87: 2. if create-config enabled & agent supports it, if target* not specified, FAIL. | 14:45 |
rloo | rameshg87: no opt out on a per-node basis. (Not yet anyway) | 14:45 |
rloo | rameshg87: did i miss anything? | 14:45 |
rameshg87 | rloo: 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_config | 14:46 |
lucasagomes | my concern with it is that we have generic drivers for different types of hardware | 14:46 |
*** harshs has quit IRC | 14:47 | |
rloo | rameshg87: 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 |
lucasagomes | the same pxe_ilo that supports RAID for certain models may not support for others | 14:47 |
lucasagomes | even tho it's possible to control the power state for both, rameshg87 right? | 14:47 |
rloo | rameshg87, lucasagomes: the work around is to put a different agent ramdisk on those nodes, right? | 14:47 |
rameshg87 | lucasagomes: yeah | 14:48 |
lucasagomes | hmmmmmmmm | 14:48 |
*** x3k has joined #openstack-ironic | 14:48 | |
rameshg87 | rloo: that's too much of an ask | 14:48 |
rloo | rameshg87, lucasagomes: i mean if there is no opt out, a different agent that doesn't support raid. | 14:48 |
lucasagomes | rloo, wouldn't be easy to be able to say "this node supports RAID" | 14:48 |
lucasagomes | instead of it? it's much more explicity | 14:48 |
lucasagomes | it's node capabilities | 14:48 |
lucasagomes | I know you said about not having per node opt out | 14:49 |
lucasagomes | but I actually think that may be the right way of doingit | 14:49 |
lucasagomes | doing it* | 14:49 |
rloo | lucasagomes: hmm. yeah, could add it to node capabilities. or properties. or driver info or instance info. (i can't get it straight) | 14:49 |
lucasagomes | the operator knows it's hardware, and know which model supports it or not | 14:49 |
lucasagomes | so he can enable for those | 14:49 |
*** mdbooth has quit IRC | 14:49 | |
lucasagomes | and he can see via the API what are the ones that supports it or not | 14:49 |
rloo | lucasagomes: 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 |
lucasagomes | if we leave it for the ramdisk it's very obscure, because all we can see is a UUID | 14:50 |
lucasagomes | rloo, right yeah without that target_raid_config +1 | 14:50 |
rameshg87 | rloo: so are you saying we can do this | 14:50 |
rameshg87 | rloo: enable it for now without an opt-out so that people can at least start using it by using different ramdisks | 14:51 |
rloo | rameshg87: 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 |
rloo | rameshg87: right, yes, enable it now for all nodes. and add a bug/patch later for opt out per node. | 14:51 |
jroll | so the proposal is to use RAID, the operator needs to set capabilities/raid = true, and target_raid_config = {...}? | 14:51 |
*** tsekiyama has joined #openstack-ironic | 14:51 | |
rameshg87 | jroll: ah no | 14:51 |
rameshg87 | jroll: proposal is to switch back to the agentdeploy model of cleaning | 14:51 |
*** tsekiyam_ has joined #openstack-ironic | 14:52 | |
rameshg87 | jroll: query the ramdisk for the supported raid clean steps | 14:52 |
rameshg87 | jroll: invoke them only if it is supported | 14:52 |
lucasagomes | to be very honest, I think that we should keep what the spec was intended to do | 14:52 |
lucasagomes | which is add RAID to zapping | 14:52 |
lucasagomes | I undestand zapping have been postponed, and that's unfortunately | 14:52 |
rloo | rameshg87, jroll: (and if clean-step-priority-config is non-zero) | 14:52 |
lucasagomes | but RAID for cleaning brings a whole new level of complexity | 14:52 |
jroll | hmm | 14:53 |
jroll | lucasagomes: a zap step is just a manual clean step... if an operator sets a zap step priority to non-zero, it will run during cleaning | 14:53 |
lucasagomes | jroll, hmm right | 14:54 |
rloo | I am fine with what rameshg87 said, cuz it is in line with existing AgentDeploy. | 14:54 |
lucasagomes | jroll, so zap == clean but manual | 14:54 |
*** saripurigopi has joined #openstack-ironic | 14:54 | |
jroll | lucasagomes: right, and we're actually planning to re-work zapping so it's just called 'manual cleaning' | 14:54 |
openstackgerrit | Anton Arefiev proposed openstack/ironic: Use oslo_config choices support https://review.openstack.org/226201 | 14:54 |
rloo | lucasagomes: 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 |
lucasagomes | jroll, +1 for that | 14:54 |
lucasagomes | rloo, perfect, I just understand it now | 14:55 |
*** mdbooth has joined #openstack-ironic | 14:55 | |
rloo | lucasagomes: 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 IRC | 14:56 | |
lucasagomes | makes sense | 14:56 |
jroll | rameshg87: rloo I'm fine with rameshg87's proposal, but what happens if it isn't supported and target_raid_config is set? | 14:56 |
rloo | lucasagomes: 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 dansmith | 14:56 | |
lucasagomes | rloo, well, I think it has some flaws in the design | 14:57 |
rloo | jroll: 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 |
lucasagomes | that can be solved later tho | 14:57 |
openstackgerrit | Vladyslav Drok proposed openstack/ironic: Add retries to ssh._get_hosts_name_for_node https://review.openstack.org/224828 | 14:57 |
*** getvasanth has quit IRC | 14:57 | |
jroll | rloo: yeah, but for now the reaction is "why the %^&*% doesn't this have raid?!" | 14:57 |
jroll | rloo: and that's really sad for a stable release :( | 14:57 |
rloo | jroll: that would be a similar question for the erase stuff? | 14:57 |
*** mgoddard has quit IRC | 14:58 | |
jroll | rloo: an operator would have to modify the ramdisk heavily for it not to have the erase step | 14:58 |
jroll | and presumably they would remember that was done | 14:58 |
*** mgoddard has joined #openstack-ironic | 14:59 | |
rloo | jroll: 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 |
openstackgerrit | Vladyslav Drok proposed openstack/ironic: Add retries to ssh._get_hosts_name_for_node https://review.openstack.org/224828 | 14:59 |
jroll | rloo: well, if the operator just followed our deployer's guide, erase_devices will always be there | 14:59 |
rloo | jroll: 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 |
jroll | rloo: as opposed to needing to modify the ramdisk to support raid | 15:00 |
xek | dansmith, hi :) | 15:00 |
dansmith | xek: hi | 15:00 |
xek | dansmith, I made the changes you requested in https://review.openstack.org/#/c/224079/ | 15:00 |
dansmith | xek: cool, looking now | 15:00 |
rloo | jroll: what happens when some other foo-clean-step is added that may require additional info. | 15:00 |
lucasagomes | not wanting to defend erase here, but, a detail is that erase is generic where raid is not? | 15:01 |
rloo | lucasagomes: yeah. raid is not generic. | 15:01 |
dansmith | xek: 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 |
rloo | jroll, 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 |
lucasagomes | I think that's because I think about the agent as a dummy thing, we tell it what to do | 15:01 |
lucasagomes | and it just do what we say | 15:02 |
rloo | the 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 |
lucasagomes | and error if it can't do what we ask it to do | 15:02 |
jroll | rloo: we have architected this | 15:02 |
jroll | rloo: why wouldn't it be performed? | 15:02 |
rameshg87 | jroll: because it is not supported | 15:02 |
xek | dansmith, ok, sa maybe just "Implementation of indirection_api"? | 15:02 |
jroll | then it should error. | 15:02 |
xek | dansmith, *so | 15:03 |
jroll | rloo: 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#L83 | 15:03 |
rameshg87 | jroll: in zapping it makes sense to error and is right approach | 15:03 |
rloo | jroll: your question was: what happens if it isn't supported and target_raid_config is set? | 15:03 |
dansmith | xek: yeah, let me look at the changes here and then we can just tweak it in gerrit before we approve | 15:03 |
rameshg87 | jroll: but in cleaning the model - execute whatever agent ramdisk supports | 15:03 |
xek | dansmith, ok | 15:03 |
rloo | jroll: what do you think should happen? | 15:04 |
jroll | rloo: right, I'm not sure, it's a weird case | 15:04 |
dansmith | xek: I just noticed your topic=None on the rpcapi methods.. why do you have that? | 15:04 |
openstackgerrit | Dmitry Tantsur proposed openstack/ironic-inspector: Support IPA in raid_device plugin https://review.openstack.org/225658 | 15:05 |
xek | dansmith, all Ironic RPCs have it, I didn't dig deeper... | 15:05 |
lazy_prince | rameshg87: is there a deb package for proliantutils available..? | 15:05 |
dansmith | xek: 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 comment | 15:06 |
lucasagomes | jroll, 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,bar | 15:06 |
rameshg87 | lazy_prince: I guess there is one. | 15:06 |
rloo | jroll: 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 done | 15:06 |
rameshg87 | lazy_prince: python-proliantutils is it's name iirc | 15:06 |
xek | dansmith, you are probably right | 15:06 |
lucasagomes | the 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 |
lucasagomes | that's explicit and that's consistent to me | 15:07 |
lucasagomes | easy to extent | 15:07 |
jroll | lucasagomes: so ironic needs to know about every clean step embedded in the ramdisk? | 15:07 |
lucasagomes | jroll, yes | 15:07 |
lucasagomes | because the ramdisk only does what we tell it to do | 15:07 |
jroll | lucasagomes: so if we go back to https://github.com/rackerlabs/onmetal-ironic-hardware-manager/blob/master/onmetal_ironic_hardware_manager/__init__.py#L83 | 15:07 |
lucasagomes | it's dummy and predictable | 15:07 |
lucasagomes | jroll, the conductor will have a plugin for every step there | 15:08 |
jroll | lucasagomes: I would just need to set a config clean_steps=remove_bootloader,upgrade_bios,etc | 15:08 |
jroll | uhhhh | 15:08 |
lucasagomes | and you make sure the ramdisk supports each one | 15:08 |
jroll | so now I need to write a plugin on both ends? | 15:08 |
lucasagomes | or you don't even get it to available | 15:08 |
dansmith | xek: okay, otherwise looks good | 15:08 |
lucasagomes | jroll, right, that's consistent right? | 15:08 |
dansmith | xek: can you make those tweaks real fast? If not, I can do it for you if you prefer | 15:08 |
lucasagomes | client <-> sever | 15:08 |
lucasagomes | we implement a rpc call you better have it supported on the other side | 15:09 |
jroll | lucasagomes: sure, but it seems like a lot of duplicate work (and also breaking backwards compat, but let's ignore that for now) | 15:09 |
xek | dansmith, I started checking when was the topic=None introduced in RPC calls | 15:09 |
*** saripurigopi has quit IRC | 15:09 | |
lucasagomes | jroll, the server side is a description (yeah it breaks, it's brainstorm) | 15:09 |
jroll | lucasagomes: we're basically re-architecting how cleaning works at this point :) | 15:10 |
lucasagomes | you don't have to implement the clean step because it runs in-band | 15:10 |
lucasagomes | jroll, yes I know | 15:10 |
lucasagomes | cause we brought this subject up whent alking about erasing again | 15:10 |
rameshg87 | lucasagomes: the model seems much simpler to me tbh | 15:10 |
lucasagomes | I'm just trying to think about how we could have better and more consistent way of doing things we do | 15:10 |
lucasagomes | having steps as plugins, where a step has two types: in-band or out-of-band | 15:11 |
lucasagomes | for out-of-band it should be implemented in the ramdisk | 15:11 |
lucasagomes | in-band it's implemented in the plugin | 15:11 |
lucasagomes | some sort of "remotable or not remotable thing" | 15:11 |
*** romcheg has quit IRC | 15:11 | |
rameshg87 | lucasagomes: and a mechanism for opt-outs in a generic way as well | 15:11 |
lucasagomes | the conductor always dictates what runs and which order it runs | 15:11 |
xek | dansmith, https://github.com/openstack/ironic/commit/0fc3ad85e90a05322e20f4c2c0fce299d1c352f1 | 15:12 |
rameshg87 | lucasagomes: in your model it's a CONF option, so it's going to get run for every node | 15:12 |
lucasagomes | the client (IPA in this case) just runs what it's been told to run | 15:12 |
lucasagomes | priorities can be easily defined by the order we list the clean steps (clean_steps=step1,step2,step3) | 15:12 |
rameshg87 | lucasagomes: so perhaps a different way of telling, "hey these clean steps were skipped because of ...." | 15:12 |
lucasagomes | and so on | 15:12 |
*** harshs has joined #openstack-ironic | 15:12 | |
lucasagomes | rameshg87, right | 15:12 |
* lucasagomes is just throwing some food for thought here, I know it changes everything! | 15:13 | |
rameshg87 | lucasagomes: a return code could do it | 15:13 |
jroll | xek: dansmith: the caller passes in the topic in (I believe) every case today, and self.topic is the fallback | 15:13 |
rameshg87 | but that needs to be boldly put out by conductor | 15:13 |
sambetts | maybe have a per node driver_info option that defines ones to skip ? | 15:13 |
dansmith | xek: 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 now | 15:14 |
jroll | xek: 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 up | 15:14 |
dansmith | jroll: 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 |
dansmith | and this would be an "any free conductors that can do this for me?" sort of thing | 15:16 |
xek | dansmith, 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 code | 15:16 |
dansmith | xek: yep | 15:17 |
lucasagomes | rameshg87, yeah we can think about it, something like sambetts mentioned perhaps... keep in the global config the generic steps for all nodes | 15:17 |
lucasagomes | keep in the nodes (driver_info) the node specific ones | 15:18 |
jroll | dansmith: 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 node | 15:18 |
rameshg87 | yeah | 15:18 |
dansmith | okay | 15:18 |
jroll | dansmith: because we have evil state between node and conductor in some cases | 15:18 |
dansmith | jroll: yeah, our conductors are nameless and stateless | 15:18 |
rameshg87 | jroll: lucasagomes: rloo: so coming back to the original problem | 15:19 |
jroll | dansmith: right, our 'conductors' are more like compute nodes in that they do the provisioning etc, however when needed we can shuffle things around | 15:19 |
dansmith | jroll: what is the concurrency model for your conductors? we run at least $ncpus conductor workers on each node | 15:19 |
rameshg87 | jroll: lucasagomes: rloo: so it's too late to decide another mechanism for an opt-out as we discussed | 15:19 |
dansmith | jroll: 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 think | 15:20 |
rameshg87 | jroll: 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 IRC | 15:20 | |
jroll | dansmith: any long-ish thing on a conductor spawns a worker to do the thing | 15:20 |
jroll | dansmith: that's a good point, though, hmm | 15:20 |
rameshg87 | jroll: lucasagomes: rloo: if not, let's try to do it better next time | 15:20 |
dansmith | jroll: but a greenthread? | 15:20 |
rameshg87 | what do you people say ? | 15:20 |
rloo | rameshg87: that makes sense to me, but it doesn't address jroll's question of user setting target-raid-config and create-raid not being done | 15:21 |
lucasagomes | rameshg87, right, yeah well I prefer to abstain really | 15:21 |
rameshg87 | rloo: that's why I said experimental basis if it's acceptable :) | 15:21 |
lucasagomes | I don't think it's a very good design | 15:21 |
rloo | rameshg87: and the big #2. IF we change the cleaning architecture, do we want to do this raid stuff now? | 15:21 |
rloo | lucasagomes: by 'design', you don't mean the RAID stuff but the overall cleaning architecture? | 15:22 |
jroll | dansmith: '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 tasks | 15:22 |
lucasagomes | rloo, both... but here talking about the RAID | 15:22 |
*** tsekiyam_ has quit IRC | 15:22 | |
*** lazy_prince has quit IRC | 15:22 | |
lucasagomes | rloo, cause I still don't see a good way we will opt-out in the future | 15:22 |
rloo | lucasagomes: which part of the RAID design bothers you? | 15:22 |
lucasagomes | the per-node config imo seems to be very needed for raid | 15:22 |
*** tsekiyama has joined #openstack-ironic | 15:23 | |
dansmith | jroll: okay, so anything that blocks the process will make the rest of the conductor go away, which means things like db accesses | 15:23 |
rloo | lucasagomes: i don't see why we can't set some opt-out flag like in the capabilities or driver-info or whatever | 15:23 |
dansmith | jroll: 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 call | 15:23 |
lucasagomes | rloo, right but that won't be part of that change right? | 15:23 |
rloo | lucasagomes: usually, when one has a global setting, there is a way to turn it off on a per instance basis. | 15:23 |
lucasagomes | it's a future thing | 15:23 |
dansmith | jroll: but doing that would be much harder for you to just do, given that your conductors are nameful and stateful | 15:23 |
rloo | lucasagomes: no, i don't think we want it as part of this patch. | 15:23 |
jroll | dansmith: 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 thread | 15:24 |
rameshg87 | lucasagomes: right, may be a future thing, not in this release | 15:24 |
dansmith | jroll: greenthread though, if you're using oslo.messaging | 15:24 |
rloo | lucasagomes: do you think opt-out is necessary for this feature to go out? | 15:24 |
lucasagomes | rloo, yeah, so see, I don't know who is going to use it as a global thing | 15:24 |
jroll | dansmith: oh, right, so mysqldb will still block yeah? | 15:24 |
dansmith | jroll: we get distribution across real processes because we fork early and all the workers are pulling from a single queue | 15:24 |
dansmith | jroll: correct | 15:24 |
lucasagomes | rloo, IMHO, I think it's a very necessary thing | 15:24 |
rloo | lucasagomes: it is turned off by default anyway. | 15:24 |
rloo | lucasagomes: oh. | 15:24 |
jroll | dansmith: side note: we use pymysql downstream :D | 15:24 |
*** vdrok has quit IRC | 15:25 | |
lucasagomes | rloo, right, but once you turn it on, do we really expect to all machines using a certain driver to have raid | 15:25 |
jroll | (that's not a good answer, I know) | 15:25 |
*** vdrok has joined #openstack-ironic | 15:25 | |
* jroll investigates | 15:25 | |
dansmith | jroll: that'll help, but it still limits you to one CPU of work | 15:25 |
lucasagomes | I don't know. maybe I don't have enough hands-on experience with datacenters here but it seems unrealistic | 15:25 |
*** garthb has joined #openstack-ironic | 15:25 | |
rameshg87 | lucasagomes: definitely not, considering even this is in-band | 15:26 |
lucasagomes | rameshg87, rloo I'm OK if it's merged as-is, it's cool but I slight prefer we not too | 15:26 |
rloo | lucasagomes: 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 |
lucasagomes | rloo, right, people still can create their cleaning manually and register the nodes in Ironic | 15:26 |
*** puranamr has joined #openstack-ironic | 15:27 | |
lucasagomes | I'm afraid of releasing something with a design that actually doesn't match the realities | 15:27 |
jroll | dansmith: 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 model | 15:27 |
*** puranamr has quit IRC | 15:27 | |
lucasagomes | rloo, because really, the "if you enable raid you need to enable for all nodes" seems to be a very small niche | 15:28 |
*** e0ne has quit IRC | 15:28 | |
*** dims has joined #openstack-ironic | 15:28 | |
lucasagomes | someone with RAID support may have big datacenters | 15:28 |
xek | jroll, the actual work will be done by Mitaka version of the conductor, until then, we can work something out | 15:28 |
*** harshs has quit IRC | 15:28 | |
dansmith | jroll: 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 build | 15:28 |
dansmith | jroll: but yeah, your call for sure | 15:28 |
lucasagomes | rloo, I don't have data tho, that's why I prefer to abstain... | 15:29 |
dansmith | jroll: what xek said is true, the conductor side of this is not actually used in liberty | 15:29 |
rloo | lucasagomes: ok. rameshg87 there you go. it needs a way to opt-out for lucas to ok it. | 15:29 |
dansmith | jroll: 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 later | 15:29 |
xek | jroll, do you agree that the topic argument can be removed, or should it stay? | 15:29 |
jroll | xek: 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-ironic | 15:30 | |
lucasagomes | rloo, 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 disabled | 15:30 |
dansmith | jroll: yep, fair point | 15:30 |
jroll | xek: dansmith and our goal is to release frequently, so someone may be doing rolling upgrades in a month | 15:30 |
dansmith | jroll: but again, no load unless a person actually tries to run multiple versions | 15:30 |
jroll | basically this blocks a release until the conductor is fixed | 15:30 |
lucasagomes | rloo, 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-ironic | 15:30 | |
dansmith | jroll: but yeah, if your release model makes this easier to do sooner than 6 mo, waiting for a resolution makes sense | 15:31 |
openstackgerrit | Merged openstack/ironic-inspector: Stop recommending using DIB from source https://review.openstack.org/226203 | 15:31 |
dansmith | jroll: 6-mo release projects have to be a little proactive about landing things we can leverage the next cycle | 15:31 |
*** saripurigopi has joined #openstack-ironic | 15:31 | |
rloo | lucasagomes: how do you think we should implement an opt-out? | 15:31 |
rameshg87 | lucasagomes: but this one still has your concerns | 15:31 |
*** ifarkas has quit IRC | 15:31 | |
lucasagomes | rameshg87, which one? cause the enable-for-all will not skip stuff will it? | 15:32 |
rameshg87 | lucasagomes: 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 to | 15:32 |
jroll | dansmith: 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 over | 15:32 |
jroll | dansmith: maybe it's a docs problem, though :) | 15:32 |
lucasagomes | rameshg87, if delete is enabled always deletes the RAID (independent of what is set in the raid_config fields) > | 15:33 |
lucasagomes | ?* | 15:33 |
rameshg87 | lucasagomes: that needs a better mechanism for opt-out | 15:33 |
lucasagomes | rloo, thinking... | 15:33 |
dansmith | jroll: 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 |
jroll | dansmith: yeah, totally. going to think on it a bit | 15:33 |
dansmith | cool | 15:34 |
*** rameshg871 has joined #openstack-ironic | 15:34 | |
rloo | lucasagomes, 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 |
rameshg871 | rloo: 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 now | 15:36 | |
rameshg871 | *got | 15:36 |
jroll | xek: 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 |
xek | jroll, ok | 15:36 |
* rameshg871 feels raid is so near but far enough | 15:36 | |
rloo | rameshg871: 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 |
rloo | rameshg871: which is why i'm fine w/o the opt out for now. Adding opt-out won't change the underlying design. | 15:37 |
rloo | rameshg871: 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 question | 15:37 |
*** rameshg87 has quit IRC | 15:38 | |
rameshg871 | makes sense, whatever opt out we choose later, would later be just an addon | 15:38 |
jroll | rloo: 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 |
rloo | rameshg871: 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 |
rloo | jroll: so we need to re-archtect cleaning then? | 15:39 |
*** praneshp has joined #openstack-ironic | 15:39 | |
jroll | rloo: I'm just talking about landing this patch specifically | 15:40 |
jroll | we can work out whatever we want to do in M on friday | 15:40 |
lucasagomes | jroll, I mean people can have RAID, just create it manually. As a developer I'm more interested about the design we have for automating it | 15:40 |
lucasagomes | is it good enough and flexible so we can extend it later | 15:40 |
rloo | jroll: 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 |
lucasagomes | does it cover the cases for RAID we have in mind even right now? | 15:40 |
jroll | rloo: 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 M | 15:41 |
lucasagomes | jroll, I just think that if the answer is "no" or "i don't know" we should think, because getting rid of it later is painful | 15:41 |
rloo | jroll: 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 IRC | 15:41 | |
*** romainh has left #openstack-ironic | 15:42 | |
jroll | rloo: right, and my current concern is that we aren't going to flush out all the cases and fix them the right way | 15:43 |
jroll | and we're going to have to do repairs in M | 15:43 |
rloo | rameshg871: 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 quantity | 15:43 | |
rloo | rameshg871: but i *would* like it updated to reflect the AgentDeploy method :) | 15:43 |
jroll | that's my thought as well | 15:43 |
jroll | too many questions | 15:43 |
rloo | rameshg871: and then we can add comments about what is outstanding | 15:43 |
jroll | lucasagomes: I mostly agree, I'm more concerned that we missed on networking and RAID which are the two biggest asks from users | 15:43 |
rloo | lucasagomes: 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 |
lucasagomes | jroll, :-( yeah it's very unfortunate | 15:44 |
jroll | lucasagomes: I want more (happy) users :) | 15:44 |
lucasagomes | jroll, but again, with the new release model that's not a big deal | 15:44 |
lucasagomes | thinking within the projects scope | 15:44 |
lucasagomes | and not the whole openstack umbrealla | 15:44 |
jroll | lucasagomes: yeah, I'm curious to see how many folks we can get on the intermediate releases | 15:44 |
jroll | lucasagomes: 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 in | 15:45 | |
lucasagomes | rloo, it's all good, we all have to rush some stuff at some point. Just lets make sure the direction is right | 15:45 |
*** dtantsur is now known as dtantsur|afk | 15:45 | |
lucasagomes | jroll, yeah, I hope RH will do it | 15:45 |
rameshg871 | rloo: lucasagomes: jroll: so one last word | 15:45 |
lucasagomes | tho I don't foresee it at the present moment | 15:45 |
rameshg871 | rloo: lucasagomes: jroll: I guess it's better if we don't merge that patch in L ? | 15:46 |
jroll | lucasagomes: if you tell them debian is doing it will it help them get moving on it? :D | 15:46 |
lucasagomes | rameshg871, in 4.2.0 | 15:46 |
jroll | rameshg871: I think so, yes | 15:46 |
rameshg871 | :) | 15:46 |
rameshg871 | then let's don't do it #agreed | 15:46 |
lucasagomes | jroll, heh I think it's a valid argument, I dunno the weight it will have tho | 15:46 |
rloo | rameshg871: yeah, sorry. I know you worked a lot on the raid etc stuff. | 15:46 |
rameshg871 | we will merge it in 4.3.0 for sure | 15:46 |
* rameshg871 hopes so | 15:47 | |
jroll | rameshg871: cool. I also apologize this didn't get in | 15:47 |
rameshg871 | jroll: rloo: np. ultimately ironic first. :) | 15:47 |
dtantsur|afk | jroll, we even package git master, but it does not mean it will be used... | 15:47 |
lucasagomes | rameshg871, yeah me too, I'm not against RAID at all, I just think we need to think a bit more about how we do it | 15:47 |
rameshg871 | will come up with a spec on how to enable it for cleaning, let's discuss on spec | 15:47 |
lucasagomes | and 2 days we have left is not comfortable enough to do it | 15:47 |
lucasagomes | rameshg871, thanks | 15:48 |
rameshg871 | sure | 15:48 |
jroll | dtantsur|afk: I'd love to see RDO using the most recent release we do | 15:48 |
rloo | lucasagomes, 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 |
jroll | rloo: +1 | 15:48 |
rameshg871 | rloo: I agree it needs to be captured in spec. | 15:48 |
rameshg871 | rloo: it's ideal | 15:48 |
dtantsur|afk | jroll, I doubt it's possible. RDO packages stable releases. Ironic alone will pull the whole bunch of other dependencies | 15:49 |
lucasagomes | rloo, yes... I'm partially blamed for it cause I think I can read code better than just ideas | 15:49 |
rloo | rameshg871: but *what* needs to be captured. Seems like sometimes the devil is in the details. | 15:49 |
rameshg871 | rloo: but I don't see something wrong if we find it later and go back and correct it | 15:49 |
lucasagomes | sometimes it clicks when I see what the code does, but the idea I don't get it in time :-( | 15:49 |
rameshg871 | rloo: as long as we do it and don't argue that "spec was submitted this way" | 15:49 |
jroll | dtantsur|afk: mehhhhh | 15:49 |
openstackgerrit | Grzegorz Grasza (xek) proposed openstack/ironic: Implement indirection_api https://review.openstack.org/224079 | 15:49 |
rloo | yeah, 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 |
rameshg871 | rloo: +1 | 15:50 |
rameshg871 | and with that I will call it a day | 15:50 |
rloo | thx for staying up so late rameshg871! | 15:50 |
lucasagomes | rloo, ++ | 15:50 |
rameshg871 | good night folks, see you all tomorrow | 15:50 |
lucasagomes | rameshg871, g'night! | 15:50 |
* dtantsur|afk is also really afk now | 15:51 | |
*** rameshg871 has quit IRC | 15:51 | |
jroll | alright, so we're almost there: https://launchpad.net/ironic/+milestone/4.2.0 | 15:51 |
jroll | I just landed the target_raid_config fix | 15:51 |
jroll | so 4 bugs left (and anything else we pick up) | 15:51 |
jroll | and would be nice to land the boot interface stuff, if it isn't terribly risky | 15:51 |
rloo | jroll: well, the node.target_raid_config thing isn't needed any more :) | 15:52 |
jroll | rloo: I mean, it's still part of the API :P | 15:52 |
rloo | jroll: 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 |
jroll | rloo: I think so, going to read some conductor code and think about it for a moment | 15:53 |
jroll | might just need to do some testing though | 15:53 |
rloo | jroll: that seems higher than boot driver interface, but maybe riskier too. i don't know much about that stuff. | 15:54 |
jroll | rloo: so it isn't risky at all, for this release | 15:54 |
rloo | jroll: oh, that's good to know. 'for this release'! | 15:54 |
jroll | rloo: 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 load | 15:54 |
rloo | jroll: vs not getting the code in, and not handling diff versions of api/conductor at all? | 15:55 |
*** mgoddard has quit IRC | 15:56 | |
jroll | rloo: 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 thing | 15:56 |
*** Haomeng|2 has quit IRC | 15:56 | |
lucasagomes | rloo, re https://review.openstack.org/#/c/205895 would be ok if we fix as a following patch? | 15:57 |
*** mgoddard has joined #openstack-ironic | 15:57 | |
rloo | jroll: so no rolling upgrade, vs rolling upgrade but conductor might fail over... | 15:57 |
*** Haomeng|2 has joined #openstack-ironic | 15:57 | |
rloo | jroll: so might as well get it in sooner to try it out etc :-) | 15:57 |
jroll | rloo: right, that's my thought | 15:57 |
rloo | lucasagomes: yeah. that is fixable. | 15:57 |
rloo | lucasagomes: it is straightforward | 15:57 |
lucasagomes | rloo, ok I will try to bake one quickly and put on top of that so we can get this fix in today | 15:58 |
*** yog_ has quit IRC | 15:58 | |
devananda | jroll: imbw, but I thought we already had the capability for rolling upgrades in the object code we had before o.vo | 15:58 |
rloo | lucasagomes: 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 |
jroll | devananda: apparently not - because objects could not be backported across versions etc | 15:59 |
*** cdearborn has joined #openstack-ironic | 15:59 | |
jroll | devananda: I also learned @remotable wasn't actually remoting to conductor :P | 15:59 |
devananda | right -- but it would gracefully reject the request, iow, continue operating at the greatest common RPC versoin | 15:59 |
devananda | oh, hah | 15:59 |
devananda | that's different, but not great | 15:59 |
jroll | devananda: 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 it | 16:00 |
*** praneshp has quit IRC | 16:01 | |
devananda | really? | 16:01 |
jroll | AIUI, yes | 16:01 |
devananda | i thought the RPC channel would recognize that one end was asking for 1.1 and send that | 16:01 |
jroll | but I could be wrong | 16:01 |
jroll | I still don't fully grok all of this | 16:01 |
*** rbudden has quit IRC | 16:02 | |
jroll | devananda: 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 translations | 16:02 |
devananda | huh. well. I have no idea about *that* | 16:03 |
devananda | has anyone looked at what sort of load it generates, if any? | 16:03 |
jroll | right, same, so I'm going to read some code | 16:03 |
*** whydidyoustealmy is now known as shakamunyi | 16:03 | |
devananda | k k | 16:04 |
jroll | I'm not sure. | 16:04 |
devananda | I'll poke at the current code to see if you're right | 16:04 |
devananda | what's a good (current) example of an object that would be afected by this? | 16:04 |
devananda | node with raid data, probably? | 16:04 |
jroll | well, today, none | 16:04 |
jroll | because this is only allowed for RPC version > 1.31 or whatever the new version introduced is | 16:05 |
devananda | kilo API vs. current conductor | 16:05 |
jroll | so it would be any object updates after this lands | 16:05 |
jroll | devananda: so the thought is, land it now, fix the conductor by next release if there are issues | 16:06 |
devananda | heh | 16:06 |
jroll | because this only enables rolling upgrades for release past the release it lands in | 16:06 |
jroll | so we want to be sure to get this patch in Liberty for the stable-only folks, so Mitaka can be rolling | 16:06 |
jroll | make sense? | 16:06 |
devananda | yup | 16:07 |
devananda | as long as it doesn't break Kilo -> Liberty | 16:07 |
jroll | right | 16:08 |
* lucasagomes no idea either... | 16:10 | |
*** romcheg has joined #openstack-ironic | 16:10 | |
*** [1]cdearborn has quit IRC | 16:13 | |
*** Marga_ has quit IRC | 16:13 | |
*** puranamr has joined #openstack-ironic | 16:17 | |
openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic: Follow-on to 90a9832131 to fix nits https://review.openstack.org/226397 | 16:18 |
lucasagomes | rloo, lemme know what you think ^ | 16:18 |
*** baoli_ has quit IRC | 16:19 | |
*** albertoffb has joined #openstack-ironic | 16:21 | |
*** enikanorov_ has quit IRC | 16:26 | |
*** enikanorov_ has joined #openstack-ironic | 16:26 | |
*** romcheg has quit IRC | 16:26 | |
rloo | lucasagomes: why didn't you just update the original patch? | 16:29 |
lucasagomes | rloo, I can do that too, squash it... Just wonder whether the author likes it or not (I usually ask first) | 16:30 |
lucasagomes | may be a me thing, but if you prefer on the same patch I can squash the commit there | 16:30 |
rloo | lucasagomes: given the amount of changes in the original (not much) I think it should just be done in the same patch | 16:30 |
lucasagomes | rloo, ack 1 sec | 16:30 |
rloo | lucasagomes: 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-ironic | 16:31 | |
lucasagomes | rloo, it's all good | 16:31 |
*** Marga_ has joined #openstack-ironic | 16:33 | |
openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic: Make end-points discoverable via Ironic API https://review.openstack.org/205895 | 16:36 |
lucasagomes | rloo, done | 16:36 |
rloo | lucasagomes: thx. | 16:37 |
rloo | lucasagomes: it closes bug 1311288, right? | 16:38 |
openstack | bug 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 |
lucasagomes | rloo, reading | 16:39 |
lucasagomes | rloo, I bet it does | 16:39 |
* lucasagomes updates the commit message | 16:40 | |
*** athomas has quit IRC | 16:40 | |
*** romcheg has quit IRC | 16:40 | |
jroll | lol, I was just going to ask the same thing | 16:40 |
lucasagomes | rloo, or it does talk about having links in the /states to states/power and states/provision ? | 16:40 |
lucasagomes | nah, I think it does | 16:40 |
rloo | lucasagomes: if you have a minute, could you make a similar change to https://review.openstack.org/#/c/205895/23/ironic/api/controllers/v1/driver.py | 16:40 |
lucasagomes | ok lemme update it | 16:40 |
lucasagomes | rloo, ack | 16:41 |
lucasagomes | rloo, to remove the allow_links_node_states_and_driver_properties() ? | 16:41 |
rloo | lucasagomes: oh wait. there is no sample() call that uses conver_with_links. hmm. that is odd. | 16:41 |
lucasagomes | yeah the driver.py doesn't have a shared method to convert | 16:41 |
lucasagomes | as we have for nodes.py | 16:41 |
lucasagomes | odd enough | 16:41 |
rloo | lucasagomes: should be ok then. jenkins will test it. | 16:41 |
lucasagomes | rloo, yeah I ran it locally seems fine too, but wait for jenkins | 16:42 |
lucasagomes | I will update the commit message | 16:42 |
openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic: Make end-points discoverable via Ironic API https://review.openstack.org/205895 | 16:42 |
lucasagomes | boom | 16:42 |
rloo | lucasagomes: 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-ironic | 16:43 | |
jroll | +@ | 16:43 |
jroll | +2 also. | 16:43 |
*** jxiaobin has joined #openstack-ironic | 16:44 | |
lucasagomes | ta much! | 16:44 |
*** harshs has joined #openstack-ironic | 16:46 | |
*** david-lyle has quit IRC | 16:46 | |
xek | dansmith, jroll, lucasagomes, jenkins finished checking https://review.openstack.org/#/c/224079/ | 16:47 |
xek | afk | 16:47 |
*** achanda has joined #openstack-ironic | 16:47 | |
lucasagomes | thanks | 16:48 |
jroll | stepping away for a bit | 16:48 |
*** praneshp has joined #openstack-ironic | 16:49 | |
*** cdearborn has quit IRC | 16:50 | |
*** trown is now known as trown|lunch | 16:51 | |
*** baoli has joined #openstack-ironic | 16:55 | |
*** romcheg has joined #openstack-ironic | 16:56 | |
* devananda is testing https://review.openstack.org/#/c/205895/24 | 16:57 | |
*** Marga_ has quit IRC | 16:59 | |
*** rbudden has joined #openstack-ironic | 17:00 | |
*** Marga_ has joined #openstack-ironic | 17:00 | |
rloo | thx devananda, since you opened the bug(s) :) | 17:01 |
*** Marga_ has quit IRC | 17:02 | |
devananda | yup yup | 17:02 |
rloo | devananda: oh, i don't think it addresses all of https://bugs.launchpad.net/ironic/+bug/1311288 | 17:02 |
openstack | Launchpad 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-ironic | 17:03 | |
devananda | rloo: driver/properties is now discoverable in the way I would expect | 17:04 |
devananda | rloo: but yea, node/NNN/states is still awkward :-/ | 17:05 |
*** Marga_ has quit IRC | 17:05 | |
devananda | it can be discovered from the base resource now -- so that's much better | 17:05 |
rloo | devananda: you have too many expectations! | 17:05 |
*** Marga_ has joined #openstack-ironic | 17:06 | |
devananda | maybe so :) | 17:06 |
*** derekh has quit IRC | 17:06 | |
devananda | rloo: I think it's good enough | 17:07 |
*** davideagnello has quit IRC | 17:08 | |
devananda | I mean, our API here is a bit rough in general - at least this makes it a little better | 17:09 |
*** davideagnello has joined #openstack-ironic | 17:10 | |
*** penick has joined #openstack-ironic | 17:10 | |
devananda | GET /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 IRC | 17:10 | |
lucasagomes | devananda, ++ | 17:11 |
lucasagomes | and folks I will call it a day | 17:11 |
lucasagomes | have a great night everyone | 17:11 |
thiagop | night lucasagomes | 17:11 |
lucasagomes | see ya | 17:11 |
devananda | g'night lucasagomes ! | 17:11 |
*** lucasagomes is now known as lucas-dinner | 17:12 | |
*** Sukhdev has joined #openstack-ironic | 17:17 | |
*** achanda_ has joined #openstack-ironic | 17:17 | |
*** achanda has quit IRC | 17:17 | |
*** Marga_ has quit IRC | 17:20 | |
*** Marga_ has joined #openstack-ironic | 17:20 | |
*** Marga_ has quit IRC | 17:21 | |
*** Sukhdev has quit IRC | 17:21 | |
*** BobBall is now known as BobBall_AWOL | 17:22 | |
*** baoli has quit IRC | 17:27 | |
krtaylor | jlvillal, 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 devstack | 17:29 |
krtaylor | very similar to the problem that gabriel-bezerra was seeing | 17:30 |
jlvillal | krtaylor: Thanks for the info. I didn't know about that. | 17:30 |
krtaylor | jlvillal, I am thinking of adding a line to the dev-quickstart guide | 17:31 |
jlvillal | krtaylor: Good idea :) | 17:31 |
*** dims has quit IRC | 17:31 | |
*** puranamr has joined #openstack-ironic | 17:31 | |
*** dims has joined #openstack-ironic | 17:32 | |
krtaylor | gabriel-bezerra, when you were seeing the sqlite3.OperationalError, was it on a container that had previously run devstack? | 17:32 |
*** Marga_ has joined #openstack-ironic | 17:33 | |
*** puranamr has quit IRC | 17:33 | |
krtaylor | jlvillal, what if we switched unit testing to use mysql? is there a requirement for sqlite for some reason? | 17:33 |
*** Marga_ has quit IRC | 17:34 | |
jlvillal | krtaylor: ugh | 17:34 |
krtaylor | hehheh | 17:34 |
jlvillal | krtaylor: Why do I want to run mysql on my system? | 17:34 |
*** Marga_ has joined #openstack-ironic | 17:34 | |
krtaylor | jlvillal, good question, but I thought we were seeing testing problems with it anyway several weeks ago | 17:35 |
jlvillal | krtaylor: 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 |
krotscheck | Did the members of ironic-webclient-core get flushed? I was under the impression that we'd assigned someone... | 17:36 |
jlvillal | Also I think it has been fixed by running the py34 test before py27. Seems to work | 17:36 |
krtaylor | ok, well, the problem goes away if unit test is run on a clean vm/system install, I'll add a line in the dev-quickstart | 17:36 |
jlvillal | krtaylor: thanks | 17:37 |
*** puranamr has joined #openstack-ironic | 17:37 | |
openstackgerrit | Kurt Taylor proposed openstack/ironic: Unit test environment setup clarification https://review.openstack.org/226445 | 17:42 |
*** [1]cdearborn has joined #openstack-ironic | 17:43 | |
*** trown|lunch is now known as trown | 17:52 | |
*** garthb has quit IRC | 18:02 | |
*** garthb has joined #openstack-ironic | 18:02 | |
*** penick has quit IRC | 18:04 | |
openstackgerrit | Julia Kreger proposed openstack/python-ironicclient: Set a default endpoint value of None https://review.openstack.org/226475 | 18:08 |
openstackgerrit | Juliana Motira proposed stackforge/pyghmi: Fixing set dcmi command https://review.openstack.org/226476 | 18:09 |
*** puranamr has quit IRC | 18:09 | |
*** Sukhdev has joined #openstack-ironic | 18:12 | |
*** krtaylor has quit IRC | 18:16 | |
openstackgerrit | Merged openstack/ironic: Allow unsetting node.target_raid_config https://review.openstack.org/226148 | 18:19 |
*** achanda has joined #openstack-ironic | 18:23 | |
*** achanda_ has quit IRC | 18:24 | |
*** penick has joined #openstack-ironic | 18:26 | |
rloo | jroll, 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 |
openstack | Launchpad bug 1488289 in Ironic "Ironic fails to deploy instance with pxe_ipmitool driver" [High,In progress] - Assigned to Yuiko Takada (takada-yuiko) | 18:26 |
jroll | rloo: -1 to a config | 18:28 |
jroll | rloo: I fully support your comment from sept 15 | 18:28 |
rloo | jroll: thx, what's your reason? | 18:28 |
jroll | rloo: because wildly changing the locale for a bunch of stuff will likely break things :) | 18:29 |
rloo | jroll: or not. I just don't know! | 18:29 |
rloo | jroll: ok, please comment. should be an easy fix. | 18:30 |
jroll | rloo: I think it probably will, we'd at least have to check every execute() call and see if we read stdout | 18:30 |
jroll | rloo: if it ain't broke... etc | 18:30 |
*** krtaylor has joined #openstack-ironic | 18:30 | |
rloo | jroll: heh, like i said, i don't know and if no one else knows, we shouldn't do it! | 18:30 |
jroll | rloo: wdyt about me just updating the patch to move it forward? | 18:30 |
rloo | jroll: nah. she's got 2 days. | 18:31 |
rloo | jroll: she's just waiting for some comments i think, so she knows how to move forward. | 18:31 |
jroll | rloo: I hope so, she hasn't been in IRC since the 17th | 18:31 |
jroll | and iirc she usually logs in | 18:32 |
rloo | jroll: 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 |
jroll | rloo: yeah, indeed | 18:32 |
jroll | commented. | 18:34 |
rloo | jroll: thx. | 18:35 |
jroll | np | 18:35 |
*** Sukhdev has quit IRC | 18:35 | |
*** garthb has quit IRC | 18:36 | |
gabriel-bezerra | krtaylor: as far as I recall, we had just the development tools installed from packages | 18:41 |
*** achanda has quit IRC | 18:42 | |
gabriel-bezerra | krtaylor: as one can find here http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html | 18:42 |
gabriel-bezerra | krtaylor: I'm just not sure if libmysqlclient-dev installs mysql, for instance. | 18:43 |
jroll | it does not | 18:44 |
jroll | I really don't want to run mysql :| | 18:44 |
gabriel-bezerra | krtaylor: and the environment I was using was the jenkins-slave docker image, which is based on ubuntu | 18:46 |
*** achanda has joined #openstack-ironic | 18:48 | |
*** Sukhdev has joined #openstack-ironic | 18:49 | |
*** jcrubio has joined #openstack-ironic | 18:57 | |
*** albertoffb has quit IRC | 19:00 | |
*** davhou has joined #openstack-ironic | 19:05 | |
*** jcrubio has quit IRC | 19:09 | |
*** Sukhdev has quit IRC | 19:09 | |
*** e0ne has joined #openstack-ironic | 19:10 | |
*** Sukhdev has joined #openstack-ironic | 19:10 | |
*** Sukhdev has quit IRC | 19:12 | |
*** Sukhdev has joined #openstack-ironic | 19:12 | |
*** pelix has quit IRC | 19:17 | |
*** Sukhdev has quit IRC | 19:18 | |
*** ijw has quit IRC | 19:19 | |
*** Sukhdev has joined #openstack-ironic | 19:27 | |
*** puranamr has joined #openstack-ironic | 19:27 | |
*** puranamr has quit IRC | 19:28 | |
*** ijw has joined #openstack-ironic | 19:29 | |
*** wshao has quit IRC | 19:30 | |
*** saripurigopi has quit IRC | 19:31 | |
*** ukalifon1 has quit IRC | 19:31 | |
*** Sukhdev has quit IRC | 19:35 | |
*** achanda has quit IRC | 19:37 | |
*** bradjones has joined #openstack-ironic | 19:46 | |
*** bradjones has quit IRC | 19:46 | |
*** bradjones has joined #openstack-ironic | 19:46 | |
*** Sukhdev has joined #openstack-ironic | 19:49 | |
*** Sukhdev has quit IRC | 19:50 | |
*** penick has quit IRC | 19:51 | |
*** penick has joined #openstack-ironic | 19:57 | |
*** jamielennox|away is now known as jamielennox | 20:03 | |
*** lucas-dinner has quit IRC | 20:08 | |
krtaylor | gabriel-bezerra, good info, it may be something else then, but there was a conflict somewhere, the unit tests worked on Fedora too | 20:10 |
krtaylor | anyway, it works on a clean install | 20:10 |
krtaylor | something devstack did to the vm conflicted with the venv | 20:11 |
*** nicodemos has quit IRC | 20:15 | |
*** achanda has joined #openstack-ironic | 20:15 | |
*** lucas-dinner has joined #openstack-ironic | 20:20 | |
openstackgerrit | Merged openstack/bifrost: Add warning text to Debian package list https://review.openstack.org/224129 | 20:24 |
*** wshao has joined #openstack-ironic | 20:28 | |
krtaylor | rloo, 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 |
krtaylor | I could dig into that more, but not really sure if that scenario even works for other projects | 20:30 |
dansmith | rloo: replied to some of your questions on that objects patch for clarification | 20:30 |
dansmith | rloo: 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 yet | 20:31 |
dansmith | rloo: but it is an incremental step in the right direction | 20:31 |
*** wshao has quit IRC | 20:32 | |
rloo | dansmith: 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-ironic | 20:35 | |
rloo | krtaylor: 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 |
krtaylor | rloo, understood, thanks for the review, I'll put it on my todo list | 20:38 |
dansmith | rloo: yep, likely "lots" from what I've seen looking through things in the last couple weeks | 20:40 |
rloo | dansmith: ohh, we're so bad. Thx for helping us out. We might need more guidance... | 20:41 |
dansmith | no, not so bad | 20:41 |
dansmith | lots < tons :) | 20:41 |
rloo | dansmith: we're not so bad then! | 20:42 |
*** e0ne has quit IRC | 20:51 | |
openstackgerrit | William Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - DB https://review.openstack.org/206232 | 20:55 |
*** baoli has quit IRC | 21:01 | |
*** baoli has joined #openstack-ironic | 21:02 | |
*** trown is now known as trown|outttypeww | 21:05 | |
*** priteau has quit IRC | 21:09 | |
*** baoli has quit IRC | 21:12 | |
*** baoli has joined #openstack-ironic | 21:12 | |
openstackgerrit | William Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - objs https://review.openstack.org/206238 | 21:14 |
*** Sukhdev has joined #openstack-ironic | 21:15 | |
openstackgerrit | William Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - RPC https://review.openstack.org/206243 | 21:15 |
devananda | jroll: on string freeze, AIUI, we need a language to hit >= 75% translated before the bot proposes it. | 21:17 |
devananda | we have several languages close to 40% .... https://translate.openstack.org/iteration/view/ironic/master/languages ... but nothing close to 75% yet | 21:18 |
jroll | devananda: yeah | 21:18 |
jroll | devananda: we did get a proposal from zanata but maybe that was the initial import for switching | 21:18 |
devananda | last cycle we were very soft on respecting string freeze because it was fairly clear none of the languages were going to get in | 21:18 |
devananda | i 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 now | 21:19 |
devananda | that 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 on | 21:19 |
devananda | ya? | 21:20 |
*** Marga_ has quit IRC | 21:21 | |
*** thiagop has quit IRC | 21:21 | |
*** achanda has quit IRC | 21:21 | |
jroll | devananda: https://review.openstack.org/#/c/224240/ | 21:21 |
jroll | devananda: string freeze has changed anyway, the freeze happens at rc1 cut or something? | 21:22 |
* jroll digs links | 21:22 | |
*** Marga__ has joined #openstack-ironic | 21:22 | |
jroll | devananda: ok, it only applies to release-with-milestones or whatever but https://review.openstack.org/#/c/223011/2/doc/source/release-management.rst | 21:22 |
devananda | right | 21:23 |
jroll | soft freeze after X-3, hard freeze after rc1 | 21:23 |
devananda | so release-with-milestone will string freeze master for a few weeks | 21:23 |
devananda | during which time they will merge translations and such | 21:23 |
devananda | we *wont* freeze master during that time | 21:23 |
devananda | which will mess with all the i18n tooling | 21:23 |
jroll | no, RC1 is when stable branch is cut | 21:23 |
jroll | so master never hard freezes | 21:23 |
jroll | maybe you mean soft freeze, idk | 21:23 |
devananda | no, you're right, i'm all confused | 21:24 |
devananda | other projects supposedly froze a few weeks ago (while I was on PTO) | 21:24 |
jroll | yeah, they feature-froze and soft-string-froze | 21:24 |
devananda | yea, and we didn't | 21:24 |
jroll | right, something to think about for sure | 21:25 |
devananda | anyway, 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 short | 21:26 |
devananda | but good to know it's working :) | 21:26 |
jroll | heh | 21:27 |
*** [1]cdearborn has quit IRC | 21:30 | |
*** caiobo has quit IRC | 21:31 | |
jroll | devananda: lifeless just made me realize a thing, we should get people to update RELEASE-NOTES or whatever the name is when they propose code | 21:46 |
devananda | ooh. yah | 21:46 |
devananda | the top of that file would then be "## name of next release (IN PROGRESS)" or something | 21:46 |
jroll | just gotta make cores aware | 21:46 |
jroll | yep | 21:46 |
jroll | also reminds me we should start making release notes for 4.2, also moving specs to liberty/ | 21:47 |
devananda | ++ | 21:47 |
lifeless | devananda: jroll: the reno proejct handles this | 21:49 |
jroll | lifeless: yep, I'm aware of the reno stuff, just never occurred to me to update while proposing code :) | 21:49 |
lifeless | I think you'll enjoy using it much more than rolling our own | 21:49 |
jroll | lifeless: https://github.com/openstack/ironic/blob/master/RELEASE-NOTES | 21:49 |
lifeless | jroll: *your* | 21:49 |
lifeless | jroll: so you don't need that file | 21:50 |
jroll | wait what | 21:50 |
lifeless | http://git.openstack.org/cgit/openstack/reno/tree/README.rst | 21:51 |
jroll | ok maybe I'm not at all aware of this | 21:51 |
lifeless | a big file like that will be merge hell; reno is designed to avoid that - see the link to the thread I gave in -meeting | 21:51 |
jroll | lifeless: ok, what we have is what we were told to do around a month+ ago :( | 21:53 |
jroll | lifeless: so this is working today and the release team is using it? | 21:54 |
*** caiobo has joined #openstack-ironic | 21:55 | |
lifeless | its the thing to use for M | 21:57 |
jroll | lifeless: also, how do we refactor existing release notes without going back and finding all the change ids? | 21:57 |
lifeless | it was too tight a deadline to make it be used to do L | 21:57 |
lifeless | so the change id isn't the key, its now a random uuid | 21:58 |
jroll | lifeless: so where are docs on how to submit a code change that comes with release notes? | 21:58 |
lifeless | the transition will be: - make a entries for your existing things and merge those. Carry on forward. | 21:58 |
lifeless | jroll: all coming soon :) | 21:58 |
*** wshao has joined #openstack-ironic | 21:58 | |
jroll | lifeless: ok, so "reno handles this" isn't true yet :D | 22:00 |
jroll | so devananda and I should still make release notes | 22:01 |
*** baoli has quit IRC | 22:01 | |
*** baoli has joined #openstack-ironic | 22:01 | |
jroll | thank you for tolerating my questions, btw | 22:01 |
*** baoli has quit IRC | 22:02 | |
*** wshao has quit IRC | 22:04 | |
*** baoli has joined #openstack-ironic | 22:04 | |
lifeless | jroll: its usable, its just not documented ;) | 22:04 |
jroll | heh | 22:05 |
*** cppforlife_ has quit IRC | 22:07 | |
*** jerrygb has joined #openstack-ironic | 22:08 | |
*** BadCub has quit IRC | 22:08 | |
*** ndipanov has quit IRC | 22:08 | |
*** davidlenwell has quit IRC | 22:08 | |
*** cppforlife_ has joined #openstack-ironic | 22:08 | |
mrda | Morning | 22:08 |
*** ndipanov has joined #openstack-ironic | 22:09 | |
*** davidlenwell has joined #openstack-ironic | 22:09 | |
*** BadCub has joined #openstack-ironic | 22:10 | |
jroll | \o mrda | 22:10 |
mrda | o/ | 22:10 |
*** garthb has joined #openstack-ironic | 22:11 | |
*** wshao has joined #openstack-ironic | 22:11 | |
*** garthb has quit IRC | 22:11 | |
*** garthb has joined #openstack-ironic | 22:12 | |
openstackgerrit | William Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - RPC https://review.openstack.org/206243 | 22:12 |
openstackgerrit | William Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - API https://review.openstack.org/206244 | 22:12 |
openstackgerrit | William Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - DB https://review.openstack.org/206232 | 22:12 |
openstackgerrit | William Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - objs https://review.openstack.org/206238 | 22:12 |
*** zhenguo has quit IRC | 22:12 | |
openstackgerrit | William Stevenson proposed openstack/ironic: Add portgroups to support LAG interfaces - net https://review.openstack.org/206245 | 22:12 |
*** zhenguo has joined #openstack-ironic | 22:13 | |
*** yuriyz has quit IRC | 22:15 | |
*** yuriyz has joined #openstack-ironic | 22:15 | |
*** baoli has quit IRC | 22:18 | |
*** baoli has joined #openstack-ironic | 22:20 | |
*** penick has quit IRC | 22:21 | |
*** boris-42 has quit IRC | 22: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-ironic | 22:22 | |
jroll | mrda: ++ | 22:23 |
jroll | I have a todo list item to totally revamp that dashboard | 22:23 |
jroll | but I wouldn't mind if someone else did it :D | 22:23 |
*** gridinv has quit IRC | 22:24 | |
*** boris-42 has joined #openstack-ironic | 22:24 | |
mrda | jroll: I'm happy to fork that and add in new projects. I'm not sure what else you'd want though. | 22:24 |
jroll | mrda: I don't know yet either :) | 22:24 |
jroll | that was the main point, probably with sections for each project | 22:24 |
*** gridinv has joined #openstack-ironic | 22:25 | |
*** ndipanov has quit IRC | 22:26 | |
mrda | ok | 22:26 |
*** puranamr has joined #openstack-ironic | 22:26 | |
mrda | Maybe not everyon thinks they have the expertise to review webclient stuff for example | 22:27 |
*** ndipanov has joined #openstack-ironic | 22:27 | |
*** achanda has quit IRC | 22:27 | |
jroll | yeah, exactly | 22:29 |
*** puranamr has quit IRC | 22:29 | |
*** rbudden has quit IRC | 22:30 | |
*** [1]cdearborn has joined #openstack-ironic | 22:31 | |
*** romcheg has quit IRC | 22:34 | |
*** Sukhdev has quit IRC | 22:36 | |
*** romcheg has joined #openstack-ironic | 22:44 | |
mrda | jroll: did you want pyghmi included? | 22:46 |
jroll | mrda: I don't personally care, I'm not sure if any cores would find that valuable | 22:47 |
*** baoli has quit IRC | 22:47 | |
mrda | ok | 22:47 |
jroll | mrda: I suddenly wonder if that project would accept jroll.dash :D | 22:47 |
mrda | jroll: of course, but the project is more than cores y'know ;) | 22:48 |
jroll | totes | 22:48 |
jroll | just more curious than anything :) | 22:49 |
mrda | So 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 |
jroll | like, another section like that for specs? | 22:53 |
jroll | idk | 22:53 |
mrda | I guess I'll put it up for review and see if people here like it | 22:53 |
*** Sukhdev has joined #openstack-ironic | 22:54 | |
*** Sukhdev has quit IRC | 22:54 | |
*** wshao has quit IRC | 22:56 | |
devananda | random rant: we shouldn't be returning the entire contents of the configdrive from "GET /v1/nodes/NNN" | 23:05 |
devananda | this is annoying when looking at gate logs :( | 23:05 |
jroll | try looking at it while debugging production build failures | 23:06 |
jroll | I thought we fixed that btw | 23:06 |
devananda | it's all over the logs for https://review.openstack.org/#/c/205895/24 's failure | 23:08 |
devananda | so apparently we didn't | 23:08 |
jroll | maybe just ironic's logs and not the api | 23:09 |
devananda | ahh that's probably it | 23:09 |
*** achanda has joined #openstack-ironic | 23:12 | |
*** dims has quit IRC | 23:18 | |
mrda | I'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 |
jlvillal | mrda: Yeah, I have had that patch drop to the bottom of my TODO list. | 23:26 |
jlvillal | mrda: Well at least below the line of things I need to work on now. | 23:27 |
jlvillal | mrda: If you wanted to run with that patch, feel free :) | 23:27 |
mrda | jlvillal: if it's below the line, you know it's up for elimination :) | 23:27 |
*** Sukhdev has joined #openstack-ironic | 23:28 | |
*** Sukhdev has quit IRC | 23:32 | |
*** Sukhdev has joined #openstack-ironic | 23:33 | |
*** romcheg has quit IRC | 23:45 | |
*** dims has joined #openstack-ironic | 23:54 | |
*** dims has quit IRC | 23:55 | |
*** Guest18166 has joined #openstack-ironic | 23:55 | |
rloo | jroll, devananda: wrt completed features, the generic RAID interface: https://blueprints.launchpad.net/ironic/+spec/ironic-generic-raid-interface | 23:56 |
rloo | jroll, devananda: the client part isn't done yet, and whatever documentation | 23:56 |
rloo | jroll, devananda: do we care if they are done for Thurs? | 23:56 |
rloo | jroll, devananda: looks like these are the two patches: https://review.openstack.org/#/c/226234/, https://review.openstack.org/#/c/226330/ both WIP | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!