Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-10
14:58:59 openstackgerrit Peter Hamilton proposed openstack/nova-specs master: Add support for certificate validation https://review.openstack.org/357151
14:59:08 jimbaker johnthetubaguy, ack, more for my quiver
15:00:50 peter-hamilton jaypipes: thanks for the +2
15:01:20 peter-hamilton jaypipes: i just pushed an update to the spec to address the integration of cursive into nova
15:02:44 peter-hamilton jaypipes: minor changes for the most part
15:11:46 jaypipes peter-hamilton: +2d again :)
15:11:57 peter-hamilton jaypipes: awesome! thanks
15:12:24 jaypipes peter-hamilton: I used to think that *I* was the most loquacious spec writer. *you* have clearly taken that title from me ;P
15:12:43 peter-hamilton jaypipes: i do like to be thorough :)
15:12:46 jaypipes :)
15:20:47 mriedem sdague: you should probably get involved in the osc/horizon thread on novaclient 8.0 removing nova-net support, re: dtroyer's reply
15:20:49 openstackgerrit Andrey Volkov proposed openstack/nova master: Add ability to view quota details for project owner https://review.openstack.org/386008
15:20:58 mriedem sdague: or keep me in check if i'm wrong
15:24:24 sdague mriedem: yeh, I'm with you
15:24:52 mriedem i may also be not understanding what dtroyer is saying,
15:25:01 mriedem and if osc wants to support nova-net forever, then that's on them
15:26:40 sdague yep, that's fine
15:27:29 abhi89 alex_xu: Hi
15:28:31 abhi89 alex_xu: can you please review https://review.openstack.org/#/c/455118/2
15:28:39 sdague cdent: did you start in on placement uwsgi bits yet?
15:29:47 cdent sdague: no, did you see my question from earlier in the day about whether we still want placement on port 80 and a prefix and how that impacts the uwsgi bits (and my comments on mtreinish's patch)?
15:29:57 cdent (question in this channel)
15:30:15 sdague cdent: nope
15:30:55 abhi89 dansmith: Hi.. can you please review https://review.openstack.org/#/c/455118/2
15:31:26 sdague cdent: so, I guess it all comes down to the tls termination
15:31:26 cdent [t 3FDi]
15:31:27 purplerbot <cdent> sdague: in your hopes and dreams for placeument under uwsgi, is that on a custom port or standard ports (the latter requires either nginx or mod_proxy_wsgi, no?)? [2017-04-10 13:49:28.430362] [n 3FDi]
15:31:45 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Read NIC features in libvirt https://review.openstack.org/444415
15:31:46 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257
15:31:47 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777
15:31:47 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Modify PciPassthroughFilter to accept lists https://review.openstack.org/444946
15:31:49 cdent sdague: the related bits were comments on https://review.openstack.org/#/c/451562/
15:33:01 mtreinish cdent: I did see your comment on my patch. I actually didn't consider doing that. I figured we wanted to keep the 1 process per api server (at least for now)
15:33:20 mtreinish but it might be a good idea to start playing with that
15:34:00 melwitt jaypipes: hey, I have the placement project/user spec amendment proposed and your thoughts would be appreciated on whether project_id/user_id should be optional query string params for the set_allocations call https://review.openstack.org/#/c/454352/
15:34:14 cdent one way we might be able to incrementally get there is instead of switching wholesale to nginx, is to start making mox_proxy_uwsgi available
15:35:14 mtreinish cdent: that's what devstack uses in uwsgi mode
15:35:17 djohnsto mriedem: Thanks let me take a look, and I'll see what I can do. Thanks for getting me started
15:35:38 mriedem yw
15:35:50 cdent mtreinish: it is? I thought it was running standalone uwsgi servers?
15:36:26 sdague the disadvantage with with templates is that it's one more thing to understand, and things can be spun up with the wrong names easily, then not work
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 bauzas FWIW, I'm just updating the spec *now*
17:03:36 mriedem ok
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

Earlier   Later