| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-19 | |||
| 12:56:10 | cdent | indeed | |
| 13:41:51 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Account for host agg allocation ratio in placement https://review.openstack.org/544683 | |
| 13:48:49 | cdent | sean-k-mooney: live migration is for virtualisers not cloud native people! true or false? | |
| 13:51:33 | kashyap | False | |
| 13:51:37 | kashyap | cdent: Because: | |
| 13:52:18 | cdent | kashyap for context https://review.openstack.org/#/c/541290/4/specs/rocky/approved/numa-aware-vswitches.rst@241 (in other words I was mostly making a joke, but still want to know the because) | |
| 13:52:38 | kashyap | People say Cloud is all about 'cattle' (sorry, can't think of a less trite analogy), but people _do_ care about live migratability in Cloud | |
| 13:53:11 | kashyap | cdent: I realized you're joking with a straight face (also with the exclamation) :P | |
| 13:54:34 | cdent | much of that spec has trouble aligning with cattle-ness, but people do care about it | |
| 13:55:26 | edleafe | Scheduler subteam meeting in 5 minutes in #openstack-meeting-alt | |
| 13:55:49 | kashyap | cdent: Saw asomething else on the spec, will comment there too | |
| 13:59:44 | sean-k-mooney | cdent: cloud native people should be able to have there application live migrated too. | |
| 14:00:16 | cdent | sean-k-mooney: for sake of getting your point of view, why? Shouldn't it just be restarted somewhere else? | |
| 14:00:16 | sean-k-mooney | cdent: live migration is really to allow operators to do maintenace when they done really know what the tenant is running | |
| 14:01:03 | edmondsw | restarting somewhere else means possible downtime | |
| 14:01:22 | sean-k-mooney | cdent: live migration in openstack is admin only so its tenant initiated its operator driven | |
| 14:01:53 | sean-k-mooney | edmondsw: yes that said livemigration could still violate your sla with your tenant | |
| 14:02:08 | cdent | surely every service should have at least two instances of itself all the time :) | |
| 14:02:17 | edmondsw | cdent ha! if only | |
| 14:02:31 | sean-k-mooney | cdent: the best example counter example to that is a provider edge router | |
| 14:02:32 | edmondsw | sean-k-mooney that all depends | |
| 14:02:41 | edmondsw | hence your "could", I'm sure :) | |
| 14:03:20 | cdent | shadow provider edge router | |
| 14:03:27 | sean-k-mooney | cdent: you cant have ha by design as it is respocible for ratelimiting your broadband connection so all traffic from one endpoint most be handeled by 1 PE router | |
| 14:04:10 | sean-k-mooney | cdent: you dont want to reboot in this case because it can thke 10+ minutes to rebuild your peering relationships with other PE routers | |
| 14:06:11 | kashyap | cdent: High availability, is it... | |
| 14:06:30 | kashyap | Yeah, sean-k-mooney explained it clearer -- about migratability | |
| 14:06:49 | cdent | I hear and ack what you're saying. | |
| 14:06:59 | cdent | But will remain frustrated :) | |
| 14:07:06 | kashyap | Just take a look at the number of config knobs we have for live migration | |
| 14:07:23 | kashyap | A common scenario for it in OpenStack context is upgrades | |
| 14:07:42 | edmondsw | also think about dev on the cloud... I'm still developing this service and haven't setup HA yet, but I don't want you restarting it while I'm working | |
| 14:07:43 | kashyap | Where you update Compute-B, migrate all instances from Compute-A to B | |
| 14:07:46 | kashyap | And so forth | |
| 14:07:46 | sean-k-mooney | cdent: well live migration cannot always be assumed to be available in a cloud and even if it is it my not be viable due to your perfromce constratints | |
| 14:08:19 | kashyap | Yeah, random restarts that catch tenant users off-guard are completely undesirable | |
| 14:09:13 | kashyap | sean-k-mooney: Yeah, that's also why, as you pointed out, tenant users don't get to migrate instances. It is admins that drive it. | |
| 14:09:28 | cdent | Sounds like there could be a problem with "random restarts" that is orthogonal to everything else | |
| 14:09:37 | sean-k-mooney | i would generally say livemigration is more of an enterprise feature then telco as most nfv application cant tollerate the dataplane impact of a livemigration (latency,bandwith and packet loss) | |
| 14:10:07 | kashyap | True | |
| 14:11:09 | edmondsw | kashyap tenant users don't get to migrate instances because migration assumes knowledge of the infrastructure. If I don't have that knowledge, why would I try to move it :) | |
| 14:11:52 | sean-k-mooney | cdent: to your original question a cloud native application should not require livemigration to be avalible at all as it should be fault tolerant enough to cover a cold migration but most applications are not cloud native. | |
| 14:12:08 | kashyap | edmondsw: Yeah, indeed. | |
| 14:12:36 | cdent | I should probably have put some ™ in my original statement to make it clear that I was talking about over-idealized and over-hyped pictures. | |
| 14:13:11 | edmondsw | is there such a thing as over-idealized? ;) | |
| 14:13:23 | sean-k-mooney | edmondsw: that and allowing tennants to live migrate stuff is a great way to ddos you management network as that is what all the openstack installers configure to use by default. | |
| 14:14:00 | edmondsw | ++ | |
| 14:14:38 | edleafe | edmondsw: that's like being "more unique" | |
| 14:14:54 | edmondsw | but if there's no use case to allow tenants to live migrate (because they lack the necessary infra knowledge) all other concerns become secondary | |
| 14:15:19 | sean-k-mooney | edmondsw: i would say the existence of apple product in the world would be evedence of over-idealized design above fuction. | |
| 14:15:34 | edmondsw | sean-k-mooney touche! | |
| 14:15:44 | jaypipes | mriedem, dansmith, melwitt, bauzas, stephenfin: we've got pretty broad agreement on the approach in https://review.openstack.org/#/c/540111/. would be great to approve that and unblock the patch series implementing it. | |
| 14:16:09 | bauzas | jaypipes: stephenfin is on PTO this week | |
| 14:16:31 | bauzas | but I can review it for sure | |
| 14:16:40 | sean-k-mooney | oh by the way is master open for rocky and i assume not is a good time to repopose the feature based schduling spec form last cycle? | |
| 14:17:00 | edmondsw | sean-k-mooney master is open | |
| 14:17:35 | sean-k-mooney | edmondsw: cool i have some patches to rebase that missed code freeze | |
| 14:17:50 | edmondsw | join the club! | |
| 14:18:25 | jaypipes | sean-k-mooney: feature-based scheduling? | |
| 14:18:37 | jaypipes | sean-k-mooney: oh, the nic feature one? | |
| 14:18:44 | sean-k-mooney | jaypipes: ya rodolfos work | |
| 14:18:50 | jaypipes | gotcha | |
| 14:19:27 | sean-k-mooney | he is full time on yardstick in opnfv now so im pickup all his patches at least to the end of Q1 /early Q2 | |
| 14:21:25 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Provide a hint when performing a server action can't find the method https://review.openstack.org/545382 | |
| 14:23:04 | mriedem | the bug fix series starting here needs review https://review.openstack.org/#/c/539758/ - +2 on all changes; fixes a problem going back to at least newton, if not since bfv was added forever ago | |
| 14:28:54 | mriedem | jaypipes: i'll go through that spec later this morning if someone else hasn't gotten to it first | |
| 14:29:02 | mriedem | i know dan has been through it before | |
| 14:29:06 | jaypipes | mriedem: I'll go through that patch series for the bug. | |
| 14:30:02 | efried | kumbaya | |
| 14:30:10 | sean-k-mooney | jaypipes: mriedem by the way the intel nfv ci should be operational again. can ye see any logs here http://http//52.27.155.124//portland/2018-02-19/540073/4/check/tempest-dsvm-intel-nfv-xenial/b045a8e | |
| 14:31:05 | sean-k-mooney | oh i see whats wrong they are not generating the url correctly.. ill let them know | |
| 14:50:41 | Placeed | Hi all, I have a problem with ressource_tracker.py on my compute instance. This script return a disk usage of 90% to nova so I can't run new instances. The problem is on the calculation ... Actually I use Cinder with NFS backend on /var/lib/nova/mnt with few tera avaiable. I don't run ephemeral vm's. It sounds like the script sum all disk usage of vm running and check only the local disk space of the compute server. | |
| 14:50:49 | Placeed | Someone can help me ? | |
| 14:53:40 | Placeed | As you can see there : https://paste.ofcode.org/SGqTUpeuWMErjfUwmHwQN2 The node think he have only 270Go available but in reality he have few tera through NFS | |
| 14:55:20 | efried | Placeed: Is this a boot-from-volume setup? | |
| 14:56:49 | Placeed | efried : Yes, In user point of view, I create a new instance based on image and it will create a cinder volume for the root disk of the instance | |
| 14:57:14 | Placeed | But it failed to find a host acceptable because of this "bug" | |
| 14:58:17 | kashyap | bauzas: I'm not sure a spec is required in this case https://review.openstack.org/#/c/545034/ ("Allow to configure amount of PCIe ports") | |
| 14:58:47 | bauzas | kashyap: sure, I discussed with hrw about the process | |
| 14:59:03 | bauzas | he created a BP, and asked for a specless approval for the next nova meeting | |
| 14:59:18 | kashyap | Ah-ha | |
| 14:59:27 | kashyap | hrw: The above change should also mention something about its usefulness in context of Nova coping with Q35 machine types | |
| 14:59:33 | kashyap | (Recall the discussion from #virt, OFTC) | |
| 14:59:59 | kashyap | At some point distributions will default to the Q35, and Nova should be ready to gracefully handle it. | |
| 15:00:20 | kashyap | So your change helps with that; so it's worth mentioning. | |
| 15:00:23 | kashyap | I'll add a note in the review | |
| 15:02:08 | efried | Placeed: I know mriedem has been looking at bfv stuff lately, though I don't know the details. I think he has recently put up a series of fixes - but again, no idea if the bug is related to this. Looking... | |
| 15:02:38 | efried | Placeed: Here's the code series: https://review.openstack.org/#/c/539758/ | |
| 15:02:48 | openstackgerrit | Hamdy Khader proposed openstack/nova master: Adding NVMEoF for libvirt driver https://review.openstack.org/482640 | |
| 15:03:17 | efried | Placeed: Hmm, the bug doesn't sound like your issue: https://bugs.launchpad.net/nova/+bug/1404867 | |
| 15:03:17 | openstack | Launchpad bug 1404867 in OpenStack Compute (nova) "Volume remains in-use status, if instance booted from volume is deleted in error state" [Medium,In progress] - Assigned to melanie witt (melwitt) | |
| 15:05:04 | mriedem | efried: it's not, | |
| 15:05:07 | mriedem | it's likely https://bugs.launchpad.net/nova/+bug/1469179 | |
| 15:05:07 | openstack | Launchpad bug 1469179 in OpenStack Compute (nova) "instance.root_gb should be 0 for volume-backed instances" [Medium,In progress] - Assigned to melanie witt (melwitt) | |
| 15:05:11 | mriedem | https://review.openstack.org/#/q/topic:fix-bfv-boot-resources+(status:open+OR+status:merged) | |
| 15:05:55 | mriedem | which has been continually deferred until we have sharing disk_gb provider support, which continually gets deferred | |
| 15:06:31 | efried | mriedem: "sharing disk_gb provider support" as in placement? | |
| 15:06:37 | mriedem | yeah | |
| 15:06:41 | efried | okay. | |
| 15:06:46 | mriedem | having the computes / RT be aware of shared storage pools | |