Notification content

Hi,

As you probably heard (and saw in the last demo) we have a new notification
system, now its time to start using and improving it.

here are some of the content I think make sense to discuss, comments etc
are welcomed:

first, I would like to group notification based of topic, for example,
provisioning, infrastructure errors, plugin specific (e.g. content /
subscriptions) etc

Provisioning:

notification when host was failed to provision - for example we were unable
to render a template, or a proxy was down etc, this is usually hidden from
the user and the only way to figure out whats going on is via logs or
machine console.
an action could be to take the user the to rebuild host modal, which checks
the templates and proxies. another action could be to the host edit page,
but we must relay the actual error so its clear what the issue is.
I would suggest to keep the notification for 3 days or if the host got
reprovisioned - then we could remove / mark as read the old notification.

success provisioning - As we already send an email every time a host has
finished provisioning, i think it make sense to highlight that in the UI as
well, I would default to 24 hours or even less for such events. we could
further think about limiting to either top xx hosts that got provisioned,
or just have a message saying hosts were provisioned, where you can link
and get back to host list of installed_at > time and owner = current.user.

Inventory
fact / report importing

  • when a new host gets imported? does it make sense? currently if we import
    a host from facts there is no place where we tell the user it happened, yet
    the concern here is that initial import can import thousands of hosts, so
    clearly, we can't have one notification per host.

  • when there is a failure importing facts (imho reports are already visible
    in the host status).
    I personally had problems where i was able to create a host record, but Nic
    record failed from some reason. as a user, if I would not watch the logs, I
    would be clueless of that failure ever happening.
    my concern here is that while I get let the user know a failure happened, I
    have no action to take him to, for example, I see this in my logs:
    2017-01-23T15:31:08 26265d09 [app] [I] Import facts for 'host' completed.
    Added: 0, Updated: 4, Deleted 0 facts
    2017-01-23T15:31:09 26265d09 [sql] [W] Saving br182 NIC for host host
    failed, skipping because:
    2017-01-23T15:31:09 26265d09 [sql] [W] IP address has already been taken
    2017-01-23T15:31:09 26265d09 [sql] [W] Saving em1 NIC for host host failed,
    skipping because:
    2017-01-23T15:31:09 26265d09 [sql] [W] IP address can't be blank
    2017-01-23T15:31:09 26265d09 [sql] [W] Ip6 can't be blank
    2017-01-23T15:31:09 26265d09 [sql] [W] Saving ipmi NIC for host host
    failed, skipping because:
    2017-01-23T15:31:09 26265d09 [sql] [W] Identifier has already been taken
    2017-01-23T15:31:09 26265d09 [app] [I] Completed 201 Created in 569ms
    (Views: 4.3ms | ActiveRecord: 149.4ms)

yet we have no place where this information is visible in the UI, I think
we would need to either capture these errors in the db, or have a wizard /
troubleshooting flow to fix this kind of issues. maybe just notifying the
user as a first step is better than nothing.

ENC Failures

  • If we were unable to create ENC output for puppet I would like to see a
    notification, again I would limit it to a certain amount of events (e.g.
    maybe up to 5?) and would clear the notification once the issue is fixed.

Users

  • Does it make sense to notify admins when new users start using the system?
  • Anything else? (maybe admin change your permissions?)

Org/Loc

  • Hosts in mismatch mode?
  • Hosts that do not belong to any org/loc (probably because they were
    imported?)

Trends

  • When trend counter is not running?

System status

  • when proxies are down / with failures
  • when dynflow, pulp candlepin etc are down
  • when compute resources are down?
  • when ldap servers are down?
    (all of these errors should clear or change their severity once they are
    resolved).
  • when there is a newer version of foreman or plugin available upstream?

Community Templates

  • When there is a new version of the templates available at github?

Discovery

  • When at least one new host is being discovered in the last xx minutes
  • When discovered host fails?

CA Expiry (Puppet and others)
When your certificates are about to expire - I know puppet CA is by default
to 5 years, and sadly clients certs are usually less interesting as if your
CA will expire (which is happening first as the 5 years clock ticks from
your puppet master install time) all of the clients will expire too.

