-
Notifications
You must be signed in to change notification settings - Fork 175
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
Multi-document yamls are inconvenient to use in ODC's cli tools #984
Comments
I think a more proper solution is to support
|
sorry wrong button press |
So you'd like "update or add" functionality? Or like "sync to this state if safe". Should it be
I think middle three are redundant and hence confusing, I would probably go with last one, but that requires changing CLI API in non-backward compatible ways. |
On YAMLs:
Looking elsewhere for inspiration:
WRT backward compatibility, we need to get over the fear of breaking things. So long as we do it in a sane way. The obvious course here is to add new command Crazy Damien idea that should not be seen
Let's implement an ODC Kubernetes Operator, which you interact with to update an ODC Database via Kubernetes tools |
I like I wouldn’t rush to remove the old ones as there’s lots of bash scripts, beginners-guides, power point presentations and tutorials that have them. I do like the idea of supporting different record types in one file, like @omad’s example of Kubernetes. I’ve seen many people tripped up by calling the wrong command ( |
Another option is not to remove the old ones entirely, but just make them aliases for the new command. In effect, retiring the more niche options/flags that they take. Beginner tutorials usually say (and I could imagine it occasionally still making a bash script clearer to write |
+1 for |
we can of course implement |
For my 2 cents: I think Whereas With regard to (a potential case for) mixing dataset and product types in one yaml: BTW: very happy to share the Assembler - adapted from eodataset3's - as I think it could add value to eo3 uptake in the ODC community. But that's a topic for another thread - Rob may speak to it in the next SC. |
@mpaget mixing dataset and product definitions in one yaml file is not something we are proposing. Although I can see it being useful in very few cases, something like a DEM stored in one giant file, so it would be one product one dataset sort of deal. Also this would not change auto-matching logic at all, one would still need to make sure that dataset and product definitions are "compatible", so |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I tried to update a set of products recently that were stored in a multi-document yaml:
datacube product update products.yaml.gz
threw an error because one of the products didn't exist yet in the datacube.datacube product add products.yaml.gz
failed because some of the products were different to those stored in the datacube (they need to be updated, not added!)The only way I know to fix this is to split up the file temporarily and
add
them separately.I wish I could tell it: "update ODC to match my whole file" without caring about whether they're updates or additions.
Examples of multi-doc usage are in DEA's metadata-types and products, and some datasets on the NCI.
All document commands have this inconvenience:
(sourced from #983, cc @omad )
The text was updated successfully, but these errors were encountered: