New schema for Provider Attributes (JSON-Schema)

[cloud-j-luna]

New schema for Provider Attributes (JSON-Schema)

Provider Attributes

Provider Attributes are currently used to allow users of the Akash Network to check on different attributes of providers. These include the type of hardware, location and supported features. There is currently a spec for provider attributes that is used by cloudmos.io for their UI. This spec lacks formal syntax that can be used by external systems to validate and compute provider attributes.

We believe there should be a formal JSON-Schema that can be used to parse and validate provider attributes. This could be a requirement for providers to be audited and would allow for interoperability between the network and other external systems as they could populate their models based on a formal schema.

Why should you care?

When you have systems that integrate with multiple Akash Providers, defining a Provider Attributes JSON-Schema serves as a structured and standardized way to communicate the capabilities, requirements, and specifications of each Provider to external systems. Here's why it's essential:

• Consistency and Standardization: By using a JSON-Schema, we ensure that the data format and structure for describing each compute provider are consistent across different providers. This standardization simplifies integration efforts and reduces potential errors that might arise due to varied data formats.
• Clarity and Documentation: A well-defined JSON-schema acts as documentation. It provides a clear and detailed description of each provider's attributes, which helps users and developers understand the capabilities and limitations of each Provider without ambiguity.
• Ease of Integration: External systems that want to integrate with the Akash Network can use the JSON-Schema as a reference to understand what information is required or optional when interacting with a specific Provider. This simplifies the integration process and reduces development time.
• Validation and Verification: The JSON-Schema can be used to validate the attributes or configurations provided by external systems against the defined schema. This ensures that the data or configurations meet the required specifications before they are processed or accepted by the network or external systems.
• Flexibility and Scalability: As new Providers are added to the network or existing providers evolve, having a defined JSON-schema makes it easier to incorporate these changes. Instead of ad-hoc or inconsistent updates, you can modify the schema to accommodate new attributes or changes in specifications, ensuring that the integration remains consistent and robust.
• Enhanced Security: By defining clear attributes and specifications, you can enforce security measures and best practices across all integrated compute providers. This helps in identifying potential vulnerabilities or compliance issues and ensures that external systems adhere to the required security standards when interacting with the network.
• Interoperability: A standardized JSON-Schema promotes interoperability among different systems and platforms. External systems can understand and interpret the provider attributes uniformly, regardless of the underlying compute provider, fostering seamless communication and collaboration.

In summary, defining a provider attributes JSON-Schema for external systems integrating with Akash Network providers enhances consistency, clarity, security, and interoperability. It streamlines integration efforts, facilitates understanding, and ensures that all parties involved adhere to standardized practices and specifications.

Draft Proposal

Cloudmos.io's schema provides a great baseline for what could be the formal Provider Attributes Schema.
Below is a starting point for this discussion with comments.

{
  # === General ===
  "host":  "string", # Name of the host. Ex.: 'd3akash.cloud'.
  "email": "string", # Email associated with the provider.
  "organization": "string", # Name of the organization that owns the provider.
  "website": "string", # Link to the organization's website.
  "status-page": "string", # Link to a status page for the provider.
  "certifications": ["string", "string"], # Provider certifications. (LEED, ISO, TIA, Power Usage Effectiveness (PUE), ...)

  # === Location ===
  "location-region": "string", #Geo location region of the provider. Based on the United Nations geoscheme. https://en.wikipedia.org/wiki/United_Nations_geoscheme
  "country": "string", # Country ISO 3166 Alpha-2 code of the provider. https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes
  "city": "string", # City 3 letter code code of the provider. https://www.hh-express.com/en/support/three_code/harbor.html
  "timezone": "string", # Timezone UTC-12 to UTC+14 of the provider. https://www.timeanddate.com/time/map/
  "location-type": "string", # One of: datacenter, colo, home, office, mix.
  "hosting-provider": "string", # Name of the datacenter, colo, public cloud, etc where hosted.

  # === Hardware ===
  "hardware-cpu": "string", # CPU manufacturer.
  "hardware-cpu-arch": "string", # CPU architecture.
  "hardware-gpu": "string", # GPU manufacturer.
  "hardware-gpu-models": ["string", "string"], # GPU models.
  "hardware-disks": ["string", "string"], # Storage type.
  "hardware-memory": ["string", "string"], # Memory (RAM) type.
  "hardware-energy-source": ["string", "string"], # The sources of energy for the provider. (solar, coal, wind, nuclear, mix, unknown, ...)
  "hardware-cooling-systems": ["string", "string"], # The type of cooling system used. (free, air, liquid, ...)


  # === Network ===
  "network-provider": "string", # Internet service provider.
  "network-speed-up": "number", # Upload Bandwidth in mbps.
  "network-speed-down": "number", # Download Bandwidth in mbps.

  # === Features ===
  "feat-persistent-storage": "boolean", # True if the provider offers persistent storage.
  "feat-persistent-storage-type": ["string", "string"], # Type of persistent storage offered.
  "feat-endpoint-ip": "boolean", # Does this provider support leasing of IP addresses?
  "feat-endpoint-custom-domain": "boolean", # Does this provider support custom domains?

This is just a draft proposal for how the Provider Attributes could look like. It's up to the community to discuss and implement the schema. We at Quasarch are committed in moving forward with this initiative as part of the WG-Provider-Attributes.

[piber-dev]

hello @cloud-j-luna, thank you for starting this discussion. i would love to get involved with helping here, giving providers instructions on how to fill these out and possibly create automated steps for both filling them out and verifying them. this will be especially true if the proposal i am part of passes 🤞

[zJuuu]

hey, i really like the idea and think its important to have a schema for this. With a JSON schema its also easy for providers to use/verify valid values.
Will the provider also bid on deployments based on this schema or does it require additional attributes?

[cloud-j-luna]

Thanks! 😄 I think it would need to be up to the tenants to specify a set of attributes that they would want and then a provider would only bid if it matched the requirements of the tenant. But I think that goes a little bit out of the scope of this proposal although it could perfectly be a use of this schema.

The value proposition here is to have the schema defined so that Akash Network could use it for some actions (bidding, filtering, ...) as seen fit at later development, but more directly to be used by third party systems for all the reasons stated in Why should you care.
Whatever tools end up integrating with Akash Network will have a common structure to operate Provider Attributes.