| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-31 | |||
| 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 | |
| 14:59:11 | openstackgerrit | Ed Leafe proposed openstack/nova master: Modify select_destinations() to return objects and alts https://review.openstack.org/510159 | |
| 14:59:11 | openstackgerrit | Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854 | |
| 14:59:12 | openstackgerrit | Ed Leafe proposed openstack/nova master: Make conductor pass and use host_lists https://review.openstack.org/511358 | |
| 14:59:12 | openstackgerrit | Ed Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357 | |
| 14:59:13 | openstackgerrit | Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/516707 | |
| 14:59:23 | reedip_ | we resolved them , and retried the tests, but still got the failure, thats why I am thinking if it is or not | |
| 14:59:28 | reedip_ | jaypipes: ^^ | |
| 14:59:54 | edleafe | mriedem: dansmith: ^^ refactored with additional RPC param | |
| 15:01:03 | jaypipes | reedip_: on a call for an hour or so.. | |
| 15:01:06 | reedip_ | jaypipes : I may need to leave soon, but I will see the logs and accordingly report it on the launchpad. Maybe we can proceed from there ... is that ok ? | |
| 15:01:21 | openstackgerrit | Dan Smith proposed openstack/nova master: Make put_allocations() retry on concurrent update https://review.openstack.org/516708 | |
| 15:01:22 | openstackgerrit | Dan Smith proposed openstack/nova master: Refactor claim_resources() to use retries decorator https://review.openstack.org/516709 | |
| 15:01:26 | dansmith | mriedem: ^ | |
| 15:01:32 | reedip_ | jaypipes : then I think my plan is good enough .. thanks for your time | |
| 15:13:49 | mriedem | edleafe: dansmith: ack | |
| 15:14:00 | mriedem | trying to un-f ocata atm | |
| 15:44:15 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data (2) https://review.openstack.org/452819 | |
| 15:44:15 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data https://review.openstack.org/452818 | |
| 15:44:16 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Deduplicate instance.power-off notification samples https://review.openstack.org/475860 | |
| 15:44:16 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Deduplicated instance.(un)pause notification samples https://review.openstack.org/452820 | |
| 15:44:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Deduplicate instance.live_migration notification samples https://review.openstack.org/515745 | |
| 15:44:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Deduplicate instance.interface_attach samples https://review.openstack.org/515740 | |
| 15:44:18 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Deduplicate instance.reboot notification samples https://review.openstack.org/515751 | |
| 15:47:40 | gibi | jaypipes: thanks for the review on the notification sample refactoring patches. I fixed your comments | |