| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-02 | |||
| 16:23:01 | mriedem | we don't go down the new conductor task route unless the scheduler picks a host in another cell | |
| 16:23:25 | mriedem | so for the more-like-resize option, i could create the db records early in the dest cell yet | |
| 16:23:28 | mriedem | *yeah | |
| 16:24:47 | dansmith | ah, right, right | |
| 16:24:57 | dansmith | I forgot that we don't do this unless the scheduler picks another cell | |
| 16:26:13 | mriedem | even with my shelve poc, i see that my early verify code won't work there either - because that's running code on the dest host in the dest cell | |
| 16:26:29 | mriedem | so likely either route is going to require creating the instance record and friends in the dest cell db early in the process | |
| 16:29:08 | mriedem | and then i likely have some split brain / db syncing that i need to do throughout which sucks but likely unavoidable | |
| 16:29:27 | dansmith | well, | |
| 16:29:47 | dansmith | didn't I say something about creating the instance in deleted state so we could avoid that? | |
| 16:30:07 | dansmith | I think you told me why that won't work, but I'm still paging this in | |
| 16:31:28 | mriedem | that's not really the sync issue i'm thinking of, i'm thinking of like, we create the record in the dest cell db, do the claim which creates the migration context, now if i need to sync that migration context back over to the source cell, i need to do that copy explicitly; likewise, if the source cell changes the task_state on the instance during the process (like resize does), then i might need to sync those changes back ove | |
| 16:31:29 | mriedem | the dest cell instance record as well | |
| 16:31:57 | dansmith | oh | |
| 16:32:29 | dansmith | yeah, I guess | |
| 16:49:07 | openstackgerrit | weizj proposed openstack/python-novaclient master: Update hacking version https://review.openstack.org/627726 | |
| 17:01:53 | melwitt | o/ | |
| 17:12:25 | mriedem | dansmith: so i think i'm going to spend some time today updating the spec because the more i work on the code, the more down the rabbit hole i go and likely won't have the spec ready by the time i'm out next week - so my plan is basically get some kind of high level agreement on the spec knowing there will be dragons during implementation, and then i'll be ferreting out those dragons | |
| 17:13:55 | mriedem | i think i at least know enough to know some pros/cons of the shelve vs more-like-resize flow to list those as well | |
| 17:14:00 | dansmith | okay | |
| 17:14:09 | dansmith | we really need to get more input on it than just me though | |
| 17:14:32 | mriedem | yeah mel and kevin left some feedback as well, and was in line with yours | |
| 17:14:41 | dansmith | oh, okay I hadn't looked yet | |
| 17:14:45 | mriedem | john is probably next best to review this given his prior experience | |
| 17:14:49 | dansmith | that makes me feel better | |
| 17:14:52 | dansmith | yeah | |
| 17:16:34 | dansmith | ah I see melwitt's comments were a little more anti-shelve than my waffling | |
| 17:16:50 | dansmith | so that makes what you were saying earlier make more sense | |
| 17:23:39 | melwitt | well, how I feel is I think it's hard to be definitive about shelve vs not, as both approaches have their cons, those were my initial impressions reading through. it doesn't seem like there's a great answer here and I expect us to go ahead with whichever approach mriedem thinks will be cleaner based on all of the work he's done | |
| 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 | |