| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-10 | |||
| 15:36:31 | cdent | mtreinish: using either the mod_proxy or nginx way gets us services on prefixes instead of ports, while still providing separate logs | |
| 15:37:15 | cdent | sdague: I'm not sure if I'll fulling understanding what you're saying? | |
| 15:37:46 | mtreinish | cdent: hmm, you might be right. I might be confusing it with what I did | |
| 15:38:00 | mtreinish | I just assumed it was mod_proxy_uwsgi because that's what the keystone docs say you should do | |
| 15:38:37 | cdent | yeah, I think for outside-devstack that's right, but in devstack it's standalone | |
| 15:39:25 | sdague | cdent: we can either use systemd native templating, or we can blast out our own files | |
| 15:40:00 | sdague | systemd native templating means we need everything in certain naming schemes, which actually makes figuring out which are the devstack services possibly less clear | |
| 15:40:13 | sdague | because we're going to have a couple different types of templates | |
| 15:42:59 | cdent | sdague: perhaps. I haven't fully grokked the functionality of the template file names, but I was thinking they'd still all be in the devstack namespace | |
| 15:44:25 | cdent | sdague, mtreinish: in any case I think we can set the template question aside, at least for now, and consider the question of placement + uwsgi only. Do we want to throw mod_proxy_uwsgi into the mix, or take placement off the /placement prefix and have it only on a port? (for now) | |
| 15:44:45 | sdague | cdent: there are very specific naming rules that making things potentially odd | |
| 15:45:16 | sdague | cdent: so... here is my question, which I don't know | |
| 15:45:31 | sdague | in what ways can the current apache tls proxy talk to the uwsgi process? | |
| 15:46:14 | sdague | because I'm going to assume the tls terminator remains a thing we want, and that is not port based | |
| 15:46:30 | sdague | but I don't quite know what constraints that puts on running uwsgi | |
| 15:47:23 | cdent | theoretically none: if we have a proxy it can get to anything else over more http | |
| 15:48:00 | sdague | cdent: right, except that means we need ports, right | |
| 15:48:04 | cdent | uwsgi can expose itself either over http or a socket. The socket is more efficient and if we want to use it we need either ngxin or one of the three apaceh-based solutions | |
| 15:48:35 | sdague | cdent: right, so the socket approach, if we do that, do we have a path forward that lets us dump the ports? | |
| 15:48:44 | cdent | it depends on what the tls proxy is doing, which I haven't paid much attention to. | |
| 15:48:47 | sdague | with apache tls proxy in the front end | |
| 15:48:56 | sdague | cdent: right, so that's my question :) | |
| 15:49:05 | sdague | http://uwsgi-docs.readthedocs.io/en/latest/Apache.html seems to hint yes | |
| 15:49:15 | cdent | if we have a proxy in front of uwsgi, we can dump ports in the public exposed interfaces | |
| 15:49:18 | cdent | it doesn't matter which proxy | |
| 15:49:32 | cdent | could tls, mod_uwsgi_proxy, could even be mod_rewrite | |
| 15:50:03 | jaypipes | melwitt: done | |
| 15:50:04 | sdague | cdent: well, the default devstack has tls proxy on | |
| 15:50:38 | cdent | okay, but, for example, the service catalog entry for placement doesn't care about that | |
| 15:50:44 | melwitt | thanks jaypipes | |
| 15:52:08 | cdent | sdague: I may be somewhat confused here as I've never paid any attention to the tls-proxy, how (and why) is it getting involved in any of this? | |
| 15:55:56 | mriedem | jaypipes: bauzas: johnthetubaguy: dansmith: cdent: edleafe: etherpad for notes https://etherpad.openstack.org/p/nova-pike-claims-in-scheduler pre-filled for your pleasure | |
| 15:56:16 | bauzas | kewl | |
| 15:56:17 | cdent | thanks mriedem | |
| 15:56:46 | sdague | cdent: well, I'm trying to figure out what the rest of the constraints of having an environment up and running look like. Because we turn on TLS termination during gate runs, and configure accordingly. That means we already have apache modproxy running. Maybe it's completely orthoginal. | |
| 15:57:15 | sdague | cdent: my preference is have a way to run all these, as per service uwsgi daemons, that don't have special ports | |
| 15:57:37 | sdague | however we can make that happen, cool | |
| 15:58:57 | cdent | sdague: Okay, when I get a bit more headspace I'll put together some examples of the various ways it can be done, none should be too overly complex to do, so relatively easy to compare and contrast. Should be within the next 24 hours or less. gotta starta meeting now | |
| 16:00:33 | mriedem | cdent: edleafe: dansmith: jaypipes: bauzas: https://hangouts.google.com/hangouts/_/t7rdtjfdprf7dj3ynbipspid6ue | |
| 16:16:14 | openstackgerrit | Octave Orgeron proposed openstack/nova master: Enables MySQL Cluster Support for Nova https://review.openstack.org/446643 | |
| 16:31:31 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Add description to policies in servers.py https://review.openstack.org/451966 | |
| 17:02:50 | mriedem | cdent: dansmith: jaypipes: edleafe: bauzas: to be clear, do we pass an AllocationList object? or something more? | |
| 17:02:56 | mriedem | to compute i mean | |
| 17:03:03 | bauzas | mriedem: I thought the former | |
| 17:03:18 | bauzas | because they're already having a nested ResourceProvider object | |
| 17:03:20 | mriedem | i kept getting confused by jaypipes saying we'd be passing the resource providers down | |
| 17:03:24 | jaypipes | mriedem: I would say an AllocationList object, yes. | |
| 17:03:35 | dansmith | yeah | |
| 17:03:36 | mriedem | ok | |
| 17:03:36 | bauzas | FWIW, I'm just updating the spec *now* | |
| 17:03:37 | jaypipes | mriedem: resource provider is part of the Allocation object | |
| 17:03:41 | mriedem | yeah i see that now | |
| 17:04:51 | openstackgerrit | Dinesh Bhor proposed openstack/nova master: Refactor: Move post method to APIValidationTestCase base class https://review.openstack.org/364687 | |
| 17:06:45 | mriedem | ok updated the etherpad with what i think we agreed on | |
| 17:06:59 | mriedem | i'm still fuzzy on the steps where we create the instance in the cell, and how that changes | |
| 17:08:11 | bauzas | dropping now, but back later | |
| 17:13:38 | cdent | mriedem: if I'm continuing to feel antsy about allocations over RPC, do you want my thoughts (when they go from general anxiety to concrete concerns) recorded on the etherpad or the spec? | |
| 17:17:26 | mriedem | cdent: i suppose the spec? | |
| 17:17:37 | cdent | mriedem: roger, I'll sleep on it | |
| 17:18:03 | cdent | if I can sleep through my code complexity nightmares | |
| 17:24:44 | mnestratov | hi all | |
| 17:25:53 | mnestratov | looks like my bp left without any attention https://blueprints.launchpad.net/nova/+spec/config-drive-support-for-virtuozzo-containers | |
| 17:26:19 | mnestratov | and I wonder if it needs a spec? | |
| 17:28:32 | mnestratov | at PTG we agreed that tonyb will ask mikal what was his concern about previous implementation | |
| 17:30:15 | mnestratov | but I doubt this was done as there was no movement neither in bp nor in the code review | |
| 17:30:51 | mnestratov | so, my question is there any chance for this bp to be approved? | |
| 17:37:14 | abhi89 | johnthetubaguy: Hi John.. can you please review https://review.openstack.org/#/c/455118/2 | |
| 17:46:40 | mriedem | mnestratov: thanks for the reminder, i'll email mikal and tonyb about it | |
| 17:47:45 | mnestratov | mriedem: thanks | |
| 17:49:26 | mnestratov | mriedem: I should have done it myself and a bit earlier I think | |
| 18:00:42 | mriedem1 | mnestratov: done. remind me in a couple of days if we don't hear back and I'll just approve the blueprint. | |
| 18:01:34 | mnestratov | mriedem: thanks a lot! | |
| 18:03:16 | mriedem | sdague: so my daughter complained of feeling like she was going to throw up this morning so stayed home, she's not yet at the age to lie about being sick to ditch school, | |
| 18:03:33 | mriedem | and lo and behold i found the original reading rainbow on the pbs kids channel on amazon | |
| 18:03:42 | mriedem | it's like i've traveled back in time | |
| 18:03:45 | sdague | heh | |
| 18:04:10 | mriedem | "this is what people looked like when i was your age" | |
| 18:04:10 | sdague | I funded the reading rainbow kickstarter a few years ago, and got a t-shirt out of it | |
| 18:04:21 | clarkb | hbo has old sesame street | |
| 18:04:22 | sdague | it's really the best t-shirt to travel in | |
| 18:04:33 | mriedem | clarkb: i thought the hbo stuff was new? | |
| 18:04:40 | sdague | TSA folks are super cheery when they see you in it | |
| 18:04:50 | clarkb | mriedem: its both, they also go rights the stream the old catalog | |
| 18:04:56 | mriedem | oh nice | |
| 18:05:00 | dansmith | I think you guys are in the wrong channel | |
| 18:05:00 | mriedem | the old stuff is way better | |
| 18:05:10 | mriedem | can it nerd | |
| 18:05:21 | dansmith | big bird would not approve :( | |
| 18:05:40 | mriedem | for support of 80s pbs kids shows, go to #openstack-pbs-memories | |
| 19:11:03 | mriedem | sdague: isn't there some way to tell api samples tests when they verify a response, that i don't care what a value is, i just want to validate the type, like a uuid field, in a response | |
| 19:13:02 | mriedem | nvm, "%(uuid)s" does the trick | |
| 19:38:34 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read NIC features in libvirt https://review.openstack.org/444415 | |
| 19:56:16 | openstackgerrit | Eric Fried proposed openstack/nova master: Glance download: only fsync files https://review.openstack.org/451094 | |
| 19:59:49 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/delete #1: no-ops https://review.openstack.org/438119 | |
| 19:59:59 | efried | mriedem ^^ manual rebase (cursive) | |
| 20:02:04 | kfox1111 | which pip package has nova-manage cli now? | |
| 20:04:35 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Modify PciPassthroughFilter to accept lists https://review.openstack.org/444946 | |
| 20:05:26 | mriedem | kfox1111: same as always | |
| 20:05:28 | mriedem | nova | |
| 20:06:44 | kfox1111 | pip install python-novaclient? | |