Consistent Support for Plan Language objects from within apply blocks
#1244
Comments
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Nov 21, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the *Result* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. ... Stil TODO: - [] Future proof - [] Tests - [] Docs - [] Threading
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 2, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the *Result* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. ... Stil TODO: - [] Future proof - [] Tests - [] Docs - [] Threading
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 3, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the *Result* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. ... Stil TODO: - [] Future proof - [] Tests - [] Docs - [] Threading
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 3, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets-in-apply as their own class, an ApplyTarget. When creating the catalog compiler we set the inventory to a bare string, then look for that in the Target object. When a Target object is instantiated while the inventory is in 'apply mode', it will create an ApplyTarget instead of a Target. For now this is only ever done by the deserializer when target objects are deserialized. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 3, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets-in-apply as their own class, an ApplyTarget. When creating the catalog compiler we set the inventory to a bare string, then look for that in the Target object. When a Target object is instantiated while the inventory is in 'apply mode', it will create an ApplyTarget instead of a Target. For now this is only ever done by the deserializer when target objects are deserialized. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 3, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets-in-apply as their own class, an ApplyTarget. When creating the catalog compiler we set the inventory to a bare string, then look for that in the Target object. When a Target object is instantiated while the inventory is in 'apply mode', it will create an ApplyTarget instead of a Target. For now this is only ever done by the deserializer when target objects are deserialized. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 5, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets and inventory in apply separately, as ApplyTarget and ApplyInventory. When creating the catalog compiler we create an ApplyInventory, which implements errors for invalid apply functions and has ApplyTarget as it's implementation class. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 6, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets and inventory in apply separately, as ApplyTarget and ApplyInventory. When creating the catalog compiler we create an ApplyInventory, which implements errors for invalid apply functions and has ApplyTarget as it's implementation class. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 9, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets and inventory in apply separately, as ApplyTarget and ApplyInventory. When creating the catalog compiler we create an ApplyInventory, which implements errors for invalid apply functions and has ApplyTarget as it's implementation class. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 9, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets and inventory in apply separately, as ApplyTarget and ApplyInventory. When creating the catalog compiler we create an ApplyInventory, which implements errors for invalid apply functions and has ApplyTarget as it's implementation class. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 9, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets and inventory in apply separately, as ApplyTarget and ApplyInventory. When creating the catalog compiler we create an ApplyInventory, which implements errors for invalid apply functions and has ApplyTarget as it's implementation class. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 9, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets and inventory in apply separately, as ApplyTarget and ApplyInventory. When creating the catalog compiler we create an ApplyInventory, which implements errors for invalid apply functions and has ApplyTarget as it's implementation class. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 10, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets and inventory in apply separately, as ApplyTarget and ApplyInventory. When creating the catalog compiler we create an ApplyInventory, which implements errors for invalid apply functions and has ApplyTarget as it's implementation class. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 12, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets and inventory in apply separately, as ApplyTarget and ApplyInventory. When creating the catalog compiler we create an ApplyInventory, which implements errors for invalid apply functions and has ApplyTarget as it's implementation class. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
lucywyman
added a commit
to lucywyman/bolt
that referenced
this issue
Dec 12, 2019
There are 4 custom types in the Bolt plan language that we want to make available inside apply blocks: Target, Result, ResultSet, ApplyResult. For each of the \*Result\* objects this is accomplished by serializing the plan variables to the apply block as pcore instead of as json. We also needed to add pcore_init methods to the implementation classes of the objects, because the pcore deserializer will by default call `initialize` on the class and pass in the values of the attributes of the type, which doesn't match the signature of the actual implementations. Using `_pcore_init_hash` and `_pcore_init_from_hash` lets us define what data gets serialized and how it gets deserialized for those types. Target objects are trickier for a few reasons: 1. They must have an associate inventory 2. They should not be modified or created inside an apply block Instead of trying to create the right guard rails around using Target objects in apply blocks and pass around an inventory, it's easier to think of (and implement) targets and inventory in apply separately, as ApplyTarget and ApplyInventory. When creating the catalog compiler we create an ApplyInventory, which implements errors for invalid apply functions and has ApplyTarget as it's implementation class. This protects the inventory within apply blocks, and clearly separates the concept of Targets in plans, and Targets in apply blocks. Closes puppetlabs#1244
nicklewis
added a commit
that referenced
this issue
Dec 12, 2019
(GH-1244) Serialize plan variables as pcore
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Use Case
Currently plan language objects are not correctly serialized/deserialized around
applyblocks.Describe the Solution You Would Like
Targetobjects andDatacontainingTargetobjects that are assigned to variables should work and be available inside apply blocks.get_target(s)functions should raise a clear error when called inside an apply block.Target.newshould raise a clear error when called inside an apply block.Errorobjects assigned to a variable should be accessible inside apply blocks.Result,ApplyResultandResultSetobjects should either be available or raise a clear error when certain methods/attributes are accessed (for example: Result should work, but thetargetattribute should not work (performance)). The current behavior of converting themDatais a bug.Describe Alternatives You've Considered
get_target(s). This method has side effects(adding new targets to theallgroup) and prevents us from optimizing how much of the inventory is loaded in each compiler.Additional Context
We should at least spike on making Pcore serialization/serialization work. This may be difficult for Target objects. Experiment with that and come up with a proposal for the first step. Perhaps we should serialize targets and inventory and pass them separately.
Should other Pcore types like
Patternwork across the boundary? Can we just use Pcore serialization with explicit tests for the Plan language objects?Should new serialization/deserialization be feature flagged with the
version: 2inventory? Yes, flag this with$futureThe text was updated successfully, but these errors were encountered: