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

[Moti Asayag]

----- 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
>