6 ms·

So the idea is that you would choose your changes in the GUI, but instead of actually changing the target, it spits out the required code to do it for you in a

• jamiesonbecker 9y ago
  Example Cloudformation Designer stack diagram (click View In Designer or scroll down for a screenshot): https://userify.com/docs/enterprise/cloudformation/ https://userify.com/docs/enterprise/cloudformation/ If you have an AWS account, you can actually modify/fork the template on the fly by clicking on one of the objects in the diagram and editing its properties (which edits the YAML CloudFormation template in the background).
• 0xbadcafebee 9y ago
  A better idea would be to spit out a spec that tools could use to perform the thing, and get tools to follow the spec. Unfortunately, even though most tools do virtually the exact same thing, they all use their own incompatible ways to describe it in a config. I'm not sure why devs enjoy reinventing the wheel in incompatible ways all the time. For example: you have Puppet, Chef, Ansible, Salt, etc. They can all make a directory. They do exactly the same thing on almost all systems they support, because POSIX. They literally all just run this syscall: int mkdir(const char pathname, mode_t mode);. But each tool has their own goofy way of being told to make the directory. Why can't I just pass "{'mkdir': [ '/the/path/name', '0700' ]}" to all of them? This is literally all they will be doing, and all they need to know. Just make this path with this permission. This is declarative programming, without a custom language! Anything else, like directory ownership, should be an extra object, like "{'chown': [ '/the/path/name', '1000', '1000' ] }". Again, this is literally called the same way everywhere: int chown(const char pathname, uid_t owner, gid_t group);. You can combine the two into one JSON blob in the output of this config management tool (that's what this GUI really is - a GUI CM with a dashboard). You can have sets of blobs with tags that are discrete reusable pieces of configuration. And every tool can just read them, follow a spec based on POSIX, and execute them.
  • SSLy 9y ago
    because most of these systems also support non-Unixy target systems
    • peterwwillis 9y ago
      All the non-Unixy targets are POSIX compliant so the majority of the basic functionality is the same. All the other stuff like package management will vary among distros anyway, so they can just add extra portability glue for more complicated functions.
      • SSLy 9y ago
        Windows without WSL or WSU is not Posix-compliant.
  • kilburn 9y ago
    Sure, you picked the simplest possible case for a configuration management system. Now, in this very simple case: - What happens when "/the/path" changes depending on the distribution? How do you specify that? - What should happen if the "/the/path/name" already exists? Should the system touch it or something? - What if it exists but is not a directory? Should it delete whatever exists and create a directory instead? There is no way to define that stuff using POSIX semantics, because POSIX is inherently imperative. "mkdir" means "make a directory", not "on this path there must be a directory". That mismatch in semantics is real, and each configuration management system tries to close that gap in the simplest, most user-friendly way they can figure out. Most have flocked towards defining their own, as declarative as possible, API. For instance, ansible defines this as: - name: Ensure name's base folder exists file: path: /the/path/name state: directory recurse: no owner: pid/name group: gid/name I do think that, like that snippet above demonstrates, none of them do an astounding job at defining that API. However, I blame their failure to the hardness of the task, not to the incompetence of the developers of ansible/salt/puppet/etc.
    • 0xbadcafebee 9y ago
• viraptor 9y ago
  The cloudformation designer is... Not terrible, but it's pretty bad. It requires lots of clicking and manual work for simple things and doesn't help you do the complex ones. It's a 1:1 visual representation of the generated json/yaml and it's easier to just write those directly. To be really useful, it should have some kind of snippet options (insert a vpc with all the usual subnets, routing, etc in one go), or some "fill in the blanks" functionality.