Other areas:
Tasks (would probably prefer not to create a task specific notification,
but rather a notification for what ever that is using the task in the first
place).
Sync failures
Subscription expiry
Virt-who reporting failures
SCAP failures?

Thanks,
Ohad

It's be nice to be able to turn some of these off, I might not care about
some types of notifications.

I think a simple "don't show this type of notifications again" on the
notification would be great.

I don't know if this is already possible?

Also a couple of more notification suggestions:

  • Disk space if using Katello
  • new blog post posted
  • new community demo
  • other community stuff?

Sean

··· On Wed, 25 Jan 2017 at 07:42, Ohad Levy wrote:

Hi,

As you probably heard (and saw in the last demo) we have a new
notification system, now its time to start using and improving it.

here are some of the content I think make sense to discuss, comments etc
are welcomed:

first, I would like to group notification based of topic, for example,
provisioning, infrastructure errors, plugin specific (e.g. content /
subscriptions) etc

Provisioning:

notification when host was failed to provision - for example we were
unable to render a template, or a proxy was down etc, this is usually
hidden from the user and the only way to figure out whats going on is via
logs or machine console.
an action could be to take the user the to rebuild host modal, which
checks the templates and proxies. another action could be to the host edit
page, but we must relay the actual error so its clear what the issue is.
I would suggest to keep the notification for 3 days or if the host got
reprovisioned - then we could remove / mark as read the old notification.

success provisioning - As we already send an email every time a host has
finished provisioning, i think it make sense to highlight that in the UI as
well, I would default to 24 hours or even less for such events. we could
further think about limiting to either top xx hosts that got provisioned,
or just have a message saying hosts were provisioned, where you can link
and get back to host list of installed_at > time and owner = current.user.

Inventory
fact / report importing

  • when a new host gets imported? does it make sense? currently if we
    import a host from facts there is no place where we tell the user it
    happened, yet the concern here is that initial import can import thousands
    of hosts, so clearly, we can’t have one notification per host.

  • when there is a failure importing facts (imho reports are already
    visible in the host status).
    I personally had problems where i was able to create a host record, but
    Nic record failed from some reason. as a user, if I would not watch the
    logs, I would be clueless of that failure ever happening.
    my concern here is that while I get let the user know a failure happened,
    I have no action to take him to, for example, I see this in my logs:
    2017-01-23T15:31:08 26265d09 [app] [I] Import facts for ‘host’ completed.
    Added: 0, Updated: 4, Deleted 0 facts
    2017-01-23T15:31:09 26265d09 [sql] [W] Saving br182 NIC for host host
    failed, skipping because:
    2017-01-23T15:31:09 26265d09 [sql] [W] IP address has already been taken
    2017-01-23T15:31:09 26265d09 [sql] [W] Saving em1 NIC for host host
    failed, skipping because:
    2017-01-23T15:31:09 26265d09 [sql] [W] IP address can’t be blank
    2017-01-23T15:31:09 26265d09 [sql] [W] Ip6 can’t be blank
    2017-01-23T15:31:09 26265d09 [sql] [W] Saving ipmi NIC for host host
    failed, skipping because:
    2017-01-23T15:31:09 26265d09 [sql] [W] Identifier has already been taken
    2017-01-23T15:31:09 26265d09 [app] [I] Completed 201 Created in 569ms
    (Views: 4.3ms | ActiveRecord: 149.4ms)

yet we have no place where this information is visible in the UI, I think
we would need to either capture these errors in the db, or have a wizard /
troubleshooting flow to fix this kind of issues. maybe just notifying the
user as a first step is better than nothing.

ENC Failures

  • If we were unable to create ENC output for puppet I would like to see a
    notification, again I would limit it to a certain amount of events (e.g.
    maybe up to 5?) and would clear the notification once the issue is fixed.

Users

  • Does it make sense to notify admins when new users start using the
    system?
  • Anything else? (maybe admin change your permissions?)

Org/Loc

  • Hosts in mismatch mode?
  • Hosts that do not belong to any org/loc (probably because they were
    imported?)

Trends

  • When trend counter is not running?

System status

  • when proxies are down / with failures
  • when dynflow, pulp candlepin etc are down
  • when compute resources are down?
  • when ldap servers are down?
    (all of these errors should clear or change their severity once they are
    resolved).
  • when there is a newer version of foreman or plugin available upstream?

Community Templates

  • When there is a new version of the templates available at github?

Discovery

  • When at least one new host is being discovered in the last xx minutes
  • When discovered host fails?

CA Expiry (Puppet and others)
When your certificates are about to expire - I know puppet CA is by
default to 5 years, and sadly clients certs are usually less interesting as
if your CA will expire (which is happening first as the 5 years clock ticks
from your puppet master install time) all of the clients will expire too.

Other areas:
Tasks (would probably prefer not to create a task specific notification,
but rather a notification for what ever that is using the task in the first
place).
Sync failures
Subscription expiry
Virt-who reporting failures
SCAP failures?

Thanks,
Ohad

You received this message because you are subscribed to the Google Groups
"foreman-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

> Hi,
>
> As you probably heard (and saw in the last demo) we have a new
> notification system, now its time to start using and improving it.
>
> here are some of the content I think make sense to discuss, comments etc
> are welcomed:
>
> first, I would like to group notification based of topic, for example,
> provisioning, infrastructure errors, plugin specific (e.g. content /
> subscriptions) etc
>
> Provisioning:
>
> notification when host was failed to provision - for example we were
> unable to render a template, or a proxy was down etc, this is usually
> hidden from the user and the only way to figure out whats going on is via
> logs or machine console.
> an action could be to take the user the to rebuild host modal, which
> checks the templates and proxies. another action could be to the host edit
> page, but we must relay the actual error so its clear what the issue is.
> I would suggest to keep the notification for 3 days or if the host got
> reprovisioned - then we could remove / mark as read the old notification.
>
> success provisioning - As we already send an email every time a host has
> finished provisioning, i think it make sense to highlight that in the UI as
> well, I would default to 24 hours or even less for such events. we could
> further think about limiting to either top xx hosts that got provisioned,
> or just have a message saying hosts were provisioned, where you can link
> and get back to host list of installed_at > time and owner = current.user.
>
This notification has been implemented and demoed in last week community
demo.

>
> Inventory
> fact / report importing
> - when a new host gets imported? does it make sense? currently if we
> import a host from facts there is no place where we tell the user it
> happened, yet the concern here is that initial import can import thousands
> of hosts, so clearly, we can't have one notification per host.
>
> - when there is a failure importing facts (imho reports are already
> visible in the host status).
> I personally had problems where i was able to create a host record, but
> Nic record failed from some reason. as a user, if I would not watch the
> logs, I would be clueless of that failure ever happening.
> my concern here is that while I get let the user know a failure happened,
> I have no action to take him to, for example, I see this in my logs:
> 2017-01-23T15:31:08 26265d09 [app] [I] Import facts for 'host' completed.
> Added: 0, Updated: 4, Deleted 0 facts
> 2017-01-23T15:31:09 26265d09 [sql] [W] Saving br182 NIC for host host
> failed, skipping because:
> 2017-01-23T15:31:09 26265d09 [sql] [W] IP address has already been taken
> 2017-01-23T15:31:09 26265d09 [sql] [W] Saving em1 NIC for host host
> failed, skipping because:
> 2017-01-23T15:31:09 26265d09 [sql] [W] IP address can't be blank
> 2017-01-23T15:31:09 26265d09 [sql] [W] Ip6 can't be blank
> 2017-01-23T15:31:09 26265d09 [sql] [W] Saving ipmi NIC for host host
> failed, skipping because:
> 2017-01-23T15:31:09 26265d09 [sql] [W] Identifier has already been taken
> 2017-01-23T15:31:09 26265d09 [app] [I] Completed 201 Created in 569ms
> (Views: 4.3ms | ActiveRecord: 149.4ms)
>
> yet we have no place where this information is visible in the UI, I think
> we would need to either capture these errors in the db, or have a wizard /
> troubleshooting flow to fix this kind of issues. maybe just notifying the
> user as a first step is better than nothing.
>
> ENC Failures
> - If we were unable to create ENC output for puppet I would like to see a
> notification, again I would limit it to a certain amount of events (e.g.
> maybe up to 5?) and would clear the notification once the issue is fixed.
>
> Users
> - Does it make sense to notify admins when new users start using the
> system?
> - Anything else? (maybe admin change your permissions?)
>

