----- Original Message ----- > From: "Martin Mucha" <[email protected]> > To: "Yevgeny Zaspitsky" <[email protected]> > Cc: [email protected], [email protected] > 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" <[email protected]> > To: "Martin Mucha" <[email protected]> > Cc: [email protected], [email protected] > Sent: Sunday, April 27, 2014 2:22:04 PM > Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC > > Now for [email protected] indeed. > > ----- Original Message ----- > From: "Yevgeny Zaspitsky" <[email protected]> > To: "Martin Mucha" <[email protected]> > Cc: [email protected], [email protected] > 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" <[email protected]> > To: [email protected], [email protected] > 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
