Satellite 6: Filtered Content Views and Errata
I'm in the process of building my new Satellite 6.1 environment, transitioning to it from 5.7 in the near future. I have it mostly up and running, doing things that I want it to do. However, I have come across a situation and wanted to ask the community for feedback and ideas. I have a ticket open with RH support as well.
The situation:
I have an oracle database environment that must remain on RHEL 6.5 due to 3rd party vendor support requirements. There is one dev server and two prod servers which are in a RAC.
I created a new content view and added all the 6Server repositories. Then I created a filter that excludes all errata that was released after 10/13/14, the day before 6.6 came out. Created a new view and published it to dev. It works how I would expect it to.
Even though these servers are locked at 6.5, I'm still required to apply critical errata unless that update requires an update past 6.5. To do this, I go into the Content > Errata menu in Satellite. This will show me all available errata that is applicable or installable to the client servers. Since the errata is filtered out in my content view, all errata released after 10/13/14 is available. I go through the list and select all critical errata as well as any errata identified by our internal vulnerability scanner as required. I click apply errata and it creates an incremental content view which I can them promote to dev and then later to prod. Everything is happy and patched as much as it can be.
That is, until I have to publish a new version. Say I add a new custom repository to the content view, I'd have to publish a new version of the content view to make it available to the servers. When I do this, the packages from my new repository are available, but none of the errata I had applied before (in the incremental version) are in this version of the content view.
If I build a new server to be a 3rd member of the RAC cluster, it'll only get whatever packages are in the content view version. None of the errata that was already applied to the other 2 servers would be available since I've promoted the prod lifecycle environment past the original incremental update. I'd have to go back through the errata menu, select everything I selected before and add it to a new incremental version.
This seems like a lot of messing around and wouldn't really work in a situation where servers are being built more often. Am I doing something wrong? Anyone have any ideas how to get around this besides manually keeping a list of errata I added before and readding it every time I publish a new content view?
Responses
Hi Ben,
Not sure if this is practical in your setup (might depend on how many erratas you apply to 6.5) but could you maintain a static list of the incremental errata and then use hammer to commit the changes after you publish a new version of your view? The syntax would probably look like this:
# hammer -u admin -p changeme content-view version incremental-update --errata-ids=f51f03db-dae7-40d9-9bbc-368fcb95db39,004d860a-625e-4daf-ab7e-a71827169a39 --environment-ids=2,3 --id=6
(Example taken from Red Hat Bugzilla 1200571 )
Might not be ideal and it would require a bit of work up front to identify the errata id's, but at least you could keep this script under change control and update it when necessary as you select new errata. Hopefully it would allow you to maintain a consistent content view with each major update you publish.
Richard.
Ben,
Could you please update this discussion with a progress update at some time? This may be a common use case and it would be good to know if the advice you received from Red Hat Support got you the solution you needed. Others may be able to benefit from your experience.
Ben,
Thanks. I'll take that feedback and see if we can somehow streamline the workflow.
Russell,
I have raised a similar issue in previous Satellite versions. I am not sure how big the lab is that you test Satellite 6 in, but I feel that anyone that is using it in a sizeable environment is going to have the same complaints about the UI and its inability to handle large numbers of entities (eg. errata, hosts, packages).
The UI and it's 'infitinite scrolling' style lists are extremely tedious to navigate if you have anything more than a few pages. On one site we have ~200 ESX servers, browsing these (without any VMs added) is a frustrating experience. I had a similar experience when creating content filters as Ben has outlined.. essentially paginating through thousands of entries just isn't workable.
PixelDrift.NET Support,
As always, thanks for your feedback. Regarding the UI and handling a large number of entities, are there specific enhancements you would like to see implemented? Apologies if you've detailed this before. If I understand correctly, there are two issues here: 1. It's not easy to handle the management and deployment of a large set of errata, up to a specific date. 2. The Satellite web UI makes it difficult to select a large number of errata.
Do I understand the issues here correctly? If so, I can raise tickets as necessary to have this improved.
Russell,
The scrolling and pagination issues aren't isolated to errata. As I have mentioned in my post above, the method that Satellite 6 Web UI uses to paginate lists works against the user... and efficiency is sacrificed for aesthetics. In Satellite 5 you could list very large numbers of items (~500) without pagination.
I have a collection of other issues detailed in this thread, and I encourage anyone with Satellite 6 issues to air them (ie. provide feedback) rather than waiting for fixes in upcoming releases.
I look forward to your feedback in the following thread Russell: https://access.redhat.com/discussions/2092611
PixelDift.NET Support,
Thanks for your feedback. If I understand correctly, your issue with the Satellite web UI and long lists is that pagination, while it may provide a more responsive UI, makes interacting with a large number of items less efficient. Is that what you meant by your comment?
I have also responded to your discussion - 2092611.
Russell,
I wouldn't say it provides a more responsive UI, I would say it provides a more aesthetically pleasing UI (ie. looks nice, fade in/out effects etc.) but in providing this sacrifices usability for large numbers of items.
It results in a UI experience of:
scroll to bottom of list -> pause, wait for list to update -> scroll to bottom of list -> pause, wait for list to update
I will admit that I haven't spent much time on the 6.2 beta because we ran into virt-who problems with ESX which didn't appear to exist in 6.1. When I have time to troubleshoot I will provide more useful feedback on 6.2 specifically.
PixelDrift.NET Support,
Thanks for your feedback about the UI. I'll pass this on to the developers for discussion.
Please provide feedback about Satellite 6.2 as all constructive criticism is welcome. What problem did you encounter with virt-who? For Satellite 6.2 a new guide was written, named the Virtual Instances Guide [1]. It ought to walk you through the necessary configuration steps.
[1] https://access.redhat.com/documentation/en/red-hat-satellite/version-6.2-beta/virtual-instances-guide/
Russell,
We have configured virt-who fine in 6.0 and 6.1 (although it definitely has its idiosyncrasies), but with 6.2 beta 1 virt-who would return all ESX hosts correctly when a one shot was executed and output to a file, but would not correctly import them into Satellite.
Now 6.2 beta 2 is released we are starting a fresh build for testing, I will advise if have the same issue again.
PixelDrift.NET Support,
Thanks for that feedback. I'm keen to see if, with virt-who configured in conjunction with Satellite 6.2 Beta 2, your ESX hosts are successfully imported into Satellite.
Russell,
virt-who process was smoother this time, possibly due to the number of times we have re-installed/configured it. We successfully imported ~200 ESX content hosts without problem (with hostnames).
The UI issues still remain. A good example is if we view 'Content Hosts' it will show us 40 of the 200. We then have to scroll to the bottom of the page, wait for an additional 20 to appear.. then scroll to the bottom of the page.. wait for an additional 20. So to get a full list of our Content Hosts, we need to scroll down to the bottom of the page 12-13 times + update time.
I also find the following a bug in the 'select all' behaviour of the Content Host list.
1. Browse to the content hosts page
2. Click the select all checkbox next to the Name at the top of the column, this will result in the current 40 visible content hosts being marked as selected.
3. Scroll to the bottom of the list and 20 additional content hosts will be added.. but their checkboxes will not be selected. You now have 40 hosts selected and 20 not selected even though you have the 'select all' checkbox marked.
To truly select all you need to scroll to the bottom of page 12-13 times (as mentioned above) then click the 'select all' checkbox.
The issue with Puppet environment directories not being created when you create a Puppet environment through the UI still exists. So it won't create the directory structure when you create a Puppet environment and if you select to 'Import' Puppet environments it suggests removing the UI created environment because it doesn't exist on the filesystem (why doesn't it create it?).
I also found another issue with the default 'production' Puppet environment on a fresh install. By default the installation leaves 'production' and 'example_env' in the Puppet environments directory. If I select 'Import' from the UI, and check 'production', it will fail with an error saying that the environment 'production' already exists even though the UI suggests no Puppet environments exist.
These are all things I know how to work around due to having experience with Puppet.. but the lack of consistency in the UI behaviour is my major pain point.
PixelDrift.NET Support,
It's good to hear the virt-who implementation went well this time. Could you perhaps share some of the difficulties you have had in the past? With that information, perhaps I can help alleviate the risk by improving the documentation?
On the topic of the UI, now I understand the issue better. I'll pass that along and see if it can be addressed.
PixelDrift.NET Support,
I am currently discussing the UI behaviour with developers here at Red Hat. It seems that the "endless lists" behaviour applies to only some of the UI, though I haven't yet tested that myself. The "endless lists" behaviour is intended to keep the UI responsive, even when there is a large number of items available. This obviously presents a problem when you need to select several hundred items in a list.
If there is not already a Bugzilla ticket open to look into this behaviour, I will raise one and provide the link here.
Russell,
My contention is that the 'endless list' behaviour provides no functional or material benefit to the end user, it's purely aesthetic (ie. 'looks nice'). 'UI responsiveness' is largely subjective, and the increase in the amount of time spent returning the full list up front would be marginal (you already have the DB query response, it's purely rendering). In comparison, Satellite 5 returns full lists in manageable timeframes.
Thanks re: Bugzilla ticket
PixelDrift.NET Support,
I take your point regarding that UI responsiveness is subjective and that the time taken to return the full list in the UI may be outweighed by the benefit of having the full list. As soon as I have more information to share I'll include it here.
PixelDrift.NET Support,
I have created a BZ ticket [1] in the hope we can change the "Select all" behaviour in the Content Hosts view. Please tell me if you have encountered this problem in other areas of the Satellite web UI and if needed, I will raise BZ tickets for those also.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1353060
Hello, i am not sure if you have tested it and you have working example ? i have similar requirement ( for managing or locking CVs ), now how do i lock CV ... what i think is
currently i am working on RHEL7.2 CV, and once RHEL7.3 is released i want to lock my RHEL7.2 CV ...
1) i will create filter with "Include all rmps" and "include all errata upto today's date" ... 2) publish CV, and promote it to all life cycle envs ( now i want to know when i publish, do my contents are same as earlier version of CV ? do i also need to include package group ? ) 3) now i will start updating 7.3 CV till 7.4 releases .. 4) if any bug fix or erratas comes in, i will "include" that in 7.2 CV and publish.
Do you think all good ?
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.