| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-17 | |||
| 11:57:06 | openstackgerrit | Alex Szarka proposed openstack/nova master: Add method for verify multiple notifications https://review.openstack.org/465526 | |
| 12:07:19 | openstackgerrit | jichenjc proposed openstack/nova master: WIP: remove flavor policy https://review.openstack.org/465505 | |
| 12:21:52 | openstackgerrit | Alex Szarka proposed openstack/nova master: [WIP] Transform instance.exists notification https://review.openstack.org/403660 | |
| 12:22:33 | openstackgerrit | Alex Szarka proposed openstack/nova master: [WIP] Transform instance.exists notification https://review.openstack.org/403660 | |
| 12:35:45 | Miouge | Is there an extra spec (flavor or image) to configure <cpu mode='host-passthrough'> with libvirt? I know of cpu_mode in nova.conf but that’s for a whole compute node | |
| 12:37:59 | openstackgerrit | Alex Szarka proposed openstack/nova master: Add method for verify multiple notifications https://review.openstack.org/465526 | |
| 12:38:13 | openstackgerrit | Alex Szarka proposed openstack/nova master: [WIP] Transform instance.exists notification https://review.openstack.org/403660 | |
| 12:39:52 | sfinucan | Miouge: not that I'm aware of, and it's not something we'd be eager to enable | |
| 12:40:38 | artom | mriedem, I thought it was OK to continue using mox when it's already in place? | |
| 12:40:51 | artom | I essentially copy-pasted an existing test and tweaked it a bit | |
| 12:42:22 | Miouge | sfinucan: curious to why not something eager to enable, recommended to use cpu_nova.conf and a separate host aggregate instead? | |
| 12:42:23 | mriedem | artom: not for new tests | |
| 12:42:24 | artom | mriedem, anyways, I think we had this discussion previously, and it was only dansmith who persuaded you to let it go, so I'll just fix my test, shall I | |
| 12:42:28 | mriedem | artom: new tests should be written in mock | |
| 12:42:28 | artom | ;) | |
| 12:42:53 | mriedem | artom: using mox to tweak existing tests that are using mox is acceptable | |
| 12:43:53 | sfinucan | Miouge: The comments in this spec should explain the position :) https://review.openstack.org/#/c/387295/ | |
| 12:44:12 | sfinucan | ...and host aggregates would be preferred, yes | |
| 12:44:54 | artom | mriedem, fair enough. If I ever find the discussion I'm thinking of I'll wave it in your face, but yeah, I won't be lazy and do the new test with mock ;) | |
| 12:45:16 | mriedem | artom: i remember it, it was some nova-network live migration thing | |
| 12:45:29 | mriedem | and i believe dansmith went back afterward and re-wrote the tests in mock | |
| 12:46:08 | mriedem | artom: see #4 here https://docs.openstack.org/infra/manual/developers.html#peer-review | |
| 12:51:30 | dane-fichter | hey dansmith, could you take a look at my trusted certs patch when you get a chance? | |
| 12:51:37 | dane-fichter | https://review.openstack.org/#/c/457711/ | |
| 12:52:26 | dane-fichter | It's passing unit tests, not sure if there's anything else I need to implement here | |
| 12:53:36 | sdague | dansmith / mriedem: thinking about the thing that came up in the cells forum session around searching by ip .... | |
| 12:53:51 | sdague | it's really pathologically bad in our code | |
| 12:54:18 | mriedem | i looked it up after the session, | |
| 12:54:23 | mriedem | and it wasn't mysql or pg specific | |
| 12:54:30 | sdague | nope | |
| 12:54:31 | mriedem | it was originally just about a security bug | |
| 12:54:39 | sdague | mriedem: what was the security bug? | |
| 12:55:00 | mriedem | api would call down to nova-network which would pull all instances from the db and iterate them filtering on ip, something like that | |
| 12:56:39 | sdague | ok, so removing nova-network out of the flow, we're now just loading every instance, loading every network info cache, and grepping through each json? | |
| 12:56:46 | sdague | especially in the all_tenants case | |
| 12:57:49 | mriedem | https://github.com/openstack/nova/commit/ae781ee97947c33d6d43e4c21df4f338c875bf1c was the original change | |
| 12:58:43 | mriedem | sdague: not sure how you'd do the filtering in the db when the instance_info_cache.network_data is serialized json | |
| 12:59:14 | mriedem | *network_info | |
| 12:59:30 | sdague | right, in order to make it efficient we'd need to extract the search keys that we wanted to hit into a column | |
| 12:59:48 | sdague | which you could do, just denormalize it a bit | |
| 13:00:55 | sdague | given that the ip search is regex, you could even just make it a comma separated list, and still do the second stage filter, but it would drop a lot of db bloat | |
| 13:01:37 | sdague | anyway, just pondering that, given it seemed like it was a query many wanted to do, and it's one of our most pathologically bad ones | |
| 13:01:51 | mriedem | and it's also been this way forever.. | |
| 13:02:26 | mriedem | if we had numbers on how long it takes to do the filter on an all_tenants call with 1000 instances or something, then it might be more interesting | |
| 13:02:53 | sdague | mriedem: yeh data would be good | |
| 13:03:22 | sdague | it does also mean though if you exceed 1000 instances in your filter set before ips, you'll get the wrong answer, right? | |
| 13:03:32 | sdague | that's actually the thing I'm more concerned about | |
| 13:03:54 | mriedem | true, if the ip you're looking for is the 1001 instance, you're not going to get anything back | |
| 13:04:15 | sdague | if nothing else, we should describe that issue | |
| 13:05:15 | mriedem | yeah, definitely, | |
| 13:05:19 | mriedem | could go into the api-ref | |
| 13:05:44 | mriedem | i feel like there was something else we said we'd doc in the api-ref but i'm forgetting - i think notes are in etherpads though, and i haven't digested those yet | |
| 13:06:25 | mriedem | ip (Optional) query string An IPv4 address to filter results by. | |
| 13:06:25 | sdague | well, in mysql we could - https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-contains | |
| 13:06:32 | mriedem | ^ is the api-ref and doesn't mention anything about this | |
| 13:06:40 | sdague | mriedem: yep, I know | |
| 13:06:46 | sdague | I honestly didn't realize how bad it was | |
| 13:07:59 | mriedem | looks like postgresql does too https://www.postgresql.org/docs/9.3/static/functions-json.html | |
| 13:08:27 | mriedem | http://schinckel.net/2014/05/25/querying-json-in-postgres/ | |
| 13:09:52 | rabel | Hi there, I'm a little bit confused about quotas in nova. To start with: Can anyone tell me, what a quota class is? And how are those related to default quotas? How do default quotas work in detail? For example why does a project have default quotas? I thought default quotas are global quotas that take effect for projects without quotas? | |
| 13:12:06 | mriedem | rabel: se | |
| 13:12:07 | mriedem | *sec | |
| 13:12:37 | mriedem | rabel: some notes here https://docs.openstack.org/developer/nova/quotas.html | |
| 13:12:52 | mriedem | rabel: there is only one quota class and it's "default" | |
| 13:13:18 | mriedem | some more info here https://review.openstack.org/#/c/411035/ | |
| 13:14:47 | rabel | mriedem: thank you very much! do you know if other openstack components differ in this regard? | |
| 13:18:35 | mkoderer | mriedem: ping | |
| 13:18:40 | bhagyashris | Hi all, Can anyone please guide me How to check the memory consumption or memory during the process initialization suppose for n-cpu service? Is there any command to check this? | |
| 13:22:10 | rabel | mriedem: what is still confusing to me is the --default option of "openstack quota show", which shows default quotas for a given project or class. that does not seem to make a lot of sense. what do you think? | |
| 13:30:35 | mriedem | rabel: i think that's trying to match the nova quota-defaults CLI | |
| 13:31:38 | mriedem | mkoderer: pong | |
| 13:32:10 | mkoderer | mriedem: dgonzalez and I wanted to discuss a tricky bug with you: https://bugs.launchpad.net/nova/+bug/1691131 | |
| 13:32:11 | openstack | Launchpad bug 1691131 in OpenStack Compute (nova) "IO stuck causes nova compute agent outage" [Undecided,New] | |
| 13:32:55 | mkoderer | nova-compute stops sending it's heartbeats if we have a NFS overload | |
| 13:33:30 | mkoderer | and with this we can't control the cloud anylonger since stopping of vms is not possible anylonger | |
| 13:33:41 | mriedem | mkoderer: which release? | |
| 13:33:56 | mkoderer | we are on liberty - but the code is the same on master | |
| 13:34:05 | mriedem | "The nova-compute services scans over all attached volume paths" | |
| 13:34:11 | mriedem | which part specifically are you referring to there? | |
| 13:34:40 | rabel | mriedem: so, let me summarize: the only quota class is "default" and the concept of quota classes will probably soon be removed. default quotas are quotas that take effect if there is no project-specific quotas. and having default quotas for a project/class does not make sense. is this correct in your opinion? | |
| 13:35:24 | mriedem | "and having default quotas for a project/class does not make sense" - why does that not make sense? | |
| 13:35:34 | mriedem | rabel: having default quota (limits) is fine | |
| 13:36:08 | mriedem | having an api and database for quota classes when there is only ever a single entry though, is weird | |
| 13:36:15 | mriedem | *database table | |
| 13:36:57 | mkoderer | mriedem: this part blocks: https://github.com/openstack/nova/blob/902b7bf6f5425824a0661b8e4beac4a894749c03/nova/virt/libvirt/driver.py#L7022 | |
| 13:37:28 | rabel | mriedem: default quotas do make sense. but how are they connected to a specific project? isn't the idea of default quotas that they are global? | |
| 13:37:28 | dansmith | sdague: mriedem: setting the precedent of loading json in mysql seems not awesome | |
| 13:37:42 | dansmith | sdague: mriedem: I'd almost rather just build a separate index of that thing, if it's a thing people do often | |
| 13:38:06 | dansmith | sdague: mriedem: also, it's something rather easy that a client can do right? find the port/device_id in neutron and then show the instance in nova? | |
| 13:41:57 | bauzas | dansmith: edleafe: tbc, I'm working on updating my series given dan's comments | |
| 13:42:14 | dansmith | bauzas: sweet :) | |
| 13:42:33 | bauzas | just has a problem with a 2-instances request | |
| 13:42:42 | edleafe | bauzas: cool. I'll be pushing an update to my series, but it's just a pep8 fix, so don't freak out | |
| 13:42:42 | bauzas | because I need more hosts than just 4 | |
| 13:42:56 | sdague | dansmith: expect, neutron api isn't always exposed correctly directly to users | |
| 13:43:17 | sdague | dansmith: yeh, secondary index would be fine as well | |
| 13:43:36 | bauzas | edleafe: which one do you think you want to update ? the ones about passing the UUIDs and the scheduler claims? | |
| 13:44:26 | edleafe | bauzas: yep | |
| 13:44:30 | bauzas | ok | |
| 13:45:19 | dansmith | sdague: could we also just special case that search by asking neutron ourselves and then pulling the relevant instances out ? | |