Re: [openstack-dev] [all] Bringing some DevOps love to Openstack
Yes, the aim is to get a vagrant-openstack provider plugin under Hashicorp's or Mitchellh's github account. Whether you call that official or blessed, doesn't really matter. In order for Vagrant to integrate with other tools such as Packer there needs to be a preferred plugin. Hopefully the owners of the other plugins will agree to deprecate theirs so that an end can be put to the fragmentation that has happened so far and direct contributors to the correct place. On 29 October 2014 10:04, Flavio Percoco fla...@redhat.com wrote: On 28/10/14 21:23 +0100, Philip Cheong wrote: Hi all, In preparation of the OpenStack Summit in Paris next week, I'm hoping to speak to some people in the OpenStack foundation about the benefits of a partnership with Hashicorp, who make fantastic tools like Vagrant and Packer (and others). As a n00b aspiring to become an OpenStack contributor, the variety of Vagrant devstack environments is pretty overwhelming. It appears to me that it really depends on what project you are contributing to, which denotes which devstack you should use. The ones I have tried take a long time (45 mins+) to provision from scratch. One aspect which I am acutely aware of is developer productivity and 45 minutes is a lot of time. Packer was designed to help alleviate bottleneck, and Vagrantcloud has inbuilt support for the versioning of Vagrant boxes. It would be a pretty straight forward exercise to use Packer to do a daily (or however often) build of a devstack box and upload it to Vagrantcloud for developers to download. With a decent internet connection that time would be significantly less than 45 minutes. I would really like to think that this community should also be able to come to a consensus over what to include in a standard devstack. That there currently seems to be many different flavours cannot help with issues of fragmentation between so many different moving parts to build an OpenStack environment. Another big issue that I hope to address with the foundation, is the integration of Hashicorp's tools with OpenStack. The various Vagrant plugins to add OpenStack as a provider is a mess. There is one specific for Rackspace who have a different Keystone API, and at least 3 others for the vanilla OpenStack: https://github.com/mitchellh/vagrant-rackspace https://github.com/ggiamarchi/vagrant-openstack-provider https://github.com/cloudbau/vagrant-openstack-plugin https://github.com/FlaPer87/vagrant-openstack I'm pretty sure mine doesn't even work any more, I don't even know ruby ;) I do see a value in having a vagrant-openstack provider but I don't think we should pick one and mark it as blessed. We're trying very hard to move away from 'blessing' projecs, at the very least depend less on it. Anyone should feel free to create the provider on stackforge and maintain it. What would be even better is to have Hashicorp itself creating and maintaining this provider. Cheers, Flavio The significance of not having an official provider, for one example, is when you use Packer to build an image in OpenStack and try to post-process it into a Vagrant box, it bombs with this error: == openstack: Running post-processor: vagrant Build 'openstack' errored: 1 error(s) occurred: * Post-processor failed: Unknown artifact type, can't build box: mitchellh.openstack Because Packer doesn't know what Vagrant expects the provider to be, as explained here. In my opinion this a pretty big issue holding back the wider acceptance of OpenStack. When I am at a customer and introduce them to tools like Vagrant and Packer and how well they work with AWS, I still avoid the conversation about OpenStack when I would really love to put them on our (Elastx's) public cloud. What say you? Could I get a +1 from those who see this as a worthwhile issue? Cheers, Phil. -- Philip Cheong Elastx | Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 870 814 twitter: @Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Philip Cheong* *Elastx *| Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 870 814 twitter: @Elastx https://twitter.com/Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Solum Design Session at OpenStack Summit
+1 Thanks for the heads up! See you there! On 29 October 2014 19:15, Lee Calcote (lecalcot) lecal...@cisco.com wrote: Noted. Looking forward to the face time. Lee On 10/29/14, 9:30 AM, Adrian Otto adrian.o...@rackspace.com wrote: Team, See below. For those of us attending the OpenStack Summit in Paris, please be sure to plan your schedule so you can attend this session. Thanks, Adrian Begin forwarded message: From: Chris Hoge ch...@openstack.org Subject: Solum Design Session at OpenStack Summit Date: October 22, 2014 at 11:09:55 AM PDT To: Adrian Otto adrian.o...@rackspace.com Hi, Here is the latest schedule information for the Solum Design Session at the OpenStack Summit. Thanks, Chris http://kilodesignsummit.sched.org/event/4e2033ced61b8dadf7a2db1aee6d8123 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Philip Cheong* *Elastx *| Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 870 814 twitter: @Elastx https://twitter.com/Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Bringing some DevOps love to Openstack
Hi all, In preparation of the OpenStack Summit in Paris next week, I'm hoping to speak to some people in the OpenStack foundation about the benefits of a partnership with Hashicorp, who make fantastic tools like Vagrant and Packer (and others). As a n00b aspiring to become an OpenStack contributor, the variety of Vagrant devstack environments is pretty overwhelming. It appears to me that it really depends on what project you are contributing to, which denotes which devstack you should use. The ones I have tried take a long time (45 mins+) to provision from scratch. One aspect which I am acutely aware of is developer productivity and 45 minutes is a lot of time. Packer was designed to help alleviate bottleneck, and Vagrantcloud has inbuilt support for the versioning of Vagrant boxes. It would be a pretty straight forward exercise to use Packer to do a daily (or however often) build of a devstack box and upload it to Vagrantcloud for developers to download. With a decent internet connection that time would be significantly less than 45 minutes. I would really like to think that this community should also be able to come to a consensus over what to include in a standard devstack. That there currently seems to be many different flavours cannot help with issues of fragmentation between so many different moving parts to build an OpenStack environment. Another big issue that I hope to address with the foundation, is the integration of Hashicorp's tools with OpenStack. The various Vagrant plugins to add OpenStack as a provider is a mess. There is one specific for Rackspace who have a different Keystone API, and at least 3 others for the vanilla OpenStack: https://github.com/mitchellh/vagrant-rackspace https://github.com/ggiamarchi/vagrant-openstack-provider https://github.com/cloudbau/vagrant-openstack-plugin https://github.com/FlaPer87/vagrant-openstack The significance of not having an official provider, for one example, is when you use Packer to build an image in OpenStack and try to post-process it into a Vagrant box, it bombs with this error: == openstack: Running post-processor: vagrant Build 'openstack' errored: 1 error(s) occurred: * Post-processor failed: Unknown artifact type, can't build box: mitchellh.openstack Because Packer doesn't know what Vagrant expects the provider to be, as explained here https://github.com/mitchellh/packer/issues/776. In my opinion this a pretty big issue holding back the wider acceptance of OpenStack. When I am at a customer and introduce them to tools like Vagrant and Packer and how well they work with AWS, I still avoid the conversation about OpenStack when I would really love to put them on our (Elastx's) public cloud. What say you? Could I get a +1 from those who see this as a worthwhile issue? Cheers, Phil. -- *Philip Cheong* *Elastx *| Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 870 814 twitter: @Elastx https://twitter.com/Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [solum] N00b problems running solum
Hello hello!
I'm trying to bring up a solum development environment with vagrant
devstack, but I'm having problems running any of the example assemblys.
They all get suck at status BUILDING like follows:
vagrant@devstack:/var/log/solum/worker$ solum assembly show
5c8c26fc-6c9c-460d-b26a-4ac57a86ca82
+-++
| Property| Value
|
+-++
| status | BUILDING
|
| description | test assembly
|
| application_uri | None
|
| name| ex1
|
| trigger_uri |
http://10.0.2.15:9777/v1/triggers/4664cc77-77e4-4ecc-8ba9-784204bee273 |
| uuid| 5c8c26fc-6c9c-460d-b26a-4ac57a86ca82
|
+-++
The solum worker looks likes it built the docker image successfully:
{ @timestamp: 2014-10-20 22:16:37.272, project_id:
e1bbe85dcd334626891c41462c382af9, build_id:
56476b9d5bc7d12eaf36696fe85baa75ccd51328715a9c617846f04baa94d94e, task:
build, message: Step 5 : CMD start web}
{ @timestamp: 2014-10-20 22:16:37.355, project_id:
e1bbe85dcd334626891c41462c382af9, build_id:
56476b9d5bc7d12eaf36696fe85baa75ccd51328715a9c617846f04baa94d94e, task:
build, message: --- Running in d128f920e976}
{ @timestamp: 2014-10-20 22:16:44.986, project_id:
e1bbe85dcd334626891c41462c382af9, build_id:
56476b9d5bc7d12eaf36696fe85baa75ccd51328715a9c617846f04baa94d94e, task:
build, message: --- 8b540a8b4899}
{ @timestamp: 2014-10-20 22:16:45.893, project_id:
e1bbe85dcd334626891c41462c382af9, build_id:
56476b9d5bc7d12eaf36696fe85baa75ccd51328715a9c617846f04baa94d94e, task:
build, message: Removing intermediate container d128f920e976}
{ @timestamp: 2014-10-20 22:16:45.896, project_id:
e1bbe85dcd334626891c41462c382af9, build_id:
56476b9d5bc7d12eaf36696fe85baa75ccd51328715a9c617846f04baa94d94e, task:
build, message: Successfully built 8b540a8b4899}
{ @timestamp: 2014-10-20 22:16:45.919, project_id:
e1bbe85dcd334626891c41462c382af9, build_id:
56476b9d5bc7d12eaf36696fe85baa75ccd51328715a9c617846f04baa94d94e, task:
build, message: Finished: sudo docker build -t nodeus . [Elapsed: 43
sec] (EXIT_STATUS=0)}
{ @timestamp: 2014-10-20 22:18:05.596, project_id:
e1bbe85dcd334626891c41462c382af9, build_id:
56476b9d5bc7d12eaf36696fe85baa75ccd51328715a9c617846f04baa94d94e, task:
build, message: = Total elapsed time: 166 sec}
{ @timestamp: 2014-10-20 22:18:05.604, project_id:
e1bbe85dcd334626891c41462c382af9, build_id:
56476b9d5bc7d12eaf36696fe85baa75ccd51328715a9c617846f04baa94d94e, task:
build, message: created_image_id= ID}
In on the HEAD of master:
commit 6e764bb9d7f831a722ffa2ed6530060ec2f48b82
Author: Ed Cranford ed.cranf...@rackspace.com
Date: Thu Oct 16 10:27:07 2014 -0500
Any tips?
Thanks,
Phil.
--
*Philip Cheong*
*Elastx *| Public and Private PaaS
email: philip.che...@elastx.se
office: +46 8 557 728 10
mobile: +46 702 870 814
twitter: @Elastx https://twitter.com/Elastx
http://elastx.se
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack][Docker] Run OpenStack Service in Docker Container
I think it's a very interesting test for docker. I too have been think about this for some time to try and dockerise OpenStack services, but as the usual story goes, I have plenty things I'd love to try, but there are only so many hours in a day... Would definitely be interested to hear if anyone has attempted this and what the outcome was. Any suggestions on what the most appropriate service would be to begin with? On 14 August 2014 14:54, Jay Lau jay.lau@gmail.com wrote: I see a few mentions of OpenStack services themselves being containerized in Docker. Is this a serious trend in the community? http://allthingsopen.com/2014/02/12/why-containers-for-openstack-services/ -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Philip Cheong* *Elastx *| Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 8170 814 twitter: @Elastx https://twitter.com/Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] The future of the integrated release
This thread couldn't help but make me wonder what kind of problems people hit developing on the linux kernel. I discovered this pretty incredible article which seemed to have enough relevant information in it to post it, but also give me the hopes that Openstack and it's contributors are different enough that we can avoid similar issues. Gives some perspective at least... http://arstechnica.com/information-technology/2013/07/linus-torvalds-defends-his-right-to-shame-linux-kernel-developers/ 2014-08-08 11:58 GMT+02:00 Nikola Đipanov ndipa...@redhat.com: On 08/08/2014 11:37 AM, Thierry Carrez wrote: Personally I think we just need to get better at communicating the downstream expectations, so that if we create waste, it's clearly upstream fault rather than downstream. Currently it's the lack of communication that makes developers produce more / something else than what core reviewers want to see. Any tool that lets us communicate expectations better is welcome, and I think the runway approach is one such tool, simple enough to understand. I strongly agree with everything here except the last part of the last sentence. To me the runway approach seems like yet another set of arbitrary hoops that we will put in place so that we don't have to tell people that we don't have bandwidth/willingness to review and help their contribution in. It is process over communication at it's finest and will in no way help to foster an open and honest communication in the community IMHO. I don't see it making matters any worse, since I think what we have now is more or less that with one layer of processes less, but I don't see it making things better either. The biggest issue I see is that there is no justifiable metric with which we can back up assigning a slot to a feature other than we say so. We can do that just as easily without runways. I'd love for someone to tell me what am I missing here... Nikola ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Philip Cheong* *Elastx *| Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 8170 814 twitter: @Elastx https://twitter.com/Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] 5 node Openstack Icehouse with Vagrant and Puppet on Virtualbox and Centos 6.5
Greetings to all! So I'm learning Openstack and hope some day to add my name among the list of contributors (maybe on something like Solum). My first real foray into the Openstack world was to build myself a multi-node environment and is available here https://github.com/phiche/vagrant-puppet-openstack In this example I used Vagrant and Puppet enterprise and the puppet modules from puppetlabs. My simple target was to have a single Vagrantfile that could bring up a fully functional multi-node environment at the push of a button (i.e. vagrant up). I discovered that goal was perhaps overly ambitious. But anyways, it works (with a bit of massaging). Hopefully it might be useful to others, if nothing else but perhaps for some amusement. Happy to hear feedback if you try it! Phil -- *Philip Cheong* *Elastx *| Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 8170 814 twitter: @Elastx https://twitter.com/Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
