On Tue, Sep 1, 2020, 12:22 PM Stephen John Smoogen <smooge@xxxxxxxxx> wrote:
On Tue, 1 Sep 2020 at 02:36, Manu Hernandez <manu@xxxxxxxxxxxxxxxxxxx> wrote:Hi!
I was going to suggest NetBox as well.
NetBox is also a data center management infrastructure tool (DCIM) too,
so it can be used to document racks, circuits, power, etc.
https://netbox.readthedocs.io/en/stable/
This is a useful tool and one I could have used during the move.. However I have a couple of concerns.One issue is that we would only be able to use it as a reactive tool. We do not control the physical layout, the network, the power and other items for any of our 'clusters' of systems. For most of our systems in different datacenters I have never seen where they are, how they are laid out, etc. Instead I need to rely on different tools at each site to keep that data in place (and for several places that can change regularly).Secondly I don't know how useful this data would be to apprentices if it was kept up to date. The more data in it, the more we would need to lock it down because it would contain non-disclosure data (various sites who lend us systems have different rules for what information they consider public/private.. what limited we have in ansible is generally what is considered what we could share.) Other things like serial numbers of systems are considered sensitive because they can be used to defraud our warranty. [Having had parts ordered for a system we had under warranty to a third party for resale is not something I want to deal with again.]Neither of these concerns are end-of-the-world but they need to be dealt with in any plan to install this service somewhere and then populate it with data.
Agreed.
I've deployed this @work and it indeed is a useful network inventory/management tools specifically for our hybrid infrastructure. I mostly use the API feature to deal w/ it.
But this is to kept private to the world. I mean if you want to use it, use it at its full potential, like you would need to rely on it for every single features it provides, otherwise, it would make no sense and cost you maintenance and SKUs.
Also, there's no other auth method than LDAP (no Kerberos) and afaik, you will have to impl on yourself the SAML plugin and make it work 🤷.
There have been a topic about it on their GitHub page a year ago.
If we use this tool as a "source of truth" (desired state vs operational
state), the change flow should be:
1. Update the NetBox data to reflect the change
2. Change the Ansible code to make it so
When reviewing the Ansible code (roles/playbooks), if a discrepancy
between the Ansible tasks and the NetBox data is found, NetBox should be
used as the correct one (because it's the intended config.) and the
Ansible tasks corrected.
We started writing an ansible plugin which can help dealing with thay w/o having to worry about diff as your playbooks or tasks will gather directly the info from netbox data. This means, you're onboarding a dynamic inventory to you ansible config.
_______________________________________________
A tool like this will help, not only experienced members, but new
candidates like me, giving us a lot of structured information about the
Fedora infra.
Do we have something like NetBox running at the moment? If that's not
the case, please, consider adding it.
Thanks for packaging it, ignatenkobrain!
Regards,
Manu
_______________________________________________
infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
--Stephen J Smoogen.
infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
