Re: [openstack-dev] [Solum] Should app names be unique?
I can attest to the customer preference (from the customer survey and research) to working with names (as opposed to UUIDs). My vote would be to optimize for user experience, and then figure out an implementation approach that solves for that. On the question on blue-green deployments, I am not bought in that having duplicate names is the most elegant way to support the feature. It will be worthwhile for one of us to propose a solution for blue-green deployments that works with enforcement of unique app names. As the examples below indicate, there is no consistency within open stack on allowing duplicate names. From: Murali Allada [mailto:murali.all...@rackspace.com] Sent: Wednesday, March 11, 2015 3:12 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Solum] Should app names be unique? The only reason this came up yesterday is because we wanted Solums 'app create' behavior to be consistent with other openstack services. However, if heat has a unique stack name constraint and glance\nova don't, then the argument of consistency does not hold. I'm still of the opinion that we should have a unique name constraint for apps and languagepacks within a tenants namespace, as it can get very confusing if a user creates multiple apps with the same name. Also, customer research done here at Rackspace has shown that users prefer using 'names' rather than 'UUIDs'. -Murali From: Devdatta Kulkarni devdatta.kulka...@rackspace.commailto:devdatta.kulka...@rackspace.com Sent: Wednesday, March 11, 2015 2:48 PM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Solum] Should app names be unique? Hi Solum team, In yesterday's team meeting the question of whether Solum should enforce unique app name constraint within a tenant came up. As a recollection, in Solum one can create an 'app' using: solum app create --plan-file plan-file --name app-name Currently Solum does support creating multiple apps with the same name. However, in yesterday's meeting we were debating/discussing whether this should be the case. The meeting log is available here: http://eavesdrop.openstack.org/meetings/solum_team_meeting/2015/solum_team_meeting.2015-03-10-21.00.log.html To set the context for discussion, consider the following: - heroku does not allow creating another app with the same name as that of an already existing app - github does not allow creating another repository with the same name as that of an already existing repo Thinking about why this might be in case for heroku, one aspect that comes to mind is the setting of a 'remote' using the app name. When we do a 'git push', it happens to this remote. When we don't specify a remote in 'git push' command, git defaults to using the 'origin' remote. Even if multiple remotes with the same name were to be possible, when using an implicit command such as 'git push', in which some of the input comes from the context, the system will not be able to disambiguate which remote to use. So requiring unique names ensures that there is no ambiguity when using such implicit commands. This might also be the reason why on github we cannot create repository with an already existing name. But this is just a guess for why unique names might be required. I could be totally off. I think Solum's use case is similar. Agreed that Solum currently does not host application repositories and so there is no question of Solum generated remotes. But by allowing non-unique app names it might be difficult to support this feature in the future. As an aside, I checked what position other Openstack services take on this issue. 1) Heat enforces unique stack-name constraint. 2) Nova does not enforce this constraint. So it is clear that within Openstack there is no consistency on this issue. What should Solum do? Thoughts? Best regards, Devdatta __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Contributing to Solum
Hi Keyvan, good to know of your interest in contributing to project Solum. If useful, Adrian and myself are available for a call with you to better understand your motivation around Solum and help you with getting plugged in a meaningful way. From: Keyvan Mir Mohammad Sadeghi [mailto:keyvan.m.sade...@gmail.com] Sent: Tuesday, November 18, 2014 4:52 AM To: openstack-dev@lists.openstack.org Cc: Amirhossein Nourani Zadeh; Mehdi Balouchi; Ramin Barati Subject: [openstack-dev] [Solum] Contributing to Solum Hi, I am not even sure that I'm posting this in the right place, but the official Solum website was rather sparse on info regarding where to start. As a compact intro, my name is Keyvan, I've been an active OSS developer/adminhttps://github.com/keyvan-m-sadeghi since 2011, mainly working on the OpenCog projecthttps://github.com/opencog/opencog. I am planning to create a cloud platform, in the long-term. We are a team of 4 ppl, right now we're most interested in Solum, as it'd make a strong ground for our ideas. We all have strong Python skills and the team is willing to set aside around 10 hrs / week for Solum development, initially. I've read the wiki and there doesn't seem to be an 'Ideas' page where I could see a list of projects to be done, best thing I've found so far was the bugs pagehttps://bugs.launchpad.net/solum, but I'm not sure on where to start. We really appreciate if someone could define a small-sized project for us to undertake; that serves both for the purpose of getting to know Solum code more in depth and also set a start for our contribution. Regards, Keyvan -- Keyvan Mir Mohammad Sadeghi MSc AI One has to pay dearly for immortality; one has to die several times while one is still alive. -- Friedrich Nietzsche ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Core Reviewer Change
Murali, James, congratulations on core reviewer status ! -Original Message- From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: Wednesday, October 01, 2014 1:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Core Reviewer Change Thanks everyone for your feedback on this. The adjustments have been made. Regards, Adrian On Sep 30, 2014, at 10:03 AM, Adrian Otto adrian.o...@rackspace.com wrote: Solum Core Reviewer Team, I propose the following change to our core reviewer group: -lifeless (Robert Collins) [inactive] +murali-allada (Murali Allada) +james-li (James Li) Please let me know your votes (+1, 0, or -1). Thanks, Adrian ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] Juno-3 Items
Hi, following up from last week's IRC meeting, I updated the Solum roadmap wiki with items for consideration for Juno-3. Please mail back your comments/suggestions, as well as we can discuss more in the next IRC and finalize Juno release scope. Wiki link: https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap#Milestone_2014.2.3:_Juno-3 MILESTONE 2014.2.3: JUNO-3 == . Jenkins Integration: as a customer already using Jenkins for my CI needs, I would be able to integrate my Jenkins CI instance with Solum and have access to Solum features (i.e. persist build output produced by Jenkins in glance via Solum, automated deployments, etc.) . Trove Integration: as an application developer, I would be able to deploy apps that have ready access to trove MySQL service. . Horizontal Scaleout: as an application developer, I would be able to horizontal scale out my apps via a load balanced set of app container instances . LanguagePack-Java Tomcat 7: as an application developer, I can deploy my Java Tomcat 7 web app via Solum without having to deal with build scripts or setup of the language runtime . LanguagePack-Node.js: as an application developer, I can deploy my Node.js web app via Solum without having to deal with setup of the language runtime . Sample apps: as an application developer, I can build my apps without having to start from scratch by customizing sample apps provided by Solum. Sample Apps for Java Tomcat 7 and Node.js Thanks Regards, Roshan Agrawal Direct: 512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Core Reviewer Change
Pierre, welcome to Solum Core !! -Original Message- From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: Wednesday, July 09, 2014 1:13 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Core Reviewer Change Thanks everyone for your input. The change has been applied. Welcome Pierre! Regards, Adrian On Jul 9, 2014, at 2:26 AM, Adrian Otto adrian.o...@rackspace.com wrote: Solum Core Reviewer Team, I propose the following change to our core reviewer group: +stannie (Pierre Padrixe) Please let me know your votes (+1, 0, or -1). Thanks, Adrian ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [solum] reviews for the new API
Agreeing with what Murali said below. We should make things really simple for the 99 percentile of the users, and not force the complexity needed by the minority of the advanced users on the rest of the 99 percentile users. Mistral is a generic workflow DSL, we do not need to expose all that complexity to the Solum user that wants to customize the pipeline. Non-advanced users will have a need to customize the pipeline. In this case, the user is not necessarily the developer persona, but typically an admin/release manager persona. Pipeline customization should be doable easily, without having the understand or author a generic workflow DSL. For the really advanced user who needs to have a finer grained need to tweak the mistral workflow DSL (I am not sure if there will be a use case for this if we have the right customizations exposed via the pipeline API), we should have the option for the user to tweak the mistral DSL directly, but we should not expect 99.9% (or more) of the users to deal with a generic workflow. From: Murali Allada [mailto:murali.all...@rackspace.com] Sent: Wednesday, June 04, 2014 12:09 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [solum] reviews for the new API Angus/Julien, I would disagree that we should expose the mistral DSL to end users. What if we decide to use something other than Mistral in the future? We should be able to plug in any workflow system we want without changing what we expose to the end user. To me, the pipeline DSL is similar to our plan file. We don't expose a heat template to our end users. Murali On Jun 4, 2014, at 10:58 AM, Julien Vey vey.jul...@gmail.commailto:vey.jul...@gmail.com wrote: Hi Angus, I really agree with you. I would insist on #3, most of our users will use the default workbook, and only advanced users will want to customize the workflow. advanced users should easily understand a mistral workbook, cause they are advanced To add to the cons of creating our own DSL, it will require a lot more work, more design discussions, more maintenance... We might end up doing what mistral is already doing. If we have some difficulties with Mistral's DSL, we can talk with the team, and contribute back our experience of using Mistral. Julien 2014-06-04 14:11 GMT+02:00 Angus Salkeld angus.salk...@rackspace.commailto:angus.salk...@rackspace.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all I have posted this series and it has evoked a surprising (to me) amount of discussion so I wanted to clarify some things and talk to some of the issues so we can move forward. So first note is this is an early posting and still is not tested much. https://review.openstack.org/#/q/status:open+project:stackforge/solum+branch:master+topic:new-api,n,z First the terminology I have a pipeline meaning the association between a mistral workbook, a trigger url and a plan. This is a running entity not just a different workbook. The main issue seems to be the extent to which I am exposing the mistral workbook. Many of you expected a simpler workflow DSL that would be converted into the mistral workbook. The reason for me doing it this way are: 1) so we don't have to write much code 2) this is an iterative process. Let's try it the simple way first and only make it more complicated if we really need to (the agile way?). 3) to be consistent in the way we treat heat templates, mistral workbooks and language packs - i.e. we provide standard ones and allow you to customize down to the underlying openstack primitives if you want (we should aim for this to be only a small percentage of our users). eg. pipeline == (check-build-deploy mistral workbook + basic-docker heat template + custom plan) here the user just choose the heat template and workbook from a list of options. 4) if the mistral dsl is difficult for our users to work with we should give the mistral devs a chance to improve it before working around it. 5) our users are primary developers and I don't think the current mistral DSL is tricky to figure out for someone that can code. 6) doing it this way we can make use of heat and mistral's horizon plugins and link to them from the pipeline instead of having to redo all of the same pages. In a similar why that heat links to servers/volumes etc from a running stack. - -Angus Some things to note: - - the entire mistral engine can be replaced with an engine level plugin -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTjwz2AAoJEFrDYBLxZjWoEr0H/3nh66Umdw2nGUEs+SikigXa XAN90NHHPuf1ssEqrF/rMjRKg+GvrLx+31x4oFfHEj7oplzGeVA9TJC0HOp4h6dh iCeXAHF7KX+t4M4VuZ0y9TJB/jLxfxg4Qge7ENJpNDD/gggjMYSNhcWzBG87QBE/ Mi4YAvxNk1/C3/YZYx2Iujq7oM+6tflTeuoG6Ld72JMHryWT5/tdYZrCMnuD4F7Q 8a6Ge3t1dQh7ZlNHEuRDAg3G5oy+FInXyFasXYlYbtdpTxDL8/HbXegyAcsw42on
Re: [openstack-dev] [solum] reviews for the new API
I documented a starting point for What can be customized in the CI Pipeline. Hopefully this helps in the design discussion Take a look at the google docs below: https://docs.google.com/document/d/1a0yjxKWbwnY7g9NZtYALEZdm1g8Uf4fixDZLAgRBZCU/edit?pli=1# From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: Wednesday, June 04, 2014 2:58 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [solum] reviews for the new API Good question Randall. Either we implement some workflow, which is what we do now that is not configurable, or we adopt another workflow system. We figured that using an existing workflow system would be smarter than duplicating one by making Solum any more configurable. We have plans to allow the workflow component to be pluggable, so if you prefer to have Jenkins or xyz underneath, that would be possible. We selected Mistral as a first implementation attempt since we already use a devstack environment for the basic deployment, and adding Mistral to that is rather easy. Adrian Sent from my Verizon Wireless 4G LTE smartphone Original message From: Randall Burt Date:06/04/2014 12:35 PM (GMT-08:00) To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [solum] reviews for the new API Sorry to poke my head in, but doesn't that beg the question of why you'd want to expose some third party DSL in the first place? If its an advanced feature, I wonder why it would be even considered before the 90% solution works, much less take a dependency on another non-integrated service. IMO, the value of Solum initially lies in addressing that 90% CI/CD/ALM solution well and in a way that doesn't require me to deploy and maintain an additional service that's not part of integrated OpenStack. At best, it would seem prudent to me to simply allow for a basic way for me to insert my own CI/CD steps and be prescriptive about how those custom steps participate in Solum's workflow rather than locking me into some specific workflow DSL. If I then choose to use Mistral to do some custom work, I can, but Solum shouldn't care what I use. If Solum isn't fairly opinionated (at least early on) about the basic CI/CD-ALM lifecycle and the steps therein, I would question its utility if its a wrapper over my existing Jenkins jobs and a workflow service. On Jun 4, 2014, at 1:10 PM, Julien Vey vey.jul...@gmail.commailto:vey.jul...@gmail.com wrote: Murali, Roshan. I think there is a misunderstood. By default, the user wouldn't see any workflow dsl. If the user does not specify anything, we would use a pre-defined mistral workbook defined by Solum, as Adrian described If the user needs more, mistral is not so complicated. Have a look at this example Angus has done https://review.openstack.org/#/c/95709/4/etc/solum/workbooks/build.yaml We can define anything as solum actions, and the users would just have to call one of this actions. Solum takes care of the implementation. If we have comments about the DSL, Mistral's team is willing to help. Our end-users will be developers, and a lot of them will need a custom workflow at some point. For instance, if Jenkins has so many plugins, it's because there are as many custom build workflows, specific to each company. If we add an abstraction on top of mistral or any other workflow engine, we will lock developers in our own decisions, and any additional feature would require a new development in Solum, whereas exposing (when users want it) mistral, we would allow for any customization. Julien 2014-06-04 19:50 GMT+02:00 Roshan Agrawal roshan.agra...@rackspace.commailto:roshan.agra...@rackspace.com: Agreeing with what Murali said below. We should make things really simple for the 99 percentile of the users, and not force the complexity needed by the minority of the advanced users on the rest of the 99 percentile users. Mistral is a generic workflow DSL, we do not need to expose all that complexity to the Solum user that wants to customize the pipeline. Non-advanced users will have a need to customize the pipeline. In this case, the user is not necessarily the developer persona, but typically an admin/release manager persona. Pipeline customization should be doable easily, without having the understand or author a generic workflow DSL. For the really advanced user who needs to have a finer grained need to tweak the mistral workflow DSL (I am not sure if there will be a use case for this if we have the right customizations exposed via the pipeline API), we should have the option for the user to tweak the mistral DSL directly, but we should not expect 99.9% (or more) of the users to deal with a generic workflow. From: Murali Allada [mailto:murali.all...@rackspace.com] Sent: Wednesday, June 04, 2014 12:09 PM To: OpenStack Development Mailing List (not for usage questions
[openstack-dev] [solum] Solum roadmap for review
I updated the high level roadmap for the program and the project vision https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap Let us use the Solum workshop meeting today to go over and refine it. Thanks Regards, Roshan Agrawal Direct: 512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Solum Demo@Summit
Interested in a sneak peak at Solum? Hop over for a VBrownBag demo tomorrow (Wednesday) at the Summit Room B207. What: Solum demo When: Wednesday 12:45 pm - 1:00 pm Where: Summit Room B207 You can also watch a 2 min clip of the demo @ http://vimeo.com/94905913 Thanks Regards, Roshan Agrawal ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [solum] Program and Project vision Wiki
Here is the wiki for the Program and Project mission statement. https://wiki.openstack.org/wiki/Solum/MissionStatement, please edit in place as needed on the wiki Below is the ether pad for reference: https://etherpad.openstack.org/p/solum-mission Thanks Regards, Roshan Agrawal Direct:512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.commailto:roshan.agra...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [solum] Agenda for design workshop at Atlanta
The solum team would be meeting at Atlanta on Wednesday for a design workshop session Wednesday, May 14 1:50pm - 5:20pm: Open Source Comm Project Solum I created an ether pad page for coming up with agenda for the session. Please enter in your inputs on the page - https://etherpad.openstack.org/p/SolumSummitAgenda Thanks Regards, Roshan Agrawal Direct: 512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [solum] [heat] Environments Working Group
Per decision in the the Solum weekly IRC meeting today, we will have the environment working group discussion via ML/etherpad. GOAL: develop a POV on 1. Which OpenStack program/projects should Environments live under 2. What projects does Environments depend on (Heat, Keystone, OpenStack congress, etc.) 3. What discussions do we need to drive in the OpenStack Atlanta summit to get Environments added to relevant project roadmaps Etherpad for discussion: https://etherpad.openstack.org/p/Environments . Do jump in and share your input on etherpad and ML We will still go ahead and have a placeholder meeting for Wed May 7th 9 am US Central time, just in case we need it. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] Environments Working Group
The most popular time slot right now is Wed 4:30 pm Central US time. The issue with this time though is that it is bad time for folks in India and Europe [Noorul, Rajdeep, Julien] I have added a few more time slot options [8 am, 9 am central US time]. Please retake the poll keeping in view that we have to accommodate folks from Europe and India as well. http://doodle.com/n4w9gmekwz58ekdz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [solum] Environments Working Group
Let us meet to develop a POV on 1. Which OpenStack program/project should Environments live under 2. What projects does Environments depend on (Heat, Keystone, OpenStack congress, etc.) Here is a set of environment use cases to frame the notion of environments - https://wiki.openstack.org/wiki/Solum/Environments Please indicate your availability for an IRC meeting on the doodle poll: http://doodle.com/n4w9gmekwz58ekdz It is worth noting that we are scheduling with participants across 5 times zones ! [US CST, US PST, Europe, Australia, India]. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Environments Use Cases
Julien, good inputs. I will make updates to the wiki after compiling feedback from today's IRC From: Julien Vey [vey.jul...@gmail.com] Sent: Monday, April 14, 2014 3:14 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Environments Use Cases Hi Roshan, Happy to see you start the discussion about environments Angus also started a wiki page on this https://wiki.openstack.org/wiki/Solum/ApiModel but on a more technical level. And we discussed it a little on this review https://review.openstack.org/#/c/84434/ About the use-cases you described, here are some comments: #1 : I don't think it should be the developer responsibility to say where his application gets deployed. It should have been decided during the creation of the environments, what would be the chaining of environnements. A developer would only push his code to the first environment, and the promotions are responsible of the rest. #3 : I think a better way to say it would be As a release manager, I can choose how many resources I allocate to each environnement. I don't think we need quota or threshold #4 : Good point! #6 : The artifact generated by the build job will never get rebuild (a WAR archive for instance, in case of a Java WebApp), but the DU might be. For instance, we might want to use docker for Dev/Testing and VMs for production Regards Julien 2014-04-14 21:43 GMT+02:00 Roshan Agrawal roshan.agra...@rackspace.commailto:roshan.agra...@rackspace.com: As a follow up to our F2F discussion at Raleigh on Environments, I have documented an initial set of use cases as it relates to Environments: https://wiki.openstack.org/wiki/Solum/Environments The goal of this discussion thread on Environments is for the Solum team to develop a POV on what Environment is, and which project(s) in OpenStack should own it. With this, we should be able to go into the Atlanta summit and engage in discussions with the relevant project teams. We can discuss in the IRC meeting tomorrow, meanwhile would appreciate your feedback on what is documented above. Thanks Regards, Roshan Agrawal Direct:512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.commailto:roshan.agra...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
[openstack-dev] [Solum] Environments Use Cases
As a follow up to our F2F discussion at Raleigh on Environments, I have documented an initial set of use cases as it relates to Environments: https://wiki.openstack.org/wiki/Solum/Environments The goal of this discussion thread on Environments is for the Solum team to develop a POV on what Environment is, and which project(s) in OpenStack should own it. With this, we should be able to go into the Atlanta summit and engage in discussions with the relevant project teams. We can discuss in the IRC meeting tomorrow, meanwhile would appreciate your feedback on what is documented above. Thanks Regards, Roshan Agrawal Direct:512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.commailto:roshan.agra...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Proposed Core Reviewer Changes
+ 1 From: Adrian Otto [adrian.o...@rackspace.com] Sent: Tuesday, March 18, 2014 12:13 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Solum] Proposed Core Reviewer Changes Solum Cores, I propose the following changes to the Solum core reviewer team: +gokrokve +julienvey +devdatta-kulkarni -kgriffs (inactivity) -russelb (inactivity) Please reply with your +1 votes to proceed with this change, or any remarks to the contrary. Thanks, Adrian ___ 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
[openstack-dev] [Solum] Milestone 1 End to end scenario
It is exciting to see we are getting close to delivering the first end to end use case for Solum ! Though we have blueprints to track individual work items for Milestone 1, it is useful to have a view into exactly what end to end experience we will be delivering. I have made an attempt at documenting that, and linked to the Solum High Level Roadmap wiki: https://wiki.openstack.org/wiki/Solum/Milestone1 The goal is not to have a comprehensive listing of all features delivered in M1, but rather to summarize in a few lines the desired outcome from a user perspective. Comments, suggestions welcome. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Milestone 1 End to end scenario
Thanks Dev. Done. -Original Message- From: devdatta kulkarni [mailto:devdatta.kulka...@rackspace.com] Sent: Monday, February 10, 2014 12:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Milestone 1 End to end scenario Hi Roshan, Great to see the big picture that we are targeting. Some minor comments/suggestions: 1) It will be helpful to explicitly call out in the first step that the git repositories are not hosted by Solum but are public repositories on github.com 1) In step 3, what do you mean by 'automatic' deployment? I would suggest we remove that word. 2) It will help if we use two different terms to identify the end users of an application and the developer of an application. In the line 'Only authorized users .. access the service', I think you mean 'only application developers who are also registered with Solum will be able to access the Solum API service'. In its current form it is not clear whether 'users' refer to developers or application users and whether 'service' refers to solum API or the running application. Similarly in the last line the last word can be changed from 'user' to 'API user'. Thanks, Devdatta -Original Message- From: Roshan Agrawal roshan.agra...@rackspace.com Sent: Monday, February 10, 2014 12:28pm To: openstack-dev@lists.openstack.org openstack- d...@lists.openstack.org Subject: [openstack-dev] [Solum] Milestone 1 End to end scenario It is exciting to see we are getting close to delivering the first end to end use case for Solum ! Though we have blueprints to track individual work items for Milestone 1, it is useful to have a view into exactly what end to end experience we will be delivering. I have made an attempt at documenting that, and linked to the Solum High Level Roadmap wiki: https://wiki.openstack.org/wiki/Solum/Milestone1 The goal is not to have a comprehensive listing of all features delivered in M1, but rather to summarize in a few lines the desired outcome from a user perspective. Comments, suggestions welcome. ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Proposed changes to solum-core
+1 From: Rajesh Ramchandani [rajesh.ramchand...@cumulogic.com] Sent: Friday, January 24, 2014 9:35 PM To: OpenStack Development Mailing List (not for usage questions) Cc: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Solum] Proposed changes to solum-core +1 On Jan 24, 2014, at 5:35 PM, Adrian Otto adrian.o...@rackspace.com wrote: Solum Core Reviewers, I propose the following changes to solum-core: +asalkeld +noorul -mordred Thanks very much to mordred for helping me to bootstrap the reviewer team. Please reply with your votes. Thanks, Adrian ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Diesel] Proposal for new project
Diesel seems to be a subset of what Solum delivers. For reference: Solum Wiki: https://wiki.openstack.org/wiki/Solum Solum Roadmap: https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap We should discuss combining efforts instead of duplicating initiatives. From: Jay Pipes [jaypi...@gmail.com] Sent: Saturday, January 18, 2014 12:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Diesel] Proposal for new project On Sat, 2014-01-18 at 03:31 +, Raymond, Rob wrote: I would like to gauge interest in a new project named Diesel. https://wiki.openstack.org/wiki/Diesel If you are already familiar with Savanna, the best way to describe it is: Savanna is to map reduce applications as Diesel is to web applications. The mission of Diesel is to allow OpenStack clouds to run applications. The cloud administrator can control the non functional aspects, freeing up the application developer to focus on their application and its functionality. In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel runs web applications in the cloud. It can be used by cloud administrators to define the application types that they support. They are also responsible for defining through Diesel how these applications run on top of their cloud infrastructure. Diesel will control the availability and scalability of the web application deployment. Hi Rob, So I've read through the above wiki page a couple times, and I'm really having trouble understanding how Diesel differs from Solum. In the wiki page, you mention: Solum - Solum is focused on the development lifecycle for the application. The application may be one that Diesel can run. Could you elaborate on how you envision how Diesel differs from Solum in its basic intent? Solum deploys applications into a cloud. Diesel is intended to run applications in clouds, but I'm not sure how there is a difference between deploying an application into a cloud and running one. Perhaps I'm just missing something, though, so perhaps you might elaboraste? Best, -jay ___ 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
Re: [openstack-dev] [Solum] CLI minimal implementation
-Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: Monday, December 02, 2013 8:17 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Solum] CLI minimal implementation On 12/02/2013 07:03 PM, Roshan Agrawal wrote: I have created a child blueprint to define scope for the minimal implementation of the CLI to consider for milestone 1. https://blueprints.launchpad.net/solum/+spec/cli-minimal-implementatio n Spec for the minimal CLI @ https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/CLI-minimal-im plementation Etherpad for discussion notes: https://etherpad.openstack.org/p/MinimalCLI Would look for feedback on the ML, etherpad and discuss more in the weekly IRC meeting tomorrow. What is this R1.N syntax? How does it relate to development milestones? Does R1 mean a requirement for milestone-1? These do not relate to development milestones. R1 is a unique identified for the given requirement. R1.x is a unique requirement Id for something that is a sub item of the top level requirement R1. Is there a more openstack standard way for generating requirements Id? For consistency, I would use commands like: solum app-create solum app-delete solum assembly-create solum assembly-delete instead of adding a space in between: solum app create to be more consistent with other clients, like: nova flavor-create nova flavor-delete glance image-create glance image-delete The current proposal is an attempt to be consistent with the direction for the openstack one CLI. Adrian's addressed it in his other reply. I would make required arguments positional arguments. So, instead of: solum app-create --plan=planname do: solum app-create planname I will make this change unless hear objections Lastly, everywhere you have a name, I would use a UUID. Names shouldn't have to be globally unique (because of multi-tenancy). UUIDs should always work, but you can support a name in the client code as a friendly shortcut, but it should fail if a unique result can not be resolved from the name. Names do not have to be globally unique; just unique within the tenant namespace. The Name+tenant combination should map to a unique uuid. The CLI is a client tool, where as a user working with names is easier. We will support both, but start with Names (the friendly shortcut), and map it to uuid behind the scenes. -- Russell Bryant ___ 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
[openstack-dev] [Solum] CLI minimal implementation
I have created a child blueprint to define scope for the minimal implementation of the CLI to consider for milestone 1. https://blueprints.launchpad.net/solum/+spec/cli-minimal-implementation Spec for the minimal CLI @ https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/CLI-minimal-implementation Etherpad for discussion notes: https://etherpad.openstack.org/p/MinimalCLI Would look for feedback on the ML, etherpad and discuss more in the weekly IRC meeting tomorrow. Thanks Regards, Roshan Agrawal Direct: 512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] API worker architecture
We should probably include support for asynchronous responses right from the beginning to handle calls that need a long time to process. Is this in line with what you were thinking ? I am referring to your comment in the blueprint To start things off, we can implement workflow #1 shown above and make all requests synchronous From: Murali Allada [mailto:murali.all...@rackspace.com] Sent: Wednesday, November 27, 2013 12:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Solum] API worker architecture Hi all, I'm working on a new blueprint to define the API service architecture. https://blueprints.launchpad.net/solum/+spec/api-worker-architecture It is still a draft for now. I've proposed a simple architecture for us to get started with implementing a few useful use cases. Please chime in on the mailing list with your thoughts. Thanks, Murali ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum]: Etherpad notes for today's workshop
https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes I also took a stab at documenting the minimal set of features Solum should implement for the first milestone at the etherpad page above Thanks Regards, Roshan Agrawal Direct: 512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] SFO Design Workshop
We are all set for the Solum design workshops at SFO on Nov 19,20. The etherpad page below has schedule and agenda details https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop Please sign up as topic leads/scribe for the sessions listed in the agenda. We also have etherpad pages setup for each track of discussion, and we can fill in content right away to prep for the lively discussions next week. We also have a happy hour planned on the evening of Tuesday, and have lunch arrangements on the house. Looking forward to a fun and productive two days at SFO! Thanks Regards, Roshan Agrawal Direct: 512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Gated Source Code Flow (was: Weekly Team Meeting)
Speaking of tests: we have unit tests and we will have integration tests. Unit tests may not require a fully deployment application, but integration tests do. The nature of tests executed during the CI/gate process will determine what Solum API needs to be invoked [based on if we we need a fully deployment environment to run the integration tests or need something less elaborate to run the unit tests] From: Clayton Coleman [ccole...@redhat.com] Sent: Wednesday, November 13, 2013 3:09 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Gated Source Code Flow (was: Weekly Team Meeting) - Original Message - Clayton, On Nov 13, 2013, at 11:41 AM, Clayton Coleman ccole...@redhat.com wrote: - Original Message - Hello, Solum meets Tuesdays at 1600 UTC in #openstack-meeting-alt (formerly in #solum) Note: Due to the Nov 3rd change in Daylight Savings Time, this now happens at 08:00 US/Pacific (starts in about 45 minutes from now) Agenda: https://wiki.openstack.org/wiki/Meetings/Solum In the meeting yesterday there was a mention of a gated source code flow (where a push might go to an external system, and the gate system github/gerritt/etc would control when the commit goes back to the primary repository). I've added that flow to https://wiki.openstack.org/wiki/File:Solum_r01_flow.jpeg as well as a mention of the DNS abstraction (a deployed assembly may or may not have an assigned DNS identity). Are the two source change notification abstraction flows really different? Could we express this with two lines converging on Notify Solum API … in a single flow with two similar entrances. I think you hit on something fundamental - I reswizzled the diagram to show the gate flow moving into the normal source push flow after tests pass. https://wiki.openstack.org/w/images/7/72/Solum_r01_flow.jpeg One key difference that I noticed between those two proposed flows are that the gate type uses the Solum API to test code, and the push one does not. Perhaps both should run unit tests in the same way with an option to bypass steps for those who don't want them? Yeah - this also highlights that an input to the build flow might be the desired outcome - possibly no deploy, deploy, deploy as temporary assembly X, or deploy as temporary assembly X without tests. There may be consumers who wish to make Solum the end result of a flow, but if the tools and abstractions Solum offers for build and deploy are compelling, we should expect to want to let external systems utilize Solum as much as possible. Another point of discussion is whether test is part of both build and deploy, or just part of deploy. If it's part of both, perhaps deploy and build need to have similar ways of letting someone run their tests at the right opportunities. ___ 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
Re: [openstack-dev] [Solum]: Workshop dates at SFO
Based on what I am seeing on the doodle poll, we are sticking to the original dates for the workshop [Nov 19, 20] Eventbrite registration page https://www.eventbrite.com/event/9130831563 Etherpad planning page for the event https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop See you all for a great set of discussions! From: Roshan Agrawal Sent: Wednesday, November 06, 2013 8:45 PM To: openstack-dev@lists.openstack.org Subject: [Solum]: Workshop dates at SFO Folks, some of us indicated they cannot make Nov 19,20, so I created a doodle poll to finalize a date that works for most of us. Please take a moment to indicate your preference on the doodle link below - http://www.doodle.com/6yey9nfgfapzv4f8 Please get this done by EOD if you can. Thanks, Roshan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Design Workshop at SFO
Re-sending details for the upcoming Solum workshop at SFO on popular demand We will also have an events section on Solum.io for this kind of communication in the next week or so. Please confirm your attendance by visiting the eventbrite page: https://www.eventbrite.com/event/9130831563 . This is important so we get an accurate count of attendees. From: Roshan Agrawal Sent: Friday, November 01, 2013 3:17 PM To: openstack-dev@lists.openstack.org Subject: [Solum] Design Workshop at SFO Hello, we are locked down on the plan to hold design workshops on Solum at SFO! It it now time to confirm your participation, and make travel arrangements. Please confirm your attendance by visiting the eventbrite page: https://www.eventbrite.com/event/9130831563 . This is important so we get an accurate count of attendees. Workshop dates: Nov 19, 20 Location: Rackspace SFO office (620 Folsom St, San Francisco, CA 94107) Purpose: working sessions for Solum contributors to discuss design/blueprints. Meeting Structure Nov 19 Tuesday 9:00 am - 5 pm 9:00 - 9:30: check-in 9:30 - 10:00: introductions, agenda 10:00 - 5:00: Roundtable workshop, whiteboarding 5:30 - 7:00: Happy hour (3rd floor at the Rackspace SFO office) Nov 20 Wednesday 9:30 am - 3:00 pm : Continue workshops Workshop Concludes 3 pm Wednesday Please refer to the etherpad page below for the latest info on the event, and to provide input on discussion topics for the workshop. https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop Thanks, and look forward to seeing you all at the event. Thanks! Roshan Agrawal ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum]: Workshop dates at SFO
Folks, some of us indicated they cannot make Nov 19,20, so I created a doodle poll to finalize a date that works for most of us. Please take a moment to indicate your preference on the doodle link below - http://www.doodle.com/6yey9nfgfapzv4f8 Please get this done by EOD if you can. Thanks, Roshan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum]: Workshop dates at SFO
Clayton, correct. We may end up sticking to the original dates; I wanted to arrive at the decision based on collective input. From: Clayton Coleman [ccole...@redhat.com] Sent: Wednesday, November 06, 2013 9:14 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum]: Workshop dates at SFO Some of us have already booked travel? On Nov 7, 2013, at 10:46 AM, Roshan Agrawal roshan.agra...@rackspace.com wrote: Folks, some of us indicated they cannot make Nov 19,20, so I created a doodle poll to finalize a date that works for most of us. Please take a moment to indicate your preference on the doodle link below - http://www.doodle.com/6yey9nfgfapzv4f8 Please get this done by EOD if you can. Thanks, Roshan ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] : Lightening Talks and Unconference Sessions
1. Lightening Talk: Today (Tuesday) at 1:40 pm 2. Unconference: Solum- Goal, Vision, Roadmap: Wednesday 12:05 -12:45 pm 3. Unconference: Solum - what OpenStack services should it leverage: Thursday 5:20 - 6:00 pm See you all there!! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum]: Welcome to the community site for Solum !!
The community site for Solum has gone live! www.Solum.iohttp://www.Solum.io - this is a landing page for all things Solum related. Also check out the blog section on the site. The logo: is a placeholder for now. We are working on a cool new logo - but the placeholder right now isn't too bad either, is it? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum]: Welcome to the community site for Solum !!
Clint, thanks. Logo - if an OpenStack related project is allowed to use the OpenStack logo, then we should absolutely do so. We can discuss in the next solum IRC meeting and decide. From: Clint Byrum [cl...@fewbar.com] Sent: Monday, November 04, 2013 7:46 PM To: openstack-dev Subject: Re: [openstack-dev] [Solum]: Welcome to the community site for Solum !! This is cool, I think other OpenStack projects would do well to have a more user-centric landing page. I have a suggestion for a logo for Solum though ... http://www.openstack.org/brand/openstack-logo/ What I mean is, rather than create a new brand.. enhance the OpenStack brand with users. Excerpts from Roshan Agrawal's message of 2013-11-05 09:25:33 +0800: The community site for Solum has gone live! www.Solum.iohttp://www.Solum.io - this is a landing page for all things Solum related. Also check out the blog section on the site. The logo: is a placeholder for now. We are working on a cool new logo - but the placeholder right now isn't too bad either, is it? ___ 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
[openstack-dev] [Solum] Design Workshop at SFO
Hello, we are locked down on the plan to hold design workshops on Solum at SFO! It it now time to confirm your participation, and make travel arrangements. Please confirm your attendance by visiting the eventbrite page: https://www.eventbrite.com/event/9130831563 . This is important so we get an accurate count of attendees. Workshop dates: Nov 19, 20 Location: Rackspace SFO office (620 Folsom St, San Francisco, CA 94107) Purpose: working sessions for Solum contributors to discuss design/blueprints. Meeting Structure Nov 19 Tuesday 9:00 am - 5 pm 9:00 - 9:30: check-in 9:30 - 10:00: introductions, agenda 10:00 - 5:00: Roundtable workshop, whiteboarding 5:30 - 7:00: Happy hour (3rd floor at the Rackspace SFO office) Nov 20 Wednesday 9:30 am - 3:00 pm : Continue workshops Workshop Concludes 3 pm Wednesday Please refer to the etherpad page below for the latest info on the event, and to provide input on discussion topics for the workshop. https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop Thanks, and look forward to seeing you all at the event. Thanks! Roshan Agrawal ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] HOLD THE DATES: Design Workshop @SFO
BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:Central Standard Time BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0500 TZOFFSETTO:-0600 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETFROM:-0600 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Roshan Agrawal:MAILTO:roshan.agra...@rackspace.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=openstack- d...@lists.openstack.org:MAILTO:openstack-dev@lists.openstack.org DESCRIPTION;LANGUAGE=en-US:When: Tuesday\, November 19\, 2013\, 9:30 AM to Wednesday\, November 20\, 2013\, 3:00 PM. (UTC-06:00) Central Time (US C anada)\nWhere: Rackspace SFO office\n\n*~*~*~*~*~*~*~*~*~*\n\nBlocking tim e on the calendars for the 2 day design workshop at SFO. More details to f ollow\, but here is the current plan:\n\n\nWorkshop sessions\nNov 19 Tuesd ay 9:30 am - 5 pm\nNov 20 Wednesday 9:30 am - 3:00 pm (we break early on W ednesday if some of us want to catch an evening return flight)\n\n\nEtherp ad for event planning-\nhttps://etherpad.openstack.org/p/SolumSFOCommunity Workshop\n\n SUMMARY;LANGUAGE=en-US:[Solum] HOLD THE DATES: Design Workshop @SFO DTSTART;TZID=Central Standard Time:20131119T093000 DTEND;TZID=Central Standard Time:20131120T15 UID:04008200E00074C5B7101A82E008117CE6277ED6CE01000 01000EB5D62ED45B251458DF7C660180FDDBA CLASS:PUBLIC PRIORITY:5 DTSTAMP:20131031T211416Z TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:0 LOCATION;LANGUAGE=en-US:Rackspace SFO office X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-OWNERAPPTID:2111502609 X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-DISALLOW-COUNTER:FALSE BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-P1D END:VALARM END:VEVENT END:VCALENDAR ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] An early peek into the Solum.io website
The Solum community website is very close to be launched publicly. If you want to take an early peek into how it is coming along, here are the access details: www.Solum.iohttp://www.Solum.io User name: Solum, password: OpenStack The Solum logo is still in works, what we have now is meant to be a placeholder till we finalize on an awesome looking logo. Comments/suggestions welcome. (Cc Solum list for now, till everyone have had a chance to migrate to the openstack list) Thanks Regards, Roshan Agrawal Product Manager-Project Solum Direct:512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.commailto:roshan.agra...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
