https://pulumi.com logo
Join Slack
Channels
Powered by Linen
general
  • m

    microscopic-florist-22719

    06/20/2018, 10:18 PM
    During a preview/update we give each analyzer referenced by the project a chance to inspect each resource. If an analyzer reports failures, the resource registration fails and the preview/update halts.
  • s

    stocky-spoon-28903

    06/20/2018, 10:18 PM
    Excellent. Is the intention for the analysers to be exposed via the same programming model?
  • s

    stocky-spoon-28903

    06/20/2018, 10:19 PM
    And will it have the ability to retrospectively inspect conformance with a new or modified policy?
  • m

    microscopic-florist-22719

    06/20/2018, 10:19 PM
    Those are great questions. 🙂 @big-piano-35669 or @white-balloon-205 probably have better insight there.
  • m

    microscopic-florist-22719

    06/20/2018, 10:20 PM
    (FWIW, it turns out we do have one example analyzer in the 
    pulumi/pulumi
    repo, though I'm not sure of its precise status: https://github.com/pulumi/pulumi/blob/master/examples/analyzers/infosec/main.go)
  • s

    stocky-spoon-28903

    06/20/2018, 10:21 PM
    Interesting. It’s a bit unclear what additional context each analyzer has access to there. Often they’d need implementing in terms of the entire dependency graph?
  • m

    microscopic-florist-22719

    06/20/2018, 10:23 PM
    Hm, that's an interesting complication. One consequence of the Pulumi model is that the graph is built and executed incrementally, so the complete graph is (generally speaking) not known until the preview/update has completed.
  • s

    stocky-spoon-28903

    06/20/2018, 10:24 PM
    Yes, that seems to be the major difference between Pulumi and Terraform when it comes to execution - TF has a complete graph before execution.
  • m

    microscopic-florist-22719

    06/20/2018, 10:24 PM
    To be a bit more precise, given a resource 
    r
    , we are guaranteed to have seen the transitive closure of `r`'s dependencies by the time 
    r
    is registered, but we are also guaranteed not to have seen any resource that depend on 
    r
    .
  • m

    microscopic-florist-22719

    06/20/2018, 10:24 PM
    Correct.
  • s

    stocky-spoon-28903

    06/20/2018, 10:25 PM
    I think that is OK for the purposes of policy
  • s

    stocky-spoon-28903

    06/20/2018, 10:25 PM
    But perhaps not
  • s

    stocky-spoon-28903

    06/20/2018, 10:25 PM
    It might only be possible to evaluate some policies retrospectively
  • s

    stocky-spoon-28903

    06/20/2018, 10:25 PM
    Which I think might also be OK
  • m

    microscopic-florist-22719

    06/20/2018, 10:26 PM
    Yeah, if a policy requires an understanding of which resources depend on a given resource, then that policy can only be evaluated in retrospect
  • m

    microscopic-florist-22719

    06/20/2018, 10:26 PM
    Though we can give a conservative answer on such a policy using the graph produced by a preview
  • s

    stocky-spoon-28903

    06/20/2018, 10:27 PM
    My canonical example is “instances may not be placed in a subnet with a route to an internet gateway”
  • m

    microscopic-florist-22719

    06/20/2018, 10:27 PM
    ....that's a really good example
  • s

    stocky-spoon-28903

    06/20/2018, 10:27 PM
    In that case the instance would have a dependency on the subnet, but the route would be an edge from the subnet also.
  • m

    microscopic-florist-22719

    06/20/2018, 10:27 PM
    esp. as it can be phrased from different perspectives
  • s

    stocky-spoon-28903

    06/20/2018, 10:28 PM
    Assuming we are walking in parallel, there is a possibility the context necessary for matching the policy wouldn’t exist at the evaluation of the instance.
  • m

    microscopic-florist-22719

    06/20/2018, 10:29 PM
    Right. So you might need to implement this policy in such a way that it can handle all possible partial orderings of resource creation that create the problematic result
  • s

    stocky-spoon-28903

    06/20/2018, 10:33 PM
    I wonder if a policy could be made into a graph node such that the execution is delayed until all of the inputs are reified
  • s

    stocky-spoon-28903

    06/20/2018, 10:34 PM
    That could get awkward thoguh
  • s

    stocky-spoon-28903

    06/20/2018, 10:39 PM
    It might be worth adding some library functions to either 
    pulumi
    or perhaps a new 
    network
    package which has things like 
    cidr_subnet
    in order to implement things like “extend this CIDR prefix by n bytes and then find the network number x within it”
  • s

    stocky-spoon-28903

    06/20/2018, 10:39 PM
    (similar to the Terraform 
    cidr_subnet
    interpolation function)
  • m

    microscopic-florist-22719

    06/20/2018, 10:41 PM
    That's a good idea. Would you mind filing an issue for that in https://github.com/pulumi/pulumi?
  • s

    stocky-spoon-28903

    06/20/2018, 10:47 PM
    Done https://github.com/pulumi/pulumi/issues/1552
  • m

    microscopic-florist-22719

    06/20/2018, 10:47 PM
    Thanks!
  • b

    big-piano-35669

    06/21/2018, 12:34 AM
    Late to the party, sorry!
    Is the intention for the analysers to be exposed via the same programming model?
    Analyzers are gRPC plugins too, so yes, they can be written in any language and have access to the parts of graph available per Pat's comments. The current state is a little half-baked -- which is why we don't advertise or doc them -- but it's a preview of core capability we're going to go pretty hard on in the weeks to come. For instance, we have a query language prototype that will expand to give you GraphQL-ish capabilities to perform rich analysis against resource graphs/plans. I expect we'll have lots more to say about this over the next couple milestones, but for now, if you end up wanting to kick the tires on what's there, just let us know and we can point you at some defaults.
    đź’Ż 2
Title
b

big-piano-35669

06/21/2018, 12:34 AM
Late to the party, sorry!
Is the intention for the analysers to be exposed via the same programming model?
Analyzers are gRPC plugins too, so yes, they can be written in any language and have access to the parts of graph available per Pat's comments. The current state is a little half-baked -- which is why we don't advertise or doc them -- but it's a preview of core capability we're going to go pretty hard on in the weeks to come. For instance, we have a query language prototype that will expand to give you GraphQL-ish capabilities to perform rich analysis against resource graphs/plans. I expect we'll have lots more to say about this over the next couple milestones, but for now, if you end up wanting to kick the tires on what's there, just let us know and we can point you at some defaults.
đź’Ż 2
View count: 2