| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-31 | |||
| 12:32:27 | jaypipes | efried: just like the current code currently first calls out to a separate function to get "root providers" and then gets shared providers, etc... | |
| 12:32:41 | jaypipes | efried: just needs to be cleaned up a bit. | |
| 12:32:45 | jaypipes | efried: and better doc'd. | |
| 12:40:16 | openstackgerrit | David Rabel proposed openstack/nova master: Fix format in live-migration-usage.rst https://review.openstack.org/516416 | |
| 12:45:35 | cdent | jaypipes: i’ll go ahead and fix that thing separately https://bugs.launchpad.net/nova/+bug/1728934 | |
| 12:45:37 | openstack | Launchpad bug 1728934 in OpenStack Compute (nova) "placement gabbi tests that manipulate microversion can intermittently fail" [Medium,Triaged] - Assigned to Chris Dent (cdent) | |
| 12:57:25 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] avoid case issues microversions in gabbits https://review.openstack.org/516662 | |
| 12:57:34 | efried | jaypipes Was about to respin the flavor-side granular series (https://review.openstack.org/#/c/515151/) - you got more to say there at the moment? | |
| 12:57:53 | cdent | jaypipes, efried, gibi ^^ gate flakiness bug fix | |
| 12:58:11 | efried | cdent Would that be officially remedied by making gabbi use case insensitive dicts (like requests does) for headers? | |
| 12:58:25 | cdent | efried: read the commit message for the answer to that | |
| 12:59:35 | cdent | efried: the idea is that gabbi needs to support the behaviors of http, not whatever clients happen to be available | |
| 12:59:40 | gibi | cdent: looking... | |
| 12:59:55 | efried | cdent I thought the http standard was for headers to be case-insensitive. But I'm no expert. | |
| 13:00:07 | efried | cdent Did you deliberately say "vagrancies" rather than "vagaries"? | |
| 13:00:37 | cdent | and because http header names are case insensitive it is possible to accidentally set the same header twice in some implementations | |
| 13:00:43 | cdent | no, but i’ll take it :) | |
| 13:01:22 | efried | I think even with case insensitivity you can set the same header multiple times. | |
| 13:01:45 | cdent | yes, that’s the “implementation” part of the commit message. | |
| 13:01:55 | cdent | it’s a yaml dict | |
| 13:02:29 | cdent | so _if_ we want to send a header twice, we have to use different case | |
| 13:03:01 | cdent | sloppy, but… | |
| 13:03:13 | efried | cdent Because yaml, or because gabbi? | |
| 13:03:43 | cdent | because of gabbi’s choice to use a dict for request headers | |
| 13:04:36 | cdent | efried: there’s a gabbi bug about this from a few months ago: https://github.com/cdent/gabbi/issues/213 | |
| 13:05:16 | cdent | efried: note that in that case the bug is talking about all the dicts in defaults, not just request headers | |
| 13:06:08 | cdent | the resulting conclusion was “don’t normalize as then what you see is not what you get” | |
| 13:07:03 | gibi | cdent: is there a reason choosing the non capitalized form of the header name? It seems that placement returns a capitalized from in the response here https://github.com/openstack/nova/blob/master/nova/tests/functional/api/openstack/placement/gabbits/microversion.yaml#L16 | |
| 13:08:23 | cdent | gibi: a) because nearly everything else you type into left hand side of gabbi is lowercase, b) uppercase is a pain to type. Yes, the response header is cased, and I noted that while making the changes and decided to still go with lower case. | |
| 13:09:21 | gibi | cdent: if it is intentional then I'm cool with it :) | |
| 13:10:06 | cdent | yeah, it’s intentional. I hate the shift key :) | |
| 13:14:38 | alex_xu | jaypipes: efried, hey I'm here | |
| 13:15:45 | efried | alex_xu Check out the backscroll between me & jaypipes and speak up if you have objections/questions/comments on what jaypipes is planning to do wrt refactoring stuff for GET /allocation_candidates | |
| 13:17:31 | alex_xu | efried: yea, I read those, the current series can be rewrite as a set of sub-method instead of the objects also. but yea, I'm not sure what is the plan of jaypipes | |
| 13:19:32 | alex_xu | jaypipes: efried, i'm not sure what I can do now, sounds like just abandoned the patch, or jaypipes do you want to share your idea on etherpad or anywhere. Then I and efried can help on that, since we already work on that series, and found few cases which easy to miss, that may help you? | |
| 13:25:21 | jaypipes | alex_xu: no, please don't abandon. lemme push some sample code and then let me know what you think about using it as the basis for your series. | |
| 13:26:09 | alex_xu | jaypipes: ok, got it, if you get the code up very soon, reading the code is more easy something | |
| 13:26:17 | jaypipes | efried: no, feel free to respin. I think you got most of my feedback on IRC on that one, yeah? | |
| 13:26:22 | alex_xu | s/something/sometime/ | |
| 13:26:26 | jaypipes | alex_xu: working it right now :) | |
| 13:26:39 | efried | jaypipes Hopefully. Respinning now... | |
| 13:28:51 | jaypipes | alex_xu: nighty night! :)( | |
| 13:29:03 | jaypipes | cdent: +W'd | |
| 13:39:33 | efried | jaypipes You said the order of subclauses in an AND isn't important... so the database doesn't short-circuit the clause on the first false condition? | |
| 13:40:27 | jaypipes | efried: no, it doesn't work that way. RDBMs will always prioritize the field(s) that are in indexes chosen by the query optimizer. | |
| 13:40:47 | efried | hm, neat. | |
| 13:41:23 | jaypipes | efried: so in that case, it makes no difference since the resource class and resource provider fields will always be evaluated before anything with total, max_unit, step_size, or min_unit | |
| 13:42:14 | efried | jaypipes But it's (slightly) cheaper to do the single-comparator math than the multiple-add-compare stuff. | |
| 13:42:38 | efried | multiply-add-compare, that is. | |
| 13:42:44 | efried | I'm sure it's negligible. | |
| 13:42:52 | jaypipes | efried: I don't think you'd see the difference there, no. | |
| 13:43:25 | jaypipes | efried: compared to the cost of loading all of the fields into memory after the join conditions are satisfied, the comparison of the data in those loaded fields is miniscule. | |
| 13:43:38 | efried | noted | |
| 13:44:28 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/511035 | |
| 13:48:56 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/511035 | |
| 13:59:11 | openstackgerrit | Eric Fried proposed openstack/nova master: Granularize resources_from_{flavor|request_spec} https://review.openstack.org/515223 | |
| 13:59:11 | openstackgerrit | Eric Fried proposed openstack/nova master: Parse granular resources/traits from extra_specs https://review.openstack.org/515151 | |
| 13:59:12 | openstackgerrit | Eric Fried proposed openstack/nova master: ResourceRequest.to_querystring() https://review.openstack.org/515811 | |
| 13:59:18 | efried | gibi jaypipes alex_xu ^ | |
| 13:59:26 | efried | and cdent too ^ | |
| 14:03:57 | cdent | ✔ | |
| 14:27:11 | gibi | efried: I'm +2 on the whole series, thanks for working on it | |
| 14:32:41 | reedip_ | Hi guys , how much time does it take for an instance to boot up in Nova ? We have a 32 GB RAM for Compute node, and booting up a VM using Ubuntu 14.04 | |
| 14:32:53 | reedip_ | but the VM doesnt boot up in 6 minutes.... | |
| 14:33:00 | reedip_ | does that normally occur ? | |
| 14:33:16 | reedip_ | I tried it atleast 8-10 times , booting a set of 10 VMs. | |
| 14:33:32 | reedip_ | each VM is an Ubuntu Xenial CLoud image | |
| 14:34:13 | reedip_ | but of the 10 VMs, 4-6 boot up succesfully... failure occurs after that | |
| 14:34:23 | reedip_ | Flavor given is 2 GB RAM and 3 GB HDD | |
| 14:35:19 | jaypipes | reedip_: 14.72917672 seconds. every time. | |
| 14:35:39 | reedip_ | jaypipes : its that accurate ???? | |
| 14:36:06 | jaypipes | reedip_: no, of course not, I was only joking... :) there's no way to say. totally depends on the hardware, the virt driver, the number of nodes, etc etc | |
| 14:36:09 | reedip_ | jaypipes : so if a VM doesnt boot up ( BTW I am using Mitaka with Ubuntu 14.04 ), where can I find the logs ? | |
| 14:36:35 | reedip_ | jaypipes : I thought so :) | |
| 14:37:03 | jaypipes | reedip_: look in the nova-scheduler logs. you will likely find an error about resources being over capacity... | |
| 14:37:17 | reedip_ | jaypipes : okay, let me check ... | |
| 14:38:37 | jaypipes | reedip_: for a small setup like that, if the VM doesn't boot in under 15 seconds, that's unusual... | |
| 14:39:05 | reedip_ | jaypipes : wait, the complete setup is below : | |
| 14:39:14 | jaypipes | for tiny images like that, I'd expect something more like 6 seconds, especially if the image has already been launched/cached on the comput ehost. | |
| 14:39:23 | reedip_ | 1 Controller: 4 GB RAM, 12 GB HDD | |
| 14:41:43 | jaypipes | reedip_: how many compute nodes? | |
| 14:42:48 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: config drive https://review.openstack.org/409404 | |
| 14:42:48 | jaypipes | reedip_: also, your instances should end up in an ERROR state if they aren't booting in six minutes. You should be able to check the error by looking at the instance faults returned in the GET /servers/{uuid}/detail call. | |
| 14:49:06 | reedip_ | jaypipes : hi , did you get my earlier messages ? | |
| 14:49:26 | jaypipes | reedip_: err, no? | |
| 14:50:56 | reedip_ | jaypipes : sorry then, my network issue ... | |
| 14:51:04 | reedip_ | jaypipes : the complete setup is below : | |
| 14:51:41 | reedip_ | jaypipes :1 Controller: 4 GB RAM, 12 GB HDD, 3 Compute : 2 COmpute with 32 GB RAM and 100 GB HDD , 1 with 8 GB RAM and 20 GB HDD, 1 Glance server ,The request goes to the 100 GB COmpute machine, and we are using Qemu | |
| 14:52:41 | reedip_ | jaypipes : would Nova-Scheduler report it as an Error ?? I think it should but reconfirming | |
| 14:52:48 | jaypipes | reedip_: what are your allocation ratios? have you changed any of the default configuration values for cpu_allocation_ratio, ram_allocation_ratio or disk_alllocation_ratio? | |
| 14:52:54 | reedip_ | jaypipes : in case resources are less | |
| 14:53:07 | reedip_ | jaypipes : no , not changed any default configurations | |
| 14:53:13 | jaypipes | reedip_: yes. you would see a NoValidHost pop up. | |
| 14:53:17 | jaypipes | reedip_: k | |
| 14:53:48 | jaypipes | reedip_: look in the nova-scheduler and nova-compute log files. nova-scheduler on controller. nova-compute on each of the compute nodes. look for any ERROR log line. | |
| 14:53:55 | reedip_ | jaypipes : yeah, couldnt find that ... I know the NoValidHost error , happened to me amny a times now .. :) | |
| 14:55:49 | jaypipes | reedip_: you see no errors at all? | |
| 14:57:16 | reedip_ | jaypipes : no , I couldnt see the NoValidHost error .. there are some rabbitmq errors but that was because rabbitmq was failed ... this happened quite a long time after we noticed the VM failure, so I dont think that would be an issue | |
| 14:58:49 | jaypipes | reedip_: rabbit errors would definitely be an issue... | |
| 14:59:10 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239 | |