Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-19
15:56:22 sean-k-mooney dansmith: yes i suggested splitting it into 3 specs a while ago
15:56:33 dansmith L324 specifically
15:56:54 dansmith sean-k-mooney: even if it gets split, those definitions don't belong in one of our specs, IMHO
15:57:57 sean-k-mooney am i highlevel discription of the os-acc that nova will consume would be nice but the cyborg apis dont need to be in the spec for sure
15:58:29 sean-k-mooney i would like to know the data structure that are passed the the fuction that should be called at diffrent point by nova but the internal can live in cyborg specs
15:59:19 dansmith sean-k-mooney: the data structures are fine, but you asked him to add more api signatures where I asked him to completely remove them
15:59:25 sean-k-mooney dansmith: i think the os-vif spec got it about right https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/os-vif-library.html
15:59:27 dansmith which is why we need to converge so he knows what to do
15:59:51 jaypipes sean-k-mooney: I think I was pretty clear in Denver and elsewhere that I think the Cyborg team first needs to have some workable low-level device plumbing library (what I *thought* os-acc was supposed to be) before Nova even becomes part of the conversation. I view os-acc as very similar to os-vif, and I'm disappointed that there is even discussion about REST APIs or anything like that instead of designing an easy to use, hard-to-abuse low-level
15:59:51 jaypipes device plugging lib.
16:00:25 sean-k-mooney dansmith: well that was because he was documenting the api and did not discribe the device profile enpoint
16:00:38 sean-k-mooney so either remove the api enpoitn entirely which im fine with or include that one
16:00:52 sean-k-mooney jaypipes: yes i agree with that
16:00:55 jaypipes sean-k-mooney: totally unnecessary at this point, IMHO.
16:01:03 jaypipes sean-k-mooney: (the REST API or anything like that)
16:01:29 sean-k-mooney jaypipes: ya so let ask for all the cyborg rest apis to be removed and state it will be handeled by os-acc
16:01:32 dansmith jaypipes: can you comment on the spec (L324ish)? I've already voiced there and so another "remove all this" would be good..
16:01:43 jaypipes sean-k-mooney: the path to success with Cyborg is to mimick os-vif, not Mogan.
16:01:54 sean-k-mooney jaypipes: yes i agree
16:02:04 sean-k-mooney jaypipes: anyway i need to jump on a call
16:02:08 jaypipes dansmith: ok. I've already made a number of those comments but will do so again
16:02:30 dansmith jaypipes: I know, and I appreciate it.. L324 is where there was a conflicting "Do X" and "Don't do X"
16:02:41 sean-k-mooney dansmith: jaypipes feel free to link to this irc convo or just state im +1 on removing the api enpoint too
16:02:45 jaypipes dansmith: ack
16:02:49 dansmith jaypipes: and sundar expressed confusion there, so..
16:03:42 cdent I spoke with sundar briefly in berlin and he felt like he was getting different messages from jaypipes and dansmith. Both efried and I suggested he show up here to be a part of these discussions if/when he had a chance.
16:08:24 dansmith cdent: I imagine you mean between me and sean-k-mooney or jaypipes and sean-k-mooney
16:08:35 dansmith he didn't even acknowledge my comments on the spec,
16:08:41 cdent dansmith: I don't.
16:08:46 dansmith and jaypipes and I didn't comment on most of the same lines
16:09:07 cdent I'm reporting merely on what sundar said to me, not what's happening on the spec
16:09:23 cdent The only attention I've given to the spec is to point out where the proposed API is not right
16:20:59 mriedem and i haven't looked at it at all
16:21:14 mriedem i'm kind of waiting for ^ to settle before digging into it
16:39:34 jaypipes mriedem: the nova-cyborg thing?
16:40:35 mriedem ye
16:40:37 mriedem *yes
16:51:40 sean-k-mooney cdent: there were some mixed messages from me vs dan and jay. i wanted them to either document everything or drop the api stuff. dan wanted the api stuff remvoed and i think jay agreed
16:52:18 sean-k-mooney cdent: i was fine with removing the cyborg api stuff which sundar may not have picked up on but i dislike have only some of the enpoints int he spec
16:53:25 sean-k-mooney i think dansmith jaypipes and i all agree we would like to see the integration follow the os-vif and os-bricks model where os-acc become the nova integration point
16:53:26 cdent sean-k-mooney: I said to him that it would be easier to evaluate the API if it were all in one place
16:53:43 cdent And if the API isn't needed at this stage, then cool
16:54:00 cdent I was simply trying to help him navigate what has proven to be a strenuous process
16:54:02 sean-k-mooney cdent: that is true but the one place could be a cyborg spec that we provide input into yes?
16:55:39 cdent yes, if the one place were to happen, then in cyborg would be the place
16:58:00 efried problem there being that they've had very little input on the cyborg specs from outside the cyborg team.
16:58:40 efried I think it may have been on my recommendation (which was for that reason ^) that Sundar put this one into nova-specs.
16:59:03 dansmith there really shouldn't need to be a lot of input from us on cyborg APIs I don't think
16:59:18 dansmith if we keep the discussion on the nova side to the workflow and interaction with the library,
16:59:20 sean-k-mooney efried: well you and i have both left quite a lot of feedback at different times but i dont think alot of it has been incorperated. some definetly has but we have had the same converstaton several times
16:59:31 dansmith the server-side stuff should be discernible from that I think
16:59:49 dansmith sean-k-mooney: yeah, definitely feel like we've gone in circles a lot on this, approaching exhaustion
17:01:01 openstackgerrit Elod Illes proposed openstack/nova master: Transform scheduler.select_destinations notification https://review.openstack.org/508506
17:10:11 jaypipes jangutter: I really like the "before and after" sections in https://review.openstack.org/#/c/607610/3/specs/stein/approved/generic-os-vif-offloads.rst (e.g. lines 133-177). makes it much easier to see how the changes affect things. ++
17:25:13 sean-k-mooney jaypipes: dansmith i responded on the cyborg spec to say please remove the cyborg api section.
17:25:45 sean-k-mooney jaypipes: dansmith also do we all agree the indirect usecase where the acclerator is not attach to the vm should not be in the spec?
17:26:35 jaypipes sean-k-mooney: I just finished up with jangutter's spec on os-vif object model changes. adding some comments to the cyborg spec now...
17:26:47 sean-k-mooney my understanding is that the instance will not be the consumer of the devices in placement and since they are not attach to the nova instance nova should not care
17:27:05 cdent efried: we (you?) need to come up with a plan for replacing the tests that use rp_object as added in https://review.openstack.org/#/c/560444/
17:27:16 sean-k-mooney jaypipes: oh ya i need to go back to that one
17:28:23 sean-k-mooney jaypipes: am one point i made on the code which is not in the spec is we should not use the term datapath offlod since the representor netdev is actull part of the control plane.
17:30:47 jaypipes sean-k-mooney: I said on the spec that I think "OffloadBase" is fine and removing "Datapath" would be good.
17:31:55 sean-k-mooney i realise when i clicked the link i have only looked at the code for this so im currently readign the spec for the first tiem
17:35:01 sean-k-mooney jaypipes: if you have not seen it can you reivew this comment on the code to see if you agree https://review.openstack.org/#/c/572081/9/os_vif/objects/vif.py@376 i will see how that relates to the spec
17:41:20 efried cdent: That should be easy peasy. Did you want me to do that in nova, placement, or both?
17:41:34 cdent efried: it only exists in nova
17:41:40 efried stand by.
17:44:29 openstackgerrit Merged openstack/nova stable/rocky: Handle unicode characters in migration params https://review.openstack.org/618734
17:51:34 openstackgerrit Eric Fried proposed openstack/nova master: Nix refs to ResourceProvider obj from libvirt UT https://review.openstack.org/618786
17:51:35 efried cdent: There ya go ^
17:51:41 cdent rad
17:52:16 cdent thanks
17:52:21 efried There's more refactoring that could be done there, but this is roughly the easiest.
17:52:25 efried without being too hacky
17:54:02 efried cdent: BTW, pretty sure the origin of the test code was bhagyashris. This doesn't look like my style at all.
17:54:34 cdent efried: noted. I just went by git blame when raising the "alarm`'
17:54:47 efried yup, and she's not around atm anyway. Easy enough fix.
18:01:04 efried jaypipes, mriedem, bauzas: ----^ easy one
18:07:35 openstackgerrit Chris Dent proposed openstack/nova master: Use external placement in functional tests https://review.openstack.org/617941
18:07:36 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Delete the placement code https://review.openstack.org/618215
18:08:51 cdent feh, that's not going to work after a merge
18:48:54 larsks Hey folks. Should disk-related instance resource quotas (such as quota:disk_write_bytes_sec) be applied when booting from a volume?
19:21:53 cfriesen larsks: I think it's supposed to be applied, at least for libvirt/qemu.
19:26:59 sean-k-mooney cfriesen: yes it is but i just tested with devstack and it does not work on master
19:27:43 sean-k-mooney cfriesen: larsks moved to public pastbin http://paste.openstack.org/show/735692/
19:28:33 sean-k-mooney im link 95% sure this used to work
19:28:36 cfriesen sean-k-mooney: I think it's "quota:write_bytes_sec"
19:29:05 cfriesen no, that webpage was wrong
19:29:12 sean-k-mooney quota:disk_write_bytes_sec is what horizon set
19:30:16 sean-k-mooney ill set all the limits and see what hapes perhaps its just that one. i think this works with the ceph backend but maybe for boot form volume you have to use cinder qos
19:34:20 sean-k-mooney cfriesen: larsks nope still ignored http://paste.openstack.org/show/735693/
19:40:09 openstackgerrit Jack Ding proposed openstack/nova master: Add HPET timer support for x86 guests https://review.openstack.org/605902
19:46:08 larsks cfriesen: thanks, and sean-k-mooney thanks for checking. What I'm curious about is whether or not that is expected behavior...
19:46:17 larsks I.e., should I open a bug for this?
19:46:25 sean-k-mooney larsks: it is expect to work and yes
19:46:38 larsks Ack, I'll do that right now, then.
19:47:02 sean-k-mooney but we also advise peole not to use falvor qouta any more even though we have not deprecated them offically
19:47:24 larsks Oh, that's news. Why is that?
19:47:49 sean-k-mooney because cinder and neutron both have there own qos apis which are richer and better tested
19:48:38 larsks Okay. Being able to associate a collection disk/network/etc quotas with a flavor is very convenient.

Earlier   Later