15 ms·
While I respect the job that libvirt does (it works — high praise for software), it’s unfortunate that it is also the answer to the question “how can I represen
by amscanne 6y ago
While I respect the job that libvirt does (it works — high praise for software), it’s unfortunate that it is also the answer to the question “how can I represent all these virtualized things using XML?”, which was in fashion when libvirt was created.
It’s also a bit misleading to characterize cloud providers as building on libvirt. Libvirt is useful as an mostly hypervisor-agnostic wrapper, which is super useful for enterprise on-prem software, but kinda of the opposite of what big providers need and build for themselves.
I wonder what we will look back on as the XML of today. Everything is schemaless JSON and YAML; surely we’ll look back and wonder WTF everyone was thinking? But alas, it’s probably not a data format at all. Only time will tell.
- catmanjan 6y agoYep, if people think XML has aged poorly, wait until these schema-less formats age...
- stochastastic 6y agoHa! ... that’s a laugh of bitter jealousy. I’ve dealt with XML, but I’ve never with XML that came with a schema, or which would have reliably followed one. Not saying schema-less formats are great, but at least I can eyeball them to see what is going on.
- shmerl 6y agoSchemas are good. Even JSON now has one.
- hinkley 6y agoXML turned everyone into a language designer during an era where we already knew that language design was a rare skill. If I saw a schema, which I often didn’t, it usually didn’t say what the author thought it said. To a first order approximation, all the good ones I saw came from one tool (XMLSpy possibly?) Namespaces ended up in a sort of uncanny valley that I can’t quite do justice to.
- agumonkey 6y agoI'd even classical OO did the same.
- riffraff 6y ago> but I’ve never with XML that came with a schema how about docbook? It's been a while, but I think even eclipse's project.xml used to have a schema, and would validate it if you tried modifying it yourself.
- aaomidi 6y agoThe reason these schemaless and super simple formats are getting popular is because how easy it is to write various things on top of them. You can essentially use typescript to put a schema on JSON.
- foepys 6y agoJSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Hell, even INI files had support for comments and were just as expressional as JSON. I wonder why we regressed in that regard. Was it just because of the success of JavaScript and readily available JSON parsers? Because I'd argue that an INI parser is just as easy to write.
- vbezhenar 6y agoSometimes you can just add property "comment" or something like this.
- japanuspus 6y agoThis is exactly why TOML [0] is gaining traction as a simple configuration file format. Rust's cargo has been TOML from day one (`Cargo.toml`) and Python is moving this way with (`pyproject.toml`). For more general data structures, remember that JSON is a true subset of YAML [1]: Switch to a YAML parser and you can start optionally adding comments to your files while still being compatible with legacy input. [0] https://toml.io/en/ https://toml.io/en/ [1] https://yaml.org/ https://yaml.org/
- rurban 6y agoYAML has too many features, and is entirely insecure. You really need a safe subset, as eg. used in the various CI's.
- jmillikin 6y ago> For more general data structures, remember that JSON is > a true subset of YAML [1] This is unfortunately not true -- try the input '{"a":1e2}'.
- eska 6y agoYaml is generally derided as too complex and transforming data in unintended ways. I see a lot of Rust programmers preferring RON over TOML because it is much less complex and doesn't have multiple ways to express the same thing https://crates.io/crates/ron https://crates.io/crates/ron
- shmerl 6y agoWhat's wrong with XML?
- hinkley 6y agoI’ll start. Take an XML document. Validate it. Take all of the top level elements. Call getElementByID on each with the same value. Combine all the answers into an array, eliminating the nulls. You might expect that array to have length one or zero on all valid documents. You’d be wrong, and dangerously so for some XML schemas. You can use the same ID on every node and I don’t know of a parser that would balk at that. And yet every implementation will return the first node that has that ID, which will then change any time you descend into the DOM.
- _-___________-_ 6y agoParent asked what's wrong with XML, not what's wrong with DOM. Does XML actually even define a special meaning for the `id` attribute?
- hinkley 6y agoThe XML element object always has this function, in every implementation I’ve seen.
- _-___________-_ 6y agoThat does not make any sense. There are entire classes of XML parser that cannot implement getElementByID, such as streaming parsers. getElementByID is specified as part of the Document Object Model (DOM), not as part of XML. I don't think `id` even has a special meaning in XML.
- shmerl 6y agoI presume JSON is less ambiguous and easier to validate and parse?
- 6y ago
- throwaway189262 6y agoHaha yeah JSON is a terrible config format. As another poster mentioned, no comments. But the other big problem is inconsistent serialization. Null vs missing props, conversion of "true" to true. I've lost track of the number of times I've had to workaround differences in the serializer vs deserializer on other end. It's really quite bad format for how ubiquitous it's become.
- _-___________-_ 6y agoUgh, please name and shame the [de]serializer that was silently converting a string to a boolean.
- throwaway189262 6y agoThe problem we ran into is that they can all be configured to do whatever. There's no consistently or standard
- _-___________-_ 6y agowell, there's the JSON standard, which does not define "false" and false as equivalent.
- bonzini 6y agoNot sure about JSON, but YAML has the Norway problem: https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/
- formerly_proven 6y agoJSON does not, because JSON is explicitly typed: - "... - string - 14, 14.5 - number (problematic) - false, true - bool - {... - object - [... - array - null No cute abbreviations.
- danmur 6y agoNot a big fan of JSON myself but that sounds more like a bad implementation than ambiguity in the spec.
- bonzini 6y ago> It’s also a bit misleading to characterize cloud providers as building on libvirt Libvirt provides lifetime management for KVM virtual machines, including orchestration of live migration, setting up SELinux to ensure isolation between QEMU processes and cgroups to limit resource utilization, creating network interfaces and bridging them to host networking, and more. Any cloud provider that uses Openstack+KVM relies on Libvirt for all these tasks.
- amscanne 6y agoSure, but Openstack-based public clouds are in short supply (unfortunately? fortunately?). I think the short explanation is that pure OSS stacks limit providers ability to move fast and differentiate. So it’s a race the bottom for Openstack-based providers. (Rackspace’s gambit was quite different, as they were arguably trying to do exactly that.. comoditize cloud services.)
- bonzini 6y agoNo the short explanation is that no one is able to put in their cloud the same amount of money that Amazon, Microsoft and to a lesser extent Google do.
- amscanne 6y agoI don’t know why you’re disagreeing when you’re making the same argument. If you have the money, you build your own thing, which is better.
- gwd 6y ago> Libvirt is useful as an mostly hypervisor-agnostic wrapper Not sure if you're claiming this or not, but it's worth clarifying: Libvirt is a hypervisor-agnostic transport library; but it is not a hypervisor abstraction library. That is, you can use libvirt to talk to KVM or VMWare or Xen or Hyper-V. But you cannot, in general, take a VM config from one hypervisor and use it on another hypervisor: there are too many details of the underlying hypervisor exposed to make this possible. And if you build a tool on top of libvirt for one hypervisor, you can't just flip a switch and have it work on another hypervisor -- all of the code that generates your XML configs for (say) KVM will need to be rewritten if you want to use Xen or VMWare or Hyper-V. As an example, in the config you don't really say, "Give me a disk, and here's the disk image". You say, "Give me a virtio disk of this particular version with these particular properties." If your hypervisor doesn't provide virtio, the image simply can't be created. Which means the tool you're writing on top of libvirt needs to know the appropriate PV disk type for each different hypervisor and use the appropriate one. (At least, this was the situation several years ago, when a team from oVirt came to a Xen hackathon to see if they could get oVirt working on Xen. It turned out to be more work than they thought.)
- kashyapc 6y agoIt is not at all misleading—it is in fact correct to state that several open source "cloud infrastructure" projects rely on libvirt's ability to do a lot of guest life cycle heavy-lifting. And not least of all, libvirt provides critical layered security for QEMU processes (i.e. VMs) through Linux Namespaces, CGroups, sVirt ('Secure Virtualization', based SELinux), and more. (Also see user bonzini's response here for some more detail — https://news.ycombinator.com/item?id=24372499 https://news.ycombinator.com/item?id=24372499)
- baq 6y agoi'm looking at jinja-templated YAMLs with awe: how can anyone think it's a good idea? and yet, this insanity is everywhere nowadays. XML is verbose, hard to write manually and has many ways of representing the same thing, but it's actually designed compared to YAML which seems to be a hodgepodge of features, half of which need to be disabled in the safe variant.
- colechristensen 6y agoEmbedded Ruby (erb) templated yaml is nice. Not perfect, but nice.