Re: [ovirt-devel] Firewalld migration.

[Yedidyah Bar David]

On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg  wrote:
> Effectively, upgrading will leave lingering (but nonetheless operational)
> iptables rules on the hosts. I'm not even sure there needs to be special
> upgrade treatment?

Please describe the expected flow.

Please note that at least when I tried, 'systemctl start firewalld' stops
iptables.

Thanks,

>
> On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David  wrote:
>>
>> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg 
>> wrote:
>> > 1) Do we actually need iptables for any reason that isn't a legacy
>> > consideration?
>>
>> No idea personally.
>>
>> Perhaps some users prefer that, and/or need that for integration with
>> other
>> systems/solutions/whatever.
>>
>> If we drop iptables, how do you suggest to treat upgrades?
>>
>> >
>> > 2 & 3) I am in favor of treating custom services as a requirement and
>> > plan
>> > accordingly. Many (most, even) of the services are already provided by
>> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages
>> > (e.g.
>> > gluster). Some are missing (I've recently created a pull request for
>> > ovirt-imageio to firewalld, for example) and I hope we'll be able to get
>> > all
>> > the services to be statically provided (by either firewalld or the
>> > relevant
>> > 3rd party packages).
>> >
>> > Ideally I think we'd like use statically provided services, and provide
>> > the
>> > capability to provide additional services (I'm not a fan of the current
>> > methodology of converting strings into xmls). I don't think we'd want to
>> > limit usage to just statically provided services. (2)
>> >
>> > As previously stated, I don't see a technical reason to keep iptables
>> > under
>> > consideration. (3)
>> >
>> >
>> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David 
>> > wrote:
>> >>
>> >>
>> >> 1. Do we want to support in some version X both iptables and firewalld,
>> >> or
>> >> is it ok to stop support for iptables and support only firewalld
>> >> without
>> >> overlap? If so, do we handle upgrades, and how?
>> >>
>> >> 2. Do we want to support custom firewalld xml to be configured on the
>> >> host by us? Or is it ok to only support choosing among existing
>> >> services,
>> >> which will need to be added to the host using other means (packaged by
>> >> firewalld, packaged by 3rd parties, added manually by users)?
>> >>
>> >> 3. Opposite of (2.): Do we want to support firewalld services that are
>> >> added to the host using other means (see there)? Obviously we do, but:
>> >> If we do, do we still want to support also iptables (see (1.))? And if
>> >> so, what do we want to then happen?
>> >>
>> >> (2.) and (3.) are not conflicting, each needs its own answer.
>> >>
>> >>
>> >> --
>> >> Didi
>> >
>> >
>>
>>
>>
>> --
>> Didi
>
>



-- 
Didi
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Writing SQL queries in DAO code

[Moti Asayag]

On Sun, Mar 26, 2017 at 5:12 PM, Yevgeny Zaspitsky 
wrote:

> Hi All,
>
> Recently I had a task of performance improvement in one of our network
> related flows and had some hard time following our DAL code and one of the
> outcomes of the task was defining a couple of new quite simple, but neat
> queries.
> When I came to coding those new queries I remembered how hard was
> following the existing DAL code, I decided to make my own new methods
> clearer. So I created [1] and [2] patches.
>
> Everything is quite standard there beside the fact that they do not use
> any stored procedure, but use SQL directly, IMHO by that they save time
> that I spent in trying to follow what a DAO method does. Looking into the
> method code you get the understanding of what this method is all about:
>
>- no looking for a stored procedure name that is buried in the DAO
>class hierarchy
>- no looking for the SP definition
>
>
There are additional pros and cons for the suggestion to consider:

Pros:

   1. No need to run engine-setup after changing DB related code (in case
   of SQL inside Java).

Cons:

   1. DAO files might become very long.
   2. If you decide to return the business entity associated with the DAO
   as a returned object, you won't know as a caller which fields to expect to
   be populated, which lead to 3:
   3. An inflation of business entities to represent partial populated
   business entity or inflation of mappers inflation (this will be required
   for SP as well).
   4. SQL code inside of Java:
   1. Beside of the fact that a multi-line concatenated string that cannot
  be easily copied and run with psql, it means that we should compile the
  code in order to test the change (vs building with DEV_REBUILD=0
which only
  package the SQL file).
  2. No syntax highlighting when performing code review. i.e. I don't
  think reviewing a patch such as
  https://gerrit.ovirt.org/#/c/66729/10/packaging/dbscripts/network_sp.sql
  would be more clear inside a java file.
  3. The user permissions management is implemented on DB level. That
  means that SQL will be more complex (more concatenated java lines).
   5. Stored procedure are cached by project's code. See
   SimpleJdbcCallsHandler.getCall(), while the NamedParameterJdbcTemplate
   are cached by spring's code which seems less optimal (sync all calls using
   synchronized vs using ConcurrentHashMap as in SP cache).
   6. With the NamedParametersJdbcTemplate there is no use of the
   DbEngineDialect. What's the impact of it ?

So besides 5 and 6, the rest is a matter of style. I'd like to hear more
opinions from other members.

Regards,
Moti

So I'd like to propose moving towards this approach in general in all cases
> when nothing beyond a simple SQL is needed (no stored procedure programming
> language is needed).
> From my experience with the performance improvement task it looks like
> people avoid adding new queries for a specific need of a flow, instead they
> use the existing general ones (e.g. dao.getAllForX()) and do the actual
> join in the bll code.
> IMHO the proposed approach would simplify adding new specific queries and
> by that would prevent a decent part of performance issues in the future.
>
> I do not propose changing all existing SP's to inline queries in a once,
> but to allow adding new queries this way. Also we might consider converting
> relatively simple SP's to inline SQL statements later in a graduate way.
>
> [1] - https://gerrit.ovirt.org/#/c/74456
> [2] - https://gerrit.ovirt.org/#/c/74458
>
> Regards,
> Yevgeny
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
Regards,
Moti
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Gsoc proposal on Configuring backup storage in ovirt

[Maor Lipchuk]

Thanks for your help Greg :)

The initial plan will be to start with the REST changes and depends on
the progress there we will see what we can achieve in the UI also.

Regarding the GUI changes: The changes I was thinking about is to add
a checkbox indicating whether a storage domain is configured as backup
or not which will be placed in the advanced parameters under the "wipe
after delete" checkbox.
Regarding the presentation of this attribute, it will be discussed
based on the progress of the feature.

Shubham and I should have a meeting this week where we will focus in
more detail about the tasks and the schedule which will probably be
updated in the doc.

Regards,
Maor

On Sun, Mar 26, 2017 at 5:59 PM, shubham dubey  wrote:
> Thanks for reviewing the proposal.:)
>
> I was not sure if significant changes need to be done in UI that’s why I
> haven't
> mentioned that in my proposal.But I will discuss about that with Maor and if
> it
> is needed then I will also include that.
>
> Thanks
>
> On Sun, Mar 26, 2017 at 5:58 PM, Greg Sheremeta  wrote:
>>
>> Nice job, Shubham :) I added some suggestions to your document.
>>
>> Do you have any plans for UI changes? In your examples, I only saw REST
>> API calls.
>>
>> Best wishes,
>> Greg
>>
>>
>> On Sun, Mar 26, 2017 at 4:38 AM, shubham dubey 
>> wrote:
>>>
>>> hello,
>>> I was mentioning about the
>>> http://www.ovirt.org/develop/release-management/features/storage/online-virtual-drive-resize/.
>>> since it was written in the docs that shrinking drive is not supported
>>> yet hence I have decided to work on that.But if it is
>>> already supported in 4.1v then I think I need to remove them from my
>>> proposal.:).
>>>
>>> Thanks,
>>> Shubham
>>>
>>> On Sun, Mar 26, 2017 at 1:55 PM, Maor Lipchuk 
>>> wrote:

 Hi Shubham,

 The proposal looks very impressive, good job!

 I got a question regarding what you mentioned about the "Online
 Virtual Drive Resize" feature.
 Did you refer to the ovirt sparsify feature:
 http://www.ovirt.org/develop/release-management/features/virt-sparsify/

 or the online-virtual-drive-resize feature:

 http://www.ovirt.org/develop/release-management/features/storage/online-virtual-drive-resize/

 both should be supported in oVirt 4.1 IINM

 Regarding the synopsis section which you mentioned the supported types
 of storage domains, please also add Ceph as part of the block Storage
 Domains. oVirt 3.6 should supports it through Cinder.

 Regards,
 Maor

 On Sun, Mar 26, 2017 at 8:12 AM, shubham dubey 
 wrote:
 > Hello,
 > I have created the draft proposal recently on Configuring backup
 > storage in
 > ovirt.Here is the link to view
 >
 > https://docs.google.com/document/d/1orulgCTY1K6jUmomCIgZHA0g9xsWWUqttj0c1R0d9uU.
 > Any suggestion or comments are welcome.
 >
 > Thanks,
 > Shubham Dubey
>>>
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>>
>> --
>> Greg Sheremeta, MBA
>> Red Hat, Inc.
>> Sr. Software Engineer
>> gsher...@redhat.com
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Firewalld migration.

[Leon Goldberg]

Effectively, upgrading will leave lingering (but nonetheless operational)
iptables rules on the hosts. I'm not even sure there needs to be special
upgrade treatment?

On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David  wrote:

> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg 
> wrote:
> > 1) Do we actually need iptables for any reason that isn't a legacy
> > consideration?
>
> No idea personally.
>
> Perhaps some users prefer that, and/or need that for integration with other
> systems/solutions/whatever.
>
> If we drop iptables, how do you suggest to treat upgrades?
>
> >
> > 2 & 3) I am in favor of treating custom services as a requirement and
> plan
> > accordingly. Many (most, even) of the services are already provided by
> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages
> (e.g.
> > gluster). Some are missing (I've recently created a pull request for
> > ovirt-imageio to firewalld, for example) and I hope we'll be able to get
> all
> > the services to be statically provided (by either firewalld or the
> relevant
> > 3rd party packages).
> >
> > Ideally I think we'd like use statically provided services, and provide
> the
> > capability to provide additional services (I'm not a fan of the current
> > methodology of converting strings into xmls). I don't think we'd want to
> > limit usage to just statically provided services. (2)
> >
> > As previously stated, I don't see a technical reason to keep iptables
> under
> > consideration. (3)
> >
> >
> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David 
> wrote:
> >>
> >>
> >> 1. Do we want to support in some version X both iptables and firewalld,
> or
> >> is it ok to stop support for iptables and support only firewalld without
> >> overlap? If so, do we handle upgrades, and how?
> >>
> >> 2. Do we want to support custom firewalld xml to be configured on the
> >> host by us? Or is it ok to only support choosing among existing
> services,
> >> which will need to be added to the host using other means (packaged by
> >> firewalld, packaged by 3rd parties, added manually by users)?
> >>
> >> 3. Opposite of (2.): Do we want to support firewalld services that are
> >> added to the host using other means (see there)? Obviously we do, but:
> >> If we do, do we still want to support also iptables (see (1.))? And if
> >> so, what do we want to then happen?
> >>
> >> (2.) and (3.) are not conflicting, each needs its own answer.
> >>
> >>
> >> --
> >> Didi
> >
> >
>
>
>
> --
> Didi
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Gsoc proposal on Configuring backup storage in ovirt

[shubham dubey]

Thanks for reviewing the proposal.:)

I was not sure if significant changes need to be done in UI that’s why I
haven't
mentioned that in my proposal.But I will discuss about that with Maor and
if it
is needed then I will also include that.

Thanks

On Sun, Mar 26, 2017 at 5:58 PM, Greg Sheremeta  wrote:

> Nice job, Shubham :) I added some suggestions to your document.
>
> Do you have any plans for UI changes? In your examples, I only saw REST
> API calls.
>
> Best wishes,
> Greg
>
>
> On Sun, Mar 26, 2017 at 4:38 AM, shubham dubey 
> wrote:
>
>> hello,
>> I was mentioning about the http://www.ovirt.org/develop/r
>> elease-management/features/storage/online-virtual-drive-resize/.
>> since it was written in the docs that shrinking drive is not supported
>> yet hence I have decided to work on that.But if it is
>> already supported in 4.1v then I think I need to remove them from my
>> proposal.:).
>>
>> Thanks,
>> Shubham
>>
>> On Sun, Mar 26, 2017 at 1:55 PM, Maor Lipchuk 
>> wrote:
>>
>>> Hi Shubham,
>>>
>>> The proposal looks very impressive, good job!
>>>
>>> I got a question regarding what you mentioned about the "Online
>>> Virtual Drive Resize" feature.
>>> Did you refer to the ovirt sparsify feature:
>>> http://www.ovirt.org/develop/release-management/features/virt-sparsify/
>>>
>>> or the online-virtual-drive-resize feature:
>>> http://www.ovirt.org/develop/release-management/features/sto
>>> rage/online-virtual-drive-resize/
>>>
>>> both should be supported in oVirt 4.1 IINM
>>>
>>> Regarding the synopsis section which you mentioned the supported types
>>> of storage domains, please also add Ceph as part of the block Storage
>>> Domains. oVirt 3.6 should supports it through Cinder.
>>>
>>> Regards,
>>> Maor
>>>
>>> On Sun, Mar 26, 2017 at 8:12 AM, shubham dubey 
>>> wrote:
>>> > Hello,
>>> > I have created the draft proposal recently on Configuring backup
>>> storage in
>>> > ovirt.Here is the link to view
>>> > https://docs.google.com/document/d/1orulgCTY1K6jUmomCIgZHA0g
>>> 9xsWWUqttj0c1R0d9uU.
>>> > Any suggestion or comments are welcome.
>>> >
>>> > Thanks,
>>> > Shubham Dubey
>>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gsher...@redhat.com
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Fwd: Question for oVirt

[Yaniv Dary]

This is not relevant anymore.
We are exploring an option to use NM for network configuration in the
future.

Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary


On Tue, Mar 21, 2017 at 4:40 AM, jeff hsueh  wrote:

> Hi Devel,
>
> Could you help to give me some detail information about this feature?
> Thanks.
>
> Jeff
>
> -- Forwarded message --
> From: Mike Burns 
> Date: 2017-03-20 20:44 GMT+08:00
> Subject: Re: Question for oVirt
> To: jeff hsueh 
>
>
> This is very old (last update 2012).  I haven't worked on oVirt in a long
> time either.  You should redirect this and other questions to
>
> devel@ovirt.org.
>
> Thanks
>
> On Mon, Mar 20, 2017 at 4:56 AM, jeff hsueh  wrote:
>
>> Hi Mike,
>>
>> I am studying "NetworkManager Support" of oVirt project.
>> Link: http://www.ovirt.org/develop/release-management/featur
>> es/network/networkmanager-support/
>>
>> I could not understand what does this feature want to achieve.
>> Could I get more information and status about this feature from you?
>> Because the information about this feature in oVirt web site is too brief.
>>
>> Thanks.
>>
>> Jeff
>>
>>
>> 
>> 不含病毒。www.avast.com
>> 
>> <#m_-7074419660434254156_m_-8795404721952800494_m_4727600564310439803_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>
>
>
> ___
> 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

