-
Notifications
You must be signed in to change notification settings - Fork 467
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
Docs updates #229
Docs updates #229
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some suggestions but going in the right direction!
docs/book/core-concepts.md
Outdated
@@ -152,6 +154,10 @@ zenml stack register STACK_NAME \ | |||
-o ORCHESTRATOR_NAME | |||
``` | |||
|
|||
**Container Registry** | |||
|
|||
Container registries are where pre-built (Docker) containers are hosted, ready for use in various configurations. A ZenML workflow involving a container registry would see you spinning up a Kubernetes cluster and then deploying a pipeline to be run on Kubeflow Pipelines. As part of the deployment to the cluster, the ZenML base image would be downloaded and used as the basis for the deployed 'run'. When you are running a local Kubeflow stack, you will also have a local container registry which stores the container images you create that bundle up your pipeline code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably makes sense to make this a bit more general. A container registry is basically a store for docker images. The local variant of this is used to push a new docker image that is created based off a base image or custom image of your choice. However in the future there can be a cloud variant which points to hosted registries for example the Google container registry or dockerhub
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The newly created images are pushed to the container registry specified in the stack, this however is not limited to a local registry (even now, it is entirely possible to specify a gcr.io/... registry URL as long as the local docker client is authorized to push to that registry).
docs/book/core-concepts.md
Outdated
A materializer defines how and where Artifacts live in between steps. | ||
A materializer defines how and where Artifacts live in between steps. It is used to convert a ZenML artifact into a specific format. They are most often used to handle the input or output of ZenML steps, and can be extended by building on the `BaseMaterializer` class. We care about this because steps are not just isolated pieces of work; they are linked together and the outputs of one step might well be the inputs of the next. | ||
|
||
We have some built-in ways to serialize and deserialize the data flowing between steps. Of course, if you are using some library or tool which doesn't work with our built-in options, you can write [your own custom materializer](https://docs.zenml.io/guides/low-level-api/chapter-5) to ensure that your data can be passed from step to step in this way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe write here about the fileio role in this. I.e using the fileio we ensure it works across artifact stores?
@htahir1 should be better now |
Pre-requisites
Please ensure you have done the following:
Types of changes
Describe changes
Docs updates as discussed.