hi all:
When I install ovirt-node, after two days I found this version by the
question and I have some local storage of data on the inside, I want to upgrade
ovirt-node, but I found the following error.
all Hacker, please help me out a good idea...
[Errno 30] Read-only file system:
'liveos/grub'
Traceback(most recent call lash):
File
"/usr/libexex/ovirt-config-installer". line 1087 in start
self.upgrade_node()
File
"/usr/libexex/ovirt-config-installer". line 886, in upgrade_node()
boot_setup = install.ovirt_boot_setup()
File
"/usr/lib/python2.6/site-paceages/ovirtnode/install.py", line 391, in
ovirt_boot_setup
File
"/usr/lib64/python2.6/os.py", line 157 in makedirs
OSError:[Error 30] Read-only file system:
'/liveos/grub'
I at least tried mounting the LABEL=Root partition to /liveos, I was told it
is busy, but I couldn't find out why it was busy, because I ran into the
squashfs errors, which appeared indmesg as soon as I used tools like findmnt
etc.
------------------ Original ------------------
From: "devel-request";<devel-requ...@ovirt.org>;
Date: Wed, Dec 3, 2014 09:04 PM
To: "devel"<devel@ovirt.org>;
Subject: Devel Digest, Vol 9, Issue 8
Send Devel mailing list submissions to
devel@ovirt.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ovirt.org/mailman/listinfo/devel
or, via email, send a message with subject or body 'help' to
devel-requ...@ovirt.org
You can reach the person managing the list at
devel-ow...@ovirt.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Devel digest..."
Today's Topics:
1. [QE][ACTION REQUIRED] oVirt 3.6.0 status (Sandro Bonazzola)
2. Re: ioprocess 0.14.0 released (Yeela Kaplan)
3. Re: ioprocess 0.14.0 released (Michal Skrivanek)
4. Re: Important change in UI plugins REST API integration
(Yaniv Dary)
5. Re: hosted-engine setup/migration features for 3.6 (Bob Doolittle)
6. Re: hosted-engine setup/migration features for 3.6
(Yedidyah Bar David)
----------------------------------------------------------------------
Message: 1
Date: Wed, 03 Dec 2014 10:37:19 +0100
From: Sandro Bonazzola <sbona...@redhat.com>
To: "devel@ovirt.org" <devel@ovirt.org>, "us...@ovirt.org"
<us...@ovirt.org>
Subject: [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.6.0 status
Message-ID: <547ed9cf.2050...@redhat.com>
Content-Type: text/plain; charset=iso-8859-15
Hi,
Release criteria discussion has been closed with last week oVirt sync meeting
[1].
Release management for 3.6.0 [2] will soon be updated with the accepted changes
in release criteria.
The remaining key milestones for this release must now be scheduled.
For reference, external project schedules we're tracking are:
Fedora 21: 2014-12-09
Fedora 22: 2015-XX-XX
GlusterFS 3.7: 2015-04-29
OpenStack Kilo: 2015-04-30
Two different proposals have been made about above scheduling [3]:
1) extend the cycle to 10 months for allowing to include a large feature set
2) reduce the cycle to less than 6 months and split features over 3.6 and 3.7
Feature proposed for 3.6.0 must now be collected in the 3.6 Google doc [4]
and reviewed by maintainers.
The tracker bug for 3.6.0 [5] currently shows no blockers.
There are 453 bugs [6] targeted to 3.6.0.
Excluding node and documentation bugs we have 430 bugs [7] targeted to 3.6.0.
[1]
http://resources.ovirt.org/meetings/ovirt/2014/ovirt.2014-11-26-15.07.log.html
[2] http://www.ovirt.org/OVirt_3.6_Release_Management
[3] http://lists.ovirt.org/pipermail/users/2014-November/028875.html
[4] http://goo.gl/9X3G49
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1155425
[6] http://goo.gl/zwkF3r
[7] http://goo.gl/ZbUiMc
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
------------------------------
Message: 2
Date: Wed, 3 Dec 2014 04:49:18 -0500 (EST)
From: Yeela Kaplan <ykap...@redhat.com>
To: Michal Skrivanek <michal.skriva...@redhat.com>
Cc: Oved Ourfali <ov...@redhat.com>, devel@ovirt.org, Martyn Taylor
<mtay...@redhat.com>
Subject: Re: [ovirt-devel] ioprocess 0.14.0 released
Message-ID:
<1719244357.5997272.1417600158544.javamail.zim...@redhat.com>
Content-Type: text/plain; charset=utf-8
----- Original Message -----
> From: "Michal Skrivanek" <michal.skriva...@redhat.com>
> To: "Saggi Mizrahi" <smizr...@redhat.com>, "Oved Ourfali" <ov...@redhat.com>
> Cc: "Martyn Taylor" <mtay...@redhat.com>, devel@ovirt.org
> Sent: Wednesday, December 3, 2014 11:30:34 AM
> Subject: Re: [ovirt-devel] ioprocess 0.14.0 released
>
>
> On Oct 23, 2014, at 10:06 , Saggi Mizrahi <smizr...@redhat.com> wrote:
>
> >
> >
> > ----- Original Message -----
> >> From: "Michal Skrivanek" <michal.skriva...@redhat.com>
> >> To: "Saggi Mizrahi" <smizr...@redhat.com>
> >> Cc: devel@ovirt.org, "Martyn Taylor" <mtay...@redhat.com>
> >> Sent: Wednesday, October 22, 2014 10:55:34 AM
> >> Subject: Re: [ovirt-devel] ioprocess 0.14.0 released
> >>
> >>
> >> On Oct 21, 2014, at 10:59 , Saggi Mizrahi <smizr...@redhat.com> wrote:
> >>
> >>> ioprocess 0.14.0 has been tagged and released.
> >>>
> >>> The changelog includes:
> >>> - python-bindings: IOProcess objects can be collected by the GC
> >>> - python-bindings: Slave processes can optionally be collected
> >>> by zombie reaper
> >>>
> >>> It's recommended that everyone upgrade to the latest version.
> >>
> >> does this remove the annoying debug level messages in vdsm.log?
> >> or some other patch already addressed that?
> > Long long time ago. We added the TRACE level that is only
> > used during iprocess development.
> >
> > * Sun Jul 20 2014 Saggi Mizrahi <smizr...@redhat.com> 0.6.1-1
> > - Reduced logging even for debug level
>
> well, I still see that in *latest* 3.5 on QE systems. It's really annoying?
> might it be because of upgrades?
> Oved, IMHO it needs to be fixed/clarified ASAP, the logs are useless...
>
If QE has latest 3.5 then they should have ioprocess-0.14 installed,
if that's the case and there's still too much logging then the issue should be
checked.
> Thanks,
> michal
>
> >>
> >> Thanks,
> >> michal
> >>
> >>>
> >>> Please test and give karma:
> >>> https://admin.fedoraproject.org/updates/search/ioprocess-0.14.0
> >>>
> >>> Good day.
> >>> _______________________________________________
> >>> Devel mailing list
> >>> Devel@ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/devel
> >>
> >>
>
> _______________________________________________
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
------------------------------
Message: 3
Date: Wed, 3 Dec 2014 10:57:33 +0100
From: Michal Skrivanek <michal.skriva...@redhat.com>
To: Yeela Kaplan <ykap...@redhat.com>
Cc: Oved Ourfali <ov...@redhat.com>, devel@ovirt.org, Martyn Taylor
<mtay...@redhat.com>
Subject: Re: [ovirt-devel] ioprocess 0.14.0 released
Message-ID: <746ee06d-1c7c-46c3-8432-0949536c7...@redhat.com>
Content-Type: text/plain; charset=windows-1252
On Dec 3, 2014, at 10:49 , Yeela Kaplan <ykap...@redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Michal Skrivanek" <michal.skriva...@redhat.com>
>> To: "Saggi Mizrahi" <smizr...@redhat.com>, "Oved Ourfali" <ov...@redhat.com>
>> Cc: "Martyn Taylor" <mtay...@redhat.com>, devel@ovirt.org
>> Sent: Wednesday, December 3, 2014 11:30:34 AM
>> Subject: Re: [ovirt-devel] ioprocess 0.14.0 released
>>
>>
>> On Oct 23, 2014, at 10:06 , Saggi Mizrahi <smizr...@redhat.com> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michal Skrivanek" <michal.skriva...@redhat.com>
>>>> To: "Saggi Mizrahi" <smizr...@redhat.com>
>>>> Cc: devel@ovirt.org, "Martyn Taylor" <mtay...@redhat.com>
>>>> Sent: Wednesday, October 22, 2014 10:55:34 AM
>>>> Subject: Re: [ovirt-devel] ioprocess 0.14.0 released
>>>>
>>>>
>>>> On Oct 21, 2014, at 10:59 , Saggi Mizrahi <smizr...@redhat.com> wrote:
>>>>
>>>>> ioprocess 0.14.0 has been tagged and released.
>>>>>
>>>>> The changelog includes:
>>>>> - python-bindings: IOProcess objects can be collected by the GC
>>>>> - python-bindings: Slave processes can optionally be collected
>>>>> by zombie reaper
>>>>>
>>>>> It's recommended that everyone upgrade to the latest version.
>>>>
>>>> does this remove the annoying debug level messages in vdsm.log?
>>>> or some other patch already addressed that?
>>> Long long time ago. We added the TRACE level that is only
>>> used during iprocess development.
>>>
>>> * Sun Jul 20 2014 Saggi Mizrahi <smizr...@redhat.com> 0.6.1-1
>>> - Reduced logging even for debug level
>>
>> well, I still see that in *latest* 3.5 on QE systems. It's really annoying?
>> might it be because of upgrades?
>> Oved, IMHO it needs to be fixed/clarified ASAP, the logs are useless...
>>
>
> If QE has latest 3.5 then they should have ioprocess-0.14 installed,
> if that's the case and there's still too much logging then the issue should
> be checked.
Ha! indeed it was not the case. The system as somehow missing many updates,
including ioprocess.
It should have probably been enforced?but I agree if one does a proper yum
update it should work (I didn't try it yet;-)
Thanks,
michal
>
>> Thanks,
>> michal
>>
>>>>
>>>> Thanks,
>>>> michal
>>>>
>>>>>
>>>>> Please test and give karma:
>>>>> https://admin.fedoraproject.org/updates/search/ioprocess-0.14.0
>>>>>
>>>>> Good day.
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel@ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
------------------------------
Message: 4
Date: Wed, 3 Dec 2014 05:02:19 -0500 (EST)
From: Yaniv Dary <yd...@redhat.com>
To: Vojtech Szocs <vsz...@redhat.com>
Cc: devel@ovirt.org
Subject: Re: [ovirt-devel] Important change in UI plugins REST API
integration
Message-ID:
<1781152095.22179849.1417600939871.javamail.zim...@redhat.com>
Content-Type: text/plain; charset=utf-8
Does this affect any 3rd parties that implemented UI plugins?
Will they need to change anything or is this change more a behaviour change
only?
Yaniv
----- Original Message -----
> From: "Vojtech Szocs" <vsz...@redhat.com>
> To: "Alon Bar-Lev" <alo...@redhat.com>
> Cc: devel@ovirt.org
> Sent: Tuesday, December 2, 2014 7:12:21 PM
> Subject: Re: [ovirt-devel] Important change in UI plugins REST API integration
>
>
>
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alo...@redhat.com>
> > To: "Sven Kieske" <s.kie...@mittwald.de>
> > Cc: devel@ovirt.org
> > Sent: Tuesday, December 2, 2014 9:43:18 AM
> > Subject: Re: [ovirt-devel] Important change in UI plugins REST API
> > integration
> >
> >
> >
> > ----- Original Message -----
> > > From: "Sven Kieske" <s.kie...@mittwald.de>
> > > To: devel@ovirt.org
> > > Sent: Tuesday, December 2, 2014 10:41:00 AM
> > > Subject: Re: [ovirt-devel] Important change in UI plugins REST API
> > > integration
> > >
> > >
> > >
> > > On 01/12/14 20:26, Vojtech Szocs wrote:
> > > > In other words, usability of REST session ID is now strictly
> > > > scoped to GUI user being authenticated. If the user logs in,
> > > > (always) new REST session ID will be passed to all UI plugins.
> > > > If the user logs out, REST session ID will not work anymore.
> > >
> > > What if I use just REST for logging in and doing something
> > > without any GUI interaction at all?
>
> This announcement was about UI plugins in WebAdmin. If you use
> Engine REST API without any GUI interaction involved, you aren't
> affected in any way.
>
> > >
> > > this reads a little like: you always need an open web gui
> > > to be able to use REST, which does not make sense at all.
>
> Sorry if my email confused you. It should read like: if you're
> an author of oVirt UI plugin for WebAdmin, please beware that
> REST API session ID (automatically acquired by UI plugin infra
> on behalf of all UI plugins) will not work after GUI logout.
>
> >
> > If you provide your own credentials nothing changed.
> >
> > The change is only effecting RESTAPI usage within the user interface using
> > the credentials obtained interactively from the user within login page.
> >
> > > So I guess I'm misreading this?
> > >
> > > --
> > > Mit freundlichen Gr??en / Regards
> > >
> > > Sven Kieske
> > >
> > > Systemadministrator
> > > Mittwald CM Service GmbH & Co. KG
> > > K?nigsberger Stra?e 6
> > > 32339 Espelkamp
> > > T: +49-5772-293-100
> > > F: +49-5772-293-333
> > > https://www.mittwald.de
> > > Gesch?ftsf?hrer: Robert Meyer
> > > St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad
> > > Oeynhausen
> > > Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad
> > > Oeynhausen
> > > _______________________________________________
> > > Devel mailing list
> > > Devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> > _______________________________________________
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
------------------------------
Message: 5
Date: Wed, 3 Dec 2014 07:53:24 -0500
From: Bob Doolittle <b...@doolittle.us.com>
To: Yedidyah Bar David <d...@redhat.com>
Cc: users-ovirt <us...@ovirt.org>, "devel@ovirt.org" <devel@ovirt.org>
Subject: Re: [ovirt-devel] hosted-engine setup/migration features for
3.6
Message-ID:
<ca+4jj+szppqquptbgcw+v0s2rcvgbzamlqoynnqag5xr5gl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Resending - inadvertently dropped CCs.
On Wed, Dec 3, 2014 at 7:50 AM, Bob Doolittle <b...@doolittle.us.com> wrote:
> Another issue with that page is that it assumes a remote database. I am
> not sure what percentage of cases have remote databases but clearly many
> (most?) do not, since that's not default behavior. So that page definitely
> needs attention. See:
> https://bugzilla.redhat.com/show_bug.cgi?id=1099995
> https://bugzilla.redhat.com/show_bug.cgi?id=1099998
>
> Some of us have wanted to disable global maintenance upon bootup by adding
> a systemd service on Fedora 20 (since you must enable global maintenance to
> shut it down cleanly), and have found it impossible to create the necessary
> systemd dependencies. It seems that (at least with 3.4) hosted-engine
> --set-maintenance --mode=none will return an error for several seconds
> after all other services have started and it's not clear what can be waited
> upon in order to issue the command with assurance it will complete
> successfully. This isn't strictly a setup/migration issue but it is an
> issue with setting up a desired configuration with hosted-engine. The way
> to reproduce this is simply to wait until gdm-greeter displays the login
> prompt, ssh into the system and execute hosted-engine --set-maintenance
> --mode=none and observe the error. Or create a systemd service that depends
> upon (waits for) the latest-possible service, try executing the command
> there, and observe the error. Ideally there would be some external
> observable event which a systemd service could depend upon, when
> hosted-engine is ready to do its thing.
>
> Regards,
> Bob
>
>
> On Wed, Dec 3, 2014 at 2:59 AM, Yedidyah Bar David <d...@redhat.com>
> wrote:
>
>> Hi all,
>>
>> We already have quite a lot of open ovirt-hosted-engine-setup bugs for
>> 3.6 [1].
>>
>> Yesterday I tried helping someone on irc who planned to migrate to
>> hosted-engine
>> manually, and without knowing (so it seems) that such a feature exists.
>> He had
>> an engine set up on a physical host, prepared a VM for it, and asked
>> about migrating
>> the engine to the VM. In principle this works, but the final result will
>> be a
>> hosted-engine, where the engine manages a VM the runs itself, without
>> knowing it,
>> and without HA.
>>
>> The current recommended migration flow is described in [2]. This page is
>> perhaps
>> a bit outdated, perhaps missing some details etc., but principally works.
>> The main
>> issue with it, AFAICT after discussing this a bit with few people, is
>> that it
>> requires a new clean host.
>>
>> I'd like to hear what people here think about such and similar flows.
>>
>> If you already had an engine and migrated to hosted-engine, what was
>> good, what
>> was bad, what would you like to change?
>>
>> If you plan such a migration, what do you find missing currently?
>>
>> [1] http://red.ht/1vle8Vv
>> [2] http://www.ovirt.org/Migrate_to_Hosted_Engine
>>
>> Best,
>> --
>> Didi
>> _______________________________________________
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ovirt.org/pipermail/devel/attachments/20141203/d8ab2364/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 3 Dec 2014 08:04:17 -0500 (EST)
From: Yedidyah Bar David <d...@redhat.com>
To: Bob Doolittle <b...@doolittle.us.com>
Cc: users <us...@ovirt.org>, devel <devel@ovirt.org>
Subject: Re: [ovirt-devel] hosted-engine setup/migration features for
3.6
Message-ID:
<1810755665.22244497.1417611857805.javamail.zim...@redhat.com>
Content-Type: text/plain; charset=utf-8
----- Original Message -----
> From: "Bob Doolittle" <b...@doolittle.us.com>
> To: "Yedidyah Bar David" <d...@redhat.com>
> Sent: Wednesday, December 3, 2014 2:50:12 PM
> Subject: Re: [ovirt-devel] hosted-engine setup/migration features for 3.6
>
> Another issue with that page is that it assumes a remote database. I am not
> sure what percentage of cases have remote databases but clearly many
> (most?) do not, since that's not default behavior.
I agree.
> So that page definitely
> needs attention. See:
> https://bugzilla.redhat.com/show_bug.cgi?id=1099995
Indeed. Note that this isn't specific to hosted-engine, it's the same for
any migration using engine-backup to backup/restore, therefore there is
a link to its page in the top, where this is more detailed. We also have
a bug [3] to automate this.
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1064503
> https://bugzilla.redhat.com/show_bug.cgi?id=1099998
>
> Some of us have wanted to disable global maintenance upon bootup by adding
> a systemd service on Fedora 20 (since you must enable global maintenance to
> shut it down cleanly), and have found it impossible to create the necessary
> systemd dependencies. It seems that (at least with 3.4) hosted-engine
> --set-maintenance --mode=none will return an error for several seconds
> after all other services have started and it's not clear what can be waited
> upon in order to issue the command with assurance it will complete
> successfully. This isn't strictly a setup/migration issue but it is an
> issue with setting up a desired configuration with hosted-engine. The way
> to reproduce this is simply to wait until gdm-greeter displays the login
> prompt, ssh into the system and execute hosted-engine --set-maintenance
> --mode=none and observe the error. Or create a systemd service that depends
> upon (waits for) the latest-possible service, try executing the command
> there, and observe the error. Ideally there would be some external
> observable event which a systemd service could depend upon, when
> hosted-engine is ready to do its thing.
Adding Jiri for that. Do you have an open bug?
Thanks,
>
> Regards,
> Bob
>
>
> On Wed, Dec 3, 2014 at 2:59 AM, Yedidyah Bar David <d...@redhat.com> wrote:
>
> > Hi all,
> >
> > We already have quite a lot of open ovirt-hosted-engine-setup bugs for 3.6
> > [1].
> >
> > Yesterday I tried helping someone on irc who planned to migrate to
> > hosted-engine
> > manually, and without knowing (so it seems) that such a feature exists. He
> > had
> > an engine set up on a physical host, prepared a VM for it, and asked about
> > migrating
> > the engine to the VM. In principle this works, but the final result will
> > be a
> > hosted-engine, where the engine manages a VM the runs itself, without
> > knowing it,
> > and without HA.
> >
> > The current recommended migration flow is described in [2]. This page is
> > perhaps
> > a bit outdated, perhaps missing some details etc., but principally works.
> > The main
> > issue with it, AFAICT after discussing this a bit with few people, is that
> > it
> > requires a new clean host.
> >
> > I'd like to hear what people here think about such and similar flows.
> >
> > If you already had an engine and migrated to hosted-engine, what was good,
> > what
> > was bad, what would you like to change?
> >
> > If you plan such a migration, what do you find missing currently?
> >
> > [1] http://red.ht/1vle8Vv
> > [2] http://www.ovirt.org/Migrate_to_Hosted_Engine
> >
> > Best,
> > --
> > Didi
> > _______________________________________________
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
>
--
Didi
------------------------------
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
End of Devel Digest, Vol 9, Issue 8
***********************************_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
