| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-14 | |||
| 14:44:07 | sdague | mriedem: in the nova tree? | |
| 14:44:30 | mriedem | sdague: yes, where placement currently lives | |
| 14:44:33 | sdague | I'm definitely -1 on in the nova tree, those things shouldn't be coupled that way | |
| 14:44:44 | mriedem | so openstack/placement-osc-plugin? | |
| 14:44:52 | sdague | mriedem: sure | |
| 14:45:05 | sdague | it can be under nova control, but you don't want to pip install all of nova | |
| 14:45:14 | sdague | to get 200 lines of osc plugin | |
| 14:45:14 | mriedem | oh right i didn't think about that | |
| 14:45:20 | bauzas | good point | |
| 14:45:21 | sean-k-mooney | mriedem: would it not make sense to have the placement osc plugin live in the placement repo when that is created | |
| 14:45:29 | mriedem | sean-k-mooney: but that's not pike, | |
| 14:45:32 | mriedem | or maybe even queens | |
| 14:45:39 | sdague | sean-k-mooney: no, it would not | |
| 14:45:51 | sdague | osc plugins should not be in the trees of larger projects | |
| 14:45:55 | bauzas | yeah | |
| 14:45:56 | jroll | mriedem: how we do osc stuff is the osc plugin goes in the python-ironicclient tree | |
| 14:46:08 | sdague | because osc plugins should be super minimal | |
| 14:46:21 | jroll | seems to work well, and you'll need the ironicclient dep anyway | |
| 14:46:34 | mriedem | jroll: we wouldn't have a dep on a placementclient though | |
| 14:46:49 | sean-k-mooney | sdague: oh ok. i guess you can use depends-on to track patches to both but i just assumend it would be eaisier to keep them in sync if the clients and apis were in the same repo | |
| 14:46:55 | openstackgerrit | Alex Szarka proposed openstack/nova master: Transform instance-exists notification https://review.openstack.org/403660 | |
| 14:47:07 | sdague | sean-k-mooney: the whole point of osc is to optimize for consumption | |
| 14:47:32 | sean-k-mooney | sdague: ah so you want them to be seperate to minimies the code footprint | |
| 14:47:34 | jroll | mriedem: ah, yeah I guess just it's own repo makes sense to me then | |
| 14:47:43 | sdague | and, honestly, I'm not really sure why we would do things that way vs. just put it into osc directly | |
| 14:47:55 | mriedem | sdague: i'm talking with dtroyer in -dev | |
| 14:48:00 | mriedem | if you want to ask about it living in osc directly | |
| 14:48:08 | mriedem | because i thought they didn't want more stuff living in osc directly, | |
| 14:48:09 | openstackgerrit | Alex Szarka proposed openstack/nova master: Transform instance.resize.error notifications https://review.openstack.org/417882 | |
| 14:48:13 | mriedem | just like tempest wants to move things to plugins | |
| 14:51:01 | dansmith | I guess there's no support for generating multiple packages from one source, like deb and rpm can do? | |
| 14:51:51 | jroll | dansmith: pbr doesn't do that, no | |
| 14:53:49 | mriedem | melwitt: did you happen to get a functional test started for https://review.openstack.org/#/c/444106/ ? if not, i could try starting something there | |
| 14:54:16 | dansmith | jroll: yeah, that's a bummer | |
| 14:54:23 | jroll | indeed | |
| 15:10:03 | mriedem | cdent: bauzas: dansmith: sdague: jaypipes: ok here is a simple blueprint to start tracking the osc plugin stuff https://blueprints.launchpad.net/nova/+spec/placement-osc-plugin | |
| 15:10:22 | mriedem | with enough detail to hopefully get someone started, maybe someone from osic - they are an infinite resource right? | |
| 15:11:13 | cdent | ✔ | |
| 15:18:59 | johnthetubaguy | mriedem: I wish we had that ;) | |
| 15:19:18 | johnthetubaguy | raj_singh: I guess everyone is busy right now right? | |
| 15:20:39 | johnthetubaguy | mriedem: but +1 documenting it so someone can take that on | |
| 15:20:49 | sdague | dansmith / jroll it's not just a pbr limitation, there are other substantial issues there with the python packaging toolchain | |
| 15:21:13 | raj_singh | johnthetubaguy: yea running out of bandwidth for this cycle | |
| 15:22:05 | jroll | sdague: that's the understatement of the day :) | |
| 15:22:17 | jroll | I know pbr has hard blockers for it, that's all I wanted to point out | |
| 15:22:20 | mriedem | Kevin_Zheng: i know it's late for you, just fyi that https://review.openstack.org/#/c/429569/ could use some small improvements and then i'm +2 | |
| 15:25:51 | openstackgerrit | Dan Smith proposed openstack/nova master: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025 | |
| 15:25:55 | dansmith | bauzas: can you look at this ^ ? | |
| 15:26:23 | dansmith | bauzas: I think that's what you're going for.. I still need to do some tests and fix the commit message and stuff, but I think that will efficiently make the caching scheduler behave the same as the filter scheduler | |
| 15:26:41 | bauzas | dansmith: sure, will do | |
| 15:26:47 | dansmith | i.e. filter based on cell per request, from the global collected list | |
| 15:26:58 | bauzas | dansmith: I need to go to the garage soon, but I'll look at it quickly | |
| 15:27:13 | dansmith | just a brief look to see if it's what you meant would be good | |
| 15:27:20 | dansmith | then I'll release you to the garage | |
| 15:28:55 | bauzas | dansmith: so https://review.openstack.org/#/c/438025/23/nova/scheduler/caching_scheduler.py | |
| 15:29:22 | bauzas | dansmith: lgtm, but I was also thinking about _get_by_hosts() returning a dict instead of a list | |
| 15:29:38 | bauzas | oops _get_up_hosts | |
| 15:29:53 | bauzas | dansmith: so we could just lookup by the cell name | |
| 15:30:00 | hamzy | hey mriedem I think that I am running into https://bugs.launchpad.net/nova/+bug/1670627 is there a way to clean up the instances from the CLI? I guess that I need to do some DB cleanup? | |
| 15:30:00 | openstack | Launchpad bug 1670627 in OpenStack Compute (nova) ocata "quota is always in-use after delete the ERROR instances " [Critical,In progress] - Assigned to Matt Riedemann (mriedem) | |
| 15:30:56 | dansmith | bauzas: okay, I need to see how much change that is to the other stuff, but probably okay | |
| 15:31:16 | bauzas | dansmith: it's just a nit tho | |
| 15:31:31 | bauzas | dansmith: but I'd prefer both of them rather than a filter | |
| 15:31:59 | mriedem | hamzy: the instances are deleted right? | |
| 15:32:13 | mriedem | hamzy: the problem is the quota usage isn't decremented | |
| 15:32:17 | hamzy | mriedem, yes "nova list --all-tenants" shows nothing | |
| 15:32:32 | hamzy | My compute overview page shows "RAM Used 48GB of 50GB" and 6 used instances... | |
| 15:32:57 | dansmith | bauzas: yeah, I don't know why I didn't think to do this when johnthetubaguy and I were talking about it.. probably just misunderstanding the cachingscheduler at the time | |
| 15:33:06 | mriedem | hamzy: yeah, and the "nova_cell0.usages" table should have that information in it, can you confirm | |
| 15:33:07 | mriedem | ? | |
| 15:33:14 | mriedem | oh wait, sorry, | |
| 15:33:16 | mriedem | not nova_cell0, | |
| 15:33:19 | mriedem | just nova.usages | |
| 15:33:34 | bauzas | dansmith: the problem with a filter is that operators would need to modify their config for an upgrade | |
| 15:33:38 | hamzy | mriedem, I have an AIO installation with a bunch of containers... do I need to attach to one of them> | |
| 15:33:45 | bauzas | dansmith: or they wouldn't check the cells | |
| 15:34:03 | bauzas | if they forget to modify their conf opt | |
| 15:34:09 | dansmith | bauzas: they wouldn't until they add another cell | |
| 15:34:10 | mriedem | hamzy: let me check something, we might have a CLI to run | |
| 15:34:19 | dansmith | bauzas: but I know, this is better, I'm not arguing | |
| 15:34:30 | bauzas | dansmith: sure, but they could also opt-out verifying cells, which I also dislike :) | |
| 15:34:40 | bauzas | anyway | |
| 15:34:42 | mriedem | cdent: replied to the ML thread on the placement client topic for completeness | |
| 15:34:51 | bauzas | mriedem: thanks for that, appreciatedf | |
| 15:34:52 | mriedem | and so i don't forget what we agreed on in 4 months time | |
| 15:34:52 | cdent | mriedem: yeah, saw that, thanks | |
| 15:34:53 | dansmith | bauzas: I'm not arguing for a filter | |
| 15:35:05 | bauzas | yeah no worries :) | |
| 15:35:20 | mriedem | hamzy: https://docs.openstack.org/developer/nova/man/nova-manage.html#nova-project | |
| 15:35:29 | mriedem | hamzy: i'm wondering if "nova-manage project quota_usage_refresh <project_id> [--user <user_id>] [--key <key>]" will help | |
| 15:35:47 | mriedem | hamzy: can you try that for the project in question | |
| 15:36:39 | hamzy | yeah let me figure out the project_id | |
| 15:38:25 | hamzy | mriedem, is there an openstack CLI equivalent? | |
| 15:38:32 | mriedem | hamzy: nope | |
| 15:38:35 | mriedem | it's direct to the nova db | |
| 15:38:53 | mriedem | and something in osc cli would require a rest api for this in the compute endpoint, which we don't have | |
| 15:41:06 | hamzy | mriedem, trying to figure out how to install it in my AIO environment | |
| 15:41:35 | mriedem | hamzy: nova-manage is available on the controller | |
| 15:41:42 | mriedem | it's a CLI | |
| 15:41:46 | mriedem | so "which nova-manage" | |