[ovirt-devel] upgrade ovirt-node 2.6 error
天天行动
120828490 at qq.com
Fri Dec 5 15:17:29 UTC 2014
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-request at ovirt.org>;
Date: Wed, Dec 3, 2014 09:04 PM
To: "devel"<devel at ovirt.org>;
Subject: Devel Digest, Vol 9, Issue 8
Send Devel mailing list submissions to
devel at 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-request at ovirt.org
You can reach the person managing the list at
devel-owner at 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 <sbonazzo at redhat.com>
To: "devel at ovirt.org" <devel at ovirt.org>, "Users at ovirt.org"
<Users at ovirt.org>
Subject: [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.6.0 status
Message-ID: <547ED9CF.2050408 at 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 <ykaplan at redhat.com>
To: Michal Skrivanek <michal.skrivanek at redhat.com>
Cc: Oved Ourfali <ovedo at redhat.com>, devel at ovirt.org, Martyn Taylor
<mtaylor at redhat.com>
Subject: Re: [ovirt-devel] ioprocess 0.14.0 released
Message-ID:
<1719244357.5997272.1417600158544.JavaMail.zimbra at redhat.com>
Content-Type: text/plain; charset=utf-8
----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>, "Oved Ourfali" <ovedo at redhat.com>
> Cc: "Martyn Taylor" <mtaylor at redhat.com>, devel at 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 <smizrahi at redhat.com> wrote:
>
> >
> >
> > ----- Original Message -----
> >> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> >> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> >> Cc: devel at ovirt.org, "Martyn Taylor" <mtaylor at 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 <smizrahi at 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 <smizrahi at 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 at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/devel
> >>
> >>
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
------------------------------
Message: 3
Date: Wed, 3 Dec 2014 10:57:33 +0100
From: Michal Skrivanek <michal.skrivanek at redhat.com>
To: Yeela Kaplan <ykaplan at redhat.com>
Cc: Oved Ourfali <ovedo at redhat.com>, devel at ovirt.org, Martyn Taylor
<mtaylor at redhat.com>
Subject: Re: [ovirt-devel] ioprocess 0.14.0 released
Message-ID: <746EE06D-1C7C-46C3-8432-0949536C7544 at redhat.com>
Content-Type: text/plain; charset=windows-1252
On Dec 3, 2014, at 10:49 , Yeela Kaplan <ykaplan at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>> To: "Saggi Mizrahi" <smizrahi at redhat.com>, "Oved Ourfali" <ovedo at redhat.com>
>> Cc: "Martyn Taylor" <mtaylor at redhat.com>, devel at 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 <smizrahi at redhat.com> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>>>> To: "Saggi Mizrahi" <smizrahi at redhat.com>
>>>> Cc: devel at ovirt.org, "Martyn Taylor" <mtaylor at 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 <smizrahi at 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 <smizrahi at 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 at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
------------------------------
Message: 4
Date: Wed, 3 Dec 2014 05:02:19 -0500 (EST)
From: Yaniv Dary <ydary at redhat.com>
To: Vojtech Szocs <vszocs at redhat.com>
Cc: devel at ovirt.org
Subject: Re: [ovirt-devel] Important change in UI plugins REST API
integration
Message-ID:
<1781152095.22179849.1417600939871.JavaMail.zimbra at 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" <vszocs at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: devel at 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" <alonbl at redhat.com>
> > To: "Sven Kieske" <s.kieske at mittwald.de>
> > Cc: devel at 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.kieske at mittwald.de>
> > > To: devel at 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 at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
------------------------------
Message: 5
Date: Wed, 3 Dec 2014 07:53:24 -0500
From: Bob Doolittle <bob at doolittle.us.com>
To: Yedidyah Bar David <didi at redhat.com>
Cc: users-ovirt <users at ovirt.org>, "devel at ovirt.org" <devel at ovirt.org>
Subject: Re: [ovirt-devel] hosted-engine setup/migration features for
3.6
Message-ID:
<CA+4jJ+szppQQuPTBgCW+v0s2rcVgBzamLQoYnnqAG5xR5gLarg at 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 <bob at 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 <didi at 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 at 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 <didi at redhat.com>
To: Bob Doolittle <bob at doolittle.us.com>
Cc: users <users at ovirt.org>, devel <devel at ovirt.org>
Subject: Re: [ovirt-devel] hosted-engine setup/migration features for
3.6
Message-ID:
<1810755665.22244497.1417611857805.JavaMail.zimbra at redhat.com>
Content-Type: text/plain; charset=utf-8
----- Original Message -----
> From: "Bob Doolittle" <bob at doolittle.us.com>
> To: "Yedidyah Bar David" <didi at 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 <didi at 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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
>
--
Didi
------------------------------
_______________________________________________
Devel mailing list
Devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
End of Devel Digest, Vol 9, Issue 8
***********************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20141205/0c7c32cf/attachment-0001.html>
More information about the Devel
mailing list