[Container-tools] debugging atomicapp examples & the adb

Jason Brooks jbrooks at redhat.com
Thu Aug 6 05:13:13 UTC 2015


Look, kube 1.0 is coming to centos core:

https://git.centos.org/summary/?r=rpms/kubernetes

----- Original Message -----
> From: "Lalatendu Mohanty" <lmohanty at redhat.com>
> To: "Jason Brooks" <jbrooks at redhat.com>, "Aaron Weitekamp" <aweiteka at redhat.com>
> Cc: "container-tools" <Container-tools at redhat.com>
> Sent: Wednesday, August 5, 2015 8:59:09 PM
> Subject: Re: [Container-tools] debugging atomicapp examples & the adb
> 
> On 08/06/2015 02:31 AM, Jason Brooks wrote:
> >
> > ----- Original Message -----
> >> From: "Aaron Weitekamp" <aweiteka at redhat.com>
> >> To: "Jason Brooks" <jbrooks at redhat.com>, "Lalatendu Mohanty"
> >> <lmohanty at redhat.com>
> >> Cc: "container-tools" <Container-tools at redhat.com>
> >> Sent: Wednesday, August 5, 2015 1:55:30 PM
> >> Subject: Re: [Container-tools] debugging atomicapp examples & the adb
> >>
> >> Jason, I'm able to reproduce the issue. I suspect we've got a kubectl
> >> version mismatch, v.9 vs v1. I upgraded to kube to v0.17 with similar (but
> >> different) error. I was able to run the service on OpenShift using Kube
> >> v1,
> >> for what it's worth.
> >>
> >> Does anyone know when we get kube v1 in centos? Lala?
> > It's available in the cbs here:
> >
> > http://cbs.centos.org/repos/virt7-docker-common-testing/x86_64/os/
> 
> I have seen it coming :).  So for developing atomicapp we are relaying
> on newer bits of docker, atomic command, k8ns etc, which is fine.  But
> the Vagrant box is based on CentOS core. Hence the mismatch.
> 
> We had couple of rounds of discussion about the merits and demerits of
> taking newer bits in to the Vagrant box and mostly decided for CentOS
> core bits.
> 
> But I can see a requirement for the newer bits as well. So I can think
> we can achieve it in two ways.
> 
> 1. We can create a script , which will put  yum repos for newer bits and
> update the packages (from sig repos) . But user has to manually run it
> or we can run it through a Vagrantfile.
> 
> 2. Or to build another Vagrant box with newer bits (from SIG repos).
> 
> 
> Let me know your thoughts on this.
> 
> -Lala
> >> -Aaron
> >>
> >> On Wed, Aug 5, 2015 at 12:27 PM, Jason Brooks <jbrooks at redhat.com> wrote:
> >>
> >>> Hey all, I'm experiencing an issue running some of the examples at
> >>> the nulecule project w/ the atomicapp/dev vagrant box, and I'm
> >>> trying to figure out where to look / file issues.
> >>>
> >>> I'm trying to figure out if this is known to be working w/
> >>> image X or w/ kube version Y, etc., making this an issue w/
> >>> my setup, or whether the problem is with the atomicapp.
> >>>
> >>> Here are the steps I'm following:
> >>>
> >>> vagrant init atomicapp/dev
> >>> vagrant up provider=libvirt
> >>> vagrant ssh
> >>> sudo atomic run projectatomic/wordpress-centos7-atomicapp
> >>>
> >>> ...
> >>>
> >>>
> >>> F0805 16:17:14.946675      48 create.go:75] unable to recognize
> >>> "/atomicapp/.workdir/mariadb-atomicapp/artifacts/kubernetes/mariadb-service.yaml":
> >>> no object named "Service" is registered
> >>> Traceback (most recent call last):
> >>>    File "/usr/bin/atomicapp", line 9, in <module>
> >>>      load_entry_point('atomicapp==0.1', 'console_scripts', 'atomicapp')()
> >>>    File "/usr/lib/python2.7/site-packages/atomicapp/cli/main.py", line
> >>>    89,
> >>> in main
> >>>      cli.run()
> >>>    File "/usr/lib/python2.7/site-packages/atomicapp/cli/main.py", line
> >>>    70,
> >>> in run
> >>>      args.func(args)
> >>>    File "/usr/lib/python2.7/site-packages/atomicapp/cli/main.py", line
> >>>    21,
> >>> in cli_run
> >>>      ae.run()
> >>>    File "/usr/lib/python2.7/site-packages/atomicapp/run.py", line 187, in
> >>> run
> >>>      self._dispatchGraph()
> >>>    File "/usr/lib/python2.7/site-packages/atomicapp/run.py", line 95, in
> >>> _dispatchGraph
> >>>      ret = component_run.run()
> >>>    File "/usr/lib/python2.7/site-packages/atomicapp/run.py", line 187, in
> >>> run
> >>>      self._dispatchGraph()
> >>>    File "/usr/lib/python2.7/site-packages/atomicapp/run.py", line 99, in
> >>> _dispatchGraph
> >>>      self._processComponent(component, graph_item)
> >>>    File "/usr/lib/python2.7/site-packages/atomicapp/run.py", line 172, in
> >>> _processComponent
> >>>      provider.deploy()
> >>>    File
> >>> "/usr/lib/python2.7/site-packages/atomicapp/providers/kubernetes.py",
> >>> line
> >>> 73, in deploy
> >>>      self._callK8s(k8s_file)
> >>>    File
> >>> "/usr/lib/python2.7/site-packages/atomicapp/providers/kubernetes.py",
> >>> line
> >>> 41, in _callK8s
> >>>      subprocess.check_call(cmd)
> >>>    File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call
> >>>      raise CalledProcessError(retcode, cmd)
> >>> subprocess.CalledProcessError: Command '['/host/usr/bin/kubectl',
> >>> 'create', '-f',
> >>> u'/atomicapp/.workdir/mariadb-atomicapp/artifacts/kubernetes/mariadb-service.yaml',
> >>> '--namespace=default']' returned non-zero exit status 255
> >>>
> >>>
> >>> ---
> >>>
> >>> Jason Brooks
> >>> Red Hat Open Source and Standards
> >>>
> >>> @jasonbrooks | @redhatopen
> >>> http://community.redhat.com
> >>>
> >>>
> >>> _______________________________________________
> >>> Container-tools mailing list
> >>> Container-tools at redhat.com
> >>> https://www.redhat.com/mailman/listinfo/container-tools
> >>>
> 
> 




More information about the Container-tools mailing list