Re: [ovirt-users] upgrade to 4.1

[Fabrice Bacchella]

> Le 23 avr. 2017 à 07:59, Yedidyah Bar David  a écrit :
> 
> 

> The main reason we require this is for pg_dump/pg_restore which are ran
> during setup/rollback (if needed). pg_dump can't know for sure that all
> the changes in the db were done using a client of its own version (that
> is, current machine usually), and if indeed a newer client was used, it
> might have used features that pg_dump of the lower version doesn't know
> how to back up (and especially pg_restore does not know how to restore).
> See also [1]. I seem to have tested there (can't remember anymore, see
> comment 13) 9.2 client with 9.5 server and it didn't work. pg_dump(1)
> manpage says:
> 
>   Because pg_dump is used to transfer data to newer versions of
>   PostgreSQL, the output of pg_dump can be expected to load into
>   PostgreSQL server versions newer than pg_dump's version.  pg_dump can
>   also dump from PostgreSQL servers older than its own version.
>   (Currently, servers back to version 7.0 are supported.) However,
>   pg_dump cannot dump from PostgreSQL servers newer than its own major
>   version; it will refuse to even try, rather than risk making an invalid
>   dump. Also, it is not guaranteed that pg_dump's output can be loaded
>   into a server of an older major version — not even if the dump was
>   taken from a server of that version. Loading a dump file into an older
>   server may require manual editing of the dump file to remove syntax not
>   understood by the older server. Use of the --quote-all-identifiers
>   option is recommended in cross-version cases, as it can prevent
>   problems arising from varying reserved-word lists in different
>   PostgreSQL versions.
> 

I don't get it, but I don't know pg so I might be wrong.

You have a client application (like ovirt) written using features from V1 of pg.

It's running on a server where version V2 is installing. For good reasons, V2 
>= V1 is needed.

The server is running a version V3. Again V3 >= V1 is needed.   Except for 
major version, does V3 => V2 is really needed ?

And for backup the problem is the same. It must probably know every features 
used in the application (so again being V1 or more). Why does it needs to match 
both V2 and V3 ?  It will probably fits V2 is installation is the same. But 
that not mandatory. In a java application, the client library might be a jar 
provided by the application and pg_dump a tool installed with native os 
packaging. But how can complain against V3 ?

But with ovirt we have V1=V2=V3, even for for patch level (9.4.8 against 
9.4.11). What kind of feature that ovirt don't know about might be missing ? I 
don't think ovirt might know about any 9.4 since you talked about version 9.2 
as the official supported version.


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] ETL service sampling has encountered an error. Please consult the service log for more details.

[Nicolás]

Any ideas on this?

Thanks.

El 20/04/17 a las 12:12, nico...@devels.es escribió:

Hi,

We're using oVirt 4.1.1.8 (upgraded yesterday) and since it has been 
showing some strange errors I'd like to know about:


ETL service sampling has encountered an error. Please consult the 
service log for more details.


I'm attaching the engine log FWIW. This message showed up at 11:07:04 
but in the log I see the exceptions started 1 minute ago.


Also, at 11:07:58 this event showed up:

Engine server is not responding.

And at 11:12:58 it seems to recover:

Engine server is up and running.

At 12:00:00 this message showed up:

ETL service aggregation to hourly tables has encountered an error. 
Please consult the service log for more details.


But relative to this one I see nothing in logs.

Could someone clarify what these error messages mean?

Thanks.


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] The web portal gives: Bad Request: 400

[Yaniv Kaul]

On Sun, Apr 23, 2017 at 2:32 PM, Arman Khalatyan  wrote:

> Hi Yaniv,
> I'm unfortunately there is nothing in the logs, it looks like a ovirt
> doesnot listen to the right interface.
> We have multiples interfaces internal and external access.
> We sometimes ago we renamed the engine name to work with the external ip
> address. Now it is listening only to the local address.
> To fix it i just added:
>
> /etc/ovirt-engine/engine.conf.d/99-setup-http-proxy.conf
>
>
And this file did not survive the upgrade?
Y.


