| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-03 | |||
| 09:34:32 | adisky_ | hi , can anybody help on some query related to nova volume-update | |
| 09:34:34 | adisky_ | ? | |
| 09:41:07 | denaitre | bauwser: thanks for the answer! from my PoV you should declare your different glance api endpoints to a service like haproxy to manage the round-robin, and register the haproxy endpoint in keystone, does it make sense? | |
| 09:41:43 | bauwser | denaitre: yeah that's what I would do as an operator | |
| 09:42:11 | bauwser | you can define any HA strategy in a load-balancer behind a VIP | |
| 09:42:26 | bauwser | glanceclient shouldn't be handling that | |
| 09:42:30 | bauwser | but anyway | |
| 09:43:06 | bauwser | FWIW, I'd recommend you to use a single VIP for api_servers and do all your necessary HA rules behind that VIP | |
| 09:43:35 | denaitre | great, thank you | |
| 09:44:45 | denaitre | is this option mandatory? i mean, it would make sense that if it is not set, nova would contact keystone | |
| 09:53:19 | jaosorior | hey folks, I'm dealing with nova configurations and would like to know what the DEFAULT/host value is used for; the information in the sample config file is not very explicit :/ | |
| 10:09:40 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.openstack.org/439925 | |
| 10:12:44 | lyarwood | mdbooth: did you see https://review.openstack.org/#/c/437356/3 btw | |
| 10:14:10 | mdbooth | lyarwood: Nope. Is there anything I should be looking at in particular? | |
| 10:15:02 | mdbooth | lyarwood: Eurgh | |
| 10:15:31 | lyarwood | mdbooth: yeeeeeeeeeeeeah, I was sure one of us had looked at this before | |
| 10:16:06 | mdbooth | lyarwood: That workaround is obviously disgusting, but I'm actually ok with it because at least it calls itself out for what it is in the comment. | |
| 10:16:39 | lyarwood | mdbooth: cool, as long as you're fine with it, just wanted to highlight it as I recalled this being a complete PITA the last time someone tried to fix it | |
| 10:16:39 | mdbooth | i.e. it can be removed with confidence later. | |
| 10:28:50 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Move detach logic from manager into driver BDM https://review.openstack.org/439520 | |
| 10:28:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Only destroy BDMs after successful detach call https://review.openstack.org/440693 | |
| 10:28:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: objects: Add attachment_id to BlockDeviceMapping https://review.openstack.org/437665 | |
| 10:39:15 | openstackgerrit | Huan Xie proposed openstack/nova master: Make xenapi driver compatible with assert_can_migrate https://review.openstack.org/439960 | |
| 10:48:02 | openstackgerrit | sahid proposed openstack/nova master: libvirt: update the active migrations DS to support migration result https://review.openstack.org/409260 | |
| 10:48:03 | openstackgerrit | sahid proposed openstack/nova master: libvirt: ensure live-migration success https://review.openstack.org/409261 | |
| 10:58:16 | openstackgerrit | Andreas Jaeger proposed openstack/nova master: Fix api-ref with Sphinx 1.5 https://review.openstack.org/441053 | |
| 10:59:07 | openstackgerrit | Andreas Jaeger proposed openstack/nova master: Fix api-ref with Sphinx 1.5 https://review.openstack.org/441053 | |
| 11:12:45 | johnthetubaguy | ratailor: hi, can I help? | |
| 11:14:03 | johnthetubaguy | jaosorior_lunch: I guess you are having lunch, but lets try get that info updated when you get back | |
| 11:15:46 | johnthetubaguy | jaosorior_lunch: basically, it is the name of the rabbit queue used by Nova, and its the name used when binding ports with neutron (has to match the same conf in the neutron agent), and attaching volumes with Cinder. We probably need more context, given whats here: https://docs.openstack.org/developer/nova/sample_config.html | |
| 11:21:25 | openstack | Launchpad bug 1669746 in OpenStack Compute (nova) "sample config for host is unclear" [Medium,New] | |
| 11:21:25 | johnthetubaguy | jaosorior_lunch: let me know if this bug covers the problem OK: https://bugs.launchpad.net/nova/+bug/1669746 | |
| 11:25:11 | openstack | Launchpad bug 1452641 in Cinder "Static Ceph mon IP addresses in connection_info can prevent VM startup" [Medium,Confirmed] - Assigned to Jon Bernard (jbernard) | |
| 11:25:11 | ratailor | johnthetubaguy, https://bugs.launchpad.net/cinder/+bug/1452641 | |
| 11:25:40 | ratailor | johnthetubaguy, Can we handle this issue during nova-compute restart ? | |
| 11:27:05 | ratailor | johnthetubaguy, http://lists.openstack.org/pipermail/openstack-dev/2016-May/095391.html | |
| 11:27:06 | johnthetubaguy | ratailor: I don't really know I am afraid, we do have init_host for doing stuff on startup, but I don't think we generally support the volume system config changing like that | |
| 11:27:09 | AJaeger | nova cores, could you import translations again, please? https://review.openstack.org/#/c/439925/ - the deletions are all ok | |
| 11:27:16 | ratailor | johnthetubaguy, as mentioned in this ^^mailing discussion, which mentioned to implement periodic task to handle this issue. | |
| 11:28:26 | ratailor | johnthetubaguy, Because the connection info stored in BDM and domain xml of instance. And on hard reboot conn_info is getting updated in BDM and the updated conn_info is recorded in domain xml. | |
| 11:28:32 | johnthetubaguy | AJaeger: does that mean we don't need all those _LW and _LE stuff anymore? | |
| 11:29:19 | johnthetubaguy | ratailor: I mean it seems possible, I just don't really know enough about how ceph works to know if thats a good idea | |
| 11:29:31 | johnthetubaguy | ratailor: not sure how that works with Cinder attached ceph things either | |
| 11:30:35 | ratailor | johnthetubaguy, IMO implementing periodic task to handle this issue, would be an overhead. Because operators would be changing IPs rarely. And being a maintenance task, they might need to restart some services to take updated IPs in account. | |
| 11:30:59 | johnthetubaguy | ratailor: totally | |
| 11:31:18 | AJaeger | johnthetubaguy: you still need them so that the strings do not end in the main file. | |
| 11:31:32 | jbernard | ratailor: can we send hostnames instead of ip addresses? | |
| 11:31:43 | AJaeger | But translation of error and warnings is very very low prio for translators - and not sure it's usefull at all. | |
| 11:31:52 | johnthetubaguy | AJaeger: they would be the API responses then? or many CLI tool stuff? | |
| 11:32:14 | AJaeger | johnthetubaguy: _LW and _LE is what ends in your log files | |
| 11:32:15 | johnthetubaguy | AJaeger: honestly, it seems like totally a mistake we ever tried to translate the logs, but that might just be me | |
| 11:32:28 | ratailor | jbernard, I don't know, but the IPs are hardcoded in domain xml as well as BDM table. | |
| 11:32:39 | johnthetubaguy | AJaeger: yeah, I am just not sure what else we actually have in Nova that should be translated, other than logs | |
| 11:32:43 | AJaeger | johnthetubaguy: Me as well. So, goging forward you could not translate them at all - but discuss that with i18n team first | |
| 11:32:51 | johnthetubaguy | AJaeger: +1 | |
| 11:33:14 | openstack | Launchpad bug 1581367 in OpenStack Compute (nova) "Changed SAN iscsi IP addresses in connection_info can prevent VM startup" [Low,Confirmed] | |
| 11:33:14 | ratailor | johnthetubaguy, https://bugs.launchpad.net/nova/+bug/1581367 | |
| 11:33:35 | AJaeger | johnthetubaguy: for now, we just removed the log files from translation workflow completely... | |
| 11:33:43 | johnthetubaguy | ratailor: so they are soon going to be hardcoded into Cinder, in an immutable way | |
| 11:34:02 | ratailor | johnthetubaguy, I think, this is not only issue with ceph, its with how storage node are IPs are handled. | |
| 11:34:50 | ratailor | johnthetubaguy, could you please provide any reference for that ? | |
| 11:34:59 | johnthetubaguy | AJaeger: cool, I just think you are better removing all of Nova, I have a feeling the other stuff are just logs we haven't moved across, and API messages we never send back in anything but english right now (although I may have just missed that code that translates thouse) | |
| 11:35:36 | johnthetubaguy | ratailor: I have no reference, its just today we assume the IPs don't change, else the whole system falls over, which I guess is what the bugs are describing | |
| 11:36:25 | johnthetubaguy | ratailor: I think lyarwood and mdbooth are better looking at this than I am | |
| 11:36:53 | johnthetubaguy | ratailor: it sounds a bit like we need an os.brick connector refresh on nova-compute startup, but I have no idea how much that would mess up Cinder, probably a lot, for many drivers | |
| 11:37:36 | ratailor | johnthetubaguy, Thanks for your help! Where could I see if there is any progress on keeping hardcoded IPs that won't change ? | |
| 11:37:49 | mdbooth | lyarwood johnthetubaguy: Am I right in thinking that in the new world order we can just re-fetch connection_info from cinder? | |
| 11:38:19 | johnthetubaguy | mdbooth: basically, yes, although we are just getting back what we put there, I think | |
| 11:38:30 | mdbooth | So we could potentially have a retry loop of: try to connect, if it didn't work re-fetch (and re-stash) and try again. | |
| 11:38:50 | mdbooth | So if an iscsi endpoint changed, we'd eventually sort it out | |
| 11:39:02 | lyarwood | this is the ceph mon ip bug right? | |
| 11:39:07 | johnthetubaguy | ratailor: I can't say I heard about this problem before, so not sure if anyone is looking into it yet, looks like mdbooth might have some good ideas though | |
| 11:39:09 | johnthetubaguy | lyarwood: yeah | |
| 11:39:12 | mdbooth | lyarwood: Well this particular bug is about iscsi | |
| 11:39:18 | johnthetubaguy | well, both | |
| 11:39:29 | AJaeger | johnthetubaguy: yeah - and the priorities of the translators are nowadays horizon and its plugins, osc, docs. | |
| 11:39:29 | johnthetubaguy | they feel related | |
| 11:39:36 | mdbooth | The ceph thing is the same wrt volumes, but not wrt local disks | |
| 11:39:39 | johnthetubaguy | AJaeger: that makes total sense | |
| 11:39:42 | mdbooth | With local disks there's no connection_info | |
| 11:39:49 | lyarwood | yeah local disks look it up dynamically | |
| 11:40:02 | lyarwood | I was talking to melwitt about this at the ptg | |
| 11:40:04 | mdbooth | lyarwood: Nah, local disks it's hard-coded in nova.conf | |
| 11:40:12 | lyarwood | mdbooth: nope, not the mon ips | |
| 11:40:19 | mdbooth | lyarwood: Eh? | |
| 11:40:24 | mdbooth | Where does it look it up from? | |
| 11:40:39 | lyarwood | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/storage/rbd_utils.py#L162 | |
| 11:40:50 | johnthetubaguy | well, nova.conf would still be better than in lots of different places in the DB | |
| 11:40:57 | lyarwood | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/imagebackend.py#L813 | |
| 11:41:00 | lyarwood | mdbooth: ^ | |
| 11:41:05 | lyarwood | I was talking to melwitt about this at the ptg | |
| 11:41:13 | johnthetubaguy | it feels like we should just get this from os.brick every time? would that be possible / sensible? | |
| 11:41:19 | lyarwood | for volumes I think she verified a workaround of using shelve and unshelve | |
| 11:41:36 | johnthetubaguy | making hard reboot do it makes sense I guess | |
| 11:41:50 | johnthetubaguy | shelve you risk creating a snapshot | |
| 11:41:58 | ratailor | lyarwood, She also mentioned start/stop or hard reboot the instance. | |
| 11:41:58 | lyarwood | true | |
| 11:42:21 | lyarwood | ratailor: iirc start/stop doesn't update the connection_info | |
| 11:42:30 | mdbooth | lyarwood: Ok, it's hard-coded in ceph.conf | |
| 11:42:33 | johnthetubaguy | lyarwood: yeah, it doesn't today | |