[ovirt-devel] Writing SQL queries in DAO code

[Yevgeny Zaspitsky]

Hi All,

Recently I had a task of performance improvement in one of our network
related flows and had some hard time following our DAL code and one of the
outcomes of the task was defining a couple of new quite simple, but neat
queries.
When I came to coding those new queries I remembered how hard was following
the existing DAL code, I decided to make my own new methods clearer. So I
created [1] and [2] patches.

Everything is quite standard there beside the fact that they do not use any
stored procedure, but use SQL directly, IMHO by that they save time that I
spent in trying to follow what a DAO method does. Looking into the method
code you get the understanding of what this method is all about:

   - no looking for a stored procedure name that is buried in the DAO class
   hierarchy
   - no looking for the SP definition

So I'd like to propose moving towards this approach in general in all cases
when nothing beyond a simple SQL is needed (no stored procedure programming
language is needed).
>From my experience with the performance improvement task it looks like
people avoid adding new queries for a specific need of a flow, instead they
use the existing general ones (e.g. dao.getAllForX()) and do the actual
join in the bll code.
IMHO the proposed approach would simplify adding new specific queries and
by that would prevent a decent part of performance issues in the future.

I do not propose changing all existing SP's to inline queries in a once,
but to allow adding new queries this way. Also we might consider converting
relatively simple SP's to inline SQL statements later in a graduate way.

[1] - https://gerrit.ovirt.org/#/c/74456
[2] - https://gerrit.ovirt.org/#/c/74458

Regards,
Yevgeny
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Firewalld migration.

[Yedidyah Bar David]

On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg  wrote:
> 1) Do we actually need iptables for any reason that isn't a legacy
> consideration?

No idea personally.

Perhaps some users prefer that, and/or need that for integration with other
systems/solutions/whatever.

If we drop iptables, how do you suggest to treat upgrades?

>
> 2 & 3) I am in favor of treating custom services as a requirement and plan
> accordingly. Many (most, even) of the services are already provided by
> either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages (e.g.
> gluster). Some are missing (I've recently created a pull request for
> ovirt-imageio to firewalld, for example) and I hope we'll be able to get all
> the services to be statically provided (by either firewalld or the relevant
> 3rd party packages).
>
> Ideally I think we'd like use statically provided services, and provide the
> capability to provide additional services (I'm not a fan of the current
> methodology of converting strings into xmls). I don't think we'd want to
> limit usage to just statically provided services. (2)
>
> As previously stated, I don't see a technical reason to keep iptables under
> consideration. (3)
>
>
> On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David  wrote:
>>
>>
>> 1. Do we want to support in some version X both iptables and firewalld, or
>> is it ok to stop support for iptables and support only firewalld without
>> overlap? If so, do we handle upgrades, and how?
>>
>> 2. Do we want to support custom firewalld xml to be configured on the
>> host by us? Or is it ok to only support choosing among existing services,
>> which will need to be added to the host using other means (packaged by
>> firewalld, packaged by 3rd parties, added manually by users)?
>>
>> 3. Opposite of (2.): Do we want to support firewalld services that are
>> added to the host using other means (see there)? Obviously we do, but:
>> If we do, do we still want to support also iptables (see (1.))? And if
>> so, what do we want to then happen?
>>
>> (2.) and (3.) are not conflicting, each needs its own answer.
>>
>>
>> --
>> Didi
>
>



-- 
Didi
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] master branch host installation fails in ovirt-system-tests - regression due to ABRT integration?

[Yaniv Kaul]

2017-03-26 09:50:47,235-04 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(VdsDeploy) [2c34dfce] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511),
Correlation ID: 2c34dfce, Call Stack:
null, Custom Event ID: -1, Message: Failed to install Host
lago-basic-suite-master-host1. Failed to execute stage 'Package
installation': [u'vdsm-4.20.0-542.git93156a7.el7.centos.x86_64 requires
abrt-addon-vmcor
e', u'vdsm-4.20.0-542.git93156a7.el7.centos.x86_64 requires
abrt-addon-ccpp', u'vdsm-4.20.0-542.git93156a7.el7.centos.x86_64 requires
abrt-addon-python'].
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Firewalld migration.

[Leon Goldberg]

1) Do we actually need iptables for any reason that isn't a legacy
consideration?

2 & 3) I am in favor of treating custom services as a requirement and plan
accordingly. Many (most, even) of the services are already provided by
either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages
(e.g. gluster). Some are missing (I've recently created a pull request for
ovirt-imageio to firewalld, for example) and I hope we'll be able to get
all the services to be statically provided (by either firewalld or the
relevant 3rd party packages).

Ideally I think we'd like use statically provided services, and provide the
capability to provide additional services (I'm not a fan of the current
methodology of converting strings into xmls). I don't think we'd want to
limit usage to just statically provided services. (2)

As previously stated, I don't see a technical reason to keep iptables under
consideration. (3)


On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David  wrote:

>
> 1. Do we want to support in some version X both iptables and firewalld, or
> is it ok to stop support for iptables and support only firewalld without
> overlap? If so, do we handle upgrades, and how?
>
> 2. Do we want to support custom firewalld xml to be configured on the
> host by us? Or is it ok to only support choosing among existing services,
> which will need to be added to the host using other means (packaged by
> firewalld, packaged by 3rd parties, added manually by users)?
>
> 3. Opposite of (2.): Do we want to support firewalld services that are
> added to the host using other means (see there)? Obviously we do, but:
> If we do, do we still want to support also iptables (see (1.))? And if
> so, what do we want to then happen?
>
> (2.) and (3.) are not conflicting, each needs its own answer.
>
>
> --
> Didi
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Firewalld migration.

[Edward Haas]

I may be too naive, but it all sounds too complex to me.
Is there any reference to the use cases of the firewall configuration?

Few questions:
- Why do we need to use firewalld?
- What is the role of the central management in this regard?
-- Does it need to manage firewalls per host in detail? (are we acting as a
firewall management system?)
-- Does it need to apply a firewall template configuration to all the
hosts? (all being identical)
-- Does it need to specify what services it wants the host to run and
mention if the whole setup should be harden or not?

As far as I know, firewalld and iptables can co-exist, therefore, I do not
see the need to 'upgrade' or perform a hard replacement.
It can be done as an option (firewall-type: iptables/firewalld).
On upgrade it continues with the 'old' definition and on new created host
the default can be firewalld.
Is someone will explicitly want to change it from one to the other, we
could go with remove/add approach to make things simpler.

I personally like the distributed approach, where the upper management
layer passes what it wants to the lower layers with minimum information.
Letting the lower levels
do the explicit work and figure out what they need to do.
If that was the original approach, Engine would have not 'care' what type
of firewall you use down at the host, you could even use a custom firewall,
an NFV firewall solution
or anything that may pop up in the future.
Engine would have just said: I want libvirt, vdsm, ssh, etc... services
opened (for access from ...).
Custom settings? That implies we manage firewalls. So either let the user
add their special stuff on the hosts or provide them with a proper firewall
management interface.

Thanks,
Edy.


On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David  wrote:

