Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-23
15:39:53 CeeMac but I'm guessing I'd need to go with mounting /var/lib/nova/instances to NFS on our SAN
15:40:15 CeeMac which is where instances_path points to right now
15:40:19 CeeMac in nova.config
15:40:20 sean-k-mooney CeeMac: i think we have a config option that will help
15:40:37 sean-k-mooney https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.max_local_block_devices
15:40:51 sean-k-mooney if you set that to 0 you have to use cinder volumes
15:40:58 sean-k-mooney not sure if tha tis what you want
15:41:39 CeeMac sean-k-mooney: that is a good start to prevent local disks being created and potentially filling up the (small) local disks on the compute
15:41:49 sean-k-mooney the other options open to you if you nova no/limnited local stoage and have ceph is to enable the RBD image backend
15:41:57 CeeMac but I haven't found a way to instruct rancher, or docker for that matter, to use volumes for images
15:42:09 CeeMac sean-k-mooney: sadly no ceph here
15:42:17 CeeMac iscsi backed cinder
15:42:26 sean-k-mooney ah ok
15:42:52 sean-k-mooney we dont have a cinder or iscis image backend to force all instace to use cinder unfortunetly
15:43:01 CeeMac is NFS the only/best/supported way of backing off the instance_path, or is iscsi an option?
15:43:27 CeeMac haha, i think you answered that question then.
15:43:33 sean-k-mooney i think you would be stuck with nfs
15:44:12 CeeMac you could be right, at least for the short term until I can get/hack a workaround for rancher to be able to call for volume on instance launch
15:44:48 CeeMac thanks for the help mriedem and sean-k-mooney appreciate it
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

Earlier   Later