[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Modifying an example image for deployment from source



Ok, that makes sense. The database information that I'm giving it are not running as a service in openshift. I was passing those environment variables with the '-e' option instead of the '-p' option which is probably why it wasn't giving me any error. However it still was not setting those as an environment variable. Since those would both come back as blank that explains the error from the migrate command.

I edited the template and added parameters for the HOST and PORT and then updated the django database file to use the new environment variables, and it deployed properly. A few more tweaks and I should have it done. Thanks for your help!

On Thu, Jul 21, 2016 at 4:21 PM, Ben Parees <bparees redhat com> wrote:


On Thu, Jul 21, 2016 at 3:55 PM, Tony Saxon <tony saxon gmail com> wrote:
Thanks for the help. I'm very close to getting this working I believe. Now the build finishes and pushes to the internal repository. The deployment starts and the django app errors:

---> Migrating database ...
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
    utility.execute()
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/core/management/__init__.py", line 330, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/core/management/base.py", line 393, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/core/management/base.py", line 443, in execute
    self.check()
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/core/management/base.py", line 481, in check
    include_deployment_checks=include_deployment_checks,
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/core/checks/registry.py", line 72, in run_checks
    new_errors = check(app_configs=app_configs)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/core/checks/model_checks.py", line 28, in check_all_models
    errors.extend(model.check(**kwargs))
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/models/base.py", line 1205, in check
    errors.extend(cls._check_fields(**kwargs))
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/models/base.py", line 1282, in _check_fields
    errors.extend(field.check(**kwargs))
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/models/fields/__init__.py", line 934, in check
    errors = super(AutoField, self).check(**kwargs)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/models/fields/__init__.py", line 207, in check
    errors.extend(self._check_backend_specific_checks(**kwargs))
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/models/fields/__init__.py", line 306, in _check_backend_specific_checks
    return connection.validation.check_field(self, **kwargs)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/backends/mysql/validation.py", line 18, in check_field
    field_type = field.db_type(connection)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/models/fields/__init__.py", line 614, in db_type
    return connection.data_types[self.get_internal_type()] % data
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/__init__.py", line 36, in __getattr__
    return getattr(connections[DEFAULT_DB_ALIAS], item)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/utils/functional.py", line 60, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 196, in data_types
    if self.features.supports_microsecond_precision:
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/utils/functional.py", line 60, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/backends/mysql/features.py", line 52, in supports_microsecond_precision
    return self.connection.mysql_version >= (5, 6, 4) and Database.version_info >= (1, 2, 5)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/utils/functional.py", line 60, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 371, in mysql_version
    with self.temporary_connection():
  File "/opt/rh/python27/root/usr/lib64/python2.7/contextlib.py", line 17, in __enter__
    return self.gen.next()
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/backends/base/base.py", line 462, in temporary_connection
    cursor = self.cursor()
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/backends/base/base.py", line 162, in cursor
    cursor = self.make_debug_cursor(self._cursor())
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/backends/base/base.py", line 135, in _cursor
    self.ensure_connection()
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/backends/base/base.py", line 130, in ensure_connection
    self.connect()
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/backends/base/base.py", line 118, in connect
    conn_params = self.get_connection_params()
  File "/opt/app-root/src/.local/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 263, in get_connection_params
    if settings_dict['HOST'].startswith('/'):
AttributeError: 'NoneType' object has no attribute 'startswith'

So it seems to be having issues with the initial database migration. The command that I'm using to deploy the application is:

oc new-app openshift/templates/django.json -p SOURCE_REPOSITORY_URL=http://gitlab.tonysaxon.com/tsaxon/pmweb.git,DATABASE_ENGINE=mysql,DATABASE_NAME=pmweb,DATABASE_USER=pmweb,DATABASE_PASSWORD=pmweb,DATABASE_SERVICE_NAME=mysql,MYSQL_SERVICE_HOST=mariadb1.libvirt,MYSQL_SERVICE_PORT=3306

I pulled the build image from the internal repository with docker and started a container to get a bash shell in it. I then manually set all the environment variables that I passed along with the new-app command. After those were set, I was able to do the following in the /opt/app-root/src directory:

bash-4.2$ ./manage.py makemigrations
System check identified some issues:

​this is the logic in the python image that runs migrations:
https://github.com/sclorg/s2i-python-container/blob/master/2.7/s2i/bin/run#L45-L53

do you see that output in your pod?  note that it is not identical to the command you are running.

You may need to provide a custom run script or a pre-deployment hook to run the migrations.

You can also run "oc describe pod" on the app pod to confirm all the env variables are present...you should not need to be passing "MYSQL_SERVICE_XXXXX" as those env variables are automatically created if you have a service named mysql.  In fact new-app should be giving you an error since you are specifying parameter keys that do not much any parameter defined in the template, unless you've modified the template.

 

WARNINGS:
stats.HostPerfStatus.date: (fields.W161) Fixed default value provided.
        HINT: It seems you set a fixed date / time / datetime value as default for this field. This may not be what you want. If you want to have the current date as default, use `django.utils.timezone.now`
Migrations for 'stats':
  0002_auto_20160721_1928.py:
    - Alter field date on hostperfstatus
bash-4.2$ ./manage.py migrate
System check identified some issues:

WARNINGS:
stats.HostPerfStatus.date: (fields.W161) Fixed default value provided.
        HINT: It seems you set a fixed date / time / datetime value as default for this field. This may not be what you want. If you want to have the current date as default, use `django.utils.timezone.now`
Operations to perform:
  Synchronize unmigrated apps: staticfiles, messages
  Apply all migrations: admin, contenttypes, stats, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
  Installing custom SQL...
Running migrations:
  Rendering model states... DONE
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying sessions.0001_initial... OK
  Applying stats.0001_initial... OK
  Applying stats.0002_auto_20160721_1928... OK
bash-4.2$ ./manage.py runserver
Performing system checks...

System check identified some issues:

WARNINGS:
stats.HostPerfStatus.date: (fields.W161) Fixed default value provided.
        HINT: It seems you set a fixed date / time / datetime value as default for this field. This may not be what you want. If you want to have the current date as default, use `django.utils.timezone.now`

System check identified 1 issue (0 silenced).
July 21, 2016 - 19:29:08
Django version 1.8.4, using settings 'pm_web.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.


What is different about the process that openshift uses when it deploys from the imagestream?

On Thu, Jul 21, 2016 at 9:17 AM, Ben Parees <bparees redhat com> wrote:


On Thu, Jul 21, 2016 at 9:15 AM, Tony Saxon <tony saxon gmail com> wrote:
Thanks. Looks like that puts me back on the right track. The django:3.5 was a mistype on my part. I was referring to the python:3.5 image that was referred to in the build strategy in https://github.com/openshift/django-ex/blob/master/openshift/templates/django.json.

Now it's building no errors and the pod is deploying. 'oc status' shows that it's deployed and 'oc get pods' shows the deploy pod ready and running but the application pod is running but '0/1' ready. When I look at the logs for both the deploy pod and the application pod, I don't see any errors, but the application pod definitely keeps restarting.

​that template defines a readiness check for the application pod:
https://github.com/openshift/django-ex/blob/master/openshift/templates/django.json#L173-L188

is your application still serving traffic at the "/" path on port 8080?  If not, it's going to fail the readiness check.

 

logs from application pod:

Synchronizing apps without migrations:
  Creating tables...
    Creating table stats_fagroup
    Creating table stats_metrics
    Creating table stats_host
    Creating table stats_hostperfstatus
    Creating table stats_statistics
    Creating table stats_defaultthreshold
    Creating table stats_threshold
    Creating table stats_pmsignoff
    Running deferred SQL...
  Installing custom SQL...
Running migrations:
  Rendering model states... DONE
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
System check identified some issues:

WARNINGS:
stats.HostPerfStatus.date: (fields.W161) Fixed default value provided.
        HINT: It seems you set a fixed date / time / datetime value as default for this field. This may not be what you want. If you want to have the current date as default, use `django.utils.timezone.now`
  Applying sessions.0001_initial... OK
---> Serving application with 'manage.py runserver' ...
WARNING: this is NOT a recommended way to run you application in production!
Consider using gunicorn or some other production web server.

Logs from the deploy pod:

[root oso-master pmweb]# oc logs -f pmweb-1-deploy
I0721 13:08:55.477158       1 deployer.go:200] Deploying test/pmweb-1 for the first time (replicas: 1)
I0721 13:08:55.478057       1 recreate.go:126] Scaling test/pmweb-1 to 1 before performing acceptance check
I0721 13:08:57.518253       1 recreate.go:131] Performing acceptance check of test/pmweb-1
I0721 13:08:57.518333       1 lifecycle.go:445] Waiting 600 seconds for pods owned by deployment "test/pmweb-1" to become ready (checking every 1 seconds; 0 pods previously accepted)