I've added a notification on hosts that do not have an owner. this is
currently triggered only when there is another notification for that host
that we are unable to deliver (as there is no owner).
in the future, we can run this in a daily task or something similar.

>
> Org/Loc
> - Hosts in mismatch mode?
> - Hosts that do not belong to any org/loc (probably because they were
> imported?)
>
> Trends
> - When trend counter is not running?
>
> System status
> - when proxies are down / with failures
> - when dynflow, pulp candlepin etc are down
> - when compute resources are down?
> - when ldap servers are down?
> (all of these errors should clear or change their severity once they are
> resolved).
> - when there is a newer version of foreman or plugin available upstream?
>
> Community Templates
> - When there is a new version of the templates available at github?
>
> Discovery
> - When at least one new host is being discovered in the last xx minutes
>
Was demoed as well last week.

> - When discovered host fails?
>
> CA Expiry (Puppet and others)
> When your certificates are about to expire - I know puppet CA is by
> default to 5 years, and sadly clients certs are usually less interesting as
> if your CA will expire (which is happening first as the 5 years clock ticks
> from your puppet master install time) all of the clients will expire too.
>
>
> Other areas:
> Tasks (would probably prefer not to create a task specific notification,
> but rather a notification for what ever that is using the task in the first
> place).
> Sync failures
> Subscription expiry
> Virt-who reporting failures
> SCAP failures?
>
>
>
Any other notifications people would like to see / implement?

··· On Wed, Jan 25, 2017 at 9:42 AM, Ohad Levy wrote:

Thanks,
Ohad

> - new blog post posted
> - new community demo
> - other community stuff?
>

That's a wonderful idea. We should make some cron task that
reads from an RSS feed or something similar, and create notifications
from there.

··· On 01/25, Sean O'Keeffe wrote:

Sean

On Wed, 25 Jan 2017 at 07:42, Ohad Levy ohadlevy@gmail.com wrote:

Hi,

As you probably heard (and saw in the last demo) we have a new
notification system, now its time to start using and improving it.

here are some of the content I think make sense to discuss, comments etc
are welcomed:

first, I would like to group notification based of topic, for example,
provisioning, infrastructure errors, plugin specific (e.g. content /
subscriptions) etc

Provisioning:

notification when host was failed to provision - for example we were
unable to render a template, or a proxy was down etc, this is usually
hidden from the user and the only way to figure out whats going on is via
logs or machine console.
an action could be to take the user the to rebuild host modal, which
checks the templates and proxies. another action could be to the host edit
page, but we must relay the actual error so its clear what the issue is.
I would suggest to keep the notification for 3 days or if the host got
reprovisioned - then we could remove / mark as read the old notification.

success provisioning - As we already send an email every time a host has
finished provisioning, i think it make sense to highlight that in the UI as
well, I would default to 24 hours or even less for such events. we could
further think about limiting to either top xx hosts that got provisioned,
or just have a message saying hosts were provisioned, where you can link
and get back to host list of installed_at > time and owner = current.user.

Inventory
fact / report importing

  • when a new host gets imported? does it make sense? currently if we
    import a host from facts there is no place where we tell the user it
    happened, yet the concern here is that initial import can import thousands
    of hosts, so clearly, we can’t have one notification per host.

  • when there is a failure importing facts (imho reports are already
    visible in the host status).
    I personally had problems where i was able to create a host record, but
    Nic record failed from some reason. as a user, if I would not watch the
    logs, I would be clueless of that failure ever happening.
    my concern here is that while I get let the user know a failure happened,
    I have no action to take him to, for example, I see this in my logs:
    2017-01-23T15:31:08 26265d09 [app] [I] Import facts for ‘host’ completed.
    Added: 0, Updated: 4, Deleted 0 facts
    2017-01-23T15:31:09 26265d09 [sql] [W] Saving br182 NIC for host host
    failed, skipping because:
    2017-01-23T15:31:09 26265d09 [sql] [W] IP address has already been taken
    2017-01-23T15:31:09 26265d09 [sql] [W] Saving em1 NIC for host host
    failed, skipping because:
    2017-01-23T15:31:09 26265d09 [sql] [W] IP address can’t be blank
    2017-01-23T15:31:09 26265d09 [sql] [W] Ip6 can’t be blank
    2017-01-23T15:31:09 26265d09 [sql] [W] Saving ipmi NIC for host host
    failed, skipping because:
    2017-01-23T15:31:09 26265d09 [sql] [W] Identifier has already been taken
    2017-01-23T15:31:09 26265d09 [app] [I] Completed 201 Created in 569ms
    (Views: 4.3ms | ActiveRecord: 149.4ms)

yet we have no place where this information is visible in the UI, I think
we would need to either capture these errors in the db, or have a wizard /
troubleshooting flow to fix this kind of issues. maybe just notifying the
user as a first step is better than nothing.

ENC Failures

  • If we were unable to create ENC output for puppet I would like to see a
    notification, again I would limit it to a certain amount of events (e.g.
    maybe up to 5?) and would clear the notification once the issue is fixed.

Users

  • Does it make sense to notify admins when new users start using the
    system?
  • Anything else? (maybe admin change your permissions?)

Org/Loc

  • Hosts in mismatch mode?
  • Hosts that do not belong to any org/loc (probably because they were
    imported?)

Trends

  • When trend counter is not running?

System status

  • when proxies are down / with failures
  • when dynflow, pulp candlepin etc are down
  • when compute resources are down?
  • when ldap servers are down?
    (all of these errors should clear or change their severity once they are
    resolved).
  • when there is a newer version of foreman or plugin available upstream?

Community Templates

  • When there is a new version of the templates available at github?

Discovery

  • When at least one new host is being discovered in the last xx minutes
  • When discovered host fails?

CA Expiry (Puppet and others)
When your certificates are about to expire - I know puppet CA is by
default to 5 years, and sadly clients certs are usually less interesting as
if your CA will expire (which is happening first as the 5 years clock ticks
from your puppet master install time) all of the clients will expire too.

Other areas:
Tasks (would probably prefer not to create a task specific notification,
but rather a notification for what ever that is using the task in the first
place).
Sync failures
Subscription expiry
Virt-who reporting failures
SCAP failures?

Thanks,
Ohad

You received this message because you are subscribed to the Google Groups
"foreman-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

I'm biased, but +1 :slight_smile:

There was a PR a while back to add RSS as a dashboard widget, which didn't
make it in. I'm genuinely unsure whether RSS-as-a-widget or RSS-as-a-
notification is better, but one of these should be done, from my viewpoint :slight_smile:

On top tof that, if you're going to notify about "new" things, then:

  • New version of Foreman available
  • New version for any of your proxies
  • New verison of plugins you have enabled

The latter needs some thought and possibly some new infra on our end - while
it's easy enough for packaged ones, perhaps we can go further…

Greg

··· On Thursday, 26 January 2017 21:02:54 CET Daniel Lobato Garcia wrote:

On 01/25, Sean O’Keeffe wrote:

  • new blog post posted
  • new community demo
  • other community stuff?

That’s a wonderful idea. We should make some cron task that
reads from an RSS feed or something similar, and create notifications
from there.


IRC / Twitter: gwmngilfen
Diaspora: gwmngilfen@joindiaspora.com