| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-23 | |||
| 16:39:48 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: add cells v2 FAQ on refreshing global cells cache https://review.openstack.org/467318 | |
| 16:46:24 | ihrachys | anyone seen the failure? https://bugs.launchpad.net/neutron/+bug/1692984 | |
| 16:46:24 | openstack | Launchpad bug 1692984 in neutron "VM boot fails with "TCG doesn't support requested feature: CPUID.01H:ECX.vmx"" [High,New] | |
| 16:46:58 | mriedem | ihrachys: nope, libvirt/qemu fun | |
| 16:47:00 | mriedem | kashyap: ^ | |
| 16:47:18 | ihrachys | I am not completely sure this is the culprit. the log suggests it's a 'warning' | |
| 16:47:35 | ihrachys | so *maybe* it just spills it as part of stderr when some other failure happens. | |
| 16:47:45 | ihrachys | I am too dumb to distinguish :) | |
| 16:49:42 | mriedem | please standby, firefox is struggling to open logs | |
| 16:50:31 | mriedem | ihrachys: it definitely killed the server build http://logs.openstack.org/83/466983/1/check/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/bd69e6b/logs/screen-n-cpu.txt.gz?level=TRACE#_May_23_03_04_29_688986 | |
| 16:51:55 | ihrachys | yeah, sure. I am merely saying I am not sure if the cpu flag thing is a red herring, or the culprit of the failure | |
| 16:52:35 | jaypipes | cdent: in a gabbit, can I test for greater or equal to a value? | |
| 16:52:55 | jaypipes | cdent: for example, $.traits.`len`: 2 | |
| 16:53:07 | jaypipes | cdent: can I change that to test for >= 2? | |
| 16:53:14 | cdent | maybe, I need to do some checking | |
| 16:53:34 | mriedem | ihrachys: hmm, yeah http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22process%20exited%20while%20connecting%20to%20monitor%3A%20warning%3A%20TCG%20doesn't%20support%20requested%20feature%3A%20CPUID.01H%3AECX.vmx%20%5Bbit%205%5D%5C%22%20AND%20tags%3A%5C%22screen-n-cpu.txt%5C%22&from=7d | |
| 16:53:41 | mriedem | ihrachys: it's definitely not 100% failure | |
| 16:53:43 | mriedem | not even close | |
| 16:56:19 | ihrachys | right. so I was thinking, maybe it's just spilled all the time, but we dump stderr on failures. but other log messages are very generic to my taste, and I needed to capture something in the bug, so... | |
| 16:57:24 | cdent | jaypipes: simple answer is "not really" but you could perhaps do a regex to get the results you want?: /[2-9]/ | |
| 16:57:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: add cells v2 FAQ on mapping instances https://review.openstack.org/467322 | |
| 16:58:41 | mriedem | pabelanger: dansmith: fyi, no one replied to my question about doing PUT for keypairs in the ops channel | |
| 16:58:41 | cdent | jaypipes: the limitation at this point is that the RHS is that the assert is either an assertEqual or an assertRegex | |
| 17:12:16 | jaypipes | cdent: k, no prob. thx! | |
| 17:21:53 | jaypipes | mriedem, smcginnis: if it makes you feel any better (doubtful), k8s is dealing with similar feature requests and inconsistent UX around volume types. There, it's called dynamicStorageClass but the concept is virtually identical | |
| 17:22:52 | cfriesen | jaypipes: got a sched race for you to consider for placement/claims: 2 vms in server group with anti-affinity, both vms get migrated at same time, scheduler picks same host for both, both end up on same host. | |
| 17:23:23 | jaypipes | cfriesen: two trains leave New York and San Francisco, each going 60mph... | |
| 17:23:27 | cfriesen | jaypipes: make that live-migrated. ^ | |
| 17:24:10 | cfriesen | not sure how to fix this without either atomic schedule/claim or secondary check on compute and possible reschedule | |
| 17:24:34 | cfriesen | (I guess secondary check could be anywhere post-claim) | |
| 17:25:00 | jaypipes | cfriesen: we can dramatically decrease the length of time that such a decision can be made with claims in the scheduler... | |
| 17:26:18 | cfriesen | jaypipes: agreed, | |
| 17:27:49 | cfriesen | but it might still make sense to allow reschedule within the cell | |
| 17:30:45 | jaypipes | cfriesen: yes, perhaps. | |
| 17:31:00 | jaypipes | cfriesen: trying to avoid that though if possible. (doesn't look like we'll be able to, though) | |
| 17:33:53 | pabelanger | mriedem: dansmith: Ya, for now we are leaning towards updating ansible os_keypair module to support the update functionality | |
| 17:34:10 | pabelanger | then delete / create the key with same name | |
| 17:40:45 | cfriesen | jaypipes: something to consider in the above scenario...if we have an anti-affinity instance migrating from host1 to host2, we probably want to exclude *both* hosts from consideration when scheduling other instances in the same group. | |
| 17:42:27 | jaypipes | cfriesen: sure, no disagreement. | |
| 18:00:40 | ildikov | lyarwood: sfinucan: hi | |
| 18:00:46 | ildikov | lyarwood: sfinucan: if you have some time there're two patches related to the new Cinder attach/detach flow with one +2 already: https://review.openstack.org/#/c/459111/ https://review.openstack.org/#/c/459113/ | |
| 18:00:55 | ildikov | lyarwood: sfinucan: tnx :) | |
| 18:06:48 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/467344 | |
| 18:10:26 | efried | jaypipes johnthetubaguy mordred Would y'all please have a look at this spec update? Been +2 for a few weeks. https://review.openstack.org/#/c/461481/ | |
| 18:12:02 | efried | But the pen IS mightier than the sword, so... | |
| 18:12:07 | jaypipes | :) | |
| 18:14:03 | jaypipes | efried: done. | |
| 18:14:10 | efried | jaypipes Thanks dude. | |
| 18:16:42 | efried | jaypipes Still on my list to ask you for that pointer to the shared resource pool code. Is that a quick answer? | |
| 18:17:17 | jaypipes | efried: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/shared-resources-pike | |
| 18:20:58 | efried | jaypipes Okay, looking through. I know you've slept (in multiple time zones) since then, so to refresh your memory on the conversation: I'm looking to get my compute driver itself to do the registration of its shared storage pool. | |
| 18:21:21 | jaypipes | efried: ah. yeah, sorry.. one sec | |
| 18:21:45 | jaypipes | efried: https://review.openstack.org/#/c/457782/ | |
| 18:21:49 | efried | jaypipes As impressive as your SQL construction is... ;-) | |
| 18:21:54 | jaypipes | efried: that's more what you're looking for I think? | |
| 18:21:58 | efried | ... | |
| 18:22:20 | jaypipes | speaking of which... dansmith, if you or bauzas have a chance to review https://review.openstack.org/#/c/457782/, that would be great | |
| 18:22:44 | efried | hmph, I've been watching this change set; but clearly didn't realize what I was looking at... | |
| 18:22:48 | dansmith | oh that fell off, I'll look | |
| 18:28:14 | efried | jaypipes I don't think this is quite what I'm looking for. I do think I'd like to do it from get_inventory(); but what I'm looking to do involves talking to the placement API and saying something like, "Do ya got a shared storage pool with UUID <uuid>? No: Okay, here it is. ==> And this compute host is part of it." | |
| 18:29:00 | jaypipes | efried: yeah, you'll have to wait a bit for a few more patches in that shared-resources-pike series to get to that | |
| 18:29:54 | efried | jaypipes Roger that. If it helps, the words I wrote down while we were chatting were: "scheduler client report" | |
| 18:44:32 | mordred | mriedem: in my ongoing effort to report 'fun' api interactions ... | |
| 18:44:43 | mordred | efried: (I just opened that link, will look in a sec) | |
| 18:45:03 | cfriesen | weird question....if we start with nova version N, and upgrade everything to N+1, am I correct that Service._check_minimum_version() would prevent us from downgrading even if the RPC is explicitly still set to something suitable for version N? | |
| 18:45:34 | jaypipes | efried: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py | |
| 18:45:54 | mordred | mriedem: today I learned that GET /os-simple-tenant-usage?start=%s&end=%s&detailed=%s ... which takes an ISO 8601 date string as input for start and ed | |
| 18:46:11 | mordred | mriedem: fails if your ISO 8601 date string includes a timezone offset | |
| 18:46:23 | jaypipes | efried: and an example of usage from the scheduler: https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L170 | |
| 18:46:59 | mriedem | mordred: yeah https://developer.openstack.org/api-ref/compute/?expanded=list-tenant-usage-statistics-for-all-tenants-detail#id365 | |
| 18:47:10 | mordred | mriedem: so it is incumbent on a consumer to take their ISO 8601 date string, apply the timezone offset expressed in the string and then submit the string without the timezone offset | |
| 18:47:24 | jaypipes | efried: and where the compute resource tracker calls it: https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L759-L763 | |
| 18:47:39 | mordred | mriedem: indeed - so it is documented, which is nice :) | |
| 18:48:45 | mordred | mriedem: however, also, python-novaclient does this: | |
| 18:48:48 | mordred | return self._list( | |
| 18:48:49 | mordred | "/os-simple-tenant-usage?start=%s&end=%s&detailed=%s" % | |
| 18:48:51 | mordred | (start.isoformat(), end.isoformat(), int(bool(detailed))), | |
| 18:48:54 | mordred | "tenant_usages") | |
| 18:49:17 | mordred | so if the datetime passed to python-novaclient is a datetime that has a tzinfo attached, sadness occurs - because it isn't actually isoformat that is accepted | |
| 18:49:44 | mordred | (this is what results from starting by looking at the novaclient code instead of the docs for how to work an API, btw) | |
| 18:50:57 | openstackgerrit | Dan Smith proposed openstack/nova master: re-Allow adding computes with no ComputeNodes to aggregates https://review.openstack.org/460616 | |
| 18:51:02 | dansmith | mriedem: rebased ^ | |
| 18:51:11 | mriedem | mordred: it also does this thing https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/usage.py#L32 | |
| 18:51:53 | mriedem | which is related to this thing in the api https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/simple_tenant_usage.py#L228 | |
| 18:52:35 | mordred | fascinating | |
| 18:53:26 | mordred | mriedem: I'm truly curious as to the reasoning behind defining our own format that isn't the ISO standard but close to it - but it's not super important ... I mostly just learned a new thing today and want to check in and see if it was bug or feature | |
| 18:53:53 | mriedem | changing it would be a microversion | |
| 18:54:04 | mriedem | why it's that way, you'd have to ask vish or someone | |
| 18:54:44 | sdague | or mordred or jaypipes | |
| 18:54:47 | mordred | I don't think it needs to change -since it's clearly documented and has obviously been implemented on purpose -- I've got the conversion call written on my side now | |
| 18:54:54 | mriedem | yeah no sh*t, *those* guys | |
| 18:55:01 | mordred | jaypipes: oh - you're here ... can you tl;dr me? ^^ | |
| 18:55:35 | jaypipes | mordred: ya, me here. | |
| 18:55:37 | mordred | mriedem: would I be safe in assuming that anywhere nova takes a date it's gonna be in that format and not full ISO? | |
| 18:55:56 | mriedem | i don't know where else we take a date | |
| 18:56:51 | mriedem | the compute api ref has a standard description for fields in the response that are a datetime | |
| 18:57:41 | mriedem | e.g. https://github.com/openstack/nova/blob/master/api-ref/source/parameters.yaml#L1648 | |
| 18:57:58 | jaypipes | sdague: I have no part in the making of os-simple-tenant-usage... | |
| 18:58:58 | sdague | mordred: the best recollections I've got are there are at least 3 different time formats because people picked things oddly (all predates me) | |
| 18:59:20 | sdague | I think the oslo utils actually take any of them and digest into the same thing | |