| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-06 | |||
| 17:54:00 | mriedem | i.e. you might get your goodies on boot but they are gone after resizing | |
| 17:55:28 | dansmith | config drive is a big benefit for edge peeps | |
| 17:55:55 | dansmith | because hitting the metadata api is a trip over the wan, either via http if it's central, or by it to the db which likely is | |
| 17:55:58 | dansmith | configdrive keeps working even if you're isolated | |
| 18:00:10 | openstackgerrit | Dan Smith proposed openstack/nova-specs master: Add nova-audit spec https://review.opendev.org/693226 | |
| 18:02:58 | sean-k-mooney | you can use metadta service if you have isolated neutron networks too | |
| 18:03:14 | sean-k-mooney | but you need to configure neturon to proxy the metadta api via the dhcp agent | |
| 18:03:19 | sean-k-mooney | instead fo the router | |
| 18:03:47 | dansmith | sean-k-mooney: to be clear, I meant partitioned as in...the wan is down | |
| 18:03:48 | sean-k-mooney | but ya config drive woks regardless of the network topology | |
| 18:03:58 | sean-k-mooney | ah right | |
| 18:04:35 | sean-k-mooney | the only draw back with the config drive is that it will not be updated if you attach interface ectra at least while the vm is running | |
| 18:04:50 | sean-k-mooney | in general i works well for what it does | |
| 18:05:21 | artom | jgwentworth, I think gmann and the other tempest folks need to weigh in on https://review.opendev.org/#/c/693096/ - I'm not even sure it's necessary at all | |
| 18:06:50 | jgwentworth | yes, I assumed tempest ppl will review it :) | |
| 18:07:13 | artom | There's... latency, sometimes :) | |
| 18:09:47 | jgwentworth | yeah, I just meant it's a tempest patch so it's gonna be up to them | |
| 18:13:20 | mriedem | dansmith: per usual you updated while i was leaving comments :/ | |
| 18:16:42 | dansmith | mriedem_lunch: sorry man, just fixing pep8 | |
| 18:18:45 | jgwentworth | dansmith: spec looks sane to me and ok for ML input | |
| 18:22:36 | dansmith | jgwentworth: thanks, I'll make some of the changes mriedem_lunch suggested and then blast | |
| 18:38:44 | openstackgerrit | Dan Smith proposed openstack/nova-specs master: Add nova-audit spec https://review.opendev.org/693226 | |
| 18:46:24 | openstackgerrit | Dan Smith proposed openstack/nova-specs master: Add nova-audit spec https://review.opendev.org/693226 | |
| 18:56:27 | dansmith | omg the gate, the gate | |
| 18:56:35 | dansmith | 5 minute turnaround time.... <3 | |
| 19:01:34 | melwitt | we're living in gate luxury | |
| 19:02:52 | sean-k-mooney | if only there was ptg every month | |
| 19:03:04 | sean-k-mooney | and we did not have to travel | |
| 19:04:16 | artom | PTG in my basement, hell yeah | |
| 19:31:28 | openstackgerrit | Archit Modi proposed openstack/nova stable/pike: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693236 | |
| 19:32:01 | artom | Do we have a middleware-knowing person? | |
| 19:32:18 | artom | I'm trying to figure out a 413 error for a downstream, and it's bugging me | |
| 19:32:48 | artom | Even with debug enabled, the only log line I see is "POST /v2.1/servers" status: 413" | |
| 19:32:54 | artom | Nothing else that's interesting for that request ID | |
| 19:33:12 | artom | So... could it be oslo_middleware's sizelimit doing that? How would we make sure? | |
| 19:37:51 | openstackgerrit | Archit Modi proposed openstack/nova stable/queens: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693239 | |
| 19:38:09 | sean-k-mooney | artom: byond a print statemtent in the function im not really sure | |
| 19:38:39 | artom | sean-k-mooney, or I guess removing it from the paste config | |
| 19:38:58 | artom | But paste scares me | |
| 19:39:07 | sean-k-mooney | ya although that might fail somewhere else then | |
| 19:39:43 | mriedem | artom: efried_rollin has dorked around in a lot of that code lately | |
| 19:39:46 | openstackgerrit | Archit Modi proposed openstack/nova stable/rocky: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693240 | |
| 19:39:46 | sean-k-mooney | im sure there is a way to congirue custom midelware to log extra stuff in the 413 case but ya i didnt really want to have to learn that | |
| 19:40:07 | sean-k-mooney | cdent know that code pretty well too i think | |
| 19:40:08 | mriedem | amodi: i see you're doing backports backwards, | |
| 19:40:21 | mriedem | amodi: note that you should be doing train -> stein -> rocky -> queens -> pike | |
| 19:40:22 | mriedem | in that order | |
| 19:40:23 | amodi | mriedem: yes | |
| 19:40:34 | amodi | mriedem: oh i dint know it mattered | |
| 19:40:47 | artom | mriedem, can I blow your mind? | |
| 19:40:50 | mriedem | https://docs.openstack.org/project-team-guide/stable-branches.html#processes | |
| 19:40:52 | artom | amodi is Red Hat QE! | |
| 19:40:52 | amodi | mriedem: im still cherry picking from the master | |
| 19:41:04 | sean-k-mooney | amodi: the patch has to merge on all the newer branches first | |
| 19:41:05 | mriedem | artom: that does not blow my mind | |
| 19:41:10 | sean-k-mooney | amodi: same as downstream | |
| 19:41:10 | artom | He's upstream! | |
| 19:41:40 | mriedem | amodi: the point of that is if we merged the rocky backport, someone got it, and then upgraded to train where the backport isn't merged yet, they'd lose the fix | |
| 19:41:42 | mriedem | and have to re-fix it | |
| 19:41:48 | mriedem | that's why you go latest to oldest | |
| 19:41:54 | amodi | mriedem: i see, yes makes sense | |
| 19:43:04 | melwitt | recently I struggled with locating where an exception was being raised to nova api, all the log said was "INFO [nova.api.openstack.wsgi] HTTP exception thrown: Maximum number of ports exceeded" I'm not sure whether more would be shown at DEBUG | |
| 19:44:01 | melwitt | and for this 413 thing, you said there's zero logging of it.. I can't recall if I've seen that before or how/why it happens | |
| 19:44:55 | artom | melwitt, well, there's just the 1 line | |
| 19:45:12 | artom | And then the request ID appears in a bunch of OPTIONS / requests | |
| 19:45:15 | melwitt | yeah, sorry, I meant other than the POST line with the status code | |
| 19:45:22 | artom | Which I assume are load balancers poking the API | |
| 19:45:49 | sean-k-mooney | artom: no the load blancer would not reuse a request id like that | |
| 19:46:19 | artom | sean-k-mooney, this is queens, did we still have that request ID sharing bug back then? | |
| 19:46:32 | artom | Though that was only for periodic tasks | |
| 19:46:50 | openstackgerrit | Archit Modi proposed openstack/nova stable/train: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693241 | |
| 19:47:14 | openstackgerrit | Archit Modi proposed openstack/nova stable/stein: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693242 | |
| 19:47:30 | sean-k-mooney | ha proxy is dumb and know nothing about the request id. iw we are seeing multipel request with the same request id its form heat/novaclient reusing the request id i woudl suspect | |
| 19:48:10 | sean-k-mooney | its a vm create so it might use the same request id to poll for its completion | |
| 19:48:11 | artom | sean-k-mooney, wait, so heat would be creating the whole stack with a single request ID? | |
| 19:48:12 | artom | Fun | |
| 19:48:14 | mriedem | nobody calls haproxy dumb and gets away with it | |
| 19:48:30 | artom | sean-k-mooney, but... OPTIONS / ? | |
| 19:48:38 | artom | That's obviously health check stuff | |
| 19:48:56 | artom | I've like we've gotten sidelined :) | |
| 19:49:03 | sean-k-mooney | well a http options request is use to discover info about the endpoint | |
| 19:49:15 | mriedem | heh, oh boy, someone just reply-all'ed to 400 people internally | |
| 19:49:59 | sean-k-mooney | yes we may have internal maining lists that people dont understand how to unsubsribe form | |
| 19:50:29 | melwitt | unsubsquirrel | |
| 19:50:36 | sean-k-mooney | and they may or may not like to reply all to them to ask for help to the point ^ is now a thing | |
| 19:51:04 | sean-k-mooney | as is http://www.unsubsquirrel.com/ | |
| 19:52:19 | artom | Oh common | |
| 19:52:31 | mriedem | great now i'm playing that game | |
| 19:52:40 | sean-k-mooney | https://scratch.mit.edu/projects/327361863/ is the beeter version | |
| 19:52:48 | artom | I can't believe the obvious "Unsubscribe you? That's nuts!" pun | |
| 19:52:52 | artom | *they missed | |
| 19:53:28 | melwitt | open a PR | |
| 19:54:52 | artom | Ah no, if you refresh enough times you get it | |
| 19:55:20 | melwitt | oh yeah, I see https://github.com/joellord/subsquirrel/blob/master/index.html#L33 | |
| 20:13:01 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Regression test for bug 1849657 https://review.opendev.org/693248 | |
| 20:13:01 | openstack | bug 1849657 in OpenStack Compute (nova) " allocation key is missing from the binding:profile of the neutron qos port when the server is created by a non-admin user" [Medium,In progress] https://launchpad.net/bugs/1849657 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 20:24:30 | efried | artom: paste? | |
| 20:26:25 | efried | sean-k-mooney: So the one where I added --with-apparmor_profiles and --prefix=/usr failed, but the one where I added that symlink and rebooted succeeded. | |
| 20:27:04 | sean-k-mooney | efried: ok so i need to work on proper apparmor support in a follow up | |
| 20:27:51 | sean-k-mooney | i may have spent the last 3 hour fixing my openstack that i broke but im testing it on a clean vm right now | |