New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Child run contexts #8044

Open
jaymzh opened this Issue Dec 13, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@jaymzh
Copy link
Member

jaymzh commented Dec 13, 2018

Describe the Enhancement:

Please give access to children runcontext from parent runcontexts.

In a report handler, when walking run_context.resources - given how CustomResources now work (with inline resource) it's currently a lie and you lose a ton of data.

Describe the Need:

We want to be able to log and report on what resources were fired during a run, their timing, etc. but currently we only get that for the root context.

Current Alternative

A potential work around (thanks to @jonlives) WOULD be enabling file-based datacollector, then later parsing that file, and later parsing that file, except the DataCollector is littered with unless nested_resource?(resource). :( See #8049

Can We Help You Implement This?:

Please.

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

lamont-granquist commented Dec 14, 2018

so it is easy enough to shove all the child run_contexts into an array off of the run_context.

the next step though is that what you really want is to iterate recursively through all the resource_collections to find resources. there really needs to be a stable API to iterate through the meta-resource_collection and visit every resource, or find every file resource, etc...

i almost wonder if we should wire up the resource collections with parent and child pointers and put the API there. i'm not sure jamming it into the run_context is the best place (because then there's a duplication of concerns), and not sure creating a meta resource_collection object or module is the best idea (again, duplication of concerns). i don't entirely like wiring up pointers across the run_context and the resource_collection because that feels like some duplication as well. i need to noodle on it a bit more...

@jaymzh

This comment has been minimized.

Copy link
Member

jaymzh commented Dec 18, 2018

So I think that assuming the only thing people care about is resource_collection is probably short-sighted.

Wiring up run context seems correct. For example I have code that does stuff like look for queued notifications in the current context, then goes to the parent, repeats until it hits the root.

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

lamont-granquist commented Dec 18, 2018

I think we need another ticket.

"We want to be able to log and report on what resources were fired during a run, their timing, etc. but currently we only get that for the root context."

That task I now think boils down to "fix and generalize the code in the ResourceReporter (and rip out half of the DataCollector as well)" which now looks like it has nothing to do with child run_contexts and is all about hooking the event API.

@jaymzh

This comment has been minimized.

Copy link
Member

jaymzh commented Dec 18, 2018

per Slack chat, this will be for the generic "wanna walk child contexts" and your other PR will be for the resources specifically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment