Earlier  
Posted Nick Remark
#openstack-nova - 2018-02-19
10:51:35 bauzas hrw: sorry got distracted
10:51:48 hrw bauzas: no problem. work is work
10:52:09 bauzas hrw: so, in https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting (seems a bit stale, you should comment that it's for the 22th), in Open Discussion
10:52:16 hrw thx
10:52:20 bauzas saying "specless BP approval"
10:54:17 hrw bauzas: added
10:56:50 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe ports https://review.openstack.org/545034
10:58:10 hrw commit message partially rewritten + BP link. some suggested code changes
11:09:00 openstackgerrit Chris Dent proposed openstack/nova master: Fix PatternPropertiesTestCase for py 3.6 https://review.openstack.org/545798
11:47:34 openstackgerrit Tetsuro Nakamura proposed openstack/nova-specs master: Support shared/dedicated vCPUs in one instance https://review.openstack.org/545734
12:23:15 openstackgerrit Tetsuro Nakamura proposed openstack/nova-specs master: Support shared and dedicated VMs in one host https://review.openstack.org/543805
12:32:57 openstackgerrit Tetiana Lashchova proposed openstack/python-novaclient master: Fix the docstring for the update method https://review.openstack.org/545819
12:42:27 openstackgerrit Surya Seetharaman proposed openstack/nova master: Extending delete_cell --force to delete instance_mappings https://review.openstack.org/540073
12:49:46 sean-k-mooney stephenfin: enhancing your specs with images http://logs.openstack.org/90/541290/4/check/build-openstack-sphinx-docs/da8d825/html/specs/rocky/approved/numa-aware-vswitches.html thats almost cheating :P
12:51:29 cdent I thought the same thing
12:55:59 sean-k-mooney cdent: you can tell being on the docs team is rubing off on him :) that said the fact that he uses images to help explain numa rather then 10 paragraps of text no one will follow might be a reason he is a good person to be on the docs team.
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 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:00:16 cdent sean-k-mooney: for sake of getting your point of view, why? Shouldn't it just be restarted somewhere else?
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 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:07:46 kashyap And so forth
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.

Earlier   Later