Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-10
15:25:06 mriedem "* Future of compute host metrics monitoring in Nova"
15:25:24 mriedem http://docs.openstack.org/developer/nova/policies.html?highlight=monitoring#metrics-gathering
15:28:43 cfriesen mriedem: thanks for the links
15:32:37 cfriesen mriedem: is there any coalescing around a new standard metrics gathering tool?
15:34:45 mriedem cfriesen: not that i'm aware of,
15:34:49 mriedem there are lots of metrics gathering tools,
15:34:56 mriedem i'm sure there are probably at least 3 competing big tent projects
15:36:04 mriedem cfriesen: might be worth asking the telemetry and/or watcher teams,
15:36:11 mriedem edleafe is involved with watcher so he might have some tips
15:37:15 edleafe cfriesen: I'd ask in #openstack-watcher
15:37:23 edleafe oops! my manners
15:38:51 figleaf heh
15:40:03 openstackgerrit Dan Smith proposed openstack/nova master: Remove flavor_* functions from db/api https://review.openstack.org/431752
15:40:03 openstackgerrit Dan Smith proposed openstack/nova master: Remove main_db flavor compatibility https://review.openstack.org/431722
15:40:04 openstackgerrit Dan Smith proposed openstack/nova master: Remove straggling use of main db flavors in cellsv1 code https://review.openstack.org/432352
15:40:14 mriedem random question - why do we even have this decorator on compute_api.delete when it won't enforce anything? https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2152
15:40:43 mriedem i think everything in here will eval to False https://github.com/openstack/nova/blob/master/nova/compute/api.py#L130
15:40:54 mriedem so we'll never get InstanceInvalidState
15:42:24 cfriesen mriedem: is there no way to assert that the vm_state/task_state must be None?
15:42:40 mriedem that's not what None means there
15:42:42 cfriesen but yeah, that does seem pointless on the delete operation
15:42:48 mriedem None for that decorator means, i don't care about vm_state or task_state
15:42:54 cfriesen mriedem: yeah, I see that.
15:43:15 cfriesen mriedem: but what if I wanted to ensure that it actually was None?
15:43:49 cfriesen wait, I guess vm_state should be something else
15:44:02 mriedem then you pass in (None,)
15:45:03 sfinucan mriedem: We can't remove the floating IP nova-manage commands until we remove cells v1 and nova-network, correct? https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L305-L308
15:45:52 mriedem sfinucan: corect
15:45:53 mriedem *correct
15:45:55 mriedem i already tried
15:45:56 mriedem and gave up
15:46:00 mriedem b/c devstack uses those
15:46:11 sfinucan mriedem: aww :(
15:46:12 cfriesen mriedem: maybe it serves to assert that we don't care about the state?
15:46:28 mriedem cfriesen: then we shouldn't even use the decorator right?
15:46:43 sfinucan OK, I'll update that comment to reflect the new reality so
15:46:48 cfriesen mriedem: an argument could be made to that effect
15:52:26 cfriesen someone should tell leakypipes about VMs.
16:08:02 artom cfriesen, I hear there's a thing called OvenShack or something that can even manage VMs for you
16:09:47 superdan hah
16:16:50 openstackgerrit Sivasathurappan Radhakrishnan proposed openstack/nova master: Extract _post_live_migratiion_network_setup https://review.openstack.org/413021
16:17:48 openstackgerrit Sivasathurappan Radhakrishnan proposed openstack/nova master: [WIP] Network binding based on events https://review.openstack.org/432370
16:19:46 openstackgerrit Stephen Finucane proposed openstack/nova master: nova-manage: Update deprecation timeline https://review.openstack.org/432373
16:30:48 mriedem melwitt: some feedback in https://review.openstack.org/#/c/429075/
16:31:14 melwitt cool, thanks
16:36:43 kashyap mriedem: [OT?] Your response on that IRC thread made me chuckle, and do a `grep` for the said word (not going to repeat here, lest it ends up archives again)
16:36:50 kashyap So, it's not really _that_ bad:
16:36:53 kashyap $ grep $WORD ~/irclogs/FN-B/#openstack-nova.log | wc -l
16:36:54 kashyap 12
16:37:37 kashyap I checked that all entries were from you :-)
16:38:15 mriedem kashyap: heh
16:38:20 mriedem yeah i wasn't making it up
16:39:11 kashyap Oh, should mention the archives were starting only from 22-MAR-2015
16:40:24 kashyap mriedem: On a diff. topic, from your email on min libv version
16:40:43 kashyap Should the next one be 1.3.1, then?
16:40:55 kashyap FWIW, /me wrote this http://lists.openstack.org/pipermail/openstack-dev/2017-February/111933.html
16:41:01 mriedem kashyap: well, i know you always want bleeding edge so i'm not sure i can trust you here :)
16:41:05 mriedem i saw your response
16:41:23 mriedem your general comment on anything libvirt version related is "but that version was released 2 years ago?!"
16:42:06 kashyap mriedem: No, please don't be so harsh that I don't care about operators who don't care about bleeding edge.
16:42:40 kashyap mriedem: If you saw, I was careful to not mention any newer release on the response :-)
16:42:49 mriedem heh
16:43:00 mriedem so you mean bump to 1.2.9 and mark 1.3.1 as 'next'?
16:43:01 kashyap I know you'd chide me for that. Learnt from the burnt.
16:43:24 kashyap Yeah.
16:43:27 mriedem it sounded like sgordon was ok with going to 1.2.9
16:44:01 mriedem 1.3.1 would be nice since we have lots of checks we could drop after that i think
16:44:10 mriedem but that's queens at the earliest
16:44:25 kashyap Okay, maybe we need hard data here: to evaluate pros & cons w.r.t. features / critical bug fixes with 1.3.1 compared to 1.2.9
16:44:36 mriedem it's less about that,
16:44:39 mriedem and more about distro support
16:45:12 sgordon mriedem, from an RDO and RHOSP pov we always recommend folks use the latest RHEL anyway
16:45:15 kashyap Me nods. I am not ignoring the support matrix
16:45:31 sgordon mriedem, so right now while we still support OSP all the way back to icehouse, the recommended host OS for that is RHEL 7.3
16:45:48 sgordon mriedem, and that is the combination we currently (re)validate
16:46:07 mriedem which is libvirt 2.0
16:46:09 mriedem ballsy
16:46:13 sgordon correct
16:46:19 cfriesen mriedem: which distros do we care about
16:46:21 kashyap For upstream, we should also see what is available in Debian, too
16:46:33 sgordon (and of course anyone still on icehouse, isnt impacted by us changing the minimum for ocata anyway)
16:46:51 mriedem cfriesen: https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
16:48:04 mriedem so rhel would be ok with 1.3.1
16:48:10 mriedem i'm less sure about debian and sles/suse
16:48:54 mriedem maybe i should ask ajaeger
16:49:23 kashyap Yeah, if we can get the data from Debian and SUSE folks, we can settle on 1.3.1 -- as the cross-distro supported version, for upstream
16:49:58 mriedem zigo would know about debian
16:50:43 kashyap Yeah, would be better if they responded on the list, so the record is archived
16:51:22 mriedem i'll follow up with those guys
16:51:48 kashyap Thanks.
16:52:32 mordred debian stable has 1.2.9 - debian testing has 3.0.0
16:52:38 AJaeger hi nova team
16:52:47 cfriesen do we only care about LTS versions of Ubuntu?
16:53:06 mordred cfriesen: yah
16:53:16 AJaeger mriedem: what's up?
16:53:43 kashyap AJaeger: See the mailing list post:
16:53:49 mriedem AJaeger: see -infra now :)
16:53:54 AJaeger ;)
16:54:06 kashyap AJaeger: http://lists.openstack.org/pipermail/openstack-dev/2017-February/111902.html
16:54:06 mordred cfriesen: or, rather, we must care about at least the latest LTS- and we only test the latest LTS in the gate. our policy _technically_ is to target the latest ubuntu unless doing so would make backporting to latest lts unreasonably difficult ... but since in practice we gate on latest LTS ...

Earlier   Later