Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-23
15:44:49 sean-k-mooney rancher use docker to run all service rihgt
15:44:58 sean-k-mooney i have not looked at rahcner os much
15:45:12 CeeMac yeah
15:45:16 sean-k-mooney but i think you can confugre docer to use remote sotorage
15:45:20 CeeMac and docker-volume isn't block storage aware
15:45:32 CeeMac you feed it a flavour and image effectively
15:45:59 sean-k-mooney e.g. i think you should be able to have the non system docker use a volume plugin and mont /var/libvirt/instace... or what ever on a network share
15:46:44 CeeMac if rancher was running inside openstack yeah, but we're connecting to openstack through api to a project from outside
15:47:07 CeeMac i'll have a ponder
15:47:40 sean-k-mooney i know there used to be a tone of voluem plugins https://docs.docker.com/engine/extend/legacy_plugins/#volume-plugins but i dont know if any of thos worked with racner/still exists
15:48:16 CeeMac i've seen a cinder driver for docker on github, but havent had a chance to test that yet
15:49:01 mriedem sean-k-mooney: https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.max_local_block_devices is not what you think it is
15:49:31 mriedem sean-k-mooney: that's only if the bdm has destination_type='local'
15:49:45 mriedem unless you mean for the implicit image-defined bdm
15:49:48 sean-k-mooney it prevent you spaning flavor tha trequest ephmeral/swap or root disk if you are using qcow
15:49:56 mriedem source_type='image', destination_type='local'
15:50:14 sean-k-mooney ya i ment you can use that to ensure only bfv guest can boot on that node
15:50:29 mriedem *any* node
15:50:36 mriedem it's config-driven api
15:50:49 sean-k-mooney yeah thos are awsome... but ya
15:51:52 sean-k-mooney i was looking to do that in the past but since i was deploying ceph for cinder i just deploy with the rbd image backend instead
15:57:51 sean-k-mooney mriedem: im going to step away for an hour or so to have breakfast/lunch but i plan to adress your comments on https://review.opendev.org/#/c/669738/ when i get back since they have been waiting a while.
15:58:49 mriedem breakfast/lunch?
15:58:59 mriedem it's 5pm
15:59:00 sean-k-mooney lyarwood: mriedem if we can land https://review.opendev.org/#/c/678098/ on stable stine that would make mnaser happy
15:59:37 sean-k-mooney yes.. i normally eat once to twice a day. usually i try to grab something at around 3
15:59:48 sean-k-mooney and then around 8
16:00:28 sean-k-mooney or i jsut have one big meal around 6 and then snack on fruit/nuts/small things
16:02:48 mriedem i just got the image of you as the giant in jack and the beanstalk crushing human bones to make your bread
16:02:50 mriedem "small things"
16:04:12 dansmith artom: I looked at the top two patches with plans to prescribe an ordering and squash/split instructions, but I think it probably just needs to be fully squashed
16:04:53 artom dansmith, yeah? I was hoping to avoid that, as it makes reviewing difficult
16:04:56 dansmith I know
16:05:10 dansmith I kept calling out lines as "this could be separate" and then removed those comments
16:05:26 artom But you're most likely right (duh!), as a whole bunch of things need to happen in one chunk
16:06:17 dansmith yup, any ordering that I could come up with was dependent on a patch ahead of everything that was like "add a bunch of single-line unrelated changes to various places" followed by a bigger one that hooked them all up
16:06:21 dansmith and it just doesn't make sense
16:06:47 dansmith I kept having to jump back and forth between those two patches to work that out and ultimately fail, which means reviewing isn't really improved
16:06:54 dansmith fewer lines, but not in a meaningful way, so...
16:07:11 artom Well, at least the commit message is already in bullet points
16:07:31 dansmith usually that's a bad sign, but in this case, I don't really see a useful way around
16:07:45 dansmith mriedem might disagree, but hopefully not
16:08:01 dansmith he likes to disagree with me periodically to make himself look smart though
16:08:33 dansmith or to assert his smartness, maybe I should say
16:08:46 artom Oh, nice save
16:08:51 dansmith heh
16:10:45 mriedem https://www.youtube.com/watch?v=YLP1_jwT9_M
16:11:12 dansmith heh
16:11:50 dansmith https://www.youtube.com/watch?v=oGfkPCZYfFw
16:12:35 artom Have we finally devolved to communicating via only YouTube videos?
16:12:55 dansmith trying to speak mriedem's language
16:12:55 openstackgerrit Balazs Gibizer proposed openstack/nova master: update allocation in binding profile during migrate https://review.opendev.org/656422
16:12:56 openstackgerrit Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle migrations https://review.opendev.org/655114
16:14:31 openstackgerrit Matt Riedemann proposed openstack/nova master: Docs and functional test for max_local_block_devices https://review.opendev.org/678268
16:15:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth https://review.opendev.org/655109
16:16:39 dougsz One other question (sorry!). If I upgrade one cell of many, run online_data_migrations in that cell only, set upgrade_levels to auto (or N-1 level) to pin RPC version, will there be a performance penalty in that cell, until all cells move to the latest RPC version?
16:17:05 dansmith dougsz: you need to move the upgrade pin only once all the cells are updated
16:17:19 dansmith otherwise the conductors will start speaking newer versions to the old cells
16:17:29 dansmith also,
16:17:31 dougsz so auto is not good enough?
16:18:00 dansmith if you use auto, then it will always get the minimum support version, you don't need to tweak it before and after
16:18:11 dansmith online-data-migrations is unrelated to the rpc pin version fwiw
16:19:53 openstackgerrit Balazs Gibizer proposed openstack/nova master: Func test for migrate server with ports having resource request https://review.opendev.org/655113
16:19:54 openstackgerrit Balazs Gibizer proposed openstack/nova master: Make _rever_allocation nested allocation aware https://review.opendev.org/676138
16:20:42 dougsz ok, thanks, that makes sense, i can upgrade a single cell and take my time checking that it doesn't catch fire before upgrading the others
16:21:00 dansmith theoretically yes
16:21:06 dougsz :)
16:21:10 dansmith I believe cern does this
16:23:13 openstackgerrit Merged openstack/nova master: trivial: Rename exception argument https://review.opendev.org/671795
16:23:22 openstackgerrit Merged openstack/nova master: Remove 'hardware.get_host_numa_usage_from_instance' https://review.opendev.org/671797
16:23:35 openstackgerrit Merged openstack/nova master: Remove 'hardware.host_topology_and_format_from_host' https://review.opendev.org/671798
16:23:45 openstackgerrit Merged openstack/nova master: Remove 'hardware.instance_topology_from_instance' https://review.opendev.org/671799
16:23:57 openstackgerrit Merged openstack/nova master: Rework 'hardware.numa_usage_from_instances' https://review.opendev.org/672565
16:24:49 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support reverting migration / resize with bandwidth https://review.opendev.org/676140
16:27:10 openstackgerrit Balazs Gibizer proposed openstack/nova master: Func test for migrate re-schedule with bandwidth https://review.opendev.org/676972
16:29:10 stephenfin Nice. Delighted to get rid of all those awful functions ^
16:29:22 stephenfin This is all going swimmingly
16:29:32 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support migrating SRIOV port with bandwidth https://review.opendev.org/676980
16:31:55 openstackgerrit Balazs Gibizer proposed openstack/nova master: Allow migrating server with port resource request https://review.opendev.org/671497
16:36:06 artom dansmith, about the is_trackable_migration removal...
16:36:24 dansmith yar
16:36:30 artom We obviously need to get rid of it, because we want the resource tracker to track NUMA live migrations and update resource usage accordingly
16:37:13 artom But we're removing it entirely, not just for NUMA live migrations.
16:37:22 dansmith isn't this just for reporting purposes?
16:37:33 artom Well, resource usage as well
16:37:35 dansmith I've mostly dumped this out of my brain because placement,
16:37:44 artom NUMATopologyFilter still uses it
16:37:47 dansmith but does the scheduler actually use some of this information anymore?
16:37:51 dansmith right, okay, the legacy things
16:38:27 artom So because we'll be tracking all live migrations, we need to do claims for all live migrations, not just NUMA ones
16:38:35 artom (which is what's currently in the patch series)
16:38:39 dansmith so right now we don't report this for live migrations, nor do we claim, so the numa filter will send us things we don't have room for, and we also won't do claims to check that it was wrong, right?
16:38:55 artom Yep
16:39:14 dansmith okay, but non-numa-affected live migrations are already protected and don't need anything else right?
16:39:21 dansmith because we're depending on placement for the non-numa resources
16:39:32 artom Yeah, that should be fine
16:39:40 artom I was more worried about things like PCI
16:40:05 artom Though I guess we don't support live migrations for those at all, so it the claim fails, it'll just be a plus
16:40:11 dansmith no live migration with pci devices yeah?
16:40:12 dansmith right

Earlier   Later