Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-12
10:39:38 alex_xu emm...so, yes, sounds like no version is ok
10:43:12 alex_xu johnthetubaguy: gmann Kevin_Zheng I guess the only different is we want to put all the info together, or just split that special case out of schema? is that question we should answer?
10:48:15 gmann alex_xu: you mean in case we add in schema with new formatter ?
10:48:57 alex_xu gmann: yes
10:49:12 gmann alex_xu: but 'format' only work if instance going to be validated is string and in our case it is list of values right
10:49:43 alex_xu gmann: we have macro function 'multi_params', that works for list
10:51:19 openstackgerrit Davanum Srinivas (dims) proposed openstack/nova: Better black list for py35 tests https://review.openstack.org/419250
10:52:00 gmann alex_xu: yea but instance (values) will be list and we would not be able to define like {"system_metadata": {"type": "string", "format": "reject_always"}}
10:52:16 alex_xu gmann: here is https://github.com/openstack/nova/blob/master/nova/api/validation/parameter_types.py#L38
10:52:26 gmann we have to do like this - {"system_metadata": {multi_params, "format": "reject_always"}}
10:52:53 alex_xu gmann: sorry, it should be {"system_metadata": multi_params({"type": "string", "format": "reject_always"})}
10:54:01 gmann alex_xu: ahh i see, so that each item will be validated against "reject_always"
10:54:11 alex_xu gmann: yea
10:54:38 alex_xu but have to say reject_always format is another hacky thing. is it decorator more explicitly?
10:55:09 alex_xu s/is it decorator/ is decorator/
10:55:51 alex_xu s/explicitly/explicity/...
10:56:02 gmann humm, another issue may be error message otherwise i like new formatter way
10:56:24 gmann alex_xu: but we can catch and format error message which will be other hack but wotrks
10:57:46 alex_xu gmann: yea, we already have one case https://github.com/openstack/nova/blob/master/nova/api/validation/validators.py#L264, then probably add another one
10:57:48 gmann johnthetubaguy: i think string thing solved here as alex_xu mentioned we can validate against each item of list and 'format' works
10:58:06 gmann alex_xu: :) aboout to give that example
10:58:25 gmann alex_xu: i am +1 with new formatter.
10:58:32 alex_xu gmann: :)
10:58:56 gmann alex_xu: johnthetubaguy have to rush for train. ll see log later
10:59:34 alex_xu gmann: yea, I have to go home also, back later
11:02:36 openstackgerrit Zhenyu Zheng proposed openstack/nova: [poc] add a decorator to reject know bad filters. https://review.openstack.org/419256
11:20:22 openstackgerrit Zhenyu Zheng proposed openstack/nova: [poc] add a decorator to reject know bad filters. https://review.openstack.org/419256
11:21:02 openstackgerrit zhangyujun proposed openstack/nova: Update JSON Schema for flavor access https://review.openstack.org/418683
11:38:38 openstackgerrit Zhihai Song proposed openstack/nova: Update py35 functional tests blacklist https://review.openstack.org/415149
11:39:51 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.volume_attach notification https://review.openstack.org/401992
11:49:14 openstackgerrit Wang Qing wu proposed openstack/nova: WIP(4): Introduce base PowerVM driver (cfg drv) https://review.openstack.org/409404
11:57:46 openstackgerrit Zhenyu Zheng proposed openstack/nova: [poc] add a decorator to reject know bad filters. https://review.openstack.org/419256
11:59:48 openstackgerrit Zhihai Song proposed openstack/nova: Enable tests.functional.db.api.test_migrations for py35 https://review.openstack.org/419435
12:02:02 openstackgerrit Zhenyu Zheng proposed openstack/nova: [poc] add a decorator to reject know bad filters. https://review.openstack.org/419256
12:02:48 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.volume_attach notification https://review.openstack.org/401992
12:13:02 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.volume_detach notification https://review.openstack.org/408676
12:15:11 openstackgerrit Béla Vancsics proposed openstack/nova: Reduce code duplication https://review.openstack.org/270911
12:21:25 openstackgerrit Istvan Imre proposed openstack/python-novaclient: Pass relevant parameters to Token based authentication https://review.openstack.org/419441
12:24:17 openstackgerrit Zhihai Song proposed openstack/nova: Update py35 functional tests blacklist https://review.openstack.org/415149
12:31:42 dims mriedem : bauzas : the review for the py35 functional test blacklist is ready - https://review.openstack.org/#/c/419250/
12:42:30 openstackgerrit Chris Dent proposed openstack/nova: Small improvements to placement.rst https://review.openstack.org/403811
12:46:42 cdent mriedem, bauzas : can we get that merged or otherwise reviewed? Or if not, let me know so I can abandon it.
12:50:50 openstackgerrit Béla Vancsics proposed openstack/nova: Reduced the complexity of the _init_instance method https://review.openstack.org/374661
12:53:42 openstackgerrit John Garbutt proposed openstack/nova: Pass objects into _create_ports_for_instance https://review.openstack.org/418512
13:02:26 bauzas cdent: looking
13:02:38 cdent thanks
13:03:01 bauzas cdent: +2d
13:03:08 cdent more thanks!
13:03:12 bauzas cdent: I'll abandon my doc patch changing the port number
13:13:42 gibi hi nova!
13:13:50 gibi I have a question about lazy-loaded fields
13:13:55 cdent hi gibi !
13:14:05 cdent (someone has had their coffee today)
13:14:14 gibi cdent: :)
13:14:36 gibi Do I see correctly that instance.flavor.projects access is a double lazy-load?
13:14:45 gibi and that it will not work
13:14:54 gibi as when the flavor is loaded into the instance
13:15:00 gibi then the Flavor object is orphaned
13:15:05 gibi https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L315
13:16:29 gibi so I have an instance object
13:16:40 gibi and I access instance.flavor
13:16:48 gibi which will lazy load the Falvor object
13:17:10 gibi and then I try to access the projects field of that Flavor object that is again a lazy load
13:17:18 gibi then that is fails as the Falvor object is orphaned
13:18:30 gibi I started here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5031
13:18:36 gibi with an instance
13:19:07 gibi then that notification sending first access instance.flavor and that is OK as the instance is not orphaned
13:19:23 gibi but after that the code needs instance.flavor.projects and that fails
13:19:28 cdent gibi: this is the sort of question I'd love to see on the mailing list so that the response is preserved somewhere more readable by more people than IRC. Also I don't know the answer :)
13:19:37 gibi OrphanedObjectError: Cannot call _load_projects on orphaned Flavor object
13:19:52 gibi cdent: OK, I post to ML
13:21:17 cdent it looks like those flavor objects being created never get a context?
13:22:42 openstackgerrit Zhenyu Zheng proposed openstack/nova: [poc] add some code to reject known bad filters. https://review.openstack.org/419256
13:22:49 gibi yes, it seems to me the context is missingf
13:23:56 cdent which presumably means someone wanted to make sure you can't do what you're trying to do? :)
13:24:41 gibi I'm not sure about that
13:25:25 gibi I think it is more likely that we forgot the context there
13:25:50 Dinesh_Bhor cdent: Hi, do you have some time? I am not much clear about 'Content-Type' in response so thought to ask you few doubts.
13:26:24 cdent Dinesh_Bhor: I can try. What's up?
13:26:39 Dinesh_Bhor cdent: Is it compulsory that all openstack services should return 'Content-Type' in response header?
13:26:49 Dinesh_Bhor cdent: I have seen most of the openstack services returning 'Content-Type' in response header.
13:28:17 cdent Dinesh_Bhor: that's a requirement of HTTP, not just openstack
13:28:38 cdent if there is a body in the response there needs to be a content-type header to identify what media type it is
13:29:47 cdent Dinesh_Bhor: there's some extensive information in the RFC: https://tools.ietf.org/html/rfc7231#section-3.1
13:31:12 cdent Dinesh_Bhor: does that help?
13:31:34 Dinesh_Bhor cdent: yes, thank you so much
13:32:01 cdent the same thing is true of a request: if it has a body it needs a content-type header too
13:35:45 openstackgerrit Béla Vancsics proposed openstack/nova: Reduced the complexity of the _init_instance method (2) https://review.openstack.org/419463
13:36:32 dims bauzas : you may have missed my ping :) https://review.openstack.org/#/c/419250/
13:36:48 bauzas dims: heh, oops :)
13:36:58 dims no worries :)
13:37:22 openstackgerrit Julian proposed openstack/nova: Create script that prints JSON Schema of Notification Payload Classes https://review.openstack.org/411836
13:41:02 Dinesh_Bhor cdent: sry to disturb you again. agree that If the request contains body then there must have content-type but if service returns an http exception then in response will that content-type be available?
13:41:33 efried mriedem: Can we add a PowerVM section in https://etherpad.openstack.org/p/ocata-nova-priorities-tracking ?
13:42:15 cdent Dinesh_Bhor: the content-type header should always say what the media type of the body is, even when returning an exception. If the exception has been formatted to JSON then the content-type should be application/json. If it is html, then text/html. If it is straight text then text/plain
13:43:32 Dinesh_Bhor cdent: ok, explains a lot
13:43:56 cdent Dinesh_Bhor: just out of curiosity what are you working on that raised these questions?
13:45:11 Dinesh_Bhor cdent: https://github.com/openstack/python-glanceclient/blob/master/glanceclient/exc.py#L156 this one
13:45:26 Dinesh_Bhor cdent: here all logic is based on content-type
13:47:15 Dinesh_Bhor cdent: and I am trying to solve bug in openstacksdk by refering that logic

Earlier   Later