Selecione um idioma
We recently re-initiated the Red Hat Satellite Ask Me Anything (AMA) events. For anyone not familiar, the Satellite AMAs are an ask me anything-style event where we invite Red Hat customers to bring all of their questions about Satellite, drop them in the chat, and members of the Satellite product team will answer as many of them live as we can during the AMA and we then follow up with a blog post detailing the questions and answers.
The ground rules of the AMA are:
In the interest of making everyone feel like they can truly ask any question, the Satellite AMA sessions are not recorded.
The Satellite AMA is not the appropriate place to ask questions about specific support cases or specific sales issues. While we may be able to give generic feedback about certain areas we cannot use this time to troubleshoot or dig into logs. For your support cases please continue to work with Red Hat support, and for any sales issues please work with your Red Hat or Partner sales rep.
The AMA is presented using Blue Jeans Prime. All questions are asked via the Q&A panel which allows other attendees to vote on questions that are asked. Questions are read by an event moderator based on the popularity of the questions and answered live and in real time.
As we kicked off the March Satellite AMA we pointed out a few important items happening in the Satellite area:
Red Hat Satellite 5.7 and earlier end of life (EOL) was on January 31, 2019. Content for these versions stopped on March 14th as part of the Red Hat Network (RHN) shutdown. To continue to receive content on your Satellite environment you need to upgrade to Satellite 5.8, if you have not yet done so.
Satellite 5.8 EOL is scheduled for May 31, 2020. At that point all Satellite 5 versions will be EOL and you will need to transition to Satellite 6.
Satellite 6.2 will go EOL in May of 2019. Satellite operates on a N-2 support model, so once the next version of Satellite releases Satellite 6.2 will go end of life.
More Satellite customers are on Satellite 6.4 than any other version.
For more information about Satellite check out the latest version of the Satellite Frequently Asked Questions.
Here are questions and answers (lightly edited for readability, grammar, spelling,etc.) from the March 11, 2019 Red Hat Satellite Ask Me Anything.
Event date: Monday, 11 March, 2019 - 09:00 AM to 10:00 AM
Q: Hows the future of Puppet vs Ansible looking within Satellite?
A: Satellite 6.4 introduced some Ansible capabilities that allow you to deploy Ansible roles and perform remote execution. For the Satellite 6 lifecycle we plan to continue supporting both Ansible and Puppet. Red Hat is trying to keep Satellite fairly current on the Puppet version (Puppet 5 currently).
Q: Any update on a more streamlined / user-friendly way to create custom errata?
A: Right now we don't have a tool in Satellite to create custom errata. This is on the backlog.
Q: Will Satellite someday support deploying kpatch?
A: This is a two-part answer:
Part 1 of 2: Will we support deploying kpatch? Yes. It is available as an RPM. Today kpatch packages are delivered on a case by case basis. As a customer you can take that RPM, upload it as a custom product, assign it to a CV and publish promote. You can do that today.
Part 2 of 2: Will Red Hat treat kpatch as a 1st class citizen? Will Red Hat ship kpatch RPMs in repositories hosted on the CDN like all other repositories? That’s to be determined (TBD) and outside the scope of the Satellite team. If Red Hat makes kpatch a real thing it should work inside of Satellite like any other repo.
Q: Is there a place to upvote existing Request For Enhancements (RFE)?
A: Best thing to do is open a support ticket and get your name attached to the RFE. This helps to impact (and in other words upvote) the RFE. We prefix "RFE" for feature improvement bugs.
Q: In what version are we likely see the migration from MongoDB to PostgreSQL?
A: Migration to Postgres is a big change and will take several releases for us to make this as seamless as possible. We've been doing smaller changes over the last several and next several releases to work towards this goal. When this does happen this should be an automatic upgrade and not a migration event. We cannot commit to a specific release at this time.
Q: For disconnected environments, the Intra Satellite Sync feature represents an ingest path that could be leveraged for all repository types. Should we be looking at Artifactory or Nexus Repository Manager for this, or will Satellite 6 handle this role?
A:Today for content import/export we are fairly complete with RPM content, but Satellite supports other content types. For the other content types the story isn't as strong and we are looking to address this in future releases.
In the near term the story will be focused on containers and RPMs.
Q: One of the most important functionalities of Satellite should be subscription management. However, aside from auto attach it's very limited and auto-attach often causes issues for us. For example, by taking subscriptions away from an activation key. What will Red Hat do to improve this?
A: In Subscription Management, take a look at Subscription Management for the former RHN user, part 9. As a general rule the activation keys if setup like mentioned in this article should work. We've made several changes over the last few releases, and we'll introduce support for System Purpose in the next Satellite release which will eventually work with other RHEL versions.
Follow up Q: What I actually meant is: how can we disable auto-attach for a certain contract. Some background in this RFE. And, aside from that, I want to be able to tell the Satellite: assign this type of subscription to this content-host and replace it when it expires. Right now I have to use the API and Ansible for that.
We do use automation to assign the subscriptions, but the problem is the subscriptions from the activation key are already in use once auto attach runs even when we have other subscriptions available. That's why I opened that RFE... This one is a big "pain" for me.
A: There are three ways to handle this:
1 - activation keys
2 - future dated subscriptions
3 - automation to attach subscriptions if you have complex rules
Q: Any thoughts on containerizing Satellite 6's components (Pulp, Candlepin, etc.) in a far future release?
A: Eventually, yes. It creates some business and deployment challenges. We want to do this, but not as a monolithic container. Breaking apart Satellite's components is being considered for scale and HA purposes and this may ultimately help with our containerization plans. Lots to be determined.
Q: If synchronizations have run on multiple products/repos, how can I determine if actual content updates have been applied since a given date? i.e. Do I have updates since my last export?
A:Log parsing is probably the best way. Satellite does dedupe when you overlap exports
Q: Is there support for maintaining a private CDN ( export content version ), or should an export be treated as a transient format for moving content to another Satellite where the content will be ingested into its DML?
A: Exports from Satellite are generally transient unless you are doing a full export. A full export is a full representation of the CDN that the Satellite has exported. Otherwise the export is incremental.
Q: Can I think of Satellite tasks as transactions, which will roll back intermediate actions if the entire task fails (or is canceled)?
A: Satellite tasks are not transactions - They are more like a fan out model.
Q: What sort of new features do you see being added to Satellite over the next year / what are customers asking for?
A: We’ll answer the what customers are asking for question, but we can’t publically answer the roadmap portion of the questions. Looking at the RFEs (which are based on customer demand - please enter RFEs by opening a support ticket) the most common asks are:
- Improvements to scale/resiliency/HA
- Improvements to content management
To help address issues and keep Satellite up to date we have moved to a six month cadence.
Q: The RHS6.4 API pales in comparison to the Tower API. Can we expect improvements here? Since the apidoc is so thin wrt data model, is there another documentation source for this? Do I need to create my own by saving the responses to all "list object" API calls?
A: The API doc does a good job of telling you how to use the API calls, but we don't document the responses since they change over time. Best to raise this as an RFE so we can best figure out how to deliver this.
Q: The hammer CLI help does not indicate required options or which options can or cannot be used together. Is trial & error the only way to find this info?
A: We should be able to improve this experience. We need to file an RFE to make this better.
Q: To my knowledge, Satellite does not provide delta RPMs to clients. If correct, are there plans to add this functionality?
A: Today Satellite does not deliver delta RPMs. We are planning to add this functionality in the future. A lot of 3rd party repos ship delta RPMs and we want to be able to support those. Red Hat does not ship delta RPMs today, but if they do we plan to support those.
Q: Related to delta RPMs, are we likely to see Zchunk support being added, e.g. to support the Fedora 30 release?
A: Yes, as part of an updated Pulp version. Release unknown at this time.
Q: In the GUI, Content | Red Hat Repositories, the product search parameter does not filter the Enabled Repositories on the right pane - why? (dropdown either Enabled or Both)
A: Part of the UI redesign was to enable the easy selection of repositories. Once enabled do you really need to search for them was the thought process. If this is causing you issues please open a RFE.
Join us for April's AMA
The April Red Hat Satellite Ask Me Anything is scheduled for Wednesday, April 24th 2019 at 11am EDT (GMT -5). Please join us and bring any questions about Satellite that you might have. We look forward to hearing from you!