Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Figure out graph queryability #30

Closed
joeduffy opened this issue Dec 23, 2016 · 4 comments
Closed

Figure out graph queryability #30

joeduffy opened this issue Dec 23, 2016 · 4 comments
Assignees
@hausdorff
Labels
area/tooling impact/usability Something that impacts users' ability to use the product easily and intuitively kind/enhancement Improvements or new features
Milestone
0.22

Comments

@joeduffy
Copy link
Member

joeduffy commented Dec 23, 2016 •
edited

A scenario to consider is queryability of resource graphs. This covers multiple scenarios:

  • Simple questions about the contents of a graph ("What versions of Ubuntu am I running?")
  • Complex questions that combine static analysis ("What VMs are vulnerability to CVE-Xxx?")
  • Registering event notifications off the graph ("Tell me if any of my nodes ever get out of date")
  • Even making modifications to the graph based on queries ("Patch all old Ubuntu versions")

Furthermore, this could be exposed in a bot-like interface (text or speech), for real bot-driven IT/configuration management workflows.

There are many graph technologies to consider, however we should keep this in mind as we design.
@joeduffy joeduffy added area/tooling impact/usability Something that impacts users' ability to use the product easily and intuitively kind/enhancement Improvements or new features labels Dec 23, 2016
joeduffy added a commit that referenced this issue Dec 23, 2016
@joeduffy
Add a work item to figure out MuGL graph queries
eb20e5f 
This tags the relevant TODO with the work item #30.
joeduffy referenced this issue Dec 23, 2016
@joeduffy
Mu languages, take three
e864aa3 
This documents our latest thinking on Mu languages.  At a high level,
there are three classes of language at play:

1. Mu Metadata Languages (MuML): these are the high-level language
   subsets that a programmer uses to specify Mu modules, etc.  Examples
   include MuJS, MuPy, MuRu, and MyGo, each representing a deterministic
   subset of JavaScript, Python, Ruby, and Go, respectively.

2. Mu Intermediate Language (MuIL): this is the intermediate form that
   all of the above compile down to.  It is capable of representing
   computations like functions, conditionals, and basic expressions like
   string concatenation, etc.  This is fully statically analyzable and
   can be used to create deterministic plans and topology graphs.

3. Mu Graph Language (MuGL): this is the "final" form in which any Mu
   service topology is represented.  It never contains computations and
   is merely a metadata description of services-as-nodes, dependencies-as-
   edges, and all known properties.  In the planning form, it may contain
   "holes" because output properties aren't known until execution has
   occurred, while in the actual applied form, those holes have been
   plugged.  MuGLs can be diffed, and a MuGL can be generated from an
   existing live environment (for bootstrapping and/or drift analysis).

There are several TODOs in here, but this is braindump of where we're at.
@joeduffy joeduffy added this to the 0.3 milestone May 26, 2017
@joeduffy joeduffy changed the title Figure out MuGL graph queryability Figure out graph and resource queryability May 26, 2017
@joeduffy
Copy link
Member Author

This came up in a different place just now: resource providers.

The usage of Get APIs for fetching resources currently populates all properties on the resource, and I also expect us to end up with a List API that permits more ad-hoc querying. A more GraphQL like approach here would let you pick and choose which fields you want, possibly cutting down -- in some cases dramatically -- the amount of work required to execute a particular query.

This would be tough to add after the fact (because it changes the internal behavior of resource providers), and so I'm adding to 0.3 so we at least discuss it.

This was referenced Jun 14, 2017
Closed
Closed
@joeduffy joeduffy changed the title Figure out graph and resource queryability Figure out graph queryability Jun 19, 2017
@joeduffy
Copy link
Member Author

I'm repurposing this work item to cover only the graph querying aspects -- presumably part of the service API -- and we will continue using #83 for resource APIs specifically.

@joeduffy joeduffy removed this from the 0.3 milestone Jun 19, 2017
@joeduffy joeduffy added this to the 0.20 milestone Oct 29, 2018
@lukehoban lukehoban modified the milestones: 0.20, 0.21 Dec 9, 2018
@lukehoban
Copy link
Member

@hausdorff implemented a prototype in #2502 of adding checks into the Pulumi deployment process to block or warn on based on rules related to the desired state of a Pulumi deployment. This addresses a few of the issues above, as well as other "gating" scenarios.

This issue is rather old, and doesn't really capture the paths we expect to go down going forward. I suspect we should close this out and open new issues to track the concrete issues we are expect to invest in over coming months.

@lukehoban lukehoban modified the milestones: 0.21, 0.22 Mar 9, 2019
@lukehoban
Copy link
Member

We are now pursuing this as part of #2601.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hausdorff hausdorff

Labels
area/tooling impact/usability Something that impacts users' ability to use the product easily and intuitively kind/enhancement Improvements or new features
Projects
None yet
Milestone
0.22
Development

No branches or pull requests
3 participants
@lukehoban @hausdorff @joeduffy