Earlier  
Posted Nick Remark
#openstack-nova - 2017-03-03
07:24:50 migi edleafe: hi
08:29:19 bauzas good morning Nova
08:32:40 openstackgerrit Feodor Tersin proposed openstack/nova-specs master: Add ScaleIO ephemeral storage backend https://review.openstack.org/304715
09:13:27 openstackgerrit Huan Xie proposed openstack/nova master: Make xenapi driver compatible with assert_can_migrate https://review.openstack.org/439960
09:14:32 denaitre hi everyone
09:14:47 denaitre I was looking for a piece of information
09:15:45 denaitre I noticed that one can set different api adresses in nova.conf (e.g. glance, neutron)
09:16:14 denaitre I thought nova would contact keystone for getting such information
09:17:46 denaitre I feel like I missed something
09:18:36 bauwser denaitre: which specific conf opts are you looking at ?
09:19:43 denaitre for instance, `api_servers` under [glance]
09:20:19 denaitre i think it is called `url` under [neutron]
09:27:08 bauwser ah that
09:27:11 bauwser well
09:28:25 bauwser denaitre: the api_servers conf opt is a legacy feature helping glance client to do round-robin calls between all the glance API services
09:28:47 bauwser from my personal PoV, that's very unfortunate we accepted that
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 mdbooth i.e. it can be removed with confidence later.
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: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: objects: Add attachment_id to BlockDeviceMapping https://review.openstack.org/437665
10:28:51 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Only destroy BDMs after successful detach call https://review.openstack.org/440693
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 johnthetubaguy jaosorior_lunch: let me know if this bug covers the problem OK: https://bugs.launchpad.net/nova/+bug/1669746
11:21:25 openstack Launchpad bug 1669746 in OpenStack Compute (nova) "sample config for host is unclear" [Medium,New]
11:25:11 ratailor johnthetubaguy, https://bugs.launchpad.net/cinder/+bug/1452641
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: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 ratailor johnthetubaguy, https://bugs.launchpad.net/nova/+bug/1581367
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: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 johnthetubaguy they feel related
11:39:29 AJaeger johnthetubaguy: yeah - and the priorities of the translators are nowadays horizon and its plugins, osc, docs.
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

Earlier   Later