Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-08
20:31:04 mriedem tssurya: dansmith: efried: ^ tis written but with lots of todo/question/alternates inline
20:31:36 mriedem eandersson: "never able to run services normally at the Pike level" is for FFU yes
20:32:15 mriedem eandersson: when you restart the ironic compute service it should migrate the embedded instance.flavor for each node it's managing automagically
20:32:28 aspiers artom: I learnt the difference on Sat, which is *almost* long enough ago for me to have forgotten it ;-)
20:33:06 mriedem https://opendev.org/openstack/nova/src/tag/18.0.0/nova/virt/ironic/driver.py#L545
20:33:22 artom aspiers, hah :) So yeah, do you think you want/need help (from admittedly another placement newbie)?
20:33:48 aspiers artom: probably will, but have to catch up with a bunch of other stuff before I get to this
20:34:25 mriedem eandersson: if you go down that route, note there are some open issues https://review.opendev.org/#/c/637217/
20:34:25 aspiers including filing expenses and sending a report about the self-healing SIG :-o
20:35:02 artom Reason I'm pestering is we have internal tracking requirements, so if I'm committing to helping with this thing, I'll need to file trackers for it sooner rather than later
20:36:34 aspiers artom: Got it. TBH I probably won't know how much help I need (if any) until I understand it better
20:37:24 artom aspiers, totally fair
20:37:46 artom In any case, nothing has to be decided tonight, and I have my own share of reading to do :)
20:37:52 artom And kids to fetch from daycare.
20:37:52 aspiers +1
20:37:55 openstackgerrit Surya Seetharaman proposed openstack/nova-specs master: Support server power state update through external event https://review.opendev.org/636132
20:45:40 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Spec to pre-filter disabled computes with placement https://review.opendev.org/657884
21:59:16 sorrison mriedem: Yeah didn't think of that but that seems ok to me and desired. Controlling access to list other projects instances seems like it should be separate to the other filters I think
22:01:00 mriedem alright, sounds like no change necessary then
22:01:06 mriedem no work works for me
22:09:41 openstackgerrit Eric Fried proposed openstack/os-traits master: Introduce traits for NUMA and NIC subtree affinity https://review.opendev.org/657898
22:17:28 openstackgerrit Rodrigo Barbieri proposed openstack/nova master: Add functional confirm_migration_error test https://review.opendev.org/657870
#openstack-nova - 2019-05-09
04:13:15 openstackgerrit Brin Zhang proposed openstack/nova master: Change the migration warning log https://review.opendev.org/657916
04:33:36 openstackgerrit Merged openstack/nova stable/stein: Use migration_status during volume migrating and retyping https://review.opendev.org/657575
06:29:15 openstackgerrit zhongshengping proposed openstack/nova master: Update Python 3 test runtimes for Train https://review.opendev.org/657941
09:37:44 openstackgerrit zhongshengping proposed openstack/nova master: Update Python 3 test runtimes for Train https://review.opendev.org/657941
10:07:16 openstackgerrit Sylvain Bauza proposed openstack/nova master: Pass allocations to virt drivers when resizing https://review.opendev.org/589085
11:09:49 openstackgerrit Surya Seetharaman proposed openstack/nova stable/ocata: [DNM] Populate key_pairs from top_cell to child cells https://review.opendev.org/657995
11:13:12 openstackgerrit Surya Seetharaman proposed openstack/nova stable/ocata: [DNM] Populate key_pairs from top_cell to child cells https://review.opendev.org/657995
11:14:17 tssurya sorrison: ^^ its an ugly fix, but it worked for us :) I don't think it will be merged upstream but you can use it downstream. Let me know if you have any questions
11:19:21 openstackgerrit Surya Seetharaman proposed openstack/nova stable/ocata: [DNM] Populate key_pairs from top_cell to child cells https://review.opendev.org/657995
13:10:34 shilpasd efried: Hi
13:10:42 efried o/ shilpasd
13:10:45 shilpasd Hi need bit input, i am currently working on implementation of https://review.opendev.org/#/c/650188/, Allow compute nodes to use shared storage provider for DISK_GB resources
13:11:24 shilpasd Gone through RESHAPE functionality implemented and here which deals with reshaping inventory and allocations
13:11:33 shilpasd In Shared storage Provider, similarly doing reshape where moving allocations of DISK_GB from compute node to shared storage provider
13:12:10 shilpasd now i want to correct local_gb_used at compute node at nova side
13:12:23 shilpasd so can you help me how to proceed here
13:13:34 shilpasd pre_start_hook() first update_available_resource() and then calls update_provider_tree()
13:14:13 shilpasd and during update_provider_tree() i am doing RESHAPE for DISK_GB similarly done for VGPU
13:16:01 efried shilpasd: let me go look at some code...
13:16:15 efried IIRC local_gb_used is a bit tricky
13:17:59 efried shilpasd: I'm sort of thinking we may want local_gb_used to be set to zero when the host is using shared disk.
13:18:10 efried mriedem, gibi, dansmith: You guys have a take on this? ^
13:24:28 mriedem idk, i'd think local_gb_used would at least report reserved_host_disk_mb (which defaults to 0)
13:25:19 mriedem otherwise i'd tend to agree that it should be 0 for instance usage in the resource tracker if you're using shared storage on that node
13:25:39 mriedem mdbooth might have other wrinkles in mind there
13:28:42 dansmith yea, what mriedem said... because in the future we could have the compute *also* reporting its own disk inventory if it gained the ability to do that thing
13:28:48 mdbooth Hmm, I'd need to look at code. Depends how local_gb_used is used.
13:36:43 efried mdbooth: The only nod to thin provisioning is allocation_ratio
13:36:50 efried which amounts to a wild-ass guess
13:37:19 efried and is why cinder has shown minimal enthusiasm for adopting placement to do their tracking
13:37:22 mdbooth IIRC local_gb_used is all about thin provisioning.
13:37:37 efried oh?
13:37:52 mdbooth IIRC it answers the question: can I migrate here?
13:38:56 mdbooth It's weird that we don't track actual usage in placement.
13:39:40 efried mdbooth: you would have to be sending updates all the time
13:40:00 mdbooth Yeah
13:40:04 efried the actual usage of thin-provisioned storage changes every time the guest does a write
13:40:23 efried also, somebody told me that the storage doesn't ever actually tell you how much space it really has anyway.
13:40:31 efried the more expensive the storage, the less accurate
13:40:32 mdbooth *some* storage
13:40:44 efried which seems bizarre to me
13:40:46 mdbooth We don't use that in Nova, though.
13:40:52 efried "we" don't?
13:41:10 efried I was assuming we would eventually be using this shared storage stuff for cinder volumes too
13:41:10 mdbooth The question we want to answer is: "do I have enough space to write X bytes here"?
13:41:25 mdbooth It seems weird to me that any useful storage would not be able to answer that question.
13:41:32 efried agree with that
13:41:35 efried but apparently it is so
13:41:35 dansmith mdbooth: uh, we do if we're on nfs backed by it
13:41:48 mdbooth That's a different question to "how much storage do I have?"
13:41:51 dansmith but the most expensive and most impressive storage gives you no useful numbers
13:42:15 dansmith reportedly some of them give you nothing more than "buy more disks around october"
13:42:38 mdbooth DISK_GB_PURCHASED_OCTOBER
13:42:56 dansmith obviously that would be a trait not a resource class :)
13:43:04 mdbooth Hehe
13:45:35 ganso mriedem: good morning! =) I replied to your comment in https://review.opendev.org/#/c/657870 Could you please confirm if the test case is really the same?
13:45:41 kashyap efried: Nice work on doing the summary emails. Tireless donkey work it is.
13:45:46 kashyap Thanks!
13:49:51 efried kashyap: :) thanks
13:52:16 efried shilpasd: afaict, the libvirt driver is setting the DISK_GB inventory based on the result from _get_local_gb_info()
13:53:04 efried At a glance, it seems like it would make sense to split that into two methods: _get_local_disk_info and _get_shared_disk_info.
13:53:41 efried If we start off supporting either local or shared but not both, then in a shared scenario the locals ought to report zero.
13:54:16 efried If the provider tree you are given has its disk local, and _get_local_disk_info returns zeros but _get_shared_disk_info returns nonzeros, you know you need to reshape.
13:54:53 efried And local_gb_used (really local_gb<anything>) should simply be fed from _get_local_disk_info, no matter what, meaning in the above case it will be zeros.
13:56:45 stephenfin anyone know if/when jaypipes will be back around. It sure would be lovely give the a once over and get it in (he reviewed in depth previously) https://review.opendev.org/#/c/629589/
13:59:36 jaypipes stephenfin: I am here.
14:03:01 jaypipes stephenfin: +2 from me. feel free to +W it.
14:04:35 shilpasd efried: thanks for input
14:09:04 openstackgerrit Eric Fried proposed openstack/nova-specs master: Train Cycle Themes https://review.opendev.org/657171
14:13:50 ganso Hi folks! I got a question about the num_instances value in the compute_nodes table. I have run into a situation where I have 4 VMs and "openstack hypervisor show" displays running_vms = 2. I found that this value is incremented/decremented in nova/compute/stats.py. Is there a way to recalculate this value or is the only way to fix this to update the database directly?
14:20:59 mriedem ganso: are all 4 of those vms running?
14:21:10 ganso mriedem: yes
14:23:13 mriedem looks like the update_available_resource periodic task in the compute should recalculate that value on each run of the task, which is every 1 minute by default
14:23:42 mriedem which release are you on?
14:24:42 ganso mriedem: mitaka
14:27:55 mriedem ganso: ok there was a stats related bug that probably only got fixed back to ocata, se
14:27:56 mriedem *sec
14:28:49 openstackgerrit Surya Seetharaman proposed openstack/nova master: Disable max_placement_results if affinity (or anti) is requested https://review.opendev.org/658110

Earlier   Later