Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-13
16:47:40 stephenfin moshele: No problem. Thanks :)
16:50:13 klindgren Hello, Working on setting up a new pike cloud with cellsv2 running on it. and trying to get a list of services that need to be ran at each level. I found https://docs.openstack.org/nova/latest/user/cellsv2-layout.html. But I just want to confirm. So at the Top level API cell. I need to run: nova-api, nova-consoleauth, nova-spicehtml5proxy, nova-conductor, API rabbitmq, API DB, Cell0 DB. Then in each cell I need to r
16:50:13 klindgren un: Cell rabbitmq, nova-conductor, nova-computes (attached to the cell rmq), cell DB. Now in cellv1 we run nova-manage at both the api cell and the child cell level. I assume the same is required with cellsv2?
16:52:24 dansmith klindgren: ye[
16:52:28 dansmith er yup
16:52:45 klindgren So all thats need in child cells now is nova-conductor
16:53:07 dansmith and compute :)
16:53:49 mriedem scheduler is top level
16:53:52 mriedem didn't see that in your list
16:54:10 dansmith oh yeah
16:54:14 dansmith you will want a scheduler
16:54:26 klindgren and placement
16:54:48 mriedem yes
16:54:53 mriedem placement is assumed to be global
16:55:04 mriedem cern is doing it per-cell to start
16:55:21 mriedem i think for perf reasons
16:55:30 mriedem if you're not at cern scale, global is your long-term friend
16:55:34 mriedem imo
16:55:37 dansmith yup
16:56:50 cfriesen__ Is it possible to reset specific individual tenant quotas back to the default value? (by writing -1 to them, maybe?) What about specific user/tenant quotas? (The code there makes it look like you can't set the max to more than the custom tenant quota.)
16:57:15 melwitt except for console proxies, after they move (because they'll need cell database access and don't have instance uuid)
16:57:30 mriedem cfriesen__: once you start overriding default quotas for a tenant, you're stuck
16:57:39 mriedem unless you remove those entries from the db
16:57:51 melwitt cfriesen__: writing -1 will make them unlimited, so that's not what you want either
16:58:04 mriedem remember that the lookup order for quota is (1) per-project quota table (2) global quota_classes table, (3) config
16:58:14 mriedem so you'd have to remove (1)
16:58:19 klindgren do you guys have a blog post or something that explains all the nova-manage commands to run now to setup cellsv2?
16:58:22 melwitt yup, that
16:58:37 mriedem klindgren: https://docs.openstack.org/nova/latest/user/cells.html
16:59:02 mriedem klindgren: there is basic setup stuff in there and in the install guide
16:59:12 mriedem the cellsv1->v2 portion is admittedly light
16:59:34 mriedem klindgren: and you know about https://etherpad.openstack.org/p/cellsv1-to-v2-migration
17:00:18 cfriesen__ mriedem: so we have a way to remove *all* per-tenant quotas, but no way to remove individual ones?
17:00:42 klindgren yea - right now just getting a pike cloud with all the new features enabled on it (cellsv2, network aware placement, neutron routed networks, ect ect). So we can start working on the migration to that. So not currently concerned with cellsv1 -> cellv2
17:00:46 mriedem cfriesen__: this ?https://developer.openstack.org/api-ref/compute/#revert-quotas-to-defaults
17:00:59 mriedem klindgren: ack
17:01:24 cfriesen__ mriedem: yeah. so you can revert all the quotas for a tenant back to defaults, and you can override specific quotas, but you can't revert specific quotas back to defaults
17:01:26 mriedem cfriesen__: yes correct, https://developer.openstack.org/api-ref/compute/#revert-quotas-to-defaults removes all of the per-tenant quota
17:01:47 mriedem cfriesen__: you'd need like a DELETE /os-quota-sets/{tenant_id}/{quota_key} or something
17:01:49 mriedem which we don't have
17:02:16 cfriesen__ right. okay, thanks
17:02:44 klindgren mriedem, thanks for the link, I thought I looked at this, but I guess I just didn't scroll down enough :-/
17:04:04 mriedem klindgren: that reminds me of something sdague posted recently,
17:04:16 mriedem at this point, we should probably move the 'setup of cellsv2 and faqs' to the top of page
17:04:22 mriedem and the cellsv1/v2 manifesto to the bottom of page
17:04:35 mriedem so people don't glaze over the content looking for install instructions
17:04:59 melwitt I think that's a good idea
17:05:36 mriedem i can take a shot at that re-org in a bit
17:05:49 openstackgerrit Merged openstack/python-novaclient master: Optimize jobs run on novaclient https://review.openstack.org/527550
17:09:16 melwitt mriedem: I have a question regarding my consoles series. because console proxies run globally in devstack, the top patch in my series fails and then passes on the devstack Depends-On patch https://review.openstack.org/#/c/484973/ that moves proxies per cell (which is expected). would you recommend I instead make the top patch Depends-On the devstack patch to set things up properly?
17:11:20 mriedem a bit confused,
17:11:53 mriedem i'd think we would change devstack to run the console proxy service per-cell if we're in superconductor mode
17:12:02 mriedem else globally for singleconductor?
17:12:18 melwitt yeah, that's what I think I've done in my devstack patch
17:12:32 mriedem but it's a chicken and egg isn't isn't it?
17:12:39 melwitt it's just that the current topology is console proxies at the top. my series will make it so console proxies need to be per cell
17:12:41 melwitt yeah
17:12:43 mriedem the per-cell nova patch can't work if devstack is using global
17:12:57 mriedem so what happens if you changed devstack today to run consoleproxy per cell
17:13:00 mriedem w/o a depends-on
17:13:05 mriedem how does it blow up
17:13:12 melwitt right. the current console stuff *might* probably work if deployed per cell because the storage is global
17:13:19 melwitt well, I'm not sure actually
17:13:25 mriedem so you probably need a 2-step dance
17:13:44 melwitt yeah, let me try that without a depends-on and see what happens
17:14:12 mriedem if it's like one test in tempest that fails, we could maybe disable the test in tempest via config in devstack until we have the thing that makes it all work with the nova patch
17:14:34 melwitt I see. yeah, it is one test, the novnc test
17:15:00 stephenfin cfriesen__: This look like something you'd be interested in reviewing? https://review.openstack.org/#/c/527472/
17:15:32 melwitt mriedem: okay, let me try a run without depends-on in the devstack patch and see what blows up. thanks for the ideas
17:16:23 cfriesen__ stephenfin: yep, will take a look
17:20:04 mriedem melwitt: ok then you could disable that in devstack/lib/tempest using CONF.compute_feature_enabled.vnc_console=False in tempest.conf
17:20:28 mriedem melwitt: so maybe disable that with a TODO saying if you're running per-cell console proxy, it won't work until the nova patch which a later devstack patch depends on and removes that tempest conf
17:20:39 melwitt aha, cool
17:20:45 mriedem so devstack1->nova->devstack2
17:20:48 mriedem is the dep order i think
17:21:00 mriedem if that works, you owe me a cream sodda
17:21:01 mriedem *soda
17:21:17 melwitt heh, can do
17:48:22 openstackgerrit Stephen Finucane proposed openstack/nova master: SchedulerReportClient._get_providers_in_aggregates https://review.openstack.org/521097
17:48:22 openstackgerrit Stephen Finucane proposed openstack/nova master: Traits ops on ProviderTree https://review.openstack.org/521605
17:48:23 openstackgerrit Stephen Finucane proposed openstack/nova master: Move aggregates from report client to ProviderTree https://review.openstack.org/521685
17:48:23 openstackgerrit Stephen Finucane proposed openstack/nova master: Track provider traits in report client https://review.openstack.org/521686
17:48:24 openstackgerrit Stephen Finucane proposed openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539
17:48:24 openstackgerrit Stephen Finucane proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540
17:48:25 openstackgerrit Stephen Finucane proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756
17:48:25 openstackgerrit Stephen Finucane proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541
17:48:26 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: Scheduler[Report]Client.get_provider_tree https://review.openstack.org/521098
17:48:26 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: ComputeDriver.update_provider_tree() https://review.openstack.org/521187
17:48:27 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246
17:48:46 cfriesen__ stephenfin: the added comments are helpful
17:49:36 stephenfin cfriesen__: Good to hear. I got pretty bogged down in it myself yesterday and decided to add what I learned
17:51:21 stephenfin I also noticed a fair chunk of duplication and the likes going on, e.g. https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L148-L155 vs https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L242-L248
17:51:35 stephenfin Gonna tackle that once this in in, hopefully
17:53:54 yumapath hi all, am trying to launch a instance on devstack (queen's) and am getting the following error
17:54:04 yumapath Error: Failed to perform requested operation on instance "vm2", the instance has an error status: Please try again later [Error: No sql_connection parameter is established].
17:54:11 yumapath what could be the possible reason
17:54:25 yumapath googling did not yeild any useful results
17:54:34 yumapath can someone help
17:55:28 stephenfin yumapath: Looks like an oslo.db issue. You'd be better off asking about it on #openstack http://codesearch.openstack.org/?q=No%20sql_connection%20parameter%20is%20established&i=nope&files=&repos=
17:56:10 yumapath ok

Earlier   Later