Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-15
14:41:19 sean-k-mooney since they can move between compute services
14:41:52 sean-k-mooney they code they linked too however is querying placment
14:41:54 sean-k-mooney https://github.com/openstack/neutron/blob/master/neutron/services/segments/plugin.py#L253
14:42:50 gibi sean-k-mooney: I think neutron creates a host aggregate that is then mapped to placement aggregate by nova and then neutron puts the IP RP to into that placement aggregate
14:43:15 gibi or something like that (it is pretty complicate)
14:43:30 sean-k-mooney gibi: neutron should be creating both a RP and hostaggreate makeing the RP a sharing resouce provider of ips
14:43:51 hrw bauzas: https://review.opendev.org/714425 (AMD SEV check) updated with tests
14:44:45 sean-k-mooney hrw: that looks like an optimiation
14:44:53 sean-k-mooney is this breaking something if so you shoudl file a bug
14:47:00 gibi sean-k-mooney: so for ironic neturon gets the node uuid for libvirt neutron gets the hostname and the neutron in both case use the given id as a member of an aggregate but in nova host aggregates works on compute host level not on compute node level
14:48:18 sean-k-mooney gibi: well this is all handeld at the compute manager level
14:48:33 sean-k-mooney for everythign other then ironic it gets the instance.host
14:48:37 gibi yepp
14:48:45 gibi this is the key difference
14:48:47 sean-k-mooney for ironic it gets the node uuid
14:48:57 sean-k-mooney the instance.host shoudl be the node uuid
14:49:05 sean-k-mooney in the ironic case
14:49:09 sean-k-mooney so it shoudl be the same
14:49:28 gibi yepp, but I don't think you can add a node to a nova host aggregate
14:49:35 gibi you can only add a host there
14:50:04 sean-k-mooney isnint instance.host always set to the hypervior hostname
14:50:35 sean-k-mooney so i think the neutron code only ever works in that case because for non ironic host the hypervior hostname and compute service host are the same
14:50:51 gibi yepp, that could be the case
14:51:24 hrw sean-k-mooney: it does not break anything. just looks weird when on aarch64 host I see checks of x86 features in log
14:51:39 sean-k-mooney hrw: its not an x86 feature
14:51:45 sean-k-mooney its not part of the instuction set
14:51:50 sean-k-mooney its an AMD extention
14:51:56 hrw sean-k-mooney: AMD SVE is not aarch64 feature as well ;D
14:52:12 sean-k-mooney yes but its incrrect to call it x86
14:52:44 hrw sean-k-mooney: when you run 'lscpu' it is listed in features. along with 'I can run KVM' which is not part of ISA iirc too
14:53:29 sean-k-mooney sure but the feature are not instuctionsets
14:53:56 sean-k-mooney several of the security flaws are listed as "features" too
14:54:31 sean-k-mooney anyway if you file a bug for that patch im +1 on it
14:54:51 hrw sean-k-mooney: looking at history of amd64/x86-64/x64 it is sometimes hard to notice who copied who ;D
14:56:20 sean-k-mooney well that is irrelevent to this conversation but x64 was itainiaum amd64 is the 64 bit extentison amd developed and x86_64 is the name for x86 with the amd64 extnetions intel licened form amd
14:56:21 hrw sean-k-mooney: ok
14:56:39 hrw ia64 was itanium. x64 is ms name for x86-64/amd64
14:57:13 sean-k-mooney ah yep correct
14:58:03 hrw my previous (x86-64) laptop has 'Intel Itanium Inside' sticker on it - for pure fun of it
15:02:15 melwitt gibi, slaweq: we need to merge the train backport in order to see the bug disappear because grenade runs train first, then upgrades to ussuri https://review.opendev.org/718934
15:03:08 gibi melwitt: bahh, you are correct. /o\ putting the bug back to FixReleased state
15:04:30 melwitt and that patch was stuck behind https://review.opendev.org/719120 but that merged, so it is good to review now
15:04:51 gibi elod, lyarwood: could you please look at ^^ ?
15:07:40 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: libvirt: check for AMD SEV only on x86-64 https://review.opendev.org/714425
15:07:52 hrw sean-k-mooney: bug created, linked
15:08:55 elod gibi melwitt : this one, right? https://review.opendev.org/#/c/718934/ anyway, looking
15:09:17 gibi elod: yepp, that one, thanks
15:14:37 lyarwood gibi / melwitt ; ack done
15:16:01 gibi lyarwood: thnks
15:27:40 openstackgerrit Ghanshyam Mann proposed openstack/nova stable/stein: Use placement stable version for functional job https://review.opendev.org/719121
15:34:39 gibi bauzas: releasing bug triage lock as I'm leaving for today
15:34:51 bauzas gibi: ack, will continue then
15:35:08 bauzas gibi: I triaged a couple of in-progress, nothing crucial
15:35:09 melwitt stephenfin: fyi brief discussion from yesterday on the possibility of bringing back the ability to show user_data in the cli with a switch http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-04-14.log.html#t2020-04-14T22:59:39
15:35:41 gibi bauzas: thanks. nothing RC blocking on my side either
15:54:09 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in servers attributes policies https://review.opendev.org/719730
15:54:33 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing remaining servers policies https://review.opendev.org/720104
15:54:41 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in remaining servers Policies https://review.opendev.org/720106
15:54:50 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in remaining servers policies https://review.opendev.org/720116
16:16:17 openstackgerrit Merged openstack/nova master: fup: Remove the use of the term `unstable rescue` INFO logs https://review.opendev.org/718451
16:16:24 openstackgerrit Merged openstack/nova master: fup: Add missing docstrings from get_rescue_device|bus diskinfo funcs https://review.opendev.org/718464
16:24:25 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: libvirt: Calculate disk_over_committed for raw instances https://review.opendev.org/718964
16:28:39 gmann melwitt: lyarwood stein backport is ready now (train is merges) - https://review.opendev.org/#/c/719121/
16:29:32 openstackgerrit Merged openstack/nova master: libvirt: Change UEFI check to handle AArch64 better https://review.opendev.org/714311
16:29:58 melwitt gmann: I thought you were gonna re-cherry-pick that one from the train change and remove the conflict note from the commit message?
16:32:18 hrw yay ;D
16:32:53 gmann melwitt: there was conflict form train also due to deps url
16:33:10 melwitt gmann: haha oh
16:33:30 gmann due to git.openstack.org and opendev.org
16:33:53 melwitt nevermind then
16:35:18 hrw does https://review.opendev.org/#/c/712607/ needs another 7h recheck?
16:38:29 openstackgerrit Lee Yarwood proposed openstack/nova master: fup: Fix [workarounds]/rbd_volume_local_attach config docs https://review.opendev.org/718100
16:39:08 lyarwood stephenfin: ^ no idea how that ended up in merge conflict, can you +W that again if it's still okay?
16:41:46 sean-k-mooney huh i taught that already merged honestly
16:42:12 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: [WIP] CI: add tempest-integrated-compute-aarch64 job https://review.opendev.org/714439
16:42:14 sean-k-mooney oh it did this is just a fix up for the config
16:49:34 stephenfin melwitt: I saw that, but wasn't sure what the conclusion was
16:50:27 melwitt stephenfin: no conclusion yet, wanted to see what you thought about it
16:50:47 melwitt since you had removed the user_data, what you thought about adding it back but by flag only
16:51:51 stephenfin Realistically I don't think we'd ever want that information included in raw format as part of the show command, but we clearly want it somehow. How about a new command?
16:54:27 melwitt I guess that seems heavier than what I was imagining. to just have it be like nova show --include-user-data or something like that
16:54:27 stephenfin Hmm, so it's both the 'nova boot' and 'nova show' commands that are affected
16:54:38 melwitt and rebuild apparently
16:54:43 stephenfin yup
16:55:29 melwitt it's not something "commonly" used but it's useful if an end user wants to see, did I pass in the user_data I expected, or what did I pass in user_data earlier
16:56:44 sean-k-mooney melwitt: can you see that via the metadata api
16:56:58 melwitt anyway, I wanted to run it by you in case you're strongly against putting it back via --<option>
16:57:17 melwitt sean-k-mooney: I think you could but that if you're config drive only, you wouldn't be able to
16:57:51 sean-k-mooney oh we dont store the user data in the db do we
16:58:08 melwitt we do
16:58:22 sean-k-mooney sorry im thinking of injected files
16:58:33 sean-k-mooney those are the ones that are only in the config drive
16:59:04 melwitt yeah, sorry, I mean like if you're not running the metadata service. and are config drive only deployment
16:59:35 melwitt (example: verizon media)
16:59:42 sean-k-mooney ya if you dont have metadata api then you would have to check the config drive unless we dumped it as part of nova show
16:59:50 stephenfin and we don't provide a way to configure output or output formats either. Drat
17:00:10 sean-k-mooney you mean in nova client
17:00:15 stephenfin yup
17:00:43 sean-k-mooney then we cant alter the format without potentally breaking people
17:01:00 stephenfin Yes, that's exactly what's happening here :)

Earlier   Later