<div dir="ltr">Thanks for the pointer Saravanan!<br>@Dan, would you mind if I continue the patch work at <a target="_blank" rel="noreferrer" href="https://review.openstack.org/#/c/383516/">https://review.openstack.org/#<wbr>/c/383516/</a>?<br><br>Cheers!<br>zenghui<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 2, 2017 at 1:33 PM, Saravanan KR <span dir="ltr"><<a href="mailto:skramaja@redhat.com" target="_blank">skramaja@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Aug 2, 2017 at 5:21 AM, Zenghui Shi <<a href="mailto:zshi@redhat.com">zshi@redhat.com</a>> wrote:<br>
><br>
> On Wed, 2 Aug 2017 at 02:34 Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On 07/25/2017 09:53 PM, Zenghui Shi wrote:<br>
>> > Hi,<br>
>> ><br>
>> > Could anyone shed some light on how to get the physical interface name<br>
>> > (e.g eth0) from network name (e.g PublicNetwork, ExternalNetwork) in<br>
>> > tripleo-heat-template service profile ?<br>
>> ><br>
>> > for example:<br>
>> ><br>
>> > I want to add a service profile under puppet/services/time/ptp.pp where<br>
>> > it uses 'PtpInterface' as a parameter to get physical interface name<br>
>> > (please refer to below piece of code), but I'd like to expose a more<br>
>> > user friendly parameter like NetworkName(e.g. provision network,<br>
>> > external network etc) instead of 'PtpInterface' and retrieve the actual<br>
>> > physical interface name from the NetworkName where the physical<br>
>> > interface is connected to, is there any possible way to do this ?<br>
>><br>
>> I don't think there is. In many cases the templates don't even know the<br>
>> name of the physical device on which the network will be running. A<br>
>> simple example would be when a user uses the nicX abstraction to specify<br>
>> interfaces in their net-iso templates. That doesn't get mapped to an<br>
>> actual interface name until os-net-config runs, and the results of that<br>
>> run are not available to the templates.<br>
><br>
><br>
> Thanks Ben!<br>
><br>
> I'm also thinking if it makes sense to have a way in template or target<br>
> nodes to re-use the results of os-net-config for services which are bonded<br>
> to certain interfaces, or re-implement the os-net-config logic in template<br>
> to get the physical interface name. The latter one will be a repetitive work<br>
> of os-net-config.<br>
<br>
</div></div>This patch [1] has been started by Dan Sneddon to provide the nic<br>
number to name mapping by providing an extra option "--interfaces" to<br>
os-net-config command. May this could be reused to get the mapping.<br>
<br>
Regards,<br>
Saravanan KR<br>
<br>
[1] <a href="https://review.openstack.org/#/c/383516/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/383516/</a><br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Cheers!<br>
> Zenghui<br>
>><br>
>><br>
>> ><br>
>> > ####<br>
>> > parameters:<br>
>> > [...]<br>
>> > PtpInterface: # ---> change this parameter to PtpNetwork<br>
>> > default: eth0<br>
>> > description: PTP interfaces name.<br>
>> > type: string<br>
>> ><br>
>> > resources:<br>
>> > RoleParametersValue<br>
>> > type: OS::Heat::Value<br>
>> > properties:<br>
>> > type: json<br>
>> > value: # ---> add logic to get real interface name<br>
>> > from PtpNetwork<br>
>> > map_replace:<br>
>> > - map_replace:<br>
>> > - tripleo::profile::base::time::<wbr>ptp::ptp4l_interface:<br>
>> > PtpInterface<br>
>> > - values: {get_param: [RoleParameters]}<br>
>> > - values:<br>
>> > PtpInterface: {get_param: PtpInterface}<br>
>> ><br>
>> > outputs:<br>
>> > role_data:<br>
>> > description: Role ptp using commposable services.<br>
>> > value:<br>
>> > service_name: ptp<br>
>> > config_settings:<br>
>> > map_merge:<br>
>> > - get_attr: [RoleParametersValue, value]<br>
>> > [...]<br>
>> > ####<br>
>> ><br>
>> > Thanks!<br>
>> > zenghui<br>
>> ><br>
>> ><br>
>> ><br>
>> > ______________________________<wbr>______________________________<wbr>______________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>> ><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>