> On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali  wrote:
> >
> >
> > On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg 
> wrote:
> >>
> >> Hey Oved,
> >>
> >> I don't think completely moving away from iptables is foreseeable at
> this
> >> point, but I could be of course wrong. Either way, upgrading still
> needs to
> >> be thought of.
> >>
> >
> > I see.
> >
> >>
> >> By stating that the current infrastructure is complex, I was referring
> to
> >> the entire chain of storing rules in the database, fetching them using a
> >> dedicated deployment class consisting of include/exclude logic, sending
> them
> >> over, unpacking, deploying...
> >>
> >> This procedure involves a lot of code that could be made redundant if
> the
> >> required logic is present in the host, which to me seems favorable. It
> of
> >> course entails other potential difficulties, primarily in the form of
> custom
> >> services.
> >>
> >> I don't think otopi's firewalld plugin is any more complex than the
> >> potential code that will have to be written in vdsm-tool, however it
> >> currently expects the data generated by aforementioned chain. The hybrid
> >> approach briefly touches on simplifying Engine's involvement while
> retaining
> >> use of otopi's plugin.
> >>
> >
> > Okay. I think that writing a new plugin for firewalld is indeed a good
> > option, whether you "refactor" the engine side or not.
>
> otopi already has a 'firewalld' plugin. It's already in use, at least
> by engine-setup, so we should be a bit careful if we want to change it.
> Not preventing/objecting anything, just mentioning.
>
> This plugin's interface currently only takes XML-content as input.
> It has no place for configuring existing firewalld services presumably
> already provided elsewhere (by firewalld itself or 3rd party packages,
> such as vdsm). So if we go that route we probably want to extend this
> interface to allow passing service names and rely on them being defined
> elsewhere.
>
> A related issue is that for engine-setup, the _input_ is currently
> firewalld xml content, and if users choose to configure 'iptables',
> this is parsed to generate iptables rules. This is currently an
> engine-setup
> issue only, but will affect also host deploy flow if we decided to
> allow passing service names (without their xml content) and still keep
> compatibility to current state and allow configuring iptables on the
> host. We'll then be there in the same situation we are at with
> engine-setup.
> See also https://bugzilla.redhat.com/1432354 . An alternative is obviously
> deciding to remove iptables support and support only firewalld, but this
> is a rather radical change for users, imo.
>
> See also this for some of the existing behavior of engine-setup:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1024707#c9
>
> IMO we first need to decide what we want, then how to do that. IMO the
> questions we have re "what we want" are, more-or-less:
>
> 1. Do we want to support in some version X both iptables and firewalld, or
> is it ok to stop support for iptables and support only firewalld without
> overlap? If so, do we handle upgrades, and how?
>
> 2. Do we want to support custom firewalld xml to be co

[ovirt-devel] vdsm-hook-ovs dependency

[Daniel Belenky]

Hi all,

I try to test our master tested repo for repoclosure, and the test
fails on the following dependency:

10:44:49 package:
vdsm-hook-ovs-4.20.0-162.gitcc43be6.el7.centos.noarch from
internal_repo
10:44:49   unresolved deps:
10:44:49  vdsm = 0:4.20.0-162.gitcc43be6.el7.centos

When looking at the last builds of VDSM, I could not find this
package: *vdsm-hook-ovs* in the 'exported artifacts'.
Can someone advise where this package is coming from? Do we need this package?

Thanks,

-- 

*Daniel Belenky*

*RHV DevOps*

*Red Hat Israel*
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Gsoc proposal on Configuring backup storage in ovirt

[Greg Sheremeta]

Nice job, Shubham :) I added some suggestions to your document.

Do you have any plans for UI changes? In your examples, I only saw REST API
calls.

Best wishes,
Greg


On Sun, Mar 26, 2017 at 4:38 AM, shubham dubey  wrote:

> hello,
> I was mentioning about the http://www.ovirt.org/develop/
> release-management/features/storage/online-virtual-drive-resize/.
> since it was written in the docs that shrinking drive is not supported yet
> hence I have decided to work on that.But if it is
> already supported in 4.1v then I think I need to remove them from my
> proposal.:).
>
> Thanks,
> Shubham
>
> On Sun, Mar 26, 2017 at 1:55 PM, Maor Lipchuk  wrote:
>
>> Hi Shubham,
>>
>> The proposal looks very impressive, good job!
>>
>> I got a question regarding what you mentioned about the "Online
>> Virtual Drive Resize" feature.
>> Did you refer to the ovirt sparsify feature:
>> http://www.ovirt.org/develop/release-management/features/virt-sparsify/
>>
>> or the online-virtual-drive-resize feature:
>> http://www.ovirt.org/develop/release-management/features/sto
>> rage/online-virtual-drive-resize/
>>
>> both should be supported in oVirt 4.1 IINM
>>
>> Regarding the synopsis section which you mentioned the supported types
>> of storage domains, please also add Ceph as part of the block Storage
>> Domains. oVirt 3.6 should supports it through Cinder.
>>
>> Regards,
>> Maor
>>
>> On Sun, Mar 26, 2017 at 8:12 AM, shubham dubey 
>> wrote:
>> > Hello,
>> > I have created the draft proposal recently on Configuring backup
>> storage in
>> > ovirt.Here is the link to view
>> > https://docs.google.com/document/d/1orulgCTY1K6jUmomCIgZHA0g
>> 9xsWWUqttj0c1R0d9uU.
>> > Any suggestion or comments are welcome.
>> >
>> > Thanks,
>> > Shubham Dubey
>>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gsher...@redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Firewalld migration.

[Yedidyah Bar David]

On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali  wrote:
>
>
> On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg  wrote:
>>
>> Hey Oved,
>>
>> I don't think completely moving away from iptables is foreseeable at this
>> point, but I could be of course wrong. Either way, upgrading still needs to
>> be thought of.
>>
>
> I see.
>
>>
>> By stating that the current infrastructure is complex, I was referring to
>> the entire chain of storing rules in the database, fetching them using a
>> dedicated deployment class consisting of include/exclude logic, sending them
>> over, unpacking, deploying...
>>
>> This procedure involves a lot of code that could be made redundant if the
>> required logic is present in the host, which to me seems favorable. It of
>> course entails other potential difficulties, primarily in the form of custom
>> services.
>>
>> I don't think otopi's firewalld plugin is any more complex than the
>> potential code that will have to be written in vdsm-tool, however it
>> currently expects the data generated by aforementioned chain. The hybrid
>> approach briefly touches on simplifying Engine's involvement while retaining
>> use of otopi's plugin.
>>
>
> Okay. I think that writing a new plugin for firewalld is indeed a good
> option, whether you "refactor" the engine side or not.

otopi already has a 'firewalld' plugin. It's already in use, at least
by engine-setup, so we should be a bit careful if we want to change it.
Not preventing/objecting anything, just mentioning.

This plugin's interface currently only takes XML-content as input.
It has no place for configuring existing firewalld services presumably
already provided elsewhere (by firewalld itself or 3rd party packages,
such as vdsm). So if we go that route we probably want to extend this
interface to allow passing service names and rely on them being defined
elsewhere.

A related issue is that for engine-setup, the _input_ is currently
firewalld xml content, and if users choose to configure 'iptables',
this is parsed to generate iptables rules. This is currently an engine-setup
issue only, but will affect also host deploy flow if we decided to
allow passing service names (without their xml content) and still keep
compatibility to current state and allow configuring iptables on the
host. We'll then be there in the same situation we are at with engine-setup.
See also https://bugzilla.redhat.com/1432354 . An alternative is obviously
deciding to remove iptables support and support only firewalld, but this
is a rather radical change for users, imo.

See also this for some of the existing behavior of engine-setup:

https://bugzilla.redhat.com/show_bug.cgi?id=1024707#c9

IMO we first need to decide what we want, then how to do that. IMO the
questions we have re "what we want" are, more-or-less:

1. Do we want to support in some version X both iptables and firewalld, or
is it ok to stop support for iptables and support only firewalld without
overlap? If so, do we handle upgrades, and how?

2. Do we want to support custom firewalld xml to be configured on the
host by us? Or is it ok to only support choosing among existing services,
which will need to be added to the host using other means (packaged by
firewalld, packaged by 3rd parties, added manually by users)?

