Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-20
14:13:19 sean-k-mooney stephenfin: just taking a look now
14:13:56 sean-k-mooney ah the printable mixin
14:14:19 stephenfin bauzas: This one's another easy +W, IMO https://review.openstack.org/#/c/466051/
14:15:32 bauzas stephenfin: ack
14:16:46 stephenfin cdent: Seen this? https://review.openstack.org/#/c/511936/ Are we expecting to have a python-placementclient library?
14:17:36 cdent there’s going to be an osc plugin, but no plans for a specific client
14:17:56 cdent in large part because it’s “just json”
14:18:49 cdent stephenfin: https://review.openstack.org/#/q/topic:bp/placement-osc-plugin+(status:open+OR+status:merged)
14:19:45 efried cdent I would be in favor of a client lib that performs useful API calls, like SchedulerReportClient does, and parlays "just json" into useful python objects, like ProviderTree.
14:20:22 cdent I was really hoping we’d keep ProviderTree hidden in the bowels of nova and not make that a thing that people commonly want to use...
14:20:52 cdent But if that’s not the case, then sure, I guess. The deal simply was that until multiple implementations with commonanilities showed up, why bother?
14:21:07 efried It doesn't have to be ProviderTree itself, but in that vein.
14:21:38 openstackgerrit Merged openstack/os-vif master: Add VersionedObjectPrintable mixin https://review.openstack.org/493082
14:21:49 efried cdent Oh, I can answer that one: so that we don't have multiple implementations with commonalities show up, which we then have to reconcile and consolidate.
14:22:14 cdent sigh
14:22:37 cdent reconciliation and consilidation is a _good_ thing. it allows for compare and contrast amongst a variety of thoughts
14:22:41 cdent rather than imposing a single vision
14:23:18 efried But then you wind up with things you can't get rid of because momentum.
14:23:38 cdent The way nova chooses to do things internal to the report client isn’t necessarily right for the rest of the world and vice versa
14:23:56 cdent and if you can’t just use requests for the API when we may as well give up and go home because we’ve failed
14:24:30 efried cdent This is interesting in light of some of the work I did last week. Let's chat after the meeting.
14:25:16 cdent (or at least by 3)
14:25:30 efried cdent Okay, well, if you get a chance, have a look at this: https://review.openstack.org/#/c/521098/4/nova/scheduler/client/report.py
14:26:34 efried A non-trivial method to collate all the information about a group of providers. Call it ProviderTree or whatever, IMO it's conceivably a useful thing to be able to do for any client.
14:27:12 cdent In idealized world mode, the fact that we need a provider tree (or whatever) is a reason to go home
14:27:19 cdent so now isn’t the best time for me to think about that...
14:27:52 cdent if we make it a habit that anything beyond a compute-node/hypervisor needs to know that stuff all the puppies will cry
14:30:12 sean-k-mooney stephenfin: can you take a look at this https://review.openstack.org/#/c/520788/1
14:32:31 openstackgerrit Andrey Kurilin proposed openstack/python-novaclient master: [ci] Use pseudo-random names for new resources https://review.openstack.org/479777
14:33:21 stephenfin sean-k-mooney: I agree with AJaeger there: Sphinx doesn't require you to set the version number and it wouldn't make semantic sense for release notes anyway
14:33:52 sean-k-mooney stephenfin: well i was just about to respond mail thread
14:34:03 stephenfin sean-k-mooney: pbr also overrides the project name and version if built with 'build_sphinx'. I'm not sure if we're using that here but it's probably worth mentioning
14:34:20 stephenfin Cool. I'll hold off on merging so
14:34:34 sean-k-mooney stephenfin: i why are release nots not considerd to be versiond. they are written from the perspective of the release in which they are added
14:34:58 sean-k-mooney i do agree that ideally we should not need to install the projects
14:35:21 stephenfin sean-k-mooney: Because of how they're distributed. At the moment, we don't distribute them at all
14:35:36 sean-k-mooney but i think we have bigger issue if i cant look at just the ocata release nots without seeing the pike release nots if i am upgrading to ocata
14:36:13 stephenfin We "distribute" them only online, via docs.o.o (or is it release.o.o?)
14:39:16 stephenfin sean-k-mooney: As for locally, distribution is via an sdist but you can't currently build release notes from this because you don't have the metadata necessary
14:39:22 stephenfin (because it's not a git repo)
14:40:01 stephenfin reno can export this metadata to a file, but we haven't done this historically. This is changing in the next MAJOR version of pbr, thankfully https://review.openstack.org/#/c/475034/
14:40:47 stephenfin sean-k-mooney: Also, RE: " i think we have bigger issue if i cant look at just the ocata release nots without seeing the pike release nots if i am upgrading to ocata"
14:40:53 stephenfin Isn't this what you want? https://docs.openstack.org/releasenotes/nova/ocata.html
14:42:11 sean-k-mooney stephenfin: yes :) it is. the commit message as written however implies that there is no versioning of release notes at all.
14:42:32 stephenfin sean-k-mooney: Ahh, no no
14:43:06 stephenfin What he's saying is that there'll be no version number provided to Sphinx, because it's no necessary
14:43:17 sean-k-mooney that fine then ill remove my -1 i was fine with the change as long as we could still view it per release
14:44:34 stephenfin Actually, sorry, what he _really_ meant was that version notes are versioned like everything else. E.g. we just have '/releasenotes/{project}' instead of '{series}/releasenotes/{project}'
14:44:41 stephenfin Either way, you have what you want :)
14:45:08 stephenfin bauzas: albeit...?
14:45:56 sean-k-mooney stephenfin: see this is why i ping you on docs changes so i can learn somthing new :)
14:46:35 bauzas stephenfin: oh dammit
14:46:41 bauzas albeit = although
14:47:13 bauzas I thought it was something like "all be it" which sounds to me like "ok, fine, accepted."
14:47:48 stephenfin sean-k-mooney: Anytime, buddy :D
14:48:29 stephenfin bauzas: Not quite, heh. It's pronounced al-bait (like, bait a fish)
14:49:45 dansmith stephenfin: here it's pronounced "all be it"
14:50:26 stephenfin dansmith: Please, haven't you ruined our language enough?
14:50:32 dansmith stephenfin: yeah, sorry about that
14:50:34 sean-k-mooney :)
14:52:44 openstackgerrit Elod Illes proposed openstack/nova master: Functional test: cold migrate to compute down https://review.openstack.org/496280
14:53:49 dansmith mriedem: I responded to your comments on that patch
14:54:06 dansmith mriedem: I have an errand to run in about 30 minutes and then can push up another rev
14:55:45 mriedem dansmith: ack
14:56:08 mriedem efried: if you want an easy docs improvement, we should put something in the top of the placement api-ref about the microversion header to use for placement https://developer.openstack.org/api-ref/placement/#placement-api
14:56:42 efried bauzas French has the elegant 'soit'. If that's what you're going for, in English, "So be it" is probably closest.
14:57:00 bauzas efried: ah you're right
14:57:37 openstackgerrit Merged openstack/os-vif master: Remove setting of version/release from releasenotes https://review.openstack.org/520788
14:57:41 efried mriedem Noted, I'll look into that.
14:58:30 efried bauzas If you want something more imperative, that Star Trek fans will appreciate, use "Make it so" (optionally addressing your audience as "number one")
14:59:30 dansmith heh
15:00:25 bauzas efried: I personnally use "dont acte", in case it rings you a bell
15:02:38 efried bauzas TIL. Celui-çi https://fr.wiktionary.org/wiki/dont_acte ?
15:04:26 mriedem stephenfin: for the PciPassthroughFilter,
15:04:32 mriedem do the pci requests only come through flavor extra specs?
15:04:38 mriedem or can they also come through image metadata?
15:05:01 bauzas efried: yup
15:05:22 bauzas acknowledged sounds the most appropriate
15:05:36 bauzas but it sounds less harsh in English than it sounds in French
15:05:42 bauzas anyway
15:05:49 bauzas we should open a new chan
15:06:04 efried #openstack-linguistic-nerdiness
15:07:03 bauzas efried: I was more thinking of a general #openstack-schmooze
15:07:27 efried bauzas Ironically, if you say "dont acte", it sounds like you're saying "don't act" in English, which is almost the opposite.
15:09:30 efried (By the way, you should not google "don't act")
15:10:26 bauzas efried: "eventually" is the most interesting false friend I know of
15:11:34 bauzas efried: 'éventuellement' means "maybe" in our language
15:12:30 efried bauzas How is that different from "peut-être"?
15:12:44 bauzas that's a synonym
15:13:45 efried bauzas Google translate doesn't agree, which I'm sure leads to lots of humorous exchanges: https://translate.google.com/#fr/en/%C3%A9ventuellement
15:14:54 efried bauzas In Spanish/Porguguese, "indroducir" means "insert", not "introduce". So people wind up saying, "Allow me to insert myself".
15:15:14 stephenfin mriedem: iirc, it's only for extra specs
15:15:49 efried stephenfin At least according to the docs, there's no affordance for PCI requests via image metadata. I'm like 80% sure.
15:16:56 stephenfin mriedem, efried: https://github.com/openstack/nova/blob/6535abdaaa73d92ebe9101626cc3f5b11117a194/nova/compute/api.py#L825-L834
15:17:19 sean-k-mooney you can request pci device using the alias in the flavor our via the vnic type on a neutorn port in the case of sriov nics
15:17:43 efried stephenfin sean-k-mooney Yup, that all gels with what I believed to be true.
15:17:49 efried (phew)
15:18:34 openstackgerrit Merged openstack/nova master: Fix docstring for GET /os-migrations and related DB API https://review.openstack.org/520200
15:18:40 openstackgerrit Merged openstack/nova master: api-ref: make a note about os:scheduler_hints being a top-level key https://review.openstack.org/519717
15:19:00 sean-k-mooney efried: i do belive that some peole wante to be able to restrict the type of sriov device that could be passthough via the image metadata at some point but i dont think that ever went anywhere

Earlier   Later