Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-01
21:41:43 jonher I would guess something like https://docs.openstack.org/nova/rocky/contributor/blueprints.html HW-Peter
#openstack-nova - 2019-01-02
02:39:41 openstackgerrit Jie Li proposed openstack/nova master: Add microversion 2.68 to support for volume-backed server rebuild https://review.openstack.org/627518
07:32:03 openstackgerrit Jie Li proposed openstack/nova master: Add compute version 37 to support volume backed server rebuild https://review.openstack.org/625893
07:50:10 openstackgerrit Jie Li proposed openstack/nova master: Add microversion 2.68 to support for volume-backed server rebuild https://review.openstack.org/627518
10:46:08 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Add workaround to cleanup instance dir when using rbd https://review.openstack.org/618478
10:53:08 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Add workaround to cleanup instance dir when using rbd https://review.openstack.org/618478
10:59:01 nehaalhat Hi, I am trying to run tox -e pep8 and getting below issue...is any one have some idea about this?
10:59:10 nehaalhat Could not find a version that satisfies the requirement kombu===4.2.2 (from -c https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt (line 442))
11:22:18 openstackgerrit Merged openstack/nova stable/rocky: Document using service user tokens for long running operations https://review.openstack.org/626578
11:31:12 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: libvirt: Add workaround to cleanup instance dir when using rbd https://review.openstack.org/627958
12:09:20 frickler nehaalhat: yes, this is a known issue, a fix to requirements is being merged. see https://review.openstack.org/627925
12:12:09 frickler also https://storyboard.openstack.org/#!/story/2004685
12:53:07 openstackgerrit Merged openstack/nova stable/rocky: Ensure rbd auth fallback uses matching credentials https://review.openstack.org/627009
12:53:12 openstackgerrit Merged openstack/nova stable/rocky: Fix a broken-link in nova doc https://review.openstack.org/626581
12:53:21 openstackgerrit Merged openstack/nova stable/rocky: Fix a broken-link in nova doc https://review.openstack.org/626580
12:53:26 openstackgerrit Merged openstack/nova stable/rocky: Fix an inaccurate link in nova doc https://review.openstack.org/626579
12:57:43 openstackgerrit Ifat Afek proposed openstack/nova master: The field instance_name was added to InstanceCreatePayload https://review.openstack.org/627967
12:59:47 openstackgerrit Merged openstack/nova stable/rocky: Exclude build request marker from server listing https://review.openstack.org/626584
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

Earlier   Later