Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-20
21:48:09 mriedem i'm not sure where "if we had the http service integrated into compute for the health check" came from
21:48:32 dansmith thinking of better ways to move bulk data between compute nodes than requiring ssh keys and allowing logins
21:48:44 dansmith because that _is_ totally nuts from a security perspective,
21:49:06 dansmith and fixing that with something more secure would be better than just adding a different path (regen) which only works in some cases anyway
21:49:55 dansmith such an approach would work for and fix the security holes in cold migration as well
21:50:26 mriedem well, it's essentially what i'm doing for cross-cell resize with glance
21:50:40 dansmith using glance as the intermediary, but yeah
21:50:59 mriedem noting now that your config drive will have to get rebuilt on the other side...
21:51:11 mriedem does config driver already get rebuilt on resize?
21:51:15 mriedem *drive
21:51:20 dansmith I thought it gets copied
21:51:34 dansmith along with the root disk
21:51:57 mriedem i'm not sure https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L8882
21:52:00 dansmith if we had this http endpoint, your cross-cell resize stuff could be much more like regular resize and not have to go through glance
21:52:34 dansmith mriedem: that doesn't run if it already exists
21:52:44 dansmith so yeah, maybe that means it's regen'd but if it's copied then it won't
21:53:03 dansmith https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3626
21:54:17 mriedem hmm yeah so i suppose disk.config gets copied here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L8811
21:55:39 mriedem huh, i guess that's something that needs to be at least documented for the cross-cell stuff as a limitation right now because it's not doing anything with the config drive, so it's going to get regenerated on the dest and you'd lose any personality files
21:56:40 dansmith you're welcome.
21:58:23 mriedem duly noted in my re-proposed spec https://review.openstack.org/#/c/642807/1
21:58:41 mriedem i don't know what the answer is, upload a snapshot of the disk.config to glance?
22:00:04 dansmith no the answer is implement an http server :D
22:03:38 cdent efried, mriedem : the gist of the problem is that you can register other opts multiple times, but not cli opts, and adding oslo_log.log.register_opts() to the common path brings CLI options into the scene of test_local_delete_removes_allocations_after_compute_restart, where config is registered multiple times (3 in fact)
22:04:11 cdent it only shows up in that test because we are doing some wildness with the PlacementFixture that doesn't happen anywhere else
22:04:27 cdent candidates for fixing it:
22:04:36 cdent 1. that revert, worry about it later
22:05:24 cdent 2. change that test to do things differently (hard because the reference to the in ram sqlite database needs to be maintained)
22:05:53 cdent 3. change the placement fixture (on the placement side) to take a flag to register or not register opts
22:06:17 cdent 3 is probably the best choice in the long run, and won't take me long to do
22:06:27 efried why does the placement fixture need to register opts ever?
22:06:45 cdent because it has to use opts in order to start placement
22:06:49 efried I guess when tests go after opts, the defaults need to be there.
22:06:51 efried and that
22:07:10 cdent unfortunately the way oslo_config works, it has to know about stuff
22:07:15 cdent (good and bads to that)
22:07:28 efried 3 today, or should we 1 to unblock and then 3?
22:07:54 cdent the mode the fixture has now is "don't make the caller think, if possible"
22:08:06 cdent I'm happy with just 3 if everyone else is
22:08:19 cdent but if you want to unblock quicker, then 1 and then 3
22:08:40 efried yeah, let's merge 1 and you can put 3 on top and include unrevert in it?
22:09:13 cdent I wanted to be able to find a version of 2, but that test is already so hairy I don't think it is worth
22:09:14 cdent sure
22:09:33 cdent feel free to push the revert through
22:10:03 efried cdent, mriedem, melwitt: fast-approved https://review.openstack.org/#/c/645014/
22:10:44 efried and then mriedem respun and did same, neat
22:10:51 mriedem i added the bug tag
22:11:06 efried yup, ++
22:12:58 openstackgerrit Eric Fried proposed openstack/nova master: DNM: Trying a different strategy for tests https://review.openstack.org/645026
22:19:57 melwitt efried: ack, thanks
22:25:45 mriedem well now i'm depressed and have a 2 hour call in 3 hours so it's time to leave
22:35:40 NobodyCam anyone have any pointers to stacking down instances stuck in scheduling .. I set nova* to debug mode and don't see any errors jumping out
22:36:26 NobodyCam s/stracking/tracking
22:36:39 openstackgerrit Chris Dent proposed openstack/nova master: Don't register placement opts mutiple times in a test https://review.openstack.org/645033
22:37:37 cdent mriedem_away, efried ^ that fixes the nova side and depends-on the placement side fix
22:39:02 NobodyCam I do see this in the compute log:
22:39:04 NobodyCam Instance 7d8f61e6-155c-47a9-9d35-95939b29d487 has been scheduled to this compute host, the scheduler has made an allocation against this compute node but the instance has yet to start. Skipping heal of allocation: {u'resources': {u'MEMORY_MB': 1024, u'VCPU': 1, u'DISK_GB': 20}}. _remove_deleted_instances_allocations /openstack/venvs/nova-18.1.5.dev5/lib/python2.7/site-packages/nova/compute/resource_tracker.py:1355
23:16:22 aspiers cdent: OK, now you are not just ahead of me but downright telepathic. I was about to report that placement issue...
23:17:00 cdent aspiers: which one?
23:17:17 aspiers the option registering
23:17:38 cdent that's mriedem_away's psychic powers not mine
23:18:49 aspiers OK, so you just fixed it :)
23:19:12 aspiers Either way it's nice when things get fixed even before I get a chance to report them
23:19:17 aspiers haha
23:20:17 cdent it's all smoke and mirrors. There's an openstack cabal where people like efried, mriedem_away, me place latent bugs into the code that we can then fix quickly, making ourselves appear heroic and super insightful
23:20:40 aspiers That's dastardly cunning
23:21:04 cdent the chaos that you see isn't figuring out the solution for the bug, it's figuring out which bug, of the many that we have caused, is being revealed this time
23:21:30 aspiers I'd hope our govt was doing the same, but alas they're not
23:21:38 cdent heh
23:22:04 cdent it's...shocking
23:22:40 aspiers damn right
23:32:34 mriedem efried: cdent: thanks got both
23:55:38 mriedem sorrison: if you can't make the next nova meeting, you could add https://bugs.launchpad.net/nova/+bug/1819568 to the open discussion agenda as a potential specless blueprint
23:55:39 openstack Launchpad bug 1819568 in OpenStack Compute (nova) "RFE: network_data.json doesn't contain information about floating IPs" [Wishlist,Opinion]
#openstack-nova - 2019-03-21
03:29:03 openstackgerrit Ghanshyam Mann proposed openstack/nova-specs master: Spec for API policy updates https://review.openstack.org/547850
03:29:54 openstackgerrit Ghanshyam Mann proposed openstack/nova-specs master: Spec for API policy updates https://review.openstack.org/547850
04:55:22 openstackgerrit Yongli He proposed openstack/nova master: Clean up orphan instances https://review.openstack.org/627765
05:15:05 openstackgerrit Merged openstack/python-novaclient stable/stein: Update .gitreview for stable/stein https://review.openstack.org/644181
05:15:05 openstackgerrit Merged openstack/python-novaclient stable/stein: Update UPPER_CONSTRAINTS_FILE for stable/stein https://review.openstack.org/644182
05:42:34 openstackgerrit Merged openstack/os-vif stable/stein: Update .gitreview for stable/stein https://review.openstack.org/644034
07:51:22 kashyap sean-k-mooney: Hi, just saw the ping in the scrollback; there's a lot of text. Hope klindgren's problem is resolved :-)
08:00:22 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable https://review.openstack.org/641981
08:00:23 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: vzstorage: Use 'writeback' QEMU cache mode https://review.openstack.org/643376
08:00:24 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: smbfs: Use 'writeback' QEMU cache mode https://review.openstack.org/643377
08:04:05 kashyap efried: When you get a moment, lost yours / SylvainB's +2s & +W; appreciate if you can re-ACK|NACK it.
08:39:48 kashyap bauzas: ^ When you get a moment :-)
08:40:17 kashyap (It already had +W, just lost the ACK due to rebase)
09:24:03 kashyap bauzas: Docs will be fixed in a separate change
09:24:12 kashyap To not let the core patch be blocked
09:24:15 bauzas cool with me then
09:24:25 kashyap bauzas: Please see the review comments :-) MattR and MattB both agreed on the change
09:24:35 kashyap That to let this merge, and I fix the rest of the documenation
09:24:39 bauzas just comment and say you'll add a fup
09:24:49 bauzas sorry, fup == follow-up change
09:24:52 kashyap Yeah, it's actually added
09:24:58 kashyap bauzas: Also at the end of the commit message I noted as such
09:25:10 kashyap [quote]
09:25:11 kashyap Do the minimum required update to the `disk_cachemodes` config help text. (In a future patch, rewrite the cache modes documentation to fix confusing fragments and outdated information.)
09:25:15 kashyap [/quote
09:27:15 bauzas kashyap: sure, but I still feel we need to document in the relnote why we now recommend writeback as default

Earlier   Later