3. Opposite of (2.): Do we want to support firewalld services that are
added to the host using other means (see there)? Obviously we do, but:
If we do, do we still want to support also iptables (see (1.))? And if
so, what do we want to then happen?

(2.) and (3.) are not conflicting, each needs its own answer.

My (thoughts about) answers:

1. If done well enough, and considerably simplifies things, I think it's
ok to jump directly from "only iptables" to "only firewalld", but then
we should announce this ahead of time to give users time to plan/prepare.
If it's not too costly, I'd prefer to support both for the foreseeable
future, though.

2. Latter option here is problematic, if we need/want to allow
customizing services during deploy. E.g. suppose that one day we want
to make the vdsm port configurable. It will be nice if this can be done
by only changing things on the engine, without having to distribute
changes (conf and/or packages) to all hosts before host-deploy.
I'd say we can go a long way here by having a strict requirement from
all services that we need/want on hosts to have official IANA-registered
port numbers - then, it's imo much easier to tell users "If you want to
change the port for service X, you have to (long list of complex actions
goes here)". Currently, where services are not registered, we risk
conflicts with existing services, requiring the user to change ports -
and so we can't make this process too difficult. No idea how important
this is in practice.

3. Not sure :-( I'd say that if we want to support both iptables and
firewalld together, and support both "xml in engine" and "xml in host",
then it might be ok if the custom rules/services will not automatically
appl

Re: [ovirt-devel] Firewalld migration.

[Oved Ourfali]

On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg  wrote:

> Hey Oved,
>
> I don't think completely moving away from iptables is foreseeable at this
> point, but I could be of course wrong. Either way, upgrading still needs to
> be thought of.
>
>
I see.


> By stating that the current infrastructure is complex, I was referring to
> the entire chain of storing rules in the database, fetching them using a
> dedicated deployment class consisting of include/exclude logic, sending
> them over, unpacking, deploying...
>
> This procedure involves a lot of code that could be made redundant if the
> required logic is present in the host, which to me seems favorable. It of
> course entails other potential difficulties, primarily in the form of
> custom services.
>
> I don't think otopi's firewalld plugin is any more complex than the
> potential code that will have to be written in vdsm-tool, however it
> currently expects the data generated by aforementioned chain. The hybrid
> approach briefly touches on simplifying Engine's involvement while
> retaining use of otopi's plugin.
>
>
Okay. I think that writing a new plugin for firewalld is indeed a good
option, whether you "refactor" the engine side or not.


>
>
> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali  wrote:
>
>> top-posting:
>> You need to also consider how upgrade will be handled, right?
>> Or iptables will still remain supported?
>>
>> Also, see some comments inline.
>>
>> Regards,
>> Oved
>>
>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg 
>> wrote:
>>
>>>
>>> Hey,
>>>
>>> We're looking to migrate from iptables to firewalld. We came up with a
>>> couple of possible approaches we'd like opinions on. I'll list the options
>>> first, and will
>>>
>>> 1) Replicate existing flow:
>>>
>>> As of date, iptable rules are inserted in the database via SQL config
>>> files. During host deployment, VdsDeployIptablesUnit adds the required
>>> rules (based on cluster/firewall configuration) to the deployment
>>> configuration, en route to being deployed on the host via otopi and its
>>> iptables plugin.
>>>
>>> Pros:
>>>
>>> - Reuse of existing infrastructure.
>>>
>>> Cons:
>>>
>>> - Current infrastructure is overly complex...
>>>
>>
>> Can you elaborate?
>> I'm not an otopi expert, but I think that otopi plugins shouldn't be more
>> complex than what you describe in section #2, and the plugins were meant in
>> order to handle such cases.
>>
>> - Many of the required services are provided by firewalld. Rewriting them
>>> is wasteful; specifying them (instead of providing actual service .xml
>>> content) will require adaptations on both (engine/host) sides. More on that
>>> later.
>>>
>>>
>>> 2) Host side based configuration:
>>>
>>> Essentially, all the required logic (aforementioned cluster/firewall
>>> configuration) to determine if/how firewalld should be deployed could be
>>> passed on to the host via ohd. Vdsm could take on the responsibility of
>>> examining the relevant configuration, and then creating and/or adding the
>>> required services (using vdsm.conf and vdsm-tool).
>>>
>>>
>> So here you replace the otopi plugin with relevant vdsm-tool code, and
>> the question is why is that better?
>>
>>
>>> Pros:
>>>
>>>  - Engine side involvement is greatly diminished.
>>>  - Simple(r).
>>>
>>> Cons:
>>>
>>>  - Custom services/rules capabilities will have to be rethought and
>>> re-implemented (current infrastructure supports custom iptables rules by
>>> being specified in the SQL config file).
>>>
>>>
>>> 3) Some other hybrid approach:
>>>
>>> If we're able to guarantee all the required firewalld services are
>>> statically provided one way or the other, the current procedure could be
>>> replicated and be made more simpler. Instead of providing xml content in
>>> the form of strings, service names could be supplied. The responsibility of
>>> actual service deployment becomes easier, and could be left to otopi (with
>>> the appropriate modifications) or switched over to vdsm.
>>>
>>> --
>>>
>>> Regardless, usage of statically provided vs. dynamically created
>>> services remains an open question. I think we'd like to avoid implementing
>>> logic that ask whether some service is provided (and then write it if it
>>> isn't...), and so choosing between the dynamic and static approaches is
>>> also needed. Using the static approach, guaranteeing *all* services are
>>> provided will be required.
>>>
>>> I do believe guaranteeing the presence of all required services is worth
>>> it, however custom services aren't going to be naively compatible, and
>>> we'll still have to use similar mechanism as described in #1 (service
>>> string -> .xml -> addition of service name to active zone).
>>>
>>>
>>> Your thoughts are welcome.
>>>
>>> Thanks,
>>> Leon
>>>
>>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Firewalld migration.

[Leon Goldberg]

Hey Oved,

I don't think completely moving away from iptables is foreseeable at this
point, but I could be of course wrong. Either way, upgrading still needs to
be thought of.

By stating that the current infrastructure is complex, I was referring to
the entire chain of storing rules in the database, fetching them using a
dedicated deployment class consisting of include/exclude logic, sending
them over, unpacking, deploying...

This procedure involves a lot of code that could be made redundant if the
required logic is present in the host, which to me seems favorable. It of
course entails other potential difficulties, primarily in the form of
custom services.

I don't think otopi's firewalld plugin is any more complex than the
potential code that will have to be written in vdsm-tool, however it
currently expects the data generated by aforementioned chain. The hybrid
approach briefly touches on simplifying Engine's involvement while
retaining use of otopi's plugin.


On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali  wrote:

