Release IP address on Obsolete linked CI

[Frank Licik]

Hi,

is it possible to release IP address upon setting linked CI to obsolete state? I mean change the status from Allocated to Obsolete.
Use case. We have data collector. When the object (CI) is set to obsolete the IP address stays allocated to the object. When you sellect the tab "Linked CIs" you can see the CI as obsolete. If you want to reuse the IP address you have to manually release the IP address and then assign it to new CI. I tried to look the through the code and i see how the IP gets unassigned when there is no linked CI, but i don't know if it is possible to use another query to change it (not overly DB skilled...)

Thx
Frank

[Xtophe38]

Hello,

Good idea !! I'll include that feature in TeemIp next release that I expect to see in a month or so.

But instead of moving the IP to the "Unassigned" state, I'll move it to the "Released" one. Indeed, I consider that an unassigned IP can be realocated straight away without any risk, where a released one should be realocated thinking about it twice as it was allocated not a long time ago, meaning that there is a risk that the IP is still alive...

Regards,
Christophe

[Frank Licik]

thx Christophe, agreed on the state "Released"
Frank

[Xtophe38]

Thinking on the best way do to this, I'm leaning toward a background task that regularly checks if obsolete CIs are using IPs and release them, if any (parameter driven, by organization). The option to do it at the time where a CI is set to obsolete may bring too much latency on the update operations.

Cheers,
Christophe

[Xtophe38]

Next to the status "obsolete", we may set a CI in "stock". I think it could make sense to apply the same rule for such CIs than for the obsolete ones, ie release all the IPs attached to it. Any objection ? Note that a configuration parameter could drive this behaviour.

Rgds,
Christophe

[Frank Licik]

Hello Christophe,
i see new version was released. Did you manage to implement this topic? In the version 2.5?
Thx
Frank

[Xtophe38]

Hi Frank,

Yes, this feature is now part of TeemIp 2.5.0. See here on the wiki.

Enjoy !
Christophe

[Xtophe38]

On additional note: today, CIs that have an 'obsolete' status (as defined by the data model), are not displayed in the list of CIs attached to an IP, even if the IP is still attahced to the obsolete CI... That wil lbe corrected in 2.5.1.

[Frank Licik]

Hi Christophe,
i must be doing something wrong .... ain't working for me. I have enabled the function in Global IP setttings -> Release IPs of CIs that become obsolete = Yes, also changed it in iTop config:
'teemip-ip-mgmt' => array (
'ip_release_on_ci_status' => array (
'enabled' => true,
'debug' => false,
'periodicity' => 3600,
'status_list' =>
array (
0 => 'obsolete',
),
),
),

Scenario:
Obsolete VM (testtest) - Obsolete Logical Interface (eth0), but IP stays linked with the object (which is what you are talking about in your last post?!?), BUT the IP stays "Allocated"

Is there any log i can check? Any other suggestions?
Thank you
Frank

[Xtophe38]

Hello,

Have you activated the CRON so that background tasks can run ? Please, refer to its wiki, here, if needeed.

Rgds,
Christophe

[Frank Licik]

Hi Christophe
yes. the cronjob is running. i get backups everyday (for example) ...
FL

[Xtophe38]

Thanks,

Last point to check (I could have mentionned it in my provious post, sorry): there is a parameter to set in the Global IP Settings for your organization. This one is called "Release IPs of CIs that become obsolete " under the "Default Settings for IPs" tab. Default is set to "no"...

The note is a bit hidden at the bottom of the wiki page related to this feature. I'll improve this... now !

Cheers,
Christophe

[Frank Licik]

As far as i can see this option is ticked for my company.
However i noticed that the text in itop-config got screwed up somehow. I tried to fix it according o the wiki. i will see tomorrow. i might do a rollback tomorrow and start over.
Actually this is interesting. I modified config earlier to reflect the documentation. However checking again it seems it automatically changed again to this...
'teemip-ip-mgmt' => array (
'ip_release_on_ci_status' => array (
'enabled' => true,
'debug' => false,
'periodicity' => 3600,
'status_list' =>
array (
0 => 'obsolete',
),
),
),

Could this be the problem?