>
> One need to dig more to fix it
>
>
> Am 20.04.2017 2:55 nachm. schrieb "Yaniv Kaul" :
>
>>
>>
>> On Thu, Apr 20, 2017 at 1:06 PM, Arman Khalatyan 
>> wrote:
>>
>>> After the recent upgrade from ovirt Version 4.1.1.6-1.el7.centos. to
>>> Version 4.1.1.8-1.el7.centos
>>>
>>> The web portal gives following error:
>>> Bad Request
>>>
>>> Your browser sent a request that this server could not understand.
>>>
>>> Additionally, a 400 Bad Request error was encountered while trying to
>>> use an ErrorDocument to handle the request.
>>>
>>>
>>> Are there any hints how to fix it?
>>>
>>
>> It'd be great if you could share some logs. The httpd logs, server.log
>> and engine.log, all might be useful.
>> Y.
>>
>>
>>> BTW the rest API works as expected, engine-setup went without errors.
>>>
>>> Thanks,
>>>
>>> Arman.
>>>
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Communicate between the guest vm's hosted on, different hosts on different data centres using OVS

[Linov Suresh]

I have created a separate network for 10G network and made central server
part of it. After that configured the OVN controller using vdsm-tool

vdsm-tool ovn-config  

Then added OVN provider to oVirt as an external network provider and
created a new network based on OVS. Now the new VM's we create use this new
network.

Thanks for your help!

On Fri, Apr 21, 2017 at 5:39 AM, Charles Tassell  wrote:

> Hmm, so you have 2 10G ports on each host.  1 port is currently in use
> with oVirt, and the other isn't?  Then I think you just add a new network
> in the Networks tab called OVNLink, then go into the Hosts tab, click on
> each host and then on the Network Interfaces tab in the bottom of the
> window and assign the unused 10G network device to that link.
>
> I haven't used OVN with oVirt, but that would work with regular networking
> so I think it should work with OVN.
>
> If the link is already in use, you should be able to do the same thing
> only when you add the new network set it up with a VLAN ID.  If you are
> going through a switch then the switch will have to be setup to handle the
> VLANs.
>
>
>
> On 2017-04-20 10:07 PM, Linov Suresh wrote:
>
> Hi Charles,
>
> We use an Ethernet cable to connect between the hosts through 10G port.
>
> We want to use the guest VM's hosted on different hosts 10G network. oVirt
> already supports SR-IOV. So we should guest 10G speed for our VM's.
>
> In KVM we can create a second bridge and add the 10G interface to the
> bridge would do the trick.
>
> But in oVirt how do we do this? We want to use our OVs network, which was
> created using OVN Provider.
>
>
>Linov Suresh
>
>
>
> On Thu, Apr 20, 2017 at 6:59 PM, Charles Tassell 
> wrote:
>
>> Hi Suresh,
>>
>>   You would need to connect the two OVN instances somehow.  If it's just
>> two single hosts, I think the easiest way would be to create a VPN
>> connection between the two hosts with OpenVPN or the like and then add the
>> tun/tap interfaces into the OVN on each box.  You might run into problems
>> if you start adding more hosts though, as if the host with the VPN goes
>> down it would disconnect the two datacenters.
>>
>>   If the two datacenters are on the same physical network (ie, you just
>> mean oVirt datacenter and not different colocation providers) then adding a
>> VLAN to the NICs connected to the OVN interface would work.  You would
>> probably have to setup some sort of channel bonding/LACP as you add more
>> hosts, but OVN should be able to handle that simply enough.
>>
>> On 2017-04-20 07:33 PM, users-requ...@ovirt.org wrote:
>>
>>> Date: Thu, 20 Apr 2017 14:43:26 -0400
>>> From: Linov Suresh 
>>> To: users@ovirt.org
>>> Subject: [ovirt-users] Communicate between the guest vm's hosted on
>>> different hosts on different data centres using OVS
>>> Message-ID:
>>> >> ail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hello,
>>>
>>> I have configured OVS network on oVirt 4.1.1, following the document
>>> https://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/
>>>
>>> I have created OVN Provider, and created new Logical Network for OVS
>>> using
>>> OVN Provider. I have synced the network also selected OVS when I created
>>> the cluster.
>>>
>>> I have two data centres and each data centre has one host each.
>>>
>>> Now I have created VM's selecting OVS network (not ovirtmgmt). VM's in
>>> the
>>> same data centre can talk to each other.
>>>
>>> How do i make the VM's hosted on different data centre can talk to each
>>> other?
>>>
>>> Appreciate your help in advance,
>>>
>>> Sincerely,
>>>
>>> Suresh.
>>>
>>
>>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] ETL service sampling has encountered an error. Please consult the service log for more details.

