ignatenkobrain wanted to share this with us as something potentially interesting to look at. He opened a ticket but agreed that an email thread would be better suited to discuss this, so here it is and here below is Igor's original comment:
----
Hi folks,
This is not really request to do anything but rather heads-up from work I've been doing in GoodData for some time. We've been searching for something that helps us to have list of devices, their IPs and generally some kind of IP management in one place. So we started to use netbox (I think it is originating from DigitalOcean).
I've finally managed to package it https://src.fedoraproject.org/rpms/netbox in Fedora. It supports LDAP and I guess can be somehow paired with Kerberos. I did not check if it is possible to pair it with OIDC, but since it is Django should be not very hard.
So in case you were looking for something like this - feel free to try it out and let me know if you have any issues.
----
Original ticket: https://pagure.io/fedora-infrastructure/issue/9279
Pierre
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/
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.
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
On Tue, 1 Sep 2020 at 02:36, Manu Hernandez manu@littlemousetrap.com 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.
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.
If we use this tool as a "source of truth" (desired state vs operational state), the change flow should be:
- Update the NetBox data to reflect the change
- 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.
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@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org 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@lists.fedorapro...
On Tue, Sep 01, 2020 at 06:21:58AM -0400, Stephen John Smoogen wrote:
On Tue, 1 Sep 2020 at 02:36, Manu Hernandez manu@littlemousetrap.com 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.
Another thing: RHIT uses their own DCIM to keep track of things... so if we use our own thats another place to update, etc.
Of course anything we run will be open, while the RHIT one will likely be limited to employees. :(
kevin
Thanks for the information, Kevin.
On 02/09/2020 23:39, Kevin Fenzi wrote:
On Tue, Sep 01, 2020 at 06:21:58AM -0400, Stephen John Smoogen wrote:
On Tue, 1 Sep 2020 at 02:36, Manu Hernandez manu@littlemousetrap.com 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.
Another thing: RHIT uses their own DCIM to keep track of things... so if we use our own thats another place to update, etc.
RHIT == Red Hat Infrastructure Team?
Of course anything we run will be open, while the RHIT one will likely be limited to employees. :(
kevin
Does Red Hat manage all the Fedora infrastructure?
If that's *not* the case, I suppose their DCIM will have only the systems under their control. Who manages/tracks the rest?
On Thu, Sep 03, 2020 at 09:46:35PM +0200, Manu Hernandez wrote:
Thanks for the information, Kevin.
On 02/09/2020 23:39, Kevin Fenzi wrote:
On Tue, Sep 01, 2020 at 06:21:58AM -0400, Stephen John Smoogen wrote:
On Tue, 1 Sep 2020 at 02:36, Manu Hernandez manu@littlemousetrap.com 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.
Another thing: RHIT uses their own DCIM to keep track of things... so if we use our own thats another place to update, etc.
RHIT == Red Hat Infrastructure Team?
Yep.
Of course anything we run will be open, while the RHIT one will likely be limited to employees. :(
kevin
Does Red Hat manage all the Fedora infrastructure?
If that's *not* the case, I suppose their DCIM will have only the systems under their control. Who manages/tracks the rest?
Well, depends on what you mean. :)
"Fedora" doesn't exist as a legal entity. All the hardware we manage is owned by Red Hat (or donated for the projects use). We manage all the servers we use, but those servers are in datacenters that we don't own or manage. So, things like switches and firewall rules and upstream connections are all managed by Red Hat's IT (and the datacenter itself).
So, IMHO it would be helpfull to have some kind of inventory thing for our servers that we do directly manage, but putting things like switches or routers or other datacenter assets in it wouldnt make much sense to me since we don't directly control those.
Does that make sense?
kevin
Thanks, Kevin.
On 04/09/2020 17:17, Kevin Fenzi wrote:
On Thu, Sep 03, 2020 at 09:46:35PM +0200, Manu Hernandez wrote:
Does Red Hat manage all the Fedora infrastructure?
If that's *not* the case, I suppose their DCIM will have only the systems under their control. Who manages/tracks the rest?
Well, depends on what you mean. :)
"Fedora" doesn't exist as a legal entity. All the hardware we manage is owned by Red Hat (or donated for the projects use). We manage all the servers we use, but those servers are in datacenters that we don't own or manage. So, things like switches and firewall rules and upstream connections are all managed by Red Hat's IT (and the datacenter itself).
I thought Fedora was something like Debian but with some Red Hat support (donated hardware, man-hours, financial support...), but I wasn't aware of all the Fedora infra being owned by Red Hat!
That changes everything.
So, IMHO it would be helpfull to have some kind of inventory thing for our servers that we do directly manage, but putting things like switches or routers or other datacenter assets in it wouldnt make much sense to me since we don't directly control those.
Does that make sense?
Yep, I think the same.
kevin
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.
I didn't know that...
As someone used to have its servers at hand, this is new to me (and a bit strange, to be honest, but I suppose it's common in large environments)
Who does all that? (I mean, the tasks at the DC)
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).
Which tools are those? Are they accessible to the fi-apprentice team?
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.)
So, is that information accesible only to some Fedora infra teams? To Red Hat employees? Do you have to sign some kind of NDA?
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.]
I have no words. Faith in humanity -1
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.
On Tue, Sep 1, 2020, 12:22 PM Stephen John Smoogen smooge@gmail.com wrote:
On Tue, 1 Sep 2020 at 02:36, Manu Hernandez manu@littlemousetrap.com 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.
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:
- Update the NetBox data to reflect the change
- 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@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org 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@lists.fedorapro...
-- Stephen J Smoogen.
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org 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@lists.fedorapro...
On 04/09/2020 20:10, SmootherFrOgZ wrote:
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.
So who would have access to it? I suppose the fi-apprentice team will be left out until we "graduated" to a "trusted" team.
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.
Thanks for pointing this up.
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.
That sounds great!
I was thinking about this: https://docs.ansible.com/ansible/latest/plugins/inventory/netbox.html
Are you using that or a custom inventory plugin?
infrastructure@lists.fedoraproject.org