> top-posting:
> You need to also consider how upgrade will be handled, right?
> Or iptables will still remain supported?
>
> Also, see some comments inline.
>
> Regards,
> Oved
>
> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg 
> wrote:
>
>>
>> Hey,
>>
>> We're looking to migrate from iptables to firewalld. We came up with a
>> couple of possible approaches we'd like opinions on. I'll list the options
>> first, and will
>>
>> 1) Replicate existing flow:
>>
>> As of date, iptable rules are inserted in the database via SQL config
>> files. During host deployment, VdsDeployIptablesUnit adds the required
>> rules (based on cluster/firewall configuration) to the deployment
>> configuration, en route to being deployed on the host via otopi and its
>> iptables plugin.
>>
>> Pros:
>>
>> - Reuse of existing infrastructure.
>>
>> Cons:
>>
>> - Current infrastructure is overly complex...
>>
>
> Can you elaborate?
> I'm not an otopi expert, but I think that otopi plugins shouldn't be more
> complex than what you describe in section #2, and the plugins were meant in
> order to handle such cases.
>
> - Many of the required services are provided by firewalld. Rewriting them
>> is wasteful; specifying them (instead of providing actual service .xml
>> content) will require adaptations on both (engine/host) sides. More on that
>> later.
>>
>>
>> 2) Host side based configuration:
>>
>> Essentially, all the required logic (aforementioned cluster/firewall
>> configuration) to determine if/how firewalld should be deployed could be
>> passed on to the host via ohd. Vdsm could take on the responsibility of
>> examining the relevant configuration, and then creating and/or adding the
>> required services (using vdsm.conf and vdsm-tool).
>>
>>
> So here you replace the otopi plugin with relevant vdsm-tool code, and the
> question is why is that better?
>
>
>> Pros:
>>
>>  - Engine side involvement is greatly diminished.
>>  - Simple(r).
>>
>> Cons:
>>
>>  - Custom services/rules capabilities will have to be rethought and
>> re-implemented (current infrastructure supports custom iptables rules by
>> being specified in the SQL config file).
>>
>>
>> 3) Some other hybrid approach:
>>
>> If we're able to guarantee all the required firewalld services are
>> statically provided one way or the other, the current procedure could be
>> replicated and be made more simpler. Instead of providing xml content in
>> the form of strings, service names could be supplied. The responsibility of
>> actual service deployment becomes easier, and could be left to otopi (with
>> the appropriate modifications) or switched over to vdsm.
>>
>> --
>>
>> Regardless, usage of statically provided vs. dynamically created services
>> remains an open question. I think we'd like to avoid implementing logic
>> that ask whether some service is provided (and then write it if it
>> isn't...), and so choosing between the dynamic and static approaches is
>> also needed. Using the static approach, guaranteeing *all* services are
>> provided will be required.
>>
>> I do believe guaranteeing the presence of all required services is worth
>> it, however custom services aren't going to be naively compatible, and
>> we'll still have to use similar mechanism as described in #1 (service
>> string -> .xml -> addition of service name to active zone).
>>
>>
>> Your thoughts are welcome.
>>
>> Thanks,
>> Leon
>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Firewalld migration.

[Oved Ourfali]

top-posting:
You need to also consider how upgrade will be handled, right?
Or iptables will still remain supported?

Also, see some comments inline.

Regards,
Oved

On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg  wrote:

>
> Hey,
>
> We're looking to migrate from iptables to firewalld. We came up with a
> couple of possible approaches we'd like opinions on. I'll list the options
> first, and will
>
> 1) Replicate existing flow:
>
> As of date, iptable rules are inserted in the database via SQL config
> files. During host deployment, VdsDeployIptablesUnit adds the required
> rules (based on cluster/firewall configuration) to the deployment
> configuration, en route to being deployed on the host via otopi and its
> iptables plugin.
>
> Pros:
>
> - Reuse of existing infrastructure.
>
> Cons:
>
> - Current infrastructure is overly complex...
>

Can you elaborate?
I'm not an otopi expert, but I think that otopi plugins shouldn't be more
complex than what you describe in section #2, and the plugins were meant in
order to handle such cases.

- Many of the required services are provided by firewalld. Rewriting them
> is wasteful; specifying them (instead of providing actual service .xml
> content) will require adaptations on both (engine/host) sides. More on that
> later.
>
>
> 2) Host side based configuration:
>
> Essentially, all the required logic (aforementioned cluster/firewall
> configuration) to determine if/how firewalld should be deployed could be
> passed on to the host via ohd. Vdsm could take on the responsibility of
> examining the relevant configuration, and then creating and/or adding the
> required services (using vdsm.conf and vdsm-tool).
>
>
So here you replace the otopi plugin with relevant vdsm-tool code, and the
question is why is that better?


> Pros:
>
>  - Engine side involvement is greatly diminished.
>  - Simple(r).
>
> Cons:
>
>  - Custom services/rules capabilities will have to be rethought and
> re-implemented (current infrastructure supports custom iptables rules by
> being specified in the SQL config file).
>
>
> 3) Some other hybrid approach:
>
> If we're able to guarantee all the required firewalld services are
> statically provided one way or the other, the current procedure could be
> replicated and be made more simpler. Instead of providing xml content in
> the form of strings, service names could be supplied. The responsibility of
> actual service deployment becomes easier, and could be left to otopi (with
> the appropriate modifications) or switched over to vdsm.
>
> --
>
> Regardless, usage of statically provided vs. dynamically created services
> remains an open question. I think we'd like to avoid implementing logic
> that ask whether some service is provided (and then write it if it
> isn't...), and so choosing between the dynamic and static approaches is
> also needed. Using the static approach, guaranteeing *all* services are
> provided will be required.
>
> I do believe guaranteeing the presence of all required services is worth
> it, however custom services aren't going to be naively compatible, and
> we'll still have to use similar mechanism as described in #1 (service
> string -> .xml -> addition of service name to active zone).
>
>
> Your thoughts are welcome.
>
> Thanks,
> Leon
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Firewalld migration.

[Leon Goldberg]

Hey,

We're looking to migrate from iptables to firewalld. We came up with a
couple of possible approaches we'd like opinions on. I'll list the options
first, and will

1) Replicate existing flow:

As of date, iptable rules are inserted in the database via SQL config
files. During host deployment, VdsDeployIptablesUnit adds the required
rules (based on cluster/firewall configuration) to the deployment
configuration, en route to being deployed on the host via otopi and its
iptables plugin.

Pros:

- Reuse of existing infrastructure.

Cons:

- Current infrastructure is overly complex...
- Many of the required services are provided by firewalld. Rewriting them
is wasteful; specifying them (instead of providing actual service .xml
content) will require adaptations on both (engine/host) sides. More on that
later.


2) Host side based configuration:

Essentially, all the required logic (aforementioned cluster/firewall
configuration) to determine if/how firewalld should be deployed could be
passed on to the host via ohd. Vdsm could take on the responsibility of
examining the relevant configuration, and then creating and/or adding the
required services (using vdsm.conf and vdsm-tool).

Pros:

 - Engine side involvement is greatly diminished.
 - Simple(r).

Cons:

 - Custom services/rules capabilities will have to be rethought and
re-implemented (current infrastructure supports custom iptables rules by
being specified in the SQL config file).


3) Some other hybrid approach:

If we're able to guarantee all the required firewalld services are
statically provided one way or the other, the current procedure could be
replicated and be made more simpler. Instead of providing xml content in
the form of strings, service names could be supplied. The responsibility of
actual service deployment becomes easier, and could be left to otopi (with
the appropriate modifications) or switched over to vdsm.

--

Regardless, usage of statically provided vs. dynamically created services
remains an open question. I think we'd like to avoid implementing logic
that ask whether some service is provided (and then write it if it
isn't...), and so choosing between the dynamic and static approaches is
also needed. Using the static approach, guaranteeing *all* services are
provided will be required.

I do believe guaranteeing the presence of all required services is worth
it, however custom services aren't going to be naively compatible, and
we'll still have to use similar mechanism as described in #1 (service
string -> .xml -> addition of service name to active zone).


Your thoughts are welcome.

Thanks,
Leon
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt 4.1 ] [ 24-03-2017 ] [ 002_bootstrap.list_glance_images ]

[Yaniv Kaul]

On Sun, Mar 26, 2017 at 11:59 AM, Shlomo Ben David 
wrote:

