| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-13 | |||
| 14:00:10 | mriedem | artom: network metadata could change couldn't it depending on attaching/detaching ports? | |
| 14:00:25 | mriedem | not to mention dynamic vendor data | |
| 14:00:27 | bauzas | mriedem: if your ML thread is related to my az spec, nevermind it, we could just wait for Queens | |
| 14:00:39 | mriedem | bauzas: it was the impetus yes | |
| 14:00:49 | mriedem | i never knew about default_scheduler_zone | |
| 14:00:54 | artom | mriedem, that's probably correct... | |
| 14:01:05 | bauzas | mriedem: default_schedul/e/_zone but yeah | |
| 14:01:15 | mriedem | artom: so if you accept as a limitation that you're not getting the latest changes immediately when using metadata api, then this is probably ok | |
| 14:01:16 | bauzas | mriedem: hope my reply made things clearer for you | |
| 14:01:32 | mriedem | bauzas: it made me feel like there was a purpose | |
| 14:01:43 | mriedem | bauzas: however, the help text on those options is still murky | |
| 14:01:43 | artom | mriedem, I think that's acceptable in the short term, at least | |
| 14:01:46 | mriedem | and should probably be updated | |
| 14:01:53 | bauzas | mriedem: yup, hence johnthetubaguy and frickler point | |
| 14:01:55 | mriedem | bauzas: plus, | |
| 14:01:58 | snikitin_ | sfinucan: :D | |
| 14:01:58 | artom | mriedem, and if someone complains we can always do a "real" cache later | |
| 14:02:01 | mriedem | this big fat scary warning https://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs | |
| 14:02:04 | mriedem | should probably be in the api-ref | |
| 14:02:07 | mriedem | where api users would see it | |
| 14:02:10 | mriedem | rather than way down in devref | |
| 14:02:11 | artom | Or they can run memcache and we can add a bit where we invalidate it | |
| 14:02:29 | bauzas | mriedem: well, when I wrote by that time, I wasn't seasoned with api-ref :) | |
| 14:02:39 | mriedem | artom: memcache doesn't help the timing problem right? just the consistency issue, | |
| 14:02:40 | bauzas | it should even be in the operators guide | |
| 14:02:51 | mriedem | i.e. depending on which metadata api worker i hit with my request, i could get different results | |
| 14:03:02 | bauzas | anyway, spec deadline day, I'm turned into review day for me | |
| 14:03:07 | mriedem | or would memcache be updated globally for all? i suppose it would | |
| 14:03:09 | mriedem | nevermind then | |
| 14:03:18 | artom | mriedem, I'm assuming memcache would be a global singleton | |
| 14:03:32 | artom | So it's much easier to invalidate an item from a different place in the code | |
| 14:03:36 | mriedem | bauzas: "Consequently, it is highly recommended for users to never ever ask for booting an instance by specifying an explicit AZ named nova and for operators to never set the AZ metadata for an aggregate to nova." | |
| 14:03:40 | mriedem | ^ is all about the end user | |
| 14:03:47 | mriedem | artom: yeah true | |
| 14:04:10 | mriedem | artom: so yeah if you were a deployment that heavily depended on metadata api, you're probably using memcahe | |
| 14:04:22 | bauzas | mriedem: setting AZ metadata is an operator thing, right? not sure I get your point | |
| 14:04:27 | mriedem | *memcache - that's why the dogpile per-process dict cache is the cheap and easy default | |
| 14:04:38 | mriedem | bauzas: read again "Consequently, it is highly recommended for users to never ever ask for booting an instance by specifying an explicit AZ named nova and for operators to never set the AZ metadata for an aggregate to nova." | |
| 14:04:42 | bauzas | mriedem: most of the bugs I see are related to people saying "I did nova boot --az nova" and now I'm stuck | |
| 14:04:52 | mriedem | bauzas: yes, that's exactly what that warning says | |
| 14:05:02 | mriedem | "don't do nova boot --availability-zone nova" | |
| 14:05:02 | bauzas | mriedem: or people saying "I did created aggregate with AZ=nova and now I'm broken" | |
| 14:05:18 | bauzas | mriedem: I know, *I* wrote that big fat warning :)à | |
| 14:05:30 | mriedem | the user doesn't read the operators guide | |
| 14:05:52 | mriedem | https://github.com/openstack/nova/blob/master/api-ref/source/parameters.yaml#L3499 | |
| 14:05:54 | bauzas | ah okay, get your point | |
| 14:06:20 | bauzas | gotcha | |
| 14:06:24 | bauzas | I can forge a patch | |
| 14:06:27 | johnthetubaguy | lbragstad: mriedem: sounds like we need to talk about "is_admin_project:True", I am assuming that basically means god_mode=True | |
| 14:07:35 | mriedem | johnthetubaguy: my understanding in talking with lbragstad was is_admin_project was assigning someone as admin to a project, not the deployment | |
| 14:07:41 | mriedem | but it's really confusing so i probably screwed it up | |
| 14:08:00 | mriedem | or is is_admin_project a flag on a project that says, this is the god project, if yo'ure a member, welcome to heaven | |
| 14:08:02 | lbragstad | mriedem that - but the other way around | |
| 14:08:33 | lbragstad | the admin_project is this super-duper special project within keystone and if you have admin on it, you have admin on the deployment | |
| 14:08:50 | lbragstad | (it's weird and a little strange) | |
| 14:09:09 | mriedem | so what is the case where i'm just admin on a non-admin project? | |
| 14:09:18 | mriedem | is that just, role:admin on project foo? | |
| 14:09:24 | mriedem | not role:admin on project admin? | |
| 14:09:26 | lbragstad | mriedem yeah | |
| 14:09:49 | lbragstad | mriedem the case would be that you'd be able to manage the project, but not the deployment | |
| 14:09:50 | mriedem | ok | |
| 14:09:56 | lbragstad | (think creating subprojects) | |
| 14:10:21 | mriedem | johnthetubaguy: i don't know if you need that explained in your spec or not, it would have helped me, and in simple terms | |
| 14:10:34 | openstackgerrit | Sergey Nikitin proposed openstack/nova-specs master: PCI NUMA Policies https://review.openstack.org/361140 | |
| 14:10:37 | mriedem | * god-mode: user as admin role on the special admin project | |
| 14:10:38 | lbragstad | or if you wanted to manage role assignments for things within the project you have admin on | |
| 14:11:12 | johnthetubaguy | mriedem: I tried to describe that in there, I probably failed. Its why I spoke about a "special" admin project. | |
| 14:11:14 | mriedem | * fief lord: user has admin role on non-admin tenant project | |
| 14:11:14 | lbragstad | i mean - it's a step in the right direction, but i kinda think of it as a bandaid | |
| 14:11:35 | johnthetubaguy | mriedem: +1 | |
| 14:11:53 | mriedem | or demigod if you like | |
| 14:12:07 | mriedem | fief lord seems more appropriate | |
| 14:12:14 | lbragstad | yeah | |
| 14:12:53 | mriedem | johnthetubaguy: my main question was can we split fixing the db issue (the trove service user 404 case) from the scope check overhaul? | |
| 14:13:06 | mriedem | because the former i think i understand the mechanics of, the latter i don't so much | |
| 14:13:18 | johnthetubaguy | mriedem: I don't believe we can | |
| 14:13:26 | johnthetubaguy | mriedem: I think one check is there to replace the other | |
| 14:13:29 | mriedem | i figured that would be the answer | |
| 14:13:49 | johnthetubaguy | mriedem: is it worth a quick hangout? | |
| 14:13:59 | mriedem | in that case, you have to answer my gauntlet of questions in the scope check section | |
| 14:14:16 | johnthetubaguy | yeah, heading down them now | |
| 14:14:16 | mriedem | we could, | |
| 14:14:26 | mriedem | would be good if it were more than just me though | |
| 14:15:49 | johnthetubaguy | mriedem: very true, I wonder if sdague and lbragstad would be up for it? | |
| 14:16:01 | sdague | ?? | |
| 14:16:16 | lbragstad | ? | |
| 14:17:00 | johnthetubaguy | wondering about a quick hangout | |
| 14:17:06 | johnthetubaguy | around policy stuff, with mriedem | |
| 14:17:15 | sdague | sure, give me 2 minutes, then I could do it | |
| 14:17:25 | lbragstad | I have some time now - meeting in 45 | |
| 14:17:47 | johnthetubaguy | lbragstad: same here | |
| 14:17:53 | johnthetubaguy | well, same meeting | |
| 14:17:54 | openstackgerrit | Monty Taylor proposed openstack/python-novaclient master: Add novaclient client_name and client_version to user-agent https://review.openstack.org/456638 | |
| 14:17:58 | lbragstad | johnthetubaguy :) | |
| 14:18:55 | sdague | ok, well let me know when | |
| 14:19:15 | johnthetubaguy | policy hangout: https://hangouts.google.com/call/5zxc7sggwndgrcihsydb5o37mmy | |
| 14:19:23 | johnthetubaguy | mriedem: lbragstad: sdague: ^ | |
| 14:19:30 | mriedem | johnthetubaguy: i'll also be totally honest and say i worry about starting a new big slog of changes like this, when we have some things we haven't completed yet from previous releases | |
| 14:20:02 | mordred | jamielennox|away: ^^ see 456638 and double-check me that that's right before I do it for the other clients | |
| 14:20:05 | johnthetubaguy | mriedem: I kinda thought we finished the conf now, hence opening this up | |