[Shirly Radco]

Hi Nicolas,

These are DWH error. I see in engine.log that around the time you are
referring to there are many connectipn errors to the postgresql database.
When DWH is unable to connect to the engine database and error is sent to
the ovirt-engine-history.log.
I don't see the error you are referring to in the engine.log.

The DWH samples every 20 second for statistics that are used to create the
ovirt dashboards.

If there is a problem with the postgres connection then the hourly
aggregation of the samples failed too.

I see that first postgres connection error started at 2017-04-20
11:06:04,162+01 ERROR .
I see the problem with the database is still not fixed.
Please check for the reason your database connection keeps closing.

Best regards,


--

SHIRLY RADCO

BI SOFTWARE ENGINEER,

Red Hat Israel 

sra...@redhat.com
 
 


On Thu, Apr 20, 2017 at 2:12 PM,  wrote:

> Hi,
>
> We're using oVirt 4.1.1.8 (upgraded yesterday) and since it has been
> showing some strange errors I'd like to know about:
>
> ETL service sampling has encountered an error. Please consult the
> service log for more details.
>
> I'm attaching the engine log FWIW. This message showed up at 11:07:04 but
> in the log I see the exceptions started 1 minute ago.
>
> Also, at 11:07:58 this event showed up:
>
> Engine server is not responding.
>
> And at 11:12:58 it seems to recover:
>
> Engine server is up and running.
>
> At 12:00:00 this message showed up:
>
> ETL service aggregation to hourly tables has encountered an error.
> Please consult the service log for more details.
>
> But relative to this one I see nothing in logs.
>
> Could someone clarify what these error messages mean?
>
> Thanks.
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt 4.1.1 and ovn problems

[Marcin Mirecki]

Hello Gianluca,

Can you please check the ovn north db log.
This is placed in /var/log/openvswitch/ovsdb-server-nb.log
Please check if the logs has any new entries when you try to connect and
when you issue the 'ovn-nbctl set-connection ptcp:6641' command.
If the connection attempt is getting through, pvs db should print an error
to the log.

Please also try restarting the ovn-northd service.

Do the ovn-controllers connect to the south-db?
You can verify this by looking at /var/log/openvswitch/ovn-controller.log
on the ovn-controller host (please look for entries saying "... :6642 connected")

Marcin



On Fri, Apr 21, 2017 at 1:09 PM, Gianluca Cecchi 
wrote:

> On Thu, Apr 20, 2017 at 6:54 PM, Gianluca Cecchi <
> gianluca.cec...@gmail.com> wrote:
>
>> Hello,
>> I installed some months ago a test setup in 4.1.0 with ovn.
>> Now after updating engine and host to 4.1.1 it seems the services are up
>> but it doesn't work.
>> If I run a VM with a network device in OVN external provider, it cant'
>> boot and I get this in engine.log:
>>
>>
>> [snip]
>
>>
>> At the page
>> https://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/
>>
>> I see this note about ports:
>>
>> "
>> Since OVS 2.7, OVN central must be configured to listen to requests on
>> appropriate ports:
>>
>> ovn-sbctl set-connection ptcp:6642
>> ovn-nbctl set-connection ptcp:6641
>> "
>>
>> and in my case I indeed passed from 2.6.90 to 2.7.0...
>>
>> Do I need to run these two commands?
>> Or any other configuration settings?
>>
>> Thanks in advance,
>> Gianluca
>>
>
> I confirm that after running these two commands all work ok again and I'm
> able to start a VM with a vnic provided by the OVN provider
>
> [root@ractorshe ~]# ovn-sbctl set-connection ptcp:6642
> [root@ractorshe ~]# ovn-nbctl set-connection ptcp:6641
> [root@ractorshe ~]#
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>


-- 

MARCIN mIRECKI

Red Hat



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Communicate between the guest vm's hosted on different hosts on different data centres using OVS

[Yaniv Dary]

You will the DCs to share the same physical L2 to allow communication and
deploy the same OVN definition between the DCs.

YANIV DARY

SENIOR TECHNICAL PRODUCT MANAGER

Red Hat Israel Ltd. 

