Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-27
13:27:36 sfinucan We're thinking that will require physical hardware. Not sure if it's something the Intel PCI CI could validate or not
13:27:53 johnthetubaguy cdent: does my comment make sense?
13:28:00 johnthetubaguy going to fix up now, and push it
13:28:22 cdent oh hell
13:28:38 cdent i hate it when it is something like that
13:29:23 cdent I just assumed that was correct because all this service version stuff is new to me
13:29:30 cdent savagely educated
13:29:56 johnthetubaguy I read that three times and checked it
13:30:07 openstackgerrit John Garbutt proposed openstack/nova: Scheduler calling the Placement API https://review.openstack.org/417961
13:30:22 johnthetubaguy I like that phrase
13:30:25 johnthetubaguy its a bit like used in anger
13:30:30 cdent "bugger" is the best comment ever
13:30:43 johnthetubaguy its the correct british way, I feel
13:30:49 cdent quite
13:30:56 johnthetubaguy one doesn't want to offend
13:31:08 cdent unless one really needs to
13:31:13 cdent we were nearly there
13:31:13 johnthetubaguy heh
13:31:23 johnthetubaguy so I left the debugging in, just in case
13:31:44 cdent good choice
13:35:07 cdent edleafe: you surfaced yet?
13:36:38 markus_z dansmith: If you find time to review: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton+topic:%22bug+1455252%22
13:42:52 markus_z ^ or any other stable core, I'm not picky ;)
13:54:26 figleaf cdent: I'm here
13:55:07 cdent figleaf: just wanted to know if you're up to date on the above
13:55:20 figleaf cdent: still reading...
13:55:50 figleaf cdent: want to give me the summary?
13:56:22 cdent figleaf: the only thing that real matters is: https://review.openstack.org/#/c/417961/35/nova/scheduler/filter_scheduler.py
13:56:29 cdent (john's discovery)
13:56:44 figleaf just reading the 'bugger' comment :)
13:57:39 figleaf looks like johnthetubaguy has taken care of it
13:58:16 cdent yes
13:58:21 figleaf and I have a merge conflict on the last of the RP series https://review.openstack.org/#/c/414769/
13:58:55 cdent the debugging stuff that's right around bauzas patch is still in there for the current gate run, but if it happys will be cleared out
13:59:22 figleaf cool
13:59:44 cdent we're not trying to get nested rps in ocata, or are we?
14:00:08 figleaf cdent: yes, but they won't be doing very much at all
14:01:05 cdent then I guess my rp update 9 email is wrong, could you extend it?
14:02:20 jroll cdent: figleaf: safe to assume we didn't get the extra_specs=CUSTOM_FOO_RESOURCE_CLASS=1 thing done, right?
14:02:24 johnthetubaguy the ironic custom stuff, I guess we don't query that either yet, but if its in this cycle we can query it next cycle?
14:02:42 johnthetubaguy is looking at: https://review.openstack.org/#/c/404472
14:02:47 jroll johnthetubaguy: I think we have similar questions :)
14:02:56 cdent jroll: the handling of extra specs, no, but the recording of inventory is still trying to get in
14:03:06 johnthetubaguy jroll: heh, yup
14:03:20 figleaf cdent: dammit, you type too fast
14:03:48 jroll cdent: right, so operators cannot change their flavors until pike, so we can't cut over how we schedule until q :(
14:04:27 jroll with 'cut over' ~= 'drop cpu/ram/disk-based scheduling'
14:04:36 figleaf jroll: wait - why can't they update their flavors? The new stuff will be ignored, but still...
14:04:48 cdent jroll: I guess so? :( It's been really hard to track some of this
14:05:17 jroll figleaf: because a flavor with cpu/ram/disk won't work in the new world, where ironic resource providers don't have cpu/ram/disk
14:05:40 jroll it would require CUSTOM_FOO *and* 2 vcpu and 16384 rams, etc
14:06:09 johnthetubaguy so I am reading through, it looks like each nova-compute node can only look at one ironic resource_class, is that correct?
14:06:16 jroll the old flavors are incompatible with the new
14:06:44 figleaf jroll: ah, so they could update their flavors, but the flavors will have both the resource class name *and* the vm-ish stuff too
14:07:09 figleaf johnthetubaguy: that's the idea
14:07:40 jroll figleaf: yeah, something like that
14:08:03 johnthetubaguy jroll: are we OK with nova-compute to resource class 1:1 mapping?
14:08:05 figleaf jroll: the scheduler/placement will just ignore the former for now, and at some point, switch to ignoring the latter
14:08:53 figleaf johnthetubaguy: to be clear, there can be multiple nova-computes that are mapped to the same resource class
14:09:37 jroll figleaf: I'm skeptical, how would it know to ignore ram/cpu for that flavor (but not for a virt flavor)?
14:10:09 jroll johnthetubaguy: that seems... wrong. are we talking nova-compute service or compute_node entry? a compute service should handle more than one resource class fine
14:10:51 jroll there should be n:1 node:resource_class, and m:n service:resource_class
14:11:21 johnthetubaguy jroll: that was my assumption
14:12:06 figleaf jroll: there will probably be an "if _is_ironic():" check added to that code to look for the resource class
14:12:12 jroll johnthetubaguy: I also don't see that n:1 service:resource_class in the code
14:12:25 johnthetubaguy jroll: the resource class request's presence just always dominates any other request, that seems fine
14:13:57 cdent Is it normal for us to be as confused about stuff as we've been?
14:14:04 johnthetubaguy figleaf: I guess we can make it nested, once we have nested?
14:14:43 johnthetubaguy cdent: thats probably yes, I prefer the "can we do better at this" question, I hope thats a yes too
14:15:00 cdent just checking
14:15:04 johnthetubaguy jroll: I am looking here: https://review.openstack.org/#/c/404472/23/nova/compute/resource_tracker.py@525
14:15:11 johnthetubaguy cdent: its good to check these things
14:15:18 cdent I'm trying to decide whether it is reasonable to be chill or panicky
14:15:57 jroll johnthetubaguy: yeah, so that's for a single ironic node, and that code will run once per ironic node
14:16:29 openstackgerrit Andrey Volkov proposed openstack/nova: WIP Update pci device fields from deleted object https://review.openstack.org/426243
14:16:46 figleaf cdent: it's more the overlapping terminology that confuses me
14:16:56 johnthetubaguy jroll: doh, I see the loop now
14:17:05 figleaf "compute" can mean multiple things
14:18:00 johnthetubaguy figleaf: sorry, I see what you were trying to tell me now
14:18:08 jroll figleaf: I've learned to always say compute *service* (nova-compute process) or compute *node* (the hypervisor/hardware), it seems to help
14:18:33 cdent jroll: if you said compute service to me, I'd assume you meant all of nova
14:19:00 jroll cdent: ahem, "nova-compute service"
14:19:00 cdent language is hard
14:19:02 jroll heh
14:21:39 openstackgerrit Sam Betts proposed openstack/nova: Change order of _cleanup_deploy and _unprovision in Ironic virt https://review.openstack.org/422678
14:21:40 jroll through an IV
14:23:48 cdent jroll++
14:26:30 artom Intra-vineous :D
14:26:38 figleaf johnthetubaguy: in that case, let's make some wine!
14:28:24 openstackgerrit Andrey Volkov proposed openstack/nova: WIP Update pci device fields from deleted object https://review.openstack.org/426243
14:36:49 johnthetubaguy figleaf: best idea I heard all day
14:39:19 BlackDex hello again. I'm having trouble with nova-consoleauth
14:39:31 BlackDex i have an ha setup, with hacluster and a vip
14:39:37 BlackDex 3 systems
14:40:01 BlackDex if i use horizon to view the console i have a 1 in 3 times luck to get the console to view
14:40:42 BlackDex i have configured memcached, but nothing is getting into memcached, i can connect to memcached from the nova-controle nodes
14:47:20 superdan that scheduler change failed on the old side due to volumes and neutron
14:47:21 cdent johnthetubaguy, dansmith : looks like the latest multinode grenade failed on timeouts this time
14:47:25 cdent jinx
14:47:27 superdan heh

Earlier   Later