| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-10 | |||
| 14:14:43 | bauzas | gibi: I wouldn't play with affinity if I was a blind user honestly | |
| 14:15:12 | bauzas | gibi: I'd rather find a public cloud provider that would guarantee me some space with no noisy neighbors | |
| 14:15:52 | bauzas | gibi: affinity and anti-affinity policies are for super users that have kind of knowledge of what the cloud has in its guts IMO | |
| 14:16:03 | gibi | in a public cloud I would do that you suggest. In a private telco cloud I might use affinity and anti-affinity | |
| 14:16:21 | bauzas | that's my point | |
| 14:16:33 | bauzas | if I'm private cloud, I have a team to bog with | |
| 14:16:38 | bauzas | to bug* | |
| 14:16:55 | bauzas | like, I want to spin X instances and I want the maximum IO | |
| 14:17:00 | bauzas | that's a good thing | |
| 14:17:46 | gibi | yes | |
| 14:17:50 | gibi | I think we agree | |
| 14:17:54 | bauzas | but then, you'll end-up with such locked-in environment that you'll need the help of your SA team to move your instances or you kill'em all | |
| 14:18:35 | mriedem | well, when gibi implements migration of entire server groups, then this won't be a problem anymore | |
| 14:19:04 | gibi | migration of an entire group is something I like as an idea | |
| 14:19:22 | gibi | but it might needs a scheduler that considers more than one instances at a time | |
| 14:19:31 | gibi | or I have to order the instances properly | |
| 14:20:39 | gibi | so I feel a bit frightened to jump into that implementation right now | |
| 14:23:24 | gibi | also if we talk about server groups then one big limitation of the group approach over the same_host / different_host approach is that a instance can only be part of a single group today | |
| 14:23:42 | gibi | while the hints are allowing a lot more complex setup than tat | |
| 14:23:43 | gibi | that | |
| 14:24:41 | gibi | of course it is just a technical limitation today | |
| 14:25:06 | bauzas | mriedem: migrating a server group as a whole is kinda of a big deal with the current implementation | |
| 14:25:27 | bauzas | even not talking of claims | |
| 14:25:48 | bauzas | but what if for example, a user is booting yet another instance for that group while we migrate ? | |
| 14:26:10 | bauzas | or, how can we be sure some target has enough resources by the time we migrate ? | |
| 14:26:14 | mriedem | bauzas: we don't allow adding/removing members for a group right? | |
| 14:26:34 | bauzas | mriedem: removing, no | |
| 14:26:46 | bauzas | mriedem: adding, it's like the single usecase we implemented | |
| 14:26:56 | gibi | adding a new instance not adding an existing one | |
| 14:27:08 | bauzas | yup, that | |
| 14:27:20 | gibi | but I agree with bauzas here | |
| 14:27:38 | gibi | this is complex | |
| 14:27:54 | mriedem | you guys realize i'm half joking about saying once gibi implements migrate server groups right? | |
| 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 | mriedem | djohnsto: got something for you https://bugs.launchpad.net/nova/+bug/1680773 | |
| 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: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 | 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 | |