34 Jerusalem Road, Building A, 1st floor

Ra'anana, Israel 4350109

yd...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: ydary
 
TRIED. TESTED. TRUSTED. 
@redhatnews    Red Hat
   Red Hat



On Thu, Apr 20, 2017 at 9:43 PM, Linov Suresh 
wrote:

> Hello,
>
> I have configured OVS network on oVirt 4.1.1, following the document
> https://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/
>
> I have created OVN Provider, and created new Logical Network for OVS using
> OVN Provider. I have synced the network also selected OVS when I created
> the cluster.
>
> I have two data centres and each data centre has one host each.
>
> Now I have created VM's selecting OVS network (not ovirtmgmt). VM's in the
> same data centre can talk to each other.
>
> How do i make the VM's hosted on different data centre can talk to each
> other?
>
> Appreciate your help in advance,
>
> Sincerely,
>
> Suresh.
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt GUI bug? clicking "ok" on upgrade host confirmation screen

[knarra]

On 04/21/2017 10:20 PM, Nelson Lameiras wrote:

Hello,

Since "upgrade" functionality is available for hosts in oVirt GUI I 
have this strange bug :


- Click on "Installation>>Upgrade"
- Click "ok" on confirmation screen
- -> (bug) confirmation screen does not dissapear as expected
- Click "ok" again on confirmation screen -> error : "system is 
already upgrading"

- Click "cancel" to be able to return to oVirt

This happens using on :
ovirt engine : oVirt Engine Version: 4.1.1.6-1.el7.centos
client : windows 10
client : chrome Version 57.0.2987.133 (64-bit)

This bug was already present on oVirt 4.0 before updating to 4.1.

Has anybody else have this problem?

(will try to reproduce with firefox, IE)

cordialement, regards,



Nelson LAMEIRAS
Ingénieur Systèmes et Réseaux/ Systems and Networks engineer
Tel: +33 5 32 09 09 70
nelson.lamei...@lyra-network.com 
www.lyra-network.com  | www.payzen.eu 










Lyra Network, 109 rue de l'innovation, 31670 Labège, FRANCE




___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Hi Nelson,

Once you click on 'OK' you will need to wait for few seconds 
(before the confirmation disappears) then you can see that upgrade 
starts.  In the previous versions once user clicks on 'OK' confirmation 
screen usually disappears immediately.


Thanks

kasturi

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] upgrade to 4.1

[Yedidyah Bar David]

On Sun, Apr 23, 2017 at 2:53 PM, Fabrice Bacchella
 wrote:
>
>> Le 23 avr. 2017 à 07:59, Yedidyah Bar David  a écrit :
>>
>>
>
>> The main reason we require this is for pg_dump/pg_restore which are ran
>> during setup/rollback (if needed). pg_dump can't know for sure that all
>> the changes in the db were done using a client of its own version (that
>> is, current machine usually), and if indeed a newer client was used, it
>> might have used features that pg_dump of the lower version doesn't know
>> how to back up (and especially pg_restore does not know how to restore).
>> See also [1]. I seem to have tested there (can't remember anymore, see
>> comment 13) 9.2 client with 9.5 server and it didn't work. pg_dump(1)
>> manpage says:
>>
>>   Because pg_dump is used to transfer data to newer versions of
>>   PostgreSQL, the output of pg_dump can be expected to load into
>>   PostgreSQL server versions newer than pg_dump's version.  pg_dump can
>>   also dump from PostgreSQL servers older than its own version.
>>   (Currently, servers back to version 7.0 are supported.) However,
>>   pg_dump cannot dump from PostgreSQL servers newer than its own major
>>   version; it will refuse to even try, rather than risk making an invalid
>>   dump. Also, it is not guaranteed that pg_dump's output can be loaded
>>   into a server of an older major version — not even if the dump was
>>   taken from a server of that version. Loading a dump file into an older
>>   server may require manual editing of the dump file to remove syntax not
>>   understood by the older server. Use of the --quote-all-identifiers
>>   option is recommended in cross-version cases, as it can prevent
>>   problems arising from varying reserved-word lists in different
>>   PostgreSQL versions.
>>
>
> I don't get it, but I don't know pg so I might be wrong.
>
> You have a client application (like ovirt) written using features from V1 of 
> pg.

Right.

