On Thu, Jul 21, 2016 at 3:55 PM, Tony Saxon <[email protected]> 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 see an example of that for our Rails example app here:
https://github.com/openshift/rails-ex/blob/master/openshift/templates/rails-postgresql.json#L134-L141
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 <[email protected]> wrote:
>
>>
>>
>> On Thu, Jul 21, 2016 at 9:15 AM, Tony Saxon <[email protected]> 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 <[email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jul 20, 2016 at 7:53 PM, Tony Saxon <[email protected]>
>>>> 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
>>>>> [email protected]
>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ben Parees | OpenShift
>>>>
>>>>
>>>
>>
>>
>> --
>> Ben Parees | OpenShift
>>
>>
>
--
Ben Parees | OpenShift
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
