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

Mon Apr 28 02:43:17 EDT 2014


----- Original Message -----
> From: "Martin Mucha" <mmucha at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "Yevgeny Zaspitsky" <yzaspits at redhat.com>, users at ovirt.org, devel at ovirt.org
> Sent: Monday, April 28, 2014 9:38:11 AM
> Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
> 
> thanks for bringing up this datatypes, I was not aware of them.
> 
> Are we allowed/supposed to use vendor specific types if appropriate to?
> note: using this type will enforce a validity, right, but that does not mean
> that much (from other code perspective) since one's still obliged to do all
> checking on all other app layers avoiding calls from one layer to another
> with invalid data (calls to backend are expensive, call to db are even more
> expensive considering lot of users working simultaneously).
> 
> >and will allow functionality such as comparison (is required).
> maybe I do not understand this. Which mac ranges comparison is currently
> required and not possible? Either I do not get it or I'm not aware of that
> use case.
> 

If we plan at some point to support the search mechanism for mac address ranges
(the search box in the webadmin on top of the main tabs)

> m.
> 
> ----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Martin Mucha" <mmucha at redhat.com>
> Cc: "Yevgeny Zaspitsky" <yzaspits at redhat.com>, users at ovirt.org,
> devel at ovirt.org
> Sent: Monday, April 28, 2014 8:21:50 AM
> Subject: Re: [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
> > 
>