Merge ~kgarloff/cloud-init:detect_otc_as_openstack_ds into cloud-init:master

[Kurt Garloff]

Two commits to address LP: #1756471.
(a) Detect gen1 Xen hosts in OpenTelekomCloud by asset tag as OpenSource DS.
(b) Downgrade OpenStack DS to DS_MAYBE if ConfigDrive2 is detected, as it is a valid fallback on many OpenStack clouds, including OpenTelekomCloud BareMetal systems.

[Scott Moser (smoser)]

Hi Kurt, Thanksk for the merge proposal.

I'd like to make a suggestion
a.) split the 'a' and 'b' to different merge requests.
  'a' is straight forward win
b.) could have side effects.
  we can discuss that more on its own MP, but I think that as it is right now config-drive would always end up taking precedence if it is present, because it runs at "local" time frame while the openstack runs in network stage.

[Kurt Garloff (kgarloff)]

Hi Scott,

On 21.03.2018 19:34, Scott Moser wrote:
> Hi Kurt, Thanksk for the merge proposal.
>
> I'd like to make a suggestion
> a.) split the 'a' and 'b' to different merge requests.

I intentionally did two commits to the branch, not just one, so they can
be treated as separate entities ...
You could just git cherry-pick the first one, no?
Or does that break your tooling/workflow?

> 'a' is straight forward win
Agree.
> b.) could have side effects.
> we can discuss that more on its own MP, but I think that as it is right now config-drive would always end up taking precedence if it is present, because it runs at "local" time frame while the openstack runs in network stage.

Sure, IF cloud-init / ds-identify are configured to allow the
ConfigDrive DS, then it will take precendence, so no change there.
If for some reason it's disabled or fails and if the user has configured
the ds-identify policy to also try the MAYBE sources (which is default),
then a fallback can happen.

So do you want to cherry-pick or do you want me to create a fresh branch
with the first patch and then another branch based on the first branch
with the second patch on top?
Or, if you merge quickly, I can alternatively create the second branch
on top of master with the first one already merged ...

Let me know ...

--
Kurt Garloff <email address hidden>, Cologne, DE

[Scott Moser (smoser)]

Kurt,
I put up just the 'Identify OpenTelecomcloud' commit as
 https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341851

and added a ds-identify unit test for it.

After that lands (I hope shortly) we can look at the second one here.

[Scott Moser (smoser)]

the other is merged now, so you can rebase and push then the diff will get updated.

[Kurt Garloff (kgarloff)]

Rebase done. (I hope I have not screwed up the git commands.)

[Scott Moser (smoser)]

Kurt I suspect you didn't push without --force.

you have to push --force because you have a non-fastforward locally after the rebase.

[Kurt Garloff (kgarloff)]

Hi Scott,

thanks for the hint!

Better now?

-- Kurt

On 23.03.2018 17:32, Scott Moser wrote:
> Kurt I suspect you didn't push without --force.
>
> you have to push --force because you have a non-fastforward locally after the rebase.
>

--
Kurt Garloff <email address hidden>, Cologne, DE

[Scott Moser (smoser)]

Kurt.
Looks good. thanks.

I still have to think about this more. But you've done the right bits in the MP.
Thanks.

[Chad Smith (chad.smith)]

Kurt, thanks for the work on this, your work has landed in 18.2 cloud-init version 18.2 and is currently present in bionic (and xenial-proposed pocket). If you wish to test it out cloud-init 18.2 or greater will have the functionality you need as the branch which landed your functionality is here:
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341851

Marking this branch as rejected only from a documentation perspective. The content has been accepted upstream.

Unmerged commits

89abc06... by Kurt Garloff on 2018-03-21

Downgrade OpenStack DS to MAYBE is ConfigDrive2 is found.

The old code unconditionally disabled OpenStack DS when ConfigDrive2
was detected. However, we might not have ConfigDrive2 configured or
find it undesirable otr sable for some reason.

So change this to keep OpenStack as MAYBE DS that we can fall back
to if the user so desires.

OpenTelekomCloud provide a network OpenStack DS on BareMetal instances
in addition to the ConfigDrive DS provided there, so this patch
increases the options there.

Followup to LP: #1756471.

825db3a... by Kurt Garloff on 2018-03-21

Identify OpenTelekomCloud Xen as OpenStack DS.

Open Telekom Cloud gen1 (Xen) hosts do not provide nova product
names in DMI but Xen HVM domU. They can however be safely identified
by the OpenTelekomCloud Chassis asset tag. OpenTelekomCloud does
use the network OpenStack DataSource, so we better detect it.

This fixes LP: #1756471.

diff --git a/tools/ds-identify b/tools/ds-identify
index 9a2db5c..a981e53 100755
--- a/tools/ds-identify
+++ b/tools/ds-identify
@@ -892,23 +892,29 @@ dscheck_GCE() {
 dscheck_OpenStack() {
     # the openstack metadata http service
 
-    # if there is a config drive, then do not check metadata
+    OSDS_FOUND=${DS_FOUND}
+    # if there is a config drive, then downgrade OpenStack to fallback
+    # datasource DS_MAYBE (if we find signs of existence).
     # FIXME: if config drive not in the search list, then we should not
     # do this check.
     check_configdrive_v2
     if [ $? -eq ${DS_FOUND} ]; then
-        return ${DS_NOT_FOUND}
+        OSDS_FOUND=${DS_MAYBE}
     fi
     local nova="OpenStack Nova" compute="OpenStack Compute"
     if dmi_product_name_matches "$nova"; then
-        return ${DS_FOUND}
+        return ${OSDS_FOUND}
     fi
     if dmi_product_name_matches "$compute"; then
         # RDO installed nova (LP: #1675349).
-        return ${DS_FOUND}
+        return ${OSDS_FOUND}
     fi
     if [ "${DI_PID_1_PRODUCT_NAME}" = "$nova" ]; then
-        return ${DS_FOUND}
+        return ${OSDS_FOUND}
+    fi
+    # OTC gen1 (Xen) hosts use OpenStack datasource, LP: #1756471
+    if dmi_chassis_asset_tag_matches "OpenTelekomCloud"; then
+        return ${OSDS_FOUND}
     fi
 
     if dmi_chassis_asset_tag_matches "OpenTelekomCloud"; then