5:12 a.m.
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
1:36 a.m.
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
5:21 a.m.
On Tue, 1 Sep 2020 at 02:36, Manu Hernandez <manu(a)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.
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.
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
_______________________________________________
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to
infrastructure-leave(a)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.fedora...
--
Stephen J Smoogen.
4:39 p.m.
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(a)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.
>
> https://netbox.readthedocs.io/en/stable/
>
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
2:46 p.m.
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(a)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.
>>
>> https://netbox.readthedocs.io/en/stable/
>>
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?
10:17 a.m.
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(a)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.
> > >
> > > https://netbox.readthedocs.io/en/stable/
> > >
>
> 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
11:36 a.m.
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
2:35 p.m.
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.
1:10 p.m.
On Tue, Sep 1, 2020, 12:22 PM Stephen John Smoogen <smooge(a)gmail.com> wrote:
On Tue, 1 Sep 2020 at 02:36, Manu Hernandez <manu(a)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.
>
> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-leave(a)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.fedora...
>
--
Stephen J Smoogen.
_______________________________________________
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to
infrastructure-leave(a)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.fedora...
11:47 a.m.
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?
1322
days inactive
1327
days old
infrastructure@lists.fedoraproject.org
9 comments
5 participants
participants (5)
-
Kevin Fenzi -
Manu Hernandez -
Pierre-Yves Chibon -
SmootherFrOgZ -
Stephen John Smoogen