FL

[Frank Licik]

Hi Christophe,
unfortunatelly it is still not working for me .... i did a rollback and then installed newest version again. I enabled the obsolence management both in itop-config and in Global IP settings, Background jobs are also configured. Nightly backups are running.
I noticed 1 thing though. There is discrepancy between documentation and actual settings.
The section in config-itop.php after the install reads: (i changed the enabled parameter already)

• 'teemip-ip-mgmt' => array (
  'ip_release_on_ci_status' => array (
  'enabled' => true,
  'debug' => false,
  'periodicity' => 900,
  'status_list' =>
  array (
  0 => 'obsolete',
  ),
  ),
  ),
  *

However doco says:

• 'teemip-ip-mgmt' => array (
  'ip_release_on_ci_status' => array (
  'enabled' => true,
  'debug' => false,
  'periodicity' => 3600,
  'status_list' => array (
  'obsolete',
  ),
  ),
  ),*

  Where is the background job actually triggered? Any other logs i could check?
  Thx
  FL

[Xtophe38]

Hi,

What you could do is to display the priv_backgroundtask in your SQL DB and check if there is an entry for the class names ReleaseIPsFromObsoleteCIs (class_name column). The next_run_date will tell you when the task is suppose to run.

FYI, background tasks are described here.

Rgds,
Christophe

[Frank Licik]

Hi,
it seems it is working now. I will keep an eye on it for a while do some more testing. It appears the problem might have been that it is a test instance and IP addresses are somehow screwed up. IPs have status "Unassigned" yet they were used and linked to another CIs.
I apologize for the false alarm ....
Thank you for your fast responses though.
Regards
Frank

[Frank Licik]

actually (now i'm thinking loud) the mess might be caused by either vSphere collector or vSphere Collector together with teemip. it seems that if you switch off a VM then the IP address is no longer reported to the collector. Then the vSphere collector data sync releases the IP address from the IP field on VM object, but the teemip doesn't unlink the IP because the VM as such is not obsoleted.
I think if you run iTop without Teemip then the vSphere collector syncs the IP address against IP field of the VM. If you have TeemIP then the sync on top of that also creates the logical interfaces and links the IP address to the logical interface. As a result you have those problems i described and also have side effect that each IP has got 2 CIs linked to one IP address. 1 CI = VM, 2nd CI is the logical interface of the VM .... Is it something which can be rectified by correcting some settings?
Thx
FL

[Xtophe38]

Hello,

An idea could be to obsolete the link between the logical interface and the IP address as soon as it disappears from the synchro. What you can do is play with the "full_load_periodicity", "delete_policy", "delete_policy_update" and "delete_policy_retention" in the vSpherelnkIPInterfaceToIPAddressCollector.json file, which corresponds to the "Full load interval", "Delete policy", "Update rules" and "Retention Duration" parameter of the corresponding data synchro in iTop / TeemIp.

Idea could be to delete the lnk as soon as it is not reported by vSphere anymore. It will be recreated as soon as vSphere will detect the link again. Side effect is that we'll loose history data on the link but i don't think this is that important on such object.

I'll look at integrating such mechanism by default in the collector.

Rgds,
Christophe

[schirrms]

Hi Christophe,

I encounter a very nice trouble today, because our VMware sync didn(t work the night before, so i Got a bunch (more than 100…)

Background task (TeemIp\TeemIp\Extension\IPManagement\Hook\ReleaseIPsFromObsoleteCIs)

I'm currently correcting all these wrong managementip_id suppression, and I also removed the 'Remove IP From obsoleted CI' option from my global IP param (didn't know this parameter) to see if this is better in my setup.

But I think that (more or less like Frank said) there is a 'strange' behavior: The backgrtound task release the IP from the CI, but not from the logical interface. As a result, the IP is still 'allocated', hence not reusable to reapply to the VM.

So the correction is :

• Deallocate the IP from all devices
• allocate the IP to the VM
• allocate the IP to the logical interface

And this, a hundred time today…

Thanks,

Pascal

[Xtophe38]

Hi Pascal,

Hum... I'll have a look at this and I'll let you know.

Rgds,
Christophe