Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-10
14:28:08 mriedem i realize it's a giant mess today
14:28:43 mriedem i just like to set the insurmountable task
14:30:04 mriedem gibi: i'm creating a growth opportunity for you :) like a good first line manager.
14:30:35 mriedem gibi: oh btw,
14:30:49 mriedem did you see my comments on the instance tags in the versioned notifications patch?
14:30:56 gibi mriedem: honestly I grow in this community every day and I'm very happy about that
14:31:02 mriedem speaking of insurmountable tasks
14:31:42 gibi mriedem: I even responded to them ;)
14:31:54 openstackgerrit Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168
14:34:20 openstackgerrit Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168
14:35:08 openstack Launchpad bug 1680773 in OpenStack Compute (nova) "Migration of a one VM deployed as part of group fails with NoValidHost" [Undecided,Incomplete] - Assigned to Arun Mani (arun-mani)
14:35:08 mriedem djohnsto: got something for you https://bugs.launchpad.net/nova/+bug/1680773
14:35:10 mriedem djohnsto: see the last comment
14:35:29 mriedem djohnsto: we could use a note in the docs about server groups with an affinity policy that they can't be migrated
14:35:42 mriedem djohnsto: that doesn't close the bug, so i'd push that as a Related-Bug change
14:43:34 openstackgerrit Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168
14:48:07 openstackgerrit Sean Dague proposed openstack/nova master: remove log translation tags from nova.cells https://review.openstack.org/454854
14:49:37 openstackgerrit Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168
14:54:04 mriedem johnthetubaguy: jimbaker: so what i'd do is:
14:54:08 mriedem 1. deploy ocata
14:54:32 mriedem 2. goof up the [placement] creds in nova.conf for the scheduler service so it can't talk to the placement endpoint
14:54:36 mriedem 3. boot a server and time it
14:54:41 mriedem (osprofiler?)
14:54:53 mriedem 4. fix the placement creds in nova.conf for the scheduler service
14:55:08 mriedem 5. boot a server and time it (probably delete that server from step 3 too before this)
14:55:19 mriedem compare the times and digest in the ML
14:55:51 johnthetubaguy I love stats so I would say do it 30 times so its normally distributed, but otherwise, +1
14:55:58 mriedem yeah good point
14:56:10 mriedem i think that's what rally does right? but it's 3 rather than 30?
14:56:14 jimbaker mriedem, so that gets us to some raw performance. and yeah, i have some basic stats knowledge. i was planning to look at the chatter as well with placement
14:56:37 mriedem i've personally never used rally or osprofiler so i can't claim to know how easy they are to do this
14:57:05 johnthetubaguy yeah, I have only seen the output from it
14:57:07 jimbaker i had previously looked at the possibility of using osprofiler for craton (which i'm transitioning away from)
14:57:26 jimbaker and in general a fan of tracing
14:58:14 openstackgerrit Maciej Szankin proposed openstack/nova-specs master: Add remove-nova-consoleauth spec https://review.openstack.org/450063
14:58:19 jimbaker but i think the thing that made sense here for someone new was getting a handle on the flow - and seeing what was necessary after all
14:58:43 johnthetubaguy jimbaker: its amazing what you can get from just the instance.save() notification system, you see how long it takes to set the host, for example, but thats probably a distraction
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 cdent [t 3FDi]
15:31:26 sdague cdent: so, I guess it all comes down to the tls termination
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: Modify PciPassthroughFilter to accept lists https://review.openstack.org/444946
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: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 :)

Earlier   Later