Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-19
15:36:38 spatel_ oh!! got it.. what you saying..
15:36:58 spatel_ i was wrong about queuing logic...
15:37:20 mriedem tobias-urdin: there is no external REST API for changing things within the instance system_metadata,
15:37:27 spatel_ let me change my all instance to use all nproc
15:37:41 mriedem and what goes in there depends on the instance and operation, and manually messing with it is probably a bad idea given it's system data
15:38:04 mriedem tobias-urdin: so you'd have to be more specific about the incorrect sysmeta data that needs to be fixed
15:38:05 spatel_ sean-k-mooney: thanks again for saving me!!!
15:38:10 tobias-urdin mriedem: we are affected by https://review.openstack.org/#/c/618734/ but we have renamed the project until then but live migrations fails since it's wrong in the XML
15:38:31 sean-k-mooney spatel_: no worries this is rather difficult to figure out all at once
15:38:49 tobias-urdin so i was not sure if doing a hard reboot would use the cached instance_system_metadata or not, it does rebuild the XML but perhaps with the wrong data
15:38:59 tobias-urdin perhaps better to just test it out in a test environment
15:39:26 spatel_ in document is not very clear! anyway i am totally on it now
15:39:28 tobias-urdin it's probably not a good idea to DELETE those rows in instance_system_metadata
15:39:56 mriedem tobias-urdin: no that's probably not a great idea
15:40:25 mriedem tobias-urdin: what are the bad fields? user name and project name?
15:40:52 mriedem i.e. owner_user_name and owner_project_name in the xml?
15:41:14 sean-k-mooney spatel_: ya this was a topic at the summit. we need an nfv tuning guide with examples as the docs for these advanced feature are... lacking clarity to put it nicely
15:41:40 tobias-urdin mriedem: yeah the owner project name in the xml
15:42:02 mriedem i'm guessing _get_guest_config_meta in the libvirt driver is the thing putting the bad data in the xml
15:42:22 mriedem if you deleted owner_user_name and owner_project_name from the instance_system_metadata, we would put "N/A" in the xml
15:42:24 sean-k-mooney spatel_: i as a developer often use the specs to understand what we intended to enable but end users should not needed to read them to consume the features and use them properly.
15:43:44 spatel_ ++
15:44:04 mriedem tobias-urdin: and those fields are put into the system_metadata only at server create time, not reboot
15:44:21 mriedem so even if you changed the user name / project name in keystone, that wouldn't be reflected in the instance sysmeta
15:46:33 tobias-urdin mriedem: thanks! then i'll apply the patch manually on the affected nodes until it lands in stable/rocky
15:52:17 dansmith mriedem: tobias-urdin +W
15:55:37 dansmith mriedem: jaypipes sean-k-mooney: I think we need to give some clarity to sundar here: https://review.openstack.org/#/c/603955/10/specs/stein/approved/nova-cyborg-interaction.rst
15:55:56 dansmith I am majorly opposed to documenting all the cyborg and os-acc APIs and functions in that spec
15:56:08 sean-k-mooney dansmith: just hopping on a call in 5 mins but sure what had you in mind
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

Earlier   Later