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 <[email protected]> wrote: > > > 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