>
> It's running on a server where version V2 is installing. For good reasons, V2 
> >= V1 is needed.

Indeed.

>
> The server is running a version V3. Again V3 >= V1 is needed.   Except for 
> major version, does V3 => V2 is really needed ?

For oVirt itself, no.

>
> And for backup the problem is the same. It must probably know every features 
> used in the application (so again being V1 or more). Why does it needs to 
> match both V2 and V3 ?  It will probably fits V2 is installation is the same. 
> But that not mandatory. In a java application, the client library might be a 
> jar provided by the application and pg_dump a tool installed with native os 
> packaging. But how can complain against V3 ?

pg_dump is indeed a tool installed from the OS. I copied above the relevant
part of its manpage - if you think it does a wrong thing, perhaps better
continue the discussion on postgresql lists.

For our concern, the only relevant fact is that we decided to backup the
db using pg_dump during setup, and to restore it on rollback. If you want
to make this backup optional, please open an RFE, as already requested, and
we can discuss this there.

>
> But with ovirt we have V1=V2=V3,

Not exactly. Using your terminology, we have V1<=V2, V2=V3.

> even for for patch level (9.4.8 against 9.4.11). What kind of feature that 
> ovirt don't know about might be missing ? I don't think ovirt might know 
> about any 9.4 since you talked about version 9.2 as the official supported 
> version.

At the time, oVirt didn't check versions at all, and so failed on a
certain combination, and it was decided to require V2=V3, as a simple
and effective solution. This was also specifically discussed there,
as you can see for yourself, open to the public for review/comments.
Check especially comments 9 to 19 (in bz 1331168).

If you think we need a more delicate test, please open an RFE,
preferably providing the details I suggested that should be considered
for one.

Also please recall that you have a third, very simple, IMHO, option.
If for any reason you decided to have your server with version V3,
simply install V3 on your client machine (the oVirt engine). This
will be simple and solve all problems. If your concern is that the
OS does not supply pg V3, then it applies also to the OS of the
server. If that is a different OS, you are welcome to port oVirt
engine to that OS so you can have all you want at once.

You also have a fourth option - patch oVirt to not check for the
version, by reverting the patch that introduced this check (might
require a bit more work than "git revert", but not much):

https://gerrit.ovirt.org/59941

Of course, this will essentially be a fork, and I'd personally not
recommend it. But it's still an option.

Best,
-- 
Didi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Communicate between the guest vm's hosted on different hosts on different data centres using OVS

[Linov Suresh]

Hello,

I have configured OVS network on oVirt 4.1.1, following the document
https://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/

I have created OVN Provider, and created new Logical Network for OVS using
OVN Provider. I have synced the network also selected OVS when I created
the cluster.

I have two data centres and each data centre has one host each.

Now I have created VM's selecting OVS network (not ovirtmgmt). VM's in the
same data centre can talk to each other.

How do i make the VM's hosted on different data centre can talk to each
other?

Appreciate your help in advance,

Sincerely,

Suresh.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] upgrade to 4.1

[Yaniv Kaul]

On Thu, Apr 20, 2017 at 4:50 PM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

> I tried to upgrade ovirt to version 4.1 from 4.0 and got:
>
>   Found the following problems in PostgreSQL configuration for the
> Engine database:
>autovacuum_vacuum_scale_factor required to be at most 0.01
>autovacuum_analyze_scale_factor required to be at most 0.075
>autovacuum_max_workers required to be at least 6
>Postgresql client version is '9.4.8', whereas the version on
> XXX is '9.4.11'. Please use a Postgresql server of version '9.4.8'.
>

I'm not sure we support 9.4.8, we use whatever comes with EL7, which AFAIR,
is 9.2.x
Y.


>   Please set:
>autovacuum_vacuum_scale_factor = 0.01
>autovacuum_analyze_scale_factor = 0.075
>autovacuum_max_workers = 6
>server_version = 9.4.8
>   in postgresql.conf on ''. Its location is usually
> /var/lib/pgsql/data , or somewhere under /etc/postgresql* .
>
> I'm a little afraid about that. Does ovirt want pg to lies about it's
> version ? It's a shared instance so what about other tools that access it ?
> Is there some explanation about the meaning of those values ?
>
> And it was not in the release notes, it's not funny to get this warning
> after starting the upgrade
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt services outage last Friday [ 21/04/17 ]

