From bex at pobox.com Mon May 2 04:35:48 2016 From: bex at pobox.com (Brian (bex) Exelbierd) Date: Mon, 2 May 2016 06:35:48 +0200 Subject: [Devtools] rhel-k8s-singlenode-setup In-Reply-To: References: <22A553AC-6BC0-4CC1-A925-0DBA18407DF1@redhat.com> Message-ID: <5726D924.6020600@pobox.com> On 04/24/2016 08:51 AM, Burr Sutter wrote: > We do have a k8s in the CDK - but it would appear relatively few have > really tried to use it :-) Expanding on this, you can use Kube with the OpenShift default of CDK and by booting with the with Vagrantfile in the cdk.zip. There are similar Vagrantfiles for the ADB at https://github.com/projectatomic/adb-atomic-developer-bundle/tree/master/components/centos kubectl works from both your workstation and, if you insist :P, via `vagrant ssh`. If you find problems or issues, please suggest a different configuration. regards, bex > > On Fri, Apr 22, 2016 at 8:18 PM, James Strachan > wrote: > > if you wanna try k8s here?s a little vagrantfile we?ve been using: > https://github.com/fabric8io/fabric8-installer/tree/master/vagrant/kubernetes > > whenever the new docker beta is open to the public for windows & > mac, using a script like this might be the easiest way for > windows/mac folks to spin up a local k8s cluster > https://github.com/fabric8io/fabric8-installer/blob/master/vagrant/kubernetes/bin/start-kubernetes > > >> On 22 Apr 2016, at 15:41, Burr Sutter > > wrote: >> >> >> I though I would give the k8s vagrantfile a try (I normally just >> use rhel-ose) >> >> and "vagrant up" produces: >> >> ==> default: Clearing any previously set network interfaces... >> A host only network interface you're attempting to configure via DHCP >> already has a conflicting host only adapter with DHCP enabled. The >> DHCP on this adapter is incompatible with the DHCP settings. Two >> host only network interfaces are not allowed to overlap, and each >> host only network interface can have only one DHCP server. Please >> reconfigure your host only network or remove the virtual machine >> using the other host only network. >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools > > > James > ------- > Red Hat > > Twitter: @jstrachan > Email: jstracha at redhat.com > Blog: http://macstrac.blogspot.com/ > > hawtio: http:/ /hawt.io/ > fabric8: http:/ /fabric8.io/ > > > Open Source Integration > > > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -- Brian (bex) Exelbierd | bex at pobox.com +420-606-055-877 | @bexelbie http://www.winglemeyer.org From manderse at redhat.com Mon May 2 08:06:36 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 02 May 2016 13:36:36 +0530 Subject: [Devtools] Question on the cdk + openshift + eap deployment markers In-Reply-To: <5722AB9E.6090009@redhat.com> References: <5722AB9E.6090009@redhat.com> Message-ID: <18E8B1D4-D9AD-4AFD-9AB7-5AC27121140C@redhat.com> On 29 Apr 2016, at 6:02, Rob Stryker wrote: > Hey All: > > Not sure what list to send this to, since it's part CDK, part > openshift, part EAP. Hope this is the right list. > > Two issues... > First, despite me deleting a .deployed marker (ROOT.war.deployed), and > rsyncing back up to the pod using the --delete flag, the server seems > to be replacing the file immediately, rather than undeploying the app > as it's supposed to. Is it the case that eap on openshift cannot > undeploy root.war ? I don't know - but Have you tried doing it manually by ssh'ing in ? Have you tried do it on a local running EAP ? This stuff been unchanged for years so I would be surprised if changed thus try locate where it goes wrong - and wether it is unique to openshift or not. > Secondly, I'm noticing really strange behavior with oc rsync. > > I have a local folder 'deploy' in a directory i use in JBT: > > [rob at rawbdor deploy]$ ls > activemq-rar.rar README.txt ROOT.war.deployed > activemq-rar.rar.deployed ROOT.war > > This maps to the remote openshift folder > eap-app-1-auugc:/opt/eap/standalone/deployments > > But when I run the following commands, I get very unexpected results: > > Try 1: > oc rsync eap-app-1-auugc:/opt/eap/standalone/deployments > "/home/rob/apps/eclipse/workspaces/runtime-EclipseApplication/.metadata/.plugins/org.jboss.ide.eclipse.as.core/test at eap-app/deploy" > > RESULT: deployments -> /deployments - ie, it created a new folder > called deployments inside my deploy folder. Not what I want. > > Try 2: > oc rsync eap-app-1-auugc:/opt/eap/standalone/deployments/ > /home/rob/apps/eclipse/workspaces/runtime-EclipseApplication/.metadata/.plugins/org.jboss.ide.eclipse.as.core/test at eap-app/deploy > > (Note I added a trailing slash > eap-app-1-auugc:/opt/eap/standalone/deployments) - Result: it > copied the entire remote folder into a new subfolder called "deploy" > inside my existing folder named "deploy" > > Try 3: > oc rsync eap-app-1-auugc:/opt/eap/standalone/deployments/ > /home/rob/apps/eclipse/workspaces/runtime-EclipseApplication/.metadata/.plugins/org.jboss.ide.eclipse.as.core/test at eap-app/deploy/ > > (Note I added an additional trailing slash to local path) > Result: same as try 2 > > Try 4: > oc rsync eap-app-1-auugc:/opt/eap/standalone/deployments > /home/rob/apps/eclipse/workspaces/runtime-EclipseApplication/.metadata/.plugins/org.jboss.ide.eclipse.as.core/test at eap-app/deploy/ > > (Note, local path has trailing slash, remote path does not) > Result: Same as try 1 > > This all seems strange, no? Pretty sure the attempt with no trailing > slashes is the correct one, but its behavior is strange. I don't spot what you believe is strange here. Can you be more specific about what you actually expected ? note: The ending slash matters in rsync. /max http://about.me/maxandersen From bsutter at redhat.com Mon May 2 12:04:44 2016 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 2 May 2016 17:34:44 +0530 Subject: [Devtools] rhel-k8s-singlenode-setup In-Reply-To: <5726D924.6020600@pobox.com> References: <22A553AC-6BC0-4CC1-A925-0DBA18407DF1@redhat.com> <5726D924.6020600@pobox.com> Message-ID: On Mon, May 2, 2016 at 10:05 AM, Brian (bex) Exelbierd wrote: > On 04/24/2016 08:51 AM, Burr Sutter wrote: > >> We do have a k8s in the CDK - but it would appear relatively few have >> really tried to use it :-) >> > > Expanding on this, you can use Kube with the OpenShift default of CDK and > by booting with the with Vagrantfile in the cdk.zip. > > There are similar Vagrantfiles for the ADB at > https://github.com/projectatomic/adb-atomic-developer-bundle/tree/master/components/centos > > kubectl works from both your workstation and, if you insist :P, via > `vagrant ssh`. > > If you find problems or issues, please suggest a different configuration. > > Here are my notes & scripts for a "kubectl" demo on the CDK https://github.com/burrsutter/kube4docker > regards, > > bex > > >> On Fri, Apr 22, 2016 at 8:18 PM, James Strachan > > wrote: >> >> if you wanna try k8s here?s a little vagrantfile we?ve been using: >> >> https://github.com/fabric8io/fabric8-installer/tree/master/vagrant/kubernetes >> >> whenever the new docker beta is open to the public for windows & >> mac, using a script like this might be the easiest way for >> windows/mac folks to spin up a local k8s cluster >> >> https://github.com/fabric8io/fabric8-installer/blob/master/vagrant/kubernetes/bin/start-kubernetes >> >> >> On 22 Apr 2016, at 15:41, Burr Sutter >> > wrote: >>> >>> >>> I though I would give the k8s vagrantfile a try (I normally just >>> use rhel-ose) >>> >>> and "vagrant up" produces: >>> >>> ==> default: Clearing any previously set network interfaces... >>> A host only network interface you're attempting to configure via DHCP >>> already has a conflicting host only adapter with DHCP enabled. The >>> DHCP on this adapter is incompatible with the DHCP settings. Two >>> host only network interfaces are not allowed to overlap, and each >>> host only network interface can have only one DHCP server. Please >>> reconfigure your host only network or remove the virtual machine >>> using the other host only network. >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> https://www.redhat.com/mailman/listinfo/devtools >>> >> >> >> James >> ------- >> Red Hat >> >> Twitter: @jstrachan >> Email: jstracha at redhat.com >> Blog: http://macstrac.blogspot.com/ >> >> hawtio: http:/ /hawt.io/ >> fabric8: http:/ /fabric8.io/ >> >> >> Open Source Integration >> >> >> >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> >> > -- > Brian (bex) Exelbierd | bex at pobox.com > +420-606-055-877 | @bexelbie > http://www.winglemeyer.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rstryker at redhat.com Mon May 2 18:49:22 2016 From: rstryker at redhat.com (Rob Stryker) Date: Mon, 2 May 2016 14:49:22 -0400 Subject: [Devtools] Question on the cdk + openshift + eap deployment markers In-Reply-To: <18E8B1D4-D9AD-4AFD-9AB7-5AC27121140C@redhat.com> References: <5722AB9E.6090009@redhat.com> <18E8B1D4-D9AD-4AFD-9AB7-5AC27121140C@redhat.com> Message-ID: <5727A132.4070009@redhat.com> On 05/02/2016 04:06 AM, Max Rydahl Andersen wrote: > On 29 Apr 2016, at 6:02, Rob Stryker wrote: > >> Hey All: >> >> Not sure what list to send this to, since it's part CDK, part >> openshift, part EAP. Hope this is the right list. >> >> Two issues... >> First, despite me deleting a .deployed marker (ROOT.war.deployed), >> and rsyncing back up to the pod using the --delete flag, the server >> seems to be replacing the file immediately, rather than undeploying >> the app as it's supposed to. Is it the case that eap on openshift >> cannot undeploy root.war ? > > I don't know - but Have you tried doing it manually by ssh'ing in ? Yes, I've tried this by ssh'ing in and deleting the file, and the server log didn't seem to have any output indicating the module stopped. > Have you tried do it on a local running EAP ? Yes, on a local running EAP, the server immediately responds with some undeploy output. This is not occurring via openshift. > > I don't spot what you believe is strange here. Can you be more > specific about what you actually expected ? I was expecting at least one of the commands to behave as the documents indicate they should. The contents of the remote server inside folder 'x' should be transferred to the local folder 'y'. ie, x/* should be moved into y as if i had done a cp x/* y/. Instead, behavior seems to be either creation of a symlink (?!) or the contents of x (ie x/*) are being placed inside y/y-last-segment/. For example, when openshift folder 'deployments' has file "x.txt", then I would expect oc rsync eap-app-1-auugc:/opt/eap/standalone/deployments/ /home/local/path/deploy to place file x.txt inside /home/local/path/deploy/. Instead, it is placing x.txt inside /home/local/path/deploy/deploy. This is VERY wrong. Is anyone else able to replicate this?? > > note: The ending slash matters in rsync. > > > /max > http://about.me/maxandersen -------------- next part -------------- An HTML attachment was scrubbed... URL: From manderse at redhat.com Tue May 3 05:19:10 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 03 May 2016 10:49:10 +0530 Subject: [Devtools] Question on the cdk + openshift + eap deployment markers In-Reply-To: <5727A132.4070009@redhat.com> References: <5722AB9E.6090009@redhat.com> <18E8B1D4-D9AD-4AFD-9AB7-5AC27121140C@redhat.com> <5727A132.4070009@redhat.com> Message-ID: <3E0BA248-46B4-4717-8ABF-ACED95848A4F@redhat.com> On 3 May 2016, at 0:19, Rob Stryker wrote: > On 05/02/2016 04:06 AM, Max Rydahl Andersen wrote: >> On 29 Apr 2016, at 6:02, Rob Stryker wrote: >> >>> Hey All: >>> >>> Not sure what list to send this to, since it's part CDK, part >>> openshift, part EAP. Hope this is the right list. >>> >>> Two issues... >>> First, despite me deleting a .deployed marker (ROOT.war.deployed), >>> and rsyncing back up to the pod using the --delete flag, the server >>> seems to be replacing the file immediately, rather than undeploying >>> the app as it's supposed to. Is it the case that eap on openshift >>> cannot undeploy root.war ? >> >> I don't know - but Have you tried doing it manually by ssh'ing in ? > > Yes, I've tried this by ssh'ing in and deleting the file, and the > server log didn't seem to have any output indicating the module > stopped. > >> Have you tried do it on a local running EAP ? > > Yes, on a local running EAP, the server immediately responds with some > undeploy output. This is not occurring via openshift. check the configuration of the EAP in OpenShift - maybe they have a higher timeout or not enabled scanning ? >> I don't spot what you believe is strange here. Can you be more >> specific about what you actually expected ? > > I was expecting at least one of the commands to behave as the > documents indicate they should. The contents of the remote server > inside folder 'x' should be transferred to the local folder 'y'. ie, > x/* should be moved into y as if i had done a cp x/* y/. Instead, > behavior seems to be either creation of a symlink (?!) or the contents > of x (ie x/*) are being placed inside y/y-last-segment/. > > For example, when openshift folder 'deployments' has file "x.txt", > then I would expect oc rsync > eap-app-1-auugc:/opt/eap/standalone/deployments/ > /home/local/path/deploy to place file x.txt inside > /home/local/path/deploy/. Instead, it is placing x.txt inside > /home/local/path/deploy/deploy. This is VERY wrong. > > Is anyone else able to replicate this?? I am not in a position right now to test it - I suggest open a bug against the oc client (https://github.com/openshift/origin/issues) with a test case of what fails for you and how you expected it to behave. Maybe verify this is somehow not working as rsync does. /max > >> >> note: The ending slash matters in rsync. >> >> >> /max >> http://about.me/maxandersen /max http://about.me/maxandersen From mmusaji at redhat.com Tue May 3 08:58:19 2016 From: mmusaji at redhat.com (Mustafa Musaji) Date: Tue, 3 May 2016 09:58:19 +0100 Subject: [Devtools] CDK installation issue on Fedora 23 Message-ID: First of all I hope this is the correct mailing list to ask about CDK installation. I'm following the instructions here [1] to install the CDK on my Fed23 machine. However, I'm getting to a specific point and not really sure what is wrong and hoping someone can help me. When I attempt to install the plugins as per the installation guide I get the following error: [mmusaji at dhcp-1-88 plugins]$ vagrant plugin install vagrant-registration-1.2.1.gem Installing the 'vagrant-registration-1.2.1.gem' plugin. This can take a few minutes... Bundler, the underlying system Vagrant uses to install plugins, reported an error. The error is shown below. These errors are usually caused by misconfigured plugin installations or transient network issues. The error from Bundler is: An error occurred while installing vagrant (1.8.1), and Bundler cannot continue. Make sure that `gem install vagrant -v '1.8.1'` succeeds before bundling. NoMethodError: undefined method `spec' for nil:NilClass When I run gem install vagrant -v '1.8.1' [mmusaji at dhcp-1-88 plugins]$ gem install vagrant -v '1.8.1' ERROR: Could not find a valid gem 'vagrant' (= 1.8.1) in any repository ERROR: Possible alternatives: vagrant However, I do have vagrant 1.8.1. installed. [mmusaji at dhcp-1-88 plugins]$ vagrant --version Vagrant 1.8.1 [mmusaji at dhcp-1-88 plugins]$ bundler --version Bundler version 1.12.0 Am I missing an obvious step in the installation or is this an installation issue? Thanks Mus [1] https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/version-7/container-development-kit-installation-guide/#installing_the_cdk_on_fedora_or_red_hat_enterprise_linux From lmohanty at redhat.com Tue May 3 09:05:49 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 3 May 2016 14:35:49 +0530 Subject: [Devtools] CDK installation issue on Fedora 23 In-Reply-To: References: Message-ID: <572869ED.7060602@redhat.com> On 05/03/2016 02:28 PM, Mustafa Musaji wrote: > First of all I hope this is the correct mailing list to ask about CDK > installation. > > I'm following the instructions here [1] to install the CDK on my Fed23 > machine. However, I'm getting to a specific point and not really sure > what is wrong and hoping someone can help me. > > When I attempt to install the plugins as per the installation guide I > get the following error: > > [mmusaji at dhcp-1-88 plugins]$ vagrant plugin install > vagrant-registration-1.2.1.gem > Installing the 'vagrant-registration-1.2.1.gem' plugin. This can take > a few minutes... > Bundler, the underlying system Vagrant uses to install plugins, > reported an error. The error is shown below. These errors are usually > caused by misconfigured plugin installations or transient network > issues. The error from Bundler is: > > An error occurred while installing vagrant (1.8.1), and Bundler cannot > continue. > Make sure that `gem install vagrant -v '1.8.1'` succeeds before bundling. > > NoMethodError: undefined method `spec' for nil:NilClass > > When I run gem install vagrant -v '1.8.1' > > [mmusaji at dhcp-1-88 plugins]$ gem install vagrant -v '1.8.1' > ERROR: Could not find a valid gem 'vagrant' (= 1.8.1) in any repository > ERROR: Possible alternatives: vagrant > > However, I do have vagrant 1.8.1. installed. > > [mmusaji at dhcp-1-88 plugins]$ vagrant --version > Vagrant 1.8.1 > [mmusaji at dhcp-1-88 plugins]$ bundler --version > Bundler version 1.12.0 > > Am I missing an obvious step in the installation or is this an > installation issue? > > Thanks > Mus > > [1] https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/version-7/container-development-kit-installation-guide/#installing_the_cdk_on_fedora_or_red_hat_enterprise_linux I am running Vagrant 1.8.1 on Fedora 23 without any issue. Are you able to install another Vagrant plugin? Or the issue is only with vagrant-registration plugin. -Lala > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From mmusaji at redhat.com Tue May 3 09:13:57 2016 From: mmusaji at redhat.com (Mustafa Musaji) Date: Tue, 3 May 2016 10:13:57 +0100 Subject: [Devtools] CDK installation issue on Fedora 23 In-Reply-To: <572869ED.7060602@redhat.com> References: <572869ED.7060602@redhat.com> Message-ID: I get the issue with all the plugins in the CDK plugins directory. Although the error is slightly different. [mmusaji at dhcp-1-189 plugins]$ vagrant plugin install ~/Tools/CDK/cdk/plugins/vagrant-service-manager-1.0.1.gem Installing the '/home/mmusaji/Tools/CDK/cdk/plugins/vagrant-service-manager-1.0.1.gem' plugin. This can take a few minutes... Bundler, the underlying system Vagrant uses to install plugins, reported an error. The error is shown below. These errors are usually caused by misconfigured plugin installations or transient network issues. The error from Bundler is: Could not find gem 'vagrant-service-manager (= 1.0.1) ruby' in the gems available on this machine. I was pointed to [1] but this on Fed24, however, if you have this working on Fed23 I think it might be something I have missed. Did you follow the instructions from the installation guide and can you double check you didn't do anything not documented in the docs? Thanks Mus [1] https://bugzilla.redhat.com/show_bug.cgi?id=1330216#c1 -------------- Mustafa Musaji Solution Architect Red Hat UK Our mission is to be the catalyst in communities of customers, contributors, and partners creating better technology the open source way. Registered in England and Wales under Company Registration No. 03798903 Directors:Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander On 3 May 2016 at 10:05, Lalatendu Mohanty wrote: > On 05/03/2016 02:28 PM, Mustafa Musaji wrote: >> >> First of all I hope this is the correct mailing list to ask about CDK >> installation. >> >> I'm following the instructions here [1] to install the CDK on my Fed23 >> machine. However, I'm getting to a specific point and not really sure >> what is wrong and hoping someone can help me. >> >> When I attempt to install the plugins as per the installation guide I >> get the following error: >> >> [mmusaji at dhcp-1-88 plugins]$ vagrant plugin install >> vagrant-registration-1.2.1.gem >> Installing the 'vagrant-registration-1.2.1.gem' plugin. This can take >> a few minutes... >> Bundler, the underlying system Vagrant uses to install plugins, >> reported an error. The error is shown below. These errors are usually >> caused by misconfigured plugin installations or transient network >> issues. The error from Bundler is: >> >> An error occurred while installing vagrant (1.8.1), and Bundler cannot >> continue. >> Make sure that `gem install vagrant -v '1.8.1'` succeeds before bundling. >> >> NoMethodError: undefined method `spec' for nil:NilClass >> >> When I run gem install vagrant -v '1.8.1' >> >> [mmusaji at dhcp-1-88 plugins]$ gem install vagrant -v '1.8.1' >> ERROR: Could not find a valid gem 'vagrant' (= 1.8.1) in any repository >> ERROR: Possible alternatives: vagrant >> >> However, I do have vagrant 1.8.1. installed. >> >> [mmusaji at dhcp-1-88 plugins]$ vagrant --version >> Vagrant 1.8.1 >> [mmusaji at dhcp-1-88 plugins]$ bundler --version >> Bundler version 1.12.0 >> >> Am I missing an obvious step in the installation or is this an >> installation issue? >> >> Thanks >> Mus >> >> [1] >> https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/version-7/container-development-kit-installation-guide/#installing_the_cdk_on_fedora_or_red_hat_enterprise_linux > > > I am running Vagrant 1.8.1 on Fedora 23 without any issue. Are you able to > install another Vagrant plugin? Or the issue is only with > vagrant-registration plugin. > > -Lala >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From mmusaji at redhat.com Tue May 3 09:47:29 2016 From: mmusaji at redhat.com (Mustafa Musaji) Date: Tue, 3 May 2016 10:47:29 +0100 Subject: [Devtools] CDK installation issue on Fedora 23 In-Reply-To: References: <572869ED.7060602@redhat.com> Message-ID: After reviewing the steps here [1] and seeing that it recommends vagrant 1.7.4, I uninstalled and downloaded vagrant 1.7.4 and I no longer get this error! Mus [1] http://developers.redhat.com/products/cdk/get-started/ -------------- Mustafa Musaji Solution Architect Red Hat UK Our mission is to be the catalyst in communities of customers, contributors, and partners creating better technology the open source way. Registered in England and Wales under Company Registration No. 03798903 Directors:Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander On 3 May 2016 at 10:13, Mustafa Musaji wrote: > I get the issue with all the plugins in the CDK plugins directory. > Although the error is slightly different. > > [mmusaji at dhcp-1-189 plugins]$ vagrant plugin install > ~/Tools/CDK/cdk/plugins/vagrant-service-manager-1.0.1.gem > Installing the '/home/mmusaji/Tools/CDK/cdk/plugins/vagrant-service-manager-1.0.1.gem' > plugin. This can take a few minutes... > Bundler, the underlying system Vagrant uses to install plugins, > reported an error. The error is shown below. These errors are usually > caused by misconfigured plugin installations or transient network > issues. The error from Bundler is: > > Could not find gem 'vagrant-service-manager (= 1.0.1) ruby' in the > gems available on this machine. > > I was pointed to [1] but this on Fed24, however, if you have this > working on Fed23 I think it might be something I have missed. Did you > follow the instructions from the installation guide and can you double > check you didn't do anything not documented in the docs? > > Thanks > Mus > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1330216#c1 > -------------- > Mustafa Musaji > Solution Architect > Red Hat UK > > Our mission is to be the catalyst in communities of customers, > contributors, and partners creating better technology the open source > way. > > Registered in England and Wales under Company Registration No. 03798903 > Directors:Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > > > On 3 May 2016 at 10:05, Lalatendu Mohanty wrote: >> On 05/03/2016 02:28 PM, Mustafa Musaji wrote: >>> >>> First of all I hope this is the correct mailing list to ask about CDK >>> installation. >>> >>> I'm following the instructions here [1] to install the CDK on my Fed23 >>> machine. However, I'm getting to a specific point and not really sure >>> what is wrong and hoping someone can help me. >>> >>> When I attempt to install the plugins as per the installation guide I >>> get the following error: >>> >>> [mmusaji at dhcp-1-88 plugins]$ vagrant plugin install >>> vagrant-registration-1.2.1.gem >>> Installing the 'vagrant-registration-1.2.1.gem' plugin. This can take >>> a few minutes... >>> Bundler, the underlying system Vagrant uses to install plugins, >>> reported an error. The error is shown below. These errors are usually >>> caused by misconfigured plugin installations or transient network >>> issues. The error from Bundler is: >>> >>> An error occurred while installing vagrant (1.8.1), and Bundler cannot >>> continue. >>> Make sure that `gem install vagrant -v '1.8.1'` succeeds before bundling. >>> >>> NoMethodError: undefined method `spec' for nil:NilClass >>> >>> When I run gem install vagrant -v '1.8.1' >>> >>> [mmusaji at dhcp-1-88 plugins]$ gem install vagrant -v '1.8.1' >>> ERROR: Could not find a valid gem 'vagrant' (= 1.8.1) in any repository >>> ERROR: Possible alternatives: vagrant >>> >>> However, I do have vagrant 1.8.1. installed. >>> >>> [mmusaji at dhcp-1-88 plugins]$ vagrant --version >>> Vagrant 1.8.1 >>> [mmusaji at dhcp-1-88 plugins]$ bundler --version >>> Bundler version 1.12.0 >>> >>> Am I missing an obvious step in the installation or is this an >>> installation issue? >>> >>> Thanks >>> Mus >>> >>> [1] >>> https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/version-7/container-development-kit-installation-guide/#installing_the_cdk_on_fedora_or_red_hat_enterprise_linux >> >> >> I am running Vagrant 1.8.1 on Fedora 23 without any issue. Are you able to >> install another Vagrant plugin? Or the issue is only with >> vagrant-registration plugin. >> >> -Lala >>> >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> https://www.redhat.com/mailman/listinfo/devtools >> >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools From bsutter at redhat.com Tue May 3 17:18:23 2016 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 3 May 2016 22:48:23 +0530 Subject: [Devtools] Hawkular Metrics Message-ID: Any concerns of the use of this metric capture/display tool within the CDK? https://docs.openshift.com/enterprise/latest/install_config/cluster_metrics.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From fche at redhat.com Tue May 3 23:20:59 2016 From: fche at redhat.com (Frank Ch. Eigler) Date: Tue, 3 May 2016 19:20:59 -0400 Subject: [Devtools] Hawkular Metrics In-Reply-To: References: Message-ID: <20160503232059.GD12139@redhat.com> Hi, Burr - On Tue, May 03, 2016 at 10:48:23PM +0530, Burr Sutter wrote: > Any concerns of the use of this metric capture/display tool within the CDK? > https://docs.openshift.com/enterprise/latest/install_config/cluster_metrics.html We may be aiming a little low. Heapster/Hawkular/K8S integration is compelling, but Heapster is not that rich a source of data, compared to something like Performance Co-Pilot [2]. Compare dozens of metrics [1] from the former (specialized to containers) to the thousands from the latter (containers -and- host) [3]. Luckily, PCP is packageable as a container, and can already talk [4] to Hawkular via the latter's graphite protocol adapter [5], to supplement the Heapster data, so it can be just a deployment-configuration problem, not a "need more code" one. [1] https://github.com/kubernetes/heapster/blob/master/docs/storage-schema.md [2] http://www.pcp.io/ [3] http://paste.fedoraproject.org/362338/17510146 (a random subset; /usr/bin/pminfo) [4] http://man7.org/linux/man-pages/man1/pcp2graphite.1.html [5] https://github.com/hawkular/hawkular-metrics/tree/master/clients/ptranslator - FChE From bsutter at redhat.com Thu May 5 12:35:24 2016 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 5 May 2016 08:35:24 -0400 Subject: [Devtools] Hawkular Metrics In-Reply-To: <20160503232059.GD12139@redhat.com> References: <20160503232059.GD12139@redhat.com> Message-ID: On Tue, May 3, 2016 at 7:20 PM, Frank Ch. Eigler wrote: > Hi, Burr - > > On Tue, May 03, 2016 at 10:48:23PM +0530, Burr Sutter wrote: > > > Any concerns of the use of this metric capture/display tool within the > CDK? > > > https://docs.openshift.com/enterprise/latest/install_config/cluster_metrics.html > > We may be aiming a little low. Heapster/Hawkular/K8S integration is > compelling, but Heapster is not that rich a source of data, compared > to something like Performance Co-Pilot [2]. Compare dozens of metrics > [1] from the former (specialized to containers) to the thousands from > the latter (containers -and- host) [3]. > > Luckily, PCP is packageable as a container, and can already talk [4] > to Hawkular via the latter's graphite protocol adapter [5], to > supplement the Heapster data, so it can be just a > deployment-configuration problem, not a "need more code" one. > > [1] > https://github.com/kubernetes/heapster/blob/master/docs/storage-schema.md > [2] http://www.pcp.io/ > [3] http://paste.fedoraproject.org/362338/17510146 (a random subset; > /usr/bin/pminfo) > [4] http://man7.org/linux/man-pages/man1/pcp2graphite.1.html > [5] > https://github.com/hawkular/hawkular-metrics/tree/master/clients/ptranslator > > Looks like a lot of work, not sure when I can get to it :-) Anyone every try this with CDK? > - FChE > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hferents at redhat.com Fri May 6 08:11:55 2016 From: hferents at redhat.com (Hardy Ferentschik) Date: Fri, 6 May 2016 13:41:55 +0530 Subject: [Devtools] Hawkular Metrics In-Reply-To: References: <20160503232059.GD12139@redhat.com> Message-ID: <20160506081155.GA5453@nineveh.local> Hi, > Looks like a lot of work, not sure when I can get to it :-) The Hawkular part is not so hard. I use Hawkular in the demos I give to show autoscaling. I am using this script (https://github.com/hferentschik/container-demos/blob/master/openshift/metrics.sh) to install metrics on the CDK. ssh onto the VM and execute this script and all should be ready to go. You will need to restart OpenShift though, since the script updates master-config.xml to add the 'metricPublicURL'. Also, it will take a while until all required pods are running. You can login as admin via oc and view the project 'openshift-infra'. There you will see when all pods are ready. > Anyone every try this with CDK? See above :-) My experience is mixed. It seems to work a bit flaky and the UI in the OpenShift console keeps showing a warning dialog. Also, sometimes metrics don't seem to be available at all. Not sure whether this is a UI thing only, since autoscaling does work once Hawkular is enabled. It might also be that the problem lies in the fact that the CDK VM is just running out of memory. My next project is to actually add Cockpit into the mix. I've seen some demo video and it looked nice, but for some reason there were not instructions on how to enable Cockpit in combination with OpenShift. This thread seems to offer some hints :-) I'll let you know once I tried it. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From nshaikh at redhat.com Mon May 9 16:19:29 2016 From: nshaikh at redhat.com (Navid Shaikh) Date: Mon, 9 May 2016 21:49:29 +0530 Subject: [Devtools] vagrant-service-manager version 1.0.2 release Message-ID: We have a new release of vagrant-service-manager plugin, version 1.0.2. This release of the plugin adds new commands and options. - `status` command is added to show the statuses of configured services in the box - `box ip` command to show the routable IP address of the box - `--script-readable` option is added for `env` and `env docker` sub-commands to make sure the consumers of plugin get the output in desirable format for processing This release of the plugin improves the way its commands and their output are formed and displayed for easy consumption by other tools. There are bug fixes, refactoring and Budh Ram as new co-maintainer for the plugin! Check [1] to find the detailed changelog for the release. [1] https://github.com/projectatomic/vagrant-service-manager/releases/tag/v1.0.2 -- Thanks, Navid -------------- next part -------------- An HTML attachment was scrubbed... URL: From surajd at redhat.com Tue May 10 11:12:55 2016 From: surajd at redhat.com (Suraj Deshmukh) Date: Tue, 10 May 2016 16:42:55 +0530 Subject: [Devtools] Compose file for Multi-container Nulecule-lib example Message-ID: Hi, I have taken all the multi-container Nulecule examples and transformed them into docker compose, just so that moving forward when we come up with a tool that does the conversion, we will have something to test against. If you guys have some suggestion please do provide. The repo is at [1]. Or this can also help from the day one of the conversion tool. [1] https://github.com/surajssd/compose-lib -- - Suraj Deshmukh (surajd) https://deshmukhsuraj.wordpress.com https://twitter.com/surajd_ From pradeepto at redhat.com Tue May 10 11:38:24 2016 From: pradeepto at redhat.com (Pradeepto Bhattacharya) Date: Tue, 10 May 2016 17:08:24 +0530 Subject: [Devtools] Compose file for Multi-container Nulecule-lib example In-Reply-To: References: Message-ID: On Tue, May 10, 2016 at 4:42 PM, Suraj Deshmukh wrote: > Hi, > > I have taken all the multi-container Nulecule examples and transformed > them into docker compose, just so that moving forward when we come up > with a tool that does the conversion, we will have something to test > against. If you guys have some suggestion please do provide. The repo > is at [1]. > > Or this can also help from the day one of the conversion tool. > > [1] https://github.com/surajssd/compose-lib > > Super! Thank you for taking the initiative to do this. Cheers! Pradeepto -- Pradeepto Bhattacharya -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgurung at redhat.com Tue May 10 15:42:35 2016 From: bgurung at redhat.com (Budh Gurung) Date: Tue, 10 May 2016 21:12:35 +0530 Subject: [Devtools] Developer Studio + CDK screencasts Message-ID: Hello, Following are the two screencasts shared by Alexey after having discussion with him over Developer studio and CDK. 1. Red Hat JBoss Developer Studio Platform Installer. Beta [1] 2. Starting Red Hat CDK and OpenShift 3 in JBoss Developer Studio 9.1 [2] [1] https://youtu.be/dMWAguol3as [2] https://www.youtube.com/watch?v=h_FACXXl94g Regards, Budh Ram Gurung Software Engineer - Dev Tools -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Tue May 10 16:00:37 2016 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 10 May 2016 12:00:37 -0400 Subject: [Devtools] Developer Studio + CDK screencasts In-Reply-To: References: Message-ID: Awesome stuff, we should send these (and the future updates) around...often :-) On Tue, May 10, 2016 at 11:42 AM, Budh Gurung wrote: > Hello, > > Following are the two screencasts shared by Alexey after having discussion > with him > over Developer studio and CDK. > > 1. Red Hat JBoss Developer Studio Platform Installer. Beta [1] > 2. Starting Red Hat CDK and OpenShift 3 in JBoss Developer Studio 9.1 [2] > > [1] https://youtu.be/dMWAguol3as > [2] https://www.youtube.com/watch?v=h_FACXXl94g > > > Regards, > Budh Ram Gurung > Software Engineer - Dev Tools > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manderse at redhat.com Tue May 10 16:05:40 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 10 May 2016 18:05:40 +0200 Subject: [Devtools] Developer Studio + CDK screencasts In-Reply-To: References: Message-ID: <7904723C-DF0D-497E-A554-8A3E15C66EE5@redhat.com> On 10 May 2016, at 18:00, Burr Sutter wrote: > Awesome stuff, we should send these (and the future updates) around...often > :-) Every three weeks there are 3 hours of demo. Enough for you ? :) /max > > On Tue, May 10, 2016 at 11:42 AM, Budh Gurung wrote: > >> Hello, >> >> Following are the two screencasts shared by Alexey after having discussion >> with him >> over Developer studio and CDK. >> >> 1. Red Hat JBoss Developer Studio Platform Installer. Beta [1] >> 2. Starting Red Hat CDK and OpenShift 3 in JBoss Developer Studio 9.1 [2] >> >> [1] https://youtu.be/dMWAguol3as >> [2] https://www.youtube.com/watch?v=h_FACXXl94g >> >> >> Regards, >> Budh Ram Gurung >> Software Engineer - Dev Tools >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> >> > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools /max http://about.me/maxandersen From bsutter at redhat.com Tue May 10 20:02:03 2016 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 10 May 2016 16:02:03 -0400 Subject: [Devtools] Developer Studio + CDK screencasts In-Reply-To: <7904723C-DF0D-497E-A554-8A3E15C66EE5@redhat.com> References: <7904723C-DF0D-497E-A554-8A3E15C66EE5@redhat.com> Message-ID: On Tue, May 10, 2016 at 12:05 PM, Max Rydahl Andersen wrote: > On 10 May 2016, at 18:00, Burr Sutter wrote: > > > Awesome stuff, we should send these (and the future updates) > around...often > > :-) > > Every three weeks there are 3 hours of demo. Enough for you ? :) > I am referring to the publication side...how to broadcast these things to bigger audiences and rebroadcast them again. For instance, if we are getting 3 hours of great demo content every 3 weeks (1 hour per week run rate), we could easily be "marketing" 1 hour a week, perhaps repeating things based on quality of the demo, etc. > > /max > > > > > On Tue, May 10, 2016 at 11:42 AM, Budh Gurung > wrote: > > > >> Hello, > >> > >> Following are the two screencasts shared by Alexey after having > discussion > >> with him > >> over Developer studio and CDK. > >> > >> 1. Red Hat JBoss Developer Studio Platform Installer. Beta [1] > >> 2. Starting Red Hat CDK and OpenShift 3 in JBoss Developer Studio 9.1 > [2] > >> > >> [1] https://youtu.be/dMWAguol3as > >> [2] https://www.youtube.com/watch?v=h_FACXXl94g > >> > >> > >> Regards, > >> Budh Ram Gurung > >> Software Engineer - Dev Tools > >> > >> _______________________________________________ > >> Devtools mailing list > >> Devtools at redhat.com > >> https://www.redhat.com/mailman/listinfo/devtools > >> > >> > > > > _______________________________________________ > > Devtools mailing list > > Devtools at redhat.com > > https://www.redhat.com/mailman/listinfo/devtools > > > /max > http://about.me/maxandersen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Wed May 11 14:43:28 2016 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 11 May 2016 10:43:28 -0400 Subject: [Devtools] OpenShift 3.2 Message-ID: What is the plan for getting 3.2 into the CDK? -------------- next part -------------- An HTML attachment was scrubbed... URL: From prkumar at redhat.com Wed May 11 15:02:33 2016 From: prkumar at redhat.com (Praveen Kumar) Date: Wed, 11 May 2016 11:02:33 -0400 (EDT) Subject: [Devtools] OpenShift 3.2 In-Reply-To: References: Message-ID: <1453774426.50060698.1462978953808.JavaMail.zimbra@redhat.com> ----- Original Message ----- | From: "Burr Sutter" | To: devtools at redhat.com | Sent: Wednesday, May 11, 2016 8:13:28 PM | Subject: [Devtools] OpenShift 3.2 | | What is the plan for getting 3.2 into the CDK? For testing purpose you can use vagrant file available on redhat-developer-tooling github[0]. You have to set *OPENSHIFT_VAGRANT_USE_OSE_3_2=true* environment variable before doing *vagant up*. We still don't have any CDK build to cache OSE-3.2 images because of a issue with brew[1], we will try again if that is resolved now. [0] https://github.com/redhat-developer-tooling/openshift-vagrant/blob/master/cdk-v2/Vagrantfile [1] https://projects.engineering.redhat.com/browse/RCM-1329 -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen From lmohanty at redhat.com Wed May 11 15:33:22 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Wed, 11 May 2016 21:03:22 +0530 Subject: [Devtools] OpenShift 3.2 In-Reply-To: <1453774426.50060698.1462978953808.JavaMail.zimbra@redhat.com> References: <1453774426.50060698.1462978953808.JavaMail.zimbra@redhat.com> Message-ID: <9a72fde3-489d-af01-aeee-afa7e5eaac92@redhat.com> On 05/11/2016 08:32 PM, Praveen Kumar wrote: > > ----- Original Message ----- > | From: "Burr Sutter" > | To: devtools at redhat.com > | Sent: Wednesday, May 11, 2016 8:13:28 PM > | Subject: [Devtools] OpenShift 3.2 > | > | What is the plan for getting 3.2 into the CDK? > > For testing purpose you can use vagrant file available on redhat-developer-tooling github[0]. You have to set *OPENSHIFT_VAGRANT_USE_OSE_3_2=true* environment variable before doing *vagant up*. We still don't have any CDK build to cache OSE-3.2 images because of a issue with brew[1], we will try again if that is resolved now. > > [0] https://github.com/redhat-developer-tooling/openshift-vagrant/blob/master/cdk-v2/Vagrantfile > [1] https://projects.engineering.redhat.com/browse/RCM-1329 > Burr, The above issue came because we tried to use the docker registry which hosts the nightly 3.2 builds. Post OSE 3.2 GA and it is available from Red Hat registry it would be relatively easy for us to cache it in to CDK. Do you need nightly OSE 3.2 builds in nightly/weekly CDK builds or OSE 3.2 GA version? Thanks, Lala From bsutter at redhat.com Wed May 11 15:35:39 2016 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 11 May 2016 11:35:39 -0400 Subject: [Devtools] OpenShift 3.2 In-Reply-To: <9a72fde3-489d-af01-aeee-afa7e5eaac92@redhat.com> References: <1453774426.50060698.1462978953808.JavaMail.zimbra@redhat.com> <9a72fde3-489d-af01-aeee-afa7e5eaac92@redhat.com> Message-ID: On Wed, May 11, 2016 at 11:33 AM, Lalatendu Mohanty wrote: > On 05/11/2016 08:32 PM, Praveen Kumar wrote: > >> >> ----- Original Message ----- >> | From: "Burr Sutter" >> | To: devtools at redhat.com >> | Sent: Wednesday, May 11, 2016 8:13:28 PM >> | Subject: [Devtools] OpenShift 3.2 >> | >> | What is the plan for getting 3.2 into the CDK? >> >> For testing purpose you can use vagrant file available on >> redhat-developer-tooling github[0]. You have to set >> *OPENSHIFT_VAGRANT_USE_OSE_3_2=true* environment variable before doing >> *vagant up*. We still don't have any CDK build to cache OSE-3.2 images >> because of a issue with brew[1], we will try again if that is resolved now. >> >> [0] >> https://github.com/redhat-developer-tooling/openshift-vagrant/blob/master/cdk-v2/Vagrantfile >> [1] https://projects.engineering.redhat.com/browse/RCM-1329 >> >> Burr, > > The above issue came because we tried to use the docker registry which > hosts the nightly 3.2 builds. Post OSE 3.2 GA and it is available from Red > Hat registry it would be relatively easy for us to cache it in to CDK. > > Do you need nightly OSE 3.2 builds in nightly/weekly CDK builds or OSE 3.2 > GA version? > I would be comfortable with the GA version. Just looking for the timing of the deliverable. I am trying to push many other parties to consider the CDK as a "first-class citizen" for running their stuff (e.g. Vert.x, Hawkular, APIMan, Fabric8) but often those teams want the "latest & greatest". > > Thanks, > > Lala > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmuir at redhat.com Fri May 13 12:26:16 2016 From: pmuir at redhat.com (Pete Muir) Date: Fri, 13 May 2016 13:26:16 +0100 Subject: [Devtools] OpenShift 3.2 In-Reply-To: References: <1453774426.50060698.1462978953808.JavaMail.zimbra@redhat.com> <9a72fde3-489d-af01-aeee-afa7e5eaac92@redhat.com> Message-ID: ADB may make more sense for the teams you mention as it contains purely upstream bits. On 11 May 2016 at 16:35, Burr Sutter wrote: > > > On Wed, May 11, 2016 at 11:33 AM, Lalatendu Mohanty > wrote: >> >> On 05/11/2016 08:32 PM, Praveen Kumar wrote: >>> >>> >>> ----- Original Message ----- >>> | From: "Burr Sutter" >>> | To: devtools at redhat.com >>> | Sent: Wednesday, May 11, 2016 8:13:28 PM >>> | Subject: [Devtools] OpenShift 3.2 >>> | >>> | What is the plan for getting 3.2 into the CDK? >>> >>> For testing purpose you can use vagrant file available on >>> redhat-developer-tooling github[0]. You have to set >>> *OPENSHIFT_VAGRANT_USE_OSE_3_2=true* environment variable before doing >>> *vagant up*. We still don't have any CDK build to cache OSE-3.2 images >>> because of a issue with brew[1], we will try again if that is resolved now. >>> >>> [0] >>> https://github.com/redhat-developer-tooling/openshift-vagrant/blob/master/cdk-v2/Vagrantfile >>> [1] https://projects.engineering.redhat.com/browse/RCM-1329 >>> >> Burr, >> >> The above issue came because we tried to use the docker registry which >> hosts the nightly 3.2 builds. Post OSE 3.2 GA and it is available from Red >> Hat registry it would be relatively easy for us to cache it in to CDK. >> >> Do you need nightly OSE 3.2 builds in nightly/weekly CDK builds or OSE 3.2 >> GA version? > > > I would be comfortable with the GA version. Just looking for the timing of > the deliverable. I am trying to push many other parties to consider the > CDK as a "first-class citizen" for running their stuff (e.g. Vert.x, > Hawkular, APIMan, Fabric8) but often those teams want the "latest & > greatest". > >> >> >> Thanks, >> >> Lala >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools > > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > From bsutter at redhat.com Sat May 14 21:33:59 2016 From: bsutter at redhat.com (Burr Sutter) Date: Sat, 14 May 2016 17:33:59 -0400 Subject: [Devtools] Cordova Tooling Message-ID: I see have folks looking at the Cordova tutorial videos I published a long time ago https://www.youtube.com/watch?v=FstGLMr3W8s&lc=z12qdd0g3u35svcji04cdbfh1xetclqpa3o Can someone double-check that the current tools sync up with the video? I have not tried these same steps in well over a year. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gercan at redhat.com Sat May 14 21:42:54 2016 From: gercan at redhat.com (Gorkem Ercan) Date: Sat, 14 May 2016 17:42:54 -0400 Subject: [Devtools] Cordova Tooling In-Reply-To: References: Message-ID: <4A165846-912D-4AC3-A19C-84C87CCBDB06@redhat.com> The video you have linked looks OK at a glance. We now use Cordova CLI directly for cordova plugin management. It would be best if the first video on the series tell about cordova cli requirement. ? Gorkem On 14 May 2016, at 17:33, Burr Sutter wrote: > I see have folks looking at the Cordova tutorial videos I published a > long > time ago > https://www.youtube.com/watch?v=FstGLMr3W8s&lc=z12qdd0g3u35svcji04cdbfh1xetclqpa3o > > Can someone double-check that the current tools sync up with the > video? I > have not tried these same steps in well over a year. > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From ibuziuk at redhat.com Mon May 16 10:01:39 2016 From: ibuziuk at redhat.com (Ilya Buziuk) Date: Mon, 16 May 2016 12:01:39 +0200 Subject: [Devtools] Cordova Tooling In-Reply-To: <4A165846-912D-4AC3-A19C-84C87CCBDB06@redhat.com> References: <4A165846-912D-4AC3-A19C-84C87CCBDB06@redhat.com> Message-ID: >From the CordovaSim perspective the tutorials should be fine - I tested CordovaSim some time ago against cordova 5.x.x API. One thing to mention - Ripple (the upstream project CordovaSim falls back on) was retired from Apache incubation due to lack of activity and was moved to another non-apache repository[1] for further maintenance / development. [1] https://github.com/ripple-emulator On Sat, May 14, 2016 at 11:42 PM, Gorkem Ercan wrote: > > The video you have linked looks OK at a glance. > We now use Cordova CLI directly for cordova plugin management. > It would be best if the first video on the series tell about cordova cli > requirement. > ? > Gorkem > > > On 14 May 2016, at 17:33, Burr Sutter wrote: > > I see have folks looking at the Cordova tutorial videos I published a long >> time ago >> >> https://www.youtube.com/watch?v=FstGLMr3W8s&lc=z12qdd0g3u35svcji04cdbfh1xetclqpa3o >> >> Can someone double-check that the current tools sync up with the video? I >> have not tried these same steps in well over a year. >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Mon May 16 12:10:37 2016 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 16 May 2016 08:10:37 -0400 Subject: [Devtools] Cordova Tooling In-Reply-To: References: <4A165846-912D-4AC3-A19C-84C87CCBDB06@redhat.com> Message-ID: This one fellow seems to be having a problem getting an REST endpoint to work "+Burr Sutter hey thank for the fast answer :) . I switched to a online Rest-Demo Server("http://jsonplaceholder.typicode.com/users" They have users as well) and tried at again in the Cordova sim it was fine on my Device not. :(" https://www.youtube.com/watch?v=FstGLMr3W8s&index=2&list=PLuWlr4oKSRUb7T69rE557VCRFNFeZMZud It has been a long time since I looked at Cordova, has RESTful interactions been "locked down" in some way that requires some form of additional plug-in or configuration? If you have a quick answer, please respond via the comments :-) On Mon, May 16, 2016 at 6:01 AM, Ilya Buziuk wrote: > From the CordovaSim perspective the tutorials should be fine - I tested > CordovaSim some time ago against cordova 5.x.x API. > One thing to mention - Ripple (the upstream project CordovaSim falls back > on) was retired from Apache incubation due to lack of activity and was > moved to another non-apache repository[1] for further maintenance / > development. > > [1] https://github.com/ripple-emulator > > On Sat, May 14, 2016 at 11:42 PM, Gorkem Ercan wrote: > >> >> The video you have linked looks OK at a glance. >> We now use Cordova CLI directly for cordova plugin management. >> It would be best if the first video on the series tell about cordova cli >> requirement. >> ? >> Gorkem >> >> >> On 14 May 2016, at 17:33, Burr Sutter wrote: >> >> I see have folks looking at the Cordova tutorial videos I published a long >>> time ago >>> >>> https://www.youtube.com/watch?v=FstGLMr3W8s&lc=z12qdd0g3u35svcji04cdbfh1xetclqpa3o >>> >>> Can someone double-check that the current tools sync up with the video? >>> I >>> have not tried these same steps in well over a year. >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> https://www.redhat.com/mailman/listinfo/devtools >>> >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ibuziuk at redhat.com Mon May 16 12:25:39 2016 From: ibuziuk at redhat.com (Ilya Buziuk) Date: Mon, 16 May 2016 14:25:39 +0200 Subject: [Devtools] Cordova Tooling In-Reply-To: References: <4A165846-912D-4AC3-A19C-84C87CCBDB06@redhat.com> Message-ID: Hello, Burr I have responded in the comment for youtube video. I guess the Whitelist[1] configuration is smth. that should be tuned to make it work on the device. It works for CordovaSim due to different way of handling CORS[2]. [1] https://cordova.apache.org/docs/en/4.0.0/guide/appdev/whitelist/index.html [2] http://tools.jboss.org/blog/2015-03-02-cordovasim-cross-domain-ajax.html On Mon, May 16, 2016 at 2:10 PM, Burr Sutter wrote: > This one fellow seems to be having a problem getting an REST endpoint to > work > > "+Burr Sutter hey thank for the fast answer :) . I switched to a online > Rest-Demo Server("http://jsonplaceholder.typicode.com/users" They have > users as well) and tried at again in the Cordova sim it was fine on my > Device not. :(" > > > https://www.youtube.com/watch?v=FstGLMr3W8s&index=2&list=PLuWlr4oKSRUb7T69rE557VCRFNFeZMZud > > It has been a long time since I looked at Cordova, has RESTful > interactions been "locked down" in some way that requires some form of > additional plug-in or configuration? > > If you have a quick answer, please respond via the comments :-) > > > > On Mon, May 16, 2016 at 6:01 AM, Ilya Buziuk wrote: > >> From the CordovaSim perspective the tutorials should be fine - I tested >> CordovaSim some time ago against cordova 5.x.x API. >> One thing to mention - Ripple (the upstream project CordovaSim falls back >> on) was retired from Apache incubation due to lack of activity and was >> moved to another non-apache repository[1] for further maintenance / >> development. >> >> [1] https://github.com/ripple-emulator >> >> On Sat, May 14, 2016 at 11:42 PM, Gorkem Ercan wrote: >> >>> >>> The video you have linked looks OK at a glance. >>> We now use Cordova CLI directly for cordova plugin management. >>> It would be best if the first video on the series tell about cordova cli >>> requirement. >>> ? >>> Gorkem >>> >>> >>> On 14 May 2016, at 17:33, Burr Sutter wrote: >>> >>> I see have folks looking at the Cordova tutorial videos I published a >>>> long >>>> time ago >>>> >>>> https://www.youtube.com/watch?v=FstGLMr3W8s&lc=z12qdd0g3u35svcji04cdbfh1xetclqpa3o >>>> >>>> Can someone double-check that the current tools sync up with the >>>> video? I >>>> have not tried these same steps in well over a year. >>>> _______________________________________________ >>>> Devtools mailing list >>>> Devtools at redhat.com >>>> https://www.redhat.com/mailman/listinfo/devtools >>>> >>> >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> https://www.redhat.com/mailman/listinfo/devtools >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Mon May 16 12:28:24 2016 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 16 May 2016 08:28:24 -0400 Subject: [Devtools] Cordova Tooling In-Reply-To: References: <4A165846-912D-4AC3-A19C-84C87CCBDB06@redhat.com> Message-ID: Thank you! On Mon, May 16, 2016 at 8:25 AM, Ilya Buziuk wrote: > Hello, Burr > I have responded in the comment for youtube video. I guess > the Whitelist[1] configuration is smth. that should be tuned to make it > work on the device. It works for CordovaSim due to different way of > handling CORS[2]. > > [1] > https://cordova.apache.org/docs/en/4.0.0/guide/appdev/whitelist/index.html > [2] > http://tools.jboss.org/blog/2015-03-02-cordovasim-cross-domain-ajax.html > > On Mon, May 16, 2016 at 2:10 PM, Burr Sutter wrote: > >> This one fellow seems to be having a problem getting an REST endpoint to >> work >> >> "+Burr Sutter hey thank for the fast answer :) . I switched to a online >> Rest-Demo Server("http://jsonplaceholder.typicode.com/users" They have >> users as well) and tried at again in the Cordova sim it was fine on my >> Device not. :(" >> >> >> https://www.youtube.com/watch?v=FstGLMr3W8s&index=2&list=PLuWlr4oKSRUb7T69rE557VCRFNFeZMZud >> >> It has been a long time since I looked at Cordova, has RESTful >> interactions been "locked down" in some way that requires some form of >> additional plug-in or configuration? >> >> If you have a quick answer, please respond via the comments :-) >> >> >> >> On Mon, May 16, 2016 at 6:01 AM, Ilya Buziuk wrote: >> >>> From the CordovaSim perspective the tutorials should be fine - I tested >>> CordovaSim some time ago against cordova 5.x.x API. >>> One thing to mention - Ripple (the upstream project CordovaSim falls >>> back on) was retired from Apache incubation due to lack of activity and was >>> moved to another non-apache repository[1] for further maintenance / >>> development. >>> >>> [1] https://github.com/ripple-emulator >>> >>> On Sat, May 14, 2016 at 11:42 PM, Gorkem Ercan >>> wrote: >>> >>>> >>>> The video you have linked looks OK at a glance. >>>> We now use Cordova CLI directly for cordova plugin management. >>>> It would be best if the first video on the series tell about cordova >>>> cli requirement. >>>> ? >>>> Gorkem >>>> >>>> >>>> On 14 May 2016, at 17:33, Burr Sutter wrote: >>>> >>>> I see have folks looking at the Cordova tutorial videos I published a >>>>> long >>>>> time ago >>>>> >>>>> https://www.youtube.com/watch?v=FstGLMr3W8s&lc=z12qdd0g3u35svcji04cdbfh1xetclqpa3o >>>>> >>>>> Can someone double-check that the current tools sync up with the >>>>> video? I >>>>> have not tried these same steps in well over a year. >>>>> _______________________________________________ >>>>> Devtools mailing list >>>>> Devtools at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/devtools >>>>> >>>> >>>> _______________________________________________ >>>> Devtools mailing list >>>> Devtools at redhat.com >>>> https://www.redhat.com/mailman/listinfo/devtools >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdrage at redhat.com Mon May 16 14:00:39 2016 From: cdrage at redhat.com (Charlie Drage) Date: Mon, 16 May 2016 10:00:39 -0400 Subject: [Devtools] Atomic App / Nulecule Weekly IRC Meeting Message-ID: <20160516140039.GA1@f7c8af10d252> No blockers this week. Just a week of updates to the face-to-face in India. See log below! https://meetbot.fedoraproject.org/nulecule/2016-05-16/weekly_nulecule_irc_meeting.2016-05-16-13.34.log.html -- Charlie Drage Red Hat - OSAS Team / Project Atomic 4096R / 0x9B3B446C http://pgp.mit.edu/pks/lookup?op=get&search=0x622CDF119B3B446C From dshah at redhat.com Mon May 16 14:22:06 2016 From: dshah at redhat.com (Dharmit Shah) Date: Mon, 16 May 2016 19:52:06 +0530 Subject: [Devtools] Automate ADB Provider Tests Message-ID: Hello all, Almost every time a new version of ADB [1] is about to be released, Lala opens up an issue on GitHub [2] asking people to test out some basic things. To me, he asks to check if the Mesos provider is working as expected. It's generally a simple task that can be done in under 30 minutes. I thought about automating this job, so that next time Lala has a release candidate that he wants to be tested just before release, he can go to a Jenkins UI and test it out at a click of button. With my recently acquired knowledge of Jenkins and CentOS CI, I setup a parameterized job [3] which requires one to enter the URL of the rc build and trigger the job. It uses Python unittests and does a few basic tasks/checks like: 1. pull the box from mentioned URL 2. does `vagrant up` to bring up the box 3. checks if required services (zookeeper, marathon, mesos-master and mesos-slave) are running 4. start an atomicapp 5. destroy the vagrant box The pull request for above mentioned job can be found at [4]. I'd love to get some feedback on it to help it get merged. If required, I can do a quick demo about this on Wednesday (2016-05-18) at 1500 IST. [1] https://github.com/projectatomic/adb-atomic-developer-bundle [2] https://github.com/projectatomic/adb-atomic-developer-bundle/issues/363#issuecomment-214976462 [3] https://ci.centos.org/job/adb-release-mesos/ [4] https://github.com/projectatomic/adb-tests/pull/31 Regards, Dharmit. From bgurung at redhat.com Mon May 16 14:28:45 2016 From: bgurung at redhat.com (Budh Gurung) Date: Mon, 16 May 2016 19:58:45 +0530 Subject: [Devtools] Automate ADB Provider Tests In-Reply-To: References: Message-ID: On Mon, May 16, 2016 at 7:52 PM, Dharmit Shah wrote: > Hello all, > > Almost every time a new version of ADB [1] is about to be released, Lala > opens up an issue on GitHub [2] asking people to test out some basic > things. To me, he asks to check if the Mesos provider is working as > expected. It's generally a simple task that can be done in under 30 minutes. > > I thought about automating this job, so that next time Lala has a release > candidate that he wants to be tested just before release, he can go to a > Jenkins UI and test it out at a click of button. > > With my recently acquired knowledge of Jenkins and CentOS CI, I setup a > parameterized job [3] which requires one to enter the URL of the rc build > and trigger the job. It uses Python unittests and does a few basic > tasks/checks like: > > 1. pull the box from mentioned URL > 2. does `vagrant up` to bring up the box > 3. checks if required services (zookeeper, marathon, mesos-master and > mesos-slave) are running > 4. start an atomicapp > 5. destroy the vagrant box > > The pull request for above mentioned job can be found at [4]. I'd love to > get some feedback on it to help it get merged. > > If required, I can do a quick demo about this on Wednesday (2016-05-18) at > 1500 IST. > +1 for quick demo. > [1] https://github.com/projectatomic/adb-atomic-developer-bundle > [2] > https://github.com/projectatomic/adb-atomic-developer-bundle/issues/363#issuecomment-214976462 > [3] https://ci.centos.org/job/adb-release-mesos/ > [4] https://github.com/projectatomic/adb-tests/pull/31 > > Regards, > Dharmit. > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools Regards, Budh Ram Gurung Software Engineer - Dev Tools -------------- next part -------------- An HTML attachment was scrubbed... URL: From akashche at redhat.com Tue May 17 12:20:57 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 17 May 2016 13:20:57 +0100 Subject: [Devtools] WixGen - Java API for WiX MSI installers using JAXB Message-ID: <573B0CA9.8090606@redhat.com> Hi devtools developers, I've been working on a MSI installer for OpenJDK (recently posted details about OpenJDK on windows to internal devtools list). For that installer I created a WixGen utility (github project link [1]) that generates .wxs XML descriptors for WiX. WiX is an open-source project from Outercurve Foundation [1], it is a de-facto standard for MSI installers. It is written in C++ and C#, so it doesn't have a direct Java API. Installer's "input descriptor" should be written in XML format and then processed by WiX tools to generate a MSI. Using WiX' XSD-schema [3] we can generate [4] JAXB classes [5] from that schema that effectively gives us a Java API for generating XML descriptors. JAXB-generated API is by no means elegant (example [6]), but quite flexible - all WiX features can be used though it. wixgen.jar utility (created on top of JAXB API) itself is not of much interest - it is basically a limited (albeit fine-tuned) NIH version of the WiX' heat utility [7]. But JAXB classes IMO may be useful for developing additional tooling for creating MSI installers. For example Maven plugin can be developed to build MSI installers for Java applications. And more features can be packed into such plugin: for example some time ago I was doing a Maven plugin [8] for installers (non-MSI) to install Java apps as Windows Services using ProcRun/PrunSrv [9] tools. The same Windows Services support can be done with WiX. And as AFAIK main author of ProcRun/PrunSrv works for RH - such plugin can be supported quite well. Another example is a possible Eclipse plugin for WiX. VisualStudio has one [10], probably something similar can be developed for Eclipse. And while WiX is Windows-only, there exists a msitools project [11] in Fedora that supports a subset of WiX' XSD-schema. Currently there are no plans for the further development of WixGen, as it currently covers required features for OpenJDK installer (link to MSI [12] - as an example generated by WixGen). But if there will be some interest in creating additional tooling for MSI installers - I can assist in such efforts. [1] http://www.outercurve.org/ [2] https://github.com/akashche/wixgen [3] https://github.com/akashche/wixgen/blob/c77cf791399b6b0a9304f4deec6b7aa14b80b280/wixgen-jaxb/src/main/resources/com/redhat/akashche/wixgen/jaxb/wix.xsd [4] https://github.com/akashche/wixgen/blob/c77cf791399b6b0a9304f4deec6b7aa14b80b280/wixgen-jaxb/pom.xml#L37 [5] http://akashche.github.io/wixgen/wixgen-jaxb/apidocs/ [6] https://github.com/akashche/wixgen/blob/19bd1a0b7f24df5034a868f37eeff17c5a61d0df/wixgen-dir/src/main/java/com/redhat/akashche/wixgen/dir/DirectoryGenerator.java#L48 [7] http://wixtoolset.org/documentation/manual/v3/overview/heat.html [8] https://github.com/alexkasko/windows-service-installer [9] http://commons.apache.org/proper/commons-daemon/procrun.html [10] https://visualstudiogallery.msdn.microsoft.com/b6868002-9770-4479-80a7-259de34df527 [11] https://wiki.gnome.org/msitools [12] https://github.com/ojdkbuild/ojdkbuild/releases/download/1.8.0.91-3/java-1.8.0-openjdk-1.8.0.91-3.b14.windows.x86_64.msi -- -Alex From tmancini at redhat.com Tue May 17 12:23:27 2016 From: tmancini at redhat.com (Todd Mancini) Date: Tue, 17 May 2016 08:23:27 -0400 Subject: [Devtools] WixGen - Java API for WiX MSI installers using JAXB In-Reply-To: <573B0CA9.8090606@redhat.com> References: <573B0CA9.8090606@redhat.com> Message-ID: FYI, WiX has been handed over to the .NET Foundation (of which we are a member, of course): http://www.dotnetfoundation.org/blog/wix-toolset-welcome On Tue, May 17, 2016 at 8:20 AM, Alex Kashchenko wrote: > Hi devtools developers, > > I've been working on a MSI installer for OpenJDK (recently posted details > about OpenJDK on windows to internal devtools list). For that installer I > created a WixGen utility (github project link [1]) that generates .wxs XML > descriptors for WiX. > > WiX is an open-source project from Outercurve Foundation [1], it is a > de-facto standard for MSI installers. It is written in C++ and C#, so it > doesn't have a direct Java API. Installer's "input descriptor" should be > written in XML format and then processed by WiX tools to generate a MSI. > > Using WiX' XSD-schema [3] we can generate [4] JAXB classes [5] from that > schema that effectively gives us a Java API for generating XML descriptors. > JAXB-generated API is by no means elegant (example [6]), but quite flexible > - all WiX features can be used though it. > > wixgen.jar utility (created on top of JAXB API) itself is not of much > interest - it is basically a limited (albeit fine-tuned) NIH version of the > WiX' heat utility [7]. But JAXB classes IMO may be useful for developing > additional tooling for creating MSI installers. > > For example Maven plugin can be developed to build MSI installers for Java > applications. And more features can be packed into such plugin: for example > some time ago I was doing a Maven plugin [8] for installers (non-MSI) to > install Java apps as Windows Services using ProcRun/PrunSrv [9] tools. The > same Windows Services support can be done with WiX. And as AFAIK main > author of ProcRun/PrunSrv works for RH - such plugin can be supported quite > well. > > Another example is a possible Eclipse plugin for WiX. VisualStudio has one > [10], probably something similar can be developed for Eclipse. And while > WiX is Windows-only, there exists a msitools project [11] in Fedora that > supports a subset of WiX' XSD-schema. > > Currently there are no plans for the further development of WixGen, as it > currently covers required features for OpenJDK installer (link to MSI [12] > - as an example generated by WixGen). But if there will be some interest in > creating additional tooling for MSI installers - I can assist in such > efforts. > > > [1] http://www.outercurve.org/ > [2] https://github.com/akashche/wixgen > [3] > https://github.com/akashche/wixgen/blob/c77cf791399b6b0a9304f4deec6b7aa14b80b280/wixgen-jaxb/src/main/resources/com/redhat/akashche/wixgen/jaxb/wix.xsd > [4] > https://github.com/akashche/wixgen/blob/c77cf791399b6b0a9304f4deec6b7aa14b80b280/wixgen-jaxb/pom.xml#L37 > [5] http://akashche.github.io/wixgen/wixgen-jaxb/apidocs/ > [6] > https://github.com/akashche/wixgen/blob/19bd1a0b7f24df5034a868f37eeff17c5a61d0df/wixgen-dir/src/main/java/com/redhat/akashche/wixgen/dir/DirectoryGenerator.java#L48 > [7] http://wixtoolset.org/documentation/manual/v3/overview/heat.html > [8] https://github.com/alexkasko/windows-service-installer > [9] http://commons.apache.org/proper/commons-daemon/procrun.html > [10] > https://visualstudiogallery.msdn.microsoft.com/b6868002-9770-4479-80a7-259de34df527 > [11] https://wiki.gnome.org/msitools > [12] > https://github.com/ojdkbuild/ojdkbuild/releases/download/1.8.0.91-3/java-1.8.0-openjdk-1.8.0.91-3.b14.windows.x86_64.msi > > -- > -Alex > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshah at redhat.com Tue May 17 17:08:02 2016 From: dshah at redhat.com (Dharmit Shah) Date: Tue, 17 May 2016 22:38:02 +0530 Subject: [Devtools] Automate ADB Provider Tests In-Reply-To: References: Message-ID: On 05/16/2016 07:58 PM, Budh Gurung wrote: > +1 for quick demo. Ack, I'll do it tomorrow (2016-05-18) at 1500 IST on https://bluejeans.com/u/dshah62/ Regards, Dharmit. From lmohanty at redhat.com Tue May 17 17:43:20 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 17 May 2016 23:13:20 +0530 Subject: [Devtools] Cockpit in ADB Message-ID: Hi, We have added Cockpit packages to ADB as we thought it would add value to ADB users. With Cockpit GUI an user can do docker pulls , docker runs etc apart from system administration work. Cockpit also provides a web terminal which can used to run docker commands without logging in to the Vagrantbox (it is useful for Windows users as |vagrant ssh| does not work naively). How ever we are not sure whether it should be part of the default experience of ADB. So at this point the Cockpit service is not started by default. There is an open issue for this [1] and we are looking for feedback. [1] https://github.com/projectatomic/adb-atomic-developer-bundle/issues/389 Thanks, Lala -------------- next part -------------- An HTML attachment was scrubbed... URL: From dusty at dustymabe.com Wed May 18 03:27:07 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Tue, 17 May 2016 23:27:07 -0400 Subject: [Devtools] openshift is way too permissive in the CDK/ADB Message-ID: <573BE10B.7060707@dustymabe.com> Currently we are configuring openshift in the CDK/ADB to be more permissive than it should be when running containers. At [1] we are setting: oadm policy add-scc-to-group anyuid system:authenticated >From my experiments this means that containers run as anyuid and thus can be root, cc clayton for confirmation. What this means is that we are misleading users to thinking things will run in production OpenShift, when the production OpenShift most likely won't have things configured this way. We should probably not be doing this. Reverting this change will also mean that proposed demos, etc.. should be retested on the newer version meticulously. Dusty [1] https://github.com/projectatomic/adb-utils/blob/01adadd904dea98033c9c83d0648d90f5e8f2806/services/openshift/scripts/openshift_provision#L47 From ccoleman at redhat.com Wed May 18 11:10:58 2016 From: ccoleman at redhat.com (Clayton Coleman) Date: Wed, 18 May 2016 07:10:58 -0400 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <573BE10B.7060707@dustymabe.com> References: <573BE10B.7060707@dustymabe.com> Message-ID: <-4959106190020746004@unknownmsgid> It was a deliberate choice, predicated on other changes coming to Docker (user namespaces) plus the desire to ensure demos run. Ultimately, the CDK is a playground. Putting up chain link fences around the playground sends the wrong message. I'd prefer to have it easier to go between the levels in the short term than to ratchet it back. > On May 17, 2016, at 11:27 PM, Dusty Mabe wrote: > > > Currently we are configuring openshift in the CDK/ADB to be more > permissive than it should be when running containers. > > At [1] we are setting: > > oadm policy add-scc-to-group anyuid system:authenticated > > From my experiments this means that containers run as anyuid and thus > can be root, cc clayton for confirmation. > > What this means is that we are misleading users to thinking things > will run in production OpenShift, when the production OpenShift most > likely won't have things configured this way. > > We should probably not be doing this. Reverting this change will also > mean that proposed demos, etc.. should be retested on the newer version > meticulously. > > Dusty > > [1] https://github.com/projectatomic/adb-utils/blob/01adadd904dea98033c9c83d0648d90f5e8f2806/services/openshift/scripts/openshift_provision#L47 From aslak at redhat.com Wed May 18 11:18:58 2016 From: aslak at redhat.com (Aslak Knutsen) Date: Wed, 18 May 2016 13:18:58 +0200 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <-4959106190020746004@unknownmsgid> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> Message-ID: I think most teams at the Brno F2F were struggling with this. It works locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH engineers there, none knew 100% or was able to dig up a doc that explained why and how to fix it... This is/will be a massive pain point moving from Dev to Production. The very least we need some very clear, simple guides on how to make it work. -aslak- On Wed, May 18, 2016 at 1:10 PM, Clayton Coleman wrote: > It was a deliberate choice, predicated on other changes coming to > Docker (user namespaces) plus the desire to ensure demos run. > > Ultimately, the CDK is a playground. Putting up chain link fences > around the playground sends the wrong message. > > I'd prefer to have it easier to go between the levels in the short > term than to ratchet it back. > > > On May 17, 2016, at 11:27 PM, Dusty Mabe wrote: > > > > > > Currently we are configuring openshift in the CDK/ADB to be more > > permissive than it should be when running containers. > > > > At [1] we are setting: > > > > oadm policy add-scc-to-group anyuid system:authenticated > > > > From my experiments this means that containers run as anyuid and thus > > can be root, cc clayton for confirmation. > > > > What this means is that we are misleading users to thinking things > > will run in production OpenShift, when the production OpenShift most > > likely won't have things configured this way. > > > > We should probably not be doing this. Reverting this change will also > > mean that proposed demos, etc.. should be retested on the newer version > > meticulously. > > > > Dusty > > > > [1] > https://github.com/projectatomic/adb-utils/blob/01adadd904dea98033c9c83d0648d90f5e8f2806/services/openshift/scripts/openshift_provision#L47 > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manderse at redhat.com Wed May 18 11:31:41 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 18 May 2016 13:31:41 +0200 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> Message-ID: <1AC5961C-3F44-41AC-B79F-F901102FDC67@redhat.com> Yeah, if CDK was running with this enabled I would not be able to run anything in any meaningful timeframe on openshift. I wish there was a better way though. i.e. that I could set a flag for a specific deployment wether it should be allowed to run as root or not without making this a fully global flag. But in short - without this permission I don't see CDK/ADB being useful to anyone trying to use it for docker based development because dockerhub just has too many containers that requires it. /max > I think most teams at the Brno F2F were struggling with this. It works > locally, but semi-obscure failures when pushed 'live'. And out of the > 30 RH > engineers there, none knew 100% or was able to dig up a doc that > explained > why and how to fix it... > > This is/will be a massive pain point moving from Dev to Production. > The > very least we need some very clear, simple guides on how to make it > work. > > -aslak- > > On Wed, May 18, 2016 at 1:10 PM, Clayton Coleman > wrote: > >> It was a deliberate choice, predicated on other changes coming to >> Docker (user namespaces) plus the desire to ensure demos run. >> >> Ultimately, the CDK is a playground. Putting up chain link fences >> around the playground sends the wrong message. >> >> I'd prefer to have it easier to go between the levels in the short >> term than to ratchet it back. >> >>> On May 17, 2016, at 11:27 PM, Dusty Mabe >>> wrote: >>> >>> >>> Currently we are configuring openshift in the CDK/ADB to be more >>> permissive than it should be when running containers. >>> >>> At [1] we are setting: >>> >>> oadm policy add-scc-to-group anyuid system:authenticated >>> >>> From my experiments this means that containers run as anyuid and >>> thus >>> can be root, cc clayton for confirmation. >>> >>> What this means is that we are misleading users to thinking things >>> will run in production OpenShift, when the production OpenShift most >>> likely won't have things configured this way. >>> >>> We should probably not be doing this. Reverting this change will >>> also >>> mean that proposed demos, etc.. should be retested on the newer >>> version >>> meticulously. >>> >>> Dusty >>> >>> [1] >> https://github.com/projectatomic/adb-utils/blob/01adadd904dea98033c9c83d0648d90f5e8f2806/services/openshift/scripts/openshift_provision#L47 >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools /max http://about.me/maxandersen -------------- next part -------------- An HTML attachment was scrubbed... URL: From aslak at redhat.com Wed May 18 11:41:34 2016 From: aslak at redhat.com (Aslak Knutsen) Date: Wed, 18 May 2016 13:41:34 +0200 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <1AC5961C-3F44-41AC-B79F-F901102FDC67@redhat.com> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <1AC5961C-3F44-41AC-B79F-F901102FDC67@redhat.com> Message-ID: An index.openshift.org with proper images similar to 'index.docker.org' would be a start :) On Wed, May 18, 2016 at 1:31 PM, Max Rydahl Andersen wrote: > Yeah, if CDK was running with this enabled I would not be able to run > anything > in any meaningful timeframe on openshift. > > I wish there was a better way though. > > i.e. that I could set a flag for a specific deployment wether > it should be allowed to run as root or not without making this a fully > global flag. > > But in short - without this permission I don't see CDK/ADB being useful to > anyone > trying to use it for docker based development because dockerhub just has > too many > containers that requires it. > > /max > > I think most teams at the Brno F2F were struggling with this. It works > locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH > engineers there, none knew 100% or was able to dig up a doc that explained > why and how to fix it... > > This is/will be a massive pain point moving from Dev to Production. The > very least we need some very clear, simple guides on how to make it work. > > -aslak- > > On Wed, May 18, 2016 at 1:10 PM, Clayton Coleman > wrote: > >> It was a deliberate choice, predicated on other changes coming to >> Docker (user namespaces) plus the desire to ensure demos run. >> >> Ultimately, the CDK is a playground. Putting up chain link fences >> around the playground sends the wrong message. >> >> I'd prefer to have it easier to go between the levels in the short >> term than to ratchet it back. >> >> > On May 17, 2016, at 11:27 PM, Dusty Mabe wrote: >> > >> > >> > Currently we are configuring openshift in the CDK/ADB to be more >> > permissive than it should be when running containers. >> > >> > At [1] we are setting: >> > >> > oadm policy add-scc-to-group anyuid system:authenticated >> > >> > From my experiments this means that containers run as anyuid and thus >> > can be root, cc clayton for confirmation. >> > >> > What this means is that we are misleading users to thinking things >> > will run in production OpenShift, when the production OpenShift most >> > likely won't have things configured this way. >> > >> > We should probably not be doing this. Reverting this change will also >> > mean that proposed demos, etc.. should be retested on the newer version >> > meticulously. >> > >> > Dusty >> > >> > [1] >> https://github.com/projectatomic/adb-utils/blob/01adadd904dea98033c9c83d0648d90f5e8f2806/services/openshift/scripts/openshift_provision#L47 >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> > > ------------------------------ > > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > /max > http://about.me/maxandersen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Wed May 18 11:55:20 2016 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 18 May 2016 07:55:20 -0400 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <1AC5961C-3F44-41AC-B79F-F901102FDC67@redhat.com> Message-ID: On average, the current CDK is move of an evaluator's tool, not a for-real dev tool. In a for-real dev scenario some super user would have configured a team server and prepopulated it with "proper" base images, not ones from Docker Hub. If we locked down the CDK to only production ready base images then it would fail for the average evaluator who is trying their first experience with Linux containers. On Wednesday, May 18, 2016, Aslak Knutsen wrote: > An index.openshift.org with proper images similar to 'index.docker.org' > would be a start :) > > On Wed, May 18, 2016 at 1:31 PM, Max Rydahl Andersen > wrote: > >> Yeah, if CDK was running with this enabled I would not be able to run >> anything >> in any meaningful timeframe on openshift. >> >> I wish there was a better way though. >> >> i.e. that I could set a flag for a specific deployment wether >> it should be allowed to run as root or not without making this a fully >> global flag. >> >> But in short - without this permission I don't see CDK/ADB being useful >> to anyone >> trying to use it for docker based development because dockerhub just has >> too many >> containers that requires it. >> >> /max >> >> I think most teams at the Brno F2F were struggling with this. It works >> locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH >> engineers there, none knew 100% or was able to dig up a doc that explained >> why and how to fix it... >> >> This is/will be a massive pain point moving from Dev to Production. The >> very least we need some very clear, simple guides on how to make it work. >> >> -aslak- >> >> On Wed, May 18, 2016 at 1:10 PM, Clayton Coleman > > wrote: >> >>> It was a deliberate choice, predicated on other changes coming to >>> Docker (user namespaces) plus the desire to ensure demos run. >>> >>> Ultimately, the CDK is a playground. Putting up chain link fences >>> around the playground sends the wrong message. >>> >>> I'd prefer to have it easier to go between the levels in the short >>> term than to ratchet it back. >>> >>> > On May 17, 2016, at 11:27 PM, Dusty Mabe >> > wrote: >>> > >>> > >>> > Currently we are configuring openshift in the CDK/ADB to be more >>> > permissive than it should be when running containers. >>> > >>> > At [1] we are setting: >>> > >>> > oadm policy add-scc-to-group anyuid system:authenticated >>> > >>> > From my experiments this means that containers run as anyuid and thus >>> > can be root, cc clayton for confirmation. >>> > >>> > What this means is that we are misleading users to thinking things >>> > will run in production OpenShift, when the production OpenShift most >>> > likely won't have things configured this way. >>> > >>> > We should probably not be doing this. Reverting this change will also >>> > mean that proposed demos, etc.. should be retested on the newer version >>> > meticulously. >>> > >>> > Dusty >>> > >>> > [1] >>> https://github.com/projectatomic/adb-utils/blob/01adadd904dea98033c9c83d0648d90f5e8f2806/services/openshift/scripts/openshift_provision#L47 >>> >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> >>> https://www.redhat.com/mailman/listinfo/devtools >>> >> >> ------------------------------ >> >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> >> /max >> http://about.me/maxandersen >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccoleman at redhat.com Wed May 18 12:12:27 2016 From: ccoleman at redhat.com (Clayton Coleman) Date: Wed, 18 May 2016 08:12:27 -0400 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <1AC5961C-3F44-41AC-B79F-F901102FDC67@redhat.com> Message-ID: <6774920658174145209@unknownmsgid> This is a usecase "oc debug" was designed to solve. 1. Set your app up normally (as root) 2. Get it working 3. Run "oc debug dc/foo --as-user=xxx" 4. See that it works or not I'll add that flag, although it will be a while before it makes it into an origin release. On May 18, 2016, at 7:55 AM, Burr Sutter wrote: On average, the current CDK is move of an evaluator's tool, not a for-real dev tool. In a for-real dev scenario some super user would have configured a team server and prepopulated it with "proper" base images, not ones from Docker Hub. If we locked down the CDK to only production ready base images then it would fail for the average evaluator who is trying their first experience with Linux containers. On Wednesday, May 18, 2016, Aslak Knutsen wrote: > An index.openshift.org with proper images similar to 'index.docker.org' > would be a start :) > > On Wed, May 18, 2016 at 1:31 PM, Max Rydahl Andersen > wrote: > >> Yeah, if CDK was running with this enabled I would not be able to run >> anything >> in any meaningful timeframe on openshift. >> >> I wish there was a better way though. >> >> i.e. that I could set a flag for a specific deployment wether >> it should be allowed to run as root or not without making this a fully >> global flag. >> >> But in short - without this permission I don't see CDK/ADB being useful >> to anyone >> trying to use it for docker based development because dockerhub just has >> too many >> containers that requires it. >> >> /max >> >> I think most teams at the Brno F2F were struggling with this. It works >> locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH >> engineers there, none knew 100% or was able to dig up a doc that explained >> why and how to fix it... >> >> This is/will be a massive pain point moving from Dev to Production. The >> very least we need some very clear, simple guides on how to make it work. >> >> -aslak- >> >> On Wed, May 18, 2016 at 1:10 PM, Clayton Coleman > > wrote: >> >>> It was a deliberate choice, predicated on other changes coming to >>> Docker (user namespaces) plus the desire to ensure demos run. >>> >>> Ultimately, the CDK is a playground. Putting up chain link fences >>> around the playground sends the wrong message. >>> >>> I'd prefer to have it easier to go between the levels in the short >>> term than to ratchet it back. >>> >>> > On May 17, 2016, at 11:27 PM, Dusty Mabe >> > wrote: >>> > >>> > >>> > Currently we are configuring openshift in the CDK/ADB to be more >>> > permissive than it should be when running containers. >>> > >>> > At [1] we are setting: >>> > >>> > oadm policy add-scc-to-group anyuid system:authenticated >>> > >>> > From my experiments this means that containers run as anyuid and thus >>> > can be root, cc clayton for confirmation. >>> > >>> > What this means is that we are misleading users to thinking things >>> > will run in production OpenShift, when the production OpenShift most >>> > likely won't have things configured this way. >>> > >>> > We should probably not be doing this. Reverting this change will also >>> > mean that proposed demos, etc.. should be retested on the newer version >>> > meticulously. >>> > >>> > Dusty >>> > >>> > [1] >>> https://github.com/projectatomic/adb-utils/blob/01adadd904dea98033c9c83d0648d90f5e8f2806/services/openshift/scripts/openshift_provision#L47 >>> >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> >>> https://www.redhat.com/mailman/listinfo/devtools >>> >> >> ------------------------------ >> >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> >> /max >> http://about.me/maxandersen >> > > _______________________________________________ Devtools mailing list Devtools at redhat.com https://www.redhat.com/mailman/listinfo/devtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From dusty at dustymabe.com Wed May 18 12:28:26 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Wed, 18 May 2016 08:28:26 -0400 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <-4959106190020746004@unknownmsgid> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> Message-ID: <573C5FEA.8030705@dustymabe.com> On 05/18/2016 07:10 AM, Clayton Coleman wrote: > It was a deliberate choice, predicated on other changes coming to > Docker (user namespaces) plus the desire to ensure demos run. > I guess this was surprising to me. To me part of the "promise" of the CDK is that you are running in an Environment that more closely resembles production. I know there are many places where this promise falls apart, but this seems like a fundamental one since this is the one huge learning gap when going from running in kube to running in openshift. I would almost prefer for this to be a question asked on startup of the cdk (that can be overriden). The question could explain the limitation and why it will exist in production and then the user can choose if they want to ignore and run without restrictions. As a side note, how far off are user namespaces? From my understanding that's not really coming soon. > Ultimately, the CDK is a playground. Putting up chain link fences > around the playground sends the wrong message. > > I'd prefer to have it easier to go between the levels in the short > term than to ratchet it back. > >> On May 17, 2016, at 11:27 PM, Dusty Mabe wrote: >> >> >> Currently we are configuring openshift in the CDK/ADB to be more >> permissive than it should be when running containers. >> >> At [1] we are setting: >> >> oadm policy add-scc-to-group anyuid system:authenticated >> >> From my experiments this means that containers run as anyuid and thus >> can be root, cc clayton for confirmation. >> >> What this means is that we are misleading users to thinking things >> will run in production OpenShift, when the production OpenShift most >> likely won't have things configured this way. >> >> We should probably not be doing this. Reverting this change will also >> mean that proposed demos, etc.. should be retested on the newer version >> meticulously. >> >> Dusty >> >> [1] https://github.com/projectatomic/adb-utils/blob/01adadd904dea98033c9c83d0648d90f5e8f2806/services/openshift/scripts/openshift_provision#L47 From dusty at dustymabe.com Wed May 18 12:30:24 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Wed, 18 May 2016 08:30:24 -0400 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> Message-ID: <573C6060.3090402@dustymabe.com> On 05/18/2016 07:18 AM, Aslak Knutsen wrote: > I think most teams at the Brno F2F were struggling with this. It works locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH engineers there, none knew 100% or was able to dig up a doc that explained why and how to fix it... > > This is/will be a massive pain point moving from Dev to Production. The very least we need some very clear, simple guides on how to make it work. Yeah, I think a lot of people are going to be very frustrated by this. It took me over an hour to track down and that's only because I know a lot about how the CDK is set up. Others would probably never be able to figure it out. From ccoleman at redhat.com Wed May 18 12:34:05 2016 From: ccoleman at redhat.com (Clayton Coleman) Date: Wed, 18 May 2016 08:34:05 -0400 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <573C6060.3090402@dustymabe.com> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C6060.3090402@dustymabe.com> Message-ID: It's surprising to you because you know that there *should* be protections and then try to reduce them. For the vast majority of users, there is no surprise, because they have no expectation. Explaining that expectation, helping users transition, and educating them via example is something we need to be doing across the board. But forcing them to take that first step the moment they start is a burden. On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe wrote: > > > On 05/18/2016 07:18 AM, Aslak Knutsen wrote: >> I think most teams at the Brno F2F were struggling with this. It works locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH engineers there, none knew 100% or was able to dig up a doc that explained why and how to fix it... >> >> This is/will be a massive pain point moving from Dev to Production. The very least we need some very clear, simple guides on how to make it work. > > Yeah, I think a lot of people are going to be very frustrated by this. > It took me over an hour to track down and that's only because I know a > lot about how the CDK is set up. Others would probably never be able > to figure it out. From lmohanty at redhat.com Wed May 18 12:34:34 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Wed, 18 May 2016 18:04:34 +0530 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <573C5FEA.8030705@dustymabe.com> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C5FEA.8030705@dustymabe.com> Message-ID: On 05/18/2016 05:58 PM, Dusty Mabe wrote: > > On 05/18/2016 07:10 AM, Clayton Coleman wrote: >> It was a deliberate choice, predicated on other changes coming to >> Docker (user namespaces) plus the desire to ensure demos run. >> > I guess this was surprising to me. To me part of the "promise" of > the CDK is that you are running in an Environment that more closely > resembles production. I know there are many places where this promise > falls apart, but this seems like a fundamental one since this is the > one huge learning gap when going from running in kube to running in > openshift. Will a documentation in CDK/ADB about how to migrate application to production OpenShift will help? Till we have "oc debug". > I would almost prefer for this to be a question asked on startup of > the cdk (that can be overriden). The question could explain the > limitation and why it will exist in production and then the user can > choose if they want to ignore and run without restrictions. I am conservative about asking questions during setup as it reduces the user experience and we are not sure if the user has enough knowledge about it. > As a side note, how far off are user namespaces? From my understanding > that's not really coming soon. > >> Ultimately, the CDK is a playground. Putting up chain link fences >> around the playground sends the wrong message. >> >> I'd prefer to have it easier to go between the levels in the short >> term than to ratchet it back. >> > >>> On May 17, 2016, at 11:27 PM, Dusty Mabe wrote: >>> >>> >>> Currently we are configuring openshift in the CDK/ADB to be more >>> permissive than it should be when running containers. >>> >>> At [1] we are setting: >>> >>> oadm policy add-scc-to-group anyuid system:authenticated >>> >>> From my experiments this means that containers run as anyuid and thus >>> can be root, cc clayton for confirmation. >>> >>> What this means is that we are misleading users to thinking things >>> will run in production OpenShift, when the production OpenShift most >>> likely won't have things configured this way. >>> >>> We should probably not be doing this. Reverting this change will also >>> mean that proposed demos, etc.. should be retested on the newer version >>> meticulously. >>> >>> Dusty >>> >>> [1] https://github.com/projectatomic/adb-utils/blob/01adadd904dea98033c9c83d0648d90f5e8f2806/services/openshift/scripts/openshift_provision#L47 > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From aweiteka at redhat.com Wed May 18 12:34:56 2016 From: aweiteka at redhat.com (Aaron Weitekamp) Date: Wed, 18 May 2016 08:34:56 -0400 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <573C6060.3090402@dustymabe.com> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C6060.3090402@dustymabe.com> Message-ID: On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe wrote: > > > On 05/18/2016 07:18 AM, Aslak Knutsen wrote: > > I think most teams at the Brno F2F were struggling with this. It works > locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH > engineers there, none knew 100% or was able to dig up a doc that explained > why and how to fix it... > > > > This is/will be a massive pain point moving from Dev to Production. The > very least we need some very clear, simple guides on how to make it work. > > Yeah, I think a lot of people are going to be very frustrated by this. > It took me over an hour to track down and that's only because I know a > lot about how the CDK is set up. Others would probably never be able > to figure it out. > > ? For the "eval" use case we made the right choice. Dusty's question is about the CDK use case. To my mind the CDK should add value to a ?n openshift eval environment. This is a great opportunity for the CDK to provide tooling to address this ubiquitous problem. Mitch Harpur's ideas around this months ago were spot-on: walk devs through a journey, educate them, etc. _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prkumar at redhat.com Wed May 18 12:45:47 2016 From: prkumar at redhat.com (Praveen Kumar) Date: Wed, 18 May 2016 08:45:47 -0400 (EDT) Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C6060.3090402@dustymabe.com> Message-ID: <1726943701.52675887.1463575547755.JavaMail.zimbra@redhat.com> ----- Original Message ----- | From: "Clayton Coleman" | To: "Dusty Mabe" | Cc: devtools at redhat.com, "Aslak Knutsen" , "container-tools" | Sent: Wednesday, May 18, 2016 6:04:05 PM | Subject: Re: [Devtools] openshift is way too permissive in the CDK/ADB | | It's surprising to you because you know that there *should* be | protections and then try to reduce them. For the vast majority of | users, there is no surprise, because they have no expectation. | | Explaining that expectation, helping users transition, and educating | them via example is something we need to be doing across the board. | But forcing them to take that first step the moment they start is a | burden. I am agree on this point. We have to improve our documentation around transition for time being until we have something like 'oc debug' by default. | | On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe wrote: | > | > | > On 05/18/2016 07:18 AM, Aslak Knutsen wrote: | >> I think most teams at the Brno F2F were struggling with this. It works | >> locally, but semi-obscure failures when pushed 'live'. And out of the 30 | >> RH engineers there, none knew 100% or was able to dig up a doc that | >> explained why and how to fix it... | >> | >> This is/will be a massive pain point moving from Dev to Production. The | >> very least we need some very clear, simple guides on how to make it work. | > | > Yeah, I think a lot of people are going to be very frustrated by this. | > It took me over an hour to track down and that's only because I know a | > lot about how the CDK is set up. Others would probably never be able | > to figure it out. | | _______________________________________________ | Devtools mailing list | Devtools at redhat.com | https://www.redhat.com/mailman/listinfo/devtools | -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen From bsutter at redhat.com Wed May 18 13:17:10 2016 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 18 May 2016 09:17:10 -0400 Subject: [Devtools] [Container-tools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C6060.3090402@dustymabe.com> Message-ID: On Wed, May 18, 2016 at 8:34 AM, Aaron Weitekamp wrote: > On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe wrote: > >> >> >> On 05/18/2016 07:18 AM, Aslak Knutsen wrote: >> > I think most teams at the Brno F2F were struggling with this. It works >> locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH >> engineers there, none knew 100% or was able to dig up a doc that explained >> why and how to fix it... >> > >> > This is/will be a massive pain point moving from Dev to Production. The >> very least we need some very clear, simple guides on how to make it work. >> >> Yeah, I think a lot of people are going to be very frustrated by this. >> It took me over an hour to track down and that's only because I know a >> lot about how the CDK is set up. Others would probably never be able >> to figure it out. >> >> ? > For the "eval" use case we made the right choice. Dusty's question is > about the CDK use case. To my mind the CDK should add value to a > ?n openshift eval environment. This is a great opportunity for the CDK to > provide tooling to address this ubiquitous problem. Mitch Harpur's ideas > around this months ago were spot-on: walk devs through a journey, educate > them, etc. > Either the CDK can add this additional "tool", to help walk an end-user through a "proper" Dockerfile or pre-built container image. OR Openshift could offer this tool and I believe that is where it belongs. Because Openshift Online Users are going to hit this 100 times an hour once we open up the floodgates. :-) > > _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> > > > _______________________________________________ > Container-tools mailing list > Container-tools at redhat.com > https://www.redhat.com/mailman/listinfo/container-tools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccoleman at redhat.com Wed May 18 13:46:27 2016 From: ccoleman at redhat.com (Clayton Coleman) Date: Wed, 18 May 2016 09:46:27 -0400 Subject: [Devtools] [Container-tools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C6060.3090402@dustymabe.com> Message-ID: Yes, this is an openshift problem (really, it's container platform, but we'll use OpenShift as a proxy here). We have added things that make it easier, and warnings, but people don't read stuff. For instance, new-app warns you, and "oc status" tells you exactly what to do, but we need it in more places. On Wed, May 18, 2016 at 9:17 AM, Burr Sutter wrote: > > > On Wed, May 18, 2016 at 8:34 AM, Aaron Weitekamp > wrote: >> >> On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe wrote: >>> >>> >>> >>> On 05/18/2016 07:18 AM, Aslak Knutsen wrote: >>> > I think most teams at the Brno F2F were struggling with this. It works >>> > locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH >>> > engineers there, none knew 100% or was able to dig up a doc that explained >>> > why and how to fix it... >>> > >>> > This is/will be a massive pain point moving from Dev to Production. The >>> > very least we need some very clear, simple guides on how to make it work. >>> >>> Yeah, I think a lot of people are going to be very frustrated by this. >>> It took me over an hour to track down and that's only because I know a >>> lot about how the CDK is set up. Others would probably never be able >>> to figure it out. >>> >> >> For the "eval" use case we made the right choice. Dusty's question is >> about the CDK use case. To my mind the CDK should add value to a >> n openshift eval environment. This is a great opportunity for the CDK to >> provide tooling to address this ubiquitous problem. Mitch Harpur's ideas >> around this months ago were spot-on: walk devs through a journey, educate >> them, etc. > > > Either the CDK can add this additional "tool", to help walk an end-user > through a "proper" Dockerfile or pre-built container image. > > OR > > Openshift could offer this tool and I believe that is where it belongs. > Because Openshift Online Users are going to hit this 100 times an hour once > we open up the floodgates. :-) > > >> >> >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> https://www.redhat.com/mailman/listinfo/devtools >> >> >> >> _______________________________________________ >> Container-tools mailing list >> Container-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/container-tools >> > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > From cdrage at redhat.com Wed May 18 13:50:33 2016 From: cdrage at redhat.com (Charlie Drage) Date: Wed, 18 May 2016 09:50:33 -0400 Subject: [Devtools] Atomic App / Nulecule spec reviews Message-ID: <20160518135033.GA1@e8fba55e7bbf> Hi all! I've made some considerable progress in regards to the Nulecule / Atomic App direction and how we're becoming more of a deployment tool for distributing and deploying multi-container applications. However! I'm starting to become blocked now due to awaiting spec / code reviews as I begin to finish / catch up to my original workload. Although I could merge it individually, it's best to get a community review / support on it before continuing :) One of the biggest changes is the specification, as per pull: https://github.com/projectatomic/nulecule/pull/205 which makes some considerable changes to the way we write Nulecule files. If I could get some input on it, that would be great as it would create some work to get added to Atomic App / Nulecule as well as decrease the learning curve associated with creating and generating a Nulecule file. Another large change is the addition to *binary* generation for Atomic App, creating support for not only Linux, but Mac OS X and Windows platforms, allowing the ability to use Atomic App to deploy a multi-container application on a cluster from whichever platform you wish, whether or not it uses Python on the distribution. I've tested the generated binary on multiple operating systems and it appears to work awesomely! A third change is the addition of the Kubernetes binary usage to the API, which (at the moment) contains an additional 1200 lines of code to be added to Atomic App. Both functional and unit tests pass :) Many thanks and happy coding! -- Charlie Drage Red Hat - OSAS Team / Project Atomic 4096R / 0x9B3B446C http://pgp.mit.edu/pks/lookup?op=get&search=0x622CDF119B3B446C From bsutter at redhat.com Wed May 18 14:03:32 2016 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 18 May 2016 10:03:32 -0400 Subject: [Devtools] [Container-tools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C6060.3090402@dustymabe.com> Message-ID: Actually I was thinking we need the warning on "oc start-build" since that is how we are primarily re-deploying to OpenShift for Helloworld MSA. On Wed, May 18, 2016 at 9:46 AM, Clayton Coleman wrote: > Yes, this is an openshift problem (really, it's container platform, > but we'll use OpenShift as a proxy here). > > We have added things that make it easier, and warnings, but people > don't read stuff. For instance, new-app warns you, and "oc status" > tells you exactly what to do, but we need it in more places. > > On Wed, May 18, 2016 at 9:17 AM, Burr Sutter wrote: > > > > > > On Wed, May 18, 2016 at 8:34 AM, Aaron Weitekamp > > wrote: > >> > >> On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe > wrote: > >>> > >>> > >>> > >>> On 05/18/2016 07:18 AM, Aslak Knutsen wrote: > >>> > I think most teams at the Brno F2F were struggling with this. It > works > >>> > locally, but semi-obscure failures when pushed 'live'. And out of > the 30 RH > >>> > engineers there, none knew 100% or was able to dig up a doc that > explained > >>> > why and how to fix it... > >>> > > >>> > This is/will be a massive pain point moving from Dev to Production. > The > >>> > very least we need some very clear, simple guides on how to make it > work. > >>> > >>> Yeah, I think a lot of people are going to be very frustrated by this. > >>> It took me over an hour to track down and that's only because I know a > >>> lot about how the CDK is set up. Others would probably never be able > >>> to figure it out. > >>> > >> > >> For the "eval" use case we made the right choice. Dusty's question is > >> about the CDK use case. To my mind the CDK should add value to a > >> n openshift eval environment. This is a great opportunity for the CDK to > >> provide tooling to address this ubiquitous problem. Mitch Harpur's ideas > >> around this months ago were spot-on: walk devs through a journey, > educate > >> them, etc. > > > > > > Either the CDK can add this additional "tool", to help walk an end-user > > through a "proper" Dockerfile or pre-built container image. > > > > OR > > > > Openshift could offer this tool and I believe that is where it belongs. > > Because Openshift Online Users are going to hit this 100 times an hour > once > > we open up the floodgates. :-) > > > > > >> > >> > >>> _______________________________________________ > >>> Devtools mailing list > >>> Devtools at redhat.com > >>> https://www.redhat.com/mailman/listinfo/devtools > >> > >> > >> > >> _______________________________________________ > >> Container-tools mailing list > >> Container-tools at redhat.com > >> https://www.redhat.com/mailman/listinfo/container-tools > >> > > > > > > _______________________________________________ > > Devtools mailing list > > Devtools at redhat.com > > https://www.redhat.com/mailman/listinfo/devtools > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccoleman at redhat.com Wed May 18 14:14:37 2016 From: ccoleman at redhat.com (Clayton Coleman) Date: Wed, 18 May 2016 10:14:37 -0400 Subject: [Devtools] [Container-tools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C6060.3090402@dustymabe.com> Message-ID: start build has no idea what your destination runtime environment is, unfortunately. On Wed, May 18, 2016 at 10:03 AM, Burr Sutter wrote: > Actually I was thinking we need the warning on "oc start-build" since that > is how we are primarily re-deploying to OpenShift for Helloworld MSA. > > On Wed, May 18, 2016 at 9:46 AM, Clayton Coleman > wrote: >> >> Yes, this is an openshift problem (really, it's container platform, >> but we'll use OpenShift as a proxy here). >> >> We have added things that make it easier, and warnings, but people >> don't read stuff. For instance, new-app warns you, and "oc status" >> tells you exactly what to do, but we need it in more places. >> >> On Wed, May 18, 2016 at 9:17 AM, Burr Sutter wrote: >> > >> > >> > On Wed, May 18, 2016 at 8:34 AM, Aaron Weitekamp >> > wrote: >> >> >> >> On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe >> >> wrote: >> >>> >> >>> >> >>> >> >>> On 05/18/2016 07:18 AM, Aslak Knutsen wrote: >> >>> > I think most teams at the Brno F2F were struggling with this. It >> >>> > works >> >>> > locally, but semi-obscure failures when pushed 'live'. And out of >> >>> > the 30 RH >> >>> > engineers there, none knew 100% or was able to dig up a doc that >> >>> > explained >> >>> > why and how to fix it... >> >>> > >> >>> > This is/will be a massive pain point moving from Dev to Production. >> >>> > The >> >>> > very least we need some very clear, simple guides on how to make it >> >>> > work. >> >>> >> >>> Yeah, I think a lot of people are going to be very frustrated by this. >> >>> It took me over an hour to track down and that's only because I know a >> >>> lot about how the CDK is set up. Others would probably never be able >> >>> to figure it out. >> >>> >> >> >> >> For the "eval" use case we made the right choice. Dusty's question is >> >> about the CDK use case. To my mind the CDK should add value to a >> >> n openshift eval environment. This is a great opportunity for the CDK >> >> to >> >> provide tooling to address this ubiquitous problem. Mitch Harpur's >> >> ideas >> >> around this months ago were spot-on: walk devs through a journey, >> >> educate >> >> them, etc. >> > >> > >> > Either the CDK can add this additional "tool", to help walk an end-user >> > through a "proper" Dockerfile or pre-built container image. >> > >> > OR >> > >> > Openshift could offer this tool and I believe that is where it belongs. >> > Because Openshift Online Users are going to hit this 100 times an hour >> > once >> > we open up the floodgates. :-) >> > >> > >> >> >> >> >> >>> _______________________________________________ >> >>> Devtools mailing list >> >>> Devtools at redhat.com >> >>> https://www.redhat.com/mailman/listinfo/devtools >> >> >> >> >> >> >> >> _______________________________________________ >> >> Container-tools mailing list >> >> Container-tools at redhat.com >> >> https://www.redhat.com/mailman/listinfo/container-tools >> >> >> > >> > >> > _______________________________________________ >> > Devtools mailing list >> > Devtools at redhat.com >> > https://www.redhat.com/mailman/listinfo/devtools >> > > > From pmuir at redhat.com Wed May 18 14:25:21 2016 From: pmuir at redhat.com (Pete Muir) Date: Wed, 18 May 2016 15:25:21 +0100 Subject: [Devtools] Atomic App / Nulecule spec reviews In-Reply-To: <20160518135033.GA1@e8fba55e7bbf> References: <20160518135033.GA1@e8fba55e7bbf> Message-ID: On 18 May 2016 at 14:50, Charlie Drage wrote: > Hi all! > > I've made some considerable progress in regards to the Nulecule / > Atomic App direction and how we're becoming more of a deployment tool > for distributing and deploying multi-container applications. > > However! I'm starting to become blocked now due to awaiting spec / > code reviews as I begin to finish / catch up to my original workload. > Although I could merge it individually, it's best to get a community > review / support on it before continuing :) > > One of the biggest changes is the specification, as per pull: > https://github.com/projectatomic/nulecule/pull/205 which makes some > considerable changes to the way we write Nulecule files. If I could get > some input on it, that would be great as it would create some work to > get added to Atomic App / Nulecule as well as decrease the learning > curve associated with creating and generating a Nulecule file. Could you summarise the changes you have made. I couldn't find an actual spec change in the changeset, just changes to example files. > > Another large change is the addition to *binary* generation for Atomic > App, creating support for not only Linux, but Mac OS X and Windows > platforms, allowing the ability to use Atomic App to deploy a > multi-container application on a cluster from whichever platform you > wish, whether or not it uses Python on the distribution. I've tested > the generated binary on multiple operating systems and it appears to > work awesomely! I don't quite understand this one - do you have a video of it in action? Would be good to add this to the sprint review. > > A third change is the addition of the Kubernetes binary usage to the > API, which (at the moment) contains an additional 1200 lines of code > to be added to Atomic App. Both functional and unit tests pass :) > > Many thanks and happy coding! > -- > > Charlie Drage > Red Hat - OSAS Team / Project Atomic > 4096R / 0x9B3B446C > http://pgp.mit.edu/pks/lookup?op=get&search=0x622CDF119B3B446C > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From cdrage at redhat.com Wed May 18 14:31:37 2016 From: cdrage at redhat.com (Charlie Drage) Date: Wed, 18 May 2016 10:31:37 -0400 Subject: [Devtools] Atomic App / Nulecule spec reviews In-Reply-To: References: <20160518135033.GA1@e8fba55e7bbf> Message-ID: <20160518143137.GF1@e8fba55e7bbf> See inline comments below On 05/18, Pete Muir wrote: > On 18 May 2016 at 14:50, Charlie Drage wrote: > > Hi all! > > > > I've made some considerable progress in regards to the Nulecule / > > Atomic App direction and how we're becoming more of a deployment tool > > for distributing and deploying multi-container applications. > > > > However! I'm starting to become blocked now due to awaiting spec / > > code reviews as I begin to finish / catch up to my original workload. > > Although I could merge it individually, it's best to get a community > > review / support on it before continuing :) > > > > One of the biggest changes is the specification, as per pull: > > https://github.com/projectatomic/nulecule/pull/205 which makes some > > considerable changes to the way we write Nulecule files. If I could get > > some input on it, that would be great as it would create some work to > > get added to Atomic App / Nulecule as well as decrease the learning > > curve associated with creating and generating a Nulecule file. > > Could you summarise the changes you have made. I couldn't find an > actual spec change in the changeset, just changes to example files. Ah yes! It was just the addition of the example files as I found that the easiest way to reflect the largeer changes without re-writting the entire documentation. If the original spec writers give their approval for the change I can write a large PR which will change/re-write the original documentation to conform to the new spec. > > > > > Another large change is the addition to *binary* generation for Atomic > > App, creating support for not only Linux, but Mac OS X and Windows > > platforms, allowing the ability to use Atomic App to deploy a > > multi-container application on a cluster from whichever platform you > > wish, whether or not it uses Python on the distribution. I've tested > > the generated binary on multiple operating systems and it appears to > > work awesomely! > > I don't quite understand this one - do you have a video of it in action? > > Would be good to add this to the sprint review. Not yet! I've tested it on some other platforms such as CoreOS / Project Atomic / Debian / CentOS which are of course all Linux specific. *theoretically* there shouldn't be a problem running it on Mac OS X / Windows. As the tool used for the binary generation (pyinstaller) works on all platforms. I'm awaiting for the PR's to be commented on if this is a step in the right direction and then I can pull out my Windows machine and start testing it more then. I'm sure I'll encounter a few bugs (I know of one right now with .kube/config pulling...) > > > > > A third change is the addition of the Kubernetes binary usage to the > > API, which (at the moment) contains an additional 1200 lines of code > > to be added to Atomic App. Both functional and unit tests pass :) > > > > Many thanks and happy coding! > > -- > > > > Charlie Drage > > Red Hat - OSAS Team / Project Atomic > > 4096R / 0x9B3B446C > > http://pgp.mit.edu/pks/lookup?op=get&search=0x622CDF119B3B446C > > > > _______________________________________________ > > Devtools mailing list > > Devtools at redhat.com > > https://www.redhat.com/mailman/listinfo/devtools -- Charlie Drage Red Hat - OSAS Team / Project Atomic 4096R / 0x9B3B446C http://pgp.mit.edu/pks/lookup?op=get&search=0x622CDF119B3B446C From bsutter at redhat.com Wed May 18 14:33:35 2016 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 18 May 2016 10:33:35 -0400 Subject: [Devtools] [Container-tools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C6060.3090402@dustymabe.com> Message-ID: On Wed, May 18, 2016 at 10:14 AM, Clayton Coleman wrote: > start build has no idea what your destination runtime environment is, > unfortunately. > Interesting...from an end-user perspective, it causes a "redeployment" but I guess that is Openshift picking up the image stream change (pull) therefore the potential "warning" message would only be in the OpenShift console/logs, not as feedback/output of "start-build". > > On Wed, May 18, 2016 at 10:03 AM, Burr Sutter wrote: > > Actually I was thinking we need the warning on "oc start-build" since > that > > is how we are primarily re-deploying to OpenShift for Helloworld MSA. > > > > On Wed, May 18, 2016 at 9:46 AM, Clayton Coleman > > wrote: > >> > >> Yes, this is an openshift problem (really, it's container platform, > >> but we'll use OpenShift as a proxy here). > >> > >> We have added things that make it easier, and warnings, but people > >> don't read stuff. For instance, new-app warns you, and "oc status" > >> tells you exactly what to do, but we need it in more places. > >> > >> On Wed, May 18, 2016 at 9:17 AM, Burr Sutter > wrote: > >> > > >> > > >> > On Wed, May 18, 2016 at 8:34 AM, Aaron Weitekamp > > >> > wrote: > >> >> > >> >> On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe > >> >> wrote: > >> >>> > >> >>> > >> >>> > >> >>> On 05/18/2016 07:18 AM, Aslak Knutsen wrote: > >> >>> > I think most teams at the Brno F2F were struggling with this. It > >> >>> > works > >> >>> > locally, but semi-obscure failures when pushed 'live'. And out of > >> >>> > the 30 RH > >> >>> > engineers there, none knew 100% or was able to dig up a doc that > >> >>> > explained > >> >>> > why and how to fix it... > >> >>> > > >> >>> > This is/will be a massive pain point moving from Dev to > Production. > >> >>> > The > >> >>> > very least we need some very clear, simple guides on how to make > it > >> >>> > work. > >> >>> > >> >>> Yeah, I think a lot of people are going to be very frustrated by > this. > >> >>> It took me over an hour to track down and that's only because I > know a > >> >>> lot about how the CDK is set up. Others would probably never be able > >> >>> to figure it out. > >> >>> > >> >> > >> >> For the "eval" use case we made the right choice. Dusty's question is > >> >> about the CDK use case. To my mind the CDK should add value to a > >> >> n openshift eval environment. This is a great opportunity for the CDK > >> >> to > >> >> provide tooling to address this ubiquitous problem. Mitch Harpur's > >> >> ideas > >> >> around this months ago were spot-on: walk devs through a journey, > >> >> educate > >> >> them, etc. > >> > > >> > > >> > Either the CDK can add this additional "tool", to help walk an > end-user > >> > through a "proper" Dockerfile or pre-built container image. > >> > > >> > OR > >> > > >> > Openshift could offer this tool and I believe that is where it > belongs. > >> > Because Openshift Online Users are going to hit this 100 times an hour > >> > once > >> > we open up the floodgates. :-) > >> > > >> > > >> >> > >> >> > >> >>> _______________________________________________ > >> >>> Devtools mailing list > >> >>> Devtools at redhat.com > >> >>> https://www.redhat.com/mailman/listinfo/devtools > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> Container-tools mailing list > >> >> Container-tools at redhat.com > >> >> https://www.redhat.com/mailman/listinfo/container-tools > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Devtools mailing list > >> > Devtools at redhat.com > >> > https://www.redhat.com/mailman/listinfo/devtools > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccoleman at redhat.com Wed May 18 14:46:23 2016 From: ccoleman at redhat.com (Clayton Coleman) Date: Wed, 18 May 2016 10:46:23 -0400 Subject: [Devtools] [Container-tools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C6060.3090402@dustymabe.com> Message-ID: <-4231403923858250670@unknownmsgid> Ideally a build would continue into deployment, but there are some challenges. We definitely need to brainstorm and implement better guide rails around this in the near term. On May 18, 2016, at 10:33 AM, Burr Sutter wrote: On Wed, May 18, 2016 at 10:14 AM, Clayton Coleman wrote: > start build has no idea what your destination runtime environment is, > unfortunately. > Interesting...from an end-user perspective, it causes a "redeployment" but I guess that is Openshift picking up the image stream change (pull) therefore the potential "warning" message would only be in the OpenShift console/logs, not as feedback/output of "start-build". > > On Wed, May 18, 2016 at 10:03 AM, Burr Sutter wrote: > > Actually I was thinking we need the warning on "oc start-build" since > that > > is how we are primarily re-deploying to OpenShift for Helloworld MSA. > > > > On Wed, May 18, 2016 at 9:46 AM, Clayton Coleman > > wrote: > >> > >> Yes, this is an openshift problem (really, it's container platform, > >> but we'll use OpenShift as a proxy here). > >> > >> We have added things that make it easier, and warnings, but people > >> don't read stuff. For instance, new-app warns you, and "oc status" > >> tells you exactly what to do, but we need it in more places. > >> > >> On Wed, May 18, 2016 at 9:17 AM, Burr Sutter > wrote: > >> > > >> > > >> > On Wed, May 18, 2016 at 8:34 AM, Aaron Weitekamp > > >> > wrote: > >> >> > >> >> On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe > >> >> wrote: > >> >>> > >> >>> > >> >>> > >> >>> On 05/18/2016 07:18 AM, Aslak Knutsen wrote: > >> >>> > I think most teams at the Brno F2F were struggling with this. It > >> >>> > works > >> >>> > locally, but semi-obscure failures when pushed 'live'. And out of > >> >>> > the 30 RH > >> >>> > engineers there, none knew 100% or was able to dig up a doc that > >> >>> > explained > >> >>> > why and how to fix it... > >> >>> > > >> >>> > This is/will be a massive pain point moving from Dev to > Production. > >> >>> > The > >> >>> > very least we need some very clear, simple guides on how to make > it > >> >>> > work. > >> >>> > >> >>> Yeah, I think a lot of people are going to be very frustrated by > this. > >> >>> It took me over an hour to track down and that's only because I > know a > >> >>> lot about how the CDK is set up. Others would probably never be able > >> >>> to figure it out. > >> >>> > >> >> > >> >> For the "eval" use case we made the right choice. Dusty's question is > >> >> about the CDK use case. To my mind the CDK should add value to a > >> >> n openshift eval environment. This is a great opportunity for the CDK > >> >> to > >> >> provide tooling to address this ubiquitous problem. Mitch Harpur's > >> >> ideas > >> >> around this months ago were spot-on: walk devs through a journey, > >> >> educate > >> >> them, etc. > >> > > >> > > >> > Either the CDK can add this additional "tool", to help walk an > end-user > >> > through a "proper" Dockerfile or pre-built container image. > >> > > >> > OR > >> > > >> > Openshift could offer this tool and I believe that is where it > belongs. > >> > Because Openshift Online Users are going to hit this 100 times an hour > >> > once > >> > we open up the floodgates. :-) > >> > > >> > > >> >> > >> >> > >> >>> _______________________________________________ > >> >>> Devtools mailing list > >> >>> Devtools at redhat.com > >> >>> https://www.redhat.com/mailman/listinfo/devtools > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> Container-tools mailing list > >> >> Container-tools at redhat.com > >> >> https://www.redhat.com/mailman/listinfo/container-tools > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Devtools mailing list > >> > Devtools at redhat.com > >> > https://www.redhat.com/mailman/listinfo/devtools > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Wed May 18 15:03:34 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Wed, 18 May 2016 20:33:34 +0530 Subject: [Devtools] Fwd: Re: 'oc cluster up' command In-Reply-To: <1212311788895726682@unknownmsgid> References: <1212311788895726682@unknownmsgid> Message-ID: <0e56c77e-0d7b-6ea2-90dc-f2d3957f2e24@redhat.com> FYI. This going to make an positive impact on CDK/ADB -------- Forwarded Message -------- Subject: Re: 'oc cluster up' command Date: Tue, 17 May 2016 20:51:52 -0400 From: Clayton Coleman To: Cesar Wong CC: dev For now you'll need to build your own binary or download it from the Jenkins nightly, at least until we release 1.3.0-alpha.1 On May 17, 2016, at 8:48 PM, Cesar Wong > wrote: > PR #7675 introduces a > new command 'oc cluster up' that allows you to start an OpenShift > all-in-one cluster with a configured registry, router and an initial > set of templates and image streams. The 'oc cluster down' command will > stop the cluster. > > The command can be run from any client platform we support (Windows, > OS X, Linux). All it requires is a valid Docker connection. > > At it's most basic, ensure Docker commands work, like 'docker ps', > download the 'oc' binary > for your > platform, and run: > > $ oc cluster up > > To stop, run > > $ oc cluster down > > You can read more about other options and usage in specific situations > here > . > > > > _______________________________________________ > dev mailing list > dev at lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ dev mailing list dev at lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev From prkumar at redhat.com Wed May 18 15:17:03 2016 From: prkumar at redhat.com (Praveen Kumar) Date: Wed, 18 May 2016 11:17:03 -0400 (EDT) Subject: [Devtools] Fwd: Re: 'oc cluster up' command In-Reply-To: <0e56c77e-0d7b-6ea2-90dc-f2d3957f2e24@redhat.com> References: <1212311788895726682@unknownmsgid> <0e56c77e-0d7b-6ea2-90dc-f2d3957f2e24@redhat.com> Message-ID: <1591351950.52726885.1463584623769.JavaMail.zimbra@redhat.com> ----- Original Message ----- | From: "Lalatendu Mohanty" | To: devtools at redhat.com | Sent: Wednesday, May 18, 2016 8:33:34 PM | Subject: [Devtools] Fwd: Re: 'oc cluster up' command | | FYI. This going to make an positive impact on CDK/ADB Nice, but it will take time to land in CDK side till then ADB will provide us a good opportunity to test this out. | | -------- Forwarded Message -------- | Subject: Re: 'oc cluster up' command | Date: Tue, 17 May 2016 20:51:52 -0400 | From: Clayton Coleman | To: Cesar Wong | CC: dev | | | | For now you'll need to build your own binary or download it from the | Jenkins nightly, at least until we release 1.3.0-alpha.1 | | On May 17, 2016, at 8:48 PM, Cesar Wong > wrote: | | > PR #7675 introduces a | > new command 'oc cluster up' that allows you to start an OpenShift | > all-in-one cluster with a configured registry, router and an initial | > set of templates and image streams. The 'oc cluster down' command will | > stop the cluster. | > | > The command can be run from any client platform we support (Windows, | > OS X, Linux). All it requires is a valid Docker connection. | > | > At it's most basic, ensure Docker commands work, like 'docker ps', | > download the 'oc' binary | > for your | > platform, and run: | > | > $ oc cluster up | > | > To stop, run | > | > $ oc cluster down | > | > You can read more about other options and usage in specific situations | > here | > . | > | > | > | > _______________________________________________ | > dev mailing list | > dev at lists.openshift.redhat.com | > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev | | _______________________________________________ | Devtools mailing list | Devtools at redhat.com | https://www.redhat.com/mailman/listinfo/devtools | -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen From pmuir at redhat.com Wed May 18 17:50:13 2016 From: pmuir at redhat.com (Pete Muir) Date: Wed, 18 May 2016 18:50:13 +0100 Subject: [Devtools] Cockpit in ADB In-Reply-To: References: Message-ID: Is this installed on the host, or is it in a container? My concern is that it will increase the size of the VM. On 17 May 2016 at 18:43, Lalatendu Mohanty wrote: > Hi, > > We have added Cockpit packages to ADB as we thought it would add value to > ADB users. > > With Cockpit GUI an user can do docker pulls , docker runs etc apart from > system administration work. Cockpit also provides a web terminal which can > used to run docker commands without logging in to the Vagrantbox (it is > useful for Windows users as vagrant ssh does not work naively). > > How ever we are not sure whether it should be part of the default experience > of ADB. So at this point the Cockpit service is not started by default. > There is an open issue for this [1] and we are looking for feedback. > > [1] https://github.com/projectatomic/adb-atomic-developer-bundle/issues/389 > > Thanks, > Lala > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > From ccoleman at redhat.com Wed May 18 18:26:22 2016 From: ccoleman at redhat.com (Clayton Coleman) Date: Wed, 18 May 2016 14:26:22 -0400 Subject: [Devtools] [Container-tools] openshift is way too permissive in the CDK/ADB In-Reply-To: <-4231403923858250670@unknownmsgid> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C6060.3090402@dustymabe.com> <-4231403923858250670@unknownmsgid> Message-ID: Opened https://github.com/openshift/origin/pull/8929 to make: oc debug dc/thing_that_works_in_cdk --as-user=10000 possible, which should catch 90% of real user problems. On Wed, May 18, 2016 at 10:46 AM, Clayton Coleman wrote: > Ideally a build would continue into deployment, but there are some > challenges. We definitely need to brainstorm and implement better guide > rails around this in the near term. > > On May 18, 2016, at 10:33 AM, Burr Sutter wrote: > > > > On Wed, May 18, 2016 at 10:14 AM, Clayton Coleman > wrote: >> >> start build has no idea what your destination runtime environment is, >> unfortunately. > > > Interesting...from an end-user perspective, it causes a "redeployment" but I > guess that is Openshift picking up the image stream change (pull) therefore > the potential "warning" message would only be in the OpenShift console/logs, > not as feedback/output of "start-build". > >> >> >> On Wed, May 18, 2016 at 10:03 AM, Burr Sutter wrote: >> > Actually I was thinking we need the warning on "oc start-build" since >> > that >> > is how we are primarily re-deploying to OpenShift for Helloworld MSA. >> > >> > On Wed, May 18, 2016 at 9:46 AM, Clayton Coleman >> > wrote: >> >> >> >> Yes, this is an openshift problem (really, it's container platform, >> >> but we'll use OpenShift as a proxy here). >> >> >> >> We have added things that make it easier, and warnings, but people >> >> don't read stuff. For instance, new-app warns you, and "oc status" >> >> tells you exactly what to do, but we need it in more places. >> >> >> >> On Wed, May 18, 2016 at 9:17 AM, Burr Sutter >> >> wrote: >> >> > >> >> > >> >> > On Wed, May 18, 2016 at 8:34 AM, Aaron Weitekamp >> >> > >> >> > wrote: >> >> >> >> >> >> On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe >> >> >> wrote: >> >> >>> >> >> >>> >> >> >>> >> >> >>> On 05/18/2016 07:18 AM, Aslak Knutsen wrote: >> >> >>> > I think most teams at the Brno F2F were struggling with this. It >> >> >>> > works >> >> >>> > locally, but semi-obscure failures when pushed 'live'. And out of >> >> >>> > the 30 RH >> >> >>> > engineers there, none knew 100% or was able to dig up a doc that >> >> >>> > explained >> >> >>> > why and how to fix it... >> >> >>> > >> >> >>> > This is/will be a massive pain point moving from Dev to >> >> >>> > Production. >> >> >>> > The >> >> >>> > very least we need some very clear, simple guides on how to make >> >> >>> > it >> >> >>> > work. >> >> >>> >> >> >>> Yeah, I think a lot of people are going to be very frustrated by >> >> >>> this. >> >> >>> It took me over an hour to track down and that's only because I >> >> >>> know a >> >> >>> lot about how the CDK is set up. Others would probably never be >> >> >>> able >> >> >>> to figure it out. >> >> >>> >> >> >> >> >> >> For the "eval" use case we made the right choice. Dusty's question >> >> >> is >> >> >> about the CDK use case. To my mind the CDK should add value to a >> >> >> n openshift eval environment. This is a great opportunity for the >> >> >> CDK >> >> >> to >> >> >> provide tooling to address this ubiquitous problem. Mitch Harpur's >> >> >> ideas >> >> >> around this months ago were spot-on: walk devs through a journey, >> >> >> educate >> >> >> them, etc. >> >> > >> >> > >> >> > Either the CDK can add this additional "tool", to help walk an >> >> > end-user >> >> > through a "proper" Dockerfile or pre-built container image. >> >> > >> >> > OR >> >> > >> >> > Openshift could offer this tool and I believe that is where it >> >> > belongs. >> >> > Because Openshift Online Users are going to hit this 100 times an >> >> > hour >> >> > once >> >> > we open up the floodgates. :-) >> >> > >> >> > >> >> >> >> >> >> >> >> >>> _______________________________________________ >> >> >>> Devtools mailing list >> >> >>> Devtools at redhat.com >> >> >>> https://www.redhat.com/mailman/listinfo/devtools >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Container-tools mailing list >> >> >> Container-tools at redhat.com >> >> >> https://www.redhat.com/mailman/listinfo/container-tools >> >> >> >> >> > >> >> > >> >> > _______________________________________________ >> >> > Devtools mailing list >> >> > Devtools at redhat.com >> >> > https://www.redhat.com/mailman/listinfo/devtools >> >> > >> > >> > > > From hferents at redhat.com Wed May 18 18:46:25 2016 From: hferents at redhat.com (Hardy Ferentschik) Date: Wed, 18 May 2016 20:46:25 +0200 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <-4959106190020746004@unknownmsgid> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> Message-ID: <20160518184625.GA59306@nineveh.lan> Hi, On Wed, 18-May-2016 07:10, Clayton Coleman wrote: > It was a deliberate choice, predicated on other changes coming to > Docker (user namespaces) plus the desire to ensure demos run. > > Ultimately, the CDK is a playground. Putting up chain link fences > around the playground sends the wrong message. > > I'd prefer to have it easier to go between the levels in the short > term than to ratchet it back. +1 to all the above. My understanding was anyways that in with the upcoming user namespaces things would change and the problem would "go away". Where do things stand regarding this feature? --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From ccoleman at redhat.com Wed May 18 18:48:12 2016 From: ccoleman at redhat.com (Clayton Coleman) Date: Wed, 18 May 2016 14:48:12 -0400 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <20160518184625.GA59306@nineveh.lan> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <20160518184625.GA59306@nineveh.lan> Message-ID: Mostly that it's still experimental, will probably be enabled but not considered "secure" in OpenShift 3.3 on Docker 1.10, and we're still working to add the right controls and get soak time so that by the time we get to Docker 1.12/1.13 we can say "it's actually secure". On Wed, May 18, 2016 at 2:46 PM, Hardy Ferentschik wrote: > Hi, > > On Wed, 18-May-2016 07:10, Clayton Coleman wrote: >> It was a deliberate choice, predicated on other changes coming to >> Docker (user namespaces) plus the desire to ensure demos run. >> >> Ultimately, the CDK is a playground. Putting up chain link fences >> around the playground sends the wrong message. >> >> I'd prefer to have it easier to go between the levels in the short >> term than to ratchet it back. > > +1 to all the above. > > My understanding was anyways that in with the upcoming user namespaces > things would change and the problem would "go away". Where do things > stand regarding this feature? > > --Hardy > From hferents at redhat.com Wed May 18 18:53:15 2016 From: hferents at redhat.com (Hardy Ferentschik) Date: Wed, 18 May 2016 20:53:15 +0200 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <573C6060.3090402@dustymabe.com> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C6060.3090402@dustymabe.com> Message-ID: <20160518185315.GB59306@nineveh.lan> Hi, > > I think most teams at the Brno F2F were struggling with this. It works locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH engineers there, none knew 100% or was able to dig up a doc that explained why and how to fix it... > > > > This is/will be a massive pain point moving from Dev to Production. The very least we need some very clear, simple guides on how to make it work. > > Yeah, I think a lot of people are going to be very frustrated by this. > It took me over an hour to track down and that's only because I know a > lot about how the CDK is set up. Others would probably never be able > to figure it out. It works the other way around as well as I painfully experienced and I think it took me more than an our to find out how to fix (aka be more permissive). All I could get from the logs etc were some seemingly unrelated Java stack traces. I think by now there are some better warnings at place, but still, it is a major pain point. When are you more likely to turn your back on the CDK? Right in the beginning when you cannot get anything to work or later down the road where you already put some time into it and have something running locally, but you cannot push it into a production environment. I am tempted to say the former. +1 to do everything we can from a documentation point of view. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From hferents at redhat.com Wed May 18 18:58:06 2016 From: hferents at redhat.com (Hardy Ferentschik) Date: Wed, 18 May 2016 20:58:06 +0200 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C5FEA.8030705@dustymabe.com> Message-ID: <20160518185806.GC59306@nineveh.lan> Hi, > >I would almost prefer for this to be a question asked on startup of > >the cdk (that can be overriden). The question could explain the > >limitation and why it will exist in production and then the user can > >choose if they want to ignore and run without restrictions. > > I am conservative about asking questions during setup as it reduces the user > experience and we are not sure if the user has enough knowledge about it. I am usually also against asking questions, but this might be the only way to get a user to at least read the question. We can write it in as many places we want, unless we literally force the user to make a choice, we will have people running into this problem. Since who read documentation, right? --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From dusty at dustymabe.com Wed May 18 19:29:31 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Wed, 18 May 2016 15:29:31 -0400 Subject: [Devtools] redhat registry: What repo toplevel for atomicapp? Message-ID: <573CC29B.4070605@dustymabe.com> In the Red Hat registry I can only get AtomicApp from: docker pull devstudio/atomicapp OR docker pull cdk_beta/atomicapp (OUTDATED) This doesn't seem right to me. What toplevel should we be under? Dusty From dusty at dustymabe.com Wed May 18 19:42:54 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Wed, 18 May 2016 15:42:54 -0400 Subject: [Devtools] redhat registry: What repo toplevel for atomicapp? In-Reply-To: <573CC29B.4070605@dustymabe.com> References: <573CC29B.4070605@dustymabe.com> Message-ID: <573CC5BE.5040801@dustymabe.com> On 05/18/2016 03:29 PM, Dusty Mabe wrote: > In the Red Hat registry I can only get AtomicApp from: > > docker pull devstudio/atomicapp > OR > docker pull cdk_beta/atomicapp (OUTDATED) > > > This doesn't seem right to me. What toplevel should we be under? > Also the tags for atomicapp in the registry are inappropriate. The latest version is 0.5.0 but the tags that I can pull from are: ``` # skopeo registry.access.redhat.com/devstudio/atomicapp 2>/dev/null | jq '.RepoTags' [ "7.2-13", "latest" ] ``` What we are doing upstream looks much different: ``` # skopeo docker.io/projectatomic/atomicapp 2>/dev/null | jq '.RepoTags' [ "0.0.1", "0.1.0", "0.1.1", "0.1.10", "0.1.11", "0.1.12", "0.1.2", "0.1.3", "0.2.1", "0.2.2", "0.2.3", "0.3.0", "0.3.1", "0.4.0", "0.4.1", "0.4.2", "0.4.3", "0.4.4", "0.4.5", "0.5.0", "0.5.1", "dev", "latest" ] ``` From prkumar at redhat.com Thu May 19 01:23:31 2016 From: prkumar at redhat.com (Praveen Kumar) Date: Wed, 18 May 2016 21:23:31 -0400 (EDT) Subject: [Devtools] redhat registry: What repo toplevel for atomicapp? In-Reply-To: <573CC29B.4070605@dustymabe.com> References: <573CC29B.4070605@dustymabe.com> Message-ID: <1632322206.52813362.1463621011170.JavaMail.zimbra@redhat.com> ----- Original Message ----- | From: "Dusty Mabe" | To: devtools at redhat.com | Sent: Thursday, May 19, 2016 12:59:31 AM | Subject: [Devtools] redhat registry: What repo toplevel for atomicapp? | | In the Red Hat registry I can only get AtomicApp from: | | docker pull devstudio/atomicapp We are under devstudio namespace[0]. We recently did that migration and will file another request to remove cdk_beta to avoid any confusion. [0] https://projects.engineering.redhat.com/browse/RCM-2162 | OR | docker pull cdk_beta/atomicapp (OUTDATED) | | | This doesn't seem right to me. What toplevel should we be under? | | Dusty -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen From prkumar at redhat.com Thu May 19 01:33:36 2016 From: prkumar at redhat.com (Praveen Kumar) Date: Wed, 18 May 2016 21:33:36 -0400 (EDT) Subject: [Devtools] Cockpit in ADB In-Reply-To: References: Message-ID: <429497178.52813698.1463621616092.JavaMail.zimbra@redhat.com> ----- Original Message ----- | From: "Pete Muir" | To: "Lalatendu Mohanty" | Cc: devtools at redhat.com, "container-tools" | Sent: Wednesday, May 18, 2016 11:20:13 PM | Subject: Re: [Devtools] Cockpit in ADB | | Is this installed on the host, or is it in a container? It installed in VM as rpm package not using container. | | My concern is that it will increase the size of the VM. It's around 6MB and we can have a trade-off between increased size and functionality/user-experience it provides. | | On 17 May 2016 at 18:43, Lalatendu Mohanty wrote: | > Hi, | > | > We have added Cockpit packages to ADB as we thought it would add value to | > ADB users. | > | > With Cockpit GUI an user can do docker pulls , docker runs etc apart from | > system administration work. Cockpit also provides a web terminal which can | > used to run docker commands without logging in to the Vagrantbox (it is | > useful for Windows users as vagrant ssh does not work naively). | > | > How ever we are not sure whether it should be part of the default | > experience | > of ADB. So at this point the Cockpit service is not started by default. | > There is an open issue for this [1] and we are looking for feedback. | > | > [1] https://github.com/projectatomic/adb-atomic-developer-bundle/issues/389 | > | > Thanks, | > Lala | > | > _______________________________________________ | > Devtools mailing list | > Devtools at redhat.com | > https://www.redhat.com/mailman/listinfo/devtools | > | | _______________________________________________ | Devtools mailing list | Devtools at redhat.com | https://www.redhat.com/mailman/listinfo/devtools | -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen From bsutter at redhat.com Thu May 19 01:48:18 2016 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 18 May 2016 21:48:18 -0400 Subject: [Devtools] export OPENSHIFT_VAGRANT_USE_OSE_3_2=true Message-ID: I have seen a reference or two to this piece of magic export OPENSHIFT_VAGRANT_USE_OSE_3_2=true does this really work with a CDK 2.0.0? Like the one we shipped from developers.redhat.com? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Thu May 19 03:29:30 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 19 May 2016 08:59:30 +0530 Subject: [Devtools] Cockpit in ADB In-Reply-To: <429497178.52813698.1463621616092.JavaMail.zimbra@redhat.com> References: <429497178.52813698.1463621616092.JavaMail.zimbra@redhat.com> Message-ID: <30d918f4-acf2-bf6d-b812-830ff62e0b0b@redhat.com> On 05/19/2016 07:03 AM, Praveen Kumar wrote: > > ----- Original Message ----- > | From: "Pete Muir" > | To: "Lalatendu Mohanty" > | Cc: devtools at redhat.com, "container-tools" > | Sent: Wednesday, May 18, 2016 11:20:13 PM > | Subject: Re: [Devtools] Cockpit in ADB > | > | Is this installed on the host, or is it in a container? > > It installed in VM as rpm package not using container. As a container it would have been around 200MB and docker pulls take time . However recently we have identified extra set of packages in ADB which we have removed and it reduced the size of the Vagrantbox around 100MB. We have more plans to reduce the size too. > > | > | My concern is that it will increase the size of the VM. > > It's around 6MB and we can have a trade-off between increased size and functionality/user-experience it provides. > > | > | On 17 May 2016 at 18:43, Lalatendu Mohanty wrote: > | > Hi, > | > > | > We have added Cockpit packages to ADB as we thought it would add value to > | > ADB users. > | > > | > With Cockpit GUI an user can do docker pulls , docker runs etc apart from > | > system administration work. Cockpit also provides a web terminal which can > | > used to run docker commands without logging in to the Vagrantbox (it is > | > useful for Windows users as vagrant ssh does not work naively). > | > > | > How ever we are not sure whether it should be part of the default > | > experience > | > of ADB. So at this point the Cockpit service is not started by default. > | > There is an open issue for this [1] and we are looking for feedback. > | > > | > [1] https://github.com/projectatomic/adb-atomic-developer-bundle/issues/389 > | > > | > Thanks, > | > Lala > | > > | > _______________________________________________ > | > Devtools mailing list > | > Devtools at redhat.com > | > https://www.redhat.com/mailman/listinfo/devtools > | > > | > | _______________________________________________ > | Devtools mailing list > | Devtools at redhat.com > | https://www.redhat.com/mailman/listinfo/devtools > | > From lmohanty at redhat.com Thu May 19 03:39:40 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 19 May 2016 09:09:40 +0530 Subject: [Devtools] export OPENSHIFT_VAGRANT_USE_OSE_3_2=true In-Reply-To: References: Message-ID: On 05/19/2016 07:18 AM, Burr Sutter wrote: > I have seen a reference or two to this piece of magic > export OPENSHIFT_VAGRANT_USE_OSE_3_2=true > does this really work with a CDK 2.0.0? > Like the one we shipped from developers.redhat.com > ? It will not. Because OpenShift Origin and OSE have different steps to setup registry and router. Praveen has fixed it [1] it in upstream already. Will let you know when we have downstream build with it. [1] https://github.com/projectatomic/adb-utils/pull/120 > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From prkumar at redhat.com Thu May 19 06:02:20 2016 From: prkumar at redhat.com (Praveen Kumar) Date: Thu, 19 May 2016 11:32:20 +0530 Subject: [Devtools] export OPENSHIFT_VAGRANT_USE_OSE_3_2=true In-Reply-To: References: Message-ID: <1463637740.4795.7.camel@redhat.com> On Wed, 2016-05-18 at 21:48 -0400, Burr Sutter wrote: > I have seen a reference or two to this piece of magic > export OPENSHIFT_VAGRANT_USE_OSE_3_2=true This piece of magic you can only use if you try Vagrantfile[0], there we have a variable "OPENSHIFT_VAGRANT_USE_OSE_3_2=true" which can be used. > > does this really work with a CDK 2.0.0? No, but we now have nightly builds of CDK[1] which are having OSE3.2 (one which we shipped) so you can try those bits without any magic. > > Like the one we shipped from developers.redhat.com? Above mentioned Vagrantfile doesn't come with cdk.zip so here also it didn't work. [0]?https://github.com/redhat-developer-tooling/openshift-vagrant/blob/ master/cdk-v2/Vagrantfile [1]?http://cdk-builds.usersys.redhat.com/builds/nightly/latest-build/ From tmader at redhat.com Thu May 19 07:53:51 2016 From: tmader at redhat.com (=?UTF-8?Q?Thomas_M=c3=a4der?=) Date: Thu, 19 May 2016 09:53:51 +0200 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <20160518185806.GC59306@nineveh.lan> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C5FEA.8030705@dustymabe.com> <20160518185806.GC59306@nineveh.lan> Message-ID: <573D710F.2000307@redhat.com> Am 18.05.2016 um 20:58 schrieb Hardy Ferentschik: > I am usually also against asking questions, but this might be the only > way to get a user to at least read the question. We can write it in as > many places we want, unless we literally force the user to make a > choice, we will have people running into this problem. Since who read > documentation, right? --Hardy A question like that at first start will not work, as noone would understand it. I certainly wouldn't have. The underlying problem here is that we are very much cli-focused. This works well when someone has read through all the documentation and knows all the syntax, but it is not discoverable. If I don't know something is there, I will never know how to find out about it. We have some tooling for Openshift in Eclipse, but for any but the trivial things, we fall back on text editing. This shifts the burden of knowing Openshift configuration syntax to the user. The learning curve for Openshift is about as steep as the north face of the Eiger. If you have no previous knowledge of docker, kubernetes, networkding architecture, etc. you're totally up shit creek without a paddle. I would peg the effort at about 3 weeks of straight reading. The tools don't really help: when I do a "oc describe pods", you get about 10 pages of technobabble which no sane person can parse. Of course it takes you an hour to find a simple misconfiguration! /Thomas From tmader at redhat.com Thu May 19 10:26:48 2016 From: tmader at redhat.com (=?UTF-8?Q?Thomas_M=c3=a4der?=) Date: Thu, 19 May 2016 12:26:48 +0200 Subject: [Devtools] jmx over jboss remoting client jars Message-ID: <573D94E8.5090502@redhat.com> Hi folks, as part of a larger effort, I'm trying to establish jmx connections to eap or wildfly servers inside Openshift/CDK. In a prototype version, this all works well. However, I've recently learned that the version of jmx remoting used is tightly coupled with the wildfly/eap version (see here for an indication: https://paste.fedoraproject.org/368295/14636462/) The problem now is to use the exact right remoting-jmx client version for the server running inside the Openshift pod. This has two facets: 1. How do I know the exact version of the Widlfly or EAP running in the pod Curently, we do some guessing of the version via the template name of the application. Can anyone suggest a generally applicapble and reliable way to find out what server is running inside a pod? 2. Where do I get the appropriate client jar for that version With local servers, we work around this problem by dyncamically adding a classloader for the jbossclient(-all).jar in the server runtime. The trouble with Openshift is that we don't really have access to the server runtime. So assuming we know the server version, we have two options: 1. Bundle client jars with eclipse or 2. get the client jar from the pod via rsync. I'd love to hear you guys chime in, since I am a bit lost here. /Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From aweiteka at redhat.com Thu May 19 12:13:55 2016 From: aweiteka at redhat.com (Aaron Weitekamp) Date: Thu, 19 May 2016 08:13:55 -0400 Subject: [Devtools] openshift is way too permissive in the CDK/ADB In-Reply-To: <573D710F.2000307@redhat.com> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <573C5FEA.8030705@dustymabe.com> <20160518185806.GC59306@nineveh.lan> <573D710F.2000307@redhat.com> Message-ID: On Thu, May 19, 2016 at 3:53 AM, Thomas M?der wrote: > Am 18.05.2016 um 20:58 schrieb Hardy Ferentschik: > >> I am usually also against asking questions, but this might be the only >> way to get a user to at least read the question. We can write it in as many >> places we want, unless we literally force the user to make a choice, we >> will have people running into this problem. Since who read documentation, >> right? --Hardy >> > > A question like that at first start will not work, as noone would > understand it. I certainly wouldn't have. > The underlying problem here is that we are very much cli-focused. This > works well when someone has read through all the documentation and knows > all the syntax, but it is not discoverable. If I don't know something is > there, I will never know how to find out about it. > > We have some tooling for Openshift in Eclipse, but for any but the trivial > things, we fall back on text editing. This shifts the burden of knowing > Openshift configuration syntax to the user. > > > The learning curve for Openshift is about as steep as the north face of > the Eiger. If you have no previous knowledge of docker, kubernetes, > networkding architecture, etc. you're totally up shit creek without a > paddle. I would peg the effort at about 3 weeks of straight reading. The > tools don't really help: when I do a "oc describe pods", you get about 10 > pages of technobabble which no sane person can parse. Of course it takes > you an hour to find a simple misconfiguration! > > > ? Yes, and I think the CDK needs to fill this void. We need more than an "evaluation" tool, as valuable as that is. OpenShift itself can and will close some of these gaps but not all. ? > /Thomas > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dusty at dustymabe.com Thu May 19 13:28:26 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Thu, 19 May 2016 09:28:26 -0400 Subject: [Devtools] redhat registry: What repo toplevel for atomicapp? In-Reply-To: <1632322206.52813362.1463621011170.JavaMail.zimbra@redhat.com> References: <573CC29B.4070605@dustymabe.com> <1632322206.52813362.1463621011170.JavaMail.zimbra@redhat.com> Message-ID: <573DBF7A.6010303@dustymabe.com> On 05/18/2016 09:23 PM, Praveen Kumar wrote: > > > ----- Original Message ----- > | From: "Dusty Mabe" > | To: devtools at redhat.com > | Sent: Thursday, May 19, 2016 12:59:31 AM > | Subject: [Devtools] redhat registry: What repo toplevel for atomicapp? > | > | In the Red Hat registry I can only get AtomicApp from: > | > | docker pull devstudio/atomicapp > > We are under devstudio namespace[0]. We recently did that migration and will file another request to remove cdk_beta to avoid any confusion. > > [0] https://projects.engineering.redhat.com/browse/RCM-2162 Can we get the tags fixed? See my other email From rcernich at redhat.com Thu May 19 14:28:34 2016 From: rcernich at redhat.com (Rob Cernich) Date: Thu, 19 May 2016 10:28:34 -0400 (EDT) Subject: [Devtools] jmx over jboss remoting client jars In-Reply-To: <573D94E8.5090502@redhat.com> References: <573D94E8.5090502@redhat.com> Message-ID: <888940734.15871958.1463668114858.JavaMail.zimbra@redhat.com> Hey Thomas, You can look at the labels for the image. There should be a JBOSS_PRODUCT label in each image, along with something like JBOSS_EAP_VERSION, JBOSS_DATAGRID_VERSION, etc., which has the version. You can also look at the image name. EAP 6.4 images are named: jboss-eap-6/eap64 - base product image (i.e. no openshift integration) jboss-eap-6/eap64-openshift - OpenShift s2i image (with clustering and all the configuration goodies) Hope that helps. Rob ----- Original Message ----- > Hi folks, > as part of a larger effort, I'm trying to establish jmx connections to eap or > wildfly servers inside Openshift/CDK. In a prototype version, this all works > well. However, I've recently learned that the version of jmx remoting used > is tightly coupled with the wildfly/eap version (see here for an indication: > https://paste.fedoraproject.org/368295/14636462/ ) > The problem now is to use the exact right remoting-jmx client version for the > server running inside the Openshift pod. This has two facets: > 1. How do I know the exact version of the Widlfly or EAP running in the pod > Curently, we do some guessing of the version via the template name of the > application. Can anyone suggest a generally applicapble and reliable way to > find out what server is running inside a pod? > 2. Where do I get the appropriate client jar for that version With local > servers, we work around this problem by dyncamically adding a classloader > for the jbossclient(-all).jar in the server runtime. The trouble with > Openshift is that we don't really have access to the server runtime. So > assuming we know the server version, we have two options: > 1. Bundle client jars with eclipse or > 2. get the client jar from the pod via rsync. > I'd love to hear you guys chime in, since I am a bit lost here. > /Thomas > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From prkumar at redhat.com Thu May 19 14:39:52 2016 From: prkumar at redhat.com (Praveen Kumar) Date: Thu, 19 May 2016 20:09:52 +0530 Subject: [Devtools] redhat registry: What repo toplevel for atomicapp? In-Reply-To: <573CC5BE.5040801@dustymabe.com> References: <573CC29B.4070605@dustymabe.com> <573CC5BE.5040801@dustymabe.com> Message-ID: <1463668792.4795.11.camel@redhat.com> On Wed, 2016-05-18 at 15:42 -0400, Dusty Mabe wrote: > Also the tags for atomicapp in the registry are inappropriate. The > latest version is 0.5.0 but the tags that I can pull from are: > > ``` > # skopeo registry.access.redhat.com/devstudio/atomicapp??2>/dev/null > | jq '.RepoTags' > [ > ? "7.2-13", > ? "latest" > ] > ``` > > What we are doing upstream looks much different: > > ``` > # skopeo docker.io/projectatomic/atomicapp??2>/dev/null | jq > '.RepoTags'?????????????????????????????????????????????????????????? > ????????????????????????????????????????????????????????????????????? > ??????????????????? > [ > ? "0.0.1", > ? "0.1.0", > ? "0.1.1", > ? "0.1.10", > ? "0.1.11", > ? "0.1.12", > ? "0.1.2", > ? "0.1.3", > ? "0.2.1", > ? "0.2.2", > ? "0.2.3", > ? "0.3.0", > ? "0.3.1", > ? "0.4.0", > ? "0.4.1", > ? "0.4.2", > ? "0.4.3", > ? "0.4.4", > ? "0.4.5", > ? "0.5.0", > ? "0.5.1", > ? "dev", > ? "latest" > ] > ``` I filled a ticket[0] to update tags.? [0]?https://projects.engineering.redhat.com/browse/RCM-3014 From lmohanty at redhat.com Thu May 19 18:17:28 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 19 May 2016 23:47:28 +0530 Subject: [Devtools] Fwd: Released ADB 2.1.0 In-Reply-To: <9f6ecf66-48e6-83d1-ff07-201003fbbf67@redhat.com> References: <9f6ecf66-48e6-83d1-ff07-201003fbbf67@redhat.com> Message-ID: <09943aaf-230b-ab4b-9307-c0ad089673cd@redhat.com> -------- Forwarded Message -------- Subject: [Container-tools] Released ADB 2.1.0 Date: Thu, 19 May 2016 23:33:20 +0530 From: Lalatendu Mohanty To: container-tools We have released the Atomic Developer Bundle 2.1.0 through CentOS Atomic SIG. The ADB 2.1.0 release also includes release of following ecosystem projects: * adb-utils 1.6: A set of utility scripts and configuration files for ADB. * vagrant-service manager 1.0.2 : Enables easier access to the features and services provided by ADB ADB 2.1.0 release adds new featuresand several bug fixes, including: - Addingcockpitin ADB box.Refer the project documentation for start using it with ADB [5]. - Removed some unwanted RPMs to reduce the size of the Vagrantbox. adb-utils 1.6release includes several enhancements , including - Added bash script auto completion for oc, oadm and OpenShift - SCCLI is re-written in Python with some enhancements. vagrant-service-manager 1.0.2 release adds new features and bug fixes. For its release announcement , please refer https://www.redhat.com/archives/container-tools/2016-May/msg00019.html Known issues: * Running AtomicApp in ADB fails. Refer: https://github.com/projectatomic/adb-atomic-developer-bundle/issues/329 * Following workaround can be used till the above issue is fixed. $ sudo -E atomic run projectatomic/helloapache This release also includes many smaller changes and bugfixes, which are detailed in the release changelog of adb-utils [1]andADB [2]. Please update the ADB Vagrant box [4] and the vagrant-service-manager ($ vagrant plugin update vagrant-service-manager) and give the new ADB version a spin. [1] https://github.com/projectatomic/adb-utils/releases/tag/v1.6 [3] https://github.com/projectatomic/adb-atomic-developer-bundle/tree/v2.1.0 [4] https://github.com/projectatomic/adb-atomic-developer-bundle/blob/master/docs/updating.rst [5] https://github.com/projectatomic/adb-atomic-developer-bundle/blob/master/docs/cockpit.rst -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Container-tools mailing list Container-tools at redhat.com https://www.redhat.com/mailman/listinfo/container-tools From hferents at redhat.com Thu May 19 19:03:53 2016 From: hferents at redhat.com (Hardy Ferentschik) Date: Thu, 19 May 2016 21:03:53 +0200 Subject: [Devtools] [Container-tools] openshift is way too permissive in the CDK/ADB In-Reply-To: <395542e7-b1bc-c233-5cc7-ee4ac932308b@redhat.com> References: <573BE10B.7060707@dustymabe.com> <-4959106190020746004@unknownmsgid> <20160518184625.GA59306@nineveh.lan> <395542e7-b1bc-c233-5cc7-ee4ac932308b@redhat.com> Message-ID: <20160519190353.GA74394@nineveh.lan> Hi, On Thu, 19-May-2016 10:12, Daniel J Walsh wrote: > User namespace as you would expect it to work. (Container Isolation) does > not work yet. User Namespace can be used with docker-1.10, but only for > protecting the host from the container. All containers would run with the > same "DockerRoot". So one thing which always surprised me, is that Docker seems to recommend in its best practices to actually do change the USER - https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/ Hence, so many images on DockerHub follow this principle and each and every one won't run out of the box on OpenShift. Is it really so wrong? And if it is, why does Docker not change its recommendation? --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From bsutter at redhat.com Thu May 19 23:07:46 2016 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 19 May 2016 19:07:46 -0400 Subject: [Devtools] Cockpit in ADB In-Reply-To: <30d918f4-acf2-bf6d-b812-830ff62e0b0b@redhat.com> References: <429497178.52813698.1463621616092.JavaMail.zimbra@redhat.com> <30d918f4-acf2-bf6d-b812-830ff62e0b0b@redhat.com> Message-ID: On Wed, May 18, 2016 at 11:29 PM, Lalatendu Mohanty wrote: > On 05/19/2016 07:03 AM, Praveen Kumar wrote: > >> >> ----- Original Message ----- >> | From: "Pete Muir" >> | To: "Lalatendu Mohanty" >> | Cc: devtools at redhat.com, "container-tools" >> | Sent: Wednesday, May 18, 2016 11:20:13 PM >> | Subject: Re: [Devtools] Cockpit in ADB >> | >> | Is this installed on the host, or is it in a container? >> >> It installed in VM as rpm package not using container. >> > > As a container it would have been around 200MB and docker pulls take time > . However recently we have identified extra set of packages in ADB which we > have removed and it reduced the size of the Vagrantbox around 100MB. We > have more plans to reduce the size too. > > While I think Cockpit is cool, how does Cockpit add value to our "enterprise developer"? There is an interest in slimming the size (disk & RAM) of downloadable VM (.box) not beefing it up. :-) > > >> | >> | My concern is that it will increase the size of the VM. >> >> It's around 6MB and we can have a trade-off between increased size and >> functionality/user-experience it provides. >> >> | >> | On 17 May 2016 at 18:43, Lalatendu Mohanty wrote: >> | > Hi, >> | > >> | > We have added Cockpit packages to ADB as we thought it would add >> value to >> | > ADB users. >> | > >> | > With Cockpit GUI an user can do docker pulls , docker runs etc apart >> from >> | > system administration work. Cockpit also provides a web terminal >> which can >> | > used to run docker commands without logging in to the Vagrantbox (it >> is >> | > useful for Windows users as vagrant ssh does not work naively). >> | > >> | > How ever we are not sure whether it should be part of the default >> | > experience >> | > of ADB. So at this point the Cockpit service is not started by >> default. >> | > There is an open issue for this [1] and we are looking for feedback. >> | > >> | > [1] >> https://github.com/projectatomic/adb-atomic-developer-bundle/issues/389 >> | > >> | > Thanks, >> | > Lala >> | > >> | > _______________________________________________ >> | > Devtools mailing list >> | > Devtools at redhat.com >> | > https://www.redhat.com/mailman/listinfo/devtools >> | > >> | >> | _______________________________________________ >> | Devtools mailing list >> | Devtools at redhat.com >> | https://www.redhat.com/mailman/listinfo/devtools >> | >> >> > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Fri May 20 02:19:05 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 20 May 2016 07:49:05 +0530 Subject: [Devtools] Cockpit in ADB In-Reply-To: References: <429497178.52813698.1463621616092.JavaMail.zimbra@redhat.com> <30d918f4-acf2-bf6d-b812-830ff62e0b0b@redhat.com> Message-ID: <3e76f0c9-be7a-ff39-6788-6e03cd84e5f6@redhat.com> On 05/20/2016 04:37 AM, Burr Sutter wrote: > > > On Wed, May 18, 2016 at 11:29 PM, Lalatendu Mohanty > > wrote: > > On 05/19/2016 07:03 AM, Praveen Kumar wrote: > > > ----- Original Message ----- > | From: "Pete Muir" > > | To: "Lalatendu Mohanty" > > | Cc: devtools at redhat.com , > "container-tools" > > | Sent: Wednesday, May 18, 2016 11:20:13 PM > | Subject: Re: [Devtools] Cockpit in ADB > | > | Is this installed on the host, or is it in a container? > > It installed in VM as rpm package not using container. > > > As a container it would have been around 200MB and docker pulls > take time . However recently we have identified extra set of > packages in ADB which we have removed and it reduced the size of > the Vagrantbox around 100MB. We have more plans to reduce the size > too. > > > While I think Cockpit is cool, how does Cockpit add value to our > "enterprise developer"? We had a long discussion in https://github.com/projectatomic/adb-atomic-developer-bundle/issues/389 :) > > There is an interest in slimming the size (disk & RAM) of downloadable > VM (.box) not beefing it up. :-) > > > > | > | My concern is that it will increase the size of the VM. > > It's around 6MB and we can have a trade-off between increased > size and functionality/user-experience it provides. > > | > | On 17 May 2016 at 18:43, Lalatendu Mohanty > > wrote: > | > Hi, > | > > | > We have added Cockpit packages to ADB as we thought it > would add value to > | > ADB users. > | > > | > With Cockpit GUI an user can do docker pulls , docker runs > etc apart from > | > system administration work. Cockpit also provides a web > terminal which can > | > used to run docker commands without logging in to the > Vagrantbox (it is > | > useful for Windows users as vagrant ssh does not work > naively). > | > > | > How ever we are not sure whether it should be part of the > default > | > experience > | > of ADB. So at this point the Cockpit service is not > started by default. > | > There is an open issue for this [1] and we are looking for > feedback. > | > > | > [1] > https://github.com/projectatomic/adb-atomic-developer-bundle/issues/389 > | > > | > Thanks, > | > Lala > | > > | > _______________________________________________ > | > Devtools mailing list > | > Devtools at redhat.com > | > https://www.redhat.com/mailman/listinfo/devtools > | > > | > | _______________________________________________ > | Devtools mailing list > | Devtools at redhat.com > | https://www.redhat.com/mailman/listinfo/devtools > | > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmader at redhat.com Fri May 20 07:34:25 2016 From: tmader at redhat.com (=?UTF-8?Q?Thomas_M=c3=a4der?=) Date: Fri, 20 May 2016 09:34:25 +0200 Subject: [Devtools] jmx over jboss remoting client jars In-Reply-To: <888940734.15871958.1463668114858.JavaMail.zimbra@redhat.com> References: <573D94E8.5090502@redhat.com> <888940734.15871958.1463668114858.JavaMail.zimbra@redhat.com> Message-ID: <84b5f8c6-be62-2560-3fb3-0faa6c2bbbb5@redhat.com> Hi Rob, thanks for that input. Can you point me to some documentation about theses labels and what values they can have? I'm trying to prevent a case where stuff breaks with each minor update. Thomas Am 19.05.2016 um 16:28 schrieb Rob Cernich: > Hey Thomas, > > You can look at the labels for the image. There should be a > JBOSS_PRODUCT label in each image, along with something like > JBOSS_EAP_VERSION, JBOSS_DATAGRID_VERSION, etc., which has the version. > > You can also look at the image name. EAP 6.4 images are named: > jboss-eap-6/eap64 - base product image (i.e. no openshift integration) > jboss-eap-6/eap64-openshift - OpenShift s2i image (with clustering and > all the configuration goodies) > > Hope that helps. > Rob > > > ------------------------------------------------------------------------ > > Hi folks, > > as part of a larger effort, I'm trying to establish jmx > connections to eap or wildfly servers inside Openshift/CDK. In a > prototype version, this all works well. However, I've recently > learned that the version of jmx remoting used is tightly coupled > with the wildfly/eap version (see here for an indication: > https://paste.fedoraproject.org/368295/14636462/) > The problem now is to use the exact right remoting-jmx client > version for the server running inside the Openshift pod. This has > two facets: > > 1. How do I know the exact version of the Widlfly or EAP running > in the pod > Curently, we do some guessing of the version via the template > name of the application. Can anyone suggest a generally > applicapble and reliable way to find out what server is > running inside a pod? > 2. Where do I get the appropriate client jar for that version > With local servers, we work around this problem by > dyncamically adding a classloader for the > jbossclient(-all).jar in the server runtime. The trouble with > Openshift is that we don't really have access to the server > runtime. So assuming we know the server version, we have two > options: > 1. Bundle client jars with eclipse or > 2. get the client jar from the pod via rsync. > > I'd love to hear you guys chime in, since I am a bit lost here. > > /Thomas > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdrage at redhat.com Fri May 20 15:22:41 2016 From: cdrage at redhat.com (Charlie Drage) Date: Fri, 20 May 2016 11:22:41 -0400 Subject: [Devtools] Atomic App 0.5.2 pre-release Message-ID: <20160520152241.GA1@a4adf86fe551> Hey all, We'll be doing a release of Atomic App on Tuesday! Please ping the respective people if you still have any open PR's :) Best regards, -- Charlie Drage Red Hat - OSAS Team / Project Atomic 4096R / 0x9B3B446C http://pgp.mit.edu/pks/lookup?op=get&search=0x622CDF119B3B446C From pchandra at redhat.com Mon May 23 10:03:52 2016 From: pchandra at redhat.com (Preeti Chandrashekar) Date: Mon, 23 May 2016 15:33:52 +0530 Subject: [Devtools] Proposal - Moving container development tools docs to the Asciidoc format Message-ID: Hi All, In line with our ongoing efforts at streamlining the docs process, and in order to ensure better upstream-downstream coordination, we are proposing to move to the Asciidoc format for docs related to container development tools in Project Atomic. Adoption of Asciidoc would: - allow us to leverage existing code for publishing to docs.projecatomic.io. - allow for easier contribution by downstream communities that have standardized on Asciidoc. AsciiDoc belongs to the family of lightweight markup languages, the most renowned of which is Markdown [1]. It is very similar to markdown in terms of formatting and is not that steep a curve in terms of learning [2]. Please let us know what you think about this so that the docs team can freeze on the process. [1] [http://asciidoctor.org/docs/what-is-asciidoc/] [2] [http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/] Thank you, Regards, Preeti -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmader at redhat.com Mon May 23 10:10:09 2016 From: tmader at redhat.com (=?UTF-8?Q?Thomas_M=c3=a4der?=) Date: Mon, 23 May 2016 12:10:09 +0200 Subject: [Devtools] jmx over jboss remoting client jars In-Reply-To: <573D94E8.5090502@redhat.com> References: <573D94E8.5090502@redhat.com> Message-ID: <7e3a893e-e826-75ce-f40f-5fbc4fac1e61@redhat.com> I have created pull requests https://github.com/jbosstools/jbosstools-openshift/pull/1175 and https://github.com/jbosstools/jbosstools-server/pull/417 incorporating option 2.2 from below. /Thomas Am 19.05.2016 um 12:26 schrieb Thomas M?der: > Hi folks, > > as part of a larger effort, I'm trying to establish jmx connections to > eap or wildfly servers inside Openshift/CDK. In a prototype version, > this all works well. However, I've recently learned that the version > of jmx remoting used is tightly coupled with the wildfly/eap version > (see here for an indication: > https://paste.fedoraproject.org/368295/14636462/) > The problem now is to use the exact right remoting-jmx client version > for the server running inside the Openshift pod. This has two facets: > > 1. How do I know the exact version of the Widlfly or EAP running in > the pod > Curently, we do some guessing of the version via the template name > of the application. Can anyone suggest a generally applicapble and > reliable way to find out what server is running inside a pod? > 2. Where do I get the appropriate client jar for that version > With local servers, we work around this problem by dyncamically > adding a classloader for the jbossclient(-all).jar in the server > runtime. The trouble with Openshift is that we don't really have > access to the server runtime. So assuming we know the server > version, we have two options: > 1. Bundle client jars with eclipse or > 2. get the client jar from the pod via rsync. > > I'd love to hear you guys chime in, since I am a bit lost here. > > /Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From aslak at redhat.com Mon May 23 10:10:19 2016 From: aslak at redhat.com (Aslak Knutsen) Date: Mon, 23 May 2016 12:10:19 +0200 Subject: [Devtools] Proposal - Moving container development tools docs to the Asciidoc format In-Reply-To: References: Message-ID: +100 :) The ALM plan to support AsciiDoc as a first class citizen where ever possible/feasible as well. Issues/Descriptions/README's/Wiki/Docs etc. -aslak- On Mon, May 23, 2016 at 12:03 PM, Preeti Chandrashekar wrote: > Hi All, > > In line with our ongoing efforts at streamlining the docs process, and in > order to ensure better upstream-downstream coordination, we are proposing > to move to the Asciidoc format for docs related to container development > tools in Project Atomic. > > Adoption of Asciidoc would: > - allow us to leverage existing code for publishing to > docs.projecatomic.io. > - allow for easier contribution by downstream communities that have > standardized on Asciidoc. > > AsciiDoc belongs to the family of lightweight markup languages, the most > renowned of which is Markdown [1]. It is very similar to markdown in terms > of formatting and is not that steep a curve in terms of learning [2]. > > Please let us know what you think about this so that the docs team can > freeze on the process. > > [1] [http://asciidoctor.org/docs/what-is-asciidoc/] > [2] [http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/] > > Thank you, > Regards, > Preeti > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hferents at redhat.com Mon May 23 14:32:55 2016 From: hferents at redhat.com (Hardy Ferentschik) Date: Mon, 23 May 2016 16:32:55 +0200 Subject: [Devtools] Proposal - Moving container development tools docs to the Asciidoc format In-Reply-To: References: Message-ID: <20160523143255.GB15282@nineveh.local> On Mon, 23-May-2016 12:10, Aslak Knutsen wrote: > +100 :) I'll add another +100 :-) --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From lmohanty at redhat.com Mon May 23 15:07:10 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 23 May 2016 20:37:10 +0530 Subject: [Devtools] [atomic-devel] Proposal - Moving container development tools docs to the Asciidoc format In-Reply-To: References: Message-ID: <36622277-2bc8-19e7-7f47-5894253937de@redhat.com> On 05/23/2016 03:33 PM, Preeti Chandrashekar wrote: > Hi All, > > In line with our ongoing efforts at streamlining the docs process, and > in order to ensure better upstream-downstream coordination, we are > proposing to move to the Asciidoc format for docs related to container > development tools in Project Atomic. > > Adoption of Asciidoc would: > - allow us to leverage existing code for publishing to > docs.projecatomic.io . > - allow for easier contribution by downstream communities that have > standardized on Asciidoc. > > AsciiDoc belongs to the family of lightweight markup languages, the > most renowned of which is Markdown [1]. It is very similar to markdown > in terms of formatting and is not that steep a curve in terms of > learning [2]. > > Please let us know what you think about this so that the docs team can > freeze on the process. > > [1] [http://asciidoctor.org/docs/what-is-asciidoc/] > [2] [http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/] > > Thank you, > Regards, > Preeti +1 for ascii doc. Have you looked in to tools for doing mass conversion of docs already exists in reStructuredText and makrdown to ascii doc? So that the move will become relatively smooth. Thanks, Lala -------------- next part -------------- An HTML attachment was scrubbed... URL: From bex at pobox.com Tue May 24 10:49:48 2016 From: bex at pobox.com (Brian (bex) Exelbierd) Date: Tue, 24 May 2016 12:49:48 +0200 Subject: [Devtools] [atomic-devel] Proposal - Moving container development tools docs to the Asciidoc format In-Reply-To: <36622277-2bc8-19e7-7f47-5894253937de@redhat.com> References: <36622277-2bc8-19e7-7f47-5894253937de@redhat.com> Message-ID: <574431CC.9070001@pobox.com> On 05/23/2016 05:07 PM, Lalatendu Mohanty wrote: > +1 for ascii doc. Have you looked in to tools for doing mass conversion > of docs already exists in reStructuredText and makrdown to ascii doc? So > that the move will become relatively smooth. I've done some test conversions and don't believe this will be onerous. regards, bex From bex at pobox.com Tue May 24 10:53:28 2016 From: bex at pobox.com (Brian (bex) Exelbierd) Date: Tue, 24 May 2016 12:53:28 +0200 Subject: [Devtools] [Container-tools] [atomic-devel] Proposal - Moving container development tools docs to the Asciidoc format In-Reply-To: <57434FAA.8060308@redhat.com> References: <57434FAA.8060308@redhat.com> Message-ID: <574432A8.2050507@pobox.com> On 05/23/2016 08:44 PM, Josh Berkus wrote: > On 05/23/2016 06:03 AM, Preeti Chandrashekar wrote: >> Hi All, >> >> In line with our ongoing efforts at streamlining the docs process, and >> in order to ensure better upstream-downstream coordination, we >> are proposing to move to the Asciidoc format for docs related to >> container development tools in Project Atomic. > > I'm happy for this to be our default, but I'm concerned about making > existing projects port their docs. For one thing, at least a couple of > projects make use of readthedocs.org, which requires a different format. The initial goal is to port just ADB, vagrant-service-manager, and adb-utils. Other projects should be considered on a case-by-case basis. regards, bex From jporter at redhat.com Wed May 25 14:46:11 2016 From: jporter at redhat.com (Jason Porter) Date: Wed, 25 May 2016 08:46:11 -0600 Subject: [Devtools] [Container-tools] [atomic-devel] Proposal - Moving container development tools docs to the Asciidoc format In-Reply-To: <574432A8.2050507@pobox.com> References: <57434FAA.8060308@redhat.com> <574432A8.2050507@pobox.com> Message-ID: Hi all, adding the asciidoc list here. There's some work going on around docbookrx [1] to make it a better conversion utility. I strong recommend looking it (if you're converting from docbook) and other tools those on the asciidoc list know about. [1] https://github.com/asciidoctor/docbookrx On Tue, May 24, 2016 at 4:53 AM, Brian (bex) Exelbierd wrote: > On 05/23/2016 08:44 PM, Josh Berkus wrote: > >> On 05/23/2016 06:03 AM, Preeti Chandrashekar wrote: >> >>> Hi All, >>> >>> In line with our ongoing efforts at streamlining the docs process, and >>> in order to ensure better upstream-downstream coordination, we >>> are proposing to move to the Asciidoc format for docs related to >>> container development tools in Project Atomic. >>> >> >> I'm happy for this to be our default, but I'm concerned about making >> existing projects port their docs. For one thing, at least a couple of >> projects make use of readthedocs.org, which requires a different format. >> > > The initial goal is to port just ADB, vagrant-service-manager, and > adb-utils. Other projects should be considered on a case-by-case basis. > > > regards, > > bex > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -- Jason Porter Senior Software Engineer developers.redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bex at pobox.com Thu May 26 12:57:18 2016 From: bex at pobox.com (Brian (bex) Exelbierd) Date: Thu, 26 May 2016 18:27:18 +0530 Subject: [Devtools] Proposal - Moving container development tools docs to the Asciidoc format In-Reply-To: References: Message-ID: <5746F2AE.9030203@pobox.com> An Issue (and fixing PR) has been opened to convert the vagrant-service-manager docs per the below https://github.com/projectatomic/vagrant-service-manager/issues/233 I'd encourage everyone to take a look so we can close this via lazy consensus and then we (docs) can begin looking at adb and adb-utils. regards, bex On 05/23/2016 03:33 PM, Preeti Chandrashekar wrote: > Hi All, > > In line with our ongoing efforts at streamlining the docs process, and > in order to ensure better upstream-downstream coordination, we are > proposing to move to the Asciidoc format for docs related to container > development tools in Project Atomic. > > Adoption of Asciidoc would: > - allow us to leverage existing code for publishing to > docs.projecatomic.io . > - allow for easier contribution by downstream communities that have > standardized on Asciidoc. > > AsciiDoc belongs to the family of lightweight markup languages, the most > renowned of which is Markdown [1]. It is very similar to markdown in > terms of formatting and is not that steep a curve in terms of learning [2]. > > Please let us know what you think about this so that the docs team can > freeze on the process. > > [1] [http://asciidoctor.org/docs/what-is-asciidoc/] > [2] [http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/] > > Thank you, > Regards, > Preeti > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -- Brian (bex) Exelbierd | bex at pobox.com +420-606-055-877 | @bexelbie http://www.winglemeyer.org From bex at pobox.com Thu May 26 13:06:58 2016 From: bex at pobox.com (Brian (bex) Exelbierd) Date: Thu, 26 May 2016 18:36:58 +0530 Subject: [Devtools] Consolidate Docs for ADB (and related projects) into a single repo Message-ID: <5746F4F2.3010106@pobox.com> Hola, We'd like to consolidate the documentation related to the ADB into a new repository in ProjectAtomic GH namespace. The working name for the repo is "Developer-Docs". The affected projects would be: ADB, Vagrant-Service-Manager and ADB-utils. The goal of this move is to: o Make it easier to tell a cohesive story and improve onboarding. o Enable deeper cross-linking o Enable easier community contribution (including downstream consumers) by centralizing docs to reduce "hunting" o Enable easier publishing to docs.projectatomic.io (very WIP/conceptual) - it will at least not make it harder Docs that are for developers working on the tools themselves will not be moved at this time. This can be done if there is a general feeling this is valuable. Each sub-project repo's README would be updated to direct users to the docs in the published location (initially in the new repo). Given the impact of these changes, I'd like to see acks from an appropriate set of maintainers from each project. If a project would like an issue to ack against in their project, please reply and I will create one. Assuming it is accepted, the conversion to AsciiDoc will be done in conjunction with this move. We may also reorder/rewrite docs as a part of this to begin telling a more cohesive and complete story. Thank you. regards, bex From cdrage at redhat.com Mon May 30 13:45:44 2016 From: cdrage at redhat.com (Charlie Drage) Date: Mon, 30 May 2016 09:45:44 -0400 Subject: [Devtools] Weekly IRC Nulecule Meeting Message-ID: <20160530134544.GD1@06ce32f5f87d> Short meeting this week :) https://meetbot.fedoraproject.org/nulecule/2016-05-30/nulecule_weekly_irc_meeting.2016-05-30-13.32.log.html -- Charlie Drage Red Hat - OSAS Team / Project Atomic 4096R / 0x9B3B446C http://pgp.mit.edu/pks/lookup?op=get&search=0x622CDF119B3B446C