| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-17 | |||
| 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 | |
| 10:20:03 | lyarwood | mdbooth: we already have instance and volume lookups for that part | |
| 10:20:10 | mdbooth | Where are we using that in the series already posted? | |
| 10:20:33 | lyarwood | mdbooth: using what sorry? | |
| 10:20:39 | mdbooth | bdm.attachment_id | |
| 10:21:07 | lyarwood | mdbooth: again, we are not but I wanted to land the refactor _before_ we started using it in the new detach flow | |
| 10:21:32 | lyarwood | mdbooth: jgriffith posted a PoC that we were going to rebase on top of the refactor for the new detach flow | |
| 10:21:33 | mdbooth | Right, that makes sense to me | |
| 10:21:45 | mdbooth | So why not move the refactor to the head of the series? | |
| 10:21:54 | mdbooth | It doesn't have to depend on the attachment_id patches | |
| 10:22:24 | mdbooth | Now that I've noticed that there's no user for attachment_id, not even just posted for review, I don't think we should merge it | |
| 10:22:26 | lyarwood | the db and model changes were the priority at the time so I didn't want the refactor changes getting in the way | |
| 10:23:07 | mdbooth | I don't understand why they would be a priority if we're not writing data there, or reading from it | |
| 10:23:10 | lyarwood | how does that matter? we know we are going to need it | |
| 10:24:56 | mdbooth | Not really. I think, for example, that you'll discover that bdm lookup by attachment id is essential, and you'll need a second db migration | |
| 10:25:13 | mdbooth | But we have no solid data because there's no code. | |
| 10:25:41 | lyarwood | haha, I can't win either way | |
| 10:26:18 | mdbooth | lyarwood: I hadn't realised there was no user in the following patches. I'd just assumed there was. | |
| 10:26:53 | mdbooth | The patches as posted are good, imho. There's no reason I see why they can't merge quickly when they have a reason to be in the code. | |
| 10:27:06 | mdbooth | I just think it's counter-productive to merge them now. | |
| 10:27:38 | mdbooth | s/counter-productive/premature/ | |
| 10:27:48 | lyarwood | yup understood | |
| 10:28:38 | mdbooth | lyarwood: Yeah, I will. | |
| 10:28:42 | lyarwood | thanks | |
| 10:28:56 | mdbooth | lyarwood: Is there a merge conflict with the detach patches, btw? | |
| 10:29:09 | mdbooth | If not, why not just separate them into their own independent series anyway? | |
| 10:29:19 | lyarwood | mdbooth: yes, they are based on jgriffith's own db & object change | |
| 10:29:22 | mdbooth | Then they can both proceed at their own pace. | |
| 10:29:32 | lyarwood | mdbooth: ah | |
| 10:29:38 | lyarwood | mdbooth: wait you mean my refactor patches | |
| 10:29:42 | mdbooth | Yeah | |