[Rdo-list] [RDO-Manager] Rewriting instack scripts into python?

[Hugh O. Brock]

(moving this thread upstream where it belongs. It should probably in
fact be on openstack-dev, I'll leave that step to someone else however.)

For context: This is a debate over whether to have a common library for
combining instack deployment commands, and hoe the unified CLI plays
with that library. I have edited a bit for length, apologies if I have
distorted anyone's meaning.

On Thu, Apr 23, 2015 at 08:06:47AM +0200, Jaromir Coufal wrote:
> 
> 
> On 23/04/15 04:07, James Slagle wrote:
> >On Wed, Apr 22, 2015 at 01:20:25PM -0500, Jacob Liberman wrote:
> >>
> >>
> >>On 4/22/15 11:46 AM, Ben Nemec wrote:
> >>>>I am very concerned about this single call action which is doing all the
> >>>>>magic in the background but gives user zero flexibility. It will not
> >>>>>help neither educate users about the project.
> >>>Our job is not to educate the users about all the implementation details
> >>>of the deployment process.  Our job is to write a deployment tool that
> >>>simplifies that process to the point where an ordinary human can
> >>>actually complete it.  In theory you could implement the entire
> >>>deployment process in documentation without any code whatsoever, and in
> >>>fact upstream devtest tries to do exactly that:
> >>>http://docs.openstack.org/developer/tripleo-incubator/devtest_overcloud.html
> >>>
> >>>And let me tell you - as someone who has tried to follow those docs -
> >>>it's a horrible user experience.  Fortunately we have a tool in
> >>>instack-undercloud that rolls up those 100+ steps from devtest into
> >>>maybe a dozen or so steps that combine the logically related bits into
> >>>single commands.  Moving back toward the devtest style is heading in the
> >>>wrong direction IMNSHO.
> >>>
> >>>Does instack-undercloud/rdo-manager need to be more flexible?
> >>>Absolutely.  Does that mean we should throw out our existing code and
> >>>convert it to documentation?  I don't believe so.
> >>>
> >>
> >>Definitely get input from our field folks on this topic.
> >>
[snip]
> >>
> >>A GUI and unified deployment scripts are nice to have but are not
> >>replacements for complete CLIs + docs.
> >
> >I'm just replying to the thread, I'm not picking on your specific point :-).
> >Your feedback is really good and something that we need to keep in mind.
> >
> >However, this discussion isn't actually about POC vs production vs flexibility.
> >That's pretty much a strawman to the discussion given that the 'openstack
> >flavor' command is already there, and will always be there. No one is saying
> >you shouldn't use it, or we shouldn't document why and how we use flavors. Or
> >for that matter that any amount of customization via flavors wouldn't
> >eventually be possible.
> 
> But this is our primary focus - production ready flow. Which we should test
> as soon as we can and it is still not out there. So this discussion actually
> is about it. And also about production ready people's user experience.
> 
> 
> >There's also going to be a big difference between our end user documentation
> >that just gets you any repeatable process (what we have now), and advanced
> >workflows we might document for the field or consultants, or hide behind a "not
> >officially supported without RH consultants" banner.
> 
> End user documentation is not what we have now. What we have now is very
> narrow restricted flow for people to get started with 1 controller and 1
> compute -- which is just POC. With zero knowledge of what is happening in
> the background.
> 
> 
> >Moreso, the point is that:
> >
> >The shell script we currently have, the proposed Python code, and the proposed
> >documentation change all are 100% equivalent in terms of functionality and
> >flexiblity. The proposed documentation change doesn't even offer anything other
> >than replacing 1 command with 6, with no explanation of why or how you might
> >customize them (that's why I say it's worse).
> 
> First of all -- reason why it *has* to run 6 commands is how was written the
> instack deployment script which requires 3 flavors with very specific name
> for each role, despite the fact that one of the roles is not deployed.
> 
> If user follows regular way (when we get out of the deployment scripts), he
> would have to create *one* single flavor (2 commands) and in these commands
> is specifically listed what features are being registered with the flavor
> (ram, disk, vcpu). So it is not hidden from user.
> 
> This is very important. If you even want to improve this flow, we should
> suggest flavors to user and improve unified CLI.
> 
> >Here's really my main point I guess:
> >
> >If it takes 12 (eventually) CLI commands to create flavors, do we expect people
> >to *type* those into their shell? I hope not.
> >
> >Let's suppose we document it that way...in my experience the most likely thing
> >someone would do (especially if they're repeating the process) would be to
> >copy/paste those 12 commands out of the documentation, and write their own
> >shell script/deployment tool to execute them, or just copy/paste them
> >straight into their shell, while perhaps customizing them along the way.
> >
> >That would certainlly be a totally valid way to do it.
> 
> If user has homogeneous environment, he can have just one simple flavor. If
> he has heterogeneous or he wants to get more specific, he will take
> additional actions (create more flavors or deal with edeploy matching).
> 
> You are overstating - at the moment the problem with those 6 commands is
> really how the instack scripts are written. So that I could get us out of
> scripts and replace flavors script I had to create three flavors instead of
> one.
> 
> >So...why don't we just give them that shell script to start off with?
> >Better yet, let's write something we'd actually like to support long term (in
> >Python) and is just as flexible, perhaps taking json (or more likely YAML tbh)
> >as input, with a nice Python program to log stuff and offer --help's along the
> >way. Something that's actually supportable so we could ask: What input did you
> >provide to this tool and what was the output? VS. How did you customize these
> >12 commands, now go please run these other commands so we can figure out what
> >happened.
> 
> Yes, let's write something what we support longer term. Didn't we agree it
> is unified CLI? Didn't we agree we should support and improve it? Feeding
> another yaml file to create a single flavor? I disagree that this is better
> user experience.
> 
> 
> >I'm already seeing developers and external people saying that it's too much
> >as-is and that they're going to write custom tooling to help out. Why wouldn't
> >we just offer that already (especially when 90% of the code is already written
> >upstream), and still be able to keep all the flexibility, as long we actually
> >document how it works, and what commands you'd run to customize it?
> 
> Are these developers real world users in production environments? Ask field
> guys. The feedback you are getting is from people who are running these
> commands 20 times a day. Then it is valid point that it is too many steps
> for them. But this is *completely* different use case than production
> environments.
> 
> And we will not get out of the use case that people will write automation
> scripts. But instack will not help them with that because they will write
> very specific automation scripts on top of their production environments and
> they will use our CLI as the basis.
> 
> We should focus on production environments first and then simplify for POCs.
> Not vice-versa. And not improving the scripts.
> 
> -- Jarda

I'm sorry to say this Jarda but I think I am with James and Ben
here -- although this discussion is way too short on specifics, which I
think is part of the problem.

What I think Ben is proposing is a Python library that will encapsulate
the business logic that we need to do a deployment. If that's the case,
then I think that yes, that is exactly what we need. If I understand it
correctly the first version of this library will have some things
like flavor matching hard-coded, but we will add the ability to
configure those things as the library matures. I think this makes a ton
of sense.

I don't believe that having this library in any way precludes use of the
unified CLI, although it may change the way the CLI works -- certainly,
we would want the CLI to be able to take advantage of the business logic
in the library.

Finally, I completely support your desire that the individual operations
the manager is taking during deployment be well documented. However, I
don't think that need for documentation also means that the recommended
path for users should be to follow each individual step.

I think the only genuine disagreement here is over the usability of the
manager CLI -- the idea that "instack is never going to go away and the
unified CLI will never become the primary interface" is a red herring
and I think we should stop chasing it. Given that, if we're having a
debate about usability, let's please get some actual examples on this
thread and get some folks like Jacob to see for themselves what we're
talking about.

Thanks,
--Hugh

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Senior Engineering Manager, Cloud Engineering                   ==
== Tuskar: Elastic Scaling for OpenStack                           ==
== http://github.com/tuskar                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey