Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-08-30
08:08:32 mordred gtema: re: accept headers - I think the default value of '' is weird and it seems like changing that isn't a bad idea
08:08:49 gtema I'm glad
08:10:12 gtema mordred: can you please have another look on stats change? After your +2 I only addressed dtantsurs review - no functional changes
08:10:39 gtema I'm just tired rebasing my dockerfile, where I checkout this change
08:10:54 mordred gtema: yup. just re-reviewed
08:11:04 gtema cool, thanks
08:11:43 mordred gtema: does that accept patch work on your cloud? I though someone was saying requests adds a */* if you don't do anything and you needed to pass accept: None if you wanted no header ...
08:11:54 mordred (although it looks like the unit tests show no header - so I guess it does)
08:12:17 gtema well, with this I was only only checking the Swift - and it works this way
08:12:38 gtema Actually even swiftclient if you look is not passing any "Accept" header
08:13:03 gtema but since I modified HEAD and DELETE globally - this might bring problems somewhere
08:13:32 mordred I doubt it... but I guess anything is possible :)
08:13:40 dtantsur I think we should start with being standard compliant, and only add hacks if proved required
08:13:46 gtema that's exactly the problem - everything is possible
08:13:58 mordred dtantsur: ++
08:14:37 gtema dtantsur: now I definitely owe you a beer. Let's see when we can meet
08:14:43 dtantsur ++ :)
08:15:24 gtema btw, I hope in one-two weeks I plan to come back to switching remaining stuff in cloud to proxy/resource
08:15:48 gtema but we need to address one thing - caching
08:17:00 gtema it's either we still cast everything to dict in the cloud return, or we teach dogpile/etc to serialize Resource (what it can't do now)
08:18:53 gtema dtantsur: I also answered your question in https://review.opendev.org/#/c/665110/ - it's a default microver, so no change is required
08:19:23 mordred gtema: oh - yeah - I have some thoughts about that - I should write them down so we can discuss whether they're any good
08:19:36 gtema cool
08:21:39 dtantsur gtema: approved as well
08:24:08 gtema thanks
09:32:34 openstackgerrit Merged openstack/openstacksdk master: Rework statistics reporting https://review.opendev.org/659841
09:39:26 openstackgerrit Bo Tran proposed openstack/openstacksdk master: Add a fields meta_data to result of Senlin API https://review.opendev.org/678585
12:17:37 frickler mordred: dtroyer: I'm still seeing this "location | Munch..." spam in osc output, I thought we had fixed that some time ago already. can we get that fixed for the upcoming release still? http://paste.openstack.org/show/767631/
12:24:02 frickler the issue is triggered by openstacksdk>=0.24.0 but I can't remember whether it needs fixing in sdk or on osc side
12:27:45 Shrews frickler: yeah, that's less than pleasing. I'm guessing it should be osc side since sdk is supposed to return Munch objects to the callers
12:30:01 dtroyer frickler: one of the things we pushed in for osc4 is the output formatting changes, it may have crept back in with that sinne some of those were rather old
12:30:41 dtroyer the good news there is that it might only be ne place to change… I do not recall what the fix was initially
12:32:08 gtema_ dtroyer, since you are here and I remember this. I am going to finally come back to glanceclient=>SDK replacement (I think I need to redo this from scratch, rather then try to rebase).
12:32:10 frickler dtroyer: it seems to happen with all 3.x released version I've tested, so possibly it never got fixed
12:32:35 gtema_ should I do this in osc4 branch or in master?
12:34:41 dtroyer gtema_: the osc4 branch is dormant. I rebased what we had into back into master after the last release so osc4 is in master now and will be the next release
12:34:56 gtema_ ah, cool.
12:36:36 dtroyer frickler: ah, ok. next Q then is if it happens only in columns with the new formatting or olny not in those. I've seen it but not kept track of exactly where…
12:45:12 frickler dtroyer: I'm not sure I understand that question. from a quick test up to now I only see this issue for command showing/creating items living in the neutron api
12:50:51 dtroyer frickler: that is probably true as the others do not use SDK
12:52:04 dtroyer the change is the introduction of osc_lib.format_columns module to de-pythonize structured output, a recent example is on https://review.opendev.org/#/c/678689/2/openstackclient/compute/v2/aggregate.py
12:52:40 dtroyer without looking I am hoping we can just make DictColumn understand Munch
12:53:22 dtroyer if Much shows up in columns that are not handled by format_columns then we'll need to fix it on those columns specifically
12:59:28 frickler dtroyer: hmm, I can fix it for one object by inserting invisible_columns = ['location'] here, but I think it would be nice to have a more global solution https://opendev.org/openstack/python-openstackclient/src/branch/master/openstackclient/network/v2/router.py#L78
13:01:43 mordred frickler: yeah - I think it would be nice to generally teach $something what to do when it sees a munch - or a Resource for that matter
13:03:30 dtroyer frickler: I have a thing this morning, will dig in to that after lunch if you guys haven't already solved it all :)
13:12:23 frickler mordred: like that? http://paste.openstack.org/show/767638/
13:13:56 frickler hmm, that looks nice enough to me, I'll submit a patch for it
13:17:20 openstackgerrit Jens Harbott (frickler) proposed openstack/python-openstackclient master: Don't display Munch objects in the output https://review.opendev.org/679445
13:27:20 gtema frickler: just hiding munch columns is not a nice idea. Any complex structure will come out of SDK as munch, so you potentially loose important data
13:27:58 gtema and while currently there is nothing else then location/project, it may be any time later
13:29:04 frickler gtema: the idea is that it should be re-formatted to something that makes sense to an end user before it reaches that point. seeing "Munch(whatever)" in the cli output IMO should never happen
13:29:29 gtema I know, but simply hiding that is also not a way to go
13:29:55 gtema treat is as a dict and show correspondingly, but not simply hide
13:30:39 frickler gtema: the other option would be to just drop the 'location' column for all network objects. the content isn't relevant afaict
13:31:06 mordred frickler: it's a property of every object in sdk actually
13:31:17 frickler ... in an osc context. it sure is relevant in the sdk context
13:32:01 mordred frickler: nod. I'm not sure if it's useful to output from osc - it's mostly there so if you're doing multi-cloud-region things you can tell where a given object is from the object
13:32:20 gtema I wouldn't hide location by definition. In some contexts it might make sense
13:32:24 mordred it might not be super hard to make a generalized location renderer
13:32:29 gtema yea, as mordred said
13:33:05 gtema it's not actually only about location - it will be same for any complex structure in the SDK resource
13:33:42 gtema so there need to be a "apply dict formatter to any munch", and then in the network you can additionally hide location
13:34:46 mordred gtema: yeah. s/munch/resource or munch/
13:35:19 gtema it's following us in multiple contexts :)
13:36:09 mordred gtema: maybe it's not terrible to hide it for now then do a followup patch that unhides it as a placeholder to remind us t deal with it?
13:36:47 gtema beah, I am afraid it would be immediately forgotten
13:37:30 gtema but ok, let us then have a fat TODO/NOTE for that
14:06:11 openstackgerrit Merged openstack/openstacksdk master: Volume.Backup restore fixes https://review.opendev.org/665110
15:54:58 dtroyer so the column formatting is exactly what we added in osc_lib.format_columns, to produce useful output rather than python-formatted strings. We need to either treat Munch as a dict and use DictColumn() or make a MunchColumn() to handle those. I am assuming that type is predictable per column?
16:06:39 mordred dtroyer: yeah. I think treating Munch as a dict type is likely the right choice
16:14:13 mordred hrm. or - maybe a MunchColumn type woudl be right - that way we could run toDict() on it
16:14:19 openstackgerrit Monty Taylor proposed openstack/osc-lib master: Add a MunchColumn type https://review.opendev.org/679474
16:14:29 mordred dtroyer, frickler: ^^ something liek that perhaps
16:19:41 dtroyer mordred: see, I knew if I had lunch first… :) That approach works, is there enough difference to not just use DictColumn()? Other than having to call to_dict(). I am trying to decide if developers should know (or care) if they have a Much or a dict
16:20:48 mordred dtroyer: no - it _should_ behave just the same
16:21:39 mordred oh - yeah - actually - format_dict should totally work perfectly well with either Munch or Resource objects
16:22:06 dtroyer so we really just need to apply the DictColum calls to them… am trying that now
16:22:51 mordred ++
16:25:15 dtroyer \o/ I needed to make a pass through output one more time to catch columns added since the original work was done, that gets it
16:25:34 dtroyer now, nested Munch/dicts :)
16:26:33 dtroyer I am not sure how to represent those in the prettytable output
16:26:52 mordred dtroyer: maybe just as emoji
16:27:21 mordred dtroyer: or, more seriously, maybe with dotted notation ...
16:27:30 mordred do like project.name=foo
16:27:45 dtroyer that would be the cleanest visually
16:27:50 mordred for location = { project: { name: "foo" }}
16:28:35 mordred I mean - I say that - it's probably not really that hard as a recursive call
16:28:36 dtroyer I don't recall if other dicts we processed are nested, I didn't notice that location was before now
16:29:03 mordred I made it nested just to make life harder
16:29:17 dtroyer I would also totally buy doing that in a follow-up
16:30:37 mordred ++
16:32:12 dtroyer I think that could be limited to osc_lib format_dict(), so we'd pick it up when it that gets released
16:34:20 dtroyer mordred: off-topic: do you have a preferred ansible role to run Gerrit? I have not found one that seems to be an obvious choice that seems actively maintained...
16:35:50 mordred funny story - we're working on making one of those right now :)
16:36:01 mordred dtroyer: so ask me that again in couple of weeks
16:36:31 dtroyer heh, wish I could wait… to be part of windmill?
16:37:31 mordred dtroyer: for opendev - we're aiming to switch from puppet to ansible-driven-docker
16:38:22 mordred dtroyer: that said - we install gerrit from upstream docker containers in the zuul docker-compose file and there's ansible around that to set it up ... maybe there's enough there to be helpful?
16:38:59 mordred https://opendev.org/zuul/zuul/src/branch/master/doc/source/admin/examples/docker-compose.yaml

Earlier   Later