I have this configuration file where dps can have a list of switches (e.g. sw1, sw2, etc) each switch has db_id and list of interfaces as shown below. I want to write a YANG model for this fils.
dps:
<sw1>:
dp_id: <value>
interfaces:
1:
name: <value>
native_vlan: <value>
2:
name: <value>
native_vlan: <value>
<sw2>:
dp_id: <value>
interfaces:
1:
name: <value>
native_vlan: <value>
2:
name: <value>
native_vlan: <value>
I could not find a way to make the inner list name (i.e. sw1, sw2) configurable (i.e. inserted by users). Is it possible or YANG doesn't support that.
Not possible. All list entries have the same name and are uniquely identified via their keys (in JSON encoding, the list is even represented as a single JSON array of objects). You should name your list sw, and have your users configure their name key leaf.
list sw { key name; leaf name { type string; } }
The list's name is the only way to bind an instance (a list entry) to the model definitions.
Related
I've a requirement where I need to re-use my sequence to write register present in different register map, the register name and structure(bit width, field endiness etc) differ in each map but the field name is same. Is there a way, where I can use the field name(string) to get register name or hierarchy in the register map.
Here's some code that gets a register name given a field name:
uvm_field field;
uvm_reg parent_reg;
string parent_reg_name;
field = m_env.m_serial_regmodel.get_field_by_name("TX_DMA_RUN");
parent_reg = field.get_parent;
parent_reg_name = parent_reg.get_name;
// etc
I'm updating my API spec (OAS 3.0.0), and am having trouble understanding how to properly model a "complex" default value.
In general, default values for parameters are scalar values (i.e. the field offset has a default value of 0). But in the API I'm spec'ing, the default value is actually calculated based on other provided parameters.
For example, what if we take the Pet model from the example documentation, and decide that all animals need to be tagged. If the user of the API wants to supply a tag, great. If not, it will be equal to the name.
One possibility:
Pet:
required:
- id
- name
properties:
id:
type: integer
format: int64
name:
type: string
tag:
type: string
default: '#/components/schemas/Pet/name'
This stores the path value as the default, but I'd like to have it explain that the default value will be calculated.
Bonus points if I can encode information from a parent schema.
Is the alternative to just describe the behavior in a description field?
OpenAPI Specification does not support dynamic/conditional defaults. You can only document the behavior verbally in the description.
That said, you can use specification extensions (x-...) to add custom information to your definitions, like so:
tag:
type: string
x-default: name
or
tag:
type: string
x-default:
propertyName: name
# or similar
and extend the tooling to support your custom extensions.
Sorry if this sounds like I'm lazy, but I've search around, around and around, but couldn't find it!
I'm looking for a reference that explains each of the fields that may exist in an OpenShift / Kubernetes template, e.g. what possible values there are.
The templates you get in OpenShift are OpenShift specific and not part of Kubernetes. If you mean the purpose of each of the possible fields you can specify for a parameter, you can run oc explain template. For example:
$ oc explain template.parameters
RESOURCE: parameters <[]Object>
DESCRIPTION:
parameters is an optional array of Parameters used during the Template to
Config transformation.
Parameter defines a name/value variable that is to be processed during the
Template to Config transformation.
FIELDS:
description <string>
Description of a parameter. Optional.
displayName <string>
Optional: The name that will show in UI instead of parameter 'Name'
from <string>
From is an input value for the generator. Optional.
generate <string>
generate specifies the generator to be used to generate random string from
an input value specified by From field. The result string is stored into
Value field. If empty, no generator is being used, leaving the result Value
untouched. Optional. The only supported generator is "expression", which
accepts a "from" value in the form of a simple regular expression
containing the range expression "[a-zA-Z0-9]", and the length expression
"a{length}". Examples: from | value -----------------------------
"test[0-9]{1}x" | "test7x" "[0-1]{8}" | "01001100" "0x[A-F0-9]{4}" |
"0xB3AF" "[a-zA-Z0-9]{8}" | "hW4yQU5i"
name <string> -required-
Name must be set and it can be referenced in Template Items using
${PARAMETER_NAME}. Required.
required <boolean>
Optional: Indicates the parameter must have a value. Defaults to false.
value <string>
Value holds the Parameter data. If specified, the generator will be
ignored. The value replaces all occurrences of the Parameter ${Name}
expression during the Template to Config transformation. Optional.
You can find more information in:
https://docs.openshift.org/latest/dev_guide/templates.html
If that isn't what you mean, you will need to be more specific as to what you mean. If you are talking about fields on any resource object (templates are specific type of resource object in OpenShift), you can use oc explain on any of them, pass the name of the resource type as argument, and then a dotted path as you traverse into fields. If using plain Kubernetes, you can use kubectl explain.
I'm working with some legacy code, that implements a very basic X.509 parser. The code is quite old and I cannot distribute it.
This code reads the standard set of attributes in issuer and subject sequentially and in a specific order. As a basic example:
C=XX, O=MyOrganization, OU=MyOrganizationalUnit,
CN=myCommonName
So it would read the country, then the organization, and then the organizational unit and finally the common name.
I've been reading the standard (https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.4), (see section 4.1.2.4 and 4.1.2.6) and this legacy code somehow works with most certificates.
The question is if this set of attributes must follow a specific order and where it says so or the opposite.
The reason for that specific order is that Distinguished Names (DNs) were defined in the X.500 series of standards. X.500 is about directory services. X.500 directory servers have been mostly replaced by LDAP servers, but X.509, the part of the series that defines certificates, has survived for other purposes.
In a directory tree the most general node is at the top (in your example country) and then narrows down on every level of the tree. A person is usually a leaf in this tree:
C=US
|
O=Example1 ----- O=Example2
| |
OU=OU1-----OU=OU2 ...
| |
CN=XYZ ...
AFAIK X.500 includes some rules that define which attribute type can follow a certain attribute type in the tree, but unfortunately the documents are not freely available.
The order of the relative distinguished names (RDNs) in the subject or issuer DN of a certificate on an ASN.1 level reflects the order in the tree (i.e. top-down):
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER=CountryName (2.5.4.6)
PRINTABLE STRING='US'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER=OrganizationName (2.5.4.10)
PRINTABLE STRING='GeoTrust Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER=CommonName (2.5.4.3)
PRINTABLE STRING='GeoTrust Global CA'
}
}
}
However, for the string representation of a DN there are two standards: OpenSSL shows the attributes by default as they are actually stored in the certificate, while RFC 2253/4514 reverses the order:
... the output consists of the string encodings of each
RelativeDistinguishedName in the RDNSequence (according to Section
2.2), starting with the last element of the sequence and moving
backwards toward the first.
CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US
Also note that there are certificates "in the wild" which have multiple OUs in their DNs or less common attribute types from RFC 4519 like SERIALNUMBER or UID. I have also seen quite a few certificates, where the RDNs were actually encoded in the wrong order.
I am trying to configure and use mongoid for the first time. I have set the mongoid.yml config file simply as:
host: localhost
database: table
and my code:
Mongoid.load!("/mongoid.yml")
class Data
include Mongoid::Document
field :study, type: String
field :nbc_id, type: String
field :short_title, type: String
field :source, type: String
field :start_date, type: Date
end
puts Data.study
I keep getting an error:
NoMethodError at / undefined method `study' for Data:Class
I think it is because I have not specified the collection name which is 'test'. However I can find no examples on how to do this. Do I specify it in the .yml file or in the code. What is the correct syntax. Can anyone point me in the right direction?
Tx.
According to the Mongoid documentation, "Mongoid by default stores documents in a collection that is the pluralized form of the class name. For the following Person class, the collection the document would get stored in would be named people."
http://mongoid.org/docs/documents.html
The documentation goes on to state that Mongoid uses a method called ActiveSupport::Inflector#classify to determine collection names, and provides instructions on how to specify the plural yourself.
Alternatively, you can specify the collection name in your class by including "store_in" in your class definition.
class Data
include Mongoid::Document
store_in :test
Hope this helps!