I have 2 modules with class name has A-Class and B-Class. I want to make sure B-Class runs first and with A-Class when i run Puppet apply site.pp. But getting error as 'Syntax error at 'mongos'; expected '}' at require B-Class line, below is the code.
node 'HOST-1'{
class { 'a_class':
require b_class,
first => "abcd",
log_data_path => "/log/serv.1",
}
class { 'b_Class':
build_id => "php_2.4",
}
}
Is it the right way to use require? Else what is the better way to do.
TIA
This is also right. But better way to do it is
class { 'a_class':
first => "abcd",
log_data_path => "/log/serv.1",
require => Class['a_class']
}
Almost right, but require is a parameter in its own right.
require => Class['a_class']
In this scenario, you could also use chaining arrows.
class { 'b_class': ... }
->
class { 'a_class': ... }
This will have the same effect.
Related
I have a code, and I want to make sure that a class definion is indeed loaded.
Lets say that the class name is foo. I can do the following:
if { [ catch { foo new } ] } { source "path_to_code" }
Is there a way to do it without catch?
You can use the info command:
if {![info object isa class foo]} {source "path_to_code"}
Is it possible to build an enum inside a Rust macro using fields that are defined as macro parameters? I've tried this:
macro_rules! build {
($($case:ty),*) => { enum Test { $($case),* } };
}
fn main() {
build!{ Foo(i32), Bar(i32, i32) };
}
But it fails with error: expected ident, found 'Foo(i32)'
Note that if the fields are defined inside the enum, there is no problem:
macro_rules! build {
($($case:ty),*) => { enum Test { Foo(i32), Bar(i32, i32) } };
}
fn main() {
build!{ Foo(i32), Bar(i32, i32) };
}
It also works if my macro only accepts simple fields:
macro_rules! build {
($($case:ident),*) => { enum Test { $($case),* } };
}
fn main() {
build!{ Foo, Bar };
}
But I've been unable to get it to work in the general case.
It's absolutely possible, but you're conflating totally unrelated concepts.
Something like $case:ty does not mean $case is something which looks like a type, it means $case is literally a type. Enums are not made up of a sequence of types; they're made up of a sequence of variants which are an identifier followed (optionally) by a tuple structure body, a record structure body, or a tag value.
The parser doesn't care if the type you give it happens to coincidentally look like a valid variant, it's simply not expecting a type, and will refuse to parse one in that position.
What you need is to use something like $case:variant. Unfortunately for you, no such matcher exists. The only way to do something like this is to manually parse it using a recursive incremental parser and that is so out of scope of an SO question it's not funny. If you want to learn more, try the chapter on incremental TT munchers in the Little Book of Rust Macros as a starting point.
However, you don't appear to actually do anything with the cases. You're just blindly substituting them. In that case, you can just cheat and not bother with trying to match anything coherent:
macro_rules! build {
($($body:tt)*) => {
as_item! {
enum Test { $($body)* }
}
};
}
macro_rules! as_item {
($i:item) => { $i };
}
fn main() {
build!{ Foo, Bar };
}
(Incidentally, that as_item! thing is explained in the section on AST coercion (a.k.a. "the reparse trick").)
This just grabs everything provided as input to build!, and shoves it into the body of an enum without caring what it looks like.
If you were trying to do something meaningful with the variants, well, you're going to have to be more specific about what you're actually trying to accomplish, as the best advice of how to proceed varies wildly depending on the answer.
Let's say I have 1 directive for authentication. And after authentication, I would like to log. This is what I do so far:
get(...) {
myauthdirective() { v =>
myloggingdirective(v) {
...
}
}
}
So I would like to covert that to a single directive instead of having to have 2 every time I need to authenticate.
I tried using flat map, but that doesn't seem to work because authenticate returns a Directive1 and logRequestResponse returns Directive0.
// Does not work!
authenticate(myAuthMagnet).flatMap {
case ca: returnType => logRequestResponse(LoggingMagnet(logme(ca)))
}
So I tried it with map, but it doesn't seem to go into my logging magnet function.
// Does not work either!
authenticate(myAuthMagnet).map {
case ca: returnType =>
logRequestResponse(LoggingMagnet(logme(ca))) // does not go into logme function for some reason
ca
}
I also can't call logme directly because I need the request and response objects as well.
Is there a way to create a new directive with 2 directives that return different Directive types? Thanks.
There is one little thing missing in your implementation. You need to provide value after logging. So the implementation should be like:
authenticate(myAuthMagnet).flatMap {
case ca: returnType => logRequestResponse(LoggingMagnet(logme(ca))) & provide(ca)
}
New puppet user, trying to wrap my head around name spaces and so forth.
I am currently working on a module called user. It has a unixuser class and a unixgroup class in unixuser.pp and unixgroup.pp. I'll limit my question to the creation of users.
init.pp currently only contains:
class user {
class {'user::unixuser': }
class {'user::unixgroup': }
# Create groups before creating users
Class['user::unixgroup'] -> ['user::unixuser']
}
In unixuser.pp and unixgroup.pp I only want to define the virtual resources. The functions that do this should be in functions.pp for readability.
Question 1: Should functions.pp should only contain definitions or should the definitions sit inside a class? So in code, should functions.pp contain this:
class user::functions {
define login ($uid, $gid) {
user { $title:
ensure => present,
uid => $uid,
gid => $gid,
}
}
}
Or should define login not be in the user::functions class? If so, should the define line be define user::login or something else?
Going further, unixuser.pp will then contain something similar to the following (incomplete) stanza:
class user::unixuser {
#something { 'admin':
uid => 1000,
gid => 1000,
}
}
If all of this is finished then I will realize the users from nodes.pp with something like realize User::Something['admin'].
Question 2: How should the class user::unixuser be made aware of the login function? Is this done by having class user::unixuser inherits user::functions or should I have include user::functions or class {'user::functions': } or...?
Question 3: Based on question 2, what comes in the place of #something when the user::unixuser class plays nicely with functions.pp?
I tried to formulate the question to the best of my abilities but if it is still a bit chaotic I apologize. :)
First off if a user is assigned to a group that group is auto required, so you shouldn't need the following,:
# Create groups before creating users
Class['user::unixgroup'] -> ['user::unixuser']
functions.pp looks fine try the following in init.pp:
class user {
include user::functions
include user::unixgroup
include user::unixuser
}
and unixuser.pp:
class user::unixuser {
login { 'admin':
uid => 1000,
gid => 1000,
}
...
}
In both Python and Java we have import to eliminate the repetition of fully-qualified package/module names throughout code. Is there any equivalent in Perl/Moose? I think it would really make Moose nicer to use if we didn't have to repeat MyApp::Model::Item. Instead, I'd like to [somehow declare] MyApp::Model::Item; and later on, simply refer to Item. I can think of all of these use-cases where class names are used...
extends 'Item';
with 'ItemRole';
Item->new(name => 'thing');
method foo(Item $xyz) { ... }, with MooseX::Method::Signatures
$var->isa('Item');
try { ... } catch (DatabaseError $e) { ... }, with TryCatch
$Item::SOME_PACKAGE_GLOBAL_VARIABLE
If there is no such thing yet, any idea on how I might start to cleanly implement this? I can see that it would be tricky to deal with cases where the classname is used as a string.
This all works with aliased
use aliased 'MyApp::Model::Item';
use aliased 'MyApp::ItemRole';
use aliased 'MyApp::Exception::DatabaseError';
extends Item;
with ItemRole;
Item->new(name => 'thing');
method foo (Item $xyz) { ... }
$var->isa(Item);
try { ... } catch(DatabaseError $e) { ... }
This doesn't:
$Item::SOME_PACKAGE_GLOBAL_VAR
Needing something like that seems to be quite rare, but I suppose it could be made to work with the namespace::alias module.