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

Data Collector misses tons of resources #8049

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

Comments

Projects
None yet
2 participants
@jaymzh
Copy link
Member

jaymzh commented Dec 14, 2018

Description

The datacollector code is filled with unless nested_resource?(resource).

Our primary use-case for datacollector is to get the data about child runcontexts we can't access from report handlers or event handlers (see #8044).

Please update datacollector to include nested resources, possibly with a config if necessary.

Chef Version

14.8.12

Platform Version

CentOS 7

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

lamont-granquist commented Dec 19, 2018

So #8063 is going this direction.

The question I've got is what the JSON output should look like? Right now in the action collection I've kept it flat and the wrapping resource appears after all the sub-resources. There's a single integer for how many nesting levels deep the resource is. That's the minimum viable product here most likely, makes it easy for consumers to just rip through the whole thing and not care about nesting at all as well (optimizing for the case where the user cares that there's a file resource on a given file but has no interest in how many levels deep inside of a resource it occurs).

@jaymzh

This comment has been minimized.

Copy link
Member

jaymzh commented Dec 21, 2018

I think the best choice would be to do something like

{
  'name': 'my_resource[dingleberry]',
  'action': ':run',
  ...
  'child_resources': {
    {
      'name': 'template[shoopshoop]',
      'action': ':create',
      ...
    },
    ...
  },
},

This would be useful to be able to debug weird problems, to figure out where two duplicate child-resources in different run contexts were coming from, etc...

I think it's not absolutely necessary to do it this way - your way will get us what we need at the moment. My concern is backcompat. If we do the less-expressive way now, changing it later is hard.

@jaymzh

This comment has been minimized.

Copy link
Member

jaymzh commented Dec 21, 2018

And then if we do that, it'd be useful to may have some helpers like:

find_all_resources(type)

or

get_flattened_list_of_resources
@lamont-granquist

This comment has been minimized.

Copy link
Contributor

lamont-granquist commented Dec 21, 2018

Yeah I'll have to figure out first if the action_collection itself should be organized flat internally and then has methods to expose it nested, or is nested internally and has methods exposed to make it flat.

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