API Documentation
In this section you will find links to the API documentation of metal-stack components.
Click here to go to the documentation for the latest stable release.'; + div.appendChild(closer); + document.body.appendChild(div); +} + +if (document.readyState === "loading") { + document.addEventListener("DOMContentLoaded", maybeAddWarning); +} else { + maybeAddWarning(); +} diff --git a/previews/PR232/assets/youtube.css b/previews/PR232/assets/youtube.css new file mode 100644 index 0000000000..bf93bab32b --- /dev/null +++ b/previews/PR232/assets/youtube.css @@ -0,0 +1,17 @@ +.video-container { + position: relative; + padding-bottom: 56.25%; + padding-top: 0; + height: 0; + overflow: hidden; +} + +.video-container iframe, +.video-container object, +.video-container embed { + position: absolute; + top: 0; + left: 0; + width: 100%; + height: 100%; +} diff --git a/previews/PR232/development/client_libraries/index.html b/previews/PR232/development/client_libraries/index.html new file mode 100644 index 0000000000..b96da5198a --- /dev/null +++ b/previews/PR232/development/client_libraries/index.html @@ -0,0 +1,2 @@ + +
Client Libraries
Our public-facing APIs are built on swagger, which allows you generating API clients in all sorts of programming languages.
For the metal-api we officially support the following client libraries:
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Contributing
This document describes the way we want to contribute code to the projects of metal-stack, which are hosted on github.com/metal-stack.
The document is meant to be understood as a general guideline for contributions, but not as burden to be placed on a developer. Use your best judgment when contributing code. Try to be as clean and precise as possible when writing code and try to make your code as maintainable and understandable as possible for other people.
Even if it should go without saying, we live an open culture of discussion, in which everybody is welcome to participate. We treat every contribution with respect and objectiveness with the general aim to write software of quality.
If you want, feel free to propose changes to this document in a pull request.
How Can I Contribute?
Open a Github issue in the project you would like to contribute. Within the issue, your idea can be discussed. It is also possible to directly create a pull request when the set of changes is relatively small.
Pull Requests
The process described here has several goals:
- Maintain quality
- Enable a sustainable system to review contributions
- Enable documented and reproducible addition of contributions
- Create a meaningful issue describing the WHY? of your contribution
- Create a repository fork within the context of that issue.
- Create a Draft Pull Request to the master branch of the target repository.
- Develop, document and test your contribution (try not to solve more than one issue in a single pull request)
- Ask for merging your contribution by removing the draft marker
- If code owners are defined, try to assign the request to a code owner
General Objectives
This section contains language-agnostic topics that all metal-stack projects are trying to follow.
Code Ownership
The code base is owned by the entire team and every member is allowed to contribute changes to any of the projects. This is considered as collective code ownership[1].
As a matter of fact, there are persons in a project, which already have experience with the sources. These are defined directly in the repository's CODEOWNERS file. If you want to merge changes into the master branch, it is advisable to include code owners into the process of discussion and merging.
Microservices
One major ambition of metal-stack is to follow the idea of microservices. This way, we want to achieve that we can
- adapt to changes faster than with monolithic architectures,
- be free of restrictions due to certain choices of technology,
- leverage powerful traits of cloud infrastructures (e.g. high-scalability, high-availability, ...).
Programming Languages
We are generally open to write code in any language that fits best to the function of the software. However, we encourage golang to be the main language of metal-stack as we think that it makes development faster when not establishing too many different languages in our architecture. Reason for this is that we are striving for consistent behavior of the microservices, similar to what has been described for the Twelve-Factor App (see 12 Factor). We help enforcing unified behavior by allowing a small layer of shared code for every programming language. We will refer to this shared code as "libraries" for the rest of this document.
Artifacts
Artifacts are always produced by a CI process (Github Actions).
Docker images are published on the Github Container Registry of the metal-stack organization.
Binary artifacts or OS images can be uploaded to images.metal-stack.io if necessary.
When building Docker images, please consider our build tool docker-make or the specific docker-make action respectively.
APIs
We are currently making use of Swagger when we exposing traditional REST APIs for end-users. This helps us with being technology-agnostic as we can generate clients in almost any language using go-swagger. Swagger additionally simplifies the documentation of our APIs.
Most APIs though are not required to be user-facing but are of technical nature. These are preferred to be implemented using grpc.
Versioning
Artifacts are versioned by tagging the respective repository with a tag starting with the letter v. After the letter, there stands a valid semantic version.
Documentation
In order to make it easier for others to understand a project, we document general information and usage instructions in a README.md in any project.
In addition to that, we document a microservice in the docs repository. The documentation should contain the reasoning why this service exists and why it was being implemented the way it was being implemented. The aim of this procedure is to reduce the time for contributors to comprehend architectural decisions that were made during the process of writing the software and to clarify the general purpose of this service in the entire context of the software.
Guidelines
This chapter describes general guidelines on how to develop and contribute code for a certain programming language.
Golang
Development follows the official guide to:
- Write clear, idiomatic Go code[2]
- Learn from mistakes that must not be repeated[3]
- Apply appropriate names to your artifacts:
- Enable others to understand the reasoning of non-trivial code sequences by applying a meaningful documentation.
Development Decisions
- Dependency Management by using Go modules
- Build and Test Automation by using GNU Make.
- End-user APIs should consider using go-swagger and Go-Restful Technical APIs should consider using grpc
Libraries
metal-stack maintains several libraries that you should utilize in your project in order unify common behavior. Some of these projects are:
Error Handling with Generated Swagger Clients
From the server-side you should ensure that you are returning the common error json struct in case of an error as defined in the metal-lib/httperrors. Ensure you are using go-restful >= v2.9.1 and go-restful-openapi >= v0.13.1 (allows default responses with error codes other than 200).
Documentation
We want to share knowledge and keep things simple. If things cannot kept simple we want enable everybody to understand them by:
- Document in short sentences[4].
- Do not explain the HOW (this is already documented by your code and documenting the obvious is considered a defect).
- Explain the WHY. Add a "to" in your documentation line to force yourself to explain the reasonning (e.g. "
<THE WHAT> to <THE TO>").
Python
Development follows the official guide to:
- Style Guide for Python Code (PEP 8)[5]
- The use of an IDE like PyCharm helps to write compliant code easily
- Consider setuptools for packaging
- If you want to add a Python microservice to the mix, consider pyinstaller on Alpine to achieve small image sizes
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Distributed Metal Control Plane
Problem Statement
We face the situation that we argue for running bare metal on premise because this way the customers can control where and how their software and data are processed and stored. On the other hand, we have currently decided that our metal-api control plane components run on a kubernetes cluster (in our case on a cluster provided by one of the available hyperscalers).
Running the control plane on Kubernetes has the following benefits:
- Ease of deployment
- Get most, if not all, of the required infrastructure services like (probably incomplete):
- IPs
- DNS
- L7-Loadbalancing
- Storage
- S3 Backup
- High Availability
Using a kubernetes as a service offering from one of the hyperscalers, enables us to focus on using kubernetes instead of maintaining it as well.
Goal
It would be much saner if metal-stack has no, or only minimal dependencies to external services. Imagine a metal-stack deployment in a plant, it would be optimal if we only have to deliver a single rack with servers and networking gear installed and wired, plug that rack to the power supply and a internet uplink and its ready to go.
Have a second plant which you want to be part of all your plants? Just tell both that they are part of something bigger and metal-api knows of two partitions.
Possible Solutions
We can think of two different solutions to this vision:
- Keep the central control plane approach and require some sort of kubernetes deployment accessible from the internet. This has the downside that the user must, provide a managed kubernetes deployment in his own datacenter or uses a hyperscaler. Still not optimal.
- Install the metal-api and all its dependencies in every partition, replicate or shard the databases to every connected partition, make them know each other. Connect the partitions over the internet with some sort of vpn to make the services visible to each other.
As we can see, the first approach does not really address the problem, therefore i will describe solution #2 in more details.
Central/Current setup
Stateful services
Every distributed system suffer from handling state in a scalable, fast and correct way. To start how to cope with the state, we first must identify which state can be seen as partition local only and which state must be synchronous for read, and synchronous for writes across partitions.
Affected states:
- masterdata: e.g. tenant and project must be present in every partition, but these are entities which are read often but updates are rare. A write can therefore be visible with a decent delay in a distinct partition with no consequences.
- ipam: the prefixes and ip´s allocated from machines. These entities are also read often and rare updates. But we must differentiate between dirty reads for different types. A machine network is partition local, ips acquired from such a network must by synchronous in the same partition. Ips acquired from global networks such as internet must by synchronous for all partitions, as otherwise a internet ip could be acquired twice.
- vrf ids: they must only be unique in one partition
- image and size configurations: read often, written seldom, so no high requirements on the storage of these entities.
- images: os images are already replicated from a central s3 storage to a per partition s3 service. metal-hammer kernel and initrd are small and pull always from the central s3, can be done similar to os images.
- machine and machine allocation: must be only synchronous in the partition
- switch: must be only synchronous in the partition
- nsq messages: do not need to cross partition boundaries. No need to keep the messages persistent, even the opposite is true, we don't want to have the messages persist for a longer period.
Now we can see that the most critical state to held and synchronize are the IPAM data, because these entities must be guaranteed to be synchronously updated, while being updated frequently.
Datastores:
We use three different types of datastores to persist the states of the metal application.
- rethinkdb is the main datastore for almost all entities managed by metal-api
- postgresql is used for masterdata and ipam data.
- nsq uses disk and memory tho store the messages.
Stateless services
These are the easy part, all of our services which are stateless can be scaled up and down without any impact on functionality. Even the stateful services like masterdata and metal-api rely fully on the underlying datastore and can therefore also be scaled up and down to meet scalability requirements.
Albeit, most of these services need to be placed behind a loadbalancer which does the L4/L7 balancing across the started/available replicas of the service for the clients talking to it. This is actually provided by kubernetes with either service type loadbalancer or type clusterip.
One exception is the metal-console service which must have the partition in it´s dns name now, because there is no direct network connectivity between the management networks of the partitions. See "Network Setup)
Distributed setup
State
In order to replicate certain data which must be available across all partitions we can use on of the existing open source databases which enable such kind of setup. There are a few available out there, the following incomplete list will highlight the pro´s and cons of each.
RethinkDB
We already store most of our data in RethinkDB and it gives already the ability to synchronize the data in a distributed manner with different guarantees for consistency and latency. This is described here: Scaling, Sharding and replication. But because rethinkdb has a rough history and unsure future with the last release took more than a year, we in the team already thought that we eventually must move away from rethinkdb in the future.
Postgresql
Postgres does not have a multi datacenter with replication in both directions, it just can make the remote instance store the same data.
CockroachDB
Is a Postgresql compatible database engine on the wire. CockroachDB gives you both, ACID and geo replication with writes allowed from all connected members. It is even possible to configure Follow the Workload and Geo Partitioning and Replication.
If we migrate all metal-api entities to be stored the same way we store masterdata, we could use cockroachdb to store all metal entities in one ore more databases spread across all partitions and still ensure consistency and high availability.
A simple setup how this would look like is shown here.
go-ipam was modified in a example PR here: PR 17
API Access
In order to make the metal-api accessible for api users like cloud-api or metalctl as easy at it is today, some effort has to be taken. One possible approach would be to use a external loadbalancer which spread the requests evenly to all metal-api endpoints in all partitions. Because all data are accessible from all partitions, a api request going to partition A with a request to create a machine in partition B, will still work. If on the other hand partition B is not in a connected state because the interconnection between both partitions is broken, then of course the request will fail.
IMPORTANT The NSQ Message to inform metal-core must end in the correct partition
To provide such a external loadbalancer we have several opportunities:
- Cloudflare or comparable CDN service.
- BGP Anycast from every partition
Another setup would place a small gateway behind the metal-api address, which forwards to the metal-api in the partition where the request must be executed. This gateway, metal-api-router must inspect the payload, extract the desired partition, and forward the request without any modifications to the metal-api endpoint in this partition. This can be done for all requests, or if we want to optimize, only for write accesses.
Network setup
In order to have the impact to the overall security concept as minimal as possible i would not modify the current network setup. The only modifications which has to be made are:
- Allow https ingress traffic to all metal-api instances.
- Allow ssh ingress traffic to all metal-console instances.
- Allow CockroachDB Replication between all partitions.
- No NSQ traffic from outside required anymore, except we cant solve the topic above.
A simple setup how this would look like is shown here, this does not work though because of the forementioned NSQ issue.
Therefore we need the metal-api-router:
Deployment
The deployment of our components will substantially differ in a partition compared to a the deployment we have actually. Deploying it in kubernetes in the partition would be very difficult to achieve because we have no sane way to deploy kubernetes on physical machines without a underlying API. I would therefore suggest to deploy our components in the same way we do that for the services running on the management server. Use systemd to start docker containers.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
SONiC Support
As writing this proposal, metal-stack only supports Cumulus on Broadcom ASICs. Unfortunately, after the acquisition of Cumulus Networks by Nvidia, Broadcom decided to cut its relationship with Cumulus, and therefore Cumulus 4.2 is the last version that supports Broadcom ASICs. Since trashing the existing hardware is not a solution, adding support for a different network operating system is necessary.
One of the remaining big players is SONiC, which Microsoft created to scale the network of Azure. It's an open-source project and is now part of the Linux Foundation.
For a general introduction to SONiC, please follow the Architecture official documentation.
ConfigDB
On a cold start, the content of /etc/sonic/config_db.json will be loaded into the Redis database CONFIG_DB, and both contain the switch's configuration except the BGP unnumbered configuration, which still has to be configured directly by the frr configuration files. The SONiC community is working to remove this exception, but no release date is known.
BGP Configuration
Frr runs inside a container, and a shell script configured it on the container startup. For BGP unnumbered, we must set the configuration variable docker_routing_config_mode to split to prevent SONiC from overwriting our configuration files created by metal-core. But by using the split mode, the integrated configuration mode of frr is deactivated, and we have to write our BGP configuration to the daemon-specific files bgp.conf, staticd.conf, and zebra.conf instead to frr.conf.
elif [ "$CONFIG_TYPE" == "split" ]; then
+ echo "no service integrated-vtysh-config" > /etc/frr/vtysh.conf
+ rm -f /etc/frr/frr.confReference: docker-init
Adding support for the integrated configuration mode, we must at least adjust the startup shell script and the supervisor configuration:
{% if DEVICE_METADATA.localhost.docker_routing_config_mode is defined and DEVICE_METADATA.localhost.docker_routing_config_mode == "unified" %}
+[program:vtysh_b]
+command=/usr/bin/vtysh -bReference: supervisord.conf
Non-BGP Configuration
For the Non-BGP configuration we have to write it into the Redis database directly or via one of the following interfaces:
config replace <file>- the Mgmt Framework
- the SONiC restapi
Directly writing into the Redis database isn't a stable interface, and we must determine the create, delete, and update operations on our own. The last point is also valid for the Mgmt Framework and the SONiC restapi. Furthermore, the Mgmt Framework doesn't start anymore for several months, and a potential fix is still not merged. And the SONiC restapi isn't enabled by default, and we must build and maintain our own SONiC images.
Using config replace would reduce the complexity in the metal-core codebase because we don't have to determine the actual changes between the running and the desired configuration. The approach's drawbacks are using a version of SONiC that contains the PR Yang support for VXLAN, and we must provide the whole new startup configuration to prevent unwanted deconfiguration.
Configure Loopback interface and activate VXLAN
{
+ "LOOPBACK_INTERFACE": {
+ "Loopback0": {},
+ "Loopback0|<loopback address/32>": {}
+ },
+ "VXLAN_TUNNEL": {
+ "vtep": {
+ "src_ip": "<loopback address>"
+ }
+ }
+}Configure MTU
{
+ "PORT": {
+ "Ethernet0": {
+ "mtu": "9000"
+ }
+ }
+}Configure PXE Vlan
{
+ "VLAN": {
+ "Vlan4000": {
+ "vlanid": "4000"
+ }
+ },
+ "VLAN_INTERFACE": {
+ "Vlan4000": {},
+ "Vlan4000|<metal core cidr>": {}
+ },
+ "VLAN_MEMBER": {
+ "Vlan4000|<interface>": {
+ "tagging_mode": "untagged"
+ }
+ },
+ "VXLAN_TUNNEL_MAP": {
+ "vtep|map_104000_Vlan4000": {
+ "vlan": "Vlan4000",
+ "vni": "104000"
+ }
+ }
+}Configure VRF
{
+ "INTERFACE": {
+ "Ethernet0": {
+ "vrf_name": "vrf104001"
+ }
+ },
+ "VLAN": {
+ "Vlan4001": {
+ "vlanid": "4001"
+ }
+ },
+ "VLAN_INTERFACE": {
+ "Vlan4001": {
+ "vrf_name": "vrf104001"
+ }
+ },
+ "VRF": {
+ "vrf104001": {
+ "vni": "104001"
+ }
+ },
+ "VXLAN_TUNNEL_MAP": {
+ "vtep|map_104001_Vlan4001": {
+ "vlan": "Vlan4001",
+ "vni": "104001"
+ }
+ }
+}DHCP Relay
The DHCP relay container only starts if DEVICE_METADATA.localhost.type is equal to ToRRouter.
LLDP
SONiC always uses the local port subtype for LLDP and sets it to some freely configurable alias field of the interface.
# Get the port alias. If None or empty string, use port name instead
+port_alias = port_table_dict.get("alias")
+if not port_alias:
+ self.log_info("Unable to retrieve port alias for port '{}'. Using port name instead.".format(port_name))
+ port_alias = port_name
+
+lldpcli_cmd = "lldpcli configure ports {0} lldp portidsubtype local {1}".format(port_name, port_alias)Reference: lldpmgr
Mgmt Interface
The mgmt interface is eth0. To configure a static IP address and activate the Mgmt VRF, use:
{
+ "MGMT_INTERFACE": {
+ "eth0|<mgmt cidr>": {
+ "gwaddr": "<mgmt gateway>"
+ }
+ },
+ "MGMT_VRF_CONFIG": {
+ "vrf_global": {
+ "mgmtVrfEnabled": "true"
+ }
+ }
+}IP forwarding is deactivated on eth0, and no IP Masquerade is configured.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Auditing of metal-stack resources
Currently no logs of the ownership of resources like machines, networks, ips and volumes are generated or kept. Though due to legal requirements data centers are required to keep track of this ownership over time to prevent liability issues when opening the platform for external users.
In this proposal we want to introduce a flexible and low-maintenance approach for auditing on top of Meilisearch.
Overview
In general our auditing logs will be collected by a request interceptor or middleware. Every request and response will be processed and eventually logged to Meilisearch. Meilisearch will be configured to regularly create chunks of the auditing logs. These finished chunks will be backed up to a S3 compatible storage with a read-only option enabled.
Of course sensitive data like session keys or passwords will be redacted before logging. We want to track relevant requests and responses. If auditing the request fails, the request itself will be aborted and will not be processed further. The requests and responses that will be audited will be annotated with a correlation id.
Transferring the meilisearch auditing data chunks to the S3 compatible storage will be done by a sidecar cronjob that is executed periodically. To avoid data manipulation the S3 compatible storage will be configured to be read-only.
Whitelisting
To reduce the amount of unnecessary logs we want to introduce a whitelist of resources and operations on those that should be logged. Other requests will be passed directly to the next middleware or web service without any further processing.
As we are only interested in mutating endpoints, we ignore all GET requests. The whitelist includes all POST, PUT, PATCH and DELETE endpoints of the HTTP middleware except for the following (non-manipulating) route suffixes:
/find/notify/tryand/match/capacity/from-hardware
Regarding GRPC audit trails, they are not so interesting because only internal clients are using this API. However, we can log the trails of the Boot service, which can be interesting to revise the machine lifecycle.
Chunking in Meilisearch
We want our data to be chunked in Meilisearch. To accomplish this, we rotate the index identifier on a scheduled basis. The index identifiers will be derived from the current date and time.
To keep things simple, we only support hourly, daily and monthly rotation. The eventually prefixed index names will only include relevant parts of date and time like 2021-01, 2021-01-01 or 2021-01-01_13.
The metal-api will only write to the current index and switches to the new index on rotation. The metal-api will never read or update data in any indices.
Moving chunks to S3 compatible storage
As Meilisearch will be filled with data over time, we want to move completed chunks to a S3 compatible storage. This will be done by a sidecar cronjob that is executed periodically. Note that the periods of the index rotation and the cronjob execution don't have to match.
When the backup process gets started, it initiates a Meilisearch dump of the whole database across all indices. Once the returned task is finished, the dump must be copied from a Meilisearch volume to the S3 compatible storage. After a successful copy, the dump can be deleted.
Now we want to remove all indices from Meilisearch, except the most recent one. For this, we get all indices, sort them and delete each index except the most recent one to avoid data loss.
For the actual implementation, we can build upon backup-restore-sidecar. But due to the index rotation and the fact, that older indices need to be deleted, this probably does not fit into the mentioned sidecar.
S3 compatible storage
The dumps of chunks should automatically deleted after a certain amount of time, once we are either no longer allowed or required to keep them. The default retention time will be 6 months. Ideally already uploaded chunks should be read-only to prevent data manipulation.
A candidate for the S3 compatible storage is Google Cloud Storage, which allows to configure automatic expiration of objects through a lifecycle rule.
Affected components
- metal-api grpc server needs an auditing interceptor
- metal-api web server needs an auditing filter chain / middleware
- metal-api needs new command line arguments to configure the auditing
- mini-lab needs a Meilisearch instance
- mini-lab may need a local S3 compatible storage
- we need a sidecar to implement the backup to S3 compatible storage
- Consider auditing of volume allocations and freeings outside of metal-stack
Alternatives considered
Instead of using Meilisearch we investigated using an immutable database like immudb. But immudb does not support chunking of data and due to its immutable nature, we will never be able to free up space of expired data. Even if we are legally allowed or required to delete data, we will not be able to do so with immudb.
In another variant of the Meilisearch approach the metal-api would also be responsible for copying chunks to the S3 compatible storage and deleting old indices. But separating the concerns allows completely different implementations for every deployment stage.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Rack Spreading
Currently, when creating a machine through the metal-api, the machine is placed randomly inside a partition. This algorithm does not consider spreading machines across different racks and different chassis. This may lead to the situation that a group of machines (that for example form a cluster) can end up being placed in the same rack and the same chassis.
Spreading a group of machines across racks can enhance availability for scenarios like a rack loosing power or a chassis meltdown.
So, instead of just randomly deciding the placement of a machine candidate, we want to propose a placement strategy that attempts to spread machine candidates across the racks inside a partition.
Furthermore a followup improvement to guarantee that machines are really spread across multiple racks, even if multiple machines are ordered in parallel, was implemented with PR490.
Placement Strategy
Machines in the project are spread across all available racks evenly within a partition (best effort). For this, an additional request to the datastore has to be made in order to find allocated machines within the project in the partition.
The algorithm will then figure out the least occupied racks and elect a machine candidate randomly from those racks.
The user can optionally pass placement tags which will be considered for spreading the machines as well (this will for example allow spreading by a cluster id tag inside the same project).
API
// service/v1/machine.go
+
+type MachineAllocation struct {
+ // existing fields are omitted for readability
+ PlacementTags []string `json:"placement_tags" description:"by default machines are spread across the racks inside a partition for every project. if placement tags are provided, the machine candidate has an additional anti-affinity to other machines having the same tags"`
+}Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
marp: true theme: metal-stack paginate: true footer: Gerrit Schwerthelm – x-cellent technologies GmbH — metal-stack Training backgroundImage: url("https://metal-stack.io/images/shape/banner.png") –- <!– _class: cover lead –>
<!– _class: cover lead –>
Multi-Partition-Layout
<!– _class: lead _backgroundColor: #1f1f1f _backgroundImage: _footer: "" –> 
<!– _class: lead _backgroundColor: #1f1f1f _backgroundImage: _footer: "" –> 
<style>section { font-size: 30px; }</style>
Multi-Partition-Layout Properties
- Fully independent locations with own storage and own node networks
- Clusters can only be created independent in every location
- Failover mechanism for deployed applications requires duplicated deployments, which can serve independently
- Failover through BGP
- If cluster nodes are spread across partitions (not implemented yet), nodes will not be able to reach each other
- Would require an overlay network for inter-node-communication
<!– _class: cover lead –>
Single-Partition-Layout
<!– _class: lead _backgroundColor: #1f1f1f _backgroundImage: _footer: "" –> 
<style>section { font-size: 30px; }</style>
Single-Partition-Layout Properties
- Multiple groups of racks at multiple locations but connected to same CLOS topology
- All racks can connect to the same storage network
- Nodes in private networks can communicate
- When creating a cluster, nodes will be randomly spread across the racks
- Possible improvement of this situation, see
MEP-12: Rack Spreading
- Possible improvement of this situation, see
MEP-12: Rack Spreading
- Instead of selecting a machine from a machine pool randomly
- Get all existing machines in the same project and count to which rack they belong
- Place machine on the rack with the least amount of machines already allocated
- Best effort only
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Independence from external sources
In certain situations some customers may need to operate and create machines without making use of external services like DNS or NTP through the internet. To make this possible, all metal-stack components reaching external services need to be configurable with custom endpoints.
So far, the following components have been identified as requiring changes:
- pixiecore
- metal-hammer
- metal-images
More components are likely to be added to the list during processing. For DNS and NTP servers it should be possible to provide default values within a partition. They can either be inherited from machines and firewalls or overwritten with own ones.
pixiecore
A NTP server endpoint need to be configured on the pixiecore. This can be achieved by providing it through environment variables on start up.
metal-hammer
If using a self-deployed NTP server, also the metal-hammer need to be configured with it. For backward compatibility, default values from pool.ntp.org and time.google.com are used.
metal-images
Configurations for the metal-images are different for machines and firewalls.
metalctl
In order to pass DNS and NTP servers to partitions and machines while creating them, the flags dnsservers and ntpservers need to be added.
The implementation of this MEP will make metal-stack possible to create and maintain machines without requiring an internet connection.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
HAL Improvements
Currently, we have a specific list of hardware vendors and models that we support with metal-stack. This list is documented in docs.metal-stack.io.
Vendor support needs to be implemented in our "hardware abstraction layer" (HAL) called go-hal once the particular set of hardware arrives.
Over the past few years, it has become clear that potential users are always interested in using more and different types of hardware, either because they want to reuse their existing hardware or because their companies are tied to specific vendors. It would be a great improvement for them to have broader support for hardware in general, similar to what is promised by projects like OpenStack Ironic.
We have found that vendor support is hard to implement and even harder to test and maintain. We have some really sophisticated parts in our code base, reaching down to patching BIOS XMLs for individual BIOS versions of specific motherboards. It is almost impossible to touch these pieces of code again because it could break the implementation for specific hardware.
So with this MEP, we want to evaluate ways to improve our code to make it easier to add new vendors, increase the reliability of the implementation, and provide broader hardware support more quickly.
While we continue to have a list of vendors and models for which we verified our integration works, we will also be able to say that we have general support for a number of drivers, starting with IPMI, Redfish, iDrac and Unmanaged (e.g. for developer usage in the mini-lab).
Vendors that implement these driver APIs properly may work right out of the box through our default implementation for a given driver. Through a CLI operators can quickly figure out if the existing implementation is sufficient or not. If a vendor requires specific modifications of the default implementation a dedicated vendor-overwrite can be implemented in go-hal (which will be required for Supermicro for sure).
Shortcomings of the current implementation
- Every new vendor has to be individually whitelisted in go-hal, a new board of a Supermicro server potentially requires a pull request.
- The current interface implements functions using different underlying drivers whenever it fits, so it's not obvious if IPMI or Redfish is used, sometimes information from different protocols differ.
- There are almost no unit tests and no automated integration tests (despite indirect integration testing through our release integration, which is creating and deleting machines).
- The CLI is not implementing the entire API interface. It is implemented only roughly. To use it for testing, it requires ad hoc code changes and recompilation.
- There is no possibility for an operator to provide the user / password that a server was shipped with in order to initialize it with these credentials. Such that the metal-hammer must be booted first before it can be managed through BMC. This also implies that the implementation relies on inband to work.
Bundling Functionality in the metal-bmc
In order to minimize the BMC interface and spread library usage, we should try to bundle as much of the implementation as possible in a single microservice. This microservice should have a proto / gRPC API for access.
A suitable microservice is already in place on the mgmt-servers called the metal-bmc, which can be extended for this purpose. The metal-bmc will implement the server API. The API can be called by the metal-api (indirectly through NSQ), the metal-hammer and a metal-bmc CLI.
In general, it should be preferred to run actions from remote (a.k.a outband) in order to have the functionality easily accessible for other services. Another advantage is to only bundle heavy-weight proprietary tools like sum in a single component. There are only few exceptions where for example an IPMI inband connection is required. For this, we need to offer a special package, which purpose can be described as enabling a server to be managed from remote. This is explained in more detail in a later section of this MEP.
metal-bmc CLI
The CLI of the new metal-bmc API must become a first-class citizen in order to simplify testing the API. The entire new API should be generically implemented such that operators can run commands easily against a BMC.
Additions to the metal-api
In order to have earliest possible discovery of a machine and allow potential BMC management without having to run the metal-hammer, a new table in the metal-api named bmc is proposed. The primary key for this table is a BMC's mac address.
This table contains the available drivers to access a machine with, which is tried to be automatically discovered through the metal-bmc. It may be that the table entries do not have an association to a machine ID directly. This is also not required in order to issue commands against the machines. A relation can be established at a later point (in most cases automatically done by the metal-hammer), such that the existing commands like metalctl machine power/boot/... continue to work.
New Approach for Bootstrapping
After a server is mounted in a rack in the data center, the BMC of a server gets connected to a management switch. The BMC obtains an IP address via DHCP broadcast from a DNS server, typically running on an mgmt-server in the data center partition. Then, the metal-bmc periodically checks the DHCP lease list in order to discover new BMCs or update existing ones.
So far, nothing new here. But now it's getting different:
For every DHCP entry, the metal-bmc looks up the BMC in the new metal-api bmc table.
If it does not find an entity in the database, it performs an "auto discovery". In this process, the metal-bmc tries to automatically discover available BMC drivers for this server (e.g. for IPMI through RMCP like idiscover, etc.).
It then reports this BMC to the metal-api containing the mac address, IP and possible drivers.
A user might provide connection details for specific drivers or select a different default driver for BMC management. It is now theoretically possible to interact with the machine BMC through the metal-api. Note that the metal-hammer was not yet involved.
If there is already an entity found in the bmc table, the metal-bmc attempts to update the BMC information. If, in addition to that, credentials are already provided to access the machine, the metal-bmc can additionally figure out a machine UUID related to the BMC address it can establish a relation between BMC table and machine table by updating the machine ID field in the bmc table and also update information about the board.
When a machine gets connected to the leaf switches and boots for the first time, the metal-hammer is run through PXE boot.
The metal-hammer gets access to the BMC API as well as to the metal-api through the pixiecore. The metal-hammer will lookup the BMC in the metal-api by the locally discovered UUID. If there is a relation between the machine and the BMC already, the metal-hammer does not need to do anything specific. It may call the new BMC API at any given point during the provisioning sequence.
If there is no relation yet, the metal-hammer attempts to establish this relation by using IPMI inband information. The metal-hammer tries to figure out the BMC mac address and attempts to generate a privileged IPMI user and password. If this works, then the metal-hammer updates the BMC table with working access credentials. This way, it is not strictly required for operators to manually insert connection data into the BMC table, but the metal-hammer can generate them through inband capabilities. If it does not work, an operator has to manually provide credentials.
From here everything should work the same as before but through remote accessing the BMC API.
New metalctl commands
List BMCs:
metalctl bmc ls
+MAC IP VENDOR DRIVER MACHINE ID
+27:53:57:51:6b:c8 10.0.0.8
+27:53:57:51:6b:c9 10.0.0.9
+92:33:b8:0e:df:8f 10.0.0.1 Supermicro Redfish 37c43c25-69fe-4f88-b69d-4e71dc4070d0
+b3:74:fc:50:76:b6 10.0.0.4 Supermicro Redfish 4bdf5c1b-3f7d-47df-84dd-05acb6e0718d
+56:62:97:4e:1f:1f 10.0.0.3 Dell iDrac 995119fd-ec18-4cd7-8ca0-a9e1c2f70624Describe a BMC:
metalctl bmc describe 92:33:b8:0e:df:8f
+---
+mac: 92:33:b8:0e:df:8f
+address: 10.0.0.1
+vendor: Supermicro
+protocol: Redfish
+machine_id: 37c43c25-69fe-4f88-b69d-4e71dc4070d0
+created_at: "2024-11-19T11:15:53.760Z"
+changed_at: "2024-11-19T11:18:53.760Z"
+bios:
+ date: 12/31/2021
+ vendor: American Megatrends Inc.
+ version: "3.6"
+board:
+ board_mfg: Supermicro
+ board_part_number: X11DPT-B
+ chassis_part_number: CSE-217BHQ+...
+ chassis_part_serial: C217BAK18P...
+ product_manufacturer: Supermicro
+ product_part_number: SYS-2029BT-HNR
+ product_serial: E262335X2304003C
+bmc:
+ version: "1.74"
+ipmi:
+ interface: lanplus
+ port: 623
+ password: abc
+ user: metal
+redfish:
+ password: abc
+ user: metal
+powermetric:
+ averageconsumedwatts: 70
+ intervalinmin: 5
+ maxconsumedwatts: 70
+ minconsumedwatts: 70
+ powerstate: "ON"
+ powersupplies:
+ - status:
+ health: Critical
+ state: Enabled
+ - status:
+ health: OK
+ state: Enabled
+ledstate:
+ description: ""
+ value: LED-OFFAdditional commands:
# establish initial access without metal-hammer
+metalctl bmc create-ipmi-user 92:33:b8:0e:df:8f --ipmi-role privileged --ipmi-password 123!
+# set preferred protocol
+metalctl bmc update 92:33:b8:0e:df:8f --preferred-protocol IPMI
+# enforce using Redfish implementation for this specific BMC
+metalctl bmc update 92:33:b8:0e:df:8f --preferred-protocol Redfish --redfish-user afish --redfish-password 123!Feature Deprecation
In order to simplify the new implementation, we can deprecate some features.
Firmware Update Functionality
This feature will be dropped because it was not completely worked out at the point of implementation. It also seems like nobody is actively using it. This brings so many challenges that we should create another MEP in order to bring it back when it's required.
BMC Super User
This feature is a potential security issue and we primarily do it simply because the metal-bmc does not lookup the connection data from the metal-api. We should create a privileged user for operator / metal-stack component access with random credentials by the metal-hammer automatically or let the user enter these credentials manually into the new BMC table by hand.
Then we need another restricted user for machine owners in order to open serial console connections, which can be achieved through the BMC API as part of the contract.
Testability
For the hardware support we have no particular integration testing opportunities apart from our large integration suite, which runs at the FI-TS, which is currently testing our metal-stack integration in Gardener.
In order to improve this situation, we should utilize the IPMI simulator in the mini-lab and run integration tests against it. For this, @robertvolkmann already provided a POC here.
In addition to that, we need to setup a small rack with servers of individual vendors, which can be targeted from a GitHub runner. These servers should be for the sole purpose of integration testing the metal-bmc API.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Machine Re-Installation
In the current metal-api only machine installations are possible, performing a machine upgrade is only possible by creating a new machine and delete the old one. This has the drawback that in case a lot of data is stored on the local disks, a full restore of the original data must be performed.
To prevent this, we will introduce a new metal-api endpoint to reinstall the machine with a new image, without actually deleting the data stored on the additional hard disks.
Storage is a difficult task to get right and reliable. A short analysis of our different storage requirements lead to 3 different scenarios.
- Storage for the etcd pvs in the seed cluster of every partition. This is the most important storage in our setup because these etcd pods serve as configuration backend for all customer kubernetes clusters. If they fail, the cluster is down. However gardener deploys a backup and restore sidecar into the etcd pod of every customer kubernetes control plane, and if this sidecar detects a corrupt or missing etcd database file(s) it starts automatic restore from the configured backup location. This will take some minutes. If for example a node dies, and gardener creates a new node instead, the csi-lvm created pv is not present on that node. Kubernetes will not schedule the missing etcd pod on this node because it has a local PV configured and is therefore tainted to run only on that node. To let kubernetes create that pod anyhow, someone has to either remove the taint, or delete the pod. If this is done, the pod starts and the restore of the etcd data can start as well. You can see this is a bit too complicated and will take the customer cluster down for a while (not measured yet but in the range of 5-10 minutes).
- Storage in customer clusters. This was not promised in 2020. We have a intermediate solution with the provisioning of csi-lvm by default into all customer clusters. Albeit this is only local storage and will get deleted if a node dies.
- S3 Storage. We have two possibilities to cope with storage:
- In place update of the OS with a daemonset This will be fast and simple, but might fail because the packages being installed are broken right now, or a filesystem gets full, or any other failure you can think of during a os update. Another drawback is that metal-api does not reflect the updated os image.
- metal-api get a machine reinstall endpoint With this approach we leverage from existing and already proven mechanisms. Reinstall must keep all data except the sata-dom. Gardener currently is not able to do an update with this approach because it can only do
rollingupdates. Therefore a additionalosupdatestrategyhas to be implemented for metal and other providers in gardener to be able to leverage the metal reinstall on the same machineID approach.
If reinstall is implemented, we should focus on the same technology for all scenarios and put ceph via rook.io into the kubernetes clusters as additional StorageClass. It has to be checked whether to use the raw disk or a PV as the underlay block device where ceph stores its data.
API and behavior
The API will get an new endpoint "reinstall" this endpoint takes two arguments:
- machineID
- image
No other aspects of the machine can be modified during the re-installation. All data stored in the existing allocation will be preserved, only the image will be modified. Once this endpoint was called, the machine will get a reboot signal with the boot order set to PXE instead of HDD and the network interfaces on the leaf are set to PXE as well. Then the normal installation process starts:
- unchanged: PXE boot with metal-hammer
- changed: metal-hammer first checks with the machineID in the metal-api (through metal-core) if there is already a allocation present
- changed: if a allocation is present and the allocation has set
reinstall: true, wipe disk is only executed for the root disk, all other disks are untouched. - unchanged: the specified image is downloaded and burned,
/install.shis executed - unchanged: successful installation is reported back, network is set the the vrf, boot order is set to HDD.
- unchanged: distribution kernel is booted via kexec
We can see that the allocation requires one additional parameter: reinstall and metal-hammer must check for already existing allocation at an earlier stage.
Components which requires modifications (first guess):
- metal-hammer:
- check for allocation present earlier
- evaluation of
reinstallflag set - wipe of disks depends on that flag
- Bonus: move configuration of disk layout and primary disk detection algorithm (PDDA) from metal-hammer into metal-api. metal-api MUST reject reinstallation if the disk found by PDDA does not have the
/etc/metaldirectory!
- metal-core:
- probably nothing
- metal-api:
- new endpoint
/machine/reinstall - add
Reinstall boolto data model ofallocation - make sure to reset
Reinstallafter reinstallation to prevent endless reinstallation loop
- new endpoint
- metalctl:
- implement
reinstall
- implement
- metal-go:
- implement
reinstall
- implement
- gardener (longterm):
- add the
OSUpgradeStrategyreinstall
- add the
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Multi-Tenancy for the metal-api
This document is work in progress.
In the past we decided to treat the metal-api as a "low-level API", i.e. the API does not specifically deal with projects and tenants. A user with editor access can for example assign machines to every project he desires, he can see all the machines available and can control them. We tried to keep the metal-api code base as small as possible and we added resource scoping to a "higher-level APIs". From there, a user would be able to only see his own clusters and IP addresses.
As time passed metal-stack has become an open-source project and people are willing to adopt. Adopters who want to put their own technologies on top of the metal-stack infrastructure don't have those "higher-level APIs" that we implemented closed-source for our user base. So, external adopters most likely need to implement resource scoping on their own.
Introducing multi-tenancy to the metal-api is a serious chance of making our product better and more successful as it opens the door for:
- Becoming a "fully-featured" API
- Narrowing down attack surfaces and possibility of unintended resource modification produced by bugs or human errors
- Discouraging people to implement their own scoping layers in front of the metal-stack
- Gaining performance through resource scopes
- Letting untrusted / third-parties work with the API
Table of Contents
Requirements
These are some general requirements / higher objectives that MEP-4 has to fulfill.
- Should be able to run with mini-lab without requiring to setup complex auth backends (dex, LDAP, keycloak, ...)
- Simple to start with, more complex options for production setups
- Should utilize auth mechanisms that we have already in place to best possible degree
- Fine-grained access permissions (every endpoint maps to a permission)
- Tenant scoping (disallow resource access to resources of other tenants)
- Project scoping (disallow resource access to resources of other projects)
- Access tokens in self-service for technical user access
Implementation
We gathered a lot of knowledge while implementing a multi-tenancy-capable backend for metalstack.cloud. The goal is now to use the same technology and adopt that to the metal-api, this includes:
- gRPC in combination with connectrpc
- OPA for making auth decisions
- REST HTTP only for OIDC login flows
API Definitions
The API definitions should be located on a separate Github repository separate from the server implementation. The proposed repository location is: https://github.com/metal-stack/api.
This repository contains the proto3 specification of the exposed metal-stack api. This includes the messages, simple validations, services and the access permission to these services. The input parameters for the authorization in the backend are generated from the proto3 annotations.
Client implementations for the most relevant languages (go, python) are generated automatically.
This api is divided into end-user and admin access at the top level. The proposed APIs are:
api.v2: For end-user facing servicesadmin.v2: For operators and controllers which need access to unscoped entities
The methods of the API can have different role scopes (and can be narrowed down further with fine-grained method permissions):
tenant: Tenant-scoped methods, e.g. project creation (tenant needs to be provided in the request payload)- Available roles: VIEWER, EDITOR, OWNER
project: Project-scoped methods, e.g. machine creation (tenant needs to be provided in the request payload)- Available roles: VIEWER, EDITOR, OWNER
adminAdmin-scoped methods, e.g. unscoped tenant list or switch register- Available roles: VIEWER, EDITOR
And has methods with different visibility scopes:
self: Methods that only the logged in user can access, e.g. show permissions with the presented tokenpublic: Methods that do not require any specific authorizationprivate: Methods that are not exposed
API
The API server implements the services defined in the API and validates access to a method using OPA with the JWT tokens passed in the requests. The server is implemented using the connectrpc.com framework.
The API server implements the login flow through OIDC. After successful authentication, the API server derives user permissions from the OIDC provider and issues a new JWT token which is passed on to the user. The tokens including the permissions are stored in a redis compatible backend.
With these tokens, users can create Access Tokens for CI/CD or other use cases.
JWT Tokens can be revoked by admins and the user itself.
API Server
Is put into a new github repo which implements the services defined in the api repository. It opens a https endpoints where the grpc (via connectrpc.com) and oidc servives are exposed.
Migration of the Consumers
To allow consumers to migrate to the v2 API gradually, both apis, the new and the old, are deployed in parallel. In the control-plane both apis are deployed side-by-side behind the ingress. api.example.com is forwarded to metal-api and metal.example.com is forwarded to the new api-server.
The api-server will talk to the existing metal-api during the process of migration services away to the new grpc api.
The migration process can be done in the following manner:
for each resource in the metal-api:
- create a new proto3 based definition in the
apirepo. - implement at least a small wrapper service in the
api-serverwhich asks the metal-api for this resource an maps the response back the caller in the grpc format. - identify all consumers of this resource and replace them to use the grpc instead of the rest api
- move the business logic incl. the backend calls to ipam, metal-db, masterdata-ap, nsq for this resource from the metal-api to the api-server
We will try to migrate the rethinkdb backend implementation to a generic approach during this effort.
There are a lot of consumers of metal-api, which need to be migrated:
- ansible
- firewall-controller
- firewall-controller-manager
- gardener-extension-auth
- gardener-extension-provider-metal
- Do not point the secret bindings to a the shared provider secret in the seed anymore. Instead, use individual provider-secret containing project-scoped API access tokens in the Gardener project namespaces.
- machine-controller-manager-provider-metal
- metal-ccm
- metal-console
- metal-bmc
- metal-core
- metal-hammer
- metal-image-cache-sync
- metal-images
- metal-metrics-exporter
- metal-networker
- metalctl
- pixie
User Scenarios
This section gathers a collection of workflows from the perspective of a user that we want to provide with the implementation of this proposal.
Machine Creation
A regular user wants to create a machine resource.
Requirements: Project was created, permissions are present
The user can see networks that were provided by the admin.
$ metalctl network ls +ID NAME PROJECT PARTITION NAT SHARED PREFIXES IPS +internet Internet Network true false 212.34.83.0/27 ● +tenant-super-network-fra-equ01 Project Super Network fra-equ01 false false 10.128.0.0/14 ● +underlay-fra-equ01 Underlay Network fra-equ01 false false 10.0.0.0/16 ●The user has to set the project scope first or provide
--projectflags for all commands.$ metalctl project set 793bb6cd-8b46-479d-9209-0fedca428fe1 +You are now acting on project 793bb6cd-8b46-479d-9209-0fedca428fe1.The user can create the child network required for machine allocation.
$ metalctl network allocate --partition fra-equ01 --name testNow, the user sees his own child network.
$ metalctl network ls +ID NAME PROJECT PARTITION NAT SHARED PREFIXES IPS +internet Internet Network true false 212.34.83.0/27 ● +tenant-super-network-fra-equ01 Project Super Network fra-equ01 false false 10.128.0.0/14 ● +└─╴08b9114b-ec47-4697-b402-a11421788dc6 test 793bb6cd-8b46-479d-9209-0fedca428fe1 fra-equ01 false false 10.128.64.0/22 ● +underlay-fra-equ01 Underlay Network fra-equ01 false false 10.0.0.0/16 ●The user does not see any machines yet.
$ metalctl machine lsThe user can create a machine.
$ metalctl machine create --networks internet,08b9114b-ec47-4697-b402-a11421788dc6 --name test --hostname test --image ubuntu-20.04 --partition fra-equ01 --size c1-xlarge-x86`The machine will now be provisioned.
$ metalctl machine ls +ID LAST EVENT WHEN AGE HOSTNAME PROJECT SIZE IMAGE PARTITION +00000000-0000-0000-0000-ac1f6b7befb2 Phoned Home 20s 50d 4h test 793bb6cd-8b46-479d-9209-0fedca428fe1 c1-xlarge-x86 Ubuntu 20.04 20210415 fra-equ01
A user cannot list all allocated machines for all projects. The user must always switch project context first and can only view the machines inside this project. Only admins can see all machines at once.
Scopes for Resources
The admins / operators of the metal-stack should be able to provide global resources that users are able to use along with their own resources. In particular, users can view and use global resources, but they are not allowed to create, modify or delete them.
When a project ID field is empty on a resource, the resource is considered global.
Where possible, users should be capable of creating their own resource entities.
| Resource | User | Global |
|---|---|---|
| File System Layout | yes | yes |
| Firewall | yes | |
| Firmware | yes | |
| OS Image | yes | |
| Machine | yes | |
| Network (Base) | yes | |
| Network (Children) | yes | |
| IP | yes | |
| Partition | yes | |
| Project | yes | |
| Project Token | yes | |
| Size | yes | |
| Switch | ||
| Tenant | yes |
Example: A user can make use of the file system layouts provided by the admins, but can also create own layouts. Same applies for images. As soon as a user creates own resources, the user takes over the responsibility for the machine provisioning to succeed.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Shared Networks
Why are shared networks needed
For special purpose machines that serve shared services with performance critical workloads to all machines of a partition (like persistent storage) it would be good to have kind of a "shared network" that is easily accessible. They do not necessarily need another firewall. This would avoid having two firewalls in the datapath between a machine in a private network and the machines of a shared service.
Constraints that need to hold
- a shared network is usable from all machines that have a firewall in front, that uses it
- a shared network is only usable within a single partition (currently we are constrained in bandwidth and have no routing of 10.0.0.0/8 addresses btw. partitions and failure domain should be the partition but this constraint might get lifted in the future)
- networks may be marked as shared after network allocation (but there should be no way back from shared to unshared)
- neither machines nor firewalls may have multiple private, unshared networks configured
- machines must have a single primary network configured
- this might be a shared network
- OR a plain, unshared private network
- firewalls may participate in multiple shared networks
- machines can be allocated with a primary network using auto IP allocation or with
noautoand a specific IP
Should shared networks be private
Alternative 1: If we implemented shared networks by extending functions around plain, private networks we would not have to manage another CIDR (mini point) and it would be possible to create a k8s cluster with a private network, mark the network as shared and produce shared services from this k8s cluster.
Alternative 2: If shared networks are implemented as first class networks we could customize the VRF and also accomplish an other goal of our roadmap: being able to create machines directly in an external network.
Together with @majst01 and @Gerrit91 we decided to continue to implement Alternative 1.
Firewalls accessing a shared network
Firewalls that access shared networks need to:
- hide the private network behind an ip address of the shared network if the shared network was configured with
nat=true. - import the prefixes of the shared VRF to the private VRF and import the prefixes of the private VRF to the shared VRF so that the communication between the two is working in both directions. As long as no
nat=truewas set on the shared VRF, the original machine ips are visible in both communication directions.
Setup with shared networks and single consumer
Setup with single shared network and multiple consumers
Getting internet access
Machines contained in a shared network can access the internet with different scenarios:
- if they have an own firewall: this is internet accessibility, as common (check whether all traffic gets routed through it!)
- if they don't have an own firewall, an external HTTP proxy is needed that has an endpoint exposed as Service Type NodePort
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
DMZ Networks
Reasoning
To fulfill higher levels of security measures the standard metal-stack approach with a single firewall in front of a set of machines might be insufficient. There are cases where two physically distinct firewalls in front of application workload are mandatory. In traditional network terms this is known as DMZ approach.
For Kubernetes workloads it makes sense to use the front cluster for ingress, WAF purposes and as outgoing proxy. The clusters may be used for application workload.
DMZ network
- Use a separate DMZ network prefix for every tenant
- This is used as intermediate network btw. private networks of a tenant and the internet
- For every partition a distinct DMZ firewall/cluster is needed for a tenant
- For Gardener orchestrated Kubernetes clusters this network must be a publicly reachable internet prefix because shoot clusters need a vpn service that is used for instrumentation from the seed cluster - this will be a requirement as long as the inverse vpn tunnel feature Konnectivity is not available to us.
Approach 1: DMZ with publicly reachable internet prefix
A DMZ network with publicly reachable internet prefix will look like this in the metal-api:
---
+description: DMZ-Network
+destinationprefixes:
+- 0.0.0.0/0
+id: dmz
+labels:
+ network.metal-stack.io/default-external: ""
+name: DMZ-Network
+parentnetworkid: null
+partitionid: ""
+prefixes:
+- 212.90.30.128/25
+privatesuper: false
+projectid: ""
+vrf: 104007
+vrfshared: false
+nat: true
+shared: false
+underlay: falseDMZ firewall
The firewall of the DMZ will intersect its private network for attached machines, the DMZ network and the public internet.
- The private network of the project needs to import
- the default route from the internet network
- the DMZ network
- The internet network must import the DMZ network
- The DMZ network provides the default route for tenant's clusters in a partition. It imports the default route from the internet network
Application Firewall
The firewall of application workloads intersects its private network for attached machines and the DMZ network.
This is currently supported by the metal-networker and needs no further changes!
Approach 2: DMZ with private IPs
A DMZ network with private IPs will look like this in the metal-api:
---
+description: DMZ-Network
+destinationprefixes:
+- 0.0.0.0/0
+id: dmz
+labels:
+ network.metal-stack.io/default-external: ""
+name: DMZ-Network
+parentnetworkid: tenant-super-network-fra-equ01
+partitionid: fra-equ01
+prefixes:
+- 10.90.30.128/25
+privatesuper: false
+projectid: ""
+vrf: 4711
+vrfshared: false
+nat: true
+shared: true # it's usable from multiple projects
+underlay: falseDMZ firewall
The firewall of the DMZ will intersect its private network for attached machines, the DMZ network and the public internet.
- The private network of the project needs to import
- the default route from the internet network
- the DMZ network
- The internet network must import the DMZ network (only locally, no-export)
- The DMZ network provides the default route for tenant's clusters in a partition. It imports the default route from the internet network
Application Firewall
The firewall of application workloads intersects its private network for attached machines and the DMZ network.
Code Changes / Implications
metal-networkerandmetal-ccmassume that there is only one network providing the default-routemetal-networkerneeds to- import the default route from the internet network to the dmz network (DMZ Firewall)
- import the DMZ network to the internet network and adjusting NAT rules (DMZ Firewall)
- import destination prefixes of the DMZ network to the private primary network (DMZ Firewall, Application Firewall)
- import DMZ-IPs of the private primary network to the DMZ network (DMZ Firewall, Application Firewall)
metal-api: destination prefixes of private networks need to be configurable (allocateNetwork)gardener-extension-provider-metal: needs to be able to delete DMZ clusters (but skip the network deletion part)- the application firewall is not publicly reachable - for debugging purposes a hop over the DMZ firewall is needed
Decision
We decided to follow the second approach with private DMZ networks.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Configurable Filesystem layout for Machine Allocation
The current implementation uses a hard coded filesystem layout depending on the specified size and image. This is done in the metal-hammer. This worked well in the past because we had a small amount of sizes and images. But we reached a point where this is to restricted for all use cases we have to fulfill. It also forces us to modify the metal-hammer source code to support a new filesystem layout.
This proposal tries to address this issue by introducing a filesystem layout struct in the metal-api which is then configurable per machine allocation. The original behavior of automatic filesystem layout decision must still be present, because there must be no API change for existing API consumers. It should be a additional feature during machine allocation.
API and behavior
The API will get a new endpoint filesystemlayoutsto create/update/delete a set of available filesystemlayouts.
Constraints
In order to keep the actual machine allocation api compatible, there must be no difference while allocating a machine. To achieve this every filesystemlayout defines constraints which specifies for which combination of sizes and images this layout should be used by default. The specified constraints over all filesystemlayouts therefore must be collision free, to be more specific, there must be exactly one layout outcome for every possible combination of sizes and images.
The size constraint must be a list of the exact size ids, the image constraint must be a map of os to semver compatible version constraint. For example:
debian: ">= 10.20210101"ordebian: "< 10.20210101"
The general form of a image constraint is a map from os to versionconstraint where:
os must match the first part of the image without the version. versionconstraint must be the comparator, a space and the version, or simply * to match all versions of this os. The comparator must be one of: "=", "!=", ">", "<", ">=", "=>", "<=", "=<", "~", "~>", "^"
It must also be possible to have a filesystemlayout in development or for other special purposes, which can be specified during the machine allocation. To have such a layout, both constraints sizes and imagesmust be empty list.
Reinstall
The current reinstall implementation the metal-hammer detects during the installation on which disk the OS was installed and reports back to the metal-api the Report struct which has two properties primarydisk and ospartition. Both fields are not required anymore because the logic is now shifted to the filesystemlayout definition. If Disk.WipeOnReinstall is set to true, this disk will be wiped, default is false and is preserved.
Handling of s2-xlarge machines
These machines are a bit special compared to our c1-* machines because they have rotating hard disks for the mass storage purpose. The downside is that the on board SATA-DOM has the same naming as the HDDs and can not be specified as the first /dev/sda disk because all HDDs are also /dev/sd* disks. Therefore we had a special SATA-DOM detection algorithm inside metal-hammer which simply checks for the smallest /dev/sd disk and took this to install the OS.
This is not possible with the current approach, but we figured out that the SATA-DOM is always /dev/sde. So we can create a special filesystemlayout where the installations is made on this disk.
Possible Filesystemlayout hierarchies
It is only possible to create a filesystem on top of a block device. The creation of a block device can be done on multiple ways, depending on the requirements regarding performance, space and redundancy of the filesystem. It also depends on the disks available on the server.
The current approach implements the following hierarchies:
Implementation
// FilesystemLayout to be created on the given machine
+type FilesystemLayout struct {
+ // ID unique layout identifier
+ ID string
+ // Description is human readable
+ Description string
+ // Filesystems to create on the server
+ Filesystems []Filesystem
+ // Disks to configure in the server with their partitions
+ Disks []Disk
+ // Raid if not empty, create raid arrays out of the individual disks, to place filesystems onto
+ Raid []Raid
+ // VolumeGroups to create
+ VolumeGroups []VolumeGroup
+ // LogicalVolumes to create on top of VolumeGroups
+ LogicalVolumes []LogicalVolume
+ // Constraints which must match to select this Layout
+ Constraints FilesystemLayoutConstraints
+}
+
+type FilesystemLayoutConstraints struct {
+ // Sizes defines the list of sizes this layout applies to
+ Sizes []string
+ // Images defines a map from os to versionconstraint
+ // the combination of os and versionconstraint per size must be conflict free over all filesystemlayouts
+ Images map[string]string
+}
+
+type RaidLevel string
+type Format string
+type GPTType string
+
+// Filesystem defines a single filesystem to be mounted
+type Filesystem struct {
+ // Path defines the mountpoint, if nil, it will not be mounted
+ Path *string
+ // Device where the filesystem is created on, must be the full device path seen by the OS
+ Device string
+ // Format is the type of filesystem should be created
+ Format Format
+ // Label is optional enhances readability
+ Label *string
+ // MountOptions which might be required
+ MountOptions []string
+ // CreateOptions during filesystem creation
+ CreateOptions []string
+}
+
+// Disk represents a single block device visible from the OS, required
+type Disk struct {
+ // Device is the full device path
+ Device string
+ // Partitions to create on this device
+ Partitions []Partition
+ // WipeOnReinstall, if set to true the whole disk will be erased if reinstall happens
+ // during fresh install all disks are wiped
+ WipeOnReinstall bool
+}
+
+// Raid is optional, if given the devices must match.
+// TODO inherit GPTType from underlay device ?
+type Raid struct {
+ // ArrayName of the raid device, most often this will be /dev/md0 and so forth
+ ArrayName string
+ // Devices the devices to form a raid device
+ Devices []Device
+ // Level the raidlevel to use, can be one of 0,1,5,10
+ // TODO what should be support
+ Level RaidLevel
+ // CreateOptions required during raid creation, example: --metadata=1.0 for uefi boot partition
+ CreateOptions []string
+ // Spares defaults to 0
+ Spares int
+}
+
+
+// VolumeGroup is optional, if given the devices must match.
+type VolumeGroup struct {
+ // Name of the volumegroup without the /dev prefix
+ Name string
+ // Devices the devices to form a volumegroup device
+ Devices []string
+ // Tags to attach to the volumegroup
+ Tags []string
+}
+
+// LogicalVolume is a block devices created with lvm on top of a volumegroup
+type LogicalVolume struct {
+ // Name the name of the logical volume, without /dev prefix, will be accessible at /dev/vgname/lvname
+ Name string
+ // VolumeGroup the name of the volumegroup
+ VolumeGroup string
+ // Size of this LV in mebibytes (MiB)
+ Size uint64
+ // LVMType can be either striped or raid1
+ LVMType LVMType
+}
+
+// Partition is a single partition on a device, only GPT partition types are supported
+type Partition struct {
+ // Number of this partition, will be added to the device once partitioned
+ Number int
+ // Label to enhance readability
+ Label *string
+ // Size given in MebiBytes (MiB)
+ // if "0" is given the rest of the device will be used, this requires Number to be the highest in this partition
+ Size string
+ // GPTType defines the GPT partition type
+ GPTType *GPTType
+}
+
+const (
+ // VFAT is used for the UEFI boot partition
+ VFAT = Format("vfat")
+ // EXT3 is usually only used for /boot
+ EXT3 = Format("ext3")
+ // EXT4 is the default fs
+ EXT4 = Format("ext4")
+ // SWAP is for the swap partition
+ SWAP = Format("swap")
+ // None
+ NONE = Format("none")
+
+ // GPTBoot EFI Boot Partition
+ GPTBoot = GPTType("ef00")
+ // GPTLinux Linux Partition
+ GPTLinux = GPTType("8300")
+ // GPTLinuxRaid Linux Raid Partition
+ GPTLinuxRaid = GPTType("fd00")
+ // GPTLinux Linux Partition
+ GPTLinuxLVM = GPTType("8e00")
+
+ // LVMTypeLinear append across all physical volumes
+ LVMTypeLinear = LVMType("linear")
+ // LVMTypeStriped stripe across all physical volumes
+ LVMTypeStriped = LVMType("striped")
+ // LVMTypeStripe mirror with raid across all physical volumes
+ LVMTypeRaid1 = LVMType("raid1")
+)Example metalctl outputs:
$ metalctl filesystemlayouts ls
+ID DESCRIPTION SIZES IMAGES
+default default fs layout c1-large-x86, c1-xlarge-x86 debian >=10, ubuntu >=20.04, centos >=7
+ceph fs layout for ceph s2-large-x86, s2-xlarge-x86 debian >=10, ubuntu >=20.04
+firewall firewall fs layout c1-large-x86, c1-xlarge-x86 firewall >=2
+storage storage fs layout s3-large-x86 centos >=7
+s3 storage fs layout s2-xlarge-x86 debian >=10, ubuntu >=20.04, >=firewall-2
+default-devel devel fs layout The default layout reflects what is actually implemented in metal-hammer to guarantee backward compatibility.
---
+id: default
+constraints:
+ sizes:
+ - c1-large-x86
+ - c1-xlarge-x86
+ images:
+ debian: ">=10"
+ ubuntu: ">=20.04"
+ centos: ">=7"
+filesystems:
+ - path: "/boot/efi"
+ device: "/dev/sda1"
+ format: "vfat"
+ options: "-F 32"
+ label: "efi" # required to be compatible with old images
+ - path: "/"
+ device: "/dev/sda2"
+ format: "ext4"
+ label: "root" # required to be compatible with old images
+ - path: "/var/lib"
+ device: "/dev/sda3"
+ format: "ext4"
+ label: "varlib" # required to be compatible with old images
+ - path: "/tmp"
+ device: "tmpfs"
+ format: "tmpfs"
+ mountoptions: ["defaults","noatime","nosuid","nodev","noexec","mode=1777","size=512M"]
+disks:
+ - device: "/dev/sda"
+ wipe: true
+ partitions:
+ - number: 1
+ label: "efi"
+ size: 500
+ type: GPTBoot
+ - number: 2
+ label: "root"
+ size: 5000
+ type: GPTLinux
+ - number: 3
+ label: "varlib"
+ size: 0 # to end of partition
+ type: GPTLinuxThe firewall layout reuses the built in nvme disk to store the logs, which is way faster and larger than what the sata-dom ssd provides.
---
+id: firewall
+constraints:
+ sizes:
+ - c1-large-x86
+ - c1-xlarge-x86
+ images:
+ firewall: ">=2"
+filesystems:
+ - path: "/boot/efi"
+ device: "/dev/sda1"
+ format: "vfat"
+ options: "-F 32"
+ - path: "/"
+ device: "/dev/sda2"
+ format: "ext4"
+ - path: "/var"
+ device: "/dev/nvme0n1p1"
+ format: "ext4"
+disks:
+ - device: "/dev/sda"
+ wipe: true
+ partitions:
+ - number: 1
+ label: "efi"
+ size: 500
+ type: GPTBoot
+ - number: 2
+ label: "root"
+ size: 5000
+ type: GPTLinux
+ - device: "/dev/nvme0n1"
+ wipe: true
+ partitions:
+ - number: 1
+ label: "var"
+ size: 0
+ type: GPTLinuxThe storage layout will be used for the storage servers, which must have mirrored boot disks.
---
+id: storage
+constraints:
+ sizes:
+ - s3-large-x86
+ images:
+ centos: ">=7"
+filesystems:
+ - path: "/boot/efi"
+ device: "/dev/md1"
+ format: "vfat"
+ options: "-F32"
+ - path: "/"
+ device: "/dev/md2"
+ format: "ext4"
+disks:
+ - device: "/dev/sda"
+ wipe: true
+ partitions:
+ - number: 1
+ label: "efi"
+ size: 500
+ type: GPTLinuxRaid
+ - number: 2
+ label: "root"
+ size: 5000
+ type: GPTLinuxRaid
+ - device: "/dev/sdb"
+ wipe: true
+ partitions:
+ - number: 1
+ label: "efi"
+ size: 500
+ type: GPTLinuxRaid
+ - number: 2
+ label: "root"
+ size: 5000
+ type: GPTLinuxRaid
+raid:
+ - name: "/dev/md1"
+ level: 1
+ devices:
+ - "/dev/sda1"
+ - "/dev/sdb1"
+ options: "--metadata=1.0"
+ - name: "/dev/md2"
+ level: 1
+ devices:
+ - "/dev/sda2"
+ - "/dev/sdb2"
+ options: "--metadata=1.0"The s3-storage layout matches the special situation on the s2-xlarge machines.
---
+id: s3-storage
+constraints:
+ sizes:
+ - c1-large-x86
+ - s2-xlarge-x86
+ images:
+ debian: ">=10"
+ ubuntu: ">=20.04"
+ centos: ">=7"
+filesystems:
+ - path: "/boot/efi"
+ device: "/dev/sde1"
+ format: "vfat"
+ options: "-F 32"
+ - path: "/"
+ device: "/dev/sde2"
+ format: "ext4"
+ - path: "/var/lib"
+ device: "/dev/sde3"
+ format: "ext4"
+disks:
+ - device: "/dev/sde"
+ wipe: true
+ partitions:
+ - number: 1
+ label: "efi"
+ size: 500
+ type: GPTBoot
+ - number: 2
+ label: "root"
+ size: 5000
+ type: GPTLinux
+ - number: 3
+ label: "varlib"
+ size: 0 # to end of partition
+ type: GPTLinuxA sample lvm layout which puts /var/lib as stripe on the nvme device
---
+id: lvm
+description: "lvm layout"
+constraints:
+ size:
+ - s2-xlarge-x86
+ images:
+ debian: ">=10"
+ ubuntu: ">=20.04"
+ centos: ">=7"
+filesystems:
+ - path: "/boot/efi"
+ device: "/dev/sda1"
+ format: "vfat"
+ createoptions:
+ - "-F 32"
+ label: "efi"
+ - path: "/"
+ device: "/dev/sda2"
+ format: "ext4"
+ label: "root"
+ - path: "/var/lib"
+ device: "/dev/vg00/varlib"
+ format: "ext4"
+ label: "varlib"
+ - path: "/tmp"
+ device: "tmpfs"
+ format: "tmpfs"
+ mountoptions: ["defaults","noatime","nosuid","nodev","noexec","mode=1777","size=512M"]
+volumegroups:
+ - name: "vg00"
+ devices:
+ - "/dev/nvmne0n1"
+ - "/dev/nvmne0n2"
+logicalvolumes:
+ - name: "varlib"
+ volumegroup: "vg00"
+ size: 200
+ lvmtype: "striped"
+disks:
+ - device: "/dev/sda"
+ wipeonreinstall: true
+ partitions:
+ - number: 1
+ label: "efi"
+ size: 500
+ gpttype: "ef00"
+ - number: 2
+ label: "root"
+ size: 5000
+ gpttype: "8300"
+ - device: "/dev/nvmne0n1"
+ wipeonreinstall: false
+ - device: "/dev/nvmne0n2"
+ wipeonreinstall: falseComponents which requires modifications
- metal-hammer:
- change implementation from build in hard coded logic
- move logic to create fstab from install.sh to metal-hammer
- metal-api:
- new endpoint
filesystemlayouts - add optional spec of
filesystemlayoutduringallocationwith validation if givenfilesystemlayoutis possible on given size. - add
allocation.filesystemlayoutin the response, based on either the specifiedfilesystemlayoutor the calculated one. - implement
filesystemlayoutsvalidation for:- matching to disks in the size
- no overlapping with the sizes/imagefilter specified in
filesystemlayouts - all devices specified exists from top to bottom (fs -> disks -> device || fs -> raid -> devices)
- new endpoint
- metalctl:
- implement
filesystemlayouts
- implement
- metal-go:
- adopt api changes
- metal-images:
- install mdadm for raid support
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
No Open Ports To the Data Center
Our metal-stack partitions typically have open ports for metal-stack native services, these are:
- SSH port on the firewalls
- bmc-reverse-proxy for serial console access through the metal-console
These open ports are potential security risks. For example, while SSH access is possible only with private key it's still vulnerable to DoS attack.
Therefore, we want to get rid off these open ports to reduce the attack surface to the data center.
Requirements
- Access to firewall SSH only via VPN
- Easy to update VPN components
As a next step, we can also consider joining the management servers to the VPN mesh, which would replace typical WireGuard setups for operators to enter resources inside the partition.
High Level Design
Simplified drawing showing old vs. new architecture.
Concerns
There's few concerns when using WireGuard for implementing VPN:
- WireGuard doesn't implement dynamic cipher substitution. Which is important in case one of the crypto methods, used by WireGuard will be broken. The only possible solution for that will be to update WireGuard to a fixed version.
- Coordination server(Headscale) is a single point of failure. In case it fails, it potentially can disconnect existing members of the network, as WireGuard can't manage dynamic IPs by itself.
- Headscale is already falls behind Tailscale coordination server implementation. Which can complicate the upgrade to newer version of Tailscale client in case of emergency.
Solutions to concerns
- Tailscale node software is using userspace implementation of WireGuard –
wireguard-go. One of the options is to inject Tailscale client intometalctl. And make it available asmetalctl vpnor similar command. It should be possible to do astailscalenode is already available as open sourced Go pkg. That would allow us to control, what version of Tailscale users are using and in case of any critical changes to enforce them to updatemetalctlto use VPN functionality. - Would it be a considerable risk? We could look into
wg-dynamicproject to cover this problem. - At the moment, repository looks well maintained and the metal-stack team already contributes to it.
Implementation Details
metal-roles
metal-roles will be responsible for deployment of headscale server(via new headscale role). It also should provide sufficient config to metal-api so it establishes connection with headscale gRPC server.
New metalctl commands
metalctl will be responsible for client-side implementation of this MEP. Specifically, it's by using metalctl user expected to connect to firewalls.
metalctl vpn– section for VPN related commands:metalctl vpn get key [vpn name] --namespace [namespace name]– returns auth key to be used withtailscaleclient for establishing connection.
Extend metalctl firewall:
metalctl firewall ssh [ID]– connect to firewall via SSH.
Extend metalctl machine:
metalctl machine ssh [ID]– connect to machine via SSH.
metalctl will be able to connect to firewall and machines by running tailscale in container.
metal-api
Updates to metal-api should be made, so that it's able to add firewalls to VPNs. There should be one Tailscale namespace per project. So if multiple firewalls are created in single project, they will join the same namespace.
Two new flags should be introduced to connect metal-api to headscale gRPC server:
headscale-addr– specifies address of Headscale grpc API.headscale-api-key– specifies temporary API key to connect to Headscale. It should be replaced and then rotated bymetal-api.
If metal-api initialized with headscale connection it should automatically join all created firewalls to VPN.
Add new endpoint, that will be used by metalctl to connect to VPN:
/v1/vpn GET– requests auth key fromheadscaleserver.
metal-hammer
metal-hammer acts as an intermediary for machine configuration between metal-api and machine's image. Specifically it writes to /etc/metal/install.yaml file, data from which later will be used by image's install.sh file.
To implement VPN support we have to add authentication key and VPN server address to install.yaml file. This key will be used to join machine to a VPN.
metal-images
Images install.sh script have to be updated to work with authentication key and VPN server address, provided in install.yaml file. If this key is present, machine should connect to VPN.
metal-networker
metal-networker also have to know if VPN was configured. In that case we need to disable public access to SSH and allow all(?) traffic from WireGuard interface.
firewall-controller
firewall-controller have to monitor changes in Firewall resource and keep tailscaled version up-to-date.
Resources
Update Firewall resource to include desired/actual tailscale version:
Firewall:
+ Spec:
+ tailscale:
+ Version: Minimal version
+ ...
+ Status:
+ ...
+ VPN:
+ Status: Boolean field
+ tailscale:
+ Version: Actual version
+ ...bmc-reverse-proxy
TODO
References
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Metal Stack Enhancement Proposals (MEPs)
This section contains proposals which address substantial modifications to metal-stack.
Every proposal has a short name which starts with MEP followed by an incremental, unique number. Proposals should be raised as pull requests in the docs repository and can be discussed in Github issues.
The list of proposal and their current state is listed in the table below.
Possible states are:
In DiscussionAcceptedDeclinedIn ProgressCompletedAborted
Once a proposal was accepted, an issue should be raised and the implementation should be done in a separate PR.
| Name | Description | State |
|---|---|---|
| MEP-1 | Distributed Control Plane Deployment | In Discussion |
| MEP-2 | Two Factor Authentication | Aborted |
| MEP-3 | Machine Re-Installation to preserve local data | Completed |
| MEP-4 | Multi-tenancy for the metal-api | In Discussion |
| MEP-5 | Shared Networks | Completed |
| MEP-6 | DMZ Networks | Completed |
| MEP-8 | Configurable Filesystemlayout | Completed |
| MEP-9 | No Open Ports To the Data Center | Completed |
| MEP-10 | SONiC Support | Completed |
| MEP-11 | Auditing of metal-stack resources | Completed |
| MEP-12 | Rack Spreading | Completed |
| MEP-14 | Independence from external sources | In Discussion |
| MEP-15 | HAL Improvements | In Discussion |
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Roadmap
A roadmap with short-, mid- and long-term planning will be available soon. For now, there is only a backlog.
Short-term
Available soon.
Mid-term
Available soon.
Long-term
Available soon.
Backlog
The backlog contains ideas of what could become part of the roadmap in the future. The list is ordered alphabetically. Therefore, the order does not express the importance or weight of a backlog item.
We incorporate community feedback into the roadmap. If you think that important points are missing in the backlog, please share your ideas with us. We have a Slack channel. Please check out metal-stack.io for contact information.
By no means this list is a promise of what is being worked on in the near future. It is just a summary of ideas that was agreed on to be "nice to have". It is up to the investors, maintainers and the community to choose topics from this list and to implement them or to remove them from the list.
- Add metal-stack to Gardener conformance test grid
- Autoscaler for metal control plane components
- CI dashboard and public integration testing
- Cilium as the default CNI for metal-stack on Gardener K8s clusters
- Improved release and deploy processes (GitOps, Spinnaker, Flux)
- Machine internet without firewalls
- metal-stack dashboard (UI)
- Offer our metal-stack extensions as enterprise products (accounting, cluster-api, S3) (neither of them will ever be required for running metal-stack, they just add extra value for certain enterprises)
- Partition managed by Kubernetes (with Kubelets joining the control plane cluster)
- Public offering / demo playground
- Resource scoping in the metal-api (MEP-4)
- Service / API tokens (for scoped technical user access)
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Contributing
Please check out the contributing section in our docs.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
csi-driver-lvm
CSI DRIVER LVM utilizes local storage of Kubernetes nodes to provide persistent storage for pods.
It automatically creates hostPath based persistent volumes on the nodes.
Underneath it creates a LVM logical volume on the local disks. A comma-separated list of grok pattern, which disks to use must be specified.
This CSI driver is derived from csi-driver-host-path and csi-lvm
Currently it can create, delete, mount, unmount and resize block and filesystem volumes via lvm
For the special case of block volumes, the filesystem-expansion has to be performed by the app using the block device
Installation
Helm charts for installation are located in a separate repository called helm-charts. If you would like to contribute to the helm chart, please raise an issue or pull request there.
You have to set the devicePattern for your hardware to specify which disks should be used to create the volume group.
helm install --repo https://helm.metal-stack.io mytest csi-driver-lvm --set lvm.devicePattern='/dev/nvme[0-9]n[0-9]'Now you can use one of following storageClasses:
csi-driver-lvm-linearcsi-driver-lvm-mirrorcsi-driver-lvm-striped
To get the previous old and now deprecated csi-lvm-sc-linear, ... storageclasses, set helm-chart value compat03x=true.
Migration
If you want to migrate your existing PVC to / from csi-driver-lvm, you can use korb.
Todo
- implement CreateSnapshot(), ListSnapshots(), DeleteSnapshot()
Test
kubectl apply -f examples/csi-pvc-raw.yaml
+kubectl apply -f examples/csi-pod-raw.yaml
+
+
+kubectl apply -f examples/csi-pvc.yaml
+kubectl apply -f examples/csi-app.yaml
+
+kubectl delete -f examples/csi-pod-raw.yaml
+kubectl delete -f examples/csi-pvc-raw.yaml
+
+kubectl delete -f examples/csi-app.yaml
+kubectl delete -f examples/csi-pvc.yamlDevelopment
In order to run the integration tests locally, you need to create to loop devices on your host machine. Make sure the loop device mount paths are not used on your system (default path is /dev/loop10{0,1}).
You can create these loop devices like this:
for i in 100 101; do fallocate -l 1G loop${i}.img ; sudo losetup /dev/loop${i} loop${i}.img; done
+sudo losetup -a
+# use this for recreation or cleanup
+# for i in 100 101; do sudo losetup -d /dev/loop${i}; rm -f loop${i}.img; doneYou can then run the tests against a kind cluster, running:
make testTo recreate or cleanup the kind cluster:
make test-cleanupPage Tree
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Contributing
Please check out the contributing section in our docs.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Develop Setup
- download kubebuilder
- download kustomize from kustomize
- init project and run kubebuilder
kubebuilder init --domain metal-stack.io +kubebuilder create api --group firewall --version v1 --kind Network - run test
export KUBEBUILDER_ASSETS=/usr/local/kubebuilder/bin # path-to-kubebuilder/bin +make test
Testing locally
# make binary
+make
+
+# start the controller
+bin/firewall-controller --hosts-file ./hosts --enable-signature-check=false --enable-IDS=false
+
+# install kind (k8s in docker)
+
+# create a local kind cluster
+kind create cluster
+
+# deploy manifests
+k apply -f deploy
+
+# watch results
+k describe -n firewall firewall
+cat nftables.v4
+cat hostsSettings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Firewall Controller
This controller is installed on a bare-metal firewall in front of several kubernetes worker nodes and responsible to reconcile a ClusterwideNetworkPolicy to nftables rules to control access to and from the kubernetes cluster. It allows also to control the traffic rate going through, to limit network resources for restricted usage scenarios. Nftable and node metrics are exposed with the nftables-exporter and node-exporter, the ips are visible as service and endpoint from the kubernetes cluster.
Additional an IDS is managed on the firewall to detect known network anomalies. suricata is used for this purpose. Right now, only basic statistics about the amount of scanned packets is reported. In a future release, access to all alarms will be provided.
Architecture
Automatically generated ingress rules
For every Service of type LoadBalancer in the cluster, the corresponding ingress rules will be automatically generated.
If loadBalancerSourceRanges is not specified, incomig traffic to this service will be allowed for any source ip addresses.
Configuration
Firewall Controller is configured with 2 CRDs: firewalls.metal-stack.io and clusterwidenetworkpolicies.metal-stack.io. Both are namespaced and must reside in the firewall namespace. The firewalls CRD is typically written from the gardener-extension-provider-metal, the clusterwidenetworkpolicy should be provided by the deployment of your application.
Example Firewall CRD:
apiVersion: metal-stack.io/v1
+kind: Firewall
+metadata:
+ namespace: firewall
+ name: firewall
+spec:
+ # Interval of reconciliation if nftables rules and network traffic accounting
+ interval: 10s
+ # Ratelimits specify on which physical interface, which maximum rate of traffic is allowed
+ ratelimits:
+ # The name of the interface visible with ip link show
+ - interface: vrf104009
+ # The maximum rate in MBits/s
+ rate: 10
+ # Internalprefixes defines a list of prefixes where the traffic going to, or coming from is considered internal, e.g. not leaving into external networks
+ # given the architecture picture above this would be:
+ internalprefixes:
+ - "1.2.3.0/24
+ - "172.17.0.0/16"
+ - "10.0.0.0/8"Example ClusterwideNetworkPolicy:
apiVersion: metal-stack.io/v1
+kind: ClusterwideNetworkPolicy
+metadata:
+ namespace: firewall
+ name: clusterwidenetworkpolicy-sample
+spec:
+ egress:
+ - to:
+ - cidr: 1.1.0.0/24
+ except:
+ - 1.1.1.0/16
+ - cidr: 8.8.8.8/32
+ ports:
+ - protocol: UDP
+ port: 53
+ - protocol: TCP
+ port: 53Status
Once the firewall-controller is running, it will report several statistics to the Firewall CRD Status: This can be inspected by running:
kubectl describe -n firewall firewallThe output would look like:
Status:
+ Last Run: 2020-06-17T13:18:58Z
+ Stats:
+ # Network traffic in bytes separated into external and internal in/out/total
+ Devices:
+ External:
+ In: 91696
+ Out: 34600
+ Total: 0
+ Internal:
+ In: 0
+ Out: 0
+ Total: 2678671
+ # IDS Statistics by interface
+ Idsstats:
+ vrf104009:
+ Drop: 1992
+ Invalidchecksums: 0
+ Packets: 4997276
+ # nftable rule statistics by rule name
+ Rules:
+ Accept:
+ BGP unnumbered:
+ Counter:
+ Bytes: 0
+ Packets: 0
+ SSH incoming connections:
+ Counter:
+ Bytes: 936
+ Packets: 16
+ accept established connections:
+ Counter:
+ Bytes: 21211168
+ Packets: 39785
+ accept icmp:
+ Counter:
+ Bytes: 0
+ Packets: 0
+ accept traffic for k8s service kube-system/vpn-shoot:
+ Counter:
+ Bytes: 360
+ Packets: 6
+ Drop:
+ drop invalid packets:
+ Counter:
+ Bytes: 52
+ Packets: 1
+ drop invalid packets from forwarding to prevent malicious activity:
+ Counter:
+ Bytes: 0
+ Packets: 0
+ drop invalid packets to prevent malicious activity:
+ Counter:
+ Bytes: 0
+ Packets: 0
+ drop packets with invalid ct state:
+ Counter:
+ Bytes: 0
+ Packets: 0
+ drop ping floods:
+ Counter:
+ Bytes: 0
+ Packets: 0
+ Other:
+ block bgp forward to machines:
+ Counter:
+ Bytes: 0
+ Packets: 0
+ count and log dropped packets:
+ Counter:
+ Bytes: 2528
+ Packets: 51
+ snat (networkid: internet):
+ Counter:
+ Bytes: 36960
+ Packets: 486Prometheus integration
There are two exporters running on the firewall to report essential metrics from this machine:
- node-exporter for machine specific metrics like cpu, ram and disk usage, see node-exporter for details.
- nftables-exporter for nftables metrics, see nftables-exporter
Both exporters are exposed as services:
kubectl get svc -n firewall
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+nftables-exporter ClusterIP None <none> 9630/TCP 13h
+node-exporter ClusterIP None <none> 9100/TCP 13hThese services are in front of virtual endpoints:
kubectl get ep -n firewall
+NAME ENDPOINTS AGE
+nftables-exporter 10.3.164.1:9630 13h
+node-exporter 10.3.164.1:9100 13hYou can scrape these services in you prometheus installation to get the metrics.
To check you can run:
curl nftables-exporter.firewall.svc.cluster.local:9630/metrics
+curl node-exporter.firewall.svc.cluster.local:9100/metricsFirewall Logs
It is also possible to tail for the dropped packets with the following command (install stern from stern ):
stern -n firewall dropThe output will look like:
+droptailer-6d556bd988-4g8gp droptailer 2020-06-17 13:23:27 +0000 UTC {"DPT":"4000","DST":"1.2.3.4","ID":"54321","IN":"vrf104009","LEN":"40","MAC":"ca:41:f9:80:fa:89:aa:bb:0e:62:8c:a6:08:00","OUT":"vlan179","PREC":"0x00","PROTO":"TCP","RES":"0x00","SPT":"38464","SRC":"2.3.4.5","SYN":"","TOS":"0x00","TTL":"236","URGP":"0","WINDOW":"65535","timestamp":"2020-06-17 13:23:27 +0000 UTC"}
+droptailer-6d556bd988-4g8gp droptailer 2020-06-17 13:23:34 +0000 UTC {"DPT":"2362","DST":"1.2.3.4","ID":"44545","IN":"vrf104009","LEN":"40","MAC":"ca:41:f9:80:fa:89:aa:bb:0e:62:8c:a6:08:00","OUT":"","PREC":"0x00","PROTO":"TCP","RES":"0x00","SPT":"40194","SRC":"2.3.4.5","SYN":"","TOS":"0x00","TTL":"242","URGP":"0","WINDOW":"1024","timestamp":"2020-06-17 13:23:34 +0000 UTC"}
+droptailer-6d556bd988-4g8gp droptailer 2020-06-17 13:23:30 +0000 UTC {"DPT":"650","DST":"1.2.3.4","ID":"12399","IN":"vrf104009","LEN":"40","MAC":"ca:41:f9:80:fa:89:aa:bb:0e:62:8c:a6:08:00","OUT":"vlan179","PREC":"0x00","PROTO":"TCP","RES":"0x00","SPT":"40194","SRC":"2.3.4.5","SYN":"","TOS":"0x00","TTL":"241","URGP":"0","WINDOW":"1024","timestamp":"2020-06-17 13:23:30 +0000 UTC"}
+droptailer-6d556bd988-4g8gp droptailer 2020-06-17 13:23:34 +0000 UTC {"DPT":"2362","DST":"1.2.3.4","ID":"44545","IN":"vrf104009","LEN":"40","MAC":"ca:41:f9:80:fa:89:aa:bb:0e:62:8c:a6:08:00","OUT":"","PREC":"0x00","PROTO":"TCP","RES":"0x00","SPT":"40194","SRC":"2.3.4.5","SYN":"","TOS":"0x00","TTL":"242","URGP":"0","WINDOW":"1024","timestamp":"2020-06-17 13:23:34 +0000 UTC"}
+droptailer-6d556bd988-4g8gp droptailer 2020-06-17 13:23:10 +0000 UTC {"DPT":"63351","DST":"1.2.3.4","ID":"11855","IN":"vrf104009","LEN":"40","MAC":"ca:41:f9:80:fa:89:aa:bb:0e:62:8c:a6:08:00","OUT":"vlan179","PREC":"0x00","PROTO":"TCP","RES":"0x00","SPT":"54589","SRC":"2.3.4.5","SYN":"","TOS":"0x00","TTL":"245","URGP":"0","WINDOW":"1024","timestamp":"2020-06-17 13:23:10 +0000 UTC"}
+droptailer-6d556bd988-4g8gp droptailer 2020-06-17 13:23:51 +0000 UTC {"DPT":"8002","DST":"1.2.3.4","ID":"17539","IN":"vrf104009","LEN":"40","MAC":"ca:41:f9:80:fa:89:aa:bb:0e:62:8c:a6:08:00","OUT":"","PREC":"0x00","PROTO":"TCP","RES":"0x00","SPT":"47615","SRC":"2.3.4.5","SYN":"","TOS":"0x08","TTL":"239","URGP":"0","WINDOW":"1024","timestamp":"2020-06-17 13:23:51 +0000 UTC"}You can forward the droptailer logs to any log aggregation infrastructure you have in place.
Page Tree
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Contributing
Please check out the contributing section in our docs.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl
metalctl is the command line client to access the metal-api.
Installation
Download locations:
Installation on Linux
curl -LO https://github.com/metal-stack/metalctl/releases/latest/download/metalctl-linux-amd64
+chmod +x metalctl-linux-amd64
+sudo mv metalctl-linux-amd64 /usr/local/bin/metalctlInstallation on MacOS
For x86 based Macs:
curl -LO https://github.com/metal-stack/metalctl/releases/latest/download/metalctl-darwin-amd64
+chmod +x metalctl-darwin-amd64
+sudo mv metalctl-darwin-amd64 /usr/local/bin/metalctlFor Apple Silicon (M1) based Macs:
curl -LO https://github.com/metal-stack/metalctl/releases/latest/download/metalctl-darwin-arm64
+chmod +x metalctl-darwin-arm64
+sudo mv metalctl-darwin-arm64 /usr/local/bin/metalctlInstallation on Windows
curl -LO https://github.com/metal-stack/metalctl/releases/latest/download/metalctl-windows-amd64
+copy metalctl-windows-amd64 metalctl.exemetalctl update
In order to keep your local metalctl installation up to date, you can update the binary like this:
metalctl update check
+latest version:v0.8.3 from:2020-08-13T11:55:14Z
+local version:v0.8.2 from:2020-08-12T09:27:39Z
+metalctl is not up to date
+
+metalctl update do
+# a download with progress bar starts and replaces the binary. If the binary has root permissions please execute
+sudo metalctl update do
+# insteadBuilt from project
make
+sudo ln -sf $(pwd)/bin/metalctl /usr/local/bin/metalctlConfiguration
Set up auto-completion for metalctl, e.g. add to your ~/.bashrc:
source <(metalctl completion bash)Set up metalctl config, by first creating the config folder (mkdir -p ~/.metalctl), then set the values according to your installation in ~/.metalctl/config.yaml:
---
+current: prod
+contexts:
+ prod:
+ url: https://api.metal-stack.io/metal
+ issuer_url: https://dex.metal-stack.io/dex
+ client_id: metal_client
+ client_secret: 456
+ hmac: YOUR_HMACOptional you can specify issuer_type: generic if you use other issuers as Dex, e.g. Keycloak (this will request scopes openid,profile,email):
contexts:
+ prod:
+ url: https://api.metal-stack.io/metal
+ issuer_url: https://keycloak.somedomain.io
+ issuer_type: generic
+ client_id: my-client-id
+ client_secret: my-secretIf you must specify special scopes for your issuer, you can use custom_scopes:
contexts:
+ prod:
+ url: https://api.metal-stack.io/metal
+ issuer_url: https://keycloak.somedomain.io
+ custom_scopes: roles,openid,profile,email
+ client_id: my-client-id
+ client_secret: my-secretAvailable commands
Full documentation is generated out of the cobra command implementation with:
metalctl markdown
generated markdown is here and here
Development
For MacOS users, running the tests might throw an error because tests are utilizing go-mpatch in order to manipulate the time.Now function. The patch allows testing with fixed timestamps.
Instead, MacOS users can utilize the make test-in-docker target to execute the tests.
Page Tree
- Contributing
- metalctl
- metalctl
- metalctl audit
- metalctl audit describe
- metalctl audit list
- metalctl completion
- metalctl completion bash
- metalctl completion fish
- metalctl completion powershell
- metalctl completion zsh
- metalctl context
- metalctl context short
- metalctl filesystemlayout
- metalctl filesystemlayout apply
- metalctl filesystemlayout create
- metalctl filesystemlayout delete
- metalctl filesystemlayout describe
- metalctl filesystemlayout edit
- metalctl filesystemlayout list
- metalctl filesystemlayout match
- metalctl filesystemlayout try
- metalctl filesystemlayout update
- metalctl firewall
- metalctl firewall create
- metalctl firewall describe
- metalctl firewall list
- metalctl firewall ssh
- metalctl firmware
- metalctl firmware delete
- metalctl firmware list
- metalctl firmware upload
- metalctl firmware upload bios
- metalctl firmware upload bmc
- metalctl health
- metalctl image
- metalctl image apply
- metalctl image create
- metalctl image delete
- metalctl image describe
- metalctl image edit
- metalctl image list
- metalctl image update
- metalctl login
- metalctl logout
- metalctl machine
- metalctl machine apply
- metalctl machine console
- metalctl machine consolepassword
- metalctl machine create
- metalctl machine delete
- metalctl machine describe
- metalctl machine edit
- metalctl machine identify
- metalctl machine identify off
- metalctl machine identify on
- metalctl machine ipmi
- metalctl machine ipmi events
- metalctl machine issues
- metalctl machine issues list
- metalctl machine list
- metalctl machine lock
- metalctl machine logs
- metalctl machine power
- metalctl machine power bios
- metalctl machine power cycle
- metalctl machine power disk
- metalctl machine power off
- metalctl machine power on
- metalctl machine power pxe
- metalctl machine power reset
- metalctl machine reinstall
- metalctl machine reserve
- metalctl machine update-firmware
- metalctl machine update-firmware bios
- metalctl machine update-firmware bmc
- metalctl machine update
- metalctl markdown
- metalctl network
- metalctl network allocate
- metalctl network apply
- metalctl network create
- metalctl network delete
- metalctl network describe
- metalctl network edit
- metalctl network free
- metalctl network ip
- metalctl network ip apply
- metalctl network ip create
- metalctl network ip delete
- metalctl network ip describe
- metalctl network ip edit
- metalctl network ip issues
- metalctl network ip list
- metalctl network ip update
- metalctl network list
- metalctl network update
- metalctl partition
- metalctl partition apply
- metalctl partition capacity
- metalctl partition create
- metalctl partition delete
- metalctl partition describe
- metalctl partition edit
- metalctl partition list
- metalctl partition update
- metalctl project
- metalctl project apply
- metalctl project create
- metalctl project delete
- metalctl project describe
- metalctl project edit
- metalctl project list
- metalctl project update
- metalctl size
- metalctl size apply
- metalctl size create
- metalctl size delete
- metalctl size describe
- metalctl size edit
- metalctl size imageconstraint
- metalctl size imageconstraint apply
- metalctl size imageconstraint create
- metalctl size imageconstraint delete
- metalctl size imageconstraint describe
- metalctl size imageconstraint edit
- metalctl size imageconstraint list
- metalctl size imageconstraint try
- metalctl size imageconstraint update
- metalctl size list
- metalctl size reservation
- metalctl size reservation apply
- metalctl size reservation create
- metalctl size reservation delete
- metalctl size reservation describe
- metalctl size reservation edit
- metalctl size reservation list
- metalctl size reservation update
- metalctl size reservation usage
- metalctl size suggest
- metalctl size update
- metalctl switch
- metalctl switch connected-machines
- metalctl switch console
- metalctl switch delete
- metalctl switch describe
- metalctl switch detail
- metalctl switch edit
- metalctl switch list
- metalctl switch migrate
- metalctl switch port
- metalctl switch port describe
- metalctl switch port down
- metalctl switch port up
- metalctl switch replace
- metalctl switch ssh
- metalctl switch update
- metalctl tenant
- metalctl tenant apply
- metalctl tenant create
- metalctl tenant delete
- metalctl tenant describe
- metalctl tenant edit
- metalctl tenant list
- metalctl tenant update
- metalctl update
- metalctl update check
- metalctl update do
- metalctl version
- metalctl vpn
- metalctl vpn key
- metalctl whoami
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl
a cli to manage entities in the metal-stack api
Options
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ -h, --help help for metalctl
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl audit - manage audit trace entities
- metalctl completion - Generate the autocompletion script for the specified shell
- metalctl context - manage metalctl context
- metalctl filesystemlayout - manage filesystemlayout entities
- metalctl firewall - manage firewall entities
- metalctl firmware - manage firmwares
- metalctl health - shows the server health
- metalctl image - manage image entities
- metalctl login - login user and receive token
- metalctl logout - logout user from OIDC SSO session
- metalctl machine - manage machine entities
- metalctl markdown - create markdown documentation
- metalctl network - manage network entities
- metalctl partition - manage partition entities
- metalctl project - manage project entities
- metalctl size - manage size entities
- metalctl switch - manage switch entities
- metalctl tenant - manage tenant entities
- metalctl update - update the program
- metalctl version - print the client and server version information
- metalctl vpn - access VPN
- metalctl whoami - shows current user
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl audit
manage audit trace entities
Synopsis
show audit traces of the api. feature must be enabled on server-side.
Options
-h, --help help for auditOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl audit describe - describes the audit trace
- metalctl audit list - list all audit traces
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl audit describe
describes the audit trace
metalctl audit describe <id> [flags]Options
-h, --help help for describe
+ --phase string phase of the audit trace. One of [request, response, single, error, opened, closed] (default "response")
+ --prettify-body attempts to interpret the body as json and prettifies itOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl audit - manage audit trace entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl audit list
list all audit traces
metalctl audit list [flags]Options
--component string component of the audit trace.
+ --detail string detail of the audit trace. An HTTP method, unary or stream
+ --error string error of the audit trace.
+ --forwarded-for string forwarded for of the audit trace.
+ --from string start of range of the audit traces. e.g. 1h, 10m, 2006-01-02 15:04:05 (default "1h")
+ -h, --help help for list
+ --limit int limit the number of audit traces. (default 100)
+ --path string api path of the audit trace.
+ --phase string phase of the audit trace. One of [request, response, single, error, opened, closed]
+ -q, --query string filters audit trace body payloads for the given text.
+ --remote-addr string remote address of the audit trace.
+ --request-id string request id of the audit trace.
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: path|tenant|timestamp|user
+ --status-code int32 HTTP status code of the audit trace.
+ --tenant string tenant of the audit trace.
+ --to string end of range of the audit traces. e.g. 1h, 10m, 2006-01-02 15:04:05
+ --type string type of the audit trace. One of [http, grpc, event].
+ --user string user of the audit trace.Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl audit - manage audit trace entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl completion
Generate the autocompletion script for the specified shell
Synopsis
Generate the autocompletion script for metalctl for the specified shell. See each sub-command's help for details on how to use the generated script.
Options
-h, --help help for completionOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl completion bash - Generate the autocompletion script for bash
- metalctl completion fish - Generate the autocompletion script for fish
- metalctl completion powershell - Generate the autocompletion script for powershell
- metalctl completion zsh - Generate the autocompletion script for zsh
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl completion bash
Generate the autocompletion script for bash
Synopsis
Generate the autocompletion script for the bash shell.
This script depends on the 'bash-completion' package. If it is not installed already, you can install it via your OS's package manager.
To load completions in your current shell session:
source <(metalctl completion bash)To load completions for every new session, execute once:
Linux:
metalctl completion bash > /etc/bash_completion.d/metalctlmacOS:
metalctl completion bash > $(brew --prefix)/etc/bash_completion.d/metalctlYou will need to start a new shell for this setup to take effect.
metalctl completion bashOptions
-h, --help help for bash
+ --no-descriptions disable completion descriptionsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl completion - Generate the autocompletion script for the specified shell
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl completion fish
Generate the autocompletion script for fish
Synopsis
Generate the autocompletion script for the fish shell.
To load completions in your current shell session:
metalctl completion fish | sourceTo load completions for every new session, execute once:
metalctl completion fish > ~/.config/fish/completions/metalctl.fishYou will need to start a new shell for this setup to take effect.
metalctl completion fish [flags]Options
-h, --help help for fish
+ --no-descriptions disable completion descriptionsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl completion - Generate the autocompletion script for the specified shell
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl completion powershell
Generate the autocompletion script for powershell
Synopsis
Generate the autocompletion script for powershell.
To load completions in your current shell session:
metalctl completion powershell | Out-String | Invoke-ExpressionTo load completions for every new session, add the output of the above command to your powershell profile.
metalctl completion powershell [flags]Options
-h, --help help for powershell
+ --no-descriptions disable completion descriptionsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl completion - Generate the autocompletion script for the specified shell
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl completion zsh
Generate the autocompletion script for zsh
Synopsis
Generate the autocompletion script for the zsh shell.
If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once:
echo "autoload -U compinit; compinit" >> ~/.zshrcTo load completions in your current shell session:
source <(metalctl completion zsh)To load completions for every new session, execute once:
Linux:
metalctl completion zsh > "${fpath[1]}/_metalctl"macOS:
metalctl completion zsh > $(brew --prefix)/share/zsh/site-functions/_metalctlYou will need to start a new shell for this setup to take effect.
metalctl completion zsh [flags]Options
-h, --help help for zsh
+ --no-descriptions disable completion descriptionsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl completion - Generate the autocompletion script for the specified shell
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl context
manage metalctl context
Synopsis
context defines the backend to which metalctl talks to. You can switch back and forth with "-"
metalctl context <name> [flags]Examples
+~/.metalctl/config.yaml
+---
+current: prod
+contexts:
+ prod:
+ url: https://api.metal-stack.io/metal
+ issuer_url: https://dex.metal-stack.io/dex
+ client_id: metal_client
+ client_secret: 456
+ dev:
+ url: https://api.metal-stack.dev/metal
+ issuer_url: https://dex.metal-stack.dev/dex
+ client_id: metal_client
+ client_secret: 123
+...
+Options
-h, --help help for contextOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl context short - only show the default context name
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl context short
only show the default context name
metalctl context short [flags]Options
-h, --help help for shortOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl context - manage metalctl context
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl filesystemlayout
manage filesystemlayout entities
Synopsis
a filesystemlayout is a specification how the disks in a machine are partitioned, formatted and mounted.
Options
-h, --help help for filesystemlayoutOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl filesystemlayout apply - applies one or more filesystemlayouts from a given file
- metalctl filesystemlayout create - creates the filesystemlayout
- metalctl filesystemlayout delete - deletes the filesystemlayout
- metalctl filesystemlayout describe - describes the filesystemlayout
- metalctl filesystemlayout edit - edit the filesystemlayout through an editor and update
- metalctl filesystemlayout list - list all filesystemlayouts
- metalctl filesystemlayout match - check if a machine satisfies all disk requirements of a given filesystemlayout
- metalctl filesystemlayout try - try to detect a filesystem by given size and image
- metalctl filesystemlayout update - updates the filesystemlayout
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl filesystemlayout apply
applies one or more filesystemlayouts from a given file
metalctl filesystemlayout apply [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl filesystemlayout describe filesystemlayout-1 -o yaml > filesystemlayout.yaml
+ $ vi filesystemlayout.yaml
+ $ # either via stdin
+ $ cat filesystemlayout.yaml | metalctl filesystemlayout apply -f -
+ $ # or via file
+ $ metalctl filesystemlayout apply -f filesystemlayout.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for apply
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl filesystemlayout - manage filesystemlayout entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl filesystemlayout create
creates the filesystemlayout
metalctl filesystemlayout create [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl filesystemlayout describe filesystemlayout-1 -o yaml > filesystemlayout.yaml
+ $ vi filesystemlayout.yaml
+ $ # either via stdin
+ $ cat filesystemlayout.yaml | metalctl filesystemlayout create -f -
+ $ # or via file
+ $ metalctl filesystemlayout create -f filesystemlayout.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for create
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl filesystemlayout - manage filesystemlayout entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl filesystemlayout delete
deletes the filesystemlayout
metalctl filesystemlayout delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl filesystemlayout describe filesystemlayout-1 -o yaml > filesystemlayout.yaml
+ $ vi filesystemlayout.yaml
+ $ # either via stdin
+ $ cat filesystemlayout.yaml | metalctl filesystemlayout delete <id> -f -
+ $ # or via file
+ $ metalctl filesystemlayout delete <id> -f filesystemlayout.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for delete
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl filesystemlayout - manage filesystemlayout entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl filesystemlayout describe
describes the filesystemlayout
metalctl filesystemlayout describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl filesystemlayout - manage filesystemlayout entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl filesystemlayout edit
edit the filesystemlayout through an editor and update
metalctl filesystemlayout edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl filesystemlayout - manage filesystemlayout entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl filesystemlayout list
list all filesystemlayouts
metalctl filesystemlayout list [flags]Options
-h, --help help for list
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: description|id|nameOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl filesystemlayout - manage filesystemlayout entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl filesystemlayout match
check if a machine satisfies all disk requirements of a given filesystemlayout
metalctl filesystemlayout match [flags]Options
--filesystemlayout string filesystemlayout id to check against [required]
+ -h, --help help for match
+ --machine string machine id to check for match [required]Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl filesystemlayout - manage filesystemlayout entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl filesystemlayout try
try to detect a filesystem by given size and image
metalctl filesystemlayout try [flags]Options
-h, --help help for try
+ --image string image to try
+ --size string size to tryOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl filesystemlayout - manage filesystemlayout entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl filesystemlayout update
updates the filesystemlayout
metalctl filesystemlayout update [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl filesystemlayout describe filesystemlayout-1 -o yaml > filesystemlayout.yaml
+ $ vi filesystemlayout.yaml
+ $ # either via stdin
+ $ cat filesystemlayout.yaml | metalctl filesystemlayout update -f -
+ $ # or via file
+ $ metalctl filesystemlayout update -f filesystemlayout.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl filesystemlayout - manage filesystemlayout entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl firewall
manage firewall entities
Synopsis
firewalls are used to establish network connectivity between metal-stack networks. firewalls are similar to machines but are managed by the provider. almost every command of the machine command subset works on firewalls, too.
Options
-h, --help help for firewallOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl firewall create - creates the firewall
- metalctl firewall describe - describes the firewall
- metalctl firewall list - list all firewalls
- metalctl firewall ssh - SSH to a firewall
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl firewall create
creates the firewall
metalctl firewall create [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -d, --description string Description of the firewall to create. [optional]
+ --dnsservers strings dns servers to add to the machine or firewall. [optional]
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl firewall describe firewall-1 -o yaml > firewall.yaml
+ $ vi firewall.yaml
+ $ # either via stdin
+ $ cat firewall.yaml | metalctl firewall create -f -
+ $ # or via file
+ $ metalctl firewall create -f firewall.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ --filesystemlayout string Filesystemlayout to use during machine installation. [optional]
+ --firewall-rules-file string firewall rules specified in a yaml file
+
+ Example:
+
+ $ metalctl firewall create ..mandatory args.. --firewall-rules-file rules.yaml
+
+ rules.yaml
+ ---
+ egress:
+ - comment: allow outgoing https
+ ports:
+ - 443
+ protocol: TCP
+ to:
+ - 0.0.0.0/0
+ - comment: allow outgoing dns via tcp
+ ports:
+ - 53
+ protocol: TCP
+ to:
+ - 0.0.0.0/0
+ - comment: allow outgoing dns and ntp via udp
+ ports:
+ - 53
+ - 123
+ protocol: UDP
+ to:
+ - 0.0.0.0/0
+ ingress:
+ - comment: allow incoming ssh only to one ip
+ ports:
+ - 22
+ protocol: TCP
+ from:
+ - 0.0.0.0/0
+ - 1.2.3.4/32
+ to:
+ - 212.34.83.19/32
+ - comment: allow incoming https to all targets
+ ports:
+ - 80
+ - 433
+ protocol: TCP
+ from:
+ - 0.0.0.0/0
+
+
+ -h, --help help for create
+ -H, --hostname string Hostname of the firewall. [required]
+ -I, --id string ID of a specific firewall to allocate, if given, size and partition are ignored. Need to be set to reserved (--reserve) state before.
+ -i, --image string OS Image to install. [required]
+ --ips strings Sets the firewall's IP address. Usage: [--ips[=IPV4-ADDRESS[,IPV4-ADDRESS]...]]...
+ IPV4-ADDRESS specifies the IPv4 address to add.
+ It can only be used in conjunction with --networks.
+ -n, --name string Name of the firewall. [optional]
+ --networks strings Adds network(s). Usage: --networks NETWORK[:MODE][,NETWORK[:MODE]]... [--networks NETWORK[:MODE][,
+ NETWORK[:MODE]]...]...
+ NETWORK specifies the id of an existing network.
+ MODE can be omitted or one of:
+ auto IP address is automatically acquired from the given network
+ noauto No automatic IP address acquisition
+ --ntpservers strings ntp servers to add to the machine or firewall. [optional]
+ -S, --partition string partition/datacenter where the firewall is created. [required, except for reserved machines]
+ -P, --project string Project where the firewall should belong to. [required]
+ -s, --size string Size of the firewall. [required, except for reserved machines]
+ --skip-security-prompts skips security prompt for bulk operations
+ -p, --sshpublickey string SSH public key for access via ssh and console. [optional]
+ Can be either the public key as string, or pointing to the public key file to use e.g.: "@~/.ssh/id_rsa.pub".
+ If ~/.ssh/[id_ed25519.pub | id_rsa.pub | id_dsa.pub] is present it will be picked as default, matching the first one in this order.
+ --tags strings tags to add to the firewall, use it like: --tags "tag1,tag2" or --tags "tag3".
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operations
+ --userdata string cloud-init.io compatible userdata. [optional]
+ Can be either the userdata as string, or pointing to the userdata file to use e.g.: "@/tmp/userdata.cfg".Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl firewall - manage firewall entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl firewall describe
describes the firewall
metalctl firewall describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl firewall - manage firewall entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl firewall list
list all firewalls
metalctl firewall list [flags]Options
-h, --help help for list
+ --hostname string allocation hostname to filter [optional]
+ --id string ID to filter [optional]
+ --image string allocation image to filter [optional]
+ --mac string mac to filter [optional]
+ --name string allocation name to filter [optional]
+ --partition string partition to filter [optional]
+ --project string allocation project to filter [optional]
+ --size string size to filter [optional]
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: age|event|id|image|liveliness|partition|project|size|when
+ --tags strings tags to filter, use it like: --tags "tag1,tag2" or --tags "tag3".Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl firewall - manage firewall entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl firewall ssh
SSH to a firewall
Synopsis
SSH to a firewall via VPN.
metalctl firewall ssh <firewall ID> [flags]Options
-h, --help help for ssh
+ -i, --identity string specify identity file to SSH to the firewall like: -i path/to/id_rsa (default "~/.ssh/id_rsa")Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl firewall - manage firewall entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl firmware
manage firmwares
Synopsis
list, upload and remove firmwares.
Options
-h, --help help for firmwareOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl firmware delete - delete a firmware
- metalctl firmware list - list firmwares
- metalctl firmware upload - upload a firmware
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl firmware delete
delete a firmware
Synopsis
deletes the specified firmware.
metalctl firmware delete [flags]Options
--board string the board type (required)
+ -h, --help help for delete
+ --kind string the firmware kind [bmc|bios] (required)
+ --revision string the firmware revision (required)
+ --vendor string the vendor (required)Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl firmware - manage firmwares
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl firmware list
list firmwares
Synopsis
lists all available firmwares matching the given criteria.
metalctl firmware list [flags]Options
--board string the board type
+ -h, --help help for list
+ --kind string the firmware kind [bmc|bios]
+ --machineid string the machine id (ignores vendor and board flags)
+ --vendor string the vendorOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl firmware - manage firmwares
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl firmware upload
upload a firmware
Options
-h, --help help for uploadOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl firmware - manage firmwares
- metalctl firmware upload bios - upload a BIOS firmware
- metalctl firmware upload bmc - upload a BMC firmware
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl firmware upload bios
upload a BIOS firmware
Synopsis
the given BIOS firmware file will be uploaded and tagged as given revision.
metalctl firmware upload bios <file> [flags]Options
--board string the board type (required)
+ -h, --help help for bios
+ --revision string the BIOS firmware revision (required)
+ --vendor string the vendor (required)Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl firmware upload - upload a firmware
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl firmware upload bmc
upload a BMC firmware
Synopsis
the given BMC firmware file will be uploaded and tagged as given revision.
metalctl firmware upload bmc <file> [flags]Options
--board string the board type (required)
+ -h, --help help for bmc
+ --revision string the BMC firmware revision (required)
+ --vendor string the vendor (required)Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl firmware upload - upload a firmware
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl health
shows the server health
metalctl health [flags]Options
-h, --help help for healthOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl image
manage image entities
Synopsis
os images available to be installed on machines.
Options
-h, --help help for imageOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl image apply - applies one or more images from a given file
- metalctl image create - creates the image
- metalctl image delete - deletes the image
- metalctl image describe - describes the image
- metalctl image edit - edit the image through an editor and update
- metalctl image list - list all images
- metalctl image update - updates the image
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl image apply
applies one or more images from a given file
metalctl image apply [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl image describe image-1 -o yaml > image.yaml
+ $ vi image.yaml
+ $ # either via stdin
+ $ cat image.yaml | metalctl image apply -f -
+ $ # or via file
+ $ metalctl image apply -f image.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for apply
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl image - manage image entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl image create
creates the image
metalctl image create [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -d, --description string Description of the image.
+ --features strings features of the image, can be one of machine|firewall
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl image describe image-1 -o yaml > image.yaml
+ $ vi image.yaml
+ $ # either via stdin
+ $ cat image.yaml | metalctl image create -f -
+ $ # or via file
+ $ metalctl image create -f image.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for create
+ --id string ID of the image.
+ -n, --name string Name of the image.
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operations
+ --url string url of the image.Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl image - manage image entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl image delete
deletes the image
metalctl image delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl image describe image-1 -o yaml > image.yaml
+ $ vi image.yaml
+ $ # either via stdin
+ $ cat image.yaml | metalctl image delete <id> -f -
+ $ # or via file
+ $ metalctl image delete <id> -f image.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for delete
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl image - manage image entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl image describe
describes the image
metalctl image describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl image - manage image entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl image edit
edit the image through an editor and update
metalctl image edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl image - manage image entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl image list
list all images
metalctl image list [flags]Options
--classification string Classification of this image.
+ --features string Features of this image.
+ -h, --help help for list
+ --id string ID of the image.
+ --name string Name of the image.
+ --os string OS derivate of this image.
+ --show-usage show from how many allocated machines every image is used
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: classification|description|expiration|id|name
+ --version string Version of this image.Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl image - manage image entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl image update
updates the image
metalctl image update [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl image describe image-1 -o yaml > image.yaml
+ $ vi image.yaml
+ $ # either via stdin
+ $ cat image.yaml | metalctl image update -f -
+ $ # or via file
+ $ metalctl image update -f image.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl image - manage image entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl login
login user and receive token
Synopsis
login and receive token that will be used to authenticate commands.
metalctl login [flags]Options
-h, --help help for login
+ --print-only If true, the token is printed to stdoutOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl logout
logout user from OIDC SSO session
metalctl logout [flags]Options
-h, --help help for logoutOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine
manage machine entities
Synopsis
a machine is a bare metal server provisioned through metal-stack that is intended to run user workload.
Options
-h, --help help for machineOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl machine apply - applies one or more machines from a given file
- metalctl machine console - console access to a machine
- metalctl machine consolepassword - fetch the consolepassword for a machine
- metalctl machine create - creates the machine
- metalctl machine delete - deletes the machine
- metalctl machine describe - describes the machine
- metalctl machine edit - edit the machine through an editor and update
- metalctl machine identify - manage machine chassis identify LED power
- metalctl machine ipmi - display ipmi details of the machine, if no machine ID is given all ipmi addresses are returned.
- metalctl machine issues - display machines which are in a potential bad state
- metalctl machine list - list all machines
- metalctl machine lock - lock a machine
- metalctl machine logs - display machine provisioning logs
- metalctl machine power - manage machine power
- metalctl machine reinstall - reinstalls an already allocated machine
- metalctl machine reserve - reserve a machine
- metalctl machine update - updates the machine
- metalctl machine update-firmware - update a machine firmware
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine apply
applies one or more machines from a given file
metalctl machine apply [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl machine describe machine-1 -o yaml > machine.yaml
+ $ vi machine.yaml
+ $ # either via stdin
+ $ cat machine.yaml | metalctl machine apply -f -
+ $ # or via file
+ $ metalctl machine apply -f machine.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for apply
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine console
console access to a machine
Synopsis
console access to a machine, machine must be created with a ssh public key, authentication is done with your private key. In case the machine did not register properly a direct ipmi console access is available via the –ipmi flag. This is only for administrative access.
metalctl machine console <machine ID> [flags]Options
--admin authenticate as admin (admin only).
+ -h, --help help for console
+ --ipmi use ipmitool with direct network access (admin only).
+ --ipmipassword string overwrite ipmi password (admin only).
+ --ipmiuser string overwrite ipmi user (admin only).
+ -i, --sshidentity string SSH key file, if not given the default ssh key will be used if present [optional].Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine consolepassword
fetch the consolepassword for a machine
metalctl machine consolepassword <machine ID> [flags]Options
-h, --help help for consolepassword
+ --reason string a short description why access to the consolepassword is requiredOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine create
creates the machine
metalctl machine create [flags]Examples
machine create can be done in two different ways:
+
+- default with automatic allocation:
+
+ metalctl machine create \
+ --hostname worker01 \
+ --name worker \
+ --image ubuntu-18.04 \ # query available with: metalctl image list
+ --size t1-small-x86 \ # query available with: metalctl size list
+ --partition test \ # query available with: metalctl partition list
+ --project cluster01 \
+ --sshpublickey "@~/.ssh/id_rsa.pub"
+
+- for metal administration with reserved machines:
+
+ reserve a machine you want to allocate:
+
+ metalctl machine reserve 00000000-0000-0000-0000-0cc47ae54694 --description "blocked for maintenance"
+
+ allocate this machine:
+
+ metalctl machine create \
+ --hostname worker01 \
+ --name worker \
+ --image ubuntu-18.04 \ # query available with: metalctl image list
+ --project cluster01 \
+ --sshpublickey "@~/.ssh/id_rsa.pub" \
+ --id 00000000-0000-0000-0000-0cc47ae54694
+
+after you do not want to use this machine exclusive, remove the reservation:
+
+metalctl machine reserve 00000000-0000-0000-0000-0cc47ae54694 --remove
+
+Once created the machine installation can not be modified anymore.
+Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -d, --description string Description of the machine to create. [optional]
+ --dnsservers strings dns servers to add to the machine or firewall. [optional]
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl machine describe machine-1 -o yaml > machine.yaml
+ $ vi machine.yaml
+ $ # either via stdin
+ $ cat machine.yaml | metalctl machine create -f -
+ $ # or via file
+ $ metalctl machine create -f machine.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ --filesystemlayout string Filesystemlayout to use during machine installation. [optional]
+ -h, --help help for create
+ -H, --hostname string Hostname of the machine. [required]
+ -I, --id string ID of a specific machine to allocate, if given, size and partition are ignored. Need to be set to reserved (--reserve) state before.
+ -i, --image string OS Image to install. [required]
+ --ips strings Sets the machine's IP address. Usage: [--ips[=IPV4-ADDRESS[,IPV4-ADDRESS]...]]...
+ IPV4-ADDRESS specifies the IPv4 address to add.
+ It can only be used in conjunction with --networks.
+ -n, --name string Name of the machine. [optional]
+ --networks strings Adds a network. Usage: [--networks NETWORK[:MODE][,NETWORK[:MODE]]...]...
+ NETWORK specifies the name or id of an existing network.
+ MODE cane be omitted or one of:
+ auto IP address is automatically acquired from the given network
+ noauto IP address for the given network must be provided via --ips
+ --ntpservers strings ntp servers to add to the machine or firewall. [optional]
+ -S, --partition string partition/datacenter where the machine is created. [required, except for reserved machines]
+ -P, --project string Project where the machine should belong to. [required]
+ -s, --size string Size of the machine. [required, except for reserved machines]
+ --skip-security-prompts skips security prompt for bulk operations
+ -p, --sshpublickey string SSH public key for access via ssh and console. [optional]
+ Can be either the public key as string, or pointing to the public key file to use e.g.: "@~/.ssh/id_rsa.pub".
+ If ~/.ssh/[id_ed25519.pub | id_rsa.pub | id_dsa.pub] is present it will be picked as default, matching the first one in this order.
+ --tags strings tags to add to the machine, use it like: --tags "tag1,tag2" or --tags "tag3".
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operations
+ --userdata string cloud-init.io compatible userdata. [optional]
+ Can be either the userdata as string, or pointing to the userdata file to use e.g.: "@/tmp/userdata.cfg".Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine delete
deletes the machine
Synopsis
delete a machine and destroy all data stored on the local disks. Once destroyed it is back for usage by other projects. A destroyed machine can not restored anymore
metalctl machine delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl machine describe machine-1 -o yaml > machine.yaml
+ $ vi machine.yaml
+ $ # either via stdin
+ $ cat machine.yaml | metalctl machine delete <id> -f -
+ $ # or via file
+ $ metalctl machine delete <id> -f machine.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for delete
+ --remove-from-database remove given machine from the database, is only required for maintenance reasons [optional] (admin only).
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine describe
describes the machine
metalctl machine describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine edit
edit the machine through an editor and update
metalctl machine edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine identify
manage machine chassis identify LED power
Options
-h, --help help for identifyOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
- metalctl machine identify off - power off the machine chassis identify LED
- metalctl machine identify on - power on the machine chassis identify LED
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine identify off
power off the machine chassis identify LED
Synopsis
set the machine chassis identify LED to off state
metalctl machine identify off <machine ID> [flags]Options
-d, --description string description of the reason for chassis identify LED turn-off. (default "Triggered by metalctl")
+ -h, --help help for offOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine identify - manage machine chassis identify LED power
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine identify on
power on the machine chassis identify LED
Synopsis
set the machine chassis identify LED to on state
metalctl machine identify on <machine ID> [flags]Options
-d, --description string description of the reason for chassis identify LED turn-on.
+ -h, --help help for onOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine identify - manage machine chassis identify LED power
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine ipmi
display ipmi details of the machine, if no machine ID is given all ipmi addresses are returned.
Synopsis
display ipmi details of the machine, if no machine ID is given all ipmi addresses are returned.
Meaning of the emojis:
🚧 Machine is reserved. Reserved machines are not considered for random allocation until the reservation flag is removed. 🔒 Machine is locked. Locked machines can not be deleted until the lock is removed. 💀 Machine is dead. The metal-api does not receive any events from this machine. ❗ Machine has a last event error. The machine has recently encountered an error during the provisioning lifecycle. ❓ Machine is in unknown condition. The metal-api does not receive phoned home events anymore or has never booted successfully. ⭕ Machine is in a provisioning crash loop. Flag can be reset through an API-triggered reboot or when the machine reaches the phoned home state. 🚑 Machine reclaim has failed. The machine was deleted but it is not going back into the available machine pool. 🛡 Machine is connected to our VPN, ssh access only possible via this VPN.
metalctl machine ipmi [<machine ID>] [flags]Options
--bmc-address string bmc ipmi address (needs to include port) to filter [optional]
+ --bmc-mac string bmc mac address to filter [optional]
+ --board-part-number string fru board part number to filter [optional]
+ -h, --help help for ipmi
+ --hostname string allocation hostname to filter [optional]
+ --id string ID to filter [optional]
+ --image string allocation image to filter [optional]
+ --last-event-error-threshold duration the duration up to how long in the past a machine last event error will be counted as an issue [optional] (default 1h0m0s)
+ --mac string mac to filter [optional]
+ --manufacturer string fru manufacturer to filter [optional]
+ --name string allocation name to filter [optional]
+ --network-destination-prefixes string network destination prefixes to filter [optional]
+ --network-ids string network ids to filter [optional]
+ --network-ips string network ips to filter [optional]
+ --partition string partition to filter [optional]
+ --product-part-number string fru product part number to filter [optional]
+ --product-serial string fru product serial to filter [optional]
+ --project string allocation project to filter [optional]
+ --rack string rack to filter [optional]
+ --role string allocation role to filter [optional]
+ --size string size to filter [optional]
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: age|bios|bmc|event|id|liveliness|partition|project|rack|size|when
+ --state string state to filter [optional]
+ --tags strings tags to filter, use it like: --tags "tag1,tag2" or --tags "tag3".Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
- metalctl machine ipmi events - display machine hardware events
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine ipmi events
display machine hardware events
metalctl machine ipmi events <machine ID> [flags]Options
-h, --help help for events
+ --ipmipassword string overwrite ipmi password (admin only).
+ --ipmiuser string overwrite ipmi user (admin only).
+ -n, --last string show last <n> log entries. (default "10")Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine ipmi - display ipmi details of the machine, if no machine ID is given all ipmi addresses are returned.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine issues
display machines which are in a potential bad state
Synopsis
display machines which are in a potential bad state
Meaning of the emojis:
🚧 Machine is reserved. Reserved machines are not considered for random allocation until the reservation flag is removed. 🔒 Machine is locked. Locked machines can not be deleted until the lock is removed. 💀 Machine is dead. The metal-api does not receive any events from this machine. ❗ Machine has a last event error. The machine has recently encountered an error during the provisioning lifecycle. ❓ Machine is in unknown condition. The metal-api does not receive phoned home events anymore or has never booted successfully. ⭕ Machine is in a provisioning crash loop. Flag can be reset through an API-triggered reboot or when the machine reaches the phoned home state. 🚑 Machine reclaim has failed. The machine was deleted but it is not going back into the available machine pool. 🛡 Machine is connected to our VPN, ssh access only possible via this VPN.
metalctl machine issues [<machine ID>] [flags]Options
--bmc-address string bmc ipmi address (needs to include port) to filter [optional]
+ --bmc-mac string bmc mac address to filter [optional]
+ --board-part-number string fru board part number to filter [optional]
+ -h, --help help for issues
+ --hostname string allocation hostname to filter [optional]
+ --id string ID to filter [optional]
+ --image string allocation image to filter [optional]
+ --last-event-error-threshold duration the duration up to how long in the past a machine last event error will be counted as an issue [optional]
+ --mac string mac to filter [optional]
+ --manufacturer string fru manufacturer to filter [optional]
+ --name string allocation name to filter [optional]
+ --network-destination-prefixes string network destination prefixes to filter [optional]
+ --network-ids string network ids to filter [optional]
+ --network-ips string network ips to filter [optional]
+ --omit strings issue types to omit [optional]
+ --only strings issue types to include [optional]
+ --partition string partition to filter [optional]
+ --product-part-number string fru product part number to filter [optional]
+ --product-serial string fru product serial to filter [optional]
+ --project string allocation project to filter [optional]
+ --rack string rack to filter [optional]
+ --role string allocation role to filter [optional]
+ --severity string issue severity to include [optional]
+ --size string size to filter [optional]
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: age|bios|bmc|event|id|liveliness|partition|project|rack|size|when
+ --state string state to filter [optional]
+ --tags strings tags to filter, use it like: --tags "tag1,tag2" or --tags "tag3".Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
- metalctl machine issues list - list all machine issues that the metal-api can evaluate
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine issues list
list all machine issues that the metal-api can evaluate
metalctl machine issues list [flags]Options
-h, --help help for list
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: id|severityOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine issues - display machines which are in a potential bad state
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine list
list all machines
Synopsis
list all machines
Meaning of the emojis:
🚧 Machine is reserved. Reserved machines are not considered for random allocation until the reservation flag is removed. 🔒 Machine is locked. Locked machines can not be deleted until the lock is removed. 💀 Machine is dead. The metal-api does not receive any events from this machine. ❗ Machine has a last event error. The machine has recently encountered an error during the provisioning lifecycle. ❓ Machine is in unknown condition. The metal-api does not receive phoned home events anymore or has never booted successfully. ⭕ Machine is in a provisioning crash loop. Flag can be reset through an API-triggered reboot or when the machine reaches the phoned home state. 🚑 Machine reclaim has failed. The machine was deleted but it is not going back into the available machine pool. 🛡 Machine is connected to our VPN, ssh access only possible via this VPN.
metalctl machine list [flags]Options
--bmc-address string bmc ipmi address (needs to include port) to filter [optional]
+ --bmc-mac string bmc mac address to filter [optional]
+ --board-part-number string fru board part number to filter [optional]
+ -h, --help help for list
+ --hostname string allocation hostname to filter [optional]
+ --id string ID to filter [optional]
+ --image string allocation image to filter [optional]
+ --last-event-error-threshold duration the duration up to how long in the past a machine last event error will be counted as an issue [optional] (default 1h0m0s)
+ --mac string mac to filter [optional]
+ --manufacturer string fru manufacturer to filter [optional]
+ --name string allocation name to filter [optional]
+ --network-destination-prefixes string network destination prefixes to filter [optional]
+ --network-ids string network ids to filter [optional]
+ --network-ips string network ips to filter [optional]
+ --partition string partition to filter [optional]
+ --product-part-number string fru product part number to filter [optional]
+ --product-serial string fru product serial to filter [optional]
+ --project string allocation project to filter [optional]
+ --rack string rack to filter [optional]
+ --role string allocation role to filter [optional]
+ --size string size to filter [optional]
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: age|event|id|image|liveliness|partition|project|rack|size|when
+ --state string state to filter [optional]
+ --tags strings tags to filter, use it like: --tags "tag1,tag2" or --tags "tag3".Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine lock
lock a machine
Synopsis
when a machine is locked, it can not be destroyed, to destroy a machine you must first remove the lock from that machine with –remove
metalctl machine lock <machine ID> [flags]Options
-d, --description string description of the reason for the lock.
+ -h, --help help for lock
+ -r, --remove remove the lock.Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine logs
display machine provisioning logs
metalctl machine logs <machine ID> [flags]Options
-h, --help help for logs
+ --last-event-error-threshold duration the duration up to how long in the past a machine last event error will be counted as an issue [optional] (default 168h0m0s)Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine power
manage machine power
Options
-h, --help help for powerOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
- metalctl machine power bios - boot a machine into BIOS
- metalctl machine power cycle - power cycle a machine (graceful shutdown)
- metalctl machine power disk - boot a machine from disk
- metalctl machine power off - power off a machine
- metalctl machine power on - power on a machine
- metalctl machine power pxe - boot a machine from PXE
- metalctl machine power reset - power reset a machine
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine power bios
boot a machine into BIOS
Synopsis
the machine will boot into bios. (machine does not reboot automatically)
metalctl machine power bios <machine ID> [flags]Options
-h, --help help for biosOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine power - manage machine power
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine power cycle
power cycle a machine (graceful shutdown)
Synopsis
(soft) cycle the machine power.
metalctl machine power cycle <machine ID> [flags]Options
-h, --help help for cycleOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine power - manage machine power
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine power disk
boot a machine from disk
Synopsis
the machine will boot from disk. (machine does not reboot automatically)
metalctl machine power disk <machine ID> [flags]Options
-h, --help help for diskOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine power - manage machine power
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine power off
power off a machine
Synopsis
set the machine to power off state, if the machine already was off nothing happens. It will usually take some time to power off the machine, depending on the machine type. Power on will therefore not work if the machine is in the powering off phase.
metalctl machine power off <machine ID> [flags]Options
-h, --help help for offOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine power - manage machine power
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine power on
power on a machine
Synopsis
set the machine to power on state, if the machine already was on nothing happens.
metalctl machine power on <machine ID> [flags]Options
-h, --help help for onOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine power - manage machine power
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine power pxe
boot a machine from PXE
Synopsis
the machine will boot from PXE. (machine does not reboot automatically)
metalctl machine power pxe <machine ID> [flags]Options
-h, --help help for pxeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine power - manage machine power
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine power reset
power reset a machine
Synopsis
(hard) reset the machine power.
metalctl machine power reset <machine ID> [flags]Options
-h, --help help for resetOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine power - manage machine power
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine reinstall
reinstalls an already allocated machine
Synopsis
reinstalls an already allocated machine. If it is not yet allocated, nothing happens, otherwise only the machine's primary disk is wiped and the new image will subsequently be installed on that device
metalctl machine reinstall <machine ID> [flags]Options
-d, --description string description of the reinstallation. [optional]
+ -h, --help help for reinstall
+ --image string id of the image to get installed. [required]Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine reserve
reserve a machine
Synopsis
reserve a machine for exclusive usage, this machine will no longer be picked by other allocations. This is useful for maintenance of the machine or testing. After the reservation is not needed anymore, the reservation should be removed with –remove.
metalctl machine reserve <machine ID> [flags]Options
-d, --description string description of the reason for the reservation.
+ -h, --help help for reserve
+ -r, --remove remove the reservation.Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine update-firmware
update a machine firmware
Options
-h, --help help for update-firmwareOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
- metalctl machine update-firmware bios - update a machine BIOS
- metalctl machine update-firmware bmc - update a machine BMC
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine update-firmware bios
update a machine BIOS
Synopsis
the machine BIOS will be updated to given revision. If revision flag is not specified an update plan will be printed instead.
metalctl machine update-firmware bios <machine ID> [flags]Options
--description string the reason why the BIOS should be updated
+ -h, --help help for bios
+ --revision string the BIOS revisionOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine update-firmware - update a machine firmware
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine update-firmware bmc
update a machine BMC
Synopsis
the machine BMC will be updated to given revision. If revision flag is not specified an update plan will be printed instead.
metalctl machine update-firmware bmc <machine ID> [flags]Options
--description string the reason why the BMC should be updated
+ -h, --help help for bmc
+ --revision string the BMC revisionOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine update-firmware - update a machine firmware
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl machine update
updates the machine
metalctl machine update <id> [flags]Options
--add-tags strings tags to be added to the machine [optional]
+ --bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ --description string the description of the machine [optional]
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl machine describe machine-1 -o yaml > machine.yaml
+ $ vi machine.yaml
+ $ # either via stdin
+ $ cat machine.yaml | metalctl machine update <id> -f -
+ $ # or via file
+ $ metalctl machine update <id> -f machine.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --remove-tags strings tags to be removed from the machine [optional]
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl machine - manage machine entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl markdown
create markdown documentation
metalctl markdown [flags]Options
-h, --help help for markdownOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network
manage network entities
Synopsis
networks can be attached to a machine or firewall such that they can communicate with each other.
Options
-h, --help help for networkOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl network allocate - allocate a network
- metalctl network apply - applies one or more networks from a given file
- metalctl network create - creates the network
- metalctl network delete - deletes the network
- metalctl network describe - describes the network
- metalctl network edit - edit the network through an editor and update
- metalctl network free - free a network
- metalctl network ip - manage ip entities
- metalctl network list - list all networks
- metalctl network update - updates the network
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network allocate
allocate a network
metalctl network allocate [flags]Options
-d, --description string description of the network to create. [optional]
+ --dmz use this private network as dmz. [optional]
+ -h, --help help for allocate
+ --labels strings labels for this network. [optional]
+ -n, --name string name of the network to create. [required]
+ --partition string partition where this network should exist. [required]
+ --project string partition where this network should exist. [required]
+ --shared shared allows usage of this private network from other networksOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network - manage network entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network apply
applies one or more networks from a given file
metalctl network apply [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl network describe network-1 -o yaml > network.yaml
+ $ vi network.yaml
+ $ # either via stdin
+ $ cat network.yaml | metalctl network apply -f -
+ $ # or via file
+ $ metalctl network apply -f network.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for apply
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network - manage network entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network create
creates the network
metalctl network create [flags]Options
--additional-announcable-cidrs strings list of cidrs which are added to the route maps per tenant private network, these are typically pod- and service cidrs, can only be set in a supernetwork
+ --bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -d, --description string description of the network to create. [optional]
+ --destination-prefixes strings destination prefixes in this network.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl network describe network-1 -o yaml > network.yaml
+ $ vi network.yaml
+ $ # either via stdin
+ $ cat network.yaml | metalctl network create -f -
+ $ # or via file
+ $ metalctl network create -f network.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for create
+ --id string id of the network to create. [optional]
+ --labels strings add initial labels, must be in the form of key=value, use it like: --labels "key1=value1,key2=value2".
+ -n, --name string name of the network to create. [optional]
+ --nat set nat flag of network, if set to true, traffic from this network will be natted.
+ -p, --partition string partition where this network should exist.
+ --prefixes strings prefixes in this network.
+ --privatesuper set private super flag of network, if set to true, this network is used to start machines there.
+ --project string project of the network to create. [optional]
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operations
+ --underlay set underlay flag of network, if set to true, this is used to transport underlay network traffic
+ --vrf int vrf of this network
+ --vrfshared vrf shared allows multiple networks to share a vrfOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network - manage network entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network delete
deletes the network
metalctl network delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl network describe network-1 -o yaml > network.yaml
+ $ vi network.yaml
+ $ # either via stdin
+ $ cat network.yaml | metalctl network delete <id> -f -
+ $ # or via file
+ $ metalctl network delete <id> -f network.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for delete
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network - manage network entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network describe
describes the network
metalctl network describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network - manage network entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network edit
edit the network through an editor and update
metalctl network edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network - manage network entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network free
free a network
metalctl network free <networkid> [flags]Options
-h, --help help for freeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network - manage network entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network ip
manage ip entities
Synopsis
an ip address can be attached to a machine or firewall such that network traffic can be routed to these servers.
Options
-h, --help help for ipOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network - manage network entities
- metalctl network ip apply - applies one or more ips from a given file
- metalctl network ip create - creates the ip
- metalctl network ip delete - deletes the ip
- metalctl network ip describe - describes the ip
- metalctl network ip edit - edit the ip through an editor and update
- metalctl network ip issues - display ips which are in a potential bad state
- metalctl network ip list - list all ips
- metalctl network ip update - updates the ip
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network ip apply
applies one or more ips from a given file
metalctl network ip apply [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl ip describe ip-1 -o yaml > ip.yaml
+ $ vi ip.yaml
+ $ # either via stdin
+ $ cat ip.yaml | metalctl ip apply -f -
+ $ # or via file
+ $ metalctl ip apply -f ip.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for apply
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network ip - manage ip entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network ip create
creates the ip
metalctl network ip create [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -d, --description string description of the IP to allocate. [optional]
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl ip describe ip-1 -o yaml > ip.yaml
+ $ vi ip.yaml
+ $ # either via stdin
+ $ cat ip.yaml | metalctl ip create -f -
+ $ # or via file
+ $ metalctl ip create -f ip.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for create
+ --ipaddress string a specific ip address to allocate. [optional]
+ -n, --name string name of the IP to allocate. [optional]
+ --network string network from where the IP should be allocated.
+ --project string project for which the IP should be allocated.
+ --skip-security-prompts skips security prompt for bulk operations
+ --tags strings tags to attach to the IP.
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operations
+ --type string type of the IP to allocate: ephemeral|static [optional] (default "ephemeral")Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network ip - manage ip entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network ip delete
deletes the ip
metalctl network ip delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl ip describe ip-1 -o yaml > ip.yaml
+ $ vi ip.yaml
+ $ # either via stdin
+ $ cat ip.yaml | metalctl ip delete <id> -f -
+ $ # or via file
+ $ metalctl ip delete <id> -f ip.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for delete
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network ip - manage ip entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network ip describe
describes the ip
metalctl network ip describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network ip - manage ip entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network ip edit
edit the ip through an editor and update
metalctl network ip edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network ip - manage ip entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network ip issues
display ips which are in a potential bad state
metalctl network ip issues [flags]Options
-h, --help help for issuesOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network ip - manage ip entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network ip list
list all ips
metalctl network ip list [flags]Options
-h, --help help for list
+ --ipaddress string ipaddress to filter [optional]
+ --machineid string machineid to filter [optional]
+ --name string name to filter [optional]
+ --network string network to filter [optional]
+ --prefix string prefix to filter [optional]
+ --project string project to filter [optional]
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: age|description|id|ipaddress|name|network|type
+ --tags strings tags to filter [optional]
+ --type string type to filter [optional]Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network ip - manage ip entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network ip update
updates the ip
metalctl network ip update [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl ip describe ip-1 -o yaml > ip.yaml
+ $ vi ip.yaml
+ $ # either via stdin
+ $ cat ip.yaml | metalctl ip update -f -
+ $ # or via file
+ $ metalctl ip update -f ip.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network ip - manage ip entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network list
list all networks
metalctl network list [flags]Options
--destination-prefixes strings destination prefixes to filter, use it like: --destination-prefixes prefix1,prefix2.
+ -h, --help help for list
+ --id string ID to filter [optional]
+ --name string name to filter [optional]
+ --nat nat to filter [optional]
+ --parent string parent network to filter [optional]
+ --partition string partition to filter [optional]
+ --prefixes strings prefixes to filter, use it like: --prefixes prefix1,prefix2.
+ --privatesuper privatesuper to filter [optional]
+ --project string project to filter [optional]
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: description|id|name|partition|project
+ --underlay underlay to filter [optional]
+ --vrf int vrf to filter [optional]Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network - manage network entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl network update
updates the network
metalctl network update <id> [flags]Options
--add-destinationprefixes strings destination prefixes to be added to the network [optional]
+ --add-prefixes strings prefixes to be added to the network [optional]
+ --additional-announcable-cidrs strings list of cidrs which are added to the route maps per tenant private network, these are typically pod- and service cidrs, can only be set in a supernetwork
+ --bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ --description string the description of the network [optional]
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl network describe network-1 -o yaml > network.yaml
+ $ vi network.yaml
+ $ # either via stdin
+ $ cat network.yaml | metalctl network update <id> -f -
+ $ # or via file
+ $ metalctl network update <id> -f network.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --labels strings the labels of the network, must be in the form of key=value, use it like: --labels "key1=value1,key2=value2". [optional]
+ --name string the name of the network [optional]
+ --remove-destinationprefixes strings destination prefixes to be removed from the network [optional]
+ --remove-prefixes strings prefixes to be removed from the network [optional]
+ --shared marks a network as shared or not [optional]
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl network - manage network entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl partition
manage partition entities
Synopsis
a partition is a failure domain in the data center.
Options
-h, --help help for partitionOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl partition apply - applies one or more partitions from a given file
- metalctl partition capacity - show partition capacity
- metalctl partition create - creates the partition
- metalctl partition delete - deletes the partition
- metalctl partition describe - describes the partition
- metalctl partition edit - edit the partition through an editor and update
- metalctl partition list - list all partitions
- metalctl partition update - updates the partition
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl partition apply
applies one or more partitions from a given file
metalctl partition apply [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl partition describe partition-1 -o yaml > partition.yaml
+ $ vi partition.yaml
+ $ # either via stdin
+ $ cat partition.yaml | metalctl partition apply -f -
+ $ # or via file
+ $ metalctl partition apply -f partition.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for apply
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl partition - manage partition entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl partition capacity
show partition capacity
metalctl partition capacity [flags]Options
-h, --help help for capacity
+ --id string filter on partition id. [optional]
+ --project-id string consider project-specific counts, e.g. size reservations. [optional]
+ --size string filter on size id. [optional]
+ --sort-by strings order by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: description|id|nameOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl partition - manage partition entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl partition create
creates the partition
metalctl partition create [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ --cmdline string kernel commandline for the metal-hammer in the partition. [required]
+ -d, --description string Description of the partition. [required]
+ --dnsservers string dns servers for the machines and firewalls in the partition. [optional]
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl partition describe partition-1 -o yaml > partition.yaml
+ $ vi partition.yaml
+ $ # either via stdin
+ $ cat partition.yaml | metalctl partition create -f -
+ $ # or via file
+ $ metalctl partition create -f partition.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for create
+ --id string ID of the partition. [required]
+ --imageurl string initrd for the metal-hammer in the partition. [required]
+ --kernelurl string kernel url for the metal-hammer in the partition. [required]
+ --mgmtserver string management server address in the partition. [required]
+ -n, --name string Name of the partition. [optional]
+ --ntpservers string ntp servers for the machines and firewalls in the partition. [optional]
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl partition - manage partition entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl partition delete
deletes the partition
metalctl partition delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl partition describe partition-1 -o yaml > partition.yaml
+ $ vi partition.yaml
+ $ # either via stdin
+ $ cat partition.yaml | metalctl partition delete <id> -f -
+ $ # or via file
+ $ metalctl partition delete <id> -f partition.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for delete
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl partition - manage partition entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl partition describe
describes the partition
metalctl partition describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl partition - manage partition entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl partition edit
edit the partition through an editor and update
metalctl partition edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl partition - manage partition entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl partition list
list all partitions
metalctl partition list [flags]Options
-h, --help help for list
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: description|id|nameOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl partition - manage partition entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl partition update
updates the partition
metalctl partition update [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl partition describe partition-1 -o yaml > partition.yaml
+ $ vi partition.yaml
+ $ # either via stdin
+ $ cat partition.yaml | metalctl partition update -f -
+ $ # or via file
+ $ metalctl partition update -f partition.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl partition - manage partition entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl project
manage project entities
Synopsis
a project belongs to a tenant and groups together entities in metal-stack.
Options
-h, --help help for projectOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl project apply - applies one or more projects from a given file
- metalctl project create - creates the project
- metalctl project delete - deletes the project
- metalctl project describe - describes the project
- metalctl project edit - edit the project through an editor and update
- metalctl project list - list all projects
- metalctl project update - updates the project
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl project apply
applies one or more projects from a given file
metalctl project apply [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl project describe project-1 -o yaml > project.yaml
+ $ vi project.yaml
+ $ # either via stdin
+ $ cat project.yaml | metalctl project apply -f -
+ $ # or via file
+ $ metalctl project apply -f project.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for apply
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl project - manage project entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl project create
creates the project
metalctl project create [flags]Options
--annotation strings add initial annotation, must be in the form of key=value, can be given multiple times to add multiple annotations, e.g. --annotation key=value --annotation foo=bar
+ --bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ --cluster-quota int32 cluster quota
+ --description string description of the project.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl project describe project-1 -o yaml > project.yaml
+ $ vi project.yaml
+ $ # either via stdin
+ $ cat project.yaml | metalctl project create -f -
+ $ # or via file
+ $ metalctl project create -f project.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for create
+ --ip-quota int32 ip quota
+ --label strings add initial label, can be given multiple times to add multiple labels, e.g. --label=foo --label=bar
+ --machine-quota int32 machine quota
+ --name string name of the project, max 10 characters.
+ --skip-security-prompts skips security prompt for bulk operations
+ --tenant string create project for given tenant
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl project - manage project entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl project delete
deletes the project
metalctl project delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl project describe project-1 -o yaml > project.yaml
+ $ vi project.yaml
+ $ # either via stdin
+ $ cat project.yaml | metalctl project delete <id> -f -
+ $ # or via file
+ $ metalctl project delete <id> -f project.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for delete
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl project - manage project entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl project describe
describes the project
metalctl project describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl project - manage project entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl project edit
edit the project through an editor and update
metalctl project edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl project - manage project entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl project list
list all projects
metalctl project list [flags]Options
-h, --help help for list
+ --id string ID of the project.
+ --name string Name of the project.
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: description|id|name|tenant
+ --tenant string tenant of this project.Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl project - manage project entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl project update
updates the project
metalctl project update [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl project describe project-1 -o yaml > project.yaml
+ $ vi project.yaml
+ $ # either via stdin
+ $ cat project.yaml | metalctl project update -f -
+ $ # or via file
+ $ metalctl project update -f project.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl project - manage project entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size
manage size entities
Synopsis
a size matches a machine in terms of cpu cores, ram and storage.
Options
-h, --help help for sizeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl size apply - applies one or more sizes from a given file
- metalctl size create - creates the size
- metalctl size delete - deletes the size
- metalctl size describe - describes the size
- metalctl size edit - edit the size through an editor and update
- metalctl size imageconstraint - manage imageconstraint entities
- metalctl size list - list all sizes
- metalctl size reservation - manage reservation entities
- metalctl size suggest - suggest size from a given machine id
- metalctl size update - updates the size
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size apply
applies one or more sizes from a given file
metalctl size apply [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl size describe size-1 -o yaml > size.yaml
+ $ vi size.yaml
+ $ # either via stdin
+ $ cat size.yaml | metalctl size apply -f -
+ $ # or via file
+ $ metalctl size apply -f size.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for apply
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size - manage size entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size create
creates the size
metalctl size create [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -d, --description string Description of the size. [required]
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl size describe size-1 -o yaml > size.yaml
+ $ vi size.yaml
+ $ # either via stdin
+ $ cat size.yaml | metalctl size create -f -
+ $ # or via file
+ $ metalctl size create -f size.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for create
+ --id string ID of the size. [required]
+ --max int min value of given size constraint type. [required]
+ --min int min value of given size constraint type. [required]
+ -n, --name string Name of the size. [optional]
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operations
+ --type string type of constraints. [required]Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size - manage size entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size delete
deletes the size
metalctl size delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl size describe size-1 -o yaml > size.yaml
+ $ vi size.yaml
+ $ # either via stdin
+ $ cat size.yaml | metalctl size delete <id> -f -
+ $ # or via file
+ $ metalctl size delete <id> -f size.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for delete
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size - manage size entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size describe
describes the size
metalctl size describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size - manage size entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size edit
edit the size through an editor and update
metalctl size edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size - manage size entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size imageconstraint
manage imageconstraint entities
Synopsis
if a size has specific requirements regarding the images which must fulfill certain constraints, this can be configured here.
Options
-h, --help help for imageconstraintOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size - manage size entities
- metalctl size imageconstraint apply - applies one or more imageconstraints from a given file
- metalctl size imageconstraint create - creates the imageconstraint
- metalctl size imageconstraint delete - deletes the imageconstraint
- metalctl size imageconstraint describe - describes the imageconstraint
- metalctl size imageconstraint edit - edit the imageconstraint through an editor and update
- metalctl size imageconstraint list - list all imageconstraints
- metalctl size imageconstraint try - try if size and image can be allocated
- metalctl size imageconstraint update - updates the imageconstraint
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size imageconstraint apply
applies one or more imageconstraints from a given file
metalctl size imageconstraint apply [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl imageconstraint describe imageconstraint-1 -o yaml > imageconstraint.yaml
+ $ vi imageconstraint.yaml
+ $ # either via stdin
+ $ cat imageconstraint.yaml | metalctl imageconstraint apply -f -
+ $ # or via file
+ $ metalctl imageconstraint apply -f imageconstraint.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for apply
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size imageconstraint - manage imageconstraint entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size imageconstraint create
creates the imageconstraint
metalctl size imageconstraint create [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl imageconstraint describe imageconstraint-1 -o yaml > imageconstraint.yaml
+ $ vi imageconstraint.yaml
+ $ # either via stdin
+ $ cat imageconstraint.yaml | metalctl imageconstraint create -f -
+ $ # or via file
+ $ metalctl imageconstraint create -f imageconstraint.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for create
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size imageconstraint - manage imageconstraint entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size imageconstraint delete
deletes the imageconstraint
metalctl size imageconstraint delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl imageconstraint describe imageconstraint-1 -o yaml > imageconstraint.yaml
+ $ vi imageconstraint.yaml
+ $ # either via stdin
+ $ cat imageconstraint.yaml | metalctl imageconstraint delete <id> -f -
+ $ # or via file
+ $ metalctl imageconstraint delete <id> -f imageconstraint.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for delete
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size imageconstraint - manage imageconstraint entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size imageconstraint describe
describes the imageconstraint
metalctl size imageconstraint describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size imageconstraint - manage imageconstraint entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size imageconstraint edit
edit the imageconstraint through an editor and update
metalctl size imageconstraint edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size imageconstraint - manage imageconstraint entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size imageconstraint list
list all imageconstraints
metalctl size imageconstraint list [flags]Options
-h, --help help for list
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: description|id|nameOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size imageconstraint - manage imageconstraint entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size imageconstraint try
try if size and image can be allocated
metalctl size imageconstraint try [flags]Options
-h, --help help for try
+ --image string image to check if allocaltion is possible
+ --size string size to check if allocaltion is possibleOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size imageconstraint - manage imageconstraint entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size imageconstraint update
updates the imageconstraint
metalctl size imageconstraint update [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl imageconstraint describe imageconstraint-1 -o yaml > imageconstraint.yaml
+ $ vi imageconstraint.yaml
+ $ # either via stdin
+ $ cat imageconstraint.yaml | metalctl imageconstraint update -f -
+ $ # or via file
+ $ metalctl imageconstraint update -f imageconstraint.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size imageconstraint - manage imageconstraint entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size list
list all sizes
metalctl size list [flags]Options
-h, --help help for list
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: description|id|nameOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size - manage size entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size reservation
manage reservation entities
Synopsis
manage size reservations
Options
-h, --help help for reservationOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size - manage size entities
- metalctl size reservation apply - applies one or more reservations from a given file
- metalctl size reservation create - creates the reservation
- metalctl size reservation delete - deletes the reservation
- metalctl size reservation describe - describes the reservation
- metalctl size reservation edit - edit the reservation through an editor and update
- metalctl size reservation list - list all reservations
- metalctl size reservation update - updates the reservation
- metalctl size reservation usage - see current usage of size reservations
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size reservation apply
applies one or more reservations from a given file
metalctl size reservation apply [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl reservation describe reservation-1 -o yaml > reservation.yaml
+ $ vi reservation.yaml
+ $ # either via stdin
+ $ cat reservation.yaml | metalctl reservation apply -f -
+ $ # or via file
+ $ metalctl reservation apply -f reservation.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for apply
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size reservation - manage reservation entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size reservation create
creates the reservation
metalctl size reservation create [flags]Options
--amount int32 the amount to associate with this reservation
+ --bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ --description string the description to associate with this reservation
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl reservation describe reservation-1 -o yaml > reservation.yaml
+ $ vi reservation.yaml
+ $ # either via stdin
+ $ cat reservation.yaml | metalctl reservation create -f -
+ $ # or via file
+ $ metalctl reservation create -f reservation.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for create
+ --id string the id to associate with this reservation
+ --labels strings the labels to associate with this reservation
+ --partitions strings the partition ids to associate with this reservation
+ --project string the project id to associate with this reservation
+ --size string the size id to associate with this reservation
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size reservation - manage reservation entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size reservation delete
deletes the reservation
metalctl size reservation delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl reservation describe reservation-1 -o yaml > reservation.yaml
+ $ vi reservation.yaml
+ $ # either via stdin
+ $ cat reservation.yaml | metalctl reservation delete <id> -f -
+ $ # or via file
+ $ metalctl reservation delete <id> -f reservation.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for delete
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size reservation - manage reservation entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size reservation describe
describes the reservation
metalctl size reservation describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size reservation - manage reservation entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size reservation edit
edit the reservation through an editor and update
metalctl size reservation edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size reservation - manage reservation entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size reservation list
list all reservations
metalctl size reservation list [flags]Options
-h, --help help for list
+ --id string the id to filter
+ --partition string the partition id to filter
+ --project string the project id to filter
+ --size string the size id to filter
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: amount|id|partition|project|sizeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size reservation - manage reservation entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size reservation update
updates the reservation
metalctl size reservation update <id> [flags]Options
--amount int32 the amount to associate with this reservation
+ --bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ --description string the description to associate with this reservation
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl reservation describe reservation-1 -o yaml > reservation.yaml
+ $ vi reservation.yaml
+ $ # either via stdin
+ $ cat reservation.yaml | metalctl reservation update <id> -f -
+ $ # or via file
+ $ metalctl reservation update <id> -f reservation.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --labels strings the labels to associate with this reservation
+ --partitions strings the partition ids to associate with this reservation
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size reservation - manage reservation entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size reservation usage
see current usage of size reservations
metalctl size reservation usage [flags]Options
-h, --help help for usage
+ --partition string the partition to filter
+ --project string the project to filter
+ --size-id string the size-id to filter
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: amount|id|partition|project|size|used-amountOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size reservation - manage reservation entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size suggest
suggest size from a given machine id
metalctl size suggest <id> [flags]Options
--description string The description of the suggested size (default "a suggested size")
+ -h, --help help for suggest
+ --labels strings labels to add to the size
+ --machine-id string Machine id used to create the size suggestion. [required]
+ --name string The name of the suggested size (default "suggested-size")Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size - manage size entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl size update
updates the size
metalctl size update [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl size describe size-1 -o yaml > size.yaml
+ $ vi size.yaml
+ $ # either via stdin
+ $ cat size.yaml | metalctl size update -f -
+ $ # or via file
+ $ metalctl size update -f size.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl size - manage size entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch
manage switch entities
Synopsis
switch are the leaf switches in the data center that are controlled by metal-stack.
Options
-h, --help help for switchOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl switch connected-machines - shows switches with their connected machines
- metalctl switch console - connect to the switch console
- metalctl switch delete - deletes the switch
- metalctl switch describe - describes the switch
- metalctl switch detail - switch details
- metalctl switch edit - edit the switch through an editor and update
- metalctl switch list - list all switches
- metalctl switch migrate - migrate machine connections and other configuration from one switch to another
- metalctl switch port - sets the given switch port state up or down
- metalctl switch replace - put a leaf switch into replace mode in preparation for physical replacement. For a description of the steps involved see the long help.
- metalctl switch ssh - connect to the switch via ssh
- metalctl switch update - updates the switch
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch connected-machines
shows switches with their connected machines
metalctl switch connected-machines [flags]Examples
The command will show the machines connected to the switch ports.
+
+Can also be used with -o template in order to generate CSV-style output:
+
+$ metalctl switch connected-machines -o template --template '{{ $machines := .machines }}{{ range .switches }}{{ $switch := . }}{{ range .connections }}{{ $switch.id }},{{ $switch.rack_id }},{{ .nic.name }},{{ .machine_id }},{{ (index $machines .machine_id).ipmi.fru.product_serial }}{{ printf "\n" }}{{ end }}{{ end }}'
+r01leaf01,swp1,f78cc340-e5e8-48ed-8fe7-2336c1e2ded2,<a-serial>
+r01leaf01,swp2,44e3a522-5f48-4f3c-9188-41025f9e401e,<b-serial>
+...
+Options
-h, --help help for connected-machines
+ --id string ID of the switch.
+ --machine-id string The id of the connected machine, ignores size flag if set.
+ --name string Name of the switch.
+ --os-vendor string OS vendor of this switch.
+ --os-version string OS version of this switch.
+ --partition string Partition of this switch.
+ --rack string Rack of this switch.
+ --size string Size of the connected machines.Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch console
connect to the switch console
Synopsis
this requires a network connectivity to the ip address of the console server this switch is connected to.
metalctl switch console <switchID> [flags]Options
-h, --help help for consoleOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch delete
deletes the switch
metalctl switch delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl switch describe switch-1 -o yaml > switch.yaml
+ $ vi switch.yaml
+ $ # either via stdin
+ $ cat switch.yaml | metalctl switch delete <id> -f -
+ $ # or via file
+ $ metalctl switch delete <id> -f switch.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ --force forcefully delete the switch accepting the risk that it still has machines connected to it
+ -h, --help help for delete
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch describe
describes the switch
metalctl switch describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch detail
switch details
metalctl switch detail [flags]Options
-h, --help help for detail
+ --id string ID of the switch.
+ --name string Name of the switch.
+ --os-vendor string OS vendor of this switch.
+ --os-version string OS version of this switch.
+ --partition string Partition of this switch.
+ --rack string Rack of this switch.Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch edit
edit the switch through an editor and update
metalctl switch edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch list
list all switches
metalctl switch list [flags]Options
-h, --help help for list
+ --id string ID of the switch.
+ --name string Name of the switch.
+ --os-vendor string OS vendor of this switch.
+ --os-version string OS version of this switch.
+ --partition string Partition of this switch.
+ --rack string Rack of this switch.
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: description|id|nameOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch migrate
migrate machine connections and other configuration from one switch to another
metalctl switch migrate <oldSwitchID> <newSwitchID> [flags]Options
-h, --help help for migrateOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch port
sets the given switch port state up or down
Options
-h, --help help for port
+ --port string the port to be changed.Options inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
- metalctl switch port describe - gets the given switch port state
- metalctl switch port down - sets the given switch port state down
- metalctl switch port up - sets the given switch port state up
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch port describe
gets the given switch port state
Synopsis
shows the current actual and desired state of the port of the given switch.
metalctl switch port describe <switch ID> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --port string the port to be changed.
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch port - sets the given switch port state up or down
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch port down
sets the given switch port state down
Synopsis
sets the port status to DOWN so the connected machine will not be able to connect to the switch.
metalctl switch port down <switch ID> [flags]Options
-h, --help help for downOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --port string the port to be changed.
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch port - sets the given switch port state up or down
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch port up
sets the given switch port state up
Synopsis
sets the port status to UP so the connected machine will be able to connect to the switch.
metalctl switch port up <switch ID> [flags]Options
-h, --help help for upOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --port string the port to be changed.
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch port - sets the given switch port state up or down
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch replace
put a leaf switch into replace mode in preparation for physical replacement. For a description of the steps involved see the long help.
Synopsis
Put a leaf switch into replace mode in preparation for physical replacement
Operational steps to replace a switch:
- Put the switch that needs to be replaced in replace mode with this command
- Replace the switch MAC address in the metal-stack deployment configuration
- Make sure that interfaces on the new switch do not get connected to the PXE-bridge immediately by setting the interfaces list of the respective leaf switch to [] in the metal-stack deployment configuration
- Deploy the management servers so that the dhcp servers will serve the right address and DHCP options to the new switch
- Replace the switch physically. Be careful to ensure that the cabling mirrors the remaining leaf exactly because the new switch information will be cloned from the remaining switch! Also make sure to have console access to the switch so you can start and monitor the install process
- If the switch is not in onie install mode but already has an operating system installed, put it into install mode with "sudo onie-select -i -f -v" and reboot it. Now the switch should be provisioned with a management IP from a management server, install itself with the right software image and receive license and ssh keys through ZTP. You can check whether that process has completed successfully with the command "sudo ztp -s". The ZTP state should be disabled and the result should be success.
- Deploy the switch plane and metal-core through metal-stack deployment CI job
- The switch will now register with its metal-api, and the metal-core service will receive the cloned interface and routing information. You can verify successful switch replacement by checking the interface and BGP configuration, and checking the switch status with "metalctl switch ls -o wide"; it should now be operational again
metalctl switch replace <switchID> [flags]Options
-h, --help help for replaceOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch ssh
connect to the switch via ssh
Synopsis
this requires a network connectivity to the management ip address of the switch.
metalctl switch ssh <switchID> [flags]Options
-h, --help help for sshOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl switch update
updates the switch
metalctl switch update [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl switch describe switch-1 -o yaml > switch.yaml
+ $ vi switch.yaml
+ $ # either via stdin
+ $ cat switch.yaml | metalctl switch update -f -
+ $ # or via file
+ $ metalctl switch update -f switch.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl switch - manage switch entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl tenant
manage tenant entities
Synopsis
a tenant belongs to a tenant and groups together entities in metal-stack.
Options
-h, --help help for tenantOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl tenant apply - applies one or more tenants from a given file
- metalctl tenant create - creates the tenant
- metalctl tenant delete - deletes the tenant
- metalctl tenant describe - describes the tenant
- metalctl tenant edit - edit the tenant through an editor and update
- metalctl tenant list - list all tenants
- metalctl tenant update - updates the tenant
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl tenant apply
applies one or more tenants from a given file
metalctl tenant apply [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl tenant describe tenant-1 -o yaml > tenant.yaml
+ $ vi tenant.yaml
+ $ # either via stdin
+ $ cat tenant.yaml | metalctl tenant apply -f -
+ $ # or via file
+ $ metalctl tenant apply -f tenant.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for apply
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl tenant - manage tenant entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl tenant create
creates the tenant
metalctl tenant create [flags]Options
--annotations strings add initial annotations, must be in the form of key=value, can be given multiple times to add multiple annotations, e.g. --annotation key=value --annotation foo=bar
+ --bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ --cluster-quota int32 cluster quota
+ --description string description of the tenant.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl tenant describe tenant-1 -o yaml > tenant.yaml
+ $ vi tenant.yaml
+ $ # either via stdin
+ $ cat tenant.yaml | metalctl tenant create -f -
+ $ # or via file
+ $ metalctl tenant create -f tenant.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for create
+ --id string id of the tenant, max 10 characters.
+ --ip-quota int32 ip quota
+ --labels strings add initial label, can be given multiple times to add multiple labels, e.g. --label=foo --label=bar
+ --machine-quota int32 machine quota
+ --name string name of the tenant, max 10 characters.
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl tenant - manage tenant entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl tenant delete
deletes the tenant
metalctl tenant delete <id> [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl tenant describe tenant-1 -o yaml > tenant.yaml
+ $ vi tenant.yaml
+ $ # either via stdin
+ $ cat tenant.yaml | metalctl tenant delete <id> -f -
+ $ # or via file
+ $ metalctl tenant delete <id> -f tenant.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for delete
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl tenant - manage tenant entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl tenant describe
describes the tenant
metalctl tenant describe <id> [flags]Options
-h, --help help for describeOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl tenant - manage tenant entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl tenant edit
edit the tenant through an editor and update
metalctl tenant edit <id> [flags]Options
-h, --help help for editOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl tenant - manage tenant entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl tenant list
list all tenants
metalctl tenant list [flags]Options
--annotations strings annotations
+ -h, --help help for list
+ --id string ID of the tenant.
+ --name string Name of the tenant.
+ --sort-by strings sort by (comma separated) column(s), sort direction can be changed by appending :asc or :desc behind the column identifier. possible values: description|id|nameOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl tenant - manage tenant entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl tenant update
updates the tenant
metalctl tenant update [flags]Options
--bulk-output when used with --file (bulk operation): prints results at the end as a list. default is printing results intermediately during the operation, which causes single entities to be printed in a row.
+ -f, --file string filename of the create or update request in yaml format, or - for stdin.
+
+ Example:
+ $ metalctl tenant describe tenant-1 -o yaml > tenant.yaml
+ $ vi tenant.yaml
+ $ # either via stdin
+ $ cat tenant.yaml | metalctl tenant update -f -
+ $ # or via file
+ $ metalctl tenant update -f tenant.yaml
+
+ the file can also contain multiple documents and perform a bulk operation.
+
+ -h, --help help for update
+ --skip-security-prompts skips security prompt for bulk operations
+ --timestamps when used with --file (bulk operation): prints timestamps in-between the operationsOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl tenant - manage tenant entities
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl update
update the program
Options
-h, --help help for updateOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl update check - check for update of the program
- metalctl update do - do the update of the program
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl update check
check for update of the program
metalctl update check [flags]Options
-h, --help help for checkOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl update - update the program
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl update do
do the update of the program
metalctl update do [flags]Options
-h, --help help for do
+ -v, --version string the version to update to, by default updates to the supported version, use "latest" to update to latest versionOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl update - update the program
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl version
print the client and server version information
metalctl version [flags]Options
-h, --help help for versionOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl vpn
access VPN
Synopsis
access VPN
Options
-h, --help help for vpnOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
- metalctl vpn key - create an auth key
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl vpn key
create an auth key
Synopsis
create an auth key to connect to VPN
metalctl vpn key [flags]Examples
auth key for tailscale can be created by this command:
+metalctl vpn key \
+ -- project cluster01
+Options
--ephemeral create an ephemeral key (default true)
+ -h, --help help for key
+ --project string project ID for which auth key should be createdOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl vpn - access VPN
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
metalctl whoami
shows current user
Synopsis
shows the current user, that will be used to authenticate commands.
metalctl whoami [flags]Options
-h, --help help for whoamiOptions inherited from parent commands
--api-token string api token to authenticate. Can be specified with METALCTL_API_TOKEN environment variable.
+ --api-url string api server address. Can be specified with METALCTL_API_URL environment variable.
+ -c, --config string alternative config file path, (default is ~/.metalctl/config.yaml).
+ Example config.yaml:
+
+ ---
+ apitoken: "alongtoken"
+ ...
+
+
+ --debug debug output
+ --force-color force colored output even without tty
+ --kubeconfig string Path to the kube-config to use for authentication and authorization. Is updated by login. Uses default path if not specified.
+ --no-headers do not print headers of table output format (default print headers)
+ -o, --output-format string output format (table|wide|markdown|json|yaml|template), wide is a table with more columns. (default "table")
+ --template string output template for template output-format, go template format.
+ For property names inspect the output of -o json or -o yaml for reference.
+ Example for machines:
+
+ metalctl machine list -o template --template "{{ .id }}:{{ .size.id }}"
+
+
+ --yes-i-really-mean-it skips security prompts (which can be dangerous to set blindly because actions can lead to data loss or additional costs)SEE ALSO
- metalctl - a cli to manage entities in the metal-stack api
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Contributing
Please check out the contributing section in our docs.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
mini-lab
The mini-lab is a small, virtual setup to locally run the metal-stack. It deploys the metal control plane and a metal-stack partition with two simulated leaf switches. The lab can be used for trying out metal-stack, demonstration purposes or development.
ℹ This project can also be used as a template for writing your own metal-stack deployments.
<!– TOC depthfrom:2 depthto:6 withlinks:true updateonsave:false orderedlist:false –>
<!– /TOC –>
Requirements
- Linux machine with hardware virtualization support
- kvm as hypervisor for the VMs (you can check through the
kvm-okcommand) - docker >= 24.x.y (for using kind and our deployment base image)
- kind == v0.23.0 (for hosting the metal control plane)
- containerlab >= v0.56.0
- the lab creates a docker network on your host machine with the address block
203.0.113.0/24, designated as TEST-NET-3 for documentation and examples. - (recommended) haveged to have enough random entropy (only needed if the PXE process does not work)
Here is some code that should help you to set up most of the requirements:
# If UFW enabled.
+# Disable the firewall or allow traffic through Docker network IP range.
+sudo ufw status
+sudo ufw allow from 172.17.0.0/16
+
+# Install kvm
+sudo apt install -y git curl qemu qemu-kvm haveged
+
+# Install Docker
+curl -fsSL https://get.docker.com | sh
+# if you want to be on the safe side, follow the original installation
+# instructions at https://docs.docker.com/engine/install/ubuntu/
+
+# Ensure that your user is member of the group "docker"
+# you need to login again in order to make this change take effect
+sudo usermod -G docker -a ${USER}
+
+# Install containerlab
+bash -c "$(curl -sL https://get.containerlab.dev)"
+
+# Install kind (kubernetes in docker), for more details see https://kind.sigs.k8s.io/docs/user/quick-start/#installation
+sudo curl -Lo /usr/local/bin/kind "https://kind.sigs.k8s.io/dl/v0.20.0/kind-linux-amd64"
+sudo chmod +x /usr/local/bin/kindThe following ports are used statically on your host machine:
| Port | Bind Address | Description |
|---|---|---|
| 6443 | 0.0.0.0 | kube-apiserver of the kind cluster |
| 4443 | 0.0.0.0 | HTTPS ingress |
| 4150 | 0.0.0.0 | nsqd |
| 8080 | 0.0.0.0 | HTTP ingress |
Known Limitations
- to keep the demo small there is no EVPN
- machine restart and destroy does not work because we cannot change the boot order via IPMI in the lab easily (virtual-bmc could, but it's buggy)
- login to the machines is possible with virsh console, login to the firewall is possible with SSH from your local machine
Try it out
git clone https://github.com/metal-stack/mini-lab.git
+cd mini-labStart the mini-lab with a kind cluster, a metal-api instance as well as two containers wrapping leaf switches and another container that hosts two user-allocatable machines:
make
+# containerlab will ask you for root permissions (https://github.com/srl-labs/containerlab/issues/669)After the deployment and waiting for a short amount of time, two machines in status PXE booting become visible through metalctl machine ls:
docker compose run --rm metalctl machine ls
+
+ID LAST EVENT WHEN AGE HOSTNAME PROJECT SIZE IMAGE PARTITION
+e0ab02d2-27cd-5a5e-8efc-080ba80cf258 PXE Booting 3s
+2294c949-88f6-5390-8154-fa53d93a3313 PXE Booting 5sWait until the machines reach the waiting state:
docker compose run --rm metalctl machine ls
+
+ID LAST EVENT WHEN AGE HOSTNAME PROJECT SIZE IMAGE PARTITION
+e0ab02d2-27cd-5a5e-8efc-080ba80cf258 Waiting 8s v1-small-x86 mini-lab
+2294c949-88f6-5390-8154-fa53d93a3313 Waiting 8s v1-small-x86 mini-labCreate a firewall and a machine with:
make firewall
+make machineAlternatively, you may want to issue the metalctl commands on your own:
docker compose run --rm metalctl network allocate \
+ --partition mini-lab \
+ --project 00000000-0000-0000-0000-000000000000 \
+ --name user-private-network
+
+# lookup the network ID and create a machine
+docker compose run --rm metalctl machine create \
+ --description test \
+ --name machine \
+ --hostname machine \
+ --project 00000000-0000-0000-0000-000000000000 \
+ --partition mini-lab \
+ --image ubuntu-20.04 \
+ --size v1-small-x86 \
+ --networks <network-ID>
+
+# create a firewall that is also connected to the virtual internet-mini-lab network
+docker compose run --rm metalctl machine create \
+ --description fw \
+ --name fw \
+ --hostname fw \
+ --project 00000000-0000-0000-0000-000000000000 \
+ --partition mini-lab \
+ --image firewall-ubuntu-2.0 \
+ --size v1-small-x86 \
+ --networks internet-mini-lab,$(privatenet)See the installation process in action
make console-machine01/02
+...
+Ubuntu 20.04 machine ttyS0
+
+machine login:Two machines are now installed and have status "Phoned Home"
docker compose run --rm metalctl machine ls
+ID LAST EVENT WHEN AGE HOSTNAME PROJECT SIZE IMAGE PARTITION
+e0ab02d2-27cd-5a5e-8efc-080ba80cf258 Phoned Home 2s 21s machine 00000000-0000-0000-0000-000000000000 v1-small-x86 Ubuntu 20.04 20200331 mini-lab
+2294c949-88f6-5390-8154-fa53d93a3313 Phoned Home 8s 18s fw 00000000-0000-0000-0000-000000000000 v1-small-x86 Firewall 2 Ubuntu 20200730 mini-labLogin with user name metal and the console password from
docker compose run --rm metalctl machine consolepassword e0ab02d2-27cd-5a5e-8efc-080ba80cf258To remove the kind cluster, the switches and machines, run:
make cleanupReinstall machine
Reinstall a machine with
docker compose run --rm metalctl machine reinstall \
+ --image ubuntu-20.04 \
+ e0ab02d2-27cd-5a5e-8efc-080ba80cf258Free machine
Free a machine with make free-machine01 or
docker compose run --rm metalctl machine rm e0ab02d2-27cd-5a5e-8efc-080ba80cf258Flavors
There are two versions, or flavors, of the mini-lab environment which differ in regards to the NOS running on the leaves:
cumulus– runs 2 Cumulus switches.sonic– runs 2 SONiC switches
In order to start specific flavor, you can define the flavor as follows:
export MINI_LAB_FLAVOR=sonic
+makePage Tree
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Welcome to the metal-stack docs!
metal-stack is an open source software that provides an API for provisioning and managing physical servers in the data center. To categorize this product, we use the terms Metal-as-a-Service (MaaS) or bare metal cloud.
From the perspective of a user, the metal-stack does not feel any different from working with a conventional cloud provider. Users manage their resources (machines, networks and ip addresses, etc.) by themselves, which effectively turns your data center into an elastic cloud infrastructure.
The major difference to other cloud providers is that compute power and data reside in your own data center.
Why metal-stack?
Before we started with our mission to implement the metal-stack, we decided on a couple of key characteristics and constraints that we think are unique in the domain (otherwise we would definitely have chosen an existing solution).
We hope that the following properties appeal to you as well.
On-Premise
Running on-premise gives you data sovereignty and usually a better price / performance ratio than with hyperscalers — especially the larger you grow your environment. Another benefit of running on-premise is an easier connectivity to existing company networks.
Fast Provisioning
Provisioning bare metal machines should not feel much different from virtual machines. metal-stack is capable of provisioning servers in less than a minute. The underlying network topology is based on BGP and allows announcing new routes to your host machines in a matter of seconds.
No-Ops
Part of the metal-stack runs on dedicated switches in your data center. This way, it is possible to automate server inventorization, permanently reconcile network configuration and automatically manage machine lifecycles. Manual configuration is neither required nor wanted.
Security
Our networking approach was designed for highest standards on security. Also, we enforce firewalling on dedicated tenant firewalls before users can establish connections to other networks than their private tenant network. API authentication and authorization is done with the help of OIDC.
API driven
The development of metal-stack is strictly API driven and offers self-service to end-users. This approach delivers the highest possible degree of automation, maintainability and performance.
Ready for Kubernetes
Not only does the metal-stack run smoothly on Kubernetes (K8s). The major intent of metal-stack has always been to build a scalable machine infrastructure for Kubernetes as a Service (KaaS). In partnership with the open-source project Gardener, we can provision Kubernetes clusters on metal-stack at scale.
From the perspective of the Gardener, the metal-stack is just another cloud provider. The time savings compared to providing machines and Kubernetes by hand are significant. We actually want to be able to compete with offers of public cloud providers, especially regarding speed and usability.
Of course, you can use metal-stack only for machine provisioning as well and just put something else on top of your metal infrastructure.
Open Source
The metal-stack is open source and free of constraints regarding vendors and third-party products. The stack is completely built on open source products. We have a community actively working on the metal-stack, which can assist you delivering all reasonable features you are gonna need.
Why Bare Metal?
Bare metal has several advantages over virtual environments and overcomes several drawbacks of virtual machines. We also listed drawbacks of the bare metal approach. Bare in mind though that it is still possible to virtualize on bare metal environments when you have your stack up and running.
Virtual Environment Drawbacks
- Spectre and Meltdown can only be mitigated with a "cluster per tenant" approach
- Missing isolation of multi-tenant change impacts
- Licensing restrictions
- Noisy-neighbors
Bare Metal Advantages
- Guaranteed and fastest possible performance (especially disk i/o)
- Reduced stack depth (Host / VM / Application vs. Host / Container)
- Reduced attack surface
- Lower costs, higher performance
- No VM live-migrations
- Bigger hardware configurations possible (hypervisors have restrictions, e.g. it is not possible to assign all CPUs to a single VM)
Bare Metal Drawbacks
- Hardware defects have direct impact (should be considered by design) and can not be mitigated by live-migration as in virtual environments
- Capacity planning is more difficult (no resource overbooking possible)
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Deploying metal-stack
We are bootstrapping the metal control plane as well as our partitions with Ansible through CI.
In order to build up your deployment, we recommend to make use of the same Ansible roles that we are using by ourselves in order to deploy the metal-stack. You can find them in the repository called metal-roles.
In order to wrap up deployment dependencies there is a special deployment base image hosted on GitHub that you can use for running the deployment. Using this Docker image eliminates a lot of moving parts in the deployment and should keep the footprints on your system fairly small and maintainable.
This document will from now on assume that you want to use our Ansible deployment roles for setting up metal-stack. We will also use the deployment base image, so you should also have Docker installed. It is in the nature of software deployments to differ from site to site, company to company, user to user. Therefore, we can only describe you the way of how the deployment works for us. It is up to you to tweak the deployment described in this document to your requirements.
- Deploying metal-stack
Probably you need to learn writing Ansible playbooks if you want to be able to deploy the metal-stack as presented in this documentation. However, even when starting without any knowledge about Ansible it should be possible to follow these docs. In case you need further explanations regarding Ansible please refer to docs.ansible.com.
If you do not want to use Ansible for deployment, you need to come up with a deployment mechanism by yourself. However, you will probably be able to re-use some of our contents from our metal-roles repository, e.g. the Helm chart for deploying the metal control plane.
You can use the mini-lab as a template project for your own deployment. It uses the same approach as described in this document.
Metal Control Plane Deployment
The metal control plane is typically deployed in a Kubernetes cluster. Therefore, this document will assume that you have a Kubernetes cluster ready for getting deployed. Even though it is theoretically possible to deploy metal-stack without Kubernetes, we strongly advise you to use the described method because we believe that Kubernetes gives you a lot of benefits regarding the stability and maintainability of the application deployment.
For metal-stack it does not matter where your control plane Kubernetes cluster is located. You can of course use a cluster managed by a hyperscaler. This has the advantage of not having to setup Kubernetes by yourself and could even become beneficial in terms of fail-safe operation. The only requirement from metal-stack is that your partitions can establish network connections to the metal control plane. If you are interested, you can find a reasoning behind this deployment decision here.
Let's start off with a fresh folder for your deployment:
mkdir -p metal-stack-deployment
+cd metal-stack-deploymentAt the end of this section we are gonna end up with the following files and folder structures:
.
+├── ansible.cfg
+├── deploy_metal_control_plane.yaml
+├── files
+│ └── certs
+│ ├── ca-config.json
+│ ├── ca-csr.json
+│ ├── metal-api-grpc
+│ │ ├── client.json
+│ │ ├── server.json
+│ ├── masterdata-api
+│ │ ├── client.json
+│ │ ├── server.json
+│ └── roll_certs.sh
+├── inventories
+│ ├── control-plane.yaml
+│ └── group_vars
+│ ├── all
+│ │ └── images.yaml
+│ └── control-plane
+│ ├── common.yaml
+│ └── metal.yml
+├── generate_role_requirements.yaml
+└── roles
+ └── ingress-controller
+ └── tasks
+ └── main.yamlYou can already define the inventories/group_vars/all/images.yaml file. It contains the metal-stack version you are gonna deploy:
---
+metal_stack_release_version: masterReleases and Ansible Role Dependencies
As metal-stack consists of many microservices all having individual versions, we have come up with a releases repository. It contains a YAML file (we often call it release vector) describing the fitting versions of all components for every release of metal-stack.
Ansible role dependencies are also part of a metal-stack release. Therefore, we will now write up a playbook, which dynamically renders a requirements.yaml file from the ansible-roles defined in the release repository. The requirements.yaml can then be used to resolve the actual role dependencies through Ansible Galaxy. Define the following playbook in generate_role_requirements.yaml:
---
+- name: generate requirements.yaml
+ hosts: control-plane
+ connection: local
+ gather_facts: false
+ vars:
+ release_vector_url: "https://raw.githubusercontent.com/metal-stack/releases/{{ metal_stack_release_version }}/release.yaml"
+ tasks:
+ - name: download release vector
+ uri:
+ url: "{{ release_vector_url }}"
+ return_content: yes
+ register: release_vector
+
+ - name: write requirements.yaml from release vector
+ copy:
+ dest: "{{ playbook_dir }}/requirements.yaml"
+ content: |
+ {% for role_name, role_params in (release_vector.content | from_yaml).get('ansible-roles').items() %}
+ - src: {{ role_params.get('repository') }}
+ name: {{ role_name }}
+ version: {{ hostvars[inventory_hostname][role_name | lower | replace('-', '_') + '_version'] | default(role_params.get('version'), true) }}
+ {% endfor %}This playbook will always be run before the actual metal-stack deployment and provide you with the proper versions of the Ansible role dependencies.
Inventory
Then, there will be an inventory for the control plane deployment in inventories/control-plane.yaml that adds the localhost to the control-plane host group:
---
+control-plane:
+ hosts:
+ localhost:
+ ansible_python_interpreter: "{{ ansible_playbook_python }}"We do this since we are deploying to Kubernetes and do not need to SSH-connect to any hosts for the deployment (which is what Ansible typically does). This inventory is also necessary to pick up the variables inside inventories/group_vars/control-plane during the deployment.
We recommend using the following ansible.cfg:
[defaults]
+retry_files_enabled = false
+force_color = true
+host_key_checking = false
+stdout_callback = yaml
+jinja2_native = true
+transport = ssh
+timeout = 30
+force_valid_group_names = ignore
+
+[ssh_connection]
+retries=3
+ssh_executable = /usr/bin/sshMost of the properties in there are up to taste, but make sure you enable the Jinja2 native environment as this is needed for some of our roles in certain cases.
Control Plane Playbook
Next, we will define the actual deployment playbook in a file called deploy_metal_control_plane.yaml. You can start with the following lines:
---
+- name: Deploy Control Plane
+ hosts: control-plane
+ connection: local
+ gather_facts: no
+ vars:
+ setup_yaml:
+ - url: https://raw.githubusercontent.com/metal-stack/releases/{{ metal_stack_release_version }}/release.yaml
+ meta_var: metal_stack_release
+ roles:
+ - name: ansible-common
+ tags: always
+ - name: ingress-controller
+ tags: ingress-controller
+ - name: metal-roles/control-plane/roles/prepare
+ tags: prepare
+ - name: metal-roles/control-plane/roles/nsq
+ tags: nsq
+ - name: metal-roles/control-plane/roles/metal-db
+ tags: metal-db
+ - name: metal-roles/control-plane/roles/ipam-db
+ tags: ipam-db
+ - name: metal-roles/control-plane/roles/masterdata-db
+ tags: masterdata-db
+ - name: metal-roles/control-plane/roles/metal
+ tags: metalBasically, this playbook does the following:
- Include all the modules, filter plugins, etc. of ansible-common into the play
- Deploys an ingress-controller into your cluster
- Deploys the metal-stack by
- Running preparation tasks
- Deploying NSQ
- Deploying the rethinkdb database for the metal-api (wrapped in a backup-restore-sidecar),
- Deploying the postgres database for go-ipam (wrapped in a backup-restore-sidecar)
- Deploying the postgres database for the masterdata-api (wrapped in a backup-restore-sidecar)
- Applying the metal control plane helm chart
Setup an ingress-controller
As a next step you have to add a task for deploying an ingress-controller into your cluster. nginx-ingress is what we use. If you want to use another ingress-controller, you need to parametrize the metal roles carefully. When you just use ingress-nginx, make sure to also deploy it to the default namespace ingress-nginx.
This is how your roles/ingress-controller/tasks/main.yaml could look like:
- name: Deploy ingress-controller
+ include_role:
+ name: ansible-common/roles/helm-chart
+ vars:
+ helm_repo: "https://helm.nginx.com/stable"
+ helm_chart: nginx-ingress
+ helm_release_name: nginx-ingress
+ helm_target_namespace: ingress-nginxThe ansible-common repository contains very general roles and modules that you can also use when extending your deployment further.
Deployment Parametrization
Now you can parametrize the referenced roles to fit your environment. The role parametrization can be looked up in the role documentation on metal-roles/control-plane. You should not need to define a lot of variables for the beginning as most values are reasonably defaulted. You can start with the following content for group_vars/control-plane/common.yaml:
---
+metal_control_plane_ingress_dns: <your-dns-domain> # if you do not have a DNS entry, you could also start with <ingress-ip>.nip.ioProviding Certificates
We have several components in our stack that communicate over encrypted gRPC just like Kubernetes components do.
For the very basic setup you will need to create self-signed certificates for the communication between the following components (see architecture document):
- metal-api and masterdata-api (in-cluster traffic communication)
- metal-api and metal-hammer (partition to control plane communication)
Here is a snippet for files/roll_certs.sh that you can use for generating your certificates (requires cfssl):
#!/usr/bin/env bash
+set -eo pipefail
+
+for i in "$@"
+do
+case $i in
+ -t=*|--target=*)
+ TARGET="${i#*=}"
+ shift
+ ;;
+ *)
+ echo "unknown parameter passed: $1"
+ exit 1
+ ;;
+esac
+done
+
+if [ -z "$TARGET" ]; then
+ echo "generating ca cert"
+ cfssl genkey -initca ca-csr.json | cfssljson -bare ca
+ rm *.csr
+fi
+
+if [ -z "$TARGET" ] || [ $TARGET == "grpc" ]; then
+ pushd metal-api-grpc
+ echo "generating grpc certs"
+ cfssl gencert -ca=../ca.pem -ca-key=../ca-key.pem -config=../ca-config.json -profile=server server.json | cfssljson -bare server
+ cfssl gencert -ca=../ca.pem -ca-key=../ca-key.pem -config=../ca-config.json -profile=client client.json | cfssljson -bare client
+ rm *.csr
+ popd
+fi
+
+if [ -z "$TARGET" ] || [ $TARGET == "masterdata-api" ]; then
+ pushd masterdata-api
+ echo "generating masterdata-api certs"
+ rm -f *.pem
+ cfssl gencert -ca=../ca.pem -ca-key=../ca-key.pem -config=../ca-config.json -profile=client-server server.json | cfssljson -bare server
+ cfssl gencert -ca=../ca.pem -ca-key=../ca-key.pem -config=../ca-config.json -profile=client client.json | cfssljson -bare client
+ rm *.csr
+ popd
+fiAlso define the following configurations for cfssl:
files/certs/ca-config.json{ + "signing": { + "default": { + "expiry": "43800h" + }, + "profiles": { + "server": { + "expiry": "43800h", + "usages": ["signing", "key encipherment", "server auth"] + }, + "client": { + "expiry": "43800h", + "usages": ["signing", "key encipherment", "client auth"] + }, + "client-server": { + "expiry": "43800h", + "usages": [ + "signing", + "key encipherment", + "client auth", + "server auth" + ] + } + } + } +}files/certs/ca-csr.json{ + "CN": "metal-control-plane", + "hosts": [], + "key": { + "algo": "rsa", + "size": 4096 + }, + "names": [ + { + "C": "DE", + "L": "Munich", + "O": "Metal-Stack", + "OU": "DevOps", + "ST": "Bavaria" + } + ] +}files/certs/masterdata-api/client.json{ + "CN": "masterdata-client", + "hosts": [""], + "key": { + "algo": "ecdsa", + "size": 256 + }, + "names": [ + { + "C": "DE", + "L": "Munich", + "O": "Metal-Stack", + "OU": "DevOps", + "ST": "Bavaria" + } + ] +}files/certs/masterdata-api/server.json{ + "CN": "masterdata-api", + "hosts": [ + "localhost", + "masterdata-api", + "masterdata-api.metal-control-plane.svc", + "masterdata-api.metal-control-plane.svc.cluster.local" + ], + "key": { + "algo": "ecdsa", + "size": 256 + }, + "names": [ + { + "C": "DE", + "L": "Munich", + "O": "Metal-Stack", + "OU": "DevOps", + "ST": "Bavaria" + } + ] +}files/certs/metal-api-grpc/client.json{ + "CN": "grpc-client", + "hosts": [""], + "key": { + "algo": "rsa", + "size": 4096 + }, + "names": [ + { + "C": "DE", + "L": "Munich", + "O": "Metal-Stack", + "OU": "DevOps", + "ST": "Bavaria" + } + ] +}files/certs/metal-api-grpc/server.json(Fill in your control plane ingress DNS here){ + "CN": "metal-api", + "hosts": ["<your-metal-api-dns-ingress-domain>"], + "key": { + "algo": "rsa", + "size": 4096 + }, + "names": [ + { + "C": "DE", + "L": "Munich", + "O": "Metal-Stack", + "OU": "DevOps", + "ST": "Bavaria" + } + ] +}
Running the roll_certs.sh bash script without any arguments should generate you the required certificates.
Now Provide the paths to these certificates in group_vars/control-plane/metal.yaml:
---
+metal_masterdata_api_tls_ca: "{{ lookup('file', 'certs/ca.pem') }}"
+metal_masterdata_api_tls_cert: "{{ lookup('file', 'certs/masterdata-api/server.pem') }}"
+metal_masterdata_api_tls_cert_key: "{{ lookup('file', 'certs/masterdata-api/server-key.pem') }}"
+metal_masterdata_api_tls_client_cert: "{{ lookup('file', 'certs/masterdata-api/client.pem') }}"
+metal_masterdata_api_tls_client_key: "{{ lookup('file', 'certs/masterdata-api/client-key.pem') }}"
+
+metal_api_grpc_certs_server_key: "{{ lookup('file', 'certs/metal-api-grpc/server-key.pem') }}"
+metal_api_grpc_certs_server_cert: "{{ lookup('file', 'certs/metal-api-grpc/server.pem') }}"
+metal_api_grpc_certs_client_key: "{{ lookup('file', 'certs/metal-api-grpc/client-key.pem') }}"
+metal_api_grpc_certs_client_cert: "{{ lookup('file', 'certs/metal-api-grpc/client.pem') }}"
+metal_api_grpc_certs_ca_cert: "{{ lookup('file', 'certs/ca.pem') }}"For the actual communication between the metal-api and the user clients (REST API, runs over the ingress-controller you deployed before), you can simply deploy a tool like cert-manager into your Kubernetes cluster, which will automatically provide your ingress domains with Let's Encrypt certificates.
Running the Deployment
Finally, it should be possible to run the deployment through a Docker container. Make sure to have the Kubeconfig file of your cluster and set the path in the following command accordingly:
export KUBECONFIG=<path-to-your-cluster-kubeconfig>
+docker run --rm -it \
+ -v $(pwd):/workdir \
+ --workdir /workdir \
+ -e KUBECONFIG="${KUBECONFIG}" \
+ -e K8S_AUTH_KUBECONFIG="${KUBECONFIG}" \
+ -e ANSIBLE_INVENTORY=inventories/control-plane.yaml \
+ metalstack/metal-deployment-base:v0.7.5 \
+ /bin/bash -ce \
+ "ansible-playbook obtain_role_requirements.yaml
+ ansible-galaxy install -r requirements.yaml
+ ansible-playbook deploy_metal_control_plane.yaml"If you are having issues regarding the deployment take a look at the troubleshoot document. Please give feedback such that we can make the deployment of the metal-stack easier for you and for others!
Providing Images
After the deployment has finished (hopefully without any issues!), you should consider deploying some masterdata entities into your metal-api. For example, you can add your first machine sizes and operating system images. You can do this by further parametrizing the metal role. We will just add an operating system for demonstration purposes. Add the following variable to your inventories/group_vars/control-plane/common.yaml:
metal_api_images:
+- id: firewall-ubuntu-2.0.20201004
+ name: Firewall 2 Ubuntu 20201004
+ description: Firewall 2 Ubuntu 20201004
+ url: http://images.metal-stack.io/metal-os/master/firewall/2.0-ubuntu/20201004/img.tar.lz4
+ features:
+ - firewall
+- id: ubuntu-20.04.20201004
+ name: Ubuntu 20.04 20201004
+ description: Ubuntu 20.04 20201004
+ url: http://images.metal-stack.io/metal-os/master/ubuntu/20.04/20201004/img.tar.lz4
+ features:
+ - machineThen, re-run the deployment to apply your changes. Our playbooks are idempotent.
Image versions should be regularly checked for updates.
Setting up metalctl
You can now verify the existence of the operating system images in the metal-api using our CLI client called metalctl. The configuration for metalctl should look like this:
# ~/.metalctl/config.yaml
+---
+current: test
+contexts:
+ test:
+ # the metal-api endpoint depends on your dns name specified before
+ # you can look up the url to the metal-api via the kubernetes ingress
+ # resource with:
+ # $ kubectl get ingress -n metal-control-plane
+ url: <metal-api-endpoint>
+ # in the future you have to change the HMAC to a strong, random string
+ # in order to protect against unauthorized api access
+ # the default hmac is "change-me"
+ hmac: change-meIssue the following command:
$ metalctl image ls
+ID NAME DESCRIPTION FEATURES EXPIRATION STATUS
+ubuntu-19.10.20200331 Ubuntu 19.10 20200331 Ubuntu 19.10 20200331 machine 89d 23h previewThe basic principles of how the metal control plane can be deployed should now be clear. It is now up to you to move the deployment execution into your CI and add things like certificates for the ingress-controller and NSQ.
Setting Up the backup-restore-sidecar
The backup-restore-sidecar can come up very handy when you want to add another layer of security to the metal-stack databases in your Kubernetes cluster. The sidecar takes backups of the metal databases in small time intervals and stores them in a blobstore of a cloud provider. This way your metal-stack setup can even survive the deletion of your Kubernetes control plane cluster (including all volumes getting lost). After re-deploying metal-stack to another Kubernetes clusters, the databases come up with the latest backup data in a matter of seconds.
Checkout the role documentation of the individual databases to find out how to configure the sidecar properly. You can also try out the mechanism from the backup-restore-sidecar repository.
Auth
metal-stack currently supports two authentication methods:
- dex for providing user authentication through OpenID Connect (OIDC)
- HMAC auth, typically used for access by technical users (because we do not have service account tokens at the time being)
In the metal-api, we have three different user roles for authorization:
- Admin
- Edit
- View
How the user permissions are used is documented in the technical API docs.
If you decided to set up a dex server, you can parametrize the metal role for using the dex server by defining the variable metal_api_dex_address.
We also have dedicated controllers for using the dex server for Kubernetes clusters when deploying metal-stack along with the Gardener in your environment. The approach is described in further detail in the section Gardener with metal-stack.
Bootstrapping a Partition
Out-Of-Band-Network
To be able to deploy and maintain a metal-stack partition, you need to bootstrap the Out-Of-Band-Network first. Some considerations must be made to fulfill the requirements of our infrastructure, a partition is designed to be:
- secure
- fully routable (BGP)
- scalable
- resilient
- deployable via CI/CD jobs
- accessible from the internet from specific IPs
In order to accomplish this task remotely and in a nearly automatic manner, you have to bootstrap the components in this order:
- management firewalls
- management servers
- management spines
- management leaves
- leaves, spines and exits
This document assumes that all cabling is done. Here is a quick overview of the architecture:
Management Firewalls
As you can see, the management firewalls are the first bastion hosts in a partition to provide access to our infrastructure. There are two of them in each partition to guarantee high availability and load balancing. The very first configuration of these routers has to be done manually to solve the chicken and egg problem that you need the management firewalls in place to deploy the partition. Manually means that we generate a configuration template with ansible that we deploy with copy/paste, and the load, through the machine console. Once the management server has been deployed, we are able to deploy this configuration via CI runner and ansible. For this you need the user and the ssh-key, which is deployed with the configuration file mentioned above. The Edgerouters has to fulfill some requirements including:
- provide and restrict access to the Out-Of-Band-Network from the internet with a firewall ruleset
- provide destination NAT to the management server and its IPMI interface
- provide Onie Boot and ztp via DHCP options for the management spine
- provide DHCP management addresses for management spine, management server and ipmi interface of the management server
- Hairpin-NAT for the management server to access itself via its puplic IP, needed by the CI runner to delegate CI Jobs.
- propagate a default gateway via BGP
Management Servers
The second bastion hosts are the management servers. They are the main bootstrapping components of the Out-Of-Band-Network. They also act as jump hosts for all components in a partition. Once they are installed and deployed, we are able to bootstrap all the other components. To bootstrap the management servers, we generate an ISO image which will automatically install an OS and an ansible user with ssh keys. It is preconfigured with a preseed file to allow an unattended OS installation for our needs. This is why we need remote access to the IPMI interface of the management servers: The generated ISO is attached via the virtual media function of the BMC. After that, all we have to do is boot from that virtual CD-ROM and wait for the installation to finish. Deployment jobs (Gitlab-CI) in a partition are delegated to the appropriate management servers, therefore we need a CI runner active on each management server.
After the CI runner has been installed, you can trigger your Playbooks from the the CI. The Ansible-Playbooks have to make sure that these functionalities are present on the management servers:
- Prometheus and exporters
- CI runner
- metal-bmc
- image-cache
- simple webserver to provide images
- Onie Boot and ZTP
- DHCP addresses for ipmi interfaces of the workers
- DHCP addresses for switches
Management Spines
If you are using SONiC switches, you should make use of Zero Touch Provisioning and Onie Boot
The purpose of these switches is to connect the management interfaces of all switches to the management servers. The management spine's own management interface is connected to the management firewall for the bootstrapping of the management spine itself. The management firewall will provide a DHCP address and DHCP options to start SONiC's Zero Touch Provisioning; the images for all switches are downloaded from the management server (nginx container). Each management leaf is connected to both management spines to provide redundant connectivity to both management servers. BGP is used as a routing protocol such that, when a link goes down, an alternate path is used. In the picture above you can see that there are also switch management interfaces connected to the management spine. This has to be done so that we can bootstrap these switches; the management spine relays the DHCP requests from these switches to the management servers so that they are able to Onie Boot and get their ZTP scripts.
Management Leaves
All workers have to be connected with their IPMI/BMC interface to the management leaves to get DHCP addresses from the management server. The management leaves are relaying those DHCP requests to the management server which will answer the requests and provide IPs from a given range. The management interfaces of the management leaves also have to be reachable from the management server, and need to get their IP address via DHCP for the bootstrapping process.
In the example setup, these interfaces are connected to an end-of-row-switch which aggregates them and connects them to the management spines with a fiber-optics connection. If you can reach the management spines from the management leaves with copper cables, you do not need the end of row switch. After the initial bootstrapping, the management interfaces of the management leaves continue to be used for access to the switches' command line, and for subsequent OS updates. (update=reset+bootrap+deployment)
Partition Deployment
Gardener with metal-stack
If you want to deploy metal-stack as a cloud provider for Gardener, you should follow the regular Gardener installation instructions and setup a Gardener cluster first. It's perfectly fine to setup the Gardener cluster in the same cluster that you use for hosting metal-stack.
You can find installation instructions for Gardener on the Gardener website beneath docs. metal-stack is an out-of-tree provider and therefore you will not find example files for metal-stack resources in the Gardener repositories. The following list describes the resources and components that you need to deploy into the Gardener cluster in order to make Gardener work with metal-stack:
The following list assumes you have Gardener installed in a Kubernetes cluster and that you have a basic understanding of how Gardener works. If you need further help with the following steps, you can also come and ask in our Slack channel.
- Deploy the validator from the gardener-extension-provider-metal repository to your cluster via Helm
- Add a cloud profile called
metalcontaining all your machine images, machine types and regions (region names can be chosen freely, the zone names need to match your partition names) together with our metal-stack-specific provider config as defined here - Register the gardener-extension-provider-metal controller by deploying the controller-registration into your Gardener cluster, parametrize the embedded chart in the controller registration's values section if necessary (this is the corresponding values file)
- metal-stack does not provide an own backup storage infrastructure for now. If you want to enable ETCD backups (which you should do because metal-stack also does not have persistent storage out of the box, which makes these backups even more valuable), you should deploy an extension-provider of another cloud provider and configure it to only reconcile the backup buckets (you can reference this backup infrastructure used for the metal shoot in the shoot spec)
- Register the os-extension-provider-metal controller by deploying the controller-registration into your Gardener cluster, this controller can transform the operating system configuration from Gardener into Ignition user data
- You need to use the Gardener's networking-calico controller for setting up shoot CNI, you will have to put specific provider configuration into the shoot spec to make it work with metal-stack:
networking: + type: calico + # we can peer with the frr within 10.244.0.0/16, which we do with the metallb + # the networks for the shoot need to be disjunct with the networks of the seed, otherwise the VPN connection will not work properly + # the seeds are typically deployed with podCIDR 10.244.128.0/18 and serviceCIDR 10.244.192.0/18 + # the shoots are typically deployed with podCIDR 10.244.0.0/18 and serviceCIDR 10.244.64.0/18 + pods: 10.244.0.0/18 + services: 10.244.64.0/18 + providerConfig: + apiVersion: calico.networking.extensions.gardener.cloud/v1alpha1 + kind: NetworkConfig + backend: vxlan + ipv4: + pool: vxlan + mode: Always + autoDetectionMethod: interface=lo + typha: + enabled: false - For your seed cluster you will need to provide the provider secret for metal-stack containing the key
metalAPIHMac, which is the API HMAC to grant editor access to the metal-api - Checkout our current provider configuration for infrastructure and control-plane before deploying your shoot
We are officially supported by Gardener dashboard. The dashboard can also help you setting up some of the resources mentioned above.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Monitoring the metal-stack
Overview
Logging
Logs are being collected by Promtail and pushed to a Loki instance running in the control plane. Loki is deployed in monolithic mode and with storage type 'filesystem'. You can find all logging related configuration parameters for the control plane in the control plane's logging role.
In the partitions, Promtail is deployed inside a systemd-managed Docker container. Configuration parameters can be found in the partition's promtail role. Which hosts Promtail collects from can be configured via the prometheus_promtail_targets variable.
Monitoring
For monitoring we deploy the kube-prometheus-stack and a Thanos instance in the control plane. Metrics for the control plane are supplied by
metal-metrics-exporterrethindb-exporterevent-exportergardener-metrics-exporter
To query and visualize logs, metrics and alerts we deploy several grafana dashboards to the control plane:
grafana-dashboard-alertmanagergrafana-dashboard-machine-capacitygrafana-dashboard-metal-apigrafana-dashboard-rethinkdbgrafana-dashboard-sonic-exporter
and also some gardener related dashboards:
grafana-dashboard-gardener-overviewgrafana-dashboard-shoot-clustergrafana-dashboard-shoot-customizationsgrafana-dashboard-shoot-detailsgrafana-dashboard-shoot-states
The following ServiceMonitors are also deployed:
gardener-metrics-exporteripam-dbmasterdata-apimasterdata-dbmetal-apimetal-dbrethinkdb-exportermetal-metrics-exporter
All monitoring related configuration parameters for the control plane can be found in the control plane's monitoring role.
Partition metrics are supplied by
node-exporterblackbox-exporteripmi-exportersonic-exportermetal-corefrr-exporter
and scraped by Prometheus. For each of these exporters, the target hosts can be defined by
prometheus_node_exporter_targetsprometheus_blackbox_exporter_targetsprometheus_frr_exporter_targetsprometheus_sonic_exporter_targetsprometheus_metal_core_targetsprometheus_frr_exporter_targets
Alerting
In addition to Grafana, alerts can optionally be sent to a Slack channel. For this to work, at least a valid monitoring_slack_api_url and a monitoring_slack_notification_channel must be specified. For further configuration parameters refer to the monitoring role. Alerting rules are defined in the rules directory of the partition's prometheus role.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Troubleshoot
This document summarizes help when something goes wrong and provides advice on debugging the metal-stack in certain situations.
Of course, it is also advisable to check out the issues on the Github projects for help.
If you still can't find a solution to your problem, please reach out to us and our community. We have a public Slack Channel to discuss problems, but you can also reach us via mail. Check out metal-stack.io for contact information.
- Troubleshoot
Deployment
Ansible fails when the metal control plane helm chart gets applied
There can be many reasons for this. Since you are deploying the metal control plane into a Kubernetes cluster, the first step should be to install kubectl and check the pods in your cluster. Depending on the metal-stack version and Kubernetes cluster, your control-plane should look something like this after the deployment (this is in a Kind cluster):
kubectl get pod -A
+NAMESPACE NAME READY STATUS RESTARTS AGE
+ingress-nginx nginx-ingress-controller-56966f7dc7-khfp9 1/1 Running 0 2m34s
+kube-system coredns-66bff467f8-grn7q 1/1 Running 0 2m34s
+kube-system coredns-66bff467f8-n7n77 1/1 Running 0 2m34s
+kube-system etcd-kind-control-plane 1/1 Running 0 2m42s
+kube-system kindnet-4dv7m 1/1 Running 0 2m34s
+kube-system kube-apiserver-kind-control-plane 1/1 Running 0 2m42s
+kube-system kube-controller-manager-kind-control-plane 1/1 Running 0 2m42s
+kube-system kube-proxy-jz7kp 1/1 Running 0 2m34s
+kube-system kube-scheduler-kind-control-plane 1/1 Running 0 2m42s
+local-path-storage local-path-provisioner-bd4bb6b75-cwfb7 1/1 Running 0 2m34s
+metal-control-plane ipam-db-0 2/2 Running 0 2m31s
+metal-control-plane masterdata-api-6dd4b54db5-rwk45 1/1 Running 0 33s
+metal-control-plane masterdata-db-0 2/2 Running 0 2m29s
+metal-control-plane metal-api-998cb46c4-jj2tt 1/1 Running 0 33s
+metal-control-plane metal-api-initdb-r9sc6 0/1 Completed 0 2m24s
+metal-control-plane metal-api-liveliness-1590479940-brhc7 0/1 Completed 0 6s
+metal-control-plane metal-console-7955cbb7d7-p6hxp 1/1 Running 0 33s
+metal-control-plane metal-db-0 2/2 Running 0 2m34s
+metal-control-plane nsq-lookupd-5b4ccbfb64-n6prg 1/1 Running 0 2m34s
+metal-control-plane nsqd-6cd87f69c4-vtn9k 2/2 Running 0 2m33sIf there are any failing pods, investigate those and look into container logs. This information should point you to the place where the deployment goes wrong.
Sometimes, you see a helm errors like "no deployed releases" or something like this. When a helm chart fails after the first deployment it could be that you have a chart installation still pending. Also, the control plane helm chart uses pre- and post-hooks, which creates jobs that helm expects to be completed before attempting another deployment. Delete the helm chart (use Helm 3) with helm delete -n metal-control-plane metal-control-plane and delete the jobs in the metal-control-plane namespace before retrying the deployment.
In the mini-lab the control-plane deployment fails because my system can't resolve api.172.17.0.1.nip.io
The control-plane deployment returns an error like this:
deploy-control-plane | fatal: [localhost]: FAILED! => changed=false
+deploy-control-plane | attempts: 60
+deploy-control-plane | content: ''
+deploy-control-plane | elapsed: 0
+deploy-control-plane | msg: 'Status code was -1 and not [200]: Request failed: <urlopen error [Errno -5] No address associated with hostname>'
+deploy-control-plane | redirected: false
+deploy-control-plane | status: -1
+deploy-control-plane | url: http://api.172.17.0.1.nip.io:8080/metal/v1/health
+deploy-control-plane |
+deploy-control-plane | PLAY RECAP *********************************************************************
+deploy-control-plane | localhost : ok=29 changed=4 unreachable=0 failed=1 skipped=7 rescued=0 ignored=0
+deploy-control-plane |
+deploy-control-plane exited with code 2Some home routers have a security feature that prevents DNS Servers to resolve anything in the router's local IP range (DNS-Rebind-Protection).
You need to add an exception for nip.io in your router configuration or add 127.0.0.1 api.172.17.0.1.nip.io to your /etc/hosts.
FritzBox
Home Network -> Network -> Network Settings -> Additional Settings -> DNS Rebind Protection -> Host name exceptions -> nip.io
Operations
Fixing Machine Issues
The metalctl machine issues command gives you an overview over machines in your metal-stack environment that are in an unusual state.
Machines that are known not to function properly, should be locked through metalctl machine lock and annotated with a description of the problem. This way, you can mark machine for replacement without being in danger of having a user allocating the faulty machine.
In the following sections, you can look up the machine issues that are returned by metalctl and find out how to deal with them properly.
no-event-container
Every machine in the metal-stack database usually has a corresponding event container where provisioning events are stored. This database entity gets created lazily as soon as a machine is registered by the metal-hammer or a provisioning event for the machine arrives at the metal-api.
When there is no event container, this means that the machine has never registered nor received a provisioning event. As an operator you should evaluate why this machine is not booting into the metal-hammer.
This issue is special in a way that it prevents other issues from being evaluated for this machine because the issue calculation usually requires information from the machine event container.
no-partition
When a machine has no partition, the metal-hammer has not yet registered the machine at the metal-api. Instead, the machine was created through metal-stack's event machinery, which does not have a lot of information about a machine (e.g. a PXE boot event was reported from the pixiecore), or just by the metal-bmc which discovered the machine through DHCP.
This can usually happen on the very first boot of a machine and the machine's hardware is not supported by metal-stack, leading to the metal-bmc being unable to report BMC details to the metal-api (a metal-bmc report sets the partition id of a machine) and the metal-hammer not finishing the machine registration phase.
To resolve this issue, you need to identify the machine in your metal-stack partition that emits PXE boot events and find the reason why it is not properly booting into the metal-hammer. The console logs of this machine should enable you to find out the root cause.
liveliness-dead
For machines without an allocation, the metal-hammer consistently reports whether a machine is still being responsive or not. When the liveliness is Dead, there were no events received from this machine for longer than ~5 minutes.
Reasons for this can be:
- The network connection between the partition and metal-stack control plane is interrupted
- The machine was removed from your data center
- The machine has changed its UUID metal-hammer#52
- The machine is turned off
- The machine hangs / freezes
- The machine booted to BIOS or UEFI shell and does not try to PXE boot again
- The issue only appears temporarily
- The machine takes longer than 5 minutes for the reboot
- The machine is performing a firmware upgrade, which usually takes longer than 5 minutes to succeed
In order to minimize maintenance overhead, a machine which is dead for longer than an hour will be rebooted through the metal-api.
In case you want to prevent this action from happening for a machine, you can lock the machine through metalctl machine lock.
If the machine is dead for a long time and you are sure that it will never come back, you can clean up the machine through metalctl machine rm --remove-from-database.
liveliness-unknown
For machines that are allocated by a user, the ownership has gone over to this user and as an operator you cannot access the machine anymore. This makes it harder to detect whether a machine is in a healthy state or not. Typically, all official metal-stack OS images deploy an LLDP daemon, that consistently emits alive messages. These messages are caught by the metal-core and turned into a Phoned Home event. Internally, the metal-api uses these events as an indicator to decide whether the machine is still responsive or not.
When the LLDP daemon stopped sending packages, the reasons are identical to those of dead machines. However, it's not possible anymore to decide whether the user is responsible for reaching this state or not.
In most of the cases, there is not much that can be done from the operator's perspective. You will need to wait for the user to report an issue with the machine. When you do support, you can use this issue type to quickly identify this machine.
liveliness-not-available
This is more of a theoretical issue. When the machine liveliness is not available check that the Kubernetes CronJob in the metal-stack control plane for evaluating the machine liveliness is running regularly and not containing error logs. Make the machine boot into the metal-hammer and this issue should not appear.
failed-machine-reclaim
If a machine remains in the Phoned Home state without having an allocation, this indicates that the metal-bmc was not able to put the machine back into PXE boot mode after metalctl machine rm. The machine is still running the operating system and it does not return back into the allocatable machine pool. Effectively, you lost a machine in your environment and no-one pays for it. Therefore, you should resolve this issue as soon as possible.
In bad scenarios, when the machine was a firewall, the machine can still reach the internet through the PXE boot network and also attract traffic, which it cannot route anymore inside the tenant VRF. This can cause traffic loss inside a tenant network.
In most of the cases, it should be sufficient to run another metalctl machine rm on this machine in order to retry booting into PXE mode. If this still does not succeed, you can boot the machine into the BIOS and manually and change the boot order to PXE boot. This should force booting the metal-hammer again and add the machine back into your pool of allocatable machines.
For further reference, see metal-api#145.
crashloop
Under bad circumstances, a machine diverges from its typical machine lifecycle. When this happens, the internal state-machine of the metal-api detects that the machine reboots unexpectedly during the provisioning phase. It is likely that the machine has entered a crash loop where it PXE boots again and again without the machine ever becoming usable.
Reasons for this can be:
- The machine's hardware is not supported and the metal-hammer crashes during the machine discovery
- The machine registration fails through the metal-hammer because an orphaned / dead machine is still present in the metal-api's data base. The machine is connected to the same switch ports that were used by the orphaned machine. In this case, you should clean up the orphaned machine through
metalctl machine rm --remove-from-database.
Please also consider console logs of the machine for investigating the issue.
The incomplete cycle count is reset as soon as the machine reaches Phoned Home state or there is a Planned Reboot of the machine (planned reboot is also done by the metal-hammer once a day in order to reboot with the latest version).
last-event-error
The machine had an error during the provisioning lifecycle recently or events are arriving out of order at the metal-api. This can be an interesting hint for the operator that something during machine provisioning went wrong. You can look at the error through metalctl machine describe or metalctl machine logs.
This error will disappear after a certain time period from machine issues. You can still look up the error as described above.
asn-not-unique
This issue was introduced by a bug in earlier versions of metal-stack and was fixed in PR105
To resolve the issue, you need to recreate the firewalls that use the same ASN.
bmc-without-mac
The metal-bmc is responsible to report connection data for the machine's BMC.
If it's uncapable of discovering this information, your hardware might not be supported. Please investigate the logs of the metal-bmc to find out what's going wrong with this machine.
bmc-without-ip
The metal-bmc is responsible to report connection data for the machine's BMC.
If it's uncapable of discovering this information, your hardware might not be supported. Please investigate the logs of the metal-bmc to find out what's going wrong with this machine.
bmc-no-distinct-ip
The metal-bmc is responsible to report connection data for the machine's BMC.
When there is no distinct IP address for the BMC, it can be that an orphaned machine used this IP in the past. In this case, you need to clean up the orphaned machine through metalctl machine rm --remove-from-database.
bmc-info-outdated
The metal-bmc is responsible to report bmc details for the machine's BMC.
When the metal-bmc was not able to fetch the bmc info for longer than 20 minutes, something is wrong with the BMC configuration of the machine. This can be caused by one of the following reasons:
- Wrong password for the root user is configured in the BMC
- ip address of the BMC is either wrong or not present
- the device on the given ip address is not a machine, maybe a switch or a management component which is not managed by the metal-api
In either case, please check the logs for the given machine UUID on the metal-bmc for further details. Also check that the metal-bmc is configured to only consider BMC IPs in the range they are configured from the DHCP server in the partition. This prevents grabbing unrelated BMCs.
A machine has registered with a different UUID after reboot
metal-stack heavily relies on steady machine UUIDs as the UUID is the primary key of the machine entity in the metal-api.
For further reference also see metal-stack/metal-hammer#52.
Reasons
There are some scenarios (can be vendor-specific), which can cause a machine UUID to change over time, e.g.:
- When the UUID partly contains of a network card's mac address, it can happen when:
- Exchanging network cards
- Disabling network cards through BIOS
- Changing the UUID through vendor-specific CLI tool
Solution
- After five minutes, the orphaned machine UUID will be marked dead (💀) because machine events will be sent only to the most recent UUID
- Identify the dead machine through
metalctl machine ls - Remove the dead machine forcefully with
metalctl machine rm --remove-from-database --yes-i-really-mean-it <uuid>
Fixing Switch Issues
switch-sync-failing
For your network infrastructure it is key to adapt to new configuration. In case this sync process fails for more than 10 minutes, it is likely to require manual investigation.
Depending on your switch operating system, the error sources might differ a lot. Try to connect to your switch using the console or ssh and investigate the logs. Check if the hard drive is full.
Switch Replacement and Migration
There are two mechanisms to replace an existing switch with a new one, both of which will transfer existing VRF configuration and machine connections from one switch to another. Due to the redundance of the CLOS topology, a switch replacement can be performed without downtime.
Replacing a Switch
If the new switch should have the same ID as the old one you should perform a switch replacement. To find detailed information about the procedure of a switch replacement use metalctl switch replace --help. Basically, what you need to do is mark the switch for replacement via metalctl switch replace, then physically replace the switch with the new one and configure it. The last step is to deploy metal-core on the switch. Once metal-core registers the new switch at the metal-api, the old switches configuration and machine connections will be transferred to the new one. Note that the replacement only works if the new switch has the same ID as the old one. Otherwise metal-core will simply register a new switch and leave the old one untouched.
Migrating from one Switch to another
If the new switch should not or cannot have the same ID as the old one, then the switch migrate command can be used to achieve the same result as a switch replacement. Perform the following steps:
- Leave the old switch in place.
- Install the new switch in the rack without connecting it to any machines yet.
- Adjust the metal-stack deployment in the same way as for a switch replacement.
- Deploy metal-core on the new switch and wait for it to register at the metal-api. Once the switch is registered it will be listed when you run
metalctl switch ls. - Run
metalctl switch migrate <old-switch-id> <new-switch-id>. - Disconnect all machines from the old switch and connect them to the new one.
In between steps 5 and 6 there is a mismatch between the switch-machine-connections known to the metal-api and the real connections. Since the metal-api learns about the connections from what a machine reports during registration, a machine registration that occurs in between steps 5 and 6 will result in a condition that looks somewhat broken. The metal-api will think that a machine is connected to three switches. This, however, should not cause any problems. Just move on to step 6 and delete the old switch from the metal-api afterwards. If the case just described really occurs, then metalctl switch delete <old-switch-id> will throw an error, because deleting a switch with existing machine connections might be dangerous. If, apart from that, the migration was successful, then the old switch can be safely deleted with metalctl switch delete <old-switch-id> --force.
Preconditions for Migration and Replacement
An invariant that must be satisfied throughout is that the switch ports a machine is connected to must match, i.e. a machine connected to Ethernet0 on switch 1 must be connected to Ethernet0 on switch 2 etc. Furthermore, the breakout configurations of both switches must match and the new switch must contain at least all of the old switch's interfaces.
Migrating from Cumulus to Edgecore SONiC
Both migration and replacement can be used to move from Cumulus to Edgecore SONiC (or vice versa). Migrating to or from Broadcom SONiC or mixing Broadcom SONiC with Cumulus or Edgecore SONiC is not supported.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Releases and Updates
Your are currently reading the documentation for the metal-stack master release.
Releases and integration tests are published through our release repository. You can also find the release notes for this metal-stack version in there. The release notes contain information about new features, upgrade paths and bug fixes.
A release is created in the following way:
- Individual repository maintainers within the metal-stack Github Org can publish a release of their component.
- This release is automatically pushed to the
developbranch of the release repository by the metal-robot. - The push triggers a small release integration test through the mini-lab.
- To contribute components that are not directly part of the release vector, a pull request must be made against the
developbranch of the release repository. Release maintainers may push directly to thedevelopbranch. - The release maintainers can
/freezethedevelopbranch, effectively stopping the metal-robot from pushing component releases to this branch. - The
developbranch is tagged by a release maintainer with a-rc.xsuffix to create a release candidate. - The release candidate must pass a large integration test suite on a real environment, which is currently run by FI-TS. It tests the entire machine provisioning engine including the integration with Gardener, the deployment, metal-images and Kubernetes conformance tests.
- If the integration tests pass, the PR of the
developbranch must be approved by at least two release maintainers. - A release is created via Github releases, including all release notes, with a tag on the
mainbranch.
If you want, you can sign up at our Slack channel where we are announcing every new release. Often, we provide additional information for metal-stack administrators and adopters at this place, too.
Update Policy
For new features and breaking changes we create a new minor release of metal-stack. For every minor release we present excerpts of the changes in a corresponding blog article published on metal-stack.io.
It is not strictly necessary to cycle through the patch releases if you depend on the pure metal-stack components. However, it is important to go through all the patch releases and apply all required actions from the release notes. Therefore, we recommend to just install every patch release one by one in order to minimize possible problems during the update process.
In case you depend on the Gardener integration, especially when using metal-stack roles for deploying Gardener, we strongly recommend installing every patch release version. We increment our Gardener dependency version by version following the Gardener update policy. Jumping versions may lead to severe problems with the installation and should only be done if you really know what you are doing.
If you use the Gardener integration of metal-stack do not skip any patch releases. You may skip patch releases if you depend on metal-stack only, but we recommend to just deploy every patch release one by one for the best possible upgrade experience.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Architecture
The metal-stack is a compound of microservices predominantly written in Golang.
This page gives you an overview over which microservices exist, how they communicate with each other and where they are deployed.
Target Deployment Platforms
For our environments, we chose to deploy the metal-stack into a Kubernetes cluster. This means that also our entire installation was developed for metal-stack being run on Kubernetes. Running applications on Kubernetes gives you a lot of benefits regarding ease-of-deployment, scalability, reliability and so on.
However, very early we decided that we do not want to depend on technical Kubernetes functionality with our software (i.e. we did not implement the stack "kube-native" by using controllers and Kubernetes CRDs and things like that). With the following paragraph we want to point out the reasoning behind this "philosophical" decision that may sound conservative at first glance. But not relying on Kubernetes technology:
- Makes deployments of the stack without Kubernetes theoretically possible.
- We believe that cloud providers should be able to act beneath Kubernetes
- This way it is possible to use metal-stack for providing your own Kubernetes offering without relying on Kubernetes yourself (breaks the chicken-egg problem)
- Follows an important claim in microservice development: "Be agnostic to your choice of technology"
- For applications that are purely made for being run on Kubernetes, it does not matter to rely on this technology (we even do the same a lot with our applications that integrate the metal-stack with Gardener) but as soon as you start using things like the underlying reconciliation abilities (which admittedly are fanstatic) you are locking your code into a certain technology
- We don't know what comes after Kubernetes but we believe that a cloud offering should have the potential to survive a choice of technology
- By this decision we ensured that we can migrate the stack to another future technology and survive the change
One more word towards determining the location for your metal control plane: It is not strictly required to run the control plane inside the same data center as your servers. It even makes sense not to do so because this way you can place your control plane and your servers into a different failure domains, which makes your installation more robust to data center meltdown. Externally hosting the control plane brings you up and running quickly plus having the advantage of higher security through geo-distribution.
Metal Control Plane
The foundation of the metal-stack is what we call the metal control plane.
The control plane contains a couple of essential microservices for the metal-stack including:
- metal-api The API to manage control plane resources like machines, switches, operating system images, machine sizes, networks, IP addresses and more. The exposed API is an old-fashioned REST API with different authentication methods. The metal-api stores the state of these entities in a RethinkDB database. The metal-api also has its own IP address management (go-ipam), which writes IP address and network allocations into a PostgreSQL backend.
- masterdata-api Manages tenant and project entities, which can be described as entities used for company-specific resource separation and grouping. Having these "higher level entities" managed by a separate microservice was a design choice that allows to re-use the information by other microservices without having them to know the metal-api at all. The masterdata gets persisted in a dedicated PostgreSQL database.
- metal-console Provides access for users to a machine's serial console via SSH. It can be seen as an optional component.
- nsq A message queuing system (not developed by the metal-stack) used for decoupling microservices and distributing tasks.
The following figure shows the relationships between these microservices:
Figure 1: The metal control plane deployed in a Kubernetes environment with an ingress-controller exposing additional services via service exposal.
Some notes on this picture:
- Users can access the metal-api with the CLI client called metalctl.
- You can programmatically access the metal-api with client libraries (e.g. metal-go).
- Our databases are wrapped in a specially built backup-restore-sidecar, which is consistently backing up the databases in external blob storage.
- The metal-api can be scaled out using replicas when being deployed in Kubernetes.
Partitions
A partition is our term for describing hardware in the data center controlled by the metal-stack with all the hardware participating in the same network topology. Being in the same network topology causes the hardware inside a partition to build a failure domain. Even though the network topology for running the metal-stack is required to be redundant by design, you should consider setting up multiple partitions. With multiple partitions it is possible for users to maintain availability of their applications by spreading them across the partitions. Installing partitions in multiple data centers would be even better in regards of fail-safe application performance, which would even tolerate the meltdown of a data center.
In our setups, we encode the name of a region and a zone name into our partition names. However, we do not have dedicated entities for regions and zones in our APIs.
A region is a geographic area in which data centers are located.
Zones are geographic locations in a region usually in different fire compartments. Regions can consist of several zones.
A zone can consist of several partitions. Usually, a partition spans a rack or a group of racks.
We strongly advise to group your hardware into racks that are specifically assembled for running metal-stack. When using modular rack design, the amount of compute resources of a partition can easily be extended by adding more racks to your partition.
The hardware that we currently support to be placed inside a partition is described in the hardware document.
How large you can grow your partitions and how the network topology inside a partition looks like is described in the networking document.
The metal-stack has microservices running on the leaf switches in a partition. For this reason, your leaf switches are required to run a Linux distribution that you have full access to. Additionally, there are a servers not added to the pool of user-allocatable machines, which are instead required for running metal-stack and we call them management servers. We also call the entirety of switches inside a partition the switch plane.
The microservices running inside a partition are:
- metal-hammer (runs on a server when not allocated by user, often referred to as discovery image) An initrd, which is booted up in PXE mode, preparing and registering a machine. When a user allocates a machine, the metal-hammer will install the target operating system on this machine and kexec into the new operating system kernel.
- metal-core (runs on leaf switches) Dynamically configures the leaf switch from information provided by the metal-api. It also proxies requests from the metal-hammer to the metal-api including publishment of machine lifecycle events and machine registration requests.
- pixiecore (preferably runs on management servers, forked by metal-stack) Provides the capability of PXE booting servers in the PXE boot network.
- metal-bmc (runs on management servers) Reports the ip addresses that are leased to ipmi devices together with their machine uuids to the metal-api. This provides machine discovery in the partition machines and keeps all IPMI interface access data up-to-date. Also forwards metal-console requests to the actual machine, allowing user access to the machine's serial console. Furthermore it processes firmware updates and power on/off, led on/off, boot order changes.
Figure 2: Simplified illustration of services running inside a partition.
Some notes on this picture:
- This figure is slightly simplified. The switch plane consists of spine switches, exit routers, management firewalls and a bastion router with more software components deployed on these entities. Please refer to the networking document to see the full overview over the switch plane.
- The image-cache is an optional component consisting of multiple services to allow caching images from the public image store inside a partition. This brings increased download performance on machine allocation and increases independence of a partition on the internet connection.
Complete View
The following figure shows several partitions connected to a single metal control plane. Of course, it is also possible to have multiple metal control planes, which can be useful for staging.
Figure 3: Reduced view on the communication between the metal control plane and multiple partitions.
Some notes on this picture:
- By design, a partition only has very few ports open for incoming-connections from the internet. This contributes to a smaller attack surface and higher security of your infrastructure.
- With the help of NSQ, it is not required to have connections from the metal control plane to the metal-core. The metal-core instances register at the message bus and can then consume partition-specific topics, e.g. when a machine deletion gets issued by a user.
Machine Provisioning Sequence
The following sequence diagram illustrates some of the main principles of the machine provisioning lifecycle.
Figure 4: Sequence diagram of the machine provisioning sequence.
Here is a video showing a screen capture of a machine's serial console while running the metal-hammer in "wait mode". Then, a user allocates the machine and the metal-hammer installs the target operating system and the machine boots into the new operating system kernel via the kexec system call.
+
+
Offline Resilience
It is possible to use metal-stack without any external network dependencies by integrating your own DNS and NTP configuration into the stack. This feature is great for workloads requiring strong independence and reliability. Even in case of an internet connection failure, your infrastructure remains operational. Existing machines do not encounter any downtime as well as new machines can be provisioned. All you need to have in place is a DNS and NTP server configured and accessible for metal-stack.
NTP servers need to be configured on the pixiecore and the metal-hammer microservices. This can be achieved by providing a list of NTP servers with the following Ansible variable through metal-roles:
pixiecore_metal_hammer_ntp_servers: []In the background, the pixiecore is taking the NTP servers and passing it via the MetalConfig to the metal-hammer. When booting bare-metal servers, the metal-hammer needs to configure NTP servers. It recognises the ones from the MetalConfig and configures itself accordingly. If no NTP servers are passed along, the following standard servers are used:
- 0.de.pool.ntp.org
- 1.de.pool.ntp.org
- 2.de.pool.ntp.org
Moreover, machine and firewall images need to be configured with your custom DNS and NTP servers. The customisation can be made via the fields ntp_servers an dns_servers and specifying a list of servers in the creation request for the machine or firewall.
Within a partition default values for DNS and NTP servers can be configured. They are applied to all machines and firewalls within this partition, but can be replaced by specifying different ones inside the machine allocation request.
Thus, for creating a partition as well as a machine or a firewall, the flags dnsservers and ntpservers can be provided within the metalctl command.
In order to be fully offline resilient, make sure to check out metal-image-cache-sync. This component provides copies of metal-images, metal-kernel and metal-hammer.
This feature is related to MEP14.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Comparison with Commercial Solutions
As metal-stack is the foundation to build Kubernetes clusters on premise on bare metal, there are several commercial solutions available which offer management of Kubernetes. In this document we describe the differences between some of the most popular solutions. It´s is not a complete list.
Comparison between Gardener on Metal Stack and Openshift running on VMWare.
Gardener
Gardener is a Kubernetes cluster manager to organize a fleet of Kubernetes clusters at scale. It is designed to scale to thousands of clusters at a variety of IaaS Providers regardless where - in the cloud or on premise, virtualized or bare metal. It not only manages the creation and deletion of Kubernetes clusters, it also takes care of updating or upgrading Kubernetes and the operating system of the involved worker nodes in a automatic manner. Gardener is designed cloud-native and as such, it defines clusters, workers and all other components as Kubernetes resources (like pods and deployments) and reconciles these resources to the desired state.
Kubernetes
Kubernetes is the de facto open-source standard for container scheduling and orchestration in the data center.
Openshift
A fork of Kubernetes with proprietary addons, created by RedHat. For all details see: https://en.wikipedia.org/wiki/OpenShift.
metal-stack
Is an IaaS provider for bare metal focused to create Kubernetes cluster on premise. Gardener support is built in.
VMWare
The most used virtualization technology in the enterprise data centers.
Comparison of Gardener on Metal Stack vs. Openshift on VMWare
| Feature | Gardener on Metal Stack | Openshift on VMWare |
|---|---|---|
| Container Runtime | docker, containerd, gvisor | cri-o |
| Host Operating System | Ubuntu, Debian , also see OS | RHEL, Fedora-Core |
| Network Plugins | Calico, Cilium(soon) | Openshift SDN |
| Storage | Local NVME, Lightbits NVMEoTCP, all CSI compatible Solutions, also see Storage | CSI compatible |
| Loadbalancing | BGP built in | requires extra HW like F5, VMWare NSX |
| IO at Native Speed | Pods run on bare metal | all IO must go through the Hypervisor |
| Hard Multitenancy | Workers, firewall and load balancers are dedicated for every cluster on bare metal | Shared virtualization hosts, shared load balancers |
| UI | Gardener Dashboard | Openshift Console |
| Multi-cluster management | Yes (through Gardener) | Requires extra licences SW: Redhat Advanced Cluster Manager |
| Automatic Kubernetes Updates | Yes | Yes |
| Automatic Worker Nodes Updates | Yes | Yes |
| Supported IaaS Providers | GCP, AWS, Azure, Alibaba, Openstack, VMWare, metal-stack and more | GCP, AWS, Azure Openstack, VMWare |
| Monitoring / Logging Stack | Grafana/Loki, Kibana/Elastic | Kibana/Elastic |
| GitOPS | Tool of choice via Helm Install | Openshift GitOPS |
| Container Registry | all public accessible registries, private deployed registry of choice | all public accessible registries, in cluster registry |
| CI/CD | Tool of choice via Helm Install | Jenkins |
| Security | K8s control plane isolated from tenant, PSP enabled by default | Strong cluster defaults |
| CNCF Kubernetes certified | Yes (Gardener) | Yes |
| Local development | minikube, kind | minishift |
| Proprietary extensions | No | DeploymentConfig and others |
| kubectl access | Yes | Yes |
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
GPU Support
For workloads which require the assistance of GPUs, support for GPUs in bare metal servers was added to metal-stack.io v0.18.0.
GPU Operator installation
With the nvidia image a worker has basic GPU support. This means that the required kernel driver, the containerd shim and the required containerd configuration are already installed and configured.
To enable Pods that require GPU support to be scheduled on a worker node with a GPU, a `gpu-operator' must be installed. This has to be done by the cluster owner after the cluster is up and running.
The simplest way to install this operator is as follows:
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
+helm repo update
+
+kubectl create ns gpu-operator
+kubectl label --overwrite ns gpu-operator pod-security.kubernetes.io/enforce=privileged
+
+helm install --wait \
+ --generate-name \
+ --namespace gpu-operator \
+ --create-namespace \
+ nvidia/gpu-operator \
+ --set driver.enabled=false \
+ --set toolkit.enabled=falseAfter that kubectl describe node must show the gpu in the capacity like so:
...
+Capacity:
+ cpu: 64
+ ephemeral-storage: 100205640Ki
+ hugepages-1Gi: 0
+ hugepages-2Mi: 0
+ memory: 263802860Ki
+ nvidia.com/gpu: 1
+ pods: 510
+...With this basic installation, the worker node is ready to process GPU workloads.
However, there is a caveat - only one 'Pod' can access the GPU. If this is all you need, no additional configuration is required. On the other hand, if you are planning to deploy multiple applications that require GPU support, and there are not that many GPUs available, you will need to configure the gpu-operator to allow the GPU to be shared between multiple Pods.
There are several approaches to sharing GPUs, please consult the official Nvidia documentation for further reference.
https://developer.nvidia.com/blog/improving-gpu-utilization-in-kubernetes https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-operator-mig.html https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-sharing.html
With this, happy AI processing.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Hardware Support
In order to keep the automation and maintenance overhead small, we strongly advise against building highly heterogeneous environments with metal-stack. Having a lot of different vendors and server models in your partitions will heavily increase the time and effort for introducing metal-stack in your infrastructure. From experience we can tell that the interfaces for automating hardware provisioning are usually inconsistent between vendors and even between server models of the same vendor. Therefore, we encourage adopters to start off with only a small amount of machine types. If you want to be on the safe side, you should consider buying the hardware that we officially support.
We came up with a repository called go-hal, which includes the interface required for metal-stack to support a machine vendor. If you plan to implement support for new vendors, please check out this repository and contribute back your efforts in order to make the community benefit from extended vendor support as well.
Servers
The following server types are officially supported and verified by the metal-stack project:
| Vendor | Series | Model | Board Type | Status |
|---|---|---|---|---|
| Supermicro | Big-Twin | SYS-2029BT-HNR | X11DPT-B | stable |
| Supermicro | Big-Twin | SYS-220BT-HNTR | X12DPT-B6 | stable |
| Supermicro | SuperServer | SSG-5019D8-TR12P | X11SDV-8C-TP8F | stable |
| Supermicro | SuperServer | 2029UZ-TN20R25M | X11DPU | stable |
| Supermicro | SuperServer | SYS-621C-TN12R | X13DDW-A | stable |
| Supermicro | Microcloud | 5039MD8-H8TNR | X11SDD-8C-F | stable |
| Supermicro | Microcloud | SYS-531MC-H8TNR | X13SCD-F | coming soon |
| Supermicro | Microcloud | 3015MR-H8TNR | H13SRD-F | coming soon |
| Lenovo | ThinkSystem | SD530 | alpha |
Other server series and models might work but were not reported to us.
GPUs
The following GPU types are officially supported and verified by the metal-stack project:
| Vendor | Model | Status |
|---|---|---|
| NVIDIA | RTX 6000 | stable |
| NVIDIA | H100 | stable |
Other GPU models might work but were not reported to us. For a detailed description howto use GPU support in a kubernetes cluster please check this documentation
Network Cards
The following network cards are officially supported and verified by the metal-stack project for usage in servers:
| Vendor | Series | Model | Status |
|---|---|---|---|
| Intel | XXV710 | DA2 DualPort 2x25G SFP28 | stable |
| Intel | E810 | DA2 DualPort 2x25G SFP28 | stable |
| Intel | E810 | CQDA2 DualPort 2x100G SFP28 | stable |
| Mellanox | ConnectX-5 | MCX512A-ACAT 2x25G SFP28 | stable |
Switches
The following switch types are officially supported and verified by the metal-stack project:
| Vendor | Series | Model | OS | Status |
|---|---|---|---|---|
| Edge-Core | AS7700 Series | AS7712-32X | Cumulus 3.7.13 | stable |
| Edge-Core | AS7700 Series | AS7726-32X | Cumulus 4.1.1 | stable |
| Edge-Core | AS7700 Series | AS7712-32X | Edgecore SONiC | stable |
| Edge-Core | AS7700 Series | AS7726-32X | Edgecore SONiC | stable |
Other switch series and models might work but were not reported to us.
On our switches we run SONiC. The metal-core writes network configuration specifically implemented for this operating system. Please also consider running SONiC on your switches if you do not want to run into any issues with networking.
Our previous support for Cumulus Linux will come to an end.
Of course, contributions for supporting other switch vendors and operating systems are highly appreciated.
Portable metal-stack Setup DIY
A minimal physical hardware setup may contain at least the following components:
This setup should work as the components are very similar to the currently supported ones but it's currently untested.
| # | Vendor | Series | Model | Function |
|---|---|---|---|---|
| 2x | Edge-Core | AS5500 Series | AS5512-54x (10G) | Leaf / Exit switches |
| 1x | Supermicro | Microcloud | SYS-5039MA16-H12RFT | Usable machines |
| 1x | Teltonika | Router | RUTXR1 | Front router for internet and out-of-band access to servers and switches |
Besides that, a 6HE rack with 1000mm depth and a portable LTE modem is needed.
This MVP will yield in 12 usable machines, one of them will be reserved as management server.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Isolated Kubernetes Clusters
- Isolated Kubernetes Clusters
Some customers have the need to run their workloads in a very restricted environment. These restrictions are driven by regulatory requirements in some industries such as finance, healthcare, energy and more. Regulatory requirements often mandate that the workload must not be exposed to the public internet, nor is capable to reach the public internet in any case.
For this purpose we implemented a possibility to start Kubernetes clusters in such a manner. This is referred to as cluster isolation.
Design Choices
When talking about highly secure Kubernetes environments people often raise the term "Air Gapped Cluster". This would mean that no physical connection exists between the Kubernetes control plane and the Kubernetes worker nodes with the outside world. This requirement exists in extreme environments such as ships, moon bases or nuclear plants. The effort to produce this in a completely automated manner is extremely challenging.
We decided to follow a different approach which is more practical, still very secure but much simpler to implement and operate. The solution we created is called "Isolated Cluster" which means that there are still physical connections between the Kubernetes cluster, but guarded to prohibit malicious traffic. It is also not possible to enable malicious traffic by accident, e.g. if a cluster user configures network policies or load balancers to untrusted environments.
Network Design
In order to be able to restrict ingress and egress internet traffic, but still make it possible to create a working Kubernetes cluster we implemented the following network design.
- All strictly required container images are mirrored to a registry which is only accessible from the Kubernetes clusters.
- DNS and NTP servers are produced alongside the registry.
- The
containerdconfiguration on every worker node is configured to pull all of the strictly required container images from this private registry mirror. - DNS and NTP configuration is also adopted to use the DNS and NTP servers on this private environment.
- A list of networks which are allowed to reach is managed, this list reflects the networks of the cloud provider and is not modifiable by the cluster user. This list usually contains the internet prefixes of the provider and one or more RFC address ranges.
Users are advised to attach an additional network to the Kubernetes cluster in order to be able to pull container images for the application workloads from private registries.
Strictly Required Container Images
In general the creation of a Kubernetes cluster requires the ability to pull container images for several applications which are necessary to make a machine a Kubernetes worker node. To mention the most important:
- Kubelet: the main controller on each worker node to manage the workload
- CNI (Container Network Interface): controller and daemon set to setup and run the container networking
- CSI (Container Storage Interface): controller and daemon set to setup and run the container storage
- CoreDNS: DNS for containers
- MetalLB: Service Type LoadBalancer Implementation
- node-exporter and metrics-server: Monitoring for the worker node
- Metal-Stack Addons: for firewall and auditing events
Flavors
With the introduction of Isolated Kubernetes Clusters, cluster users must decide upon cluster creation which type of isolation he needs for his workload. There are three different flavours available:
- Internet access
baseline: This is the default cluster creation mode, which does not change any aspects of network and registry access. - Internet access
forbidden: No internet access is possible, neither ingress nor egress. - Internet access
restricted: No internet access is possible, neither ingress nor egress, but can be enabled by the cluster user.
Please see the detailed description of these flavors below.
Cluster Wide Network Policies CWNP
To restrict which egress traffic is allowed, Custom Resources ClusterWideNetworkPolicy are deployed and can be deployed by the cluster user. The set of deployed CWNPs differs between baseline and forbidden/restricted.
baseline CWNPs:
| Rule Name | Destination | Purpose |
|---|---|---|
| allow-to-http | 0.0.0.0/0 | egress via http |
| allow-to-https | 0.0.0.0/0 | egress via https |
| allow-to-apiserver | IP of the Kubernetes API Server on the control plane | API Server communication of kubelet and other controllers |
| allow-to-dns | IP of the Google DNS Servers | DNS resolution from the Kubernetes worker nodes and containers |
| allow-to-ntp | IP of the Cloudflare NTP Servers | Time synchronization |
| allow-to-storage | network of the container storage | persistent volumes with the cni driver |
| allow-to-vpn | IP of the vpn endpoint on the control plane | allow communication from the api server to the kubelet for container logs and container exec |
forbidden and restricted CWNPs:
| Rule Name | Destination | Purpose |
|---|---|---|
| allow-to-apiserver | IP of the Kubernetes API Server on the control plane | API Server communication of kubelet and other controllers |
| allow-to-dns | IP of the private DNS Server | DNS resolution from the Kubernetes worker nodes and containers |
| allow-to-ntp | IP of the private NTP Server | Time synchronization |
| allow-to-registry | IP of the private Registry Mirror | Pulling strictly required container images |
| allow-to-storage | network of the container storage | persistent volumes with the cni driver |
| allow-to-vpn | IP of the vpn endpoint on the control plane | allow communication from the api server to the kubelet for container logs and container exec |
All of these CWNPs are managed by the gardener-extension-provider-metal, every manual modification will be reverted immediately.
Internet Access Baseline
This is the default configuration of a Kubernetes cluster, egress traffic is controlled by multiple CWNPs (ClusterWideNetworkPolicy), ingress traffic is possible by deploying a Service Type LoadBalancer. The cluster user can add additional CWNPs without any restrictions and is responsible for them.
Container images can be pulled from any reachable container registry. The containerd is not reconfigured to point to our private registry mirror.
DNS and NTP are configured to internet DNS resolvers and NTP servers.
Internet Access Forbidden
This configuration can only be achieved by creating a new Kubernetes cluster, it is not possible to modify a existing cluster (with internet access baseline or restricted) to this configuration. It is also required to specify the most recent version of Kubernetes, older versions of Kubernetes are not supported.
Every network access modification triggered by a cluster user, either by adding or modifying CWNPs or adding a Service Type LoadBalancer, is validated against the list of allowed networks.
containerd is configured so that all required images are pulled from the private registry mirror. This registry contains only the strictly required images, therefore no additional (workload) images can be pulled from public registries.
Egress traffic
Egress traffic is only allowed to the private registry mirror and the DNS and NTP servers. Additional CWNPs can be added to reach destinations in the internal networks if specified. If a CWNP was created which points to a destination outside of the allowed networks, the CWNP will still be present but stays in the status ignored.
> kubectl get clusterwidenetworkpolicies.metal-stack.io
+NAME STATUS MESSAGE
+allow-to-apiserver deployed
+allow-to-dns deployed
+allow-to-ntp deployed
+allow-to-registry deployed
+allow-to-storage deployed
+allow-to-vpn deployed
+allow-to-google ignored ingress/egress does not match allowed networksAlso an event is created which describes why the CWNP was ignored:
> kubectl get events
+5s Warning ForbiddenCIDR clusterwidenetworkpolicy/allow-to-google address:"8.8.8.8/32" is outside of the allowed network range:"10.0.0.0/8,100.64.0.0/10,212.34.83.0/27", ignoringIngress traffic
Ingress traffic is only allowed from the internal networks if specified. To specify the address where the Service Type LoadBalancer is listening to, the cluster user must use one of his statically acquired ip addresses. Of course, this ip address is only considered if it is contained in the list of allowed networks. Then this ip address must be configured in the service:
apiVersion: v1
+kind: Service
+spec:
+ type: LoadBalancer
+ loadBalancerIP: 10.1.1.1 # ip from the internal networkBy default, no ip address will be automatically selected for such clusters and the ip of the service will stay in pending mode until the ip was specified as shown above.
> kubectl get svc
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+example-service LoadBalancer 10.244.75.171 <pending> 443:32179/TCP 4s
+
+> kubectl get events
+8s Warning AllocationFailed service/example-service Failed to allocate IP for "default/example-service": no available IPs
+3s Warning SyncLoadBalancerFailed service/example-service Error syncing load balancer: failed to ensure load balancer: no default network for ip acquisition specified, acquire an ip for your cluster's project and specify it directly in "spec.loadBalancerIP"Internet Access Restricted
This configuration can only be achieved by creating a new Kubernetes cluster, it is not possible to modify a existing cluster (with internet access baseline or forbidden) to this configuration. It is also required to specify the most recent version of Kubernetes, older versions of Kubernetes are not supported.
The same default CWNPs are deployed and the container images are pulled from the private registry. Also DNS and NTP are configured to use the private DNS and NTP servers. The only difference to the forbidden mode is that CWNPs and Service Type LoadBalancers can be created without the restriction that only allowed networks are allowed.
Pulling container images is theoretically possible if a cluster user creates a CWNP which allows network access to an external registry. But most container registries serve the container images from large CDN networks, which have a lot of ip addresses. Simply adding the ip address of docker.io is therefore not sufficient.
Application Container Images
In order to deploy application containers into a cluster with Internet Access forbidden a private registry must be provided. This private registry must be located in the list of allowed networks. The DNS name of the registry must resolve in the public DNS servers. The registry must be secured with a TLS certificate that is also valid with the CA certificates from the worker node, e.g. vanilla debian ca-certificates.
Implementation
To achieve this functionality modifications have been implemented in various components in metal-stack, this includes:
Gardener Extension Provider Metal
The ControlPlane API is adopted to enable a user to configure a shoot with the internet access type forbidden or restricted. The CloudProfile can now be extended to carry the list of allowed networks, the dns and ntp servers, the registry with the mirrored registries.
ControlPlane:
// ControlPlaneConfig contains configuration settings for the control plane.
+type ControlPlaneConfig struct {
+ metav1.TypeMeta
+
+ // NetworkAccessType defines how the cluster can reach external networks.
+ // +optional
+ NetworkAccessType *NetworkAccessType
+}
+type (
+ // NetworkAccessType defines how a cluster is capable of accessing external networks
+ NetworkAccessType string
+)
+
+const (
+ // NetworkAccessBaseline allows the cluster to access external networks in a baseline manner
+ NetworkAccessBaseline = NetworkAccessType("baseline")
+ // NetworkAccessRestricted access to external networks is by default restricted to registries, dns and ntp to partition only destinations.
+ // Therefore registries, dns and ntp destinations must be specified in the cloud-profile accordingly.
+ // If this is not the case, restricting the access must not be possible.
+ // Image overrides for all images which are required to create such a shoot, must be specified. No other images are provided in the given registry.
+ // customers can define own rules to access external networks as in the baseline.
+ // Service type LoadBalancers are also not restricted.
+ NetworkAccessRestricted = NetworkAccessType("restricted")
+ // NetworkAccessForbidden in this configuration a customer can no longer create rules to access external networks.
+ // which are outside of a given list of allowed networks. This is enforced by the firewall.
+ // Service type LoadBalancers are also not possible to open a service ip which is not in the list of allowed networks.
+ // This is also enforced by the firewall.
+ NetworkAccessForbidden = NetworkAccessType("forbidden")
+)A sample Shoot Spec:
---
+apiVersion: core.gardener.cloud/v1beta1
+kind: Shoot
+metadata:
+ name: isolated
+ namespace: sample
+spec:
+ provider:
+ type: metal
+ controlPlaneConfig:
+ networkAccessType: forbidden
+...CloudProfile:
type NetworkIsolation struct {
+ // AllowedNetworks is a list of networks which are allowed to connect in restricted or forbidden NetworkIsolated clusters.
+ AllowedNetworks AllowedNetworks
+ // DNSServers
+ DNSServers []string
+ // NTPServers
+ NTPServers []string
+ // The registry which serves the images required to create a shoot.
+ RegistryMirrors []RegistryMirror
+}
+
+// AllowedNetworks is a list of networks which are allowed to connect in restricted or forbidden NetworkIsolated clusters.
+type AllowedNetworks struct {
+ // Ingress defines a list of networks which are allowed for incoming traffic like service type LoadBalancer
+ // to allow all you must specify 0.0.0.0/0 or ::/0
+ Ingress []string
+ // Egress defines a list of networks which are allowed for outgoing traffic
+ // to allow all you must specify 0.0.0.0/0 or ::/0
+ Egress []string
+}
+
+type RegistryMirror struct {
+ // Name describes this server
+ Name string
+ // Endpoint is typically the url of the registry in the form https://hostname
+ Endpoint string
+ // IP is the ipv4 or ipv6 address of this server
+ IP string
+ // Port at which port the service is reachable
+ Port int32
+ // This Registry Mirror mirrors the following registries
+ MirrorOf []string
+}A sample configuration in the CloudProfile would look like:
network-isolation:
+ allowedNetworks:
+ egress:
+ - 1.2.3.0/24 # Internet CIDR of the Provider
+ - 100.64.0.0/10
+ - 10.0.0.0/8
+ ingress:
+ - 100.64.0.0/10
+ dnsServers:
+ - "1.2.3.1"
+ - "1.2.3.2"
+ - "1.2.3.3"
+ ntpServers:
+ - "1.2.3.1"
+ - "1.2.3.2"
+ - "1.2.3.3"
+ registryMirrors:
+ - name: test registry
+ endpoint: https://some.private.registry
+ ip: "1.2.3.4"
+ port: 443
+ mirrorOf:
+ - "docker.io"
+ - "quay.io"
+ - "eu.gcr.io"
+ - "ghcr.io"
+ - "registry.k8s.io"OS Metal Extension
Based on the configuration of a cluster the configuration of the containerd must be changed to pull images from the private registry mirror. If a cluster is either configured with restricted or forbidden, the configuration of containerd will be created as such:
config.toml
# Generated by os-extension-metal
+version = 2
+imports = ["/etc/containerd/conf.d/*.toml"]
+
+disabled_plugins = []
+[plugins."io.containerd.grpc.v1.cri".registry]
+ config_path = "/etc/containerd/certs.d"And for every registry mirror an additional certs.d/$HOST/hosts.yaml will be created. This is in line with Gardener's containerd Registry Configuration.
# certs.d/docker.io/hosts.yaml
+
+server = "https://docker.io"
+[host."https://some.private.registry"]
+ capabilities = ["pull", "resolve"]DNS and NTP must also be adopted according to the configuration in the CloudProfile.
Firewall Controller Manager and Firewall Controller
The Firewall Controller Manager has extended the FirewallSpec to configure the Firewall Controller which must enforce the restrictions regarding allowed networks.
// FirewallSpec defines parameters for the firewall creation along with configuration for the firewall-controller.
+type FirewallSpec struct {
+ // AllowedNetworks defines which networks are allowed to connect to, and allow incoming traffic from.
+ // Is enforced with NetworkAccessForbidden.
+ // The node network is always allowed.
+ AllowedNetworks AllowedNetworks `json:"allowedNetworks,omitempty"`
+}
+
+// AllowedNetworks is a list of networks which are allowed to connect when NetworkAccessType is NetworkAccessForbidden.
+type AllowedNetworks struct {
+ // Ingress defines a list of cidrs which are allowed for incoming traffic like service type LoadBalancer
+ Ingress []string `json:"ingress,omitempty"`
+ // Egress defines a list of cidrs which are allowed for outgoing traffic
+ Egress []string `json:"egress,omitempty"`
+}Also the ClusterwideNetworkPolicy in the Firewall Controller was changed to show the deployment status of a CWNP.
+type ClusterwideNetworkPolicy struct {
+ metav1.TypeMeta `json:",inline"`
+ metav1.ObjectMeta `json:"metadata,omitempty"`
+
+ Spec PolicySpec `json:"spec,omitempty"`
+ Status PolicyStatus `json:"status,omitempty"`
+}
+
+// PolicyDeploymentState describes the state of a CWNP deployment
+type PolicyDeploymentState string
+
+const (
+ // PolicyDeploymentStateDeployed the CWNP was deployed to a native nftable rule
+ PolicyDeploymentStateDeployed = PolicyDeploymentState("deployed")
+ // PolicyDeploymentStateIgnored the CWNP was not deployed to a native nftable rule because it is outside of the allowed networks
+ PolicyDeploymentStateIgnored = PolicyDeploymentState("ignored")
+)
+
+// PolicyStatus defines the observed state for CWNP resource
+type PolicyStatus struct {
+ // FQDNState stores mapping from FQDN rules to nftables sets used for a firewall rule.
+ // Key is either MatchName or MatchPattern
+ // +optional
+ FQDNState FQDNState `json:"fqdn_state,omitempty"`
+ // State of the CWNP, can be either deployed or ignored
+ State PolicyDeploymentState `json:"state"`
+ // Message describe why the state changed
+ Message string `json:"message,omitempty"`
+}Cloud Controller Manager
This component was adopted to allow to be started without a default network specified. This was actually always the internet network and if no ip address was specified in the Service Type LoadBalancer, one ip was allocated from this default network. For isolated clusters this is not provided and a cluster user must always specify this ip to get a working load balancer.
OCI Mirror
The OCI Mirror is a new application which acts as a scheduled job that pulls a given list of container images and pushes them to a private registry (which will then serve as the private registry mirror). The detailed description can be read on the project website.
Related Pull Requests
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Kubernetes Integration
With the help of the Gardener project, metal-stack can be used for spinning up Kubernetes clusters quickly and reliably on bare metal machines.
To make this happen, we implemented a couple of components, which are described here.
metal-ccm
CCM stands for cloud-controller-manager and is the bridge between Kubernetes and a cloud-provider.
We implemented the cloud provider interface in the metal-ccm repository. With the help of the cloud-controller-controller we provide metal-stack-specific properties for Kubernetes clusters, e.g. load balancer configuration through MetalLB or node properties.
firewall-controller
To make the firewalls created with metal-stack easily configurable through Kubernetes resources, we add our firewall-controller to the firewall image. The controller watches special CRDs, enabling users to manage:
- nftables rules
- Intrusion-detection with suricata
- network metric collection
Please check out the guide on how to use it.
Gardener components
There are some Gardener resources that need be reconciled when you act as a cloud provider for the Gardener. This section briefly describes the controllers implemented for deploying Kubernetes clusters through Gardener.
If you want to learn how to deploy metal-stack with Gardener, please check out the installation section.
gardener-extension-provider-metal
The gardener-extension-provider-metal contains of a set of webhooks and controllers for reconciling or mutating Gardener-specific resources.
The project also contains a validator for metal-type Gardener resources, which you should also deploy in case you want to use metal-stack in combination with Gardener.
os-metal-extension
Due to the reason we use ignition in our operating system images for userdata, we had to provide an own extension controller for metal-stack, which you can find at Github in the os-metal-extension repository.
machine-controller-manager-provider-metal
Worker nodes are managed through Gardener's machine-controller-manager (MCM). The MCM allows out-of-tree provider implementation via sidecar, which is what we implemented in the machine-controller-manager-provider-metal repository.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Networking
We spent a lot of time on trying to provide state-of-the-art networking in the data center. This document describes the requirements, ideas and implementation details of the network topology that hosts the metal-stack.
The document is separated into three main sections describing the constraints, theoretical ideas and implementation details.
Requirements
Finding the requirements for this greenfield project was kicked off with a handful of design parameters that included:
- Investigation of the idea of a layer-3 based infrastructure to overcome the drawbacks of traditional layer-2 architectures.
- Application of a routing technology that involves a single stand-alone protocol BGP for operational simplicity.
- Utilization of the overlay virtual network technology EVPN to support cost-effective scaling, efficient network information exchange and a manageable amount of administration effort.
- Applying the routing topology on top of a completely new physical infrastructure that is designed as a CLOS network topology.
Evaluation of those parameters led to more specific requirements:
- Physical Wiring:
- The data center is made of a leaf-spine CLOS topology containing:
- leaf switches
- spine switches
- exit switches
- management server
- management switch
- tenant servers
- tenant firewalls.
- Bare metal servers are dual-attached to leaf switches. The bare metal servers either become tenant servers or firewalls for a group of tenant servers.
- All network switches are connected to a management switch. A management server provides access to this management network.
- The data center is made of a leaf-spine CLOS topology containing:
- Network Operation Characteristics:
- IPv4 based network.
- No IPv6 deployment.
- Utilization of external BGP.
- Numbered BGP only for peerings at exit switches with third parties (Internet Service Provider).
- Overall BGP unnumbered.
- 4-byte private ASN instead of default 2-byte ASN for BGP.
- Network operation relies on SONiC Linux.
- Bleeding edge Routing-to-the-Host/EVPN-to-the-Host with ordinary Linux distributions.
- Layer-3 routing using BGP and VXLAN/EVPN.
- Every VTEP acts as a layer-3 gateway and does routing. Routing is done on both the ingress and the egress VTEP (aka distributed symmetric routing).
- Tenant isolation is realized with VRF.
- Internet Access is implemented with route leak on the firewall servers and during the PXE-Process with route leak on the exit switches.
- MTU 9216 is used for VXLAN-facing interfaces, otherwise MTU 9000 is used.
Furthermore, requirements such as operational simplicity and network stability that a small group of people can effectively support have been identified being a primary focus for building metal-stack.
Concept
The theoretical concept targets the aforementioned requirements. New technologies have been evaluated to apply the best solutions. The process was heavily inspired by the work of Dinesh G. Dutt regarding BGP (bgp-ebook) and EVPN (evpn-ebook).
External BGP together with network overlay concepts as EVPN can address the essential demands. These revolutionary concepts are part of the next evolutionary step in data center design. It overcomes common issues of traditional layer 2 architectures (e.g. VLAN limitations, network visibility for operations, firewall requirements) by introducing a layer 3 based network topology.
CLOS
A CLOS topology is named after the pioneer Charles Clos (short: CLOS) who first formalized this approach. CLOS defines a multistage network topology that is used today to improve performance and resilience while enabling a cost effective scalability. A CLOS topology comprises network switches aggregated into spine and leaf layers. Each leaf switch (short: leaf) is connected to all spine switches (short: spine) but there is no direct leaf-to-leaf or spine-to-spine connection (See: picture 1).
Picture 1: Fragment of CLOS to show leaf-spine layer.
This data center network architecture, based on a leaf-spine architecture, is also know as "two-tier" CLOS topology.
Picture 2: Fragment to show a 3-stage, 2-layer CLOS topology.
Tenant servers are dual-attached to the leaf layer in order to have redundancy and load balancing capability (Picture 2). The set of leaves, spine switches and tenant servers define stages. From top down each server is reachable with 3 hops (spine -> leaf -> server). This is why that CLOS design is called a 3-stage CLOS. Consistent latency throughout the data center are an outcome of this design.
It is not only important to have a scalable and resilient infrastructure but also to support planning and operation teams. Visibility within the network is of significant meaning for them. Consequently layer-3 routing in favor of layer-2 bridging provides this kind of tooling.
BGP
For routing the Border Gateway Protocol (BGP), more specific: External BGP was selected. Extensive testing and operational experiences have shown that External BGP is well suited as a stand-alone routing protocol (see: RFC7938).
Not all tenant servers are connected to the same leaf. Instead they can be distributed among any of the leaves of the data center. To not let this detail restrict the intra-tenant communication it is required to interconnect those layer-2 domains. In the context of BGP there is a concept of overlay networking with VXLAN/ EVPN that was evaluated to satisfy the needs of the metal-stack.
BGP Unnumbered
In BGP traditionally each BGP peer-facing interface requires a separate IPv4 address. This consumes a lot of IP addresses. RFC 5549 defines the BGP unnumbered standard. It allows to use interface's IPv6 link local address (LLA) to set up a BGP session with a peer. With BGP unnumbered the IPv6 LLA of the remote is automatically discovered via Router Advertisement (RA) protocol. Important: This does not (!) mean that IPv6 must be deployed in the network. BGP uses RFC 5549 to encode IPv4 routes as reachable over IPv6 next-hop using the LLA. Having unnumbered interfaces does not mean no IPv4 address may be in place. It is a good practice to configure an IP address to the never failing and always present local loopback interface (lo). This lo address is reachable over BGP from other peers because the RFC 5549 standard provides an encoding scheme to allow a router to advertise IPv4 routes with an IPv6 next-hop. BGP unnumbered also has an advantage from security perspective. It removes IPv4 and global IPv6 addresses from router interfaces, thus reducing the attack vector.
To sum it up:
- BGP unnumbered uses IPv6 next-hops to announce IPv4 routes.
- There is no IPv6 deployment in the network required.
- IPv6 just has to be enabled on the BGP peers to provide LLA and RA.
In BGP, ASN is how BGP peers know each other.
ASN Numbering
Within the data center each BGP router is identified by a private autonomous system number (ASN). This ASN is used for internal communication. The default is to have 2-byte ASN. To avoid having to find workarounds in case the ASN address space is exhausted, a 4-byte ASN that supports up to 95 million ASNs (4200000000–4294967294) is used from the beginning.
ASN numbering in a CLOS topology should follow a model to avoid routing problems (path hunting) due to it's redundant nature. Within a CLOS topology the following ASN numbering model is suggested to solve path hunting problems:
- Leaves have unique ASN
- Spines share an ASN
- Exit switches share an ASN
Address-Families
As stated, BGP is a multi-protocol routing protocol. Since it is planned to use IPv4 and overlay networks using EVPN/VXLAN several address-families have to be activated for the BGP sessions to use:
- IPv4 unicast address-family
- L2 EVPN address-family
EVPN
Ethernet VPN (EVPN) is an overlay virtual network that connects layer-2 segments over layer-3 infrastructure. EVPN is an answer to common problems of entire layer-2 data centers.
Why do we need EVPN
Challenges such as large failure domains, spanning tree complexities, difficult troubleshooting and scaling issues are addressed by EVPN:
- administration: less routers are involved in configuration (with VLAN every switch on routing-paths needs VLAN awareness). The configuration is less error prone due to the nature of EVPN and the good support in FRR.
- scaling: EVPN overcomes scaling issues with traditional VLANs (max. 4094 VLANs).
- cost-effectiveness: EVPN is an overlay virtual network. Not every switch on the routing path needs EVPN awareness. This enables the use of standard routers (in contrast to traditional VLAN); e.g.: spine switches act only as evpn information replicator and do not need to have knowledge of specific virtual networks.
- efficiency: EVPN information is exclusively exchanged via BGP (Multiprotocol BGP). Only a single eBGP session is needed to advertise layer-2 reachability. No other protocols beneath BGP are involved and flood traffic is reduced to a minimum (no "flood-and-learn", no BUM traffic).
Virtual routing permits multiple network paths without the need of multiple switches. Hence the servers are logically isolated by assigning their networks to dedicated virtual routers using virtual routing and forwarding (short: VRF).
How do we use EVPN
EVPN (technology) is based on BGP as control plane protocol (underlay) and VXLAN as data plane protocol (overlay).
As EVPN is an overlay network, only the VXLAN Tunnel End Points (VTEPs) must be configured. In the case of two-tier CLOS networks leaf switches are tunnel endpoints.
In EVPN routing is assumed to occur in the context of a VRF. VRF enables true multitenancy. Therewith, VRF is the first step for EVPN configuration and there is a 1:1 relationship between tenant and VRF.
To enable layer-2 connectivity, we need a special interface to route between layer-2 networks. This interface is called Switched VLAN Interface (SVI). The SVI is realized with a VLAN. It is part of a VRF (layer-3).
The VTEP configuration requires the setup of a VXLAN interface. A VLAN aware bridge interconnects the VXLAN interface and the SVI.
Required Interfaces to establish the EVPN control plane:
- VRF: because routing happens in the context of this interface.
- SVI: because remote host routes for symmetric routing are installed over this interface.
- VLAN-aware bridge: because router MAC addresses of remote VTEPs are installed over this interface.
- VXLAN Interface / VXLAN Tunnel Endpoint: because the VRF to layer-3 VNI mapping has to be consistent across all VTEPs)
Picture 3: Required interfaces on the switch to wire up the vrf to swp 1 connectivity with a given vxlan
Integrated routing and bridging (IRB) is the most complex part of EVPN. You could choose between centralized or distributed routing, and between asymmetrical (routing on ingress) or symmetrical (routing on ingress and egress) routing. We expect a lot of traffic within the data center itself which implies the need to avoid zigzag routing. This is why we go with distributed routing model. Further it is recommended to use the symmetric model since it makes the cut in most cases and has advantages in scalability (see "EVPN in the Data Center", Dinesh G. Dutt).
MTU
In a layer-3 network it is important to associate each interface with a proper Maximum Transmission Unit (MTU) to avoid fragmentation of IP packets. Typical modern networks do not fragment IP packets and the introduction of VXLAN adds another additional header to the packets that must not exceed the MTU. If the MTU is exceeded, VXLAN might just fail without error. This already represents a difficult-to-diagnose connectivity issue that has to be avoided.
It is common practice to set the MTU for VXLAN facing interfaces (e.g. inter-switch links) to a value of 9216 to compensate the additional VXLAN overhead and an MTU of 9000 as a default to other interfaces (e.g. server facing ports). The common MTU of 1500 is not sufficient for traffic inside a data center!
VRF
Routing is needed for communication between VXLAN tunnels or between a VXLAN tunnel and an external networks. VXLAN routing supports layer-3 multi-tenancy. All routing occurs in the context of a VRF. There is a 1:1 relation of a VRF to a tenant. Picture 3 illustrates this. Servers A and B belong to the same vrf VRF1. Server C is enslaved into VRF2. There is no communication possible between members of VRF1 and those of VRF2.
Picture 4: Illustration of two distinct routing tables of VRF1 (enslaved: servers A and B) and VRF2 (enslaved: server C)
To leaverage the potential and power of BGP, VRF, EVPN/VXLAN without a vendor lock-in the implementation relies on hardware that is supported by open network operating system: SONiC.
Implementation
Implementation of the network operation requires the data center infrastructure to be in place. To implement a functional meaning for the parts of the CLOS network, all members must be wired accordingly.
Physical Wiring
Reference: See the CLOS overview picture in ./README.md.
| Name | Wiring |
|---|---|
| Tenant server (aka Machine) | Bare metal server that is associated to a tenant. Dual-connected to leafs. |
| Tenant firewall | Bare metal server that is associated to a tenant. Dual-connected to leafs. |
| Leaf | Network Switch that interconnects tenant servers and firewalls. Connected to spines. |
| Spine | Network switch that interconnects leafs and exit switches. |
| Exit | Network switch that connects to spines and interconnects to external networks. |
| Management Server | Jump-host to access all network switches within the CLOS topology for administrative purpose. |
| Management Switch | Connected to the management port of each of the network switches. |
Tenant servers are organized into a layer called projects. In case those tenant servers require access to or from external networks, a new tenant server to function as a firewall is created. Leaf and spine switches form the fundament of the CLOS network to facilitate redundancy, resilience and scalability. Exit switches establish connectivity to or from external networks. Management Switch and Management Server are mandatory parts that build a management network to access the network switches for administration.
To operate the CLOS topology, software defined configuration to enable BGP, VRF, EVPN and VXLAN must be set up.
Network Operating Systems
SONiC as the network operating system will be installed on all network switches (leaves, spines, exit switches) within the CLOS topology. SONiC cannot be installed on bare metal servers that require BGP/EVPN but does not have a switching silicon.
Components without a switching silicon are:
- tenant servers
- tenant firewalls
- management server
There exist two paradigms to use BGP and/or VXLAN/EVPN on non switching bare metal servers: BGP-to-the-host and EVPN-to-the-host. Both describe a setup of Free Range Routing Framework (see frrouting.org) and its configuration. FRR seamlessly integrates with the native Linux IP networking stacks.
Starting with an explanation of the tenant server's BGP-to-the-Host helps to get an insight into the setup of the CLOS network from a bottom-up perspective.
Tenant Servers: BGP-to-the-Host
Tenant servers are dual-connected to leaf switches. To communicate with other servers or reach out to external networks they must join a BGP session with each of the leaf switches. Thus, it is required to bring BGP to those hosts (aka BGP-to-the-Host). Each tenant server becomes a BGP router (aka BGP speaker).
BGP-to-the-Host is established by installing and configuring FRR. The required FRR configuration for tenant servers is limited to a basic setup to peer with BGP next-hops:
# /etc/network/interfaces
+
+auto lo
+iface lo inet static
+ address 10.0.0.1/32
+
+auto lan0
+iface lan0 inet6 auto
+ mtu 9000
+
+auto lan1
+iface lan1 inet6 auto
+ mtu 9000Listing 1: Network interfaces of a tenant server.
Listing 1 shows the local interfaces configuration. lan0 and lan1 connect to the leaves. As described, there is no IPv4 address assigned to them (BGP unnumbered). The local loopback has an IPv4 address assigned that is announced by BGP.
The required BGP configuration:
# /etc/frr/frr.conf
+
+frr version 7.0
+frr defaults datacenter
+log syslog debugging
+service integrated-vtysh-config
+!
+interface lan0
+ ipv6 nd ra-interval 6
+ no ipv6 nd suppress-ra
+!
+interface lan1
+ ipv6 nd ra-interval 6
+ no ipv6 nd suppress-ra
+!
+router bgp 4200000001
+ bgp router-id 10.0.0.1
+ bgp bestpath as-path multipath-relax
+ neighbor TOR peer-group
+ neighbor TOR remote-as external
+ neighbor TOR timers 1 3
+ neighbor lan0 interface peer-group TOR
+ neighbor lan1 interface peer-group TOR
+ neighbor LOCAL peer-group
+ neighbor LOCAL remote-as internal
+ neighbor LOCAL timers 1 3
+ neighbor LOCAL route-map local-in in
+ bgp listen range 10.244.0.0/16 peer-group LOCAL
+ address-family ipv4 unicast
+ redistribute connected
+ neighbor TOR route-map only-self-out out
+ exit-address-family
+!
+bgp as-path access-list SELF permit ^$
+!
+route-map local-in permit 10
+ set weight 32768
+!
+route-map only-self-out permit 10
+ match as-path SELF
+!
+route-map only-self-out deny 99
+!Listing 2: FRR configuration of a tenant server.
The frr configuration in Listing 2 starts with frr defaults datacenter. This is a marker that enables compile-time provided settings that e.g. set specific values for BGP session timers. This is followed by a directive to state that instead of several configuration files for different purposes a single frr.conf file is used: service integrated-vtysh-config. The two interface specific blocks starting with interface ... enable the RA mechanism that is required for BGP unnumbered peer discovery. There is a global BGP instance configuration router bgp 4200000001 that sets the private ASN. The BGP router configuration contains a setup that identifies the BGP speaker bgp router-id 10.0.0.1. This router id should be unique. It is a good practice to assign the local loopback IPv4 as router-id. To apply the same configuration to several interfaces a peer group named TOR is defined via neighbor TOR peer-group. remote-as external activates external BGP for this peer group. To have a fast convergence, limits of default timers are reduced by timer 1 3 section. The two BGP-peer-facing interfaces are enslaved into the peer-group to inherit the peer-group's setup. Activation of IPv4 unicast protocol is completed with address-family ipv4 unicast. To prevent a tenant server from announcing other paths than lo interface a route-map only-self-out is defined. This route map is activated within the ipv4 address family: neighbor TOR route-map only-self-out out.
Application of the route map only-self-out enables to announce only local ip(s). This is to avoid that a tenant server announces paths to other servers (prevents unwanted traffic). To achieve this:
the route-map named
only-self-outpermits only matches against an access list namedSELFaccess list
SELFpermits only empty path announcementsthe path of the tenant server itself has no ASN. It is always empty (see line
*> 10.0.0.2/32 0.0.0.0 0 32768 ?):root@machine:~# vtysh -c 'show bgp ipv4 unicast' +BGP table version is 7, local router ID is 10.0.0.2, vrf id 0 +Default local pref 100, local AS 4200000002 +Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, + i internal, r RIB-failure, S Stale, R Removed +Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self +Origin codes: i - IGP, e - EGP, ? - incomplete + + Network Next Hop Metric LocPrf Weight Path +*= 0.0.0.0/0 lan1 0 4200000012 4200000040 i +*> lan0 0 4200000011 4200000040 i +*= 10.0.0.1/32 lan1 0 4200000012 4200000001 ? +*> lan0 0 4200000011 4200000001 ? +*> 10.0.0.2/32 0.0.0.0 0 32768 ? +*= 10.0.0.78/32 lan1 0 4200000012 4200000001 ? +*> lan0 0 4200000011 4200000001 ? + +Displayed 4 routes and 7 total pathsThat is why only the self ip (loopback ip) is announced.
To allow for peering between FRR and other routing daemons on a tenant server a listen range is specified to accept iBGP sessions on the network 10.244.0.0/16. Therewith it gets possible that pods / containers like metal-lb with IPs of this range may peer with FRR.
This is the only place where we use iBGP in our topology. For local peering this has the advantage, that we don't need an additional ASN that has to be handled / pruned in the AS-path of routes. Routes coming from other routing daemons look as if they are configured on the tenant server's lo interface from the viewpoint of the leaves. iBGP routes are differently handled than eBGP routes in BGPs best path algorithm. Generally BGP has the rule to prefer eBGP routes over iBGP routes (s. 'eBGP over iBGP' ). BGP adds automatically an weight based on the route type. To overcome this issue, we set the weight of iBGP routes to the same weight that eBGP routes have, namely 32768 (set weight 32768). Without this configuration we will only get a single route to the IPs announced via iBGP. So this setting is essential for HA/failover!
Statistics of the established BGP session can be viewed locally from the tenant server via: sudo vtysh -c 'show bgp ipv4 unicast'
To establish this BGP session a BGP setup is required on the leaves as well.
Leaf Setup
Every leaf switch is connected to every spine switch. Tenant servers can be distributed within the data center and thus be connected to different leaves. Routing for tenant servers is isolated in unique VRFs. These constraints imply several configuration requirements for the leaf and spine switches:
- leaves define tenant VRFs
- leaves terminate VXLAN tunnels (aka "VXLAN tunnel endpoint" = VTEP)
The leaf setup requires the definition of a tenant VRF that enslaves the tenant server facing interfaces:
# /etc/network/interfaces
+
+# [...]
+
+iface vrf3981
+ vrf-table auto
+
+iface swp1
+ mtu 9000
+ post-up sysctl -w net.ipv6.conf.swp1.disable_ipv6=0
+ vrf vrf3981
+
+# [...]Listing 3: Fragment that shows swp1 being member of vrf vrf3981.
There is a VRF definition iface vrf3981 to create a distinct routing table and a section vrf vrf3981 that enslaves swp1 (connects the tenant server) into the VRF. Those host facing ports are also called edge ports.
Unfortunately, due to a kernel bug, IPv6 is not reliably enabled, so it is enforced explicitly via post-up sysctl -w net.ipv6.conf.swp1.disable_ipv6=0. If this post-up trigger is missing the LLA of the interface might be absent.
Additional to the VRF definition the leaf must be configured to provide and connect a VXLAN interface to establish a VXLAN tunnel. This network virtualization begins at the leaves. Therefore, the leaves are also called Network Virtualization Edges (NVEs). The leaves encapsulate and decapsulate VXLAN packets.
# /etc/network/interfaces
+
+# [...]
+
+iface bridge
+ bridge-ports vni3981
+ bridge-vids 1001
+ bridge-vlan-aware yes
+
+iface vlan1001
+ mtu 9000
+ vlan-id 1001
+ vlan-raw-device bridge
+ vrf vrf3981
+
+iface vni3981
+ mtu 9000
+ bridge-access 1001
+ bridge-arp-nd-suppress on
+ bridge-learning off
+ mstpctl-bpduguard yes
+ mstpctl-portbpdufilter yes
+ vxlan-id 3981
+ vxlan-local-tunnelip 10.0.0.11
+
+# [...]Listing 4: Fragment that shows VXLAN setup for vrf vrf3981.
All routing happens in the context of the tenant VRF. To send and receive packets of a VRF, several interface are in place.
A bridge is used to attach VXLAN interface bridge-ports vni3981 and map its local VLAN to a VNI. Router MAC addresses of remote VTEPs are installed over this interface.
The Routed VLAN Interface or Switched Virtual Interface (SVI) iface vlan1001 is configured corresponding to the per-tenant VXLAN interface. It is attached to the tenant VRF. Remote host routes are installed over this SVI. The vlan-raw-device bridge is used to associate the SVI with the VLAN aware bridge. For a packet received from a locally attached host the SVI interface corresponding to the VLAN determines the VRF vrf vrf3981.
The VXLAN interface iface vni3981 defines a tunnel address that is used for the VXLAN tunnel header vlxan-local-tunnelip 10.0.0.11. This VTEP IP address is typically the loopback device address of the switch. When EVPN is provisioned, data plane MAC learning for VXLAN interfaces must be disabled because the purpose of EVPN is to exchange MACs between VTEPs in the control plane: bridge-learning off. EVPN is responsible for installing remote MACs. bridge-arp-nd-suppress suppresses ARP flooding over VXLAN tunnels. Instead, a local proxy handles ARP requests received from locally attached hosts for remote hosts. ARP suppression is the implementation for IPv4; ND suppression is the implementation for IPv6. It is recommended to enable ARP suppression on all VXLAN interfaces. Bridge Protocol Data Unit (BPDU) are not transmitted over VXLAN interfaces. So as a good practice bpduguard and pbdufilter are enabled with mstpctl-bpduguard yes and mstpctl-portbpdufilter yes. These settings filter BPDU and guard the spanning tree topology from unauthorized switches affecting the forwarding path. vxlan-id 3981 specifies the VXLAN Network Identifier (VNI). The type of VNI can either be layer-2 (L2) or layer-3 (L3). This is an implicit thing. A VNI is a L3 VNI (L3VNI) when a mapping exists that maps the VNI to a VRF (configured in /etc/frr/frr.conf) otherwise it is a L2 VNI (L2VNI).
# /etc/frr/frr.conf
+# [...]
+vrf vrf3981
+ vni 3981
+ exit-vrf
+#[...]
+router bgp 4200000011
+# [...]
+ address-family ipv4 unicast
+ redistribute connected route-map LOOPBACKS
+ # [...]
+ address-family l2vpn evpn
+ neighbor FABRIC activate
+ advertise-all-vni
+ exit-address-family
+# [...]
+router bgp 4200000011 vrf vrf3981
+ # [...]
+ address-family ipv4 unicast
+ redistribute connected
+ neighbor MACHINE maximum-prefix 100
+ exit-address-family
+ !
+ address-family l2vpn evpn
+ advertise ipv4 unicast
+ exit-address-family
+
+# [...]
+route-map LOOPBACKS permit 10
+ match interface lo
+# [...]Listing 5: Leaf FRR configuration.
Listing 5 shows the required FRR configuration of the BGP control plane. Only content not discussed so far is explained. The section vrf vrf3981 contains the mapping from layer-3 VNI to VRF. This is required to be able to install EVPN IP prefix routes (type-5 routes) into the routing table. Further the file contains a global BGP instance router bgp 4200000011 definition. A new setting redistribute connected route-map LOOPBACKS is in place to filter the redistribution of routes that are not matching the local loopback interface. The route-map is defined with route-map LOOPBACKS permit 10. With the configuration line address-family l2vpn evpn, the EVPN address family is enabled between BGP neighbours. advertise-all-vni makes the switch a VTEP configures it in such a way, that all locally configured VNIs should be advertised by the BGP control plane.
The second BGP instance configuration is specific to the tenant VRF router bgp 4200000011 vrf vrf3981. This VRF BGP instance configures the l2vpn evpn address family with advertise ipv4 unicast to announce IP prefixes in BGP's routing information base (RIB). This is required to apply learned routes to the routing tables of connected hosts. The Maximum-Prefix feature is useful to avoid that a router receives more routes than the router memory can take. The maximum number of prefixes a tenant server is allowed to announce is limited to 100 with: neighbor MACHINE maximum-prefix 100.
Spine setup
On the spine switches the setup is quite simple. /etc/network/interfaces contains the loopback interface definition to support BGP unnumbered and listings for connected switch ports to provide proper MTUs (Listing 6). I.e. swp1 is configured with an MTU of 9216 as it is a VXLAN-facing interface.
# /etc/network/interfaces
+# [...]
+iface swp1
+ mtu 9216Listing 6: Fragment of spine interface configuration.
The spines are important to forward EVPN routes and transport VXLAN packets between the VTEPs. They are not configured as VTEPs. The FRR configuration only contains the already known global BGP instance configuration router bgp 4200000020 plus the activation of the l2vpn evpn address family address-family l2vpn evpn to enable EVPN type-5 route forwarding (Listing 7).
hostname spine01
+username admin nopassword
+!
+# [...]
+interface swp1
+ ipv6 nd ra-interval 6
+ no ipv6 nd suppress-ra
+!
+# [...]
+!
+router bgp 4200000020
+ # [...]
+!
+ address-family l2vpn evpn
+ neighbor FABRIC activate
+ exit-address-family
+!
+# [...]Listing 7: Fragment of spine FRR configuration to show the activated L2VPN EVPN address-family.
Tenant Firewalls: EVPN-to-the-Host
In case a tenant server needs to reach out to external networks as the Internet, a tenant firewall is provisioned. The firewall is a bare metal server without a switching silicon. Thus, there is no installation of SONiC. FRR provides the BGP / EVPN functionality known as EVPN-to-the-host. The firewall is configured as a VTEP and applies dynamic route-leaking to install routes of an foreign VRF. The set of routes that are leaked are restricted with route-maps.
As Listing 8 shows, the firewall is configured with VXLAN interfaces as known from the leaf setup. Additionally, a VXLAN setup for VRF vrfInternet is added to provide Internet access. vrfInternet contains a route to the Internet that will be leaked into the tenant VRF.
Traffic that originates from the tenant network 10.0.0.0/22 will be masqueraded before leaving the interface vlanInternet towards the internet.
# /etc/network/interfaces
+# [...]
+iface bridge
+# [...]
+iface vlan1001
+# [...]
+iface vni3981
+# [...]
+iface vrf3981
+# [...]
+iface vlanInternet
+ mtu 9000
+ vlan-id 4009
+ vlan-raw-device bridge
+ vrf vrfInternet
+ address 185.1.2.3
+ post-up iptables -t nat -A POSTROUTING -s 10.0.0.0/22 -o vlanInternet -j MASQUERADE
+ pre-down iptables -t nat -D POSTROUTING -s 10.0.0.0/22 -o vlanInternet -j MASQUERADE
+
+iface vniInternet
+ mtu 9000
+ bridge-access 4009
+ mstpctl-bpduguard yes
+ mstpctl-portbpdufilter yes
+ vxlan-id 104009
+ vxlan-local-tunnelip 10.0.0.40
+
+iface vrfInternet
+ mtu 9000
+ vrf-table autoListing 8: Interfaces configuration of firewall to show the VTEP interface configuration.
To install a default route into the routing table of tenant VRF vrf3981 a dynamic route leak is established for it (import vrf vrfInternet). With the help of a route-map import vrf route-map vrf3981-import-map only the default route will be leaked:
root@firewall01:~# vtysh -c 'show ip route vrf vrf3981'
+# [...]
+VRF vrf3981:
+S>* 0.0.0.0/0 [1/0] is directly connected, vrfInternet(vrf vrfInternet), 03:19:26
+B>* 10.0.0.1/32 [20/0] via 10.0.0.12, vlan1001 onlink, 02:34:48
+ * via 10.0.0.11, vlan1001 onlink, 02:34:48
+B>* 10.0.0.2/32 [20/0] via 10.0.0.12, vlan1001 onlink, 02:34:49
+ * via 10.0.0.11, vlan1001 onlink, 02:34:49To receive responses from vrfInternet in vrf3981 a route is leaked into vrfInternet as well (import vrf vrf3981) restricted with the route-map vrfInternet-import-map that allows leaking of the tenant routes as well as internet prefixes used on worker nodes of the tenant. To limit the prefixes that are announced from the firewall within the global BGP instance a route-map only-self-out is defined and applied within the ipv4 and l2vpn evpn address family. Together with the definition of an as path access list bgp as-path access-list it avoids the announcement of prefixes to non VRF BGP peers.
# /etc/frr/frr.conf
+!
+vrf vrf3981
+ vni 3981
+!
+vrf vrfInternet
+ vni 104009
+!
+# [...]
+!
+router bgp 4200000040
+ # [...]
+ !
+ address-family ipv4 unicast
+ # [...]
+ neighbor FABRIC route-map only-self-out out
+ exit-address-family
+ !
+!
+router bgp 4200000040 vrf vrf3981
+ # [...]
+ address-family ipv4 unicast
+ redistribute connected
+ import vrf vrfInternet
+ import vrf route-map vrf3981-import-map
+ # [...]
+ address-family l2vpn evpn
+ advertise ipv4 unicast
+ # [...]
+router bgp 4200000040 vrf vrfInternet
+ # [...]
+ address-family ipv4 unicast
+ redistribute connected
+ import vrf vrf3981
+ import vrf route-map vrfInternet-import-map
+ # [...]
+ address-family l2vpn evpn
+ advertise ipv4 unicast
+ # [...]
+ bgp as-path access-list SELF permit ^$
+!
+route-map only-self-out permit 10
+ match as-path SELF
+!
+route-map only-self-out deny 99
+!
+route-map LOOPBACKS permit 10
+ match interface lo
+!
+ip prefix-list vrf3981-import-prefixes seq 100 permit 0.0.0.0/0
+!
+route-map vrf3981-import-map permit 10
+ match ip address prefix-list vrf3981-import-prefixes
+!
+route-map vrf3981-import-map deny 99
+!
+ip prefix-list vrfInternet-import-prefixes seq 100 permit 10.0.0.0/22 le 32
+ip prefix-list vrfInternet-import-prefixes seq 101 permit 185.1.2.0/24 le 32
+ip prefix-list vrfInternet-import-prefixes seq 102 permit 185.27.0.0/27 le 32
+!
+route-map vrfInternet-import-map permit 10
+ match ip address prefix-list vrfInternet-import-prefixes
+!
+route-map vrfInternet-import-map deny 99
+!
+line vty
+!Listing 9: FRR configuration of a tenant firewall to show route leak and prefix announcement filtering.
Exit Switch
Traffic to external networks is routed via the firewalls to the exit switch. The exit switch, as an exception, connects to the Internet Service Provider using numbered BGP. Numbered BGP implies to assign IPv4 addresses to network interfaces (See Listing 10, swp1). Interface swp1 is enslaved into vrf vrfInternet to include the port that is connected to the ISP within the VRF that is expected to contain a way into the Internet. The exit switch is configured to be a VTEP to terminate traffic coming from the firewall VRF vrfInternet.
# /etc/network/interfaces
+# [...]
+iface swp1
+ mtu 9000
+ vrf vrfInternet
+ address 172.100.0.2/30
+# [...]
+iface vlan4000
+ mtu 9000
+ address 10.0.0.71/24
+ vlan-id 4000
+ vlan-raw-device bridge
+# [...]
+iface vlanInternet
+# [...]
+iface vniInternet
+# [...]
+iface vrfInternet
+# [...]Listing 10: Fragment of interfaces configuration of exit switch.
The configuration of FRR is equivalent to the previously discussed ones. It contains a global BGP instance configuration that enables IPv4 unicast and l2vpn evpn address families. The vrfInternet BGP instance defines neighbor 172.100.0.1 peer-group INTERNET to use "old style BGP" transit network.
# [..]
+vrf vrfInternet
+ vni 104009
+!
+# [...]
+router bgp 4200000031
+ bgp router-id 10.0.0.31
+ neighbor FABRIC peer-group
+ neighbor FABRIC remote-as external
+ neighbor FABRIC timers 1 3
+ # [...]
+ !
+ address-family ipv4 unicast
+ neighbor FABRIC activate
+ redistribute connected route-map LOOPBACKS
+ exit-address-family
+ !
+ address-family l2vpn evpn
+ neighbor FABRIC activate
+ advertise-all-vni
+ exit-address-family
+!
+router bgp 4200000031 vrf vrfInternet
+ bgp router-id 10.0.0.31
+ bgp bestpath as-path multipath-relax
+ neighbor INTERNET peer-group
+ neighbor INTERNET remote-as external
+ neighbor INTERNET timers 1 3
+ neighbor 172.100.0.1 peer-group INTERNET
+ !
+ address-family ipv4 unicast
+ neighbor INTERNET route-map PREPEND-PATH-TO-DISFAVOR-IN in
+ neighbor INTERNET route-map PREPEND-PATH-TO-DISFAVOR-OUT out
+ exit-address-family
+
+ !
+ address-family l2vpn evpn
+ advertise ipv4 unicast
+ exit-address-family
+!
+route-map LOOPBACKS permit 10
+ match interface lo
+!
+route-map PREPEND-PATH-TO-DISFAVOR-IN permit 10
+ set as-path prepend last-as 2
+!
+route-map PREPEND-PATH-TO-DISFAVOR-OUT permit 10
+ set as-path prepend last-as 2
+!
+vrf mgmt
+ ip route 10.0.0.0/24 10.0.0.71 nexthop-vrf default
+ exit-vrf
+!
+ip route 0.0.0.0/0 192.168.0.254 nexthop-vrf mgmt
+!
+line vty
+!Listing 11: Fragment of FRR configuration on exit switch to give an example for numbered BGP and route leak.
In addition to the standard BGP setup the exit switches have configured static route leak to support internet access during PXE. There is one route leak from default VRF into the mgmt VRF defined with: ip route 0.0.0.0/0 192.168.0.254 nexthop-vrf mgmt and another one from mgmt VRF into the default VRF: ip route 10.0.0.0/24 10.0.0.71 nexthop-vrf default. The first one adds a default route into the default VRF and the second one routes traffic destined to the PXE network back from mgmt VRF into the default VRF.
To reach out into external networks each of the exit nodes joins a BGP session with a distinct external router. There is a different latency to each of these routers. To favor routes of exit nodes connected with lower latency over exit nodes with higher latency two route maps PREPEND-PATH-TO-DISFAVOR-IN and PREPEND-PATH-TO-DISFAVOR-OUT are added to high latency exit nodes. These route maps apply actions to prolong the path of the incoming and outgoing routes. Because of this path extension BGP will calculate a lower weight for these paths and favors paths via other exit nodes. It is important to know that within an address family only one route map (the last) will be applied. To apply more than one actions within a route-map the required entries can be applied to a single route-map.
PXE Boot Mode
Before a bare metal server can act as tenant server or tenant firewall, it has to be provisioned. Within the Metal domain, this provisioning mode is called "PXE Mode" since it is based on Preboot eXecution Environment (PXE). PXE uses protocols like DHCP. This requires all bare metal servers that need provisioning to be located in a layer-2 domain where DHCP is available. This domain is a VLAN vlan4000. A DHCP server for PXE Mode is installed on the exit switches to work in this specific VLAN.
# /etc/default/isc-dhcp-server
+INTERFACES="vlan4000"Listing 13: DHCP server configuration of exit switches.
As shown in listing 13, the PXE DHCP server is located on the exit switches and enforced to bind to interface vlan4000. This represents a layer-2 separation that allows only DHCP clients in the same VLAN to request IP addresses. Only unprovisionned bare metal servers are configured to be member of this VLAN. Thus unwanted or accidental provisionning is impossible.
To provide vlan4000 on the leaves (that face the bare metal servers) the exit and leaf switches are configured as VTEPs and share an interface configuration that contains the required interfaces (Listing 13). Since no EVPN routing is in place vni104000 is configured as an L2 VNI (there is no mapping for this VNI in /etc/frr/frr.conf).
# /etc/network/interfaces
+# [...]
+iface bridge
+ bridge-ports vni104000 [...]
+ bridge-vids 4000 [...]
+ bridge-vlan-aware yes
+
+iface vlan4000
+# [...]
+
+iface vni104000
+# [...]Listing 13: Interfaces configuration on exit and leaf switches to show DHCP/PXE related fragments.
On the leaf switches the bare metal server facing ports are configured as VLAN access ports to carry the traffic for only the PXE VLAN vlan4000 (listing 14)to separate unprovisioned from other bare metal servers.
# /etc/network/interfaces
+# [...]
+auto swp1
+iface swp1
+ mtu 9000
+ bridge-access 4000
+# [...]Listing 14: VLAN access setup for bare metal server facing ports on leaves.
Once a bare metal server is provisioned it is deconfigured from PXE VLAN vlan4000 to avoid accidental or unwanted provisioning.
During provisioning bare metal servers get internet access via the management network of the exit switches. This is because the exit switches are announced as DHCP gateway to the DHCP clients.
Management Network
To manage network switches beside the out-of-band system console access a further management access is required. For this purpose the concept of Management VRF is applied. The Management VRF is a subset of VRF. It provides a separation between out-of-band management network and the in-band data plane network by introducing another routing table mgmt. SONiC supports eth0 to be used as the management interface.
To enable and use the Management VRF all switches have to be connected via their eth0 interface to a management-switch. The management switch is connected to a management server. All access is established from within the management server. Logins to the switch are set into the Management VRF context once the Management VRF is enabled.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Operating Systems
Our operating system images are built on regular basis from the metal-images repository.
All images are hosted on GKE at images.metal-stack.io. Feel free to use this as a mirror for your metal-stack partitions if you want. The metal-stack developers continuously have an eye on the supported images. They are updated regularly and scanned for vulnerabilities.
Supported OS Images
The operating system images that we build are trimmed down to their bare essentials for serving as Kubernetes worker nodes. Small image sizes make machine provisioning blazingly fast.
The supported images for worker nodes currently are:
| Platform | Distribution | Version |
|---|---|---|
| Linux | Debian | 11 |
| Linux | Ubuntu | 22.04 |
The supported images for firewalls are:
| Platform | Distribution | Version | Based On |
|---|---|---|---|
| Linux | Ubuntu | 3 | 22.04 |
Building Your Own Images
It is fully possible to build your own operating system images and provide them through the metal-stack.
There are some conventions though that you need to follow in order to make your image installable through the metal-hammer. You should understand the machine provisioning sequence before starting to write your own images.
- Images need to be compressed to a tarball using the lz4 compression algorithm
- An
md5checksum file with the same name as the image archive needs to be provided in the download path along with the actual os image - A
packages.txtcontaining the packages contained in the OS image should be provided in the download path (not strictly required) - Consider semantic image versioning, which we use in our algorithms to select latest images (e.g.
os-major.minor.patch➡️ubuntu-19.10.20191018) - Consider installing packages used by the metal-stack infrastructure
- FRR to enable routing-to-the-host in our network topology
- go-lldpd to enable checking if the machine is still alive after user allocation
- ignition for enabling users to run user-specific initialization instructions before bootup. It's pretty small in size, which is why we use it. However, you are free to use other cloud instance initialization tools if you want to.
- You have to provide an
install.shscript, which applies user-specific configuration in the installed image- This script should consume parameters from the
install.yamlfile that the metal-hammer writes to/etc/metal/install.yaml - Please check this contract between image and the metal-hammer here
- This script should consume parameters from the
- For the time being, your image must be able to support kexec into the new operating system kernel, the
kexeccommand is issued by the metal-hammer after running theinstall.sh. We do this becausekexecis much faster than rebooting a machine. - We recommend building images from Dockerfiles as it is done in metal-images repository.
Building own operating system images is an advanced topic. When you have just started with metal-stack, we recommend using the public operating system images first.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Storage
When working with bare-metal servers, providing cloud storage is a challenge. With physical machines there is no opportunity that a hypervisor can mount storage devices into the servers and thus, we have to implement other mechanisms that are capable of dynamically mounting storage onto the machines.
In the meantime, we have started to integrate third-party solutions into our metal-stack landscape. They help us to provide modern, well-integrated and scalable storage solutions to our end-users.
Lightbits Labs NVMe over TCP Storage Integration
Lightbits Labs offers a proprietary implementation of persistent storage using NVMe over TCP. The solution has some very superior traits that fit very well to metal-stack. The strongest advantages are:
- High performance
- Built-in multi-tenant capabilities
- Configurable compression and replication factors
We are maintaining an open source integration for running LightOS in our Gardener cluster provisioning. You can enable it through the controller registration of the gardener-extension-provider-metal.
With the integration in place, the extension-provider deploys a duros-controller along with a Duros Storage CRD into the seed's shoot namespace. The duros-controller takes care of creating projects and managing credentials at the Lightbits Duros API. It also provides storage classes as configured in the extension-provider's controller registration to the customer's shoot cluster such that users can start consuming the Lightbits storage immediately.
Simple Node Local Storage with csi-driver-lvm
If you wish to quickly start off with cluster provisioning without caring so much about complex cloud storage solutions, we recommend using a small storage driver we wrote called csi-driver-lvm. It provides a storage class that manages node-local storage through LVM.
A definition of a PVC can look like this:
apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+ name: csi-pvc
+spec:
+ accessModes:
+ - ReadWriteOnce
+ resources:
+ requests:
+ storage: 100Mi
+ storageClassName: csi-lvm-sc-linearThe solution does not provide cloud-storage or whatsoever, but it improves the user's accessibility of local storage on bare-metal machines through Kubernetes. Check out the driver's documentation here.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
Getting Started
Before starting to buy any hardware, you should try out the metal-stack on your notebook and familiarize with the software.
For this, we made the mini-lab.
The mini-lab is a fully virtual setup of metal-stack and is supposed to be run locally on a single machine. For this reason, the setup was slightly simplified in comparison to full-blown setups on real hardware. However, the lab should help to understand all ideas behind the metal-stack.
Get your hands dirty and follow the guide on how to get on with the mini-lab here.
Settings
This document was generated with Documenter.jl version 1.3.0 on Tuesday 19 November 2024. Using Julia version 1.9.4.
\n\n
","category":"page"},{"location":"overview/architecture/#Offline-Resilience","page":"Architecture","title":"Offline Resilience","text":"","category":"section"},{"location":"overview/architecture/","page":"Architecture","title":"Architecture","text":"It is possible to use metal-stack without any external network dependencies by integrating your own DNS and NTP configuration into the stack. This feature is great for workloads requiring strong independence and reliability. Even in case of an internet connection failure, your infrastructure remains operational. Existing machines do not encounter any downtime as well as new machines can be provisioned. All you need to have in place is a DNS and NTP server configured and accessible for metal-stack.","category":"page"},{"location":"overview/architecture/","page":"Architecture","title":"Architecture","text":"NTP servers need to be configured on the pixiecore and the metal-hammer microservices. This can be achieved by providing a list of NTP servers with the following Ansible variable through metal-roles:","category":"page"},{"location":"overview/architecture/","page":"Architecture","title":"Architecture","text":"pixiecore_metal_hammer_ntp_servers: []","category":"page"},{"location":"overview/architecture/","page":"Architecture","title":"Architecture","text":"In the background, the pixiecore is taking the NTP servers and passing it via the MetalConfig to the metal-hammer. When booting bare-metal servers, the metal-hammer needs to configure NTP servers. It recognises the ones from the MetalConfig and configures itself accordingly. If no NTP servers are passed along, the following standard servers are used:","category":"page"},{"location":"overview/architecture/","page":"Architecture","title":"Architecture","text":"0.de.pool.ntp.org\n1.de.pool.ntp.org\n2.de.pool.ntp.org","category":"page"},{"location":"overview/architecture/","page":"Architecture","title":"Architecture","text":"Moreover, machine and firewall images need to be configured with your custom DNS and NTP servers. The customisation can be made via the fields ntp_servers an dns_servers and specifying a list of servers in the creation request for the machine or firewall.","category":"page"},{"location":"overview/architecture/","page":"Architecture","title":"Architecture","text":"Within a partition default values for DNS and NTP servers can be configured. They are applied to all machines and firewalls within this partition, but can be replaced by specifying different ones inside the machine allocation request.","category":"page"},{"location":"overview/architecture/","page":"Architecture","title":"Architecture","text":"Thus, for creating a partition as well as a machine or a firewall, the flags dnsservers and ntpservers can be provided within the metalctl command.","category":"page"},{"location":"overview/architecture/","page":"Architecture","title":"Architecture","text":"In order to be fully offline resilient, make sure to check out metal-image-cache-sync. This component provides copies of metal-images, metal-kernel and metal-hammer.","category":"page"},{"location":"overview/architecture/","page":"Architecture","title":"Architecture","text":"This feature is related to MEP14.","category":"page"},{"location":"external/metalctl/docs/metalctl_machine_update-firmware_bios/#metalctl-machine-update-firmware-bios","page":"metalctl machine update-firmware bios","title":"metalctl machine update-firmware bios","text":"","category":"section"},{"location":"external/metalctl/docs/metalctl_machine_update-firmware_bios/","page":"metalctl machine update-firmware bios","title":"metalctl machine update-firmware bios","text":"update a machine BIOS","category":"page"},{"location":"external/metalctl/docs/metalctl_machine_update-firmware_bios/#Synopsis","page":"metalctl machine update-firmware bios","title":"Synopsis","text":"","category":"section"},{"location":"external/metalctl/docs/metalctl_machine_update-firmware_bios/","page":"metalctl machine update-firmware bios","title":"metalctl machine update-firmware bios","text":"the machine BIOS will be updated to given revision. If revision flag is not specified an update plan will be printed instead.","category":"page"},{"location":"external/metalctl/docs/metalctl_machine_update-firmware_bios/","page":"metalctl machine update-firmware bios","title":"metalctl machine update-firmware bios","text":"metalctl machine update-firmware bios