| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-17 | |||
| 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 | |
| 10:29:48 | lyarwood | mdbooth: no, not with the db and object changes | |
| 10:29:53 | lyarwood | iirc | |
| 10:30:11 | mdbooth | I think you could pull https://review.openstack.org/#/c/440693/ to the top of its own series | |
| 10:30:12 | lyarwood | mdbooth: let me grab some more coffee and spin them out | |
| 10:30:31 | lyarwood | mdbooth: sure | |
| 10:30:34 | mdbooth | And that wouldn't compromise either those patches or the attachment_id patches in any way | |
| 10:31:55 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: do not include context to exception notification https://review.openstack.org/446948 | |
| 10:39:46 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Only destroy BDMs after successful detach call https://review.openstack.org/440693 | |
| 10:40:05 | lyarwood | mdbooth: ^ that change should be flying solo now | |
| 10:43:29 | mdbooth | lyarwood: Cool, check in a minute. | |
| 11:01:10 | gmann | mdbooth: johnthetubaguy kashyap : 1 query on swap volume | |
| 11:01:42 | gmann | mdbooth: johnthetubaguy kashyap : when we swap volume with nova volume update, we loss the thin provisioning. | |
| 11:02:29 | gmann | any way to keep the thin provisioning when libvirt rebase during swap volume | |
| 11:02:47 | johnthetubaguy | gmann: what are you aiming to do with the swap volume? | |
| 11:02:48 | gmann | did not find any flag on virDomainBlockRebase | |
| 11:03:38 | gmann | johnthetubaguy: i had thin provisioned volume attached to instance and then i want to swap that volume but new volume is not thin provisioned one its all full size as used | |
| 11:04:14 | gmann | allocated size is all volume size not actual consumed sized | |
| 11:05:33 | johnthetubaguy | gmann: but why did you swap to a new volume, I am just curious? migrating between volume types? | |
| 11:06:33 | johnthetubaguy | ( gmann: honestly, I think its the same problem we have using stroage pools for migration, it doesn't zip copying zeros, but mdbooth and kashyap will know more about that than me) | |
| 11:06:51 | johnthetubaguy | s/zip/skip/ | |
| 11:07:16 | gmann | johnthetubaguy: yea same issue, it copy all zero block too | |
| 11:07:30 | gmann | johnthetubaguy: yea use case is migrating volume to new type | |
| 11:07:40 | johnthetubaguy | gmann: cool, that makes sense | |
| 11:07:51 | johnthetubaguy | so we have to copy everything, but copying zeros is stupid | |