Earlier  
Posted Nick Remark
#openstack-nova - 2018-09-18
12:48:52 stephenfin *its
12:48:57 gibi stephenfin: it was so unconfidental that you saw the demo earlier than anybody in the company ;)
12:49:11 stephenfin :D Touché
12:52:31 gibi stephenfin: ohh I +2d the successor earlier :)
12:53:48 gibi stephenfin: done
13:02:39 openstackgerrit Christian Berendt proposed openstack/nova master: Add missing backticks in nova-manage docs https://review.openstack.org/603370
13:03:53 bauzas stephenfin: looks like someone saw your presentation ^
13:05:22 openstackgerrit Michele Baldessari proposed openstack/nova master: Ignore ArgsAlreadyParsedError exceptions when registering logging options https://review.openstack.org/603372
13:05:32 efried ō/
13:07:21 mriedem brinzhang: hi
13:07:37 brinzhang mriedem: Hi
13:07:56 mriedem you had some questions?
13:08:25 bauzas mriedem: FWIW, working on your change locally
13:08:30 brinzhang yes.
13:08:37 brinzhang 1. about this https://review.openstack.org/#/c/599276/23/api-guide/source/polling_changes-since_parameter.rst
13:09:19 mriedem yeah jay is right, git mv would be better to preserve the history
13:10:55 brinzhang But I think "polling_changes-since_and_changes-before_parameters.rst" already contains the contents of "polling_changes-since_parameter.rst", so I think this should be replaced by current doc. As mriedem said, I need to do a redirectmatch for old links.
13:11:21 brinzhang ignore the last sentence. ^^
13:12:39 brinzhang I think this do a rediecetmatch for old links is better
13:13:16 mriedem why not just rename the file as jaypipes suggested to preserve the history?
13:13:20 mriedem git history i mean
13:13:32 mriedem you have to add a redirect link either way
13:14:03 mriedem then it's also easier, as a reviewer, to see what you changed about the document when adding the changes-before conent
13:14:05 mriedem *content
13:15:07 brinzhang I don't think I understand the meaning of jaypipes :-(
13:16:10 mriedem just git mv the file to rename it
13:16:15 mriedem and then add the changes-before content
13:16:47 mriedem $ git mv api-guide/source/polling_changes-since_parameter.rst api-guide/source/polling_changes.rst
13:18:54 brinzhang Ok, after do this, can I replace the contents of the polling_changes-since_and_changes-before_parameters.rst file directly with polling_changes.rst?
13:19:16 brinzhang Not using git mv yet :-(
13:19:23 mriedem polling_changes-since_and_changes-before_parameters.rst becomes polling_changes.rst - it's just a file rename
13:19:31 mriedem and then you can edit polling_changes.rst to add changes-before content
13:20:26 brinzhang OK. I know.
13:25:30 stephenfin bauzas: :D
13:31:49 openstackgerrit Brin Zhang proposed openstack/nova master: Resource retrieving: add changes-before filter https://review.openstack.org/599276
13:39:05 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: test resize reschedule up-calls https://review.openstack.org/603389
13:43:53 sean-k-mooney looks like tetsuro has already written up the negitive memberof spec before i started https://review.openstack.org/#/c/603352/ :)
13:48:03 gibi sean-k-mooney: as far as I remember tetsuro grabbed that on the yesterday's scheduler meeting
13:52:18 openstackgerrit Brin Zhang proposed openstack/nova master: Resource retrieving: add changes-before filter https://review.openstack.org/599276
13:53:13 s10 Hello. I have a question about backport https://review.openstack.org/#/c/603358 . Clean cherry-pick to stable/queens is impossible because of the https://review.openstack.org/#/q/Ic853743573aa0b74d5d2c5b8b47252b875d5f7ef . Could I just cherry-pick this mox to mock change to stable/queens and build this backport on top of it or backported fix should use mox in tests?
13:55:54 mriedem brinzhang: that's still not a rename,
13:56:05 mriedem brinzhang: it's getting late for you - i can pull your change down and fix the rename
13:56:31 brinzhang mriedem: thank you.
13:59:02 mriedem s10: so that queens backport is going to fail tests or you've already modified the cherry pick?
13:59:10 dpawlik hi, I :a
13:59:29 mriedem s10: because it looks like a clean backport
13:59:59 s10 mriedem: I built cherry-pick fix on top of the mock to mox cherry-pick
14:00:29 mriedem oh so you're asking if backporting https://review.openstack.org/#/c/603353/ is ok
14:00:41 mriedem yet another reason why mox removal is a pain in the ass....
14:01:20 mriedem s10: personally i'd prefer that we don't backport these mox->mock changes since they are usually large and hairy,
14:01:35 mriedem and instead just modify the conflicting backports that you need and mention the conflict in the commit message
14:01:53 mriedem e.g. https://review.openstack.org/#/c/603358 commit message would mention the conflict because of https://review.openstack.org/#/q/Ic853743573aa0b74d5d2c5b8b47252b875d5f7ef
14:02:59 mriedem s10: left some comments on both of those backports
14:03:05 mriedem let me know if you need help
14:04:31 sean-k-mooney mriedem: isnt this yet another reasong to finish the mox->mock stuff this cycle
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

Earlier   Later