[Eyal Edri]

Adding also 'announce' list.

On Sun, Apr 23, 2017 at 9:49 AM, Eyal Edri  wrote:

> FYI,
>
> During last Friday the data center which oVirt services are hosted on had
> a major outage which affected some of the oVirt services, like the CI,
> e-mail and oVirt repositories.
>
> All systems should be up by now, although, since one the services which
> were affected was e-mail, it might be that your emails are still in the
> queue waiting to be sent.
>
> If you still experiencing any service downtime, please report to
> infra-supp...@ovirt.org.
> We are working with the IT team of the DC to get the full RCA will report
> once we have more info.
>
> Thanks for the understanding and sorry for the inconvenience,
>
> oVirt infra team
>
> --
>
> Eyal edri
>
>
> ASSOCIATE MANAGER
>
> RHV DevOps
>
> EMEA VIRTUALIZATION R&D
>
>
> Red Hat EMEA 
>  TRIED. TESTED. TRUSTED. 
> phone: +972-9-7692018 <+972%209-769-2018>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>



-- 

Eyal edri


ASSOCIATE MANAGER

RHV DevOps

EMEA VIRTUALIZATION R&D


Red Hat EMEA 
 TRIED. TESTED. TRUSTED. 
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] upgrade to 4.1

[Fabrice Bacchella]

> Le 23 avr. 2017 à 07:59, Yedidyah Bar David  a écrit :
>>> 

>>> 
>>> And it was not in the release notes, it's not funny to get this warning
>>> after starting the upgrade
> 
> This isn't a new test, see above bug.
> 
> Are you sure it's the first time you see it? Perhaps you upgraded your pg
> server only after the last upgrade of the engine?
> 

That's might true about the test, but not the autovacuum_vacuum_scale_factor 
and others.

And any way, about the test, having a different version of pg library and pg 
server is quite common when you have a centralized pg. You might plan an 
upgrade any time and don't expect every client to complain about a minor 
release, that's quite unexpected.

The bug https://bugzilla.redhat.com/show_bug.cgi?id=1331168 is about major 
version, I got complain from ovirt about patch level. That's not the same thing.
And the solution that ovirt propose is to have the server lying about version 
to all of it's client. What can I do if every client I use require such a thing 
?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] upgrade to 4.1

[Yedidyah Bar David]

On Sun, Apr 23, 2017 at 10:59 AM, Fabrice Bacchella
 wrote:
>
>> Le 23 avr. 2017 à 07:59, Yedidyah Bar David  a écrit :

>

 And it was not in the release notes, it's not funny to get this warning
 after starting the upgrade
>>
>> This isn't a new test, see above bug.
>>
>> Are you sure it's the first time you see it? Perhaps you upgraded your pg
>> server only after the last upgrade of the engine?
>>
>
> That's might true about the test, but not the autovacuum_vacuum_scale_factor 
> and others.
>
> And any way, about the test, having a different version of pg library and pg 
> server is quite common when you have a centralized pg. You might plan an 
> upgrade any time and don't expect every client to complain about a minor 
> release, that's quite unexpected.

Very well, so I detailed above a suggestion about what you can do.

Either make backup (and therefore rollback) optional, or make the test
more delicate. Neither seems trivial to me in terms of risk (although
they might be quite simple in the amount of code to change).

>
> The bug https://bugzilla.redhat.com/show_bug.cgi?id=1331168 is about major 
> version, I got complain from ovirt about patch level. That's not the same 
> thing.

I didn't check PG's official terminology. The bug was about 9.2
against 9.5. In general, "9" is the major version, and the bug still
applied. It might be that they consider "9.2" to be the major version,
and "9.5" a different major version.

> And the solution that ovirt propose is to have the server lying about version 
> to all of it's client.

Where did you see this?

The text you copied is: "Please use a Postgresql server of version '9.4.8'"

> What can I do if every client I use require such a thing ?

You mean:
1. I want a single server with some version X
2. I want different clients with different versions X1, X2, ...
3. More than one of these clients requires the server to be the same
version as the client
?

I'd say - upgrade all such clients to the version of the server, or
make these clients not require that :-)

Best,
-- 
Didi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] The web portal gives: Bad Request: 400

[Arman Khalatyan]

