*** f13o_ has quit IRC | 00:01 | |
* NobodyCam loves that his irc host is set to utc time and that 5 pm pst is midnight utc | 00:07 | |
*** igordcard has quit IRC | 00:15 | |
devananda | right - it's after midnight somewhere. I'm going afk for a while :) | 00:18 |
---|---|---|
NobodyCam | devananda: did you get any REST today? | 00:19 |
devananda | NobodyCam: no | 00:19 |
NobodyCam | :( | 00:19 |
*** eghobo has quit IRC | 00:27 | |
*** chuckC has quit IRC | 00:47 | |
*** jasondotstar has quit IRC | 00:48 | |
*** marzif_ has quit IRC | 00:55 | |
*** jasondotstar has joined #openstack-ironic | 00:55 | |
*** jasondotstar has quit IRC | 00:59 | |
*** eghobo has joined #openstack-ironic | 01:02 | |
*** ellenh has quit IRC | 01:05 | |
Shrews | devananda: ack | 01:07 |
*** jasondotstar has joined #openstack-ironic | 01:12 | |
*** nosnos has joined #openstack-ironic | 01:41 | |
*** jgrimm has joined #openstack-ironic | 01:43 | |
lifeless | adam_g: 103685 has conflicts with trunk | 01:43 |
*** eghobo has quit IRC | 01:43 | |
*** eghobo has joined #openstack-ironic | 01:44 | |
*** chenglch has joined #openstack-ironic | 01:45 | |
*** eghobo has quit IRC | 01:46 | |
*** chuckC has joined #openstack-ironic | 01:57 | |
*** Poornima has joined #openstack-ironic | 02:40 | |
*** jasondotstar has quit IRC | 02:42 | |
*** eghobo has joined #openstack-ironic | 03:50 | |
*** vinbs has joined #openstack-ironic | 03:54 | |
*** nosnos has quit IRC | 03:56 | |
*** jgrimm has quit IRC | 04:21 | |
*** Poornima has quit IRC | 04:21 | |
vinbs | Morning Ironic! :) | 04:23 |
*** Nisha has joined #openstack-ironic | 04:24 | |
*** LiveOne_ has joined #openstack-ironic | 04:28 | |
*** davidlenwell_ has joined #openstack-ironic | 04:28 | |
*** pcrews has quit IRC | 04:29 | |
*** proffalk1n has joined #openstack-ironic | 04:30 | |
*** GheRiver1 has joined #openstack-ironic | 04:30 | |
*** gilliard_ has joined #openstack-ironic | 04:31 | |
*** Hefeweiz1n has joined #openstack-ironic | 04:31 | |
*** nosnos has joined #openstack-ironic | 04:34 | |
*** MattMan2 has quit IRC | 04:35 | |
*** LiveOne has quit IRC | 04:35 | |
*** Hefeweizen has quit IRC | 04:35 | |
*** anteaya has quit IRC | 04:35 | |
*** antonym has quit IRC | 04:35 | |
*** proffalken has quit IRC | 04:35 | |
*** GheRivero has quit IRC | 04:35 | |
*** greghaynes has quit IRC | 04:35 | |
*** gilliard has quit IRC | 04:35 | |
*** davidlenwell has quit IRC | 04:35 | |
*** LiveOne_ is now known as LiveOne | 04:36 | |
*** MattMan has joined #openstack-ironic | 04:42 | |
*** antonym has joined #openstack-ironic | 04:43 | |
*** greghaynes has joined #openstack-ironic | 04:43 | |
*** anteaya has joined #openstack-ironic | 04:43 | |
*** Poornima has joined #openstack-ironic | 04:51 | |
*** ramineni has joined #openstack-ironic | 04:53 | |
Haomeng | vinbs: morning:) | 04:54 |
*** Nisha has quit IRC | 04:54 | |
*** k4n0 has joined #openstack-ironic | 04:56 | |
adam_g | GheRiver1, https://review.openstack.org/#/c/103685/ is this still needed? any chance of a rebase if we should still be pulling it in? | 05:06 |
adam_g | romcheg, emailed you a patch to your migration script, you should also propose the flavor migration script and subscribe it to the ironic_grenade topic. gnight! | 05:07 |
*** lazy_prince has quit IRC | 05:19 | |
*** rakesh_hs has joined #openstack-ironic | 05:20 | |
*** k4n0 has quit IRC | 05:21 | |
*** sabah has joined #openstack-ironic | 05:22 | |
*** k4n0 has joined #openstack-ironic | 05:34 | |
*** pradipta_away is now known as pradipta | 05:37 | |
*** killer_prince has joined #openstack-ironic | 05:46 | |
*** killer_prince is now known as lazy_prince | 05:46 | |
*** bmahalakshmi has joined #openstack-ironic | 05:52 | |
*** pcrews has joined #openstack-ironic | 05:58 | |
*** GheRiver1 is now known as GheRivero | 06:04 | |
*** pcrews has quit IRC | 06:06 | |
*** k4n0 has quit IRC | 06:12 | |
*** Mikhail_D_ltp has joined #openstack-ironic | 06:21 | |
openstackgerrit | Haomeng,Wang proposed a change to openstack/ironic: WIP: Add send-data-to-ceilometer support for pxe_ipminative driver https://review.openstack.org/112486 | 06:22 |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Raise MissingParameterValue instead of Invalid https://review.openstack.org/108455 | 06:24 |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Raise MissingParameterValue when validating glance info https://review.openstack.org/108456 | 06:25 |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Avoid calling _parse_deploy_info twice https://review.openstack.org/108442 | 06:26 |
*** k4n0 has joined #openstack-ironic | 06:28 | |
*** Nisha has joined #openstack-ironic | 06:34 | |
*** dtantsur|afk is now known as dtantsur | 06:38 | |
dtantsur | Morning, Ironic | 06:38 |
*** ifarkas has joined #openstack-ironic | 06:41 | |
*** pradipta is now known as pradipta_away | 06:46 | |
*** bvivek has joined #openstack-ironic | 06:46 | |
*** eghobo has quit IRC | 06:46 | |
*** nikunj2512 has joined #openstack-ironic | 06:56 | |
*** rameshg87 has joined #openstack-ironic | 07:01 | |
rameshg87 | dtantsur, hi | 07:01 |
openstackgerrit | Ramakrishnan G proposed a change to openstack/ironic: Move code to cleanup ImageCache to a common place https://review.openstack.org/110560 | 07:03 |
openstackgerrit | Imre Farkas proposed a change to openstack/ironic-specs: DRAC vendor passthru for RAID management https://review.openstack.org/107981 | 07:07 |
dtantsur | brb | 07:08 |
dtantsur | rameshg87, hi | 07:08 |
rameshg87 | dtantsur, needed your initial thoughts on a change on image_cache test case | 07:08 |
rameshg87 | dtantsur, yesterday jroll and myself were discussing on this | 07:09 |
dtantsur | rameshg87, sure, but a bit later | 07:09 |
dtantsur | breakfast time now :) | 07:09 |
rameshg87 | dtantsur, ah okay .. sorry go ahead :-) | 07:09 |
openstackgerrit | Ghe Rivero proposed a change to openstack/ironic: Fix tear_down a node with missing info https://review.openstack.org/103685 | 07:10 |
*** rameshg87 has quit IRC | 07:10 | |
*** rameshg87 has joined #openstack-ironic | 07:10 | |
*** rakesh_hs has quit IRC | 07:20 | |
*** rakesh_hs has joined #openstack-ironic | 07:21 | |
*** nikunj2512 has quit IRC | 07:25 | |
*** nikunj2512 has joined #openstack-ironic | 07:26 | |
*** rameshg87_ has joined #openstack-ironic | 07:29 | |
*** rameshg87 has quit IRC | 07:29 | |
*** sabah has quit IRC | 07:29 | |
*** subah has joined #openstack-ironic | 07:29 | |
vinbs | hi dtantsur | 07:32 |
vinbs | :) | 07:32 |
openstackgerrit | A change was merged to openstack/ironic: Sync oslo.incubator modules https://review.openstack.org/110941 | 07:38 |
*** jistr has joined #openstack-ironic | 07:42 | |
*** bvivek has quit IRC | 07:47 | |
*** foexle has joined #openstack-ironic | 07:57 | |
*** lucasagomes has joined #openstack-ironic | 08:17 | |
dtantsur | vinbs, hi! | 08:30 |
dtantsur | rameshg87_, I'm back, sorry for delay | 08:30 |
rameshg87_ | hi dtantsur | 08:31 |
rameshg87_ | dtantsur, yesterday myself and jroll were discussing about a test refactoring. just thought of checking with you | 08:32 |
rameshg87_ | dtantsur, https://github.com/openstack/ironic/blob/master/ironic/tests/drivers/test_pxe.py#L372-L492 | 08:32 |
rameshg87_ | dtantsur, they seem to be testing the image_cache's cleanup extensively and not actually fetch_images | 08:33 |
dtantsur | rameshg87_, yes, because this logic used to be somewhere there. Now it needs to be moved to test_image_cache and test you new shiny cleanup function :) | 08:33 |
rameshg87_ | dtantsur, so better move it to test_image_cache.py and add a small test case for fetch_images - fetch_images as such doesn't have much functionality | 08:34 |
rameshg87_ | dtantsur, yeah :-) | 08:34 |
dtantsur | I agree | 08:34 |
rameshg87_ | dtantsur, just did that and put up a patch. https://review.openstack.org/#/c/110560/ | 08:34 |
dtantsur | ack, will have a look | 08:35 |
rameshg87_ | dtantsur, thanks :-) | 08:36 |
*** mitz has quit IRC | 08:49 | |
vinbs | dtantsur, about the bug https://bugs.launchpad.net/ironic/+bug/1323589 | 08:51 |
dtantsur | sure | 08:51 |
vinbs | dtantsur, how do I upload the patch? I have the instructions on an etherpad | 08:51 |
*** pelix has joined #openstack-ironic | 08:52 | |
vinbs | dtantsur, should I just upload the instructions in a text file? | 08:53 |
openstackgerrit | Andrey Kurilin proposed a change to openstack/ironic: Use timeutils from one place https://review.openstack.org/112303 | 08:53 |
dtantsur | vinbs, no, I guess you should fix doc/source/deploy/install-guide.rst using your instructions, i.e. adding missing things etc | 08:54 |
*** igordcard has joined #openstack-ironic | 09:05 | |
*** marzif_ has joined #openstack-ironic | 09:07 | |
*** dtantsur is now known as dtantsur|lunch | 09:07 | |
vinbs | dtantsur, got it! thanks | 09:08 |
*** bvivek has joined #openstack-ironic | 09:13 | |
openstackgerrit | A change was merged to openstack/ironic: Migration to oslo.utils library https://review.openstack.org/110596 | 09:16 |
*** athomas has joined #openstack-ironic | 09:18 | |
*** Mikhail_D_ltp has quit IRC | 09:29 | |
*** proffalk1n has quit IRC | 09:30 | |
*** Mikhail_D_ltp has joined #openstack-ironic | 09:30 | |
*** proffalken has joined #openstack-ironic | 09:32 | |
openstackgerrit | Andrey Kurilin proposed a change to openstack/ironic: Use timeutils from one place https://review.openstack.org/112303 | 09:41 |
*** srinivas has joined #openstack-ironic | 09:57 | |
*** Nisha has quit IRC | 09:58 | |
*** sirushti has left #openstack-ironic | 10:02 | |
*** nikunj2512 has quit IRC | 10:06 | |
*** Nisha has joined #openstack-ironic | 10:07 | |
*** nikunj2512 has joined #openstack-ironic | 10:09 | |
*** sirushti has joined #openstack-ironic | 10:10 | |
*** chenglch has quit IRC | 10:13 | |
*** dtantsur|lunch is now known as dtantsur | 10:18 | |
*** ndipanov has joined #openstack-ironic | 10:18 | |
*** ndipanov has quit IRC | 10:18 | |
*** Alexei_987 has joined #openstack-ironic | 10:33 | |
rameshg87_ | dtantsur, just had a couple of questions on review of https://review.openstack.org/#/c/110560/4 | 10:34 |
dtantsur | rameshg87_, wait a bit please, I'm on call | 10:35 |
rameshg87_ | dtantsur, sure .. | 10:35 |
*** srinivas has quit IRC | 10:36 | |
*** subah has quit IRC | 10:40 | |
openstackgerrit | Imre Farkas proposed a change to openstack/ironic-specs: DRAC vendor passthru for RAID management https://review.openstack.org/107981 | 10:42 |
*** nikunj2512 has quit IRC | 10:44 | |
*** vinbs has quit IRC | 10:45 | |
*** lazy_prince has quit IRC | 10:45 | |
*** killer_prince has joined #openstack-ironic | 10:46 | |
*** killer_prince is now known as lazy_prince | 10:47 | |
*** nikunj2512 has joined #openstack-ironic | 10:47 | |
Nisha | lucasagomes: hi | 10:50 |
*** lazy_prince has quit IRC | 10:50 | |
lucasagomes | Nisha, hi there | 10:52 |
Nisha | lucasagomes: yes i am here | 10:52 |
Nisha | lucasagomes: thanks for the comments | 10:52 |
Nisha | lucasagomes: wanted to discuss on the comments | 10:53 |
lucasagomes | Nisha, oh no problem... I like the concept idea of that spec, but I didn't understand much why we are using CLI commands in the spec | 10:53 |
lucasagomes | so I put some comments on it | 10:53 |
Nisha | lucasagomes: thats where my main ques is :) | 10:54 |
Nisha | lucasagomes: if we dont have any changes in CLI how do we let API know about the option that discovery needs to be done | 10:54 |
lucasagomes | Nisha, right... I think it has to go the other way around. If we have no changes in the API how we build the CLI? | 10:55 |
lucasagomes | it's fine to have changes in the CLI as part of the spec | 10:55 |
lucasagomes | but it first needs to be in the REST API, because the CLI is just a wrapper on the API | 10:55 |
lucasagomes | e.g the node-create command will be translated into a POST -d '{ data }' v1/nodes for the REST API | 10:56 |
Nisha | lucasagomes: API also has the changes and are listed in the spec. API is the way to achieve it | 10:56 |
Nisha | Yes true | 10:56 |
lucasagomes | so I think the spec should talk about the Ironic services (API/Conductor)... And it's ok to say that as part of the work the CLI will be updated | 10:57 |
Nisha | it speaks about that too | 10:57 |
Nisha | I have the prototype already working as per the spec | 10:58 |
lucasagomes | Nisha, yeah it's mentioned there, but as a side change. Also it says things like "This proposal makes node-create asynchronous" | 10:58 |
lucasagomes | but it doesn't say what is the return code that will be returned to be async (I'm assuming 202) | 10:58 |
lucasagomes | also how the users will track that request to know when it's finished | 10:59 |
Nisha | This is because Deva has given this comment that it needs to be asynchronous | 10:59 |
lucasagomes | again node-create is the CLI command, we really should talk about POST /v1/nodes being async | 10:59 |
lucasagomes | Nisha, sure, yeah, if we are touching the BMC it should be async | 10:59 |
lucasagomes | because it can take a some time to execute | 10:59 |
Nisha | lucasagomes: so in async how it works is, it invokes the thread which does the discovery and updates the node object. | 10:59 |
lucasagomes | Nisha, right, but what is returned to the user when the request is issued? | 11:00 |
lucasagomes | Nisha, e.g if the node creation is async | 11:00 |
lucasagomes | no UUID will be returned to the client | 11:00 |
lucasagomes | how he knows which node he just created? | 11:00 |
Nisha | it returns the current node object without properties discovered as it does today | 11:00 |
lucasagomes | ah right... so the creation of the node is not async | 11:00 |
Nisha | in the background the node object is updated with the properties | 11:00 |
lucasagomes | the discovery of the properties is async | 11:01 |
Nisha | creation of node is as it is today | 11:01 |
Nisha | discovery is async | 11:01 |
lucasagomes | but when you read "This proposal makes node-create asynchronous" you don't know that ^ | 11:01 |
openstackgerrit | Victor Sergeyev proposed a change to openstack/ironic: Use metadata.create_all() to get database schema https://review.openstack.org/107629 | 11:01 |
lucasagomes | Nisha, right... I understand it better now, thanks | 11:01 |
Nisha | lucasagomes: so actually what all you think need to be modified in the spec? | 11:02 |
lucasagomes | Nisha, and what about that alternative to have 2 commands? I think that looks more sane than squeezing everything in the POST v1/nodes | 11:02 |
Nisha | in that approach | 11:02 |
Nisha | i had actually implemented that in node-create CLI itself ...ideally equivalent to have one seperate CLI for discovery | 11:03 |
lucasagomes | Nisha, right so for the spec we need to stop using the CLI commands as a refence | 11:04 |
lucasagomes | for e.g | 11:04 |
lucasagomes | when you say node-create --discovery | 11:04 |
lucasagomes | how the --discovery tag will be translated to our API? | 11:04 |
Nisha | the proposal is to discover properties and port create at the time of node create so manual steps can be removed | 11:04 |
lucasagomes | POST v1/nodes/?discovery=True!? | 11:04 |
Nisha | Yes | 11:04 |
*** ramineni has quit IRC | 11:04 | |
Nisha | I mentioned that in spec na | 11:04 |
Nisha | lucasagomes: see REST API impact | 11:05 |
Nisha | it gives that details | 11:06 |
lucasagomes | Nisha, right looking | 11:06 |
lucasagomes | Nisha, ok I just found it confused because the Proposed change actually talks about the CLI instead of the Ironic services | 11:07 |
lucasagomes | where the changes will actually be | 11:07 |
Nisha | lucasagomes: is it, the spec just tells the way it needs to be invoked from a user | 11:08 |
Nisha | lucasagomes: IMO, the spec says about complete flow from CLI to API to conductor to driver | 11:08 |
lucasagomes | Nisha, right which IMO is a bit odd/wrong, cause spec is not a user manual, it should describe the changes we are making to Ironic | 11:09 |
lucasagomes | Nisha, but yeah I understand it better now | 11:10 |
lucasagomes | thanks for that | 11:10 |
Nisha | Ok, so you dont see any issues with the given approach | 11:10 |
lucasagomes | Nisha, so... about the 1 request vs 2 requests | 11:10 |
Nisha | lucasagomes: yes | 11:10 |
lucasagomes | Nisha, well... the issue I see is, the spec is confusing | 11:10 |
lucasagomes | for talking mostly about CLI instead of the API... but ok | 11:10 |
lucasagomes | Nisha, you think that having 1 request for the discovery is better? | 11:11 |
*** ndipanov has joined #openstack-ironic | 11:11 | |
Nisha | lucasagomes: Yes thats where you avoid the manual step | 11:11 |
Nisha | correct? | 11:11 |
lucasagomes | Nisha, I don't know how I feel about having node-create to be part sync part async | 11:11 |
lucasagomes | it looks pretty odd | 11:11 |
lucasagomes | you do a POST v1/nodes?discover=True | 11:12 |
lucasagomes | it returns 202 | 11:12 |
lucasagomes | but the node was created synchrousnly | 11:12 |
Nisha | otherwise user has to again issue one CLI to do discovery and port ceration | 11:12 |
lucasagomes | that makes little sense for me | 11:12 |
*** killer_prince has joined #openstack-ironic | 11:12 | |
*** killer_prince is now known as lazy_prince | 11:12 | |
lucasagomes | Nisha, yeah I can see the optimization, but when you look at the REST API itself it looks wrong | 11:12 |
Nisha | actually i just made it 202, but i didnt encounter any issue even as 201 | 11:13 |
lucasagomes | if it returns 202 indicating it's an async call to create the node | 11:13 |
lucasagomes | but returns the node as part of the return body | 11:13 |
Nisha | yes | 11:13 |
lucasagomes | Nisha, well the issue with 201 is that it means that the request was completed fullfiled | 11:13 |
lucasagomes | when it's not | 11:13 |
Nisha | yes | 11:13 |
lucasagomes | because there's a task running on the background | 11:13 |
Nisha | true | 11:13 |
lucasagomes | so it all looks wrong to have this combination of sync + async | 11:13 |
lucasagomes | for me it's either a sync or an async request | 11:14 |
lucasagomes | so breaking into 2 calls makes way more sense | 11:14 |
lucasagomes | looks better to the API | 11:14 |
Nisha | lucasagomes: i could have tried making it completely asynch....but then it would broken compatibility for node-create | 11:15 |
lucasagomes | Nisha, yeah... and would need a mechanism to track the result of that request as well | 11:15 |
lucasagomes | Nisha, can we break it in two commands? leave the creation as-is | 11:15 |
lucasagomes | and then if you want to discovery the properties you can trigger it by a different request | 11:16 |
Nisha | we can do it, i had prototyped that as well | 11:16 |
*** rameshg87_ has quit IRC | 11:16 | |
lucasagomes | Nisha, cool, I think that's the way to go really | 11:16 |
Nisha | u mean a new CLI? | 11:16 |
lucasagomes | Nisha, have other people comments against that ^ | 11:16 |
lucasagomes | Nisha, a new CLI? like a new command? | 11:17 |
Nisha | this comment i have recvd only from you | 11:17 |
Nisha | :) | 11:17 |
Nisha | yes | 11:17 |
Nisha | i think you meant that only | 11:17 |
lucasagomes | Nisha, ack... well on the CLI as it's a wrapper | 11:17 |
Nisha | if i am wrong plz correct | 11:17 |
lucasagomes | I don't see a problem in having node-create --discovery to trigger both requests | 11:17 |
Nisha | Ok, i had done that too :) | 11:17 |
Nisha | i prototyped all three ways | 11:18 |
lucasagomes | hah | 11:18 |
lucasagomes | nice | 11:18 |
dtantsur | lucasagomes, Nisha, 2 API commands, one pure sync, one pure async make a lot of sense to me, +1 | 11:18 |
* dtantsur was partially following | 11:18 | |
lucasagomes | dtantsur, :) yeah, please join the conversation | 11:18 |
Nisha | Ok. so if user issues node-create --discover, then two URLS will be issued | 11:19 |
Nisha | thats fine? | 11:19 |
lucasagomes | Nisha, I don't see much problems on that | 11:19 |
dtantsur | lucasagomes, Nisha, actually I still have a bad feeling about node-update part accepting both key=value (required) and --discover | 11:20 |
lucasagomes | because, as said, CLI is just a wrapper | 11:20 |
Nisha | hmmm | 11:20 |
Nisha | dtantsur: :( | 11:20 |
lucasagomes | dtantsur, hmm yeah... looks a bit odd indeed | 11:20 |
dtantsur | lucasagomes, Nisha, I would stay with node-create --discover and a separate command node-discover for existing node | 11:20 |
lucasagomes | dtantsur, do you think that, if we have a separated command in the CLI it would be better? | 11:20 |
dtantsur | yep | 11:21 |
dtantsur | we still can have optional flag for -create, that makes sense to me | 11:21 |
lucasagomes | so the command will discover/update the properites of the node (in case it's already there) | 11:21 |
*** Poornima has quit IRC | 11:21 | |
lucasagomes | dtantsur, right yeah I can see that | 11:21 |
dtantsur | lucasagomes, "in case it's already there" <-- it's always there, this command will accept UUID | 11:21 |
dtantsur | or did I get you wrong? | 11:21 |
Nisha | dtantsur: lucasagomes ok i will propose a new CLI for node-update part | 11:22 |
lucasagomes | dtantsur, I mean, if the node already has the properties filled, but OP updated the hardware (put more ram) | 11:22 |
lucasagomes | and then he issued the discovery again it will just update | 11:22 |
lucasagomes | what is already there | 11:22 |
dtantsur | well yes | 11:22 |
lucasagomes | Nisha, ok | 11:22 |
lucasagomes | Nisha, thanks | 11:23 |
Nisha | dtantsur: lucasagomes do you see any issues for node-create --discover? | 11:23 |
lucasagomes | Nisha, IMO I'm fine with that | 11:23 |
dtantsur | lucasagomes, Nisha, and last idea: I suspect --create-ports should be the default for node-discover and node-create --discover. What do you think? | 11:23 |
dtantsur | (then we can have --no-create-ports as a flag, if you feel like) | 11:23 |
*** nosnos has quit IRC | 11:23 | |
Nisha | well i can do that :) | 11:23 |
lucasagomes | dtantsur, that's actually a good point | 11:23 |
lucasagomes | dtantsur, I would expect my discovery to find the NICs for me as well | 11:23 |
lucasagomes | by default | 11:23 |
dtantsur | Nisha, do you agree? | 11:24 |
Nisha | dtantsur: lucasagomes discovery will discover the NICs as it is part of node properties, but creation of ports shall be default is a thing whether we shud it in node-create by default or not | 11:25 |
Nisha | i can do that , i have no issues :) | 11:25 |
lucasagomes | Nisha, just one more thing about the spec... can we make the Proposed Change section to talk about the REST API instead of the CLI? | 11:26 |
lucasagomes | that really makes my brain hurt when reading that | 11:26 |
lucasagomes | we can mention the CLI changes but the main thing is the API | 11:26 |
dtantsur | lucasagomes, ++ | 11:26 |
lucasagomes | that's the change for Ironic, the API. The CLI is ironic but it's a diff repository of code | 11:27 |
lucasagomes | it's a different project | 11:27 |
lucasagomes | we really should not use the CLI as a reference there | 11:27 |
lucasagomes | mention it fine, but not as the proposed change for ironic | 11:27 |
lucasagomes | and I will be back... I'm in the office I will go out buy some food, be back in few minutes | 11:28 |
*** lucasagomes is now known as lucas-brb | 11:28 | |
* lucas-brb brb | 11:28 | |
dtantsur | oh, I'll also grab some tea | 11:28 |
Nisha | ok | 11:29 |
*** bvivek has quit IRC | 11:34 | |
ifarkas | Nisha, hi, I also commented on the spec that you should state that it should only discover attributes that will be used for scheduling, and a driver can also decide to discover more properties, but only in case it will be used by driver. | 11:35 |
Nisha | ifarkas: do you see any more properties listed in the spec than required | 11:36 |
ifarkas | Nisha, there isn't any, but your spec doesn't say anything about when a driver *can* include more properties | 11:37 |
ifarkas | which was my comment | 11:37 |
Nisha | ifarkas: have you seen latest patch | 11:38 |
Nisha | the spec doesnt has that line at all | 11:38 |
Nisha | your comment is addressed already | 11:38 |
ifarkas | Nisha, it's not addressed. The statement about it is missing. | 11:39 |
Nisha | means? | 11:39 |
ifarkas | Nisha, a driver can include more properties only if it will be used by Ironic | 11:40 |
Nisha | yes i removed it as per your comment | 11:40 |
Nisha | so the generic spec is not having that statement now, the driver specific spec can mention the reason for discovering any other property they intend to discover and where they plan to store it | 11:41 |
Nisha | like for iLO discover properties spec, i discover license also | 11:41 |
Nisha | which is required by ilo deploy driver | 11:42 |
Nisha | and will be stored in extras | 11:42 |
ifarkas | Nisha, I didn't comment on it to remove it but to specify when it is allowed | 11:42 |
Nisha | ifarkas: i think that responsibility shall be taken up by specific driver specs | 11:43 |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: EXPERIMENTAL Implement hardware discovery in PXE driver https://review.openstack.org/110031 | 11:43 |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Add newly_discovered column to Node object https://review.openstack.org/107389 | 11:43 |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: EXPERIMENTAL Add Conductor.discovery_driver field https://review.openstack.org/109304 | 11:43 |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: EXPERIMENTAL Implement conductor part of hardware discovery https://review.openstack.org/109312 | 11:43 |
Nisha | dtantsur: lucas-brb let me know if you feel otherwise on ifarkas above ^ comment | 11:43 |
dtantsur | Nisha, I don't quite get the context. What line/paragraph are you arguing on? | 11:44 |
Nisha | dtantsur: :) | 11:44 |
ifarkas | dtantsur, revision 30, line 38 | 11:44 |
ifarkas | dtantsur, sorry, revision 29, line 38 | 11:45 |
dtantsur | Nisha, ifarkas, I don't think this line is critical for anything or actually means anything :) anyway, each driver is going to have it's own spec with it's own reasoning | 11:46 |
dtantsur | Nisha, ifarkas, and anyway JSON structure in it does not contain anything extra for now | 11:47 |
ifarkas | dtantsur, Nisha, alright | 11:47 |
dtantsur | and I don't even see this line in a new revision :) | 11:47 |
ifarkas | dtantsur, yeah, it's missing from the new revision, that's why I thought it worth specifying when each driver can alter the list | 11:49 |
dtantsur | ifarkas, let's leave it for each driver's spec, we can't predict all the possibilities | 11:49 |
dtantsur | imagine devananda changing our statement and turning Ironic in CMDB finally :) | 11:50 |
* dtantsur is gonna be killed this evening | 11:50 | |
ifarkas | dtantsur, yeah, we don't want to predict it, just state the condition that has been stated during the meeting | 11:50 |
ifarkas | dtantsur, but I am fine either way | 11:50 |
Nisha | dtantsur: thanks | 11:51 |
Nisha | dtantsur: lucas-brb so i will do changes as discussed above | 11:52 |
Nisha | for node-create and a new CLI | 11:53 |
Nisha | thanks fr the discussion dtantsur lucas-brb | 11:54 |
dtantsur | np) | 11:57 |
*** lucas-brb is now known as lucasagomes | 12:08 | |
lucasagomes | Nisha, thank you | 12:08 |
openstackgerrit | Roman Prykhodchenko proposed a change to openstack/ironic: Migrate Nova BM data to Ironic https://review.openstack.org/112402 | 12:09 |
*** linggao has joined #openstack-ironic | 12:26 | |
*** bvivek has joined #openstack-ironic | 12:29 | |
openstackgerrit | Roman Prykhodchenko proposed a change to openstack/ironic: Flavor update tool for Ironic https://review.openstack.org/112575 | 12:36 |
*** foexle has quit IRC | 12:40 | |
romcheg | Morning guys | 12:42 |
romcheg | I moved migration tools to Ironic source tree | 12:42 |
romcheg | adam_g: When you're here you can take a look at that | 12:42 |
romcheg | I'm going to disappear for two weeks. Maybe I'll be accessible over email | 12:43 |
romcheg | So you can poke yuriyz if you need something | 12:43 |
romcheg | I also upgated review links in the whiteboard | 12:44 |
*** matty_dubs|gone is now known as matty_dubs | 12:48 | |
*** bvivek2 has joined #openstack-ironic | 12:54 | |
*** bvivek has quit IRC | 12:55 | |
*** k4n0 has quit IRC | 12:59 | |
*** jasondotstar has joined #openstack-ironic | 13:03 | |
*** bmahalakshmi has quit IRC | 13:10 | |
*** nikunj2512 has quit IRC | 13:11 | |
*** ramineni has joined #openstack-ironic | 13:27 | |
lucasagomes | JayF, ping re ipmi | 13:35 |
*** foexle has joined #openstack-ironic | 13:42 | |
*** pcrews has joined #openstack-ironic | 13:43 | |
*** ifarkas has quit IRC | 13:45 | |
yuriyz | Hi Ironic | 13:46 |
yuriyz | dtantsur, I left comment on Victor's patch for you | 13:47 |
*** ifarkas has joined #openstack-ironic | 13:48 | |
*** shakamunyi has joined #openstack-ironic | 13:50 | |
*** ifarkas has quit IRC | 13:50 | |
*** ifarkas has joined #openstack-ironic | 13:53 | |
lucasagomes | cores https://review.openstack.org/#/c/99318/ needs another +2... please if you have a time review it | 13:53 |
lucasagomes | I want to get it in so we can land the devstack patch as well and add ipxe to be tested on gate | 13:54 |
dtantsur | yuriyz, morning :) | 13:55 |
dtantsur | lucasagomes, I am on it, but have a question | 13:55 |
lucasagomes | dtantsur, sure | 13:55 |
dtantsur | lucasagomes, https://review.openstack.org/#/c/99318/17/ironic/common/pxe_utils.py looks like you're trying to supply PXE boot image for dumb firmware, not understanding iPXE, right? | 13:55 |
dtantsur | I mean, even if iPXE is enabled | 13:55 |
lucasagomes | dtantsur, yes | 13:56 |
lucasagomes | dtantsur, if it's not an iPXE boot image | 13:56 |
lucasagomes | we send the ipxe boot image so it can chainload | 13:56 |
dtantsur | lucasagomes, I can't find the place, where you save the appropriate PXE config file to TFTP root | 13:58 |
dtantsur | or did I get it wrong? | 13:59 |
lucasagomes | dtantsur, to generate the PXE config it uses a template | 13:59 |
lucasagomes | dtantsur, for iPXE I just have another template | 13:59 |
lucasagomes | so no changes to the function we have currently is needed | 13:59 |
lucasagomes | dtantsur, https://review.openstack.org/#/c/99318/17/ironic/drivers/modules/ipxe_config.template that's the template for iPXE | 14:00 |
*** Nisha has quit IRC | 14:00 | |
dtantsur | lucasagomes, yeah, but to chainload iPXE you need pure PXE config first, no? | 14:00 |
lucasagomes | dtantsur, no, this is what the PXE server does | 14:01 |
lucasagomes | (dnsmasq) in case of neutron | 14:01 |
lucasagomes | that's the extra DHCP options | 14:01 |
lucasagomes | dtantsur, http://ipxe.org/howto/dhcpd#ipxe-specific_options | 14:01 |
dtantsur | lucasagomes, "The pxe_bootfile_name config option should point to the iPXE image (undionly.kpxe)." that's what I didn't realize :) | 14:02 |
lucasagomes | oh yeah, so when enabling iPXE you also change the bootimage file config option | 14:02 |
lucasagomes | and the pxe_template | 14:02 |
Haomeng | hi ironic | 14:03 |
dtantsur | Haomeng, hi! | 14:03 |
lucasagomes | those will be documented | 14:03 |
lucasagomes | Haomeng, hi there | 14:03 |
dtantsur | lucasagomes, I hope it will be more clear, when docs arrive :) | 14:03 |
lucasagomes | yeah, the next patch of the series are docs | 14:03 |
Haomeng | dtantsur: :) | 14:03 |
Haomeng | lucasagomes: : | 14:03 |
Haomeng | just raise a question | 14:03 |
Haomeng | who see such issue when deploy ironic with devstack - "error: Failed to define network from /dev/fd/63 , error: XML error: unexpected virtualport type -1'' | 14:04 |
lucasagomes | Haomeng, haven't see that... this happens when devstack is setting up Ironic? or another OS component? | 14:05 |
Haomeng | lucasagomes: yes, happens when devstack is create VMs which used by ironic | 14:05 |
Haomeng | lucasagomes: thank you:) let me google:) | 14:06 |
lucasagomes | Haomeng, I see :( idk... virsh version maybe? | 14:06 |
Haomeng | lucasagomes: yes | 14:07 |
Haomeng | lucasagomes: good sense:) | 14:07 |
Haomeng | lucasagomes: +2:) | 14:07 |
lucasagomes | :) | 14:07 |
Haomeng | nice day:) good night:) | 14:08 |
lucasagomes | Haomeng, g'night | 14:10 |
Haomeng | lucasagomes: :) | 14:10 |
matty_dubs | jroll: JayF: Nice! (re: OnMetal pics; was on PTO yesterday) | 14:11 |
jroll | morning everybody :) | 14:18 |
jroll | dtantsur: any reason you didn't approve that ipxe patch? | 14:19 |
dtantsur | jroll, I realized that my understanding of iPXE is very bad :( | 14:22 |
dtantsur | jroll, and good morning :) | 14:22 |
*** shakamunyi has quit IRC | 14:23 | |
jroll | that's why jay and I +'d it :P | 14:23 |
jroll | idk, any problem with me approving it? I think it's solid | 14:23 |
dtantsur | jroll, will approve before leaving the office today (~1.5hrs), if nobody jumps in | 14:23 |
dtantsur | oh you can go ahead and approve :) | 14:23 |
jroll | maybe I'll run it in devstack first | 14:23 |
lucasagomes | jroll, https://review.openstack.org/#/c/99677 | 14:25 |
lucasagomes | jroll, you just need to set IRONIC_IPXE_ENABLED=True on ur localrc file | 14:25 |
jroll | a ha | 14:25 |
jroll | :) | 14:25 |
* jroll gives it a shot | 14:25 | |
NobodyCam | morning Ironic | 14:26 |
lucasagomes | NobodyCam, morning | 14:26 |
jroll | I'll review that devstack patch afterward, too | 14:27 |
jroll | hiya NobodyCam | 14:27 |
lucasagomes | jroll, :) thanks | 14:27 |
NobodyCam | morning jroll, lucasagomes, dtantsur and Haomeng :) | 14:27 |
*** jgrimm has joined #openstack-ironic | 14:28 | |
dtantsur | NobodyCam, morning :) | 14:28 |
NobodyCam | :) | 14:29 |
*** Mikhail_D_ltp has quit IRC | 14:31 | |
*** ifarkas has quit IRC | 14:34 | |
*** rakesh_hs has quit IRC | 14:37 | |
*** shakamunyi has joined #openstack-ironic | 14:38 | |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Remove direct calls to dbapi's get_node_by_instance https://review.openstack.org/112595 | 14:39 |
lucasagomes | jroll, about IPMI, you know if FRU should return the NICs information of the node? like mac addresses and all? | 14:39 |
lucasagomes | jroll, random question sorry heh | 14:39 |
jroll | lucasagomes: sorry, idk about fru things | 14:40 |
lucasagomes | jroll, no problem, thanks | 14:40 |
dtantsur | lucasagomes, why are all these patches chained https://review.openstack.org/#/c/112595/ ? It does not look like they're interdependent | 14:41 |
lucasagomes | dtantsur, they are all part of the same effort/bug | 14:41 |
openstackgerrit | Vladyslav Drok proposed a change to openstack/ironic: Add driver name on driver load exception https://review.openstack.org/112049 | 14:41 |
lucasagomes | to hide the dbapi calls underneath objects | 14:41 |
lucasagomes | dtantsur, yeah it's not a linear dependency :/ but makes it easier to me to maintain them locally | 14:42 |
dtantsur | lucasagomes, to me it does not justify chaining. Remember how long it took to merge management interface chain. I highly suggest making them independent (at least those who do not have +2 yet) | 14:42 |
lucasagomes | dtantsur, right, ok I will break the chain | 14:43 |
dtantsur | thanks | 14:43 |
openstackgerrit | Andrey Kurilin proposed a change to openstack/ironic: Use timeutils from one place https://review.openstack.org/112303 | 14:43 |
lucasagomes | dtantsur, btw, they create() destroy() get_by_instance() dependends on https://review.openstack.org/#/c/112056 | 14:43 |
dtantsur | lucasagomes, ok, I really looked only at the last one | 14:44 |
dtantsur | lucasagomes, I'm starting to approve those patches, that are ready | 14:45 |
lucasagomes | dtantsur, np, can I break it after those first two get merged? they alreayd have a +2 | 14:45 |
lucasagomes | dtantsur, oh ok | 14:45 |
lucasagomes | dtantsur, thanks | 14:46 |
dtantsur | lucasagomes, am I the only one who feels that we have to much copy-paste there? | 14:47 |
dtantsur | (point for future refactoring, won't block now) | 14:47 |
lucasagomes | dtantsur, for the get_ stuff? | 14:47 |
lucasagomes | yeah hmm... I'm thinking of it as well, maybe I will create a helper function for that as part of the get_by_instance | 14:47 |
dtantsur | lucasagomes, in patches that fix self.fields both __init__ are nearly the same | 14:47 |
lucasagomes | dtantsur, ohh yeah well that's kinda true | 14:47 |
openstackgerrit | A change was merged to openstack/python-ironicclient: Trim trailing slash and version from endpoint https://review.openstack.org/107715 | 14:48 |
lucasagomes | dtantsur, that for loop that check if the attr exists maybe could exist in the base class | 14:48 |
lucasagomes | dtantsur, well I won't look at it now, I want to finish the db stuff first | 14:48 |
lucasagomes | but I will try to reduce the duplication on the db/object part | 14:48 |
dtantsur | lucasagomes, yes, sure | 14:49 |
jroll | hey so this patch is blocked on an ironicclient bug fix that was just approved https://review.openstack.org/#/c/105590/ | 14:57 |
jroll | but I need to wait for a new client release yes? | 14:57 |
matty_dubs | lucasagomes: Playing with FRU on an HP blade, I can get the serial numbers of all the DIMMs, but no network information. Going to try on a Dell box too | 14:57 |
matty_dubs | Bah, that's even less. | 14:58 |
NobodyCam | brb .... quick walkies | 14:58 |
lucasagomes | matty_dubs, oh, yeah if you use driver specific stuff you can do it | 14:58 |
lucasagomes | matty_dubs, ipmitool delloem mac list | 14:58 |
lucasagomes | but standard ipmi I don't think we can get the NIC information anywhere :( | 14:59 |
lucasagomes | (only the NIC info from the BMC itself, "ipmitool lan print") | 14:59 |
dtantsur | jroll, and maybe even bump version of ironicclient we depend on | 15:00 |
jroll | dtantsur: I don't think that's needed because we use >= | 15:08 |
dtantsur | jroll, I think we need new >=, otherwise you risk getting old ironicclient, which is broken with your code | 15:09 |
jroll | I guess sure | 15:11 |
jroll | I'm adding /nodes/detail to the client, think it's useful to also put in in the cli? | 15:12 |
jroll | lucasagomes: ^^ | 15:12 |
lucasagomes | jroll, I guess so, well the CLI is just a translation of our API | 15:13 |
lucasagomes | so I think it makes sense to make it available as well | 15:13 |
jroll | right | 15:13 |
jroll | just that table view with all fields seems not useful :P | 15:13 |
jroll | but I'll add it, I started already | 15:14 |
lucasagomes | jroll, right... well maybe if it's too messy to have in the CLI | 15:14 |
lucasagomes | like the tables etc we can skip it | 15:14 |
jroll | yeah, idk | 15:14 |
jroll | lucasagomes: someone might use it in a bash script :P | 15:14 |
lucasagomes | heh | 15:15 |
devananda | morning, all | 15:15 |
lucasagomes | devananda, morning, feeling better? | 15:15 |
NobodyCam | good morning devananda :) | 15:15 |
devananda | I'm going to be offline again this morning - another dr appt | 15:15 |
jroll | morning devananda | 15:15 |
jroll | :( | 15:15 |
NobodyCam | :( | 15:15 |
lucasagomes | oh | 15:15 |
lucasagomes | :/ | 15:15 |
devananda | yea :( | 15:16 |
*** mdorman has joined #openstack-ironic | 15:16 | |
* NobodyCam hopes devananda starts to feel better | 15:16 | |
devananda | lucasagomes: https://bugs.launchpad.net/ironic/+bug/1353631 | 15:16 |
* lucasagomes clicks | 15:17 | |
lucasagomes | devananda, oh crap x.x | 15:18 |
devananda | I should have caught that when reviewing the initial refactoring patch. it was pointed out that adding the iLO driver can't be done today without changing patcher.py, which is silly | 15:18 |
devananda | yea | 15:18 |
lucasagomes | devananda, +1 this is something that I could have helped with in the instance_info work. Like before all parameters were pxe stuff (pxe_root_gb) etc.. | 15:18 |
lucasagomes | yeah the instance info should really go to the base class | 15:18 |
devananda | i think you did the initial work on that | 15:18 |
lucasagomes | devananda, tho we still have the deploy_k&r in the pxe | 15:18 |
devananda | but it has been refactored a few times | 15:18 |
lucasagomes | but that can be deleted in kilo | 15:18 |
lucasagomes | devananda, yeah, it was | 15:18 |
devananda | it'll need to be updated here, too: https://review.openstack.org/#/c/111423/ | 15:19 |
devananda | I noted it on the whiteboard | 15:19 |
lucasagomes | devananda, yeah that's the problem, how we are sync'ing that changes ? | 15:19 |
lucasagomes | I mean... we want that for J or the driver is frozen? | 15:19 |
devananda | we need that now | 15:19 |
devananda | before it lands in nova | 15:20 |
lucasagomes | devananda, right, lemme take a look at it then | 15:20 |
dtantsur | devananda, morning | 15:20 |
devananda | 1) propose change in ironic. 2) WIP 111423 and post link. 3) land change in ironic 4) propose new version to 111423 | 15:20 |
devananda | and track all of it on the whiteboard | 15:20 |
lucasagomes | devananda, I will try to put a reference patch up today in Ironic and then we can see how we do to the nova driver | 15:21 |
lucasagomes | ok lemm | 15:21 |
devananda | thanks much. I'll poke at it when I get back -- just leave any notes around the "Nova Driver Progress" section | 15:21 |
lucasagomes | devananda, ack | 15:21 |
* devananda heads out to dr appt | 15:22 | |
lucasagomes | thanks for pointing that out | 15:22 |
lucasagomes | cause I had forgot that part of the driver | 15:22 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/python-ironicclient: Add /nodes/detail support https://review.openstack.org/112610 | 15:26 |
jroll | ^ not tested yet but should work :P | 15:26 |
*** ramineni1 has joined #openstack-ironic | 15:27 | |
*** ramineni has quit IRC | 15:28 | |
yuriyz | dtantsur, about Victor's patch. Are you worry about models != migrations? | 15:28 |
dtantsur | yuriyz, yep. previously for mysql we always got the latest state, no matter what current | 15:30 |
yuriyz | dtantsur, we have test for schema comparison https://review.openstack.org/#/c/107628/ | 15:32 |
dtantsur | yuriyz, I'm not talking about it. Imagine user has mysql database with some intermediate version | 15:33 |
dtantsur | yuriyz, before that patch, it was automagically upgraded. after it won't and user will start getting errors. | 15:33 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/python-ironicclient: Add /nodes/detail support https://review.openstack.org/112610 | 15:34 |
*** Mikhail_D_ltp has joined #openstack-ironic | 15:35 | |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/python-ironicclient: Add /nodes/detail support https://review.openstack.org/112610 | 15:36 |
lucasagomes | jroll, agent uses pxe_deploy_ramdisk and pxe_deploy_kernel options in driver info right? | 15:37 |
jroll | lucasagomes: it just uses deploy_ramdisk and deploy_kernel | 15:38 |
jroll | I'm ok with changing that if it helps you out | 15:38 |
lucasagomes | jroll, ack, cheers | 15:38 |
jroll | lucasagomes: but I think the pxe driver should s/pxe_// | 15:38 |
lucasagomes | jroll, nop... just because I'm taking a look at the patcher and I see there's a conditional there looking for 'agent' in the driver's name | 15:38 |
yuriyz | dtantsur, this user should use 'upgrade' command, not 'create_schema' | 15:39 |
lucasagomes | jroll, oh right... wait then | 15:39 |
jroll | lucasagomes: right | 15:39 |
lucasagomes | so you expect driver_info/deploy_kernel, driver_info/deploy_ramdisk ? | 15:39 |
jroll | lucasagomes: I *think* there may be a bug there if people are using flavor to define deploy k/r | 15:40 |
lucasagomes | not pxe_deploy_kernel pxe_deploy_ramdisk | 15:40 |
jroll | correct | 15:40 |
dtantsur | yuriyz, by user you mean `test code`. yes, that's why my comment on a patch :) | 15:40 |
lucasagomes | jroll, right so you expect that to be present in the driver info already and not coming from the flavor? | 15:40 |
jroll | lucasagomes: https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/agent.py#L81 | 15:40 |
dtantsur | yuriyz, https://review.openstack.org/#/c/107629/7/ironic/tests/base.py on line #91 it is create_schema | 15:40 |
jroll | lucasagomes: yes, I figured anyone deploying the agent can also make that change while they are changing the driver name in the db | 15:40 |
lucasagomes | jroll, alright, that's good | 15:41 |
lucasagomes | because we want to drop the flavor extra prameters to have deploy k&r | 15:41 |
jroll | indeed :) | 15:41 |
lucasagomes | we keep it now for backwards compat with icehouse | 15:41 |
lucasagomes | jroll, alright thanks :) | 15:41 |
jroll | np :) | 15:42 |
*** bvivek2 has quit IRC | 15:44 | |
* jroll brb | 15:44 | |
yuriyz | dtantsur, test code runs on test db (sqlite in memory currently) Test db is new fresh db. Old behavior is to create db from models also (line 95). | 15:47 |
*** matty_dubs is now known as matty_dubs|lunch | 15:47 | |
*** eghobo has joined #openstack-ironic | 15:50 | |
*** eghobo has quit IRC | 15:51 | |
openstackgerrit | Ilya Pekelny proposed a change to openstack/ironic: Test migrations with Alembic, using Oslo.db https://review.openstack.org/111984 | 15:51 |
*** eghobo has joined #openstack-ironic | 15:51 | |
*** shakamunyi has quit IRC | 15:51 | |
JayF | lucasagomes: I didn't read /all/ of scrollback, but I know on our machines FRU data has no knowledge whatsoever of nics | 15:52 |
lucasagomes | JayF, ah, right that's fine. That's all I needed to know really | 15:53 |
lucasagomes | JayF, with standard ipmi we can't find any info about NICs right? | 15:53 |
JayF | I don't think so, no. | 15:54 |
JayF | Although honestly in my case I'm using PCIe NICs, so it's possible it'd be different for someone with onboard | 15:54 |
lucasagomes | oh yeah | 15:55 |
lucasagomes | JayF, alright, thanks | 15:55 |
jroll | lucasagomes: all those fields aren't too horrible https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/agent.py#L81 | 15:55 |
dtantsur | yuriyz, it's quite easy to use mysql for testing and IIRC that's what I'm doing now (because of broken migrations) | 15:56 |
lucasagomes | jroll, hah, it's because I'm looking into the patcher.py for the driver | 15:56 |
lucasagomes | jroll, and there's a conditional there checking for 'agent' | 15:56 |
*** jistr has quit IRC | 15:56 | |
lucasagomes | if it's part of the driver's name | 15:56 |
jroll | lucasagomes: gah, that's not the link I meant to give you :| | 15:56 |
jroll | lucasagomes: https://www.dropbox.com/s/n8uslc0e1jbfedp/Screenshot%202014-08-07%2008.54.07.png | 15:58 |
lucasagomes | jroll, MUAHAH | 15:58 |
lucasagomes | jroll, yeah looks horrible :P | 15:58 |
jroll | lucasagomes: I've done way too many "select * from nodes" in mysql if I don't think it's horrible :( | 15:59 |
lucasagomes | jroll, maybe leave detail out of the CLI? | 15:59 |
jroll | lucasagomes: mehhhh, it doesn't look bad to awk | 15:59 |
lucasagomes | jroll, folks still can do list + show | 15:59 |
jroll | hmm, idk | 15:59 |
yuriyz | dtantsur, mysql can be used for "opportunistic" migrations test, not related for this patch | 16:00 |
dtantsur | yuriyz, mysql can be used for all unit tests, if I'm stuck with some older revision, will I now be forced to call dbsync before running tests? | 16:02 |
*** linggao has quit IRC | 16:02 | |
*** vinbs has joined #openstack-ironic | 16:04 | |
*** hemna has joined #openstack-ironic | 16:05 | |
*** vinbs_ has joined #openstack-ironic | 16:06 | |
yuriyz | dtantsur, I do not try mysql for unit tests (I think some problems with hardcoded 'id' field possible), but for unit tests new fresh db created from models should be used | 16:07 |
*** vinbs has quit IRC | 16:09 | |
*** vinbs_ is now known as vinbs | 16:09 | |
dtantsur | yuriyz, well, I can't reproduce it now, but I already got hit by it some time ago (even with sqlite). Will try to reproduce tomorrow. | 16:10 |
*** dtantsur is now known as dtantsur|afk | 16:10 | |
jroll | hmm, should we get this into our nova patches? https://review.openstack.org/#/c/108545/ | 16:10 |
openstackgerrit | Vladyslav Drok proposed a change to openstack/ironic: Add driver name on driver load exception https://review.openstack.org/112049 | 16:13 |
jroll | devananda: when you're back, wondering if you want me to get this review going quickly and get it into our nova patches before they land: https://review.openstack.org/#/c/108545/ | 16:13 |
*** dvorak has joined #openstack-ironic | 16:14 | |
*** ellenh has joined #openstack-ironic | 16:21 | |
*** ramineni1 has quit IRC | 16:25 | |
*** coolsvap has quit IRC | 16:26 | |
*** vinbs has quit IRC | 16:30 | |
*** coolsvap has joined #openstack-ironic | 16:31 | |
*** gp_ has quit IRC | 16:33 | |
*** marzif_ has quit IRC | 16:33 | |
openstackgerrit | A change was merged to openstack/ironic: Fix self.fields on API Chassis object https://review.openstack.org/112055 | 16:35 |
*** rameshg87 has joined #openstack-ironic | 16:39 | |
rameshg87 | jroll, NobodyCam, please have a look at the spec for ilo virtual media - ipa deploy spec: https://review.openstack.org/#/c/108445/ | 16:41 |
JayF | looking at this and curious as to how it fits into Ironic, in terms of scope: https://review.openstack.org/#/c/107981/9/specs/juno/drac-raid-mgmt.rst,cm | 16:46 |
JayF | I'm thinking it's OK because it's 1) OOB and 2) Hardware raid | 16:46 |
JayF | but curious if anyone else has any thoughts | 16:47 |
*** rameshg87 has quit IRC | 16:51 | |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Move the 'intance_info' fields to the GenericDriverFields https://review.openstack.org/112623 | 16:55 |
lucasagomes | devananda, https://review.openstack.org/112623 I'm currently testing it locally here... I added this link in the whiteboard in front of the link to the bug | 16:58 |
*** rakesh_hs has joined #openstack-ironic | 16:59 | |
*** coolsvap has quit IRC | 17:04 | |
jroll | lucasagomes: hmmm, I don't seem to be able to run stack.sh with ipxe enabled :/ | 17:04 |
lucasagomes | jroll, why not? | 17:04 |
jroll | not sure... it installs ironicclient and then jumps straight to cleaning up | 17:05 |
lucasagomes | jroll, ouch is it a fresh install? | 17:05 |
jroll | lucasagomes: https://gist.github.com/jimrollenhagen/9889fffbbc29d73a0ae2 | 17:05 |
jroll | not a fresh install :/ | 17:05 |
jroll | so I wonder if that's related, but I still think there might be a bug | 17:06 |
JayF | 2014-08-07 17:03:15.137 | ++ sudo a2dissite ironic | 17:06 |
JayF | 2014-08-07 17:03:15.176 | ERROR: Site ironic does not exist! | 17:06 |
lucasagomes | jroll, and it pass that ^ without the IRONIC_IPXE_ENABLED? | 17:06 |
jroll | I can figure out the issue, don't worry about it... but hard to tell if this is a problem with the ironic patch or devstack patch | 17:06 |
lucasagomes | yeah | 17:06 |
jroll | yeah, without IRONIC_IPXE_ENABLED it's fine | 17:06 |
jroll | I think it's a devstack issue | 17:06 |
lucasagomes | jroll, I'm currently testing another thing here for the driver | 17:06 |
JayF | oh that's part of the cleanup | 17:06 |
jroll | JayF: yeah, the problem is why is it jumping to cleanup | 17:07 |
lucasagomes | but I can give it a go as soon as I finish it | 17:07 |
JayF | Weird. | 17:07 |
*** coolsvap has joined #openstack-ironic | 17:07 | |
lucasagomes | jroll, that seems to be some apache thing | 17:07 |
jroll | lucasagomes: I think the issue is that it's running cleanup | 17:08 |
* jroll looks again | 17:08 | |
JayF | lucasagomes: I think it's a red herring; it started cleanup really early, so it never added the site to disable it | 17:08 |
lucasagomes | JayF, yeah, maybe the cleanup on the devstack patch should be more smart and check if the site is there | 17:08 |
lucasagomes | before trying to remove it | 17:08 |
lucasagomes | I can do some sanity check on that area | 17:08 |
jroll | well, that too | 17:08 |
jroll | but the question is, should cleanup be run then at all | 17:09 |
lucasagomes | jroll, it probably will clean up other stuff... | 17:09 |
*** penick has joined #openstack-ironic | 17:09 | |
lucasagomes | but yeah I can hmm give it a shot after finishing it | 17:09 |
jroll | yeah but cleanup_ironic is being run | 17:09 |
jroll | which is triggered by devstack "clean" | 17:09 |
* jroll digs | 17:10 | |
jroll | brb | 17:11 |
lucasagomes | alright I'm heading home (came to the office today) | 17:18 |
lucasagomes | jroll, I will try it with a fresh install later | 17:18 |
lucasagomes | devananda, it seems to work... I'm going home now, but I will get online once I get there | 17:19 |
lucasagomes | good night everybody | 17:20 |
jroll | lucasagomes: yeah no worries | 17:20 |
jroll | want me to push a new patch if I find the issue? | 17:20 |
*** lucasagomes has quit IRC | 17:21 | |
*** pelix has quit IRC | 17:24 | |
*** linggao has joined #openstack-ironic | 17:26 | |
openstackgerrit | A change was merged to openstack/ironic: Fix self.fields on API Port object https://review.openstack.org/112056 | 17:27 |
devananda | back | 17:27 |
NobodyCam | good news from doc? | 17:37 |
devananda | I now have strep, they think. | 17:38 |
devananda | but hey, the pneumonia is cleared up | 17:38 |
jroll | :( | 17:38 |
NobodyCam | oh no :( | 17:38 |
NobodyCam | strep can be a real bugger | 17:39 |
jroll | there's a pun there | 17:39 |
*** matty_dubs|lunch is now known as matty_dubs | 17:40 | |
openstackgerrit | Devananda van der Veen proposed a change to openstack/ironic: Move the 'instance_info' fields to GenericDriverFields https://review.openstack.org/112623 | 17:40 |
* devananda updates commit message | 17:40 | |
devananda | JayF: fyi, you can update commit messages directly in gerrit | 17:41 |
devananda | click the little pen-and-paper icon | 17:41 |
devananda | for nits, that's generally much easier than waiting for the author | 17:41 |
devananda | jroll: can you take a look at ^ and give it a local test with IPA? | 17:42 |
JayF | devananda: ah, cool. Thanks | 17:42 |
jroll | devananda: at a glance, no reason that shouldn't work, but yeah give me a minute | 17:43 |
NobodyCam | brb | 17:46 |
mgagne | is there a way to run both nova (libvirt) and nova (ironic) in the same cell/region? | 17:52 |
devananda | mgagne: ironic requires a different scheduler HostManager class | 17:54 |
*** Alexei_987 has quit IRC | 17:54 | |
devananda | mgagne: and afaik, most folks are leaning towards isolationg that at the cell level. that being said, I have been told that Nova can support it with host-aggregates | 17:54 |
mgagne | devananda: sure, I saw a logic to use the "right" host_state class | 17:54 |
devananda | mgagne: and I think some folks from IBM talked about their work to do it at the last summit | 17:55 |
jroll | my guess is that it's not worth the trouble, but I say that as someone who already is running cells | 17:55 |
jroll | so maybe running cells is more trouble than that | 17:55 |
mgagne | devananda: yes, I was more/less looking at host aggregates but the linear nature of the scheduler makes it a non-trivial task | 17:55 |
devananda | their talk was more of a "here's all the broken stuff we ran into" | 17:55 |
devananda | bu tI haven't seen any patches come from them :( | 17:55 |
*** athomas has quit IRC | 17:55 | |
mgagne | devananda: but maybe I don't want my 10000 baremetal nodes polluting my nova database already used for virtual machines =) | 17:56 |
devananda | mgagne: I don't follow you | 17:56 |
mgagne | devananda: isn't ironic inventory synced to nova? | 17:56 |
devananda | mgagne: also - you have 10k nodes you're going to use with ironic? awesome | 17:57 |
devananda | mgagne: oh gods no | 17:57 |
devananda | mgagne: except sort of | 17:57 |
mgagne | devananda: I like to make it looks like I'm important =) | 17:57 |
devananda | mgagne: nova views each ironic node as a distinct hypervisor | 17:57 |
mgagne | devananda: lets say it's not a small install I'm looking for | 17:57 |
mgagne | devananda: yes and although it could be possible to use the same cell to manage both libvirt and "ironic" hypervisors, it might not be a good idea for those reasons | 17:58 |
devananda | right | 17:58 |
devananda | mgagne: you will get 1 record in the nova db for each ironic node. | 17:59 |
devananda | fwiw, there's a known issue right now where the periodic hypervisor stats update takes O(N) time | 17:59 |
devananda | since it loops linearly through all the hypervisor hosts (essentially every single node in ironic) | 17:59 |
mgagne | devananda: right so ironic nodes are asynchronously copied to Nova | 18:00 |
devananda | mgagne: not copied | 18:00 |
mgagne | devananda: inserted ? | 18:00 |
devananda | some metadata is cached | 18:00 |
devananda | ironic and nova have competely separate databases | 18:00 |
mgagne | devananda: ironic nodes are asynchronously "introduced" to Nova. better? =) | 18:00 |
devananda | nova stores a record for each (host, hypervisor_hostname) today -- regardless of hypervisor | 18:01 |
devananda | the difference for ironic is, instead of N compute hosts, you have 1 (or 2), but then a bagillion unique hypervisor_hostname | 18:01 |
mgagne | devananda: ok so I might also encounter performance/scalability issues in Nova when scheduling virtual machines if I have too many ironic nodes. | 18:01 |
devananda | +in the same cell. yes. | 18:02 |
devananda | hypothetically. since i haven't tried it | 18:02 |
mgagne | devananda: alright. I'm now more knowledgeable about the subject. all that's remaining to do is choose between an all-in-one nova or dedicated cells based on those details. | 18:03 |
jroll | well | 18:03 |
jroll | mgagne: so you're thinking you would have both ironic and VM stuff in the same nova-compute? | 18:03 |
devananda | Shrews: I see you've been maintaining https://review.openstack.org/#/c/94439/ -- how does that relate to all the work being tracked on https://etherpad.openstack.org/p/IronicCI ? | 18:03 |
jroll | ignore me, that doesn't make sense | 18:04 |
mgagne | jroll: I'm looking for info about what this kind of setup would imply | 18:04 |
devananda | jroll: same cell/region, i think was the question | 18:04 |
jroll | right | 18:04 |
jroll | I'm just trying to think about what we've seen | 18:04 |
devananda | mgagne: also consider neutron | 18:04 |
jroll | we see perf issues in n-cpu | 18:04 |
mgagne | devananda: oh you | 18:04 |
jroll | but not so much in the scheduler | 18:04 |
Shrews | devananda: it's kind of separate. i'm just having trouble getting reviews on it. only so much i can poke before i get annoying | 18:04 |
jroll | but that's separate cells | 18:05 |
devananda | mgagne: :) | 18:05 |
devananda | Shrews: :-/ | 18:05 |
jroll | just throw neutron out the window :) | 18:05 |
* mgagne defenestrates neutron | 18:06 | |
devananda | lol | 18:06 |
jroll | ha | 18:06 |
*** lucasagomes has joined #openstack-ironic | 18:06 | |
jroll | mgagne: can I ask how large of a deployment y'all are planning? | 18:07 |
jroll | mgagne: because, with the state of things today, I don't think I'd recommend more than 1000 ironic nodes in a single cell, without configuring very very carefully. and even then, idk. | 18:08 |
jroll | hopefully that data point helps a bit :P | 18:09 |
mgagne | jroll: we are still in the planning phase so we are looking for experience and info about scalability and good practices | 18:09 |
JayF | Well we're the largest install of Ironic that's willing to talk about it, and jroll is right in cautioning about perf issues right now | 18:10 |
jroll | mgagne: I work on rackspace's onmetal, so | 18:10 |
jroll | happy to help :) | 18:10 |
* jroll needs to blog about this more | 18:11 | |
mgagne | JayF: I attended most of the talks planning about scalability issues in Nova and how cells kind of fixed (in its way) those issues | 18:11 |
mgagne | jroll: what the hell is rackspace? | 18:11 |
JayF | mgagne: seriously? | 18:11 |
mgagne | jroll: =) | 18:11 |
mgagne | no | 18:11 |
JayF | lol | 18:11 |
*** f13o_ has joined #openstack-ironic | 18:11 | |
jroll | mgagne: just another hosting provider (tm) | 18:12 |
mgagne | jroll: =) | 18:12 |
*** rakesh_hs has quit IRC | 18:14 | |
*** krtaylor has quit IRC | 18:18 | |
JayF | devananda: would be interested in your input on https://review.openstack.org/#/c/107981/9 especially w/r/t ironic scope | 18:19 |
devananda | jroll: that 1k limit seriously irks me. | 18:21 |
devananda | jroll: we need to fix that | 18:21 |
devananda | ironic should, by itself, scale WAY more than that | 18:22 |
JayF | I think the details stuff + making the bmc power status loop parallel will go a long way... to getting us to the next bottleneck :) | 18:22 |
devananda | JayF: ooh. right. I should probably go block a bunch of specs soon. is today the deadline? | 18:23 |
devananda | or did I say it was next week? | 18:23 |
* devananda wants it to be today | 18:23 | |
JayF | I honestly don't remember at all | 18:23 |
jroll | devananda: this lgtm https://review.openstack.org/#/c/112623/ | 18:23 |
jroll | devananda: right, what JayF said | 18:23 |
devananda | awesome, tyvm | 18:23 |
JayF | devananda: there's also a thread on ML about someone asking for an exception for a driver with an exceptionally large scope... me and dtantsur|afk basically told them no | 18:23 |
jroll | devananda: new spec deadline was july 24, spec approval deadline is like sept 3 | 18:23 |
jroll | devananda: according to the timeline doc | 18:24 |
jroll | slash etherpad | 18:24 |
devananda | jroll: er, sept 3 is when we tag J3 | 18:24 |
devananda | that should not be the spec approval deadline | 18:24 |
devananda | it was two or three weeks ago for nova (exceptions notwithstanding) | 18:25 |
* jroll looks again | 18:25 | |
devananda | JayF: right. i haven't opened email today :( | 18:25 |
jroll | devananda: that's what I got out of this, but it's not explicit https://etherpad.openstack.org/p/3sxKH2po1o | 18:25 |
JayF | devananda: it's okay, we're spreading around the work of being a bad cop ;) | 18:25 |
devananda | heh | 18:25 |
lucasagomes | jroll, thanks for testing that patch with IPA | 18:26 |
jroll | lucasagomes: np :) | 18:26 |
jroll | we should get it in the check jobs | 18:26 |
* jroll finds reviews and pokes people | 18:26 | |
lucasagomes | jroll, right, but we are not testing ipa in the gate jobs right? | 18:27 |
jroll | right, not yet | 18:27 |
JayF | Soon. | 18:27 |
jroll | need some merges | 18:27 |
lucasagomes | I should have pinged you, when I did that change sorry | 18:27 |
JayF | Basically we'll test IPA and PXE in the gate for Ironic | 18:27 |
lucasagomes | yeah... we really should run that in gate | 18:27 |
lucasagomes | JayF, +1 | 18:27 |
JayF | IPA gate will test tempest w/IPA with all commonly used images (DIB+CoreOS) | 18:27 |
jroll | lucasagomes: no worries :) | 18:27 |
JayF | and Nova gate will test tempest w/default Ironic driver at the time | 18:27 |
devananda | JayF: you should write that plan somewhere :) | 18:28 |
lucasagomes | JayF, sounds good :) | 18:28 |
JayF | You mean IRC doesn't count? :P | 18:28 |
* JayF will put it in the ipa etherpad | 18:28 | |
devananda | this channel is logged.... but no | 18:28 |
jroll | noca gate? | 18:28 |
jroll | nova* | 18:28 |
jroll | or do you mean ironic gate? | 18:28 |
lucasagomes | JayF, it's on eavesdrop right? hah jk | 18:28 |
JayF | jroll: Nova gate == tempest against default Ironic driver. | 18:29 |
devananda | jroll: he means nova gate. except that it's -nv today. | 18:29 |
jroll | you know what would be killer... | 18:29 |
devananda | JayF: I mean like the mailing list | 18:29 |
JayF | jroll: Ironic gate == tempest against pxe and IPA ironig drivers (IPA would use DIB) | 18:29 |
jroll | put eavesdrop logs in elastic search | 18:29 |
JayF | devananda: ah, I'll do that :) | 18:29 |
devananda | thanks! | 18:29 |
lucasagomes | and iPXE on the gate as well yay | 18:29 |
JayF | jroll: IPA gate == tempest against IPA with all the commonly used images (I'd suspect an ISO would be fairly hard to test in gate) | 18:29 |
jroll | JayF: you ok with using coreos version in ironic gate until we get dib working? | 18:29 |
jroll | JayF: right, got it | 18:29 |
JayF | jroll: I'm very OK with that personally, but if it requires more ram, that might be a question for -infra | 18:30 |
devananda | so | 18:30 |
jroll | JayF: ironic was using 1024 for a while, should be fine | 18:30 |
JayF | okay | 18:30 |
jroll | as a temp thing | 18:30 |
devananda | as a graduation req, ironic needs to be able to run parallel tempest in the gate | 18:30 |
devananda | which means 6 nodes | 18:30 |
jroll | right ^^ | 18:30 |
devananda | at 512 MB RAM each | 18:30 |
devananda | BUT | 18:30 |
devananda | that doesn't have to apply to ALL our jobs | 18:30 |
devananda | just one | 18:31 |
jroll | was just going to say that | 18:31 |
jroll | baby steps | 18:31 |
JayF | cool. so DIB isn't in the critical path for IPA tempest | 18:31 |
lucasagomes | +1 | 18:31 |
*** penick has quit IRC | 18:32 | |
devananda | i think we should run tempest parallel on all our drivers in our gate. but steps are better than waterfalls. | 18:33 |
devananda | also, i'm mixing metaphors again | 18:33 |
jroll | I'm going to copy these here so that y'all can take a look too :) | 18:33 |
jroll | 11:28:13 jroll | can I get some eyes on a couple of devstack patches? working on the road to getting the ironic agent in the gate | 18:33 |
jroll | 11:28:13 jroll | https://review.openstack.org/#/c/112095/ | 18:33 |
jroll | 11:28:17 jroll | https://review.openstack.org/#/c/108457/ | 18:33 |
jroll | devananda: lolmetaphors | 18:34 |
jroll | bbiab | 18:34 |
lucasagomes | aight, brb going to eat something | 18:34 |
devananda | jroll: for the swift tempurl patch, you get notmyname to see it yet? | 18:34 |
*** lucasagomes is now known as lucas-dinner | 18:34 | |
devananda | lucas-dinner: g'night! | 18:34 |
lucas-dinner | devananda, g'night! oh and thanks for updating the commit message there | 18:35 |
devananda | np | 18:35 |
devananda | jroll: shouldn't there be a default avlue on this line? SWIFT_TEMPURL_KEY=${SWIFT_TEMPURL_KEY} | 18:38 |
jroll | devananda: thinking no, it ends up making a random key if one does not exist | 18:41 |
jroll | devananda: just like password things | 18:41 |
* jroll bugs notmyname | 18:41 | |
devananda | jroll: oh | 18:41 |
devananda | really? | 18:41 |
jroll | yes? | 18:41 |
devananda | https://review.openstack.org/#/c/112095/3/stack.sh | 18:41 |
devananda | calls read_password | 18:41 |
jroll | yeah | 18:41 |
jroll | that function has a horrible name :) | 18:42 |
jroll | it also sets the password randomly if the user doesn't enter one | 18:42 |
devananda | ah ok | 18:42 |
*** ellenh has quit IRC | 18:43 | |
*** ndipanov has quit IRC | 19:15 | |
*** krtaylor has joined #openstack-ironic | 19:20 | |
*** faizan has joined #openstack-ironic | 19:21 | |
*** faizan has quit IRC | 19:30 | |
adam_g | devananda, https://review.openstack.org/#/c/112575/ is something like this actually needed? | 19:32 |
openstackgerrit | A change was merged to openstack/ironic: Move the 'instance_info' fields to GenericDriverFields https://review.openstack.org/112623 | 19:36 |
*** ellenh has joined #openstack-ironic | 19:46 | |
*** slagle has joined #openstack-ironic | 19:48 | |
NobodyCam | anyone have objection to uefi spec. I think its looking good. have one +2 so with out objection I'll land it.. | 19:49 |
slagle | i had a tripleo deployment go wrong, and now my ironic nodes are stuck in "power on" and "deploying" | 19:52 |
slagle | i can't change the power state or provision state because they're locked | 19:53 |
slagle | any way to get around this? | 19:53 |
NobodyCam | slagle: I fix that with cleanup-env | 19:53 |
NobodyCam | :( | 19:53 |
slagle | how does that interact with ironic? | 19:53 |
slagle | cleanup-env doesn't make any ironic api calls does it? | 19:53 |
NobodyCam | are you using devtest | 19:54 |
slagle | yes | 19:54 |
NobodyCam | no it wipes out the vm's | 19:54 |
slagle | cleanup-env just deletes the baremetal vm's | 19:54 |
NobodyCam | ya then I rerun devtest.sh -c --trash-my-blah | 19:54 |
NobodyCam | so I get a new env | 19:55 |
adam_g | slagle, this is a fallback i use to complete wipe my nova/ironic state: http://paste.ubuntu.com/7982432/ | 19:55 |
slagle | so build a whole new seed? | 19:55 |
slagle | that's one way i guess | 19:55 |
slagle | looking for something a bit more elegant than reinstalling :) | 19:55 |
NobodyCam | :-p | 19:55 |
slagle | adam_g: yea, i had a similar thing for nova-bm | 19:56 |
slagle | ok, i can try that | 19:56 |
slagle | do we think this behavior is a bug? | 19:56 |
slagle | e.g. "impossible to delete or power off a node" | 19:56 |
adam_g | slagle, definitely not ideal but usually unblocks me | 19:56 |
*** penick has joined #openstack-ironic | 19:57 | |
adam_g | slagle, oh, also make sure the associated neutron ports have been deleted before re-deploying | 19:57 |
NobodyCam | no objections ... uefi spec landing... (bp name also checked, hehehehe) | 20:00 |
openstackgerrit | A change was merged to openstack/ironic-specs: UEFI support for Ironic deploy drivers https://review.openstack.org/99850 | 20:02 |
NobodyCam | brb | 20:03 |
adam_g | yuriyz, heads up. since he's gone for 2 weeks, i'm going to start pushing some changes to romcheg's review @ https://review.openstack.org/#/c/112402/ | 20:08 |
aweeks | I'm about to push a spec (related to https://blueprints.launchpad.net/ironic/+spec/ipa-ssl-and-client-certs) that seems unlikely to be part of juno. No one has created the specs/kilo folder in the ironic-specs repo, is there any reason I shouldn't create it, and put my spec in there? | 20:18 |
devananda | lucas-dinner: when you're around, can you explain why, in nova.virt.ironic.driver we use icli.call("node.$FUNCTION", params) rather than calling node.$FUNCTION(params) directly? | 20:19 |
aweeks | devananda: ^ I'm not sure who else I ought to ping for that | 20:19 |
devananda | lucas-dinner: I reread the client libs just now and it looks like that should work... | 20:19 |
devananda | aweeks: hi! so spec proposals are going to be frozen shortly | 20:20 |
devananda | and we're not going to be reviewing specs for Kilo until closer to the summit | 20:20 |
JayF | aweeks is one of the onmetal folks if you haven't met him yet :) | 20:20 |
aweeks | devananda: yeah, that's not an issue, but I figure I should put it somewhere in the meantime | 20:20 |
devananda | so feel free to propose it, but it'll just get -2'd and ignored until we open kilo discussions | 20:20 |
devananda | sure | 20:20 |
devananda | that reminds me, i need to email about spec freeze. more things on my list of things that i need to do instead of getting healthy ... | 20:21 |
* devananda goes back to fixing up the nova driver patches | 20:21 | |
JayF | when is the spec freeze? | 20:21 |
devananda | and ignoring his coroporate emails | 20:21 |
JayF | I can send an email about that when I send an email about the testing stuff, if you'd like? | 20:21 |
aweeks | devananda: ok, thanks | 20:22 |
*** davidlenwell_ is now known as davidlenwell | 20:23 | |
devananda | JayF: based on my email "Juno priorities..." a month ago, I said we'd stop approving any more specs on Aug 14 | 20:25 |
devananda | JayF: but I think we already have a lot approved and not yet implemented | 20:25 |
JayF | We certainly do, I think because since the mid-cycle we've been trying to get them through before the deadline. At least give the implementor a shot at making a code deadline for juno :) | 20:26 |
devananda | ++ | 20:27 |
devananda | I'd like to propose that we bump the cut off to monday after the meeting | 20:27 |
devananda | but i'll propose that at the meeting | 20:27 |
*** Mikhail_D_ltp has quit IRC | 20:27 | |
* devananda punts on writing an email about it now | 20:27 | |
NobodyCam | devananda: are we bumping up the spec deadline, Should I not have approved the one I just did? | 20:27 |
openstackgerrit | Alex Weeks proposed a change to openstack/ironic-specs: Added IPA ssl/client certificate spec https://review.openstack.org/112682 | 20:28 |
devananda | NobodyCam: "to monday after the meeting" | 20:28 |
NobodyCam | ack. | 20:28 |
mgagne | devananda: sorry for delayed reply: we are already managing way more than 1000 nodes with our existing system (not ironic). So I guess Ironic will have to handle much more than that to be useful and not be an everyday scalability pain | 20:28 |
JayF | mgagne: Please then, help us, hang out. We have similar plans at Rackspace to scale up Ironic to larger numbers than that :) | 20:29 |
devananda | mgagne: do you need to use Nova with Ironic in this future world? | 20:29 |
mmitchell | devananda: yes | 20:30 |
mmitchell | devananda: (mgagne and I work at the same place ;)) | 20:31 |
mgagne | JayF: I'm just an operator which happens to have a strong programming background and designed a bunch of systems to automate baremetal deployment. I unfortunately didn't get assigned full time to the baremetal on openstack effort yet. I'm currently offering (moral) support to my fellow coworkers atm | 20:31 |
mgagne | devananda: mmitchell is one of the said coworkers | 20:31 |
devananda | cool. well, please do hang out and help us make ironic and nova better | 20:32 |
mgagne | devananda: I want to make all openstack better =) | 20:32 |
NobodyCam | mgagne: this may have been asked already but what hardware are you running .. if I may ask | 20:32 |
mgagne | NobodyCam: it's currently in dev phase so it's running in kvm | 20:33 |
NobodyCam | :) | 20:33 |
JayF | mgagne: I'm in the same boat, except lucky for me Rackspace enabled me to expand into software development and to work full-time on Ironic (well, and our product, which is built on Ironic). You can get some moral support from me in trying to get time to work on Ironic :P | 20:33 |
mgagne | JayF: I'm still happy though, I operate and tweak our current openstack infrastructure which is a full time job by itself. If only I could get more than 24h per day =) | 20:34 |
mmitchell | NobodyCam: plan is to re-use current already deployed inventory, so only PDU control and PXE boot control, no IPMI | 20:36 |
JayF | we should support, even with a driver like IPA | 20:37 |
JayF | a blanket-chainload pxe thing | 20:37 |
JayF | where anything that tries to pxe would get a chainload configuration back by default, unless ironic was trying to boot a deploy ramdisk | 20:38 |
devananda | mmitchell: single (trusted) tenant? | 20:38 |
mgagne | devananda: no, it's not for private consumption | 20:39 |
mgagne | JayF: yep, it was one of the idea we had back then before Ironic exists =) | 20:40 |
mgagne | JayF: always boot PXE and chainload to disk if no deployment request is set | 20:40 |
JayF | mgagne: we had similar thoughts in the early days of our product planning for onmetal before we went ironic | 20:40 |
devananda | JayF: I think that's a perfectly reasonable setting to enforce | 20:41 |
JayF | it would, paired with a good pdu driver, be all the pieces needed to get servers without a bmc provisioned | 20:42 |
mgagne | JayF: one of our other products consists of a single tenant/virtual machine with added values and the DHCP/PXE "problem" was approached from a different angle. The idea was to give 100% of the disk to the customer for reasons still obscure as of today. | 20:43 |
JayF | I'm not sure I understand. | 20:43 |
mgagne | JayF: one host, one VM, one tenant | 20:44 |
mgagne | JayF: so you can market it as a dedicated host with "added value" | 20:44 |
mmitchell | mgagne: the initial requirement (that was dropped) was booting off that disk directly without the hypervisor | 20:44 |
devananda | mgagne: all the benefits of managing VMs, none of the headache of bad neighbors | 20:44 |
mgagne | mmitchell: I like to keep mystery around those details =) | 20:45 |
mgagne | devananda: yep | 20:45 |
devananda | mgagne: downside is you still get the poor performance (for some workloads) of being in a VM | 20:45 |
mmitchell | mgagne: no need to be secretive here ;) | 20:45 |
mgagne | JayF: one guy had a great idea to avoid all-time DHCP/PXE boot which consisted of installing a second small disk with a bootloader chain loading Xen and VM | 20:45 |
mgagne | devananda: don't start me on benchmarking.... | 20:45 |
mgagne | devananda: I spent months doing benchmarking and trying to explain all sort of weird behaviour especially one where the RAM disappeared and couldn't be accounted for. | 20:46 |
mmitchell | there's some ascii art of ram allocation in some xen .c file somewhere | 20:46 |
mmitchell | fun times | 20:47 |
*** krtaylor has quit IRC | 20:47 | |
JayF | mgagne: that makes sense :) | 20:48 |
*** ellenh has left #openstack-ironic | 20:53 | |
*** ellenh has joined #openstack-ironic | 20:53 | |
lucas-dinner | devananda, hey there, hmm I'm not sure... That's the ClientWrapper right? I think Shrews may be able to explain it. I'm not sure the reason why we use the icli.call("<cli command>" [,<cli args>,]) syntax | 20:56 |
lucas-dinner | devananda, but yeah, I also think that icli.<command> looks more straight forward | 20:56 |
lucas-dinner | I mean... node.$FUNCTION | 20:56 |
Shrews | lucas-dinner: there was a reason... but i'm fuzzy on it now | 20:57 |
Shrews | lucas-dinner: i think it had to do with the multiple levels of api calls: icli.node.<command>, icli.driver.<command>, etc | 20:57 |
* NobodyCam recalls that was done when we switched to the wrapper | 20:58 | |
NobodyCam | but I may be wrong | 20:58 |
Shrews | i missed deva's question about it though | 20:58 |
lucas-dinner | Shrews, I c yeah it sounds like it could be it | 20:58 |
lucas-dinner | <devananda> lucas-dinner: when you're around, can you explain why, in nova.virt.ironic.driver we use icli.call("node.$FUNCTION", params) rather than calling node.$FUNCTION(params) directly? | 20:59 |
lucas-dinner | <devananda> lucas-dinner: I reread the client libs just now and it looks like that should work... | 20:59 |
devananda | Shrews: I see lots of places using icli.call("node.$FUNCTION") | 20:59 |
lucas-dinner | Shrews, ^ | 20:59 |
devananda | yea | 20:59 |
devananda | thanks :) | 20:59 |
lucas-dinner | NobodyCam, yea it was, before we used the ironic client libs directly, but we had a mechanism to retry commands and it was duplicated all around the code. So the ClientWrapper was a convinent way to encapsulate that logic in one place | 21:00 |
Shrews | yeah, it was the muti-level attribute thing. if someone can come up with a way to not use the strings, i'm all for it | 21:00 |
lucas-dinner | +1, I wouldn't do it now that we want the driver merged in nova | 21:01 |
lucas-dinner | but for the future yeah, change that sytax makes sense to me | 21:01 |
devananda | if this is what we expect a user of our client libs to do, it seems like we didn't make them very user-friendly | 21:02 |
devananda | I don't think it is what we expect, though | 21:03 |
*** iron1 has joined #openstack-ironic | 21:03 | |
lucas-dinner | devananda, yeah :/ well the problem was the retry on Conflict | 21:03 |
devananda | ahh | 21:03 |
lucas-dinner | unless we make the libs itself retry the requests | 21:03 |
lucas-dinner | I don't see any other way | 21:03 |
devananda | and this icli.call("string") was the work around? | 21:03 |
Shrews | yeah, that was the whole reason for the wrapper | 21:03 |
lucas-dinner | devananda, yes | 21:03 |
devananda | gotcha | 21:03 |
devananda | thanks | 21:04 |
lucas-dinner | yw | 21:04 |
* lucas-dinner brb | 21:04 | |
*** jasondotstar has quit IRC | 21:04 | |
openstackgerrit | Ellen Hui proposed a change to openstack/ironic: Make DHCP provider pluggable https://review.openstack.org/112351 | 21:06 |
openstackgerrit | Devananda van der Veen proposed a change to openstack/ironic: backport reviewer comments on nova.virt.ironic.patcher https://review.openstack.org/112691 | 21:10 |
*** linggao has quit IRC | 21:11 | |
openstackgerrit | Adam Gandelman proposed a change to openstack/ironic: Script to migrate Nova BM data to Ironic https://review.openstack.org/112402 | 21:12 |
jroll | adam_g: mind looking at https://review.openstack.org/#/c/112693/ when you have a moment? | 21:16 |
adam_g | jroll, sure | 21:17 |
jroll | thanks | 21:20 |
*** matty_dubs is now known as matty_dubs|gone | 21:23 | |
*** penick has quit IRC | 21:23 | |
adam_g | jroll, i assume having no postgres coverage is okay? | 21:24 |
jroll | adam_g: if I'm using mysql-specific code in the ipa driver, please hurt me | 21:25 |
JayF | adam_g: if ipa but not pxe broke with postgres vs mysql, that'd be a layering problem, right? | 21:25 |
jroll | :) | 21:25 |
adam_g | sure | 21:26 |
jroll | JayF: btw, that's not the ideal config we want to get to, but it's a start | 21:27 |
*** penick has joined #openstack-ironic | 21:28 | |
*** foexle has quit IRC | 21:28 | |
*** ellenh has quit IRC | 21:41 | |
NobodyCam | humm any one have a way to test the ipmi double bridging patch? | 22:03 |
JayF | sounds like an experimental driver to me ;) | 22:03 |
NobodyCam | https://review.openstack.org/#/c/95775 :0p | 22:04 |
JayF | "anyone have a way to test $any_power_driver" == no :( | 22:04 |
NobodyCam | heheehe | 22:04 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/python-ironicclient: Add /nodes/detail support https://review.openstack.org/112610 | 22:04 |
*** ellenh has joined #openstack-ironic | 22:04 | |
jroll | devananda: ^^ thanks for that review | 22:04 |
devananda | NobodyCam: jbjohnso might. or some folks at Intel. | 22:08 |
NobodyCam | ahh TY | 22:09 |
devananda | JayF: yes. well. no. since ya'll DO some db work in the IPA driver | 22:09 |
JayF | devananda: RFR if you have a moment, otherwise I'll happily send as-is: https://gist.github.com/jayofdoom/8578420ef4e37ea589f6 | 22:10 |
jroll | devananda: we call dbapi | 22:10 |
jroll | so I guess if some dbapi function is broken in postgres, that only ipa uses... | 22:10 |
*** rwsu has quit IRC | 22:10 | |
devananda | JayF: some of the terminology there around what gates what may be worth revising | 22:12 |
devananda | JayF: as that's not exactly how it works, and not how infra/QA folks refer to it | 22:12 |
devananda | JayF: https://etherpad.openstack.org/p/NvDZB5gox0 | 22:13 |
jroll | ah yeah... s/gate/check jobs/ | 22:13 |
devananda | that's part of it :) | 22:13 |
jroll | we won't be gating on it at all to begin with | 22:13 |
*** rwsu has joined #openstack-ironic | 22:15 | |
JayF | is there some nutty bug in etherpad? my cursor keeps moving without me moving it | 22:16 |
JayF | jroll: ^ can you update 112693 to reflect deva's suggestion in the etherpad | 22:17 |
NobodyCam | JayF: do you have a bluetooth mouse? | 22:18 |
*** krtaylor has joined #openstack-ironic | 22:18 | |
JayF | NobodyCam: heh, no. Although I have a hilarious story about that... I work beside the office supply room and had a stored touchpad that was paired to my box and doing funky things | 22:19 |
NobodyCam | lol ++++ | 22:19 |
jroll | JayF: done | 22:20 |
jroll | NobodyCam: one time I was sitting across the room from my desk, logged into production... keyboard started going nuts so I just panicked and ctrl-d as quick as I could | 22:20 |
NobodyCam | I have one case where someone had two BT keyboards and set something on one of them and was getting "aaaaaaaaa"'s across there screen | 22:20 |
jroll | turned out the cleaning crew was wiping my keyboard down | 22:20 |
NobodyCam | lol | 22:21 |
NobodyCam | nice | 22:21 |
JayF | I don't think I've ever seen jroll move so fast | 22:21 |
JayF | he jumped up like he was stung by a bee | 22:21 |
jroll | yeah dude | 22:21 |
NobodyCam | hehehheeh | 22:21 |
jroll | it was a mysql shell | 22:21 |
jroll | panic mode | 22:21 |
NobodyCam | oh ya | 22:21 |
NobodyCam | drop table *$^#$&#$^&$%*&*$% | 22:22 |
NobodyCam | ieek | 22:22 |
jroll | lol | 22:22 |
JayF | devananda: thanks for the edits, that's a bunch better with a few changes :) | 22:27 |
devananda | JayF: think i'm done comment/editing | 22:27 |
devananda | :) | 22:27 |
devananda | yvw | 22:27 |
JayF | devananda: only question is | 22:27 |
openstackgerrit | Ellen Hui proposed a change to openstack/ironic: Make DHCP provider pluggable https://review.openstack.org/112351 | 22:27 |
JayF | wdym by the IPA CoreOS image build job stuff? | 22:27 |
devananda | oh | 22:27 |
JayF | Should I just indicate we'd have post jobs building those? | 22:27 |
devananda | so ya'll are building a coreos image and publishing them somewhere | 22:27 |
devananda | don't you? | 22:27 |
JayF | in a post job, yes | 22:27 |
devananda | right | 22:27 |
devananda | oooh so | 22:28 |
devananda | when BUILDING that image, you run the check/gate tests WITH it | 22:28 |
devananda | so that you can't publish a broken image | 22:28 |
JayF | https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml#L2194 | 22:28 |
JayF | devananda: I would think that if we gate IPA on the tempest tests against each image, it would mean a post job would never run against a broken image, right? | 22:29 |
devananda | run the ironic + ipa + tempest tests in the job that builds the CoreOS image | 22:29 |
devananda | right | 22:29 |
JayF | Hmm. So you're basically saying to replace the existing image build job with a tempest suite that /also/ creates an image | 22:30 |
JayF | and we'd just have it additionally run that in post and publish the image | 22:30 |
devananda | JayF: where's the imabe build job code? | 22:30 |
devananda | this: gate-ironic-python-agent-buildimage-coreos | 22:30 |
JayF | https://github.com/openstack/ironic-python-agent/blob/master/imagebuild/coreos/full_trusty_build.sh is the script that runs against a bare-trusty node | 22:30 |
JayF | I can find the jjb piece too | 22:31 |
devananda | k | 22:31 |
devananda | take a look at dib | 22:31 |
JayF | https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/ironic-python-agent-jobs.yaml is the config bit | 22:31 |
devananda | afaik, dib is co-tested with ironic | 22:31 |
devananda | so a change in dib should, in theory, cause all of ironic's tests to run WITH that change BEFORE it passes | 22:32 |
devananda | oh | 22:32 |
devananda | i see | 22:32 |
devananda | ironic-in-devstack isn't consuming the final image though - it's consuming the code and building the image using dib's code | 22:32 |
JayF | Yeah, I was thinking we'd keep that model. Have tempest tests in check/gate for IPA that build and use the image to deploy machines | 22:33 |
JayF | then the post job would be lighter and just build and publish the image | 22:33 |
devananda | yep | 22:33 |
JayF | otherwise we're taking up a node for a long suite of tempest testing in post that's redundant | 22:33 |
devananda | right | 22:33 |
JayF | whereas just the imagebuild, for CoreOS, takes 2m-10m (depending on which cloud it gets provisioned to by nodepool) | 22:33 |
JayF | so are you OK with that model? that was my thought when I was talking about this at the mid-cycle | 22:34 |
devananda | ++ | 22:38 |
JayF | devananda: so are you +1 to that etherpad as it sits now then? | 22:38 |
* JayF about to timeout | 22:42 | |
devananda | JayF: there's something that caught my eye | 22:42 |
devananda | "fails against agent_ssh in Ironic but not against pxe_ssh in Nova" | 22:42 |
JayF | I should word that better | 22:43 |
devananda | other than that, yes, LGTM | 22:43 |
JayF | the point I'm trying to make is that if pxe_ssh tests succeed when nova runs the ironic tempest suite | 22:43 |
JayF | and then later the agent_ssh tempest suite fails due to that same nova change | 22:43 |
JayF | the cause would almost certainly be an /ironic/ bug, not a nova bug | 22:43 |
devananda | ahhh | 22:44 |
devananda | so I missed that intent | 22:44 |
devananda | and it's a good point to make | 22:44 |
JayF | So if you missed it, and you have all the context, it's very unclear :) | 22:44 |
JayF | similarly if IPA tests failed against CoreOS image (due to Ironic OR Nova change), but DIB image passed in Ironic/Nova tests, then it's almost certainly an *IPA* bug | 22:46 |
*** jgrimm has quit IRC | 22:47 | |
devananda | yep | 22:47 |
devananda | much better | 22:47 |
JayF | okay, that's awesome. going to send it | 22:47 |
JayF | nice to be talking about testing the agent | 22:47 |
JayF | instead of talking about landing it | 22:48 |
devananda | =) | 22:48 |
devananda | indeed it is | 22:48 |
*** penick has quit IRC | 22:51 | |
*** penick has joined #openstack-ironic | 22:52 | |
*** f13o_ has quit IRC | 22:57 | |
*** dhellmann is now known as dhellmann_ | 23:00 | |
NobodyCam | brb | 23:06 |
*** lucas-dinner has quit IRC | 23:09 | |
devananda | JayF: still here? | 23:13 |
devananda | I finally read the drac raid spec | 23:13 |
JayF | yeah, I'm here | 23:14 |
JayF | jroll: everytime I review your devstack patch for ipa, I read $LINENO as $LOLNO as in, "die $LOLNO" | 23:15 |
devananda | going to block it for several reasons | 23:15 |
JayF | Cool. I suspected you might which is why I linked it up to you | 23:16 |
JayF | "displaying the current configuration for Dell Remote | 23:17 |
JayF | Access Controller in Ironic | 23:17 |
JayF | nope because ironic is not a cmdb? | 23:17 |
devananda | nope | 23:19 |
devananda | though that's almosta good reason | 23:20 |
devananda | also, it looks like someone already raised that concern, then later gave a +2 ? | 23:20 |
JayF | Yeah. | 23:20 |
JayF | I have that concern a little too, but I remember we were chatting once about IPA, and you drew a line between in-band (mdadm/lvm) disk config and oob (hw raid controllers) disk config | 23:21 |
BadCub | FYI @Nobodycam had to run to the vet with an emergency sample from one of the kids | 23:21 |
devananda | JayF: right - hw raid stuff is totally in scope, IMO | 23:21 |
*** penick has quit IRC | 23:21 | |
devananda | but storing the inventory data ... is a fuzzy line | 23:21 |
JayF | it sounded like they needed to store that data in order to implement it async | 23:21 |
devananda | this would be much more happy making if it was closer to our discussion on capabilities | 23:22 |
JayF | Yeah. I think we should have a spec for kilo-1 and get in in around using capabilities to manipulate firmware/settings(/raid config?) | 23:23 |
JayF | the cisco spec that asked for an exception on os-dev this morning was similarly icky | 23:23 |
JayF | in that a large % of it was node auto-enrollment | 23:23 |
JayF | although I couldn't remember if at the mid-cycle we declared that fully out of scope or /mostly/ out of scope :) | 23:23 |
*** mdorman has quit IRC | 23:25 | |
devananda | I feel as though, at this point, we should just block anything having to dow ith auto enrollment or discovery | 23:27 |
devananda | and say "too contentions, lets revisit this at the summit" | 23:27 |
devananda | gah. spelling. | 23:27 |
JayF | I agree. I think I'm pretty firmly in the camp of no-auto-enrollment at this point. Just too complex to do well, and borderline out of scope | 23:28 |
*** penick has joined #openstack-ironic | 23:28 | |
JayF | although validating the information you create nodes with before deploying to them (anytime you deploy) should be in scope. Same reason as decom: ensure users get the same platform to deploy their workloads on every time | 23:28 |
devananda | JayF: have you seen https://review.openstack.org/#/c/101122/8/specs/juno/firmware_settings_design.rst | 23:43 |
devananda | also, we REALLY need user docs | 23:45 |
devananda | cause all of these things are more doc debt | 23:45 |
devananda | and without in-tree docs, we are marking features as implemented without any docs being written by the authors :( | 23:46 |
devananda | by we I mean me | 23:46 |
devananda | oh nvm, you commented on it alraedy | 23:47 |
*** ellenh has quit IRC | 23:47 | |
JayF | Yeah that's specifically the spec that led to me starting the conversation about capabilities at midcycle | 23:48 |
devananda | gotcha | 23:48 |
devananda | hm. I read all those dates as June, not July | 23:48 |
devananda | now it makes sense | 23:49 |
JayF | I feel like I'm missing a comment from that, pretty sure I responded to the last comment | 23:50 |
adam_g | devananda, so FYI the grenade work is just about done AFAICS. now just waiting on all of its dependencies to make it through the review queue | 23:51 |
devananda | awesomesauce | 23:52 |
adam_g | with his permission, ive taken over https://review.openstack.org/#/c/112402/ while romcheg is gone | 23:52 |
adam_g | devananda, whats the story with the flavor migration scripts? why was it decided to go that route instead of just updating the flavor extra specs manually via API? | 23:53 |
devananda | adam_g: no CoAuthored line? | 23:53 |
* NobodyCam is back | 23:53 | |
devananda | adam_g: not sure now? there's actually a second implementation of that floating around in gerrit, from lucas | 23:53 |
devananda | adam_g: as part of our general move away from using flavor extra specs at all in ironic | 23:54 |
devananda | s/in/with/ | 23:54 |
*** penick has quit IRC | 23:55 | |
*** penick has joined #openstack-ironic | 23:55 | |
openstackgerrit | Adam Gandelman proposed a change to openstack/ironic: Script to migrate Nova BM data to Ironic https://review.openstack.org/112402 | 23:55 |
adam_g | devananda, ok, well ATM i have grenade just updating them via Nova after creating and uploading the new deploy k+rd | 23:56 |
devananda | adam_g: you're just updating the flavor? | 23:56 |
devananda | adam_g: or updating all nodes driver_info? | 23:56 |
*** penick has quit IRC | 23:57 | |
adam_g | devananda, ATM only the flavor | 23:57 |
devananda | ah, i see | 23:58 |
devananda | so that's fair in the grenade test | 23:58 |
devananda | if we are ever goign to drop support for associating deploy k/r with flavors, we'll need to do more, but probably not related to grenade | 23:59 |
adam_g | devananda, should we be having grenade + the migration tools convert to instance_info at this point? | 23:59 |
devananda | driver_info | 23:59 |
devananda | so i'm not sure we need to | 23:59 |
adam_g | hmm | 23:59 |
devananda | juno will support the backwards-compat way | 23:59 |
JayF | jroll: around? | 23:59 |
devananda | we may drop that in kilo | 23:59 |
devananda | but that doesn't matter for this test | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!