Live data from Hacker News

Libvirt – The Unsung Hero of Cloud Computing (2013)

vyomtech.com

31–40 of 113 posts

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

#31
We're currently migrating from VMware to libvirt, we discovered the cockpit project and cockpit-machines to manage VMs:

https://cockpit-project.org/

cockpit-machines is available in a recent version in debian backports, installing it is trivial, no configuration, https://hostname:9090/ and just works.

RedHat announced that cockpit will be the long term successor of virt-manager:

https://www.redhat.com/en/blog/managing-virtual-machines-rhe...

https://blog.wikichoon.com/2020/06/virt-manager-deprecated-i...

cockpit has frequent releases, latest:

https://cockpit-project.org/blog/cockpit-227.html

It hasn't all the features of virt-manager, far from it, but looks promising.

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

#32
post #8
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…

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…

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

Do this with libvirt please and report back how it went :)

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

#33
post #15
post #10

Earlier quoted context omitted.

What's wrong with XML?

I’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…

Parent asked what's wrong with XML, not what's wrong with DOM. Does XML actually even define a special meaning for the `id` attribute?

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

#34
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.

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

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

#35
post #15
post #10

Earlier quoted context omitted.

What's wrong with XML?

I’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…

Never seen getElementByID being used for XML data (not somethinghtml)...

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

#36
post #15
post #10

Earlier quoted context omitted.

What's wrong with XML?

I’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…

If only you could specify in your schema that element must be unique. But wait a minute ! Actually, you can. That's what the unique attribute does.

And here lies the main problem of XML. As a technology, it is better than its reputation. Sadly, next to no one knows how to use it properly.

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

#37
post #8
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…

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…

INI only supports 2 levels of hierarchy? That is not equivalent.

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

#38
post #15
post #10

Earlier quoted context omitted.

What's wrong with XML?

I’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…

Why aren'y you just using xpath? There are mature and powerful xpath libraries in all major languages.

Of course if you use only one limited tool which was never meant to be the main manipulator of xml (getElementByID), then you'll run into problems. It is like never using regexp and complaining that simple strings are a bad data structure.

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

#39
post #22
post #15

Earlier quoted context omitted.

I’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…

I presume JSON is less ambiguous and easier to validate and parse?

JSON doesn't even have IDs, so in this particular regard the (similar) tool to what the poster uses doesn't even exist for JSON. So no, it would not be correct to say that in this particular regard JSON is somehow easier to parse.

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

#40

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.

The problem we ran into is that they can all be configured to do whatever. There's no consistently or standard
Post reply on HN