Any idea if there's another place to look for logs for what's going wrong?


 


On Wed, Jul 20, 2016 at 8:45 PM, Ben Parees <bparees redhat com> wrote:


On Wed, Jul 20, 2016 at 7:53 PM, Tony Saxon <tony saxon gmail com> wrote:
I'm trying to take an existing Django application that we have running on a system and make it so that I can deploy into a lab origin environment that I have set up. I started by going through the example Django application: https://github.com/openshift/django-ex

I didn't have any major problems with deploying that. I then tried to adapt our existing application based on the example; I added the requirements text file made some small label modifications to the template file and attempted to deploy our application from our private git repository. It is bombing out while building the application due to the fact that it is unable to install one of the items listed in the requirements.txt file. I built another docker container and narrowed it down to needing the libffi-devel package.

​i'm not familiar with the package, but if you think it's a common package people will need, consider opening an issue against the python repo requesting it be added to the python s2i builder image:
https://github.com/sclorg/s2i-python-container
 

After pouring over the documentation, I'm having trouble figuring out the proper way to make a source image based on the openshift/django:3.5 image that has the included package. I've gone over the documentation for building s2i images and such, but don't quite grasp the procedure for building something generic that does not have any application source code included and pushing that to an internal repository to be included in a configuration file and be deployed with the new-app command. Any help would be greatly appreciated, thanks.

Not sure what "openshift/django:3.5" is, but assuming you mean the python image, what you need to do is write a Dockerfile like:

FROM centos/python-35-centos7
USER root
RUN yum install -y libffi-devel​
USER 1001  # must set user back to a non-root user

then docker build that dockerfile (you can't build it on openshift online since we don't allow Docker builds, but if you have your own cluster, you can set up a docker type build to build+push that image to your openshift registry).

Assuming you built it locally, then you'll want to push it to your openshift cluster registry (or dockerhub or some other registry) and then you can reference it from an s2i build.

If you need instructions for how to "docker login" to the openshift registry:
https://docs.openshift.org/latest/install_config/install/docker_registry.html#access-logging-in-to-the-registry



 

_______________________________________________
users mailing list
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users




--
Ben Parees | OpenShift





--
Ben Parees | OpenShift





--
Ben Parees | OpenShift



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]