Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-02
13:24:29 alex_xu jaypipes: appreciate if you can take a look at the reply https://review.openstack.org/#/c/601596/4/specs/stein/approved/virtual-persistent-memory.rst@123, just want to ensure we express our thought clearly, I try to avoid coding the size into the RC name and standard the RC in the beginning. If that isn't a thing we care about, we are happy to move to the direction you suggestted.
13:46:02 cdent alex_xu: I'm sort of back, but struggling to get going. Happy New Year.
13:46:57 alex_xu cdent: ha, Happy New Year :)
14:02:56 jaypipes alex_xu: just recovering from vacation. will try to get to that ML post later this morning.
14:06:21 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Ensure rbd auth fallback uses matching credentials https://review.openstack.org/627010
14:47:26 jaypipes alex_xu: k, responded on the ML post.
15:02:31 efried o/
15:03:05 efried Did I miss anything?
15:18:51 openstackgerrit Dongcan Ye proposed openstack/nova master: Reword volume snapshot create https://review.openstack.org/623456
16:12:44 mriedem dansmith: re cross-cell resize poc v2 to be more aligned with normal resize flow, i've got a problem which i need confirmation,
16:13:06 mriedem i'm trying to do an early prep_resize type thing on the dest which will do the resize_claim which creates the migration context,
16:13:46 mriedem problem is, at that point, the instance records are only in the source cell db and the context is targeted to the source cell, even though i'm running this code on the dest host in the dest cell - but i don't think that will work because i recall that the targeting on the context is lost over rpc right?
16:14:05 mriedem so any db stuff on the dest host at that point will try to go to conductor in the dest and blow up b/c the instance doesn't exist in that db yet
16:15:07 mriedem it works in functional tests b/c of our CheatingSerializer fixture and the CellDatabase fixture defaults to cell1
16:15:08 dansmith well, yeah, the targeting is lost over RPC, but that's not really your problem -- it's that you can't do things in the target db for a given instance until the instance is created right?
16:15:55 dansmith you need the resize-like pre-claim because of non-normal resources like numa stuff?
16:16:19 dansmith because I think we should be trying to minimize our dependence on old-school claims like that
16:16:23 dansmith where possible of course
16:17:13 mriedem well, that and the resize_claim creates the migration context, which i'm still not really convinced i need yet - but i could create the migration context in conductor outside of the resize_claim code if i do need it
16:17:26 mriedem but yeah, trying to align more with the existing resize flow per spec feedback
16:17:38 dansmith yeah
16:17:54 mriedem this wasn't a problem in the shelve poc b/c i didn't touch the target cell until after i'd created the db records there
16:17:54 dansmith well, you can't create the migration context in condutor until the instance is created anyway right?
16:18:10 mriedem i can create the migration context in the source cell db if i need it
16:18:13 mriedem and then mirror it over
16:18:28 dansmith ah, sure
16:18:30 dansmith if that works
16:18:59 mriedem the problem with the shelve poc then is i'm waiting a long time to do any claims in the dest
16:19:21 mriedem i.e. after snapshot and shelving in the source
16:19:28 mriedem which could be a long time for a big root disk
16:19:47 dansmith yeah, and even if you claim resources in placement you may not have the numa/cpu resources you expect
16:20:42 dansmith I guess with shelve you delay scheduling super late altogether, but with the more-like-resize case, you can't really reserve all the resources you need until you have an instance created there
16:20:58 dansmith so in the latter case, you _could_ go ahead and create the instance in the cell db right?
16:21:29 dansmith also, I know it's been a while, but I don't think I said "we shouldn't do this will shelve" I just said "some of these attributes are not ideal" right?
16:22:41 mriedem regarding scheduling, that happens the same either way (shelve or more-like-resize)
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.

Earlier   Later