Add blog post about deprecating nodes #30
Conversation
daviddavis
force-pushed
the
gh-pages
branch
2 times, most recently
from
e1035d3
to
71350f3
Compare
| --- | ||
|
|
||
| Nodes were introduced in Pulp in 2.1.0 and provided a way to keep multiple Pulp | ||
| servers in sync. However, maintaining Nodes in Pulp meant having to maintain a |
| servers in sync. However, maintaining Nodes in Pulp meant having to maintain a | ||
| separate codebase and given that much of the functionality of Nodes can be | ||
| acheived by running Pulp straight out of the box, we've decided to remove Nodes | ||
| in our next major release of Pulp 3.0. With Pulp 2.11, Nodes will be officially |
There was a problem hiding this comment.
Nodes needs to be deprecated with 2.12 since 2.11 is already at beta and has been branched. This means that 2.11-dev is already 2.11.1.
| separate codebase and given that much of the functionality of Nodes can be | ||
| acheived by running Pulp straight out of the box, we've decided to remove Nodes | ||
| in our next major release of Pulp 3.0. With Pulp 2.11, Nodes will be officially | ||
| deprecated. |
There was a problem hiding this comment.
I think there is more to be said than the maintenance effort. What about this for the first paragraph which includes the above comments:
Nodes were introduced in Pulp in 2.1.0 and provided a way to keep multiple Pulp servers synchronized. However, Nodes uses separate codepaths from the normal sync+publish codepaths which creates at a few problems:
- Nodes is less tested than sync+publish even though it provides a similar feature set. This greatly reduces the user to user usage and testing benefit.
- Fixing bugs in sync+publish does not fix bugs in Nodes and vice-versa
- Nodes has a good amount of bugs already reported that are still unfixed
Given that much of the functionality of Nodes can be achieved by running Pulp with sync+publish workflow, the core team is removing Nodes in the next major release of Pulp 3.0. With Pulp 2.12, Nodes will be officially deprecated.
| servers without using Nodes and how tools like cron and systemd can be used to | ||
| keep content updated across Pulp servers. I am going to illustrate a two-server | ||
| example in which I'll call one Pulp server the parent and the other the child. | ||
| However, this distinction is arbitrary as both servers are configured the same |
There was a problem hiding this comment.
s/configured the same way/each a standard Pulp server installation without any Nodes packages installed/.
| keep content updated across Pulp servers. I am going to illustrate a two-server | ||
| example in which I'll call one Pulp server the parent and the other the child. | ||
| However, this distinction is arbitrary as both servers are configured the same | ||
| way. The child Pulp server is simply the one we want to mirror content to. |
There was a problem hiding this comment.
s/simply/called that because it is/
| --------------------------------- | ||
|
|
||
| Suppose I have an rpm repo called 'centos-base' on the parent Pulp server. | ||
| First I would want to publish that repository to make it available for the |
| This repository should then be available via http or https. You can check its | ||
| relative url via `pulp-admin rpm repo list --repo-id centos-base --details`. In | ||
| my case, it's at "https://example.com/pulp/repos/centos-base". Now on the child | ||
| node, I can simply create and sync the repository: |
| pulp-admin rpm repo create --repo-id centos-base --feed https://example.com/pulp/repos/centos-base | ||
| pulp-admin rpm repo sync run --repo-id centos-base | ||
|
|
||
| Now the centos-base repository from my parent Pulp server has been mirrored |
There was a problem hiding this comment.
s/centos-base/'centos-base'/
s/my/the/
| based on your needs. For example, if we want to check for new content for our | ||
| 'centos-base' repository hourly, we could create a crontab entry: | ||
|
|
||
| @hourly pulp-admin rpm repo sync run --repo-id centos-base |
There was a problem hiding this comment.
What about adding an example to cause cron to repeat publish from the parent?
Also one gotcha with this approach is that pulp-admin cannot take the pulp server url to talk to as a parameter (iirc). We could recommend that the parent server and child both have pulp-admin configured to talk to localhost and that the parent jobs live in cron on the parent and the child jobs on the child. I'm not sure how to incorporate this content, but it's something I wanted to mention.
|
FYI, this repo is not monitored by pulp.plan.io so you'll have to manually move the issue to MODIFIED after it is merged and you won't be able to associate the issue. That is all normal (for blog posts) but I wanted to relay the info. |
There was a problem hiding this comment.
Thank you for putting this together! I really like it. I left some comments requested. I would also like to see an ack from @mhrivnak with a suggestion on the date this should be published and if he has any requested changes. Note that the date in the file description defines the date that Jekyll thinks the post was published on.
Thanks for putting this together! I can take another look to approve the changes when the next version is pushed.
daviddavis
force-pushed
the
gh-pages
branch
2 times, most recently
from
a51bd4a
to
0363cea
Compare
|
|
||
| Nodes were introduced in Pulp in 2.1.0 and provided a way to keep multiple Pulp | ||
| servers synchronized. However, Nodes uses separate codepaths from the normal | ||
| sync+publish codepaths which creates at a few problems: |
| servers synchronized. However, Nodes uses separate codepaths from the normal | ||
| sync+publish codepaths which creates at a few problems: | ||
|
|
||
| * Nodes is less tested than sync+publish even though it provides a similar |
There was a problem hiding this comment.
I know I wrote this sentence but... s/even though it provides a similar feature set//
| keep content updated across Pulp servers. I am going to illustrate a two-server | ||
| example in which I'll call one Pulp server the parent and the other the child. | ||
| However, this distinction is arbitrary as both servers are each a standard Pulp | ||
| server installation without any Nodes packages installed. The child Pulp server |
|
|
||
| By using cron or a systemd timer, we can keep content on the child Pulp server | ||
| up-to-date automatically. In order to keep the content synchronized, on the | ||
| parent, you'll need to call publish the repository while on the child, sync |
|
|
||
| Nodes were introduced in Pulp in 2.1.0 and provided a way to keep multiple Pulp | ||
| servers synchronized. However, Nodes uses separate codepaths from the normal | ||
| sync+publish codepaths which creates at a few problems: |
| servers without using Nodes and how tools like cron and systemd can be used to | ||
| keep content updated across Pulp servers. I am going to illustrate a two-server | ||
| example in which I'll call one Pulp server the parent and the other the child. | ||
| However, this distinction is arbitrary as both servers are each a standard Pulp |
There was a problem hiding this comment.
s/both servers are each a/each server is a/
| pulp-admin rpm repo publish run --repo-id centos-base | ||
|
|
||
| This repository should then be available via http or https. You can check its | ||
| relative url via `pulp-admin rpm repo list --repo-id centos-base --details`. In |
There was a problem hiding this comment.
As a small detail: you'll see a relative path via this command, not a URL. I think it's helpful for us to be careful and consistent about calling something a URL vs. a path, to avoid ambiguity.
|
|
||
| By using cron or a systemd timer, we can keep content on the child Pulp server | ||
| up-to-date automatically. In order to keep the content synchronized, on the | ||
| parent, you'll need to call publish the repository while on the child, sync |
There was a problem hiding this comment.
I think in this sentence, it is a bit difficult to follow what it is saying about parent vs. child. I would eliminate most of what it says, and instead say those things below with the description of each cron entry.
"To make content available, you will need to call publish on the parent repository. This can be done automatically after each sync via the "auto-publish" feature, or periodically as shown here:"
|
|
||
| @hourly pulp-admin rpm repo sync run --repo-id centos-base | ||
|
|
||
| If you use cron to run pulp-admin commands, we also recommend setting the Pulp |
There was a problem hiding this comment.
Why? It would be valuable to explain this.
|
|
||
| @hourly pulp-admin rpm repo sync run --repo-id centos-base | ||
|
|
||
| If you use cron to run pulp-admin commands, we also recommend setting the Pulp |
There was a problem hiding this comment.
Somehow can this be reworder for clarity. What I had meant was that pulp-admin commands destined for the child should be configured in cron on the child, and pulp-admin commands destined for the parent should be configured in cron on the parent. I'm not sure how to clarify this.
There was a problem hiding this comment.
I see. How about something like:
It's worth noting that you'll want to ensure that pulp-admin is pointing to the correct server. One option would be to edit the crontab for each server and have pulp-admin configured to point to Pulp via localhost.
|
|
||
| Given that much of the functionality of Nodes can be achieved by running Pulp | ||
| with sync+publish workflow, the core team is removing Nodes in the next major | ||
| release of Pulp 3.0. With Pulp 2.12, Nodes will be officially deprecated. |
|
Regarding my comment on login, was that addressed in any way? I haven't re-read the whole thing, but I don't initially see anything about login. |
|
@mhrivnak apologies. I totally overlooked your comment. I added some info about login to the end of the blog post in the automatic sync section. Let me know if I need to tweak it. Thanks. |
|
@daviddavis If this gets merged on Dec 8th please git mv the date once again. Once @mhrivnak signs off on it feel free to merge. Thanks! |
ref #2460
https://pulp.plan.io/issues/2460