Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-20
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
15:29:25 mriedem for rebuidl
15:29:26 mriedem *rebuild
15:29:51 mriedem w/o introducing the change that changing the image makes the api fail
15:30:03 mriedem it's a subtle difference
15:30:29 cfriesen mriedem: right...so are you basically proposing breaking up 520660 into a number of commits?
15:31:00 mriedem i already broke 520660 into 2 changes, but 520660 could also be broken into 2 more changes if we wanted
15:31:11 mriedem where the final change in the series is the new behavior to fail fast if the image is changing on a volume-backed instance
15:31:47 efried There goes mriedem, breaking stuff again.
15:32:03 alex_xu efried: which bug you want me help to debug? I see there is a mention in the scheduler meeting
15:32:26 efried alex_xu The crossing-aggregates thing
15:34:03 alex_xu efried: ah, i see, there are some testcase you/gibi added
15:34:18 efried alex_xu Yes, all part of the pile :)
15:34:40 cfriesen mriedem: the thing that's confusing me is that 521391 is still included in 520660
15:34:49 alex_xu efried: I will try, but I'm in the travel from tomorrow.
15:35:03 cfriesen oh, wait, I see....you're just adding the else clause
15:35:15 efried alex_xu No worries. It's probably something jaypipes should be looking at too/instead.
15:36:25 jaypipes wait, I thought the scheduler meeting was in 25 minutes? :( daylight savings and all that...
15:37:13 efried jaypipes Wrong direction. It was 1.5h ago.
15:37:16 efried DST is stupid.
15:37:28 jaypipes oh ffs... sorry :(
15:37:45 efried jaypipes http://eavesdrop.openstack.org/meetings/nova_scheduler/2017/nova_scheduler.2017-11-20-14.00.log.html
15:37:56 jaypipes danke
15:38:23 openstackgerrit Elod Illes proposed openstack/nova master: Deduplicate keypair notification samples https://review.openstack.org/521562

Earlier   Later