My guess is:
Use WALK to retrieve all variables (periodically)
Set our own rules in MIB to check for variable values:
true / false
Above certain threshold
etc.
I do not think the above is true.
Because if that is the case, the setup and configuration of the MIB will be tedious and user must have extensive knowledge of each variables sent by the Agent.
Hopefully someone can tell me a simpler way.
Related
The Problem:
I'm trying to have Puppet manage some of the details of several scheduled tasks without managing whether those tasks are enabled. To that end, I declare scheduled_task resources without any explicit enabled attributes, with the intention of communicating that whether the tasks are enabled is not to be altered by Puppet. Puppet, however, is persistent in re-enabling the tasks on every run, just as if I had specified enabled => true for each of them. How can I make it stop doing that?
Already Tried:
I've considered setting the attributes for each datacenter via hiera, but the reality is that this makes failovers and switches more complicated than necessary. I don't want to change my puppet code every time that needs to happen. I also can't shut-off the puppet-agent runs. I need to maintain the integrity of our rolling deployment system.
Providers?
I've read a little about providers, seems like I can handle the behavior there. However, I'm having a hard time figuring out where there is (if any) documentation that explains how to use them to override specific resource properties.
Notify/Subscribe:
I've thought about using notify/subscribe to only set the triggers to enabled on creation. I'm not thinking this is the right solution, because it's not one resource subscribing to/notifying another, it's properties being set on a single resource. If there's some magical way of doing this or something similar, I'd love to know.
Bottom-line: I just need puppet to create disabled tasks, and let me turn them on/off without changing the state in subsequent runs.
Is there a way to ignore resource attribute defaults in Puppet entirely?
Only by explicitly declaring a value for every attribute of every resource.
But that doesn't seem to be the question you really wanted to ask. You seem to be exploring ways to assign attribute values without specifying them as literals in your resource declarations, and I guess you're looking for some kind of layered approach, with the bottom layer replacing or overriding types' and providers' built-in defaults.
As you thought, you could conceivably do this at least in part via providers. You would need to write a custom provider for your resource type and specify that it be used by each resource instance. But don't. This way is complicated to implement and confusing to anyone who later has to read your manifests (maybe including future you).
Notify / subscribe, on the other hand, are simply the wrong tools for the job. They do not do what you seem to think they do, or perhaps you just haven't thought that idea through.
I think you're selling Hiera short and / or inappropriately minimizing the complexity of the task. Probably a mixture of both -- I'm inclined to guess that Hiera can do more for you than you appreciate, but also that the complications you envision will manifest to some extent, in some form, no matter what you do.
Nevertheless, there is an approach that seems to match pretty closely what I think you want: resource default declarations (I link to the latest docs, but this feature is present, in substantially the same form, in every Puppet version released in at least the last nine years). Thus, you might cause all scheduled_task resources to be disabled unless you explicitly say otherwise by putting this resource default declaration at an appropriate place:
Scheduled_task {
enabled => false
}
When choosing where to put such a statement, do note that, unlike anything else in modern Puppet, resource default statements have dynamic scope. The manual discusses that in somewhat more detail.
Revisited:
In light of the clarification of the question, I'll clarify that resource types' providers are where resource management behavior lives. Therefore, if Puppet's behavior on target machines is not what you want in the event of an altogether missing property declaration, then modifying the provider or writing your own are pretty much your only alternatives. Of course, if you have a support contract then perhaps you don't have to do that in-house.
If you don't want to hack on providers -- an altogether reasonable position -- then you're left with managing the properties to their desired values. Supposing that you employ Hiera effectively, however, you should not need to modify any manifests to control which servers have their tasks enabled.
I'm trying to make a state machine in which I want to build a retry and max attemps feature. Let me explain, so far I have this:
From SAVED, I want to go to VALIDATED, although if there is an error, it has to go to AWAITING_VALIDATION state. After 3 minutes, try again to VALIDATED state.
Did I have correctly set up retry mechanism?
After 3 attemps, I want to go back to SAVED state (and pause state machine). Is it possible to do that in a fancy waty (e.g using spring state machine) or do I have to do this manually using some kind of a cache?
Thanks for your help
There are probably many ways to do these things with different machine configurations but having said that, this is such a clearly presented guestion that I wanted to spend some time on it.
You are close and you missed some things(I'd say tricks) to make this happen. Answer is to use extended state variables to add memory into a machine. These variables are usually used to limit number of needed stated to represent what machine needs to do. You need 3 loops and you could probably create more states to represent each loop and transition(with specific guards) to those as needed. However this will simply explode state configuration if you need more loops like 10 or 20 or 100+.
I created an example in ssm-sample3 which is showing how extended state variables and different guards and actions can be used to drive this specific flow.
Unfortunately there is a bug in a current 1.1.1.RELEASE which prevents you to directly transition from a AWAITING_VALIDATION into HAS_ERROR junction and loop until you pause into VALID using an anonymous transition having a guard(that's why sample has a dummy TMP state which is not needed with 1.2.x).
This is probably something I'd like to add as an example or faq to our ref docs.
Lemmy know if this helps.
Here's my setup:
It's a basic asset management system. The picture is a little incomplete, but the general idea is this:
From the top left User task, the user has the choice of Yes or No (true or false). As you can see, there's two yeses and one no (which leads to an end). Should the user choose yes, both paths are available to him. The lower yes leads to a complex budgeting, purchasing, and approval system, while the right yes will simply assign whatever asset is already available.
Should the user choose the lower yes, at any time of the process they can simply scratch that and assign whatever asset is already available, as it is understandable that it could take a while before a new asset is acquired.
For this, I used the inclusive gateway, as I believe it allows both paths to be available to the user.
Each of my task print out its title and task ID. Both the arrows from the yes require the same boolean variable to be set to true, while the no is set to false. Should the system check false, it terminates as expected.
However, when the system detects a true, it only shows the print out of the lower yes. Now, this one works, and I've been able to complete the process from there, but what happened to the other yes?
Is there something wrong with my bpmn?
I've tried removing the joining gateway, but it does nothing, AFAIK. Only by setting the lower yes value to expect a false does the other yes trigger.
Any suggestions please?
Fixed it by removing the Join gateway and having both arrows point to the next process.
Guess the Join behaviour isn't always as useful.
I am using some SNMP traps for monitoring of applications. Now I was told that some monitoring systems might have problems if the order of the attributes within the the traps was not the same as defined in the MIB. From the Complexity of the OIDs that could easily be used to re-order the attributes I was surprised by this, so I tried to find the relevant section of the RFC, but I could neither find something that said any ordering is allowed nor anything that said it is important. In other secondary documentation about SNMP I was not able to find anything usefull either.
So this is more a curiosity question, that could however also help in further projects using SNMP. Could anyone point me to the correct documentation as far as this problem is concerned. Or is this something that one software might handle while other software might not handle this and I should check the actual documentation for that software?
I found the relevant document.
Section 3.1.2 specifies:
The VARIABLES clause, which need not be present, defines the
ordered sequence of MIB objects which are contained within
every instance of the trap type. Each variable is placed, in
order, inside the variable-bindings field of the SNMP Trap-
PDU. Note that at the option of the agent, additional
variables may follow in the variable-bindings field.
Thanks to the person who pointed this out to me.
Are there any languages with possibility of declaring global assertions - that is assertion that should hold during the whole program execution. So that it would be possible to write something like:
global assert (-10 < speed < 10);
and this assertion will be checked every time speed changes state?
eiffel supports all different contracts: precondition, postcondition, invariant... you may want to use that.
on the other hand, why do you have a global variable? why don't you create a class which modifies the speed. doing so, you can easily check your condition every time the value changes.
I'm not aware of any languages that truly do such a thing, and I would doubt that there exist any since it is something that is rather hard to implement and at the same time not something that a lot of people need.
It is often better to simply assert that the inputs are valid and modifications are only done when allowed and in a defined, sane way. This concludes the need of "global asserts".
You can get this effect "through the backdoor" in several ways, though none is truly elegant, and two are rather system-dependent:
If your language allows operator overloading (such as e.g. C++), you can make a class that overloads any operator which modifies the value. It is considerable work, but on the other hand trivial, to do the assertions in there.
On pretty much every system, you can change the protection of memory pages that belong to your process. You could put the variable (and any other variables that you want to assert) separately and set the page to readonly. This will cause a segmentation fault when the value is written to, which you can catch (and verify that the assertion is true). Windows even makes this explicitly available via "guard pages" (which are really only "readonly pages in disguise").
Most modern processors support hardware breakpoints. Unless your program is to run on some very exotic platform, you can exploit these to have more fine-grained control in a similar way as by tampering with protections. See for example this article on another site, which describes how to do it under Windows on x86. This solution will require you to write a kind of "mini-debugger" and implies that you may possibly run into trouble when running your program under a real debugger.