<div dir="ltr"><span style="font-size:12.8px">Thanks Michael, that's useful information.  </span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The primary thing I'd wanted to take a crack at is a useful method for dumping repos into an ASCII multi-column table from one pulp server and feed that ASCII data into a wrapper script that uses each line to re-create a repo.  </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">From lurking on the list for a while, and from moving from host to host myself, I've often wanted to be able to quickly populate a fresh Pulp installation with repo defs without messing with mongo or doing an import/export operation of any sort.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">For the repo defs file I was planning on splitting the information for each repo into the following columns, which will likely be stolen from the -vv output of pulp-admin rpm repo list --detail:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">{repo_id}  {feed_url}  {relative_url}  {serve_http}  {feed_key_needed?}  {retain_old_count}  ...</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">...Then I'd just feed each repo def into a wrapper script for pulp-admin rpm repo create.  </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">This doesn't preserve repo path permissions or anything, but for that sort of use case I'd be more likely to use my previously figured out backup / restore method to transfer the repos.  </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Then again this might be a good opportunity for me to just give in and continue learning Python and start messing with Requests.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Once we're on django-rest and things look like they will be stable for a couple years I'll probably put in more effort on a DB-agnostic server-to-server import/export method for populating Pulp servers that captures things like path permissions and roles and such, which appears to be a use case that others also might find to be useful.</div><div class="gmail-yj6qo gmail-ajU" style="margin:2px 0px 0px;font-size:12.8px"><div id="gmail-:13b" class="gmail-ajR" tabindex="0"><img class="gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif" style="opacity: 0.3;"></div></div><span class="gmail-HOEnZb gmail-adL" style="font-size:12.8px"><font color="#888888"><div><br></div><div> - Kodiak</div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 16, 2017 at 4:35 PM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The REST API will be completely different. It will be auto-generated using django-rest-framework, which brings a lot of advantages. It should be very consistent, compliant, well-documented, and we might even be able to auto-generate client libraries. That said, the core behaviors and concepts will be largely the same as Pulp 2, so migrating a client from 2 to 3 will mostly just involve using different URLs and different-but-similar data structures.<div><br></div><div>As for pulp-admin, we're not sure yet how easy it will be to make it work with Pulp 3. But I think we're getting close to a point where we'll be able to give that a try and see if it floats. This much is certain: there is a broad desire to replace pulp-admin completely. Things like pretty-printing, error handling, inconsistent exit codes, and the sheer amount of vertical space it uses to render data are some of the most frequently-observed rough edges. It's not all bad, but we could do better. It's just a matter of finding the time to get it prioritized. If it looks like making pulp-admin compatible with Pulp 3 will be a lot of work, we're likely to redirect that effort into a new client that is more likable.</div><div><br></div><div>So given those choices, if you're comfortable scripting against the API directly, that's what I recommend. Although you can get a lot done with just a little bit of pulp-admin, so even if you have to re-do that integration in the future, it may be worth it for the low up-front cost.</div><div><br></div><div>If you want to talk in more detail about what you'd like to automate, we could certainly help weigh the options.</div><div><br></div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Feb 16, 2017 at 4:09 PM, Kodiak Firesmith <span dir="ltr"><<a href="mailto:kfiresmith@gmail.com" target="_blank">kfiresmith@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi folks,<div>Do we know yet how much (if at all) there will be backward compatibility in the command suite and/or REST API for Pulp 3?</div><div><br></div><div>I'm considering writing more extensive wrapper scripts around pulp-admin, but didn't want to blow too much effort on it if they would become useless w/ Pulp 3 arrives.</div><div><br></div><div>Thanks!</div><span class="m_-7495917137307178588HOEnZb"><font color="#888888"><div> - Kodiak</div></font></span></div>
<br></div></div>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>