> Hi,
>
> Test failed: [ 002_bootstrap.list_glance_images ]
> Link to suspected patches: N/A
> Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_
> experimental_4.1/1063
> Link to all logs: http://jenkins.ovirt.org/job/test-repo_ovirt_
> experimental_4.1/1063/artifact/exported-artifacts/
> basic-suit-4.1-el7/test_logs/basic-suite-4.1/post-002_bootstrap.py/
>
> Error snippet from the log:
>

Same error as in master - perhaps there's a different issue there? Is test
connectivity broken for some reason? Perhaps connectivity issue that we did
not overcome?
Y.


> 
>
> 2017-03-24 08:04:46,983-04 ERROR [org.ovirt.engine.core.
> vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-7-thread-1)
> [2b2b4693] Command 'PollVDSCommand(HostName = lago-basic-suite-4-1-host1,
> VdsIdVDSCommandParametersBase:{runAsync='true',
> hostId='746e816f-6e21-4185-9d50-3e90ebefb187'})' execution failed:
> VDSGenericException: VDSNetworkException: Timeout during rpc call
> 2017-03-24 08:04:46,983-04 DEBUG [org.ovirt.engine.core.
> vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-7-thread-1)
> [2b2b4693] Exception: 
> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
> VDSGenericException: VDSNetworkException: Timeout during rpc call
> at 
> org.ovirt.engine.core.vdsbroker.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:73)
> [vdsbroker.jar:]
> at org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.getValue(
> HostSetupNetworkPoller.java:56) [bll.jar:]
> at org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.poll(
> HostSetupNetworkPoller.java:41) [bll.jar:]
> at org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.
> invokeSetupNetworksCommand(HostSetupNetworksCommand.java:426) [bll.jar:]
> at org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.
> executeCommand(HostSetupNetworksCommand.java:287) [bll.jar:]
> at 
> org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1251)
> [bll.jar:]
> at 
> org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1391)
> [bll.jar:]
> at 
> org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:2055)
> [bll.jar:]
> at org.ovirt.engine.core.utils.transaction.TransactionSupport.
> executeInSuppressed(TransactionSupport.java:164) [utils.jar:]
> at org.ovirt.engine.core.utils.transaction.TransactionSupport.
> executeInScope(TransactionSupport.java:103) [utils.jar:]
> at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1451)
> [bll.jar:]
> at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:397)
> [bll.jar:]
> at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.
> execute(DefaultBackendActionExecutor.java:13) [bll.jar:]
> at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:511)
> [bll.jar:]
> at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:493)
> [bll.jar:]
> at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:697)
> [bll.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.8.0_121]
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_121]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_121]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_121]
> at org.jboss.as.ee.component.ManagedReferenceMethodIntercep
> tor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.
> proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(
> Jsr299BindingsInterceptor.java:70) [wildfly-weld-10.1.0.Final.
> jar:10.1.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(
> Jsr299BindingsInterceptor.java:80) [wildfly-weld-10.1.0.Final.
> jar:10.1.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(
> Jsr299BindingsInterceptor.java:93) [wildfly-weld-10.1.0.Final.
> jar:10.1.0.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.
> processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.
> processInvocation(ExecutionTimeInterceptor.java:43)
> [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.
> proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivat
> ionInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> [weld-core-impl-2.3.5.Final.jar:2.3.5.

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 24-03-2017 ] [ 002_bootstrap.list_glance_images ]

[Yaniv Kaul]

On Sun, Mar 26, 2017 at 11:45 AM, Shlomo Ben David 
wrote:

> Hi,
>
> Test failed: [ 002_bootstrap.list_glance_images ]
> Link to suspected patches: N/A
> Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_
> experimental_master/5997
> Link to all logs: http://jenkins.ovirt.org/job/test-repo_ovirt_
> experimental_master/5997/artifact/exported-artifacts/
> basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/
>
> Error snippet from the log:
>

I don't think the below is the correct error.
This is:
2017-03-23 20:21:11,433-04 ERROR
[org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand]
(default task-30) [65e52c9d-67c9-49e5-8337-ac936a8d2553] Command
'org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand'
failed: EngineException: (Failed with error PROVIDER_FAILURE and code 5050)
2017-03-23 20:21:11,446-04 ERROR
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default
task-30) [] Operation Failed: [Failed to communicate with the external
provider, see log for additional details.]

Did it start right after https://gerrit.ovirt.org/#/c/72083/ ?
Y.



> 
>
> 2017-03-23 20:19:39,699-04 ERROR 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand]
> (org.ovirt.thread.pool-7-thread-2) [796c74] Command
> 'PollVDSCommand(HostName = lago-basic-suite-master-host1,
> VdsIdVDSCommandParametersBase:{runAsync='true',
> hostId='e8fa4803-7372-41d9-b5a5-848d08773479'})' execution failed:
> VDSGenericException: VDSNetworkException: Timeout during rpc call
> 2017-03-23 20:19:39,699-04 DEBUG 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand]
> (org.ovirt.thread.pool-7-thread-2) [796c74] Exception:
> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
> VDSGenericException: VDSNetworkException: Timeout during rpc call
> at 
> org.ovirt.engine.core.vdsbroker.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:74)
> [vdsbroker.jar:]
> at org.ovirt.engine.core.bll.network.host.HostSetupNetworkPolle
> r.getValue(HostSetupNetworkPoller.java:56) [bll.jar:]
> at org.ovirt.engine.core.bll.network.host.HostSetupNetworkPolle
> r.poll(HostSetupNetworkPoller.java:41) [bll.jar:]
> at org.ovirt.engine.core.bll.network.host.HostSetupNetworksComm
> and.invokeSetupNetworksCommand(HostSetupNetworksCommand.java:422)
> [bll.jar:]
> at org.ovirt.engine.core.bll.network.host.HostSetupNetworksComm
> and.executeCommand(HostSetupNetworksCommand.java:290) [bll.jar:]
> at 
> org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1253)
> [bll.jar:]
> at org.ovirt.engine.core.bll.CommandBase.executeActionInTransac
> tionScope(CommandBase.java:1393) [bll.jar:]
> at 
> org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:2057)
> [bll.jar:]
> at org.ovirt.engine.core.utils.transaction.TransactionSupport.e
> xecuteInSuppressed(TransactionSupport.java:164) [utils.jar:]
> at org.ovirt.engine.core.utils.transaction.TransactionSupport.e
> xecuteInScope(TransactionSupport.java:103) [utils.jar:]
> at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1453)
> [bll.jar:]
> at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:397)
> [bll.jar:]
> at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecu
> tor.execute(DefaultBackendActionExecutor.java:13) [bll.jar:]
> at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:496)
> [bll.jar:]
> at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:478)
> [bll.jar:]
> at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:684)
> [bll.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.8.0_121]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [rt.jar:1.8.0_121]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_121]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_121]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.
> processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorC
> ontext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(
> InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInte
> rception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-10.1.0.Final.jar
> :10.1.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInte
> rception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-10.1.0.Final.jar
> :10.1.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvoc
> ation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-10.1.0.Final.jar
> :10.1.0.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactor
> y$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorC
> ontext.java:340)
> at org.jboss.as.ejb3.component.in

[ovirt-devel] [ OST Failure Report ] [ oVirt 4.1 ] [ 24-03-2017 ] [ 002_bootstrap.list_glance_images ]

[Shlomo Ben David]

Hi,

Test failed: [ 002_bootstrap.list_glance_images ]
Link to suspected patches: N/A
Link to Job:
http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/1063
Link to all logs:
http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/1063/artifact/exported-artifacts/basic-suit-4.1-el7/test_logs/basic-suite-4.1/post-002_bootstrap.py/

Error snippet from the log:


