Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-08-12
13:42:51 sean-k-mooney melwitt: bnemec by the way i finally got aroudn to trying to repoduce https://bugs.launchpad.net/nova/+bug/1854992 since we are talking about adding a ping
13:42:51 openstack Launchpad bug 1854992 in OpenStack Compute (nova) "Frequent instances stuck in BUILD with no apparent failure" [Undecided,Incomplete]
13:43:18 sean-k-mooney melwitt: bnemec deleting the queue will not triggere it because oslo messaging just recreates the queue
13:43:49 sean-k-mooney melwitt: bnemec but unbinding the queue form the topic does break the ablity for the compute node to recive rpcs
13:44:16 sean-k-mooney but its still considered alive since it can still send the heartbeats back fine
13:53:53 sean-k-mooney melwitt: bnemec can you let me know what you think of the two options to fix this?
13:58:34 kklimonda @gmann right, but policy checks don't receive much context about server create request, and without that I can't really say whether it should be allowed or denied
14:00:22 gmann kklimonda: ohk, currently we pass only project-id, user-id and AZ - https://github.com/openstack/nova/blob/5b79ec8670619ece92ac8bb43d84d2412778a182/nova/api/openstack/compute/servers.py#L648
14:00:57 gmann kklimonda: we can add more targets there to enhance the policy control
14:01:22 gmann or pass instance object itself for wider use case
14:03:40 sean-k-mooney dpending on what api it is you might not have an instance objet at the policy time but you do get one failrly quilcly. the build request or request spec might work in those casess
14:03:48 sean-k-mooney im thinking of create server
14:04:07 sean-k-mooney but for other apis we proably could pass the instance object ya
14:04:18 gmann sean-k-mooney: yeah, the request body of instance request we can pass in case of create server
14:05:11 sean-k-mooney yes ideally we would pass a copy too
14:05:12 gmann or best will be add attr by attr based on use case we get to know
14:05:15 sean-k-mooney so that you can modify anything
14:05:23 gmann true
14:05:29 sean-k-mooney *can't
14:06:09 sean-k-mooney body looks like its a dict
14:06:36 sean-k-mooney for this kind of think i generally prefer to be lazy and pass the whole thing
14:06:48 sean-k-mooney rahter then attr by attr
14:06:58 sean-k-mooney but it depned on how strong a contract we want to give
14:07:21 sean-k-mooney e.g. if we change a field name if we just pass the body it can break things
14:07:26 sean-k-mooney so there is a trade off there
14:07:35 gmann yeah, for some APIs that is ok but for many passing everything is just unnecessary for oslo policy
14:07:36 sean-k-mooney at least form an upgrades point of vew
14:08:11 gmann you mean if API change the request attr etc?
14:08:35 gmann and overridden policy were relying on that
14:08:55 sean-k-mooney if we renamed say body['os:scheduler_hints'] to body['os:scheduler_hint'] and the polocy was relying on that then it would break
14:09:09 gmann yeah
14:09:13 sean-k-mooney but if we add a scheduler_hints attibe then we have a layer of indirection
14:09:34 sean-k-mooney not that we plan to do that but you know just trying to see what would break
14:09:37 gmann that is good upgrade checks in such case
14:10:22 gmann we can get the override rules and how they are written and compare such case of attr change at API side
14:10:42 sean-k-mooney only for default rules
14:10:49 sean-k-mooney we wont know what customer are using
14:11:19 gmann we can know, we get the policy file and the overridden rule info
14:11:33 sean-k-mooney not upstream
14:12:06 sean-k-mooney if random customer x uses this to create a custom policy rules check any sub element of the requet body
14:12:16 sean-k-mooney we can test for that
14:13:35 gmann yeah, what other case you mean we cannot test?
14:13:38 sean-k-mooney what we could do is pass create_kwargs instead of body that gives us a small laywer of indriection in this case but i think im slowly talking my self into advocating for only passing objects or indivigual atributes
14:14:26 sean-k-mooney we cant test every poicly atibute that coudl be used form the body
14:14:48 gmann ohk, yeah.
14:15:49 gmann but as long as we construct the targets explicitly, we can do. I am in favor of 'add attr based on known use case' instead of complete object/request info
14:16:18 gmann we do not test current allowed attr though but something to improve
14:16:41 gmann project_id is only tested at major/or-all
14:19:31 sean-k-mooney ya if we just add things one by one to the target we can test it
14:20:08 sean-k-mooney well the target is currently
14:20:10 sean-k-mooney target = {
14:20:13 sean-k-mooney 'project_id': context.project_id,
14:20:15 sean-k-mooney 'user_id': context.user_id,
14:20:17 sean-k-mooney 'availability_zone': availability_zone}
14:20:24 sean-k-mooney i dont think we would remove any of those well ever
14:20:29 sean-k-mooney so it pretty safe
14:21:01 sean-k-mooney kklimonda: what did you need for your usecase
14:21:05 gmann yeah, chance of changing request body is very less. addition is there
14:21:11 gmann also scope control and new defaults, can solve the problem at most extend.
14:27:31 kklimonda sean-k-mooney: it's a billing issue - we want to have two types of VMs: pay-as-you-go and prepaid (attached to a contract). I need to limit `compute:create:*` API calls based on whether user has credits, or contract with a open slots for a given flavor type. Also, have a way to return a customized error message back to the user would be nice.
14:29:02 sean-k-mooney kklimonda: that is not really a policy function
14:29:58 sean-k-mooney kklimonda: that feels more like a use case for keystone middelware or quotas
14:30:36 kklimonda keystone middleware as in custom middleware for keystone?
14:31:07 gmann yeah, we cannot control these with policy
14:31:11 sean-k-mooney as in custom mideelware for the nova api
14:31:32 sean-k-mooney sorry not keystone middelware oslo.middleware
14:31:52 sean-k-mooney we have keystone middelware that uses that to handel all our auth
14:32:02 sean-k-mooney so its the example of api middelware that comes to mind
14:32:06 kklimonda can I still add custom middleware to nova? keystone have removed that feature around stein iirc
14:32:18 sean-k-mooney you can do it with paste
14:32:19 sean-k-mooney but yes
14:32:55 gmann here https://github.com/openstack/nova/blob/master/etc/nova/api-paste.ini
14:34:37 kklimonda makes sense, for some reason I've completely blacked out on middleware - derp
14:35:13 sean-k-mooney anyway im not that familar with how that all works but you can still add custom middleware and then intercept any request and do whatever you want provided you are also happy to support it yourself :)
14:56:03 alex_xu efried: sean-k-mooney, for the user add their own custom trait manually through placement, that should be the case we want to ignore the conflict trait from provider config?
14:56:47 alex_xu efried: sean-k-mooney, compare to modify inventory, the user adds custom trait is more normal case I guess
14:59:47 sean-k-mooney so CUSTOM_ traits we shoudl ignore i think
15:00:14 sean-k-mooney but standard tratis should only be set via virt driver or provider.yaml
15:00:40 sean-k-mooney i have to join a meething now however so havnt fully tought through that answer
15:02:59 alex_xu sean-k-mooney: yea
15:32:07 efried alex_xu: What does it mean to have a trait conflict? The provider config is intended to allow you to override things. If it contains a CUSTOM_ trait that's not already on the provider, we should add it. If there's a trait -- CUSTOM or otherwise -- on the provider but not in the config, we should leave it alone. Right?
17:48:11 eandersson I know Rocky patches are not a priority, but if someone has time could you look at getting this patch series merged? https://review.opendev.org/#/c/703117/
#openstack-nova - 2020-08-13
02:22:51 openstackgerrit renminmin proposed openstack/nova master: Fix instance booted with snapshot image and bdms https://review.opendev.org/745821
02:50:01 openstackgerrit Merged openstack/nova master: Detach is broken for multi-attached fs-based volumes https://review.opendev.org/741712
04:53:53 openstackgerrit Harshavardhan Metla proposed openstack/nova master: Raising a failure in case of 403 https://review.opendev.org/735068
08:07:11 openstackgerrit Alexandre Arents proposed openstack/nova master: Rebase qcow2 images when unshelving an instance https://review.opendev.org/696084
08:27:20 openstackgerrit Jie Li proposed openstack/nova master: fix revert resize failed https://review.opendev.org/746020
12:35:06 openstackgerrit Merged openstack/nova master: [Trivial] Remove wrong format_message() conversion https://review.opendev.org/744280
12:53:58 openstackgerrit Mark Goddard proposed openstack/nova master: docs: fix aggregate weight multiplier property names https://review.opendev.org/746128
14:28:25 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in baremetal nodes policies https://review.opendev.org/741716
14:28:59 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Pass the actual target in baremetal nodes policy https://review.opendev.org/741717
14:31:30 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in networks policies https://review.opendev.org/742566
14:31:52 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Pass the actual target in networks policy https://review.opendev.org/742568
14:34:32 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add scope and new default roles in extensions policies https://review.opendev.org/743046
14:36:30 artom Is logstash... working?
14:36:42 artom I'm trying to understand if "Multiple possible networks found, use a Network ID to be more specific" in the nova-next job is a recurring thing
14:55:44 sean-k-mooney artom: its a few days delayed
14:56:02 sean-k-mooney i think 3-5 days
14:57:19 sean-k-mooney artom: http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22Multiple%20possible%20networks%20found,%20use%20a%20Network%5C%22
14:57:26 sean-k-mooney set it to 30days and you get hits

Earlier   Later