I'm creating a droplet in DigitalOcean with Pulumi. I have the following code:
name = "server"
droplet = digitalocean.Droplet(
name,
image=_image,
region=_region,
size=_size,
)
The server gets created successfully on DigitalOcean but the name in the DigitalOcean console is something like server-0bbc405 (upon each execution, it's a different name).
Why isn't it just the name I provided? How can I achieve that?
This is a result of auto-naming, which is explained here in the Pulumi docs:
https://www.pulumi.com/docs/intro/concepts/resources/names/#autonaming
The extra characters tacked onto the end of the resource name allow you to use the same "logical" name (your "server") with multiple stacks without risk of a collision (as cloud providers often require resources of the same kind to ba named uniquely). Auto-naming looks a bit strange at first, but it's incredibly useful in practice, and once you start working with multiple stacks, you'll almost surely appreciate it.
That said, you can generally override this name by providing a name in your list of resource arguments:
...
name = "server"
droplet = digitalocean.Droplet(
name,
name="my-name-override", # <-- Override auto-naming
image="ubuntu-18-04-x64",
region="nyc2",
size="s-1vcpu-1gb")
.. which would yield the following result:
+ pulumi:pulumi:Stack: (create)
...
+ digitalocean:index/droplet:Droplet: (create)
...
name : "my-name-override" # <-- As opposed to "server-0bbc405"
...
.. but again, it's usually best to go with auto-naming for the reasons specified in the docs. Quoting here:
It ensures that two stacks for the same project can be deployed without their resources colliding. The suffix helps you to create multiple instances of your project more easily, whether because you want, for example, many development or testing stacks, or to scale to new regions.
It allows Pulumi to do zero-downtime resource updates. Due to the way some cloud providers work, certain updates require replacing resources rather than updating them in place. By default, Pulumi creates replacements first, then updates the existing references to them, and finally deletes the old resources.
Hope it helps!
Related
I'm using conftest for validating policies on Kubernetes manifests.
Below policy validates that images in StatefulSet manifests have to come from specific registry reg_url
package main
deny[msg] {
input.kind == "StatefulSet"
not regex.match("[reg_url]/.+", input.spec.template.spec.initContainers[0].image)
msg := "images come from artifactory"
}
Is there a way to enforce such policy for all kubernetes resources that have image field somewhere in their description? This may be useful for policy validation on all helm chart manifests, for instance.
I'm looking for something like:
package main
deny[msg] {
input.kind == "*" // all resources
not regex.match("[reg_url]/.+", input.*.image) // any nested image field
msg := "images come from artifactory"
}
You could do this using something like the walk built-in function. However, I would recommend against it, because:
You'd need to scan every attribute of every request/resource (expensive).
You can't know for sure that e.g. "image" means the same thing across all current and future resouce manifests, including CRDs.
I'd probably just stick with checking for a match of resource kind here, and include any resource type known to have an image attribute with a shared meaning.
I am experimenting with the automatic validation feature of HAPI-Fhir Server. I am using the hapi-fhir-jpaserver-starter running in a docker container. For compatibility reasons I am forced to stick at DSTU3 for the moment. My observed behavior is the following:
If request-validation is off (controlled via Env variable API_FHIR_VALIDATION_REQUESTSENABLED unset) I can upload ValueSet and StructureDefinition resources. When uploading eg. Patient or Observation resources, I can use the .../$validate REST call to validate the resources. Works as expected.
If request-validation is on (HAPI_FHIR_VALIDATION_REQUESTSENABLED set to true) then uploading of StructureDefinitions which refer to ValueSet resources being present (by binding.valueSetReference) fail with messages like This context is for FHIR version "DSTU3" but the class "org.hl7.fhir.r4.model.ValueSet" is for version "R4". Validation of resources like Patient or Observation being uploaded works as expected. These resources are marked with a reference to my own StructureDefinitions and are validated against them. Resources with errors will not be persisted.
My current workaround is to disable validation, upload ValueSet and StructureDefinition resources. After a restart with HAPI_FHIR_VALIDATION_REQUESTSENABLED=true the server works as expected and correctly validates all resources being uploaded.
Is there a way to either avoid the errors above or prevent StructureDefinition or ValueSet resources from validation for an individual upload-request?
Every help will be appreciated.
-wolfgang
I have 5 controllers in akka-http. Each endpoint has 5 endpoints(routes). Now I need to introduce versioning for those. All endpoints should be prefixed with /version1.
For example if there was an endpoint xyz now it should be /version1/xyz.
One of the ways is to add a pathPrefix But it needs to be added to each controller.
Is there way to add it at a common place so that it appears for all endpoints.
I am using akka-http with scala.
You can create a base route, that accepts paths like /version1/... and refers to internal routes without path prefix.
val version1Route = path("xyz") {
...
}
val version2Route = path("xyz") {
...
}
val route = pathPrefix("version1") {
version1Route
} ~ pathPrefix("version2") {
version2Route
}
Indirect Answer
Aleksey Isachenkov's answer is the correct direct solution.
One alternative is to put versioning in the hostname instead of the path. Once you have "version1" of your Route values in source-control then you can tag that checkin as "version1", deploy it into production, and then use DNS entries to set the service name to version1.myservice.com.
Then, once newer functionality becomes necessary you update your code and tag it in source-control as "version2". Release this updated build and use DNS to set the name as version2.myservice.com, while still keeping the version1 instance running. This would result in two active services running independently.
The benefits of this method are:
Your code does not continuously grow longer as new versions are released.
You can use logging to figure out if a version hasn't been used in a long time and then just kill that running instance of the service to End-Of-Life the version.
You can use DNS to define your current "production" version by having production.myservice.com point to whichever version of the service you want. For example: once you've released version24.myservice.com and tested it for a while you can update the production.myservice.com pointer to go to 24 from 23. The old version can stay running for any users that don't want to upgrade, but anybody who wants the latest version can always use "production".
In many of the calls described in the Azure DevOps REST API documentation, I need to supply the name of the organization, e.g.:
https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases?api-version=5.0-preview.8
The project I can get from System.TeamProject. I would have expected something similar for organization name, something like:
System.TeamFoundationCollectionName
This does not seem to be available. I've even printed out all of my environment variables on the agent and don't see anything that fits the need exactly. Sure, I can parse it out of one of the other values, but this seems fragile since MS seems to like to change the format of URLs.
I also can't hard code the organization name because this release definition will live in multiple organizations and we don't want to have to manually update it for each. How are others solving this problem?
Try using System.TeamFoundationServerUri and System.TeamFoundationCollectionUri to build your API requests. They have the organization included in them.
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/variables?view=vsts&tabs=batch
edit: SYSTEM_TEAMFOUNDATIONSERVERURI/BUILD_PROJECTNAME/_apis/release/releases?api-version=5.0-preview.8
It looks like currently there is no such variable for the organization, also, the variables return the old URL (xxx.visualstudio.com) and not the new URL (dev.azure.com/xxx) so if you use the System.TeamFoundationCollectionName the API should work without the {organization}:
https://System.TeamFoundationCollectionName/{project}/_apis/release/releases?api-version=5.0-preview.8.
In Powershell, do this:
# Where SYSTEM_TEAMFOUNDATIONCOLLECTIONURI=https://some_org_name.visualstudio.com/
([System.Uri]$Env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI).Host.split('.')[-3] # returns 'some_org_name'
Now, just assign that to a variable and use it anywhere you like. "SYSTEM_TEAMPROJECT" is the Project Name, so no need to do any parsing there. It is already available.
From Moodle doc:
A context is a space in Moodle where roles can be assigned.
I understand that a context is a logical space used to manage Moodle objects.
I developed a custom block plugin with a file upload where I use file_prepare_draft_area andfile_save_draft_area_files functions.There is a $context parameter that must be passed and I am don't really know what context should I pass ?
This mean, I guess, in which logical space should I put my block plugin uploaded files ?
In my opinion, the most logical would be store the uploaded files in a context related to my block plugin.
I tried to use context_block::instance($instanceid) but I don't know how to get $instanceid param.
Which context should I use in this case?
How to get it?
The types of context are as follows:
System
Course category
Course
Activity module
Block
User
The hierarchy of contexts are:
System => Course category => Course => Activity module
Block contexts can appear within courses or within the 'site' course.
User contexts are outside of courses.
If you want the files tied to a specific instance of the block (e.g. so they are deleted automatically when the block is deleted and you can keep the files from different instances of the block separate), then you should use the block context (but you'll have to pass the instanceid of the block to the sub-pages in order to use this to get the context:
$context = context_block::instance($blockinstanceid);
If you want the files tied to the course - so all instances of the block in the course share the same file space and the files are only deleted when the whole course is deleted, then use the course context (pass the courseid into the subpages, as a param, then use:
$context = context_course::instance($courseid);
If, however, you want to share that file area across all blocks on the site, then the system context is what you want:
$context = context_system();
There is also a piece of (old?) documentation for reference - see par. "13.2. Moodle's Roles and Permissions System".
(I also found Russian translation of that paragraph, maybe useful for someone.)