The project overview¶
When opening the dashboard the project overview page will be the first page greeting you. It has several elements:
Let’s go over what some of these buttons do:
The “inmanta logo” button: takes you back to this page.
List of created projects: Lists all existing projects. For more on projects see the glossary. Clicking on the name of a project will take you to its page.
Project delete button: Deletes the project and all the environments it contains. This will delete the history and environments, but it will not purge the system of changes made or managed by the orchestrator.
Report an issue: If you run into any issues/bugs, this button will take you to a page where you can open a new issue.
Environment navigation button: Displays a list of projects and their environments. Allows navigation to any environment managed by this orchestrator, by simply clicking it’s name.
Add new project button: This will take you through the creation of a new project and the creation of its first environment.
Green checkmark: This will take you to the orchestrator status page, displaying all sorts of useful information about the orchestrator instance. If the dashboard loses its connection to the server, this green checkmark will turn into a red cross.
Create a new project¶
Add new project button we can create new projects:
Create is pressed, you are immediately taken to the “Create a new Environment” screen.
This will help you set up your first environment.
Pressing cancel will leave the project empty.
The two screenshots above are equivalent to the following inmanta-cli commands:
inmanta-cli project create -n dashboard-test inmanta-cli environment create -n quickstart-env -p quickstart -r https://github.com/inmanta/quickstart.git -b master
When in an environment, a new button at the bottom will appear:
This big red button will stop all of the orchestrator’s operations for the current environment.
The Environment Portal¶
Once you press the create button, you will be taken to the portal of the newly created environment:
This environment is currently empty because the model has not been compiled yet.
We can use the
Recompile button to do this.
This will clone the repository if it hadn’t been already and then compile the current model.
There is also an extra option for the recompile, which is
Update project & Recompile.
This will pull in any new commits and then compile the model.
Once the compile has succeeded, the orchestrator will automatically deploy the model. The deployment state is then shown in the portal.
Compile Reports button we can diagnose problems if our compile failed.
You can click the arrow icon next to any item to expand it and see the output of the executed command.
Next, we have the
Force deploy and
Force repair buttons.
Those are similar in function, and can be confusing to new users:
Force deploybutton will go through Every resource and redeploy the resource.
Force repairbutton by contrast, will only go through resources that are currently not in a deployed state.
Finally we have the
Clear buttons, found under the
Decommission dropdown menu:
Decommission: pushes a model that purges all resources deployed by the model.
Edit: change the configuration of the environment, such as the git repo url or what branch to use.
Clone: create a new environment using the same git repo and branch
Clear: Clears the environment. This will remove all versions and compilations. It does not decommission the currently deployed model.
Clear followed by a
Recompile, the version number will be incremented as if the previous versions were still there, but these versions will no longer be present.
The Version Overview¶
Portal we have the
This will take us to an overview of all previously compiled versions of the model and their state.
Do note that a version is created for every compile and this is not tied to the model being updated in git.
Each version has 4 buttons on the right to interact with it:
They are, in order from left to right:
Perform dry run: the orchestrator will go through all resources in the model and compare their current state to their desired state. This can be useful to double-check what effect the deployment of a version might have on your current environment.
Dry run report: will take you to the report of the last performed dry run, without performing a new one.
Release version: If
environment settingsis set to
False, this button can be used to deploy the model, otherwise this button will be grayed out.
Remove version: removes the selected version from the inmanta environment.
Finally, clicking the version number will take us to the overview of that particular version. It gives the same options as the version overview does and it displays a list of all resources and their current state.
Using the filters we can filter for resources by type, by agent used to deploy the resource, by value and by deploy state. This display is continuously updated, both during deploys and after, when the orchestrator goes through all resources to make sure they remain in the desired state.
Taking a closer look at the a specific resource, there are 2 important buttons, the
Dependency button and a
Dependency button is only available if a resource depends on other resources.
When pressed, it will add lines to the table displaying each dependency and it’s current state:
The magnifying glass icon will take us to an in depth overview of the resource. This will show a complete breakdown of the resource’s desired state at the top and an action log at the bottom.
The desired state breakdown allows for easy inspection of the impact the resource will have. For example, the resource in the image below will deploy a file with path /etc/my.cnf and file permission 644. We can even inspect the file’s content.
The action log shows a log of actions taken on the given resource. This varies from dry-runs to deploys. This log will typically start filling up with deploys due to the orchestrator enforcing the desired state. Again we can further inspect an action by pressing the drop down arrow.
Each of these logs can then be further analyzed by pressing the
The Resources Overview¶
The resources overview, not to be confused with the similar resource version overview, gives an overview of all known resources. This is not only for resources of the currently deployed model, but potentially resources from older models and the state they are in.
While not as in depth as the resource version overview, it does link every resource to its deployed version, so the resource can be inspected there.
The Parameters View¶
The parameter overview gives a list of parameters. Parameters are part of the model, but their value may or may not be known at compile time. For example, the IP address of a virtual machine that is created by the model.
Each parameter can be individually inspected or deleted. Inspecting the resource allows us to read additional metadata if any is available.
The Agent Overview¶
The agent overview shows different agents and the state they are in.
This overview allows us to
Force deploy and
Force repair resources on a per agent basis.
Pausing an agent stops deployments for that agent.
Useful when, for example, diagnosing problems on the machine the agent deploys to, without having to stop enforcement of the whole model.
The Agent Processes overview, lists the different processes running agents.
Clicking on the
magnifying glass allows us to inspect each process in more detail:
Here we can find the process
pid, the ip addresses the server has bound to and what version of Python inmanta is running on, amongst other things.
The settings menu shows settings that are configured per environment.
Hovering over the information icon tells you what each setting does, the edit icon allows for updating the setting and the delete button clears the setting and applies a default value if available.