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