[ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC

Mon Apr 28 02:59:06 EDT 2014

Hi,

thanks for your input, I'll try to satisfy your request to be able to set range 'width' either by 'end boundary' or 'mac count' in gui design.

Prior to that there are more fundamental decisions to be made -- like whether the pool definition is mandatory or optional, and how this influence the app for upgrading users. I'm pushing the idea of optional definition with one global pool as a fallback. And like I said in previous emails, from this point of view is gui design marginal, since we do not know what exact things should be displayed there(gui will be little bit different for optional pool definition). This is to be decided this week, after that we can discuss final design of gui.

m.

----- Original Message -----
From: "Genadi Chereshnya" <gcheresh at redhat.com>
To: "Moti Asayag" <masayag at redhat.com>
Cc: devel at ovirt.org, users at ovirt.org, "Martin Mucha" <mmucha at redhat.com>, "Martin Pavlik" <mpavlik at redhat.com>
Sent: Monday, April 28, 2014 8:47:11 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC

Hi, 
We would like to propose a little bit better solution from user experience side.

We should have 3 fields for each range:
1) Start range
2) End range
3) Number of MACs
When you have to fill in "End range" or "Number of MACs" (when start range is mandatory).
And the 3rd field will be filled in automatically according to others.
For example:
1) If "Start range" is 00:00:00:00:00:01 and "Number of MACs" is 5 then "End range" should be filled in with 00:00:00:00:00:05.
2) If "Start range" is 00:00:00:00:00:01 and "End range" is 00:00:00:00:00:05, then "Number of MACs" should be filled in with 5. 

For update: "End range" and "Number of MACs" should be updated automatically as well, so if you update "End range" the "Number of MACs" should be updated and vice versa.

For adding several MAC pool ranges for DC we can use the "+" or "-" sign as we do for adding VNIC profile or Labels field.

Regards,
   Genadi

----- Original Message -----
From: "Moti Asayag" <masayag at redhat.com>
To: "Martin Mucha" <mmucha at redhat.com>
Cc: devel at ovirt.org, users at ovirt.org
Sent: Monday, April 28, 2014 9:21:50 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC

----- Original Message -----
> From: "Martin Mucha" <mmucha at redhat.com>
> To: "Yevgeny Zaspitsky" <yzaspits at redhat.com>
> Cc: users at ovirt.org, devel at ovirt.org
> Sent: Monday, April 28, 2014 9:14:38 AM
> Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
> 
> Hi,
> you're right, I do know about these problems. THIS IS DEFINITELY NOT A FINAL
> CODE.
> 
> Why I did it this way: I come from agile environment.
> This supposed to be FIRST increment. Not last. I hate waterfall style of work
> -- almighty solution in one swing. I'd like to make sure, that main part,
> that core principle is valid and approved. Making gui look nice is marginal.
> So it is data structure for first increment. We can definitely think of
> thousands of improvements, BUT this RFC already include more than 10 patch
> sets and NO core reviews. How can I know, that others will approve this and
> I'm not completely wrong?
> 
> about UX: it's wrong, but just fine for first increment. It can be used
> somehow and that just sufficient. Note: even with table to enter each
> from-to range there can be validation problem needed to be handled. Gui can
> changed to better one, when we know, that this feature works. But meantime
> others can test this feature functionality via this ugly, but very fast to
> write, gui!
> 
> about DB: I'm aware of DB normalization, and about all implications my
> "design" has. Yes, storing it in one varchar column is DB (very heavily
> used) antipattern, just fine for first increment and very easy to fix.
> 

There is another motivation for using a normalized data, specifically for
mac addresses - using the MAC addresses type [1] will enforce validity of
the input and will allow functionality such as comparison (is required).

[1] http://www.postgresql.org/docs/8.4/static/datatype-net-types.html

> If it's up to me, I'd like to wait for approval of 'core' part of this change
> (lets call it spike), and finish remaining 'marginalities' after it. (just
> to make myself clear proper db design ISN'T marginal measuring it using
> absolute scale, but it IS very marginal related to situation where most of
> code wasn't approved/reviewed yet).
> 
> m.
> 
> ----- Original Message -----
> From: "Yevgeny Zaspitsky" <yzaspits at redhat.com>
> To: "Martin Mucha" <mmucha at redhat.com>
> Cc: devel at ovirt.org, users at ovirt.org
> Sent: Sunday, April 27, 2014 2:22:04 PM
> Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
> 
> Now for users at ovirt.org indeed.
> 
> ----- Original Message -----
> From: "Yevgeny Zaspitsky" <yzaspits at redhat.com>
> To: "Martin Mucha" <mmucha at redhat.com>
> Cc: users at ovrit.org, devel at ovirt.org
> Sent: Sunday, April 27, 2014 2:29:46 PM
> Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
> 
> Martin,
> 
> I'd like to propose a different approach on how the ranges to be defined and
> stored.
> 
> Discussing this feature with Moti raised the alternative UX design:
> Defining ranges could be added as a left-tab on create DC dialog and a
> sub-tab on an existing DC. It would be a table of start and end address
> fields and we can add a calculated # of MACs in the range and/or summary for
> the DC.
> Also that will make string parsing unneeded, prevent possible user mistakes
> in the string format and make possible validating every field of the range
> on the UI side easier.
> As you can see on the screenshot you've attached even a single range doesn't
> fit to the text box. In case of multiple ranges managing them in a single
> line textbox would be very uncomfortable.
> 
> A range is an object with at least 2 members (start and end). And we have few
> of these for each data center.
> Storing a collection of the objects in a single field in a relational DB
> seems a bit awkward to me.
> That has few disadvantages:
> 1. is not normalized
> 2. make data validation nearly impossible
> 3. make querying the data very difficult
> 4. is restraining our ability to extend the object (e.g. a user might like to
> give a description to a range)
> So IMHO a satellite table with the FK to storage_pool would be a more robust
> design.
> 
> Best regards,
> ____________________
> Yevgeny Zaspitsky
> Senior Software Engineer
> Red Hat Israel
> 
> 
> ----- Original Message -----
> From: "Martin Mucha" <mmucha at redhat.com>
> To: users at ovirt.org, devel at ovirt.org
> Sent: Thursday, April 10, 2014 9:59:44 AM
> Subject: [ovirt-devel] new feature
> 
> Hi,
> 
> I'd like to notify you about new feature, which allows to specify distinct
> MAC pools, currently one per data center.
> http://www.ovirt.org/Scoped_MacPoolManager
> 
> any comments/proposals for improvement are very welcomed.
> Martin.
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
_______________________________________________
Users mailing list
Users at ovirt.org
http://lists.ovirt.org/mailman/listinfo/users