----- Original Message ----- > From: "Martin Mucha" <[email protected]> > To: "Moti Asayag" <[email protected]> > Cc: "Yevgeny Zaspitsky" <[email protected]>, [email protected], > [email protected] > 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" <[email protected]> > To: "Martin Mucha" <[email protected]> > Cc: "Yevgeny Zaspitsky" <[email protected]>, [email protected], > [email protected] > Sent: Monday, April 28, 2014 8:21:50 AM > Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC > > > > ----- 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
