Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-20
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
15:19:11 efried Good to know.
15:20:10 sean-k-mooney efried: e.g. i only have intel nic driver so when i state that in image metatdata via vendor ids and product ids and then request an sriov nic in neutron and nova would make sure it iwas an intel one
15:20:36 efried sean-k-mooney But that's now done via the whitelist, nah?
15:20:56 sean-k-mooney efried: no they are two different things
15:22:15 sean-k-mooney the whitelist is the operators way to say this is what i will allow to be passed through . in the neutron sriov case it will be resticted to that list, but this was a way to allow tenants to say i only budeled x drives in my image so limit to those vedors
15:22:42 efried sean-k-mooney That makes sense. But you say that never got implemented?
15:23:10 openstackgerrit Andreas Jaeger proposed openstack/nova master: DNM - test updated releasenotes job https://review.openstack.org/520677
15:23:57 sean-k-mooney correct there was also a counter proposal for it to be supported as an atribute on the neutron port when you set vnic type direct via the port binding profile but neither were impleneted in the end
15:24:11 cfriesen mriedem: what's your plan for https://review.openstack.org/#/c/521200/ vs https://review.openstack.org/#/c/520660 ? Are you looking to break it up into a number of smaller commits?
15:26:32 mriedem cfriesen: do you mean because of this? https://review.openstack.org/#/c/520660/5/nova/compute/api.py@2954
15:27:51 mriedem cfriesen: as i see it, https://review.openstack.org/#/c/520660/ is really fixing 2 things, (1) rebuilding a volume-backed server changes the instance.image_ref from '' to $image_id, and (2) rebuilding a volume-backed server with a different image from what's in the root volume doesn't fail in the api
15:28:23 mriedem thinking about backports, i think backporting the fix for (1) is an easier case than (2)
15:28:29 cfriesen mriedem: whoops, I meant https://review.openstack.org/#/c/521391....which seems to be the same as 520660
15:28:56 mriedem it's not the same
15:29:19 mriedem https://review.openstack.org/#/c/521391/ fixes the bug where any volume-backed server, regardless of the image being different or not, sends the instance through the scheduler

Earlier   Later