Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-26
15:33:16 stephenfin Maybe ask on #openstack-requirements. If not, I don't mind. I assume you can't just install it on your system?
15:33:40 cfriesen sean-k-mooney: the TPM code should be ready to take for a spin (without cold migration, hoping to do that today)
15:34:03 sean-k-mooney i can but im writing up some dev docs on how to set up vs-code for development of os-vif
15:34:34 cfriesen sean-k-mooney: no worries. you'll likely need a new os-traits release.
15:34:45 sean-k-mooney stephenfin: for not i can just add a note to pip install it.
15:35:25 stephenfin sean-k-mooney: Yeah, it does feel like something that would be better off installed systemwide (like tox)
15:35:52 sean-k-mooney not really
15:36:22 sean-k-mooney you could but i try to avoid poluting my system with lots of random packages.
15:36:35 sean-k-mooney its nicer to have it in the tox venv but its minor
15:37:29 cfriesen incidentally, I've uploaded a new version of the flavor/image validation patch addressing alex_xu's comments. Would appreciate review as it's on a runway.
15:43:15 mriedem apparently someone doesn't know how to count https://etherpad.openstack.org/p/nova-runways-stein
15:48:21 cfriesen mriedem: I'm talking about the top one in that list, with "jackding" associated with it.
15:50:07 mriedem yeah the show topology one was added to the current runways, i fixed it
15:51:32 cfriesen ah, okay. I couldn't figure out what the problem was. :)
16:12:05 sean-k-mooney stephenfin: actully auto build is not needed.
16:12:47 sean-k-mooney well it is if you are using sphix specifc stuff
16:15:39 openstackgerrit Balazs Gibizer proposed openstack/nova master: Fup for the bandwidth series https://review.openstack.org/639159
16:17:26 gibi mriedem, jaypipes, efried: fixed the comments from the already merged patches ^^
16:19:02 mriedem gibi: ok, did you see my comments on https://review.openstack.org/#/c/622421/ ?
16:19:12 mriedem there were a lot but it's a big patch
16:19:40 gibi mriedem: that is my next patch to look at
16:20:10 gibi mriedem: do you want me to split out the report client change from https://review.openstack.org/#/c/622421/ ?
16:22:27 mriedem gibi: up to you
16:22:34 mriedem it might help move things along faster
16:24:16 gibi mriedem: OK I will do it
16:29:06 gibi mriedem: regarding leaking the port allocation if a port is detached in neutron
16:29:30 gibi mriedem: is this a valid case that nova binds a port in neutron then the admin unbind it in the neturon API?
16:29:45 gibi mriedem: I thought that if the nova bound it the nova needs to unbound it
16:30:21 gibi mriedem: I can start looking at what to do when extrenal event comes if this is a valid use case
16:32:08 mriedem gibi: neutron does not prevent it
16:32:11 mriedem like cinder does
16:32:56 mriedem i don't know how common that could be so i'd be ok with a todo for now to deal with it later. i assume it would only ever happen because something broke and an admin was fumbling around trying to fix things.
16:34:29 gibi mriedem: OK, then I will add a TODO.
16:34:36 openstackgerrit sean mooney proposed openstack/os-vif master: modify functional base.py to allow using vscode https://review.openstack.org/638058
16:36:17 mriedem i have no idea if neutron has policy rules in place to only allow certain users to update a port's device_id
16:36:28 mriedem i know port binding attributes require admin
16:37:09 gibi mriedem: I will check with the neutron guys in my team
16:40:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Improve CinderFixtureNewAttachFlow https://review.openstack.org/639382
16:40:43 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Fix the leak in the cross-cell revert resize code https://review.openstack.org/638314
16:45:52 openstackgerrit Merged openstack/os-vif master: docs: Add API docs for profile, datapath offload types https://review.openstack.org/638395
16:52:58 sean-k-mooney jaypipes: stephenfin im planning on working on working on some os-vif gate jobs after stien feature freeze. would you object to me skipping the tempest jobs in os-vif if the change is only affecting the docs directory.
16:54:17 sean-k-mooney the other tox jobs are quick but if it is a docs only change ore release not only change tempest adds little vlaue
16:55:46 stephenfin fine by me
17:04:17 openstackgerrit Ghanshyam Mann proposed openstack/nova stable/pike: DNM: For testing only https://review.openstack.org/620592
17:06:58 openstackgerrit melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324
17:06:58 openstackgerrit melanie witt proposed openstack/nova master: WIP Count instances from mappings and cores/ram from placement https://review.openstack.org/638073
17:10:44 gibi mriedem: fyi. If I delete a bound port then nova gets notification from neutron, but If I just update the device_id and device_owner field of the port then nova does not get notification
17:16:26 openstackgerrit Merged openstack/nova master: Dump config options on wsgi startup earlier https://review.openstack.org/638691
17:21:33 openstackgerrit Chris Dent proposed openstack/nova master: Correct lower-constraints.txt and the related tox job https://review.openstack.org/622972
17:26:03 jaypipes sean-k-mooney: +1 to skip func tests if change in docs dir
17:33:47 mriedem gibi: hmm ok so i guess we have to handle the network-vif-deleted event right?
17:36:06 openstackgerrit Merged openstack/nova master: [Doc] Best practices for effectively tolerating down cells https://review.openstack.org/638173
17:37:51 openstackgerrit Artom Lifshitz proposed openstack/nova master: [Broken WIP] Split external events handling into 2 steps https://review.openstack.org/639396
17:48:04 artom dansmith, so, you've just made me have an epiphany
17:48:26 artom I thought the claims would provide extra checking that the instance will fit
17:48:32 artom But no, the scheduler already does that
17:48:45 artom If the scheduler accepted a host, the claim will work.
17:49:00 artom The problem is that we never updated the XML, not that we allowed unacceptable hosts
17:49:10 dansmith artom: no, that's not true
17:49:21 artom Unless the host was forced
17:49:25 sean-k-mooney well it does but only to the extent that it check that something else has not raced with you for resouce on that host
17:49:25 artom dansmith, no?
17:49:34 dansmith artom: the scheduler may send you four instances that it thinks will fit into the last slot
17:49:44 sean-k-mooney ya ^
17:49:52 artom Ah, that problem.
17:50:03 artom OK, so my original reply that I'm writing stands.
17:50:05 dansmith artom: since the scheduler does not reserve/lock/claim numa resources when it makes a decision, there's no context between decisions to make sure they don't overlap
17:50:07 artom Lemme finish it up.
17:50:29 artom Essentially, we need the claim to happen before driver.cclmad()
17:51:08 artom dansmith, ok, replies in https://review.openstack.org/#/c/634828/28
17:51:16 sean-k-mooney cclmad -> check_can_live_migrate_at_destination?
17:52:25 artom Yeah, at some point I need to shorten stuff
17:53:12 sean-k-mooney artom: just dont do tha in the code...
17:53:56 artom Hrmm, unless we do manager.cclmad() -> driver.cclmad() -> source.cclmas() -> put instance_numa_topology into migrate_data -> driver.cclmad() returns -> manager checks for presence of instance_numa_topology -> claims -> driver.new_method_that_returns_NUMAMIgrateData
17:54:35 dansmith artom: isn't that what I suggested?
17:54:51 artom dansmith, I hadn't groked that last new_method part
17:55:51 artom Then we'd have some instance live migrating with a claim and migration_context, and some without
17:55:55 artom Is that acceptable?
17:56:31 artom Or do we still do the claim regardless, and just call that new_NUMAMigrateData method conditionally?
17:57:25 dansmith well, I was going to ask somewhere else about this.. it's unfortunate to have a bunch of new hosts that don't do claims until all the hosts are upgraded and then you've migrated everything around one step to the left
17:57:43 dansmith but, obviously if you need the source to do the pin config in the xml, it's tough
17:58:24 dansmith but yeah, I think you always call the new method, and that method does the claim iff the source indicated during its pre-check that it's going to do the xml manip for you
17:58:43 dansmith instead of you doing it before you called to the host based on educated guessing
17:59:38 artom dansmith, ok, and that's a nicely elegant solution to the upgrades problem
17:59:49 dansmith s'mah point
18:00:08 artom You know, a gracious "thank you" would have been even better ;)
18:00:19 dansmith GAWD
18:00:40 artom Who do you think you are, Han Solo? With your "I know"s
18:00:41 artom :D
18:00:42 openstackgerrit Chris Friesen proposed openstack/nova master: Add emulated TPM support to Nova https://review.openstack.org/631363
18:01:15 dansmith I'm going to assume that is a very impressive deep reference that, if I got it, would be hilarious
18:01:40 artom I'm secure in my references and don't need no validation
18:01:47 artom (Unlike in my code)
18:02:08 dansmith heh
18:05:07 mriedem it's when leia tells han she loves him
18:05:08 mriedem duh
18:05:21 mriedem or wait, the other way around?
18:06:01 dansmith mriedem: so artom is leia and I'm solo? I'm okay with that I guess.
18:06:18 artom That backfired slightly
18:06:32 mriedem according to this tshirt, yes https://www.amazon.com/Star-Wars-Shirt-Medium-Heather/dp/B078Z1Z1BG/ref=asc_df_B078Z1Z1BG/?tag=hyprod-20&linkCode=df0&hvadid=319000730304&hvpos=1o1&hvnetw=g&hvrand=18017460218835467438&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1020048&hvtargid=pla-659942629837&psc=1

Earlier   Later