2017-03-24 08:04:46,983-04 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand]
(org.ovirt.thread.pool-7-thread-1) [2b2b4693] Command
'PollVDSCommand(HostName = lago-basic-suite-4-1-host1,
VdsIdVDSCommandParametersBase:{runAsync='true',
hostId='746e816f-6e21-4185-9d50-3e90ebefb187'})' execution failed:
VDSGenericException: VDSNetworkException: Timeout during rpc call
2017-03-24 08:04:46,983-04 DEBUG
[org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand]
(org.ovirt.thread.pool-7-thread-1) [2b2b4693] Exception:
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
VDSGenericException: VDSNetworkException: Timeout during rpc call
at
org.ovirt.engine.core.vdsbroker.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:73)
[vdsbroker.jar:]
at
org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.getValue(HostSetupNetworkPoller.java:56)
[bll.jar:]
at
org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.poll(HostSetupNetworkPoller.java:41)
[bll.jar:]
at
org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.invokeSetupNetworksCommand(HostSetupNetworksCommand.java:426)
[bll.jar:]
at
org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.executeCommand(HostSetupNetworksCommand.java:287)
[bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1251)
[bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1391)
[bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:2055)
[bll.jar:]
at
org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164)
[utils.jar:]
at
org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103)
[utils.jar:]
at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1451)
[bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:397)
[bll.jar:]
at
org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13)
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:511) [bll.jar:]
at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:493)
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:697)
[bll.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.8.0_121]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[rt.jar:1.8.0_121]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_121]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_121]
at
org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70)
[wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80)
[wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
[wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
[wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at
org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
[weld-core-impl-2.3.5.Final.jar:2.3.5.Final]
at
org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
[wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
[wildfly-ee-10.1.0.Final.jar:10.1.0.Final]
at
org.jboss.invocation.InterceptorConte

[ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 24-03-2017 ] [ 002_bootstrap.list_glance_images ]

[Shlomo Ben David]

Hi,

Test failed: [ 002_bootstrap.list_glance_images ]
Link to suspected patches: N/A
Link to Job:
http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/5997
Link to all logs:
http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/5997/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/

Error snippet from the log:


2017-03-23 20:19:39,699-04 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand]
(org.ovirt.thread.pool-7-thread-2) [796c74] Command
'PollVDSCommand(HostName = lago-basic-suite-master-host1,
VdsIdVDSCommandParametersBase:{runAsync='true',
hostId='e8fa4803-7372-41d9-b5a5-848d08773479'})'
execution failed: VDSGenericException: VDSNetworkException: Timeout during
rpc call
2017-03-23 20:19:39,699-04 DEBUG
[org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand]
(org.ovirt.thread.pool-7-thread-2) [796c74] Exception:
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
VDSGenericException: VDSNetworkException: Timeout during rpc call
at 
org.ovirt.engine.core.vdsbroker.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:74)
[vdsbroker.jar:]
at org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.getValue(
HostSetupNetworkPoller.java:56) [bll.jar:]
at org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.poll(
HostSetupNetworkPoller.java:41) [bll.jar:]
at org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.
invokeSetupNetworksCommand(HostSetupNetworksCommand.java:422) [bll.jar:]
at org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.
executeCommand(HostSetupNetworksCommand.java:290) [bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1253)
[bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1393)
[bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:2057)
[bll.jar:]
at org.ovirt.engine.core.utils.transaction.TransactionSupport.
executeInSuppressed(TransactionSupport.java:164) [utils.jar:]
at org.ovirt.engine.core.utils.transaction.TransactionSupport.
executeInScope(TransactionSupport.java:103) [utils.jar:]
at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1453)
[bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:397)
[bll.jar:]
at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(
DefaultBackendActionExecutor.java:13) [bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:496) [bll.jar:]
at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:478)
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:684)
[bll.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.8.0_121]
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_121]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_121]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_121]
at org.jboss.as.ee.component.ManagedReferenceMethodIntercep
tor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(
InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.
proceed(InterceptorContext.java:437)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(
Jsr299BindingsInterceptor.java:70) [wildfly-weld-10.1.0.Final.
jar:10.1.0.Final]
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(
Jsr299BindingsInterceptor.java:80) [wildfly-weld-10.1.0.Final.
jar:10.1.0.Final]
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(
Jsr299BindingsInterceptor.java:93) [wildfly-weld-10.1.0.Final.
jar:10.1.0.Final]
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.
processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(
InterceptorContext.java:340)
at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.
processInvocation(ExecutionTimeInterceptor.java:43)
[wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(
InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.
proceed(InterceptorContext.java:437)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivat
ionInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
[weld-core-impl-2.3.5.Final.jar:2.3.5.Final]
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInter
ceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
[wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(
InterceptorContext.java:340)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.
processInvocation(ConcurrentContextInterceptor.java:45)
[wildfly-ee-10.1.0.Final.jar:10.1.0.Final]

Re: [ovirt-devel] Gsoc proposal on Configuring backup storage in ovirt

[shubham dubey]

hello,
I was mentioning about the
http://www.ovirt.org/develop/release-management/features/storage/online-virtual-drive-resize/
.
since it was written in the docs that shrinking drive is not supported yet
hence I have decided to work on that.But if it is
already supported in 4.1v then I think I need to remove them from my
proposal.:).

Thanks,
Shubham

On Sun, Mar 26, 2017 at 1:55 PM, Maor Lipchuk  wrote:

> Hi Shubham,
>
> The proposal looks very impressive, good job!
>
> I got a question regarding what you mentioned about the "Online
> Virtual Drive Resize" feature.
> Did you refer to the ovirt sparsify feature:
> http://www.ovirt.org/develop/release-management/features/virt-sparsify/
>
> or the online-virtual-drive-resize feature:
> http://www.ovirt.org/develop/release-management/features/
> storage/online-virtual-drive-resize/
>
> both should be supported in oVirt 4.1 IINM
>
> Regarding the synopsis section which you mentioned the supported types
> of storage domains, please also add Ceph as part of the block Storage
> Domains. oVirt 3.6 should supports it through Cinder.
>
> Regards,
> Maor
>
> On Sun, Mar 26, 2017 at 8:12 AM, shubham dubey 
> wrote:
> > Hello,
> > I have created the draft proposal recently on Configuring backup storage
> in
> > ovirt.Here is the link to view
> > https://docs.google.com/document/d/1orulgCTY1K6jUmomCIgZHA0g9xsWW
> Uqttj0c1R0d9uU.
> > Any suggestion or comments are welcome.
> >
> > Thanks,
> > Shubham Dubey
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Gsoc proposal on Configuring backup storage in ovirt

[Maor Lipchuk]

Hi Shubham,

The proposal looks very impressive, good job!

I got a question regarding what you mentioned about the "Online
Virtual Drive Resize" feature.
Did you refer to the ovirt sparsify feature:
http://www.ovirt.org/develop/release-management/features/virt-sparsify/

or the online-virtual-drive-resize feature:
http://www.ovirt.org/develop/release-management/features/storage/online-virtual-drive-resize/

both should be supported in oVirt 4.1 IINM

Regarding the synopsis section which you mentioned the supported types
of storage domains, please also add Ceph as part of the block Storage
Domains. oVirt 3.6 should supports it through Cinder.

Regards,
Maor

On Sun, Mar 26, 2017 at 8:12 AM, shubham dubey  wrote:
> Hello,
> I have created the draft proposal recently on Configuring backup storage in
> ovirt.Here is the link to view
> https://docs.google.com/document/d/1orulgCTY1K6jUmomCIgZHA0g9xsWWUqttj0c1R0d9uU.
> Any suggestion or comments are welcome.
>
> Thanks,
> Shubham Dubey
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel