On Sun, Oct 14, 2018 at 01:41:27PM +0200, Andrea Bolognani wrote:
> On Fri, 2018-10-12 at 16:21 +0100, Daniel P. Berrangé wrote:
> > On Wed, Oct 10, 2018 at 01:09:50PM +0200, Andrea Bolognani wrote:
> > > So once we have these changes in place, command line users can be
> > > pretty much
On Fri, 2018-10-12 at 16:21 +0100, Daniel P. Berrangé wrote:
> On Wed, Oct 10, 2018 at 01:09:50PM +0200, Andrea Bolognani wrote:
> > So once we have these changes in place, command line users can be
> > pretty much completely isolated from libvirt defaults, just like
> > virt-manager and oVirt and
On 10/12/2018 11:21 AM, Daniel P. Berrangé wrote:
> On Wed, Oct 10, 2018 at 01:09:50PM +0200, Andrea Bolognani wrote:
>> I wonder if showing a message suggesting to use virt-xml instead
>> when 'virsh edit' or 'virsh attach-device' are called would be
>> considered acceptable at that point?
>
On Wed, Oct 10, 2018 at 01:09:50PM +0200, Andrea Bolognani wrote:
> Pavel helpfully pointed out that such a client already exists:
> it's called virt-xml and it's part of virt-manager.
>
> It needs a few tweaks before it can really fit the bill, but once
> that's been taken care of you should be
Picking up the thread again from here because it looks like as
sensible a point as any.
On Tue, 2018-10-02 at 18:26 +0200, Andrea Bolognani wrote:
> q35 is what sparked the discussion, but it's far from the only
> offender. For example, if I create a guest using
>
> $ virt-install \
>
On Fri, 2018-10-05 at 12:10 +0100, Daniel P. Berrangé wrote:
> On Fri, Oct 05, 2018 at 12:33:57PM +0200, Jiri Denemark wrote:
> > OK, but if it's us choosing some default which QEMU considers
> > deprecated, it's us who should dealt with it. That is, change the
> > default IMHO. Sure apps could
On Fri, 2018-10-05 at 12:05 +0100, Daniel P. Berrangé wrote:
> On Fri, Oct 05, 2018 at 11:38:14AM +0200, Andrea Bolognani wrote:
> > Warnings printed on stderr -> users and developers will actually
> > see them, be annoyed by them, eventually cave in and act upon them.
> >
> > Warnings written to
On Fri, Oct 05, 2018 at 12:10:51 +0100, Daniel P. Berrangé wrote:
> On Fri, Oct 05, 2018 at 12:33:57PM +0200, Jiri Denemark wrote:
> > On Fri, Oct 05, 2018 at 09:54:02 +0100, Daniel P. Berrangé wrote:
> > > On Fri, Oct 05, 2018 at 10:34:33AM +0200, Jiri Denemark wrote:
> > > > On Thu, Oct 04, 2018
On Fri, 2018-10-05 at 11:56 +0200, Pavel Hrdina wrote:
> On Fri, Oct 05, 2018 at 11:38:14AM +0200, Andrea Bolognani wrote:
> > Warnings printed on stderr -> users and developers will actually
> > see them, be annoyed by them, eventually cave in and act upon them.
> >
> > Warnings written to a log
On Fri, Oct 05, 2018 at 12:33:57PM +0200, Jiri Denemark wrote:
> On Fri, Oct 05, 2018 at 09:54:02 +0100, Daniel P. Berrangé wrote:
> > On Fri, Oct 05, 2018 at 10:34:33AM +0200, Jiri Denemark wrote:
> > > On Thu, Oct 04, 2018 at 14:13:41 +0100, Daniel P. Berrangé wrote:
> > > > The problem with
On Fri, Oct 05, 2018 at 11:38:14AM +0200, Andrea Bolognani wrote:
> On Fri, 2018-10-05 at 09:54 +0100, Daniel P. Berrangé wrote:
> > On Fri, Oct 05, 2018 at 10:34:33AM +0200, Jiri Denemark wrote:
> > > But what if QEMU (or any other hypervisor) marks something (device
> > > model, machine type) as
On Fri, Oct 05, 2018 at 09:54:02 +0100, Daniel P. Berrangé wrote:
> On Fri, Oct 05, 2018 at 10:34:33AM +0200, Jiri Denemark wrote:
> > On Thu, Oct 04, 2018 at 14:13:41 +0100, Daniel P. Berrangé wrote:
> > > The problem with saying applications were doing it "wrong" is that
> > > this definition of
On Fri, Oct 05, 2018 at 11:38:14AM +0200, Andrea Bolognani wrote:
> On Fri, 2018-10-05 at 09:54 +0100, Daniel P. Berrangé wrote:
> > On Fri, Oct 05, 2018 at 10:34:33AM +0200, Jiri Denemark wrote:
> > > But what if QEMU (or any other hypervisor) marks something (device
> > > model, machine type) as
On Fri, 2018-10-05 at 09:54 +0100, Daniel P. Berrangé wrote:
> On Fri, Oct 05, 2018 at 10:34:33AM +0200, Jiri Denemark wrote:
> > But what if QEMU (or any other hypervisor) marks something (device
> > model, machine type) as deprecated and we use that deprecated value as
> > our default. Shouldn't
On Thu, 2018-10-04 at 16:04 +0100, Daniel P. Berrangé wrote:
> On Thu, Oct 04, 2018 at 04:49:43PM +0200, Andrea Bolognani wrote:
> > I agree that having better documentation would help, and we should
> > definitely work towards that goal.
> >
> > However, I'm fairly confident trying to address
On Fri, Oct 05, 2018 at 10:34:33AM +0200, Jiri Denemark wrote:
> On Thu, Oct 04, 2018 at 14:13:41 +0100, Daniel P. Berrangé wrote:
> > The problem with saying applications were doing it "wrong" is that
> > this definition of "wrong" changes. Applications were perfectly
> > justified in not
On Thu, Oct 04, 2018 at 14:13:41 +0100, Daniel P. Berrangé wrote:
> The problem with saying applications were doing it "wrong" is that
> this definition of "wrong" changes. Applications were perfectly
> justified in not providing a machine type, because the concept
> didn't even exist in earlier
On Thu, 2018-10-04 at 15:26 +0100, Daniel P. Berrangé wrote:
> On Thu, Oct 04, 2018 at 04:08:31PM +0200, Andrea Bolognani wrote:
> > I think keeping up with changes in libraries you consume is simply
> > due diligence for developers, and while of course that takes up
> > some of your time and is
On Thu, Oct 04, 2018 at 04:49:43PM +0200, Andrea Bolognani wrote:
> On Thu, 2018-10-04 at 14:13 +0100, Daniel P. Berrangé wrote:
> > I think we're largely missing the bigger picture here. Configuring
> > guests, and using libvirt APIs in general, can be very complicated.
> >
> > We provide basic
On Thu, 2018-10-04 at 14:13 +0100, Daniel P. Berrangé wrote:
> On Tue, Oct 02, 2018 at 06:26:12PM +0200, Andrea Bolognani wrote:
> > However, libvirt's own default for x86_64 guests' network devices is
> > rtl8139, which means that if I later 'virsh edit' the guest or 'virsh
> > attach-device' a
On Tue, Oct 02, 2018 at 04:14:39PM +0200, Andrea Bolognani wrote:
Background
==
We have plenty of features in libvirt, some of which were designed at
a time when the virtualization story was much more straightforward
than the multi-architecture, multi-hypervisor, multi-machine world we
On Thu, Oct 04, 2018 at 04:08:31PM +0200, Andrea Bolognani wrote:
> On Thu, 2018-10-04 at 14:02 +0100, Daniel P. Berrangé wrote:
> > On Thu, Oct 04, 2018 at 01:38:33PM +0200, Andrea Bolognani wrote:
> > > GTK+ does it, Qt does it; and I'm willing to bet there are more
> > > applications linking
On Thu, 2018-10-04 at 14:02 +0100, Daniel P. Berrangé wrote:
> On Thu, Oct 04, 2018 at 01:38:33PM +0200, Andrea Bolognani wrote:
> > GTK+ does it, Qt does it; and I'm willing to bet there are more
> > applications linking against either of them than there are linking
> > against libvirt.
>
> I
On Tue, Oct 02, 2018 at 06:26:12PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-10-02 at 17:19 +0200, Peter Krempa wrote:
> > On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote:
> [...]
> > > Two concrete examples are considered here: one is the
> > > virConnectNumOfDomains() API
On Thu, Oct 04, 2018 at 02:06:54PM +0200, Andrea Bolognani wrote:
> On Thu, 2018-10-04 at 13:36 +0200, Pavel Hrdina wrote:
> > Runtime deprecation warning in C code is wrong in my opinion and even
> > though there are some project doing it we should not do it.
> > Deprecation warning is for
On Thu, Oct 04, 2018 at 01:38:33PM +0200, Andrea Bolognani wrote:
> GTK+ does it, Qt does it; and I'm willing to bet there are more
> applications linking against either of them than there are linking
> against libvirt.
I don't think that's a positive example. As a developer who has
used GTK for
On Thu, 2018-10-04 at 13:36 +0200, Pavel Hrdina wrote:
> Runtime deprecation warning in C code is wrong in my opinion and even
> though there are some project doing it we should not do it.
> Deprecation warning is for developers, not for users.
>
> Yes, adding deprecation warning into libvirt
On Thu, 2018-10-04 at 13:16 +0200, Michal Privoznik wrote:
> On 10/04/2018 01:03 PM, Andrea Bolognani wrote:
> > That said, in order to reap real benefits, deprecating features
> > should go hand in hand with having a well-defined support policy
> > that includes a timeline describing how, after a
On Thu, Oct 04, 2018 at 01:16:46PM +0200, Michal Privoznik wrote:
> On 10/04/2018 01:03 PM, Andrea Bolognani wrote:
> > On Wed, 2018-10-03 at 10:44 +0200, Erik Skultety wrote:
> >> On Wed, Oct 03, 2018 at 09:13:00AM +0200, Michal Privoznik wrote:
> >>> On 10/02/2018 05:38 PM, Pavel Hrdina wrote:
>
On 10/04/2018 01:03 PM, Andrea Bolognani wrote:
> On Wed, 2018-10-03 at 10:44 +0200, Erik Skultety wrote:
>> On Wed, Oct 03, 2018 at 09:13:00AM +0200, Michal Privoznik wrote:
>>> On 10/02/2018 05:38 PM, Pavel Hrdina wrote:
Definitely agree with Peter, having a runtime warning for issue that
On Wed, 2018-10-03 at 10:44 +0200, Erik Skultety wrote:
> On Wed, Oct 03, 2018 at 09:13:00AM +0200, Michal Privoznik wrote:
> > On 10/02/2018 05:38 PM, Pavel Hrdina wrote:
> > > Definitely agree with Peter, having a runtime warning for issue that
> > > you cannot change in runtime situation is
On Tue, Oct 02, 2018 at 18:26:12 +0200, Andrea Bolognani wrote:
> On Tue, 2018-10-02 at 17:19 +0200, Peter Krempa wrote:
> > Our documentation states in multiple places that fields not populated by
> > the user are mostly hypervisor dependant what the default will become.
> >
> > In my opinion
On Wed, Oct 03, 2018 at 09:13:00AM +0200, Michal Privoznik wrote:
> On 10/02/2018 05:38 PM, Pavel Hrdina wrote:
> > On Tue, Oct 02, 2018 at 05:19:30PM +0200, Peter Krempa wrote:
> >> On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote:
> >>> Background
> >>> ==
> >>
> >> [...]
>
On 10/02/2018 05:38 PM, Pavel Hrdina wrote:
> On Tue, Oct 02, 2018 at 05:19:30PM +0200, Peter Krempa wrote:
>> On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote:
>>> Background
>>> ==
>>
>> [...]
>>
>>> Two concrete examples are considered here: one is the
>>>
On 10/2/18 10:14 AM, Andrea Bolognani wrote:
> Background
> ==
>
> We have plenty of features in libvirt, some of which were designed at
> a time when the virtualization story was much more straightforward
> than the multi-architecture, multi-hypervisor, multi-machine world we
>
I feel like I've addressed most of your points in my reply to
Peter's message so I won't repeat the same arguments and will
snip quite aggressively, but please let me know if I've missed
anything.
On Tue, 2018-10-02 at 17:38 +0200, Pavel Hrdina wrote:
[...]
> But in this case I thing that it's
On Tue, 2018-10-02 at 17:19 +0200, Peter Krempa wrote:
> On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote:
[...]
> > Two concrete examples are considered here: one is the
> > virConnectNumOfDomains() API which, while known to be racy and having
> > non-racy alternatives, can still be
On Tue, Oct 02, 2018 at 05:19:30PM +0200, Peter Krempa wrote:
> On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote:
> > Background
> > ==
>
> [...]
>
> > Two concrete examples are considered here: one is the
> > virConnectNumOfDomains() API which, while known to be racy and
On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote:
> Background
> ==
[...]
> Two concrete examples are considered here: one is the
> virConnectNumOfDomains() API which, while known to be racy and having
> non-racy alternatives, can still be used by developers without
>
Background
==
We have plenty of features in libvirt, some of which were designed at
a time when the virtualization story was much more straightforward
than the multi-architecture, multi-hypervisor, multi-machine world we
currently live in and, while we have found ways to keep the APIs
40 matches
Mail list logo
