Why are JoinedTimestamp and JoinedMethod missing from the results?

[Iain Samuel McLean Elder]

For the same reason I closed #34, I'm fine with this extra metadata not being handled by Botocove. Botocove should focus on the iteration of accounts and the collection of function results.

But I wanted to check because the data is right there so maybe it was just missed.

I've just run into a situation where I need the JoinedDate of the account to explain some behavior.

For now I can solve it by listing the accounts separately and joining by the account ID to compare the JoinedDate to the function result.

[Dave Connell]

No particular reason besides it's hard to gauge what's a useful addition to returned data and what's extra noise. As you say, it's not in the mission of the tool - but I'm not opposed to it being present if it's helpful.

Those kind of decisions are all over the codebase - for example, I spotted this while thinking about the extra metadata -one day someone will have an org and some extra "org-gapped" accounts or something and this will annoy them:

    def _generate_account_sessions(self) -> Iterable[CoveSessionInformation]:
        for region in self.target_regions:
            for account_id in self.target_accounts:
                if self.account_data is not None:

                    # If running with target accounts, but with organization data
                    # available, i.e., running from org master but not targeting
                    # whole org.
                    if account_id not in self.account_data:
                        raise ValueError(
                            f"Account {account_id} is not ACTIVE in the organization."
                        )

since there's a valid case for using a custom role in all org accounts plus some non-org accounts that trust the org master still. I think we'd go mad trying to please every hypothetical edge case (and I'd suggest that person just runs two cove funcs now I've thought about it :) ).

[Iain Samuel McLean Elder]

Although it doesn't affect me just now, the code you point out does bother me for the reasons you say.

It could be solved by separating the selection of accounts and roles from the iteration and collection of results.

The session iteration, function application, and result collection are the three core features that botocove needs to do.

Botocove currently also handles the account/region/role selection. It covers my use case today, but it lacks flexibility to cover all use cases.

I'd like to refactor this part out. I'd like to pass a "Selection" object or a "Selector" function to the cove function that botocove queries to get the selection.

The Selection/Selector default value would implement the current behavior, so that existing botocove calls will work unchanged.

Any other behavior could then be passed in by the user if they have other requirements. Common other use cases could be added to a library of Selectors.

For example, a selector that runs over the AWS CLI config file would allow arbitrarily complex account lists and role configurations. In fact, I think I might need something like this for my next project.

I had attempted to do something like this in my attempt to refactor around the "org_master" option, but I hit a dead end because the scope of the work was too big.

Now that the other changes have already been made, and I have a more articulate idea of the new change I want to make, I think I'd like to make that refactoring again when I have time.

Is this a feature you'd like to see in Botocove?

[Iain Samuel McLean Elder]

The question that prompted this issue is answered, so I will close it, and for now I won't add any more fields.

Another reason for this "Selector" object would allow me to pre-load the org accounts once with all the metadata I need for my analyses, either from ListAccounts directly or other source.

The pre-loaded list of org accounts would make iterative development much quicker in a large org because I would be able to run the function quickly on one account using "include_ids" without having to wait for the whole ListAccounts operation to complete each time.

I would create a new issue to track the Selector refactoring if you think it would be helpful.