Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-18
14:04:32 dpawlik Hi, I can't find where is a problem when I deploy fresh installation of Nova. I create DB's: nova, nova_api, nova_cell0, nova_cell1 and nova_placement. On controller I execute: db sync, api_db sync, then cell_v2 map_cell0 where I set --database_connection to "nova_cell0" database. Then db online_data_migrations and I create new cell1: nova-manage cell_v2 create_cell --name cell1 where I set --database_connection to nova_c
14:04:32 dpawlik ell1 DB and also I change transport_url to new vhost: cell1. After creation, I rerun DB, API_DB sync, then cell_v2 discover_hosts, but still I have one issue: nova service-list shows me duplicated services. Is it something related to Queens release or I make something bad?
14:05:17 dansmith dpawlik: duplicate listing is almost always because you have two cell mappings pointing at the same database
14:05:45 dpawlik hmm
14:06:23 openstackgerrit Vlad Gusev proposed openstack/nova stable/queens: libvirt: Reduce calls to qemu-img during update_available_resource https://review.openstack.org/603358
14:06:42 dpawlik dansmith: But in nova.conf in section [database] I have connection to "nova_cell1" DB, for nova_api connection is to nova_api DB,
14:07:21 dansmith dpawlik: the [database]/connection doesn't get used for this, what matters is what is in the db for cell mappings
14:07:26 dpawlik I got a feeling that something is missing in cells doc
14:08:13 bauzas gibi: those rechecks aren't super happy when you're willing to review :)
14:09:03 dansmith dpawlik: or that you're just reading the docs and pasting commands that don't need to be run every time and thus you now have two mappings for the same DB :)
14:09:47 dansmith mriedem: are you able to still push a queens release? sounds like it's been a long time since we've had one
14:10:02 dansmith noticed because we're missing some juicy fixes from upstream in our branch that tracks upstream releases
14:10:10 dpawlik how can I check what mappings are done?
14:10:10 s10 mriedem: the problem with not backporting mox->mock change is that every other related fix will require resolving a conflict. For example, if I want consequent change https://review.openstack.org/#/c/589567/ be backported to Queens, this conflict resolve will be needed again...
14:10:20 gibi bauzas: you mean I should go and fix the unrelated gate issues instead? ;)
14:10:37 dansmith s10: this is why mox removal is a fool's errand, IMHO :)
14:10:37 mriedem dansmith: i am, or anyone is really able to propose them,
14:10:37 bauzas gibi: nah, just that it's sad
14:10:43 dpawlik dansmith: how can I check what mappings are done?
14:10:44 mriedem i'm taking over stable release review duties while tony is out
14:10:56 dansmith dpawlik: nova-manage cell_v2 list_cells (or whatever)
14:11:02 mriedem sean-k-mooney: you're missing my point
14:11:16 bauzas dansmith: FWIW, I turned the problem multiple ways
14:11:19 mriedem it was the mox->mock removal in rocky that is causing backport problems in queens now
14:11:22 bauzas dansmith: about NUMA affinity
14:11:30 bauzas dansmith: and the fact we don't model yet pGPUs
14:11:56 bauzas dansmith: the fact is, we said at the PTG that NUMA topology could be a thing for Stein but affinity isn't
14:12:04 bauzas so I need to cut my spec in tow
14:12:05 bauzas two
14:12:23 dansmith bauzas: so we're going to reshape now and then reshape again?
14:12:32 bauzas dansmith: my point is, we could model pGPUs as resource providers, but it will need a reshape anyway once we have NUMA nodes
14:12:43 sean-k-mooney mriedem: yes i know its just the loger we have partial mox removal and the more releases we have this in the longer we will have mox backport issues
14:13:00 dpawlik dansmith: http://paste.openstack.org/show/730274/
14:13:15 bauzas dansmith: yup, because if I begin to model NUMA nodes as children and pGPUs as grand children, placement wouldn't find all the resources or would constraint the query
14:13:50 dansmith bauzas: you don't have to do that, you can just make them children of the compute.. reparenting is easier than a full reshape
14:13:52 bauzas that's the whole purpose of the later spec I have to write for describing queries when it's all about chidren and grand-children relationship
14:13:52 dansmith but whatever
14:14:01 mriedem sean-k-mooney: we could have just, oh idk, never done it...
14:14:05 sean-k-mooney mriedem: we are going to have them either way so there is not much we can do unless nova is going to make mox a deliverable of the project and maintain it going forward
14:14:23 mriedem sean-k-mooney: which i believe dansmith said he'd do if it became a problem,
14:14:24 mriedem which it never has
14:14:28 dansmith dpawlik: looks like only one mapping in there, so I guess you're good
14:14:37 bauzas dansmith: yup, that's my thoughts, I'm just about to model pGPUs as children, then they would just be parented to a NUMA node in a reshape
14:14:48 dansmith mox3 has never broken, so yeah I signed up to fix breakages :)
14:14:58 dansmith bauzas: okay
14:15:18 bauzas just wanted to follow-up on the situation since you made a valid point :)
14:15:50 sean-k-mooney i guess going against a openstack wide goal did not seam to be a vailable option to me but ya if it was i guess we could have never started it
14:16:10 mriedem it was always a viable option
14:16:20 dpawlik dansmith: but what if I have in [database] coonection set cell0 DB so after creating cell1 they are duplicatd?
14:16:59 mriedem dansmith: re the queens release question, i think mel was holding up on some fixes for queens regressions but i don't have a list handy, so would just have to go through what's been proposed and see if there is anything critical we should target
14:17:18 sean-k-mooney mriedem: it was always a technical option i just didnt think it was an option to explcitly go against a openstack release goal from a governance point of view
14:17:26 dansmith mriedem: it's just been a really long time (three months it seems)
14:17:33 mriedem yeah i know
14:17:51 sean-k-mooney mriedem: anyway i guss that ship has sailed.
14:17:54 dansmith we're missing things like the compute disable -> weigher thing
14:19:00 dansmith mriedem: are you saying you think I shouldn't just propose one to unblock us because there may be things pending that need to be merged first?
14:19:42 mriedem dansmith: yes, i'd want to go through the open reviews first to see if there is anything we really need to get in
14:19:58 dansmith sigh
14:20:38 dansmith I don't really understand.. all the things proposed are likely things we want to get in.. is there some reason not to just cut one and then cut another?
14:21:11 dansmith kinda seems like we should just cut one any time the delta hits 10 or the delta is >1mo old or something.. not sure why it needs more thought than that
14:21:24 dansmith lyarwood says the delta is 55 patches right now which is.. a lot
14:22:26 mriedem i realize we haven't done stable releases in a while, it was a known thing, mel was holding up for something, i can't remember what atm, if i can get out from under the other 3 things people asked me to do before we started talking about this i can take a look
14:22:39 mriedem my butt is starting to hurt
14:24:11 dansmith sorry, I'm not trying to dump on you, I'm just saying... I'm not sure what the point of waiting is
14:25:46 mriedem the release team asked me to review the open stable release requests, so let me get through that first and then i'll take a look at our stable releases to come
14:25:47 sean-k-mooney dansmith: i mean to your point if there was something we were waiting for and we cut now without it its not hard to have another z stream in a week when we rememeber what it was
14:26:06 mriedem sean-k-mooney: yes i get it
14:26:50 sean-k-mooney mriedem: sorry i was not trying to take a dig at you.
14:27:55 mriedem it probably doesn't help that this rotated in just now https://www.youtube.com/watch?v=0XoyDqFy5pU
14:28:07 sean-k-mooney release automation is one of the tings that infra/release team desgined really well. its alot less of a pain then it was when you had to manually push and sign everything to pypi by hand
14:28:55 sean-k-mooney haha it certenly set a tone
14:32:00 mriedem dansmith: you wanna wade through some of the +2d rocky backports while waiting https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/rocky ?
14:32:26 dansmith mriedem: you know I'm asking about queens right?
14:32:30 mriedem yes
14:32:37 dansmith looks like there is a lot on queens that needs just a +W
14:32:43 dansmith but yeah I can try to hit both
14:33:21 dansmith ah, maybe some are still pending on the rocky ones
14:33:37 dansmith like the service list thing
14:37:50 lyarwood yeah sorry that's my bad, I +2'd a few waiting on stable/rocky so I wouldn't block anything while I was offline yesterday
14:39:50 dansmith gdi lyarwood, stop being proactive!
14:41:56 dansmith okay I just sent a raft of rocky stuff to meet its maker
14:54:49 openstackgerrit Vlad Gusev proposed openstack/nova stable/queens: WIP libvirt: Reduce calls to qemu-img during update_available_resource https://review.openstack.org/603358
14:55:31 mriedem btw, i think that's part of the ordering, we want to make sure stuff we release in queens is also released in rocky, so someone doesn't upgrade from queens to rocky in that window and lose some fixes - probably rare that would happen though
14:55:54 mriedem so we'll do a rocky->queens->pike->ocata release stack
14:58:41 dansmith if we release by the clock, frequently enough, and keep the deps in gerrit,
14:58:44 dansmith then it should never really happen
14:58:51 dansmith but if we have three-month windows, it's far more possible
15:11:49 openstackgerrit Chen proposed openstack/nova master: doc trivial: additional info to admin-password-injection https://review.openstack.org/603414
15:20:29 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Add 'disallow-isolcpus-with-overcommit-vcpus' spec https://review.openstack.org/603417
15:32:04 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Specify doctree directory https://review.openstack.org/603421
15:57:36 stephenfin mriedem, bauzas, dansmith: Can one of you put this python3-first patch through, please? https://review.openstack.org/#/c/601373/
15:58:32 bauzas stephenfin: easy review, thanks to your help
15:59:01 stephenfin bauzas: Cheers :)
15:59:32 bauzas stephenfin: no, ``Cheers``
15:59:43 bauzas it's a string, dude
16:00:08 stephenfin Think I've found my presentation topic for Denver 2019
16:00:42 bauzas :)
16:02:11 stephenfin bauzas: If you're game, there are also these. Think it's the last of them https://review.openstack.org/#/q/topic:python3-first+status:open+(project:openstack/os-traits+OR+project:openstack/os-vif)
16:04:16 openstackgerrit Surya Seetharaman proposed openstack/nova master: Merge extended_volumes extension response into server view builder https://review.openstack.org/596285
16:06:46 openstackgerrit Merged openstack/nova master: Merge security groups extension response into server view builder https://review.openstack.org/585475

Earlier   Later