[ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.6.0 status
Hi, I haven't many news for 3.6 this week: ACTION: Feature proposed for 3.6.0 must now be collected in the 3.6 Google doc [1] and reviewed by maintainers. Finished the review process, the remaining key milestones for this release will be scheduled. For reference, external project schedules we're tracking are: Fedora 21: 2014-12-09 (RELEASED) Fedora 22: 2015-05-19 Foreman 1.8.0: 2015-03-01 GlusterFS 3.7: 2015-04-29 OpenStack Kilo: 2015-04-30 QEMU 2.1.3: 2014-01-21 QEMU 2.2.0: 2014-12-09 (RELEASED) QEMU 2.3.0: 2015-03-27 The tracker bug for 3.6.0 [2] currently shows no blockers. There are 480 bugs [3] targeted to 3.6.0. Excluding node and documentation bugs we have 454 bugs [4] targeted to 3.6.0. [1] http://goo.gl/9X3G49 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1155425 [3] http://goo.gl/zwkF3r [4] http://goo.gl/ZbUiMc -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed
Hi, We still have blockers for oVirt 3.5.1 RC release so we need to postpone it until they'll be fixed. The bug tracker [1] shows 1 open blocker: Bug ID Whiteboard Status Summary 1160846 sla POSTCan't add disk to VM without specifying disk profile when... In order to stabilize the release a new branch ovirt-engine-3.5.1 will be created from the same git hash used for composing the RC. - ACTION: Gilad please provide ETA on above blocker, the new proposed RC date will be decided on the given ETA. Maintainers: - Please be sure that 3.5 snapshot allow to create VMs - Please be sure that no pending patches are going to block the release - If any patch must block the RC release please raise the issue as soon as possible. There are still 61 bugs [2] targeted to 3.5.1. Excluding node and documentation bugs we still have 41 bugs [3] targeted to 3.5.1. Maintainers / Assignee: - Please add the bugs to the tracker if you think that 3.5.1 should not be released without them fixed. - ACTION: Please update the target to 3.5.2 or later for bugs that won't be in 3.5.1: it will ease gathering the blocking bugs for next releases. - ACTION: Please fill release notes, the page has been created here [4] Community: - If you're testing oVirt 3.5 nightly snapshot, please add yourself to the test page [5] [1] http://bugzilla.redhat.com/1155170 [2] http://goo.gl/7G0PDV [3] http://goo.gl/6gUbVr [4] http://www.ovirt.org/OVirt_3.5.1_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.5.1_Testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ENGINE][SLA] from time to time I'm getting the folowwing exception when running on master
- Original Message - > From: "Doron Fediuck" > To: "Yair Zaslavsky" > Cc: "Doron Fediuck" , "Gilad Chaplik" > , devel@ovirt.org > Sent: Wednesday, January 14, 2015 9:22:55 AM > Subject: Re: [ENGINE][SLA] from time to time I'm getting the folowwing > exception when running on master > > IS this on master or 3.5 branch? master > > On 01/14/2015 03:30 AM, Yair Zaslavsky wrote: > > 2015-01-14 03:30:27,407 INFO > > [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (MSC service > > thread 1-6) [] Initializing Scheduling manager > > 2015-01-14 03:30:27,438 ERROR > > [org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean] (MSC service > > thread 1-6) [] Failed to initialize backend: > > org.apache.commons.lang.NotImplementedException: policyUnit: Migration > > at > > > > org.ovirt.engine.core.bll.scheduling.PolicyUnitImpl.getPolicyUnitImpl(PolicyUnitImpl.java:116) > > [bll.jar:] > > at > > > > org.ovirt.engine.core.bll.scheduling.SchedulingManager.loadPolicyUnits(SchedulingManager.java:178) > > [bll.jar:] > > at > > > > org.ovirt.engine.core.bll.scheduling.SchedulingManager.init(SchedulingManager.java:101) > > [bll.jar:] > > at > > > > org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean.create(InitBackendServicesOnStartupBean.java:104) > > [bll.jar:] > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > [rt.jar:1.7.0_45] > > at > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > [rt.jar:1.7.0_45] > > at > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > [rt.jar:1.7.0_45] > > at java.lang.reflect.Method.invoke(Method.java:606) > > [rt.jar:1.7.0_45] > > at > > > > org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) > > [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] > > at > > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > > at > > > > org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > > at > > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > > at > > > > org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:73) > > [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final] > > at > > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > > at > > > > org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95) > > [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] > > at > > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > > at > > > > org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > > at > > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > > at > > > > org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > > [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] > > at > > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > > at > > > > org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) > > [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] > > at > > > > org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:333) > > [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] > > at > > > > org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56) > > [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] > > at org.jboss.invocation.InterceptorContext.proceed(Intercep > > > > > > Can someone explain me how to resolve? > > > > Cheers, > > Yair > > > > > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ENGINE][SLA] from time to time I'm getting the folowwing exception when running on master
IS this on master or 3.5 branch? On 01/14/2015 03:30 AM, Yair Zaslavsky wrote: > 2015-01-14 03:30:27,407 INFO > [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (MSC service thread > 1-6) [] Initializing Scheduling manager > 2015-01-14 03:30:27,438 ERROR > [org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean] (MSC service > thread 1-6) [] Failed to initialize backend: > org.apache.commons.lang.NotImplementedException: policyUnit: Migration > at > org.ovirt.engine.core.bll.scheduling.PolicyUnitImpl.getPolicyUnitImpl(PolicyUnitImpl.java:116) > [bll.jar:] > at > org.ovirt.engine.core.bll.scheduling.SchedulingManager.loadPolicyUnits(SchedulingManager.java:178) > [bll.jar:] > at > org.ovirt.engine.core.bll.scheduling.SchedulingManager.init(SchedulingManager.java:101) > [bll.jar:] > at > org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean.create(InitBackendServicesOnStartupBean.java:104) > [bll.jar:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [rt.jar:1.7.0_45] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [rt.jar:1.7.0_45] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [rt.jar:1.7.0_45] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] > at > org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) > [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at > org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at > org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:73) > [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final] > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at > org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95) > [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at > org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at > org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at > org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) > [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] > at > org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:333) > [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] > at > org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56) > [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] > at org.jboss.invocation.InterceptorContext.proceed(Intercep > > > Can someone explain me how to resolve? > > Cheers, > Yair > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [ENGINE][SLA] from time to time I'm getting the folowwing exception when running on master
2015-01-14 03:30:27,407 INFO [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (MSC service thread 1-6) [] Initializing Scheduling manager 2015-01-14 03:30:27,438 ERROR [org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean] (MSC service thread 1-6) [] Failed to initialize backend: org.apache.commons.lang.NotImplementedException: policyUnit: Migration at org.ovirt.engine.core.bll.scheduling.PolicyUnitImpl.getPolicyUnitImpl(PolicyUnitImpl.java:116) [bll.jar:] at org.ovirt.engine.core.bll.scheduling.SchedulingManager.loadPolicyUnits(SchedulingManager.java:178) [bll.jar:] at org.ovirt.engine.core.bll.scheduling.SchedulingManager.init(SchedulingManager.java:101) [bll.jar:] at org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean.create(InitBackendServicesOnStartupBean.java:104) [bll.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:73) [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:333) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(Intercep Can someone explain me how to resolve? Cheers, Yair ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [Feature review] Select network to be used for glusterfs
On Tue, Jan 13, 2015 at 02:51:34PM +0200, Lior Vernia wrote: > > > On 13/01/15 10:21, Sahina Bose wrote: > > > > On 01/12/2015 08:52 PM, Dan Kenigsberg wrote: > >> On Mon, Jan 12, 2015 at 02:59:50PM +0200, Lior Vernia wrote: > >>> > >>> On 12/01/15 14:44, Oved Ourfali wrote: > Hi Sahina, > > Some comments: > > 1. As far as I understand, you might not have an IP available > immediately after setupNetworks runs (getCapabilities should run, > but it isn't run automatically, afair). > 2. Perhaps you should pass not the IP but the name of the network? > IPs might change. > >>> Actually, IP address can indeed change - which would be very bad for > >>> gluster functioning! I think moving networks or changing their IP > >>> addresses via Setup Networks should be blocked if they're used by > >>> gluster bricks. > >> In the suggested feature, there is no real storage "role". The "storage > >> role" title means only "default value for glusterfs IP". > >> > >> For example, once a brick was created, nothing protects the admin from > >> accidently removing the storage network, or changing its IP address. > >> > >> Another "proof" that this is not a real "role", is that it affects only > >> GUI: I am guessing that REST API would not make use of it at all. (maybe > >> I'm wrong; for sure, REST must be defined in the feature page) > > > > REST API that lists the available networks (with IP addresses) would be > > used to select the network and pass to the create gluster volume API My question regarded the argument of the add brick API (in Engine level). Is it an IPv4 address (like it seems) or could it be a network name? > > > > I'll update the feature page with the REST API changes as well. > > > > If REST allows to choose the network used for gluster traffic, then I > think so should the GUI - I would not drop the list box from the design > in that case. > > >> > >> Maybe that's the behavior we want. But alternatively, Engine can enforce > >> a stronger linkage between the brick to the network that it uses. When > >> adding a brick, the dialog would list available networks instead of the > >> specific IP. As long as the brick is being used, the admin would be > >> blocked/warned against deleting the network. > > > > Is there a way to block against changing IP address used by a network? > > > > Yes, this should be implemented at least in the canDoAction() method of > SetupNetworksCommand (most of it is done in the SetupNetworksHelper > class). And perhaps this should be blocked in the GUI as well. > > Note that by the time 3.6 is released, the REST (and probably GUI) are > supposed to work with a different backend command that is currently > being implemented - so maybe you'll need to modify that instead, or on > top of the changes in SetupNetworksHelper. > > >> > >> I'm missing a discussion regarding the upgrade path. If we would opt to > >> requiring a single storage role network in a cluster, in an upgraded > >> cluster the management network should take this role. > > > > There would not be any change to existing volumes on upgrade, as bricks > > have already been added. Users can use the Edit brick option to update > > the network to be used, if required as mentioned in "Change network used > > by brick " > > > > I suspect Dan referred to the upgrade path of the engine itself - if you > add a new "Gluster Network" boolean column to the DB, it will initially > be null for all current networks. You'd likely need to write an upgrade > script to assign the role by default to the existing management networks > in each cluster. yep. > > > > >> > 3. Adding to "2", perhaps using DNS names is a more valid approach? > 4. You're using the terminology "role", but it might be confusing, > as we have "roles" with regards to permissions. Consider changing > "storage usage" and not "storage role" in the feature page. > >>> Well, we've already been using this terminology for a while now > >>> concerning display/migration roles for networks... That's probably the > >>> terminology to use. If I am not mistaken, it could make sense to have a setup with one brick using network A and another - using network B. Does your design support this? I think that this would be particularly important on upgraded clusters, where the management network is already used, but newly created bricks should start using another network. Would you add a feature page section regarding modification to the Vdsm/Engine API? One last comment - may I ask that new APIs accept both ipv4 and ipv6 addresses? There is an ongoing effort to support ipv6 on Vdsm. Dan. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] oVirt Node weekly meeting
BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:STANDARD DTSTART:16010101T03 TZOFFSETTO:+0100 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU TZNAME:CET END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETTO:+0200 TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU TZNAME:CEST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:880f897a-b75e-47b7-abf6-24d1e4894600 SUMMARY:oVirt Node weekly meeting LOCATION:irc://irc.oftc.net#ovirt ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE:mailto:devel@ ovirt.org ORGANIZER;CN=Fabian Deutsch:mailto:fdeut...@redhat.com DTSTART;TZID="Europe/Berlin":20150115T16 DTEND;TZID="Europe/Berlin":20150115T163000 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE RECURRENCE-ID;TZID="Europe/Berlin":20150113T15 LAST-MODIFIED:20150113T151011Z DTSTAMP:20150113T151011Z SEQUENCE:7 DESCRIPTION:A single instance of the following meeting has been modified:\n\ nSubject: oVirt Node weekly meeting \nOrganiser: "Fabian Deutsch" \n\nLocation: irc://irc.oftc.net#ovirt \nTime: Thursday\, 15 Jan uary\, 2015\, 4:00:00 PM - 4:30:00 PM GMT +01:00 Amsterdam\, Berlin\, Bern\, Rome\, Stockholm\, Vienna [MODIFIED]\n \nInvitees: devel@ovirt.org \n\n\n*~ *~*~*~*~*~*~*~*~*\n\nHey\, \n\nthis is a one time change.\n\n- fabian BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [Feature review] Select network to be used for glusterfs
On 13/01/15 10:21, Sahina Bose wrote: > > On 01/12/2015 08:52 PM, Dan Kenigsberg wrote: >> On Mon, Jan 12, 2015 at 02:59:50PM +0200, Lior Vernia wrote: >>> >>> On 12/01/15 14:44, Oved Ourfali wrote: Hi Sahina, Some comments: 1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. >>> Actually, IP address can indeed change - which would be very bad for >>> gluster functioning! I think moving networks or changing their IP >>> addresses via Setup Networks should be blocked if they're used by >>> gluster bricks. >> In the suggested feature, there is no real storage "role". The "storage >> role" title means only "default value for glusterfs IP". >> >> For example, once a brick was created, nothing protects the admin from >> accidently removing the storage network, or changing its IP address. >> >> Another "proof" that this is not a real "role", is that it affects only >> GUI: I am guessing that REST API would not make use of it at all. (maybe >> I'm wrong; for sure, REST must be defined in the feature page) > > REST API that lists the available networks (with IP addresses) would be > used to select the network and pass to the create gluster volume API > > I'll update the feature page with the REST API changes as well. > If REST allows to choose the network used for gluster traffic, then I think so should the GUI - I would not drop the list box from the design in that case. >> >> Maybe that's the behavior we want. But alternatively, Engine can enforce >> a stronger linkage between the brick to the network that it uses. When >> adding a brick, the dialog would list available networks instead of the >> specific IP. As long as the brick is being used, the admin would be >> blocked/warned against deleting the network. > > Is there a way to block against changing IP address used by a network? > Yes, this should be implemented at least in the canDoAction() method of SetupNetworksCommand (most of it is done in the SetupNetworksHelper class). And perhaps this should be blocked in the GUI as well. Note that by the time 3.6 is released, the REST (and probably GUI) are supposed to work with a different backend command that is currently being implemented - so maybe you'll need to modify that instead, or on top of the changes in SetupNetworksHelper. >> >> I'm missing a discussion regarding the upgrade path. If we would opt to >> requiring a single storage role network in a cluster, in an upgraded >> cluster the management network should take this role. > > There would not be any change to existing volumes on upgrade, as bricks > have already been added. Users can use the Edit brick option to update > the network to be used, if required as mentioned in "Change network used > by brick " > I suspect Dan referred to the upgrade path of the engine itself - if you add a new "Gluster Network" boolean column to the DB, it will initially be null for all current networks. You'd likely need to write an upgrade script to assign the role by default to the existing management networks in each cluster. > >> 3. Adding to "2", perhaps using DNS names is a more valid approach? 4. You're using the terminology "role", but it might be confusing, as we have "roles" with regards to permissions. Consider changing "storage usage" and not "storage role" in the feature page. >>> Well, we've already been using this terminology for a while now >>> concerning display/migration roles for networks... That's probably the >>> terminology to use. >>> Thanks, Oved - Original Message - > From: "Sahina Bose" > To: devel@ovirt.org, "users" > Sent: Monday, January 12, 2015 2:00:16 PM > Subject: [ovirt-users] [Feature review] Select network to be used > forglusterfs > > Hi all, > > Please review the feature page for this proposed solution and provide > your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster > > thanks > sahina >> ___ >> Users mailing list >> us...@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [Feature review] Select network to be used for glusterfs
On 13/01/15 10:18, Sahina Bose wrote: > > On 01/12/2015 06:21 PM, Lior Vernia wrote: >> Hi Sahina! :) >> >> Cool feature, and I think long-awaited by many users. I have a few >> comments: >> >> 1. In the "Add Bricks" dialog, it seems like the "IP Address" field is a >> list box - I presume the items contained there are all IP addresses >> configured on the host's interfaces. >> >> 1. a. May I suggest that this contain network names instead of IP >> addresses? Would be easier for users to think about things (they surely >> remember the meaning of network names, not necessarily of IP addresses). > > >> >> 1. b. If I correctly understood the mock-up, then configuring a "Storage >> Network" role only affects the default entry chosen in the list box. Is >> it really worth the trouble of implementing this added role? It's quite >> different than display/migration roles, which are used to determine what >> IP address to use at a later time (i.e. not when configuring the host), >> when a VM is run/migrated in the cluster. > > > If not for "Storage network" role, how would we default which network to > use. In fact, we are planning to remove the drop down to choose network > from the Add Brick UI, to avoid confusion and just use the network with > this role, if available - otherwise use the host address. (host_address > in vds_static) > If the list box goes, then yeah, somehow you'll have to mark the network used for gluster traffic, so a role would be good. However, if you keep the list box, any order would be fine (maybe alphabetic with the management network as default?). > Will update page accordingly > > >> >> 1. c. A word of warning: sometimes a host interface's IP address is >> missing in the engine - this usually happens when they're configured for >> the first time with DHCP, and the setup networks command returns before >> an IP address is allocated (this can later be resolved by refreshing >> host capabilities, there's a button for that). So when displaying items >> in the list box, you should really check that an IP address exists for >> each network. >> >> 2. "Storage Network": if you intend to keep this role in the feature (I >> don't think it adds a lot of functionality, see article 1b), it might be >> better to call it "Gluster Network" - otherwise people using virt mode >> might think this network is gonna be used to communicate with other >> types of storage domains. > > > Could this network be reused for other storage needs also. If not, we > can rename it "gluster network" > I don't think there are any current plans to incorporate a "storage network" in 3.6, CCing Allon though. >> >> Yours, Lior. >> >> On 12/01/15 14:00, Sahina Bose wrote: >>> Hi all, >>> >>> Please review the feature page for this proposed solution and provide >>> your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster >>> >>> thanks >>> sahina >>> >>> >>> ___ >>> Users mailing list >>> us...@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
Do you really want to call this entity "schedule"? I find this somehow confusing as there is already a "scheduling" component in ovirt, which does different stuff. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [Feature review] Select network to be used for glusterfs
On 01/12/2015 08:52 PM, Dan Kenigsberg wrote: On Mon, Jan 12, 2015 at 02:59:50PM +0200, Lior Vernia wrote: On 12/01/15 14:44, Oved Ourfali wrote: Hi Sahina, Some comments: 1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. Actually, IP address can indeed change - which would be very bad for gluster functioning! I think moving networks or changing their IP addresses via Setup Networks should be blocked if they're used by gluster bricks. In the suggested feature, there is no real storage "role". The "storage role" title means only "default value for glusterfs IP". For example, once a brick was created, nothing protects the admin from accidently removing the storage network, or changing its IP address. Another "proof" that this is not a real "role", is that it affects only GUI: I am guessing that REST API would not make use of it at all. (maybe I'm wrong; for sure, REST must be defined in the feature page) REST API that lists the available networks (with IP addresses) would be used to select the network and pass to the create gluster volume API I'll update the feature page with the REST API changes as well. Maybe that's the behavior we want. But alternatively, Engine can enforce a stronger linkage between the brick to the network that it uses. When adding a brick, the dialog would list available networks instead of the specific IP. As long as the brick is being used, the admin would be blocked/warned against deleting the network. Is there a way to block against changing IP address used by a network? I'm missing a discussion regarding the upgrade path. If we would opt to requiring a single storage role network in a cluster, in an upgraded cluster the management network should take this role. There would not be any change to existing volumes on upgrade, as bricks have already been added. Users can use the Edit brick option to update the network to be used, if required as mentioned in "Change network used by brick " 3. Adding to "2", perhaps using DNS names is a more valid approach? 4. You're using the terminology "role", but it might be confusing, as we have "roles" with regards to permissions. Consider changing "storage usage" and not "storage role" in the feature page. Well, we've already been using this terminology for a while now concerning display/migration roles for networks... That's probably the terminology to use. Thanks, Oved - Original Message - From: "Sahina Bose" To: devel@ovirt.org, "users" Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs Hi all, Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster thanks sahina ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [Feature review] Select network to be used for glusterfs
On 01/12/2015 06:21 PM, Lior Vernia wrote: Hi Sahina! :) Cool feature, and I think long-awaited by many users. I have a few comments: 1. In the "Add Bricks" dialog, it seems like the "IP Address" field is a list box - I presume the items contained there are all IP addresses configured on the host's interfaces. 1. a. May I suggest that this contain network names instead of IP addresses? Would be easier for users to think about things (they surely remember the meaning of network names, not necessarily of IP addresses). 1. b. If I correctly understood the mock-up, then configuring a "Storage Network" role only affects the default entry chosen in the list box. Is it really worth the trouble of implementing this added role? It's quite different than display/migration roles, which are used to determine what IP address to use at a later time (i.e. not when configuring the host), when a VM is run/migrated in the cluster. If not for "Storage network" role, how would we default which network to use. In fact, we are planning to remove the drop down to choose network from the Add Brick UI, to avoid confusion and just use the network with this role, if available - otherwise use the host address. (host_address in vds_static) Will update page accordingly 1. c. A word of warning: sometimes a host interface's IP address is missing in the engine - this usually happens when they're configured for the first time with DHCP, and the setup networks command returns before an IP address is allocated (this can later be resolved by refreshing host capabilities, there's a button for that). So when displaying items in the list box, you should really check that an IP address exists for each network. 2. "Storage Network": if you intend to keep this role in the feature (I don't think it adds a lot of functionality, see article 1b), it might be better to call it "Gluster Network" - otherwise people using virt mode might think this network is gonna be used to communicate with other types of storage domains. Could this network be reused for other storage needs also. If not, we can rename it "gluster network" Yours, Lior. On 12/01/15 14:00, Sahina Bose wrote: Hi all, Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster thanks sahina ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [Feature review] Select network to be used for glusterfs
On 01/12/2015 06:14 PM, Oved Ourfali wrote: Hi Sahina, Some comments: 1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. 3. Adding to "2", perhaps using DNS names is a more valid approach? To the gluster volume add brick command, the brick information needs to be passed in the form : So even if we do show the network names in the UI, we will need the underlying IP address to form this command. Regarding DNS names, currently is there a way to query for the DNS aliases for a host? I would need to use hostname in the command above, and assume that the user has setup his DNS outside of oVirt to correctly resolve to internal/external network, correct? 4. You're using the terminology "role", but it might be confusing, as we have "roles" with regards to permissions. Consider changing "storage usage" and not "storage role" in the feature page. Thanks, Oved - Original Message - From: "Sahina Bose" To: devel@ovirt.org, "users" Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs Hi all, Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster thanks sahina ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
