<div dir="ltr"><div>Hi Harald,</div><div>Responding on behalf of Anirudh's email:</div><div>Thanks for the response and we now do understand that we are getting IP from the expected DHCP server.</div><div><br></div><div>We tried the scenario and here are our findings, Our admin and internal endpoints are on subnet: 30.30.30.x </div><div>public : 10.0.1.x </div><div><br></div><div>(overcloud) [stack@undercloud ~]$ <b>OpenStack endpoint list | grep ironic</b><br>| 04c163251e5546769446a4fa4fa20484 | regionOne | ironic | baremetal | True | admin | <a href="http://30.30.30.213:6385">http://30.30.30.213:6385</a> |<br>| 5c8557ae639a4898bdc6121f6e873724 | regionOne | ironic | baremetal | True | internal | <a href="http://30.30.30.213:6385">http://30.30.30.213:6385</a> |<br>| 62e07a3b2f3f4158bb27d8603a8f5138 | regionOne | ironic-inspector | baremetal-introspection | True | public | <a href="http://10.0.1.88:5050">http://10.0.1.88:5050</a> |<br>| af29bd64513546409f44cc5d56ea1082 | regionOne | ironic-inspector | baremetal-introspection | True | internal | <a href="http://30.30.30.213:5050">http://30.30.30.213:5050</a> |<br>| b76cdb5e77c54fc6b10cbfeada0e8bf5 | regionOne | ironic-inspector | baremetal-introspection | True | admin | <a href="http://30.30.30.213:5050">http://30.30.30.213:5050</a> |<br>| bd2954f41e49419f85669990eb59f51a | regionOne | ironic | baremetal | True | public | <a href="http://10.0.1.88:6385">http://10.0.1.88:6385</a> |<br>(overcloud) [stack@undercloud ~]$<br></div><div><br></div><div><br></div><div>we are following the flat default n/w approach for ironic provisioning, for which we are creating a flat network on baremetal physnet. we are still getting IP from neutron range (172.23.3.220 - 172.23.3.240) - 172.23.3.240. </div><div><br></div><div>Further, we found that once IP (172.23.3.240) is allocated to baremetal node, it looks for 30.30.30.220( IP of one of the three controllers) for pxe booting. </div><div>Checking the same controllers logs we found that </div><div><br></div><div><b>`/var/lib/ironic/tftpboot/pxelinux.cfg/` directory exists,</b> but then there is <b>no file matching the mac </b>address of the baremetal node. <br></div><div><br></div><div>Also checking the <b>extra_dhcp_opts</b> we found this:</div><div>(overcloud) [stack@undercloud ~]$ <b>openstack port show d7e573bf-1028-437a-8118-a2074c7573b2 | grep "extra_dhcp_opts"</b><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>| extra_dhcp_opts | ip_version='4', opt_name='tag:ipxe,67', opt_value='<a href="http://30.30.30.220:8088/boot.ipxe">http://30.30.30.220:8088/boot.ipxe</a>' </div></blockquote><div><br></div><div> <img src="cid:ii_kzfo4l8j0" alt="image.png" width="472" height="311"><br></div><div><b>Few points as observations:</b></div><div><ol><li>Although the baremetal network (172.23.3.x) is routable to the admin network (30.30.30.x), but it gets timeout at this window.</li><li>in TCPDump we are only getting read requests.</li><li>`openstack baremetal node list</li><ol><li>(overcloud) [stack@undercloud ~]$ openstack baremetal node list<br>+--------------------------------------+------+---------------+-------------+--------------------+-------------+<br>| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |<br>+--------------------------------------+------+---------------+-------------+--------------------+-------------+<br>| 7066fbe1-9c29-4702-9cd4-2b55daf19630 | bm1 | None | power on | clean wait | False |<br>+--------------------------------------+------+---------------+-------------+--------------------+-------------+<br></li></ol><li> `openstack baremetal node show <node-uuid>`</li><ol><li><br>(overcloud) [stack@undercloud ~]$ openstack baremetal node show bm1<br>+------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+<br>| Field | Value |<br>+------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+<br>| allocation_uuid | None |<br>| automated_clean | None |<br>| bios_interface | no-bios |<br>| boot_interface | ipxe |<br>| chassis_uuid | None |<br>| clean_step | {} |<br>| conductor | overcloud-controller-0.localdomain |<br>| conductor_group | |<br>| console_enabled | False |<br>| console_interface | ipmitool-socat |<br>| created_at | 2022-02-09T14:21:24+00:00 |<br>| deploy_interface | iscsi |<br>| deploy_step | {} |<br>| description | None |<br>| driver | ipmi |<br>| driver_info | {'ipmi_address': '10.0.1.183', 'ipmi_username': 'hsc', 'ipmi_password': '******', 'ipmi_terminal_port': 623, 'deploy_kernel': '9e1365b6-261a-42a2-abfe-40158945de57', 'deploy_ramdisk': 'fe608dd2-ce86-4faf-b4b8-cc5cb143eb56'} |<br>| driver_internal_info | {'agent_erase_devices_iterations': 1, 'agent_erase_devices_zeroize': True, 'agent_continue_if_ata_erase_failed': False, 'agent_enable_ata_secure_erase': True, 'disk_erasure_concurrency': 1, 'last_power_state_change': '2022-02-09T14:23:39.525629'} |<br>| extra | {} |<br>| fault | None |<br>| inspect_interface | inspector |<br>| inspection_finished_at | None |<br>| inspection_started_at | None |<br>| instance_info | {} |<br>| instance_uuid | None |<br>| last_error | None |<br>| maintenance | False |<br>| maintenance_reason | None |<br>| management_interface | ipmitool |<br>| name | bm1 |<br>| network_interface | flat |<br>| owner | None |<br>| power_interface | ipmitool |<br>| power_state | power on |<br>| properties | {'cpus': 20, 'cpu_arch': 'x86_64', 'capabilities': 'boot_option:local,boot_mode:uefi', 'memory_mb': 63700, 'local_gb': 470, 'vendor': 'hewlett-packard'} |<br>| protected | False |<br>| protected_reason | None |<br>| provision_state | clean wait |<br>| provision_updated_at | 2022-02-09T14:24:05+00:00 |<br>| raid_config | {} |<br>| raid_interface | no-raid |<br>| rescue_interface | agent |<br>| reservation | None |<br>| resource_class | bm1 |<br>| storage_interface | noop |<br>| target_power_state | None |<br>| target_provision_state | available |<br>| target_raid_config | {} |<br>| traits | [] |<br>| updated_at | 2022-02-09T14:24:05+00:00 |<br>| uuid | 7066fbe1-9c29-4702-9cd4-2b55daf19630 |<br>| vendor_interface | ipmitool |<br>+------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+<br>(overcloud) [stack@undercloud ~]$<br></li></ol></ol></div><div><br></div><div><br></div><div><b>Queries:</b></div><div><ul><li>What are the settings we can do for successfully pxe-boot of the baremetal node and provisioning our node successfully ?</li></ul></div><div><br></div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 8, 2022 at 6:27 PM Harald Jensas <<a href="mailto:hjensas@redhat.com">hjensas@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/7/22 13:47, Anirudh Gupta wrote:<br>
> Hi Julia,<br>
> <br>
> Thanks a lot for your responses and support.<br>
> To Update on the ongoing issue, I tried deploying the overcloud with <br>
> your valuable suggestions i.e by passing "*DhcpAgentNotification: true*" <br>
> in ironic-overcloud.yaml<br>
> The setup came up successfully, but with this configuration the IP <br>
> allocated on the system is one which is being configured while creating <br>
> the subnet in openstack.<br>
> <br>
> image.png<br>
> <br>
> The system is still getting the IP (172.23.3.212) from neutron. The <br>
> subnet range was configured as *172.23.3.210-172.23.3.240 *while <br>
> creating the provisioning subnet.<br>
<br>
<br>
The node is supposed to get an IP address from the neutron subnet on the <br>
provisioning network when:<br>
a) provisioning node<br>
b) cleaning node.<br>
<br>
When you do "baremetal node provide" cleaning is most likely <br>
automatically initiated. (Since cleaning is enabled by default for <br>
Ironic in overcloud AFIK.)<br>
<br>
The only time you will get an address from the IronicInspectorSubnets <br>
(ip_range: 172.23.3.100,172.23.3.150 in your case) is when you start <br>
ironic node introspection.<br>
<br>
> The system gets stuck here and no action is performed after this.<br>
><br>
<br>
It seems the system is getting an address from the expected DHCP server, <br>
but it does not boot. I would start looking into the pxe properties in <br>
the DHCP Reply.<br>
<br>
What is the status of the node in ironic at this stage?<br>
`openstack baremetal node list`<br>
`openstack baremetal node show <node-uuid>`<br>
<br>
Check the `extra_dhcp_opts` on the neutron port, it should set the <br>
nextserver and bootfile parameters. Does the bootfile exist in <br>
/var/lib/ironic/tftpboot? Inspect the <br>
`/var/lib/ironic/tftpboot/pxelinux.cfg/` directory, you should see a <br>
file matching the MAC address of your system. Does the content make sense?<br>
<br>
Can you capture DHCP and TFTP traffic on the provisioning network?<br>
<br>
> Is there any way to resolve this and make successful provisioning the <br>
> baremetal node in *TripleO Train Release* (Since RHOSP 16 was on Train, <br>
> so I thought to go with that version for better stability)<br>
> <a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index</a> <br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index</a>><br>
> <br>
> I have some queries:<br>
> <br>
> 1. Is passing "*DhcpAgentNotification: true" *enough or do we have to<br>
> make some other changes as well?<br>
<br>
I belive in train "DhcpAgentNotification" defaults to True.<br>
The change to default to false was added more recently, and it was not <br>
backported. <br>
(<a href="https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761</a>)<br>
<br>
NOTE, the environment for enabling ironi for the overcloud <br>
'environments/services/ironic-overcloud.yaml' overrides this to 'true' <br>
in later releases.<br>
<br>
> 2. Although there are some security concerns specified in the document,<br>
> but Currently I am focusing on the default flat bare metal approach<br>
> which has dedicated interface for bare metal Provisioning. There is<br>
> one composable method approach as well. Keeping aside the security<br>
> concerns, which approach is better and functional?<br>
> 1. <a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning</a><br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning</a>><br>
<br>
Both should work, using the composable network is more secure since <br>
baremetal nodes does not have access to the control plane network.<br>
<br>
> 3. Will moving to upper openstack release version make this deployment<br>
> possible?<br>
> 1. If Yes, which release should I go with as till wallaby the<br>
> ironic-overcloud.yml file has no option of including<br>
> "*DhcpAgentNotification: true*" by default<br>
> 1. <a href="https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml</a><br>
> <<a href="https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml</a>><br>
> <br>
> <br>
> Looking forward for your valuable feedback/response.<br>
> <br>
> Regards<br>
> Anirudh Gupta<br>
> <br>
> <br>
> On Fri, Feb 4, 2022 at 8:54 PM Anirudh Gupta <<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a> <br>
> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> Surely I'll revert the status once it gets deployed.<br>
> Bdw the suspicion is because of Train Release or it is something else?<br>
> <br>
> Regards<br>
> Anirudh Gupta<br>
> <br>
> On Fri, 4 Feb, 2022, 20:29 Julia Kreger,<br>
> <<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a> <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>>><br>
> wrote:<br>
> <br>
> <br>
> <br>
> On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta<br>
> <<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>>> wrote:<br>
> <br>
> Hi Julia<br>
> <br>
> Thanks for your response.<br>
> <br>
> Earlier I was passing both ironic.yaml and<br>
> ironic-overcloud.yaml located at path<br>
> /usr/share/openstack-tripleo-heat-templates/environments/services/<br>
> <br>
> My current understanding now says that since I am using OVN,<br>
> not OVS so I should pass only ironic-overcloud.yaml in my<br>
> deployment.<br>
> <br>
> I am currently on Train Release and my default<br>
> ironic-overcloud.yaml file has no such entry<br>
> DhcpAgentNotification: true<br>
> <br>
> <br>
> I suspect that should work. Let us know if it does.<br>
> <br>
> I would add this there and re deploy the setup.<br>
> <br>
> Would that be enough to make my deployment successful?<br>
> <br>
> Regards<br>
> Anirudh Gupta<br>
> <br>
> <br>
> On Fri, 4 Feb, 2022, 18:40 Julia Kreger,<br>
> <<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a><br>
> <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>>> wrote:<br>
> <br>
> It is not a matter of disabling OVN, but a matter of<br>
> enabling the dnsmasq service and notifications.<br>
> <br>
> <a href="https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml</a><br>
> <<a href="https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml</a>><br>
> may provide some insight.<br>
> <br>
> I suspect if you're using stable/wallaby based branches<br>
> and it is not working, there may need to be a patch<br>
> backported by the TripleO maintainers.<br>
> <br>
> On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta<br>
> <<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>>> wrote:<br>
> <br>
> Hi Julia,<br>
> <br>
> Thanks for your response.<br>
> For the overcloud deployment, I am executing the<br>
> following command:<br>
> <br>
> openstack overcloud deploy --templates \<br>
> -n /home/stack/templates/network_data.yaml \<br>
> -r /home/stack/templates/roles_data.yaml \<br>
> -e /home/stack/templates/node-info.yaml \<br>
> -e /home/stack/templates/environment.yaml \<br>
> -e<br>
> /home/stack/templates/environments/network-isolation.yaml<br>
> \<br>
> -e<br>
> /home/stack/templates/environments/network-environment.yaml<br>
> \<br>
> -e<br>
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml<br>
> \<br>
> -e<br>
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml<br>
> \<br>
> -e<br>
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml<br>
> \<br>
> -e<br>
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml<br>
> \<br>
> -e /home/stack/templates/ironic-config.yaml \<br>
> -e<br>
> /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml<br>
> \<br>
> -e<br>
> /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml<br>
> \<br>
> -e /home/stack/containers-prepare-parameter.yaml<br>
> <br>
> I can see some OVN related stuff in my roles_data<br>
> and environments/network-isolation.yaml<br>
> <br>
> [stack@undercloud ~]$ grep -inr "ovn"<br>
> roles_data.yaml:34: *OVNCMSOptions:<br>
> "enable-chassis-as-gw"*<br>
> roles_data.yaml:168: -<br>
> *OS::TripleO::Services::OVNDBs*<br>
> roles_data.yaml:169: -<br>
> *OS::TripleO::Services::OVNController*<br>
> roles_data.yaml:279: -<br>
> *OS::TripleO::Services::OVNController*<br>
> roles_data.yaml:280: -<br>
> *OS::TripleO::Services::OVNMetadataAgent*<br>
> environments/network-isolation.yaml:16:<br>
> *OS::TripleO::Network::Ports::OVNDBsVipPort:<br>
> ../network/ports/vip.yaml*<br>
> *<br>
> *<br>
> What is your recommendation and how to disable<br>
> OVN....should I remove it from roles_data.yaml and<br>
> then render so that it doesn't get generated<br>
> in environments/network-isolation.yaml<br>
> Please suggest some pointers.<br>
> <br>
> Regards<br>
> Anirudh Gupta<br>
> *<br>
> *<br>
> *<br>
> *<br>
> <br>
> <br>
> <br>
> <br>
> It seems OVN is getting installed in ironic<br>
> <br>
> <br>
> On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger<br>
> <<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a><br>
> <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>>> wrote:<br>
> <br>
> My guess: You're running OVN. You need<br>
> neutron-dhcp-agent running as well. OVN disables<br>
> it by default and OVN's integrated DHCP service<br>
> does not support options for network booting.<br>
> <br>
> -Julia<br>
> <br>
> On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta<br>
> <<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a><br>
> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>>> wrote:<br>
> <br>
> Hi Team<br>
> <br>
> I am trying to Provision Bare Metal Node<br>
> from my tripleo Overcloud.<br>
> For this, while deploying the overcloud, I<br>
> have followed the *"default flat" *network<br>
> approach specified in the below link<br>
> <a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning</a><br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning</a>><br>
> <br>
> Just to highlight the changes, I have<br>
> defined the<br>
> <br>
> *ironic-config.yaml*<br>
> <br>
> parameter_defaults:<br>
> ...<br>
> ...<br>
> IronicIPXEEnabled: true<br>
> IronicInspectorSubnets:<br>
> - ip_range: *172.23.3.100,172.23.3.150*<br>
> IronicInspectorInterface: 'br-baremetal'<br>
> <br>
> Also modified the file<br>
> *~/templates/network-environment.yaml*<br>
> <br>
> parameter_defaults:<br>
> NeutronBridgeMappings:<br>
> datacentre:br-ex,baremetal:br-baremetal<br>
> NeutronFlatNetworks: datacentre,baremetal<br>
> <br>
> With this I have Followed all the steps of<br>
> creating br-baremetal bridge on controller,<br>
> given in the link below:<br>
> <br>
> <a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy</a><br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy</a>><br>
> <br>
> - type: ovs_bridge<br>
> name: br-baremetal<br>
> use_dhcp: false<br>
> members:<br>
> - type: interface<br>
> name: nic3<br>
> <br>
> Post Deployment, I have also create a flat<br>
> network on "datacentre" physical network and<br>
> subnet having the range<br>
> *172.23.3.200,172.23.3.240 *(as suggested<br>
> subnet is same as of inspector and range is<br>
> different) and the router<br>
> <br>
> Also created a baremetal node and ran<br>
> *"openstack baremetal node manage bm1", *the<br>
> state of which was a success.<br>
> <br>
> Observation:<br>
> <br>
> On executing "openstack baremetal node<br>
> *provide* bm1", the machine gets power on<br>
> and ideally it should take an IP from ironic<br>
> inspector range and PXE Boot.<br>
> But nothing of this sort happens and we see<br>
> an IP from neutron range "*172.23.3.239*"<br>
> (attached the screenshot)<br>
> <br>
> image.png<br>
> <br>
> I have checked overcloud ironic inspector<br>
> podman logs alongwith the tcpdump.<br>
> In tcpdump, I can only see dhcp discover<br>
> request on br-baremetal and nothing happens<br>
> after that.<br>
> <br>
> I have tried to explain my issue in detail,<br>
> but I would be happy to share more details<br>
> in case still required.<br>
> Can someone please help in resolving my issue.<br>
> <br>
> Regards<br>
> Anirudh Gupta<br>
> <br>
<br><br></blockquote></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><img src="https://drive.google.com/uc?id=0BynJnQEa1sUyU2dxclR4dVVWM0E&export=download&resourcekey=0-SqQLe-ZfiPFkKfdNa8WpMg" width="200" height="41"><br></div><div dir="ltr"><br></div></div></div></div></div></div>