Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Libvirt – The Unsung Hero of Cloud Computing (2013)

vyomtech.com

Post reply on HN
Print view View original

61–70 of 113 posts

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#61

Post by baq »

amscanne wrote: post #3

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…

i'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.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#62

Post by bbotond »

japanuspus wrote: post #17
foepys wrote: post #8

Earlier quoted context omitted.

JSON 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 regar…

This 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] http…

I hate YAML. XML and JSON have syntaxes that are very easy to learn. You basically see one example and know 99% of what you need. YAML has multiple ways of doing the same thing (eg. two array syntaxes) and is generally too "clean" looking to the point of being unreadable.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#63

Post by exikyut »

catern wrote: post #2

I really doubt that AWS is using libvirt. They almost certainly have their own abstraction. But still, I agree that libvirt is great; I wrote about it here: http://catern.com/posts/libvirt.html

Or QEMU, which libvirt uses. They're using KVM directly, possibly with Firecracker.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#64

Post by xfennec »

We've build our own automated hosting infrastructure* a few years ago on top of libvirt. Using the libvirt API was a breeze and libvirt is rock solid since day one for us, I can only recommend this project.

* Shameless plug: https://github.com/OnitiFR/mulch

We're using libvirt-go binding (Daniel Berrangé and his team is doing a excellent job maintaining it!), and KVM/QEMU hypervisior. For a small team like us, it's incredibly valuable to have access to such powerful tools in a such easy way.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#65

Post by Macha »

wokkel wrote: post #55
laurencerowe wrote: post #24

Earlier quoted context omitted.

For those working in dynamic languages (JavaScript, Python, Perl, Ruby, etc.) JSON maps directly onto built-in language data types and structures making it trivial to work with. With XML you usually end up needing custom code to convert to and from the parsed XML representation and the language's built-in data types and structures. This is less of a concern for statically typed languages where you usually have to mar…

It's trivial until you run into a date-field. I've connected some JSON based exchanges to each other and just created an XML intermediary format to have a single canonical model and do the various translations to/from the other systems from there.

Why are dates better in XML? You can still have:

ISO 8601, as used by XML Schema:

2020-09-04T00:00:00Z

or

Unix date output format (not sure this has an actual name)

Fri 04 Sep 2020 00:00:00 GMT

or

some sort of destructured date

2020 09 04

or

some sort of destructured date with 0 based months because Java

2020 08 04

Your app still needs to know what is coming in, and convert that to its internal format.

Even if you want to get everyone to agree on XML Schema's datetime format, it's not always sufficient because sometimes you need the actual time zone (e.g. America/New_York ) rather than the UTC offset especially when dealing with recurring/far off events.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#66

Post by danmur »

throwaway189262 wrote: post #19
amscanne wrote: post #3

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…

Haha 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.

Not a big fan of JSON myself but that sounds more like a bad implementation than ambiguity in the spec.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#67

Post by bonzini »

_-___________-_ wrote: post #34
throwaway189262 wrote: post #19

Earlier quoted context omitted.

Haha 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.

Ugh, please name and shame the [de]serializer that was silently converting a string to a boolean.

Not sure about JSON, but YAML has the Norway problem: https://hitchdev.com/strictyaml/why/implicit-typing-removed/

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#68

Post by tonyedgecombe »

Polylactic_acid wrote: post #20
shmerl wrote: post #10

Earlier quoted context omitted.

What's wrong with XML?

Im sure there are better answers here but my main issue is that attributes and child elements offer duplicate functionality. You could have 4 5 or you could have . There is often no consistency within a single spec over how this should be done let alone between different specs. JSON feels much more logical to me as well as being a whole lot simpler. If only it supported comments.

I always assumed attributes unless I was dealing with a composite or enumerable type.

Of course if someone else is producing the data then they can make a mess of things but I don't think that is specific to XML.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#69

Post by tonyedgecombe »

shmerl wrote: post #10
amscanne wrote: post #3

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…

What's wrong with XML?

The biggest problem for me is when people try and squeeze it into something it was never really meant for. I'm thinking of things like ANT files or XAML. In both of those cases they are too verbose and difficult to edit by hand. They are building an object model that would be better expressed as code.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#70

Post by shekharshan »

I couldn't understand this: "Domain is an instance of an operating system (or subsystem in case of container virtualization like OpenVZ and lxc) running on a virtualized machine provided by the hypervisor"

So the domain itself is a virtual machine? What makes it different from other guest virtual machinse?

Post reply on HN