Earlier  
Posted Nick Remark
#openstack-sdks - 2017-01-18
08:04:32 RuiChen default quota need project id too, it's passed by project=res.id in your other patch
08:05:36 reedip sorry , wrong statement. It needs project id but not in the URI
08:05:51 reedip thats why i put requires_id as false for default quotas in the second patch
08:06:07 reedip I was typing faster than I was thinking, thats why the wrong statement :D
08:10:43 RuiChen never mind, I debug the patch in my devstack to try openstack quota show, like this
08:10:50 RuiChen https://www.irccloud.com/pastebin/LaHmzLVV/
08:12:59 reedip this is quota show, right ?
08:13:07 RuiChen yes
08:13:08 reedip try quota set and quota-show --default
08:13:36 reedip this is your code ?
08:14:19 RuiChen https://www.irccloud.com/pastebin/Lpl0Srf1/
08:14:29 RuiChen this quota set --network -1 xxx
08:14:55 RuiChen quota show --default have to apply your other patch
08:15:45 reedip RuiChen, how did the request body have ID when you deleted it using the if loop ?
08:17:53 RuiChen yeah, have to handle the resource_key in body, then delete 'id'
08:19:01 reedip RuiChen : and you are trying this with SDK 0.9.12 right ??? :)
08:19:11 reedip just confirming , please do not mind :)
08:20:19 reedip Actually with 0.9.12, https://www.irccloud.com/pastebin/Lpl0Srf1/ was not happening for me, without my patch. It was failing at the _prepare_requests because quotas didnt have the ID
08:20:49 RuiChen I try the patch in current openstack sdk master, I think the code same with 0.9.12
08:21:14 reedip :)
08:21:14 reedip Yes, it should be
08:24:06 RuiChen if we can call the super class _prepare_request(), then delete 'id' in body or body[resource_key] to handle the special case for quota and default quota, i think it's better solution
08:24:46 RuiChen you don't have to care the _prepare_request() change in the future.
08:25:02 reedip RuiChen : wait, I am trying your change
08:25:17 reedip I am cloning the latest release and putting your change
08:25:28 reedip I still feel I will get a bug :P
08:28:53 RuiChen : ), I'm trying to make small change to handle quota and default quota (show and set action)
08:31:42 reedip RuiChen : I think there has been some change somewhere :D
08:35:55 reedip RuiChen: found the bug !
08:35:55 RuiChen finally, it worked
08:35:59 reedip :)
08:36:03 reedip Wait RuiChen :)
08:36:31 reedip I had 0.9.10 :P
08:36:47 reedip thats why the above code worked. Now using 0.9.12 and ur patch !
08:36:54 reedip and got the issue
08:37:09 RuiChen https://www.irccloud.com/pastebin/xFXl6TFa/
08:37:09 RuiChen https://www.irccloud.com/pastebin/H5yOdoYA/
08:39:49 reedip Ok, now it worked !
08:40:33 RuiChen \o/
08:41:14 RuiChen thank you mention the quota set case, that make the patch better
08:42:01 reedip RuiChen but what about the Default Quota now
08:42:09 reedip I need to remove the ID from URI
08:42:11 reedip :)
08:43:41 RuiChen in default quota case, project_id is not the resource id, it's attribute
08:43:59 RuiChen the resource base_path is base_path = '/quotas/%(project)s/default'
08:44:17 reedip So how would that work ?
08:44:45 RuiChen uri = self.base_path % self._uri.attributes in resource class
08:44:54 RuiChen in _prepare_request()
08:46:31 reedip so you are stating that we do not need to change anything for DefaultQuotas?>
08:47:48 RuiChen only to change the def get_quota-default(), pass id and requires_id=False
08:48:23 reedip yes, thats what I was thinking
08:48:36 reedip so I do not need to change much for the defaultquotas patch
08:48:42 reedip from the defaultquotas class
08:50:02 openstackgerrit Reedip proposed openstack/python-openstacksdk: Fix Setting Quotas in Neutron https://review.openstack.org/419911
08:50:19 reedip RuiChen vv
08:53:00 reedip RuiChen vv
08:53:16 openstackgerrit Reedip proposed openstack/python-openstacksdk: Add project ID in QuotaDefault requests https://review.openstack.org/420301
08:54:37 openstackgerrit Reedip proposed openstack/python-openstacksdk: Add project ID in QuotaDefault requests https://review.openstack.org/420301
08:57:12 RuiChen reedip: I had added my +1 for the two patches, thank you
08:58:14 reedip Thanks RuiChen :)
11:37:56 openstackgerrit Chris Dent proposed openstack/api-wg: [WIP] Refactor and re-validate api change guidelines https://review.openstack.org/421846
15:48:16 mordred dtroyer, stevemar: did we release occ already?
15:49:09 mordred ah - looks like we have
15:49:16 dtroyer https://review.openstack.org/#/c/421469/ yes
15:49:25 dtroyer need another?
15:49:41 mordred well - we got this submitted: https://review.openstack.org/#/c/421668/ which seems both easy and friendly - but also not _super_ important
15:51:28 dtroyer +A, the deadline is tomorrow if we want that in stable
15:51:30 dtroyer wait
15:51:36 dtroyer o-c-c- doesn't do stable
15:52:09 dtroyer so its just a matter of when it would be released, today/tomorrow or next month
15:54:42 mordred oh - neat. cool - no rush then
15:59:26 openstackgerrit Dean Troyer proposed openstack/golang-client: Revert "Add crud operation of volume API v3" https://review.openstack.org/422055
16:01:12 ankur-gupta-f2 dtroyer: similar note. Does OSC do a feature freeze?
16:02:59 dtroyer ankur-gupta-f: yes, next week. we will have one more release before then, early next week
16:03:24 dtroyer osc-lib freezes tomorrow, its to-become-stable-brans is the current release
16:03:33 dtroyer s/brans/branch/
16:03:52 stevemar dtroyer: we'll have to get more strict about feature freeze and such soon
16:04:26 dtroyer stevemar: soon == now for the new bits (volume v3, etc).
16:08:45 rosmaita cdent: would be interested in your opinion of the discussion happening on https://review.openstack.org/#/c/420038/ , especially in light of your email this morning about the new tag proposal
16:09:02 rosmaita elmiko: ^^ etoews: ^^
16:09:25 ankur-gupta-f2 dtroyer: Okay. I have told our team that any reviews coming in on any of these https://etherpad.openstack.org/p/osc-transition-priorities to be addressed ASAP. Thanks
16:09:30 cdent rosmaita: thanks, will look. I'm experiencing "stability" fatigue
16:09:52 rosmaita cdent: ha! well, i will warn you in advance, that this will not help :)
16:11:38 elmiko rosmaita: i'll try to take a look, i'm putting out fires at the moment :/
16:11:50 dtroyer ankur-gupta-f: at this point new commands (not already in-flight) are probably doubtful
16:13:00 rosmaita elmiko: best wishes for your firefighting!
16:13:00 ankur-gupta-f2 dtroyer: most have been in flight and are nearing completion. Just waiting for the final few reviews
16:13:41 cdent dtroyer: yeah, I have labeling fatigue too
16:13:56 elmiko rosmaita: cheers!
16:15:39 cdent dtroyer: I tend to think of consistency on the spatial (amongst apis) dimension and some term (maybe stability) is need for the time (within an api) dimension
16:17:48 dtroyer cdent: they both make me tired and make me wonder why in the world this is all so hard
16:21:41 cdent my eyes are fuzzy enough that I ready dtroyer as saying "makes me wonder why I'm in this world"
16:22:42 openstackgerrit Dean Troyer proposed openstack/golang-client: Fix unit tests https://review.openstack.org/422080
16:23:20 cdent I've withheld my opinion on this topic because at least for the time being it is probably too poorly informed to be useful, but yeah it all makes me pretty tired
16:26:26 dtroyer here is mine: one place that a BDFL is useful is in keeping at least some of the cats in the same order everywhere. I've had to say no so many times to OSC command stuff just to be as close to consistent as we are (still a ways to go). There is no way in h3ll that we'd have accomplished that with teams doing their own thing, even if they agreed on the idea. Even now, many of the OSC plugins slide past the guidelines (I d
16:26:36 dtroyer That is just the CLI, and "CLI's are easy"
16:27:46 dtroyer the only way we will get a clean, consistent REST API for OpenStack is to have a single unit (team, working group, whatever) build it <cough>oaktree</cough>
16:28:08 dtroyer </rant>
16:28:49 cdent I can get behind that (modulo corporate enterprisey nonsense)
16:30:05 dtroyer I think it would take a corporate-type sponsor without an API to defend/enhance to sponsor it to ever get anywhere

Earlier   Later