2:22 p.m.
Now for users(a)ovirt.org indeed.
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: users(a)ovrit.org, devel(a)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(a)redhat.com>
To: users(a)ovirt.org, devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
8:14 a.m.
New subject: [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.
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(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org
Sent: Sunday, April 27, 2014 2:22:04 PM
Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
Now for users(a)ovirt.org indeed.
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: users(a)ovrit.org, devel(a)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(a)redhat.com>
To: users(a)ovirt.org, devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
8:21 a.m.
New subject: [ovirt-devel] Feature Page: Mac Pool per DC
----- Original Message -----
From: "Martin Mucha" <mmucha(a)redhat.com>
To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
Cc: users(a)ovirt.org, devel(a)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(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org
Sent: Sunday, April 27, 2014 2:22:04 PM
Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
Now for users(a)ovirt.org indeed.
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: users(a)ovrit.org, devel(a)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(a)redhat.com>
To: users(a)ovirt.org, devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
8:38 a.m.
New subject: [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.
m.
----- Original Message -----
From: "Moti Asayag" <masayag(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>, users(a)ovirt.org,
devel(a)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(a)redhat.com>
To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
Cc: users(a)ovirt.org, devel(a)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(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org
Sent: Sunday, April 27, 2014 2:22:04 PM
Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
Now for users(a)ovirt.org indeed.
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: users(a)ovrit.org, devel(a)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(a)redhat.com>
To: users(a)ovirt.org, devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
8:43 a.m.
New subject: [ovirt-devel] Feature Page: Mac Pool per DC
----- Original Message -----
From: "Martin Mucha" <mmucha(a)redhat.com>
To: "Moti Asayag" <masayag(a)redhat.com>
Cc: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>, users(a)ovirt.org,
devel(a)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(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>, users(a)ovirt.org,
devel(a)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(a)redhat.com>
> To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> Cc: users(a)ovirt.org, devel(a)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(a)redhat.com>
> To: "Martin Mucha" <mmucha(a)redhat.com>
> Cc: devel(a)ovirt.org, users(a)ovirt.org
> Sent: Sunday, April 27, 2014 2:22:04 PM
> Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
>
> Now for users(a)ovirt.org indeed.
>
> ----- Original Message -----
> From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> To: "Martin Mucha" <mmucha(a)redhat.com>
> Cc: users(a)ovrit.org, devel(a)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(a)redhat.com>
> To: users(a)ovirt.org, devel(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
8:47 a.m.
New subject: [ovirt-devel] Feature Page: Mac Pool per DC
Hi,
We would like to propose a little bit better solution from user experience side.
We should have 3 fields for each range:
1) Start range
2) End range
3) Number of MACs
When you have to fill in "End range" or "Number of MACs" (when start
range is mandatory).
And the 3rd field will be filled in automatically according to others.
For example:
1) If "Start range" is 00:00:00:00:00:01 and "Number of MACs" is 5
then "End range" should be filled in with 00:00:00:00:00:05.
2) If "Start range" is 00:00:00:00:00:01 and "End range" is
00:00:00:00:00:05, then "Number of MACs" should be filled in with 5.
For update: "End range" and "Number of MACs" should be updated
automatically as well, so if you update "End range" the "Number of
MACs" should be updated and vice versa.
For adding several MAC pool ranges for DC we can use the "+" or "-"
sign as we do for adding VNIC profile or Labels field.
Regards,
Genadi
----- Original Message -----
From: "Moti Asayag" <masayag(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org
Sent: Monday, April 28, 2014 9:21:50 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC
----- Original Message -----
From: "Martin Mucha" <mmucha(a)redhat.com>
To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
Cc: users(a)ovirt.org, devel(a)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(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org
Sent: Sunday, April 27, 2014 2:22:04 PM
Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
Now for users(a)ovirt.org indeed.
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: users(a)ovrit.org, devel(a)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(a)redhat.com>
To: users(a)ovirt.org, devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
8:55 a.m.
New subject: [ovirt-devel] Feature Page: Mac Pool per DC
You could also add some option to use only e.g.
locally administered mac ranges, which should
be used for most vms anyway:
http://serverfault.com/questions/40712/what-range-of-mac-addresses-can-i-...
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
8:59 a.m.
New subject: [ovirt-devel] Feature Page: Mac Pool per DC
Hi,
thanks for your input, I'll try to satisfy your request to be able to set range
'width' either by 'end boundary' or 'mac count' in gui design.
Prior to that there are more fundamental decisions to be made -- like whether the pool
definition is mandatory or optional, and how this influence the app for upgrading users.
I'm pushing the idea of optional definition with one global pool as a fallback. And
like I said in previous emails, from this point of view is gui design marginal, since we
do not know what exact things should be displayed there(gui will be little bit different
for optional pool definition). This is to be decided this week, after that we can discuss
final design of gui.
m.
----- Original Message -----
From: "Genadi Chereshnya" <gcheresh(a)redhat.com>
To: "Moti Asayag" <masayag(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org, "Martin Mucha" <mmucha(a)redhat.com>,
"Martin Pavlik" <mpavlik(a)redhat.com>
Sent: Monday, April 28, 2014 8:47:11 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC
Hi,
We would like to propose a little bit better solution from user experience side.
We should have 3 fields for each range:
1) Start range
2) End range
3) Number of MACs
When you have to fill in "End range" or "Number of MACs" (when start
range is mandatory).
And the 3rd field will be filled in automatically according to others.
For example:
1) If "Start range" is 00:00:00:00:00:01 and "Number of MACs" is 5
then "End range" should be filled in with 00:00:00:00:00:05.
2) If "Start range" is 00:00:00:00:00:01 and "End range" is
00:00:00:00:00:05, then "Number of MACs" should be filled in with 5.
For update: "End range" and "Number of MACs" should be updated
automatically as well, so if you update "End range" the "Number of
MACs" should be updated and vice versa.
For adding several MAC pool ranges for DC we can use the "+" or "-"
sign as we do for adding VNIC profile or Labels field.
Regards,
Genadi
----- Original Message -----
From: "Moti Asayag" <masayag(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org
Sent: Monday, April 28, 2014 9:21:50 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC
----- Original Message -----
From: "Martin Mucha" <mmucha(a)redhat.com>
To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
Cc: users(a)ovirt.org, devel(a)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(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org
Sent: Sunday, April 27, 2014 2:22:04 PM
Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
Now for users(a)ovirt.org indeed.
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: users(a)ovrit.org, devel(a)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(a)redhat.com>
To: users(a)ovirt.org, devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
10:12 a.m.
New subject: [ovirt-devel] Feature Page: Mac Pool per DC
1) In our opinion the pool definition should be optional.
We should preserve the existing behavior. It will be useful especially for the upgrade
scenarios.
2) As well for the "Number of MACs" we proposed earlier you should take into
account the multicast addresses (if they are in the range) and to reduce them from the
count of "Number of MACs"
Genadi
----- Original Message -----
From: "Martin Mucha" <mmucha(a)redhat.com>
To: "Genadi Chereshnya" <gcheresh(a)redhat.com>
Cc: "Moti Asayag" <masayag(a)redhat.com>, devel(a)ovirt.org, users(a)ovirt.org,
"Martin Pavlik" <mpavlik(a)redhat.com>
Sent: Monday, April 28, 2014 9:59:06 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC
Hi,
thanks for your input, I'll try to satisfy your request to be able to set range
'width' either by 'end boundary' or 'mac count' in gui design.
Prior to that there are more fundamental decisions to be made -- like whether the pool
definition is mandatory or optional, and how this influence the app for upgrading users.
I'm pushing the idea of optional definition with one global pool as a fallback. And
like I said in previous emails, from this point of view is gui design marginal, since we
do not know what exact things should be displayed there(gui will be little bit different
for optional pool definition). This is to be decided this week, after that we can discuss
final design of gui.
m.
----- Original Message -----
From: "Genadi Chereshnya" <gcheresh(a)redhat.com>
To: "Moti Asayag" <masayag(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org, "Martin Mucha" <mmucha(a)redhat.com>,
"Martin Pavlik" <mpavlik(a)redhat.com>
Sent: Monday, April 28, 2014 8:47:11 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC
Hi,
We would like to propose a little bit better solution from user experience side.
We should have 3 fields for each range:
1) Start range
2) End range
3) Number of MACs
When you have to fill in "End range" or "Number of MACs" (when start
range is mandatory).
And the 3rd field will be filled in automatically according to others.
For example:
1) If "Start range" is 00:00:00:00:00:01 and "Number of MACs" is 5
then "End range" should be filled in with 00:00:00:00:00:05.
2) If "Start range" is 00:00:00:00:00:01 and "End range" is
00:00:00:00:00:05, then "Number of MACs" should be filled in with 5.
For update: "End range" and "Number of MACs" should be updated
automatically as well, so if you update "End range" the "Number of
MACs" should be updated and vice versa.
For adding several MAC pool ranges for DC we can use the "+" or "-"
sign as we do for adding VNIC profile or Labels field.
Regards,
Genadi
----- Original Message -----
From: "Moti Asayag" <masayag(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org
Sent: Monday, April 28, 2014 9:21:50 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC
----- Original Message -----
From: "Martin Mucha" <mmucha(a)redhat.com>
To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
Cc: users(a)ovirt.org, devel(a)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(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org
Sent: Sunday, April 27, 2014 2:22:04 PM
Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
Now for users(a)ovirt.org indeed.
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: users(a)ovrit.org, devel(a)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(a)redhat.com>
To: users(a)ovirt.org, devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
11:20 a.m.
New subject: [ovirt-devel] Feature Page: Mac Pool per DC
ad 1) mine thinking was the same. If it's optional, then upgrade process is: 'you
do not have to do anything', which seemed best to me.
ad 2) yes, this has to be reflected in gui. Currently in business layer there are checks
which do not let you use multicast address (exception is thrown when there is such attempt
-- this is appropriate from mac pool perspective). When user specified mac ranges
containing multicast address, this mac address is present in pool (due to implementation
restriction), but it is flagged as used, so system never assigns it. And if user tried to
do it by hand, it will fail, like I said.
m.
----- Original Message -----
From: "Genadi Chereshnya" <gcheresh(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: "Moti Asayag" <masayag(a)redhat.com>, devel(a)ovirt.org, users(a)ovirt.org,
"Martin Pavlik" <mpavlik(a)redhat.com>
Sent: Monday, April 28, 2014 10:12:06 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC
1) In our opinion the pool definition should be optional.
We should preserve the existing behavior. It will be useful especially for the upgrade
scenarios.
2) As well for the "Number of MACs" we proposed earlier you should take into
account the multicast addresses (if they are in the range) and to reduce them from the
count of "Number of MACs"
Genadi
----- Original Message -----
From: "Martin Mucha" <mmucha(a)redhat.com>
To: "Genadi Chereshnya" <gcheresh(a)redhat.com>
Cc: "Moti Asayag" <masayag(a)redhat.com>, devel(a)ovirt.org, users(a)ovirt.org,
"Martin Pavlik" <mpavlik(a)redhat.com>
Sent: Monday, April 28, 2014 9:59:06 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC
Hi,
thanks for your input, I'll try to satisfy your request to be able to set range
'width' either by 'end boundary' or 'mac count' in gui design.
Prior to that there are more fundamental decisions to be made -- like whether the pool
definition is mandatory or optional, and how this influence the app for upgrading users.
I'm pushing the idea of optional definition with one global pool as a fallback. And
like I said in previous emails, from this point of view is gui design marginal, since we
do not know what exact things should be displayed there(gui will be little bit different
for optional pool definition). This is to be decided this week, after that we can discuss
final design of gui.
m.
----- Original Message -----
From: "Genadi Chereshnya" <gcheresh(a)redhat.com>
To: "Moti Asayag" <masayag(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org, "Martin Mucha" <mmucha(a)redhat.com>,
"Martin Pavlik" <mpavlik(a)redhat.com>
Sent: Monday, April 28, 2014 8:47:11 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC
Hi,
We would like to propose a little bit better solution from user experience side.
We should have 3 fields for each range:
1) Start range
2) End range
3) Number of MACs
When you have to fill in "End range" or "Number of MACs" (when start
range is mandatory).
And the 3rd field will be filled in automatically according to others.
For example:
1) If "Start range" is 00:00:00:00:00:01 and "Number of MACs" is 5
then "End range" should be filled in with 00:00:00:00:00:05.
2) If "Start range" is 00:00:00:00:00:01 and "End range" is
00:00:00:00:00:05, then "Number of MACs" should be filled in with 5.
For update: "End range" and "Number of MACs" should be updated
automatically as well, so if you update "End range" the "Number of
MACs" should be updated and vice versa.
For adding several MAC pool ranges for DC we can use the "+" or "-"
sign as we do for adding VNIC profile or Labels field.
Regards,
Genadi
----- Original Message -----
From: "Moti Asayag" <masayag(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org
Sent: Monday, April 28, 2014 9:21:50 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC
----- Original Message -----
From: "Martin Mucha" <mmucha(a)redhat.com>
To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
Cc: users(a)ovirt.org, devel(a)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(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, users(a)ovirt.org
Sent: Sunday, April 27, 2014 2:22:04 PM
Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
Now for users(a)ovirt.org indeed.
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: users(a)ovrit.org, devel(a)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(a)redhat.com>
To: users(a)ovirt.org, devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
3671
days inactive
3672
days old
9 comments
5 participants
participants (5)
-
Genadi Chereshnya -
Martin Mucha -
Moti Asayag -
Sven Kieske -
Yevgeny Zaspitsky