| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-17 | |||
| 00:53:14 | Sukhdev | mriedem : One quick question (for my clarification) I read somewhere while looking for help on Google it stated that in Ocata release Nova mendate cell configuration - is it true? Do I need to add anything in local.conf in this regard> | |
| 00:54:09 | mriedem | Sukhdev: you don't need anything in local.conf for cells v2 in ocata | |
| 00:54:43 | Sukhdev | mriedem : cool - thanks - was worried if that has anything to do with this :-) | |
| 00:55:03 | mriedem | i don't think it would, the scheduler in ocata didn't take cells into consideration | |
| 00:55:35 | Sukhdev | Great - thanks | |
| 00:55:41 | sbezverk | mriedemЬ curl returns 401 Unauthorized | |
| 00:56:53 | sbezverk | mriedem: it does not look like network issue then.. | |
| 00:57:40 | mriedem | sbezverk: did you provide a token in the curl request to / ? | |
| 01:00:47 | sbezverk | mriedem: cannot do it as it is a gate job | |
| 01:01:01 | melwitt | mriedem: argh, dangit (test trace) | |
| 01:01:22 | sbezverk | mriedem: do not have much flexebility there | |
| 01:01:24 | melwitt | oh, you took care of it. thanks | |
| 01:01:27 | mriedem | melwitt: yup | |
| 01:02:12 | mriedem | sbezverk: i'm not sure what you mean. you're scripting this into the CI job right? if you've added something that makes a curl request to the root of the placement endpoint from the nova-scheduler container, can't you also get a token and include that in the request, from within the script/CI job? | |
| 01:02:31 | mriedem | OS_TOKEN=$(openstack token issue -f value -c id) | |
| 01:03:35 | sbezverk | mriedem: cool thanks, let me try with it | |
| 01:08:59 | dtp-afk | jroll are you still here? | |
| 01:10:59 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add api-ref for filter/sort whitelist https://review.openstack.org/421760 | |
| 01:18:05 | openstackgerrit | Dan Peschman proposed openstack/nova master: Option to always create network metadata information as static https://review.openstack.org/336293 | |
| 01:39:28 | sbezverk | mriedem: ok so the process is alive, there must be something with scheduler preventing it finding it.. | |
| 01:39:54 | sbezverk | mriedem: http://paste.openstack.org/show/603043/ | |
| 01:40:34 | mriedem | sbezverk: try restarting nova-scheduler, i think we cache the failed attempt and don't try again for like 10 minutes | |
| 01:44:07 | dtp | mriedem, if i have other ideas on implementation of https://blueprints.launchpad.net/nova/+spec/service-hyper-pci-uuid-in-api, should i just keep them to myself? | |
| 01:44:28 | sbezverk | mriedem: well, it is at the gate. once failed the job is failed/gone.. | |
| 01:45:32 | mriedem | sbezverk: you can't reproduce locally? | |
| 01:45:37 | mriedem | dtp: umm, idk | |
| 01:45:46 | mriedem | dtp: we could talk tomorrow, i've got to call it a day | |
| 01:45:56 | dtp | sounds good | |
| 01:46:04 | sbezverk | mriedem: when scheduler starts it tries to communicate with placement right away? | |
| 01:46:21 | mriedem | sbezverk: i don't think so no | |
| 01:46:30 | mriedem | only once a request to create an instance comes in | |
| 01:46:44 | sbezverk | mriedem: ok so ordering would not matter much | |
| 01:46:52 | sbezverk | I mean process start up | |
| 01:47:17 | mriedem | sbezverk: placement should come before the scheduler, but i'd have to dig into details, which i can't right now | |
| 01:47:31 | mriedem | sbezverk: check that nova devref doc on placement that i linked earlier, there might be something i'm forgeting | |
| 01:47:56 | sbezverk | mriedem: ok I will, also will try to repro in local test bed. thank you for your help | |
| 01:48:14 | mriedem | yw | |
| 01:59:14 | gmann | alex_xu: sfinucan mriedem can you check this. updated enum value format (api-ref for sort/filter) - https://review.openstack.org/#/c/421760/ | |
| 02:23:15 | alex_xu | gmann: thanks, I will check it soon | |
| 02:24:11 | gmann | mriedem: alex_xu johnthetubaguy sfinucan snikitin : i doubt cpu id should be integer, i replied on https://review.openstack.org/#/c/445855/1 and https://review.openstack.org/#/c/434745/3 | |
| 02:24:20 | gmann | need your opinion | |
| 02:24:24 | gmann | alex_xu: thanks | |
| 02:26:12 | gmann | libvirt driver(current diagnostics info provider) seems not appending the CPU id | |
| 04:37:04 | gmann | BobBall: can we use VM_metrics.get_VCPUs_utilisation to fetch the CPU utilization ? - https://review.openstack.org/#/c/399613/29 | |
| 06:49:10 | alex_xu | gmann: may I say 'valid value' instead of 'enum value' at https://review.openstack.org/#/c/421760/15/api-ref/source/parameters.yaml@421 | |
| 06:49:30 | alex_xu | gmann: due to from the schema, it just a field accept any string | |
| 06:49:59 | alex_xu | gmann: you won't get error when you input something out of 'auto' and 'manual' | |
| 06:52:18 | gmann | alex_xu: ah, nice point. ll update. | |
| 06:52:26 | alex_xu | gmann: thanks | |
| 06:52:30 | gmann | alex_xu: please -1 :) | |
| 06:52:43 | alex_xu | gmann: ah, yea, got one point | |
| 06:53:50 | alex_xu | gmann: done, thanks :) | |
| 06:54:05 | alex_xu | gmann: I can update the patch online | |
| 06:54:15 | alex_xu | do you want me do that, and I can +2 directly | |
| 06:54:36 | gmann | alex_xu: updating | |
| 06:54:44 | alex_xu | gmann: thanks | |
| 06:56:55 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add api-ref for filter/sort whitelist https://review.openstack.org/421760 | |
| 06:57:08 | gmann | alex_xu: ^^ | |
| 06:57:59 | alex_xu | gmann: thanks, done | |
| 06:58:31 | gmann | alex_xu: thanks. | |
| 07:27:39 | markus_z | bauzas: lyarwood: claudiub: Please add this to your review backlog: https://review.openstack.org/#/c/406898/ It's a backport to stable/newton. mriedem's questions there are answered but he's busy with other items. | |
| 09:02:23 | openstackgerrit | ChangBo Guo(gcb) proposed openstack/nova master: Fix wrong unit test about config option enabled_apis https://review.openstack.org/446898 | |
| 09:09:00 | openstackgerrit | 龚肖 proposed openstack/nova master: Modify api-ref information https://review.openstack.org/446902 | |
| 09:28:30 | BobBall | gmann: VM_metrics is the old way of doing things and I think doesn't work correctly. The best way is to obtain metrics using the RRDs with VM.query_data_source. | |
| 09:29:02 | BobBall | gmann: I think (but I'm not certain) that VM_metrics only stores info on the first vCPU | |
| 09:29:53 | BobBall | gmann: querying the RRD datasource is the most correct way of getting the details from XenAPI | |
| 09:32:06 | BobBall | gmann: See also https://git.openstack.org/cgit/openstack/ceilometer/commit/ceilometer/compute/virt/xenapi/inspector.py?id=1374cf7d229ed0b8fca0fbdc6477703d9fff0ecc | |
| 09:33:41 | gmann | BobBall: ah i see. | |
| 09:34:02 | gmann | BobBall: query_data_source will fetch all latest stats | |
| 09:35:25 | BobBall | Indeed | |
| 09:36:35 | gmann | BobBall: thanks, very useful information :) | |
| 09:36:42 | BobBall | Happy to help :) | |
| 09:37:11 | gmann | BobBall: so all info in VM_metrics is not guaranteed ? | |
| 09:37:32 | BobBall | I would recommend against using it as it will likely be removed in future versions | |
| 09:38:06 | BobBall | If you can get information from it then it is probably right (I think) but it doesn't have some information and is likely to have less moving forward | |
| 09:38:51 | gmann | BobBall: i see. +1 to remove. it give much clarity | |
| 09:39:00 | gmann | thanks again | |
| 09:40:41 | openstackgerrit | Michael Henkel proposed openstack/nova master: Implements: blueprint opencontrail-dpdk-support https://review.openstack.org/441183 | |
| 09:41:17 | kashyap | lyarwood: When you're about, I saw mention of a Gate failure on detach. Is there a bug for it? [Me searches in the scrollback meanwhile] | |
| 09:55:08 | openstack | Launchpad bug 1669924 in OpenStack Compute (nova) "InstanceUpdateConflict: Conflict updating instance Expected: {'vm_state': ['building', None]}. Actual: {'vm_state': u'error'}" [Undecided,New] | |
| 09:55:08 | saju_m | i am getting this error https://bugs.launchpad.net/nova/+bug/1669924 in nova | |
| 09:55:29 | saju_m | i am using nova master branch | |
| 09:55:44 | saju_m | any clue ? | |
| 09:57:19 | saju_m | because of this, nova-scheduler shows no host found error | |
| 10:05:17 | lyarwood | I've asked this before but does anyone have a way of unwrapping comments in launchpad as you can do in bugzilla? | |
| 10:13:31 | mdbooth | lyarwood: johnthetubaguy pointed out in review that we don't have a user for bdm_get_by_attachmend_id (or whatever) | |
| 10:13:51 | mdbooth | lyarwood: which got me looking for a user of attachment_id in the following 3 patches | |
| 10:13:57 | mdbooth | lyarwood: What did I miss? | |
| 10:17:10 | lyarwood | mdbooth: Are you asking why there isn't a user of attachment_id yet? | |
| 10:17:45 | lyarwood | mdbooth: these patches are just moving things around to make it easier to introduce the new detach flow that will use it in the following patches | |
| 10:17:58 | lyarwood | mdbooth: while also keeping the cinderv2 code around | |
| 10:18:11 | mdbooth | lyarwood: I mean the detach flow refactor doesn't seem related to the attachment_id thing | |
| 10:18:48 | lyarwood | mdbooth: it's not directly, I just wanted to land it before we started to add code that used it, thus the ordering | |
| 10:18:58 | mdbooth | johnthetubaguy is saying don't add a db function we don't call, and mriedem is saying don't therefore add an index that's only required by that function | |
| 10:19:15 | mdbooth | And I'm saying that that function and that index are the reason attachment_id exists | |
| 10:19:24 | mdbooth | So if it's not being used, don't add it yet | |
| 10:19:27 | lyarwood | mdbooth: not at all | |
| 10:19:38 | lyarwood | mdbooth: that's just the lookup right | |
| 10:19:46 | lyarwood | mdbooth: we are still going to use bdm.attachment_id | |
| 10:19:55 | lyarwood | mdbooth: we just don't need to lookup bdms by attachment_id | |