Networking deep dive feedback

Development
#1

Hi,

First, demo looked good!!!

Just catching up on the deep dive from yesterday, a few comments in random
order

  • when creating a new host, all attributes in the primary tab are auto
    populated with the hostgroup excluding the realm, maybe since its less used
    feature move it to bellow the puppet fields?
  • network tab has a header called interfaces, are we going to show any non
    interface data in there? we can drop the header maybe?
  • table view of interfaces does not show the ip initially, but when you
    edit it, its already visible?
  • do i really need to edit each time the primary interface? ideally i dont
    want to click on edit if i use the default?
  • host/show nics details, is there a hover or text defining the interface
    type? at least until people learn how to recognize the icon?
  • redirect problem ? :slight_smile:
  • something i didn't catch, did we move the build status to the primary
    interface or is it still an host attribute?
  • any idea how / if the API will change?

thanks!

Ohad

#2

Hello,

I agree with Ohad, the new network provisionning presented on deep drive
is really nice!

Another question after watching the deepdrive :

Is it possible to add static routes for NIC properties when you dont use
DHCP for a specific interface ?

Typical usage is second NIC for backup features and your backup software
is few hops far from your 2nd NIC. It would be useful to have this
parameter in YAML rather than defining a specific parameter for routes.

On the Realm topic, I prefer to see it on the host page. Fron
experience, I never saw multiple realms on multiple NICs on a single
server.

Claer

··· On Tue, Dec 02 2014 at 59:10, Ohad Levy wrote:

Hi,

First, demo looked good!!!

Just catching up on the deep dive from yesterday, a few comments in random
order

  • when creating a new host, all attributes in the primary tab are auto
    populated with the hostgroup excluding the realm, maybe since its less used
    feature move it to bellow the puppet fields?
  • network tab has a header called interfaces, are we going to show any non
    interface data in there? we can drop the header maybe?
  • table view of interfaces does not show the ip initially, but when you
    edit it, its already visible?
  • do i really need to edit each time the primary interface? ideally i dont
    want to click on edit if i use the default?
  • host/show nics details, is there a hover or text defining the interface
    type? at least until people learn how to recognize the icon?
  • redirect problem ? :slight_smile:
  • something i didn’t catch, did we move the build status to the primary
    interface or is it still an host attribute?
  • any idea how / if the API will change?

thanks!

Ohad

–
You received this message because you are subscribed to the Google Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#3

> Hi,
>
> First, demo looked good!!!

Thanks :slight_smile:

> Just catching up on the deep dive from yesterday, a few comments in random
> order
>
> * when creating a new host, all attributes in the primary tab are auto
> populated with the hostgroup excluding the realm, maybe since its less used
> feature move it to bellow the puppet fields?

I'd be fine with that change, we could even hide it when no realms are
configured, same as for some other fields.

> * network tab has a header called interfaces, are we going to show any non
> interface data in there? we can drop the header maybe?

Good point, Tomas?

> * table view of interfaces does not show the ip initially, but when you edit
> it, its already visible?

Probably just a JS issue, I'll check it.

> * do i really need to edit each time the primary interface? ideally i dont
> want to click on edit if i use the default?

No, you don't need to, if all the defaults are correct. I chose to
demo multi-nic provisioning just because thats the main usecase we're
trying to solve, but for a single-nic system with a hostgroup, you can
just carry on as normal and pretty much ignore the network tab
(excepting the annoying identifier matchup for libvirt/ovirt systems,
as described)

> * host/show nics details, is there a hover or text defining the interface
> type? at least until people learn how to recognize the icon?

There should be, if it doesn't show for you let us know

> * redirect problem ? :slight_smile:

Known issue, we're not currently sure what's causing it.

> * something i didn't catch, did we move the build status to the primary
> interface or is it still an host attribute?

Still a host attribute, we felt it didn't make sense for 50% of a host
to be in build state :slight_smile:

> * any idea how / if the API will change?

Untested yet, but should be similar to how we handle other collections
(eg puppet classes) via nested attributes. It's on my list for this
week.

··· On 2 December 2014 at 08:59, Ohad Levy wrote:

On 2 December 2014 at 10:48, Claer claer@claer.hammock.fr wrote:

Is it possible to add static routes for NIC properties when you dont use
DHCP for a specific interface ?

We’ve not added anything like that to the Nic model at this point -
there are some extra fields that I didn’t show for bonds/aliases, but
these won’t help your use case. I’m wary of making the Nic modal even
bigger than it already is, but if there’s demand for it, of course it
can be done :slight_smile:

Thanks for the feedback guys :slight_smile:

#4

Hello,

just few small comments inline

> > Hi,
> >
> > First, demo looked good!!!
>
> Thanks :slight_smile:
>
> > Just catching up on the deep dive from yesterday, a few comments in random
> > order
> >
> > * when creating a new host, all attributes in the primary tab are auto
> > populated with the hostgroup excluding the realm, maybe since its less
> > used
> > feature move it to bellow the puppet fields?
>
> I'd be fine with that change, we could even hide it when no realms are
> configured, same as for some other fields.
+1

> > * network tab has a header called interfaces, are we going to show any non
> > interface data in there? we can drop the header maybe?
>
> Good point, Tomas?
+1

> > * table view of interfaces does not show the ip initially, but when you
> > edit it, its already visible?
>
> Probably just a JS issue, I'll check it.
>
> > * do i really need to edit each time the primary interface? ideally i dont
> > want to click on edit if i use the default?
>
> No, you don't need to, if all the defaults are correct. I chose to
> demo multi-nic provisioning just because thats the main usecase we're
> trying to solve, but for a single-nic system with a hostgroup, you can
> just carry on as normal and pretty much ignore the network tab
> (excepting the annoying identifier matchup for libvirt/ovirt systems,
> as described)
>
> > * host/show nics details, is there a hover or text defining the interface
> > type? at least until people learn how to recognize the icon?
>
> There should be, if it doesn't show for you let us know
>
> > * redirect problem ? :slight_smile:
>
> Known issue, we're not currently sure what's causing it.
>
> > * something i didn't catch, did we move the build status to the primary
> > interface or is it still an host attribute?
>
> Still a host attribute, we felt it didn't make sense for 50% of a host
> to be in build state :slight_smile:

Yes, the primary interface just hold some of attributes but it's still up to
host to know whether it should build or not.

> > * any idea how / if the API will change?
>
> Untested yet, but should be similar to how we handle other collections
> (eg puppet classes) via nested attributes. It's on my list for this
> week.
>
> > Is it possible to add static routes for NIC properties when you dont use
> > DHCP for a specific interface ?
>
> We've not added anything like that to the Nic model at this point -
> there are some extra fields that I didn't show for bonds/aliases, but
> these won't help your use case. I'm wary of making the Nic modal even
> bigger than it already is, but if there's demand for it, of course it
> can be done :slight_smile:

Also we have "custom" storage in Nic model (attrs) which could be used for
storing such data. Maybe a plugin that extends the form by static routes
field and configuring it would be a way. But I agree to what Greg said, Nic
has already too many responsibilities, so if we want to support routes we
should model it as a separate object.

··· On Tuesday 02 of December 2014 23:24:13 Greg Sutcliffe wrote: > On 2 December 2014 at 08:59, Ohad Levy wrote: > On 2 December 2014 at 10:48, Claer wrote:

–
Marek

#5

[…]

··· On Tue, Dec 02 2014 at 24:23, Greg Sutcliffe wrote: > On 2 December 2014 at 10:48, Claer wrote: > > Is it possible to add static routes for NIC properties when you dont use > > DHCP for a specific interface ? > > We've not added anything like that to the Nic model at this point - > there are some extra fields that I didn't show for bonds/aliases, but > these won't help your use case. I'm wary of making the Nic modal even > bigger than it already is, but if there's demand for it, of course it > can be done :)

I’m checking again a nightly build. Maybe it is possible to move the
static routes to the network definition, where there is already gateway
definition.

If I’m lucky, I’ll be able to test PXE on vmware :slight_smile:

Thanks!

Claer

#6

>> > * when creating a new host, all attributes in the primary tab are auto
>> > populated with the hostgroup excluding the realm, maybe since its less
>> > used
>> > feature move it to bellow the puppet fields?
>>
>> I'd be fine with that change, we could even hide it when no realms are
>> configured, same as for some other fields.
> +1

Fixed in https://github.com/GregSutcliffe/foreman/commit/ce9029248179ee6dc1cf7764510c166b391e5068

>> > * network tab has a header called interfaces, are we going to show any non
>> > interface data in there? we can drop the header maybe?
>>
>> Good point, Tomas?
> +1

Fixed in https://github.com/GregSutcliffe/foreman/commit/289e7d10e5661d8480c3491cc31ce34df296eb2e

I cleaned up the Tab title as well, and moved the New Interface button
to the bottom-left to be consistent with the VM tab. Tomas, can you
check it's ok? :slight_smile:

>> > * table view of interfaces does not show the ip initially, but when you
>> > edit it, its already visible?
>>
>> Probably just a JS issue, I'll check it.

Still researching.

> > * redirect problem ? :slight_smile:
>
> Known issue, we're not currently sure what's causing it.

This isn't our PR, it turns out. Ori and I have both seen this happen
in develop recently. Removing it from the PR task list.

In addition, I've taken a guess at the correct VMware integration code
for the mac handling (in the absence of a working vmware resource, I
can't test it). Could someone check it works?

Greg

··· >> On 2 December 2014 at 08:59, Ohad Levy wrote: