I have a Vagrantfile with more than one provider, and they can't use the same synced_folder types. How do I change all the synced_folder types in the per-provider section? I would like to avoid repeating the synced_folder definitions for each provider.
config.vm.synced_folder "prog", "/home/vagrant/prog", type: "virtualbox"
# more synced folders
config.vm.provider "docker" do |docker, override|
override.vm.box = nil
docker.build_dir = "."
# change all synced_folder types here?
config.vm.synced_folder is a method call that appends to a #__synced_folders data structure inside the VM configuration object.
One way to do it might be to leave the type unset in the synced_folder declaration, and then set the allowed_synced_folder_types an array of the desired type for each provider. Another way might be to declare a local array of synced_folder arguments, looping over it in each provider configuration to pass the desired type to synced_folder.
override.vm.allowed_synced_folder_types = [:virtualbox, :rsync]
Related
I was looking inside the create_vlabel function and noted that to get the graph_name and label_name it is used graph_name = PG_GETARG_NAME(0) and label_name = PG_GETARG_NAME(1). Since these two variables are also passed as parameters, I was thinking that, if I wanted to add one more parameter to this function, then I would need to use PG_GETARG_NAME(2) to get this parameter and use it in the function's logic. Is my assumption correct or do I need to do more tweaks to do this?
You are correct, but you also need to change the function signature in the "age--1.2.0.sql" file, updating the arguments:
CREATE FUNCTION ag_catalog.create_vlabel(graph_name name, label_name name, type new_argument)
RETURNS void
LANGUAGE c
AS 'MODULE_PATHNAME';
Note that all arguments come as a "Datum" struct, and PG_GETARG_NAME automatically converts it to a "Name" struct. If you need an argument as int32, for example, you should use PG_GETARG_INT32(index_of_the_argument), for strings, PG_GETARG_CSTRING(n), and so on.
Yes, your assumption is correct. If you want to add an additional parameter to the create_vlabel function in PostgreSQL, you can retrieve the value of the third argument using PG_GETARG_NAME(2). Keep in mind that you may need to make additional modifications to the function's logic to handle the new parameter correctly.
The answers given by Fahad Zaheer and Marco Souza are correct, but you can also create a Variadic function, with which you could have n number of arguments but one drawback is that you would have to check the type yourself. You can find more information here. You can also check many Apache Age functions made this way e.g agtype_to_int2.
I'm refactoring some of my older PS scripts to a) improve them b) clean up c) modularize.
In the script I'm working now there are 10-15 functions that work on specific directory - let's call it work directory. Currently it's defined globally and loaded from a config file; it never changes after initialization (does that make it a constant?).
I want to wrap some of the functions in a separate module. The question is: should I rewrite them so the variable is passed explicitly as a parameter, or can I leave it as is, with the assumption that every script I use this module (library?) in will have this variable initialized? If the latter, how to make sure the module can "detect" the variable is uninitialized and throw some error?
And, last but not least, currently it's just a variable - should I use some specific construct so that it's obvious it is global, and not to be modified?
should I rewrite them so the variable is passed explicitly as a parameter
As long as there's no legitimate use case for overriding it in a single call, I wouldn't pass it as a parameter.
If your functions are packaged as a module, I'd strongly recommend utilizing module-scoped variables rather than globals.
Assuming you're talking about a script module, this is as simple as:
Set-Variable -Scope Script -Name ModuleTargetDirectory -Value $config.TargetDirectory
from inside the module file or a module function that runs during import (the script: scope is the same as module-scope inside a module), and then in the consuming functions:
function Get-Something
{
# ...
$targetDirectory = $script:ModuleTargetDirectory
# ...
}
Or wrap the entire config storage in a private helper method:
# don't export this function
function Get-MyModuleConfig
{
# assuming we stored a dictionary or custom object with the config options in a module-scoped variable named `config`
return $script:config
}
And then always just call $config = Get-MyModuleConfig in the begin block of functions that need access to the config data
I have a manifest file to add registry keys and values based on facts (works fine).
registry_key { 'HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate':
ensure => present,
}
registry_value { 'HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\TestKey':
ensure => present,
type => dword,
data => $test_key_value,
}
I want to add a second file to remove these if required but when i do i get an error
"Duplicate declaration: Registry_key[HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] is already declared"
Not sure how to get around this - if at all? Any advice appreciated. Obviously a puppet novice...
Thanks
If you want to solve this problem, you would probably use custom or external facts, something like this:
$ensure = $facts['include_windows_update_keys']
registry_key { 'HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate':
ensure => $ensure,
}
registry_value { 'HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\TestKey':
ensure => $ensure,
type => dword,
data => $test_key_value,
}
As you have discovered, declaring the same resource more than once but with different attributes is not allowed in Puppet.
There is more on custom facts here in the docs.
In most situations Alex's suggestion is the way I'd proceed. Usually the best way, to default it in common.yaml and override based on node name or another level in hiera. Depending on your use case, a less straight-forward way is to wrap those blocks in a conditional (if/unless/else) where it's present/absent depending on a boolean set in hiera. Something along the lines of unless $exclude_from_testkey or a case statement. Let me know if you're new to hiera and/or parameterization.
You have resource declarations for specifying that a particular registry key and value should be ensured present on the target node. If you also have declarations specifying that one or both should be absent, and Puppet evaluates both sets, then what are you actually telling Puppet to do? It cannot comply with both sets of declarations.
Puppet takes an extremely cautious approach to situations like this, which makes sense given its role in managing infrastructure. In the event that the same resource is declared more than once for the same target, Puppet aborts. This produces practical difficulties from time to time, but I am confident that it has protected many, many systems from misconfiguration.
The solution is to ensure that your manifest set declares only one set of those declarations for each node. You could do that by having only one set, and twiddling their $ensure parameters dynamically, as #AlexHarvey suggests. You could also do it by putting the two sets of declarations in different blocks, and selecting between them with conditional statements. Or you could put them in altogether different classes, and be certain to include just one of them for each node.
But I have to differ with Alex here on the specifics. I would not typically use a custom fact here, because that gives control over which option is exercised to the client. Generally speaking, I want the master to dictate questions of how various nodes are configured. For this purpose, it is a pretty common idiom to use a class parameter to control whether the resources are ensured present or absent:
class mymodule::windows_update(
Enum['absent','present'] $ensure = $present,
$test_key_value
) {
registry_key { 'HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate':
ensure => $ensure,
}
registry_value { 'HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\TestKey':
ensure => $ensure,
type => dword,
data => $test_key_value,
}
}
Why is it that, in Powershell, the System.DayOfWeek enum can be referred to like [System.DayOfWeek], whereas the System.Environment.SpecialFolder enum must be referred to like [System.Environment+SpecialFolder] (note the plus character)?
My guess is because SpecialFolder is part of the static Environment class and DayOfWeek is sitting directly in the System namespace, but I'm having trouble finding any information on this. Normally static members would use the "static member operator", but that doesn't work in this case, nor does anything else I try except the mysterious plus character...
[System.DayOfWeek] # returns enum type
[enum]::GetValues([System.DayOfWeek]) # returns enum values
[enum]::GetValues([System.Environment.SpecialFolder]) # exception: unable to find type
[enum]::GetValues([System.Environment]::SpecialFolder) # exception: value cannot be null
[enum]::GetValues([System.Environment+SpecialFolder]) # returns enum values
System.Environment.SpecialFolder is definitely a type, and in C# both enums work the same way:
Enum.GetValues(typeof(System.Environment.SpecialFolder)) // works fine
Enum.GetValues(typeof(System.DayOfWeek)) // also works
I'd really like to understand why there's a distinction in Powershell and the reasoning behind this behaviour. Does anyone know why this is the case?
System.Environment.SpecialFolder is definitely a type
Type SpecialFolder, which is nested inside type Environment, is located in namespace System:
C# references that type as a full type name as in the quoted passage; that is, it uses . not only to separate the namespace from the containing type's name, but also to separate the latter from its nested type's name.
By contrast, PowerShell uses a .NET reflection method, Type.GetType(), to obtain a reference to the type at runtime:
That method uses a language-agnostic notation to identify types, as specified in documentation topic Specifying fully qualified type names.Tip of the hat to PetSerAl.
In that notation, it is + that is used to separate a nested type from its containing type (not ., as in C#).
That is, a PowerShell type literal ([...]) such as:
[System.Environment+SpecialFolder]
is effectively the same as taking the content between [ and ], System.Environment+SpecialFolder, and passing it as a string argument to Type.GetType, namely (expressed in PowerShell syntax):
[Type]::GetType('System.Environment+SpecialFolder')
Note that PowerShell offers convenient extensions (simplifications) to .NET's language-agnostic type notation, notably the ability to use PowerShell's type accelerators (such as [regex] for [System.Text.RegularExpressions.Regex]), the ability to omit the System. prefix from namespaces (e.g. [Collections.Generic.List`1[string]] instead of [System.Collections.Generic.List`1[string]]), and not having to specify the generic arity (e.g. `1) when a list of type argument is passed (e.g. [Collections.Generic.List[string]] instead of [Collections.Generic.List`1[string]] - see this answer) for more information.
Difference between Introduce Parameter and Change Method signature in Eclipse?
Introduce parameter lets you convert a local expression to a parameter of the current method that will be added to the end of the parameter's list.
Change method signature allows you to introduce parameters without any special relation to your method's body, reorder or modify existing parameters.
A good overview can be found in Eclipse's help
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/ref-menu-refactor.htm (Galileo)
respectively
http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/ref-menu-refactor.htm (Helios)
If you are speaking of the Introduce parameter Object refactoring, one answer can be found here:
http://www.refactoring.com/catalog/introduceParameterObject.html
In fact this creates a new class representing your parameters where as the Change method signature allows to change method return type, visibility and parameters.
If you are speaking about the introduce parameter when a field or local variable is selected, this will just add a new parameter to the enclosing method with the same name and the same type than the selected field or local variable and thus use this parameter instead.
Manu