Odo: Detect that component has not been build yet

[kadel]

[kind/Feature]

In the situation when a component is newly created and it doesn't have any source yet, supervisorD is restarting application over and over again. This creates a lot of ugly error messages.

It doesn't make sense to keep trying to start it if there is no application has been build yet.

odo should detect that the component has not been deployed, and prevent supevisorD from trying to restart it, until there is something.

[jorgemoralespou]

This is one of the things that our own supervisor process, instead of a generic one, could potentially manage easily. We need to keep in mind that sooner or later, we'll need our own supervisor with a proper API to manage all these specific lifecycle events.

[kadel]

It would be good to fix this sooner than we start thinking about own supervisor process.

The only thing that we need to figure out here is how to detect that it nothing has been built, that should be fairly easy, we can just touch some file after successful assemble invocation and then only try to start component if files exist.

This is the first quick solution that I can think of. I'm sure that there is even more elegant one ;-)

[jorgemoralespou]

AFAIK this is a config in the supervisord that should be changed on first push.
We can set on the image autostart as false, and then the command that is run when we push code can change it (not sure if a reload is needed, though.

[anmolbabu]

So, this involves

1. setting autostart=false in the section https://github.com/redhat-developer/odo-supervisord-image/blob/master/supervisor.conf#L1-L8
2. setting autostart=true via an sed command in supervisor.conf before https://github.com/redhat-developer/odo-supervisord-image/blob/master/assemble-and-restart#L83 which is triggered on first push

[kadel]

/remove-priority medium
/priority high

[dharmit]

I'm assuming that this issue is affecting the cases where SourceType is local and the directory is most likely empty. It could also affect binary type when user does something like odo create java --binary . and do odo push - and, in fact, odo push is happy to push this without errors. :wink:

Besides the popular opinion of configuring supervisorD, does it make sense to add some checks to odo itself? I can think of two places where we can add some checks:

• odo create could have a function isValidGitRepo that would check for the existence of a .git/ directory. If it's not a valid git directory, odo would raise a warning that component doesn't seem to be a valid git repo. It could also go a step further and ask the user if they're sure to create a component in such a case.

  This might seem annoying at first but it will also lead to user developing a habit of cloning the git repo before doing odo create.

• odo push could have a function that would interrupt the user and ask for confirmation if

  1. it's not a valid git repo
  2. there's no server.js file (for nodejs component). We could make odo smart to check this for supported components.

  If user says that they know what they are doing, then we go ahead and create the component for them on OpenShift cluster.

This approach adds some checks which would slow down the odo create and odo push for valid components which we have worked so hard to make as fast as we could. So I'm not suggesting that we go with this approach but I'm trying to gather feedback if it's plausible to do this.

But if we go with this approach, we would be able to give quick feedback to the user "Hey you're missing things that make a component valid and if you choose to push this anyway, things might not work" instead of they coming back to us (technical support) with "Why is this thing not working?"

@kadel @jorgemoralespou @girishramnani wdyt?

[jorgemoralespou]

@dharmit A git repo is not mandatory and in many cases will not be there. The essence of inner-loop is that is the workflow before you check into git, so you might not have even initialized the directory as a git repository, so not an option IMHO.

What we need to make sure is that the supervisorD starts up with stopped runtime, to prevent an overflow of error messages trying to run a non existing application, binary or source code, and that push/sync will start it up, by any possible mechanism like changing the supervisorD configuration.

My initial thought was on a dedicated supervisor that could understand this fact, but to make things easier, maybe just having the supervisor calling a wrapper script that will do this detection should do the trick for now.

The component now, will most likely not be created empty, as it used to happen before the new workflow, so this issue's relevance has decreased, as odo create will not create the component anymore in the cluster, and push will be pushing the component creation and the code itself. Still, there's some chance due to missconfiguration that should be prevented/checked, but that's it.

[kadel]

The component now, will most likely not be created empty, as it used to happen before the new workflow, so this issue's relevance has decreased, as odo create will not create the component anymore in the cluster, and push will be pushing the component creation and the code itself. Still, there's some chance due to missconfiguration that should be prevented/checked, but that's it.

Yes, this is not a big problem as it used to be, but It still creates some problems. First-time push can still take a long time (copying files, and downloading all dependencies from maven or npm). For this time SupervisorD is constantly restarting the run script and sometimes it can sometimes lead to unexpected situations like https://github.com/openshift/odo/issues/2224#issuecomment-539543375

I think that without big re-architecturing there is probably only one way how to achieve this.

• disable autostart in a default supervisor.conf
• when the main container starts, before starting supervisord, copy the supervisor.conf (from /opt/odo/conf/supervisor.conf) into the directory that is on volume, for example ${ODO_S2I_WORKING_DIR}/odo/conf (ODO_S2I_WORKING_DIR is usually /opt/app-root)
• use ${ODO_S2I_WORKING_DIR}/odo/conf/supervisor.conf as config for supervisord (instead of current /opt/odo/conf/supervisor.conf
• After the sucessfull assemble execution (inside assemble-and-restart script) modify ${ODO_S2I_WORKING_DIR}/odo/conf/supervisor.conf and set autostart=true

The second step is necessary as the /opt/odo/ directory is on emptyDir volume. Each time the container is started the directory is empty and it gets populated by default files from odo-init-image