| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-02 | |||
| 17:32:33 | dansmith | mriedem: melwitt: I replied to a few comments from melwitt | |
| 17:33:03 | dansmith | melwitt: yeah either will be disruptive and tons of work for sure | |
| 17:41:04 | jaypipes | mriedem: save me from needing to go through the code... on unshelve do we allow changing the flavor or image? | |
| 17:49:10 | mriedem | jaypipes: no | |
| 17:50:53 | jaypipes | mriedem: k, thanks | |
| 21:22:42 | redkrieg | Hi, I'm interested in changing the vif driver for an existing instance but I don't see any differences between an instance created with an image that has the hw_vif_model property set to e1000 and one with the default virtio. is there a way to change it with the openstack cli or does it have to be done in the libvirt xml file? | |
| 21:36:08 | redkrieg | I have the same question about cpu passthrough as well, if anyone sees this later. | |
| 22:31:47 | openstackgerrit | Belmiro Moreira proposed openstack/nova master: Change to debug repetitive info messages https://review.openstack.org/628058 | |
| 22:40:16 | openstackgerrit | Belmiro Moreira proposed openstack/nova master: Change API unexpected exception message https://review.openstack.org/628061 | |
| #openstack-nova - 2019-01-03 | |||
| 01:23:59 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Spec for cross-cell resize https://review.openstack.org/616037 | |
| 01:24:23 | mriedem | melwitt: dansmith: ^ round deux | |
| 03:08:07 | openstackgerrit | Yongli He proposed openstack/nova-specs master: add spec "show-server-numa-topology" https://review.openstack.org/612256 | |
| 03:22:58 | openstackgerrit | Yongli He proposed openstack/nova-specs master: add spec "show-server-numa-topology" https://review.openstack.org/612256 | |
| 04:16:03 | alex_xu | jaypipes: thanks for the response | |
| 06:17:33 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova stable/rocky: Imported Translations from Zanata https://review.openstack.org/628109 | |
| 06:44:33 | brinzhang | Hi, when I boot an instance with a network A, and A has two or more IPv6 subnet, then the instance will be allocated two or more ipv6, I didn't figure this design idea. Can anyone explain it? | |
| 06:45:15 | brinzhang | If the network A has more IPv4 subnet, there will be allocated one IP(ipv4). | |
| 06:48:46 | alex_xu | brinzhang: that sounds like a question for neutron, not nova | |
| 06:49:55 | alex_xu | brinzhang: since nova only pass the network to neturon, the neutron done all the logic, that is scope of neutron I think | |
| 06:50:51 | brinzhang | alex_xu: Thanks. I was asked in openstack-neutron channel too. | |
| 06:51:02 | alex_xu | brinzhang: np, cool | |
| 07:53:56 | openstack | bug 1790204 in OpenStack Compute (nova) "Allocations are "doubled up" on same host resize even though there is only 1 server on the host" [High,Triaged] https://launchpad.net/bugs/1790204 | |
| 07:53:56 | openstackgerrit | Merged openstack/nova master: Add functional regression recreate test for bug 1790204 https://review.openstack.org/619123 | |
| 08:21:34 | yedongcan | brinzhang: Please refer this: https://specs.openstack.org/openstack/neutron-specs/specs/kilo/multiple-ipv6-prefixes.html | |
| 08:28:10 | openstackgerrit | Rui Zang proposed openstack/nova-specs master: support virtual persistent memory https://review.openstack.org/601596 | |
| 08:44:29 | brinzhang | yedongcan: Thank you, I will look at this :P | |
| 09:23:35 | openstackgerrit | Daniel Pawlik proposed openstack/nova stable/queens: Remove stale pip-missing-reqs tox test https://review.openstack.org/628128 | |
| 09:44:07 | openstackgerrit | Jie Li proposed openstack/nova master: Add compute version 37 to support volume backed server rebuild https://review.openstack.org/625893 | |
| 11:55:47 | openstackgerrit | Chris Dent proposed openstack/nova master: Delete the placement code https://review.openstack.org/618215 | |
| 12:21:19 | openstackgerrit | Yikun Jiang proposed openstack/nova master: WIP: Per aggregate scheduling weight https://review.openstack.org/628163 | |
| 13:08:19 | maciejjozefczyk | hey! | |
| 13:08:46 | maciejjozefczyk | maybe somebody has quick how-to run grenade jobs under my patch? | |
| 13:20:06 | jaypipes | alex_xu: see my latest comment on the PMEM spec... do you think it would be better to just use the block mode translation system for PMEM instead of the PMEM namespace system? After reading (most of) the original PMEM spec from Intel, it seems that the block mode setup is the more generic "I'm just a bunch of GB of block storage" resource class versus the PMEM namespace mode... | |
| 13:23:46 | cdent | jaypipes: I thought the reason for not doing that was because of fragmentation? I haven't, however, read the original spec, so I may have no idea what I'm talking about | |
| 13:27:02 | jaypipes | cdent: well, unless I'm badly mistaken, the difference is kind of like the difference between a bunch of GB of block storage and a filesystem that might go on a partition of said block storage. | |
| 13:27:38 | jaypipes | cdent: one needs to be wiped/cleaned/formatted whereas the other is just the bunch of blocks for storing stuff. it's up to the user to format it how they need. | |
| 13:28:44 | cdent | it's all a bit bewildering. So often we these things I think "is a vm really what you want for this?" | |
| 13:28:44 | openstackgerrit | Maciej Jozefczyk proposed openstack/nova master: Force refresh instance info_cache during heal https://review.openstack.org/591607 | |
| 13:28:44 | openstackgerrit | Maciej Jozefczyk proposed openstack/nova master: Add fill_virtual_interface_list online_data_migration script https://review.openstack.org/614167 | |
| 13:28:45 | openstackgerrit | Maciej Jozefczyk proposed openstack/nova master: Rename method _gather_port_ids_and_networks to _get_cached_network_info https://review.openstack.org/628175 | |
| 13:32:45 | jaypipes | maciejjozefczyk: reviewing your patches now. | |
| 13:44:40 | jaypipes | maciejjozefczyk: I am sincerely sorry. Please see my comment on the bottom patch :( | |
| 13:56:49 | openstackgerrit | Chris Dent proposed openstack/nova master: Remove placement from nova install docs https://review.openstack.org/628184 | |
| 13:56:49 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Update nova docs front page for placement removal https://review.openstack.org/628183 | |
| 13:56:50 | openstackgerrit | Chris Dent proposed openstack/nova master: Remove placement from contributor doc https://review.openstack.org/628186 | |
| 13:56:50 | openstackgerrit | Chris Dent proposed openstack/nova master: Remove link to placement configuration from nova config docs https://review.openstack.org/628185 | |
| 13:57:09 | maciejjozefczyk | jaypipes: :) easy | |
| 13:57:50 | maciejjozefczyk | I'm thinking now how previous patch failed on this: http://logs.openstack.org/67/614167/9/check/neutron-grenade/105121b/logs/grenade.sh.txt.gz | |
| 13:58:40 | maciejjozefczyk | jaypipes: maybe its related to the mixed context that you found in online_data_migrations script | |
| 14:02:37 | alex_xu | jaypipes: the PMEM namespace is the way suggested by the qemu, it is best performance way. | |
| 14:03:27 | alex_xu | jaypipes: block mode need a driver layer in the kernel, that isn't real direct access. I asked Rui reply on the spec, I think he can answer this better | |
| 14:05:46 | alex_xu | jaypipes: also in the beginning, we take a look at another way, build a pmem aware filesystem on the pmem namespace, but after talk with virtualization guys, they told me that is a way kernel push forward in the before, but there is bug can't be fixed in the kernel, so pmem namespace is only way for now | |
| 14:06:44 | alex_xu | then the dream of no fragmentation is broken | |
| 14:12:05 | jaypipes | alex_xu: ack | |
| 14:27:37 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Exclude build request marker from server listing https://review.openstack.org/626585 | |
| 14:30:59 | rui-zang | jaypipes, I just replied in the pmem spec on why "block mode" is not recommended | |
| 14:32:32 | rui-zang | If you still have concerns or I do not express it clearly, I am here :) | |
| 14:33:26 | alex_xu | rui-zang: being here whole night :) | |
| 14:33:54 | rui-zang | alex_xu, ->< only have a battery less than 2 hours | |
| 14:41:24 | maciejjozefczyk | jaypipes: ok, found what's wrong with gates :) | |
| 14:48:27 | HW-Peter | hey | |
| 14:48:41 | HW-Peter | Is there any documentation for setting up a Multi Cell CellsV2 Environment | |
| 14:49:16 | HW-Peter | Were running around 500 nodes per location, and are wanting to create a 2nd cell to help with scale | |
| 14:50:06 | HW-Peter | The amount of cells v1/v2 overlap in current documentation makes it difficult to see if the information presented relates to cells v1 or cellsv2 | |
| 14:50:12 | HW-Peter | The amount of cells v1/v2 overlap in current documentation makes it difficult to see if the information presented relates to cellsv1 or cellsv2 | |
| 14:54:33 | mriedem | HW-Peter: i'm assuming you've seen https://docs.openstack.org/nova/latest/user/cells.html and https://docs.openstack.org/nova/latest/user/cellsv2-layout.html ? | |
| 14:54:54 | mriedem | https://docs.openstack.org/nova/latest/user/cells.html#adding-a-new-cell-to-an-existing-deployment | |
| 14:55:56 | mriedem | HW-Peter: you setup the new db and mq for the new cell and then create the cell mapping pointing at the new db/mq | |
| 14:56:17 | mriedem | new computes in that cell will be configured to point at that cell mq/db | |
| 14:56:29 | mriedem | and then you run discover_hosts to populate the new cell db with the compute_nodes records | |
| 14:57:10 | mriedem | if you're trying to shard an existing db to a new cell, that is a bit harder | |
| 14:57:49 | mriedem | "The amount of cells v1/v2 overlap in current documentation" - if you can point me at what you're referring to i can see if the docs can be made more clear | |
| 14:57:59 | mriedem | i know the ops guide is way out of date | |
| 14:58:35 | dansmith | We probably should be removing cellsv1 words across the board anyway | |
| 15:00:48 | mriedem | i had reorganized the bug user/cells.html doc at one point to move the cells v1 stuff to the bottom so it's not the first thing you see, but abandoned it | |
| 15:00:57 | mriedem | *big | |
| 15:01:11 | dansmith | ack | |
| 15:01:18 | dansmith | we should just remove it I think | |
| 15:01:28 | dpawlik | mriedem: Hi, I reply you https://review.openstack.org/#/c/628128/ . If you have time please check :) | |
| 15:03:03 | mriedem | dpawlik: replied | |
| 15:03:19 | mriedem | dansmith: yeah, could - if a cells v1 user needs it to upgrade they can get the rocky docs | |
| 15:03:42 | dpawlik | mriedem: how fast. Thanks | |
| 15:03:45 | dansmith | yeah I mean, we're not going to be able to support upgrade forever, so I think just removing the docs about that probably helps to make it clear | |
| 15:05:06 | mriedem | when can we just drop cells v1 again? | |
| 15:05:16 | mriedem | i don't see any specific mention of it in the stein ptg etherpad | |
| 15:06:20 | mriedem | rocky ptg etherpad says we'd drop nova-net before cells v1, | |
| 15:06:37 | mriedem | but stein ptg etherpad says we can't drop nova-net until cells v1 since nova-net only runs if cells v1 is enabled :/ | |
| 15:06:51 | dansmith | well, I think we lost steam because (a) removing n-net is hard and (b) cern is still using n-net | |
| 15:07:28 | dpawlik | mriedem: I can listen in my CI job which tox env should be executed, but if I am alone with that problem, we don;'t need to backport the patch. | |
| 15:07:33 | mriedem | surely cern just comments out this line for nova-net: https://github.com/openstack/nova/blob/master/nova/cmd/network.py#L43 | |
| 15:07:57 | dansmith | mriedem: that's what they're doing, yes.. I mean if we remove it more than that, it'll be an issue | |
| 15:08:12 | mriedem | yeah i know the service itself | |
| 15:08:52 | mriedem | sorrison is on pike now i think he said | |
| 15:08:59 | mriedem | godaddy is... ? | |
| 15:09:02 | dansmith | they were neutron anyway | |
| 15:10:07 | mriedem | yeah just wondering if/when/why we can't remove cells v1 | |
| 15:13:28 | mriedem | anywho, we moved the job to experimental queue, maybe next step is dropping docs, and just continue to whittle away at removing it | |
| 15:13:37 | mriedem | make it less discoverable | |
| 15:16:16 | openstack | Launchpad bug 1804253 in openstack-manuals "Capacity planning and scaling in Operations Guide - cells information is out of date" [Undecided,Confirmed] - Assigned to lei zhang (zhang-lei) | |
| 15:16:16 | mriedem | guess i can take a shot at https://bugs.launchpad.net/openstack-manuals/+bug/1804253 | |