Hi Yaniv,
I'm unfortunately there is nothing in the logs, it looks like a ovirt
doesnot listen to the right interface.
We have multiples interfaces internal and external access.
We sometimes ago we renamed the engine name to work with the external ip
address. Now it is listening only to the local address.
To fix it i just added:

/etc/ovirt-engine/engine.conf.d/99-setup-http-proxy.conf


One need to dig more to fix it


Am 20.04.2017 2:55 nachm. schrieb "Yaniv Kaul" :

>
>
> On Thu, Apr 20, 2017 at 1:06 PM, Arman Khalatyan 
> wrote:
>
>> After the recent upgrade from ovirt Version 4.1.1.6-1.el7.centos. to
>> Version 4.1.1.8-1.el7.centos
>>
>> The web portal gives following error:
>> Bad Request
>>
>> Your browser sent a request that this server could not understand.
>>
>> Additionally, a 400 Bad Request error was encountered while trying to use
>> an ErrorDocument to handle the request.
>>
>>
>> Are there any hints how to fix it?
>>
>
> It'd be great if you could share some logs. The httpd logs, server.log and
> engine.log, all might be useful.
> Y.
>
>
>> BTW the rest API works as expected, engine-setup went without errors.
>>
>> Thanks,
>>
>> Arman.
>>
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] upgrade to 4.1

[Fabrice Bacchella]

> Le 23 avr. 2017 à 10:56, Yedidyah Bar David  a écrit :
> 
> On Sun, Apr 23, 2017 at 10:59 AM, Fabrice Bacchella
>  wrote:
>> 
>>> Le 23 avr. 2017 à 07:59, Yedidyah Bar David  a écrit :
> 
>> 
> 
> And it was not in the release notes, it's not funny to get this warning
> after starting the upgrade
>>> 
>>> This isn't a new test, see above bug.
>>> 
>>> Are you sure it's the first time you see it? Perhaps you upgraded your pg
>>> server only after the last upgrade of the engine?
>>> 
>> 
>> That's might true about the test, but not the autovacuum_vacuum_scale_factor 
>> and others.
>> 
>> And any way, about the test, having a different version of pg library and pg 
>> server is quite common when you have a centralized pg. You might plan an 
>> upgrade any time and don't expect every client to complain about a minor 
>> release, that's quite unexpected.
> 
> Very well, so I detailed above a suggestion about what you can do.
> 
> Either make backup (and therefore rollback) optional, or make the test
> more delicate. Neither seems trivial to me in terms of risk (although
> they might be quite simple in the amount of code to change).
> 
>> 
>> The bug https://bugzilla.redhat.com/show_bug.cgi?id=1331168 is about major 
>> version, I got complain from ovirt about patch level. That's not the same 
>> thing.
> 
> I didn't check PG's official terminology. The bug was about 9.2
> against 9.5. In general, "9" is the major version, and the bug still
> applied. It might be that they consider "9.2" to be the major version,
> and "9.5" a different major version.

From the very bug description:

> I'm testing migration from 3.6 EL6 with remote DBs (PG 8.x) to 4.0 EL7 while 
> still using remote DBs (which I restored from backup).

> Problem is 4.0 supports PG 9.x but I was still original PG 8.x. engine-setup 
> from 4.0 should know it needs PG 9.x and should check PG version even for 
> remote DBs.

In the extract from the man page, the main problems are also about major 
versions.

You test 9.2 against 9.5.

What I have failling is 9.4.8 against 9.4.11. That is very different from all 
the case described.

> 
>> And the solution that ovirt propose is to have the server lying about 
>> version to all of it's client.
> 
> Where did you see this?

  Please set:
   autovacuum_vacuum_scale_factor = 0.01
   autovacuum_analyze_scale_factor = 0.075
   autovacuum_max_workers = 6
   server_version = 9.4.8

Are in the log from the upgrade command.

> 
> The text you copied is: "Please use a Postgresql server of version '9.4.8'"
> 
>> What can I do if every client I use require such a thing ?
> 
> You mean:
> 1. I want a single server with some version X
> 2. I want different clients with different versions X1, X2, ...
> 3. More than one of these clients requires the server to be the same
> version as the client
> ?
> 
> I'd say - upgrade all such clients to the version of the server, or
> make these clients not require that :-)

Yes make these clients not require that. Ovirt is one of those complaining 
client.


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users