From vpereira at redhat.com Mon Aug 1 08:23:36 2016 From: vpereira at redhat.com (Vineet Reynolds Pereira) Date: Mon, 1 Aug 2016 13:53:36 +0530 Subject: [Devtools] Installing CDK - some issues noted Message-ID: Hello list, I tried out CDK 2.1 on a brand new Macbook, to test drive the installation experience. An installation was also attempted on a Linux box by someone in my team; he eventually installed CDK on a Debian host instead of a RHEL 7 VM on the same host. I'll focus on Mac, since we're looking at Windows and Mac users primarily. There are some suggestions to improve this experience. * Vagrant version issues (Mac) I started with Vagrant 1.8.5 (the latest), then ran into this bug with SSH keys [1] when bringing up the CDK vagrant box. Tried downgrading to 1.8.4, and ran into this one [2] involving installation of local gems supplied by CDK. Ultimately, I downgraded all the way down to 1.8.1, because the CDK version "appeared" to have been tested against it. * Virtualbox version issues (Mac) Vagrant 1.8.5 supports Virtualbox 5.1.x (latest) [3], but on downgrading vagrant to 1.8.1, it proceeds to download Virtualbox 5.0 when bringing up the Vagrant box. Vagrant fails to download and install Virtualbox for some reason (I didn't bother to debug any more vagrant issues at this point), and went and manually downgraded Virtualbox to 5.0.26. That's three downgrades in one installation session. * Documentation for Linux users I'm a bit lost on this area, since there might a product direction I'm unaware of. I see that the documentation references Vagrant+VirtualBox as something that can be installed on any Linux OS, by talking about deps and rpms. But, the rest of the documentation is specific on RHEL 7 Server. I have a few open questions here - ** Why is there focus on RHEL 7 Server, when developers on Linux are unlikely to use this for day-to-day development tasks? For someone using Ubuntu or Fedora with Virtualbox, the Linux docs are only partially useful, given they address libvirt on RHEL 7. ** Is there any open issue to ensure we address other prominent Linux distros? * OSE client (oc executable) The documentation on obtaining the OpenShift client, is present in an RST in CDK.zip, but not in the docs. I think this was discussed previously in some other thread, but I thought I'd mention it again incase it wasn't. Suggestions follow: * Publish the testing matrix prominently on what versions of pre-requisites users need to get CDK up and running without issues. If it's already written down somewhere, it needs to be prominent in the installation pre-requisites section of the doc. * Have nightly builds against our OS targets and possibly multiple versions of pre-requisites, so we know about issues involving pre-requisites even before our users do. * Expand the documentation for Linux users, and bring in clarity on multiple vagrant providers. If we are going to support only libvirt usage for Linux users in our docs, we should declare this as a pre-requisite. Thanks for your time in reading this. Regards Vineet [1]: https://github.com/mitchellh/vagrant/issues/7631 [2]: https://github.com/mitchellh/vagrant/issues/7493 [3]: https://github.com/mitchellh/vagrant/issues/7411 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkratky at redhat.com Mon Aug 1 09:01:26 2016 From: rkratky at redhat.com (Robert Kratky) Date: Mon, 01 Aug 2016 11:01:26 +0200 Subject: [Devtools] Installing CDK - some issues noted In-Reply-To: References: Message-ID: <98006475.7ynGCCFTpK@x230> On 1.?8.?2016 13:53:36, Vineet Reynolds Pereira wrote: > Hello list, Hi Vineet, >From reading your post, I'm thinking there's some confusion with regard to CDK docs. Could you please specify what docs you're referring to? Official CDK docs are at https://access.redhat.com/documentation/en/red-hat-container-development-kit/ > I tried out CDK 2.1 on a brand new Macbook, to test drive the > installation experience. An installation was also attempted on a Linux box > by someone in my team; he eventually installed CDK on a Debian host instead > of a RHEL 7 VM on the same host. I'll focus on Mac, since we're looking at > Windows and Mac users primarily. There are some suggestions to improve this > experience. > > * Vagrant version issues (Mac) > I started with Vagrant 1.8.5 (the latest), then ran into this bug with > SSH keys [1] when bringing up the CDK vagrant box. Tried downgrading to > 1.8.4, and ran into this one [2] involving installation of local gems > supplied by CDK. Ultimately, I downgraded all the way down to 1.8.1, > because the CDK version "appeared" to have been tested against it. Our Release Notes contain a Vagrant compatibility matrix [1] that tells users to use 1.8.1 or 1.7.4 on Mac. The Installation Guide contains this info in relevant places [2]. > * Virtualbox version issues (Mac) > Vagrant 1.8.5 supports Virtualbox 5.1.x (latest) [3], but on downgrading > vagrant to 1.8.1, it proceeds to download Virtualbox 5.0 when bringing up > the Vagrant box. Vagrant fails to download and install Virtualbox for some > reason (I didn't bother to debug any more vagrant issues at this point), > and went and manually downgraded Virtualbox to 5.0.26. That's three > downgrades in one installation session. I wasn't aware of any VirtualBox-version restrictions. I'll work with QE and update the docs with this info. > * Documentation for Linux users > I'm a bit lost on this area, since there might a product direction I'm > unaware of. I see that the documentation references Vagrant+VirtualBox as > something that can be installed on any Linux OS, by talking about deps and > rpms. But, the rest of the documentation is specific on RHEL 7 Server. I > have a few open questions here - As I said before, I'm not sure what docs you've been following. Our Installation Guide instructs users of RHEL to use libvirt/KVM, not VirtualBox [3]. > ** Why is there focus on RHEL 7 Server, when developers on Linux are > unlikely to use this for day-to-day development tasks? For someone using > Ubuntu or Fedora with Virtualbox, the Linux docs are only partially useful, > given they address libvirt on RHEL 7. For CDK 2.1, RHEL was the only supported Linux distro. For previous versions, we had instructions for Fedora as well, but they had to be removed. I'm hoping that support for Fedora will be reintroduced in CDK 2.2 -- and then it'll be documented again. > ** Is there any open issue to ensure we address other prominent Linux > distros? > > * OSE client (oc executable) > The documentation on obtaining the OpenShift client, is present in an > RST in CDK.zip, but not in the docs. I think this was discussed previously > in some other thread, but I thought I'd mention it again incase it wasn't. The Getting Started Guide includes detailed instructions on how to obtain the 'oc' (and 'docker') clients [4] for all platforms. > Suggestions follow: > > * Publish the testing matrix prominently on what versions of pre-requisites > users need to get CDK up and running without issues. If it's already > written down somewhere, it needs to be prominent in the installation > pre-requisites section of the doc. See [1]. Also, install. instructions for each supported platform tell users exactly which versions to use. For example, for Mac, it's at [2]. > * Have nightly builds against our OS targets and possibly multiple versions > of pre-requisites, so we know about issues involving pre-requisites even > before our users do. Nightly builds: http://cdk-builds.usersys.redhat.com/builds/nightly/latest-build/ > * Expand the documentation for Linux users, and bring in clarity on > multiple vagrant providers. If we are going to support only libvirt usage > for Linux users in our docs, we should declare this as a pre-requisite. I'll be happy to work on improving the docs, but I'm pretty sure you're talking about some other docs than the official ones. I'm really keen to find out where the problem is, so that we don't have this confusion. > Thanks for your time in reading this. Thanks for the report. Regards, Robert > Regards > Vineet [1] https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/release-notes-and-known-issues/#vagrant_compatibility_matrix [2] https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/single/installation-guide/#additional_software_requirements_for_mac_os_x [3] https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/single/installation-guide/#installing_virtualization_and_container_development_kit_components [4] https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/getting-started-guide/#preparing_host_system_for_using_openshift_from_the_command_line From vpereira at redhat.com Mon Aug 1 10:58:18 2016 From: vpereira at redhat.com (Vineet Reynolds Pereira) Date: Mon, 1 Aug 2016 16:28:18 +0530 Subject: [Devtools] Installing CDK - some issues noted In-Reply-To: <98006475.7ynGCCFTpK@x230> References: <98006475.7ynGCCFTpK@x230> Message-ID: Thanks Robert, I went through the docs again - they are the same ones you reference. So, my suggestions and feedback will a bit more specific, which is inline. On Mon, Aug 1, 2016 at 2:31 PM, Robert Kratky wrote: > On 1.?8.?2016 13:53:36, Vineet Reynolds Pereira wrote: > > > Hello list, > > Hi Vineet, > > From reading your post, I'm thinking there's some confusion with regard to > CDK docs. Could you please specify what docs you're referring to? > > Official CDK docs are at > https://access.redhat.com/documentation/en/red-hat-container-development-kit/ > > > I tried out CDK 2.1 on a brand new Macbook, to test drive the > > installation experience. An installation was also attempted on a Linux > box > > by someone in my team; he eventually installed CDK on a Debian host > instead > > of a RHEL 7 VM on the same host. I'll focus on Mac, since we're looking > at > > Windows and Mac users primarily. There are some suggestions to improve > this > > experience. > > > > * Vagrant version issues (Mac) > > I started with Vagrant 1.8.5 (the latest), then ran into this bug with > > SSH keys [1] when bringing up the CDK vagrant box. Tried downgrading to > > 1.8.4, and ran into this one [2] involving installation of local gems > > supplied by CDK. Ultimately, I downgraded all the way down to 1.8.1, > > because the CDK version "appeared" to have been tested against it. > > Our Release Notes contain a Vagrant compatibility matrix [1] that tells > users to use 1.8.1 or 1.7.4 on Mac. The Installation Guide contains this > info in relevant places [2]. > Ok, I think we need to find a better way to present this, and I would suggest getting in touch the UX team. My onboarding workflow was like this: * Search for RedHat CDK and land at http://developers.redhat.com/products/cdk/overview/ * Get started with the call to action button and land at http://developers.redhat.com/products/cdk/get-started/ * Start the installation for Mac as indicated in the tab: http://developers.redhat.com/products/cdk/get-started/#tab-macLinux * I expected to see the versions here, since the page already talks about installing Virtualbox and Vagrant. In fact, it talks about Vagrant 1.7.4 for RHEL, but nothing about the Mac. This is probably where the troubles started, and I think a pre-requisite matrix would help here. * It only later that I land at the pages delivered as part of product documentation, from the getting started page. A specific comment on the Vagrant 1.8.1 pre-requisite noted in the docs - the version should be emphasized, and that's why I couldn't remember where I saw it first. It easy to gloss over that entire paragraph, because other parts of the page are bolded and made to stand out as more relevant. I think a bullet list of pre-requisites would be better, separated from other text would help. Someone from UX can help you more by revisiting the onboarding flow listed above. Generally speaking, the entire navigation flow allows for installation to fail because the important parts like pre-requisite versions are brought out much later in product docs, or they're not emphasized enough over other information. My point is not that documentation is bad. Developer experience is bad. I know, we as a company don't commit the obvious mistake of not documenting the necessary, but to our end-users the same information can be hard to find. > > > * Virtualbox version issues (Mac) > > Vagrant 1.8.5 supports Virtualbox 5.1.x (latest) [3], but on > downgrading > > vagrant to 1.8.1, it proceeds to download Virtualbox 5.0 when bringing up > > the Vagrant box. Vagrant fails to download and install Virtualbox for > some > > reason (I didn't bother to debug any more vagrant issues at this point), > > and went and manually downgraded Virtualbox to 5.0.26. That's three > > downgrades in one installation session. > > I wasn't aware of any VirtualBox-version restrictions. I'll work with QE > and update the docs with this info. > It's a dependency for Vagrant as as vagrant provider, so sometimes Vagrant needs to support newer versions of Virtualbox in newer Vagrant releases. It needs to be addressed in the navigation flow, but yes, this needs revisiting from QE every release for the test matrix. > > * Documentation for Linux users > > I'm a bit lost on this area, since there might a product direction I'm > > unaware of. I see that the documentation references Vagrant+VirtualBox as > > something that can be installed on any Linux OS, by talking about deps > and > > rpms. But, the rest of the documentation is specific on RHEL 7 Server. I > > have a few open questions here - > > As I said before, I'm not sure what docs you've been following. Our > Installation Guide instructs users of RHEL to use libvirt/KVM, not > VirtualBox [3]. > Ok, going by the navigation flow, it looks the the Getting Started page at http://developers.redhat.com/products/cdk/get-started/#tab-macLinux needs to have all of this info. It allows Linux users (RHEL is Linux) to bring VirtualBox and use it, and the docs do not address how to use this vagrant provider later, instead driving the user to libvirt. I believe this particular page is not owned by docs, and I'm not faulting anyone for this, but the overall experience to end users is disjointed. > > > ** Why is there focus on RHEL 7 Server, when developers on Linux are > > unlikely to use this for day-to-day development tasks? For someone using > > Ubuntu or Fedora with Virtualbox, the Linux docs are only partially > useful, > > given they address libvirt on RHEL 7. > > For CDK 2.1, RHEL was the only supported Linux distro. For previous > versions, we had instructions for Fedora as well, but they had to be > removed. I'm hoping that support for Fedora will be reintroduced in CDK 2.2 > -- and then it'll be documented again. > That would be great to not have that regression in supported OSes. But what about other OSes? Are we going to tell developers to install RHEL/Fedora when their work OS is a different Linux distro, or is this going to be left to the community(ADB) to address ? > > > ** Is there any open issue to ensure we address other prominent > Linux > > distros? > > > > * OSE client (oc executable) > > The documentation on obtaining the OpenShift client, is present in an > > RST in CDK.zip, but not in the docs. I think this was discussed > previously > > in some other thread, but I thought I'd mention it again incase it > wasn't. > > The Getting Started Guide includes detailed instructions on how to obtain > the 'oc' (and 'docker') clients [4] for all platforms. > I missed making a suggestion in the original mail. Did we explore about packaging OpenShift client tools as part of CDK zip distribution itself? That would be great and I don't see why we shouldn't (licensing concerns et al). > > > Suggestions follow: > > > > * Publish the testing matrix prominently on what versions of > pre-requisites > > users need to get CDK up and running without issues. If it's already > > written down somewhere, it needs to be prominent in the installation > > pre-requisites section of the doc. > > See [1]. Also, install. instructions for each supported platform tell > users exactly which versions to use. For example, for Mac, it's at [2]. > > > * Have nightly builds against our OS targets and possibly multiple > versions > > of pre-requisites, so we know about issues involving pre-requisites even > > before our users do. > > Nightly builds: > http://cdk-builds.usersys.redhat.com/builds/nightly/latest-build/ > > > * Expand the documentation for Linux users, and bring in clarity on > > multiple vagrant providers. If we are going to support only libvirt usage > > for Linux users in our docs, we should declare this as a pre-requisite. > > I'll be happy to work on improving the docs, but I'm pretty sure you're > talking about some other docs than the official ones. I'm really keen to > find out where the problem is, so that we don't have this confusion. > Atleast to me it's now obvious that we need to work with our UX team on this. developers.redhat.com is where developers are onboarded and driven to the production docs later. And they're owned and updated by two different teams. I haven't seen the designed navigation flow in entirety, but it's obvious that developers.redhat.com expects (or would expect in the future) certain hooks in production documentation so that it can link users to the right information at the right time in the installation task flow. Additionally, we have to do design critiques as part of our development process (slide 45 @ http://www.slideshare.net/CatherineRobson/user-experience-bootcamp-for-developers) to spot out the obvious UX mistakes. I'm leaving it open on who does this. But it needs to be done. There is of course a different matter that we're expecting developers to download multiple third-party bits and install them. There's a legal angle to that, but our end users will need a gap experience when coming from docker-machine and other equivalent tools. > > > Thanks for your time in reading this. > > Thanks for the report. > > Regards, > Robert > > > Regards > > Vineet > > [1] > https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/release-notes-and-known-issues/#vagrant_compatibility_matrix > [2] > https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/single/installation-guide/#additional_software_requirements_for_mac_os_x > [3] > https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/single/installation-guide/#installing_virtualization_and_container_development_kit_components > [4] > https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/getting-started-guide/#preparing_host_system_for_using_openshift_from_the_command_line > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmuir at redhat.com Mon Aug 1 11:32:13 2016 From: pmuir at redhat.com (Pete Muir) Date: Mon, 1 Aug 2016 12:32:13 +0100 Subject: [Devtools] Bug in Vagrant 1.8.5 that prevents CDK VM from starting up In-Reply-To: References: Message-ID: Adding in the devtools list - Vineet also reported this bug today :-) We still recommend using Vagrant 1.8.1 AIUI. On 30 July 2016 at 15:21, Stephanos Bacon wrote: > Hi guys, > I am trying to get the helloworld msa thing running on my laptop and ran > into this. Due I guess to my own lack of googling skill it took a while > before I found it... > > https://github.com/mitchellh/vagrant/issues/7610 > > > This would affect anyone using the latest released vagrant at this point > since the fix doesn't appear to have been released yet, but patching the > installation fixes the problem. > > Given that it took me a while to find it I thought we might want to flag > this somewhere so getting going with the CDK is a bit easier. > > -steph From pmuir at redhat.com Mon Aug 1 11:35:20 2016 From: pmuir at redhat.com (Pete Muir) Date: Mon, 1 Aug 2016 12:35:20 +0100 Subject: [Devtools] CDK usage: Your thoughts are needed! In-Reply-To: <6332b615-a44f-4de4-cbaa-5a100c1899ba@redhat.com> References: <6332b615-a44f-4de4-cbaa-5a100c1899ba@redhat.com> Message-ID: On 29 July 2016 at 19:50, Lalatendu Mohanty wrote: > On 07/27/2016 10:06 PM, Rick Wagner wrote: > > Hello DevTools SMEs, > > We are seeing a few more CDK support cases, most seem to indicate curiosity > and tire-kicking. We also have a case with a customer going a step further. > > The customer in question wants to use the CDK to develop on the desktop and > deploy to an Enterprise OpenShift. > > It's my understanding that there are two primary schemes: > > - Push source code (perhaps using a tag like 'prod') to a source repository > accessed by the enterprise OpenShift environment. (Be it QE, Prod, > whatever). > - Push docker images to an external repository accessed by the enterprise > OpenShift. > > > These ideas perfectly makes sense to me. Any organization going through the > DevOps route would need this work flows. > > > There are nuances like use of WebHooks vs. manual pulls, Jenkins doing the > monitoring, etc. > > This seems a really foundational use case for the CDK, so it seems like > something we'd want to document. I've been discussing this with Robert > Kratky but wanted to open the discussion to get more viewpoints (and > especially more users that have experience.) > > > These needs to ironed out , needs testing and then documentation. > > > Of special interest: > > - The customer is indicating a desire for some widget on the CDK-supplied > OpenShift UI so he can 'push' artifacts to the enterprise OpenShift's docker > repository. > > +1 . Developer tool should help move things in to the DevOps workflow. The > pipeline work going on in OpenShift might align here. Need to cross check. I think the CD pipeline (i.e. pushing source) should be our recommended approach here. > > - The customer is asking if Docker version is relevant. (i.e. the CDK's > version of Docker may need to align with the external image repository's > version. True or False?) > > > The only requirement I think is the docker version should support the image > format present in external image repository. I do not think this would be > problem if they stick to OpenShift Enterprise. > > > Please consider, add thoughts to the discussion. > > Thank you, > > Rick > > > _______________________________________________ > 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 bgurung at redhat.com Mon Aug 1 11:37:58 2016 From: bgurung at redhat.com (Budh Gurung) Date: Mon, 1 Aug 2016 17:07:58 +0530 Subject: [Devtools] Installing CDK - some issues noted In-Reply-To: References: <98006475.7ynGCCFTpK@x230> Message-ID: Hi, On Mon, Aug 1, 2016 at 4:28 PM, Vineet Reynolds Pereira wrote: > Thanks Robert, > > I went through the docs again - they are the same ones you reference. So, > my suggestions and feedback will a bit more specific, which is inline. > > > On Mon, Aug 1, 2016 at 2:31 PM, Robert Kratky wrote: > >> On 1.?8.?2016 13:53:36, Vineet Reynolds Pereira wrote: >> >> > Hello list, >> >> Hi Vineet, >> >> >From reading your post, I'm thinking there's some confusion with regard >> to CDK docs. Could you please specify what docs you're referring to? >> >> Official CDK docs are at >> https://access.redhat.com/documentation/en/red-hat-container-development-kit/ >> >> > I tried out CDK 2.1 on a brand new Macbook, to test drive the >> > installation experience. An installation was also attempted on a Linux >> box >> > by someone in my team; he eventually installed CDK on a Debian host >> instead >> > of a RHEL 7 VM on the same host. I'll focus on Mac, since we're looking >> at >> > Windows and Mac users primarily. There are some suggestions to improve >> this >> > experience. >> > >> > * Vagrant version issues (Mac) >> > I started with Vagrant 1.8.5 (the latest), then ran into this bug >> with >> > SSH keys [1] when bringing up the CDK vagrant box. Tried downgrading to >> > 1.8.4, and ran into this one [2] involving installation of local gems >> > supplied by CDK. Ultimately, I downgraded all the way down to 1.8.1, >> > because the CDK version "appeared" to have been tested against it. >> >> Our Release Notes contain a Vagrant compatibility matrix [1] that tells >> users to use 1.8.1 or 1.7.4 on Mac. The Installation Guide contains this >> info in relevant places [2]. >> > > Ok, I think we need to find a better way to present this, and I would > suggest getting in touch the UX team. My onboarding workflow was like this: > > +1 for better way. > * Search for RedHat CDK and land at > http://developers.redhat.com/products/cdk/overview/ > * Get started with the call to action button and land at > http://developers.redhat.com/products/cdk/get-started/ > * Start the installation for Mac as indicated in the tab: > http://developers.redhat.com/products/cdk/get-started/#tab-macLinux > * I expected to see the versions here, since the page already talks about > installing Virtualbox and Vagrant. In fact, it talks about Vagrant 1.7.4 > for RHEL, but nothing about the Mac. This is probably where the troubles > started, and I think a pre-requisite matrix would help here. > * It only later that I land at the pages delivered as part of product > documentation, from the getting started page. > > A specific comment on the Vagrant 1.8.1 pre-requisite noted in the docs - > the version should be emphasized, and that's why I couldn't remember where > I saw it first. It easy to gloss over that entire paragraph, because other > parts of the page are bolded and made to stand out as more relevant. I > think a bullet list of pre-requisites would be better, separated from other > text would help. Someone from UX can help you more by revisiting the > onboarding flow listed above. > > Generally speaking, the entire navigation flow allows for installation to > fail because the important parts like pre-requisite versions are brought > out much later in product docs, or they're not emphasized enough over other > information. My point is not that documentation is bad. Developer > experience is bad. I know, we as a company don't commit the obvious mistake > of not documenting the necessary, but to our end-users the same information > can be hard to find. > > >> >> > * Virtualbox version issues (Mac) >> > Vagrant 1.8.5 supports Virtualbox 5.1.x (latest) [3], but on >> downgrading >> > vagrant to 1.8.1, it proceeds to download Virtualbox 5.0 when bringing >> up >> > the Vagrant box. Vagrant fails to download and install Virtualbox for >> some >> > reason (I didn't bother to debug any more vagrant issues at this point), >> > and went and manually downgraded Virtualbox to 5.0.26. That's three >> > downgrades in one installation session. >> >> I wasn't aware of any VirtualBox-version restrictions. I'll work with QE >> and update the docs with this info. >> > > It's a dependency for Vagrant as as vagrant provider, so sometimes Vagrant > needs to support newer versions of Virtualbox in newer Vagrant releases. It > needs to be addressed in the navigation flow, but yes, this needs > revisiting from QE every release for the test matrix. > If it is really creating issues in up and running CDK then we should document appropriate VirtualBox versions too. > >> > * Documentation for Linux users >> > I'm a bit lost on this area, since there might a product direction >> I'm >> > unaware of. I see that the documentation references Vagrant+VirtualBox >> as >> > something that can be installed on any Linux OS, by talking about deps >> and >> > rpms. But, the rest of the documentation is specific on RHEL 7 Server. I >> > have a few open questions here - >> >> As I said before, I'm not sure what docs you've been following. Our >> Installation Guide instructs users of RHEL to use libvirt/KVM, not >> VirtualBox [3]. >> > > Ok, going by the navigation flow, it looks the the Getting Started page at > http://developers.redhat.com/products/cdk/get-started/#tab-macLinux > needs to have all of this info. It allows Linux users (RHEL is Linux) to > bring VirtualBox and use it, and the docs do not address how to use this > vagrant provider later, instead driving the user to libvirt. I believe this > particular page is not owned by docs, and I'm not faulting anyone for this, > but the overall experience to end users is disjointed. > > > >> >> > ** Why is there focus on RHEL 7 Server, when developers on Linux >> are >> > unlikely to use this for day-to-day development tasks? For someone using >> > Ubuntu or Fedora with Virtualbox, the Linux docs are only partially >> useful, >> > given they address libvirt on RHEL 7. >> >> For CDK 2.1, RHEL was the only supported Linux distro. For previous >> versions, we had instructions for Fedora as well, but they had to be >> removed. I'm hoping that support for Fedora will be reintroduced in CDK 2.2 >> -- and then it'll be documented again. >> > > That would be great to not have that regression in supported OSes. > > But what about other OSes? Are we going to tell developers to install > RHEL/Fedora when their work OS is a different Linux distro, or is this > going to be left to the community(ADB) to address ? > > >> >> > ** Is there any open issue to ensure we address other prominent >> Linux >> > distros? >> > >> > * OSE client (oc executable) >> > The documentation on obtaining the OpenShift client, is present in an >> > RST in CDK.zip, but not in the docs. I think this was discussed >> previously >> > in some other thread, but I thought I'd mention it again incase it >> wasn't. >> >> The Getting Started Guide includes detailed instructions on how to obtain >> the 'oc' (and 'docker') clients [4] for all platforms. >> > > I missed making a suggestion in the original mail. Did we explore about > packaging OpenShift client tools as part of CDK zip distribution itself? > That would be great and I don't see why we shouldn't (licensing concerns et > al). > Plan is to implement CLI approach to install the client binaries for OpenShift client tool(or other services) running inside the CDK through command(Mac/Linux) or hook with Devstudio for Windows. This will be part of upcoming CDK 2.2 release. > >> > Suggestions follow: >> > >> > * Publish the testing matrix prominently on what versions of >> pre-requisites >> > users need to get CDK up and running without issues. If it's already >> > written down somewhere, it needs to be prominent in the installation >> > pre-requisites section of the doc. >> >> See [1]. Also, install. instructions for each supported platform tell >> users exactly which versions to use. For example, for Mac, it's at [2]. >> >> > * Have nightly builds against our OS targets and possibly multiple >> versions >> > of pre-requisites, so we know about issues involving pre-requisites even >> > before our users do. >> >> Nightly builds: >> http://cdk-builds.usersys.redhat.com/builds/nightly/latest-build/ >> >> > * Expand the documentation for Linux users, and bring in clarity on >> > multiple vagrant providers. If we are going to support only libvirt >> usage >> > for Linux users in our docs, we should declare this as a pre-requisite. >> >> I'll be happy to work on improving the docs, but I'm pretty sure you're >> talking about some other docs than the official ones. I'm really keen to >> find out where the problem is, so that we don't have this confusion. >> > > Atleast to me it's now obvious that we need to work with our UX team on > this. developers.redhat.com is where developers are onboarded and driven > to the production docs later. And they're owned and updated by two > different teams. I haven't seen the designed navigation flow in entirety, > but it's obvious that developers.redhat.com expects (or would expect in > the future) certain hooks in production documentation so that it can link > users to the right information at the right time in the installation task > flow. > > Additionally, we have to do design critiques as part of our development > process (slide 45 @ > http://www.slideshare.net/CatherineRobson/user-experience-bootcamp-for-developers) > to spot out the obvious UX mistakes. I'm leaving it open on who does this. > But it needs to be done. > > There is of course a different matter that we're expecting developers to > download multiple third-party bits and install them. There's a legal angle > to that, but our end users will need a gap experience when coming from > docker-machine and other equivalent tools. > > > >> >> > Thanks for your time in reading this. >> >> Thanks for the report. >> >> Regards, >> Robert >> >> > Regards >> > Vineet >> >> [1] >> https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/release-notes-and-known-issues/#vagrant_compatibility_matrix >> [2] >> https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/single/installation-guide/#additional_software_requirements_for_mac_os_x >> [3] >> https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/single/installation-guide/#installing_virtualization_and_container_development_kit_components >> [4] >> https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/getting-started-guide/#preparing_host_system_for_using_openshift_from_the_command_line >> >> > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > Thanks for your valuable suggestions Vineet. Regards, Budh Ram Gurung Software Engineer - Dev Tools -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkratky at redhat.com Mon Aug 1 11:40:05 2016 From: rkratky at redhat.com (Robert Kratky) Date: Mon, 01 Aug 2016 13:40:05 +0200 Subject: [Devtools] Installing CDK - some issues noted In-Reply-To: References: <98006475.7ynGCCFTpK@x230> Message-ID: <2880483.G8OQiFDjT2@x230> On 1.?8.?2016 16:28:18, Vineet Reynolds Pereira wrote: > Thanks Robert, Hi Vineet, > I went through the docs again - they are the same ones you reference. So, > my suggestions and feedback will a bit more specific, which is inline. > > On Mon, Aug 1, 2016 at 2:31 PM, Robert Kratky wrote: > > > On 1.?8.?2016 13:53:36, Vineet Reynolds Pereira wrote: > > > > > Hello list, > > > > Hi Vineet, > > > > From reading your post, I'm thinking there's some confusion with regard to > > CDK docs. Could you please specify what docs you're referring to? > > > > Official CDK docs are at > > https://access.redhat.com/documentation/en/red-hat-container-development-kit/ > > > > > I tried out CDK 2.1 on a brand new Macbook, to test drive the > > > installation experience. An installation was also attempted on a Linux > > box by someone in my team; he eventually installed CDK on a Debian host > > insTead of a RHEL 7 VM on the same host. I'll focus on Mac, since we're > > looking at Windows and Mac users primarily. There are some suggestions to > > improve this experience. > > > > > > * Vagrant version issues (Mac) > > > I started with Vagrant 1.8.5 (the latest), then ran into this bug with > > > SSH keys [1] when bringing up the CDK vagrant box. Tried downgrading to > > > 1.8.4, and ran into this one [2] involving installation of local gems > > > supplied by CDK. Ultimately, I downgraded all the way down to 1.8.1, > > > because the CDK version "appeared" to have been tested against it. > > > > Our Release Notes contain a Vagrant compatibility matrix [1] that tells > > users to use 1.8.1 or 1.7.4 on Mac. The Installation Guide contains this > > info in relevant places [2]. > > Ok, I think we need to find a better way to present this, and I would > suggest getting in touch the UX team. My onboarding workflow was like this: > > * Search for RedHat CDK and land at > http://developers.redhat.com/products/cdk/overview/ > * Get started with the call to action button and land at > http://developers.redhat.com/products/cdk/get-started/ > * Start the installation for Mac as indicated in the tab: > http://developers.redhat.com/products/cdk/get-started/#tab-macLinux > * I expected to see the versions here, since the page already talks about > installing Virtualbox and Vagrant. In fact, it talks about Vagrant 1.7.4 > for RHEL, but nothing about the Mac. This is probably where the troubles > started, and I think a pre-requisite matrix would help here. > * It only later that I land at the pages delivered as part of product > documentation, from the getting started page. I see this as the main problem -- users come to dev.rh.com and follow the instructions they find there. Some of them may not even reach the regular docs that are only linked from there. It doesn't matter how complete are the regular docs when the 'get started' stuff on dev.rh.com is insufficient or inconsistent with other instructions. As you correctly point out below, the docs team doesn't own the content on dev.rh.com, so we're in a difficult position. I'll try to work with Lincoln, the editor of dev.rh.com, to figure out a way to improve this experience. > A specific comment on the Vagrant 1.8.1 pre-requisite noted in the docs - > the version should be emphasized, and that's why I couldn't remember where > I saw it first. It easy to gloss over that entire paragraph, because other > parts of the page are bolded and made to stand out as more relevant. I > think a bullet list of pre-requisites would be better, separated from other > text would help. Someone from UX can help you more by revisiting the > onboarding flow listed above. For my part, I'll make sure to emphasize the version info in the regular Installation Guide. > Generally speaking, the entire navigation flow allows for installation to > fail because the important parts like pre-requisite versions are brought > out much later in product docs, or they're not emphasized enough over other > information. My point is not that documentation is bad. Developer > experience is bad. I know, we as a company don't commit the obvious mistake > of not documenting the necessary, but to our end-users the same information > can be hard to find. > > > > * Virtualbox version issues (Mac) > > > Vagrant 1.8.5 supports Virtualbox 5.1.x (latest) [3], but on downgrading > > > vagrant to 1.8.1, it proceeds to download Virtualbox 5.0 when bringing up > > > the Vagrant box. Vagrant fails to download and install Virtualbox for > > > some reason (I didn't bother to debug any more vagrant issues at this > > > point), and went and manually downgraded Virtualbox to 5.0.26. That's > > > three downgrades in one installation session. > > > > I wasn't aware of any VirtualBox-version restrictions. I'll work with QE > > and update the docs with this info. > > It's a dependency for Vagrant as as vagrant provider, so sometimes Vagrant > needs to support newer versions of Virtualbox in newer Vagrant releases. It > needs to be addressed in the navigation flow, but yes, this needs > revisiting from QE every release for the test matrix. > > > > * Documentation for Linux users > > > I'm a bit lost on this area, since there might a product direction I'm > > > unaware of. I see that the documentation references Vagrant+VirtualBox as > > > something that can be installed on any Linux OS, by talking about deps > > > and rpms. But, the rest of the documentation is specific on RHEL 7 Server. > > > I have a few open questions here - > > > > As I said before, I'm not sure what docs you've been following. Our > > Installation Guide instructs users of RHEL to use libvirt/KVM, not > > VirtualBox [3]. > > Ok, going by the navigation flow, it looks the the Getting Started page at > http://developers.redhat.com/products/cdk/get-started/#tab-macLinux > needs to have all of this info. It allows Linux users (RHEL is Linux) to > bring VirtualBox and use it, and the docs do not address how to use this > vagrant provider later, instead driving the user to libvirt. I believe this > particular page is not owned by docs, and I'm not faulting anyone for this, > but the overall experience to end users is disjointed. > > > > ** Why is there focus on RHEL 7 Server, when developers on Linux are > > > unlikely to use this for day-to-day development tasks? For someone using > > > Ubuntu or Fedora with Virtualbox, the Linux docs are only partially > > > useful, given they address libvirt on RHEL 7. > > > > For CDK 2.1, RHEL was the only supported Linux distro. For previous > > versions, we had instructions for Fedora as well, but they had to be > > removed. I'm hoping that support for Fedora will be reintroduced in CDK 2.2 > > -- and then it'll be documented again. > > That would be great to not have that regression in supported OSes. > > But what about other OSes? Are we going to tell developers to install > RHEL/Fedora when their work OS is a different Linux distro, or is this > going to be left to the community(ADB) to address ? I suppose we can't realistically support 'other' distros, but if it's requested, we can at least document generic instructions for RPM and DEB-based distros (with big warnings that such installation paths are unsupported). > > > ** Is there any open issue to ensure we address other prominent > > > Linux distros? > > > > > > * OSE client (oc executable) > > > The documentation on obtaining the OpenShift client, is present in an > > > RST in CDK.zip, but not in the docs. I think this was discussed > > > previously in some other thread, but I thought I'd mention it again > > > incase it wasn't. > > > > The Getting Started Guide includes detailed instructions on how to obtain > > the 'oc' (and 'docker') clients [4] for all platforms. > > I missed making a suggestion in the original mail. Did we explore about > packaging OpenShift client tools as part of CDK zip distribution itself? > That would be great and I don't see why we shouldn't (licensing concerns et > al). This is being discussed for the next release (not bundling but automating the download). Whatever the preferred solution ends up being, we'll document it. > > > Suggestions follow: > > > > > > * Publish the testing matrix prominently on what versions of > > > pre-requisites users need to get CDK up and running without issues. > > > If it's already written down somewhere, it needs to be prominent in > > > the installation pre-requisites section of the doc. > > > > See [1]. Also, install. instructions for each supported platform tell > > users exactly which versions to use. For example, for Mac, it's at [2]. > > > > > * Have nightly builds against our OS targets and possibly multiple > > > versions of pre-requisites, so we know about issues involving pre- > > > requisites even before our users do. > > > > Nightly builds: > > http://cdk-builds.usersys.redhat.com/builds/nightly/latest-build/ > > > > > * Expand the documentation for Linux users, and bring in clarity on > > > multiple vagrant providers. If we are going to support only libvirt usage > > > for Linux users in our docs, we should declare this as a pre-requisite. > > > > I'll be happy to work on improving the docs, but I'm pretty sure you're > > talking about some other docs than the official ones. I'm really keen to > > find out where the problem is, so that we don't have this confusion. > > Atleast to me it's now obvious that we need to work with our UX team on > this. developers.redhat.com is where developers are onboarded and driven to > the production docs later. And they're owned and updated by two different > teams. I haven't seen the designed navigation flow in entirety, but it's > obvious that developers.redhat.com expects (or would expect in the future) > certain hooks in production documentation so that it can link users to the > right information at the right time in the installation task flow. Agreed. As mentioned above, I'll work with the dev.rh.com people to fix this. Regards, Robert > Additionally, we have to do design critiques as part of our development > process (slide 45 @ > http://www.slideshare.net/CatherineRobson/user-experience-bootcamp-for-developers) > to spot out the obvious UX mistakes. I'm leaving it open on who does this. > But it needs to be done. > > There is of course a different matter that we're expecting developers to > download multiple third-party bits and install them. There's a legal angle > to that, but our end users will need a gap experience when coming from > docker-machine and other equivalent tools. From lmohanty at redhat.com Mon Aug 1 18:10:47 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 1 Aug 2016 23:40:47 +0530 Subject: [Devtools] Installing CDK - some issues noted In-Reply-To: References: Message-ID: <75beb2e9-d567-7582-c2d8-147e28685185@redhat.com> On 08/01/2016 01:53 PM, Vineet Reynolds Pereira wrote: > Hello list, > > I tried out CDK 2.1 on a brand new Macbook, to test drive the > installation experience. An installation was also attempted on a Linux > box by someone in my team; he eventually installed CDK on a Debian > host instead of a RHEL 7 VM on the same host. I'll focus on Mac, since > we're looking at Windows and Mac users primarily. There are some > suggestions to improve this experience. > We have tested CDK on RHEL 7. So if does not work then we need to findout the issues. Can you please request your team member to send the issues. > * Vagrant version issues (Mac) > I started with Vagrant 1.8.5 (the latest), then ran into this bug > with SSH keys [1] when bringing up the CDK vagrant box. Tried > downgrading to 1.8.4, and ran into this one [2] involving installation > of local gems supplied by CDK. Ultimately, I downgraded all the way > down to 1.8.1, because the CDK version "appeared" to have been tested > against it. > > * Virtualbox version issues (Mac) > Vagrant 1.8.5 supports Virtualbox 5.1.x (latest) [3], but on > downgrading vagrant to 1.8.1, it proceeds to download Virtualbox 5.0 > when bringing up the Vagrant box. Vagrant fails to download and > install Virtualbox for some reason (I didn't bother to debug any more > vagrant issues at this point), and went and manually downgraded > Virtualbox to 5.0.26. That's three downgrades in one installation session. > > * Documentation for Linux users > I'm a bit lost on this area, since there might a product direction > I'm unaware of. I see that the documentation references > Vagrant+VirtualBox as something that can be installed on any Linux OS, > by talking about deps and rpms. But, the rest of the documentation is > specific on RHEL 7 Server. I have a few open questions here - > ** Why is there focus on RHEL 7 Server, when developers on Linux > are unlikely to use this for day-to-day development tasks? For someone > using Ubuntu or Fedora with Virtualbox, the Linux docs are only > partially useful, given they address libvirt on RHEL 7. > ** Is there any open issue to ensure we address other prominent > Linux distros? > > * OSE client (oc executable) > The documentation on obtaining the OpenShift client, is present in > an RST in CDK.zip, but not in the docs. I think this was discussed > previously in some other thread, but I thought I'd mention it again > incase it wasn't. > > > Suggestions follow: > > * Publish the testing matrix prominently on what versions of > pre-requisites users need to get CDK up and running without issues. If > it's already written down somewhere, it needs to be prominent in the > installation pre-requisites section of the doc. +1. As we already have the matrix we definitely should improve the visibility. > * Have nightly builds against our OS targets and possibly multiple > versions of pre-requisites, so we know about issues involving > pre-requisites even before our users do. We are aware of these issues with recent Vagrant versions. That's the reason our support matrix does not list them. But as you suggested we need to do a better job of communicating the information. > * Expand the documentation for Linux users, and bring in clarity on > multiple vagrant providers. If we are going to support only libvirt > usage for Linux users in our docs, we should declare this as a > pre-requisite. We need to support both. But +1 for better documentation for this. I think the action item for the team is to go through the documentation and provide suggestion to documentation team. > > Thanks for your time in reading this. > > Regards > Vineet > > > [1]: https://github.com/mitchellh/vagrant/issues/7631 > [2]: https://github.com/mitchellh/vagrant/issues/7493 > [3]: https://github.com/mitchellh/vagrant/issues/7411 > > > _______________________________________________ > 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 Aug 1 22:37:18 2016 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 1 Aug 2016 18:37:18 -0400 Subject: [Devtools] CDK usage: Your thoughts are needed! In-Reply-To: References: <6332b615-a44f-4de4-cbaa-5a100c1899ba@redhat.com> Message-ID: On Mon, Aug 1, 2016 at 7:35 AM, Pete Muir wrote: > On 29 July 2016 at 19:50, Lalatendu Mohanty wrote: > > On 07/27/2016 10:06 PM, Rick Wagner wrote: > > > > Hello DevTools SMEs, > > > > We are seeing a few more CDK support cases, most seem to indicate > curiosity > > and tire-kicking. We also have a case with a customer going a step > further. > > > > The customer in question wants to use the CDK to develop on the desktop > and > > deploy to an Enterprise OpenShift. > > > > It's my understanding that there are two primary schemes: > > > > - Push source code (perhaps using a tag like 'prod') to a source > repository > > accessed by the enterprise OpenShift environment. (Be it QE, Prod, > > whatever). > > - Push docker images to an external repository accessed by the enterprise > > OpenShift. > > > > > > These ideas perfectly makes sense to me. Any organization going through > the > > DevOps route would need this work flows. > > > > > > There are nuances like use of WebHooks vs. manual pulls, Jenkins doing > the > > monitoring, etc. > > > > This seems a really foundational use case for the CDK, so it seems like > > something we'd want to document. I've been discussing this with Robert > > Kratky but wanted to open the discussion to get more viewpoints (and > > especially more users that have experience.) > > > > > > These needs to ironed out , needs testing and then documentation. > > > > > > Of special interest: > > > > - The customer is indicating a desire for some widget on the CDK-supplied > > OpenShift UI so he can 'push' artifacts to the enterprise OpenShift's > docker > > repository. > > > > +1 . Developer tool should help move things in to the DevOps workflow. > The > > pipeline work going on in OpenShift might align here. Need to cross > check. > > I think the CD pipeline (i.e. pushing source) should be our > recommended approach here. > > +1 if the developer loses the source on (local hard drive fail) then there would be no way to recreate the image on another machine. It is super critical that "builds be reproducible" and that means all source artifacts (including Dockerfile and/or Openshift template files) need to be "checked in" to a source repo. And from that source repo a CI job runs to produce the "one true image" that moves to the production/enterprise openshift. Overall, the concept of using the CDK for on-desktop development for a remote OpenShift IS a very normal use case for us to be supporting. > > > > - The customer is asking if Docker version is relevant. (i.e. the CDK's > > version of Docker may need to align with the external image repository's > > version. True or False?) > > > > > > The only requirement I think is the docker version should support the > image > > format present in external image repository. I do not think this would be > > problem if they stick to OpenShift Enterprise. > > > > > > Please consider, add thoughts to the discussion. > > > > Thank you, > > > > Rick > > > > > > _______________________________________________ > > 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 manderse at redhat.com Tue Aug 2 07:51:53 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 02 Aug 2016 09:51:53 +0200 Subject: [Devtools] support for OpenShift Container Platform / Origin in minikube? In-Reply-To: <20160708121714.GD19484@nineveh.lan> References: <34C29FC6-B5F2-439B-95F4-2D42A156E35E@redhat.com> <217D53D0-D256-48E5-8D26-CFD36BF44AC7@redhat.com> <20160706073224.GE96345@nineveh.lan> <9222908504856097678@unknownmsgid> <20160708121714.GD19484@nineveh.lan> Message-ID: Hey Hardy et.al., Did you ever get an answer to those questions ? I have had those thoughts myself and wondered what the answers are. /max > Hi, > >> Not running the Red Hat Docker is a serious problem for OpenShift / >> Kube, simply given the instability and gaps in upstream Docker. >> While >> we're not running production workloads, it's really difficult to >> certify and fix issues. > > Here is a bit I don't understand. We keep saying we should run the Red > Hat Docker > and somehow this seems to imply that you also need the CentOS/RHEL > base image. > > Can one not replace the default Docker binary of any distribution with > the > Red Hat version? Or does the Red Hat version depend on things which > are only > available on RHEL. > > My understanding was that Red Hat even offered a patch for Docker, but > they > are just not willing to accept this. So there should be not extras > required, right? > > --Hardy > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools /max http://about.me/maxandersen From shubham at linux.com Tue Aug 2 10:26:31 2016 From: shubham at linux.com (Shubham Minglani) Date: Tue, 2 Aug 2016 15:56:31 +0530 Subject: [Devtools] Deploy team cabal cancelled for today In-Reply-To: References: Message-ID: Hi, Most of us are either at Flock or in F2F meeting so we have cancelled today's deploy team's cabal today. See you next week. Regards, Shubham -------------- next part -------------- An HTML attachment was scrubbed... URL: From hferents at redhat.com Thu Aug 4 11:26:48 2016 From: hferents at redhat.com (Hardy Ferentschik) Date: Thu, 4 Aug 2016 13:26:48 +0200 Subject: [Devtools] TLD for ADB/CDK Message-ID: <20160804112648.GB20583@nineveh.local> Hi there, work on integrating Landrush per default into ADB/CDK is in full swing [1]. We are closing in on a solution and wanted to ask for some feedback. With Landrush enabled we will be going away from using IPs (eg 10.1.2.2). Instead we will be using a dynamically provided IP. This IP should mostly be transparent to the user. She will instead be using a hostname most of the time. Right now we thinking the name will be [adb|cdk].test. This means access to the console would be via https://cdk.test:8443/console (or if we manage to set it up in time https://console.cdk.test). A login to the console would be of the form: 'oc login cdk.test:8443' Last but not least, routes would be of the form '-smaple-project.cdk.test'. Obviously it is quite nice for a user to just refer to a name instead of having to remember an IP. Also switching to a dynamically assigned IP allows us to unify the Vagrant configuration across the various virtualization frameworks (most notably HyperV). So now to the question. What does everyone think about [cdk|adb].test? We initially used [cdk|adb].dev which I think would be nicer. Unfortunately .dev is probably not a good choice anymore, since we have been seeing DNS servers returning 127.0.53.53 for it. Obviously we can make up our own name here, but be careful that we must be sure that it won't conflict with 1000+ top level domains out there. The benefit of .test is that it is apparently protected by the DNS specification (as is .example .invalid and .localhost). See also [2]. Any suggestions, thoughts? --Hardy [1] https://github.com/projectatomic/adb-atomic-developer-bundle/pull/462 [2] https://iyware.com/dont-use-dev-for-development/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From pmuir at redhat.com Thu Aug 4 12:14:31 2016 From: pmuir at redhat.com (Pete Muir) Date: Thu, 4 Aug 2016 13:14:31 +0100 Subject: [Devtools] TLD for ADB/CDK In-Reply-To: <20160804112648.GB20583@nineveh.local> References: <20160804112648.GB20583@nineveh.local> Message-ID: What about just ".cdk"? On 4 August 2016 at 12:26, Hardy Ferentschik wrote: > Hi there, > > work on integrating Landrush per default into ADB/CDK is in full swing [1]. > We are closing in on a solution and wanted to ask for some feedback. > > With Landrush enabled we will be going away from using IPs (eg 10.1.2.2). > Instead we will be using a dynamically provided IP. This IP should mostly > be transparent to the user. She will instead be using a hostname most of the > time. > > Right now we thinking the name will be [adb|cdk].test. This means > access to the console would be via https://cdk.test:8443/console (or > if we manage to set it up in time https://console.cdk.test). > > A login to the console would be of the form: 'oc login cdk.test:8443' > > Last but not least, routes would be of the form '-smaple-project.cdk.test'. > > Obviously it is quite nice for a user to just refer to a name instead > of having to remember an IP. Also switching to a dynamically assigned IP allows us > to unify the Vagrant configuration across the various virtualization frameworks > (most notably HyperV). > > So now to the question. What does everyone think about [cdk|adb].test? We initially > used [cdk|adb].dev which I think would be nicer. Unfortunately .dev is probably not > a good choice anymore, since we have been seeing DNS servers returning 127.0.53.53 > for it. Obviously we can make up our own name here, but be careful that we must be > sure that it won't conflict with 1000+ top level domains out there. > The benefit of .test is that it is apparently protected by the DNS specification > (as is .example .invalid and .localhost). See also [2]. > > Any suggestions, thoughts? > > --Hardy > > [1] https://github.com/projectatomic/adb-atomic-developer-bundle/pull/462 > [2] https://iyware.com/dont-use-dev-for-development/ > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > From manderse at redhat.com Thu Aug 4 13:00:25 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Thu, 04 Aug 2016 15:00:25 +0200 Subject: [Devtools] TLD for ADB/CDK In-Reply-To: <20160804112648.GB20583@nineveh.local> References: <20160804112648.GB20583@nineveh.local> Message-ID: <12175DD8-1747-46F7-894A-86106FE16C07@redhat.com> side question - will it be possibly to flip a flag and enable xip.io in case one is having problem or would prefer without landrush ? Just curious. /max > Hi there, > > work on integrating Landrush per default into ADB/CDK is in full swing > [1]. > We are closing in on a solution and wanted to ask for some feedback. > > With Landrush enabled we will be going away from using IPs (eg > 10.1.2.2). > Instead we will be using a dynamically provided IP. This IP should > mostly > be transparent to the user. She will instead be using a hostname most > of the > time. > > Right now we thinking the name will be [adb|cdk].test. This means > access to the console would be via https://cdk.test:8443/console (or > if we manage to set it up in time https://console.cdk.test). > > A login to the console would be of the form: 'oc login cdk.test:8443' > > Last but not least, routes would be of the form > '-smaple-project.cdk.test'. > > Obviously it is quite nice for a user to just refer to a name instead > of having to remember an IP. Also switching to a dynamically assigned > IP allows us > to unify the Vagrant configuration across the various virtualization > frameworks > (most notably HyperV). > > So now to the question. What does everyone think about [cdk|adb].test? > We initially > used [cdk|adb].dev which I think would be nicer. Unfortunately .dev is > probably not > a good choice anymore, since we have been seeing DNS servers returning > 127.0.53.53 > for it. Obviously we can make up our own name here, but be careful > that we must be > sure that it won't conflict with 1000+ top level domains out there. > The benefit of .test is that it is apparently protected by the DNS > specification > (as is .example .invalid and .localhost). See also [2]. > > Any suggestions, thoughts? > > --Hardy > > [1] > https://github.com/projectatomic/adb-atomic-developer-bundle/pull/462 > [2] https://iyware.com/dont-use-dev-for-development/ > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools /max http://about.me/maxandersen From hferents at redhat.com Fri Aug 5 10:57:44 2016 From: hferents at redhat.com (Hardy Ferentschik) Date: Fri, 5 Aug 2016 12:57:44 +0200 Subject: [Devtools] TLD for ADB/CDK In-Reply-To: <12175DD8-1747-46F7-894A-86106FE16C07@redhat.com> References: <20160804112648.GB20583@nineveh.local> <12175DD8-1747-46F7-894A-86106FE16C07@redhat.com> Message-ID: <20160805105744.GA47702@nineveh.local> Hi, On Thu, 04-Aug-2016 15:00, Max Rydahl Andersen wrote: > side question - will it be possibly to flip a flag and enable xip.io in case > one is having problem or would prefer without landrush ? It need for sure to be documented on how to switch back to [xip|nip].io. We can also keep the required changes in the Vagrantfile and switch based on an environment variable. Something like https://github.com/redhat-developer-tooling/openshift-vagrant/blob/master/cdk-v2/Vagrantfile#L104 where Landrush gets enabled if a flag is set. In this case it would be the opposite. It just comes with a more verbose Vagrant config, but it might be well worth 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 hferents at redhat.com Fri Aug 5 11:01:26 2016 From: hferents at redhat.com (Hardy Ferentschik) Date: Fri, 5 Aug 2016 13:01:26 +0200 Subject: [Devtools] TLD for ADB/CDK In-Reply-To: References: <20160804112648.GB20583@nineveh.local> Message-ID: <20160805110126.GB47702@nineveh.local> Hi, On Thu, 04-Aug-2016 13:14, Pete Muir wrote: > What about just ".cdk"? We discussed this as well. It is an option. It does not seem to be a valid public TLD atm. However, this might change. The benefit of the other options I gave was, that they are protected by the DNS spec. Obviously, .cdk/.adb makes nicer URLs. I am fine with giving it a go. --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 Fri Aug 5 11:06:41 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 5 Aug 2016 16:36:41 +0530 Subject: [Devtools] TLD for ADB/CDK In-Reply-To: <20160805105744.GA47702@nineveh.local> References: <20160804112648.GB20583@nineveh.local> <12175DD8-1747-46F7-894A-86106FE16C07@redhat.com> <20160805105744.GA47702@nineveh.local> Message-ID: On 08/05/2016 04:27 PM, Hardy Ferentschik wrote: > Hi, > > On Thu, 04-Aug-2016 15:00, Max Rydahl Andersen wrote: >> side question - will it be possibly to flip a flag and enable xip.io in case >> one is having problem or would prefer without landrush ? > It need for sure to be documented on how to switch back to [xip|nip].io. > We can also keep the required changes in the Vagrantfile and switch based > on an environment variable. Something like https://github.com/redhat-developer-tooling/openshift-vagrant/blob/master/cdk-v2/Vagrantfile#L104 > where Landrush gets enabled if a flag is set. In this case it would > be the opposite. It just comes with a more verbose Vagrant config, but it > might be well worth it. +1 , we should document this. -Lala From manderse at redhat.com Fri Aug 5 11:20:54 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Fri, 05 Aug 2016 13:20:54 +0200 Subject: [Devtools] TLD for ADB/CDK In-Reply-To: <20160805110126.GB47702@nineveh.local> References: <20160804112648.GB20583@nineveh.local> <20160805110126.GB47702@nineveh.local> Message-ID: On 5 Aug 2016, at 13:01, Hardy Ferentschik wrote: > Hi, > > On Thu, 04-Aug-2016 13:14, Pete Muir wrote: >> What about just ".cdk"? > > We discussed this as well. It is an option. It does not seem to be > a valid public TLD atm. However, this might change. The benefit of the > other options I gave was, that they are protected by the DNS spec. > > Obviously, .cdk/.adb makes nicer URLs. I am fine with giving it a go. Isn't there some caveat of some browsers/OS's not behaving nice with such ? I just remember when I made up my own short names in localhost and local dns servers I ran into problems and thus started using .local. /max http://about.me/maxandersen From dusty at dustymabe.com Fri Aug 5 12:17:43 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Fri, 5 Aug 2016 08:17:43 -0400 Subject: [Devtools] vagrant-sshfs pre-release testing - round 2 Message-ID: Here is a new version to test. Please test it out as much as possible: vagrant plugin uninstall vagrant-sshfs wget https://dustymabe.fedorapeople.org/gem/vagrant-sshfs-1.1.0.e617981.gem vagrant plugin install ./vagrant-sshfs-1.1.0.e617981.gem Thanks Dusty From dusty at dustymabe.com Fri Aug 5 12:21:04 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Fri, 5 Aug 2016 08:21:04 -0400 Subject: [Devtools] Future Focus of Tools Deploy Team: Ansible Container & Kompose Message-ID: Hey Everyone, Last week the Devtools Deploy team had a meeting to discuss our goals around Ansible and Atomic App, based on the requirements coming from our PM and engineering teams. We are concerned that we have too many tools in this space - in particular we think that we end up spending a lot of time explaining the differences between these tools, rather than working on solving real use cases. We think that Ansible itself has an interesting end-to-end story for people looking to deploy applications, and we think that working with Ansible, and in particular the ansible-container project could solve a number of the use cases we want to look at. As one of our first goals we want to bring some of the deployment support we have in Atomic App to ansible container - we intend to make PRs based on our experience. We are hoping to become tightly integrated with their team and share the same roadmap when it comes to that tool. We also want to get more involved in existing upstream communities that are centered around Kubernetes/OpenShift. We have already started to get involved with the Kompose project [1] and we want to evaluate Helm [2] packaging and how it relates to Kompose and see where the good things about Nulecule can be brought to the table there. As a result of focusing on Ansible and Kompose/Helm for the next 6 months, it does mean we will slow down our work on Atomic App. One thing we do want to do is merge the Nulecule and Atomic App repositories so that it is less confusing to approach that project. We'll be merging the Nulecule repository into the Atomic App repository and Nulecule will become an implementation detail for Atomic App. After the merge we'll let it rest for a while and re-evaluate it in some time. Questions/Concerns? Dusty [1] - https://github.com/skippbox/kompose [2] - https://github.com/kubernetes/helm From rkratky at redhat.com Fri Aug 5 12:39:16 2016 From: rkratky at redhat.com (Robert Kratky) Date: Fri, 05 Aug 2016 14:39:16 +0200 Subject: [Devtools] TLD for ADB/CDK In-Reply-To: References: <20160804112648.GB20583@nineveh.local> <20160805105744.GA47702@nineveh.local> Message-ID: <4110709.RZKK9uPaV9@t460s> On Friday, 5 August 2016 16:36:41 CEST, Lalatendu Mohanty wrote: > On 08/05/2016 04:27 PM, Hardy Ferentschik wrote: > > Hi, > > > > On Thu, 04-Aug-2016 15:00, Max Rydahl Andersen wrote: > >> side question - will it be possibly to flip a flag and enable xip.io in case > >> one is having problem or would prefer without landrush ? > > It need for sure to be documented on how to switch back to [xip|nip].io. > > We can also keep the required changes in the Vagrantfile and switch based > > on an environment variable. Something like https://github.com/redhat-developer-tooling/openshift-vagrant/blob/master/cdk-v2/Vagrantfile#L104 > > where Landrush gets enabled if a flag is set. In this case it would > > be the opposite. It just comes with a more verbose Vagrant config, but it > > might be well worth it. > > +1 , we should document this. The docs team has a JIRA issue open [1] for this. Any input appreciated. Robert [1] https://issues.jboss.org/browse/RHDEVDOCS-138 From dusty at dustymabe.com Mon Aug 8 11:37:54 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Mon, 8 Aug 2016 07:37:54 -0400 Subject: [Devtools] vagrant-sshfs pre-release testing - round 2 In-Reply-To: References: Message-ID: <4253fa18-e7f2-1dca-152f-a9554b2c8c8e@dustymabe.com> Please take a chance to test this today and give feedback. I'll be making a release today unless I get negative feedback from anyone. Dusty On 08/05/2016 08:17 AM, Dusty Mabe wrote: > Here is a new version to test. Please test it out as much as possible: > > > vagrant plugin uninstall vagrant-sshfs > wget https://dustymabe.fedorapeople.org/gem/vagrant-sshfs-1.1.0.e617981.gem > vagrant plugin install ./vagrant-sshfs-1.1.0.e617981.gem > > Thanks > Dusty > From bex at pobox.com Mon Aug 8 12:30:55 2016 From: bex at pobox.com (Brian Exelbierd) Date: Mon, 08 Aug 2016 14:30:55 +0200 Subject: [Devtools] Rename ADB to Project Atomic Developer Bundle (PADB) see issue #495 Message-ID: <1470659455.1996955.689077321.14DCB664@webmail.messagingengine.com> https://github.com/projectatomic/adb-atomic-developer-bundle/issues/495 This proposal is the result of four talks and lots of hallway conversations that I have had about the ADB. Many audience members seem to "short circuit" because the name is already in use by the Android Debug Bridge and the Asian Development Bank[0]. This short-circuit prevents meaningful conversations and instead turns deep rabbit holes about names being hard. I was discussing this with @veillard and he suggested we just tack on a 'P' to the front for "Project Atomic." We riffed on this a bit and seemed to like it. The formal proposal is to rename this sub-project to "Project Atomic Developer Bundle" to be pronounced as two words, "pad bee" (pad-b). This change seems minimally invasive and would allow us to move conversations past the existing name colliding projects. regards, bex [0] In full disclosure, no one, other than google.com, has suggested the bank. Please continue the conversation in this issue: https://github.com/projectatomic/adb-atomic-developer-bundle/issues/495 From lmohanty at redhat.com Mon Aug 8 12:54:40 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 8 Aug 2016 18:24:40 +0530 Subject: [Devtools] ADB release postponed to this week Message-ID: Hi, Atomic Developer Bundle (ADB) was not released last week as there were few pending PRs and the process got delayed because of day long meetings we were attending. We will be releasing ADB this week. Thanks, Lala From mharpur at redhat.com Mon Aug 8 13:54:40 2016 From: mharpur at redhat.com (Mitchell Harpur) Date: Mon, 8 Aug 2016 09:54:40 -0400 (EDT) Subject: [Devtools] Future Focus of Tools Deploy Team: Ansible Container & Kompose In-Reply-To: References: Message-ID: <407628865.4666313.1470664480473.JavaMail.zimbra@redhat.com> +1 for Ansible. Its my opinion that it should be the tool to use accross the board. Imaging we could just use ansible and VM's where neccesary (win + mac) to simplify our provisioning development,deployment,promotion experience (remove the need for vagrant) Mitch ----- Original Message ----- From: "Dusty Mabe" To: container-tools at redhat.com, devtools at redhat.com Sent: Friday, August 5, 2016 8:21:04 AM Subject: [Devtools] Future Focus of Tools Deploy Team: Ansible Container & Kompose Hey Everyone, Last week the Devtools Deploy team had a meeting to discuss our goals around Ansible and Atomic App, based on the requirements coming from our PM and engineering teams. We are concerned that we have too many tools in this space - in particular we think that we end up spending a lot of time explaining the differences between these tools, rather than working on solving real use cases. We think that Ansible itself has an interesting end-to-end story for people looking to deploy applications, and we think that working with Ansible, and in particular the ansible-container project could solve a number of the use cases we want to look at. As one of our first goals we want to bring some of the deployment support we have in Atomic App to ansible container - we intend to make PRs based on our experience. We are hoping to become tightly integrated with their team and share the same roadmap when it comes to that tool. We also want to get more involved in existing upstream communities that are centered around Kubernetes/OpenShift. We have already started to get involved with the Kompose project [1] and we want to evaluate Helm [2] packaging and how it relates to Kompose and see where the good things about Nulecule can be brought to the table there. As a result of focusing on Ansible and Kompose/Helm for the next 6 months, it does mean we will slow down our work on Atomic App. One thing we do want to do is merge the Nulecule and Atomic App repositories so that it is less confusing to approach that project. We'll be merging the Nulecule repository into the Atomic App repository and Nulecule will become an implementation detail for Atomic App. After the merge we'll let it rest for a while and re-evaluate it in some time. Questions/Concerns? Dusty [1] - https://github.com/skippbox/kompose [2] - https://github.com/kubernetes/helm _______________________________________________ Devtools mailing list Devtools at redhat.com https://www.redhat.com/mailman/listinfo/devtools From kbsingh at redhat.com Mon Aug 8 14:08:58 2016 From: kbsingh at redhat.com (Karanbir Singh) Date: Mon, 8 Aug 2016 15:08:58 +0100 Subject: [Devtools] Future Focus of Tools Deploy Team: Ansible Container & Kompose In-Reply-To: <407628865.4666313.1470664480473.JavaMail.zimbra@redhat.com> References: <407628865.4666313.1470664480473.JavaMail.zimbra@redhat.com> Message-ID: <878ae376-20ef-245d-ef02-57374d58414c@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Top Posting to stay with the flow... I am largely +1 on the plan as well, however ansible-container itself is very immature at this point and we should do a bit of due diligence around the space to quantify challenges and how they map to the user stories side of things. A huge +1 to aligning with their roadmaps and ensuring that we get upstream + downstream buy in for the feature space we are going to work on from the devtools side. regards, On 08/08/16 14:54, Mitchell Harpur wrote: > +1 for Ansible. Its my opinion that it should be the tool to use > accross the board. > > Imaging we could just use ansible and VM's where neccesary (win + > mac) to simplify our provisioning development,deployment,promotion > experience (remove the need for vagrant) > > Mitch > > > ----- Original Message ----- From: "Dusty Mabe" > To: container-tools at redhat.com, > devtools at redhat.com Sent: Friday, August 5, 2016 8:21:04 AM > Subject: [Devtools] Future Focus of Tools Deploy Team: Ansible > Container & Kompose > > > Hey Everyone, > > Last week the Devtools Deploy team had a meeting to discuss our > goals around Ansible and Atomic App, based on the requirements > coming from our PM and engineering teams. We are concerned that we > have too many tools in this space - in particular we think that we > end up spending a lot of time explaining the differences between > these tools, rather than working on solving real use cases. > > We think that Ansible itself has an interesting end-to-end story > for people looking to deploy applications, and we think that > working with Ansible, and in particular the ansible-container > project could solve a number of the use cases we want to look at. > As one of our first goals we want to bring some of the deployment > support we have in Atomic App to ansible container - we intend to > make PRs based on our experience. We are hoping to become tightly > integrated with their team and share the same roadmap when it comes > to that tool. > > We also want to get more involved in existing upstream communities > that are centered around Kubernetes/OpenShift. We have already > started to get involved with the Kompose project [1] and we want to > evaluate Helm [2] packaging and how it relates to Kompose and see > where the good things about Nulecule can be brought to the table > there. > > As a result of focusing on Ansible and Kompose/Helm for the next 6 > months, it does mean we will slow down our work on Atomic App. One > thing we do want to do is merge the Nulecule and Atomic App > repositories so that it is less confusing to approach that project. > We'll be merging the Nulecule repository into the Atomic App > repository and Nulecule will become an implementation detail for > Atomic App. After the merge we'll let it rest for a while and > re-evaluate it in some time. > > Questions/Concerns? > > Dusty > > [1] - https://github.com/skippbox/kompose [2] - > https://github.com/kubernetes/helm > > _______________________________________________ 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 > - -- Karanbir Singh, Project Lead, The CentOS Project, London, UK Red Hat Ext. 8274455 | DID: 0044 207 009 4455 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXqJJ6AAoJEI3Oi2Mx7xbteMoH/2emVmpBympdly7nuQLAJ8w4 aWC8SLS1OJl6yNB3l4eoHQNKEb22vHkuCUBW6LTdHPmv70JpzYm3ZwilYJ78mNc8 ZTWN3PHT/+d7CDOajpv5kh9aSFLukm2KVXTk4+3Ck8xBRIZGvK33bSXHSO41c9SK n4OouRabdP1t+phf9z46R5O32x1nhdrDS6G2xZnicGZZ3oSwVWplf/vYUMmT1QXY pcOHL3haN0AJsOJaqqFtKIKtvGS4QgxU+W29fLe3Et9g9alWqup4v6Jwwv8BSnE+ qZYicPOd+mv2kEbDlRJVW+gy6cO6hMzSMVvozBqL8Ks6Q5z/MuYc9LebaI6WJt8= =LROd -----END PGP SIGNATURE----- From rwagner at redhat.com Mon Aug 8 16:15:29 2016 From: rwagner at redhat.com (Rick Wagner) Date: Mon, 8 Aug 2016 11:15:29 -0500 Subject: [Devtools] CDK as shared development platform -- viable use case? Message-ID: Hello DevTools CDK SMEs, We have a customer support case [1] where the user wishes to install the CDK and then make it available for team development purposes. They'd like to allow developers on different machines to connect to the OpenShift instance using their office VLan's address of 192.168.x.x instead of the default 10.1.x.x. So, a few questions: - Considering the active Xip.io thread in SE-JBoss, should we consider this a core use-case? (With accompanying documentation?) - Is this a recommended use? It seems the CDK is more of a 'personal' development environment than a 'team' development environment. Should this use be discouraged? - Do we have any specific words of advice for this user? Thanks in advance for all thoughts offered. As usual, CEE will dutifully KCS the tips provided. Rick [1] https://access.redhat.com/support/cases/01674763 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmancini at redhat.com Mon Aug 8 16:27:03 2016 From: tmancini at redhat.com (Todd Mancini) Date: Mon, 8 Aug 2016 12:27:03 -0400 Subject: [Devtools] CDK as shared development platform -- viable use case? In-Reply-To: References: Message-ID: This sounds like it's smacking into the use case for OpenShift Lab, so we really should coordinate with the OpenShift team to make sure this is going down a path they want. We can take offline with them. On Mon, Aug 8, 2016 at 12:15 PM, Rick Wagner wrote: > Hello DevTools CDK SMEs, > > We have a customer support case [1] where the user wishes to install the > CDK and then make it available for team development purposes. > > They'd like to allow developers on different machines to connect to the > OpenShift instance using their office VLan's address of 192.168.x.x instead > of the default 10.1.x.x. > > So, a few questions: > > - Considering the active Xip.io thread in SE-JBoss, should we consider > this a core use-case? (With accompanying documentation?) > > - Is this a recommended use? It seems the CDK is more of a 'personal' > development environment than a 'team' development environment. Should this > use be discouraged? > > - Do we have any specific words of advice for this user? > > Thanks in advance for all thoughts offered. As usual, CEE will dutifully > KCS the tips provided. > > Rick > > [1] https://access.redhat.com/support/cases/01674763 > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwagner at redhat.com Mon Aug 8 17:51:24 2016 From: rwagner at redhat.com (Rick Wagner) Date: Mon, 8 Aug 2016 12:51:24 -0500 Subject: [Devtools] CDK as shared development platform -- viable use case? In-Reply-To: References: Message-ID: Thanks for that, Todd. I'll put together a note to an OpenShift Lab stakeholder, I'll copy you on it. Rick On Mon, Aug 8, 2016 at 11:27 AM, Todd Mancini wrote: > This sounds like it's smacking into the use case for OpenShift Lab, so we > really should coordinate with the OpenShift team to make sure this is going > down a path they want. We can take offline with them. > > On Mon, Aug 8, 2016 at 12:15 PM, Rick Wagner wrote: > >> Hello DevTools CDK SMEs, >> >> We have a customer support case [1] where the user wishes to install the >> CDK and then make it available for team development purposes. >> >> They'd like to allow developers on different machines to connect to the >> OpenShift instance using their office VLan's address of 192.168.x.x instead >> of the default 10.1.x.x. >> >> So, a few questions: >> >> - Considering the active Xip.io thread in SE-JBoss, should we consider >> this a core use-case? (With accompanying documentation?) >> >> - Is this a recommended use? It seems the CDK is more of a 'personal' >> development environment than a 'team' development environment. Should this >> use be discouraged? >> >> - Do we have any specific words of advice for this user? >> >> Thanks in advance for all thoughts offered. As usual, CEE will dutifully >> KCS the tips provided. >> >> Rick >> >> [1] https://access.redhat.com/support/cases/01674763 >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alkazako at redhat.com Mon Aug 8 20:53:45 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Mon, 8 Aug 2016 13:53:45 -0700 Subject: [Devtools] vagrant-sshfs pre-release testing - round 2 In-Reply-To: <4253fa18-e7f2-1dca-152f-a9554b2c8c8e@dustymabe.com> References: <4253fa18-e7f2-1dca-152f-a9554b2c8c8e@dustymabe.com> Message-ID: <87490dce-0eb0-d660-bf01-19a6a6950285@redhat.com> Thanks Dusty. Martin and Rob have been testing it. Guys, please let us know if there is something wrong with it. On 08/08/2016 04:37 AM, Dusty Mabe wrote: > Please take a chance to test this today and give feedback. I'll be > making a release today unless I get negative feedback from anyone. > > Dusty > > > On 08/05/2016 08:17 AM, Dusty Mabe wrote: >> Here is a new version to test. Please test it out as much as possible: >> >> >> vagrant plugin uninstall vagrant-sshfs >> wget https://dustymabe.fedorapeople.org/gem/vagrant-sshfs-1.1.0.e617981.gem >> vagrant plugin install ./vagrant-sshfs-1.1.0.e617981.gem >> >> Thanks >> Dusty >> > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools On 08/08/2016 04:37 AM, Dusty Mabe wrote: > Please take a chance to test this today and give feedback. I'll be > making a release today unless I get negative feedback from anyone. > > Dusty > > > On 08/05/2016 08:17 AM, Dusty Mabe wrote: >> Here is a new version to test. Please test it out as much as possible: >> >> >> vagrant plugin uninstall vagrant-sshfs >> wget https://dustymabe.fedorapeople.org/gem/vagrant-sshfs-1.1.0.e617981.gem >> vagrant plugin install ./vagrant-sshfs-1.1.0.e617981.gem >> >> Thanks >> Dusty >> > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From dusty at dustymabe.com Mon Aug 8 21:08:06 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Mon, 8 Aug 2016 17:08:06 -0400 Subject: [Devtools] vagrant-sshfs v1.2.0 release Message-ID: There is a new release of vagrant-sshfs (1.2.0). Announcement here [1]. You can either do vagrant plugin install vagrant-sshfs or you can install via copr [2]: sudo dnf copr enable dustymabe/vagrant-sshfs && sudo dnf install vagrant-sshfs Thanks, Dusty [1] https://github.com/dustymabe/vagrant-sshfs/releases/tag/v1.2.0 [2] https://copr.fedorainfracloud.org/coprs/dustymabe/vagrant-sshfs/ From dusty at dustymabe.com Mon Aug 8 21:09:06 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Mon, 8 Aug 2016 17:09:06 -0400 Subject: [Devtools] vagrant-sshfs pre-release testing - round 2 In-Reply-To: <87490dce-0eb0-d660-bf01-19a6a6950285@redhat.com> References: <4253fa18-e7f2-1dca-152f-a9554b2c8c8e@dustymabe.com> <87490dce-0eb0-d660-bf01-19a6a6950285@redhat.com> Message-ID: On 08/08/2016 04:53 PM, Alexey Kazakov wrote: > Thanks Dusty. > Martin and Rob have been testing it. > Guys, please let us know if there is something wrong with it. I worked with them today and all looks good so far. I just cut the new release. Dusty From ccoleman at redhat.com Tue Aug 9 01:58:34 2016 From: ccoleman at redhat.com (Clayton Coleman) Date: Mon, 8 Aug 2016 21:58:34 -0400 Subject: [Devtools] support for OpenShift Container Platform / Origin in minikube? In-Reply-To: <20160708121714.GD19484@nineveh.lan> References: <34C29FC6-B5F2-439B-95F4-2D42A156E35E@redhat.com> <217D53D0-D256-48E5-8D26-CFD36BF44AC7@redhat.com> <20160706073224.GE96345@nineveh.lan> <9222908504856097678@unknownmsgid> <20160708121714.GD19484@nineveh.lan> Message-ID: On Fri, Jul 8, 2016 at 8:17 AM, Hardy Ferentschik wrote: > Hi, > > > Not running the Red Hat Docker is a serious problem for OpenShift / > > Kube, simply given the instability and gaps in upstream Docker. While > > we're not running production workloads, it's really difficult to > > certify and fix issues. > > Here is a bit I don't understand. We keep saying we should run the Red Hat > Docker > and somehow this seems to imply that you also need the CentOS/RHEL base > image. > > Can one not replace the default Docker binary of any distribution with the > Red Hat version? Or does the Red Hat version depend on things which are > only > available on RHEL. > The Red Hat version does not truly depend on RHEL, but there are a fair number of things between device mapper and docker to get exactly right, so it's not just Docker but also libdevmapper and a bunch of other things to be aligned. > > My understanding was that Red Hat even offered a patch for Docker, but they > are just not willing to accept this. So there should be not extras > required, right? > There are two classes of things in the Red Hat version of Docker: 1. Backports from newer Docker versions - Docker does *not* patch older versions, so you can't get fix A without upgrading to Docker next version without also getting bug B. In practice we were finding that it was impossible to stabilize a cluster with Docker without back porting fixes. Along with that comes specific security and other fixes that are critical to having a long term production version of docker. 2. Specific fixes that Docker refuses to carry - things like allowing registries to be reparented, or the ability to disable Docker schema2 push to registries (allowing Docker to continue to push in a way that preserves pull-by-digest for older Docker versions). The former is critical. The latter is just very useful. > > --Hardy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Tue Aug 9 12:23:21 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 9 Aug 2016 17:53:21 +0530 Subject: [Devtools] Using proxy server with ADB/CDK Message-ID: <5ec22ba4-f4e7-3922-7bd4-3df7227d09a2@redhat.com> Hi, We are trying to understand the user experience around using a proxy server with ADB/CDK. Here are the choices we have. 1. Export all proxy variables i.e. proxy server, proxy user/password to environment and then the subsequent "vagrant up" will pick the information and does the required configuration. 2. Add some proxy information in the Vagrantfile. Whenever user wants to ad the proxy information, he has to edit the Vagrantfile. IMO #1 looks fine to me. But not sure about it. Let us know what you think. Thanks, Lala From lmohanty at redhat.com Tue Aug 9 13:05:06 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 9 Aug 2016 18:35:06 +0530 Subject: [Devtools] Using proxy server with ADB/CDK In-Reply-To: <5ec22ba4-f4e7-3922-7bd4-3df7227d09a2@redhat.com> References: <5ec22ba4-f4e7-3922-7bd4-3df7227d09a2@redhat.com> Message-ID: + container-tools On 08/09/2016 05:53 PM, Lalatendu Mohanty wrote: > Hi, > > We are trying to understand the user experience around using a proxy > server with ADB/CDK. Here are the choices we have. > > 1. Export all proxy variables i.e. proxy server, proxy user/password > to environment and then the subsequent "vagrant up" will pick the > information and does the required configuration. > > 2. Add some proxy information in the Vagrantfile. Whenever user wants > to ad the proxy information, he has to edit the Vagrantfile. > > IMO #1 looks fine to me. But not sure about it. > > Let us know what you think. > > Thanks, > > Lala From tmancini at redhat.com Tue Aug 9 13:11:29 2016 From: tmancini at redhat.com (Todd Mancini) Date: Tue, 9 Aug 2016 09:11:29 -0400 Subject: [Devtools] Using proxy server with ADB/CDK In-Reply-To: References: <5ec22ba4-f4e7-3922-7bd4-3df7227d09a2@redhat.com> Message-ID: It appears to me that the consistent answer is to have (1) environment variables which are (2) consumed in the Vagrantfile and passed via configuration parameters to vagrant (or a relevant plugin). e.g. if ENV.has_key?('SUB_USERNAME') && ENV.has_key?('SUB_PASSWORD') config.registration.username = ENV['SUB_USERNAME'] config.registration.password = ENV['SUB_PASSWORD'] end So my vote is that we continue to same pattern. On Tue, Aug 9, 2016 at 9:05 AM, Lalatendu Mohanty wrote: > + container-tools > > > On 08/09/2016 05:53 PM, Lalatendu Mohanty wrote: > >> Hi, >> >> We are trying to understand the user experience around using a proxy >> server with ADB/CDK. Here are the choices we have. >> >> 1. Export all proxy variables i.e. proxy server, proxy user/password to >> environment and then the subsequent "vagrant up" will pick the information >> and does the required configuration. >> >> 2. Add some proxy information in the Vagrantfile. Whenever user wants to >> ad the proxy information, he has to edit the Vagrantfile. >> >> IMO #1 looks fine to me. But not sure about it. >> >> Let us know what you think. >> >> 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 degolovi at redhat.com Wed Aug 10 05:41:50 2016 From: degolovi at redhat.com (Denis Golovin) Date: Tue, 9 Aug 2016 22:41:50 -0700 Subject: [Devtools] Development Suite installation question - C/O SME with knowledge of installer edits In-Reply-To: <1960516785.6522026.1469002102802.JavaMail.zimbra@redhat.com> References: <1829398.oJedtQYAuc@x230> <1597469.slTCQpW6SA@x230> <6413734.nWTzG8j3RH@x230> <1960516785.6522026.1469002102802.JavaMail.zimbra@redhat.com> Message-ID: I've updated description for this https://issues.jboss.org/browse/RHDENG-579 with better workaround. The idea is to login and download CDK itself from developers.redhat.com. This will trigger, if required, additional information request which in my case included one T&C to sign. Finishing the form fixed T&C's problem in installer. Denis On 7/20/2016 1:08 AM, Denis Golovin wrote: > FYI: JIRA created to track this problem: > ORG-3470 DevSuite T&C's signing status check doesn't work for users created before May 18th > > Denis > > ----- Original Message ----- >> From: "Pete Muir" >> To: "Rick Wagner" >> Cc: devtools at redhat.com, "Mark Newton" >> Sent: Thursday, July 7, 2016 11:34:47 AM >> Subject: Re: [Devtools] Development Suite installation question - C/O SME with knowledge of installer edits >> >> On 7 July 2016 at 19:08, Rick Wagner wrote: >>> Hello All, >>> >>> Additional information, this from (no SalesForce acct required) the support >>> case at [1]. >>> >>> The customer is telling us the 'use a new account' workaround was >>> successful >>> with a Windows 10 machine. A second attempt on a Win 7 machine fails. >>> >>> The failed effort: >>> - Is using the userid 'ryanbuckett' >>> - Previously failed effort (the original account) was 'SumaGeethakumari'. >>> >>> The customer is asking if the downloaded exectuable must be used on the >>> machine it was downloaded to? (If the username specified for download and >>> installation are the same, is it relevant where the artifact was downloaded >>> to?) >> No, the link is usernames. You must use the username you downloaded >> with when you run the installer. >> >> David/Mark, can you check these user accounts - have they signed the >> RHEL Developer Suite T&C? >> >>> Thanks, >>> >>> Rick >>> >>> [1] https://access.redhat.com/support/cases/01662411 >>> >>> On Thu, Jul 7, 2016 at 11:40 AM, Pete Muir wrote: >>>> Very helpful Robert, as it helps us identify that there is a problem >>>> on the server side around older accounts that somehow aren't being >>>> properly upgraded. >>>> >>>> Mark/David, can you treat this as an urgent issue to look in to, as >>>> it's getting reported by customers. >>>> >>>> Rick Wagner is getting more info from customers, but Robert seems to >>>> have identified at least one failing path. >>>> >>>> On 7 July 2016 at 17:29, Robert Kratky wrote: >>>>> Follow up: brand new account worked for this user. So: >>>>> >>>>> - user didn't use social accounts to log in >>>>> - orig. account created on dev.rh.com on May 18: doesn't work >>>>> - new account created on July 7: works >>>>> >>>>> Hope this helps a bit. >>>>> >>>>> Regards, >>>>> Robert >>>>> >>>>> >>>>> On 7.?7.?2016 17:33:32, Robert Kratky wrote: >>>>> >>>>>> Based on a new user comment [1], the "don't use social accounts" >>>>>> workaround doesn't seem to work. It might be related to the fact that >>>>>> he >>>>>> created his RH account on May 18 (i.e. it's not fresh). >>>>>> >>>>>> I asked the user to try a completely new account, but some less drastic >>>>>> solution would be better. >>>>>> >>>>>> Robert >>>>>> >>>>>> [1] https://access.redhat.com/articles/2255391#comment-1069221 >>>>>> >>>>>> >>>>>> On 7.?7.?2016 15:58:06, Robert Kratky wrote: >>>>>> >>>>>>> I updated the text to emphasize that social accounts are not to be >>>>>>> used. It now says, basically: >>>>>>> >>>>>>> 1) log in using RH credentials >>>>>>> 2) do not use social accounts >>>>>>> 3) if you can't (i.e. you have no RH account), create a new one >>>>>>> >>>>>>> Robert >>>>>>> >>>>>>> >>>>>>> On 7.?7.?2016 14:42:15, Pete Muir wrote: >>>>>>> >>>>>>>> Robert, as discussed on the call, you might want to recommend a >>>>>>>> "radical" workaround, of just creating a new account entirely, >>>>>>>> without >>>>>>>> using social media at all. >>>>>>>> >>>>>>>> On 7 July 2016 at 14:38, Robert Kratky wrote: >>>>>>>>> I updated the trouleshooting section in [1] based on the >>>>>>>>> discussion during today's program call. Please, have a look and >>>>>>>>> let me know >>>>>>>>> if what I wrote is accurate -- I cannot test at this moment. >>>>>>>>> >>>>>>>>> This is what it says now: >>>>>>>>> >>>>>>>>> ............. >>>>>>>>> Terms and Conditions Error >>>>>>>>> >>>>>>>>> Error: ?Terms and Conditions for CDK have not been signed? >>>>>>>>> This error appears on the Log In page when starting the >>>>>>>>> Installer. To work around the problem, log in to the Developer >>>>>>>>> Portal using >>>>>>>>> your Red Hat credentials -- the credentials that you created >>>>>>>>> either on >>>>>>>>> redhat.com or developers.redhat.com. Do not use your social >>>>>>>>> accounts to log >>>>>>>>> in. Then start downloading the Installer from Red Hat Development >>>>>>>>> Suite >>>>>>>>> download page. >>>>>>>>> >>>>>>>>> If you do not have a Red Hat account, create one at >>>>>>>>> developers.redhat.com. >>>>>>>>> ............. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> Robert >>>>>>>>> >>>>>>>>> [1] https://access.redhat.com/articles/2360571#troubleshooting >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7.?7.?2016 10:32:06, Misha Husnain Ali wrote: >>>>>>>>> >>>>>>>>>> I remember this issue. Is there any way we can identify the >>>>>>>>>> paths leading >>>>>>>>>> up to this problem and comprehensively test them to provide >>>>>>>>>> clear aid to >>>>>>>>>> users who may encounter this issue? I'm happy to volunteer to >>>>>>>>>> test some of >>>>>>>>>> them if we can identify the various paths users may take. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Misha Husnain Ali >>>>>>>>>> Technical Writer 2, CCS Brisbane >>>>>>>>>> >>>>>>>>>> On Thu, Jul 7, 2016 at 5:38 AM, Denis Golovin >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> T&C's signing workflow is not user friendly ATM. >>>>>>>>>>> >>>>>>>>>>> Workaround mentioned in >>>>>>>>>>> https://access.redhat.com/articles/2360571 worked >>>>>>>>>>> before for >>>>>>>>>>> many dev's who was testing installer. I am going to do check >>>>>>>>>>> full T&C's >>>>>>>>>>> signing again today >>>>>>>>>>> and send update ASAP. >>>>>>>>>>> >>>>>>>>>>> This problem should be affecting only customers who didn't get >>>>>>>>>>> installer >>>>>>>>>>> directly from develper.redhat.com >>>>>>>>>>> download. >>>>>>>>>>> >>>>>>>>>>> Denis >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> From: "Robert Kratky" >>>>>>>>>>>> To: devtools at redhat.com >>>>>>>>>>>> Cc: "Rick Wagner" >>>>>>>>>>>> Sent: Wednesday, July 6, 2016 8:51:03 AM >>>>>>>>>>>> Subject: Re: [Devtools] Development Suite installation >>>>>>>>>>>> question - C/O >>>>>>>>>>> SME with knowledge of installer edits >>>>>>>>>>>> On 6.?7.?2016 10:08:09, Rick Wagner wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello DevTools, >>>>>>>>>>>>> >>>>>>>>>>>>> We have a customer case that deals with the error message >>>>>>>>>>>>> "Terms and >>>>>>>>>>>>> Conditions for the CDK have not been signed". (Actually, >>>>>>>>>>>>> this is the >>>>>>>>>>>>> second case in 2 days for this problem.) >>>>>>>>>>>>> >>>>>>>>>>>>> The customer has tried the suggested workaround, without >>>>>>>>>>>>> satisfactory >>>>>>>>>>>>> results. ("This error appears on the *Log In* page when >>>>>>>>>>>>> starting the >>>>>>>>>>>>> Installer. To fix the problem, start downloading the >>>>>>>>>>>>> Installer to >>>>>>>>>>> ensure >>>>>>>>>>>>> the *Terms and Conditions* are viewed and accepted and >>>>>>>>>>>>> then cancel the >>>>>>>>>>>>> binary download." We offer this suggestion in the >>>>>>>>>>>>> knowledge article at >>>>>>>>>>>>> [1].) >>>>>>>>>>>>> >>>>>>>>>>>>> Can a knowledgeable SME please offer ideas about >>>>>>>>>>>>> alternative courses of >>>>>>>>>>>>> action? >>>>>>>>>>>> Hi Rick, >>>>>>>>>>>> >>>>>>>>>>>> The problem happens quite often, apparently. I asked about >>>>>>>>>>>> this last >>>>>>>>>>> Friday >>>>>>>>>>>> in devtools-program [a] -- on behalf of a user who reported >>>>>>>>>>>> the problem >>>>>>>>>>> in a >>>>>>>>>>>> comment under the old version of the Kbase article [b]. >>>>>>>>>>>> >>>>>>>>>>>> Any workaround would be appreciated. >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> [a] >>>>>>>>>>>> >>>>>>>>>>> http://post-office.corp.redhat.com/archives/devtools-program/2016-July/msg00001.html >>>>>>>>>>>> [b] >>>>>>>>>>>> https://access.redhat.com/articles/2255391#comment-1066361 >>>>>>>>>>>> >>>>>>>>>>>>> Extra credit: Can you please point me to the source code >>>>>>>>>>>>> that produces >>>>>>>>>>>>> this edit error? A little spelunking by the Support team >>>>>>>>>>>>> sometimes >>>>>>>>>>> helps >>>>>>>>>>>>> with related issues. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>> Rick >>>>>>>>>>>>> >>>>>>>>>>>>> [1] https://access.redhat.com/articles/2360571 >>>>> >>>>> _______________________________________________ >>>>> 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 From pmuir at redhat.com Wed Aug 10 10:49:16 2016 From: pmuir at redhat.com (Pete Muir) Date: Wed, 10 Aug 2016 06:49:16 -0400 Subject: [Devtools] Development Suite installation question - C/O SME with knowledge of installer edits In-Reply-To: References: <1829398.oJedtQYAuc@x230> <1597469.slTCQpW6SA@x230> <6413734.nWTzG8j3RH@x230> <1960516785.6522026.1469002102802.JavaMail.zimbra@redhat.com> Message-ID: Also note that the devsuite had the wrong subscription type attached in the download manager. I have updated to be the RHEL Developer Suite sub, which should make the documented workaround work. Denis/Rick, could you please test the documented "if it doesn't work, try downloading devsuite again using the same account"? Thanks On 10 August 2016 at 01:41, Denis Golovin wrote: > I've updated description for this https://issues.jboss.org/browse/RHDENG-579 > with better workaround. The idea is to login and download CDK itself from > developers.redhat.com. This will trigger, if required, additional > information request which in my case included one T&C to sign. Finishing the > form fixed T&C's problem in installer. > > Denis > > > On 7/20/2016 1:08 AM, Denis Golovin wrote: >> >> FYI: JIRA created to track this problem: >> ORG-3470 DevSuite T&C's signing status check doesn't work for users >> created before May 18th >> >> Denis >> >> ----- Original Message ----- >>> >>> From: "Pete Muir" >>> To: "Rick Wagner" >>> Cc: devtools at redhat.com, "Mark Newton" >>> Sent: Thursday, July 7, 2016 11:34:47 AM >>> Subject: Re: [Devtools] Development Suite installation question - C/O SME >>> with knowledge of installer edits >>> >>> On 7 July 2016 at 19:08, Rick Wagner wrote: >>>> >>>> Hello All, >>>> >>>> Additional information, this from (no SalesForce acct required) the >>>> support >>>> case at [1]. >>>> >>>> The customer is telling us the 'use a new account' workaround was >>>> successful >>>> with a Windows 10 machine. A second attempt on a Win 7 machine fails. >>>> >>>> The failed effort: >>>> - Is using the userid 'ryanbuckett' >>>> - Previously failed effort (the original account) was >>>> 'SumaGeethakumari'. >>>> >>>> The customer is asking if the downloaded exectuable must be used on the >>>> machine it was downloaded to? (If the username specified for download >>>> and >>>> installation are the same, is it relevant where the artifact was >>>> downloaded >>>> to?) >>> >>> No, the link is usernames. You must use the username you downloaded >>> with when you run the installer. >>> >>> David/Mark, can you check these user accounts - have they signed the >>> RHEL Developer Suite T&C? >>> >>>> Thanks, >>>> >>>> Rick >>>> >>>> [1] https://access.redhat.com/support/cases/01662411 >>>> >>>> On Thu, Jul 7, 2016 at 11:40 AM, Pete Muir wrote: >>>>> >>>>> Very helpful Robert, as it helps us identify that there is a problem >>>>> on the server side around older accounts that somehow aren't being >>>>> properly upgraded. >>>>> >>>>> Mark/David, can you treat this as an urgent issue to look in to, as >>>>> it's getting reported by customers. >>>>> >>>>> Rick Wagner is getting more info from customers, but Robert seems to >>>>> have identified at least one failing path. >>>>> >>>>> On 7 July 2016 at 17:29, Robert Kratky wrote: >>>>>> >>>>>> Follow up: brand new account worked for this user. So: >>>>>> >>>>>> - user didn't use social accounts to log in >>>>>> - orig. account created on dev.rh.com on May 18: doesn't work >>>>>> - new account created on July 7: works >>>>>> >>>>>> Hope this helps a bit. >>>>>> >>>>>> Regards, >>>>>> Robert >>>>>> >>>>>> >>>>>> On 7.?7.?2016 17:33:32, Robert Kratky wrote: >>>>>> >>>>>>> Based on a new user comment [1], the "don't use social accounts" >>>>>>> workaround doesn't seem to work. It might be related to the fact that >>>>>>> he >>>>>>> created his RH account on May 18 (i.e. it's not fresh). >>>>>>> >>>>>>> I asked the user to try a completely new account, but some less >>>>>>> drastic >>>>>>> solution would be better. >>>>>>> >>>>>>> Robert >>>>>>> >>>>>>> [1] https://access.redhat.com/articles/2255391#comment-1069221 >>>>>>> >>>>>>> >>>>>>> On 7.?7.?2016 15:58:06, Robert Kratky wrote: >>>>>>> >>>>>>>> I updated the text to emphasize that social accounts are not to be >>>>>>>> used. It now says, basically: >>>>>>>> >>>>>>>> 1) log in using RH credentials >>>>>>>> 2) do not use social accounts >>>>>>>> 3) if you can't (i.e. you have no RH account), create a new one >>>>>>>> >>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>>>> On 7.?7.?2016 14:42:15, Pete Muir wrote: >>>>>>>> >>>>>>>>> Robert, as discussed on the call, you might want to recommend a >>>>>>>>> "radical" workaround, of just creating a new account entirely, >>>>>>>>> without >>>>>>>>> using social media at all. >>>>>>>>> >>>>>>>>> On 7 July 2016 at 14:38, Robert Kratky wrote: >>>>>>>>>> >>>>>>>>>> I updated the trouleshooting section in [1] based on the >>>>>>>>>> discussion during today's program call. Please, have a look and >>>>>>>>>> let me know >>>>>>>>>> if what I wrote is accurate -- I cannot test at this moment. >>>>>>>>>> >>>>>>>>>> This is what it says now: >>>>>>>>>> >>>>>>>>>> ............. >>>>>>>>>> Terms and Conditions Error >>>>>>>>>> >>>>>>>>>> Error: ?Terms and Conditions for CDK have not been signed? >>>>>>>>>> This error appears on the Log In page when starting the >>>>>>>>>> Installer. To work around the problem, log in to the Developer >>>>>>>>>> Portal using >>>>>>>>>> your Red Hat credentials -- the credentials that you created >>>>>>>>>> either on >>>>>>>>>> redhat.com or developers.redhat.com. Do not use your social >>>>>>>>>> accounts to log >>>>>>>>>> in. Then start downloading the Installer from Red Hat Development >>>>>>>>>> Suite >>>>>>>>>> download page. >>>>>>>>>> >>>>>>>>>> If you do not have a Red Hat account, create one at >>>>>>>>>> developers.redhat.com. >>>>>>>>>> ............. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> Robert >>>>>>>>>> >>>>>>>>>> [1] https://access.redhat.com/articles/2360571#troubleshooting >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7.?7.?2016 10:32:06, Misha Husnain Ali wrote: >>>>>>>>>> >>>>>>>>>>> I remember this issue. Is there any way we can identify the >>>>>>>>>>> paths leading >>>>>>>>>>> up to this problem and comprehensively test them to provide >>>>>>>>>>> clear aid to >>>>>>>>>>> users who may encounter this issue? I'm happy to volunteer to >>>>>>>>>>> test some of >>>>>>>>>>> them if we can identify the various paths users may take. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Misha Husnain Ali >>>>>>>>>>> Technical Writer 2, CCS Brisbane >>>>>>>>>>> >>>>>>>>>>> On Thu, Jul 7, 2016 at 5:38 AM, Denis Golovin >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> T&C's signing workflow is not user friendly ATM. >>>>>>>>>>>> >>>>>>>>>>>> Workaround mentioned in >>>>>>>>>>>> https://access.redhat.com/articles/2360571 worked >>>>>>>>>>>> before for >>>>>>>>>>>> many dev's who was testing installer. I am going to do check >>>>>>>>>>>> full T&C's >>>>>>>>>>>> signing again today >>>>>>>>>>>> and send update ASAP. >>>>>>>>>>>> >>>>>>>>>>>> This problem should be affecting only customers who didn't get >>>>>>>>>>>> installer >>>>>>>>>>>> directly from develper.redhat.com >>>>>>>>>>>> download. >>>>>>>>>>>> >>>>>>>>>>>> Denis >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> >>>>>>>>>>>>> From: "Robert Kratky" >>>>>>>>>>>>> To: devtools at redhat.com >>>>>>>>>>>>> Cc: "Rick Wagner" >>>>>>>>>>>>> Sent: Wednesday, July 6, 2016 8:51:03 AM >>>>>>>>>>>>> Subject: Re: [Devtools] Development Suite installation >>>>>>>>>>>>> question - C/O >>>>>>>>>>>> >>>>>>>>>>>> SME with knowledge of installer edits >>>>>>>>>>>>> >>>>>>>>>>>>> On 6.?7.?2016 10:08:09, Rick Wagner wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hello DevTools, >>>>>>>>>>>>>> >>>>>>>>>>>>>> We have a customer case that deals with the error message >>>>>>>>>>>>>> "Terms and >>>>>>>>>>>>>> Conditions for the CDK have not been signed". (Actually, >>>>>>>>>>>>>> this is the >>>>>>>>>>>>>> second case in 2 days for this problem.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> The customer has tried the suggested workaround, without >>>>>>>>>>>>>> satisfactory >>>>>>>>>>>>>> results. ("This error appears on the *Log In* page when >>>>>>>>>>>>>> starting the >>>>>>>>>>>>>> Installer. To fix the problem, start downloading the >>>>>>>>>>>>>> Installer to >>>>>>>>>>>> >>>>>>>>>>>> ensure >>>>>>>>>>>>>> >>>>>>>>>>>>>> the *Terms and Conditions* are viewed and accepted and >>>>>>>>>>>>>> then cancel the >>>>>>>>>>>>>> binary download." We offer this suggestion in the >>>>>>>>>>>>>> knowledge article at >>>>>>>>>>>>>> [1].) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can a knowledgeable SME please offer ideas about >>>>>>>>>>>>>> alternative courses of >>>>>>>>>>>>>> action? >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Rick, >>>>>>>>>>>>> >>>>>>>>>>>>> The problem happens quite often, apparently. I asked about >>>>>>>>>>>>> this last >>>>>>>>>>>> >>>>>>>>>>>> Friday >>>>>>>>>>>>> >>>>>>>>>>>>> in devtools-program [a] -- on behalf of a user who reported >>>>>>>>>>>>> the problem >>>>>>>>>>>> >>>>>>>>>>>> in a >>>>>>>>>>>>> >>>>>>>>>>>>> comment under the old version of the Kbase article [b]. >>>>>>>>>>>>> >>>>>>>>>>>>> Any workaround would be appreciated. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> Robert >>>>>>>>>>>>> >>>>>>>>>>>>> [a] >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://post-office.corp.redhat.com/archives/devtools-program/2016-July/msg00001.html >>>>>>>>>>>>> >>>>>>>>>>>>> [b] >>>>>>>>>>>>> https://access.redhat.com/articles/2255391#comment-1066361 >>>>>>>>>>>>> >>>>>>>>>>>>>> Extra credit: Can you please point me to the source code >>>>>>>>>>>>>> that produces >>>>>>>>>>>>>> this edit error? A little spelunking by the Support team >>>>>>>>>>>>>> sometimes >>>>>>>>>>>> >>>>>>>>>>>> helps >>>>>>>>>>>>>> >>>>>>>>>>>>>> with related issues. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Rick >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] https://access.redhat.com/articles/2360571 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > > From rwagner at redhat.com Wed Aug 10 16:46:40 2016 From: rwagner at redhat.com (Rick Wagner) Date: Wed, 10 Aug 2016 11:46:40 -0500 Subject: [Devtools] Development Suite installation question - C/O SME with knowledge of installer edits In-Reply-To: References: <1829398.oJedtQYAuc@x230> <1597469.slTCQpW6SA@x230> <6413734.nWTzG8j3RH@x230> <1960516785.6522026.1469002102802.JavaMail.zimbra@redhat.com> Message-ID: Hi Pete and All, I tried to validate the workaround, but wasn't able to replicate the problem on my desktop. If we don't find an internal user that can validate, we'll make a note when the next customer case arises. Thanks, Rick On Wed, Aug 10, 2016 at 5:49 AM, Pete Muir wrote: > Also note that the devsuite had the wrong subscription type attached > in the download manager. I have updated to be the RHEL Developer Suite > sub, which should make the documented workaround work. Denis/Rick, > could you please test the documented "if it doesn't work, try > downloading devsuite again using the same account"? > > Thanks > > On 10 August 2016 at 01:41, Denis Golovin wrote: > > I've updated description for this https://issues.jboss.org/ > browse/RHDENG-579 > > with better workaround. The idea is to login and download CDK itself from > > developers.redhat.com. This will trigger, if required, additional > > information request which in my case included one T&C to sign. Finishing > the > > form fixed T&C's problem in installer. > > > > Denis > > > > > > On 7/20/2016 1:08 AM, Denis Golovin wrote: > >> > >> FYI: JIRA created to track this problem: > >> ORG-3470 DevSuite T&C's signing status check doesn't work for users > >> created before May 18th > >> > >> Denis > >> > >> ----- Original Message ----- > >>> > >>> From: "Pete Muir" > >>> To: "Rick Wagner" > >>> Cc: devtools at redhat.com, "Mark Newton" > >>> Sent: Thursday, July 7, 2016 11:34:47 AM > >>> Subject: Re: [Devtools] Development Suite installation question - C/O > SME > >>> with knowledge of installer edits > >>> > >>> On 7 July 2016 at 19:08, Rick Wagner wrote: > >>>> > >>>> Hello All, > >>>> > >>>> Additional information, this from (no SalesForce acct required) the > >>>> support > >>>> case at [1]. > >>>> > >>>> The customer is telling us the 'use a new account' workaround was > >>>> successful > >>>> with a Windows 10 machine. A second attempt on a Win 7 machine fails. > >>>> > >>>> The failed effort: > >>>> - Is using the userid 'ryanbuckett' > >>>> - Previously failed effort (the original account) was > >>>> 'SumaGeethakumari'. > >>>> > >>>> The customer is asking if the downloaded exectuable must be used on > the > >>>> machine it was downloaded to? (If the username specified for download > >>>> and > >>>> installation are the same, is it relevant where the artifact was > >>>> downloaded > >>>> to?) > >>> > >>> No, the link is usernames. You must use the username you downloaded > >>> with when you run the installer. > >>> > >>> David/Mark, can you check these user accounts - have they signed the > >>> RHEL Developer Suite T&C? > >>> > >>>> Thanks, > >>>> > >>>> Rick > >>>> > >>>> [1] https://access.redhat.com/support/cases/01662411 > >>>> > >>>> On Thu, Jul 7, 2016 at 11:40 AM, Pete Muir wrote: > >>>>> > >>>>> Very helpful Robert, as it helps us identify that there is a problem > >>>>> on the server side around older accounts that somehow aren't being > >>>>> properly upgraded. > >>>>> > >>>>> Mark/David, can you treat this as an urgent issue to look in to, as > >>>>> it's getting reported by customers. > >>>>> > >>>>> Rick Wagner is getting more info from customers, but Robert seems to > >>>>> have identified at least one failing path. > >>>>> > >>>>> On 7 July 2016 at 17:29, Robert Kratky wrote: > >>>>>> > >>>>>> Follow up: brand new account worked for this user. So: > >>>>>> > >>>>>> - user didn't use social accounts to log in > >>>>>> - orig. account created on dev.rh.com on May 18: doesn't work > >>>>>> - new account created on July 7: works > >>>>>> > >>>>>> Hope this helps a bit. > >>>>>> > >>>>>> Regards, > >>>>>> Robert > >>>>>> > >>>>>> > >>>>>> On 7.?7.?2016 17:33:32, Robert Kratky wrote: > >>>>>> > >>>>>>> Based on a new user comment [1], the "don't use social accounts" > >>>>>>> workaround doesn't seem to work. It might be related to the fact > that > >>>>>>> he > >>>>>>> created his RH account on May 18 (i.e. it's not fresh). > >>>>>>> > >>>>>>> I asked the user to try a completely new account, but some less > >>>>>>> drastic > >>>>>>> solution would be better. > >>>>>>> > >>>>>>> Robert > >>>>>>> > >>>>>>> [1] https://access.redhat.com/articles/2255391#comment-1069221 > >>>>>>> > >>>>>>> > >>>>>>> On 7.?7.?2016 15:58:06, Robert Kratky wrote: > >>>>>>> > >>>>>>>> I updated the text to emphasize that social accounts are not to be > >>>>>>>> used. It now says, basically: > >>>>>>>> > >>>>>>>> 1) log in using RH credentials > >>>>>>>> 2) do not use social accounts > >>>>>>>> 3) if you can't (i.e. you have no RH account), create a new one > >>>>>>>> > >>>>>>>> Robert > >>>>>>>> > >>>>>>>> > >>>>>>>> On 7.?7.?2016 14:42:15, Pete Muir wrote: > >>>>>>>> > >>>>>>>>> Robert, as discussed on the call, you might want to recommend a > >>>>>>>>> "radical" workaround, of just creating a new account entirely, > >>>>>>>>> without > >>>>>>>>> using social media at all. > >>>>>>>>> > >>>>>>>>> On 7 July 2016 at 14:38, Robert Kratky > wrote: > >>>>>>>>>> > >>>>>>>>>> I updated the trouleshooting section in [1] based on the > >>>>>>>>>> discussion during today's program call. Please, have a look and > >>>>>>>>>> let me know > >>>>>>>>>> if what I wrote is accurate -- I cannot test at this moment. > >>>>>>>>>> > >>>>>>>>>> This is what it says now: > >>>>>>>>>> > >>>>>>>>>> ............. > >>>>>>>>>> Terms and Conditions Error > >>>>>>>>>> > >>>>>>>>>> Error: ?Terms and Conditions for CDK have not been signed? > >>>>>>>>>> This error appears on the Log In page when starting the > >>>>>>>>>> Installer. To work around the problem, log in to the Developer > >>>>>>>>>> Portal using > >>>>>>>>>> your Red Hat credentials -- the credentials that you created > >>>>>>>>>> either on > >>>>>>>>>> redhat.com or developers.redhat.com. Do not use your social > >>>>>>>>>> accounts to log > >>>>>>>>>> in. Then start downloading the Installer from Red Hat > Development > >>>>>>>>>> Suite > >>>>>>>>>> download page. > >>>>>>>>>> > >>>>>>>>>> If you do not have a Red Hat account, create one at > >>>>>>>>>> developers.redhat.com. > >>>>>>>>>> ............. > >>>>>>>>>> > >>>>>>>>>> Thanks. > >>>>>>>>>> Robert > >>>>>>>>>> > >>>>>>>>>> [1] https://access.redhat.com/articles/2360571#troubleshooting > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 7.?7.?2016 10:32:06, Misha Husnain Ali wrote: > >>>>>>>>>> > >>>>>>>>>>> I remember this issue. Is there any way we can identify the > >>>>>>>>>>> paths leading > >>>>>>>>>>> up to this problem and comprehensively test them to provide > >>>>>>>>>>> clear aid to > >>>>>>>>>>> users who may encounter this issue? I'm happy to volunteer to > >>>>>>>>>>> test some of > >>>>>>>>>>> them if we can identify the various paths users may take. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> Misha Husnain Ali > >>>>>>>>>>> Technical Writer 2, CCS Brisbane > >>>>>>>>>>> > >>>>>>>>>>> On Thu, Jul 7, 2016 at 5:38 AM, Denis Golovin > >>>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> T&C's signing workflow is not user friendly ATM. > >>>>>>>>>>>> > >>>>>>>>>>>> Workaround mentioned in > >>>>>>>>>>>> https://access.redhat.com/articles/2360571 worked > >>>>>>>>>>>> before for > >>>>>>>>>>>> many dev's who was testing installer. I am going to do check > >>>>>>>>>>>> full T&C's > >>>>>>>>>>>> signing again today > >>>>>>>>>>>> and send update ASAP. > >>>>>>>>>>>> > >>>>>>>>>>>> This problem should be affecting only customers who didn't get > >>>>>>>>>>>> installer > >>>>>>>>>>>> directly from develper.redhat.com > >>>>>>>>>>>> download. > >>>>>>>>>>>> > >>>>>>>>>>>> Denis > >>>>>>>>>>>> > >>>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>>>> > >>>>>>>>>>>>> From: "Robert Kratky" > >>>>>>>>>>>>> To: devtools at redhat.com > >>>>>>>>>>>>> Cc: "Rick Wagner" > >>>>>>>>>>>>> Sent: Wednesday, July 6, 2016 8:51:03 AM > >>>>>>>>>>>>> Subject: Re: [Devtools] Development Suite installation > >>>>>>>>>>>>> question - C/O > >>>>>>>>>>>> > >>>>>>>>>>>> SME with knowledge of installer edits > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 6.?7.?2016 10:08:09, Rick Wagner wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hello DevTools, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> We have a customer case that deals with the error message > >>>>>>>>>>>>>> "Terms and > >>>>>>>>>>>>>> Conditions for the CDK have not been signed". (Actually, > >>>>>>>>>>>>>> this is the > >>>>>>>>>>>>>> second case in 2 days for this problem.) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The customer has tried the suggested workaround, without > >>>>>>>>>>>>>> satisfactory > >>>>>>>>>>>>>> results. ("This error appears on the *Log In* page when > >>>>>>>>>>>>>> starting the > >>>>>>>>>>>>>> Installer. To fix the problem, start downloading the > >>>>>>>>>>>>>> Installer to > >>>>>>>>>>>> > >>>>>>>>>>>> ensure > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> the *Terms and Conditions* are viewed and accepted and > >>>>>>>>>>>>>> then cancel the > >>>>>>>>>>>>>> binary download." We offer this suggestion in the > >>>>>>>>>>>>>> knowledge article at > >>>>>>>>>>>>>> [1].) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Can a knowledgeable SME please offer ideas about > >>>>>>>>>>>>>> alternative courses of > >>>>>>>>>>>>>> action? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi Rick, > >>>>>>>>>>>>> > >>>>>>>>>>>>> The problem happens quite often, apparently. I asked about > >>>>>>>>>>>>> this last > >>>>>>>>>>>> > >>>>>>>>>>>> Friday > >>>>>>>>>>>>> > >>>>>>>>>>>>> in devtools-program [a] -- on behalf of a user who reported > >>>>>>>>>>>>> the problem > >>>>>>>>>>>> > >>>>>>>>>>>> in a > >>>>>>>>>>>>> > >>>>>>>>>>>>> comment under the old version of the Kbase article [b]. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Any workaround would be appreciated. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Robert > >>>>>>>>>>>>> > >>>>>>>>>>>>> [a] > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> http://post-office.corp.redhat.com/archives/devtools- > program/2016-July/msg00001.html > >>>>>>>>>>>>> > >>>>>>>>>>>>> [b] > >>>>>>>>>>>>> https://access.redhat.com/articles/2255391#comment-1066361 > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Extra credit: Can you please point me to the source code > >>>>>>>>>>>>>> that produces > >>>>>>>>>>>>>> this edit error? A little spelunking by the Support team > >>>>>>>>>>>>>> sometimes > >>>>>>>>>>>> > >>>>>>>>>>>> helps > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> with related issues. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks! > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Rick > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> [1] https://access.redhat.com/articles/2360571 > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 degolovi at redhat.com Wed Aug 10 19:53:45 2016 From: degolovi at redhat.com (Denis Golovin) Date: Wed, 10 Aug 2016 12:53:45 -0700 Subject: [Devtools] Development Suite installation question - C/O SME with knowledge of installer edits In-Reply-To: References: <1829398.oJedtQYAuc@x230> <1597469.slTCQpW6SA@x230> <6413734.nWTzG8j3RH@x230> <1960516785.6522026.1469002102802.JavaMail.zimbra@redhat.com> Message-ID: Pete, I am out of logins with T&C's problems, that nivologd was the last one. I hope Rick will be able to verify when one more similar case reported by customer. Is there a way to reset signed T&C's for nivolog at gmail.com or create new one so I can verify? Thanks, Denis On 8/10/2016 3:49 AM, Pete Muir wrote: > Also note that the devsuite had the wrong subscription type attached > in the download manager. I have updated to be the RHEL Developer Suite > sub, which should make the documented workaround work. Denis/Rick, > could you please test the documented "if it doesn't work, try > downloading devsuite again using the same account"? > > Thanks > > On 10 August 2016 at 01:41, Denis Golovin wrote: >> I've updated description for this https://issues.jboss.org/browse/RHDENG-579 >> with better workaround. The idea is to login and download CDK itself from >> developers.redhat.com. This will trigger, if required, additional >> information request which in my case included one T&C to sign. Finishing the >> form fixed T&C's problem in installer. >> >> Denis >> >> >> On 7/20/2016 1:08 AM, Denis Golovin wrote: >>> FYI: JIRA created to track this problem: >>> ORG-3470 DevSuite T&C's signing status check doesn't work for users >>> created before May 18th >>> >>> Denis >>> >>> ----- Original Message ----- >>>> From: "Pete Muir" >>>> To: "Rick Wagner" >>>> Cc: devtools at redhat.com, "Mark Newton" >>>> Sent: Thursday, July 7, 2016 11:34:47 AM >>>> Subject: Re: [Devtools] Development Suite installation question - C/O SME >>>> with knowledge of installer edits >>>> >>>> On 7 July 2016 at 19:08, Rick Wagner wrote: >>>>> Hello All, >>>>> >>>>> Additional information, this from (no SalesForce acct required) the >>>>> support >>>>> case at [1]. >>>>> >>>>> The customer is telling us the 'use a new account' workaround was >>>>> successful >>>>> with a Windows 10 machine. A second attempt on a Win 7 machine fails. >>>>> >>>>> The failed effort: >>>>> - Is using the userid 'ryanbuckett' >>>>> - Previously failed effort (the original account) was >>>>> 'SumaGeethakumari'. >>>>> >>>>> The customer is asking if the downloaded exectuable must be used on the >>>>> machine it was downloaded to? (If the username specified for download >>>>> and >>>>> installation are the same, is it relevant where the artifact was >>>>> downloaded >>>>> to?) >>>> No, the link is usernames. You must use the username you downloaded >>>> with when you run the installer. >>>> >>>> David/Mark, can you check these user accounts - have they signed the >>>> RHEL Developer Suite T&C? >>>> >>>>> Thanks, >>>>> >>>>> Rick >>>>> >>>>> [1] https://access.redhat.com/support/cases/01662411 >>>>> >>>>> On Thu, Jul 7, 2016 at 11:40 AM, Pete Muir wrote: >>>>>> Very helpful Robert, as it helps us identify that there is a problem >>>>>> on the server side around older accounts that somehow aren't being >>>>>> properly upgraded. >>>>>> >>>>>> Mark/David, can you treat this as an urgent issue to look in to, as >>>>>> it's getting reported by customers. >>>>>> >>>>>> Rick Wagner is getting more info from customers, but Robert seems to >>>>>> have identified at least one failing path. >>>>>> >>>>>> On 7 July 2016 at 17:29, Robert Kratky wrote: >>>>>>> Follow up: brand new account worked for this user. So: >>>>>>> >>>>>>> - user didn't use social accounts to log in >>>>>>> - orig. account created on dev.rh.com on May 18: doesn't work >>>>>>> - new account created on July 7: works >>>>>>> >>>>>>> Hope this helps a bit. >>>>>>> >>>>>>> Regards, >>>>>>> Robert >>>>>>> >>>>>>> >>>>>>> On 7.?7.?2016 17:33:32, Robert Kratky wrote: >>>>>>> >>>>>>>> Based on a new user comment [1], the "don't use social accounts" >>>>>>>> workaround doesn't seem to work. It might be related to the fact that >>>>>>>> he >>>>>>>> created his RH account on May 18 (i.e. it's not fresh). >>>>>>>> >>>>>>>> I asked the user to try a completely new account, but some less >>>>>>>> drastic >>>>>>>> solution would be better. >>>>>>>> >>>>>>>> Robert >>>>>>>> >>>>>>>> [1] https://access.redhat.com/articles/2255391#comment-1069221 >>>>>>>> >>>>>>>> >>>>>>>> On 7.?7.?2016 15:58:06, Robert Kratky wrote: >>>>>>>> >>>>>>>>> I updated the text to emphasize that social accounts are not to be >>>>>>>>> used. It now says, basically: >>>>>>>>> >>>>>>>>> 1) log in using RH credentials >>>>>>>>> 2) do not use social accounts >>>>>>>>> 3) if you can't (i.e. you have no RH account), create a new one >>>>>>>>> >>>>>>>>> Robert >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7.?7.?2016 14:42:15, Pete Muir wrote: >>>>>>>>> >>>>>>>>>> Robert, as discussed on the call, you might want to recommend a >>>>>>>>>> "radical" workaround, of just creating a new account entirely, >>>>>>>>>> without >>>>>>>>>> using social media at all. >>>>>>>>>> >>>>>>>>>> On 7 July 2016 at 14:38, Robert Kratky wrote: >>>>>>>>>>> I updated the trouleshooting section in [1] based on the >>>>>>>>>>> discussion during today's program call. Please, have a look and >>>>>>>>>>> let me know >>>>>>>>>>> if what I wrote is accurate -- I cannot test at this moment. >>>>>>>>>>> >>>>>>>>>>> This is what it says now: >>>>>>>>>>> >>>>>>>>>>> ............. >>>>>>>>>>> Terms and Conditions Error >>>>>>>>>>> >>>>>>>>>>> Error: ?Terms and Conditions for CDK have not been signed? >>>>>>>>>>> This error appears on the Log In page when starting the >>>>>>>>>>> Installer. To work around the problem, log in to the Developer >>>>>>>>>>> Portal using >>>>>>>>>>> your Red Hat credentials -- the credentials that you created >>>>>>>>>>> either on >>>>>>>>>>> redhat.com or developers.redhat.com. Do not use your social >>>>>>>>>>> accounts to log >>>>>>>>>>> in. Then start downloading the Installer from Red Hat Development >>>>>>>>>>> Suite >>>>>>>>>>> download page. >>>>>>>>>>> >>>>>>>>>>> If you do not have a Red Hat account, create one at >>>>>>>>>>> developers.redhat.com. >>>>>>>>>>> ............. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> Robert >>>>>>>>>>> >>>>>>>>>>> [1] https://access.redhat.com/articles/2360571#troubleshooting >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7.?7.?2016 10:32:06, Misha Husnain Ali wrote: >>>>>>>>>>> >>>>>>>>>>>> I remember this issue. Is there any way we can identify the >>>>>>>>>>>> paths leading >>>>>>>>>>>> up to this problem and comprehensively test them to provide >>>>>>>>>>>> clear aid to >>>>>>>>>>>> users who may encounter this issue? I'm happy to volunteer to >>>>>>>>>>>> test some of >>>>>>>>>>>> them if we can identify the various paths users may take. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Misha Husnain Ali >>>>>>>>>>>> Technical Writer 2, CCS Brisbane >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jul 7, 2016 at 5:38 AM, Denis Golovin >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> T&C's signing workflow is not user friendly ATM. >>>>>>>>>>>>> >>>>>>>>>>>>> Workaround mentioned in >>>>>>>>>>>>> https://access.redhat.com/articles/2360571 worked >>>>>>>>>>>>> before for >>>>>>>>>>>>> many dev's who was testing installer. I am going to do check >>>>>>>>>>>>> full T&C's >>>>>>>>>>>>> signing again today >>>>>>>>>>>>> and send update ASAP. >>>>>>>>>>>>> >>>>>>>>>>>>> This problem should be affecting only customers who didn't get >>>>>>>>>>>>> installer >>>>>>>>>>>>> directly from develper.redhat.com >>>>>>>>>>>>> download. >>>>>>>>>>>>> >>>>>>>>>>>>> Denis >>>>>>>>>>>>> >>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>> From: "Robert Kratky" >>>>>>>>>>>>>> To: devtools at redhat.com >>>>>>>>>>>>>> Cc: "Rick Wagner" >>>>>>>>>>>>>> Sent: Wednesday, July 6, 2016 8:51:03 AM >>>>>>>>>>>>>> Subject: Re: [Devtools] Development Suite installation >>>>>>>>>>>>>> question - C/O >>>>>>>>>>>>> SME with knowledge of installer edits >>>>>>>>>>>>>> On 6.?7.?2016 10:08:09, Rick Wagner wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello DevTools, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We have a customer case that deals with the error message >>>>>>>>>>>>>>> "Terms and >>>>>>>>>>>>>>> Conditions for the CDK have not been signed". (Actually, >>>>>>>>>>>>>>> this is the >>>>>>>>>>>>>>> second case in 2 days for this problem.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The customer has tried the suggested workaround, without >>>>>>>>>>>>>>> satisfactory >>>>>>>>>>>>>>> results. ("This error appears on the *Log In* page when >>>>>>>>>>>>>>> starting the >>>>>>>>>>>>>>> Installer. To fix the problem, start downloading the >>>>>>>>>>>>>>> Installer to >>>>>>>>>>>>> ensure >>>>>>>>>>>>>>> the *Terms and Conditions* are viewed and accepted and >>>>>>>>>>>>>>> then cancel the >>>>>>>>>>>>>>> binary download." We offer this suggestion in the >>>>>>>>>>>>>>> knowledge article at >>>>>>>>>>>>>>> [1].) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can a knowledgeable SME please offer ideas about >>>>>>>>>>>>>>> alternative courses of >>>>>>>>>>>>>>> action? >>>>>>>>>>>>>> Hi Rick, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The problem happens quite often, apparently. I asked about >>>>>>>>>>>>>> this last >>>>>>>>>>>>> Friday >>>>>>>>>>>>>> in devtools-program [a] -- on behalf of a user who reported >>>>>>>>>>>>>> the problem >>>>>>>>>>>>> in a >>>>>>>>>>>>>> comment under the old version of the Kbase article [b]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any workaround would be appreciated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> [a] >>>>>>>>>>>>>> >>>>>>>>>>>>> http://post-office.corp.redhat.com/archives/devtools-program/2016-July/msg00001.html >>>>>>>>>>>>>> [b] >>>>>>>>>>>>>> https://access.redhat.com/articles/2255391#comment-1066361 >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Extra credit: Can you please point me to the source code >>>>>>>>>>>>>>> that produces >>>>>>>>>>>>>>> this edit error? A little spelunking by the Support team >>>>>>>>>>>>>>> sometimes >>>>>>>>>>>>> helps >>>>>>>>>>>>>>> with related issues. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Rick >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] https://access.redhat.com/articles/2360571 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >> From pmuir at redhat.com Wed Aug 10 22:59:27 2016 From: pmuir at redhat.com (Pete Muir) Date: Wed, 10 Aug 2016 18:59:27 -0400 Subject: [Devtools] Development Suite installation question - C/O SME with knowledge of installer edits In-Reply-To: References: <1829398.oJedtQYAuc@x230> <1597469.slTCQpW6SA@x230> <6413734.nWTzG8j3RH@x230> <1960516785.6522026.1469002102802.JavaMail.zimbra@redhat.com> Message-ID: David? On 10 Aug 2016 3:53 p.m., "Denis Golovin" wrote: > Pete, > > I am out of logins with T&C's problems, that nivologd was the last one. I > hope Rick will be > able to verify when one more similar case reported by customer. > > Is there a way to reset signed T&C's for nivolog at gmail.com or create new > one so I can verify? > > Thanks, > Denis > > On 8/10/2016 3:49 AM, Pete Muir wrote: > >> Also note that the devsuite had the wrong subscription type attached >> in the download manager. I have updated to be the RHEL Developer Suite >> sub, which should make the documented workaround work. Denis/Rick, >> could you please test the documented "if it doesn't work, try >> downloading devsuite again using the same account"? >> >> Thanks >> >> On 10 August 2016 at 01:41, Denis Golovin wrote: >> >>> I've updated description for this https://issues.jboss.org/brows >>> e/RHDENG-579 >>> with better workaround. The idea is to login and download CDK itself from >>> developers.redhat.com. This will trigger, if required, additional >>> information request which in my case included one T&C to sign. Finishing >>> the >>> form fixed T&C's problem in installer. >>> >>> Denis >>> >>> >>> On 7/20/2016 1:08 AM, Denis Golovin wrote: >>> >>>> FYI: JIRA created to track this problem: >>>> ORG-3470 DevSuite T&C's signing status check doesn't work for users >>>> created before May 18th >>>> >>>> Denis >>>> >>>> ----- Original Message ----- >>>> >>>>> From: "Pete Muir" >>>>> To: "Rick Wagner" >>>>> Cc: devtools at redhat.com, "Mark Newton" >>>>> Sent: Thursday, July 7, 2016 11:34:47 AM >>>>> Subject: Re: [Devtools] Development Suite installation question - C/O >>>>> SME >>>>> with knowledge of installer edits >>>>> >>>>> On 7 July 2016 at 19:08, Rick Wagner wrote: >>>>> >>>>>> Hello All, >>>>>> >>>>>> Additional information, this from (no SalesForce acct required) the >>>>>> support >>>>>> case at [1]. >>>>>> >>>>>> The customer is telling us the 'use a new account' workaround was >>>>>> successful >>>>>> with a Windows 10 machine. A second attempt on a Win 7 machine fails. >>>>>> >>>>>> The failed effort: >>>>>> - Is using the userid 'ryanbuckett' >>>>>> - Previously failed effort (the original account) was >>>>>> 'SumaGeethakumari'. >>>>>> >>>>>> The customer is asking if the downloaded exectuable must be used on >>>>>> the >>>>>> machine it was downloaded to? (If the username specified for download >>>>>> and >>>>>> installation are the same, is it relevant where the artifact was >>>>>> downloaded >>>>>> to?) >>>>>> >>>>> No, the link is usernames. You must use the username you downloaded >>>>> with when you run the installer. >>>>> >>>>> David/Mark, can you check these user accounts - have they signed the >>>>> RHEL Developer Suite T&C? >>>>> >>>>> Thanks, >>>>>> >>>>>> Rick >>>>>> >>>>>> [1] https://access.redhat.com/support/cases/01662411 >>>>>> >>>>>> On Thu, Jul 7, 2016 at 11:40 AM, Pete Muir wrote: >>>>>> >>>>>>> Very helpful Robert, as it helps us identify that there is a problem >>>>>>> on the server side around older accounts that somehow aren't being >>>>>>> properly upgraded. >>>>>>> >>>>>>> Mark/David, can you treat this as an urgent issue to look in to, as >>>>>>> it's getting reported by customers. >>>>>>> >>>>>>> Rick Wagner is getting more info from customers, but Robert seems to >>>>>>> have identified at least one failing path. >>>>>>> >>>>>>> On 7 July 2016 at 17:29, Robert Kratky wrote: >>>>>>> >>>>>>>> Follow up: brand new account worked for this user. So: >>>>>>>> >>>>>>>> - user didn't use social accounts to log in >>>>>>>> - orig. account created on dev.rh.com on May 18: doesn't work >>>>>>>> - new account created on July 7: works >>>>>>>> >>>>>>>> Hope this helps a bit. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>>>> On 7.?7.?2016 17:33:32, Robert Kratky wrote: >>>>>>>> >>>>>>>> Based on a new user comment [1], the "don't use social accounts" >>>>>>>>> workaround doesn't seem to work. It might be related to the fact >>>>>>>>> that >>>>>>>>> he >>>>>>>>> created his RH account on May 18 (i.e. it's not fresh). >>>>>>>>> >>>>>>>>> I asked the user to try a completely new account, but some less >>>>>>>>> drastic >>>>>>>>> solution would be better. >>>>>>>>> >>>>>>>>> Robert >>>>>>>>> >>>>>>>>> [1] https://access.redhat.com/articles/2255391#comment-1069221 >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7.?7.?2016 15:58:06, Robert Kratky wrote: >>>>>>>>> >>>>>>>>> I updated the text to emphasize that social accounts are not to be >>>>>>>>>> used. It now says, basically: >>>>>>>>>> >>>>>>>>>> 1) log in using RH credentials >>>>>>>>>> 2) do not use social accounts >>>>>>>>>> 3) if you can't (i.e. you have no RH account), create a new one >>>>>>>>>> >>>>>>>>>> Robert >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7.?7.?2016 14:42:15, Pete Muir wrote: >>>>>>>>>> >>>>>>>>>> Robert, as discussed on the call, you might want to recommend a >>>>>>>>>>> "radical" workaround, of just creating a new account entirely, >>>>>>>>>>> without >>>>>>>>>>> using social media at all. >>>>>>>>>>> >>>>>>>>>>> On 7 July 2016 at 14:38, Robert Kratky >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I updated the trouleshooting section in [1] based on the >>>>>>>>>>>> discussion during today's program call. Please, have a look and >>>>>>>>>>>> let me know >>>>>>>>>>>> if what I wrote is accurate -- I cannot test at this moment. >>>>>>>>>>>> >>>>>>>>>>>> This is what it says now: >>>>>>>>>>>> >>>>>>>>>>>> ............. >>>>>>>>>>>> Terms and Conditions Error >>>>>>>>>>>> >>>>>>>>>>>> Error: ?Terms and Conditions for CDK have not been signed? >>>>>>>>>>>> This error appears on the Log In page when starting the >>>>>>>>>>>> Installer. To work around the problem, log in to the Developer >>>>>>>>>>>> Portal using >>>>>>>>>>>> your Red Hat credentials -- the credentials that you created >>>>>>>>>>>> either on >>>>>>>>>>>> redhat.com or developers.redhat.com. Do not use your social >>>>>>>>>>>> accounts to log >>>>>>>>>>>> in. Then start downloading the Installer from Red Hat >>>>>>>>>>>> Development >>>>>>>>>>>> Suite >>>>>>>>>>>> download page. >>>>>>>>>>>> >>>>>>>>>>>> If you do not have a Red Hat account, create one at >>>>>>>>>>>> developers.redhat.com. >>>>>>>>>>>> ............. >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> [1] https://access.redhat.com/articles/2360571#troubleshooting >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7.?7.?2016 10:32:06, Misha Husnain Ali wrote: >>>>>>>>>>>> >>>>>>>>>>>> I remember this issue. Is there any way we can identify the >>>>>>>>>>>>> paths leading >>>>>>>>>>>>> up to this problem and comprehensively test them to provide >>>>>>>>>>>>> clear aid to >>>>>>>>>>>>> users who may encounter this issue? I'm happy to volunteer to >>>>>>>>>>>>> test some of >>>>>>>>>>>>> them if we can identify the various paths users may take. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Misha Husnain Ali >>>>>>>>>>>>> Technical Writer 2, CCS Brisbane >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jul 7, 2016 at 5:38 AM, Denis Golovin >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> T&C's signing workflow is not user friendly ATM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Workaround mentioned in >>>>>>>>>>>>>> https://access.redhat.com/articles/2360571 worked >>>>>>>>>>>>>> before for >>>>>>>>>>>>>> many dev's who was testing installer. I am going to do check >>>>>>>>>>>>>> full T&C's >>>>>>>>>>>>>> signing again today >>>>>>>>>>>>>> and send update ASAP. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This problem should be affecting only customers who didn't get >>>>>>>>>>>>>> installer >>>>>>>>>>>>>> directly from develper.redhat.com >>>>>>>>>>>>>> download. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Denis >>>>>>>>>>>>>> >>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> From: "Robert Kratky" >>>>>>>>>>>>>>> To: devtools at redhat.com >>>>>>>>>>>>>>> Cc: "Rick Wagner" >>>>>>>>>>>>>>> Sent: Wednesday, July 6, 2016 8:51:03 AM >>>>>>>>>>>>>>> Subject: Re: [Devtools] Development Suite installation >>>>>>>>>>>>>>> question - C/O >>>>>>>>>>>>>>> >>>>>>>>>>>>>> SME with knowledge of installer edits >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 6.?7.?2016 10:08:09, Rick Wagner wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello DevTools, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We have a customer case that deals with the error message >>>>>>>>>>>>>>>> "Terms and >>>>>>>>>>>>>>>> Conditions for the CDK have not been signed". (Actually, >>>>>>>>>>>>>>>> this is the >>>>>>>>>>>>>>>> second case in 2 days for this problem.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The customer has tried the suggested workaround, without >>>>>>>>>>>>>>>> satisfactory >>>>>>>>>>>>>>>> results. ("This error appears on the *Log In* page when >>>>>>>>>>>>>>>> starting the >>>>>>>>>>>>>>>> Installer. To fix the problem, start downloading the >>>>>>>>>>>>>>>> Installer to >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ensure >>>>>>>>>>>>>> >>>>>>>>>>>>>>> the *Terms and Conditions* are viewed and accepted and >>>>>>>>>>>>>>>> then cancel the >>>>>>>>>>>>>>>> binary download." We offer this suggestion in the >>>>>>>>>>>>>>>> knowledge article at >>>>>>>>>>>>>>>> [1].) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Can a knowledgeable SME please offer ideas about >>>>>>>>>>>>>>>> alternative courses of >>>>>>>>>>>>>>>> action? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Rick, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The problem happens quite often, apparently. I asked about >>>>>>>>>>>>>>> this last >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Friday >>>>>>>>>>>>>> >>>>>>>>>>>>>>> in devtools-program [a] -- on behalf of a user who reported >>>>>>>>>>>>>>> the problem >>>>>>>>>>>>>>> >>>>>>>>>>>>>> in a >>>>>>>>>>>>>> >>>>>>>>>>>>>>> comment under the old version of the Kbase article [b]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any workaround would be appreciated. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Robert >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [a] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://post-office.corp.redhat.com/archives/devtools-program >>>>>>>>>>>>>> /2016-July/msg00001.html >>>>>>>>>>>>>> >>>>>>>>>>>>>>> [b] >>>>>>>>>>>>>>> https://access.redhat.com/articles/2255391#comment-1066361 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Extra credit: Can you please point me to the source code >>>>>>>>>>>>>>>> that produces >>>>>>>>>>>>>>>> this edit error? A little spelunking by the Support team >>>>>>>>>>>>>>>> sometimes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> helps >>>>>>>>>>>>>> >>>>>>>>>>>>>>> with related issues. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Rick >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] https://access.redhat.com/articles/2360571 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 prkumar at redhat.com Thu Aug 11 06:10:39 2016 From: prkumar at redhat.com (Praveen Kumar) Date: Thu, 11 Aug 2016 11:40:39 +0530 Subject: [Devtools] vagrant plugin installation using local gem file on F24 and CentOS In-Reply-To: <856962560.22415605.1470885872232.JavaMail.zimbra@redhat.com> References: <47217905.22121815.1470883574005.JavaMail.zimbra@redhat.com> <856962560.22415605.1470885872232.JavaMail.zimbra@redhat.com> Message-ID: On Thu, Aug 11, 2016 at 8:54 AM, Pavel Valena wrote: > Hi, > > reference: the local plugin install on F24 and CentOS (SCL) is broken[1]. > > I have patched F24[2], and the build can be immediately pushed to stable when it gets karma. Thanks a lot Pavel for adding that patch, we were using is locally for a long time. I did tested out it with fedora 24 and works as expected also added karma. > > In CentOS, I was going to update to Vagrant 1.8.5, but it is bit more complicated and it should definitely be properly tested. > Therefore I have patched the SCL too, please try this scratch-build[3] and if the build works for you I can directly push it to stable (it takes 2-3 days for the builds to sync to CentOS mirrors). I will try that in CentOS also and let you know. Thanks again. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1330216 > [2] https://bodhi.fedoraproject.org/updates/FEDORA-2016-c79ecd0357 > [3] https://cbs.centos.org/koji/taskinfo?taskID=104762 -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen From bgurung at redhat.com Fri Aug 12 11:07:03 2016 From: bgurung at redhat.com (Budh Gurung) Date: Fri, 12 Aug 2016 16:37:03 +0530 Subject: [Devtools] vagrant-service-manager version 1.3.0 release Message-ID: Hey All, We have released version 1.3.0 of vagrant-service-manager plugin. This release of plugin include cool features like: - Client binary installation support for Docker, OpenShift, Kubernetes in ADB/CDK - Auto detection of already downloaded executable 'oc.exe' binary in Windows OS only - Enable displaying of Kubernetes setup information so user can access its server from host - Added unit and acceptance tests for kubernetes to help development process - Enabled 'kubernetes' service from Vagrantfile configuration option as config.servicemanager.services = 'kubernetes' Check here [1] to find the detailed CHANGELOG for the release. [1] https://github.com/projectatomic/vagrant-service-manager/releases/tag/v1.3.0 Regards, Budh Ram Gurung Software Engineer - Dev Tools -------------- next part -------------- An HTML attachment was scrubbed... URL: From rstryker at redhat.com Mon Aug 15 20:00:36 2016 From: rstryker at redhat.com (Robert Stryker) Date: Mon, 15 Aug 2016 16:00:36 -0400 Subject: [Devtools] Does CDK have JIRA yet? Message-ID: If so, where is it? If not, when? - Rob Stryker -------------- next part -------------- An HTML attachment was scrubbed... URL: From bex at pobox.com Tue Aug 16 09:50:44 2016 From: bex at pobox.com (Brian Exelbierd) Date: Tue, 16 Aug 2016 11:50:44 +0200 Subject: [Devtools] Does CDK have JIRA yet? In-Reply-To: References: Message-ID: <1471341044.1401658.696648937.47434F5D@webmail.messagingengine.com> I believe, that CDK bugs are encouraged to be filed upstream as issues in the ADB repository. Where that is not appropriate components exist in Bugzilla. I do not believe the CDK team is planning to use JIRA. regards, bex On Mon, Aug 15, 2016, at 10:00 PM, Robert Stryker wrote: > If so, where is it? If not, when? > - Rob Stryker > _________________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From timoran at redhat.com Tue Aug 16 13:44:15 2016 From: timoran at redhat.com (Tim Moran) Date: Tue, 16 Aug 2016 09:44:15 -0400 Subject: [Devtools] Does CDK have JIRA yet? In-Reply-To: References: Message-ID: CDK does not have a Jira yet, but will. Kerri Anderson will be working with the CDK team to implement a new CDK instance. Hang tight, the wheels are turning. Thanks, -Tim On Mon, Aug 15, 2016 at 4:00 PM, Robert Stryker wrote: > If so, where is it? If not, when? > > - Rob Stryker > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From timoran at redhat.com Tue Aug 16 13:44:49 2016 From: timoran at redhat.com (Tim Moran) Date: Tue, 16 Aug 2016 09:44:49 -0400 Subject: [Devtools] Does CDK have JIRA yet? In-Reply-To: References: Message-ID: CC'ing the right person. On Tue, Aug 16, 2016 at 9:44 AM, Tim Moran wrote: > CDK does not have a Jira yet, but will. Kerri Anderson will be working > with the CDK team to implement a new CDK instance. > > Hang tight, the wheels are turning. > > Thanks, > -Tim > > On Mon, Aug 15, 2016 at 4:00 PM, Robert Stryker > wrote: > >> If so, where is it? If not, when? >> >> - Rob Stryker >> >> _______________________________________________ >> 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 Wed Aug 17 21:55:44 2016 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 17 Aug 2016 17:55:44 -0400 Subject: [Devtools] Fwd: [openshift-sme] [openshift-sales] csp login for oc tools In-Reply-To: References: Message-ID: FYI, I assume the CDK-based version of OpenShift will support this correctly. Is this the right list to alert to this sort of thing? ---------- Forwarded message ---------- From: Mike Barrett Date: Wed, Aug 17, 2016 at 4:34 PM Subject: Re: [openshift-sme] [openshift-sales] csp login for oc tools To: Erik Jacobs , Matt Davis Cc: openshift-sales at redhat.com, openshift-sme Starting in May with OCP 3.2 the oc clients became downloadable from under the help menu from the webconsole. So anyone that has access to an OCP environment and a desire to have a commandline should have access to the command line clients from that same page without needing to go anywhere else. On Wed, Aug 17, 2016 at 3:28 PM, Erik Jacobs wrote: > Adding openshift-sme and Mike Barrett directly. > > Did we make a decision on whether or not we would publicly host the oc > tools in the near future? > > > > > Erik M Jacobs, RHCA > Principal Technical Marketing Manager, OpenShift Enterprise > Red Hat, Inc. > Phone: 646.462.3745 > Email: ejacobs at redhat.com > AOL Instant Messenger: ejacobsatredhat > Twitter: @ErikonOpen > Freenode: thoraxe > > On Tue, Aug 16, 2016 at 10:24 AM, Matt Davis wrote: > >> This seems like an odd requirement when we want development teams to >> download and go. Any way to put it on the developer portal to make it >> easy (no messages about renewing subscription)? >> >> -mattd >> >> -- >> >> Matthew Davis >> JBoss Solutions Architect >> 919-302-7238 >> > > -- Mike Barrett Red Hat Cloud OpenShift Product Manager o: 919-754-4724 (81 44724) m: 513-802-3181 Have a question? First, check the FAQ: https://mojo.redhat.com/docs/DOC-943081 Next, check the archives: http://post-office.corp. redhat.com/archives/openshift-sme/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmuir at redhat.com Thu Aug 18 12:13:46 2016 From: pmuir at redhat.com (Pete Muir) Date: Thu, 18 Aug 2016 08:13:46 -0400 Subject: [Devtools] Fwd: [openshift-sme] [openshift-sales] csp login for oc tools In-Reply-To: References: Message-ID: The developer portal team are working to add it to to the developer portal at the moment. I expect it up soon. CDK will then use it from there. On 17 August 2016 at 17:55, Burr Sutter wrote: > FYI, I assume the CDK-based version of OpenShift will support this > correctly. > > Is this the right list to alert to this sort of thing? > > ---------- Forwarded message ---------- > From: Mike Barrett > Date: Wed, Aug 17, 2016 at 4:34 PM > Subject: Re: [openshift-sme] [openshift-sales] csp login for oc tools > To: Erik Jacobs , Matt Davis > Cc: openshift-sales at redhat.com, openshift-sme > > > Starting in May with OCP 3.2 the oc clients became downloadable from under > the help menu from the webconsole. So anyone that has access to an OCP > environment and a desire to have a commandline should have access to the > command line clients from that same page without needing to go anywhere > else. > > On Wed, Aug 17, 2016 at 3:28 PM, Erik Jacobs wrote: >> >> Adding openshift-sme and Mike Barrett directly. >> >> Did we make a decision on whether or not we would publicly host the oc >> tools in the near future? >> >> >> >> >> Erik M Jacobs, RHCA >> Principal Technical Marketing Manager, OpenShift Enterprise >> Red Hat, Inc. >> Phone: 646.462.3745 >> Email: ejacobs at redhat.com >> AOL Instant Messenger: ejacobsatredhat >> Twitter: @ErikonOpen >> Freenode: thoraxe >> >> On Tue, Aug 16, 2016 at 10:24 AM, Matt Davis wrote: >>> >>> This seems like an odd requirement when we want development teams to >>> download and go. Any way to put it on the developer portal to make it easy >>> (no messages about renewing subscription)? >>> >>> -mattd >>> >>> -- >>> >>> Matthew Davis >>> JBoss Solutions Architect >>> 919-302-7238 >> >> > > > > -- > > > Mike Barrett > Red Hat Cloud > OpenShift Product Manager > o: 919-754-4724 (81 44724) > m: 513-802-3181 > > > Have a question? > First, check the FAQ: https://mojo.redhat.com/docs/DOC-943081 > Next, check the archives: > http://post-office.corp.redhat.com/archives/openshift-sme/ > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > From budhram.gurung01 at gmail.com Thu Aug 18 12:33:40 2016 From: budhram.gurung01 at gmail.com (Budh Ram) Date: Thu, 18 Aug 2016 18:03:40 +0530 Subject: [Devtools] Fwd: [openshift-sme] [openshift-sales] csp login for oc tools In-Reply-To: References: Message-ID: On Thu, Aug 18, 2016 at 5:43 PM, Pete Muir wrote: > The developer portal team are working to add it to to the developer > portal at the moment. I expect it up soon. > > CDK will then use it from there. To add to Pete's comment here, the upcoming CDK 2.2 is coming up with CLI approach [1] through vagrant service-manager plugin. We will migrate it developer portal approach once it is available for CDK. [1] http://www.projectatomic.io/blog/2016/07/vagrant-service-manager-install-cli/ > On 17 August 2016 at 17:55, Burr Sutter wrote: > > FYI, I assume the CDK-based version of OpenShift will support this > > correctly. > > > > Is this the right list to alert to this sort of thing? > > > > ---------- Forwarded message ---------- > > From: Mike Barrett > > Date: Wed, Aug 17, 2016 at 4:34 PM > > Subject: Re: [openshift-sme] [openshift-sales] csp login for oc tools > > To: Erik Jacobs , Matt Davis > > Cc: openshift-sales at redhat.com, openshift-sme > > > > > > Starting in May with OCP 3.2 the oc clients became downloadable from > under > > the help menu from the webconsole. So anyone that has access to an OCP > > environment and a desire to have a commandline should have access to the > > command line clients from that same page without needing to go anywhere > > else. > > > > On Wed, Aug 17, 2016 at 3:28 PM, Erik Jacobs wrote: > >> > >> Adding openshift-sme and Mike Barrett directly. > >> > >> Did we make a decision on whether or not we would publicly host the oc > >> tools in the near future? > >> > >> > >> > >> > >> Erik M Jacobs, RHCA > >> Principal Technical Marketing Manager, OpenShift Enterprise > >> Red Hat, Inc. > >> Phone: 646.462.3745 > >> Email: ejacobs at redhat.com > >> AOL Instant Messenger: ejacobsatredhat > >> Twitter: @ErikonOpen > >> Freenode: thoraxe > >> > >> On Tue, Aug 16, 2016 at 10:24 AM, Matt Davis > wrote: > >>> > >>> This seems like an odd requirement when we want development teams to > >>> download and go. Any way to put it on the developer portal to make > it easy > >>> (no messages about renewing subscription)? > >>> > >>> -mattd > >>> > >>> -- > >>> > >>> Matthew Davis > >>> JBoss Solutions Architect > >>> 919-302-7238 > >> > >> > > > > > > > > -- > > > > > > Mike Barrett > > Red Hat Cloud > > OpenShift Product Manager > > o: 919-754-4724 (81 44724) > > m: 513-802-3181 > > > > > > Have a question? > > First, check the FAQ: https://mojo.redhat.com/docs/DOC-943081 > > Next, check the archives: > > http://post-office.corp.redhat.com/archives/openshift-sme/ > > > > > > _______________________________________________ > > 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 > -- Regards, Budh Ram Gurung -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwagner at redhat.com Mon Aug 22 14:28:15 2016 From: rwagner at redhat.com (Rick Wagner) Date: Mon, 22 Aug 2016 09:28:15 -0500 Subject: [Devtools] (DevStudio question): Which plugin for JavaFX? Message-ID: Hello DevTools / DevStudio SMEs, We have a customer that seeks recommendations for a JavaFX plugin. We have a knowledgeable internal user that suggests e(fx)clipse. Before passing this along to the customer, we wanted to touch base to see if there are any further thoughts on this topic. Please consider, share any advice if it differs from 'use e(fx)clipse'. Thank you, Rick [1] https://access.redhat.com/support/cases/01688279 -------------- next part -------------- An HTML attachment was scrubbed... URL: From timoran at redhat.com Mon Aug 22 14:31:52 2016 From: timoran at redhat.com (Tim Moran) Date: Mon, 22 Aug 2016 10:31:52 -0400 Subject: [Devtools] (DevStudio question): Which plugin for JavaFX? In-Reply-To: References: Message-ID: +devtools-team On Mon, Aug 22, 2016 at 10:28 AM, Rick Wagner wrote: > Hello DevTools / DevStudio SMEs, > > We have a customer that seeks recommendations for a JavaFX plugin. > > We have a knowledgeable internal user that suggests e(fx)clipse. Before > passing this along to the customer, we wanted to touch base to see if there > are any further thoughts on this topic. > > Please consider, share any advice if it differs from 'use e(fx)clipse'. > > Thank you, > > Rick > > [1] https://access.redhat.com/support/cases/01688279 > > _______________________________________________ > 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 Mon Aug 22 17:21:48 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 22 Aug 2016 19:21:48 +0200 Subject: [Devtools] [devtools-team] (DevStudio question): Which plugin for JavaFX? In-Reply-To: References: Message-ID: <43DF09A2-80E2-4251-A747-0F678CE9B4AD@redhat.com> e(fx)clipse is an option but just be aware JavaFX is not supported on any OpenJDK based product we have (yet) So he would need to run Oracle JDK. /max > +devtools-team > > On Mon, Aug 22, 2016 at 10:28 AM, Rick Wagner > wrote: > >> Hello DevTools / DevStudio SMEs, >> >> We have a customer that seeks recommendations for a JavaFX plugin. >> >> We have a knowledgeable internal user that suggests e(fx)clipse. >> Before >> passing this along to the customer, we wanted to touch base to see if >> there >> are any further thoughts on this topic. >> >> Please consider, share any advice if it differs from 'use >> e(fx)clipse'. >> >> Thank you, >> >> Rick >> >> [1] https://access.redhat.com/support/cases/01688279 >> >> _______________________________________________ >> 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 neugens at redhat.com Mon Aug 22 17:31:30 2016 From: neugens at redhat.com (Mario Torre) Date: Mon, 22 Aug 2016 19:31:30 +0200 Subject: [Devtools] [devtools-team] (DevStudio question): Which plugin for JavaFX? In-Reply-To: <43DF09A2-80E2-4251-A747-0F678CE9B4AD@redhat.com> References: <43DF09A2-80E2-4251-A747-0F678CE9B4AD@redhat.com> Message-ID: On Mon, Aug 22, 2016 at 7:21 PM, Max Rydahl Andersen wrote: > e(fx)clipse is an option but just be aware JavaFX is not supported on any > OpenJDK based product we have (yet) > So he would need to run Oracle JDK. > /max > That's not totally true, though. JavaFX is not supported and is an OracleJDK only thing, but OpenJFX works well with OpenJDK, it needs to be compiled from source though, we don't ship it with our OpenJDK offering. Cheers, Mario From rwagner at redhat.com Mon Aug 22 18:36:41 2016 From: rwagner at redhat.com (Rick Wagner) Date: Mon, 22 Aug 2016 13:36:41 -0500 Subject: [Devtools] [devtools-team] (DevStudio question): Which plugin for JavaFX? In-Reply-To: References: <43DF09A2-80E2-4251-A747-0F678CE9B4AD@redhat.com> Message-ID: As always, thanks for the tips. Regards, Rick On Mon, Aug 22, 2016 at 12:31 PM, Mario Torre wrote: > On Mon, Aug 22, 2016 at 7:21 PM, Max Rydahl Andersen > wrote: > > e(fx)clipse is an option but just be aware JavaFX is not supported on any > > OpenJDK based product we have (yet) > > So he would need to run Oracle JDK. > > /max > > > > That's not totally true, though. JavaFX is not supported and is an > OracleJDK only thing, but OpenJFX works well with OpenJDK, it needs to > be compiled from source though, we don't ship it with our OpenJDK > offering. > > Cheers, > Mario > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdrage at redhat.com Tue Aug 23 20:03:28 2016 From: cdrage at redhat.com (Charlie Drage) Date: Tue, 23 Aug 2016 16:03:28 -0400 Subject: [Devtools] Introducing 'kubeshift' the OpenShift / Kubernetes Python API library Message-ID: <20160823200328.GA1@ac8aba16ced7> Hey all! The work we've done to communicate with both OpenShift and Kubernetes via their respective APIs has been forked from the Atomic App project into it's own separate library! I've made the repo public at https://github.com/cdrage/kubeshift please feel free to star / fork the project! There's still a lot of things to do such as creating the rpm, deb as well as publishing it to pypi. -- Charlie Drage Red Hat - Dev Tools / Project Atomic PGP - 4096R/C037D617 http://pgp.mit.edu/pks/lookup?op=get&search=0xDA227403C037D617 From dusty at dustymabe.com Wed Aug 24 01:43:10 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Tue, 23 Aug 2016 21:43:10 -0400 Subject: [Devtools] Introducing 'kubeshift' the OpenShift / Kubernetes Python API library In-Reply-To: <20160823200328.GA1@ac8aba16ced7> References: <20160823200328.GA1@ac8aba16ced7> Message-ID: <16e3885b-9e25-7731-6424-560816d87be4@dustymabe.com> On 08/23/2016 04:03 PM, Charlie Drage wrote: > Hey all! > > The work we've done to communicate with both OpenShift and Kubernetes > via their respective APIs has been forked from the Atomic App project > into it's own separate library! > > I've made the repo public at https://github.com/cdrage/kubeshift > please feel free to star / fork the project! > > There's still a lot of things to do such as creating the rpm, deb as > well as publishing it to pypi. > Nice work charlie. Should we call it py-kubeshift or something like that to help better denote the python roots? Dusty From alr at redhat.com Wed Aug 24 02:37:59 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 23 Aug 2016 22:37:59 -0400 Subject: [Devtools] Introducing 'kubeshift' the OpenShift / Kubernetes Python API library In-Reply-To: <16e3885b-9e25-7731-6424-560816d87be4@dustymabe.com> References: <20160823200328.GA1@ac8aba16ced7> <16e3885b-9e25-7731-6424-560816d87be4@dustymabe.com> Message-ID: On Tue, Aug 23, 2016 at 9:43 PM, Dusty Mabe wrote: > > > On 08/23/2016 04:03 PM, Charlie Drage wrote: > > Hey all! > > > > The work we've done to communicate with both OpenShift and Kubernetes > > via their respective APIs has been forked from the Atomic App project > > into it's own separate library! > > > > I've made the repo public at https://github.com/cdrage/kubeshift > > please feel free to star / fork the project! > > > > There's still a lot of things to do such as creating the rpm, deb as > > well as publishing it to pypi. > > > > Nice work charlie. Should we call it py-kubeshift or something like > that to help better denote the python roots? > +1; we also have at least 2 Java APIs from the OpenShift team and from Fabric8 to similar aims. S, ALR > > Dusty > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From rstryker at redhat.com Wed Aug 24 04:47:22 2016 From: rstryker at redhat.com (Robert Stryker) Date: Wed, 24 Aug 2016 00:47:22 -0400 Subject: [Devtools] Not sure how to test new CDK, can't install plugins Message-ID: Hey all: I may have made complaints about this before in the past, but I'm really baffled how to install the vagrant plugins that come bundled in the cdk.zip, and nothing really seems to work for me... or at least, nothing that I would consider normal. It seems any time i try to install one of the bundled plugins, it just complains I need to go find its dependencies. I don't know if the dependencies are also plugins or not, but I have to install them, and, in some cases, uninstall them afterwards. For example trying to install vagrant-sshfs tells me i must install win32-process first. But win32-process isn't an actual vagrant plugin...... So I have to vagrant plugin install win32-process, then vagrant plugin install the local gem for vagrant-sshfs, then vagrant plugin uninstall win32-process. Is this intentional? Is this a known defect? Is there any way around it? [rob at rawbdor rhel-ose]$ uname -a Linux rawbdor 4.4.14-200.fc22.x86_64 #1 SMP Fri Jun 24 21:19:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [rob at rawbdor rhel-ose]$ vagrant version Installed Version: 1.7.2 Latest Version: 1.8.5 [root at rawbdor rhel-ose]$ dnf install vagrant Package vagrant-1.7.2-12.fc22.noarch is already installed, skipping. Dependencies resolved. Nothing to do. Complete! [root at rawbdor rhel-ose]$ dnf update vagrant Dependencies resolved. Nothing to do. Complete! Stream-of-conscious too much info below... Don't bother reading it unless you want to see my shell log, basically. [rob at rawbdor plugins]$ vagrant plugin list vagrant-libvirt (0.0.35, system) vagrant-registration (1.2.3) So then I look at what plugins I need to install: [rob at rawbdor plugins]$ ls *.gem landrush-1.2.0.dev.gem vagrant-service-manager-1.4.0.dev.gem vagrant-registration-1.2.3.gem vagrant-sshfs-1.2.0.gem Ok... seems reasonable... so lets start with landrush. [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' plugin. This can take a few minutes... /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' requires 'rubydns (= 0.8.5)' (Gem::UnsatisfiableDependencyError) ... etc etc etc... So then I try to install rubydns... but I know this isn't a plugin or it would be listed in the list of required plugins? [rob at rawbdor plugins]$ gem install rubydns ERROR: Could not find a valid gem 'rubydns' (>= 0) in any repository Ok... so it can't be found... um... [rob at rawbdor plugins]$ vagrant plugin install rubydns Installing the 'rubydns' plugin. This can take a few minutes... Installed the plugin 'rubydns (0.8.5)'! [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' plugin. This can take a few minutes... /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' requires 'landrush-ip (~> 0.2.3)' (Gem::UnsatisfiableDependencyError) etc etc etc... So... now I have to install landrush-ip? [rob at rawbdor plugins]$ gem install landrush-ip ERROR: Could not find a valid gem 'landrush-ip' (>= 0) in any repository I can repeat the same procedure.... I guess... but it feels very wrong to me. [rob at rawbdor plugins]$ vagrant plugin install landrush-ip Installing the 'landrush-ip' plugin. This can take a few minutes... Installed the plugin 'landrush-ip (0.2.3)'! [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' plugin. This can take a few minutes... /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' requires 'win32-process (>= 0)' (Gem::UnsatisfiableDependencyError) Ok... so now I need to install win32-process [rob at rawbdor plugins]$ vagrant plugin install win32-process Installing the 'win32-process' plugin. This can take a few minutes... Installed the plugin 'win32-process (0.8.3)'! [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' plugin. This can take a few minutes... Installed the plugin 'landrush (1.2.0.dev)'! Great... so now........ [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-registration-1.2.3.gem Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-registration-1.2.3.gem' plugin. This can take a few minutes... Installed the plugin 'vagrant-registration (1.2.3)'! Ok... that went fine... maybe that was the only problem? [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' plugin. This can take a few minutes... /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in `resolve_for_zero': Unable to resolve dependency: 'vagrant-service-manager (= 1.4.0.dev)' requires 'rubyzip (~> 1.2.0)' (Gem::UnsatisfiableDependencyError) [rob at rawbdor plugins]$ vagrant plugin install rubyzip Installing the 'rubyzip' plugin. This can take a few minutes... Installed the plugin 'rubyzip (1.2.0)'! [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' plugin. This can take a few minutes... Installed the plugin 'vagrant-service-manager (1.4.0.dev)'! [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-sshfs-1.2.0.gem Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-sshfs-1.2.0.gem' plugin. This can take a few minutes... Installed the plugin 'vagrant-sshfs (1.2.0)'! [rob at rawbdor plugins]$ vagrant plugin list landrush-ip (0.2.3) rubydns (0.8.5) win32-process (0.8.3) landrush (1.2.0.dev) - Version Constraint: 1.2.0.dev rubyzip (1.2.0) vagrant-libvirt (0.0.35, system) vagrant-registration (1.2.3) - Version Constraint: 1.2.3 vagrant-service-manager (1.4.0.dev) - Version Constraint: 1.4.0.dev vagrant-sshfs (1.2.0) - Version Constraint: 1.2.0 Obviously these shouldn't all be installed as plugins, but I don't know how else to get the cdk up and running? The CDK will not start with all these things which I assume are not vagrant plugins being installed as plugins... [rob at rawbdor rhel-ose]$ vagrant up Vagrant failed to initialize at a very early stage: The plugins failed to load properly. The error message given is shown below. unable to resolve type 'uintptr_t' I've seen this error before... and I know I have to remove win32-process as a plugin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prkumar at redhat.com Wed Aug 24 05:33:50 2016 From: prkumar at redhat.com (Praveen Kumar) Date: Wed, 24 Aug 2016 11:03:50 +0530 Subject: [Devtools] Not sure how to test new CDK, can't install plugins In-Reply-To: References: Message-ID: Hi Rob, After having discussion with you on IRC I tried to reproduce what you pointed out here. So to make sure I have a sane enviorment to test out stuff I used a fedora 22 container (this is minimal and have no dependencies at all installed) I followed required steps which we discussed also and able to install all the local plugin successfully on f22. I created a paste[0] which have all the steps I followed so I assume you have some issue with your system. I am planning to create same paste for RHEL/CentOS (in container env) so we make sure that steps which we have in document should work as expected. [0] https://paste.fedoraproject.org/413139/14720163/ On Wed, Aug 24, 2016 at 10:17 AM, Robert Stryker wrote: > Hey all: > > I may have made complaints about this before in the past, but I'm really > baffled how to install the vagrant plugins that come bundled in the cdk.zip, > and nothing really seems to work for me... or at least, nothing that I would > consider normal. > > It seems any time i try to install one of the bundled plugins, it just > complains I need to go find its dependencies. I don't know if the > dependencies are also plugins or not, but I have to install them, and, in > some cases, uninstall them afterwards. > > For example trying to install vagrant-sshfs tells me i must install > win32-process first. But win32-process isn't an actual vagrant plugin...... > So I have to vagrant plugin install win32-process, then vagrant plugin > install the local gem for vagrant-sshfs, then vagrant plugin uninstall > win32-process. > > Is this intentional? Is this a known defect? Is there any way around it? > > [rob at rawbdor rhel-ose]$ uname -a > Linux rawbdor 4.4.14-200.fc22.x86_64 #1 SMP Fri Jun 24 21:19:33 UTC 2016 > x86_64 x86_64 x86_64 GNU/Linux > > [rob at rawbdor rhel-ose]$ vagrant version > Installed Version: 1.7.2 > Latest Version: 1.8.5 > > [root at rawbdor rhel-ose]$ dnf install vagrant > Package vagrant-1.7.2-12.fc22.noarch is already installed, skipping. > Dependencies resolved. > Nothing to do. > Complete! > > [root at rawbdor rhel-ose]$ dnf update vagrant > Dependencies resolved. > Nothing to do. > Complete! > > > > Stream-of-conscious too much info below... Don't bother reading it unless > you want to see my shell log, basically. > > [rob at rawbdor plugins]$ vagrant plugin list > vagrant-libvirt (0.0.35, system) > vagrant-registration (1.2.3) > > So then I look at what plugins I need to install: > > [rob at rawbdor plugins]$ ls *.gem > landrush-1.2.0.dev.gem > vagrant-service-manager-1.4.0.dev.gem > vagrant-registration-1.2.3.gem > vagrant-sshfs-1.2.0.gem > > Ok... seems reasonable... so lets start with landrush. > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem > > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' > requires 'rubydns (= 0.8.5)' (Gem::UnsatisfiableDependencyError) > ... etc etc etc... > > > So then I try to install rubydns... but I know this isn't a plugin or it > would be listed in the list of required plugins? > > [rob at rawbdor plugins]$ gem install rubydns > ERROR: Could not find a valid gem 'rubydns' (>= 0) in any repository > > Ok... so it can't be found... um... > > [rob at rawbdor plugins]$ vagrant plugin install rubydns > Installing the 'rubydns' plugin. This can take a few minutes... > Installed the plugin 'rubydns (0.8.5)'! > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem > > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' > requires 'landrush-ip (~> 0.2.3)' (Gem::UnsatisfiableDependencyError) > etc etc etc... > > So... now I have to install landrush-ip? > > [rob at rawbdor plugins]$ gem install landrush-ip > ERROR: Could not find a valid gem 'landrush-ip' (>= 0) in any repository > > I can repeat the same procedure.... I guess... but it feels very wrong to > me. > > [rob at rawbdor plugins]$ vagrant plugin install landrush-ip > Installing the 'landrush-ip' plugin. This can take a few minutes... > Installed the plugin 'landrush-ip (0.2.3)'! > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem > > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' > requires 'win32-process (>= 0)' (Gem::UnsatisfiableDependencyError) > > Ok... so now I need to install win32-process > > [rob at rawbdor plugins]$ vagrant plugin install win32-process > Installing the 'win32-process' plugin. This can take a few minutes... > Installed the plugin 'win32-process (0.8.3)'! > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > Installed the plugin 'landrush (1.2.0.dev)'! > > Great... so now........ > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-registration-1.2.3.gem > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-registration-1.2.3.gem' > plugin. This can take a few minutes... > Installed the plugin 'vagrant-registration (1.2.3)'! > > Ok... that went fine... maybe that was the only problem? > > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' > plugin. This can take a few minutes... > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: 'vagrant-service-manager > (= 1.4.0.dev)' requires 'rubyzip (~> 1.2.0)' > (Gem::UnsatisfiableDependencyError) > > [rob at rawbdor plugins]$ vagrant plugin install rubyzip > Installing the 'rubyzip' plugin. This can take a few minutes... > Installed the plugin 'rubyzip (1.2.0)'! > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' > plugin. This can take a few minutes... > Installed the plugin 'vagrant-service-manager (1.4.0.dev)'! > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-sshfs-1.2.0.gem > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-sshfs-1.2.0.gem' > plugin. This can take a few minutes... > Installed the plugin 'vagrant-sshfs (1.2.0)'! > > [rob at rawbdor plugins]$ vagrant plugin list > landrush-ip (0.2.3) > rubydns (0.8.5) > win32-process (0.8.3) > landrush (1.2.0.dev) > - Version Constraint: 1.2.0.dev > rubyzip (1.2.0) > vagrant-libvirt (0.0.35, system) > vagrant-registration (1.2.3) > - Version Constraint: 1.2.3 > vagrant-service-manager (1.4.0.dev) > - Version Constraint: 1.4.0.dev > vagrant-sshfs (1.2.0) > - Version Constraint: 1.2.0 > > Obviously these shouldn't all be installed as plugins, but I don't know how > else to get the cdk up and running? > > The CDK will not start with all these things which I assume are not vagrant > plugins being installed as plugins... > > [rob at rawbdor rhel-ose]$ vagrant up > Vagrant failed to initialize at a very early stage: > > The plugins failed to load properly. The error message given is > shown below. > > unable to resolve type 'uintptr_t' > > I've seen this error before... and I know I have to remove win32-process as > a plugin. > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen From prkumar at redhat.com Wed Aug 24 05:36:04 2016 From: prkumar at redhat.com (Praveen Kumar) Date: Wed, 24 Aug 2016 11:06:04 +0530 Subject: [Devtools] Not sure how to test new CDK, can't install plugins In-Reply-To: References: Message-ID: On Wed, Aug 24, 2016 at 11:03 AM, Praveen Kumar wrote: > Hi Rob, > > After having discussion with you on IRC I tried to reproduce what you > pointed out here. So to make sure I have a sane enviorment to test out > stuff I used a fedora 22 container (this is minimal and have no > dependencies at all installed) > > I followed required steps which we discussed also and able to install > all the local plugin successfully on f22. I created a paste[0] which > have all the steps I followed so I assume you have some issue with > your system. I am planning to create same paste for RHEL/CentOS (in > container env) so we make sure that steps which we have in document > should work as expected. > > [0] https://paste.fedoraproject.org/413139/14720163/ Just to add all the ruby packages which are installed and vagrant plugins in the system[1] [1] https://paste.fedoraproject.org/413145/16911147/ > > On Wed, Aug 24, 2016 at 10:17 AM, Robert Stryker wrote: >> Hey all: >> >> I may have made complaints about this before in the past, but I'm really >> baffled how to install the vagrant plugins that come bundled in the cdk.zip, >> and nothing really seems to work for me... or at least, nothing that I would >> consider normal. >> >> It seems any time i try to install one of the bundled plugins, it just >> complains I need to go find its dependencies. I don't know if the >> dependencies are also plugins or not, but I have to install them, and, in >> some cases, uninstall them afterwards. >> >> For example trying to install vagrant-sshfs tells me i must install >> win32-process first. But win32-process isn't an actual vagrant plugin...... >> So I have to vagrant plugin install win32-process, then vagrant plugin >> install the local gem for vagrant-sshfs, then vagrant plugin uninstall >> win32-process. >> >> Is this intentional? Is this a known defect? Is there any way around it? >> >> [rob at rawbdor rhel-ose]$ uname -a >> Linux rawbdor 4.4.14-200.fc22.x86_64 #1 SMP Fri Jun 24 21:19:33 UTC 2016 >> x86_64 x86_64 x86_64 GNU/Linux >> >> [rob at rawbdor rhel-ose]$ vagrant version >> Installed Version: 1.7.2 >> Latest Version: 1.8.5 >> >> [root at rawbdor rhel-ose]$ dnf install vagrant >> Package vagrant-1.7.2-12.fc22.noarch is already installed, skipping. >> Dependencies resolved. >> Nothing to do. >> Complete! >> >> [root at rawbdor rhel-ose]$ dnf update vagrant >> Dependencies resolved. >> Nothing to do. >> Complete! >> >> >> >> Stream-of-conscious too much info below... Don't bother reading it unless >> you want to see my shell log, basically. >> >> [rob at rawbdor plugins]$ vagrant plugin list >> vagrant-libvirt (0.0.35, system) >> vagrant-registration (1.2.3) >> >> So then I look at what plugins I need to install: >> >> [rob at rawbdor plugins]$ ls *.gem >> landrush-1.2.0.dev.gem >> vagrant-service-manager-1.4.0.dev.gem >> vagrant-registration-1.2.3.gem >> vagrant-sshfs-1.2.0.gem >> >> Ok... seems reasonable... so lets start with landrush. >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem >> >> Installing the >> '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' >> plugin. This can take a few minutes... >> >> /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in >> `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' >> requires 'rubydns (= 0.8.5)' (Gem::UnsatisfiableDependencyError) >> ... etc etc etc... >> >> >> So then I try to install rubydns... but I know this isn't a plugin or it >> would be listed in the list of required plugins? >> >> [rob at rawbdor plugins]$ gem install rubydns >> ERROR: Could not find a valid gem 'rubydns' (>= 0) in any repository >> >> Ok... so it can't be found... um... >> >> [rob at rawbdor plugins]$ vagrant plugin install rubydns >> Installing the 'rubydns' plugin. This can take a few minutes... >> Installed the plugin 'rubydns (0.8.5)'! >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem >> >> Installing the >> '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' >> plugin. This can take a few minutes... >> /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in >> `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' >> requires 'landrush-ip (~> 0.2.3)' (Gem::UnsatisfiableDependencyError) >> etc etc etc... >> >> So... now I have to install landrush-ip? >> >> [rob at rawbdor plugins]$ gem install landrush-ip >> ERROR: Could not find a valid gem 'landrush-ip' (>= 0) in any repository >> >> I can repeat the same procedure.... I guess... but it feels very wrong to >> me. >> >> [rob at rawbdor plugins]$ vagrant plugin install landrush-ip >> Installing the 'landrush-ip' plugin. This can take a few minutes... >> Installed the plugin 'landrush-ip (0.2.3)'! >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem >> >> Installing the >> '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' >> plugin. This can take a few minutes... >> /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in >> `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' >> requires 'win32-process (>= 0)' (Gem::UnsatisfiableDependencyError) >> >> Ok... so now I need to install win32-process >> >> [rob at rawbdor plugins]$ vagrant plugin install win32-process >> Installing the 'win32-process' plugin. This can take a few minutes... >> Installed the plugin 'win32-process (0.8.3)'! >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem >> Installing the >> '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' >> plugin. This can take a few minutes... >> Installed the plugin 'landrush (1.2.0.dev)'! >> >> Great... so now........ >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-registration-1.2.3.gem >> Installing the >> '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-registration-1.2.3.gem' >> plugin. This can take a few minutes... >> Installed the plugin 'vagrant-registration (1.2.3)'! >> >> Ok... that went fine... maybe that was the only problem? >> >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem >> Installing the >> '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' >> plugin. This can take a few minutes... >> /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in >> `resolve_for_zero': Unable to resolve dependency: 'vagrant-service-manager >> (= 1.4.0.dev)' requires 'rubyzip (~> 1.2.0)' >> (Gem::UnsatisfiableDependencyError) >> >> [rob at rawbdor plugins]$ vagrant plugin install rubyzip >> Installing the 'rubyzip' plugin. This can take a few minutes... >> Installed the plugin 'rubyzip (1.2.0)'! >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem >> Installing the >> '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' >> plugin. This can take a few minutes... >> Installed the plugin 'vagrant-service-manager (1.4.0.dev)'! >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-sshfs-1.2.0.gem >> Installing the >> '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-sshfs-1.2.0.gem' >> plugin. This can take a few minutes... >> Installed the plugin 'vagrant-sshfs (1.2.0)'! >> >> [rob at rawbdor plugins]$ vagrant plugin list >> landrush-ip (0.2.3) >> rubydns (0.8.5) >> win32-process (0.8.3) >> landrush (1.2.0.dev) >> - Version Constraint: 1.2.0.dev >> rubyzip (1.2.0) >> vagrant-libvirt (0.0.35, system) >> vagrant-registration (1.2.3) >> - Version Constraint: 1.2.3 >> vagrant-service-manager (1.4.0.dev) >> - Version Constraint: 1.4.0.dev >> vagrant-sshfs (1.2.0) >> - Version Constraint: 1.2.0 >> >> Obviously these shouldn't all be installed as plugins, but I don't know how >> else to get the cdk up and running? >> >> The CDK will not start with all these things which I assume are not vagrant >> plugins being installed as plugins... >> >> [rob at rawbdor rhel-ose]$ vagrant up >> Vagrant failed to initialize at a very early stage: >> >> The plugins failed to load properly. The error message given is >> shown below. >> >> unable to resolve type 'uintptr_t' >> >> I've seen this error before... and I know I have to remove win32-process as >> a plugin. >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> > > > > -- > Praveen Kumar > https://fedoraproject.org/wiki/User:Kumarpraveen -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen From lmohanty at redhat.com Wed Aug 24 09:37:17 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Wed, 24 Aug 2016 15:07:17 +0530 Subject: [Devtools] Not sure how to test new CDK, can't install plugins In-Reply-To: References: Message-ID: <3739684c-3a75-bf54-27f1-11305ab14612@redhat.com> On 08/24/2016 10:17 AM, Robert Stryker wrote: > Hey all: > > I may have made complaints about this before in the past, but I'm > really baffled how to install the vagrant plugins that come bundled in > the cdk.zip, and nothing really seems to work for me... or at least, > nothing that I would consider normal. > > It seems any time i try to install one of the bundled plugins, it just > complains I need to go find its dependencies. I don't know if the > dependencies are also plugins or not, but I have to install them, and, > in some cases, uninstall them afterwards. > > For example trying to install vagrant-sshfs tells me i must install > win32-process first. But win32-process isn't an actual vagrant > plugin...... So I have to vagrant plugin install win32-process, then > vagrant plugin install the local gem for vagrant-sshfs, then vagrant > plugin uninstall win32-process. > > Is this intentional? Is this a known defect? Is there any way around it? Hi Rob, The issue seems to be local to your system and not a generic issue as we have tested/installed vagrant-sshfs and landrush on Fedora 23 machines multiple times. "vagrant plugin install vagrant-sshfs" should download and install win32-process. User does not need to install in separately. I would strongly recommend you to move to a newer version of Vagrant i.e. 1.8.1. -Lala > > [rob at rawbdor rhel-ose]$ uname -a > Linux rawbdor 4.4.14-200.fc22.x86_64 #1 SMP Fri Jun 24 21:19:33 UTC > 2016 x86_64 x86_64 x86_64 GNU/Linux > > [rob at rawbdor rhel-ose]$ vagrant version > Installed Version: 1.7.2 > Latest Version: 1.8.5 > > [root at rawbdor rhel-ose]$ dnf install vagrant > Package vagrant-1.7.2-12.fc22.noarch is already installed, skipping. > Dependencies resolved. > Nothing to do. > Complete! > > [root at rawbdor rhel-ose]$ dnf update vagrant > Dependencies resolved. > Nothing to do. > Complete! > > > > Stream-of-conscious too much info below... Don't bother reading it > unless you want to see my shell log, basically. > > [rob at rawbdor plugins]$ vagrant plugin list > vagrant-libvirt (0.0.35, system) > vagrant-registration (1.2.3) > > So then I look at what plugins I need to install: > > [rob at rawbdor plugins]$ ls *.gem > landrush-1.2.0.dev.gem > vagrant-service-manager-1.4.0.dev.gem > vagrant-registration-1.2.3.gem > vagrant-sshfs-1.2.0.gem > > Ok... seems reasonable... so lets start with landrush. > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem > > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: 'landrush (= > 1.2.0.dev)' requires 'rubydns (= 0.8.5)' > (Gem::UnsatisfiableDependencyError) > ... etc etc etc... > > > So then I try to install rubydns... but I know this isn't a plugin or > it would be listed in the list of required plugins? > > [rob at rawbdor plugins]$ gem install rubydns > ERROR: Could not find a valid gem 'rubydns' (>= 0) in any repository > > Ok... so it can't be found... um... > > [rob at rawbdor plugins]$ vagrant plugin install rubydns > Installing the 'rubydns' plugin. This can take a few minutes... > Installed the plugin 'rubydns (0.8.5)'! > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem > > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: 'landrush (= > 1.2.0.dev)' requires 'landrush-ip (~> 0.2.3)' > (Gem::UnsatisfiableDependencyError) > etc etc etc... > > So... now I have to install landrush-ip? > > [rob at rawbdor plugins]$ gem install landrush-ip > ERROR: Could not find a valid gem 'landrush-ip' (>= 0) in any repository > > I can repeat the same procedure.... I guess... but it feels very wrong > to me. > > [rob at rawbdor plugins]$ vagrant plugin install landrush-ip > Installing the 'landrush-ip' plugin. This can take a few minutes... > Installed the plugin 'landrush-ip (0.2.3)'! > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem > > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' > requires 'win32-process (>= 0)' (Gem::UnsatisfiableDependencyError) > > Ok... so now I need to install win32-process > > [rob at rawbdor plugins]$ vagrant plugin install win32-process > Installing the 'win32-process' plugin. This can take a few minutes... > Installed the plugin 'win32-process (0.8.3)'! > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > Installed the plugin 'landrush (1.2.0.dev)'! > > Great... so now........ > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-registration-1.2.3.gem > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-registration-1.2.3.gem' > plugin. This can take a few minutes... > Installed the plugin 'vagrant-registration (1.2.3)'! > > Ok... that went fine... maybe that was the only problem? > > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' > plugin. This can take a few minutes... > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: > 'vagrant-service-manager (= 1.4.0.dev)' requires 'rubyzip (~> 1.2.0)' > (Gem::UnsatisfiableDependencyError) > > [rob at rawbdor plugins]$ vagrant plugin install rubyzip > Installing the 'rubyzip' plugin. This can take a few minutes... > Installed the plugin 'rubyzip (1.2.0)'! > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' > plugin. This can take a few minutes... > Installed the plugin 'vagrant-service-manager (1.4.0.dev)'! > > [rob at rawbdor plugins]$ vagrant plugin install > /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-sshfs-1.2.0.gem > Installing the > '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-sshfs-1.2.0.gem' > plugin. This can take a few minutes... > Installed the plugin 'vagrant-sshfs (1.2.0)'! > > [rob at rawbdor plugins]$ vagrant plugin list > landrush-ip (0.2.3) > rubydns (0.8.5) > win32-process (0.8.3) > landrush (1.2.0.dev) > - Version Constraint: 1.2.0.dev > rubyzip (1.2.0) > vagrant-libvirt (0.0.35, system) > vagrant-registration (1.2.3) > - Version Constraint: 1.2.3 > vagrant-service-manager (1.4.0.dev) > - Version Constraint: 1.4.0.dev > vagrant-sshfs (1.2.0) > - Version Constraint: 1.2.0 > > Obviously these shouldn't all be installed as plugins, but I don't > know how else to get the cdk up and running? > > The CDK will not start with all these things which I assume are not > vagrant plugins being installed as plugins... > > [rob at rawbdor rhel-ose]$ vagrant up > Vagrant failed to initialize at a very early stage: > > The plugins failed to load properly. The error message given is > shown below. > > unable to resolve type 'uintptr_t' > > I've seen this error before... and I know I have to remove > win32-process as a plugin. > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From rstryker at redhat.com Wed Aug 24 18:09:30 2016 From: rstryker at redhat.com (Robert Stryker) Date: Wed, 24 Aug 2016 14:09:30 -0400 Subject: [Devtools] Not sure how to test new CDK, can't install plugins In-Reply-To: <3739684c-3a75-bf54-27f1-11305ab14612@redhat.com> References: <3739684c-3a75-bf54-27f1-11305ab14612@redhat.com> Message-ID: Hi Lala: Unfortunately a newer vagrant isn't available for me without upgradign OS... which I've been delaying. We eventually found the cause, and it was that no ruby repositories were available. Thanks for the help though. On Wed, Aug 24, 2016 at 5:37 AM, Lalatendu Mohanty wrote: > On 08/24/2016 10:17 AM, Robert Stryker wrote: > > Hey all: > > I may have made complaints about this before in the past, but I'm really > baffled how to install the vagrant plugins that come bundled in the > cdk.zip, and nothing really seems to work for me... or at least, nothing > that I would consider normal. > > It seems any time i try to install one of the bundled plugins, it just > complains I need to go find its dependencies. I don't know if the > dependencies are also plugins or not, but I have to install them, and, in > some cases, uninstall them afterwards. > > For example trying to install vagrant-sshfs tells me i must install > win32-process first. But win32-process isn't an actual vagrant > plugin...... So I have to vagrant plugin install win32-process, then > vagrant plugin install the local gem for vagrant-sshfs, then vagrant > plugin uninstall win32-process. > > Is this intentional? Is this a known defect? Is there any way around it? > > > Hi Rob, > > The issue seems to be local to your system and not a generic issue as we > have tested/installed vagrant-sshfs and landrush on Fedora 23 machines > multiple times. "vagrant plugin install vagrant-sshfs" should download and > install win32-process. User does not need to install in separately. > > I would strongly recommend you to move to a newer version of Vagrant i.e. > 1.8.1. > > -Lala > > > [rob at rawbdor rhel-ose]$ uname -a > Linux rawbdor 4.4.14-200.fc22.x86_64 #1 SMP Fri Jun 24 21:19:33 UTC 2016 > x86_64 x86_64 x86_64 GNU/Linux > > [rob at rawbdor rhel-ose]$ vagrant version > Installed Version: 1.7.2 > Latest Version: 1.8.5 > > [root at rawbdor rhel-ose]$ dnf install vagrant > Package vagrant-1.7.2-12.fc22.noarch is already installed, skipping. > Dependencies resolved. > Nothing to do. > Complete! > > [root at rawbdor rhel-ose]$ dnf update vagrant > Dependencies resolved. > Nothing to do. > Complete! > > > > Stream-of-conscious too much info below... Don't bother reading it unless > you want to see my shell log, basically. > > [rob at rawbdor plugins]$ vagrant plugin list > vagrant-libvirt (0.0.35, system) > vagrant-registration (1.2.3) > > So then I look at what plugins I need to install: > > [rob at rawbdor plugins]$ ls *.gem > landrush-1.2.0.dev.gem > vagrant-service-manager-1.4.0.dev.gem > vagrant-registration-1.2.3.gem > vagrant-sshfs-1.2.0.gem > > Ok... seems reasonable... so lets start with landrush. > > [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/ > 20160823/cdk/plugins/landrush-1.2.0.dev.gem > > Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' > requires 'rubydns (= 0.8.5)' (Gem::UnsatisfiableDependencyError) > ... etc etc etc... > > > So then I try to install rubydns... but I know this isn't a plugin or it > would be listed in the list of required plugins? > > [rob at rawbdor plugins]$ gem install rubydns > ERROR: Could not find a valid gem 'rubydns' (>= 0) in any repository > > Ok... so it can't be found... um... > > [rob at rawbdor plugins]$ vagrant plugin install rubydns > Installing the 'rubydns' plugin. This can take a few minutes... > Installed the plugin 'rubydns (0.8.5)'! > > [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/ > 20160823/cdk/plugins/landrush-1.2.0.dev.gem > > Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' > requires 'landrush-ip (~> 0.2.3)' (Gem::UnsatisfiableDependencyError) > etc etc etc... > > So... now I have to install landrush-ip? > > [rob at rawbdor plugins]$ gem install landrush-ip > ERROR: Could not find a valid gem 'landrush-ip' (>= 0) in any repository > > I can repeat the same procedure.... I guess... but it feels very wrong to > me. > > [rob at rawbdor plugins]$ vagrant plugin install landrush-ip > Installing the 'landrush-ip' plugin. This can take a few minutes... > Installed the plugin 'landrush-ip (0.2.3)'! > > [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/ > 20160823/cdk/plugins/landrush-1.2.0.dev.gem > > Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' > requires 'win32-process (>= 0)' (Gem::UnsatisfiableDependencyError) > > Ok... so now I need to install win32-process > > [rob at rawbdor plugins]$ vagrant plugin install win32-process > Installing the 'win32-process' plugin. This can take a few minutes... > Installed the plugin 'win32-process (0.8.3)'! > > [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/ > 20160823/cdk/plugins/landrush-1.2.0.dev.gem > Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem' > plugin. This can take a few minutes... > Installed the plugin 'landrush (1.2.0.dev)'! > > Great... so now........ > > [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/ > 20160823/cdk/plugins/vagrant-registration-1.2.3.gem > Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-registration-1.2.3.gem' > plugin. This can take a few minutes... > Installed the plugin 'vagrant-registration (1.2.3)'! > > Ok... that went fine... maybe that was the only problem? > > > [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/ > 20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem > Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' > plugin. This can take a few minutes... > /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in > `resolve_for_zero': Unable to resolve dependency: 'vagrant-service-manager > (= 1.4.0.dev)' requires 'rubyzip (~> 1.2.0)' (Gem:: > UnsatisfiableDependencyError) > > [rob at rawbdor plugins]$ vagrant plugin install rubyzip > Installing the 'rubyzip' plugin. This can take a few minutes... > Installed the plugin 'rubyzip (1.2.0)'! > [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/ > 20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem > Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' > plugin. This can take a few minutes... > Installed the plugin 'vagrant-service-manager (1.4.0.dev)'! > > [rob at rawbdor plugins]$ vagrant plugin install /home/rob/Downloads/cdk/ > 20160823/cdk/plugins/vagrant-sshfs-1.2.0.gem > Installing the '/home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-sshfs-1.2.0.gem' > plugin. This can take a few minutes... > Installed the plugin 'vagrant-sshfs (1.2.0)'! > > [rob at rawbdor plugins]$ vagrant plugin list > landrush-ip (0.2.3) > rubydns (0.8.5) > win32-process (0.8.3) > landrush (1.2.0.dev) > - Version Constraint: 1.2.0.dev > rubyzip (1.2.0) > vagrant-libvirt (0.0.35, system) > vagrant-registration (1.2.3) > - Version Constraint: 1.2.3 > vagrant-service-manager (1.4.0.dev) > - Version Constraint: 1.4.0.dev > vagrant-sshfs (1.2.0) > - Version Constraint: 1.2.0 > > Obviously these shouldn't all be installed as plugins, but I don't know > how else to get the cdk up and running? > > The CDK will not start with all these things which I assume are not > vagrant plugins being installed as plugins... > > [rob at rawbdor rhel-ose]$ vagrant up > Vagrant failed to initialize at a very early stage: > > The plugins failed to load properly. The error message given is > shown below. > > unable to resolve type 'uintptr_t' > > I've seen this error before... and I know I have to remove win32-process > as a plugin. > > > _______________________________________________ > Devtools mailing listDevtools at redhat.comhttps://www.redhat.com/mailman/listinfo/devtools > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdyson at redhat.com Wed Aug 24 19:10:12 2016 From: jdyson at redhat.com (Jimmi Dyson) Date: Wed, 24 Aug 2016 20:10:12 +0100 Subject: [Devtools] Introducing 'kubeshift' the OpenShift / Kubernetes Python API library In-Reply-To: References: <20160823200328.GA1@ac8aba16ced7> <16e3885b-9e25-7731-6424-560816d87be4@dustymabe.com> Message-ID: On 24 August 2016 at 03:37, Andrew Lee Rubinger wrote: > > > On Tue, Aug 23, 2016 at 9:43 PM, Dusty Mabe wrote: >> >> >> >> On 08/23/2016 04:03 PM, Charlie Drage wrote: >> > Hey all! >> > >> > The work we've done to communicate with both OpenShift and Kubernetes >> > via their respective APIs has been forked from the Atomic App project >> > into it's own separate library! >> > >> > I've made the repo public at https://github.com/cdrage/kubeshift >> > please feel free to star / fork the project! >> > >> > There's still a lot of things to do such as creating the rpm, deb as >> > well as publishing it to pypi. >> > >> >> Nice work charlie. Should we call it py-kubeshift or something like >> that to help better denote the python roots? > > > +1; we also have at least 2 Java APIs from the OpenShift team and from > Fabric8 to similar aims. No we only have one: the OpenShift one is an impostor :-b > > S, > ALR > >> >> >> Dusty >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools > > > > > -- > Red Hat Developer Programs Architecture > @ALRubinger > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > From rhopp at redhat.com Thu Aug 25 05:56:24 2016 From: rhopp at redhat.com (Radim Hopp) Date: Thu, 25 Aug 2016 07:56:24 +0200 Subject: [Devtools] Not sure how to test new CDK, can't install plugins In-Reply-To: References: <3739684c-3a75-bf54-27f1-11305ab14612@redhat.com> Message-ID: Just FYI: CDK cannot be started with libvirt provider on F24 because of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1368745 Solution to that bug is already in update repositories and I just verified, that with that update to selinux-policy-targeted it works. Radim On Wed, Aug 24, 2016 at 8:09 PM, Robert Stryker wrote: > Hi Lala: > Unfortunately a newer vagrant isn't available for me without upgradign > OS... which I've been delaying. > > We eventually found the cause, and it was that no ruby repositories were > available. Thanks for the help though. > > On Wed, Aug 24, 2016 at 5:37 AM, Lalatendu Mohanty > wrote: > >> On 08/24/2016 10:17 AM, Robert Stryker wrote: >> >> Hey all: >> >> I may have made complaints about this before in the past, but I'm really >> baffled how to install the vagrant plugins that come bundled in the >> cdk.zip, and nothing really seems to work for me... or at least, nothing >> that I would consider normal. >> >> It seems any time i try to install one of the bundled plugins, it just >> complains I need to go find its dependencies. I don't know if the >> dependencies are also plugins or not, but I have to install them, and, in >> some cases, uninstall them afterwards. >> >> For example trying to install vagrant-sshfs tells me i must install >> win32-process first. But win32-process isn't an actual vagrant >> plugin...... So I have to vagrant plugin install win32-process, then >> vagrant plugin install the local gem for vagrant-sshfs, then vagrant >> plugin uninstall win32-process. >> >> Is this intentional? Is this a known defect? Is there any way around it? >> >> >> Hi Rob, >> >> The issue seems to be local to your system and not a generic issue as we >> have tested/installed vagrant-sshfs and landrush on Fedora 23 machines >> multiple times. "vagrant plugin install vagrant-sshfs" should download and >> install win32-process. User does not need to install in separately. >> >> I would strongly recommend you to move to a newer version of Vagrant >> i.e. 1.8.1. >> >> -Lala >> >> >> [rob at rawbdor rhel-ose]$ uname -a >> Linux rawbdor 4.4.14-200.fc22.x86_64 #1 SMP Fri Jun 24 21:19:33 UTC 2016 >> x86_64 x86_64 x86_64 GNU/Linux >> >> [rob at rawbdor rhel-ose]$ vagrant version >> Installed Version: 1.7.2 >> Latest Version: 1.8.5 >> >> [root at rawbdor rhel-ose]$ dnf install vagrant >> Package vagrant-1.7.2-12.fc22.noarch is already installed, skipping. >> Dependencies resolved. >> Nothing to do. >> Complete! >> >> [root at rawbdor rhel-ose]$ dnf update vagrant >> Dependencies resolved. >> Nothing to do. >> Complete! >> >> >> >> Stream-of-conscious too much info below... Don't bother reading it unless >> you want to see my shell log, basically. >> >> [rob at rawbdor plugins]$ vagrant plugin list >> vagrant-libvirt (0.0.35, system) >> vagrant-registration (1.2.3) >> >> So then I look at what plugins I need to install: >> >> [rob at rawbdor plugins]$ ls *.gem >> landrush-1.2.0.dev.gem >> vagrant-service-manager-1.4.0.dev.gem >> vagrant-registration-1.2.3.gem >> vagrant-sshfs-1.2.0.gem >> >> Ok... seems reasonable... so lets start with landrush. >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem >> >> Installing the '/home/rob/Downloads/cdk/20160 >> 823/cdk/plugins/landrush-1.2.0.dev.gem' plugin. This can take a few >> minutes... >> >> /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in >> `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' >> requires 'rubydns (= 0.8.5)' (Gem::UnsatisfiableDependencyError) >> ... etc etc etc... >> >> >> So then I try to install rubydns... but I know this isn't a plugin or it >> would be listed in the list of required plugins? >> >> [rob at rawbdor plugins]$ gem install rubydns >> ERROR: Could not find a valid gem 'rubydns' (>= 0) in any repository >> >> Ok... so it can't be found... um... >> >> [rob at rawbdor plugins]$ vagrant plugin install rubydns >> Installing the 'rubydns' plugin. This can take a few minutes... >> Installed the plugin 'rubydns (0.8.5)'! >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem >> >> Installing the '/home/rob/Downloads/cdk/20160 >> 823/cdk/plugins/landrush-1.2.0.dev.gem' plugin. This can take a few >> minutes... >> /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in >> `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' >> requires 'landrush-ip (~> 0.2.3)' (Gem::UnsatisfiableDependencyError) >> etc etc etc... >> >> So... now I have to install landrush-ip? >> >> [rob at rawbdor plugins]$ gem install landrush-ip >> ERROR: Could not find a valid gem 'landrush-ip' (>= 0) in any repository >> >> I can repeat the same procedure.... I guess... but it feels very wrong to >> me. >> >> [rob at rawbdor plugins]$ vagrant plugin install landrush-ip >> Installing the 'landrush-ip' plugin. This can take a few minutes... >> Installed the plugin 'landrush-ip (0.2.3)'! >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem >> >> Installing the '/home/rob/Downloads/cdk/20160 >> 823/cdk/plugins/landrush-1.2.0.dev.gem' plugin. This can take a few >> minutes... >> /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in >> `resolve_for_zero': Unable to resolve dependency: 'landrush (= 1.2.0.dev)' >> requires 'win32-process (>= 0)' (Gem::UnsatisfiableDependencyError) >> >> Ok... so now I need to install win32-process >> >> [rob at rawbdor plugins]$ vagrant plugin install win32-process >> Installing the 'win32-process' plugin. This can take a few minutes... >> Installed the plugin 'win32-process (0.8.3)'! >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/landrush-1.2.0.dev.gem >> Installing the '/home/rob/Downloads/cdk/20160 >> 823/cdk/plugins/landrush-1.2.0.dev.gem' plugin. This can take a few >> minutes... >> Installed the plugin 'landrush (1.2.0.dev)'! >> >> Great... so now........ >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-registr >> ation-1.2.3.gem >> Installing the '/home/rob/Downloads/cdk/20160 >> 823/cdk/plugins/vagrant-registration-1.2.3.gem' plugin. This can take a >> few minutes... >> Installed the plugin 'vagrant-registration (1.2.3)'! >> >> Ok... that went fine... maybe that was the only problem? >> >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service >> -manager-1.4.0.dev.gem >> Installing the '/home/rob/Downloads/cdk/20160 >> 823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' plugin. This can >> take a few minutes... >> /home/rob/.rvm/rubies/ruby-2.2.4/lib/ruby/site_ruby/2.2.0/rubygems/resolver.rb:439:in >> `resolve_for_zero': Unable to resolve dependency: 'vagrant-service-manager >> (= 1.4.0.dev)' requires 'rubyzip (~> 1.2.0)' (Gem::UnsatisfiableDependencyE >> rror) >> >> [rob at rawbdor plugins]$ vagrant plugin install rubyzip >> Installing the 'rubyzip' plugin. This can take a few minutes... >> Installed the plugin 'rubyzip (1.2.0)'! >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-service >> -manager-1.4.0.dev.gem >> Installing the '/home/rob/Downloads/cdk/20160 >> 823/cdk/plugins/vagrant-service-manager-1.4.0.dev.gem' plugin. This can >> take a few minutes... >> Installed the plugin 'vagrant-service-manager (1.4.0.dev)'! >> >> [rob at rawbdor plugins]$ vagrant plugin install >> /home/rob/Downloads/cdk/20160823/cdk/plugins/vagrant-sshfs-1.2.0.gem >> Installing the '/home/rob/Downloads/cdk/20160 >> 823/cdk/plugins/vagrant-sshfs-1.2.0.gem' plugin. This can take a few >> minutes... >> Installed the plugin 'vagrant-sshfs (1.2.0)'! >> >> [rob at rawbdor plugins]$ vagrant plugin list >> landrush-ip (0.2.3) >> rubydns (0.8.5) >> win32-process (0.8.3) >> landrush (1.2.0.dev) >> - Version Constraint: 1.2.0.dev >> rubyzip (1.2.0) >> vagrant-libvirt (0.0.35, system) >> vagrant-registration (1.2.3) >> - Version Constraint: 1.2.3 >> vagrant-service-manager (1.4.0.dev) >> - Version Constraint: 1.4.0.dev >> vagrant-sshfs (1.2.0) >> - Version Constraint: 1.2.0 >> >> Obviously these shouldn't all be installed as plugins, but I don't know >> how else to get the cdk up and running? >> >> The CDK will not start with all these things which I assume are not >> vagrant plugins being installed as plugins... >> >> [rob at rawbdor rhel-ose]$ vagrant up >> Vagrant failed to initialize at a very early stage: >> >> The plugins failed to load properly. The error message given is >> shown below. >> >> unable to resolve type 'uintptr_t' >> >> I've seen this error before... and I know I have to remove win32-process >> as a plugin. >> >> >> _______________________________________________ >> Devtools mailing listDevtools at redhat.comhttps://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 bgurung at redhat.com Thu Aug 25 15:12:01 2016 From: bgurung at redhat.com (Budh Gurung) Date: Thu, 25 Aug 2016 20:42:01 +0530 Subject: [Devtools] vagrant-service-manager version 1.3.0 release Message-ID: Hey All, We have released version 1.3.1 of vagrant-service-manager plugin. This release of the plugin includes a few bug fixes which improves how services are handled and the resulting user experience. Check here [1] to find the detailed CHANGELOG for the release. [1] https://github.com/projectatomic/vagrant-service-manager/releases/tag/v1.3.1 Regards, Budh Ram Gurung Software Engineer - Dev Tools -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Sat Aug 27 22:40:15 2016 From: bsutter at redhat.com (Burr Sutter) Date: Sat, 27 Aug 2016 18:40:15 -0400 Subject: [Devtools] launching eclipse from command line Message-ID: Does Eclipse have the capability/feature to be launched from a terminal session (Mac OSX or Windows) and auto-import the current working directory's project? I really like this feature of various "text editors" and Visual Studio Code allows me to type code . and it opens up the project as expected and I am ready to start typing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gercan at redhat.com Sat Aug 27 23:08:21 2016 From: gercan at redhat.com (Gorkem Ercan) Date: Sat, 27 Aug 2016 19:08:21 -0400 Subject: [Devtools] launching eclipse from command line In-Reply-To: References: Message-ID: I have not heard of such a feature but with so many in the community trying to change an aircraft carrier to a PT boat I would not be surprised it exists. OTOH I can offer a fresh binary for [1] if it is Java you are after. [1] https://github.com/gorkem/vscode-java ? Gorkem On 27 Aug 2016, at 18:40, Burr Sutter wrote: > Does Eclipse have the capability/feature to be launched from a > terminal > session (Mac OSX or Windows) and auto-import the current working > directory's project? > > I really like this feature of various "text editors" and Visual Studio > Code > allows me to type > code . > > and it opens up the project as expected and I am ready to start > typing. > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From bsutter at redhat.com Sat Aug 27 23:27:43 2016 From: bsutter at redhat.com (Burr Sutter) Date: Sat, 27 Aug 2016 19:27:43 -0400 Subject: [Devtools] launching eclipse from command line In-Reply-To: References: Message-ID: Would this take care of "auto imports" for me? Or getter/setter generation? On Sat, Aug 27, 2016 at 7:08 PM, Gorkem Ercan wrote: > > I have not heard of such a feature but with so many in the community > trying to change an aircraft carrier to a PT boat > I would not be surprised it exists. > > OTOH I can offer a fresh binary for [1] if it is Java you are after. > > [1] https://github.com/gorkem/vscode-java > ? > Gorkem > > > On 27 Aug 2016, at 18:40, Burr Sutter wrote: > > Does Eclipse have the capability/feature to be launched from a terminal >> session (Mac OSX or Windows) and auto-import the current working >> directory's project? >> >> I really like this feature of various "text editors" and Visual Studio >> Code >> allows me to type >> code . >> >> and it opens up the project as expected and I am ready to start typing. >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gercan at redhat.com Sat Aug 27 23:48:51 2016 From: gercan at redhat.com (Gorkem Ercan) Date: Sat, 27 Aug 2016 19:48:51 -0400 Subject: [Devtools] launching eclipse from command line In-Reply-To: References: Message-ID: <0AD1A099-258A-47B3-9945-C602389AF95D@redhat.com> The quick fixes for Java is not there yet, soon though. ? Gorkem On 27 Aug 2016, at 19:27, Burr Sutter wrote: > Would this take care of "auto imports" for me? Or getter/setter > generation? > > On Sat, Aug 27, 2016 at 7:08 PM, Gorkem Ercan > wrote: > >> >> I have not heard of such a feature but with so many in the community >> trying to change an aircraft carrier to a PT boat >> I would not be surprised it exists. >> >> OTOH I can offer a fresh binary for [1] if it is Java you are after. >> >> [1] https://github.com/gorkem/vscode-java >> ? >> Gorkem >> >> >> On 27 Aug 2016, at 18:40, Burr Sutter wrote: >> >> Does Eclipse have the capability/feature to be launched from a >> terminal >>> session (Mac OSX or Windows) and auto-import the current working >>> directory's project? >>> >>> I really like this feature of various "text editors" and Visual >>> Studio >>> Code >>> allows me to type >>> code . >>> >>> and it opens up the project as expected and I am ready to start >>> typing. >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> https://www.redhat.com/mailman/listinfo/devtools >>> >> From manderse at redhat.com Sun Aug 28 17:57:51 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Sun, 28 Aug 2016 19:57:51 +0200 Subject: [Devtools] launching eclipse from command line In-Reply-To: <0AD1A099-258A-47B3-9945-C602389AF95D@redhat.com> References: <0AD1A099-258A-47B3-9945-C602389AF95D@redhat.com> Message-ID: <4A3C55DF-C627-468D-AD14-74C1928EEBF6@redhat.com> Eclipse supports opening files passed on command line. If it does not work for folders we could make it work with the easy import feature Mickael contributed last year. Makes perfect sense and fit the improvements we've made the latter releases imo. P.s. On OS that supports it eclipse on cli will reuse same eclipse instance so its not stealing more and more resources :) /max /max https://about.me/maxandersen > On 28 Aug 2016, at 01:48, Gorkem Ercan wrote: > > > The quick fixes for Java is not there yet, soon though. > ? > Gorkem > >> On 27 Aug 2016, at 19:27, Burr Sutter wrote: >> >> Would this take care of "auto imports" for me? Or getter/setter generation? >> >>> On Sat, Aug 27, 2016 at 7:08 PM, Gorkem Ercan wrote: >>> >>> >>> I have not heard of such a feature but with so many in the community >>> trying to change an aircraft carrier to a PT boat >>> I would not be surprised it exists. >>> >>> OTOH I can offer a fresh binary for [1] if it is Java you are after. >>> >>> [1] https://github.com/gorkem/vscode-java >>> ? >>> Gorkem >>> >>> >>> On 27 Aug 2016, at 18:40, Burr Sutter wrote: >>> >>> Does Eclipse have the capability/feature to be launched from a terminal >>>> session (Mac OSX or Windows) and auto-import the current working >>>> directory's project? >>>> >>>> I really like this feature of various "text editors" and Visual Studio >>>> Code >>>> allows me to type >>>> code . >>>> >>>> and it opens up the project as expected and I am ready to start typing. >>>> _______________________________________________ >>>> 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 mistria at redhat.com Mon Aug 29 07:29:02 2016 From: mistria at redhat.com (Mickael Istria) Date: Mon, 29 Aug 2016 09:29:02 +0200 Subject: [Devtools] launching eclipse from command line In-Reply-To: References: Message-ID: <9c3eb09c-d6ed-786c-f86c-6d63623a649d@redhat.com> Thanks for your report, I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=500388 However, a first iteration will be that `eclipse .` will do things to correctly handle the current directory, making it happen on plan `eclipse` command will be another story. Is `eclipse .` good enough to you, or is it worth doing it only if we have it on plain `eclipse` ? -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmancini at redhat.com Mon Aug 29 13:46:35 2016 From: tmancini at redhat.com (Todd Mancini) Date: Mon, 29 Aug 2016 09:46:35 -0400 Subject: [Devtools] launching eclipse from command line In-Reply-To: <9c3eb09c-d6ed-786c-f86c-6d63623a649d@redhat.com> References: <9c3eb09c-d6ed-786c-f86c-6d63623a649d@redhat.com> Message-ID: It should be "eclipse ." We would not want this to be the behavior of "eclipse" On Mon, Aug 29, 2016 at 3:29 AM, Mickael Istria wrote: > Thanks for your report, I opened https://bugs.eclipse.org/bugs/ > show_bug.cgi?id=500388 > However, a first iteration will be that `eclipse .` will do things to > correctly handle the current directory, making it happen on plan `eclipse` > command will be another story. Is `eclipse .` good enough to you, or is it > worth doing it only if we have it on plain `eclipse` ? > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > _______________________________________________ > 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 Aug 29 13:54:23 2016 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 29 Aug 2016 09:54:23 -0400 Subject: [Devtools] launching eclipse from command line In-Reply-To: References: <9c3eb09c-d6ed-786c-f86c-6d63623a649d@redhat.com> Message-ID: It seems IntelliJ IDEA has this feature. In at least one demo, the presenter make it look so easy that I would assume everybody in the audience would want that IDE. It behaved just like a regular text editor. He went to start.spring.io downloaded the default project .zip and magically opened it, ready to go He created at least 4 microservice projects "from scratch", with each one launched from IDEA. It must be that IDEA was not eating memory for every project that was opened this way https://www.youtube.com/watch?v=byvbt7FJ7ts On Mon, Aug 29, 2016 at 9:46 AM, Todd Mancini wrote: > It should be "eclipse ." We would not want this to be the behavior of > "eclipse" > > On Mon, Aug 29, 2016 at 3:29 AM, Mickael Istria > wrote: > >> Thanks for your report, I opened https://bugs.eclipse.org/bugs/ >> show_bug.cgi?id=500388 >> However, a first iteration will be that `eclipse .` will do things to >> correctly handle the current directory, making it happen on plan `eclipse` >> command will be another story. Is `eclipse .` good enough to you, or is it >> worth doing it only if we have it on plain `eclipse` ? >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat >> My blog - My Tweets >> >> >> _______________________________________________ >> 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 mistria at redhat.com Mon Aug 29 14:05:46 2016 From: mistria at redhat.com (Mickael Istria) Date: Mon, 29 Aug 2016 16:05:46 +0200 Subject: [Devtools] launching eclipse from command line In-Reply-To: References: <9c3eb09c-d6ed-786c-f86c-6d63623a649d@redhat.com> Message-ID: <017934cb-bd61-6169-fd74-99f2184cce0a@redhat.com> On 08/29/2016 03:54 PM, Burr Sutter wrote: > It seems IntelliJ IDEA has this feature. In at least one demo, the > presenter make it look so easy that I would assume everybody in the > audience would want that IDE. It behaved just like a regular text > editor. > > He went to start.spring.io > downloaded the default project .zip > and magically opened it, ready to go Ok, so what you want is that Eclipse IDE can open zip files (not directories) and can be associated as default editor for them, with default behavior of importing them? (looking at your video at 23:30-something) Note that despite being cool in a demo, there are not many people who'd like their IDE to be associated as default software for zip files like it was done as a preparation of this demo. In Eclipse IDE, currently, the similar demo is * He went to start.spring.io * downloaded the default project .zip * In Eclipse, he did File > Import projects from filesystem..., selected the zip and pressed Finish and it worked. Please try it, and if you have any concern, track it somewhere so we have a chance to put it in JBoss Tools backlog. There is not much related to memory consumption is not much related to this user story. -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Mon Aug 29 19:21:03 2016 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 29 Aug 2016 15:21:03 -0400 Subject: [Devtools] launching eclipse from command line In-Reply-To: <017934cb-bd61-6169-fd74-99f2184cce0a@redhat.com> References: <9c3eb09c-d6ed-786c-f86c-6d63623a649d@redhat.com> <017934cb-bd61-6169-fd74-99f2184cce0a@redhat.com> Message-ID: On Mon, Aug 29, 2016 at 10:05 AM, Mickael Istria wrote: > On 08/29/2016 03:54 PM, Burr Sutter wrote: > > It seems IntelliJ IDEA has this feature. In at least one demo, the > presenter make it look so easy that I would assume everybody in the > audience would want that IDE. It behaved just like a regular text editor. > > He went to start.spring.io > downloaded the default project .zip > and magically opened it, ready to go > > Ok, so what you want is that Eclipse IDE can open zip files (not > directories) > directory is great .zip is handled via the magic of the browser it self - Safari can auto-unzip. > and can be associated as default editor for them, with default behavior of > importing them? (looking at your video at 23:30-something) > Note that despite being cool in a demo, there are not many people who'd > like their IDE to be associated as default software for zip files like it > was done as a preparation of this demo. > > In Eclipse IDE, currently, the similar demo is > * He went to start.spring.io > * downloaded the default project .zip > * In Eclipse, he did File > Import projects from filesystem..., selected > the zip and pressed Finish > and it worked. > There is another person doing this demo and he just "double clicks" on the pom.xml - apparently having an associate between pom.xml and IDE > Please try it, and if you have any concern, track it somewhere so we have > a chance to put it in JBoss Tools backlog. > > There is not much related to memory consumption is not much related to > this user story. > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > -------------- next part -------------- An HTML attachment was scrubbed... URL: